Populate your Active Directory Lab in a Flash

Need to populate an AD lab with a bunch of users quickly? Here's a quick tip to automatically create lots of users with little effort. I use this PowerShell one-liner to populate labs pretty regularly. You'll need to do this on Windows Server 2008 R2 with Active Directory PowerShell installed and your DC needs to be running 2008 R2 or 2003/2008 with the AD Management Gateway installed.  Open up a PowerShell session with the Active Directory modules imported:

PS C:\> Import-Module ActiveDirectory

… and then run the following command:

PS C:\> for ($i=0; $i -lt 1000; $i++) { New-ADUser -SamAccountName user$i -Name User$i -UserPrincipalName user$i@contoso.com -AccountPassword (ConvertTo-SecureString -AsPlainText P@ssw0rd -Force) -Enabled $true)

This one-liner will create 1000 enabled user accounts named User0 – User999 with the password of P@ssw0rd. You can adjust the range of user IDs by changing the the $i=0; $i –lt 1000; part of the for loop to the range that you want. For example, if you want to create User2534 – User3145, you would change it to ($i=2534; $i –lt 3146; $i++).

On a modest virtualized Domain Controller (single CPU @ 2.66 GHz and 1GB RAM) I can create 1000 enabled users in about 2 minutes and 14 seconds, which is around 7-8 users per second.  Not super fast, but enough to get a quick lab populated. I’ve used this one-liner in the past to create 1,000,000+ user environments for some virtualization testing and other things. It takes me about a day and a half to get 1,000,000 users created on my modest virtualized DC.

This is also a quick way to bloat your DIT if you want to do some scale and performance testing. To make your DIT bigger, you would want to inject some other data into these accounts, so in this command, you might add some additional attributes such as –DisplayName, –GivenName, –Surname, –Description, etc.

Figuring out What’s in the PAS

The other day, someone asked me what attributes in Active Directory are a part of the set of attributes that is replicated in the Global Catalog, also known as the Partial Attribute Set (PAS). To answer this question, let’s take a step back first. Let’s first look at the concept of partitions or naming contexts (NC) in Active Directory. A NC is a segment of the directory that contains information used for a common purpose and sometimes has a unique replication. There are 3 default Naming Contexts in Active Directory:

· The Schema NC holds the definition of the objects and attributes used to describe objects in the directory

· The Configuration NC holds data about the configuration of the Active Directory forest, such as the site topology

· The Domain NC contains information about a domain in the forest. This includes the objects in the domain, such as users, computers, etc. Each DC has a copy of the Domain NC for the domain that it belongs to.

There are also other NCs in Active Directory that you can use for application data. These are commonly called “application partitions” and they can be used for AD-integrated applications to store data in. The most common use of an app partition is AD-integrated DNS. DNS records are stored in an app partition and you can therefore specify its scope of replication, meaning that you can choose which Domain Controllers get a copy of the partition. Up until Windows Server 2003, application partitions didn’t exist and all of the data that AD held was in one of the three NCs that I defined above. DNS records, for example, were kept in the Domain NC, and that sometimes caused problems if you were in the situation where you wanted both a root and child domain to have a copy of an AD-Integrated zone. Since the DNS data was in the domain partition, only one of the domains could hold the DNS unless you went outside of AD replication and used zone transfers. Putting DNS records in an app partition solved this problem. For now, however, I’m going to put aside app partitions and just discuss the NCs that I mentioned earlier.

Why We Need the GC

Of the three NCs that I outlined above, only two of them get replicated to every Domain Controller in the forest – the Schema and Configuration NCs. This makes sense, as every domain in the forest uses the same schema and configuration data (i.e. site topology). The Domain NC, however, is only replicated among Domain Controllers within that domain. So what happens if a user or process in one domain in a forest needs to search for data in another domain in the forest? Since the Domain NCs are only kept on the DCs that own the domain, the search would have to take place on a DC in the other domain. This can become problematic if you want to search for data across the entire forest because you have to search in every domain.

The Global Catalog (GC) solves this problem by providing some information about the objects in every domain to all of the other domains. To understand how this works, let’s take a quick look at how the schema works. The database file that AD stores its data in is called NTDS.DIT. This database is a Jet database, which is a technology that Microsoft has owned for many years. Wrapped around this database is an engine for reading and writing data to and from the database. This engine is called the ESE (Extensible Storage Engine). The job of the ESE is to perform operations on the database so the application doesn’t have to open the database file directly and read and write data to it itself. The ESE enforces standard semantics on the data – things like ensuring that the data being written to the database doesn’t break the rules of the database. The ESE also puts some logic into the database allows for the transactional data model used in AD. This is the same data model used in Exchange server – the ESE enforces this. The ESE keeps transaction logs and ensures that the atomicity of the data is kept. For example, it ensures that either the entire operation is written to the database or none of it is written to the database. This guards the database against things like data corruption.

There are several tables inside of the NTDS.DIT database file. In Windows Server 2008 R2, there are 12. Some older versions of AD have fewer tables. The primary table that the data is held in is the table called “datatable”. Inside this table there is a row for every object in AD. Each column in the “datatable” table represents an attribute of the object. The schema is what defines each of these columns. A quick look at a Windows Server 2008 DC that I had running in a lab showed that there were 2,190 columns in my “datatable” table. Each object in AD is a row in this “datatable” table. Not every row has data in all of the columns. The Directory System Agent (the DSA) ensures that these columns aren’t filled in for a row that shouldn’t use it. For example, if you create an attribute called “ShoeSize” and only specify that “User” objects can use that attribute, then the DSA will ensure that the “ShoeSize” column can only contain data for rows that contain “user” objects. The interface used for accessing AD data (ADSI) ensures that every operation goes through the DSA, so people can’t break the rules.

How Attributes Are Defined

Each of these attributes (columns) in the directory has a list of properties that define how the attribute behaves – for example, the kind of data stored in the attribute or whether it’s indexed or not. The ata about each of these attributes is stored in the Schema NC. Each attribute has an object in the Schema NC called an attributeSchema object. One of the properties on the attributeSchema objects is the “isMemberOfPartialAttributeSet” property. This boolean (true or false) property defines whether or not the attribute is replicated as part of the Global Catalog. So if you want Domain Controllers for every other domain in the forest to have a copy of this attribute, you just set the isMemberOfPartialAttributeSet property to TRUE. The easy way to do this is through the Schema MMC snap-in. Before you can use it, you have to register it – run the following command from a command prompt:

Then open the Schema MMC and browse to an attribute object. Open the properties on the object and you’ll see the “Replicate this attribute to the Global Catalog” setting. If you check this box, the isMemberOfPartialAttributeSet object gets set as TRUE and this attribute is replicated to all DCs in every domain of the forest.

Listing All of the Attributes in the PAS

So let’s go back to the question at hand – how can we find out which attributes are in the PAS? Since we now know that this is actually defined by an attribute on the attributeSchema object, we can just do a search in the Schema NC for every object that has this value set to TRUE. One way to do this is to open up ADSIEdit.msc and do a custom query in the schema partition:

isMemberOfPartialAttributeSet=TRUE

Here’s the output from running this query on one of my WS08 R2 Domain Controllers:

Happy Schema-Editing!

Managed Service Accounts

Managed Service Accounts (MSAs) are a new feature in Windows Server 2008 R2. The concept is that the service account is managed by the server that’s using it. This can be very useful, as administrators will not be required to update passwords on these service accounts, and in some cases, the SPNs will be managed for you as well. To use an MSA, use basically create the service account object in Active Directory and configure the server to use the account. There are a couple of things you need to be aware of when using MSAs:

• MSAs can only be used on servers running Windows Server 2008 R2 or Windows 7.
• You are required to update the AD schema to WS08 R2.
• If using the automatic SPN management feature, your domain must be at Windows Server 2008 R2 domain functional level.
• MSAs can only be used on one server at a time, though you can have one server using multiple MSAs.
• MSAs should only be managed through the AD Module in PowerShell. Do not use the AD GUI tools or edit the directory directly for MSA objects.

Let’s take a deeper look at how MSAs work and how you can use them.

The MSA Object

MSAs are a new object class in AD called msDS-ManagedServiceAccount, which is a subclass of the Computer class. As you probably know the inheritance structure of the Computer class is:

Top > Person > OrganizationalPerson > User > Computer

This means that MSAs inherit the same attribute classes that Computer objects have. But if you look at the object class in the schema, you’ll notice that there are no added mandatory or optional attributes, nor are there any auxiliary classes added. So the difference between msDS-ManagedServiceAccount objects and Computer objects are minimal.

Password Changes

MSAs also don’t adhere to standard user password policies. You can’t set a fine grained password policy or control the complexity of the password for a MSA. It’s a hard-coded 240 character password that’s randomly generated. When an MSA is installed on a server, that server updates the MSA password using the same process that it uses to update its computer account password. Therefore, you can’t set password policies on the service account object itself. The password is reset every 30 days by default. To change this, you must update the policy for machine account password changes. In the registry, this is the following value:

HKLM\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters\MaximumPasswordAge

Or change the setting in the server’s GPO under:

Computer Configuration\Policies\Windows Settings\Security Settings\Security Options\

Domain member: Maximum machine account password age

Using MSAs

There are basically 4 steps to using an MSA on your server.

Step 1: Meet the prerequisites

There are a couple of prerequisites that must be in place before you can use MSAs. First and foremost, your AD schema must be updated to Windows Server 2008 R2. You are not required to have Windows Server 2008 R2 DCs, unless you want to use the automatic SPN functionality. If you do want the automatic SPN functionality, your Domain Functional Level needs to be at WS08 R2.

Also, the server that the MSA will be used on requires the AD PowerShell Module and .Net framework version 3.5.1. To install these features, open PowerShell with the system modules imported and run the following commands:

Add-WindowsFeature RSAT-AD-PowerShell

Add-WindowsFeature NET-Framework-Core

If you don’t have the Add-WindowsFeature cmdlet available, make sure that you opened the PowerShell with the system modules imported. To do this, right-click on the PowerShell icon and select Import System Modules:

Step 2: Create the Managed Service Account

Open PowerShell with the AD module (Start > Administrative Tools > Active Directory Module for Windows PowerShell) and run the New-ADServiceAccount cmdlet. The only parameter that you need to specify is the name of the service account that you are creating. When the account is created, the samAccountName will have a $ appended to the end of it, just like computer accounts.

PS C:\> New-ADServiceAccount svc_app

After you create the account, you can verify it by running the Get-ADServiceAccount cmdlet.

PS C:\> Get-ADServiceAccount svc_app DistinguishedName : CN=svc_app,CN=Managed Service Accounts,DC=contoso,DC=com Enabled : True HostComputers : Name : svc_app ObjectClass : msDS-ManagedServiceAccount ObjectGUID : 7a39e2fa-eb62-4ed9-83be-c974afb493f3 SamAccountName : svc_app$ SID : S-1-5-21-3140640322-4110138197-1547801364-1118 UserPrincipalName :

Step 3: Install the Managed Service Account on the server

Now that the account is created, you can install it on the server that will be using it for a service. Open the AD PowerShell on the server and run the Install-ADServiceAccount cmdlet.

PS C:\> Install-ADServiceAccount svc_app

Now, if you run the Get-ADServiceAccount cmdlet again, you will notice that the service account is tied to a specific computer.

PS C:\> Get-ADServiceAccount svc_app DistinguishedName : CN=svc_app,CN=Managed Service Accounts,DC=contoso,DC=com Enabled : True HostComputers : {CN=CONTOSO-SRVR,CN=Computers,DC=contoso,DC=com} Name : svc_app ObjectClass : msDS-ManagedServiceAccount ObjectGUID : 7a39e2fa-eb62-4ed9-83be-c974afb493f3 SamAccountName : svc_app$ SID : S-1-5-21-3140640322-4110138197-1547801364-1118 UserPrincipalName :

You may be curious about that HostComputers attribute. Where did that come from? I showed earlier that the msDS-ManagedServiceAccount object class didn’t add any additional attributes to the Computer class that it is inherited from. So where is this HostComputers attribute defined?

It’s actually defined in two places - the computer object that the service is installed on and the managed service account object. If you look at the objects in AD, you will see the msDS-HostServiceAccount attribute on the computer object and the msDS-HostServiceAccountBL attribute on the managed service account object. This attribute is a linked attribute, so it has both the forward link (msDS-HostServiceAccount) and the backlink (msDS-HostServiceAccountBL).

So the attribute is obviously defined on the MSA object, but we saw earlier that the MSA object doesn’t contain any additional attributes over the computer object. So that means that these attributes were injected as optional attributes into pre-existing object classes. Namely, the Computer object class and the Top object class.

Step 4: Configure the service that will be using the MSA

The last step to using the MSA is to configure the service to use the account. You can do this through a couple of different ways - but the easiest is just to use the Services snap-in. When you add the account to the service, ensure that the account name has the $ at the end and leave the password blank.

One thing that you may notice is that if you click the Browse button in the service configuration dialog, the Service Accounts option shows up in the object picker.

If you decide to configure the service with the MSA through another means, such as SC.EXE, you need to ensure that you grant the MSA permissions to logon as a service. This is done through the SeServiceLogonRight, which can be applied in the local security policy or through a GPO on the server.

My Thoughts

Managed Service Accounts are an interesting feature and I definitely think there is a need for them. However, much of what I have been seeing about MSAs is focused on how much money they will save you. Whenever something is automated, there is some cost savings (unless the management of the automation process itself is a bigger chore than manually administering the thing that you automated). But I think there is one shortcoming with the way MSAs have been implemented that limits its ability to help you saving money.

This shortcoming is that the account can only be used on one computer. How does this limit cost-savings? First ask yourself how service accounts are costing you bucks. Some might say that your admins waste time updating service account passwords. I think that argument is a red herring. If admins have to update service account passwords across multiple computers every couple of months that may cost you a few bucks. So you can spend some more money and buy some 3rd party software to take care of it for you, or you can take the “cost avoidance” approach. You know what I mean - use the “Password never expires” check box for your service accounts. A lot of people take the route of setting an obscenely large password length policy for your service accounts and not think about changing them. Granted, this offers a false sense of security in many ways, but hey - a longer complex password is harder to guess and takes longer to brute force.

However, if you are using shared service accounts and if you do change the password regularly, I do think there is some cost savings. But it’s not exactly in admin time - rather it’s in the server outages incurred by mistyped passwords or servers that the admin forgot to update the password on. The real damage happens when something causes those services to restart - this could be days or weeks from when you changed the service account password, so you may not immediately realize that the incorrect password is preventing the server from functioning. So I think you can get some cost savings by automating shared service accounts. However, MSAs can’t be shared between servers - therefore, no cost savings in this scenario.

So what’s the benefit, then? I think the benefit lies more with security than with cost savings. There are two primary reasons that I believe this. First, if you have a service running on one server, you can implement an MSA and have the password changed regularly. Changing passwords on a regular basis is one way to increase security. But the second and most impactful reason why MSAs boost security is that admins will no longer be able to logon interactively with service accounts. Sure, you can prevent this with GPOs now, but that process can be circumvented. On the other hand, with MSAs, it’s basically a computer account and the admin doesn’t know the password. I think there is a great benefit with that.

To sum it all up - Managed Service Accounts are good and I am definitely a fan. I do think however, that there could be some improvements that would make them more effective - namely, allowing MSAs to be shared across multiple servers.

Using Proxy Authentication Across Trusts

Back in December 2008, I wrote an article for Technet Magazine called “Understanding Proxy Authentication in AD LDS”. In this article I explained how proxy authentication works, walked through a couple of network traces, and took you through setting up your own proxy authentication lab that you can experiment with. Since then, I’ve received quite a few emails about this article and one of the common questions I’ve been asked is “Does this work across trusts?”.

The answer is yes, this does work across trusts. Here’s the scenario looks:

In this scenario, the LDS directory with the proxy objects are in the Contoso domain. However, the users that you want to proxy are in the Fabrikam domain. So even though the user account that you are proxying authentication to through AD LDS doesn’t exist in the same forest as LDS, you can still tie that user to an LDS userProxy object. The concept is simple, but this works in the opposite way that you would expect. What do I mean by this? In the most common scenarios, you might have a forest for user accounts and a separate forest for resources.  The account forest is typically trusted by the resource forest. This is so the resources in the resource forest (e.g. a file share) can give the account in the account forest permissions. In the example of a file share, that account in the account forest has its SID added to the share’s ACL. This common configuration is illustrated in the figure below.

However, this is not how it works in proxy authentication.  If you had LDS installed in the scenario above, you would probably consider the LDS directory to be a resource and include it in the resource forest. If you have the trusts configured in this manner, where the LDS forest trusts the forest with the user objects that you are proxying authentication to, your userProxy authentication will not work across that trust. The reason for this is because LDS isn’t treated as a resource in this scenario. Rather, LDS is storing the SID of the account in the account forest and telling the account forest to do the work of authenticating the user. Therefore, the resource forest needs to be trusted by the account forest and not the other way around.

So going with my example above, the Contoso domain needs to have an Outgoing trust to the Fabrikam domain, and the Fabrikam domain needs an Incoming trust from Contoso. After that, you can use the normal process for configuring userProxy objects, which I outlined in my article that mentioned earlier. You can check out that article by clicking here.