RODC Filtered Attribute Set, Credential Caching, and the Authentication Process with an RODC

http://technet.microsoft.com/en-us/library/cc753459(WS.10).aspx

RODC Filtered Attribute Set, Credential Caching, and the Authentication Process with an RODC

Updated: May 14, 2009

Applies To: Windows Server 2008

This topic explains what the read-only domain controller (RODC) Filtered Attributes Set (FAS) is and how credential caching and the authentication process work for an RODC.
RODC FAS

RODCs contain a complete copy of the Active Directory database in the sense that they contain a read-only copy of all partitions that are held by an equivalent writable domain controller. For example, an RODC contains read-only copies of the schema and configuration partitions. If you are using Active Directory–integrated Domain Name System (DNS), an RODC that is a DNS server contains read-only copies of the DNS application directory partitions.

However, there is a set of attributes that, by default, are not replicated to an RODC:

* Attributes that belong to the RODC FAS

* Credentials, except for the RODC's own computer account credentials and a special krbtgt account for the RODC

The RODC FAS is a dynamic set of attributes that is not replicated to any RODCs in the forest. These attributes are not replicated to RODCs because they contain sensitive data. Because they are not replicated to RODCs, a malicious user who has managed to compromise an RODC cannot expose them.

The default RODC FAS contains the following list of attributes:

* ms-PKI-DPAPIMasterKeys

* ms-PKI-AccountCredentials

* ms-PKI-RoamingTimeStamp

* ms-FVE-KeyPackage

* ms-FVE-RecoveryGuid

* ms-FVE-RecoveryInformation

* ms-FVE-RecoveryPassword

* ms-FVE-VolumeGuid

* ms-TPM-OwnerInformation

These attributes are defined in the RODC FAS and marked as confidential to support Credential Roaming and BitLocker Drive Encryption.

Some other applications that use Active Directory Domain Services (AD DS) as a data store may also have credential-like data (such as passwords, credentials, or encryption keys) that you do not want to be stored on an RODC in case the RODC is stolen or compromised.

For applications with this type of data, you can take these precautions:

* Extend the RODC FAS to include any credential-like attributes that you want to prevent from replicating to any RODC in the forest.

* Mark the attributes as confidential, which removes the ability to read the data for members of the Authenticated Users group, which includes RODCs. This step is necessary so that if an RODC gets compromised, an attacker cannot—using the RODC account—read the data directly from the directory. This acts as an additional measure of protection by preventing an attacker from using a compromised RODC to read the attributes from the directory, even if they are not replicated to the RODC.

noteNote
In general, if an authenticated user requests READ_PROPERTY permissions for an attribute or for its property set, read access is granted. Default security in AD DS is set so that authenticated users have read access to all attributes.

When the attributes are prevented from replicating to RODCs, they cannot be exposed unnecessarily if an RODC is stolen or compromised.

A malicious user who compromises an RODC can attempt to replicate attributes that are defined in the RODC FAS. If the RODC tries to replicate those attributes from a domain controller that is running Windows Server 2008, the replication request is denied. However, if the RODC tries to replicate those attributes from a domain controller that is running Windows Server 2003, the replication request could succeed. Therefore, as a security precaution, you should ensure that the forest functional level is Windows Server 2008 if you plan to configure the RODC FAS. When the forest functional level is Windows Server 2008, an RODC that is compromised cannot be exploited in this manner because domain controllers that are running Windows Server 2003 are not allowed in the forest.

If an RODC is stolen, any attributes that were configured to be part of the RODC FAS will not be present on the RODC. Therefore, RODC FAS data cannot be read on a stolen RODC whether the forest functional level is Windows Server 2003 or Windows Server 2008. Other data that resides on the stolen RODC can be read, but the RODC FAS data will not be read because it will not be present.

We recommend that you also mark as confidential any attributes that you configure as part of the RODC FAS. Marking the attribute as confidential provides an additional safeguard against an RODC that is compromised by removing the permissions that are necessary to read the credential-like data.

For procedures that show how to add an attribute to the RODC FAS, see RODC Administration.
Credential caching

As mentioned earlier, by default an RODC does not store user credentials or computer credentials, except for its own computer account and a special krbtgt account for that RODC. For more information about the attributes that are part of a user or computer account credentials, see User and Computer Credentials.

When users or computers in a site that is serviced by an RODC attempt to authenticate to the domain, the RODC by default cannot validate their credentials. The RODC then forwards the authentication request to a writable domain controller. However, there might be a set of security principals that may need to be able to authenticate in a site that is serviced by an RODC, even in cases where they have no connectivity to writable domain controllers.

For example, you might have a set of users and computers in a branch office that you want to be authenticated even if there is no connectivity between the branch office and sites that contain writable domain controllers. To resolve this issue, you can configure the PRP for that RODC to allow the passwords for those users to be cached on the RODC. If the account passwords are cached on the RODC, the RODC can authenticate those accounts when connectivity to writable domain controllers is not available.

The PRP acts as an access control list (ACL). It determines whether an RODC is permitted to cache credentials for an account. After the RODC receives a user or computer logon request, it attempts to replicate the credentials for that account from a writable Windows Server 2008 domain controller. The writable Windows Server 2008 domain controller refers to the PRP to determine if the credentials for the account should be cached. If the PRP allows the account to be cached, the writable Windows Server 2008 domain controller replicates the credentials for that account to the RODC and the RODC caches them. During subsequent logons for that account, the RODC can authenticate the account by referring to the credentials that it has cached. The RODC does not have to contact the writable domain controller.
noteNote
The credentials are not actually stored in a cache, as in the traditional sense of a storage buffer. Instead, the credentials are stored directly in the Active Directory database. Also note that while there are approximately five attributes that comprise the credentials for each account, there can be any number accounts defined in the PRP.

A default PRP is defined that applies to any newly installed RODC. The default PRP specifies that no account passwords can be cached on any RODC, and certain accounts are explicitly denied from being cached on any RODC.

The PRP is defined by two multivalued Active Directory attributes that contain security principals (users, computers, and groups). Each RODC computer account has these two attributes:

* msDS-Reveal-OnDemandGroup, also known as the Allowed List

* msDS-NeverRevealGroup, also known as the Denied List

To help manage the PRP, two other attributes that are related to the PRP are maintained for each RODC:

* msDS-RevealedList, also known as the Revealed List

* msDS-AuthenticatedToAccountList, also known as the Authenticated to List

The msDS-Reveal-OnDemandGroup attribute specifies what security principals can have passwords cached on an RODC. By default, this attribute has one value, which is the Allowed RODC Password Replication Group. Because this domain local group has no members by default, no account passwords can be cached on any RODC by default.

The list of user and computer accounts whose credentials are permitted to be cached does not imply that the RODC has necessarily cached the passwords for those accounts. These accounts are considered “cacheable,” and if an administrator takes no further action other than setting the PRP, these users will have their passwords cached only after they log on against the RODC for the first time. However, an administrator can also have an RODC cache any accounts in advance of any authentication request. This way, the RODC can authenticate those accounts, even if the wide area network (WAN) link to the hub site is offline. You can cache passwords in advance by using the Active Directory Users and Computers snap-in or by using the repadmin /rodcpwdrepl command. For more information, see Administering the Password Replication Policy.

You must include the appropriate user, computer, and service accounts in the PRP so that the RODC can resolve authentication and service ticket requests locally (for the site). When only users (but not computers or service accounts) from the site are specified on the Allow list, the RODC is not able to resolve requests for service tickets locally, and it relies on access to a writable Windows Server 2008 domain controller to resolve the requests. Also, the RODC is not able to authenticate the computer account if the password for the account is not cached. In the WAN offline scenario, this is likely to lead to a service outage.
noteNote
RODCs have a feature known as Administrator Role Separation, which you can use to delegate to any domain user the credentials to be an administrator of an RODC, without granting that user any other privileges in the domain. However, the password for the delegated administrator is not cached by default. As a best practice, cache the password of the delegated RODC administrator and refresh the cache after each time that the password changes. For more information about the delegated administrator, see Administrator Role Separation.

The msDS-NeverRevealGroup attribute specifies what security principals are explicitly denied from having their passwords cached on an RODC. This is useful to help prevent credentials for highly privileged accounts from replicating to an RODC. That way, you can be assured that an attacker cannot obtain credentials for highly privileged accounts from a stolen or compromised RODC. This attribute has the following default values:

* Account Operators

* Server Operators

* Backup Operators

* Administrators

* The Denied RODC Password Replication Group, which is a domain local group that includes the following:

o Enterprise Domain Controllers

o Enterprise Read-Only Domain Controllers

o Group Policy Creator Owners

o Domain Admins

o Cert Publishers

o Enterprise Admins

o Schema Admins

o Domain-wide krbtgt account

The msDS-NeverRevealGroup attribute takes precedence over the msDS-Reveal-OnDemandGroup attribute. Therefore, if an account is either directly or indirectly included in both the Allowed List and the Denied List, the account password cannot be cached on the RODC.

The msDS-RevealedList is the list of security principals (including computer accounts) whose current credentials have been replicated to the RODC.
noteNote
The msDS-RevealedUsers attribute is another attribute that is related to credential caching. The msDS-RevealedUsers attribute is used by the system to store information about the secrets of any security principal, including computers, which has ever had its secrets replicated to the RODC at any point in time. It contains separate entries for each secret of each security principal (when a security principal is said to be cached on the RODC, it means that five secrets are replicated to the RODC). The msDS-RevealedList, on the other hand, is a list of currently revealed secrets and their associated users or computers that administrators use to manage the Password replication policy. Unlike msDS-RevealedUsers, msDS-RevealedList contains only one entry for each user or computer.

The msDS-AuthenticatedToAccountList is the list of security principals that attempt to authenticate with the RODC. This list includes accounts whose passwords have not been cached by the RODC and all accounts whose passwords have been cached. This list provides administrators with information about which accounts are using an RODC for authentication requests and therefore might be good candidates to add to the msDS-Reveal-OnDemandGroup attribute (the Allowed List).
noteNote
The msDS-AuthenticatedToAccountList contains all accounts that have been granted a service ticket to the RODC. This means that any user who accesses a resource on the RODC will be added to this list. You should not use this list as a conclusive reference to decide which accounts to add to the Allowed List. Instead, carefully review the list and use it only to help you understand which accounts might be candidates to add to the Allowed List.

It is possible to have users in the msDS-RevealedList that are not in the msDS-AuthenticatedToAccountList. Accounts whose passwords are prepopulated on the RODC are not going to appear in the msDS-AuthenticatedToAccountList, but they will be in the msDS-RevealedList. This could also happen if you clear the msDS-AuthenticatedToAccountList by using repadmin /prp. For more information about prepoulating passwords, see Prepopulating the password cache for an RODC. For more information about clearing the msDS-AuthenticatedToAccountList, see Clearing the authenticated accounts list.

Key points for authentication through an RODC

This section covers some of the important points about how authentication works with an RODC. For a step-by-step description of how authentication occurs with an RODC, see How the authentication process works on an RODC.

If only user accounts are cached on an RODC in a particular site, users will not be able to log on using computers in that site when the RODC is unable to contact a writeable domain controller running Windows Server 2008.

All credentials for user, computer, and service accounts that should be cached must be specifically allowed by the PRP. For the RODC to locally authenticate the credentials of any account, those credentials must already be cached on the RODC.

Regardless of the PRP, the RODC attempts to cache accounts that are successfully authenticated. The PRP is enforced by the writeable domain controller running Windows Server 2008, which either allows or denies the caching of account credentials on the RODC.

RODCs are advertised as KDCs for the sites in which they are configured. RODCs use different krbtgt accounts than the KDCs on writable domain controllers for encrypting or signing TGTs. This provides cryptographic isolation between KDCs running on RODCs in different sites; a compromised RODC is therefore prevented from issuing service tickets to resources in other sites. Writable Windows Server 2008 domain controllers contain credentials for all accounts, including the credentials of the krbtgt accounts of the RODCs.

By limiting the caching of credentials on RODCs, the exposure of domain accounts is limited in the event that an RODC is compromised. In the event that an RODC is stolen or otherwise compromised, the accounts that were cached on that RODC are the only accounts that can be potentially compromised.

Active Directory Maximum Limits - Scalability

Active Directory Maximum Limits - Scalability

Updated: April 27, 2009

Applies To: Windows Server 2000, Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2, Windows Server 2008

This topic describes Active Director scalability and other limitations, as well as recommendations that apply when you are designing or implementing an Active Directory infrastructure. These limitations include the following:

• Maximum Number of Objects
  
  
• Maximum Number of Security Identifiers
  
  
• Group Memberships for Security Principals
  
  
• FQDN Length Limitations
  
  
• File Name Length Limitations
  
  
• Additional Name Length Limitations
  
  
• Maximum Number of GPOs Applied
  
  
• Trust Limitations
  
  
• Maximum Number of Accounts per LDAP Transaction
  
  
• Recommended Maximum Number of Users in a Group
  
  
• Recommended Maximum Number of Domains in a Forest
  
  
• Recommended Maximum Number of Domain Controllers in a Domain
  
  
• Recommended Maximum Kerberos Settings
  
  

Maximum Number of Objects

Each domain controller in an Active Directory forest can create a little bit less than 2.15 billion objects during its lifetime.

Each Active Directory domain controller has a unique identifier that is specific to the individual domain controller. These identifiers, which are called Distinguished Name Tags (DNTs), are not replicated or otherwise visible to other domain controllers. The range of values for DNTs is from 0 through 2,147,483,393 (231 minus 255). As objects are created on a domain controller, a unique value is used. A DNT is not reused when an object is deleted. Therefore, domain controllers are limited to creating approximately 2 billion objects (including objects that are created through replication). This limit applies to the aggregate of all objects from all partitions (domain NC, configuration, schema, and any application directory partitions) that are hosted on the domain controller.

Because new domain controllers start with low initial DNT values (typically, anywhere from 100 up to 2,000), it may be possible to work around the domain controller lifetime creation limit—assuming, of course, that the domain is currently maintaining less than 2 billion objects. For example, if the lifetime creation limit is reached because approximately 2 billion objects are created, but 500 million objects are removed from the domain (for example, deleted and then permanently removed from the database through the garbage collection process), installing a new domain controller and allowing it to replicate the remaining objects from the existing domain controllers is a potential workaround. However, it is important that the new domain controller receives the objects through replication and that such domain controllers not be promoted with the Install from Media (IFM) option. Domain controllers that are installed with IFM inherit the DNT values from the domain controller that was used to create the IFM backup.

At the database level, the error that occurs when the DNT limit is reached is “Error: Add: Operations Error. <1> Server error: 000020EF: SvcErr: DSID-0208044C, problem 5012 (DIR_ERROR), data -1076.”

Maximum Number of Security Identifiers

There is a limit of approximately 1 billion security identifiers (SIDs) over the life of a domain. This limit is due to the size of the global relative identifier (RID) pool of 30 bits that makes each SID (that is assigned to user, group, and computer accounts) in a domain unique. The actual limit is 230 or 1,073,741,823 RIDs. Because RIDs are not reused—even if security principals are deleted—the maximum limit applies, even if there are less than 1 billion security principals in the domain.

Note
RIDs are assigned in blocks of 500 by default from the domain controller that holds the RID operations master role in each domain. If a domain controller is demoted, the unused RIDs that were allocated to the domain controller are not returned to the global RID pool and are therefore no longer available for use in the domain.

When all the available RIDs are assigned for a domain, the Directory Service log in the Application and Service Logs of Event Viewer also displays Event ID 16644 from an event log source of the Security Accounts Manager (SAM) that reads “The maximum domain account identifier value has been reached. No further account-identifier pools can be allocated to domain controllers in this domain.” If you run Dcdiag when all the available RIDs are assigned for a domain, you see the error message “The DS has corrupt data: rIDAvailablePool value is not valid.”

A partial work-around to this limitation is to create an additional domain to hold accounts and then migrate accounts to the new domain. However, you must create a trust relationship to migrate accounts in advance of reaching the limit. Creating a trust requires the creation of a security principal, which is also known as a trust user account. For more information about this limit, see articles 316201 (http://go.microsoft.com/fwlink/?LinkID=115211) and 305475 (http://go.microsoft.com/fwlink/?LinkId=115212) in the Microsoft Knowledge Base.

Note

The Active Directory database does not set limits on the number of objects in a container, such as organizational units (OUs). You might experience limits when you work with multiple thousands of objects. These limits are configured to help provide a certain level of application or service availability. For example, the Active Directory Users and Computers snap-in is configured by default to display a maximum of 2,000 objects per container. You can adjust this value by using the Filter Options settings on the View menu. There are also adjustable Lightweight Directory Access Protocol (LDAP) policies that are set by default to improve domain controller performance. These policies are described in article 315071 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkID=135481).

Group Memberships for Security Principals

Security principals (that is, user, group, and computer accounts) can be members of a maximum of approximately 1,015 groups. This limitation is due to the size limit for the access token that is created for each security principal. For more information, see article 328889 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkID=115213). For a detailed discussion of access token limitations, see Addressing Problems Due to Access Token Limitation (http://go.microsoft.com/fwlink/?LinkId=146571).

FQDN Length Limitations

Fully qualified domain names (FQDNs) in Active Directory cannot exceed 64 characters in total length, including hyphens and periods (.). For example, the following host name has 65 characters; therefore, it is not valid in an Active Directory domain:

server10.branch-15.southaz.westernregion.northamerica.contoso.com

This is an important limitation to keep in mind when you name domains. This limitation is due to the MAX_PATH length of 260 characters that the Win32 application programming interfaces (APIs) define, in combination with the way in which Group Policy objects (GPOs) are stored in the SYSVOL share. For more information, see article 245809 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkID=115219). For more information about naming limitations, see article 909264 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkID=106629).

File Name Length Limitations

The file system that Windows operating systems use limits the length of file names—including the path to the file name—to 260 characters. This limitation applies also to physical files that Active Directory components use, such as SYSVOL and database file paths. When you are determining where to place your SYSVOL and database files during Active Directory installation, avoid nested folder structures that might make the full file path to the SYSVOL folder longer than 260 characters. For more information, see article 245809 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkId=115219).

Additional Name Length Limitations

There are additional limitations regarding name lengths in Active Directory. The following limits are described in article 909264 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkID=106629):

• NetBIOS computer and domain names are limited to 15 characters.
  
  
• Domain Name System (DNS) host names are limited to 24 characters.
  
  
• OU names are limited to 64 characters.
  
  

Name Length Limits from the Schema

Default limits on attribute names for Active Directory objects that are imposed by the schema include the following. These items provide examples of schema-limited name attributes:

• Display names are limited to 256 characters. For more information, see Display-Name Attribute (http://go.microsoft.com/fwlink/?LinkId=153705).
  
  
• Common names are limited to 64 characters. For more information, see Common-Name Attribute (http://go.microsoft.com/fwlink/?LinkId=153706).
  
  
• The SAM-Account-Name attribute (also known as the pre–Windows 2000 user logon name) is limited to 256 characters in the schema. However, for the purpose of backward compatibility the limit is 20 characters. For more information, see SAM-Account-Name Attribute (http://go.microsoft.com/fwlink/?LinkId=153707).
  
  

Name Length Limitations for LDAP Simple Bind Operations

During binds to the directory, simple LDAP bind operations limit the distinguished name (also known as DN) of the user to 255 total characters. If you attempt a simple LDAP bind with more than 255 characters, you might experience authentication errors, such as the following:

Error <49>: ldap_simple_bind_s() failed: Invalid Credentials

Server error: 80090308: LdapErr: DSID-0C0903AA, comment: AcceptSecurityContext error, data 57, v1771

Error 0x80090308 The token supplied to the function is invalid

You can avoid this issue by ensuring that the applications, scripts, and utilities that attempt to bind to your directory use secure LDAP binds. You can also avoid this issue by reducing the depth of the OU structure or the length of the OU names. For example, the following distinguished name is 261 characters:

CN=BobKelly,OU=CorporateVicePresidents,OU=CorporateOfficers,OU=ViewOfPugetSoundOffices,OU=TopFloor,OU=Building1557,OU=CorporateCampus,OU=Redmond,OU=Washington,OU=NorthWestern,OU=UnitedStatesOfAmerica,OU=NorthAmerica,DC=BusinessGroup,DC=humongousinsurance,DC=com

If the OU named CorporateVicePresidents is shortened to CVP, the distinguished name for the user account BobKelly is only 242 characters.

Maximum Number of GPOs Applied

There is a limit of 999 Group Policy objects (GPOs) that you can apply to a user account or computer account. This does not mean that the total number of policy settings on the system is limited to 999. Rather, a single user or computer will not be able to process more than 999 GPOs. This limit exists for performance reasons.

Trust Limitations

Trust limitations arise from the number of trusted domain objects (TDOs), the length of trust paths, and the ability of clients to discover available trusts. Limitations that apply include the following:

• Kerberos clients can traverse a maximum of 10 trust links to locate a requested resource in another domain. If the trust path between the domains exceeds this limit, the attempt to access the domain fails.
  
  
• When a client searches out a trust path, the search is limited to the trusts that are established directly with a domain and the trusts that are transitive within a forest.
  
  
• Previous testing shows that the increased time to complete TDO-related operations, such as authentication across domains, deteriorates performance noticeably if the Active Directory implementation in an organization contains more than 2,400 TDOs.
  
  

For more information about trust limitations, see “Practical Limitations of Trusts” in How Domain and Forest Trusts Work (http://go.microsoft.com/fwlink/?LinkID=35356).

Maximum Number of Accounts per LDAP Transaction

When you write scripts or applications that perform LDAP transactions, the recommended limit is to perform no more than 5,000 operations per LDAP transaction. An LDAP transaction is a group of directory operations (such as add, delete, and modify) that are treated as one unit. If your script or application performs more than 5,000 operations in a single LDAP transaction, you are at risk of running into resource limits and an operational time-out. If that happens, all the operations (changes, additions, and modifications) in the transaction are rolled back, which means that you lose all those changes.

As an example, if you are using Active Directory Service Interfaces (ADSI) to write a script, the SetInfo method completes a transaction. For more information about ADSI Methods, see Active Directory Service Interfaces (http://go.microsoft.com/fwlink/?LinkID=4487).

As another example, when you use the System.DirectoryServices (S.DS) namespace in the Microsoft .Net Framework, the DirectoryEntry.CommitChanges method completes an LDAP transaction. For more information about the DirectoryEntry.CommitChanges method, see DirectoryEntry.CommitChanges () (http://go.microsoft.com/fwlink/?LinkId=115220).

Note
Regardless of the method that you use for LDAP transactions, you should plan to send less than 5,000 directory operations in a single transaction. To learn more about the LDAP data structure that commits changes, see LDAPMod (http://go.microsoft.com/fwlink/?LinkId=115221).

Recommended Maximum Number of Users in a Group

For Windows 2000 Active Directory environments, the recommended maximum number of members in a group is 5,000. This recommendation is based on the number of concurrent atomic changes that can be committed in a single database transaction.

Starting with Windows Server 2003, the ability to replicate discrete changes to linked multivalued properties was introduced as a technology called Linked Value Replication (LVR). To enable LVR, you must increase the forest functional level to at least Windows Server 2003 interim. Increasing the forest functional level changes the way that group membership (and other linked multivalued attributes) is stored in the database and replicated between domain controllers. This allows the number of group memberships to exceed the former recommended limit of 5,000 for Windows 2000 or Windows Server 2003 at a forest functional level of Windows 2000.

So far, testing in this area has yet to reveal any new recommended limits to the number of members in a group or any other linked multivalued attribute. Production environments have been reported to exceed 4 million members, and Microsoft scalability testing reached 500 million members.

Important

Increasing the forest functional level to Windows Server 2003 interim or higher does not modify the way that existing group members are stored or replicated. To do that, you must remove the members that were added to the group before the forest functional level was increased to Windows Server 2003 and then add them back again to the appropriate groups. Any group members that you either add or remove after the forest functional level is increased will be LVR enabled, even if the group contains other members that are not LVR enabled. For more information about linked attributes, see Linked Attributes (http://go.microsoft.com/fwlink/?LinkId=142909). For more information about the replication process, see How the Active Directory Replication Model Works (http://go.microsoft.com/fwlink/?LinkId=142908).

Recommended Maximum Number of Domains in a Forest

For Windows 2000 Server, the recommended maximum number of domains in a forest is 800. For Windows Server 2003, the recommended maximum number of domains when the forest functional level is set to Windows Server 2003 (also known as forest functional level 2) is 1,200. This restriction is a limitation of multivalued, nonlinked attributes in Windows Server 2003. For more information, see “Maximum Database Record Size” in How the Data Store Works (http://go.microsoft.com/fwlink/?LinkId=134791).

Recommended Maximum Number of Domain Controllers in a Domain

Because the File Replication Service (FRS) is used to replicate SYSVOL in a Windows Server 2003 domain, we recommend a limit of 1,200 domain controllers per domain to ensure reliable recovery of SYSVOL.

If any Active Directory domain in your network is expected to exceed 800 domain controllers and those domain controllers are hosting Active Directory–integrated Domain Name System (DNS) zones, review article 267855 in the Microsoft Knowledge Base (http://go.microsoft.com/fwlink/?LinkId=115222).

For more information about FRS limitations, see the FRS Technical Reference (http://go.microsoft.com/fwlink/?LinkId=115302).

Recommended Maximum Kerberos Settings

The maximum recommended size for a Kerberos ticket is 65,535 bytes, which is configured through the MaxTokenSize REG_DWORD value in the registry (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Lsa\Kerberos\Parameters). Increasing this value from the default may cause errors, particularly when Web browsers or Web servers are used. For additional information about Kerberos tickets, including error conditions that can occur when Kerberos ticket size limits are set too low or too high, see Additional Resources for Troubleshooting Kerberos (http://go.microsoft.com/fwlink/

Deploying Windows Server 2008 with System Center

http://technet.microsoft.com/en-us/magazine/2008.03.deployment.aspx

Deploying Windows Server 2008 with System Center

Tim Mintner

At a Glance:

• Configuration Manager deployment features
• Creating and customizing a server task sequence
• Adding server roles
• Setting computer-specific variables

With the release of System Center Configuration Manager 2007, server administrators can now take advantage of the same operating system deployment tools that client administrators have been able to use for several years. In the past, server administrators often performed manual installations of Windows Server® using the CD or DVD, then spent hours configuring the server. Some administrators went a step further and built unattended setup routines by creating an unattend.txt file and perhaps using Remote Installation Services (RIS) to automate the install process to avoid having to be physically present at the server console. More advanced administrators took advantage of Automated Deployment Services (ADS) for Windows Server 2003 to completely automate the entire server build process. Now, with Windows Server 2008, the installation process for servers has substantially changed for the first time since Windows NT® 4.0.

Windows Server 2008 deployment uses the same underlying deployment tools and technologies as Windows Vista®. Because of this change, the tools that server administrators have used in the past will need to be updated or replaced. RIS has been replaced by Windows® Deployment Services (WDS), and ADS doesn't support Windows Server 2008 deployment. For more information about the technologies and tools that have changed with server and client deployment, see "10 Things You Need to Know about Deploying Windows Vista" at technetmagazine.com/ issues/2006/11/Deployment.

Since the underlying technologies for deploying Windows Server 2008 and Windows Vista are the same, wouldn't it be great if you could use the same tools and leverage the same knowledge to deploy both? System Center Configuration Manager and Microsoft® Deployment now provide that integrated toolset. This article will describe how you can use Configuration Manager along with Microsoft Deployment to start rolling out Windows Server 2008.

OS Deployment with Configuration Manager

Before beginning to deploy Windows Server 2008, let's review the OS deployment features of Configuration Manager. When you launch the Configuration Manager Console and go to Computer Management, you will notice a new landing area for Operating System Deployment, as shown in Figure 1.

Figure 1 The Operating System Deployment page (Click the image for a larger view)

On this page, you can view a quick summary of the operating system deployments that have occurred in your environment, and you can navigate to other Operating System Deployment nodes, such as Manage Task Sequences and Manage Boot Images. You'll find a list of Web Reports for viewing the status of deployments and the health of your deployment environment. There is also a quick help reference under Resources that will link you to the help documentation for operating system deployment.

If you look under the nodes in the navigation pane, you can see all of the items that must be configured to perform an OS deployment. Here is a summary of these items:

Boot Images Contains a list of boot images based on Windows PE 2.0 that will be used during the deployment process.Computer Associations Primarily used for client deployments to map an existing computer to a new machine so that User State can be managed securely. It also contains a wizard to import unknown computer accounts into the Configuration Manager database so that it is possible to deploy bare metal servers.

Operating System Images Contains a list of packages that hold customized Windows Imaging Format (WIM) images for server and client deployment.

Operating System Install Packages Holds packages that contain the full set of source files for an OS deployment, such as the source files for Windows Server 2008.

Task Sequences Contains multiple steps, each of which define the command-line actions that will run without user interaction. Task Sequences are the driving engine of the operating system deployment process and can provide all of the steps needed to deploy and configure an operating system.

Drivers A central repository for managing all of the drivers needed for the various models of server and client computers.

Driver Packages Contains one or more sets of drivers that can be distributed to Configuration Manager Distribution Points and are used during the deployment of server or client computers.

Now that we have a basic understanding of Configuration Manager's Operating System Deployment features, let's gather all of the pieces we need to perform a Windows Server 2008 deployment.

Getting Ready to Deploy Windows Server 2008

What Is Microsoft Deployment?

Microsoft Deployment is the next version of Business Desktop Deployment (BDD) 2007. It brings together the tools and processes required for both desktop and server deployment into a common deployment console and collection of guidance. The product adds new deployment and task sequencing capabilities for desktops and servers using System Center Configuration Manager 2007.

Microsoft Deployment is available at the Microsoft Download Center, and guidance material can be read online in the Desktop Deployment and Server Deployment TechCenters on Microsoft TechNet. For more information and links to these destinations and other related content, visit microsoft.com/deployment.

In order to deploy Windows Server 2008 with Configuration Manager, you need the following items:

Microsoft Deployment Toolkit (MDT) Provides tools and best practices documentation for deploying server and client operating systems. It integrates directly with the Configuration Manager Console to streamline the deployment process. You can download the Microsoft Deployment Toolkit from microsoft.com/deployment.

Custom Boot Image Configuration Manager provides 32-bit and 64-bit boot images that are based on Windows PE 2.0 and includes support for VBScript, Windows Management Instrumentation (WMI), and HTML applications (HTAs). However, if you want your deployment process to request information from a separate SQL Server® database, you will need a custom boot image that has ADO support.

Operating System Install Package Contains the source files from the Windows Server 2008 DVD.

MDT Package Contains all of the scripts and supporting files needed for the Microsoft Deployment Toolkit.

Configuration Manager Client Package Contains the installation files for the Configuration Manager client.

Settings Package Contains the unattend.xml file used for an automated installation of Windows Server 2008 as well as the customsettings.ini file used with the Microsoft Deployment Toolkit.

Sysprep Package Used only when deploying Windows Server 2003 or Windows XP and provides the sysprep files that are needed to prepare a computer to capture an operating system image.

Drivers Contains all of the drivers needed for specific models of servers.

Network shares for Package Sources and Captured WIMs The Universal Naming Convention (UNC) locations where the packages listed above, along with the customized WIM image, will be stored.

It may seem like a lot of work is necessary in order to create all of these packages. The good news is that with the Microsoft Deployment Toolkit, one wizard will create all of them for you.

In order to use the Microsoft Deployment Toolkit with Configuration Manager, you must install it on the same computer as the Configuration Manager management console. After you do so, go to Start | All Programs | Microsoft Deployment Toolkit and choose Configure ConfigMgr Integration, then specify the name of your Configuration Manager Site Server and the Site code and click on Next. This adds extensions to the Configuration Manager Console provided by the Microsoft Deployment Toolkit. Now when you launch the

Configuration Manager Console and right-click on Task Sequences, you will be able to see a new option, as shown in Figure 2.

Figure 2 Import Microsoft Deployment Task Sequence (Click the image for a larger view)

Choose Import Microsoft Deployment Task Sequence and follow the steps below to create the necessary packages and the Windows Server 2008 Task Sequence:

1. On the Choose Template Screen, select Server Task Sequence, and then click Next.
2. Provide a Task Sequence Name and comments describing the task sequence, and then click Next.
3. Fill in the details for joining a domain or a workgroup, including user account credentials for joining the server to the domain. Fill in your organizational information and product key, and provide a UNC path and file name for the custom WIM image that will be captured. Provide user credentials for connecting to the network share that will store the WIM file, and click Next.
4. On the Boot Image screen, choose to create a new boot image package and provide a network location to use as the package source directory for the boot image package, and click Next.
5. Provide a package name, version information, and comments for the Boot Image package, and click Next.
6. Choose a platform (x86 or x64), ADO support, any optional fonts you need, a custom background for the boot image if needed, and any extra folders to include in the Windows PE image, and click Next.
7. On the MDT Package screen, choose to Create a new Microsoft Deployment Toolkit Files Package, provide a UNC path to use as the package source, and click Next.
8. Provide a name, version, language, manufacturer, and comments for the MDT package, and click Next.
9. For the OS Image, choose to Create a new OS Install Package, provide the path to the Windows Server 2008 source files and a UNC location to use as the package source directory, and click Next.
10. For the Client Package, choose to Create a new Configuration Manager client package, and click Next.
11. For the Settings Package, choose to Create a new Settings Package and provide a UNC location to use as a package source for the Settings Package, and click Next.
12. For the Sysprep Package, choose No Sysprep Files required, and click Next.

Now the wizard will create the boot image and all of the packages. If you expand Packages, Boot Images, Operating System Install Packages, and Task sequences, you will be able to see all of the packages and the task sequence that were created. After all of these packages are created, they should be deployed to Distribution Points.

In addition to these packages, you'll often need to add drivers for specific server hardware. You do this by adding drivers to the Configuration Manager driver store and creating a Driver Package that will be used during the deployment.

To import drivers into the Driver Catalog and create a Driver Package, go to the Configuration Manager Console, right-click on Drivers, and select Import. Choose to import all drivers in the specified UNC path, then type a UNC path that contains all of the drivers you have gathered for your specific server models. Once that is complete, click Next.

On the Drivers Details page, choose which INF files you want imported and optionally assign the drivers to a category. (A category could be based on a specific server model type.) Click Next, then, on the Add Drivers to Package page, click New Package. Specify a name, comment, and a UNC path that will be used as the package source for the Driver Package, and click OK. Choose Update distribution points when finished and click Next.

On the Add Driver to Boot Images page, choose the Boot Image you created previously and check the box for Update distribution points when finished. Click Next, then, on the summary page, click Next again to complete the wizard, import the drivers, and create the Driver Package.

Editing the Task Sequence

Now that you have finished creating all of the necessary packages and the task sequence to install Windows Server 2008, you will probably want to customize several of the actions in the default task sequence. To modify the task sequence, right-click it and choose Edit. The Microsoft Deployment Server task sequence template will then be displayed, as in Figure 3.

Figure 3 You can customize the default task sequence (Click the image for a larger view)

At a high level, a task sequence is a series of command-line items known as tasks that each perform specific operations. Each task may have specific properties that can be configured and may also have conditions set on the Options tab that evaluate whether specific tasks should be executed. For example, the first task in the task sequence has conditions set as shown in Figure 4.

Figure 4 You can disable a task or set conditions for it in the Options tab (Click the image for a larger view)

In this example, the task is disabled by default because the "Disable this step" checkbox has been checked. If the task were enabled, it would only run based on the conditions that are currently specified.

A few of the more common tasks that you may need to modify before deploying Windows Server 2008 include Format and Partition Disk, Validate, Apply Operating System Image, and Apply Network Settings.

The Format and Partition Disk task lets you define how you want to create the disk partition structure for your server deployments. The default setting creates one partition that uses all of the space on the first disk. You may not want to deploy your servers with this configuration, so you can change this setting to specify the disk layout that you want to use.

The Validate task allows you to check for some basic requirements such as memory and processor speed. If, for example, your company standard for server deployments is 2GB of memory, you could set that as a requirement, and the installation will not continue if the server does not meet that requirement.

The Apply Operating System Image task allows you to configure the specific image to deploy. For example, when using source files for Windows Server 2008, you have the option of deploying Server Standard, Server Enterprise, Server Datacenter, Server Standard Core, Server Enterprise Core, and Server Datacenter Core. You will need to choose the appropriate image to use, and this depends on which version of Windows Server 2008 you want to deploy.

The Apply Network Settings task lets you configure static IP addresses for your network cards as well as change the settings to join a domain or workgroup. Although it is possible to set a static IP address using this task, doing so would make this task sequence only functional for one server. Later, you will see how you can set static IP addresses with variables so you can use a single task sequence for multiple servers.

Installing and Configuring Server Roles

So far you have seen how you can modify the task sequence to configure items related to the installation of the operating system. With the Microsoft Deployment Toolkit, however, you are also given the opportunity to install and configure server roles. For example, you can configure a task sequence to deploy Windows Server 2008 to a branch office server that will run a read-only domain controller and a file server.

To do this successfully, in the task sequence editor, navigate to the Install Software task and choose Add | MDT | Install Roles and Features. Then, in the newly created Install Roles and Features task, check both Active Directory Domain Controller and File Server, as shown in Figure 5.

Figure 5 Installing roles and features (Click the image for a larger view)

Now you need to configure the settings for the read-only domain controller. In the task sequence editor, choose Add | MDT | Configure ADDS. In the newly created Configure ADDS task, choose to create a New read-only domain controller replica, and specify values for the following properties:

• Existing domain DNS name
• Replication source domain controller
• Account
• Recovery (safe mode) password

Working with Variables

It's important for you to understand that one of the most powerful features that task sequences offer users is the ability to set almost any property in the task sequence dynamically as a variable during deployment. Configuration Manager and Microsoft Deployment both provide several mechanisms to set and use variables.

Configuration Manager allows you to set the variables as a Computer variable, a Collection variable, or directly inside of the task sequence. Microsoft Deployment allows you to set variables through the customsettings.ini file, a back-end database, or a Web service. You'll find a list of variables that can be set at technet.microsoft.com/bb632442.aspx.

Let's use the example of setting a static IP address on a particular server. Earlier in the article you saw that you could set the static IP address directly inside the task sequence in the Apply Network Settings task. This is not the most ideal practice, however, because it makes that task sequence useful only for a specific server.

What you want to do instead is leave the task sequence alone and set the IP address through a variable. Here's the step-by-step process of how to set the static IP address as a Computer variable:

1. In the Configuration Manager console, navigate to System Center Configuration Manager | Site Database | Computer Management | Collections.
2. To assign a per-computer variable to a computer, locate and expand the collection the computer belongs to, right-click the computer, click Properties, and then click the Variables tab.
3. To specify custom variables and their associated values, click the New icon to open the Variable dialog box.
4. In the Variable dialog box, it is necessary to specify a name for the variable and whether this variable will be visible in the Configuration Manager 2007 console. For a static IP address, you would add the following variables:

• OSDAdapter0IPAddressList
• OSDAdapter0SubnetMask
• OSDAdapter0Gateways
• OSDAdapter0DNSServerList

The configured variables should resemble those in Figure 6.

Figure 6 Using computer variables to set a static IP address (Click the image for a larger view)

Deploying the Task Sequence

Now that you have the task sequence fully configured and have set up your variables, you are ready to deploy Windows Server 2008. Configuration Manager offers several mechanisms for deploying an operating system, such as Pre-Boot eXecution Environment (PXE), task sequence bootable media, standalone media, and through a standard advertisement for existing machines.

For simplicity's sake, I'll outline how to create a task sequence for bootable media. In the Configuration Manager console, navigate to Task Sequences, then choose Create Task Sequence Media from the Actions menu. On the Select Media Type page, choose Bootable Media and click Next. On the Media Type page, specify a CD as the type of media and a name for the media file. On the Security page, you can specify a password to protect the media or a self-signed certificate. Next you specify the boot image. Once that has been completed, you will go to the Confirmation page, where you will click Finish. For detailed instructions on how to deploy using this and other mechanisms, refer to the documentation at technet.microsoft.com/bb681029.aspx.

Wrapping Up

In this article, you have seen how to use System Center Configuration Manager and Microsoft Deployment to deploy Windows Server 2008, add roles such as a File Server and Domain Controller, set computer specific variables, and deploy the operating system using Task Sequence Bootable media. While actual server deployments can be much more complex, this article should help you get started in unifying your server and client deployment tools

AD DS Fine-Grained Password and Account Lockout Policy Step-by-Step Guide

http://technet.microsoft.com/en-us/library/cc770842(WS.10).aspx

This step-by-step guide provides instructions for configuring and applying fine-grained password and account lockout policies for different sets of users in Windows Server® 2008 domains.

In Microsoft® Windows® 2000 and Windows Server 2003 Active Directory domains, you could apply only one password and account lockout policy, which is specified in the domain's Default Domain Policy, to all users in the domain. As a result, if you wanted different password and account lockout settings for different sets of users, you had to either create a password filter or deploy multiple domains. Both options were costly for different reasons.

In Windows Server 2008, you can use fine-grained password policies to specify multiple password policies and apply different password restrictions and account lockout policies to different sets of users within a single domain. For example, to increase the security of privileged accounts, you can apply stricter settings to the privileged accounts and then apply less strict settings to the accounts of other users. Or in some cases, you may want to apply a special password policy for accounts whose passwords are synchronized with other data sources.

To store fine-grained password policies, Windows Server 2008 includes two new object classes in the Active Directory Domain Services (AD DS) schema:

• Password Settings Container
  
  
• Password Settings
  
  

The Password Settings Container (PSC) object class is created by default under the System container in the domain. It stores the Password Settings objects (PSOs) for that domain. You cannot rename, move, or delete this container.

For more information, see Appendix A: Fine-Grained Password and Account Lockout Policy Review.

Who should use this guide?

This guide is intended for the following audiences:

• Information technology (IT) planners and analysts who are evaluating the product from a technical perspective
  
  
• Enterprise IT planners and designers for organizations
  
  
• Administrator or managers who are responsible for IT security
  
  

Scenario overview

Define your organizational structure

Before you configure fine-grained password and account lockout policies, define your organizational structure by creating necessary groups and adding or moving users to or between the groups. It is important to consider the unique nature of your organization when you plan for the most efficient use of the fine-grained password and account lockout policies feature. How many different password policies do you need? A typical scenario might include 3 to 10 PSOs and the following password policies:

• An Administrator password policy with a strict setting (passwords expire, for example, every 14 days)
  
  
• An average user password policy with a setting that is not strict (passwords expire, for example, every 90 days)
  
  
• A service account password policy targeted at service accounts (minimum password length, for example, 32 characters)
  
  

Taking advantage of your existing group structure is equally important. What are its characteristics? Do you have existing Administrators or Users groups? The goal is to shape your group structure so that it maps directly to the desired application of the newly defined fine-grained password and account lockout policies.

PSOs cannot be applied to organizational units (OUs) directly. If your users are organized into OUs, consider creating global security groups that contain the users from these OUs and then applying the newly defined fine-grained password and account lockout policies to them. If you move a user from one OU to another, you must update user memberships in the corresponding global security groups.

Applying PSOs directly to global security groups, as opposed to directly to OUs, provides the following benefits:

• Groups offer better flexibility for managing various sets of users than OUs.
  
  
• Most Active Directory deployments use a systematic group structure to organize their users. Also, by default AD DS in Windows Server 2008 creates various groups for administrative accounts: Domain Admins, Enterprise Admins, Schema Admins, Server Operators, Backup Operators, and others.
  
  
• Group structure offers easier deployment of fine-grained password policies, and you do not have to restructure your organizations’ directories by creating OUs. Modifying an OU hierarchy requires detailed planning, and it increases the risk of introducing unforced errors because it has a significant effect on Group Policy application and access control list (ACL) inheritance.
  
  

Requirements and special considerations for fine-grained password and account lockout policies

• Domain functional level:
  
  

  Important
  For the fine-grained password and account lockout policies to function properly in a given domain, the domain functional level of that domain must be set to Windows Server 2008.

• Permissions: By default, only members of the Domain Admins group can create PSOs. Only members of this group have the Create Child and Delete Child permissions on the Password Settings Container object. In addition, only members of the Domain Admins group have Write Property permissions on the PSO by default. Therefore, only members of the Domain Admins group can apply a PSO to a group or user. You do not have to have permissions on the user object or group object to be able to apply a PSO to it. To apply a PSO to the user object or group object, you must have Write permissions on the PSO object.
  
  
• Permissions delegation: You can delegate Read Property permissions on the default security descriptor of the PSO object in the schema to any other group (such as Help desk personnel or a management application) in the domain or forest. This can also prevent a user from seeing his or her password settings in the directory. The user can read the msDS-ResultantPSO or the msDS-PSOApplied attributes, but these attributes display only the distinguished name of the PSO that applies to the user. The user cannot see the settings within that PSO. For more information, see Appendix C: Group-Based Management of Fine-Grained Password and Account Lockout Policies.
  
  
• Applying fine-grained password policies: Fine-grained password policies apply only to user objects (or inetOrgPerson objects if they are used instead of user objects) and global security groups. They cannot be applied to Computer objects.
  
  

  Note
  Because fine-grained password policies apply only to user objects, they do not affect password reset intervals for managed service accounts. For more information about managed service accounts, see Service Accounts Step-by-Step Guide (http://go.microsoft.com/fwlink/?LinkID=134695).

• Password filters : Fine-grained password policies do not interfere with custom password filters that you might use in the same domain. Organizations that have deployed custom password filters to domain controllers running Windows 2000 or Windows Server 2003 can continue to use those password filters to enforce additional restrictions for passwords.
  
  
• Custom PSCs: In addition to the default PSC, administrators can create their own custom PSCs under the System container. However, this action is not recommended because the PSOs that are held in these custom PSCs are not taken into consideration by the Resultant Set of Policy logic.
  
  
• Exceptional PSOs: If you want a certain group member to conform to a policy that is different from the policy that is assigned to the entire group, you can assign the exceptional PSO directly to that particular user. If you apply a PSO directly to the user (that is, if you apply it to the group that the user is a member of), it takes precedence over all implicit PSOs that might be linked to it when msDS-ResultantPSO for that user is being determined. However, if there are two or more exceptional PSOs that are applied directly to the user object (this is not recommended), the exceptional PSO with the smallest globally unique identifier (GUID) takes precedence.
  
  
• Password complexity errors on Windows XP® client computers: When a user to whom an FGPP applies attempts to change his or her password on a client computer that is running the Windows XP operating system, an error message appears, informing the user that the new password does not conform to the settings that are defined in the domain policy, instead of informing the user that the new password does not conform to the settings that are defined in the FGPP. The following illustration describes this error message:
  
  

The recommended approach is to ignore this error message and to make sure that the new password matches the minimum password length, password complexity, and password history requirements that are defined in the FGPP.

Steps to configure fine-grained password and account lockout policies

When the group structure of your organization is defined and implemented, you can configure and apply fine-grained password and account lockout policies to users and global security groups. Configuring fine-grained password and account lockout policies involves the following steps:

• Step 1: Create a PSO
  
  
• Step 2: Apply PSOs to Users and Global Security Groups
  
  
• Step 3: Manage a PSO
  
  
• Step 4: View a Resultant PSO for a User or a Global Security Group
  
  

Important

You can also manage fine-grained password and account lockout policies by creating corresponding global security groups for all existing PSOs and by assigning (delegating) appropriate permissions on these global security group objects to the selected users or groups from your organization, for example, support personnel. For more information, see Appendix C: Group-Based Management of Fine-Grained Password and Account Lockout Policies

For more information, see

• Appendix A: Fine-Grained Password and Account Lockout Policy Review
  
  
• Appendix B: PSO Attribute Constraints
  
  
• Appendix C: Group-Based Management of Fine-Grained Password and Account Lockout Policies