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 84710 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: adusersdn: 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!
Activate SCR Target via EMS script
If you’ve got SCR installed and are using the Database Portability model described in “Standby Continuous Replication: Database Portability“, here’s a useful Exchange Management Shell that scripts the entire activation process. Just change all of the noted fields to match your source and target servers and even add additional storage groups/databases to the script if you like.
Be sure to triple check your entries and TEST IN A LAB ENVIRONMENT before unleashing this production!
Activate-SCRTarget.zip (1.6 KiB, 662 hits)
Cleanup after DPM 2007 SP1 installation
You might have noticed, if you’ve installed SP1 for Data Protection Manager 2007, that it leaves behind the Visual C++ 2008 Redistributable package contents in your root directory. Tsk, tsk. How did that slip through beta, but yet be specifically called out in the Release Notes?
DPM 2007 SP1 setup leaves Microsoft Visual C++ Redistributable Package installation files in the root directory. You can manually delete the installation files.
Anyhow, here’s a quick and dirty batch (.bat) file that you can run on the local machine to delete the files.
Get it here:
Visual_C_2008_Redist_cleanup.zip (325 bytes, 928 hits)
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.
Scheduled task for EVAPerf
Note: This information is based on a Gen 1 EVA…things are not necessarily the same with newer generations. Your mileage may vary.
If you’ve got HP EVAs as your storage platform, you’ve probably heard of EVAPerf at some time or another…
Sure, you can run EVAPerf interactively now and then to gather data on your EVAs, but what about running it as a scheduled task and keeping a month or three or more of daily output files? You can easily do that using a scheduled task on the server running Command View and the two scripts attached here. That way you actually have the data when you need it, usually when something goes wrong in your EVA environment.
The first script is a simple VBScript that deletes files older than XX days from directory YY. You specify both items and it just works. In fact, both items you need to put are in a single line in the script! The line below assumes that you’ve created a “Data” folder inside of your “EVA Performance Monitor” folder…why not. 30 days of data will be retained with this entry.
Call CleanDirectory(”C:\Program Files\Hewlett-Packard\EVA Performance Monitor\Data”, 30)
The second script is a batch file that calls the VBScript cleanup script and then actually runs the EVAPerf command. You’ll need to have done your homework first on setting friendly names and so forth on your EVAs, but your local HP storage support team should be able to assist with that if you don’t already have that done.
The second script does a few nice things for you. First of all, it automatically generates a new file name daily with date/time in the file name. Not as easy from the command line as in VBScript or Powershell, but it can be done. The script also clears the counters on the EVA and then runs the EVAPerf command. You’ll want to pay attention to make sure you edit the EVA WWN correctly, and you might even want to not clear counters. Again, up to you and local support.
Put both scripts, once you’ve edited them, in a folder named “Scripts” inside your “EVA Performance Monitor” folder and then create a scheduled task to run the batch file. The account you use to run the batch file needs to be a local admin on the server where the scripts (and Command View) are running as well as a storage administer. How you go about setting that up depends on whether or not you have your Command View server in your Active Directory domain (all new installations) or if its in a work group (older SA based installations).
Configure the scheduled task to run once daily, I’d suggest midnight local time. Then configure it to only run for 23 hours and 58 minutes. That makes sure you get a new run daily, with a new file.
Pay attention to the following lines which require editing in the batch file:
- set filename (put your EVA name in here)
- The line where counters are cleared (put your EVA name here)
- The line where the actual EVAPerf command is issued (put your EVA WWN here). Note that you may want to change what EVAPerf data you are collecting here.
Here’s a whitepaper on EVAPerf (happy reading): whitepaper
Get the scripts here…
EVAPerf.zip (1.5 KiB, 1,296 hits)
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)
Quickly Grant Send As Permissions on a Distribution Group
Every now and then I get a request to grant someone “Send As” permissions on an Exchange Server 2007 distribution group. It’s not that difficult, but perhaps just not very evident at first glance. You can go about it quickly from the Exchange Management Shell (or just plain old Power Shell) like this:
Add-ADPermission -Identity “Group Name” -User “UserName” -AccessRights extendedright -ExtendedRights “send as”
You can use the alias or display name for the user and the display name for the group.
Of course, you could always use Active Directory Users and Computers and set the Send As attribute, which you’ll notice is set for the indicated user after using the Power Shell method.
Read all about the Add-ADPermission cmdlet here.
Disabling Active Directory User Accounts, Part 1
For a few years now I’ve been using a custom VBScript to disable AD accounts when employees leave the organization. The script was pieced together from some things I knew how to do and others I was able to find elsewhere. The script performed the following tasks:
- Disabled the specified AD account
- Hid the mailbox from the Global Address List
- Removed the account from all groups it was a member of
- Created a text file log of all groups the account was a member of
- Set the password to be changed at the next login
- Set the disable date in the “Title” field (an unused field in my organization)
- Set the RAS settings to disabled
After our upgrade to Exchange Server 2007 earlier this year I noticed that the script was not functioning fully the way it should have. Specifically, the hiding of the mailbox from the GAL was not occurring. Sure, if you looked at the mailbox of an account that had been disabled using the script in the Exchange Management Console, the check box to hide the mailbox from the GAL was checked, but just the same the mailbox was not really hidden from the GAL.
So to correct this issue, I wrote a new script in Powershell (requires the Exchange Management Shell snapin) script that would perform all of the same actions except setting the RAS attribute to disabled.
Both scripts are attached, and annotated where I remembered where certain portions of the script or ideas came from. The VBScript should be able to be run without any changes unless you want to change what it does. The Powershell (Exchange Management Shell) script should only require one change in the variable $domain as shown here: $domain = LDAP://dc=mydomain,dc=local.
VBScript version:
disable_accounts_single.zip (1.7 KiB, 1,407 hits)
Powershell (Exchange Management Shell) version:
Disable-ADAccounts.zip (1.8 KiB, 1,199 hits)
-
Translator
