What are the three user account types?

You will need to create accounts to differentiate each of your users on the network and to grant the appropriate permissions so those users can access the resources they need to perform their jobs. You will also need to create accounts for the computers that are going to act as members of your domain. Finally, you'll need to create accounts for users and computers within your domain that require the same rights and permissions.

Of course, you will also have accounts that will not need any rights or permissions, but you may have to represent them within your domain. For each of these accounts, you can create the account and use it within your domain, but then not have to worry about the account being used as a security principal within the domain.

Each account that needs access to resources must be assigned a unique security identifier (SID). The domain controller that is responsible for creating the account will build the SID from its Relative Identifier (RID) pool. If you have looked over Chapter 5, "Flexible Single Master Operations Design," you know that the RID Master is responsible for allocating the RIDs to each domain controller. These RIDs, combined with the SID from the domain, make up the account's SID. An account's SID identifies the domain in which the account resides and uniquely identifies the account within the domain.

(For more information on the RID Master and how it allocates RIDs to domain controllers, see Chapter 5 and Chapter 13, "Managing the Flexible Single Master Operations Roles.")

So why do we need to have RIDs? Why not just use the account's name? In short, names change. If we want an identifier that can be used for the lifetime of the account, we need to make sure that the identifier will not change. Having an identifier that changes makes more work for the administrator. If you were to change a user's name from Angela Jones to Angela Smith, and the account's permissions and rights were associated with the account's name, you would have to go into all the resources with which the account was associated and make the change. By using the account's SID (which should never change), you avoid this hassle.

Several accounts are already created within a domain, and they have SIDs that are considered well-known. Table 6.1 lists some of these well-known SIDs and the security principals with which they are associated. These are the SIDs that are used in every domain and are controlled by the operating system.

Table 6.2 shows the well-known security principals that are created for each domain. These are accounts that your users will employ when logging on to the domain or accounts your computers will use when authenticating to domain resources. Note that each SID of these security principals includes the domain identifier. Because these accounts could have access to resources within other domains, there has to be a way to identify them uniquely.

(These tables are not comprehensive lists of well-known SIDs. For more information about well-known SIDs, see Knowledge Base article 243330 at http://support.microsoft.com.)

In the following sections, we discuss the accounts you can create that will allow you to assign rights and permissions to the users and computers within your domain. The three accounts we start off with—Users, Computers, and Groups—are all known as security principals. The other two accounts that we examine—Contact and Distribution Group—are not security principals, but they provide other functionality within the forest.

Continue reading here: Security Principal Accounts

Was this article helpful?

What are the types of user accounts?

What are the 3 types of users in Linux?

What is user account example?

Which three types of users are available in Azure AD?