Announcing the availability of the Active Directory Delegation whitepaper
Sanjay Tandon
The Active Directory Delegation whitepaper titled Best Practices for Delegating Active Directory Administration is now available for download. Also available are the Appendices accompanying the whitepaper and the dsrevoke tool which is referenced in the whitepaper. The whitepaper, the appendices and the dsrevoke tool can all be downloaded at http://www.microsoft.com/downloads by performing a keyword search on Active Directory Delegation.
This whitepaper provides best-practices on how to use delegation of administration to securely distribute and delegate administrative responsibilities involved in securely managing an Active Directory infrastructure. The accompanying appendices contain a wealth of information, from documenting the specific permissions required to delegate almost all Active Directory management tasks to describing how to use all the Active Directory delegation tools available today to providing an updated delegwiz.inf file that allows you to delegate more than 70 administrative tasks. The dsrevoke tool can be used to report on and un-delegate administrative authority.
I hope you will find the best-practices and the information provided in this whitepaper useful and I hope it will help your customers increase the security of their Active Directory deployments, decrease their TCO and make management of even large and dynamic Active Directory deployments more efficient and tractable.
Thank you.
Sanjay Tandon
Program Manager
Active Directory Security
Windows Server Division
Microsoft Corporation
Bob
Delegation whitepaper")
LS,
Has anyone actually already tried to implement this whitepaper?
(A bit long, but in short this "story" tells that I find the whitepaper
"incomplete", and discovers an OU that resets inheritance when creating a
sub-object.)
I'm currently trying to implement it, but are running into a lot of
problems. The idea of delegation in the document is fine (matter of
opinion), but the appendix with instructions how to delegate appropriate
rights to the delegated groups is.....not entirely correct.
If you disregards the instruction(s) that tell you to add domain local
groups to the membership of BUILTIN\Administrators (you can't nest that
group, not even in native/Windows2003 mode) (p. 192, Implementing the Domain
Controller Administrators Role, step 2) or the addition of a universal group
to a domain global group (not possible in any mode) (p. 195, Implementing
the DNS Admins role, step 5), there are still some technical issues.
Site delegation:
The delegation of Replication (site) management is incomplete (p. 193,
Implementing the Replication Management Admins Role, step 3); On the Sites
container the right to create "Site" (and "Connection") objects is
configured.
When, after following the procedure, making a Site through the "Sites and
Services" MMC snap-in, a site is created, but without any of the sub-objects
(licensing, NTDS settings). What is needed there is (amongst others) also
the right to create objects of type "licensingSiteSettings" and
"nTDSSiteSettings" or even the "serversContainer" object/container in which
the server(s) needs to be placed. But since the right to create those
objects
is not delegated, site creation (complete one) fails.
Might you think that you can force replication with this procedure,
unfortunately
directory configuration is again incomplete; as can be seen in a posting to
this group by Tim Springston [MSFT] ("Re: Delegation of Replication"),
specific rights need to be set ("Replication-Synchronisation") which don't
appear in the whitepaper.
DNS delegation: (automatic disappearence of inheritance???)
With the definition of activities of the role "DNS Admins" it is not
specified that that group should be allowed to create (static) A-records (or
other static records). With our implementation we DO want that group to be
able to create records, or even remove other records if needed. To this end
I used procedure "Implementing the DNS Admins role" (p. 195) and used
inheritance of rights in step 2 and 4 (since whether or not to use
inheritance is not specified I first assumed to use it).
After implementation of this, the security had been inherited over all the
records in the DNS zones, and I was happy. Then I created a primary forest
zone (reverse lookup, to test activities with the delegated group) and
suddenly
my inherited rights had disappeared!
After investigation the following became clear (repeatable):
1 - Give "<Forest>-DnsAdmins" (or other custom group) full control to
CN=MicrosoftDNS,DC=ForestDnsZones,DC=<Forest root domain>, WITH inheritance
(this object and all subobjects) and see all sub-objects, having inherited
rights of this group.
2 - Create a new forest DNS zone
3 - See for yourself that the right given in step 1 has been transformed to
NOT-inherited (This object only)
Auditing reveals that this is "corrected" by a process running under the
SYSTEM account, after creation of a new DNS zone.
At first is seems like a container under security control such as
Administrators group is with the AdminDSHolder, but then again it only
"corrected" the inheritance bit!?!
This apparently automatic correction prevents my goal to make sure that my
DNS group has sufficient right on currently present DNS zones, but also on
DNS zones created in the future!
Anyone familiar with this mysterious correction "feature"?
(The same behavior appears on the
CN=MicrosoftDNS,DC=DomainDnsZone,DC=<domain> container as well)
At this moment we have not yet completed our implementation, but I wanted
others to share in my information. If I have done things wrong or
misunderstood or if you can clarify, please let me know.
Greetz,
Bob
PS To respond by mail, remove "vanden." from the address.
"Sanjay Tandon" <anon...@discussions.microsoft.com> wrote in message
news:4CF10196-5792-4D1E...@microsoft.com...