Creating and managing AD users groups and computers_Windows Server 2019 Automation with PowerShell Cookbook-QQ阅读男生历史网

上QQ阅读APP看书，第一时间看更新

Creating and managing AD users, groups, and computers

Once you have created your forest/domain and your domain controllers, you can begin to manage the core objects in AD, namely, users, groups, and computers and organizational units (OUs).

User and computer accounts identify a specific user or computer. These objects are used to enable the computer and the user to log on securely. Groups enable you to collect users into a single (group) account that simplifies the setting up of access controls on resources such as files or file shares. OUs enable you to partition users, computers, and groups into separate containers.

OUs serve two important roles in your AD. The first is role delegation. You can delegate the management of any OU (and child OUs) to be carried out by different groups. For example, you could create a top-level OU called UK in the Reskit.Org domain. You could then delegate permissions to the objects in this OU to a group, such as UKAdmins, enabling a member of that group to manage AD objects in and below the UK OU. Another OU, for example NA, could be delegated to a separate group, such as the North America Admins group (for example, NAAdmins). This enables you to delegate management.

The second role played by OUs is to act as a target for group policy objects. You could create a group policy object for the IT team and apply it to the IT OU. You could create a separate OU and create GPOs that apply to only the computer and user objects in that OU. Thus, each user and computer in a given OU are configured based on the GPO.

In this recipe, you create, update, and remove AD user objects as well as creating an OU and a security group, which you also populate. This recipe only creates and manages the AD objects. You assign a group policy in a later recipe, Creating a group policy object.

This recipe creates objects that are used in other recipes in this book.

Getting ready

This recipe assumes you have the Reskit.Org domain created, as performed in the Install Active Directory with DNS recipe, and you have two working domain controllers (DC1 and DC2).

Run this recipe to create and manage OUs, users, computers, and groups on DC1. Once you have created the various objects in this recipe on one DC, AD replication replicates those updates to the other DC, DC2.

How to do it...

Create a hash table for general user attributes:

$PW = 'Pa$$w0rd'
$PSS = ConvertTo-SecureString -String $PW -AsPlainText -Force
$NewUserHT = @{}
$NewUserHT.AccountPassword       = $PSS
$NewUserHT.Enabled               = $true
$NewUserHT.PasswordNeverExpires  = $true
$NewUserHT.ChangePasswordAtLogon = $false

Create two new users, utilizing the hash table created in the previous step:

# Create the first user ThomasL
$NewUserHT.SamAccountName    = 'ThomasL'
$NewUserHT.UserPrincipalName = 'thomasL@reskit.org'
$NewUserHT.Name              = 'ThomasL'
$NewUserHT.DisplayName       = 'Thomas Lee (IT)'
New-ADUser @NewUserHT

# Create a second user RLT
$NewUserHT.SamAccountName    = 'RLT'
$NewUserHT.UserPrincipalName = 'rlt@reskit.org'
$NewUserHT.Name              = 'Rebecca Tanner'
$NewUserHT.DisplayName       = 'Rebecca Tanner (IT)'
New-ADUser @NewUserHT

Create an OU and move users into it:

$OUHT = @{
    Name        = 'IT'
    DisplayName = 'Reskit IT Team'
    Path        = 'DC=Reskit,DC=Org'
}
New-ADOrganizationalUnit @OUHT    # create the eOUI
$MHT1 = @{
    Identity   = 'CN=ThomasL,CN=Users,DC=Reskit,DC=ORG'
    TargetPath = 'OU=IT,DC=Reskit,DC=Org'
}
Move-ADObject @MHT1               # move ThomasL into OU
$MHT2 = @{
    Identity = 'CN=Rebecca Tanner,CN=Users,DC=Reskit,DC=ORG'
    TargetPath = 'OU=IT,DC=Reskit,DC=Org'
}
Move-ADObject @MHT2             # Move Rebecca into OU

Create a third user directly in the IT OU:

$NewUserHT.SamAccountName    = 'JerryG'
$NewUserHT.UserPrincipalName = 'jerryg@reskit.org'
$NewUserHT.Description       = 'Virtualization Team'
$NewUserHT.Name              = 'Jerry Garcia'
$NewUserHT.DisplayName       = 'Jerry Garcia (IT)'
$NewUserHT.Path              = 'OU=IT,DC=Reskit,DC=Org'
New-ADUser @NewUserHT

Add two users who then are to be removed:

#   First user to be removed
$NewUserHT.SamAccountName    = 'TBR1'
$NewUserHT.UserPrincipalName = 'tbr@reskit.org'
$NewUserHT.Name              = 'TBR1'
$NewUserHT.DisplayName       = 'User to be removed'
$NewUserHT.Path              = 'OU=IT,DC=Reskit,DC=Org'
New-ADUser @NewUserHT

#   Second user to be removed
$NewUserHT.SamAccountName     = 'TBR2'
$NewUserHT.UserPrincipalName  = 'tbr2@reskit.org'
$NewUserHT.Name               = 'TBR2'
New-ADUser @NewUserHT

View the users that exist so far:

Get-ADUser -Filter * -Property *| 
  Format-Table -Property Name, Displayname, SamAccountName

Remove via a Get | Remove pattern:

Get-ADUser -Identity 'CN=TBR1,OU=IT,DC=Reskit,DC=Org' |
  Remove-ADUser -Confirm:$false

Remove directly from the distinguished name:

$RUHT = @{
  Identity = 'CN=TBR2,OU=IT,DC=Reskit,DC=Org'
  Confirm  = $false
}
Remove-ADUser @RUHT

Update then display the user details:

$TLHT =@{
  Identity     = 'ThomasL'
  OfficePhone  = '4416835420'
  Office       = 'Cookham HQ'
  EmailAddress = 'ThomasL@Reskit.Org'
  GivenName    = 'Thomas'
  Surname      = 'Lee' 
  HomePage     = 'Https://tfl09.blogspot.com'
}
Set-ADUser @TLHT
Get-ADUser -Identity ThomasL -Properties * |
  Format-Table -Property DisplayName,Name,Office,
                         OfficePhone,EmailAddress

Create a new group:

$NGHT = @{
  Name        = 'IT Team'
  Path        = 'OU=IT,DC=Reskit,DC=org'
  Description = 'All members of the IT Team'
  GroupScope  = 'DomainLocal'
}
New-ADGroup @NGHT

Move all the users in the IT OU into this group:

$SB = 'OU=IT,DC=Reskit,DC=Org'
$ItUsers = Get-ADUser -Filter * -SearchBase $SB
Add-ADGroupMember -Identity 'IT Team' -Members $ItUsers

Display the members:

Get-ADGroupMember -Identity 'IT Team' |
  Format-Table SamAccountName, DistinguishedName

Add a computer to the AD:

$NCHT = @{
  Name                   = 'Wolf' 
  DNSHostName            = 'Wolf.Reskit.Org'
  Description            = 'One for Jerry'
  Path                   = 'OU=IT,DC=Reskit,DC=Org'
  OperatingSystemVersion = 'Windows Server 2019 Data Center'
}
New-ADComputer @NCHT

View the computers in the Reskit.Org domain:

Get-ADComputer -Filter * -Properties * | 
  Format-Table Name, DNSHost*,LastLogonDate

How it works...

In step 1, you create a hash table of user properties to be set for the new user. You use this hash table in step 2 to create two users. In step 3, you create a new OU and move users into the new OU. In step 4, you add a third user directly into the OU. In step 5, you add two further users to the AD. These steps produce no output.

In step 6, you retrieve and display all the users in the Reskit.Org AD, like this:

In step 7 and step 8, you remove two users using different removal patterns. The first user is removed via a Get | Remove pattern in which you get an object with a Get-ADUser cmdlet and then pipe it to the Remove-ADUser cmdlet. The second is the direct use of Remove-ADUser. Neither step produces any output.

In step 9, you update a user then display the updated user, which looks like this:

In step 10, you create a new domain local security group, IT Team, and in step 11, you populate the group membership with the users in the IT OU. Neither of these steps produces output.

In step 12, you display the users in the IT Team group, which looks like this:

In step 13, you pre-stage a computer account for a new host (Wolf.Reskit.Org), which produces no output. In step 14, you display all the computer accounts in the Reskit.Org domain, which looks like this:

There's more...

In this recipe, we use two different approaches to creating a user. In the first, you use New-ADUser to create a new user which, by default, AD places in the User container in the domain. Since AD containers are not subject to a group policy, you need to move the created user objects into the appropriate OU in order to enable group policy and management delegation.

The second method used in this recipe to create a user involves using the PATH parameter to create the new user directly in an OU. When you create a new user, placing the user into the correct OU is better than leaving it in the Users container, especially if you want to apply GPOs to apply GPOs to the user.

The same logic applies to computer objects. By default, new computer objects are placed in the Computer container. As with users, objects in the Computer container are not subject to GPOs.

If you install Windows 2019 on a computer and promote it to be a domain controller, the domain installation process moves the computer account into the Domain Controllers OU. Computers in this OU are subject to a default GPO, the Default Domain Controllers policy.

You are also, in due course, likely to need to move users or computers between OUs. For example, the user Rebecca, created in step 2, might have initially been in the IT organization, but due to a job change, she moves to a new organization. To support that job move, you move her user and computer accounts to a different OU and change her group membership. After she reboots her computer and logs in, she acquires permissions needed for her new job and her user/computer accounts are then subject to any relevant GPOs.

In step 7 and step 8, you use two different methods for removing an object from the Active Directory (in this case, an AD user object). The first method is useful from the command line, where you first find the object(s) (using Get-ADUser) to be deleted, then pipe the results into Remove-ADUser.

The second way to remove an object is to use Remove-ADObject (or Remove-ADUser or Remove-ADComputer). Assuming you have the full distinguished name for the object to be removed, this is a bit faster. One risk of this approach is that you could accidentally type an incorrect DN into the command, resulting in the wrong user/computer being removed. To minimize this risk, consider configuring the AD recycle bin.

Joining a computer to the domain involves two specific steps: creating an account for the computer in the AD, then configuring the computer to be a member of the domain. If you build a new computer, you can log on as an administrator and join the computer to the domain, which achieves both of these steps. Alternatively, you could pre-stage a computer account (the first of the two necessary steps) then complete the domain-join process later.

In step 13, you pre-stage a computer account. This involves creating the AD account for a computer but without it actually joining the domain. This needs to be done using an account that has the necessary permissions. By default, this means a member of either the domain admins or the enterprise admins groups. After the computer account is created, you can complete the process of joining the computer to the domain (for example, by using the Add-Computer cmdlet). By pre-staging the account, a less privileged user can do the final step without the need for privileged domain credentials.