Provisioning Computers with ILM ‘2’

In previous post I talked about different ways to provide Registration Authority (RA) functionality for device certificates. The 4th method was using ILM ‘2’ workflow functionality to control group membership. A few days ago I decided to setup a demonstration on how it actually can be done. I used ILM ‘2’ RC0 software which at the moment of this writing can be downloaded from this location https://technet.microsoft.com/en-us/evalcenter/cc872861.aspx. I used preinstalled VHD image to speed up my testing. Keep in mind that ILM ‘2’ only comes as 64 bit application and available VHD image is build for Hyper-V server.

There is good walkthrough on how to create computer object in ILM ‘2’ and how to join this object to the security group, check Bobby and Nima's ILM Blog blog for more information https://blogs.technet.com/doittoit/archive/2008/06/25/extending-ilm-2-to-manage-and-provision-computer-objects.aspx

So if you follow instructions in this blog it will walk you through all major steps required to configure ILM schema, modify ILMMA and ADMA, and create all required rules in ILM ‘2’ for object creation and workflow approval.

After going through all configuration steps I was able to provision computer object to AD, it was shown in my target OU with the name I specified in ILM. I was happy. Then I came to the point of joining actual computer to the provisioned computer object. It didn’t work, while joining computer to AD it would create another object and it would not join it to already existing computer object. So I started troubleshooting it and trying to figure out what was going on.

Obviously the first thing I did is opened computer object to see what is looks like. First discovery was that “Computer name pre-windows 2000” was some long pre-generated string, that looked like this - $C41000-7T6LLPIABSAP. “Computer name pre-windows 2000” is actually samAccountName attribute on the computer object. So ILM was creating computer object in AD with right DN name, but it was not populating samAccountName with the same name and let AD to auto-generate it for us. As you know that would be a problem. While my actual computer name was named “TestPC1” and it was showing in OU as TestPC1 (CN name), its samAccountName didn’t match the computer name. While joining it to AD it didn’t find the object with samAccountName matching computer name and created a new computer object. OK, I asked around and got suggestion that we need to flow samAccountName from ILM to AD. No problem, I added the following attribute flow:

After adding this attribute flow I created new computer in ILM, it showed up in AD, and its samAccountName was matching computer name. Great. Till I tried to join computer with that name to AD. Same problem, I was getting new computer object in AD and it was not joining to my object.

OK, this started to frustrate me. I tried to Reset computer object, it complained to me about password not being strong enough for the password policy. This was odd.

So I decided to compare computer object created via ADUC and computer object created with ILM. It is easy to do via ADSIEdit. I discovered that object type created by ILM was actually recognized by AD as User object, its userAccountControl attribute matched user object userAccountControl, not computer object. Very good. userAccountControl for computer object is 4128.

Back to ILM attribute flow, created another one that looked like this:

Created another computer account in ILM, it showed up in AD, I tried to Reset this object – no complains, looked at it in ADSIEdit, all attributes were computer object related. Last test, join computer to AD – it worked. Life is good.

So if you are trying to create computer object in AD via ILM ‘2’ I found that the following attribute flow will create the right computer object: