Jorge's Quest For Knowledge!

All about Windows Server, ADDS, ADFS & ILM/FIM (It is just like an addiction, The more you have, the more you want to have!)

Archive for the ‘Active Directory Certificate Services (ADCS)’ Category

(2012-02-10) Managing Certificates On A Windows Computer With PowerShell

Posted by Jorge on 2012-02-10

To manage certificates on a computer, you can use the “Certificates” MMC. With that MMC you scope either the (local) computer or the current user or even both. For either scope you will find different certificate stores that contain the different certificates, with or without the private key.

image

Figure 1: Scoping The Certificates MMC And The Different Certificate Stores For Either Scope

-

Common management tasks are shown in the pictures below.

image

Figure 2a: Common Management Tasks For Certificates (For Existing Certificates In Stores)

-

image

Figure 2b: Common Management Tasks For Certificates (For New Certificates)

-

Now this is the way of doing it through the GUI. Can you do this through PowerShell to achieve automation? Yes, you can. I will provide you with examples for a few functions.

-

By default, when starting PowerShell a few default PowerShell Drivers are loaded and available. To view the current available PSDrives, use the CMDlet “Get-PSDrive”.

image

Figure 3: PS Drives Loaded And Available Right After Starting PowerShell

-

As you can see there is a PS Drive called “cert”. That’s the one you can use to manage existing certificates through PowerShell. When you issue the PoSH command “dir cert:\” you will see the two available scopes (or locations), including the available stores.

image

Figure 4: Scopes (Locations) And The Certificate Stores

-

When you issue the PoSH command “dir cert:\LocalMachine” or “dir cert:\CurrentUser”, you will see all the available stores for each scope more clear.

image image

Figure 5: All The Certificate Stores For Each Scope (Location) (! May Be Different For Another Computer !)

-

When you issue the PoSH command “dir cert:\LocalMachine\<Cert Store>” or “dir cert:\CurrentUser\<Cert Store>”, you will see all the available certificates in that store.

image

Figure 6: All The Available Certificates In The Personal Store Of The Local Computer

-

Now with this knowledge it is possible to manage those certificates.

-

Exporting Certificates WITHOUT The Private Key

By using the following PoSH commands you can export the certificate to a CER file without the private key, if any.

# Find And Target The Cert Required Based Upon Some Condition $CertToExport = dir cert:\LocalMachine\My | where {$_.ThumbPrint -eq "EC9498B48CA4E48EB8D5BC557BCFBC09B5A02651"} # Export The Targeted Cert In Bytes For The CER format $CertToExportInBytesForCERFile = $CertToExport.export("Cert") # Write The Files Based Upon The Exported Bytes [system.IO.file]::WriteAllBytes("D:\Temp\CertToExportCERFile.CER", $CertToExportInBytesForCERFile)

-

Exporting Certificates WITH The Private Key

By using the following PoSH commands you can export the certificate to a PFX file with the private key and protect it with a password.

# Find And Target The Cert Required Based Upon Some Condition $CertToExport = dir cert:\LocalMachine\My | where {$_.ThumbPrint -eq "EC9498B48CA4E48EB8D5BC557BCFBC09B5A02651"} # Define Cert Type When Exporting To PFX $CertType = [System.Security.Cryptography.X509Certificates.X509ContentType]::pfx # Define The Password To Protect The Private Key # (ALSO see: http://jorgequestforknowledge.wordpress.com/2011/12/15/passwords-containing-special-characters-in-powershell/) $PrivateKeyPassword = 'Pa$$w0rd' # Export The Targeted Cert In Bytes For The PFX format While Specifying A Password # REMARK: It Must Be Allowed To Export The Private Key, Otherwise You Will See The Error "Key not valid for use in specified state" $CertToExportInBytesForPFXFile = $CertToExport.export($CertType, $PrivateKeyPassword) # Write The Files Based Upon The Exported Bytes [system.IO.file]::WriteAllBytes("D:\Temp\CertToExportPFXFile.PFX", $CertToExportInBytesForPFXFile)

-

Managing The Permissions On The Private Keys

By using the following PoSH commands you can manage the permissions on the private key of a certificate.

# Find And Target The Cert Required Based Upon Some Condition $CertToAdjustPermissions = dir cert:\LocalMachine\My | where {$_.ThumbPrint -eq "EC9498B48CA4E48EB8D5BC557BCFBC09B5A02651"} # Possible Values For File System Based Access Rights Are # * ListDirectory, ReadData, WriteData # * CreateFiles, CreateDirectories, AppendData # * ReadExtendedAttributes, WriteExtendedAttributes, Traverse # * ExecuteFile, DeleteSubdirectoriesAndFiles, ReadAttributes # * WriteAttributes, Write, Delete # * ReadPermissions, Read, ReadAndExecute # * Modify, ChangePermissions, TakeOwnership # * Synchronize, FullControl # Specify The User, The Permissions And The Permission Type $ACE = "ADCORP\ADM.ROOT","Read,Synchronize","Allow" # Define A New File System Based Access Rule Based Upon The Previus ACE $AccessRule = new-object System.Security.AccessControl.FileSystemAccessRule $ACE # The Location Of The Machine Related Keys Can Be Found In The Following Location $MachineKeysLocation = $env:ALLUSERSPROFILE + "\Microsoft\Crypto\RSA\MachineKeys\" # Configuring ACE On Private Key Of Targeted Cert To Allow User Account To READ It (EXAMPLE!) $KeyFileCertToAdjustPermissions = $CertToAdjustPermissions.PrivateKey.CspKeyContainerInfo.UniqueKeyContainerName $KeyFileLocationCertToAdjustPermissions = $MachineKeysLocation + $KeyFileCertToAdjustPermissions # Get The Current ACL Of The Private Key $KeyFileCertToAdjustPermissionsACL = Get-Acl $KeyFileLocationCertToAdjustPermissions # Add The New ACE To The ACL Of The Private Key $KeyFileCertToAdjustPermissionsACL.SetAccessRule($AccessRule) # Write Back The New ACL $KeyFileCertToAdjustPermissionsACL | Set-Acl $KeyFileLocationCertToAdjustPermissions

Importing Certificates WITHOUT The Private Key

By using the following PoSH commands you can import the targeted certificate without the private key into the specified store.

# Define The Cert File To Import $CertFileToImport = "D:\Temp\CertToImportCERFile.CER" # Target The Cert That Needs To Be Imported $CertToImport = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2 $CertFileToImport # Define The Scope And Certificate Store Within That Scope To Import The Certificate Into # Available Cert Store Scopes are "LocalMachine" or "CurrentUser" $CertStoreScope = "LocalMachine" # For Available Cert Store Names See Figure 5 (Depends On Cert Store Scope) $CertStoreName = "My" $CertStore = New-Object System.Security.Cryptography.X509Certificates.X509Store $CertStoreName, $CertStoreScope # Import The Targeted Certificate Into The Specified Cert Store Name Of The Specified Cert Store Scope $CertStore.Open([System.Security.Cryptography.X509Certificates.OpenFlags]::ReadWrite) $CertStore.Add($CertToImport) $CertStore.Close()

-

You can also find multiple scripts about this here.

-

Importing Certificates WITH The Private Key

By using the following PoSH commands you can import the targeted certificate with the private key into the specified store. For this the password protecting the private key is needed.

# Define The Cert File To Import $CertFileToImport = "D:\Temp\CertToImportPFXFile.PFX" # Define The Password That Protects The Private Key # (ALSO see: http://jorgequestforknowledge.wordpress.com/2011/12/15/passwords-containing-special-characters-in-powershell/) $PrivateKeyPassword = 'Pa$$w0rd' # Target The Cert That Needs To Be Imported $CertToImport = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2 $CertFileToImport,$PrivateKeyPassword # Define The Scope And Certificate Store Within That Scope To Import The Certificate Into # Available Cert Store Scopes are "LocalMachine" or "CurrentUser" $CertStoreScope = "LocalMachine" # For Available Cert Store Names See Figure 5 (Depends On Cert Store Scope) $CertStoreName = "My" $CertStore = New-Object System.Security.Cryptography.X509Certificates.X509Store $CertStoreName, $CertStoreScope # Import The Targeted Certificate Into The Specified Cert Store Name Of The Specified Cert Store Scope $CertStore.Open([System.Security.Cryptography.X509Certificates.OpenFlags]::ReadWrite) $CertStore.Add($CertToImport) $CertStore.Close()

-

You can also find multiple scripts about this here.

-

So, what else can you use? Is there more than this? Yes, there is!

-

After you install the Quest Active Roles Management Shell For Active Directory (download here), you get lots of additional PowerShell CMDlets to use. To find those, just issue the command “Get-Command *QAD*” or have a look at the reference information. Just download and install the snap-in. To see the available snap-ins issue the command “Get-PSSnapIn -registered”. To import the snap-in issue the command “Add-PSSnapIn Quest.ActiveRoles.ADManagement”. The following CMDlets are available:

-

In addition, after you install the Public Key Infrastructure PowerShell Module available on Codeplex (download here), you get lots of additional PowerShell CMDlets to manage Microsoft Certificate Authorities. Just download and install the module. To see the available modules issue the command “Get-Module -ListAvailable”. To import the module issue the command “Import-Module PKI”. The following PowerShell CMDlets are available:

-

Cheers,

Jorge

———————————————————————————————

* This posting is provided "AS IS" with no warranties and confers no rights!

* Always evaluate/test yourself before using/implementing this!

* DISCLAIMER: http://jorgequestforknowledge.wordpress.com/disclaimer/

———————————————————————————————

############### Jorge’s Quest For Knowledge #############

######### http://JorgeQuestForKnowledge.wordpress.com/ ########

———————————————————————————————

Posted in Active Directory Certificate Services (ADCS), PowerShell, Windows Client, Windows Server | Leave a Comment »

(2011-09-06) Dutch Root Certificate Authority Being Marked As Untrusted By Microsoft

Posted by Jorge on 2011-09-06

As you may know, a Dutch root certificate authority was hacked a week or so ago. Because of that, it’s root certificate should be marked as untrusted to make sure every issued certificate by that cert authority becomes untrusted to prevent spoofing. Today, Microsoft released an updated fix which marks the root certificate as untrusted. This can see below. More information here.

-

MicrosoftSecurityAdvisory

By targeting “MS-KBQ2607712_Microsoft Security Advisory: Fraudulent digital certificates could allow spoofing” you can download the fix manually for every Windows version still supported (WXP and higher). You can also get the fix through Windows Update.

Make sure to install the hotfix to prevent spoofing!

-

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
http://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

Posted in Active Directory Certificate Services (ADCS), IT News, Windows Client, Windows Server | Leave a Comment »

(2011-06-16) IMPORTANT Security Update for Windows Server: Active Directory Certificate Services Web Enrollment

Posted by Jorge on 2011-06-16

SOURCE: http://blogs.technet.com/b/pki/archive/2011/06/14/important-security-update-for-windows-server-active-directory-certificate-services-web-enrollment.aspx

-

An important security update, described in MS11-051 (http://go.microsoft.com/fwlink/?LinkId=217101) was released today. The update fixes a cross-site scripting vulnerability in the sample web enrollment ASP pages that are part of Active Directory Certificate Services Web Enrollment in Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2.

-

Important: Back up any sample web enrollment sample pages you modified (%windir%system32Certsrv) before applying MS11-051. After you apply the security update, you can integrate any changes you made to the original sample files into the new secure ASP sample pages. For more information, see MS-KBQ2518295.

-

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
http://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

Posted in Active Directory Certificate Services (ADCS) | Leave a Comment »

(2009-04-16) Designing Your Own PKI Infrastructure

Posted by Jorge on 2009-04-16

These are interesting "quick-read" articles about designing, installing and troubleshooting a PKI (Public Key Infrastructure) based on Microsoft Certificate Services in Windows Server 2003. Apart of several tech differences it also applies to Windows Server 2008. For more details about how to do stuff, read the information provided by the other links below.

More detailed information:

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
http://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

Posted in Active Directory Certificate Services (ADCS), Design Guides | Leave a Comment »

(2008-12-13) CLM 2007 And W2K8 Certificate Services Now Supported Together

Posted by Jorge on 2008-12-13

CLM 2007 is the Certificate and Smart Card Management component of ILM 2007 (FP1). It performs the role of a registration authority against one or more Windows Server Enterprise CAs. On each of the CAs that are used through CLM, a policy and exit module must be installed and configured. These CLM modules communicate both with the CLM Server, the SQL Server and control the handling of certificates at the CA.

Initially, CLM 2007 only supports Windows Server 2003 Enterprise CAs and not Windows Server 2008 Enterprise CAs. It is not possible to install the mentioned policy and exit modules, or even CLM 2007 itself, on a Windows Server 2008 computer.

However, Microsoft released a hotfix to make CLM 2007 fully compatible with Windows Server 2008 computers. That means CLM 2007 can be installed on Windows Server 2008 (and officially supported) if required and/or the policy and exit modules can be installed on a Windows Server 2008 based CA. Both apply for the 32-bit architecture only. If you are interested in using CLM on the 64-bit architecture you must wait until ILM "2" has been released.

The hotfix is MS-KBQ946797_A hotfix rollup package (build 3.3.1087.2) is available for Identity Lifecycle Manager 2007 Feature Pack 1. Wait, don’t go and get it yet! Keep reading! Through this KB article it is possible to request the required hotfix by using the "View and request hotfix downloads" option at the beginning of the KB article. However, the hotfix that can be requested through the KB article only applies to CLM 2007 on Windows Server 2003. It does not help you if you want to install CLM 2007 on Windows Server 2008. For that part (the W2K8 compatibility solution) Microsoft does not provide a hotfix, but rather it provides new Windows Server 2008 fully compatible CLM 2007 installation. To get those new installation binaries you need to call Microsoft PSS, reference the KB article and specifically mention you need the Windows Server 2008 compatible installation binaries of CLM 2007 (issue 5 – see KB article). So, again: not the hotfix, but the installation binaries! I have been there and I know. ;-) )

In addition to the new installation binaries you still need a valid license with a product key. If you do not have a product key you are entitled to evaluate CLM 2007 for 180 days.

So, this is a nice story about installing CLM 2007 on Windows Server 2008. But what is really behind it and why is it so important? First of all, it makes CLM 2007 compatible with Windows Server 2008 and secondly you will be able to leverage a Windows Server 2008 based CA with CLM 2007. For organizations it can make a big difference whether you are using Windows Server 2003 Enterprise CAs or Windows Server 2008 Enterprise CAs. Windows Server 2003 CAs lack the capability of achieving high availability through clustering technologies. In Windows Server 2008 it is possible to cluster the Certificate Services and this is, amongst others, a big improvement! And that’s why this is very important. To understand the importance of having highly available Enterprise issuing CAs, it is therefore important to understand the unavailability scenarios that can occur with Windows Server CAs. The following scenarios apply:

  1. Inability to perform certificate lifecycle management operations like certificate enrollment, certificate renewal, certificate revocation, key recovery, etc.;
  2. Inability to publish fresh Certificate Revocation Lists (CRLs).

AD.1: The consequences of this scenario are generally not catastrophic in the sense that problems arise singularly. It is possible to deploy multiple Enterprise issuing CA servers to overcome situations where a single Enterprise issuing CA server fails as this can help maintain an issuing capability. However, there is always an affinity between an issued certificate and the Enterprise CA that issued the certificate. For instance, whichever Enterprise CA issued a certificate would need to be available to perform a revocation or renewal of that certificate or to recover archived private keys.

AD.2: The consequences of this scenario can be quite dramatic, potentially resulting in smart card logon (amongst others) failing throughout the entire environment for those users that are using smart card logon certificates issued by the Enterprise CA that has failed or has become unavailable for whatever reason. This occurs if a fresh CRL is not published in a timely manner by the Enterprise CA that provided the smart card logon certificates. Measures do exist, that can be taken to mitigate against the disaster scenario presented here, such as manual re-signing of stale CRLs (see: CA Maintenance – CRL Re-Sign, also seefrom the command line CERTUTIL -sign -?) and/or registry settings on domain controllers that allow smart card logon certificate validation with stale CRLs (see: MS-KBQ887578_You receive a "Logon failure" message when you use a smart card on a Windows Server 2003-based computer).

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
http://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

Posted in Active Directory Certificate Services (ADCS), Identity Lifecycle Manager (ILM), Windows Server | Leave a Comment »

(2008-07-17) AutoEnrollment Control Access Right Is Missing In AD

Posted by Jorge on 2008-07-17

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 evaluate/test yourself before using/implementing this!
* DISCLAIMER:
http://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

Posted in Active Directory Certificate Services (ADCS), Active Directory Domain Services (ADDS) | Leave a Comment »