Set the DSConfigDN for Standalone Root CAs

Are you setting up a new PKI implementation in your organization?  Are you using a Standalone Root CA with an Enterprise Subordinate CA?  If so, don’t forget to properly set the DSConfigDN attribute for your Standalone Root CA (since it can’t read or write in AD!).  If you do forget to do this and then you install your Enterprise Subordinate CA…well, you’ll be unhappy and end up having to uninstall and then reinstall that Enterprise Subordinate CA after making this change or reissue it’s certificate after making this change.  (honestly, the uninstall and reinstall is a cleaner approach if you need to fix this problem).

To properly set the DSConfigDN attribute on the Standalone CA:

1. From an administrative command prompt, enter the following command to set the Configuration container DN for the Root CA. 
   certutil -setreg ca\DSConfigDN “CN=Configuration,DC=mycompany,DC=local”
2. You should get the following output back:
   • SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\ROOTCANAME\DSConfigDN:
   • NewValue:  DSConfigDN REG_SZ  = CN=Configuration,DC=mycomapny,DC=local
   • CertUtil -setreg command completed successfully.
   • The CertSvc service may need to be restarted for changes to take effect.
3. Stop and then start the Active Directory Certificate Services service as required.  This can be done from the command prompt, the Services console or the CA console.

The change looks like that seen in the figure below when viewed in the Registry Editor.

DPM agents not functioning on Server 2008 DCs

I recently rebuilt two domain controllers in a remote site to be Windows Server 2008 SP2 64-bit. They were previously running Windows Server 2003 SP2 R2 64-bit and were in DPM 2007 SP1 with no issues.  The build for the 2008 installation from bare metal:  the old DCs were demoted, kicked out of the domain and then rebuilt as new with 2008.

When trying to install a DPM agent to the new DC installations now, error 337 was received in the DPM console:  the agent did install, but the service does not start and the agent is in an error condition in the DPM console.  Looking at a relevant DCOM article in TechNet to verify security for error 337 provided no help.   Attempting to manually install and register the DPM agents resulted in the same error.  Either way, not good…no protection groups can be configured and no backups can occur.

I could find no documentation specific to what might need to be done to get this working. 

Here’s the solution as provided by PSS (with minor edits by me): 

*** Problem Description ***
In a 2003 domain that is upgraded to a 2008 domain (native mode) DPM agents on the 2008 domain controllers will never communicate to the DPM server. The agent in DPM will show a red x on it. You can remove the agent and then reinstall the agent with the same results.

*** Resolution ***
DPM requires access to AD keys that only have the Builtin “Users” with permissions on them.  During the upgrade of the domain, it removes the NT Authority “Authenticated Users” group from the Builtin “Users” group and thus breaks the DPM server from getting access to these keys.  To fix this problem, add the NT Authority “Authenticated Users” group to the Builtin “Users” group in Active Directory Users and Computers and wait for replication to occur (in the event of DPM in a remote site), refresh the DPM agent information in the DPM console and you should be green and good.

Strange.

RFC 3647 Certification Practice Statement (CPS) template

Are you implementing a  Public Key Infrastructure solution?  If so, do you want to fully comply with RFC 3647 and ensure maximum credibility for your PKI solution?

If you answered yes to both of these questions then you’re going to be spending a lot (A LOT) of time working on the writing and approval of a Certification Practice Statement (CPS) and possibly also a Certificate Policy.  Per RFC 3647, there is a specific template should should be followed in most, if not all, cases.

Download a template here and don’t forget to also get your organization a Private Enterprise Number (PEN) from IANA…you’ll want that PEN to create your OID tree and assign a globally unique OID to your CPS.

Disclaimer:  The template is provided with no warranty or guarantee to suitabiltiy in your orgniazation.  The template was created using Microsoft Word 2007 and may open or appear differently in other versions.

Get the template: 

  CPS_Template.zip (23.8 KiB, 648 hits)

ADAM/AD LDS import fails with error 0×20e7

We’ve got an ADAM instance setup that provide proxy authentication for an application.  In one partition of the ADAM instance are the userProxy objects and in another partition objects exist specific to the application that contain security and role information, thus determining what permissions each user has in that application.  I use a scheduled VBScript to synchronize the contents of the “ADUSERS” partition with those of the application container.  The application support personnel use the built-in vendor provided security management tools to manage the data in the “application” partition, including adding new user entries.  My VBScript just created the required userProxy objects when needed in the “ADUSERS” partition…without a corresponding entry in both partitions, i.e. without the userProxy object, there can be no proxy authentication for the user to that application.  Simple, standard ADAM usage.

Anyhow, I had been alerted by the applications teams that a certain user that was provisioned within the application security tools hadn’t had a userProxy object created accordingly.  Upon further investigation, I found that the scheduled synchronization process, which relies on an ADAM LDIFDE import to create the new userProxy objects had been failing for several days.  Running the scripted LDIFDE import command manually, so I could see the exact error, yielded the following output:

C:\WINDOWS\ADAM>ldifde -b <account, domain and password> -s <server> -t <port> -i -k -f <import.ldif file>
Connecting to “<server>”
Logging in as “<user>” in domain “<domain>” using SSPI
Importing directory from file “<import.ldif file>”
Loading entries..
Add error on line 7: Unwilling To Perform
The server side error is: 0×20e7 The modification was not permitted for security reasons.
The extended server error is:
000020E7: SvcErr: DSID-03152AA9, problem 5003 (WILL_NOT_PERFORM), data 8471

0 entries modified successfully.
An error has occurred in the program

When looking at the import file, there were no issues noted…nothing out of the normal.

dn: CN=adusers,CN=application,CN=adam,DC=company,DC=local
changetype: add
objectclass: container
objectclass: top
cn: adusers

dn: cn=someuser,CN=adusers,CN=application,CN=adam,DC=company,DC=local
changetype: add
objectSID: S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxxx-xxxxx
objectclass: userProxy
cn: someuser

The key part of that error is actually the data field, 8471.  A check of that error code on the System Error Codes (Windows) site of MSDN reveals the following information:

ERROR_DS_NAME_ERROR_NOT_UNIQUE
8471 (0×2117)

Name translation: Input name mapped to more than one output name.

So, a duplicate SID exists (the SID is the unique identifier and I’d already verified that this specific CN did not exist in the “ADUSERS” partition of the ADAM instance.  Now knowing that this userProxy cannot be created due to a duplicate SID problem, things are getting clearer…but how to determine what existing userProxy object has that SID?  And how did another userProxy object get the same SID? 

First things first, to determine what existing userProxy object has that SID already, an export of the ADAM “ADUSERS” partition is required.  Use a command similar to the following to get it:

C:\WINDOWS\ADAM>ldifde -s <server> -t <port> -d CN=adusers,CN=application,
CN=adam,DC=company,DC=local -f e:\output.ldif

Now that you have the ldif file, the next step is to find the Base64 value of the SID for the user account in question.  The easiest way is to look up the objectSID value in ADSIEDIT, targeted at Active Directory (not the ADAM instance) and get the Hexadecimal value of the objectSID attribute for the user account in question.  Then convert that Hex value into Base64 using your favorite converter.  A really nice one can be found here at TRANSLATOR, BINARY.  Simply copy the Hex value into the Hex input box and click Decode.  Your Base64 value appears below.  Copy this Base64 value and use it to search the exported ldif file.  You’ll find the userProxy object with the duplicated SID in no time.

In my case, the problem tracked back to a name change on the user object, changing the first name.  The userProxy object had previously been created for the user account before the name change (and with the same SID obviously), but the application administrators had not deleted the old (incorrect) userProxy object manually as they needed to.  Thus when the LDIFDE import process tried to create a new userProxy object for the newly renamed user account, the import process failed.  Once the incorrect userProxy object was deleted, the import process was able to complete again successfully.

AD Powershell cmdlets!

With the release of Windows Server 2008 R2, there will finally be native support for Active Directory management in Powershell.  For those of us (myself included) who don’t/won’t use the third-party add-ins for AD, this is great news!

Check out the AD Powershell team’s blog:  Active Directory Powershell Blog (easy enough name to remember) for more information and a downloadable cmdlet reference chart.

Thanks AD Powershell Team!

Adding Exchange Administrators fails with error 00000525

Just as a quick reminder (because, oh…I forgot myself), if you have Exchange Server 2007 installed in a child domain in a parent/child domain forest then your Exchange security groups are going to be located in the parent (root) domain.  So, if you want to add new Exchange Administrators using the Add Exchange Administrators wizard from the EMC or the Add-ExchangeAdministrator cmdlet in the EMS, you need to be an Enterprise Administrator if you’re trying to perform the add from the child domain.  If not, you’ll get this error:

Summary: 1 item(s). 0 succeeded, 1 failed.
Elapsed time: 00:00:00

Add-ExchangeAdministrator
Failed

Error:
Active Directory operation failed on dc21.root.local. This error is not retriable. Additional information: The specified user does not exist.
Active directory response: 00000525: NameErr: DSID-031A0F80, problem 2001 (NO_OBJECT), data 0, best match of:
 ”

The object does not exist.

Exchange Management Shell command attempted:
Add-ExchangeAdministrator -Identity ‘company.local/SystemUsers/Service Accounts/ServiceAccount42′ -Role ‘ServerAdmin’ -Scope ‘XHT10A’

Elapsed Time: 00:00:00

Here’s one newsgroup post with this error, I’m sure there are others as well.

My “unofficial” Exchange Server 2007 CCR recommendations

Having had Cluster Continuous Replication in place now for about a year, I’ve derived some of my own best practice recommendations that might not be found within the official Microsoft documentation.  Of course, it’s been a little while since I last checked that documentation, so this could be duplication of recommendations. 

Although these recommendations are based on a very solid and stable production environment…anything bad or job search inducing that happens as a result of implementing them in your environment is not my responsibility.

So, here is the list in order of importance:

• Hub Transport servers should NOT be the location for your File Share Witness.  I have found the BEST location in my opinion is in fact Domain Controllers in the same domain as the Exchange servers.  This is obviously to be extended to cover other sites and domains as your organization may have them.  Of course, you need to set up two FSW locations…one primary and one staged with folders and permissions in place in the event your primary FSW server dies.
  • I do know for a fact that the original guidance Microsoft gave was to have the FSW on the Hub Transport servers.  The logic was that a Hub Transport is a required role and the FSW needs to be on a server the Exchange administrator controls…a natural fit.
• The servers hosting the File Share Witness (or at least the one server that is the primary FSW host) should NOT be in the same data center as either of the two Mailbox server nodes in the CCR cluster.  By using a three data center model (all local and in the same AD site) you provide complete and automatic fail over protection in the event of a data center failure.
• Hub Transport servers should NOT use SAN attached storage for their queue databases.  Internal storage, in the Hub Transport server, is preferred.  In the event that a CCR lossy failure occurs and Transport Dumpster redelivery is required, it would be best to not have that Transport Dumpster data on the SAN that is possibly out of action now due to a data center failure or SAN failure.  If the queue database is located on internal storage in the Hub Transport server, you can simply move that Hub Transport server physically to an operating location (doesn’t even have to be in a data center), put it back on the network and now it can participate in Transport Dumpster redelivery.  Cool.
• If possible, Hub Transport servers should NOT be placed on blade server hardware UNLESS you have the capability to place a blade server chassis in another location during a data center failure.  This goes along with the previous recommendation about being able to bring that Hub Transport back online in an alternate location.
• At least one Domain Controller SHOULD be placed in each local data center you’ve got Exchange servers placed in.  Of course, you should really have a minimum of two data centers to take advantage of CCR and you should always have at least two Domain Controllers per AD site…so one Domain Controller per data center makes perfect sense.  If you’re going to use a Domain Controller (as noted previously) for your File Share Witness, this then offers you both AD and Exchange protection in one move.

Do you have anything to add?

Scripting backups of AD LDS (ADAM) with dsdbutil

Although I’ve worked with Windows Server 2008 for quite some time now in test, I’ve just recently deployed the first production server into our environment.  This was to be a replacement for an ADAM (Active Directory Application Mode) development server used by the applications team.  The server itself is a VM running Windows Server 2008 since the requirements of ADAM (now known as Active Directory Lightweight Directory Services in Windows Server 2008) are minimal from a performance standpoint. 

Given the changes in how Windows Server Backup works in Windows Server 2008 (you cannot select just a part of the system volume to be backed up and you need a dedicated drive for backups to be stored on, by default), I was not looking forward to using it to get backups of the AD LDS databases.  Since the adamntds.dit files are open all the time, they’d need to be backed up by a normal backup program using Volume Shadow Copy.  Windows Server Backup would fill that need, but at the cost of backing up the entire system volume (over 9 GB), so that’s really a waste of space and effort.  Since we use Tivoli Storage Manager (TSM) as our enterprise backup/restore/disaster recovery solution, using Windows Server Backup to backup the entire server just seemed silly.  Of course, the problem with TSM is that considers .dit files to be off limits by default except when backing up the System State on a Domain Controller, so even using TSM’s open file support, I could not get a backup of the adamntds.dit files.  Bummer.  Enter the dsdbutil command. 

You can schedule scripted backups of your AD LDS instances databases using the dbdsutil command easily enough, although at first glance at the relevant documentation this is definitely not the case.  (See the relevant TechNet article here.)  Like most other context sensitive commands, you can simply string together all of the commands you want to execute.  So instead of you entering them manually one at a time as the TechNet article implies, you can just concatenate them all on one line and sit back and enjoy your quick and easy AD LDS instance backups.

So, the sample batch file you would use in your scheduled task would look something like this:

rd C:\ADLDS_BACKUP /Q /S

dsdbutil “activate instance INSTANCE1” ifm “create full C:\ADLDS_BACKUP\INSTANCE1” quit quit

dsdbutil “activate instance INSTANCE2” ifm “create full C:\ADLDS_BACKUP\INSTANCE2” quit quit

Note that’s only three lines of code there to backup two different instances (I’ve put line breaks in between each line).  When using the dsdbutil command to create the ifm (install from media) backups, the destination directory must be empty, thus the usage of the rd (remove directory) command first in the batch file.  You will want to schedule this task to run using an account that is a local administrator, and be sure to select the task to run with highest privledges or else you won’t get the directory removal you need.

Disabling Active Directory User Accounts, Part 2

As a followup to the Disabling Active Directory User Accounts, Part 1 post, here’s a Powershell script that will disable multiple accounts for you by using a CSV input file.

Scipt features:

• The username of the the administrator running the script is recorded in the text file that lists all of the groups the account was removed from.
• An email is automatically created and sent to the configured recipients (such as the AD Administrators group and/or Information Security…), which is fantastic from an end-to-end accountability and auditing point of view (who did it, when did they do it and why…)
• Disables the specified AD account
• Hides the mailbox from the Global Address List
• Removes the account from all groups it was a member of
• Creates a text file log of all groups the account was a member of
• Sets the password to be changed at the next login
• Sets the disable date in the “Title” field (an unused field in my organization)

Just find the following variables in the script and change them accordingly:

• $SourceFile = “\\MYSERVERPATH\account_disables_input.csv”
  • This is the full UNC path to the CSV input file
• $EmailReportFile = \\MYSERVERPATH\Account_Disables_Report.txt
  • This is the full UNC path to where you want the report saved (this is what is emailed out)
• $domain = “LDAP://dc=DOMAIN,dc=local”
  • The LDAP bind URL for your domain…
• $To = “someone@mycompany.com”
  • SMTP addresses, comma seperated, of who you want the report emailed to
• $SmtpClient.host = “smtp.mail.mycompany.com”
  • The SMTP host name to handle your email report (your Exchagne 2007 Hub Transport server(s) or Exchange 2003/2000 front-end server(s) typically, make sure you can perform anonymous relay internally though….)

 Download the script here…

  Disable-ADAccountsMultiple.zip (3.2 KiB, 1,315 hits)

UPDATED Disable AD Accounts with Powershell

As a followup to the disabling AD accounts post earlier this month, I’ve updated the Power Shell (requires the Exchange Management Shell) script some to add some additional functionality.

New features:

• The username of the the administrator running the script is recorded in the text file that lists all of the groups the account was removed from.
• An email is automatically created and sent to the configured recipients (such as the AD Administrators group and/or Information Security…), which is fantastic from an end-to-end accountability and auditing point of view (who did it, when did they do it and why…)

Just find the following variables in the script and change them accordingly:

• $EmailReportFile = “\\YOUR_SERVER_PATH_HERE\Account_Disables_Report.txt”
  • This is the full UNC path to where you want the report saved (this is what is emailed out)
• $domain = “LDAP://dc=DOMAIN,dc=local”
  • The LDAP bind URL for your domain…
• $To = “someone@yourcompany.com”
  • SMTP addresses, comma seperated, of who you want the report emailed to
• $SmtpClient.host = “smtp.yourcompany.com”
  • The SMTP host name to handle your email report (your Exchagne 2007 Hub Transport server(s) or Exchange 2003/2000 front-end server(s) typically, make sure you can perform anonymous relay internally though….)

 Download the script here…

  Disable-ADAccountsSingle.zip (2.9 KiB, 1,086 hits)

Next Page »

• 

• Translator

• Categories

  • Active Directory (13)
  • Certification (2)
  • Data Protection Manager 2007 (7)
  • Exchange Server 2007 (26)
  • Microsoft Office Communications Server 2007 (1)
  • Networking (3)
  • Operations Manager (24)
  • PKI & Certificate Services (2)
  • Powershell (10)
  • Server Hardware (5)
  • Storage (4)
  • Visual Basic Script (3)
  • Windows Server 2003 (6)
  • Windows Server 2008 (4)

• Tag Cloud

  • Active Directory | AD LDS | ADAM | Agents | Alerts | antivirus | bug | C-Class Blades | CCR | Certification | Cisco | Cluster | Clustering | Data Protection Manager 2007 | Data Warehouse | DBCreateWizard | dbdsutil | DHCP | DNS | Doh! | Error 5 | EVA | Event Logs | Exchange | Exchange Server 2007 | Fibre Channel | ForeFront | HBA | Health Service | HP | iLo | IMAP | Management | Management Pack | MOSS | Operations Manager | Overrides | PKI & Certificate Services | Powershell | Printers | Reboot | Recipients | Registry | robocopy | Root Server | SAN | Scripting | SDDL | secedit | Self Tuning Threshold | Servers | Sharepoint | SMTP | SSL | strange | Terminal Services | Tools | Updates | Virtualization | VPN | VSS | Whitepaper | Windows Server 2008 |

• Blogroll

  • Ramblings of the Mad Cow

• Archives

  • September 2009
  • August 2009
  • April 2009
  • March 2009
  • February 2009
  • January 2009
  • December 2008
  • November 2008
  • October 2008
  • September 2008
  • August 2008
  • July 2008
  • June 2008

• Users Online

  • 4 Users Online