Posts in category Favorite

AD Trivia: Where does the domain SID come from?

May15
2013 Leave a Comment

Written by Sean Metcalf

When promoting the first Domain Controller for a new domain, the domain SID is the same as the computer SID of the new DC.

The following AD groups are considered “local” to the Domain Controllers:

Administrators
Backup Operators
Print Operators
Server Operators

What’s interesting is that these groups are the local groups from the first DC promoted for the new domain, so the SID matches.

Mark Russinovich states this scenario well in his blog:

As I said earlier, there’s one exception to rule, and that’s DCs themselves. Every Domain has a unique Domain SID that’s the machine SID of the system that became the Domain’s first DC, and all machine SIDs for the Domain’s DCs match the Domain SID. So in some sense, that’s a case where machine SIDs do get referenced by other computers. That means that Domain member computers cannot have the same machine SID as that of the DCs and therefore Domain. However, like member computers, each DC also has a computer account in the Domain, and that’s the identity they have when they authenticate to remote systems.

The really interesting scenario is one where Company A owns Company B & Company C and while the IT shop keeps the domains for each domain separated, they build all the DCs from the same image (but don’t sysprep or change the SID meaning the first DC for each domain has the same machine SID and thus the same domain SID). Company A sells off Company B & Company C. Later on Company B & Company C merge and want to set up AD trusts between them. They can’t because the domains in both Company B & Company C have the same SID and a trust can’t reference its own SID!

Posted in Microsoft Products, Tech, Technical Reference, Troubleshooting - Tagged ComputerSID, DC SID, DomainSID, FirstDomainController

PowerShell and Ambiguous Name Resolution (ANR) Search in Active Directory

May01
2013 Leave a Comment

Written by Sean Metcalf

I was recently asked how to find a user when you have data that may be the SamAccountName or in another attribute. My first thought was leveraging Ambiguous Name Resolution (ANR) Search in Active Directory.

ANR enables you to find a user when you have some information about a user, but don’t know exactly to which attribute that data corresponds. For example, if you know the user has “Thor” somewhere, but don’t know exactly what the SAMAccountName is (or DN, SID, name, etc). Submitting an ANR search will query the AD attributes flagged for ANR (attributes must be indexed) and replies with the results (may be more than one user found).

Windows Server 2008 checks the following attributes for ANR queries:

displayName
givenName
legacyExchangeDN
msDS-AdditionalSamAccountName
msDS-PhoneticCompanyName
msDS-PhoneticDepartment
msDS-PhoneticDisplayName
msDS-PhoneticFirstName
msDS-PhoneticLastName
physicalDeliveryOfficeName
proxyAddresses
Name
sAMAccountName
sn

Since ANR is an LDAP-specific feature with AD, you have to use a LDAP filter to get it.

Using the Microsoft AD cmdlets included in Windows Server 2008 R2, Get-ADObject performs an ANR search:

For Example:
Get-ADObject -LDAPFilter { (&(ObjectClass=User)(ANR=Thor) }

The Quest AD cmdlets support ANR natively (of course they do!).

Reference Articles:

Posted in Microsoft Products, Powershell Code Snippet, Tech - Tagged ANR, Powershell, PowerShellAD

Capacity Planning for Active Directory Domain Services

Mar27
2013 Leave a Comment

Written by Sean Metcalf

There is a new article on TechNet called “Capacity Planning for Active Directory Domain Services” which outlines key items for planning Active Directory Domain Controller capacity (Windows Server 2008 and newer).

Here are the highlights:

Plan for the peak busy period of the day. It is recommended to look at this in either 30 minute or hour intervals. Anything greater may hide the actual peaks and anything less may be distorted by “transient spikes.”
CPU Sizing: 1 modern physical core per 1,000 users (authentication).
RAM Sizing: 2-4 GB for OS + size of NTDS.dit + size of SYSVOL.

Also, don’t forget to perform core calculations to ensure appropriate capacity for Exchange (8:1 ratio for Exchange cores to GC cores) and other applications.

I typically recommend that at least 1 DC is on physical hardware in each domain – preferably 1 physical DC per domain in each datacenter. DCs should be spread across virtual hosts as much as possible to provide redundancy and ensure there’s DC capacity for virtual clients and application servers.

Posted in Career, Deployment, Microsoft Products, Technical Reference

Checklist Before Running Promoting a Domain Controller with DCPromo

Aug29
2012 Leave a Comment

Written by Sean Metcalf

The Ask PFE Blog recently posted a great post with a checklist to follow before and during the promotion a new Domain Controller.

Here’s a sample:

Prior to DCPROMO

Before we yell BANZAI! and kick off a DCPROMO, what should we check?

Do we need to modify any DHCP scopes?

Are we providing this server’s IP address as a DNS server for DHCP clients?

Do we need to modify any member servers or other static systems?

Are we pointing any systems to this server for DNS, LDAP, etc?

SCCM is an awesome tool to inventory these sorts of settings, but if you don’t have SCCM, another great way to inventory the IP configurations for your systems is via script. PowerShell has some handy ‘export to CSV’ functions built right in. A peer PFE and PowerShell wiz is putting the final polish on a post with some script code samples to do just that…stay tuned!

Are there startup/logon/other scripts that hard-code this system and need to be modified/edited beforehand?

Are there any shares, applications, printers, scheduled tasks or other ‘services’ on the target system? Check for any additional or unexpected Roles or Features (i.e. WINS – which is far down in the GUI; be sure you scroll!)

Those may or may not be affected after you remove AD from a server

If the goal is to decommission the server, those services may need to be moved or decommissioned with the target server

You’ll want to know what you should set for the local Administrator account’s password once AD is removed and the server becomes a member server

Beware that by default, the username will be “Administrator” but if you’ve redirected the default COMPUTERS container in AD to another OU, there might be a GPO that renames the local Administrator account

You’d be wise to obtain/verify (or reset) the local Directory Service Recovery Mode password just in case you need it on this system

This is often a weak spot in an AD deployment

“Who knows the DSRM password? I’ve tried the 8 that I thought it might be and none of them work.”

On 2008 and newer versions, this can be sync’d to a domain account to make it a bit more easily managed.

Obtain and verify ILO/DRAC/KVM/VM console or other ‘out of band’ access to the system in the event the system doesn’t reboot properly (sitting at an F1 prompt because someone unplugged the keyboard to a server across the country on a Sunday at 2:00 am is no fun).

You’ll need the AD Site information for the DC so you can clean up the server ‘object’ from AD Sites after the DCPROMO

That still needs to be manually removed even in Server 2012 (at least in the Release Candidate)

Make sure you have your approved and communicated Change Control Request

Make sure the Helpdesk is aware

I recommend verifying the AD FSMOs can all be reached from the target system

From CMD: DCDIAG /TEST:FSMOCHECK <enter>

Read the rest here:
First, Do No Harm

Posted in Deployment, Microsoft Products, Tech, Technical Reference - Tagged Active Directory, DCPromo Checklist, Domain Controller

msExchVersion User Attribute Values

Apr06
2012 Leave a Comment

Written by Sean Metcalf

Exchange 2007 introduced a new user attribute called msExchVersion that tracks the Exchange version a mailbox is created on. This may be useful if you want to manage mailboxes by Exchange version.

Exchange 2003 and earlier = “”
Exchange 2007 = “4535486012416″
Exchange 2010 = “44220983382016″

Posted in Deployment, Microsoft Products, Tech, Technical Reference - Tagged Exchange 2007/2010, ExchangeAttribute, Microsoft Exchange Server, msExchVersion

Powershell and UNC Paths

Apr02
2012 Leave a Comment

Written by Sean Metcalf

One of the fun things about working with “programming” (I use the term loosely when it comes to scripting, for I am not a programmer), is figuring out how to do things that the scripting “rules” often prevents.

One of these issues is dealing with UNC paths and Powershell confusing it with a regular expression, aka RegEx, statement. Powershell interprets a backslash (“\”) as a RegExstatement, so it has to be “escaped” before working with the backslashes. A similar issue is encountered when working with a local path (see example 5).

1. Extract the server name from a UNC path

$SharePath = “\\metcorpfs1.metcorp.org\Share1″
[regex]::match(“$SharePath”,’[^\\]+’).value

The result of running this is “metcorpfs1.metcorp.org”

2. Replace the server in a UNC path (or any text string)
This is the tricky part since Powershell interprets the backslash character “\” as a regular expression (regex). The way to deal with this is to escape regex.

$OldServer = “metcorpfs1″
$NewServer = “metcorpfs3″
$SharePath = “\\metcorpfs1.metcorp.org\Share1″
$NewSharePath = $SharePath -Replace ([regex]::Escape(“$OldServer”),”$NewServer”)
$NewSharePath

3. Split the UNC path into each part

[string]$UNCSharePath = “\\metcorpfs1.metcorp.org\Share1\PathRoot\PathParent\PathChild”
[array]$UNCSharePathArray = $UNCSharePath -Split [regex]::Escape(‘\’)
[array]$UNCSharePathArray

Note that the first 2 array entries ([0] & [1]) are blank.

4. Get the parent path for a local or UNC file

$LocalPath = “c:\Temp\scripts\Test.ps1″
$UNCPath = “\\metcorpfs1\Scripts\Test.ps1″
$LocalPathParentFolder = split-path $LocalPath -Parent
$LocalPathParentFolder
$UNCPathParentFolder = split-path $LocalPath -Parent
$UNCPathParentFolder

5. Split the local path into each part

$LocalPath = “c:\Temp\scripts\Test.ps1″
[array]$LocalPathArray = $LocalPath -Split [regex]::Escape(‘\’)

Posted in Powershell Code Snippet, Tech - Tagged Powershell, RegEx, UNC

RODC Trick: Remove a User’s Password from a RODC without forcing the user to change her password

Feb11
2012 Leave a Comment

Written by Sean Metcalf

TechNet (RODC FAQ) states:

How can you clear a password that is cached on an RODC?

There is no mechanism to erase passwords after they are cached on an RODC. If you want to clear a password that is stored on an RODC, an administrator should reset the password in the hub site. This way, the password that is cached in the branch will no longer be valid for accessing any resources in the hub site or other branches. In the branch that contains the RODC on which the password may have been compromised, the password will still be valid for authentication purposes until the next replication cycle, at which time its value that is stored on the RODC will be changed to Null. The new password will be cached only after the user authenticates with it—or the new password is prepopulated on the RODC—and if the PRP has not been changed.

In the event that an RODC is compromised, you should reset the passwords for all accounts that have cached passwords and then rebuild the RODC.

I disagree.
There is a way to do this. It may not be the officially “supported method”, but there definitely is a way to remove a user’s password from a RODC.

Why would you want to do this? Say that an executive travels to a field site and an admin adds her account to the RODC Password Allow group. This means the executive’s password is cached on the RODC at that site upon successful logon. You realize that the RODC has stored the executive’s password (oops!) and you have the same security concerns about the site that led you to only deploy a RODC there. You want to wipe the password from the RODC, but don’t want the executive to have to change her password. What to do?

Check the RODC computer object and see that the executive (Jane Executive in this example) shows up in the list of security principals with their passwords stored on the RODC (msDS-RevealedList).

The LDAP Modify Operation “RODCPurgeAccount” causes the RODC to NULL the cached secrets of a specified security principal (User or Computer).

Here’s a (likely unsupported) way to do it.

Open LDP on a writable DC and connect to the RODC on port 389 (LDAP) or 636 (LDAPS). Bind to the server (ensure you have Domain Admin credentials). Select Modify (operation) from the drop down and set the following:

DN: [blank]
Edit Entry Attribute: RODCPurgeAccount
Values: CN=Jane Executive,OU=Executives,DC=metcorp,DC=org [Account DN]
Click Replace
Click Enter
Click Run.

You should see the Modify is Successful.

Check the RODC computer object and see that the executive (Jane Executive in this example) is NOT in the list of security principals with their passwords stored on the RODC.

Security concern: the executive’s password was stored on the RODC during some period of time which means it was committed to the AD database (in memory & on disk). The correct way to ensure the executive’s password is not available is to have her change it (when WAS the last time she changed her password?) since this will invalidate any cached passwords floating around the network.

Posted in Deployment, Microsoft Products, Security, Tech - Tagged Active Directory, LDAP Modify Operation, Read-Only Domain Controller, Replication, RODC, RODCPurgeAccount

Powershell Parameter Parsing – How to Use a Single Parameter to Control Script Process Targeting

Jan28
2012 Leave a Comment

Written by Sean Metcalf

When I started using Powershell parameters, I had a parameter for everything. Now I have switched to using a single parameter for all relevant input and parse the parameter data for processing.

All I’m doing is setting the parameter ConfigTarget and then parsing the input to see how the script should get the computer target list.

If ConfigTarget is set to Domain, then perform a Get-ADComputer against the domain.
If ConfigTarget is set to an OU DN, then perform a Get-ADComputer using the OU DN as the starting point.
If ConfigTarget is set to an OU CN, the script converts the CN into a DN, and then performs a Get-ADComputer using the OU DN as the starting point.
If ConfigTarget is set to a single computername, the script performs the script action against the single computer.
If ConfigTarget is set to a file path, the script imports the file, parses the data and imports as a computer list, and then performs the script action against the list of computers.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214

<#
.PARAMETER ConfigTarget
Set the ComputerType parameter to determine what computer(s) the script targets.
Options:
Enter "Domain" to have the script target all computers pf a specific type in the domain.
Enter an OU (DN or CN) from which the script will get a computer list.
Enter a computer name (hostname only).
Enter a file path the contains a text or csv file containing a computer list.
PARAMETER ALIAS: Computer or Type or CT
Example: Update-LocalAdminPw.ps1 -ConfigTarget "Domain"
Example: Update-LocalAdminPw.ps1 -ConfigTarget "OU=Workstations,OU=ComputerTarget,DC=example,DC=com"
Example: Update-LocalAdminPw.ps1 -ConfigTarget "example.com\ComputerTarget\Workstations"
Example: Update-LocalAdminPw.ps1 -ConfigTarget "COMPUTERNAME"
Example: Update-LocalAdminPw.ps1 -ConfigTarget "c:\temp\computerlist.txt"
#>

Param
(
[parameter(Mandatory=$False)]
[alias("Target","OUName","ComputerName","Computer")]
[string]$ConfigTarget = "Domain",
)

Import-Module ActiveDirectory

###############################
# Format Computer Target List #
###############################
# If $ConfigTarget is a single computername set here

IF (($ConfigTarget -notlike "*DC=*") -OR ($ConfigTarget -notlike "*/*") -OR ($ConfigTarget -ne "Domain") -OR ($ConfigTarget -notlike "*:\*") -OR ($ConfigTarget -notlike "*,*") )
{ ## OPEN IF ConfigTarget is a computer name
[array] $TargetComputerList += $ConfigTarget
} ## OPEN IF ConfigTarget is a computer name

# If $ConfigTarget is a comma delimited list set here
IF ($ConfigTarget -like "*,*")
{ ## OPEN IF comma delimited list
Write-Output "User list file identified as comma delimited `r "
$ComputerList = $ConfigTarget -Replace(" ","")
[array]$ComputerListArray = $ComputerList -split(",")
[array] $TargetComputerList = $ComputerListArray
} ## CLOSE IF comma delimited list

########################################
# Get Computer Target List from a file #
########################################

IF ($ConfigTarget -like "*:\*")
{ ## OPEN IF File
$FileCheck = Test-Path $File
IF ($FileCheck -eq $True)
{ ## OPEN IF The path to the Computers list file is true
$ComputerList = Get-Content $File
$ComputerListCount = $ComputerList.Count
Write-Output "Importing $ComputerListCount Users from $File... `r "
} ## CLOSE IF The path to the Computers list file is true
ELSE { Write-Warning "Path to Computer list: $File is invalid. `r " ; exit }

IF ($ComputerList -like ",")
{ ## OPEN IF the imported list of Computers is comma delimited
Write-Output "User list file identified as comma delimited `r "
$ComputerList = $ComputerList -Replace(" ","")
[array]$ComputerListArray = $ComputerList -split(",")
$Computers = $ComputerListArray
} ## CLOSE IF the imported list of Computers is comma delimited

} ## CLOSE IF File

###################################
# Get a list of computers from OU #
###################################

IF (($ConfigTarget -like "*DC=*") -OR ($ConfigTarget -like "*/*"))
{ ## OPEN IF OUName is specified
IF (!$ComputerType) { Write-Warning "When defining the target as an OU, the ComputerType parameter must be defined. `r " ; exit }
Write-Verbose "Check the OU path info `r "
IF ($ConfigTarget -like "*DC=*")
# This identifies the OU input as a DN OU path
# The OU DN is required for the next component that gathers the computers in the OU path.

{ ## OPEN IF OUPath contains "DC=" which means it is a DN Name
$OUCheck = $True
Write-Output "The specified OU path ($ConfigTarget) is already a DN. Continuing... `r "
} ## CLOSE IF OUPath contains "/" which means it is a Canonical Name

IF ($ConfigTarget -like "*/*")
# This identifies the OU input as a CN OU path which is then converted to be a DN
# The OU DN is required for the next component that gathers the computers in the OU path.

{ ## OPEN IF OUPath contains "/" which means it is a Canonical Name
# Create the array by spitting the text input on the "/"
$OUCheck = $True
$OUPathArray = $ConfigTarget.split("/")
IF ($OUPathArray[0] -like "*.*")
{ ## OPEN IF The first item in the array is a domain name
$Len = $OUPathArray.length
$Len--
$Num = 1
$NewArray = @(1..$Len)

for($i=0; $i -lt $Len; $i++)
{ ## OPEN FOR
$NewArray[$i] = $OUPathArray[$Num]
$Num++
} ## CLOSE FOR

$OUPathArray = $NewArray
} ## CLOSE IF The first item in the array is a domain name

# Reverse the order of the aray to build the DN appropriately
[array]::Reverse($OUPathArray)
$OUPathCount = $OUPathArray.count

# Loop through the OU data to build the DN
$OUPath = "OU="
$OUDelimiter = ",OU="
For ($CountOU = 0;$CountOU -le $OUPathCount;$CountOU++)
{ ## OPEN Bracket FOR loop to ensure the LDAP path is properly built
IF ($CountOU -eq 0) {$OUPath = $OUPath + $OUPathArray[0];$CountOU++ }
IF ($OUPathArray[$CountOU]) {$OUPath = $OUPath + $OUDelimiter + $OUPathArray[$CountOU]}
} ## CLOSE Bracket FOR loop to ensure the LDAP path is properly built

# Build the full DN by appending the domain DN to the OUPath created in the loop above
$ComputerTargetOU = "$OUPath,$ADDomainDistinguishedName"
write-output " `r "
write-output "OU is now set to $ComputerTargetOU `r "
write-output " `r "
} ## CLOSE IF OUPath contains "/" which means it is a Canonical Name

IF ($OUCheck -eq $False)
{ Write-Warning "OU entered ($ConfigTarget) is not a valid Canonical Name or Distinguished Name. Exiting... `r " ; exit }

Switch ($ComputerType)
# This determines what type of computer object is returned: workstation or server
{ ## OPEN Switch ComputerType

Workstation
{ ## OPEN Switch Workstation Option
# Gather a list of all active workstations in specified OU tree including necessary attributes
write-output "Discovering active workstations in $ComputerTargetOU ..." `r
$AllActiveWorkstations = Get-ADComputer -SearchBase $ComputerTargetOU -filter {(OperatingSystem -like "*Windows*") -and (OperatingSystem -notlike "*Server*") -and (passwordLastSet -ge $ComputerStaleDate) -and (Enabled -eq $TRUE) }
$AllActiveComputersCount = $AllActiveWorkstations.Count
write-output ""`r
write-output "There were $AllActiveComputersCount active workstations discovered in $ComputerTargetOU ..." `r
write-output ""`r
[array]$ComputerList = $AllActiveWorkstations
} ## CLOSE Switch Workstation Option

Server
{ ## OPEN Switch Server Option
# Gather a list of all active Servers (not including Domain Controllers) in specified OU tree including necessary attributes
write-output "Discovering Active Windows SERVERS in $ComputerTargetOU ..." `r
$AllActiveServers = Get-ADComputer -SearchBase $ComputerTargetOU -filter {(OperatingSystem -like "*Windows*") -and (OperatingSystem -like "*Server*") -and (passwordLastSet -ge $ComputerStaleDate) -and (Enabled -eq $TRUE)-and (PrimaryGroupID -eq 515) }
$AllActiveComputersCount = $AllActiveServers.Count
write-output "" `r
write-output "There were $AllActiveComputersCount Active Windows SERVERS discovered in $ComputerTargetOU ..." `r
write-output "" `r
[array]$ComputerList = $AllActiveServers
} ## CLOSE Switch Server Option
} ## CLOSE Switch ComputerType
ForEach ($Computer in $ComputerList)
{ ## OPEN Computer in ComputerList
$TargetComputerList += $Computer.Name
} ## CLOSE Computer in ComputerList
} ## CLOSE IF OUName is specified

IF ($ConfigTarget -eq "Domain")
{ ## OPEN IF ConfigTarget = Domain
Switch ($ComputerType)
# This determines what type of computer object is returned: workstation or server
{ ## OPEN Switch ComputerType

Workstation
{ ## OPEN Switch Workstation Option
# Gather a list of all active workstations in specified OU tree including necessary attributes
write-output "Discovering active workstations in $ADDomainDNSRoot ..." `r
$AllActiveWorkstations = Get-ADComputer -filter {(OperatingSystem -like "*Windows*") -and (OperatingSystem -notlike "*Server*") -and (passwordLastSet -ge $ComputerStaleDate) -and (Enabled -eq $TRUE) }
$AllActiveComputersCount = $AllActiveWorkstations.Count
write-output ""`r
write-output "There were $AllActiveComputersCount active workstations discovered in $ADDomainDNSRoot ..." `r
write-output ""`r
[array]$ComputerList = $AllActiveWorkstations
} ## CLOSE Switch Workstation Option

Server
{ ## OPEN Switch Server Option
# Gather a list of all active Servers (not including Domain Controllers) in specified OU tree including necessary attributes
write-output "Discovering Active Windows SERVERS in $ADDomainDNSRoot ..." `r
$AllActiveServers = Get-ADComputer -filter {(OperatingSystem -like "*Windows*") -and (OperatingSystem -like "*Server*") -and (passwordLastSet -ge $ComputerStaleDate) -and (Enabled -eq $TRUE)-and (PrimaryGroupID -eq 515) }
$AllActiveComputersCount = $AllActiveServers.Count
write-output "" `r
write-output "There were $AllActiveComputersCount Active Windows SERVERS discovered in $ADDomainDNSRoot ..." `r
write-output "" `r
[array]$ComputerList = $AllActiveServers
} ## CLOSE Switch Server Option
} ## CLOSE Switch ComputerType

ForEach ($Computer in $ComputerList)
{ ## OPEN Computer in ComputerList
$TargetComputerList += $Computer.Name
} ## CLOSE Computer in ComputerList

} ## CLOSE IF ConfigTarget = Domain

# Sort the list alphabetically
$ComputerList = $ComputerList | sort
$TargetComputerListCount = $TargetComputerList.Count

# Output Computer list to ComputerWorkFile
write-output ""`r
write-output "Saving computer job list to computer work file..."`r
write-output ""`r
$TargetComputerList | out-file $ComputerWorkFile -force

Posted in Microsoft Products, Powershell Code, Tech - Tagged Active Directory, Code, Computer Targeting, Configuration, Microsoft Windows, Powershell, Powershell Parameter

Active Directory Replication Overview & USN Rollback: What It Is & How It Happens

Jan25
2012 Leave a Comment

Written by Sean Metcalf

If you have experienced event id #2095, then you understand how a USN Rollback can negatively affect AD consistency.

What is a USN?

The USN (Update Sequence Number) is an Active Directory database instance counter that increments every time a single change is committed to the AD database on a Domain Controller. The USN is unique to each DC and has no correlation to a USN on another DC (and that doesn’t matter, as you will see why later on in this article). Active Directory replication keeps track of every Domain Controller’s USN and uses this information to determine when replication is required. Active Directory has two basic types of writes to the AD database, a replicated write (where the change is performed on another DC) and an originating write (where the change is performed on the local DC). AD Replicates and leverages the information about what changes were performed on which DCs and then replicated out.

Every Domain Controller has a server object in the site container stored within the Configuration partition. This object has a child object called “NTDS Settings” which has a GUID (Globally Unique IDentifier) attribute which is replicated as part of replication metadata and used by the KCC to build the replication topology. Each DC has its own copy of the Active Directory database stored in the ntds.dit file and this unique database instance on a DC is identified with its own GUID-type identifier called the “Invocation ID”. The Invocation ID is created when the DC is promoted and only changes when the AD database is restored using a supported method or an application partition is added or removed. The reason for this is so that when an AD database is restored to an earlier point in time, the USN is also restored to that point in time. This means that any change from the restored USN value until the original, pre-restored USN value would be ignored by other DCs pulling replication from the restored DC (since they track other DCs USNs that they replicate with and only pull updates when the destination DC’s USN increments above the last stored update value USN the DC has for it – more on this later). In order to avoid this situation, the DC’s AD database generates a new Invocation ID and stores the old Invocation ID is stored in an attribute on the server’s NTDS Settings object called retiredReplDSASignatures. In this manner, the DCs will treat a new Invocation ID as a new database and ensure it gets updates from it moving forward. You can see a DC’s Invocation ID and Server GUID by running repadmin /showrepl.

Much of the DC information is visible when running the Get-ADDomainController PowerShell commandlet:

PS C:\> import-module activedirectory ;
get-addomaincontroller -identity “MetcorpORGDC01.metcorp.org”

ComputerObjectDN           : CN=METCORPORGDC01,OU=Domain Controllers,DC=metcorp,DC=org
DefaultPartition           : DC=metcorp,DC=org
Domain                     : metcorp.org
Enabled                    : True
Forest                     : metcorp.org
HostName                   : MetcorpORGDC01.metcorp.org
InvocationId               : f2e96b87-bb2a-4572-a911-0c79721e7b4f
IPv4Address                : 10.10.10.11
IPv6Address                :
IsGlobalCatalog            : True
IsReadOnly                 : False
LdapPort                   : 389
Name                       : METCORPORGDC01
NTDSSettingsObjectDN       : CN=NTDS Settings,CN=METCORPORGDC01,CN=Servers,CN=WashingtonDC,CN=Sites,CN=Configuration,DC
                             =metcorp,DC=org
OperatingSystem            : Windows Server 2008 R2 Enterprise
OperatingSystemHotfix      :
OperatingSystemServicePack : Service Pack 1
OperatingSystemVersion     : 6.1 (7601)
OperationMasterRoles       : {SchemaMaster, DomainNamingMaster, PDCEmulator, RIDMaster…}
Partitions                 : {DC=ForestDnsZones,DC=metcorp,DC=org, DC=DomainDnsZones,DC=metcorp,DC=org, CN=Schema,CN=Co
nfiguration,DC=metcorp,DC=org, CN=Configuration,DC=metcorp,DC=org…}
ServerObjectDN             : CN=METCORPORGDC01,CN=Servers,CN=WashingtonDC,CN=Sites,CN=Configuration,DC=metcorp,DC=org
ServerObjectGuid           : 214c2f5d-f9eb-4b0c-b1fa-4829fc8be2fc
Site                       : WashingtonDC
SslPort                    : 636

Notice in the Get-ADDomainController ouput above, there is a Computer Object DN and a Server Object DN?

The Computer Object DN is where the Domain Controller’s computer object is stored in the domain partition (DC=metcorp,DC=org in the example) and represents the DC in the domain.
The Server Object DN is representation of the DC as a replication object and is stored in the configuration partition under the site object (…,CN=Sites,CN=Configuration,DC=metcorp,DC=org in the example).

Every replicated change includes the following pieces of information:

The Replication Source DC’s GUID replicating the change (originating or replicated write)
The Replication Source DC’s USN
The Originating DC’s GUID (the DC where the AD update was first performed)
The Originating DC’s USN

NOTE: If the Originating Source DC’s GUID & the Originating DC’s GUID are the same, then this is an originating write. If they are different, then the change operation is a replicated write and the replication system uses the Up-To-Dateness Vector. The DCs use all of this information inlcuding the Up-To-Dateness Vector & the High Water Mark as part of “Propagation Dampening” to ensure that replication doesn’t get stuck in a loop.

There are two primary mechanism that leverage a DC’s USN to track replication updates:

The Up-to-Dateness-Vector(UTDV) is a method by which DC replication partners can quickly identify when data needs to be replicated. Each DC has a UDV that keeps track of the USN for every DC hosting a replicated partition. Every DC in the AD forest hosts the same base partitions and replicates these partitions separately: Configuration & Schema and frequently the Domain DNS & Forest DNS application partitions. All of the DCs in the same domain host the same domain partition. Each partition has an associated UDV with all DCs hosting the partition and their associated USN.Simply put, the UTDV is a table of all the DCs for a replicated partition and their replicated USNs and date/time when the DC last replicated. The UTDV is sent to the Source DC by the requesting Destination DC (replicating data is always a pull even though the notification may be a push action) to filter out updates the Destination DC already has. At the end of the replication cycle the Source DC sends the Destination DC its UTDV.Here’s an example of what it looks like:Repadmin: running command /showutdvec against full DC METCORPORGDC02.metcorp.org
Caching GUIDs.
..
WashingtonDC\METCORPORGDC02 (retired) @ USN 65593 @ Time 2012-01-21 12:29:38
WashingtonDC\METCORPORGDC02 @ USN 62096 @ Time 2012-01-23 21:47:00
ae7a0f8e-e7bd-4d4f-83df-1c731cdd8e47 @ USN 46734 @ Time 2012-01-21 14:17:26
WashingtonDC\METCORPORGDC01 @ USN 59160 @ Time 2012-01-23 21:46:33Notice how DC02 has 2 different entries, one with a USN of 65593 (marked Retired) and one with a USN of 62096. AD replication ignores the (Retired) Invocation ID’s USN and uses the current one for replication decisions, though it does keep it in the UTDV to ensure the USNs are kept separate.
The High Water Mark (HWM) on a DC tracks the highest USN replicated from each DC and uses that to identify when replication is required.Simply put, the HWM tracks the last USN replicated by one of the local DC’s replication partner. The HWM is used to track the most recent changes (objects and attributes) a Destination DC has received from Source DCs for a specific partition.For example, we have DC01 and DC02:DC01′s USN: 3300
DC02′s USN: 2200DC01 has a HWM of 2000 for DC02 and DC02 has a HWM of 3300 for DC01. When a change is performed on DC01, the USN is incremented to 3301 and when DC02 requests updates, it requests any changes since USN 3300. DC01 sends DC02 change #3301 and DC02 performs a replicated write to its AD database incrementing its local USN to 2201. What’s interesting about this is that at this point, DC01 has a HWM of 200 still and DC02 now has a USN of 2201. Since the DCs have the information about the originating DC and the originating DC’s USN, they know that this change has already been replicated so they update their HWM and wait for the next change.

What is USN Rollback?

Since updates are replicated when the USN on the source DC is larger than the destination DC has for the source DC (according to the UTDV & HWM), a USN Rollback scenario on a DC prevents replication of AD updates on that DC to any other. Typically when a USN goes backwards, it is due to a supported restore from backup. When this process occurs, the invocation ID changes. Since all replica partners track replication based on DC GUID, Invocation ID, and USNs, a supported restore method keeps the previous invocation ID as “retired” and effectively ignores it. The new database Invocation ID & associated USN are used to get AD changes from the DC… except when the USN rolls back with NO change in Invocation ID. This means that when a DC is in a state of USN Rollback, AD updates can be performed on that DC with NONE of the changes replicated to its replication partners. That’s bad news.

Examples help clarify concepts, so I’ll use one here.

DC01, DC02 & DC03 are Domain Controllers for the Active Directory domain metcorp.org.
DC01 is running on physical hardware and DC02 & DC03 are virtual DCs running on VMWare ESX.

The AD admin copies the DC02 virtual files on Monday and on Wednesday, DC02 fails.
The admin uses the DC02 VM files from Monday to get DC02 up and running on Thursday (ASAP, right?).

During the next replication cycle, DC01 & DC03 send DC02 the last update USN they have for DC02 (USN #31,131). DC02 checks its local USN and notes that the local USN (USN #29,000) is less than the ones sent (USN #31,131), so no update is replicated to DC01 or DC03. As changes to Active Directory are performed on DC02, they are not replicated to the other metcorp.org DCs until DC02′s USN increments past the USN the other DCs have for DC02. This means that 2,131 modifications occur on DC02 before the other DCs receive a single update – and then only changes from USN 31,132 on.

Note that in this situation, any change performed on DC02 is NOT replicated to any other DC. This means that modifications to AD on DC02 only exist on DC02 while other DCs may have different versions of the same objects, including passwords and group membership. See, bad news.

Day 01 – Sunday:
DC01′s USN #34,951
DC02′s USN #28,539
DC03′s USN #22,360

Day 02 – Monday:
DC01′s USN #35,123
DC02′s USN #29,000 (VM copied)
DC03′s USN #23,101

Day 03 – Tuesday:
DC01′s USN #36,432
DC02′s USN #31,131 – FAILS
DC03′s USN #24,555

Day 04 – Wednesday:
DC01′s USN #38,012
DC02 OFFLINE
DC03′s USN #25,010

Day 05 – Thursday:
DC01′s USN #39,951
DC02 Back online with USN #29,000
DC03′s USN #27,360

What causes USN Rollback to occur?

There are several scenarios that Microsoft has identified that can cause USN Rollback on a DC (i.e. unsupported configurations). All of these include the same common theme and that is taking an earlier state of a DC (backup or copy) and running it.

Starting an Active Directory domain controller whose Active Directory database file was restored (copied) into place by using an imaging program such as Norton Ghost.

Starting a previously saved virtual hard disk image of a domain controller. The following scenario can cause a USN rollback:

Promote a domain controller in a virtual hosting environment.

Create a snapshot or alternative version of the virtual hosting environment.

Let the domain controller continue to inbound replicate and to outbound replicate.

Start the domain controller image file that you created in step 2.

Starting an Active Directory domain controller that is located on a volume where the disk subsystem loads by using previously saved images of the operating system without requiring a system state restoration of Active Directory.

These scenarios pretty much always involve a virtual environment, so if you have virtual DCs you may want to ensure backups are done on the physical DCs (you can never go wrong with performing backups on the FSMOs to start) and/or ensure that the Windows Backup tool is used to backup the AD database (SUPPORTED backup method is key).

Detecting USN Rollback

Detecting USN Rollback is extremely difficult since DCs running Windows 2000 or Windows 2003 RTM didn’t check for repeating USNs for the same Invocation ID. There are no errors in the NTDS Replication event log or when using the replication utility Repadmin. There is a manual method for detecting a USN Rollback using Repadmin and Microsoft KB 875495 describes this process:

One way to detect a USN rollback is to use the Windows Server version of Repadmin.exe to run the repadmin /showutdvec command. This version of Repadmin.exe displays the up-to-dateness vector USN for all domain controllers that replicate a common naming context. To detect a USN rollback, compare the output of the repadmin /showutdvec command on the domain controller with the output of the same command on the domain controller’s replication partners. If the direct replication partners have a higher USN number for the domain controller than the domain controller has for itself, and the repadmin /showreps command does not report replication errors between direct replication partners, you have compelling evidence of a USN rollback.

C:\>Repadmin /showutdvec dc1 dc=contoso,dc=com
Caching GUIDs…
Site1\DC1 @ USN 10 @ Time 2004-08-04 15:07:15
Site2\DC2 @ USN 24805 @ Time 2004-08-04 15:06:59
C:\>Repadmin /showutdvec dc2 dc=contoso,dc=com
Caching GUIDs…
Site1\DC1 @ USN 50 @ Time 2004-08-04 15:07:15
Site2\DC2 @ USN 24805 @ Time 2004-08-04 15:06:59

Note in the example repadmin output above, DC2 has a USN of 50 for DC1 while DC1 has a USN of 10 for itself.

Starting with Windows 2003 Sp1 or newer (or earlier with the KB 875495 hotfix), DCs track and flag when another DC (source DC) sends a USN that was previously acknowledged with the same invocation id.

When a USN Rollback is identified on a Windows 2003 Sp1 or newer (or earlier with the KB 875495 hotfix), the following actions are performed on that DC:

The DC write event 2095 to the DC’s Directory Services event log.
The DC disables inbound and outbound replication.
The DC recognizes the USN Rollback and pauses its Netlogon service. This prevents any changes from being performed on the DC.

Windows 2003 SP 1 and newer Domain Controllers that detect a USN Rollback state on a replication source DC, log the following event:

Event Type: Error
Event Source: NTDS Replication
Event Category: Replication
Event ID: 2095
Date: 3/10/2005
Time: 4:26:51 PM
User: USN\2B25VB$
Computer: 2B9A
Description: During an Active Directory replication request, the local domain controller (DC) identified a remote DC which has received replication data from the local DC using already-acknowledged USN tracking numbers. Because the remote DC believes it is has a more up-to-date Active Directory database than the local DC, the remote DC will not apply future changes to its copy of the Active Directory database or replicate them to its direct and transitive replication partners that originate from this local DC. If not resolved immediately, this scenario will result in inconsistencies in the Active Directory databases of this source DC and one or more direct and transitive replication partners. Specifically the consistency of users, computers and trust relationships, their passwords, security groups, security group memberships and other Active Directory configuration data may vary, affecting the ability to log on, find objects of interest and perform other critical operations. To determine if this misconfiguration exists, query this event ID using http://support.microsoft.com or contact your Microsoft product support. The most probable cause of this situation is the improper restore of Active Directory on the local domain controller. User Actions: If this situation occurred because of an improper or unintended restore, forcibly demote the DC. Remote DC: b55ee67f-ed73-4970-b2d4-7dc6f571439f Partition: CN=Configuration,DC=usn,DC=loc USN reported by Remote DC: 24707 USN reported by Local DC: 20485 For more information, see Help and Support Center at http://support.microsoft.com.

On the DC with USN Rollback the following events are logged:

Event Type: Warning
Event Source: NTDS General
Event Category: Replication
Event ID: 1113
Date: 3/10/2005
Time: 4:26:51 PM
User: USN\2B25VB$
Computer: 2B9A
Description: Inbound replication has been disabled by the user. For more information, see Help and Support Center at http://support.microsoft.com.

Event Type: Warning
Event Source: NTDS General
Event Category: Replication
Event ID: 1115
Date: 3/10/2005
Time: 4:26:51 PM
User: USN\2B25VB$
Computer: 2B9A
Description: Outbound replication has been disabled by the user. For more information, see Help and Support Center at http://support.microsoft.com

Event Type: Error
Event Source: NTDS General
Event Category: Service Control
Event ID: 2103
Date: 3/10/2005
Time: 4:26:51 PM
User: USN\2B25VB$
Computer: 2B9A
Description: The Active Directory database has been restored using an unsupported restoration procedure. Active Directory will be unable to log on users while this condition persists. As a result, the Net Logon service has paused. User Action See previous event logs for details. For more information, see Help and Support Center at http://support.microsoft.com.

Resolving USN Rollback on a DC

Microsoft recommends two methods to resolve a USN Rollback state:

Demote & re-promote the DC – this resets the Invocation ID & the USN.
Restore the DC from a supported backup (preferably using Microsoft’s Backup utility).

I recommend performing resolution step #1. Since the typical scenarios that bring about a USN Rollback involve imaging or performing an un-supported restoration, having a USN Rollback in the environment typically points to process issues. Often this is related to improper restore procedures.

In this situation, it is best to demote the Domain Controller by running dcpromo /forceremoval and perform a metadata cleanup of that DC. If the demoted DC was hosting any of the FSMO roles, they must be seized to another DC.

Only run DCPromo on the server to re-promote it after the metadata cleanup is successful (and any FSMOs are transferred).

References:

Posted in Microsoft Products, Tech, Technical Reference - Tagged Active Directory, AD Replication, Configuration, Deployment, Domain Controller, High Water Mark Vector, Powershell, up-to-dateness vector, Windows Server

Active Directory Domain Trusts & Trust Password Management

Jan15
2012 1 Comment

Written by Sean Metcalf

Recently a customer asked me about Active Directory Domain Trusts and how the passwords were managed. I replied with some educated guesses based on how AD manages a variety of passwords. After stating how I thought it worked (and mentioned that I wasn’t sure), I decided to look it up. I was mostly correct.

Every trust a domain maintains is represented by a Trusted Domain Object (TDO) in the Domain partition’s System container. The TDO contains the following attributes for a domain trust:

DNS domain name
Domain SID
Trust type
Trust transitivity
Reciprocal domain name

Forest trusts store the following attributes:

DNS domain name
Domain SID
Trust type
Trust transitivity
Reciprocal domain name
Domain tree names
User Principal Name (UPN) suffixes
Service Principal Name (SPN) suffixes
Security ID (SID) namespaces

Since trust information is stored in Active Directory, all domains in the forest know about all of the trusts in place with all forest domains. External NT 4 trusts are not stored as TDOs and therefore are not in Active Directory.

In a one-way trust, there is a TrustED and TrustING domain.
The TrustING domain has the resources that the account in the TrustED domain needs to access. Since a two-way trust is only 2 one-way trusts, there are actually 2 trust passwords involved.

Here’s how trust passwords are managed:

After the trust is created, the password is stored in the associated TDO object.
After 30 days the PDC emulator in the trustING domain changes the password by creating a new one. The trustED DC never attempts to change the password.
The TrustING DC updates the associated TDO OldPassword attribute to the value of the prior password.
The TrustING DC updates the associated TDO NewPassword attribute to the value of the new password.
This way there are always 2 trust passwords associated with the trust, the old password and the new (current) one. This ensures that even if there is an issue with the password change on the TrustED side, the trust remains active since both sides still have a useful password (OldPassword).
The TrustING domain DC connects to a TrustED domain controller via RPC to provide the updated password.
The TrustED DC receives the new password and updates its existing trust password.
Since the trust password is stored in the Domain container in the associated TDO, all the DCs in the domain receive the updated trust password via regular AD replication.
Until the TrustING DC authenticates to a TrustED DC using the new password, the new password is not valid. The old password is used over secure channel until the new password is updated in the TrustED domain and validated.
If authentication fails with the new password, it falls back to the old password and the the password change resumes within 15 minutes.
It is expected that trust passwords are updated among all domain DCs within a day and have a default lifetime of 30 days (same as domain computer accounts). Obviously, trusts can get out of sync if both sides of the trust don’t update and store the new password properly.

Trust Limitations:

More than 2400 Trusted Domain Objects (TDOs) incurs noticeable delays specifically related to inter-domain authentication.
There is a maximum of 10 trust links Kerberos clients (Windows 2003) can traverse to locate a requested resource in another domain. If the trust path starts approaching 10, it is better to create external trusts to bypass this issue.

Realm Trust:

A realm trust is a trust between a non-Windows Kerberos realm and a Windows 2000/2003/2008 domain which enables cross-platform Kerberos (v5) interoperability.

Only supports Kerberos v5 authentication (not NTLM).
One-way & nontransitive by default, but can be switched to transitive. configure 2 one-way trusts to enable a two-way trust relationship.

NOTE:
Windows Server 2003 administrative tools sign and encrypt all LDAP traffic by default.

Command Line Tools for managing trusts:

NLTest
“You can use the NLTest command-line tool to perform trust-related network administrative tasks such as testing the trust relationship between a Windows–based computer that is a member of a domain and the domain controller on which its computer account is located. In domains where an external trust is defined, NLTest can be used to test the trust relationship between all domain controllers in the trusting domain and a domain controller in the trusted domain. Nltest can also be used to verify any secured channel.“
NetDom
Netdom is a command-line tool that allows you to create and manage Active Directory trust relationships (except forest trusts) and can help reduce the number of steps needed to create a trust by using Active Directory Domains and Trusts. You can also use the Netdom command line tool to complete batch management of trusts, join computers to domains, verify trusts (including forest trusts) and secured channels, and obtain information about the status of trusts.Netdom can be targeted at all Active Directory domain controllers and can verify all Active Directory trust types. Verification is accomplished between two domains by enumerating the domain controllers in each domain. If you choose to have Netdom create both sides of the trust at once the trust password is automatically generated.

WMI Classes Associated with Trusts

Class Name	Namespace	Version Compatibility
Microsoft_TrustProvider	root\microsoftactivedirectory	Windows 2000 Server and Windows Server 2003
Microsoft_DomainTrustStatus	root\microsoftactivedirectory	Windows 2000 Server and Windows Server 2003
Microsoft_LocalDomainInfo	root\microsoftactivedirectory	Windows 2000 Server and Windows Server 2003

Ports Required for Trusts

Task	Outbound Ports	Inbound Ports	From–To
Set up trusts on both sides from the internal forest	LDAP (389 UDP and TCP) Microsoft SMB (445 TCP) Kerberos (88 UDP) Endpoint resolution — portmapper (135 TCP) Net Logon fixed port	N/A	Internal domain domain controllers–External domain domain controllers (all ports)
Trust validation from the internal forest domain controller to the external forest domain controller (outgoing trust only)	LDAP (389 UDP) Microsoft SMB (445 TCP) Endpoint resolution — portmapper (135 TCP) Net Logon fixed port	N/A	Internal domain domain controllers–External domain domain controllers (all ports)
Use Object picker on the external forest to add objects that are in an internal forest to groups and DACLs	N/A	LDAP (389 UDP and TCP) Windows NT Server 4.0 directory service fixed port Net Logon fixed port Kerberos (88 UDP) Endpoint resolution portmapper (135 TCP)	External server–Internal domain PDCs (Kerberos) External domain domain controllers–Internal domain domain controllers (Net Logon)
Set up trust on the external forest from the external forest	N/A	LDAP (389 UDP and TCP) Microsoft SMB (445 TCP) Kerberos (88 UDP)	External domain domain controllers–Internal domain domain controllers (all ports)
Use Kerberos authentication (internal forest client to external forest)	Kerberos (88 UDP)	N/A	Internal client–External domain domain controllers (all ports)
Use NTLM authentication (internal forest client to external forest)	N/A	Endpoint resolution – portmapper (135 TCP) Net Logon fixed port	External domain domain controllers–Internal domain domain controllers (all ports)
Join a domain from a computer in the internal network to an external domain	LDAP (389 UDP and TCP) Microsoft SMB (445 TCP) Kerberos (88 UDP) Endpoint resolution — portmapper (135 TCP) Net Logon fixed port Windows NT Server 4.0 directory service fixed port	N/A	Internal client–External domain domain controllers (all ports)

To specify the services that you want to run on a fixed port, you must appropriately configure the registry for that port.

References:

Posted in Microsoft Products, Tech, Technical Reference, Troubleshooting - Tagged Active Directory, AD Replication, AD Trusts, Configuration, Domain Controller, Domain Trusts, Forst Trust, FSMO, PDC Emulator

Posts in category Favorite

AD Trivia: Where does the domain SID come from?

PowerShell and Ambiguous Name Resolution (ANR) Search in Active Directory

Capacity Planning for Active Directory Domain Services

Checklist Before Running Promoting a Domain Controller with DCPromo

msExchVersion User Attribute Values

Powershell and UNC Paths

RODC Trick: Remove a User’s Password from a RODC without forcing the user to change her password

Powershell Parameter Parsing – How to Use a Single Parameter to Control Script Process Targeting

Active Directory Replication Overview & USN Rollback: What It Is & How It Happens

Active Directory Domain Trusts & Trust Password Management

Recent Posts

Categories

Archives

Active Directory

Exchange

Microsoft Blog

Powershell

Security

SharePoint

Virtualization

VMWare

Windows Server

Posts in category Favorite

Recent Posts

Categories

Tags

Archives

Active Directory

Exchange

Microsoft Blog

Powershell

Security

SharePoint

Virtualization

VMWare

Windows Server