Active Directory Domain Services


Let’s look at four enhancements to Active Directory in Windows Server 2008:

  • AD DS auditing enhancements

  • Read-only domain controllers

  • Restartable AD DS

  • Granular password and account lockout policies

There are other improvements as well, including some changes to the user interface for managing Active Directory and also to the Active Directory Installation Wizard. But we’ll focus here on the three enhancements just mentioned, as they’re big gains for many enterprises.

AD DS Auditing Enhancements

The first enhancement we’ll look at is AD DS auditing. In the current platform, Windows Server 2003 R2 (and in Windows Server 2008 also), you can enable a global audit policy called Audit Directory Service Access to log events in the Security event log whenever certain operations are performed on objects stored in Active Directory. Enabling logging of objects in Active Directory is a two-step process. First, you open the Default Domain Controller Policy in Group Policy Object Editor and enable the Audit Directory Service Access global audit policy found under Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy.

image from book

Then you configure the system access control list (SACL) on the object or objects you want to audit. For example, to enable Success auditing for access by Authenticated Users to User objects stored within an organizational unit (OU), you do the following:

  1. Open Active Directory Users and Computers, and make sure Advanced Features is selected from the View menu.

  2. Right-click on the OU you want to audit, and select Properties.

  3. Select the Security tab, and click Advanced to open the Advanced Security Settings for the OU.

  4. Select the Audit tab, and click Add to open the Select User, Computer or Group dialog.

  5. Type Authenticated Users, and click OK. An Auditing Entry dialog opens for the OU.

  6. In the Apply Onto list box, select Descendant User Objects.

  7. Select the Write All Properties check box in the Select column.

    image from book

  8. Click OK to return to Advanced Security Settings for the OU, which should now show the new SACL you configured.

    image from book

  9. Close all dialog boxes by clicking OK as needed.

Now if you go ahead and change a property of one of the user accounts in your OU-for example, by disabling an account-an event should be logged in the Security log with event ID 4662 and source Directory Service Access to indicate that the object was accessed.

image from book

So far, this is the same in Windows Server 2008 as in previous versions of Windows Server. What’s new in Windows Server 2008, however, is that while in previous Windows Server platforms there was only one audit policy (Audit Directory Service Access) that controlled whether auditing of directory service events was enabled or disabled, in Windows Server 2008 this policy has been divided into four different subcategories as follows:

  • Directory Service Access

  • Directory Service Changes

  • Directory Service Replication

  • Detailed Directory Service Replication

One of these subcategories-Directory Service Changes-has been enhanced to provide the ability to audit the following changes to AD DS objects whose SACLs have been configured to enable the objects to be audited:

  • Objects that have had an attribute modified will log the old and new values of this attribute in the Security log.

  • Objects that are newly created will have the values of their attributes at the time of creation logged in the Security log.

  • Objects that are moved from one container to another within a domain will have their old and new locations logged in the Security log.

  • Objects that are undeleted will have the location to which the object has been moved logged in the Security log.

The usefulness of this change should be obvious to administrators concerned about maintaining an audit trail of changes made to Active Directory, and auditing actions like these is an important part of an overall IDA strategy for an organization. For instance, using the Security log and filtering for a particular User object, you can now track in detail all changes to the attributes of that object over the entire lifetime of the object. When you enable Success auditing for the Audit Directory Service Access global audit policy (and this policy has Success auditing enabled for it by default within the Default Domain Controllers Policy), the effect of this is to also enable Success auditing for the first of the four subcategories (Directory Service Access) described earlier, which audits only attempts to access directory objects. If you need to, however, you can selectively enable or disable Success and/or Failure auditing for each of these four auditing subcategories individually by using the Auditpol.exe command-line tool included in Windows Server 2008. For example, if you wanted to enable Success auditing for the second subcategory (Directory Service Changes) so that you can maintain a record of the old and new values of an object’s attribute when the value of that attribute is successfully modified, you can do so by typing auditpol /set /subcategory:“directory service changes” /success:enable at a command prompt on your domain controller. If we do this in the preceding example and then enable the user account we disabled previously, three new directory service audit events are added to the Security log.

image from book

The first (earliest) of these events is 4662, indicating the User object has been accessed, while the second event (5136) records the old value of the attribute modified and the third event (also 5136) records the new value of the attribute. Table 7-1 lists the possible event IDs for Directory Service Changes audit events.

In addition to enabling you to track the history of an object this way, Windows Server 2008 also gives you the option of setting flags in the Active Directory schema to specify which attributes of an object you want to track changes for and which attributes you don’t want to track changes for. This can be very useful because tracking changes to objects can lead to a whole lot of audit events and your Security log can fill up awfully fast.

Table 7-1: Event IDs for Directory Service Changes Audit Events Event ID Meaning
Open table as spreadsheet

Event ID

Meaning

5136

An attribute of the object has been modified.

5137

The object was created.

5138

The object has been undeleted.

5139

The object has been moved within the domain.

Read-Only Domain Controllers

Another new feature of AD DS in Windows Server 2008 is the Read-Only Domain Controller (RODC), a domain controller that hosts a read-only replica of the AD database. The main rationale for RODCs (apart from nostalgia for the BDCs of good old NT4 days) is to provide a solution for branch offices that have inadequate physical security. For example, a corporate headquarters probably has the resources to adequately protect their domain controllers against theft or other physical dangers-at least, they better have such resources. Small branch offices, however, might not have the facilities, budget, or expertise to ensure a domain controller present there would be physically secure. One solution to this problem might be to not have a domain controller at all at your branch office and just have users there authenticate over a WAN link with a domain controller at headquarters. The problem with this approach is if the WAN link is too slow, unreliable, or saturated with other forms of traffic. The result could be unacceptably slow logons for users or difficulty logging on at all. If your WAN link is unsuitable, the other option is to place a domain controller at your branch office and have users there authenticate locally while the DC itself replicates with DCs at headquarters to ensure its directory database is always up to date. The problem with this approach, however, is that domain controllers are the heart and soul of your Windows-based network because they contain all the accounts for all the users and computers on your network. So if the domain controller at your branch office somehow got stolen (perhaps by some clever social engineering like, “Hi, I’ve come to clean your domain controller, can you show me where it is?”), your whole network should be considered compromised and your only viable solution is to flatten everything and rebuild it all from scratch.

And those are the only two solutions today for branch offices using domain controllers running Windows Server 2003-authenticate over the WAN or risk placing a domain controller at your branch office. RDOC, however, solves this dilemma by providing a secure way to have a domain controller at your branch office. The only requirement for using RDOC is that the domain controller that holds the PDC Emulator FSMO role on your network has to be running Windows Server 2008. Once this is the case and you’ve deployed an RDOC at your branch office, changes made to the directory on your normal (writable) domain controllers replicate to the RDOC, but nothing replicates in the opposite direction. That’s because the directory database of a RDOC is read-only, so you can’t write anything to it locally-it has to receive all changes to its database via replication from another (writable) domain controller. (RDOCs can’t replicate with each other either, so there’s no point having more than one RDOC at a given site-plus it could cause inconsistent logon experiences for users if you did do this.) So RDOC replication is completely unidirectional-and this applies to DFS replication traffic as well.

RDOCs also advertise themselves as the Key Distribution Center (KDC) for the branch office where they reside, so they handle all requests for Kerberos tickets from user and computer accounts at the remote site. RDOCs don’t store user or computer credentials in their directory database, however; so when a user at the branch office tries to log on, the RDOC contacts a writable DC at the hub site to request a copy of the user’s credentials. How the hub DC responds to the RDOC’s request depends on how the Password Replication Policy is configured for that RDOC. If the policy says that the user’s credentials can be replicated to the RDOC, the writable DC does this, and the RDOC caches the credentials for future use (until the user’s credentials change). The result of all this is that RDOCs generally have few credentials stored on them. So if an RDOC somehow gets stolen (remember the DC cleaning guy), only those credentials are compromised and replacing them is much less work than rebuilding your entire directory from scratch.

Another feature of RDOCs is that a domain administrator can delegate the local administrator role for an RDOC to an ordinary domain user. This can be very useful for smaller branch offices that have no full-time expert IT person on site. So if you need to load a new driver into your DC at a remote site, you can just give instructions to your “admin” by phone on how to do this. The admin is simply an ordinary user who can follow instructions, and delegating RDOC admin rights to him doesn’t enable him to perform any domain-wide administrative tasks or log on to a writable DC at headquarters-the damage he can do is limited to wrecking only the RDOC.

Let’s hear now from a Microsoft MVP and directory services expert concerning some enhancements that have been made to dcpromo.exe in Windows Server 2008 and how these enhancements relate to deploying RODCs:

image from book
From the Experts: New Active Directory Setup Wizard (dcpromo.exe)

When you want to install Active Directory, you have to use the Active Directory Setup Wizard (dcpromo.exe). It provides you with some possibilities and assumes that you have a proper design written down and you know what you want to accomplish. However, we have received many support calls and questions on the Internet because Active Directory and DNS were not set up in a way that reflects best practices. Considering the vast amount of installations of Active Directory, it’s very clear that it’s far easier to find the Active Directory Installation Wizard on the server operating system than it is to find best practices or good consultancy. Common support issues included having the wrong FSMO-Roles together on the same system, not enough Global Catalog servers, or issues in the DNS-Design that were leading to logons over the WAN lines.

In Windows Server 2008, Microsoft has put a huge effort into changing dcpromo.exe. Now it is reflecting best practices. You get a normal mode if you just want to quickly install Active Directory, and you get an advanced mode if you want to do any special configurations. Dcpromo is leveraging best practices, and it provides a lot of additional tasks. It’s checking the FSMO roles for you, and it recommends whether to automatically move the Infrastructure Master if necessary. It allows you to enable the Global Catalog on a new domain controller. It is checking the DNS infrastructure, and it allows you to automatically create forwarders and delegations. Also, dcpromo enables you to choose your replication partner for the initial replication so that you can make sure to target a specific DC.

In addition, dcpromo supports the new Read Only Domain Controller (RODC) in multiple ways. You are either able to precreate a RODC-Account in your domain and delegate a site admin to join the RODC to the domain, or you are able to fully install the RODC while selecting whether it should also be a Global Catalog server a DNS-server, or both.

Last but not least, dcpromo finally supports unattended installations from the command line without an answer script. Simply run dcpromo /?:unattend to figure out what parameters you have to script the installation of your Windows Server 2008 Active Directory Domain Controller.

–Ulf B. Simon-Weidner

MVP for Windows Server-Directory Services author, consultant, speaker, and trainer

image from book

Finally, because domain controllers often host the DNS Server role as well (because DNS is the naming system used by AD), the RDOCs need a special read-only form of DNS Server running on them also. To learn more about this feature, however, let’s listen to another one of our experts at Microsoft:

image from book
From the Experts: Advanced Considerations for DNS on RODCs in Branch Office Sites

When installing a Windows Server 2008 Read Only Domain Controller (RODC) at a branch office site, using the Active Directory Installation Wizard or the DCPromo command-line tool, you are prompted to specify a DNS domain for the Active Directory domain that you are joining the RODC to during promotion. During this process, you are prompted with DNS Server installation options. A DNS Server is required to locate domain controllers and member computers in an Active Directory domain, at both the hub site and the local branch office site. The default option is to install a DNS Server locally on the RODC, which replicates the existing AD-integrated zone for the domain specified and adds the local IP address in the DNS Server list of the domain controller local DNS Client setting.

As a best practice, Microsoft recommends that client computers have Dynamic DNS updates turned on by default and that DHCP Servers be used to configure the DNS Server list. Similarly for branch office sites, clients should be configured to use Dynamic DNS updates, and you should set the Primary DNS Server or use DHCP to set the DNS Server list to direct clients to the DNS Server running on the RODC.

If there is only one DNS Server and RODC running at the branch office site, Microsoft recommends that client computers also point to a DNS Server running on a domain controller at the hub site. This can be done either by configuring clients with an Alternate DNS Server for the hub-site DNS Server or by configuring DHCP Servers to set the DNS Server list to first the local DNS Server and then the remote DNS Server at the hub site. The DNS Server on the RODC should be the first DNS Server in the list to optimize resolution performance for branch office clients.

In larger branch office scenarios, if setting up two or more RODCs at a site, you are provided the default option to install DNS Server locally on all the RODCs. Within the same site, the RODCs do not replicate directly with each other. The RODCs rely mainly on replication with domain controllers at the hub site during scheduled intervals to refresh local data in the directory. Hence, a branch office DNS Server on an RODC receives updated DNS zone data during the normal replication cycle from a hub-site domain controller connected to the local RODC.

In addition to replication from the hub site, DNS Servers on RODCs also attempt to replicate local data after receiving a client update request. The branch office DNS Server redirects the client to a hub-site DNS Server on a domain controller that is writable and can process the update. Shortly thereafter, it attempts to contact a hub-site domain controller to update its local copy of the data with the changed record. Any other branch office DNS Server on RODCs at the site do not attempt to obtain a local copy of the single record update because they did not receive the original client update request. This mechanism has the advantage of allowing an updated client record to be resolved quickly within the branch office, without necessitating frequent and large replication requests for all domain data from the hub site. If network connectivity is lost, or no domain controller at the hub site is able to provide the updated record data to the DNS Server in the branch office, the record will be available locally only after the next scheduled replication from the hub-site domain controllers, and it will be available to all RODCs at the branch office site.

As a consequence of a DNS Server’s attempt to replicate individual records between replication cycles, if DNS zone data is stored across multiple RODCs, the local branch office records might accumulate some incongruities. To ensure a high level of consistency for DNS data, the recommendation is to configure all client computers at the branch office site with the same DNS Server list-for example, by using DHCP.

If, however, in the more rare case that timely resolution of local branch office client records is absolutely critical, to avoid any inconsistencies for resolution, you can install DNS Servers on all RODCs at the site, but point clients only to a single DNS Server.

–Moon Majumdar

Program Manager, DNS (Server and Client) and DC Locator, Directory and Service Team

image from book

Restartable AD DS

Another new feature of AD DS in Windows Server 2008 is the ability to restart the Active Directory directory services without having to restart your domain controller in Directory Services Restore Mode. In previous versions of Windows Server, when you wanted to do some maintenance task on a domain controller-such as performing offline defragmentation of the directory database or performing an authoritative restore of the Active Directory directory service database-you had to restart your domain controller in Directory Services Restore Mode by pressing F8 during startup and selecting this from the list of startup options. You then logged on to your domain controller by using the local Administrator account specified previously when you ran the Active Directory Installation Wizard (dcpromo.exe) on your machine to promote it from a member server to a domain controller. Once logged on in Directory Services Restore Mode, you could perform maintenance on your domain controller and clients couldn’t authenticate with it during your maintenance window.

Having to reboot a domain controller like this to perform maintenance operations resulted in longer downtime for clients who needed to be authenticated by your domain controller. To reduce this downtime window, AD DS has been re-architected in Windows Server 2008. Instead of rebooting your machine and logging on in Directory Services Restore Mode, you simply stop the Domain Controller service by using the Services snap-in (shown in Figure 7-1) or typing net stop ntds at a command line, perform your maintenance tasks while still logged on as a domain admin, and when you’re finished start this service again using the snap-in or the net start ntds command. Stopping and starting the Domain Controller service like this also has no effect on other services such as the DHCP Server service that might be running on your domain controller.

image from book
Figure 7-1: You can now stop and start the Domain Controller (NTDS) service without rebooting your domain controller and logging on in Directory Services Restore Mode

While domain controllers running previous versions of Windows Server had two Active Directory directory service modes (normal mode and Directory Services Restore Mode), domain controllers running Windows Server 2008 now have three possible modes or states they can be running in:

  • AD DS Started This is the normal state when the NTDS service is running and clients can be authenticated by the domain controller. This state is similar to how AD directory services worked in Windows 2000 Server and Windows Server 2003.

  • Directory Services Restore Mode This state is still available on domain controllers running Windows Server 2008 through the F8 startup options, and it’s unchanged from how it worked in Windows 2000 Server and Windows Server 2003.

  • AD DS Stopped This is the new state for domain controllers running Windows Server 2008. A domain controller running in this state shares characteristics of both a domain controller running in Directory Services Restore Mode and a member server that is joined to a domain. For example, as in Directory Services Restore Mode, a domain controller running in the AD DS Stopped state has its directory database (Ntds.dit) offline. And similar to a domain-joined member server, a domain controller running in this state is still domain-joined, and users can log on interactively or over the network by using another domain controller. But it’s a good idea not to let your domain controller remain in the AD DS Stopped state for an extended period of time because not only will it be unable to service user logon requests, it also will be unable to replicate with other domain controllers on the network.

Granular Password and Account Lockout Policies

New in Beta 3 of Windows Server 2008 is the ability to have multiple password policies and account lockout policies in a domain. To learn about this particular feature, let’s hear from a Microsoft MVP and directory services expert:

image from book
From the Experts: Granular Password Policies in Windows Server 2008

If you want to deploy multiple password policies in your forest, the domain has always been the boundary for this. This was confusing for many customers because you are able to change passwords in every Group Policy Object (GPO). However, remember that password settings (and account lockout settings) are configured in the Computer Settings part of the GPO. They apply only to computer objects, and therefore, to local accounts on those computer objects. An exception to this rule is policies that are linked to the domain head (the top node of the domain). GPOs linked here that hold password settings are the administrative interface for the password and account lockout settings for domain objects. Actually, they are written back to attributes on the domain head object and take effect from there. Domain controllers that receive a password change request compare the settings on the domain head with the password, and they either allow the password change or deny it. So it’s important to understand that password and account lockout settings are maintained on the domain head in Active Directory. You also need to keep in mind that Group Policies are only the administrative interface and that password settings configured in any GPO linked to any other OU or site are applied only to the local user accounts of the computer object to which the policy applies.

So, in the past, password and account lockout settings were limited to the domain and we were able to apply only one setting per domain. If we wanted to have different password policies, we were required to deploy multiple domains.

This has been changed in Windows Server 2008. Active Directory is extended, and the password settings validation on the domain controllers have been extended so that we are able to configure multiple password and account lockout settings for each domain now. How are they administered? Not via GPO-as mentioned before, GPO has been only an administrative interface. So the new fine-grained password policies are configured as new objects in the domain and are linked to either groups or users in the domain.

If you want to experiment with this, simply use ADSIEdit.msc. Expand the Password Settings Container underneath the System Container in the domain, right-click, and select New. You are prompted to fill in the following mandatory attributes, which define password and account lockout policies:

  • msDS-PasswordSettingsPrecendence This attribute is just a virtual number you can make up. (Be sure you leave some space in the numbering for future use.) It defines which password settings take effect if multiple settings apply to the same object (user or group, but settings on the user always take precedence over settings on the group).

    This will usually reflect on the “level” of the settings object. For example, if you have stronger settings, they have a lower value, and if you have higher settings, you’re probably assigning a higher precedence to them.

  • msDS-PasswordReversibleEncryptionEnabled This attribute is Boolean and defines whether you want to store the passwords of the accounts (that is, specify to whom the password settings object applies) in reversible encryption or not. The default and best practice is to set this value to FALSE.

  • msDS-PasswordHistoryLength This setting defines how many old passwords the user cannot reuse again (to prevent the user from changing the password back and forward to the same one or changing it multiple times until he’s able to reuse his old password).

    The domain default is to not allow the last 24 passwords of that user.

  • msDS-PasswordComplexityEnabled This attribute is also a Boolean and defines whether the password needs to be complex (that is, it has at least three of the following character sets applied: lower letters, capital letters, numbers, symbols, or unicode characters).

    The domain default and best practice is to turn it on (TRUE).

  • msDS-MinimumPasswordLength This attribute defines the minimum length of a password in characters. The domain default is seven characters long.

  • msDS-MinimumPasswordAge The msDS-MinimumPasswordAge attribute does just what its name suggests-it defines the minimum age for passwords. The minimum age is necessary to prevent a user from changing her password x amount of times on the same day until she exceeds the Password History limit and can change the password back to the same value as before.

    This is a negative number that you can compile or decompile, using the scripts at http://msdn2.microsoft.com/en-us/library/ms974598.aspx as a guideline. (The domain default is 1 day, which equals -864000000000.)

  • msDS-MaximumPasswordAge This attribute is just the opposite of the previous one. It defines when you have to change your password. It is also a negative number just like the previous one. (The domain default is 42 days, which equals -36288000000000.)

  • msDS-LockoutThreshold Defines how many failed attempts at entering a password a user can have before the user object will be locked. (The domain default is 0, which equals “Don’t lock out accounts after invalid passwords.”)

  • msDS-LockoutObservationWindow This attribute determines at which time the bad password counter should be reset. (The domain default is 6 minutes, which equals -18000000000.)

  • msDS-LockoutDuration This attribute determines how long a password should be locked. (The domain default is 6 minutes, which equals -18000000000.)

    After you create your own password settings object (PSO), you have to link it to a user or group. I recommend, for administrative purposes, always linking it to groups instead of to users. (Otherwise, it will get messy and hard to administer.) To link the PSO to a group or user, you simply change its msDS-PSOAppliesTo attribute to the distinguished name of the group or user (for example, cn=Administrators,cn=Users,dc=example,dc=com). This is a multivalued attribute, so you are able to link the same PSO to multiple groups or users.

    For administrative purposes, there are also two attributes that help you determine which password policies are applied to which users or groups. On the group or user, you will find the msDS-PSOApplied attribute, which is actually the back link of the msDS-PSOAppliesTo attribute and lists all PSOs that are directly linked to this object.

    To help you figure out which PSO is the effective one, there’s the constructed attribute msDS-ResultantPSO, which shows you which PSO is effective for the object in question.

    At the beta stage that is current at the writing of this book, this is a new feature that lacks adequate administrative support in the graphical user interface. However, you are able to administer it easily using ADSIEdit.msc. And Joe Richards, a Directory Services MVP who wrote Active Directory command line tools such as ADFind and ADMod, has created a new command-line utility named PSOMgr.exe, which helps you create and link PSOs. You’ll find it at www.joeware.net.

    –Ulf B. Simon-Weidner

    MVP for Windows Server-Directory Services author, consultant, speaker, and trainer

image from book




Microsoft Windows Server Team - Introducing Windows Server 2008
Introducing Windows Server 2008
ISBN: 0735624216
EAN: 2147483647
Year: 2007
Pages: 138

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net