IdM for Real

Anyone working with the FIM Sync engine, in its current or previous guises, for any length of time will be familiar with the age old dilemma – how best to ensure uniqueness constraints of a newly provisioned AD account.  Or a mailbox alias for that matter.

In a standard FIM Sync design, in particular one where there is an authoritative source of identity such as an HR system, there are standard considerations must be observed, the basics of which are explained here.  What makes this particularly challenging where FIM is responsible for assigning unique values in AD (based on a supplied algorithm, e.g. surname+initial+number) are a number of significant constraints such as the following:

1. Organisations continue to insist on user-friendly account names.
   In student or staff management systems there is generally already an enforced unique numeric ID that would be perfect for sAMAccountName, userPrincipleName, mailNickname, CN, or all 4.  Yet people insist on employing age-old algorithms based on functions of surname, given name and initials, adding unwanted complexity and ongoing management overhead to your IdM solution.  Such values invariably change during the identity lifecycle at some point (i.e. are not immutable), making manual intervention at some stage practically unavoidable.
2. FIM needs to have knowledge of all existing user accounts before it can provision a new one.
   It is rare that anyone would really ever want to include the full OU tree in scope of the FIM ADDS MA.  However that is effectively what you have to do so that you can implement your uniqueness algorithm in FIM logic.
3. FIM may need to enforce uniqueness across multiple AD domains and forests.
   Particularly where a hybrid cloud/on-premise user synchronisation scenario exists with a single tenant, it is no longer satisfactory to enforce uniqueness in a single AD forest alone.
4. Scoped declarative sync rules cannot be used to generate a unique value.
   These don’t support parameters, so you can’t write your clever workflow activity and pass a value in like you might have done in the days when EREs were the only declarative approach available.  In FIM2010 we’re still limited to a very small set of functions, and while calculating a random number might still be possible, implementing the type of complex rules most organisations exist on is effectively impossible today.
5. ERE-style declarative sync rules cannot reliably be used to generate a unique value.
   If you insist on going down this path then yes, there is a way to use a custom workflow activity to pass in a sync rule parameter value.  But don’t expect this to work when FIM is under even slight duress (see #6 below), and certainly don’t expect the calculated value to be guaranteed unique – especially if you are dealing with latency in writing the value out to AD.
6. When used with the FIM sync engine, the FIM service is a poor option for calculating a unique value in general.
   When processing even a moderate volume of concurrent requests invoking a FIM workflow activity designed to calculate a unique value, the FIM service will invariably cause requests to fail with the dreaded Denied error.  The uniqueness enforced in the RCDC for AccountName might work OK for new user records created in the FIM portal, but not so for new ones created either by the sync service or imported in bulk via the FIM API.  You may also think that bypassing the sync engine altogether to generate your unique account name might be an option – and if you do you are at the same point I got to – but if you do you will need to almost reinvent the very good, robust wheel that is the sync engine when it comes to making your value ‘stick’ in AD.
7. Enforcing consistency between sAMAccountName and userPrincipleName (UPN) suffix.
   It may not even be important to many people, but I always figured that it would at least be desirable that these two values were the same.  Of course they can’t be if you can’t limit your values to less the 20 character limit of the sAMAccountName property, meaning that the other 44 available characters available to you in the UPN will invariably go to waste.  I figure that the ADUC console encourages consistency, so why shouldn’t FIM?
8. Enforcing consistency between UPN and email.
   In a lot of Office365 implementations that pre-dated the “alternate login attribute” concept, it was a requirement for SSO that these values be identical.  This is made additionally challenging when multiple UPN suffixes exist to choose from.
9. Enforcing uniqueness beyond sAMAccountName and userPrincipleName.
   It is rarely enough that you can get away with not considering either or all of the other standard AD attributes too – namely CN, displayName and mailNickname.  Even if you do get lucky and achieve agreement to use the student ID or employee ID as the login name, you’ll generally need to come up with a more friendly email alias.  A unique CN becomes important if you are required to locate your account in different OUs depending on identity state information (e.g. employeeStatus).  Then there’s displayName – FIM hates it when you can’t enforce uniqueness here – and I thoroughly agree with Brad Turner’s 2007 argument here.

I think it is fair to say that in over a decade of working with this toolset, nothing has emerged that stands out as a more consistent way of addressing all of the above concerns than the original MIIS developers’ guide examples from the CHMs that used to come with the product.  I have used an approach similar to this one many times with great success – only to find that customers do not want to have to edit your C# or VB.Net code years later (assuming they can put their hands on it) just to change the number of digits appended to the end of surname+initial from 2 to 3 because they never expected volumes to rise like they had.  As someone with a .Net developer background, like some of you reading this article, I would happily keep things this way if the customer was happy with the approach.  Invariably, they are not.

So – how do we go about designing a FIM solution that covers off points 1-9 above (as well as others I simply can’t think of right now) – and NOT write any .Net code, while still using the FIM sync engine for all AD sync and provisioning?  And no, without any 3rd party tool or CodePlex library either?

Well yes you’re partially right if you’re thinking PowerShell, and I alluded to it above in point #6.  But rather than running a PowerShell activity from within a FIM workflow, you can instead use your favourite PowerShell connector to do this instead.  And all with scoped declarative sync rules and not a rules extension in sight – in fact this is probably only the 3rd time I’ve managed to create the entire sync solution without a rules extension.  The other 2 were with my company’s own xml-based ‘codeless’ extensions, so I guess this makes it the first in the purest sense.

The idea is simple enough – use a scoped SR with initial flow to provide the attributes that are the inputs of your uniqueness algorithms – but applied to a PowerShell MA/connector instead of the ADDS MA.  This gives you the freedom to do your uniqueness checks on the whole directory tree if you don’t want to bring in all OUs within the scope of the ADDS MA(s) you will still need to use to apply all your standard attribute flows best handled this way.  You can tie the two together with an inbound flow rule from AD which can unambiguously join on an attribute value that was written to the AD account created by your PowerShell MA.  At this point you can also move your account from the default OU that the ‘stub’ account was placed in originally.

So that’s the point of this post really.  I’m really letting you know that by combining 2 relatively new tools (well let’s face it nothing FIM is ever bleeding edge is it?) in (your favourite) PowerShell MA and FIM2010 R2 scoped declarative rules, you have all that you need to architect a maintainable FIM sync solution that ticks all the boxes.  Not only that but you’ll also find your customer is happy there is no .Net code to maintain, and you will be happy in the knowledge that whoever comes along after you to extend the solution will thank you for making their job a whole lot easier.  Sure – you are making yourself less indispensable, but then again with the future of MIM2015 and AADSync being a complete absence of custom rules extensions, you’re also creating a more future-proof solution on which to base repeatable business.