Planning and Implementing Active Directory Security | MCSE Planning and Maintaining a Windows Server 2003 Network Infrastructure: Exam 70-293 Study Guide and DVD Training System

EXAM 70-293 OBJECTIVE 5, 5.4, 6, 6.3

Windows Server 2003 supports statically assigned authorization to resources. This information is used to determine whether access to a resource is granted or denied. This is also referred to as static access control. Administrators can control access to AD objects by assigning them security descriptors. The security descriptor consists of information regarding the object’s ownership, access control lists (ACLs), and auditing.

Head of the Class…
Understanding Static versus Dynamic Access Control

As you might guess, in addition to static access control, there is another type of access control called dynamic access control (not currently supported by Windows Server 2003). With static access control, the information used to grant or deny access is preconfigured. At logon, a user is assigned an access control token according to the user’s account information (such as group memberships). If that information is changed (for example, the user is added to a new group or removed from a group), the change does not become effective until the user logs off and then logs on to receive a new access token.

With dynamic access control, access information can be changed dynamically, and the system determines whether to grant access at the time the request is made, based on information at that time, instead of a token issued at logon.

The ACL holds the static access control information. There are two parts to the ACL in the security descriptor:

The discretionary access control list (DACL) The DACL contains the information about which users and groups are allowed (or denied) permission to access the object, and the level of access granted. The security descriptor can even be configured to control access to a particular attribute of an object.
The system access control list (SACL) The SACL specifies the events that should be audited (if auditing is enabled).

DACLs and SACLs are associated with each type of AD object in Windows Server 2003.

There are three types of standard permissions supported with AD: Full Control, Write, and Read. Each AD object has these three standard permissions available for use. In addition to these three standard permissions, there are a number of additional permissions that can be used to control access more granularly. These depend on the object type. For example, additional permissions that can be assigned for user objects include Create All Child Objects, Delete All Child Objects, Allowed to Authenticate, Change Password, Receive As, Reset Password, Send As, Read Account Restrictions, Write Account Restrictions, Read General Information, Write General Information, Read Group Membership, Write Group Membership, Read Logon Information, Write Logon Information, Read Personal Information, Write Personal Information, Read Phone and Mail Options, Write Phone and Mail Options, Read Public Information, Write Public Information, Read Remote Access Information, Write Remote Access Information, Read Web Information, Write Web Information, and Special Permissions (configured through the Advanced settings).

So how are all these additional permissions used? For example, you could use the Read Group Membership permission to specify which users and groups are allowed to read the group membership information for a particular user account, as follows:

Select Start | All Programs | Administrative Tools | Active Directory Users and Computers.
Click View | Advanced Features (this will place a check mark by it in the menu).
In the left pane of the Active Directory Users and Computers console, expand the domain node and click the Users container.
In the right pane of the console, right-click the user account for which you want to set access controls and select Properties.
Click the Security tab. View the list of group and usernames in the top pane. When you select one, you will see the permissions assigned to it in the bottom pane. To add a group or user to this list, click the Add button.
Click Allow or Deny for each permission to granularly configure the permissions on the user account object for each user or group.

Another important aspect of access control is ownership. When a user creates an object, that user is designated as the owner of the object. An owner/creator has full access to the objects that user owns. Ownership can be delegated by the current owner to someone else.

To view the DACL, SACL, and ownership information for an object (such as a user account), click the Advanced button on the Security tab and do the following:

Click the Permissions tab to view the DACL.
Click the Auditing tab to view the SACL.
Click the Owner tab to view the ownership information.

Note
To get a detailed view of a particular access control entry (ACE), select the appropriate ACE on the Permissions or Auditing tab and click the Edit button.

When implementing Windows Server 2003’s AD, you need to provide security for your entire organization. AD allows for that by permitting you to put into action user authorization and built-in logon authentication. User authorization is used to provide specified clients access to objects such as folders. Built-in logon authentication is used for system permissions on the network.

You can also use trust relationships and Group Policy to provide security solutions for your AD network. Table 11.1 shows some AD security scenarios, along with solutions or tools you can use to plan and implement security.

Table 11.1: Scenarios and Solutions for a Stronger and More Secure Active Directory
Scenario	Solutions
You need to support and manage two forests in relationyour AD security framework, and authentication across forests needs to be simplified.	Use a forest trust, which is a trust between two Windows Server 2003 forests. This trust will create trust ships between every domain in the two forests. They can be created only on the forest root domains in each forest. These forest trusts are transitive. They can be one-way or two-way trusts. Unlike a parent-child trust, which is automatically established (implicit trust), administrators must manually establish a forest trust (explicit trust).
You need to enforce strong password policies because you have seen the word password used as an actual client password.	Use Group Policy to enforce strong password policies. Strong passwords are at minimum eight characters long and contain at least three or four characteristics, such as uppercase characters, lowercase characters, numeric digits, and symbols found on the keyboard (for example, !, @, $,#). They do not contain any part of the client’s user account name, words in dictionaries, or other easily guessed information.
You need to check event logs as part of your daily routine.	Use Group Policy to enable the Audit Policy function. Checking event logs as a daily routine can allow you to quickly recognize a security risk.
You need to make sure no one is trying to guess at user’s passwords in an attempt to compromise security.	Use Group Policy to use the Account Lockout Policy function on user accounts. This will limit the possibility of an attacker compromising the domain through frequent logon attempts.
You need to minimize the possibility of an attacker trying to crack a user’s password.	Use Group Policy to enforce minimum and maximum password age policies on user accounts to decrease the possibility of an attacker compromising your domain. As a rule, it is best practice to have passwords expire every 30 to 90 days. The default password age is 42 days.
You need to authenticate and verify the validity of each client.	Use public key cryptography to authenticate and verify each client’s identity.
You need to administer servers in your domain, but you do not want to be logged on as Administrator for long periods of time.	Use the Run as command to perform administrative tasks on the servers without needing to log on with your administrative credentials.
You need to thwart attacks from people who might try to grant elevated user rights to another user account.	Use security identifier (SID) filtering to stop the elevation of privilege attacks.
You have trade secrets and twoother confidential informa- tion on your network and you need to secure them.	Implement smart card authentication to provide factor authentication, encrypt data on the disk with Encrypted File System (EFS), and protect data traveling across the network with IPSec.
You need to secure account passwords on domain controllers, member servers, and local computers.	Implement the System Key Utility (syskey), which will provide strong encryption techniques to secure account password information.

The following are some basic security guidelines:

Avoid granting Full Control permissions over objects or Organizational Units (OUs) except when absolutely necessary, because this allows someone to take ownership of an object and also modify permissions on the object. The user will also have full control over all objects in that container unless inheritance of permissions is blocked.
Avoid changing the default permissions on AD objects, because this can cause unexpected results by creating access problems or reducing security.
Reduce the number of access control entries (ACEs) that apply to child objects. When using the Apply Onto option to control inheritance, not only do the specified objects inherit that access control, but also all child objects receive a copy of that ACE. Too many copies of this ACE on the network could significantly reduce network performance.
In the Windows Server 2003 family, ACLs feature single-instancing. Single-instancing works by storing only one instance of the ACL, even if multiple objects have identical ACLs.
If possible, assign permissions to groups rather than users. This makes management easier.
Generally, allow Read All Properties or Write All Properties permissions, rather than setting controls on individual properties, unless there are compelling reasons to do so.

Allow Read or Write access to property sets, rather than to individual properties.

Note

Property sets are also called attribute sets. These are defined sets of attributes that represent the entire set in an ACL. Microsoft defines 10 attribute sets; and you can define custom attribute sets, but each attribute can be a member of only one set.

Understanding Permission Types

It’s important to differentiate between the different types of permissions that can be assigned to user and group accounts in Windows Server 2003 networks. There are three types of permissions:

AD object permissions
NTFS file permissions
Shared folder (share) permissions

The following sections describe the AD, NTFS, and share permission types, as well as the permissions available for each.

Active Directory Permissions

AD permissions are set on any AD object, as follows:

Select Start | Administrative Tools | Active Directory Users and Computers.
Select View | Advanced Features.
Right-click the object you wish to set permission on and select the Properties option.
Select the Security tab and choose Advanced. You will see all of the available permissions for this object.
Click Add to add permissions and type the name of the user, computer, or group you wish to add. Then click OK.
In the Permission Entry for Objectname option, select the Allow or Deny options from the Object and Properties tab. The Objectname would be whatever you choose to set the permission on in step 3 above.

Object permissions in AD have many rights, such as the following:

Extended Rights Used for special operations within AD that are not related to either Read or Write access, such as Change Password, which allows the ability to change a password if the original password is known.
Validated Writes Includes value checking, which makes certain that the changed value matches specific requirements. An example of this is Validated Write Add/Remove Self As a Member. This applies to a group and allows members to remove or add themselves to a specific group for membership.
Property Set Allows a group of properties that have a specific set of rights, rather than individual rights. An example is Domain Password, which is managed through the user interface using the Domain Security Policy Group Policy Object (GPO).

Most of the time, when setting permissions on AD objects (and for assigning permissions in general) you should use groups rather than individual user accounts to control access. If one set of users needs Read permissions, and another set of users needs Change permissions, then create one group for each set of users and assign the permissions to the group. If multiple global groups need the same access, create a local group containing the global groups and assign permissions to the local group.

Exam Warning

Any object that has an explicit Allow permission entry cannot be overridden by the inherited Deny permission. Explicit permissions will always take precedence over inherited permissions. However, the explicit Deny permission always takes precedence over all other permissions.

You should try to minimize the total number of individual permissions that are published to child objects in AD. This can become a real performance issue if the total size of all the AD permissions approaches the limits of the disk storage space or the memory and processing capacity of your domain controller.

NTFS Permissions

NTFS permissions are applied at the file or folder level, and they are effective both when accessed across the network and when accessed at the local machine. NTFS permissions cannot be applied to files and folders located on FAT or FAT32 volumes. NTFS permissions can be applied in conjunction with share permissions, which give you more control of the shared resource. When the cumulative NTFS permission conflicts with the cumulative share permission, the more restrictive permission will always override the less restrictive permission. NTFS permissions allow you to set permissions for a group or user by using the Allow or Deny option.

You can set NTFS permissions as follows:

Open Windows Explorer and right-click the file or folder on which you wish to set permissions.
Select the Security tab.
To add a user or group, click the Add button. By default, the Administrators group has Full Control and the Everyone group has Read, Read & Execute, and List Folder Contents permissions.

NTFS permissions include Fill Control, Modify, Read and Execute, List Folder Contents, Read, Write, and Special Permissions. To use the Special Permissions option, you must select the Advanced option, then edit the Permission Entry for which you wish to grant special permissions. The Special Permissions option lists Fill Control, Traverse Folder/Execute File, List Folder/Read Data, Read Attributes, Read Extended Attributes, Create Files, Write Data, Create Folders/Append Data, Write Attributes, Write Extended Attributes, Delete Subfolders and Files, Delete, Read Permissions, Change Ownership, and Take Ownership.

Note

In the Windows Server 2003 family, the Anonymous group is not a member of the Everyone group. This includes Windows XP machines. If you have older applications that require anonymous access, you will probably need to go in and tweak the group permissions. If you need to grant access to the Anonymous logon group, you will need to explicitly add the Anonymous Logon security group and its permissions.

Share Permissions

Share permissions apply only to folders that are shared, and they only restrict access across the network. Share permissions on a folder are irrelevant when the folder is being accessed on the local machine.

To set share permissions, follow these steps:

Open Windows Explorer, right-click the folder on which you wish to set permissions, and select Sharing and Security in the context menu.
Select the Sharing tab.
To set permissions for a user or group, click the Permissions button.
Click the Add button to add a user or group. By default, the Everyone group has Read permission.

When setting share permissions, you can assign Read, Change, or Full Control permissions to a user or group.

Note

There are times when assigning individual permissions is appropriate. For example, if a help desk operator needs Write access to two properties of a user object, it makes sense to use one ACL for each of them, rather than trying use only one ACE by granting Write access to the entire user object.

Physically Securing Domain Controllers

A good security policy and framework starts with the basics: physical security. Implementing firewalls, access controls, permissions, and other software security measures on the network, but keeping the door to your server room unlocked could give malicious users access to everything they need to take control of your systems and access your data. Best security practice is to keep all domain controllers locked in a secure room that has limited public access.

You should also strictly limit which users you place in the following groups:

Enterprise Admins
Domain Admins
Server Operators
Account Operators
Print Operators
Backup Operators

Membership in these groups confers a lot of power (and the opportunity to misuse that power) and so should be limited to trusted personnel within your organization.

Securing the Schema

ACLs are used to protect schema objects from unauthorized use in AD. Members of the Schema Admins group are the only members permitted to have write access to the schema. The only default member of the Schema Admins group is the Administrator account in the root domain of the forest.

You should restrict membership in the Schema Admins group, because extending the schema improperly can have serious consequences to your network. For example, an improper change to the schema can cause existing objects in the directory to become invalid. If you disable a particular attribute in an object class and there are existing objects in that class that contain that attribute, these objects will become invalid because they contain an attribute that is not allowed in the class definition.

Managing Cross-domain and Cross-forest Security Relationships

Security gets more complicated when users in one domain need to access resources in another domain. The domains might be within the same forest or in different forests. When the domains are in the same forest, it is called a cross-domain relationship. When they are in different forests, this is called a cross-forest relationship.

Cross-domain Relationships

You might sometimes need to allow additional domains inside the same forest to gain security access to a trusted domain. This is done by using the Kerberos or NTLM protocol for user authentication. Kerberos works by allowing a domain controller called the ticket granting authority to issue a ticket to the client machine that made the request. The trusting domain then is presented with ticket request for authentication. After the user has been authenticated in either Windows 2000 or Windows Server 2003, AD will allow users to have access from one domain to another only after they are authenticated from their original domain. This is because two domains that belong in the same forest are joined by an implicit trust relationship.

All of the root domains for all domain trees within a forest have a two-way transitive trust with one another. This means that any domain in a forest can access the resources in any other domain in the forest (given the proper permissions), because the trust path flows up the tree to the root domain, across to the root of the other domain, and down the tree to the other domain. However, to shorten this path and make for faster authentication, you can create shortcut trusts directly between the two domains.

Because all domains within a forest trust one another, access control between domains is accomplished in the same way as within a domain: by using security groups and setting permissions and user rights. When using groups to assign permissions and rights, keep in mind a few concepts that relate to security groups:

Group nesting
Group scope
Functionality level of the domain

We will discuss each of these in a more detail.

Group Nesting

Nesting refers to the ability to place groups inside one another; that is, a group can be a member of another group. You cannot just nest any type of group anytime, however. Nesting is allowed based on group scope and the functionality level of the domain.

Group Scope

The scope of a group represents the area that a group covers within a domain tree or a forest. There are three possible group scopes:

Universal (only in Windows 2000 native and Windows Server 2003 domains) Can contain accounts, global groups, and universal groups from any domain in the forest.
Global Can contain accounts from the same domain. If the functional level is Windows 2000 native or Windows Server 2003, this scope can also contain other global groups from the same domain.
Domain local Can contain accounts and global groups from any domain. If the functional level is Windows 2000 native or Windows Server 2003, this scope can also contain universal groups from any domain and domain local groups from the same domain.

Functionality Level of the Domain

Both domains and forests can be set to different functionality levels, depending on the types of domain controllers that are present. Domain functionality affects how groups can be nested and what types of members groups of each scope can contain. There are four functionality levels available for domains:

Windows 2000 mixed Can contain Windows NT 4, Windows 2000, and Windows Server 2003 domain controllers. This is the default functionality level when you create a new domain.
Windows 2000 native Can contain Windows 2000 and Windows Server 2003 domain controllers.
Windows Server 2003 Interim Can contain Windows NT 4 and Windows Server 2003 domain controllers.
Windows Server 2003 Can contain only Windows Server 2003 domain controllers.

Note
You can raise the functionality level of a domain using the Active Directory Domains and Trusts tool, but you cannot lower it.

Cross-forest Relationships

By default, domains in different forests do not have a trust relationship with one another. However, Windows Server 2003 gives you two ways to provide for such relationships: you can join two forests together in a forest trust, or you can create an external trust between two domains in two different forests.

External trusts were also available in Windows 2000. Forest trusts are new to Windows Server 2003. In Windows Server 2003 networks, security identifier (SID) filtering is enabled by default when you create a new external or forest trust. This is a feature that protects against attackers who seek to elevate their user rights or privileges. SID filtering ensures that only the SIDs of security principals in the trusted domain are contained in any authentication requests coming from that trusted domain. This prevents the misuse of the SIDHistory attribute to grant higher privileges than an account should have.

External Trusts

An external trust creates a one-way or two-way nontransitive trust between domains in different forests. These are used if you do not want the transitivity provided by forest trusts; that is, you want Domain B in Forest 1 to have a trust relationship with Domain E in Forest 2, but you don’t want the trust relationship to extend to any other domains in other forests.

Note

Forest trusts are also used to give users access to resources that are located in a Windows NT 4 domain, since such domains are not members of forests.

When you create an external trust, AD handles the cross-forest relationship by creating a foreign security principal object in the trusting domain, also called the internal domain (the one where the resources are located) to represent each of the security principals (the users who want to access those resources) from the trusted, or external, domain. The foreign security principals can be put into Domain Local groups in the trusting domain, because Domain Local groups are allowed to contain members from domains that are in different forests.

You can create an external trust either by using the Active Directory Domains and Trusts tool or by using the netdom trust command. To use Active Directory Domains and Trusts, do the following:

Log on as a Domain Admin, Enterprise Admin, or user who has been delegated the proper authority, or use the Run as command to enter your credentials.
Select Start | All Programs | Administrative Tools | Active Directory Domains and Trusts.
In the left pane of the console, right-click the domain node with which you want to create the trust relationship and select Properties.
Click the Trusts tab.
Select New Trust and click Next.
Enter the Domain Name System (DNS) or NetBIOS name of the domain on the Trust Name page. Click Next.
Select External trust on the Trust Type page. Click Next.
The next page asks you to select the direction of the trust (one way incoming, one way outgoing, or two-way). Select the appropriate trust type and follow the Wizard’s directions (which depends on the trust type you selected).

You can create both sides of a two-way trust if you have the proper credentials for both domains. You can either allow users from the other domain to access all resources in the domain or you can allow access to only selected resources.

The syntax for using the netdom trust command to create a two-way trust is as follows:

netdom trust <trustingdomainname> /d:<trusteddomainname> /add /twoway

Forest Trusts

Forest trusts reduce the number of external trusts that need to be created. Forest trusts are created between the root domains of two forests. A forest trust can be either a one-way or two-way transitive trust. If you create a two-way trust relationship, this will effectively provide a trust relationship between every pair of domains within the two forests.

The forest functional level in both forests must be set to Windows Server 2003 before you can create a forest trust, and DNS must be properly configured. Both Kerberos v5 and NTLM are supported for authentication between the forests, and user principal names (UPNs) can be authenticated across the forests.

Exam Warning

A forest trust affects only the two forests between which the trust is explicitly created. It does not extend to other forests. So, although transitivity exists within the trust, there is no transitivity in terms of a third trust. In other words, if you create a trust between Forest 1 and Forest 2, and you create another trust between Forest 2 and Forest 3, this does not result in any kind of trust relationship between Forest 1 and Forest 3.

A forest trust is created using the Active Directory Domains and Trusts tool. To create a trust between two Windows Server 2003 forests, perform these steps:

Select Start | All Programs | Administrative Tools | Active Directory Domains and Trusts.
In the left console pane, right-click the domain that is the forest root and select Properties.
Click the Trust tab and select New. Click Next.
Enter the DNS or NetBIOS name of the forest with which you want to create a trust on the Trust Name page. Click Next.
Select Forest trust on the Trust Type page. Click Next.
Select the direction (two-way, one way incoming, or one way outgoing) on the Direction of Trust page.

Follow the Wizard’s directions (which vary depending on the direction of trust selected).

Note

There is a special group called the Incoming Forest Trust Builders group. Members of this group are allowed to create one-way incoming trusts to the forest root domain. By default, there are no members in this group, but you can use it to delegate this authority.

You can also synchronize certain types of data across forests. This includes Global Address Lists (GALs) used by Microsoft Exchange Server, public folders, and directory objects.

Account Security

Windows Server 2003 uses accounts to represent security principals (entities that access resources on the computer or on the network) of the following types:

Users
Groups
Computers

Note
Services can also have accounts. These are special user accounts that are used as dedicated service accounts so applications can access resources.

These accounts automatically have a SID assigned to them, that will be used by the account to access resources within the domain. As mentioned earlier, if a security principal from an outside domain requests resources from a local AD domain, AD will create a foreign security principal for that request.

The security information that is associated with an account is used in the authentication process, which is when a user or computer’s identity is verified. After authentication, it is used for authorization, which is the determination of which resources the user or computer can access and the level of access that is allowed. Additionally, the account is used for auditing any activities that are performed on the computer.

AD contains three built-in accounts that are created by default when the domain is created:

Guest account This account does not require a password (although you can assign one) and is for users who do not have an account in the domain. It is a member of the built-in Guest group. This account is disabled by default, and for security reasons, it should remain disabled.
Administrator account This account has complete and total control of the domain. It belongs to the Administrator, Domain Admins, Enterprise Admins, Schema Admins, and Group Policy Creator Owners groups. For obvious reasons, this account should have a strong password and be used only for tasks that require this level of privileges.

HelpAssistant account This ad hoc account is created when you request a remote assistance session and is used to establish a remote assistance session. If no remote assistance requests are pending, the account is deleted.

Note

In earlier versions of Windows, the Administrator account could not be disabled. With Windows Server 2003, you can disable the built in Administrator account to prevent it from being compromised, and give administrative privileges to other individual accounts. If you choose not to disable it, you should at least consider renaming it. If you don’t, attackers already have half of what they need to know (username and password) to gain control of the computer or network. If you disable the Administrator account, it can still be used when the computer is started in Safe Mode, to perform troubleshooting and repair activities.

User Account Security

Since all of the built-in accounts have the same permissions by default, it is a good idea to either rename or disable them. For instance, all Windows Server 2003 servers have an Administrator account by default. This is a security risk because it is no secret that built-in accounts are part of the operating system. You can rename the account to something that sounds innocuous. For example, hackers will not immediately know that the jrjones account is actually the built-in Administrator account. If you rename the Administrator account, it will still retain its properties, because it keeps the same SID. The SID will enable the account to retain its password, group membership, profile, assigned permissions, user rights, and account information.

Another way to increase security is to use the Account Lockout Policy. This policy will look at how many times a user has tried to log on to the domain and will deny access if a specified threshold is reached, locking out the account so that no more attempts can be made for a specified period. The threshold can be set at any number from 0 to 999. For example, if you set the account lockout threshold to 3, after the account credentials have been entered incorrectly three times the user will receive a message that the account has been locked out. By default, the lockout duration is 30 minutes, but you can set it to any number of minutes from 0 to 99,999. If you set the lockout duration to 0, the account will remain locked until an administrator explicitly unlocks it.

You can also set a time after which the lockout counter is to be reset. If a user tries to log on and is unsuccessful, that counts as one attempt. If the user then tries again before the reset period, that will count as a second attempt. However, if the reset period has passed and the user tries to log on again, it will count as the first attempt.

All Account Lockout Policy options are set in Group Policy. The Local Security Policy is used to set lockout parameters for logging on to the computer, and the Domain Policy is used to set lockout parameters for logging on to the domain. To set the lockout policies, open the appropriate (local or domain) GPO and follow these steps:

In the left console pane of the GPO Editor, expand the Computer Configuration node, expand Windows Settings, and expand Security Settings.
Click Account Lockout Policy.
In the right console pane, you will see three policy entries: Account lockout duration, Account lockout threshold, and Reset account lockout counter after.
Click the policy you want to configure, check the Define this policy setting check box, and then enter the desired value (number of attempts before lockout, duration in minutes of lockout, or minutes to pass before resetting the lockout counter).
Click OK.

The Account Lockout Policy options will be discussed in more detail in the “Security Policies” section later in this chapter.

Computer Accounts

All machines that join a domain have a computer account created in AD, and each computer account is unique. This includes Windows NT, Windows 2000, Windows XP, and Windows Server 2003 machines. These are the only machines that can have domain accounts. Clients that are running any of the Windows 9x operating systems (including Windows ME) are not assigned computer accounts. A user who has a user account in the domain can use a Windows 9x machine to log on, but the machine itself does not belong to the domain and cannot be centrally managed as computers running more secure operating systems can.

You can create a computer account in advance for a computer that is going to join the domain using Active Directory Users and Computers, or the account can be created during the process of joining the domain as long as the user who is joining the computer to the domain has domain administrative credentials or has been granted the right to join computers to the domain. Table 11.2 outlines some common situations that you might encounter and the options you can set in the user account properties to provide a solution for each.

Table 11.2: User Account Scenarios
Scenario	Option to Use	What It Does
A user gave his password to a consultant because the user did not wish to contact the tech support help desk to request a user account and password for the consultant.	Force the user to change his password the next time he logs on. Set the User must change password at next logon option in the user’s account properties.	This will force the user to change his password the next time the user logs on to the network. This will ensure that only this user knows his new password.
You have a temporary worker who will be with the corpora- pretion for only eight weeks. You want to give her access to network resources, but do not want the user to change her password.	Set the User cannot change password option in the user’s account properties.	This will allow you to have total control over this account by venting the temporary worker from changing her password.
You need to create new service accounts for your backup software. You don’t want to deal with changing its password every 45 days in accordance with your current password policies.	Set the Password never expires option in the account’s properties.	This password will never expire. By using this option for your service accounts, you will not need to worry about passwords expiring (which could cause software that uses these service accounts to stop functioning). This setting overrides the password expiration policies set in Group Policy.
You have a client that needs to log on to the network from an Apple Macintosh computer.	Set the Store passwords using reversible encryption option in the user’s account properties.	This option will let Apple computer clients log on to a Windows work. This option should be used only for this purpose.
You have received a call stating that a person has left the company and you need to access to the network.	Set the Account is disabled option in the user’s account properties.	This will stop the user from accessing any network accounts.
You have a remote client who has a laptop with a smart card enabled for logging on to the network. This user will be in town for a conference and needs to log on to the domain.	Set the Smart card is required for interactive logon option in the user’s account properties.	The user can use his or her smart card and smart card reader with the valid personal identification number (PIN) for logon access. The password will be set to a random and complex value, and the word will never expire option is set automatically.
You need to set a service account to behave as if it were a user account on the network.	On the Delegation tab of the user’s account properties, set the Account is trusted for delegation option.	This will allow a service running under this account to perform tasks as if it were a user account.
You need to make sure no one assigns a temporary or guest account to a service.	Set the Account is sensitive and can- not be delegated option in the account properties.	This will prevent the delegation of the specified account to a service.
You have clients who needs to use 3DES encryption for logging on to the domain.	Set the Use DES encryption types for this account supoption in the user’s account properties.	This option will allow you to port the Data Encryption Standard (DES). This encryption level ports the following standards: IPSec 56-bit DES, IPSec Triple DES (3DES), MPPE Standard (40-bit), MPPE Standard (56-bit), MPPE Strong (128-bit), and IPSec DES (40-bit).
You need to allow for imple-altermentation of Kerberos other than the Windows 2000 and Windows Server 2003 implementations.	Set the Do not require Kerberos pre-authentication option in the user’s account properties.	This will provide support for nate implementations of the Kerberos protocol. Domain con- trollers running Windows 2000 or Windows Server 2003 can use other mechanisms to synchronize time. Note that pre-authentication provides additional security.

You can configure all of the settings noted in Table 11.2 by right-clicking the user account in Active Directory Users and Computers and selecting Properties. All of these settings are on the Account tab, except when otherwise specified. Note that the

Delegation tab might not appear in the user account properties. If not, you need to do one or both of the following:

Raise the domain functional level to Windows Server 2003.
Register a service principal name (SPN) for the user account.

To register an SPN for a user account, follow these steps:

If you haven’t done so previously, install the Support Tools from the Windows Server 2003 installation CD (navigate to the Support Tools folder on the CD and click the .msi file).
Select Start | Run, type cmd, and click OK to open a command prompt window.
At the command prompt, type setspn –A http/<SPNNAME> accountname. For example, if the account name is joejones, you should type setspn –A http/joe joejones to register the SPN “joe” for this account.
You will receive the output message that the system is registering the ServicePrincipalName.

Open the Properties sheet for the account, and you will see a Delegation tab.

Test Day Tip

Constrained delegation is new to Windows Server 2003. Administrators can specify which service an account can be delegated to, and the trust delegated for a service can be limited to a select group of services that are defined by the administrator. For more detailed information about this new feature, see the article titled “How New Delegation of Authentication Options Improve Security in Windows Server 2003,” by Debra Littlejohn Shinder (http://www.windowsecurity.com/Deb_Shinder/).

User Authentication

When a user’s identity is established by the authentication process, the Local Security Authority (LSA) will process the use Kerberos v5 or NTLM authentication requests. Then LSA will generate an access token that contains the username and SID or SIDS (depending on whether the user belonged to more than one group) for the groups to which the user belongs. The SID will be permanently associated with this user account. If the account is renamed, it will still have the same SID. If the user is added to or removed from a group after the access token has been issued at logon, however, the user must log off and log back on so that the access token can be updated before the new group membership information will take effect. At that point, the user will have the permissions and rights associated with the new group membership status.