Chapter 2. Managing User and Service Accounts
In this chapter you’ll learn how to manage domain user and service accounts. Although local system accounts are discussed, they are not the primary focus. Also, current Windows operating systems add a special type of account called a Microsoft account. You can think of Microsoft accounts as synchronized accounts. When you connect a local or domain account to a Microsoft account, the account becomes a connected local or connected domain account.
As a member of the Administrators, Account Operators, Enterprise Admins, or Domain Admins group, you can use Active Directory Users And Computers or Active Directory Administrative Center to create user accounts. The process is similar regardless of which tool you use.
Follow these steps to create a user account in Active Directory Users And Computers:
23. By default, you are connected to your logon domain. If you want to create accounts in a different domain, right-click the Active Directory Users And Computers node in the console tree, and then select Change Domain. In the Change Domain dialog box, type the name of the domain to which you want to connect, and then click OK. Alternatively, you can click Browse to find the domain to which you want to connect in the Browse For Domain dialog box.
24. You can now create the user account. Right-click the container in which you want to create the user, point to New, and then select User. This will start the New Object–User Wizard.
NOTE Generally, you shouldn’t create user accounts with the domain node selected in the console tree. Instead, select Users or an appropriate organizational unit and then create the user account in this container.
25. When you create a new user, you’re prompted for the first name, initials, last name, full name, and logon name. The pre–Windows 2000 logon name then appears automatically. This logon name is used with early releases of Windows.
NOTE The user’s full name and both logon names must be unique in the domain. You’ll see an error about logon names immediately, but won’t see an error about full name conflicts until the end of the creation process.
26. When you click Next, you can set the user’s password and account options. The password must meet the complexity requirements set in Group Policy. The options are as follows: User Must Change Password At Next Logon, User Cannot Change Password, Password Never Expires, Account Is Disabled.
27. Click Next, and then click Finish. If you see an error and you’ll have to click Back and make changes before you can continue.
With Windows PowerShell, you can create user accounts with the New-ADUser cmdlet and set account properties using the Set-ADUser, Set-ADAccountPassword, Set-ADAccountControl, and Enable-ADAccount cmdlets. With New-ADUser, use –DisplayName to set the display name, –GivenName to set the first name, –Initials to set the middle initial, –Surname to set the last name, and –Name to set the full name. You also need to specify the user principal name (UPN), whether the account should be enabled, and the account password. You can do this using the –UserPrincipalName, –Enabled, and –AccountPassword parameters, respectively. Here is an example:
New-ADUser –DisplayName "William R. Stanek" –GivenName "William"
–Initials "R" –Name "William R. Stanek" –SamAccountName "WilliamSt"
-Enabled $true -AccountPassword (ConvertTo-SecureString "ChangePasswordNow!"
–AsPlainText -force) -PassThru
To bulk create user accounts, you can import the account details from a text file containing a list of column headings on the first line, followed by the details of each account you want to create on separate lines, as shown in this example:
DisplayName,GivenName,FullName,SamName
Peter Brehm,Peter,PeterBrehm,peterb
Oliver Kiel,Oliver,Oliver Kiel,oliverk
If you saved this file with the name newusers.csv in the c:\scripts\data folder, you could then use the following script to bulk create accounts:
$NewUsers = import-csv c:\scripts\data\newusers.csv
ForEach ($User in $NewUsers) { New-ADUser –DisplayName $User.FullName
–GivenName $User.GivenName –Name $User.FullName –SamAccountName
$User.SamName–Enabled $true –ChangePasswordAtLogon $true -AccountPassword
(ConvertTo-SecureString "ChangePasswordNow!" -AsPlainText -force) -PassThru }
Or you could use the file to create the accounts directly from the prompt by entering the following command all on one line:
import-csv c:\scripts\data\newusers.csv | ForEach { New-ADUser
–DisplayName $_.FullName –GivenName $_.GivenName –Name $_.FullName
–SamAccountName $_.SamName –Enabled $true –ChangePasswordAtLogon $true
–AccountPassword (ConvertTo-SecureString "ChangePasswordNow!"
-AsPlainText -force) -PassThru }
Every user account created in Active Directory has account options that control logon hours, the computers to which a user can log on, account expiration, and so on.
To manage these settings for a user, double-click the user account in Active Directory Users And Computers or Active Directory Administrative Center. Next, click the Account tab or Account panel as appropriate.
Below the general account name fields, the available options are divided into three main areas. The first area that you can configure controls two computer options: Logon Hours and Log On To.
NOTE Earlier releases of Windows required the NetBIOS protocol to restrict which computers a user can log on from. This requirement has been phased out.
Below the Logon Hours and Log On To buttons is the Unlock Account check box. If the user has become locked out by trying to log on with the wrong password too many times, you can unlock the account by clearing this check box.
Finally, you use the Account Expires panel to set expiration options for the account. The default is Never, but you might need to configure this setting for some users. For example, temporary workers, contract workers, summer help, or consultants might be working on your network for only a specified amount of time. If you know how long they need access to resources in your domain, you can use the Account Expires settings to automate the disabling of their account.
SECURITY In most network environments, administrators to whom the task of managing users has been delegated will not be able to remove users immediately upon their leaving the organization, which creates a window of vulnerability. Yet when accounts have scheduled end points, you can schedule them to be disabled on a specific date. So it’s a good idea to schedule accounts to be disabled if you are sure that the user will no longer be working. If the account is automatically disabled but the user needs access, the user will let you know. But if the account is not disabled automatically, it can represent a big security problem. To handle this on an enterprise level, many businesses are reviewing (or implementing) provisioning applications to automate the process of taking away access to company resources when employees leave the company.
User accounts also can have profiles, logon scripts, and home directories associated with them. To configure these options, double-click a user account in Active Directory Users And Computers or Active Directory Administrative Center. Next, click the Profile tab or the Profile panel as appropriate.
You can set the following options in the Profile tab:
NOTE You shouldn’t use scripts to set environment variables. Environment settings used by scripts aren’t maintained for subsequent user processes.
To specify a home folder, do either of the following:
Specify a local home folder by clicking the Local Path option button and then typing the path to the home folder on the user’s computer. Here’s an example: C:\Home\%UserName%.
Specify a network home folder by selecting the Connect option button in the Home Folder section and then by selecting a drive letter for the home folder. For consistency, you should use the same drive letter for all users. Also, be sure to select a drive letter that won’t conflict with any currently configured physical or mapped drives. To avoid problems, you might want to use Z as the drive letter. After you select the drive letter, type the complete path to the home folder, using the Universal Naming Convention (UNC) notation, such as: \\FileServer14\Home\%UserName%.
NOTE %UserName% refers to the UserName environment variable. The Windows operating system has many environment variables, which are used to refer to user-specific and system-specific values. In this case, %UserName% is used to dynamically assign the user name as appropriate for the applicable user account. Keep in mind that when a user's account and username are changed, it can create a problem that prevents access to her home folder. To resolve this problem, you simply need to rename the folder and the good news is that the folder permissions will not need to be changed.
In Active Directory, user accounts are defined as objects—as are group and computer accounts. This means that user accounts have security descriptors that list the users and groups that are granted access. Security descriptors also define ownership of the object and specify the permissions that those users and groups have been assigned with respect to the object.
Individual entries in the security descriptor are referred to as access control entries (ACEs). Active Directory objects can inherit ACEs from their parent objects. This means that permissions for a parent object can be applied to a child object. For example, all members of the Account Operators group inherit permissions granted to this group.
Because of inheritance, sometimes it isn’t clear whether a particular user, group, or computer has permission to work with another object in Active Directory. This is where the Effective Access tool comes in handy. You use this tool to examine the permissions that a user, group, or computer has with respect to another object. For example, if you want to determine what permissions, if any, a user who has received delegated control has over another user or group, you can use Effective Access to do that.
IMPORTANT The Effective Access tool is available in Active Directory Users And Computers—but only if you are in the Advanced Features view. Choose Advanced Features from the View menu if necessary.
In Active Directory Users And Computers or Active Directory Administrative Center, double-click the user, group, or computer for which you are trying to determine the effective permissions of another user or group. If you are working with Active Directory Administrative Center, open the Extensions panel.
Next, click the Advanced button in the Security tab to open the Advanced Security Settings dialog box. Click the Effective Access tab. Next, click Select A User, type the name of the user or group for which you want to see the effective permissions with regard to the previously selected object, and then click OK.
When you click View Effective Access, the effective permissions for the selected user or group in relation to the previously selected object appear. The Effective Access column has check marks showing which permissions are in effect. If there are no effective permissions, none of the permissions’ check boxes are selected.
When a user logs on to the network using his or her domain user account, a domain controller validates the account credentials. By default, users can log on using their domain user accounts even if the network connection is down or no domain controller is available to authenticate the user’s logon. However, the user must have previously logged on to the computer and have valid, cached credentials. If the user has no cached credentials on the computer and the network connection is down or no domain controller is available, the user will not be able to log on to the domain.
Authentication also can fail if the system time on the member computer deviates from the logon domain controller’s system time more than is allowed in the Kerberos Policy: Maximum Tolerance For Computer Clock Synchronization setting. The default tolerance is five minutes for member computers.
Users’ accounts can be disabled by administrators or locked out due to Account Lockout Policy. When a user tries to log on using an account that is disabled or locked out, the user sees a prompt that says that the user can’t log on because that user’s account is disabled or locked out. The prompt also tells the user to contact an administrator.
Active Directory Users And Computers shows disabled accounts with a warning icon next to the account name. To enable a disabled account, right-click the account in Active Directory Users And Computers and then select Enable Account.
You can search the entire domain for users with disabled accounts by typing Search-ADAccount -AccountDisabled at a PowerShell prompt. To enable a disabled account from the prompt, type Enable-ADAccount AccountName.
TIP Search-ADAccount returns results for all matches, whether they are user or computer accounts. Use -UsersOnly or -ComputersOnly if you want results for a specific account type.
When a user account has been locked out by the Account Lockout Policy, the account can’t be used for logging on until the lockout duration has elapsed or an administrator resets the account. If the account lockout duration is indefinite, the only way to unlock the account is to have an administrator reset it.
In Active Directory Users And Computers, you can unlock an account by right-clicking the locked account and then selecting Properties. In the Account tab of the Properties dialog box, select the Unlock Account check box and then click OK.
You can search the entire domain for users with locked accounts by typing Search-ADAccount –LockedOut at a PowerShell prompt. To enable a locked account from the prompt, type Unlock-ADAccount AccountName.
REAL WORLD When account logon failure auditing is enabled, logon failure is recorded in the security log on the logon domain controller. Auditing policies for a site, domain, or OU GPO are stored in Windows Settings\Security Settings\Local Policies\Audit Policy under the Computer Configuration node.
You also can use Search-ADAccount with -AccountExpired to search for expired accounts or with -PasswordNeverExpires to search for accounts with passwords that never expire. Here are examples:
Search-ADAccount -AccountExpired
Search-ADAccount -PasswordNeverExpires
Application servers and database servers often use service accounts. On a local computer you can configure the application to run as a built-in user account, such as Local Service, Network Service, or Local System. Although these service accounts are easy to configure and use, they usually are shared among multiple applications and services and can’t be managed on a domain level. If you configure the application to use a domain account, you can isolate the privileges for the application. However, you must then manually manage the account password and any Service Principal Names (SPNs) required for Kerberos authentication.
Windows supports both managed service accounts and managed virtual accounts. Managed service accounts are a special type of domain user account for managed services. These accounts reduce service outages and other issues by having Windows manage the account password and related SPNs automatically.
Managed virtual accounts are a special type of local computer account for managed services. These accounts provide the ability to access the network with a computer identity in a domain environment. Because the computer identity is used, no password management is required.
Because Windows Server doesn’t provide a graphical interface for managing either service accounts or virtual accounts, you must manage these accounts using the Active Directory module for Windows PowerShell. Windows operating systems also support group managed service accounts.
Group managed service accounts provide the same functionality as standard managed service accounts but extend that functionality over multiple servers. For example, when a client computer connects to a service hosted by a server farm, mutual authentication can’t succeed unless all the instances of the services use the same principal. By using a group managed service account, you allow each server in the farm to use the same service principal, which is managed by Windows itself rather than individually by the administrator.
Currently, group managed service accounts are the default type of service account. Thus, by default, managed service accounts span multiple computers.
You can add the account to more than one computer at a time as necessary to support clustered nodes, network load-balancing server farms, and so on. To restrict a managed service account to a single computer, set the –RestrictToSingleComputer option when creating the account. Don’t forget that a single computer can have multiple managed service accounts as well.
In Active Directory schema, managed service accounts are represented by msDS-ManagedServiceAccounts. This object class inherits its attributes from the Computer object class, but the objects also are users. Managed service accounts use the same password-update mechanism as regular computer accounts. Thus, the password for the account is updated whenever the computer updates its password, which by default occurs every 30 days. Managed service accounts can automatically maintain their Kerberos SPN and support delegation.
NOTE By default, all managed service accounts are created in the Managed Service Accounts container in Active Directory. This container is visible in Active Directory Users And Computers when you display advanced features. Additionally, it’s important to note that some applications, such as SQL Server and IIS, make extensive use of Kerberos and know how to register themselves with SPNs. If an application supports writing its own SPNs, managed service accounts will work for automatic SPN management.
Like standard computer accounts, managed service accounts do not use either domain or fine-grained password policies. Instead, they use a randomly generated 240-byte (120-character) password. Managed service accounts can’t perform interactive logons or be locked out like user accounts can be. You can add managed service accounts to groups using Active Directory Users And Computers or Add-ADGroupMember.
With group managed service accounts (gMSAs), you perform a series of preparatory steps and then create the actual account, which is stored by default in the Managed Service Accounts container in Active Directory. Next, you associate the account with a computer in Active Directory and then install the group managed service account on a local server to add it to the account as a local user. Finally, you configure the local service to use the account. Specifically, you must do the following:
28. Create a global security group in Active Directory and add the computers that will use the gMSA as members.
29. Create a KMS root key to generate passwords for the group managed service account.
30. Create the group managed service account.
31. Install the group managed service account on the computer that was associated.
32. Configure the local service to use the account.
Creating a hosting group allows you to more easily manage permissions for the member servers that will be using the group managed service account. Follow these steps to create the group:
33. Start Active Directory Administrative Center or Active Directory Users and Computers.
34. Right-click the container in which you want to create the group, point to New, and then select Group. This will start the New Object–Group Wizard.
35. Type a name for the group, such as SQLServers, and then click OK. This creates a global security group.
36. Double-click the group you just created to open the related Properties dialog box.
37. You next need to make the servers that will use the gMSA members of the group. After selecting the Members tab or option, click Add. Type the name of a computer in the field provided, and then click Check Names. If the correct computer name is selected, click OK. Otherwise, make changes and check the name again. Repeat this process until all the servers that should use the gMSA have been added to the group.
38. Click OK to close the Properties dialog box for the group.
39. Restart the member servers so that the new group membership is reflected in their security token.
Windows PowerShell needs a KMS root key to generate the passwords required by the group managed service account. Add this key by entering the following command:
Add-KdsRootKey -EffectiveTime ((Get-Date).addhours(-2))
Here, you create a KMS root key that is valid for the next 2 hours.
You use Windows PowerShell cmdlets to install, uninstall, and reset passwords for managed service accounts. After a managed service account has been installed, you can configure a service or application to use the account and no longer have to specify or change passwords because the computer maintains the account password. You can also configure the SPN on the service account without requiring domain administrator privileges.
To create a managed service account , you use New-ADServiceAccount. The basic syntax is as follows:
New-ADServiceAccount–Name Name –DNSHostName DNSName
-PrincipalsAllowedToDelegateToAccount HostingGroup
–PrincipalsAllowedToRetrieveManagedPassword HostingGroup
-ServicePrincipalNames ServicePrincipal
[-RestrictToSingleComputer]
Name sets the account name, DNSName sets the DNS name for the hosting group, HostingGroup is the name of the hosting group, and ServicePrincipal is the name of the service principal for the account, such as:
New-ADServiceAccount –Name "SQLServ-gMSA"
-DNSHostName sqlservers.tvpress.local
–PrincipalsAllowedToDelegateToAccount "SQLServers"
–PrincipalsAllowedToRetrieveManagedPassword "SQLServers"
–ServicePrincipalNames "sqlservice\tvpress.local:1456"
By default, the account is created as a group service account. The account will have a randomly generated 240-byte (120-character) password and is created in the Managed Service Accounts container. The account is enabled by default as well, but you can create the account in a disabled state by adding –Enabled $false. If you need to pass in credentials to create the account, use the –Credential parameter as shown in this example:
$cred = Get-Credential
New-ADServiceAccount –Name "IIS Updates Pool"
-DNSHostName iisupdates.tvpress.local
–PrincipalsAllowedToDelegateToAccount "IIS Servers"
–PrincipalsAllowedToRetrieveManagedPassword "IIS Servers"
–Credential $cred
Group managed service accounts are listed in Active Directory Users And Computers. However, you shouldn’t use this management tool to work with the account. Instead, you should work with group managed service accounts using Get-ADServiceAccount, Set-ADServiceAccount, and Remove-ADServiceAccount. Get-ADServiceAccount retrieves information about one or more managed service accounts. Set-ADServiceAccount configures properties on an existing managed service account. Remove-ADServiceAccount deletes a managed service account from Active Directory.
You can install the account on a local computer by using Install-ADServiceAccount. The basic syntax is this:
Install-ADServiceAccount [-Identity] ServiceAccountId
ServiceAccountId is the display name or SAM account name of the service account, such as:
Install-ADServiceAccount sqlagent
If you need to pass in credentials to create the account, use the –Credential parameter. Use Uninstall-ADServiceAccount to uninstall an account.
You can configure a service to run with the managed service account by following these steps:
40. In Server Manager, click Tools and then click Computer Management. As necessary, connect to the computer you want to manage. In the left pane, right-click the Computer Management node and then click Connect To Another Computer. Enter the host name, fully qualified domain name, or IP address of the remote server, and then click OK.
41. In the left pane, expand the Services And Applications node and then select the Services node. Right-click the name of the service you want to work with, and then click Properties.
42. In the Log On tab, select This Account and then type the name of the managed service account in the format DomainName\AccountName, or click Browse to search for the account.
43. Confirm that the password boxes are blank and then click OK.
44. Select the name of the service and then click Start to start the service, or click Restart to restart the service as appropriate. Confirm that the newly configured account name appears in the Log On As column for the service.
NOTE In the Services snap-in console, you’ll see a dollar sign ($) at the end of the account name. When you use the Services snap-in console to configure the logon as an account, the Service Logon Right logon right is automatically assigned to the account. If you use a different tool, the account has to be explicitly granted this right.
If a managed service account is no longer being used on a computer, you might want to uninstall the account. Before you do this, however, you should check the Services snap-in to ensure that the account isn’t being used. To uninstall a managed service account from a local computer, use Uninstall-ADServiceAccount. The basic syntax is shown here:
Uninstall-ADServiceAccount -Identity ServiceAccountId
ServiceAccountId is the display name or SAM account name of the service account, such as:
Uninstall-ADServiceAccount -Identity sqlagent
If you need to pass in credentials to uninstall the account, use the –Credential parameter.
Managed service account passwords are reset on a regular basis based on the password reset requirements of the domain, but you can reset the password manually if needed. To reset the password for a managed service account, use Reset-ADServiceAccountPassword. The basic syntax is as follows:
Reset-ADServiceAccountPassword -Identity ServiceAccountId
ServiceAccountId is the display name or SAM account name of the service account, such as:
Reset-ADServiceAccountPassword -Identity sqlagent
If you need to pass in credentials to reset the password, use the –Credential parameter. You can modify the default password change interval for managed service accounts by using the domain policy Domain Member: Maximum Machine Account Password Age under Local Policy\Security Options. Group Policy settings under Account Policies\Password Policy are not used to modify managed service account password-reset intervals, nor can the NLTEST /SC_CHANGE_PWD command be used to reset managed service account passwords.
To move a managed service account from a source computer to a new destination computer, complete the following steps:
45. On the source computer, configure any services that are using the managed account to use a different account and then run Uninstall-ADServiceAccount.
46. On the new destination computer, run Install-ADServiceAccount and then use the Services snap-in console to configure the service to run with the managed service account.
To migrate a service from a user account to a managed service account, complete the following steps:
47. Create a new managed service account in Active Directory by using New-ADServiceAccount.
48. Install the managed service account on the appropriate computer by using Install-ADServiceAccount, and then use the Services snap-in console to configure the service to run with the managed service account.
49. You also might need to configure the access control lists on the service resources for the service management account.
Virtual accounts require very little management. They can’t be created or deleted, and they don’t require any password management. Instead, they exist automatically and are represented by the machine identity of the local computer.
With virtual accounts, you configure a local service to access the network with a computer identity in a domain environment. Because the computer identity is used, no account needs to be created and no password management is required.
You can configure a service to run with a virtual account by following these steps:
50. In Server Manager, click Tools and then click Computer Management. As necessary, connect to the computer you want to manage. In the left pane, right-click the Computer Management node and then click Connect To Another Computer. Enter the host name, fully qualified domain name, or IP address of the remote server, and then click OK.
51. In the left pane, expand the Services And Applications node and then select the Services node. Right-click the name of the service you want to work with and then click Properties.
52. On the General tab, double-click the service name and then press Ctrl+C. This selects and then copies the service name.
53. In the Log On tab, select This Account and then type NT SERVICE\. Next, press Ctrl+V to paste in the service name. The result should be the name of the service account in the format NT SERVICE\ServiceName.
54. Confirm that the password boxes are blank and then click OK.
55. Select the name of the service and then click Start to start the service, or click Restart to restart the service. Confirm that the newly configured account name appears in the Log On As column for the service.
NOTE In the Services snap-in console, you’ll see a dollar sign ($) at the end of the account name. When you use the Services snap-in console to configure the logon as an account, the Service Logon Right logon right is automatically assigned to the account. If you use a different tool, the account has to be explicitly granted this right.
User accounts are easy to maintain after they’ve been configured. Most of the maintenance tasks you need to perform involve user profiles and group membership, which are covered in “Configuring Profile Options” earlier in this chapter and in “Working with Groups” in Chapter 3. Other than these areas, you might also need to perform the following tasks:
Each of these tasks is examined in the sections that follow.
One of the good things about using domain policy to require users to change their passwords is that the overall security of the network is improved. One of the downsides of frequent password changes is that users occasionally forget their passwords. If this happens, it’s easy to fix it by doing the following:
56. Find the user account whose password you want to reset in Active Directory Users And Computers or in Active Directory Administrative Center.
57. Right-click the user account, and then select Reset Password.
58. In the Reset Password dialog box, type the new password and then confirm it for the user by typing it again.
NOTE The new password takes effect the next time the user logs on. Typically, you’ll assign a generic secure password to the user that is meant to be temporary, and this is why the User Must Change Password At Next Logon option is selected by default.
59. If the account status is listed as locked, select the Unlock The User’s Account check box.
60. Click OK.
If you need to deactivate a user account temporarily so that it can’t be used for logon or authentication, you can do this by disabling the account. Although disabling an account makes it unusable, you can later enable the account so that it can be used again. To disable an account in Active Directory Users And Computers, right-click the account and then select Disable Account. To disable an account in Active Directory Administrative Center, right-click the account and then select Disable.
Next, when you are notified by a prompt that the account has been disabled, click OK. A circle with a down arrow is added to the account’s icon to show that it is disabled. If you later need to enable the account, you can do so by right-clicking the account and then selecting either Enable Account or Enable, depending on which management tool you are using.
Whenever users violate Group Policy—such as when they fail to change their passwords before they expire or exceed the limit for bad logon attempts—Active Directory locks their accounts. After an account is locked, the user can no longer log on. Because accounts also can be locked because someone is trying to break into an account, you shouldn’t automatically unlock accounts. Instead, either wait until the user asks you to unlock the account or go speak to the user when you notice that the user’s account has been locked.
You can unlock accounts by completing the following steps:
61. In Active Directory Users And Computers, right-click the locked account and then select Properties.
62. In the Properties dialog box, click the Account tab.
63. Select the Unlock Account check box and then click OK.
This option is not available in Active Directory Administrative Center.
Active Directory tracks objects by their SID. This allows you to safely rename user, computer, and group accounts without worrying about having to change access permissions as well. That said, however, the process of renaming a user account is not as easy as the process of renaming other types of accounts. The reason is that users have several name components that are all related to a user’s last name, including a full name, display name, and user logon name. So when a person’s last name changes as the result of a marriage, adoption, or divorce, you not only need to update the user’s account name in Active Directory, but you also need to update the rest of the related name components as well.
To simplify the process of renaming user accounts, Active Directory Users And Computers provides the Rename User dialog box, which you can use to rename a user’s account and all the related name components. Active Directory Administrative Center doesn’t have this simple renaming tool.
With the addition of the Rename User dialog box, the process for renaming user accounts is as follows:
64. Find the user account that you want to rename in Active Directory Users And Computers.
65. Right-click the user account, and then select Rename. Active Directory Users And Computers highlights the account name for editing. Press the Backspace or Delete key to erase the existing name, and then press Enter to open the Rename User dialog box.
66. Make the necessary changes to the user’s name information and then click OK. If the user is logged on, you’ll see a warning prompt telling you that the user should log off and then log back on using the new account logon name.
67. The account is renamed, and the SID for access permissions remains the same. You might still need to modify other data for the user in the account’s Properties dialog box, including the following:
User Profile Path As necessary, change the Profile Path information in the Profile tab and then rename the corresponding directory on disk.
Logon Script Name If you use individual logon scripts for each user, change the Logon Script Name value in the Profile tab and then rename the logon script on disk.
Home Folder As necessary, change the home folder path in the Profile tab and then rename the corresponding directory on disk.
When a user changes departments you might need to move the user account to a new container in Active Directory Users And Computers or Active Directory Administrative Center. To move a user account, right-click the account and then select Move. The Move dialog box appears, which you can use to select the container to which you want to move the user account. Alternatively, you can drag the user account into a new container. You can also select multiple users to move by using Windows keyboard shortcuts, such as Ctrl, and then selecting multiple users or by using Shift and selecting the first and last users.
Each user account created in the domain has a unique security identifier (SID) and that SID is never reused. If you delete an account, you can’t create an account with the same name and regain all the same permissions and settings of the previously deleted account. The SID for the new account will be different from the old one, and you will have to redefine all the necessary permissions and settings. Because of this, you should delete accounts only when you know they are not going to be used again. If you are unsure, disable the account rather than delete it.
To delete a user account, select the user account in either Active Directory Users And Computers or Active Directory Administrative Center and then press Delete. When prompted to confirm the deletion, click Yes. The user account is permanently deleted. Deleting a user account doesn’t delete a user’s on-disk data. It only deletes the user account from Active Directory. This means that the user’s profile and other personal data will still be available on disk until you manually delete them.
CAUTION! The permissions on users are internally characterized within Active Directory by unique SIDs that are allocated when the user is created. If you delete a user account and then re-create it, it will have a new SID and thus new permissions.
If a user account is protected from deletion, you’ll need to remove the protection before you can delete the user account.
To delete a protected user account, do either of the following:
Active Directory Recycle Bin allows you to undo the accidental deletion of Active Directory objects in much the same way as you can recover deleted files from the Windows Recycle Bin. Before you can use the recycle bin, you must raise the domain and forest functional levels to the Windows Server 2008 R2 level or higher and then you must enable the feature. Keep in mind that once you enable Active Directory Recycle Bin you will not be able to lower the domain or forest functional level below the Windows Server 2008 R2 level.
When an Active Directory object is deleted and the recycle bin is enabled, the object is put in a state referred to as logically deleted. The object’s distinguished name is altered and it’s moved to the Deleted Objects container, where it remains for the period of time set in the deleted object lifetime value, which is 180 days by default.
You enable the recycle bin for use by following these steps:
68. In Active Directory Administrative Center, the local domain is opened for management by default. If you want to work with a different domain, click Manage and then click Add Navigation Nodes. In the Add Navigation Nodes dialog box, select the domain you want to work with and then click OK.
69. Select the domain you want to work with by clicking it in the left pane. In the Tasks pane, click Enable Recycle Bin and then click OK in the confirmation dialog box.
IMPORTANT Enabling the recycle bin is a forestwide change. When you enable the recycle bin in one domain of a forest, Active Directory replicates the change to all domain controllers in all domains of the forest. Thus, every domain in the forest will have its own recycle bin.
After you enable the recycle bin, Active Directory will begin replicating the change to all domain controllers in the forest. Once the change is replicated, the recycle bin will be available for use. If you then click Refresh in Active Directory Administrative Center, you’ll see that a Deleted Objects container is available for each domain you select.
When Active Directory Recycle Bin is enabled, you can easily recover deleted objects. To do this, you use Active Directory Administrative Center. Domains using the recycle bin will have a Deleted Object container. In this container you’ll see a list of deleted objects.
TIP Use Tree View instead of List View to more easily access containers in Active Directory Administrative Center. Tree View and List View are options in the upper right corner of the main window.
Deleted objects remain fully recoverable in the Deleted Objects container for the deleted object lifetime value, which is 180 days by default. Each deleted object is listed by name, and you can see when it was deleted, the last known parent, and the type. When you select a deleted object by clicking it, you can use the options in the Tasks pane to work with it. The Restore option restores the object to its original container. For example, if the object was deleted from the Users container, it’s restored to this container.
NOTE As discussed in the section entitled “Understanding the Extensible Storage Engine” in Chapter 4, when the deleted object lifetime expires, objects are tombstoned by the storage engine. Tombstoned objects are partially recoverable during the tombstone lifetime, which is 180 days by default.
The Restore To option restores the object to an alternate container within its original domain or to a different domain within the current forest. Specify the alternate container in the Restore To dialog box. For example, if the object was deleted from the Users container in the eng.imaginedlands.com domain, you could restore it to the Technology OU in the tech.imaginedlands.com domain.