Beyond AdminSDHolder Object

Many people should know the object AdminSDHolder and what it does by now. It checks and reverts back protected group's ACL periodically, if found modified. This is a desirable feature (if you know how it works otherwise you will really be surprised). However, on the top of the above knowledge, it's also tricky to get a user's permission changed if he is a former member of protected group.

For example, if John was Domain Admin and later became a normal user. You will find out that John's permission still gets reverted periodically. This is very hard to figure if you didn't know the history of John's account. To correct this, two things need to be done before permissions can be changed.

1. Change adminCount's value to 0
2. Enable "inheritance"

Alternative Way To Recover Deleted Objects

The recommended way to recover a deleted user or group is through Authorized Restore. It's not always desirable, however. It requires you to take the DC offline, normally for a time length that most of business can't tolerant, depending on how fast you can retore from backup.

With Windows 2003 AD, Microsoft provides another way to move tomestoned objects back to their original state, partially. Basically, you have to specify "Return Deleted Objects" in order to search deleted objects; and you then remove its isDeleted attribute and replace the DN with the location you want this object to be.

Side note: Controls are a mechanism, defined in the LDAP standard, used to extend the LDAP protocol to provide additional functionality beyond what is defined in standard LDAP while remaining compatible with other LDAP-compliant software. AD supports 22 controls, including "return Deleted Objects" control.

How to reset secure channel for DCs

This post is about resetting secure channel between domain controller and PDC. Another type of secure channel resetting, much more common for most of administrators, is done between a member machine and AD, which can be achieved by:
 

netdom reset /domain:YourDomainName

Instead of running above command, many administrators will simply disjoin and rejoin domain. It should resolve the problem -*if*- it's indeed a secure channel issue. Disjoin/rejoin will reset many other things along the way therefore it's cleaner.

Now back to our topic. Resetting secure channel for a DC should be done only when the a problematic DC can't authenticated with PDC. Symptoms include:

- "The target principal name is incorrect"
- \\IP\shared folder works but not \\computerName\share
- Replication fails but network seems to be fine (all ports are open)
- User get "access denied"
- Kerberos event 3 or 4

Step-by-step:

1. Identify PDC

    "netdom query fsmo"

2. Disable the KDC service on the DC in question (the DC whose password you want to reset), (don't forget to) reboot
3. On DC in question, run

    netdom resetpwd /server:PDC_name /userd:Domain\admin /passwordd:admin_pwd

4. Reboot again regardless if step 3 is successful (you should focus on why step 3 fails though)
5. Enable and start KDC
6. Verify if this resolve the issue
7. (Optional) Even it's not required, but you are strongly encouraged to reboot the DC again. Also if the reset was for troubleshooting replication issues, it's recommended to trigger a KCC cycle to re-generate the replication topology.

You can reset secure channel as many times as you want, but it only resolves issues that are out-of-sync in nature (remember computer accounts have password too and need to authenticated to each other). It won't help you if you have underlying network or DNS issue. And most AD issues are caused by mis-configured DNS, I should say!

In short, if you have a member server/workstation that don't seem to talk to the rest of the domain, you may want to reset secure channel on the workstation. If you have a DC that doesn't replicate or doesn't talk to other DCs, you want to reset that DC's secure channel. The commands used are quite different.

Edit (2011.11.05):
Similar to what you can do with member servers, if a DC's secure channel fails to reset, you can just demote it and promote it back. However there are a few things you need to take into consideration before demote:

• Is this DC holding any fsmo role? Can you still transfer roles(most likely you can't due to failing secure channel)? Do you need to seize its roles?
• If you have to do a force demote, do remember to perform metadata clean up
• Is this DC a DNS server? Remember to remove it from your zone server list. Also consider the impact to clients that are using this server as their DNS server
• Any other services this DC provides?

Last but not least, I can't stress enough how important DNS/connectivity is. If there is something wrong with DNS/network, demote/promote won't fix the issue.