Planning Account Creation

As with any part of the design phase, you should determine the requirements for creating specific objects. This time, we are going to discuss the account creation options. Every organization will approach this differently; however, you should follow a few guidelines when creating User , Group , or Computer accounts.

Table 7.1 shows the five types of accounts within Active Directory.

Table 7.1: Accounts within Active Directory

Icon	Account Type	Description
	User	Allows a person to be authenticated by Active Directory or on a local computer and lets them access the resources.
	InetOrgPerson	Similar to the User account type, but also allows for integration with other LDAP-based directory services such as Novell s NDS or IBM s iPlanet servers.
	Contact	Represents a person who is external to the Active Directory forest While a contact cannot be granted permission to access objects, they do show up in address books and can be added to distribution lists when Exchange is implemented.
	Computer	Represents a physical computer that is member within the Active Directory forest.
	Group	Made up of a collection of User, Computer, or Group accounts that have the same resource access requirements.

When using Active Directory Users and Computers to create accounts, make sure that the name of the account reflects what the account represents and the type of account it is. A naming strategy consists of the rules that need to be followed when you are identifying an account. As you can see from the preceding descriptions, each of the account types has a unique icon that represents it within the management tools, so you will be able to tell a User account from a Computer account. Groups can pose an interesting problem, however. When we discuss group creation later in this chapter under the section Determining Group Requirements for Resource Access, you will find that multiple group types as well as scopes can be chosen based upon the functionality they require. All groups appear within the management tools with the same icon. The naming strategy you employ needs to address this.

Another rule you should follow involves populating as much account information as possible. This includes the Description field. Many designers will not address this field within the design specifications because they think it is superfluous. Although a good naming strategy should make identifying accounts easy, you ll come across instances when accounts will have names that are very close to the same ”the description could be the only way to tell them apart.

You should always start determining your account creation strategy based upon the existing account structure. This allows you to understand how the current accounts are created and what the current policies are. It will also allow you to conclude where the limitations of the strategy lie.

In the following section, we will look at how to identify the current account structure, as well as how to determine a naming strategy and an account authentication policy.

Identifying Current Account Structure

At this point within the design phase, you should have already identified the resources that exist within the organization so that you could make the proper decisions for designing the forest, domain, and OU structure. You also should have identified the administrative design as well as those employees who perform the administrative functions. If an organization is currently running another network operating system, such as NT 4, Windows 2000, Novell NetWare, or even a Windows peer-to-peer network, you may be able to transfer some of the current design to the new design.

You should study the current naming strategy for all of the account types in use. Some may not exist within the current design. For example, a peer-to-peer environment may not include Group accounts; the resources may have access granted directly to User accounts. A Windows NT 4 equivalent to the InetOrgPerson account does not exist, and is not available in a Windows 2000 Active Directory domain until the schema has been modified by running adprep to update the forest.

Where groups are concerned , make sure you document the existing group structure including nested groups if applicable . Again, what types of groups are used and how they can be used depends on the operating system. For example, a Windows peer-to-peer environment may not use groups at all, but if it does, it will not allow group nesting. All of the groups within a Windows peer-to-peer network are local to the computers where the resources are located. Windows NT allows group nesting within a domain to make resource access easier. Anyone familiar with the Windows NT AGLP principle understands that User accounts (A) are organized within Global groups (G), which are nested within Local groups (L), to which permissions (P) are granted to provide access to resources.

Document what you find within the existing environment so that you can use it later. If you have this information, you will be able to discuss the current strategies with the stakeholders and have a basis on which to build the new environment. It will also allow you to identify the deficiencies in the current design and make recommendations on ways to enhance the new design.

Identifying a Naming Strategy

All accounts need to have a unique name for which they are identified within the forest. With this in mind, you will need to identify how similar accounts will be named or how you will identify them when you are searching for them. User and InetOrgPerson accounts can be the most problematic when you are trying to determine a name, but Computer and Group accounts can prove problematic when you are trying to locate them within the directory. For these reasons, your naming policy should spell out the requirements for naming each type of account.

Naming User, Contact, and InetOrgPerson Accounts

A user s account should identify who the user is. This makes the user feel comfortable when they are logging in as well as making it easy for users to locate other user accounts. Administrative staff will need to easily identify each user, and other users will probably need to send e-mail to their fellow employees. A User account is usually identified using

• First Name, initial, or subset of first name

• First initial of last name, last name, or subset of characters from last name

• Additional characters to make account name unique

In small organizations, you may be able to use just the first name for the user. However, this solution makes the naming of user accounts for employees who have the same name difficult. If you have two users named Gina, you will need to identify how each of the names will be unique. Making one Gina and the other Gina1 will probably not make the second Gina very happy. Using a naming convention that uses the user s first name and first initial of their last name may work for some companies, but the same issues could arise. For example, Tom Smith and Tom Sanders could pose problems. And, as you might have guessed, inverting this naming convention so that the initial of the first name and the full last name is used as the account name will pose problems with users who have names such as Sandy Jones and Steve Jones.

Other options that companies employ include using the entire name of the user or adding their employee number to their account name. The first option works well until you have two John Petersons or Sue Johnsons. In this case, an incremental number at the end of the name or adding the middle initial to the name may work, but it may be confusing when you want to modify an account. The former option will guarantee that the account is unique, but it may be a little impersonal to some users. Of course, impersonal does work for some companies; the employee ID number is used as their logon ID.

No matter what option you choose, you will run into limitations. Make sure you sit down with the design team and choose a naming convention that everyone agrees upon. Once you have agreed, make sure that everyone responsible for creating accounts understands the naming convention so that all accounts will follow it.

The user accounts that will be used to allow users to have access to the network and network resources should follow a naming convention that is easy for them to accept and use. Other user accounts will exist within your environment that will be used for special purposes. Two of these special purposes are service accounts and temporary employees.

Service Accounts

A service account is a User account created for the sole purpose of allowing an application s background services to interact with the operating system. For many applications to function properly, the developers write a service program that runs in the background to provide needed functionality to the application. Although some of these services use the LocalService or NetworkService accounts, others require a special account to be created.

When creating service accounts, you should make sure a policy is in place that dictates how the account will be named. These names do not have to be user friendly as they do for a user account, but they should be descriptive enough to detail what the account is used for. That being said, because the service accounts are usually assigned generous permissions so that they can permit the service to access the resources, the name of this account should also be cryptic enough that someone trying to determine what the account name is will have a difficult time doing so.

Although every company will have their own ideas concerning the naming of service accounts, one option would be to prefix the service account name with SRV-. The application that requires this service could then be appended; for instance, an Exchange Server 2003 Information Store service might use the name SRV-Exch. Of course, this is not very cryptic, and a hacker could attempt to use this account to gain access to the network or attempt a denial of service attack on the service. To keep the service accounts hidden and secure, there are cases where companies have decided upon a service identity plan in order to hide the service accounts.

Using a service identity plan, the service, or the application that the service provides functionality for, is given a code name. For example, SQL Server could be assigned a code of 1S75. Combine this with the SRV- prefix, and you have a service account for SQL Server of SRV-1S75. This would allow the administrators to search for the service accounts within Active Directory by specifying SRV as the first letters of the account name, but it would keep the actual service name cryptic enough to safeguard it. Of course the disadvantage of this is trying to determine which accounts are used for which service, so the documentation for the service accounts will have to be good, or you could create an OU specifically for containing the service accounts so that you know where they are located within the directory.

Temporary Employees

Temporary employees are individuals who are hired for a short period of time. Whenever a company employs temporary employees, they experience a greater rollover in personnel. The staff members who are responsible for maintaining the accounts for temporary employees will be required to create and delete these accounts on a regular basis. Having a naming convention that identifies these employees will reduce the amount of time necessary to locate their accounts within the directory, and help prevent someone from adding their accounts into resource groups where they do not belong.

A long-standing tradition with Microsoft best practices is to name the temporary employees User accounts starting with a prefix T_. This provides the administrative staff with an efficient method of searching for the temporary accounts when they need to add or remove them from a resource or delete them when their term has expired .

Naming Computer Accounts

Computer accounts need to be identified within Active Directory just as any other account does. Computer accounts can be added to groups or directly to an object s access control list (ACL), so that an administrator will need to search for the Computer account. As with the User account, the Computer account should be named in a manner that will make it easy to search for and identify.

In a large organization, naming Computer accounts can be difficult. Descriptive names for the computers may be hard to come up with. Servers are generally given a descriptive name, but workstations are often overlooked. In the past, it was not uncommon to see workstation names that were the result of a random generation of alphanumeric characters. Although this may not have seemed like a bad idea under Windows NT, with the tools that are available under Windows Server 2003 and Windows XP, remote desktop control utilities are becoming more widely used. The users whom are responsible for assisting users through these utilities may need to find the systems by name. Unless the naming convention is easy to understand, good documentation will need to be maintained .

Some of the more common naming options for Computer accounts involve naming them after the user who they are assigned to or the location where they are used. Servers are usually identified by the services they provide. The following are some recommendations for naming both servers and computers.

Naming Servers

Server names can identify the service they provide. In small organizations, this name will probably consist of the service and an identifier to make the name unique. For example, domain controllers could be named DC1 and DC2. Exchange servers would be named EX1 and EX2. Although this may work in a small environment, trying to use this same convention in a large organization may be difficult.

To further identify servers within a large organization, you may want to name the servers for the service they provide and the location of the users for whom they provide the service. If you use this method, you will be able to identify the servers for a centralized or decentralized administrative model.

For example, take a company that has centralized resources with users who are located in offices at different locations. The server names could have a prefix for the service they provide, like EX for Exchange, which is followed by a location code for the accounts that use the server, such as CHI for Chicago. In this case, the EXCHI server would be the Exchange server hosting the mailboxes for the users in the Chicago office.

A company that employs decentralized resources can also take advantage of this scenario. They will be able to identify the service the server provides and the location for which it functions. A Microsoft SQL 2000 server residing within the Fort Worth branch could be identified as SQLFW.

With either of these two options, if more than one server provides the same service in the same location, you will have to determine how you are going to uniquely identify the server. And just as with the naming of the service accounts mentioned earlier, those companies that identify their servers with an alphanumeric naming convention will need to make sure they have documentation to make it understandable. Clustered servers also provide you with a challenge because you need to determine how you will name the virtual server that the users see, and the physical servers that provide the functionality.

Naming Workstations

Several options are available when it comes to naming workstations. Some organizations name the workstation for the user who uses it. Others name the workstation based on a location such as a phone extension the computer is next to or the cubicle number where the workstation resides. Still others use a random workstation name and keep track of the workstations in a database.

No matter what strategy you employ, you will need to keep good documentation so that the administrative staff knows which workstation they are working with in Active Directory. For those workstations that are running Windows XP Professional as their operating system, the Remote Desktop is available for administrators to work with. Any of the administrative staff who needs to manage the workstation from the Remote Desktop client will have to know the name of the workstation to which they are attaching.

Naming Group Accounts

As with the other account types, you should name groups in a manner that will allow you to identify what each is used for. The names you choose for groups should be very easy to search for and understand. Groups are used to organize accounts so that the members all have the same level of permissions for a resource. Unless the person naming the group really understands what it is used for, they might assign inappropriate permissions to a user.

Three group scopes exist within the two group types: distribution and security. Of the two group types, the security group is the most versatile. Security groups are used to provide access to resources and as distribution lists. Distribution groups are used solely by e-mail programs, such as Exchange, as distribution lists.

Most organization will organize the distribution groups within an OU that is used explicitly for maintaining distribution lists. These groups should be named based upon the need for the distribution list. When using Exchange, these groups will appear in the address lists users use when sending mail. Having a name that is descriptive as possible will make finding the group easier for the user.

Security groups are both a blessing and a curse for administrative staff. Though they can make assigning rights and permissions easier, the design and planning of these groups can be frustrating and time consuming. The primary reason for using a security group is to allow members of the group to have access to resources. When users no longer need access to a resource, their account can be removed from the group membership. When new users need access, they can be added to the group and be given all of the rights and permissions that are assigned to the group.

Note  

Group strategies are discussed in the section Determining Group Requirements for Resource Access later in this chapter.

The group s name should identify the group and help differentiate it from other groups within the organization. A policy should be created that designates how group names will be generated. This policy should include the following options:

• The group s scope

• The group s purpose

• The group s owner

The naming convention for the group should use the group s scope, such as G for Global groups, DL for Domain Local groups, and U for Universal groups. The purpose could be a general identification of the group s usage such as Printer03Print. The group s owner could be the business unit it is used in or the location of the resource, such as ATLHR for the Atlanta Human Resources division.

You should make sure that the naming convention is easy to understand and perform searches on. When you go to name the resource, make sure the most general portion of the name is at the beginning of the name. The most specific portion of the name should appear at the end of the name. This will allow the groups to be listed within dialog boxes in alphabetic order, and you will be able to find them easier.

Group names and descriptions can have a maximum length of 256 characters. Although this may seem as it is very generous and you could name a group with an extremely well documented name, you should take other limitations into consideration. For instance, when viewing the group name in dialog boxes, you will only be able to see around 20 characters without having to scroll or expand the column. Also, the Properties pages will only show approximately 50 characters of the name. Anything beyond that will not show and you will not be able to scroll to see it. You should always plan to have the most descriptive part of the name fall within the first 20 characters of the name. As a general rule, the name should be short enough to make out from all of the dialog boxes, yet long enough to be descriptive.

For instance, if you have a printer named Printer03 in the Atlanta Human Resources Department, and you want to assign users the Print permission on it, you could create a Domain Local group and name it DL-ATLHR-Printer03Print. This would allow you to sort the list of groups and locate all of the Domain Local groups. Within the resulting list, you would find all of the Atlanta Human Resources groups sorted together.

Another method employed by large companies that have many geographic locations is to use the location name first and then the scope, with the purpose last. In our preceding printer example, the name would then be created as ATLHR-DL-Printer03Print.

No matter what naming convention you choose, make sure you enforce it. If any of the groups do not follow the naming convention, searches will be very difficult. Stress the importance of this to anyone who has the ability to create groups. You will find that some individuals have their own ideas of what makes for a descriptive name. If they do not follow the criteria you set forth in your policy, the policy is useless.

Real World Scenario ”Naming Conventions

Randi is planning an upgrade of her current Windows NT 4 domain to a Windows Server 2003 forest. She inherited a network that has grown very fast. Her company has also bought other companies throughout this growth period and the network has grown to incorporate these new domains.

She currently has many resource domains in her NT 4 environment but would like to restructure this when she moves to the Windows Server 2003 forest. Groups in the different domains all have different naming conventions. For example, a separate domain exists for Randi s users in the Atlanta region. The sales people in the Atlanta office are in a group named Sales. Sales people in her Chicago office are in a group called SalesGroup. This has been very confusing to her and to other administrators.

When planning her authorization strategy, Randi decided to move to a more cohesive and easier-to-administer naming convention for groups. She would also like to make the design so that it is easy to incorporate new domains or forests, and the domains that reside in them. Because her new domain will be a Windows Server 2003 domain in Windows 2000 Native mode functional level, she can place users in Universal groups.

Randi plans to define the groups by group type first, then department, then location, then job responsibility, and so on. Some examples will include the following:

• G-Sales-Atlanta-Internal Sales

• G-Sales-Atlanta-Widget Sales

• G-Sales-Atlanta-Robot Sales

• G-Sales-Atlanta-Welder Sales

• G-Sales-Chicago-Press Sales

• G-Sales-Chicago-Widget Sales

  Using this naming convention, Randi is able to quickly identify the group types within her directory service and determine what they are used for and where the geographic location they apply.

 

Identifying an Account Authentication Policy

For security purposes, you should implement account policies that will safeguard the user accounts and resources. An account policy controls how passwords are used and how many times the user account can unsuccessfully attempt to authenticate within the domain before it is locked out. The account policy should be strict enough that the user accounts are protected from being attacked , yet not so restrictive that the users become frustrated when they try to access the network. Two parts make up the account policy: the password policy and the account lockout policy.

In conjunction with the account policy, you will need to determine how users will authenticate to the domain. You should specify how the user logs in, whether it is with the pre “Windows 2000 username or with the User Principle Name (UPN), as well as whether another form of authentication will be used, such as a biometric device. If using a smart card, you can dictate that the user has to have the smart card to authenticate with, but it is up to you to put a standard in place that states that the users will use either a pre “Windows 2000 logon or a UPN to log on. And the training that goes on to inform them on how to use a UPN will be up to you also.

Understanding the Password Policy

A user s password is the first line of defense against unwanted access into network resources. A password policy controls how the passwords can be used within the domain. Users should be informed of the importance of using strong passwords and be told how they can protect their passwords. Strong passwords use more than the standard lowercase letters from the keyboard. A strong password will use a combination of uppercase letters, lowercase letters, numerals, and special characters. Using a combination of these characters increases the possible combinations of characters within the password and dramatically increases the amount of time it will take an attacker to discover what the password is.

Warning  

Of course, no combination of characters is going to be effective if the user leaves their password out in broad daylight . No options within the password policy will remove yellow sticky notes from the bottom of keyboards or the sides of monitors . Make sure you stress the importance of keeping a password secure and secret.

Within a domain environment, the password policy for domain accounts can only be set at the domain level. A GPO linked to a domain s root controls the policy for every account within the domain. If there are any reasons why the password policy should be different for any set of users, another domain will need to be constructed to host the new policy.

Figure 7.1 shows the password policy options within the account policy container of the Default Domain Policy.

Figure 7.1: The Default Domain Policy password policies

The password policy consists of six settings (each of these settings can be used in conjunction with the others to create very strong password protection for accounts within the domain):

Enforce Password History     The Enforce Password History setting allows Active Directory to store the previous versions of users passwords. When a user changes their password, the new password is compared to the previous passwords to ensure that the user is not trying to reuse an old password.

Maximum Password Age     The Maximum Password Age setting allows you to define exactly how long a password may be used before another password has to be defined for the user.

Minimum Password Age     The Minimum Password Age setting defines how long a password must be used before it can be changed.

Minimum Password Length     The Minimum Password Length setting defines the number of characters that must be included within a password.

Password Must Meet Complexity Requirements     The Password Must Meet Complexity Requirements setting enforces the use of strong passwords. When enforced, the password must include at least three of the four character types: uppercase, lowercase, numeric, and special characters.

Store Password Using Reversible Encryption     The Store Passwords Using Reversible Encryption setting is used in conjunction with digest authentication. If digest authentication is required for IIS, the user s password is stored in clear text within Active Directory.

Of the six settings, the first five are commonly used within an Active Directory environment. A solid password policy will use all five of these policy settings. The default settings within a Windows Server 2003 domain are shown in Figure 7.1. Notice that the setting for password history is set to 24 passwords. Users will have to use 24 different and unique passwords before they can reuse any of them. Now note that the minimum password age is set to one day. This setting keeps the user from changing the password 24 times on the day that the password was initially changed just so that they can use the same password over again.

The maximum password age should be set long enough that the users will not become upset because they have to change their passwords too often, yet short enough that attempts to break in using the password will be thwarted by the would-be intruder having a new password to work against. The 42 days set by the initial security policy should be effective enough for most companies, although you may want to relax it some depending upon user feedback. Whatever you choose for this setting, make sure you get the proper backing from upper management to keep it in place. If they understand the need for constantly changing passwords, the users will have to abide by the policy.

The password length is another setting that users will complain about. The default setting of 7 characters is not extreme. Most organizations will use from 6 to 10 characters for password lengths. The longer the password, the more combinations of characters will be required to break it.

Finally, the setting that will cause the most complaints within the user community is complexity requirements. This setting alone will stop the use of pet names, nicknames, and favorite colors for passwords. Once you implement these, users will have no choice but to come up with creative passwords based on the character requirements. The downside to this setting is that users will start writing down their passwords, which leaves a paper trail. Passwords written on a piece of paper stuck under the keyboard are just as unsafe as using a password that is weak.

Understanding the Lockout Policy

The lockout policy for the domain controls the number of unsuccessful attempts someone can make with a user account before the account is locked from use. This thwarts an attacker who is attempting to figure out a user s password by entering several words. Figure 7.2 shows the default settings that are applied when Active Directory is installed.

Figure 7.2: The Default Domain Policy lockout settings

The lockout policy has three default settings (as with the password policy, each of the settings works in conjunction with one another to enforce a strong lockout policy):

Account Lockout Duration     The Account Lockout Duration setting specifies how long an account will remain locked out before the system automatically unlocks the account. A setting of 0 will not allow the account to unlock automatically; instead, an administrator will have to manually unlock it.

Account Lockout Threshold     The Account Lockout Threshold setting defines the number of incorrect password entries that can be made against an account before the account is locked out.

Reset Account Lockout Counter After     The Reset Account Lockout Counter After setting defines the amount of time that the lockout counter will continue to increment incorrect logon attempts. If this setting is configured for 5 minutes, the counter will not reset the bad attempts for a 5-minute period, even if the user successfully authenticated.

You will notice that the Default Domain Policy does not have the lockout restrictions enforced. This should be one area that you specify to be enforced when you design your account policy. Without these settings, attackers will have unlimited attempts at breaking into an account. Most organizations will allow three to five attempts before locking the account. Make sure your policy is generous enough that users will not complain too loudly about it, yet strict enough to be secure.

In conjunction with the lockout threshold, you will need to specify how long the account will remain locked out. The Account Lockout Duration setting will allow the account to reset automatically if you choose a number of minutes for the account to remain locked. This saves the administrator the frustration of having to manually unlock accounts; however, allowing the account to unlock automatically does not throw up a red flag to the administrator. If an administrator is inundated with telephone calls first thing Monday morning from users yelling at him because their accounts are locked out, that may indicate that his network has been attacked. Consider setting this option to 0 if you are concerned about possible attacks.

Understanding Log-on Options

In an Active Directory environment, it does not matter whether the users log on using their UPN or pre “Windows 2000 username ”the Kerberos service is responsible for authenticating their account. However, the method of authentication is different, and when you can use each type of logon will be dictated by the functional level of the domain. And then there are the alternative methods of authentication that add an additional level of security. Using devices such as smart cards and biometrics allows for multifactor authentication.

The log-in options that a user can use are:

Username/Password     Using the username/password combination is the traditional method of authenticating. User accounts are given a pre “Windows 2000 username that can be used to authenticate them. The combination of username and password that is provided during logon is validated by the Kerberos service on a domain controller within the domain that is specified during logon.

User Principal Name/Password     The User Principal Name/password combination allows you to authenticate to the domain just as you would with the username/password combination, but before the authentication request can be sent, a query is sent to the nearest Global Catalog server, which provides the appropriate username and domain name for the account.

Design Scenario ”Determining the Authentication Requirements

Donna is designing the authentication standards for the company. So far she has identified that the internal auditors would like to have passwords that are a minimum of eight characters, that complex passwords must be used, and that users must not be able to use the same password within a two-year span of time. They have also specified that they would like to enforce lockout restrictions that would lock a user s account if the password was entered incorrectly more than five times; at this point an administrator would be required to unlock the account.

1. Question: Which of the default settings for the domain will need to be updated for Donna s password policy design to meet the auditor s requirements? Answer: Within the password policy, the only change that will be required is changing the Minimum Password Length setting to 8. All of the rest of the settings meet or exceed the auditor s requirements.

2. Question: Which of the default settings for the domain will need to be updated for Donna s lockout policy design to meet the auditor s requirements? Answer: The Account LockoutThreshold setting will need to be set at 5 and the Account Lockout Duration setting will have to be set to 0.

 

Multifactor Authentication     Multifactor authentication uses an additional layer of security when the user attempts to authenticate. A user s account is associated with a certificate that identifies the user. If a smart card is used, the user is prompted to enter a Personal Identification Number (PIN) at the Windows logon screen. If the PIN is correct, the certificates stored on the smart card are compared with the certificates within Active Directory. Devices such as SecureID will generate a key value that is used to prove the authenticity of the person.

For organizations that need a higher level of protection, multifactor authentication should provide the security that they need. Multifactor authentication can be used within domains at any functional level, as can the username/password option.

In the Determining the Authentication Requirements Design Scenario, you will determine the authentication requirements for a particular scenario.