A few days ago I was chatting with a colleague of mine in the UK about automated permissions assignment in AD through DSACLS. His reason to do this was because of CLM deployments where you had to use different kinds of Extended Rights that are defined in AD throughout the AD environment. Each AD deployment by default contains a set of Extended Rights that are defined in the Configuration container. The path where the Extended Rights are defined is: "CN=Extended-Rights,CN=Configuration,DC=<FOREST ROOT DOMAIN>,DC=<TLD>". Below you can see a picture of it.
This list of Extended Rights is built when the AD forest is created and that of course occurs when the very first RWDC is installed for that AD forest. How that list is built is also not difficult. On each W2K server and higher a file called 'SCHEMA.INI' exists. That file contains instructions for DCPROMO to carry out depending on the choices and values specified for DCPROMO. Although possible, Microsoft does not support any custom changes to the file 'SCHEMA.INI'. So, let's suggest NOT TO MODIFY this file!
As soon as you install some product (e.g. AD upgrade, Exchange, CLM, etc.) that requires additional Extended Rights, these are additional Extended Rights are defined in the accompanying LDF files to be created when the AD schema is extended to support that particular product.
That same colleague told me that for Certificate Services and for CLM he was able to use DSACLS for every related Extended Right except for one. For that one he said he had to do it manually. As you may know certificate templates may have two specific certificate template related permissions. One being "Enroll" and the other one being "AutoEnroll" as you can see below.
As you see, in addition to "Allow:Read" I also assigned "Domain Users" both the "Allow:Enroll" and the "Allow:Autoenrollment" permissions (Extended Rights) on the certificate template called "User v2". Let's have a look how that would look like in LDP. That picture is shown below.
You can see the "Allow:Read", the "Allow Enroll" and some weird permission with a GUID. What the heck is that? Well, that's easy. Each Extended Right has an attribute called "rightsGuid". For more information on this attribute see this. But why is the name shown for one Extended Right and a GUID for the other? Let's have a look at that with ADFIND and retrieve more information about those two Extended Rights.
ADFIND -config -f "(&(objectClass=controlAccessRight)(displayName=Enroll))"
ADFIND -config -f "(&(objectClass=controlAccessRight)(rightsGuid=a05b8cc2-17bc-4802-a710-e7c15ab866a2))"
Hey, what's going on here? Not objects with that rightsGuid? It looks like the Extended Rights is not defined in the Extended Rights container in the Configuration NC. That's weird! This occurs in W2K (computer only), W2K3 and W2K8. To configure the "Allow:Enroll" permission on the "User v2" certificate template you could use DSACLS like:
DSACLS "CN=Userv2,CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=<FOREST ROOT DOMAIN>,DC=<TLD>" /G "Domain Users:CA;Enroll"
This was what my colleague was talking about. He was not able to use DSACLS with the name of the AutoEnroll Extended Right. For the "Allow:Autoenroll" permission you would/could NOT use the following:
DSACLS "CN=Userv2,CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=<FOREST ROOT DOMAIN>,DC=<TLD>" /G "Domain Users:CA;a05b8cc2-17bc-4802-a710-e7c15ab866a2"
Why? Well, DSACLS expects a name and then translates that to a rightsGuid. It cannot use the rightsGuid directly. The only way to define this Extended Right is to either use the GUI ("CERTTMPL.MSC") or through some tool that does support the use of the RightsGuid directly. However, there is another way if you really want to use DSACLS to automate the configuration of the non-existing Extended Right. The solution to that is to just define your own Extended Right with that specific rightsGuid in the Extended Rights container in the Configuration NC.
First, let's have a look at how the "Enroll" Extended Right looks like and analyze what must be done to create your own Extended Right. Have a look at the picture below.
When creating your own Extended Right in AD you need to define at least the following attributes to be complete (for more information on those attributes click the link to go to MSDN):
- objectClass: This attribute specifies the list of classes of which this object is an instance
- cn: This attribute specifies the name that represents an object
- displayName: This attribute specifies the display name for an object
- showInAdvancedViewOnly: This attribute specifies whether the attribute is to be visible in the Advanced mode of user interfaces (UIs). Active Directory snap-ins read this attribute
- rightsGuid: This attribute specifies the GUID used to represent an extended right within an access control entry (ACE)
- appliesTo: This attribute specifies the list of object classes that an extended right applies to.
- validAccesses: This attribute specifies the type of access that is permitted with an extended right
For the new Extended Right you would need to provide the following values:
- objectClass = controlAccessRight
- cn = Certificate-AutoEnrollment
- displayName = AutoEnrollment
- showInAdvancedViewOnly = TRUE
- rightsGuid = a05b8cc2-17bc-4802-a710-e7c15ab866a2 (the GUID we found above)
- appliesTo = e5209ca2-3bba-11d2-90cc-00c04fd91ab1 (the schemaIDGUID of Certificate Template objects which have an objectClass of "pKICertificateTemplate")
- validAccesses = 256
You can either use ADSIEDIT.MSC to create the object or you can use ADMOD. Using ADMOD the command line syntax to create the controlAccessRight object is:
ADMOD -replacedn XXX-CONFIG-XXX:_config -add -b "CN=Certificate-AutoEnrollment,CN=Extended-Rights,XXX-CONFIG-XXX" "objectClass::controlAccessRight" "displayName::AutoEnrollment" "showInAdvancedViewOnly::TRUE" "rightsGuid::a05b8cc2-17bc-4802-a710-e7c15ab866a2" "appliesTo::e5209ca2-3bba-11d2-90cc-00c04fd91ab1" "validAccesses::256"
REMARK: At this moment I did not configure the ACL of the new controlAccessRight object to match the ACL of for example the controlAccessRight object "CN=Certificate-Enrollment,CN=Extended-Rights,CN=Configuration,DC=<FOREST ROOT DOMAIN>,DC=<TLD>". This could be done easily using ADSIEDIT.MSC!
The result is shown in the picture below.
Now let's rerun the following query: ADFIND -config -f "rightsGuid=a05b8cc2-17bc-4802-a710-e7c15ab866a2". It should find an object now.
Now let's use DSACLS to configure the "AutoEnrollment" Extended Right for Domain Users (I have removed it first using the GUI)
DSACLS "CN=Userv2,CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=<FOREST ROOT DOMAIN>,DC=<TLD>" /G "Domain Users:CA;AutoEnrollment"
Let's now have a look at how LDP displays the permissions. Make sure to first close and reopen LDP! See the picture below.
As you can see, the rightsGUID is not shown anymore, but its displayName. The system is now able to translate the rightsGUID into its human readable name.
And as you have seen, you are now able to use DSACLS to configure the Extended Right called "AutoEnrollment" on certificate templates! Have fun!
Cheers,
Jorge
--------------------------------------------------------------------------------------------------
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always test before implementing!
--------------------------------------------------------------------------------------------------
############### Jorge's Quest For Knowledge ###############
######## http://blogs.dirteam.com/blogs/jorge/default.aspx #########
--------------------------------------------------------------------------------------------------