Archive for the ‘Active Directory’ Category

How to enable LDAP over SSL using Subject Alternate Names

March 17, 2009 3 comments

With multiple Domain Controllers in AD, it makes little sense to hard-code any DC within programming code, applications and user profiles.  The main reason being a single point of failure, such as during maintenance windows or if a physical machine unexpectedly dies off.  The best way to mediate this is to create a DNS Round Robin for a friendly name, such as, and list several Domain Controllers as possible end points.  The trick however, you must configure the Domain Controllers with a certificate from either your internal PKI or a 3rd party CA, such as VeriSign.  Installing this cert is a requirement to talk SSL\TLS LDAP using subject alternate names.

Here are two KB articles that outline the process:

There are 4 key steps to follow:

    1. Create the INF file, which determines which attributes to use
    2. Use the INF to create a request file
    3. Submit the request file to be signed by the Certificate Authority
    4. Accept and install the new certificate in the local computer store

  • Create the INF file.  Save the blue text to a file and name it certnew.inf


Signature=”$Windows NT$
Subject = “” ; must be the FQDN of domain controller  (EDIT THIS AND ADD THE FQDN OF YOUR DC)
EncipherOnly = FALSE
Exportable = FALSE  ; TRUE = Private key is exportable
KeyLength = 1024    ; Common key sizes: 512, 1024, 2048, 4096, 8192, 16384
KeySpec = 1             ; Key Exchange
KeyUsage = 0xA0     ; Digital Signature, Key Encipherment
MachineKeySet = True
ProviderName = “Microsoft RSA SChannel Cryptographic Provider”
ProviderType = 12
RequestType = CMC
OID= ; Server Authentication
CertificateTemplate = WebServer ;Omit  line if CA is a stand-alone CA
;Note: The first SAN Entry must be the FQDN of the Domain Controller.  If it is not, Secure LDAP will not function.


  • From the same directory you saved the certnew.inf file issue this command (On the DC). :
Certreq -new certnew.inf certnew.req
  • Issue this command:
Certreq -submit certnew.req certnew.cer
Note: Certreq.exe will prompt you for which CA to use if you have multiple CA’s in your environment.
  • Issue this command:
Certreq -accept certnew.cer
Note: This command copies the private key with the certificate and automatically places it in the private computer store.  If you try to use the Certificate Authority Web enrollment form, and do not select store in the local computer store, it will place the cert in the current user cert store on the DC.  This breaks the SSL\SAN capability.

You can and should delete any other certs in the DC computer store, as they will cause problems due to caching of certs within SCHANNEL as there is no way to know which cert the LDAP client binds to.

Best of Luck,

Ed McKinzie

Categories: Active Directory

Windows 2003 DCPROMO Fails: “Version of the active directory schema of the source forest is not compatible”

November 19, 2008 Leave a comment


This issue may occur when Active Directory has not been updated with the Windows Server 2003 R2 schema extensions.

To resolve this issue, run the adprep.exe /forestprep command from the Windows Server 2003 R2 installation disk 2 on the schema master. To do this, insert the Windows Server 2003 R2 installation disk 2, and then type the following command:

Drive:\CMPNENTS\R2\ADPREP\adprep.exe /forestprep

Once, complete, rerun your DCPROMO and the issue should be resolved.

Categories: Active Directory

How to add a Subject Alternative Name to a secure LDAP certificate

July 29, 2008 Leave a comment
I commonly need to use PKI certificates that are bound to a single IP address but host multiple DNS service names, typically spanning several ports.  This can easily be done by adding Subject Alternate Names to a certificate. However, if you are using an internal Windows Certificate Authority, you must first enable this feature.  To do so, follow this KB.

How to configure a CA to accept a SAN attribute from a certificate request

By default, a CA that is configured on a Windows Server 2003-based computer does not issue certificates that contain the SAN extension. If SAN entries are included in the certificate request, these entries are omitted from the issued certificate. To change this behavior, run the following commands at a command prompt on the server that runs the Certification Authority service. Press ENTER after each command.
certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2
net stop certsvc
net start certsvc

How to use Web enrollment pages to submit a certificate request to a stand-alone CA

To submit a certificate request that includes a SAN to a stand-alone CA, follow these steps:

In the Attributes box, type the desired SAN attributes. SAN attributes take the following form:[&]
  1. Open Internet Explorer. 
  2. In Internet Explorer, connect to http://servername/certsrv(Servername= your CA server, which must have Certificate Services Web Enrollment Support installed.)
I have added several dozen DNS names on a single cert that has worked well.
Ed McKinzie

Categories: Active Directory

EFS using internal PKI Certificates / Recovery Agent Certificates

July 15, 2008 Leave a comment

Situation: We have an EFS deployment where we can encrypt Files and folders based on the Domain GPO policy.  Unfortunately, the Recovery Agent certificates expired causing the encrypted services to begin to fail.  Here is what we did to fix the issue.  Keep in mind we use an internal PKI infrastructure to issue certificates.

Securing the Default Recovery Key for the Domain
As with the stand-alone computer, a default recovery policy is configured for the
domain when the first domain controller is set up. The default recovery policy uses
a self-signed certificate to make the domain Administrator account the recovery
Note: To change the default, log on as Administrator on the first domain controller
of the domain, and follow the steps above to secure the recovery key for the domain.


Requesting a File Recovery Certificate
If you decide to use the default recovery policies, you never need to request a file
recovery certificate. However, in circumstances where multiple recovery agents are
needed for the domain or where the recovery agent needs to be different from the
domain administrator due to legal or corporate policy, you may need to identify certain
users as recovery agents, and these users must be issued file recovery certificates.
To accomplish this, the following procedures must be completed:
•  An Enterprise certification authority (CA) must be set up, if one isn’t available.
•  The policy on the Enterprise CA must allow the designated user/agents to request and obtain a file recovery Certificate.  (Enroll rights must be granted on the EFSRECOVERY Template)
•  Each user must request a file recovery certificate.

I am assuming you already have a CA installed and have already created a user account(s) to be used as the recovery Agents.  They can be simple user accounts in the domain, if you have not. 

In my example I am using EFSUSER1 and EFSUSER2.

Add the Domain Recovery Agents group to the EFS Recovery Template.
This procedure allows users in that group to request recovery certificates.
1. Click Start, point to Programs, point to Administrative Tools, and click Active Directory Sites and Services.
2. On the View menu, click Show Services.
3. Click the + next to Services in the left pane. Use this method to expand the Public Key Services folder.
4. Click Certificate Templates (in the left pane).


5. Double-click EFSRecovery in the right pane.
6. Click the Security tab.
7. Click Add. Scroll and find the EFSUSER1 and EFSUSER2 accounts and click Add.

8. With the two accounts selected in the top pane, select the Enroll check box in the bottom pane.
9. Click OK, and close the Active Directory Sites and Services snap-in.

Assign a Certificate to the EFS Accounts.

  1. Add the EFSUSER1 and EFSUSER2 accounts to the local administrators group on a workstation in the UM-USERS domain.
  2. Login to the workstation as one of the accounts. Note, if you cannot remember the password, reset it.
  3. Once logged in, open the local certificates as “My User Account”. (NOT Computer). Either by way of an MMC or within the Administrator tools.  Expand Personal certificates.   Request a “New Certificate”. Select EFS Recovery Agent. Give it a friendly name of the user account.



  1. Once complete, export the certificate with both the private key and one without the private key to a directory on the local workstation or server.
  2. Repeat these steps for both accounts.
  3. Once the certificates are exported, login to a workstation\server with Domain Admin rights. Make sure the account has access to the directory and exported certs you just created. Launch AD Users and Computers, right click on the Domain and Select Properties. Edit the Default Domain Policy.


  • Expand the Group Policy –> Windows Settings –> Security Settings –> Public Key Policies –> Encrypting File System.


    • Right click in the EFS Panel and select Add Data Recovery Agent.


  • Browse to the Certificate with no private key or the *.CER file you just created in the exported Cert Directory. Hit Next and Finish. Refresh the EFS Panel.


  1. You should now see the proper certificates.
  2. Now burn the contents of the exported EFS directory to a CD or Media, place in the vault and delete the cert files\directories from your workstation\server.  Also remove the accounts from the local administrators group on the workstation.

Categories: Active Directory

Windows Server 2008 Adprep /ForestPrep against Windows 2003 AD Forest

March 28, 2008 Leave a comment

I was working on my test Forest and was introducing my first Windows 2008 Domain Controller into the environment.  Since I am running a Windows 2003 Forest, I had to prep the environment with the new schema extensions.  When I ran DCPROMO on the 2008 box, I received the following error.


From a Windows 2003 Domain Controller, I was required to load the 2008 Server media and issue the "ADPREP /ForestPrep" command.


I was then able to complete the DCPROMO on my Windows 2008 DC.  To credit Microsoft, the new features regarding this process has been greatly improved on the Enterprise level AD infrastructure.  They have made the Single Forest\Multi-Domain integration even more seamless. Kudos.

Categories: Active Directory

How to Restore Deleted Machine accounts\Active Directory ADRESTORE\Unicode-pwd\searchFlag

February 6, 2008 3 comments

Within our production environment, we had an Admin accidentally delete his Departmental OU in AD.  Within this OU there were Machine accounts associated with servers and desktops.  The delete caused the orphaned machines to lose the ability to login to the domain.  There are several ways to restore the lost AD objects.

  • Perform an AD LDIF import (Not recommended)
  • From each workstation, remove and re-add the machines to the Domain (ugly)
  • Perform an AD Authoritative Restore – AD Restore Mode (uglier)
  • Perform an object restore using ADRESTORE (Recommended, but with prerequisites)

I recommend doing the last option, however, you must prep your AD environment to have a certain attribute set within the AD Schema configuration.

The ADRESTORE tool is a very useful tool,  but in the case of deleted/restored machine accounts there is one missing attribute that prevents a reanimated machine account from functioning.

By default a tombstoned object does not contain the password (Unicode-pwd) and thus the reanimated computer account’s password value will not match the password held on the workstation.  This is why you cannot login in to a workstation when the machine account is deleted.

By changing the value of the searchFlag attribute on the Unicode-pwd schema object from 0 to 8, the Unicode-pwd will be preserved in the tombstoned object and will be present when the object is reanimated.  (In other words, the machine accounts’ password will be restored along with the machine account using ADRESTORE.)  The searchFlag attribute’s value can be adjusted using ADSI edit on the schema naming context on the Unicode-pwd object.  Once the object is restored, all that is left is to “Enable” the machine within AD.   You should not have to touch the workstation\server.  In most cases, the machine doesn’t even have to be rebooted, functionality should be fully restored.

Updated: There is a new feature in Windows 2008 R2, called the Active Directory Recycle Bin.  This is a win for Microsoft and allows for reanimating deleted objects.  Very Cool feature. (  For those of you still on Windows 2003 or 2008 standard, you will have to follow the above recipe.

Best of Luck!


Categories: Active Directory

Restoring A deleted Active Directory Object using ADRESTORE (Windows 2003 Domain\Exchange 2007 Mailbox)

January 24, 2008 1 comment
Windows Server 2003 introduces the ability to restore deleted ("tombstoned") objects. This simple command-line utility enumerates the deleted objects in a domain and gives you the option of restoring each one.   When an object is deleted AD, it isn’t actually removed but is instead marked as deleted by an internal marker called a tombstone.  You can use AdRestore to restore tombstoned objects without performing an authoritative backup restore.  Source code is based on sample code in the Microsoft Platform SDK. This MS KB article describes the use of ADRESTORE:   The ADRESTORE tool was created SYSINTERNALS, which has been acquired by Microsoft.   
In this example, we have a mail enabled user object named "Tonya Long".  I deleted the object from AD and Exchange 2007 using the Active Directory Users and Computers mmc. 
I then use the ADRESTORE tool to enumerate the "tombstoned" objects in AD.  Fetch the tool, export it to the root of any machine that is a member of the domain.  In my case, I performed this step from a Domain Controller with a credential with Domain Admin rights.  Depending on how big your Forest\Domain infrastructure is, I would pipe the file to a text document.
1.) c:\Adrestore > adrestore_output.txt
· Open the file with notepad:
· You should find an entry for the deleted object, such as:
cn: Tonya Long
distinguishedName: CN=Tonya LongADEL:02cf4aa2-f1d1-46d8-8c3a-c10283ad3467,CN=Deleted Objects,DC=EDM-Users,DC=com
lastKnownParent: CN=Users,DC=EDM-Users,DC=com
2.) Restoring the object.   C:\>adrestore "Tonya Long" /r    -Note the key here is the CN: name.
· Enumerating domain deleted objects:
cn: Tonya Long
distinguishedName: CN=Tonya LongADEL:02cf4aa2-f1d1-46d8-8c3a-c10283ad3467,CN=Deleted Objects,DC=EDM-Users,DC=com
lastKnownParent: CN=Users,DC=EDM-Users,DC=com
· Do you want to restore this object (y/n)?  Click "Yes"
Restore succeeded.
Found 1 item matching search criteria.
3.) Checking the object in Active Directory Users and Computers (ADUC)
· Note the object is in a Red State, meaning it is disabled. It will also have a blank password.
· You must enable the object and give it a new password that meets your Domain PSW requirements.
4.) Restoring the Exchange Mailbox.
Launch the Exchange 2007 console and select the Disconnected Mailbox option under the Recipient Configuration section.
· Right Click the object and select Connect.
· Select which Matching User, in this case LongT, which will restore the alias and SMTP aliases.
5.) Populate SAM Account (NT ID Name), Logon Domain, Display Name and User Info using the Exchange 2007 console.
· Unfortunately the ADRESTORE tool does not re-populate this info…
· You will also have to repopulate any DL\Security Groups


Categories: Active Directory