Active Directory user accounts represent physical entities, such as people. You can also use them 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 Active Directory Administrative Center contains 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. The Guest account has limited rights and permissions. The following table describes each default user account on domain controllers running Windows Server 2008 R2.

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.

Important

When the Administrator account is disabled, it can still be used to gain access to a domain controller in Safe Mode.

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 HelpAssistant account is the primary account for establishing a Remote Assistance session. This account is created automatically when a Remote Assistance session is requested. It has limited access to the computer. The Remote Desktop Help Session Manager service manages the HelpAssistant account. This account is deleted automatically if no Remote Assistance requests are pending.

Securing user accounts

If a network administrator does not modify the rights and permissions of built-in accounts, a malicious user (or service) can use them to illegally log on to a domain by 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 the Active Directory Administrative Center 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.

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. An InetOrgPerson object is derived from the user class. It can function as a security principal, just like an object from 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 Windows Server 2008 R2, you can set the userPassword attribute on InetOrgPerson and user objects as being the effective password, just as you can with the unicodePwd attribute.

Additional references


Table Of Contents