Alex Tcherniakhovski - Security : Active Directory Programming

Utility to load Active Directory with sample data and introduce incremental changes

alextch — Wed, 11 Jul 2007 00:17:00 GMT

This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm

Quite often I find myself in a situation where I need to quickly build a test environment for Active Directory (AD), whether it is to perform some MIIS directory synchronization testing or performance benchmarking of an application that utilizes AD.
I took an initial stab at this problem by creating a simple VB script (ADPopulator) that was using several Excel spreadsheets as an input for creating some randomized by still realistic user information. You can see more info on that script here: http://blogs.msdn.com/alextch/archive/2006/09/18/AdPopulate.aspx. The script has a number of limitations though:
• It only deals with user accounts and does not provide support for group population
• You can only load accounts using this script. Quite often in directory synchronization tests we need to introduce some random changes into directory (modifications, deletions, additions)
• It has very limited support for randomly populating AD attributes beyond SN, givenName, samAccountName, and userPrincipal Name
• It requires Excel to be installed on the server
So when working on a test harness for my Oracle extensible MA I decided to write something that addressed the above limitations.

Introducing ADModifer 1.0
ADModifier is written in C# (get the source and executable in the attachment section of this blog), and unlike the ADPopulator does not require Excel to be installed on the server. As a matter of fact all that is required to run this utility is .NET 2.0 framework.
Similarly to ADPopulator ADModifier utilizes a dictionary of European names to generate random material for SN, givenName, samAccountName, userPrincipal Name. This time in order to avoid the need for Excel or other databases I simply included the dictionary right in the executable by creating two classed FirstNames and LastNames. This change helps with rapid test environment setup, where all you need to do is just drop the executable on the server. But if you need to add some additional names into your test environment you would have to modify the source code (take a look at FirstNames and LastNames classes, I am sure it will be evident how to add additional names into the mix).
ADModifer utilizes .NET config file (ADModifer.exe.config) for its configuration settings. I will go over the config file parameters in detail later in this blog.

Some conceptual stuff
Before getting you started with the utility let me explain some of the concepts that I used when developing this utility.
Randomness
There are several aspects of randomness that I utilize in this utility.
First, the user IDs are generated by randomly selecting first and last name from a dictionary of European names. Prior to creating a new account the utility checks if such ID based on a random combination already exists and will add an integer to the end of the ID if a conflict exists. There is logic in the utility to keep looping and incrementing the integer until a unique ID is found, that is why you will see IDs of such format jbrown1234.
Second aspect of randomness in the utility is about picking accounts for deletion and modifications. At startup the utility will search the directory and create an array of all the user objects currently present in AD. If your directory is empty then run the utility in initialLoad mode to only create new accounts (more on this when we talk about the config file). Once such an array is created we can randomly pick objects from the array by using .NET random object. So if we want delete 5% percent of the existing accounts the utility will iterate through the array and using random number generator as an index into the array of all AD objects will delete the required number of accounts. Same idea for modifying accounts
Before I bring in the third aspect of randomness in the utility let me introduce the concept of a template first.
Prior to running a utility you will create an OU into which you will place accounts that represent your typical user account settings. For example: you may simulate different departments and locations by creating template accounts that represent respective user populations. So let’s say in my test I want to simulate a company with four locations. I will create four accounts in the designated OU (more on this OU in the config section of this blog). Each template account will have all of the attributes setup to represent that specific location (for example: l, department, manager, postalAddress etc). Also create some AD groups that are typical in that location and add the template accounts into those groups.
The idea here is that when we are creating a new account or modifying and existing account a set of attributes will be copied by randomly selecting a template account and copying those attribute from it. This can simulate employees moving to a different location or a different department. Also this approach allows for introducing some changes into the group membership within AD. So this the third aspect of randomness in this utility – we randomly select a template account from which we copy specified attributes and group membership. The more template accounts your create the better distribution of values you will get in your test environment.

Getting Started
So enough with theory let’s take ADModifier for a spin
1. Installation. Copy ADModifer and ADModifier.exe.config to a folder of your choosing on the server.
2. Preparing AD.
a. Create an OU structure into which you want ADModifier to create new accounts. I suggest creating an OU dedicated for testing. This OU can have children; there are no limitations on the depth of the tree. New accounts will be evenly and randomly distributed between OUs in this structure.
b. Create a separate OU outside the OU you created in step A for groups. Manually create as many groups as you think are necessary for your tests.
c. Create a separate OU outside the OU you created in step A for template accounts. Create as many template accounts as you need (the names of the template accounts are arbitrary). Set all of the AD attributes that personalize a template account (department, location, address, manager, etc). Also add the template accounts into the groups created in step B. The idea here is that each template account will be a member of specific set of groups. Those group memberships and attributes will be copied into new and modified accounts.
3. Modify ADModifier.exe.config to adjust it to your environment.
Below is a sample config file that I used in my test environment.
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<appSettings>
<add key="initialLoad" value="FALSE"/>
<add key="initialLoadAmount" value="10"/>
<add key="usersRoot" value="OU=employees,DC=contoso,DC=msft"/>
<add key="addAtTheRoot" value="FALSE"/>
<add key="userTemplateRoot" value="OU=templates,DC=contoso,DC=msft"/>
<add key="defaultPwd" value="pass@word1"/>
<add key="attributesToCopyFromTemplate" value="l;deparment”/>
<add key="percentToAdd" value="5"/>
<add key="percentToDelete" value="5"/>
<add key="percentToModify" value="5"/>
</appSettings>
</configuration>
Let me go through each of those setting one at a time
initialLoad – if your AD is empty you will need to do initial loading of sample data. In other words you are not at the point to specify in terms of % how much change to introduce, you simply want to get some initial data loaded. Note: even for the initial load you will need template accounts setup, since new accounts will be personalized based on those tamplates.
initialLoadAmount – This attribute is used in conjunction with the initialLoad and specifies how many accounts to create
userRoot – Distinguished name of the OU where new accounts will be created. This OU is also used as a target for account deletions and modifications. OUs that reside below this OU will also be used by addition, deletion and modification processes
addAtTheRoot – Quite often you may want to setup your OU structure as such: employees->East, employees->West. In this setup East and West are children of the employee OU, and if you don’t want new accounts to be created at the root (in this case employees, but only in sub OUs: east and west) set this value to FALSE. If you have only one OU into which you want to load all of you new accounts make sure to set this to TRUE.
defaultPwd – The value of a password that will be assigned to the new accounts
attributesToCopyFromTemplate – This is a list of attributes separated by semi-column which you want to be copied from the template accounts
percentToAdd - % of new accounts to be created
percentToDelete - % of accounts to be deleted
percentToModify - % of accounts to be modified
4. On your first run set the initialLoad to TRUE and specify the number of accounts you need to create.
5. On subsequent runs set the intialLoad to FALSE and adjust percent values for additions, deletions and modifications.

Certain things to be aware of
1. Performance. Since at startup the utility needs to create an array of all existing accounts in the AD, this may take quite a bit of time and memory if you are building really large AD database. In my environment with 12000 accounts it takes over a minute for the utility to start doing some work.
2. Make sure to put correct values in the config file. I am only doing limited error checking so some error messages may be quite generic if you put wrong values into the config file.

After publishing this blog, I got a couple of e-mails where people were getting "The Server is unwilling to process the request error". After investigating this further I found a bug in my code, which is not fixed.

The issue was around setting the userAccessControl attribute. Initially I was setting this attribute in the following sequence:

newUser.Properties["userAccountControl"].Value = 512; newUser.CommitChanges();
newUser.CommitChanges();
newUser.Invoke("SetPassword", new object[] { ConfigurationSettings.AppSettings.Get("defaultPwd") });

which worked fine in my lab environment where password complexity policy was disabled, but would produce the above mentioned error if password complexity policy is enabled.

Rearanging the sequence like so fixed the issue:

newUser.Invoke("SetPassword", new object[] { ConfigurationSettings.AppSettings.Get("defaultPwd") });
newUser.Properties["userAccountControl"].Value = 512; newUser.CommitChanges();
newUser.CommitChanges();

Active Directory Schema Design Considerations and Auxiliary Classes

alextch — Wed, 16 May 2007 22:03:00 GMT

This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm

This blog addresses one very specific but important issue around rules of creating auxiliary classes, and as most of my blogs, is based on something I stumbled upon while working on one of my projects.
The scenario I am working on involves extending Active Directory schema for the purposes of storing Oracle related information in Active Directory. For more details on the approach of synchronizing AD and Oracle security information see my previous blog on this subject: http://blogs.msdn.com/alextch/archive/2006/06/05/ADtoOra.aspx
For the purposes of this discussion what is important is that we need to store additional information in the AD user class that pertains to Oracle specific attributes. The best practice around extending AD schema suggests creating an auxiliary class to store such information as opposed to modifying directly schema classes provided by Microsoft. The idea here is to create OracleSecurityPrincipal auxiliary class, which contains Oracle specific attributes and then later add this class as an auxiliary class to the User schema class. In this way we encapsulated all of the Oracle related information in a separate class but still have the ability to store these attributes in AD user object.
So I followed this guidance and created an LDIF import file that would create the required structure.
Below you can see an excerpt from that LDIF file.

dn: CN=codePlex-OraDefaultTableSpace,CN=Schema,CN=Configuration,DC=fabrikam,DC=msft
changetype: add
adminDisplayName: codePlex-OraDefaultTableSpace
attributeID: 1.2.840.113556.1.4.7000.159.24.10.66
attributeSyntax: 2.5.5.12
cn: codePlex-OraDefaultTableSpace
description: Specifies Oracle Default TableSpace
isMemberOfPartialAttributeSet: FALSE
isSingleValued: TRUE
lDAPDisplayName: codePlex-OraDefaultTableSpace
distinguishedName: CN=codePlex-OraDefaultTableSpace,CN=Schema,CN=Configuration,DC=fabrikam,DC=msft
objectCategory: CN=Attribute-Schema,CN=Schema,CN=Configuration,DC=fabrikam,DC=msft
objectClass: attributeSchema
oMSyntax: 64
name: codePlex-OraDefaultTableSpace
searchFlags: 0

dn: CN=codePlex-OraProfile,CN=Schema,CN=Configuration,DC=fabrikam,DC=msft
changetype: add
adminDisplayName: codePlex-OraProfile
attributeID: 1.2.840.113556.1.4.7000.159.24.10.68
attributeSyntax: 2.5.5.12
cn: codePlex-OraProfile
description: Specifies Oracle Profile Name
isMemberOfPartialAttributeSet: FALSE
isSingleValued: TRUE
lDAPDisplayName: codePlex-OraProfile
distinguishedName: CN=codePlex-OraProfile,CN=Schema,CN=Configuration,DC=fabrikam,DC=msft
objectCategory: CN=Attribute-Schema,CN=Schema,CN=Configuration,DC=fabrikam,DC=msft
objectClass: attributeSchema
oMSyntax: 64
name: codePlex-OraProfile
searchFlags: 0

DN:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

dn: CN=codePlex-OraSecurityPrincipal,CN=Schema,CN=Configuration,DC=Fabrikam,DC=msft
changetype: add
adminDisplayName: codePlex-OraSecurityPrincipal
description: adds Oracle related attributes to the user class
objectCategory: CN=Class-Schema,CN=Schema,CN=Configuration,DC=Fabrikam,DC=msft
objectClass: classSchema
lDAPDisplayName: codePlex-OraSecurityPrincipal
governsID: 1.2.840.113556.1.4.7000.159.24.10.611.11
instanceType: 4
objectClassCategory: 3
subClassOf: top
mustContain: codePlex-OraDefaultTableSpace
mayContain: codePlex-OraProfile

DN:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

dn: CN=User,CN=Schema,CN=Configuration,DC=fabrikam,DC=msft
changetype: ntdsSchemaModify
add: auxiliaryClass
auxiliaryClass: codePlex-OraSecurityPrincipal
-

DN:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

So let’s quickly walk through this LDIF file.
Firstly, we created several Oracle related attributes (there are many more required attributes, but I removed them to conserve space).
Secondly, an auxiliary schema class is created and the attributes created in step 1 are attached to it via mustContain and mayContain attributes of this class. We will come back to those two attributes shortly.
Thirdly, we add the auxiliary class created in step to 2 to the user schema object.

When I put together this LDIF file it seemed pretty logical to me, but when I ran this file against my test environment I got the following error message “Unwilling to perform. The server side error is 8505.” This error occurred while trying to add the OracleSecurityPrincipal auxiliary class into User structured class.

After conducting some research I realized that the issue was around the mandatory attributes defined as part of the auxiliary class via mustContain attribute. During addition of an auxiliary class AD checks if there are any existing objects of the structured class that we are modifying (in our case we are dealing with the User class, and of course any AD deployment would have existing user objects), but since I defined codePlex-oraDefaultTableSpace as a mandatory attribute, this would create an integrity issue within AD where some object that were created previously would be missing some mandatory attributes, and therefore AD refused this change.
So now that we understand the issue at hand, the only way to fix this issue is to make all of the auxiliary class attributes optional, by specifying them as mayContain.
mustContain: codePlex-OraDefaultTableSpace
mayContain: codePlex-OraProfile
Even though from the logic of the OracleSecurityPrincipal class the OraProfile attribute may be considered optional and OraDefaultTableSpace mandatory.
This was not intuitive to me at the beginning, but I suppose this is something that we need to keep in mind when working with auxiliary classes, especially if we plan to add them into the structured classes that already have objects in AD.

Populating InfoPath 2007 Forms with data from Active Directory

alextch — Sat, 25 Nov 2006 07:31:00 GMT

This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm

This walkthrough shows you how to automatically populate an InfoPath 2007 form with information about the current user by utilizing data stored in Active Directory.

Even though not intended as a tutorial on InfoPath 2007 programming, this walkthrough will also introduce you to some basic programming tasks in InfoPath 2007: enumerating through form elements, programmatically setting an element value, etc.

Please, follow this link for detailed screencast of the solution.

Script to populate Active Directory with test accounts

alextch — Mon, 18 Sep 2006 19:26:00 GMT

This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm

Probably like many of you, I quite often need to create test environment for dealing with a range of test scenarios. Invariably, when building a test environment, a question comes up on how to populate Active Directory with test accounts to simulate production environment. Sometimes you may be able to perform restore from production environment or get an export from HR or other systems. But in many cases (for example performance testing, product functionality testing, backup and recovery etc) you don’t really need to have an exact replica of your production environment, so it would be very useful to have a script that could generate a simple but realistic Active Directory environment based on some random names.

Luckily, there is script available on Microsoft scripting repository site that provides us with a starting point http://www.microsoft.com/technet/scriptcenter/scripts/ad/users/manage/usmgvb03.mspx?mfr=true

This script will generate an arbitrary number of accounts in a specified OU based on a very simple naming convention (User1, User2, … UserN).

Despite the fact that this is a good starting point, the script has some limitations:

Does not distribute users across OUs
The names are not realistic. By the way, why having realistic names is important? Well, if you doing tests on conducting automated user management, sometimes real world names will cause some issues if you don’t catch them in the test. For example, would you process properly handle names with spaces in them, or accented characters?

Finally, I decided to invest some time and enhance the script to overcome those limitations. The script that I provide here takes as an input 3 Excel Spreadsheets: first names list, last names list, and OUs list. As you may have guessed, the first names list provides a list of sample first names and the last names list provides a list of sample last names. I provide 2 Excel spreadsheets with European names; feel free to modify those to fit your locale. The script creates a name based on selecting random values from the list of first and last names. The samAccountName is generated based on first letter of first name and full last name. Despite using random combination of names, the script quite often may produce identical names which would cause errors while creating AD accounts. In this script I simply ignore those errors and let the script try again.

The third Excel spreadsheet has a list of Active Directory OUs names (fully distinguished names) among which to distribute the users (sample provided below)

Before running the script, modify this portion of it according to your environment:

REM Modify these values according to your environment

excelPathFirstNames = "c:\dbpopulate\FirstNamesEurope.xls"

excelPathLastNames = "c:\dbpopulate\LastNamesEurope.xls"

excelPathOUs = "c:\dbpopulate\ou.xls"

upnSuffix = "contoso.com"

count = 30000

Set objRootDSE = GetObject("LDAP://rootDSE")

By the way, since the script uses Excel files as an input make sure to have Excel installed on the machine from which you are executing the script.

That is it; I hope that you may find this script useful.

The script and accompanying sample files can be found in this blog attachment below.

Walkthrough: Creating Active Directory custom data source component in SSIS

alextch — Thu, 09 Mar 2006 04:29:00 GMT

Walkthrough: Creating Active Directory custom data source component in SSIS

This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm

This walkthrough serves several purposes:

Provide an end-to-end example of creating a custom data source component for SSIS. Concepts described in this document could be applied to writing custom components for sources other then Active Directory.
Create a community driven component for extracting data from Active Directory into relational format. The extracted information could later be used for reporting and data mining.

View the walkthrough here

Source code provided as an attachment to this blog.

How to convert objectSID value in Active Directory from binary form to string (SDDL representation)

alextch — Sun, 05 Mar 2006 03:22:00 GMT

How to convert objectSID value in Active Directory from binary form to string (SDDL representation)

This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm

Recently I have been working on a project in where I was extracting some data from Active Directory into a SQL table. One of the attributes that I wanted to get from AD was objectSID (this attribute uniquely identifies an object in a domain). ObjectSID is stored in AD as a binary value, but in order for it to be useful in my application I wanted to convert it to string representation, so that I could later conduct searches against it. I searched the web, posted on MSDN ADSI forum but could not really find an elegant solution that would easily accomplish this task.

Basically before .NET 2.0 the only way to convert objectSID to a string was by using win32 API called ConvertSidToStringSid. Here is a link to the pinvoke.net site, which provies examples on how to call this API from your .NET code.

But of couse, my preference would be to use managed code, as oppoesed going through win32 API, plus I knew that there must have been a more elegant way to perform this task, since this should be probably a very common operaton for folks working with AD. Anyway, I am currenlty reading an excellent book by Stefan Schackow “Professional ASP.NET 2.0 Security, Membership, and Role Management”, and in there I stumbled on a piece of code where author was using SecurityIdentifier class in one of his examples. I did some further searching on this class in .NET documentation and was very happy to find out that this class allows us to easly (2 lines of code) convert objectSID from binary to string.

Here is how to do this:

public static string SIDtoString(byte[] sidBinary)

{

SecurityIdentifier sid = new SecurityIdentifier(sidBinary, 0);

return sid.ToString();

}