1dent1ty cHa0s

In my very first MVP Summit back in 2006 I ended up in a meeting of an unrelated topic to the one I was looking for due to a cancellation and I still came out ahead with some cool information. You see, way back then Microsoft was diligently working on "wikifying" TechNet and MSDN to make it more community driven. Each product group came over in their own time until now it seems you can find this little banner at the foot of every page wherever you go:

Anyone with a Windows Live ID can contribute content to any topic that has the Community Content enabled. This allows you to post your own comments, additions, links, clarifications and workarounds directly in-line with the content itself which is really neat. For more information about this, refer to the Community Content FAQ. Just get one thing straight, this is not a way to report bugs or ask questions - that is what the Connect Portal and TechNet Forums / MSDN Forums are for respectively.

If you check out the Identity Lifecycle Manager "2" (Beta) TechCenter you'll find some of my additions there. I would encourage anyone else that has had a meaningful experience or epiphany from working with the ILM 2 Betas to post their breakthroughs here as well.

So, while working with one of our TAP customers this past week I got the chance to do a really deep dive on Codeless Provisioning. The past weeks worth of posts here are the partial result of that endeavor and out of that came a deck with a few interesting slides that I thought would make good blog fodder. So here it is, in all of its glory, the "Codeless Provisioning Detour".

With MIIS/ILM we've enjoyed (some would say suffered) a somewhat inflexible system for provisioning new objects into other connector spaces - the Provisioning Rules extension. "Why do I need to write code to provision new accounts?" has been the frequent cry heard by the product group certainly since the product shipped back in 2003. We've all gotten used to handling our own "manual workflow" through this method despite its limitations and yet it has a peculiar bit of efficiency about it that you'll no doubt come to realize once you understand how Codeless Provisioning works. Let's look at how things work today:

The Sync Engine today is able to leverage the Provisioning Rules extension to directly to make decisions that can result in the immediate creation or deletion of objects in other connector spaces.

This creates a pretty efficient pipeline when you can take information from an authoritative source, make a decision about it and then immediately take action. With Codeless Provisioning we have to take a "detour" through the ILM MA and the portal application so the workflows, processes, and policies can work their magic.

With ILM 2, in order for WF to take effect you have to first get the object into the portal to begin with. Getting the object into the portal allows your Management Policy Rule to fire and create the ExpectedRuleEntry object for every object that falls under the scope of your Synchronization Rule.

When you check the little box on an Inbound Sync Rule to "Create object in ILM" it's provisioning the object into the ILM MA datastore so it can be evaluated for Outbound Sync Rules.

It doesn't really matter yet that you have Outbound Sync Rules already in place - until you take the detour through the ILM MA your new objects can't be added to the scope of those rules yet; more on this later.

In my last thrilling expose on the nocturnal habits of service accounts (they authenticate even when you're not looking, eww) I talked a bit about the need for the ILM MA account. In some circles it's also called the SyncEngineAccount (not to be confused with the actual account used to run the Sync Engine, seriously) and in the ILM 2 portal it lurks as the unassuming Built-In Synchronization Account (BISA anyone?). Whatever you call it, there are a few interesting things you should know about this cantankerous chameleon:

• It should be separate from the account you're using to run the ILM Sync Engine (miiserver) - more out of the need to enforce least privilege than any hard or fast rule
• It does not need to be a Local Admin, although making it one alleviates the need for the next item if SQL is on the same box; nonetheless keep the privileges light
• It does require as much as db_owner access to the MSILM database - at first I didn't think this was necessary but after further testing (and removing it from Local Administrators) this turns out to be true; there is probably a least privilege combination but I haven't found it yet since the whole Beta 3 is so touchy
• It does have to be in the MIISAdmins group for it to be able to create Sync Rules and make configuration changes within ILM Sync
• There is a bug (seen it twice myself and Joe Stepongzi confirmed it as well) where somehow this account gets an ExpectedRulesEntry applied even though it doesn't fall into the scope or sets defined by the MPR

So, what do we call this thing?

• Sync Engine Account - too easy to confuse with the service account you're using to run the ILM Sync Service (miiserver) and I don't think they should be the same account although I expect many people will take a shortcut here and do just that
• ILM MA Account - a little better but a little too self limiting perhaps as it does have a role, however nebulous and nefarious in the ILM 2 Portal
• Built-In Synchronization Account - a little long but probably the best description and it is less confusing than just Sync Account or Sync Engine Account

So, my vote is for the Built-In Synchronization Account, I'd like to see the language around how the product exposes it become more consistent so that there is less confusion.

Say goodbye to the simple days of two or three service accounts to run ILM. I'm not talking about the various accounts you might have to run the MA's you have, but the accounts used to run the Services themselves. An existing implementation might have the following basic accounts:

• ILM Service Account - the service, miiserver
• ILM Install Account - used by some instances where a separate account is needed that has sa rights to SQL for app and patch installs
• MA Account(s) - used to access data sources like AD, SQL, etc...

...and don't forget the SQL Service Account. For ILM 2 I've been trying to get my head around all of the new requirements so we can build our internal standards around what each account is named and what it is used for. Here is what I have so far:

• svc.sql - no change here, this is our SQL Server account and there may, in fact, be others for the Agent, SSIS, etc...
• svc.wss - Windows SharePoint Services needs an account to run the AppPool that the default Site Collection runs under
• svc.wssfarm - Windows SharePoint Services need an account to run the AppPool that the Central Administration site runs under as well as the Timer service
• svc.ilmsync - This is the account that runs the sync engine - good old miiserver
• svc.ilmma - This is the special synchronization account used for the ILM MA to communicate with the Web Services
• svc.ilmws - This is the account for the new ILM Web Service (Microsoft ILM Common Services)

Note that I'm not making use of Network Service here - I want Kerberos delegation (once multiple tiers are supported) to be from service account to service account and if you use local security principals like Network Service or Local System you have to delegate from the computer account.

Most of the above accounts make sense, with the exception of the special sync account - svc.ilmma. This account shows up during the ILM Server installation and appears in two places you should be aware of:

• Program Files\Microsoft Identity Management\Common Services\Microsoft.ResourceManagement.Service.exe.config - the appSettings tag references it as the SyncEngineAccount property seen here:

<appSettings>    

  <add key="mailServer" value="mail.ensynch.info"/>

  <add key="isExchange" value="0"/>

  <add key="sendAsAddress" value=""/>

  <add key="synchronizationServerName" value="ENS-ILM01"/>

  <add key="SyncEngineAccount" value="info\svc.ilmma"/>

appSettings>

• ILM MA - in order to read and write to the new MSILM database you have to use the special sync account. Now, if you're tempted to use the same account you used for the webservice, it will read successfully; however you will not be able to write, observe:

If you don't use the account you specified at setup for the Sync Engine Account as the identity powering the ILM MA then you're attempts to Export will be frustrated by cd-errors. They are nasty, vicious, brutal and don't have any error descriptions (at least in beta 3). And, if you're wondering, while this account is not delegated rights to the MSILM database in SQL it does have to be in the MIISAdmins group. It has to be in this group because of the new dependencies for Synchronization Rules. If you think about it, it makes sense - the ILM portal is passing down a configuration set and the engine is processing it...using the credentials specified in the ILM MA...which had better have rights to make configuration changes in ILM.

If you're testing ILM 2 Beta 3 then you'll want to use the following link to the Identity Lifecycle Manager TechCenter for ILM "2" (Beta).

The same documentation you downloaded in the ITPro documentation pack is fresh and up to date here; especially the Getting Started section for the walkthroughs which were plagued by some early typos.

On the other hand, if you're after up to date documentation on the existing product then look at the Identity Lifecycle Manager 2007 area.

I seem to discover all of my errors during the installation. :)

If you've had a premature failure sometimes you'll see this error in the log:

CAQuietExec:  Executing solution-deployment-microsoftidentitymanagement.wsp-0.
CAQuietExec:  The solution-deployment-microsoftidentitymanagement.wsp-0 job completed successfully, but could not be properly cleaned up.  This job may execute again on this

or this...

CAQuietExec: 
CAQuietExec:   A solution with the same name "ilmpasswordportal.wsp" or id "df66f0f3-ac0a-4781-b28a-66ec92377aea" already exists in the solution store.
CAQuietExec:  E:\Program Files\Microsoft Identity Management\Web Portals\ILMPasswordPortal.wsp: The Solution installation failed.
CAQuietExec: 
CAQuietExec:  Error 0xffffffff: Command line returned an error.
CAQuietExec:  Error 0xffffffff: CAQuietExec Failed

Here is how you clean it out:

1. Open SharePoint Central Administration
2. Click the Operations Tab
3. Under Global Configuration, click Solution Management

You should see this:

1. Click the hyperlink for offending WSP

You'll probably see something like so:

1. Click the Remove Solution link and click OK to delete the WSP file

Now you can try your reinstall again...

So, the .NET Framework 3.5 service pack 1 has been released; however if you are testing ILM 2 Beta 3, don't apply this to your server as the current ILM Server package won't work properly and it certainly won't install.  Here is the Connect bug:

ILM Server will not install with .NET Framework 3.5 SP1

If you're staring at this screen wondering why the drop-down boxes won't populate while trying to create a Synchronization Rule:

...that is because, like I am inclined to do, you installed the Sync and WS on separate platforms. I've gotten everything to function superficially until you get to this page and the lists just will not populate. This has something to do with the WS not being able to pull the information out of the Metaverse because it's on a separate box and this configuration isn't supported in Beta 3 anyway. From what I understand, the intention is to support this in future versions but for now you must stick with a single tier to test this with.

psconfig -cmd installfeatures

1. DB/Sync Tier - hosts the SQL DB's for both ILM Sync and ILM Server portal, and all of the WSS DB's; the ILM Sync app itself (formerly MIIS) is running here
2. Web/App Tier - hosts the App/IIS Roles, WSS Web Frontend, and ultimately the ILM 2 Portal; the ILM Web Service is running here

msiexec /i ilm-server-64bit.msi /log ilmserverx64.txt

Action 8:51:25: StsAdmInstallCreateWeb.
CAQuietExec:
CAQuietExec: Failed to instantiate file "default.master" from module "DefaultMasterPage": Source path "default.master" not found.
CAQuietExec:
CAQuietExec: Error 0x81070587: Command line returned an error.
CAQuietExec: Error 0x81070587: CAQuietExec Failed
Action ended 8:51:32: InstallFinalize. Return value 3.

cd /d C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\BIN
stsadm -o uninstallfeature -id 2E279CD0-C88F-43d8-B3DE-CE333D8FBCFA
stsadm -o uninstallfeature -id E2383F3D-7C1C-4368-B91B-5567684B464B
stsadm -o uninstallfeature -id 5B69107E-DCE0-4f49-80A2-24B78C202CE3
stsadm -o uninstallfeature -id 8ECFC16B-5E2D-4a82-9BD2-31F73C8FF058

Here's another little nugget in the never ending struggle to kerberize your SharePoint implementation - Kerberos authN against the SSP infrastructure:

The Infrastructure Update for Microsoft Office Servers includes a new, custom-format SPN for Kerberos authentication for the SSP infrastructure. This custom-format SPN introduces a new Service Class: MSSP. The custom-format SPN uses the following format: MSSP/<host:port>/<SSP name>. This new custom-format SPN sets a .NET Framework property to direct the .NET Framework to use a specific SPN for a given URI. The .NET Framework is used to make inter-server calls to the Office SharePoint Server 2007 SSP infrastructure Web services. 

I highly recommend taking a look at this article and the subsequent reference documentation - Configure Kerberos authentication (Office SharePoint Server).

To the SharePoint : Enabling Kerberos authentication for an Office SharePoint Server 2007 farm deployment