Understanding User Accounts
Applies To: Windows Server 2008, Windows Server 2008 R2, Windows Server 2012
Active Directory user accounts represent physical entities, such as people. You can also use user accounts as dedicated service accounts for some applications.
User accounts are also referred to as security principals. Security principals are directory objects that are automatically assigned security identifiers (SIDs), which can be used to access domain resources. A user account primarily:
Authenticates the identity of a user.
A user account enables a user to log on to computers and domains with an identity that the domain can authenticate. Each user who logs on to the network should have his or her own unique user account and password. To maximize security, avoid having multiple users sharing one account.
Authorizes or denies access to domain resources.
After a user is authenticated, the user is authorized or denied access to domain resources based on the explicit permissions that are assigned to that user on the resource.
User accounts
The Users container in the Active Directory Users and Computers snap-in displays the three built-in user accounts: Administrator, Guest, and HelpAssistant. These built-in user accounts are created automatically when you create the domain.
Each built-in account has a different combination of rights and permissions. The Administrator account has the most extensive rights and permissions over the domain, while the Guest account has limited rights and permissions. The following table describes each default user account on domain controllers.
| Default user account | Description | ||
|---|---|---|---|
Administrator |
The Administrator account has full control of the domain. It can assign user rights and access control permissions to domain users as necessary. Use this account only for tasks that require administrative credentials. We recommend that you set up this account with a strong password. The Administrator account is a default member of the following Active Directory groups: Administrators, Domain Admins, Enterprise Admins, Group Policy Creator Owners, and Schema Admins. The Administrator account can never be deleted or removed from the Administrators group, but it can be renamed or disabled. Because the Administrator account is known to exist on many versions of Windows, renaming or disabling this account will make it more difficult for malicious users to try to gain access to it. The Administrator account is the first account that is created when you set up a new domain with the Active Directory Domain Services Installation Wizard.
|
||
Guest |
People who do not have an actual account in the domain can use the Guest account. A user whose account is disabled (but not deleted) can also use the Guest account. The Guest account does not require a password. You can set rights and permissions for the Guest account just like any user account. By default, the Guest account is a member of the built-in Guests group and the Domain Guests global group, which allows a user to log on to a domain. The Guest account is disabled by default, and we recommend that it stay disabled. |
||
HelpAssistant (installed with a Remote Assistance session) |
The primary account for establishing a Remote Assistance session. This account is created automatically when you request a Remote Assistance session. It has limited access to the computer. The HelpAssistant account is managed by the Remote Desktop Help Session Manager service. This account is automatically deleted if no Remote Assistance requests are pending. |
.gif)
ImportantSecuring user accounts
If built-in account rights and permissions are not modified or disabled by a network administrator, they can be used by a malicious user (or service) to illegally log on to a domain using the Administrator account or Guest account. A good security practice for protecting these accounts is to rename or disable them. Because it retains its SID, a renamed user account retains all its other properties, such as its description, password, group memberships, user profile, account information, and any assigned permissions and user rights.
To obtain the security advantages of user authentication and authorization, use Active Directory Users and Computers to create an individual user account for each user who will participate in your network. You can then add each user account (including the Administrator account and Guest account) to a group to control the rights and permissions that are assigned to the account. When you have accounts and groups that are appropriate for your network, you ensure that you can identify users that log on to your network and that they have access only to the permitted resources.
You can help defend your domain from attackers by requiring strong passwords and implementing an account lockout policy. Strong passwords reduce the risk of intelligent password guessing and dictionary attacks on passwords. An account lockout policy decreases the possibility of an attacker compromising your domain through repeated logon attempts. An account lockout policy determines how many failed logon attempts a user account can have before it is disabled.
Account options
Each Active Directory user account has a number of account options that determine how someone logging on with that particular user account is authenticated on the network. You can use the options in the following table to configure password settings and security-specific information for user accounts.
| Account option | Description |
|---|---|
User must change password at next logon |
Forces a user to change his or her password the next time that the user logs on to the network. Enable this option when you want to ensure that the user will be the only person that knows the password. |
User cannot change password |
Prevents a user from changing his or her password. Enable this option when you want to maintain control over a user account, such as a Guest account or temporary account. |
Password never expires |
Prevents a user password from expiring. We recommend that service accounts have this option enabled and use strong passwords. |
Store passwords using reversible encryption |
Allows a user to log on to a Windows network from Apple computers. If a user is not logging on from an Apple computer, do not enable this option. |
Account is disabled |
Prevents a user from logging on with the selected account. Many administrators use disabled accounts as templates for common user accounts. |
Smart card is required for interactive logon |
Requires that a user possess a smart card to log on to the network interactively. The user must also have a smart card reader attached to their computer and a valid personal identification number (PIN) for the smart card. When this option is enabled, the password for the user account is automatically set to a random and complex value. |
Account is trusted for delegation |
Allows a service running under this account to perform operations on behalf of other user accounts on the network. A service running under a user account (otherwise known as a service account) that is trusted for delegation can impersonate a client to gain access to resources on the computer where the service is running or to resources on other computers. In a forest that is set to the Windows Server 2008 R2 functional level or above, this option is on the Delegation tab. It is available only for accounts that have been assigned service principal names (SPNs), as set with the setspn command. (Open a command window, and then type setspn .) This is a security-sensitive capability; assign it cautiously. This option is available only on domain controllers running Windows Server 2008 R2 or above where the domain functionality is set to Windows® 2000 mixed or Windows 2000 native. On domain controllers running Windows Server 2008 or above where the domain functional level is set to Windows Server 2008 or above forest functional Level, use the Delegation tab in the user properties dialog box to configure delegation settings. The Delegation tab appears only for accounts that have an assigned SPN. |
Account is sensitive and cannot be delegated |
You can use this option if the account, for example a Guest or temporary account, cannot be assigned for delegation by another account. |
Use DES encryption types for this account |
Provides support for the Data Encryption Standard (DES). DES supports multiple levels of encryption, including Microsoft Point-to-Point Encryption (MPPE) Standard (40-bit), MPPE Standard (56-bit), MPPE Strong (128-bit), Internet Protocol security (IPsec) DES (40-bit), IPsec 56-bit DES, and IPsec Triple DES (3DES |
Do not require Kerberos preauthentication |
Provides support for alternative implementations of the Kerberos protocol. However, use caution when you enable this option, because Kerberos preauthentication provides additional security and requires time synchronization between the client and the server. |
InetOrgPerson accounts
Active Directory Domain Services (AD DS) provides support for the InetOrgPerson object class and its associated attributes as defined in Request for Comments (RFC) 2798. The InetOrgPerson object class is used in several non-Microsoft, Lightweight Directory Access Protocol (LDAP) and X.500 directory services to represent people in an organization.
Support for InetOrgPerson makes migration from other LDAP directories to AD DS more efficient. The InetOrgPerson object is derived from the user class. It can function as a security principal just like the user class. For information about creating an inetOrgPerson user account, see Create a New User Account.
When the domain functional level is set to Windows Server 2008 or above, you can set the userPassword attribute on InetOrgPerson and user objects as being the effective password, just as you can with the unicodePwd attribute.