Object Management
Last updated
Last updated
The Active Directory Users and Computers (ADUC) Microsoft Management Console (MMC) can manage AD objects. With AD DS 2008 R2, Microsoft introduced the Active Directory Administrative Center (ADAC), which is a built-in PowerShell command-line interface technology
To access the ADAC console, you can type dsac.exe in a PowerShell command line or the Run box.
we can use the New-ADUser PowerShell cmdlet. You can view the full syntax of the command along with the accepted data types using the following command:
In order to create a new user account using PowerShell, the minimum value you need to pass is -Name . It will create a disabled user account, and you can define values for other attributes later.
Instead of executing multiple commands to create multiple user objects, we can create a Comma-Separated Values (CSV) file that includes data for attributes and use it to create accounts in one go.
When a desktop computer or member server is joined to a domain, it will create a computer object in AD. This computer object can be created before being added to the domain. This will not add the device to the domain, but it can be used with offline domain joins and RODC domain joins.
The minimum attribute you need to create a computer object is -Name:
We can use the Set-ADUser cmdlet to change and add attribute values to existing AD user objects or change the old ones:
Computer object values can also be added/changed using a similar method. In order to do so, we need to use the Set-ADComputer cmdlet:
This cmdlet can also be combined with a search query using the Get-ADComputer cmdlet:
we can use the Remove-ADUser cmdlet
This cmdlet can also be combined with the search query to find objects before removing them:
In the preceding command, we search for the user whose name starts with Test1 in the entire directory and then remove it.
The Remove-ADComputer cmdlet can be used to remove computer objects from the directory:
In the preceding command, we search for the computer objects in the given OU and then remove the findings from the directory.
The preceding command will list all of the attributes and values associated with user1 . This helps us to find the exact attribute names and common values, which can be used for further filtering.
I need to know the values for Name , UserPrincipalName , and Modified for all of the users. The following command will create a table with relevant attributes and their values:
I can see some accounts in the list that are service and administrator accounts. I only want to see the accounts in the Kingston office:
Now, I have the list of data I need, and I'd like to export it to a CSV file for future use, like so:
it can be used to filter accounts that are locked out:
A service account is a dedicated account with specific privileges that is used to run services, batch jobs, and management tasks. In most infrastructures, service accounts are typical user accounts with the Password never expire option
Microsoft's MSAs have the following:
There is no more password management. MSAs use a complex and random, 240-character password that changes automatically when it reaches the domain or computer password expiry date.
An MSA cannot be locked out or used for interactive login. Only one MSA can be used in one computer. It cannot be shared between multiple computers.
An MSA provides simplified SPN management; the system will automatically change the SPN value if the SamAccountName details of the computer change or DNS name property changes.
In order to create an MSA, we can use the following command. I am running this from the domain controller:
we have created a service account called MyAcc1 and restricted it to one computer.
The next step is to associate the service account with the host REBEL- SRV01 server, where I am going to use this service account:
The next step is to install the service account in the REBEL-SRV01 server. We need the AD PowerShell module for this. We can install it using Remote Server Administration Tools (RSAT). This can be done by running the Install-WindowsFeature RSAT-AD-Tools command. Once it's ready, run the following command:
We can test the service account using the following command:
It returns True , which means the test was successful.
From the AD server, we can verify the service account by running the following command:
There are operational requirements that require the same service account to be shared in multiple hosts. Microsoft's Network Load Balancing (NLB) feature and Internet Information Services (IIS) server farms are good examples of this. All the hosts in these server groups are required to use the same service principal for authentication. gMSAs provide the same functionalities as MSAs, but they extend the higher AD forest level.
The gMSA has the following capabilities:
No password management
Supports sharing across multiple hosts
Can be used to run scheduled tasks (MSAs do not support the running of scheduled tasks)
Uses Microsoft's Key Distribution Center (KDC) to create and manage passwords for the gMSA
Key Distribution Service (KDS) was introduced with Windows Server 2012 . KDS shares a secret (root key ID) among all the KDS instances in the domain. This value changes periodically. When a gMSA requires a password, a Windows Server domain controller generates a password based on a common algorithm that includes a root key ID. Then, all the hosts that share the gMSA will query from the domain controllers to retrieve the latest password.
In order to start the configuration process, we need to create a KDS root key. This needs to be run from the domain controller with Domain Admin or Enterprise Admin privileges:
Once this is executed, there is a default 10-hour time limit to replicate the root key to all the domain controllers and start processing gMSA requests. In a testing environment with one domain controller, you can forcibly remove this waiting time and start responding to gMSA requests immediately. This is not recommended for a production environment. We can remove the 10-hour replication time limit by using the following command:
After that, we can create the first gMSA account. I have created an AD group, IISFARM , and have added all my IIS servers to it. This farm will be using the new gMSA:
we can verify the new account using the following command:
The next step is to install Mygmsa1 on the server in the IIS farm. Mygmsa1 needs the AD PowerShell module to run. Mygmsa1 can be installed using RSAT:
Once that's executed, we can test the service account by running the following command:
