How Read Only Domain Controllers and DNS works

I was recently asked by a friend of mine how Read-Only Domain Controllers (RODCs) works with DNS, since they can host DNS for Active Directory, so I think it was a good idea with a blog post on how it really works. First of all Windows Server 2008 bring new capabilities to both Active Directory and DNS and many of them are related.

Read-Only Domain Controllers (RODCs) and the Primary Read-Only Zone

When you promote a Read-Only Domain Controller (RODC) and also select it to be a DNS server, it will perform inbound replication of the DNS Zones (Either stored in the applications or domain NCs) as any Writeable Domain Controller. But if you’re familiar with RODC basics you know they never perform outbound replication and the database is mostly read-only (including the DNS records), Windows Server 2008 DNS Introduce a new zone type called the Primary Read-Only Zone. The Administrator of RODC can view contents of DNS but will unable to change it from a RODC.

Read-Only Domain Controllers (RODCs) are not pointing the SOA to them self unlike Writable Domain Controllers

Writable Domain Controllers are always pointing the SOA to them self, because they all host writable copies of Active Directory-Integrated Zones, How ever RODCs doesn’t host writable copies of those and therefore points the SOA to an Writable Domain Controller using the following SOA selection model.

  1. Trying to select a writable domain controller that is running Windows Server 2008 and is published as a NS for the zone
  2. If there are no Windows Server 2008 writable domain controllers that publish a NS for the zone a randomly domain controller will be picked from the NS list.

    Note: The current SOA target DC is maintained separately for each zone and re-selected every 20 minutes (not configurable). The selection algorithm contains a random component to try to spread load between writable domain controllers.

[2] Needs a clarification to another difference, RODCs doesn’t register NS records, so it makes [2] safe from picking any RODC.

DNS Updates for clients having a Read-Only Domain Controller (RODC) as preferred DNS server

When a client attempts a dynamic update, it sends SOA query to its preferred DNS server. Typically, clients are configured to use the DNS server in their branch site as their preferred DNS server. The RODC should read its SOA record and at best effort return a writable Windows Server 2008 domain controller to the client (Using the SOA selection model above), the RODC waits a certain amount of time, as explained below, and then it attempts to replicate the updated DNS record object in Active Directory from the DNS server that it referred the client to through an RSO operation back to the RODC, an RSO operation is an operational attribute named replicateSingleObject that has existed in Active Directory since Windows 2000 and allows replication of a single object by using a LDAP modify operation of the replicateSingleObject attribute, However the replicateSingleObject has been updated in Windows Server 2008 to support replication of secrets to RODCs, More information about the attribute and it’s syntax can be found here: http://msdn.microsoft.com/en-us/library/cc223306(PROT.13).aspx

How Read-Only Domain Controllers perform RSO operations of DNS record updates

For the DNS server on the RODC to perform an RSO operation of the DNS record update, a DNS server that runs Windows Server 2008 must host writeable copies of the zone that contains the record. That Windows Server 2008 DNS server must register a name server (NS) resource record for the zone, with other words [1] must be used in the SOA selection model above.

Note:
The Windows Server 2003 Branch Office Guide recommended restricting name server (NS) record registration to a subset of the available DNS servers. If you followed those guidelines and you do not register at least one writable Windows Server 2008 DNS server as a name server for the zone, the DNS server on the RODC attempts to perform the RSO operation with a DNS server that runs Windows Server 2003 using [2] in the SOA selection model. That operation fails and generates a 4015 Error in the DNS event log of the RODC, and replication of the DNS record update will be delayed until the next scheduled replication cycle and RSO operation cannot be made by the RODC DNS against a Windows Server 2003 Domain Controller.

More specifically how the RSO operation really works, the SOA query triggers the DNS server on the RODC to put an entry in remotePollList, which is an internal queue on each DNS server. The entry includes the following:

  • The object to be replicated
  • The source domain controller to replicate from
  • A time stamp

The time stamp is set to a time in the future that is equal to the current time plus a replication delay. The replication delay is controlled by a registry setting named DsRemoteReplicationDelay. By default, the value of this setting is 30 seconds.

The internal queue (remotePollList) is processed at regular intervals. The queue-processing interval is controlled by a registry setting named DSPollingInterval. By default, the value of the interval is three minutes.

When the DNS server processes the queue, it attempts to replicate only objects whose time stamp is less than current time. Therefore, the delay between the time that the RODC refers the client to an authoritative DNS server and then attempts to replicate in is determined by the following:

  • The next time that the DNS server processes the queue
  • Whether the remote replication delay that is set on the entry in the queue has elapsed

If you use the default values for the registry settings, the amount of time before the RODC attempts to replicate the DNS update is a minimum of 30 seconds and a maximum of 210 seconds.

You can modify the values of these registry settings to reduce the amount of time before the RODC attempts to replicate the DNS update. The minimum value for the DsRemoteReplicationDelay setting is 5 seconds. The minimum value for the DSPollingInterval setting is 30 seconds. If you use the minimum values, the amount of time before the RODC attempts to replicate the DNS update is a minimum of 5 seconds and a maximum of 35 seconds.

Note: Max number of RSO requests per 5 minutes cycle is 300 to prevent Denial of Service attacks

Note: DsPollingInterval controls all Active Directory polling, not just RODC RSO handling. If you change this value, be aware that this change will affect more than just RODC RSO operations. For example, this setting will affect how often the DNS server polls Active Directory for new or updated resource records or DNS zones.

The following table lists some additional registry entries that are related to the RSO operations that are performed for DNS updates on an RODC. These registry entries are stored in the following registry key: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesDNSParameters

Registry entry Minimum value Maximum value Default value
EnableRSOForRODC Either True or False   True
MaximumRodcRsoQueueLength 1 1000000 300
MaximumRodcRsoAttemptsPerCycle 1 1000000 100
DsRemoteReplicationDelay 5 3600 30

 

To modify any of the registry entries that are related to the RSO operations for DNS updates on an RODC, use the Dnscmd.exe command-line tool to set the appropriate parameter.
Example: “dnscmd <server>.<domain>.<com> /Config /DsRemoteReplicationDelay 10”

I think that’s all I can think of for now.

Fine Grain Password Policy Tool 1.0 (2300.0) RTM

Build: FGPP RTM_2300-20081223.0
Branch: FGPP-RTM-branch.
Usage: Production Usage.

 


General Information

 

This build is the final RTM build of the Fine Grain Password Policy Tool. (FGPP RTM_2300-20081223.0) For full release notes see the document “Release notes for Fine Grain Password Policy Tool” included in the package, as well to be released on the website later today, other documentation available with this release are.

 

·         Quick Start Guide for Fine Grain Password Policy Tool

 

·         Windows PowerShell Usage for Fine Grain Password Policy Tool

 

·         Password Policy Samples for Fine Grain Password Policy Tool

 


Acknowledgements


Stanimir Stoyanov,
thanks
for providing the incredible support and your ideas while this piece of software was being written. Especially for the work that was done with the Native Methods. Please have a look at this blog for other projects he has been released http://www.stoyanoff.info

 


Björn Österman, t
hanks for your help and support with the initial design of the Password Policy class.

 


TrueSec Team
, thanks for providing support while this piece of software was being written.

 

Overview of Fine Grain Password Policies in Windows Server 2008:
http://technet2.microsoft.com/windowsserver2008/en/library/056a73ef-5c9e-44d7-acc1-4f0bade6cd751033.mspx

 

Download

Download Fine Grain Password Policy Tool (x86) 1.0.
http://blogs.chrisse.se/files/folders/fgpp/entry51.aspx

Download Fine Grain Password Policy Tool (x64) 1.0.
http://blogs.chrisse.se/files/folders/fgpp/entry50.aspx

 

Quick Start Guide.
http://blogs.chrisse.se/blogs/chrisse/pages/fine-grain-password-policy-tool.aspx

 

System Requirements

Fine Grain Password Policy Tool 1.0 are “Supported” on the following platforms

 

·         Windows Server 2008

·         Windows Server 2008 R2

·         Windows Vista with Service Pack 1 or later

·         Windows 7

·         Windows Server 2003 with Service Pack 1 or later and Windows Server 2003 R2

·         Windows XP Service Pack 2 or later


Prerequisites
Before installing this build, you must have:

Windows Server 2008, Windows Server 2008 R2 and Windows Vista, Windows 7

·         Windows Server 2008 Active Directory Domain.

·         Windows PowerShell installed (for command-line and scripting support)

Windows Server 2003 and Windows XP

·         Microsoft .NET Framework 2.0.

·         Microsoft Management Console 3.0

·         Windows Server 2008 Active Directory Domain.

·         Windows PowerShell installed (for command-line and scripting support)

 
Usage information:

Fine Grain Password Policy Tool Core PowerShell Samples.

FGPP RTM supports the following PowerShell Commands.

Create new Password Policies

New-PasswordPolicy <Name> [-domain <FQDNDomainName>] >] [–server <DCFQDN>] -MaximumPasswordAge <timespan> -MinimumPasswordAge <timespan> -MinimumPasswordLength <PassswordMinLenght> -PasswordComplexityEnabled <$True/$False> -PasswordReversibleEncryptionEnabled <$True/$False> -PasswordSettingsPrecendence <PrecendenceOrder> -PasswordHistoryLength <NumberOfPasswords> -LockoutDuration <timespan> -LockoutObservationWindow <timespan> -LockoutThreshold <int> -AppliesTo *SupportedNameFormats

 


Modify existing Password Policies
Modify-PasswordPolicy <name> [-domain <FQDNDomainName>] >] [–server <DCFQDN>] [-MaximumPasswordAge <timespan>] [-MinimumPasswordAge <timespan>] [-MinimumPasswordLength <PassswordMinLenght>] [-PasswordComplexityEnabled <$True/$False>] [-PasswordReversibleEncryptionEnabled <$True/$False>] [-PasswordSettingsPrecendence <PrecendenceOrder>] [-PasswordHistoryLength <NumberOfPasswords>] [-LockoutDuration <timespan>] [-LockoutObservationWindow <timespan>] [-LockoutThreshold <int>] -AppliesToAdd *SupportedNameFormats -AppliesToRemove *SupportedNameFormats

 


Delete Password Policies
Delete-PasswordPolicy <name> [-domain <FQDNDomainName>] [–server <DCFQDN>] [-all]

 

Reame Password Policies
Rename-PasswordPolicy <name> [-domain <FQDNDomainName>] -NewName <name>

 


Add users and global groups to an existing Password Policy
Add-PasswordPolicy -Name <name> [-domain <FQDNDomainName>] [–server <DCFQDN>] -AppliesTo *SupportedNameFormats

Remove users and global groups to an existing Password Policy
Remove-PasswordPolicy -Name <name> [-domain <FQDNDomainName>] [–server <DCFQDN>] -AppliesTo *SupportedNameFormats [-all]

 

Get the Effective PasswordPolicy for one or more users objects

Get-PasswordPolicyEffective <name> [-domain <FQDNDomainName>] [–server <DCFQDN>]

Export Password Policies

Export-PasswordPolicy <name> <path> [-domain <FQDNDomainName>] [–server <DCFQDN>]


Import Password Policies

Import-PasswordPolicy <name> <path> [-domain <FQDNDomainName>] [–server <DCFQDN>]

————————————————————————————————————————————————————–

*SupportedNameFormats: [DomainUserN, “First LastName”, {4fa050f0-f561-11cf-bdd9-00aa003a77b6}, example.microsoft.com/software/user name, usern@example.microsoft.com, S-1-5-21-397955417-626881126-188441444-501]

 
Fine Grain Password Policy Tool Additional PowerShell Samples.
————————————————————————————————————————————————————–

 

How to use the Get-PasswordPolicy and New-PasswordPolicy to copy an existing PasswordPolicy

 

Note: Any parameter can be used with New-PasswordPolicy override settings from the existing policy.

 

Get-PasswordPolicy <name> [-domain <FQDNDomainName>] | New-PasswordPolicy <Name> [-domain <FQDNDomainName>] [-MaximumPasswordAge <timespan>] [-MinimumPasswordAge <timespan>] [-MinimumPasswordLength <PassswordMinLenght>] [-PasswordComplexityEnabled <$True/$False>] [-PasswordReversibleEncryptionEnabled <$True/$False>] [-PasswordSettingsPrecendence <PrecendenceOrder>] [-PasswordHistoryLength <NumberOfPasswords>] [-LockoutDuration <timespan>] [-LockoutObservationWindow <timespan>] [-LockoutThreshold <int> -AppliesTo * SupportedNameFormats]

 

————————————————————————————————————————————————————–

 

How to check policy compliance for linked users for a one or more Password Policies

foreach ($Policy in Get-PasswordPolicy [<Name>]) { foreach ($Applied in $Policy.AppliesTo) { Get-PasswordPolicyEffective $Applied } }