Windows Azure AD with your Active Directory

I've just watched a Microsoft jump-start video on how to integrate Windows Azure AD (AAD) with your on-premise AD infrastructure. By doing so, your users can experience seamless authentication experience between public Windows Azure (e.g. Office 365, Sharepoint online etc) and on-premise network. Here is the link: AD to Windows Azure AD.

In summary, there are 3 possible options:

1) No integration. Users logon to Azure and on-premise AD separately with different sets of credential.

2) Directory sync (DirSync) only: On-premise AD user accounts and password hashes are synced to Azure. Users logon to both using same set of credential. No Single Sign-On (SSO) between AD and AAD. In other words, users have to authenticate twice, even though they may use the same set of user ids and passwords.

3) AD Federation (ADFS with DirSync): AD user objects (but no password hash) are synced to Azure. Establish one-way federated trust (i.e. Azure trusts your AD). This option supports SSO and even smart card authentication.

Active directory or sysvol is not accessible on this domain controller or an object is missing

I saw this error message on Group Policy Management when I did a status check on the AD replication. All domain controllers were stuck with replication in progress with their respective Sysvol "inaccessible" against the PDC emulator. I couldn't find any error events on "DFS Replication" at all - the replication just got stuck in progress.

When this happens, follow the steps on How to perform an authoritative synchronization of DFSR-replicated SYSVOL.

Virtualised Domain Controllers Replication Issues

I noticed virtualised domain controllers often have issues replicating new settings in Group Policy Objects. This warning message was also observed:

Error: 9036 (Paused for backup or restore)

After reading this Technet article on backing up virtual domain controller, I realised the cause was due to the snapshot back at Hyper-V level. The only supported backup method is running the backup job at the guest VM level. Since then, I've stopped backing up domain controllers at Hyper-V host level and disabled the backup integration services at VM configuration.

WS2012 Domain Controllers stop replication after Power Outage

We had some power outage and noticed newer Group Policy Objects (GPOs) weren't replicated across the AD. After running dcdiag /a diagnostic command, we noticed DRS-R event errors on some WS2012 Domain Controllers. After doing some research, we realised that WS2012 stopped auto-replication by default.

To enable it back, configure this setting on the registry and restart the affected DCs.

1. Set HKLM\System\CurrentControlSet\Services\DFSR\Parameters\StopReplicationOnAutoRecovery registry key to a DWORD value of 0.
2. On evelvated command prompt, run wmic /namespace:\\root\microsoftdfs path dfsrmachineconfig set StopReplicationOnAutoRecovery = FALSE

Reference: Understanding DFSR Dirty (Unexpected) Shutdown Recovery

Verify Domain Controller Certificate for Smartcard Logon

To enable user smartcard logon, all domain controllers must be enrolled with KDC enabled certificates. The correct cert template to deploy is Domain Controller Authentication. If you enrolled the domain controllers with wrong certs, you might encounter this error event on the domain controllers:

This event indicates an attempt was made to use smartcard logon, but the KDC is unable to use the PKINIT protocol because it is missing a suitable certificate.

To resolve, you'll have to delete the invalid cert and request for a new valid cert. To verify after enrolling domain controller certificates, run this command:

certutil -dcinfo verify

Reference: Event ID 19 — KDC Certificate Availability

Cert template of Issuing CA must be updated on Account Forest

Previously, we did a successful trial on cross-forest cert enrollment with 2-way forest trust enabled. The user objects are on Account Forest and the PKI / CA servers are on the Resource Forest. I created a new cert template, issued it on the enterprise CA and sync the new cert template to the account forest using PKIsync.ps1 script. But the users were unable to enroll the new cert even though I've ensured the necessary permissions have been granted. I tried a manual enrollment and saw the following error message:

A valid certification authority (CA) configured to issue certificates based on this template cannot be located...

The new cert template in this case would be "TestingDoNoEnroll". Look like the enrollment clients could not find the issuing CA. On a domain controller of account forest, I did a check on the "AD Sites and Services" console with "View / Show Services Node" enabled. Expand on "Services / Public Key Services / Enrollment Services" and I check on the object of issuing CA on resource forest.

Double click on the object and select "Attribute Editor / certificateTemplates". The new template was missing - no wonder that the CA for the new issuing cert template could not be found. I added the new cert template name and enrollment worked as expected!

Delegate Certificate Template Management

By default, only Domain Admins are able to create and manage Certificate Templates on the Active Directory. To delegate to other groups (e.g. CA admins), follow this guide on Allowing the Creation and Modification of any Certificate Template.

How to add custom attributes to AD User Objects

We have an application that requires to store some custom user attributes on the Active Directory. Let's say we need to add a custom attribute "Gender". How should we go about it? We need to first extend the existing User Class in the AD Schema. Please refer to this detailed step-by-step guide.

Here, I would just summarize the overall steps.

Step 1: Register AD schema tool by running "regsvr32 schmmgmt.dll" on the Domain Controller with "Schema Master" role. Add the AD Schema tool on the mmc console.
Step 2: In the AD Schema Console, right-click the Attributes folder, then select Create Attribute.

Step 3: You may like to generate your own private enterprise OID (Unique X.500 Object ID) for this custom attribute on this link.
Step 4: From the Schema Console, click the Class folder. Scroll down to the User class, right-click it, and select Properties. On the user Properties dialog box, click the Attributes tab. Click Add, then choose the Gender attribute. Click OK twice, and you've successfully added the Gender attribute to the User class.

Now we have an extra gender attribute for every user object. How should we populate its values (i.e. Male or Female)? If you have an excel sheet, convert it to CSV and use Powershell script to populate it. Below is sample script.

$Users = import-csv users.csv
Foreach ($user in $Users)
{
  $sAMAccountName = $user.sAMAccountName
  $gender = $user.gender
  $Property = @{gender=$gender}
  Write-host "Setting the gender of $sAMAccountName"
  Get-ADObject -Filter 'sAMAccountName -eq $sAMAccountName' | Set-ADObject -add $Property
  Write-host "Done!"
}

Cloning Virtual Domain Controllers

A new feature of Windows Server 2012 is the cloning of Domain Controllers. This is a rapid way to deploy new Domain Controllers in virtual machine forms. The detailed step-by-step is outlined in Virtual Domain Controller Cloning in Windows Server 2012. I won't attempt to repeat all the details. Hence, I would summarize the steps for easy reference later.

Prerequisite Check:

1. The hypervisor must support VM-GenerationID. Hyper-V running on Windows Server 2012/Windows 8 supports this feature and so do VMWare vSphere 5.x.  
2. The source virtual DC must be running Windows Server 2012. 
3. The PDC emulator role holder must be online and available to the cloned DC and must be running Windows Server 2012.

Step 1: Add source DC VM into "Clonable Domain Controllers" Security Group

Step 2: Check for applications and determine whether they should be cloned by running "Get-ADDCCloningExcludedApplicationList" cmdlet. If application is not supported for cloning, uninstall it. Otherwise, add the application to the inclusion list (CustomDCCloneAllowList.xml). The list can be generated with the same cmdlet with "-GenerateXML" option.

Step 3: Run "New-ADDCCloneConfigFile" cmdlet on source VM to run a list of prerequisite checks as mentioned above. It would also generate "DCCloneConfig.xml" file that contains a list of settings to be applied to the cloned DC, including network settings, DNS, WINS, AD site name, new DC name etc. The xml file is contained at the "%Systemroot%\NTDS" folder. These new settings can be specified with the same cmdlet input with the necessary options. For example:

New-ADDCCloneConfigFile -IPv4Address 10.2.1.10 -IPv4DefaultGateway 10.2.1.1 -IPv4SubnetMask 255.255.255.0 -IPv4DNSResolver 10.1.1.10,10.1.1.11 -Static -SiteName CORPDR

Step 4: Shut down the source VM and export it out using "Export-VM" cmdlet e.g. Export-VM -name sourceDC -Path D:\ClonedDC.

Step 5: Import the VM by running "Import-VM" cmdlet e.g. Import-VM –Path {VM XML Path} –Copy –GenerateNewId –VhdDestinationPath D:\ClonedDC. You can also rename the new VM using Hyper-V manager. Start the newly cloned VM.

Prevent Users from joining Computers to AD

From a security standpoint, it would be pretty hard to control if normal domain users can join their machines to AD without authorization. By default, a user may join up-to 10 computers to AD.

Depending on your organizational security policy, users should only self-help themselves (or restricted to help-desk personnel) with proper authorization. To enforce such policy:

1) Limit the number of computers that a user can join domain from ten (10) to zero (0) by performing the following procedure. 

• Run Adsiedit.msc on a domain controller as Domain Admin. Expand the Domain NC node. This node contains an object that begins with "DC=" and reflects the correct domain name. Right-click this object, and then click Properties.
• In the Select which properties to view box, click Both. In the Select a property to view box, click ms-DS-MachineAccountQuota.
• In the Edit Attribute box, change the number from 10 to 0.
• Click Set, and then click OK.

2) Before joining any new computers to AD, enforce a pre-staging procedure. It means pre-creating the computer objects on AD before joining the computers to domain. Do note that the computer name of pre-created object should match the local computer name of the new machine.

• To conduct pre-staging, fire-up "AD Users and Computers Console", go to the OU that the pre-staging computer objects should reside.
• Click "New" and "Computer". Name the object. Click on the "Change" button as follows to the delegated AD group for help-desk personnel or to the individual self-help user account.

• Inform the delegated users to join the new computer according to the object name. Upon successful joining, you should be able to view the computer properties, such as the Operating System versions.

EFS Recovery

There are 2 types of recovery for Encrypting File System (EFS): Key Recovery and Data Recovery. When there is a designated Key Recovery Agent (KRA) on a CA server, the KRA is authorized to retrieve the user's certificate and private key from the CA database. The user would then be able to use the recovered key to decrypt EFS files. The "Archive subject's encryption private key" in the template "Request Handling" tab should be enabled for archival. In addition, CA server must be prepared for key archival before any rollout, as the key archival should be encrypted by KRA key. As the KRA can retrieve any archived keys, there should be at least 2 different persons to be the CA administrator and the KRA separately. See "Understanding User Key Recovery".

Extract:
The recovery of a private key is a manual process that requires the user(s) to contact an administrative authority to perform the necessary processes. It should be a best practice of any organization to separate the roles of CA Officer and KRA as a minimum of two physical persons.

On the other hand, the Data Recovery Agent (DRA) is authorized the recover and decrypt all encrypted files. The DRA must be enrolled and added to the AD Group Policy to allow DRA to decrypt files.  Furthermore, DRA can be updated subsequently using Group Policy if there are any changes.

For further comparison (pros and cons) and the details on both recovery methods, refer to "Key Recovery vs Data Recovery Differences".

Remote EFS for Cross-Forest AD Users

I was working on a project that allows encrypting files on remote file share, which was not enabled by default. I've to setup the pre-requite infrastructure, including fully functional Active Directory, Public Key Infrastructure, roaming user profiles (RUP) and the file shares. Group policies would have to be configured to make everything happens. In addition, users from trusted forest must also be allowed to login to the resource forest, and be enrolled with EFS certificate to perform the same remote file encryption. I find there is a lack of clear and cohesive documentation regarding cross-forest support for remote EFS on Microsoft Technet. Here, I would attempt to document down what I did to make cross-forest for remote EFS operations work. Meanwhile, I would also thank the excellent Microsoft premium support team for providing me the necessary insights over multiple email to get it up and running.

Let's get started. First thing first, before performing cross-forest operations, you have to ensure same forest EFS operations work.

Understanding Remote EFS

Local EFS is pretty straightforward: encrypting file on local file-systems. Remote EFS comes in 2 versions: (1) remote encryption/decryption with SMB file share and (2) remote encryption/decryption with WebDAV (a.k.a Web folders). 

For (1) SMB mode, roaming user profiles for EFS certificate must be enabled, so that the file share server may impersonate the users and load the EFS keys from roaming user profiles to perform encryption/decryption on users' behalf. To enable impersonation, the file server must be trusted for delegation. As the file is decrypted when it leaves the server, the data across the network is left in plain-text. Hence, you'll have to deploy additional IPSec or SSL to protect the transport path. 

As for (2) WebDAV mode, the file is automatically copied from the Web folder to the user’s computer, encrypted on the user’s computer, and then returned to the Web folder over HTTPS. The advantage is that the computer hosting the Web folder does not need to be trusted for delegation and does not require roaming or remote user profiles. However, it comes with a serious limitation. I've tested it to be rather "slow" in access performance and Microsoft recommends that the file size should be kept below 60MB.

Refer to this Technet link on Remote EFS Operations for further information. In this post, I would focus solely on (1) Remote EFS with SMB file share. 

Phase 1: Remote EFS on SMB file share within Forest

• Provision network share and enable roaming user profiles for users. See "Deploy Roaming User Profiles"
• Setup Active Directory Certificate Services and configure EFS certificate auto-enrollment for users. See "AD CS and PKI Step-by-Steps, Labs, Walkthroughs, HowTo, and Examples"
• Login with a test user account on a client machine. Verify that an EFS certificate has been auto-enrolled using "certmgr.msc". Logout the user, so that the roaming cert can be synced to the RUP.
• Login again with the same user account. Verify that the EFS cert has been synced to the RUP folders. See this roaming cert troubleshooting guide
• Setup a file server and provision a network share for remote EFS. Delegate the file server to be trusted. See "Remote Storage of Encrypted Files Using SMB File Shares and WebDAV"
• Map the network drive on the client machine. Try to create some files and encrypt them. Verify that the files are encrypted with the same certs on your profiles. Otherwise, the file server might be requesting a new EFS cert on your behalf instead of loading it from RUP. If the files fail to encrypt,  it could due to different roaming profile folder structures created by different Windows client version. See this troubleshooting guide.

Phase 2: Supporting cross-forest users for certificate auto-enrollment and remote EFS

• Setup two-way forest trust. In this context, this forest (hosting resources, such as file servers etc)  is known as "resource forest". The forest where users come from is known as "account forest". Create new security group with "Domain Local" scope and add cross-forest users to this group.
• Allow "Read" and "Auto-enrollment" for the cross-forest group to the EFS user template
• Configure Cross forest certificate enrollment. Run the "PKIsync.ps1" script to sync PKI objects, which is critical to facilitate cross-forest enrollment. Run the command on the account forest with "Enterprise Admin" rights specifying the source and target forests. 
• The Technet link for cross-forest enrollment above missed out the step of copying the pkiEnrollmentService object over (i.e. certutil -config can't be used). Use this command instead:

• PKISync.ps1 -sourceforest source.local -targetforest target.local -type CA -cn "CA-Name"

• To verify the cert templates have been copied over, use the "AD Sites and Services" on the target DC, click "View" and tick "Show Service Node". Look under the folder "Services\Public Key Services\Certificate Template" to check the templates.
• Add the Issuing CA server to the "Cert Publishers" Domain Local group on the account forest. 
• Enable LDAP referral support on enterprise CAs: certutil -setreg Policy\EditFlags +EDITF_ENABLELDAPREFERRALS
• Deploy group policy to enable "Allow Cross-Forest User Policy and Roaming User Profiles" and set "roaming profile path for all users logging onto this computer" on the client machines for cross-forest users, as well as the file servers as shown below:

• User group policy would not take effect for cross-forest user logon to domain computer. To configure user policy, configure loopback policy to facilitate auto-enrollment on client computers logon by cross-forest users  Even if you don't enable it explicitly, loopback with replace mode would still be enabled for cross-forest user login by default. Enable Auto-enrollment on user configuration. Leave the "Certificate Enrollment Policy" as "Not configured".

• Test domain logon using a cross-forest user account. Perform the same verification procedures as earlier mentioned for single forest operations.
• If remote EFS operations fail, despite auto-enrollment works and the RUP certs are synced, it might be due to the group policy fail to take effect on the file server. The server attempts to impersonate a cross-forest user but is disallowed by default as shown on event viewer below. Furthermore, the server is not aware of the location of RUP folders for cross-forest users. 

• Apply gpupdate and gpresult /h gpresult.html on the file server. Ensure "Allow Cross-Forest User Policy and Roaming User Profiles" and "roaming profile path for all users logging onto this computer" are applied 
• Cross-forest users should be able to perform remote EFS operations on this resource forest.

Modifying Built-in AD Objects

While working on cross-forest cert enrollment, I noticed I couldn't add an cross-forest object to an AD built-in group object, e.g. "Cert Publishers" group. The built-in group is of "Global Security" scope that is unable to add objects outside a forest. Rightfully, it should be of "Domain Local" type, so that cross-forest objects can be added. If it's not a built-in object, we can simply change it to "Universal" and then "Domain Local" using "AD users and computers" console. 

Nevertheless, we can use the SYSTEM account to modify the built-in group scope.

1. Download pstools from link: http://technet.microsoft.com/en-us/sysinternals/bb896649.aspx.
2. Extract it and get psexec.exe and copy it to a Domain Controller (DC).
3. Open new command and run the command psexec.exe -s “cmd”, click Accept/Yes.
4. We will get a new command that run under System account.
5. Under new command prompt, please run the command below:

                dsmod group “CN=Cert Publishers,CN=Users,DC=contoso,DC=com” -scope U
                dsmod group “CN=Cert Publishers,CN=Users,DC=contoso,DC=com” -scope L

This would convert built-in group scope to Domain Local.

Note: If the AD was first created on Windows Server 2000, the group scope type was created "Global Security" and would remain as it was, even when there was AD prep and upgrade subsequently.

Verifying SIDHistory of user accounts

When you're performing user and resource migration between forests with trust, it's important to enable SIDHistory and disable SID quarantine during the migration process. As migrated users on target forest will get new domain SIDs, it's important for them to retain the old SIDs in their originating forest. This is to ensure that the migrated users on new target forest are still able to access resources in the source forest until the migration is complete.  This blog post sums it up using Active Directory Migration Tool (ADMT).

But how to verify a SID history of the migrated user is of the same SID in the source forest?

On new target forest:

dsquery * -Filter "(samaccountname=userid)" -attr sidHistory

On source forest:

dsquery * -Filter "(samaccountname=userid)" -attr objectSid

Compare the SID values of both output and ensure they are the same.

Setting the ACL for Home and Roaming Profiles

Wonder how should you set the ACL of Share and NTFS of the network share for Users' Home folders and Roaming Profiles? Check out this Technet Blog: Automatic creation of user folders for home, roaming profile and redirected folders

By default, all newly created folders are set with inheritable permissions that include Read permission for all users. As a result, users would be able to see all other users' home folders. Access Based Enumeration (ABE) is designed to prevent users from viewing other folders that they have no read access. It can be easily enabled on the "Share and Storage Management" console. However, inheritable permission get in the way because it permits all users to have "Read" access to all folders.

For ABE to work, you'll have to remove that inheritable permissions after the users' home folders are automatically created. You can have a Powershell Script that take in CSV file (exported by csvde) and remove all inheritable permissions on the user home folders. And this is my script:

import-csv C:\temp\users.csv | foreach-object {
  # individual user name
  $user = $_.sAMAccountName
  # user home folder
  $newPath = Join-Path "\\FileShare\Home$" -ChildPath $user
  $acl = Get-Acl $newPath
  # this would remove inheritable permission
  $acl.SetAccessRuleProtection($true,$false)
  # additional custom permission added (optional)
  $permission = "MyDomain\$user","Modify","Allow"
  $accessRule = New-Object System.Security.AccessControl.FileSystemAccessRule $permission
  $acl.SetAccessRule($accessRule)
  $acl | Set-Acl $newPath
}

If you happen to encounter situation whereby you can't move or remove the user profile folders, you'll have to take ownership of the folder recursively. Here're the command lines:
takeown /F folder-name /R /D y 
icacls folder-name /grant administrators:F /T

How to rebuild AD-integrated DNS servers

What if a joker wipe out your AD integrated DNS zones accidentally? And there's no backup? You'll find out soon enough that AD operations are heavily dependent on the DNS services.

You'll then have to rebuild the DNS manually by re-creating 2 DNS zone files namely: yourdomain.dns and _msdcs.yourdomain.dns. When non-AD integrated, both zone files should be stored on the system dns folder on %Systemdrive%\System32\dns\ e.g. C:\Windows\System32\dns

1. On all of your AD-integrated DNS servers, change both forward primary and _msdcs zones to Standard Primary zones by unchecking the "Store the zone in Active Directory" box. Backup both existing dns files on the system dns folder. Delete both primary and _msdcs zones using the DNS manager.
2. Next, you'll need to know the DNS zone file syntax. There are sample files available under the \dns\sample. Another easier way is to go to another DNS server belonging to another intact domain. Change both primary and _msdcs zones to Secondary Zone temporarily and you'll find the 2 files located on the system dns folder for your reference. Copy out the files and remember to change them back to AD-integrated.
3. Re-create both zone files using notepad/wordpad and store them on the system dns folder. Pay special attention on SRV records like _ldap, _kerberos, _dc._tcp.domain  etc for "referring" your clients to the domain controllers for authentication. Remember to keep a backup copy for both files.
4. On your DNS manager, create new standard primary zone (do not integrate with AD yet!) under the forward zones and named it after your domain. On the "Zone File" page of the setup wizard, choose to "Use this existing files". Repeat the same step for _msdcs zones.
5. Restart DNS and netlogon services by using "net stop/start dns/netlogon" respectively.
6. Test and check all entries. Rectify any errors found.
7. Once you're happy with the DNS settings, integrate the DNS server into Active Directory by checking the same box earlier in step 1.
8. If you have dynamic DNS records, execute "ipconfig /registerdns" on each dynamic DNS client. Otherwise, just wait for the clients to get back online.
9. On each subsequent DNS server, check that the DNS zone is back. Otherwise, create a new secondary zone and a new _msdcs zone. Reference them to the DNS server that you first re-created. Make sure the entries are replicated correctly. If replication fails, check the "Zone Transfer" setting on the first DNS server.
10. Once replication is successful, change both secondary zones to primary zones. Integrate both zones into AD. Reboot the DNS server.

AD authentication for Dell iDRAC6

The well-known default login name and password for iDRAC6 are "root" and "calvin" respectively. You should change it immediately, which may probably turn into accountability issues of having shared password among various administrators. A better way is to configure it to permit AD authentication that allows individual login accounts and ensures consistent password policies.

Step 0: Configure IP and DNS settings on iDRAC

Step 1:Enable Microsoft Active Directory on "Directory Service" under "Network/Security"

Step 2: Enable cert validation and upload the Enterprise CA cert.

Step 3: Choose Standard Schema

Step 4: Enter the fqdn of domain controllers e.g. dc1.domain.com. Define the user groups on AD and authorize appropriate rights accordingly.

 

Step 5: Lastly, test the settings. Supply the test account name using "user@domain.com" format instead of "domain\user" format that won't work.

Credential Roaming

Credential Roaming (CR) is especially useful in situations whereby the following 2 conditions exist: (1) user certificate auto-enrollment is enabled; (2) many user tends to logon more than 1 domain machine. You can imagine how many certificates for the same group of users are issued on your CA server if credential roaming were not enabled. No problem for domain logon, as UPN remains the same across multiple user certs. But for applications, such as S/MIME, encryption/decryption using the same cert key becomes a must for roaming users. Do note that only X.509 certificates and private keys are supported and they are stored on the Active Directory certificate store (so beware of potential NTDS bloat but that's another issue).

CR is a new alternative to Roaming User Profile (RUP) for storing user certificates and keys. According to Microsoft, CR is also supposed to be a more scalable and secure alternative than RUP. Whenever a user logon and logoff, the local user cert store would always sync with the AD cert store. Hence, the same user would always get the same cert and key regardless of what domain machines he log-on to.

Depending on your current AD level, you may or may not need to update the AD schema. For Windows 2003, refer to this guide. For Windows 2008, you can refer to this simpler guide instead.  

Migration from FRS to DFRS with RODC

Traditionally, File Replication Service (FRS) is used for replicating the contents of the SYSVOL share between Windows domain controllers (a.ka. AD replication). A new AD DS feature in Windows Server 2008 can use the DFS Replication (DFSR) service for replicating the contents of the SYSVOL share. DFSR offers several advantages over FRS, including

1. Efficient, scalable and reliable file replication protocol which has been tested extensively to ensure data consistency in multi-master replication scenarios.
2. Differential replication of changes to files using the Remote Differential Compression (RDC) algorithm, which enhances efficiency in branch office scenarios.
3. Flexible scheduling and bandwidth throttling mechanisms.
4. Self-heals from USN journal wraps and database corruptions – end user intervention and monitoring requirement is minimal.
5. Provides built in health monitoring tools for ease of monitoring deployments.
6. Improved support for Read Only Domain Controllers.

Click here to find detailed step-by-step migration guide, which comprises a 5-part series. A quicker step-by-step can be found here. Generally, migration is pretty easy and straightforward. However, if you have promoted a Read-Only Domain Controller (RODC) before the migration is complete, you will see the following error:

The RODC will never move to the next step beyond 'Start'. To resolve it, perform the following command on the PDC emulator:

• dfsrmig /DeleteRoNtfrsMember: Since Read Only Domain Controllers cannot delete the FRS related global settings from their own Active Directory, this operation needs to be performed by the Primary Domain Controller in its Active Directory. When these changes eventually replicate in to the Read Only Domain Controller (after applicable AD Replication latencies), the DFS Replication service on the RODC is able to proceed with the process of migration.

When you run dfsrmig /getGlobalState again, the RODC entry will disappear. Issue repadmin /syncall on PDC emulator to sync with all domain controllers (including RODCs).

Resetting Computer Account

A domain computer account synchronizes with the Domain Controller (DC) on a regular basis. This means that the computer checks with the DC or the DC checks for the computer on the network at a set interval. If for some reason synchronization does not take place, then the computer account can become invalid due to failed authentication. Group policy may also fail to take effect.

Each domain computer maintains a machine account password history containing the current and previous passwords used for the account. When the computer attempt to authenticate with DC and a change to the current password is not yet received, Windows then relies on the previous password. If this authentication fails (due to the failed sync of password), both computers may not communicate. Hence, you have to reset the computer password. You can't set the password directly but you can perform a computer account reset on the "Active Directory User and Computer" console or "netdom reset" on a DC.

After you have reset the computer account, you won't be able to login to the affected computer using domain-based accounts. You have to re-join the computer to domain, so that the AD re-sync can take place. Login to the affected computer on local administrator account. At the elevated command prompt,

1. Force leave the domain: netdom remove %computername% /domain:{domain-name} /force
2. Re-join the domain: netdom join %computername% /domain:{domain-name} /UserD:{domain user} /PasswordD:{domain password}
3. Reboot the computer