DFS Namespaces have really poor options in terms of permissions delegation. Either someone can edit everything about a namespace or they can’t. This led in my case to someone deleting the entire namespace while making other edits. Other than the “Are You Sure?” dialog it didn’t require for any other sort of confirmation before removing the object from Active Directory, removing the shares from the hosting servers, and generally putting File Sharing back to the stone age. Recovering from this was a multi-step process, involving recovering the CN=<name of your dfs namespace>,CN=Dfs-Configuration,CN=System,DC=<domain DN> object (The pkT attribute of that object appears to contain a binary representation of the links and targets in that namespace.), restoring the root share on the root server(s) and restoring registry settings related to those DFS shares.
- Restore the CN=<name of your dfs namespace>,CN=Dfs-Configuration,CN=System,DC=<domain DN> object from backup.
- In this case the individual object was available from a brick level backup, much easier than doing an Authoritative Restore.
- Re-share the folder on the root server(s), giving whatever permissions were appropriate.
- As a rule of thumb, I would not put files in the root of a DFS share, mostly for cleanliness, but it also helps in this case. No files in the actual root means the share can be added with basic permissions (Admin Full, User Read).
- Re-create or restore the registry settings
- In this case it is a 2000 style DFS Namespace, so the registry entries which needed to be restored are under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Dfs\Roots\Domain
- 3 entries need to be recreated for each deleted Namespace
- A Key with the name of the Namespace, and the next two entries underneath
- A String with the name LogicalShare and the value <sharename>
- A String with the name RootShare and the value <sharename>
- Restart the DFS Namespace service on the hosting servers.
And now, \\DOMAIN\<namespace> should be restored, all of the links/targets in place as they were.
ADFS site configured for Integrated Auth continually prompts for password when DNS hostname is a CNAME
I have bad habits by some accounts. I like CNAMEs. In my mind, they allow for easy changes to the DNS namespace without having to remember IPs, and in that way create simplicity. But they are invariably frowned upon for various reasons, they create additional DNS traffic, aren’t compatible with other record types on the same namespace (MX for instance).
I’ve run into a case where use of a CNAME breaks expected functionality. In an environment using Active Directory Federation Services, if the hostname of the federation service resolves to a CNAME, Windows Integrated Authentication will not work. As an example:
CNAME federation.example.com -> adfs.example.com A adfs.example.com -> 192.168.1.10
The federation service hostname as configured in ADFS is federation.example.com and the actual servername of the federation server is adfs.example.com. You attempt to access a URL of the federation service under the federation.example.com namespace, and instead of being authenticated transparently you are prompted for a username and password as below.
Repeated attempts to enter the password fail, eventually resulting in a 401 page. Replacing the DNS CNAME with an A that points to the same IP resolves this issue. Config as below:
A federation.example.com -> 192.168.1.10 A adfs.example.com -> 192.168.1.10
This is documented, though not as a bug, and I would not expect it to be fixed.
KB2461628 – Note resolution #4