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.

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.

HOW TO: Configure and Start SCR Replication

It was a bit surprising to find that the TechNet documentation about configuring and starting SCR replication was…ah…less than perfect or easy to use.  Here’s a simple set of commands you can use to get your SCR implementation rolling along nicely.

Before trying to configure SCR, be sure that your mailbox server has been configured properly first.  That includes installing and configuring the Operating System and storage exactly the same as the SCR source (typically a CCR cluster).  Here’s a few pointers:

• If you use volumes F, G, H, and I for two databases and two storage group logs…make sure you have that configuration on your SCR target. 
• You should size the hardware identically to the SCR source, so use the same CPU type and speed, same amount of RAM, same server model, etc. where possible. 
• Install Exchange using a custom setup and install the stand-alone mailbox server role.
• Leave the default mailbox storage and storage that Exchange setup installs, but be sure to remove the mailbox it created for you (if you were using an account without a mailbox).  You’ll need these local mailboxes for Ops Mgr monitoring and routine testing purposes…just don’t create any real user mailboxes in them!

Here’s the commands you’ll need to run from the Exchange Management Shell to get things rolling:

Run from an Exchange server or management station on the same operating system version (although 32-bit or 64-bit does not matter) that does NOT have Exchange Server 2007 SP1 UR5 installed:

1. Enable-StorageGroupCopy -Identity “SCR_source_server_name\Storage_Group_name” -StandbyMachine SCR_target_server_FQDN-ReplayLagTime x.x:x:x -TruncationLagTime x.x:x:x
   • Be sure to see the cmdlet notes to understand the implications of ReplayLagTime and TruncationLogTime.  The values are in days.hours:minutes:seconds.
   • If you ever need to change the values configured for ReplayLagTime or TruncationLogTime, you’ll have to disable the copy and enable it over again anew.
   • Here’s the issue with UR5.

Run from the SCR target server, after verifying that Active Directory has replicated (especially critical when your SCR target server is located in a different AD Site):

1. Suspend-StorageGroupCopy -Identity “SCR_source_server_name\Storage_Group_name” -StandbyMachine SCR_target_server_FQDN
   • This cmdlet is usually not required, but it’s good practice to run.  The SCR copy is configured and in a suspended state following the issuance of the Enable-StorageGroupCopy cmdlet.
2. Update-StorageGroupCopy -Identity “SCR_source_server_name\Storage_Group_name” -StandbyMachine SCR_target_server_FQDN
   • This gets the full copy (full reseed) started.
3. Resume-StorageGroupCopy -Identity “SCR_source_server_name\Storage_Group_name” -StandbyMachine SCR_target_server_FQDN
   • This cmdlet is usually not required, but it’s good practice to run.  The SCR copy is resumed following the completion of the reseed.

To check the SCR replication status for all SCR instances on an SCR target server, issue the following command:

• Get-StorageGroupCopyStatus -Identity “SCR_source_server_name\*” -StandbyMachine SCR_target_server_name

TechNet cmdlet references:

• Enable-StorageGroupCopy
• Suspend-StorageGroupCopy
• Update-StorageGroupCopy
• Resume-StorageGroupCopy
• Get-StorageGroupCopyStatus

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,318 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,087 hits)

EASY HP iLO Integration with Active Directory

After fumbling around for a while, and looking over a good number of “Help!  How do I get iLO working with Active Directory without extending the schema” threads on the HP ITRC (IT Resource Center), I’ve gotten Active Directory login working with iLO2 in about 5 minutes.  It’s all really about the ActiveX settings on the client PC you’re using!  Pretty anti-climatic actually.

NOTE:  These steps have been tested in IE 7 on Windows XP SP3 and Windows Vista SP1…IE 6 and older may be a bit different.

NOTE:  Steps 1 - 3 not absolutely required, but I consider them to be good security practice since we’ll be weakening the default ActiveX security policy later…better to do it for the local network and not the Internet or other non-classified locations IMO).

To get things working in five minutes, just follow these steps:

1. In Internet Explorer, open Internet Options and go the Security tab.  Select Local intranet.



2.  Click the Sites button to open the Local intranet dialog box.



3. Click the Advanced button to open the Local intranet (again) dialog box and enter the subnets on your LAN that contain your iLO hosts leaving the last octet as a wild card.  Add all of the subnets you have.



4. Click Close and then Click OK to return to the Internet Options dialog box.  Click the Custom Level button to open the Security Settings - Local Intranet Zone dialog box.



5. Change the option “Initialize and script ActiveX controls not marked as safe for scripting” to Prompt.  Click OK to close this dialog box.
6. Click OK when prompted to change the zone settings.



7. Now go into the iLO settings for your server (logging in with the default local Admin account on the tag came with the server).  The Directory settings location varies slightly by iLO version, but you want to find something that looks like this.



8. You need to select “Use Directory Default Schema” and then enter in a IP list or FQDN list of Domain Controllers separated by a comma.  If you have S-LDAP available, leave port 636 (highly recommended) or change to 389 if you don’t have certificates on your Domain Controllers.  Lastly, put the search base LDAP string in Directory User Context 1.  It seems to work well with a higher level search base, but you might find you want multiple search bases.
9. Save your settings by clicking the Apply Settings button and then click the Administer Groups button go to the group administrator settings.
10. Select the Administrators group (note you can repeat this step for lower level access groups as well) and click the View/Modify button.
11. Supply the full LDAP path to the Active Directory security group that contains your iLO users (full administrators in this case) and then enable the features you wish the members of that group to have.  Click the Save Group Information button when you’re done. 



12. Log out of the iLO as the default Admin and login to the iLO Web page using your Active Directory credentials.



13. Since you changed the “Initialize and script ActiveX controls not marked as safe for scripting” option to Prompt, you’re asked if you want the ActiveX control to run.  Click OK and you’ve just completed integration of Active Directory and iLO.

You can download a PDF file from HP that discusses this process also (nothing about ActiveX mind you), including some items I’ve not discussed here.   There is also available for download a tool, HP Directories Support for Management Processors, that can supposedly be used to configure the iLO settings on multiple servers over the network.  I know it doesn’t run on Windows Vista, but I’ve not tried it out yet to see if can help with getting the rest of the server’s iLO settings configured. 

See, that was easy…right? 

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