Implementing User Entitlements with ILM

Now that ILM is being utilized for more pervasive provisioning systems, we see more and more questions around how to perform user entitlements. The term “user entitlements” is used to describe privileges or personalized environments on the network. Quite simply, a “user entitlement” is something that a user needs when they login to their network account. This can be a home directory located on a specific file share or provisioned access to a specific application such as a SharePoint Portal. Some of the questions we see surrounding this topic are “should ILM perform these user entitlements?” and if so “should ILM perform these user entitlements directly or through some asynchronous processes?” The answer depends on the nature of the solution, but in most circumstances ILM can in fact drive these user entitlement solutions. However, to architect the most efficient solution or one where connectivity may be an issue, asynchronous processes may be required.

Before we delve into the solution architectures, I would like to briefly discuss how user entitlements are typically done in a non-ILM world. Probably the most common approach is accomplished through the use of logon/logoff scripts. I have seen scripts that venture into the thousands of lines of code! They perform such tasks as creating directories or file structures for the user, to setting file permissions, adding group membership, or evening backing up and restoring entire home directories when a user changes locations. I’m sure if you are a system administrator, you could name a dozen more entitlements without hesitation. However, most entitlements are given utilizing manual processes. Whether it requires an administrator to add a user to a security group or a manager to configure access to a specific application, many entitlements are prescriptive and can be automated with a provisioning system. Some applications have vendor-specific provisioning that may get you part of the way there, but through experience, most require someone to “push a button”.

ILM may be the perfect solution for creating user entitlements that are accessible directly through built-in Management Agents. The most common example is Active Directory or ADAM group membership management. You can quite easily provide the logic to ILM to manage group membership. I will not delve into that here, as there are many available resources that discuss this topic. If ILM does not have some built-in approach to managing a user entitlement out-of-the-box, there is the ability to create custom management agents that perform tasks directly. The only limitation to performing the tasks directly by ILM depends on the connectivity to the host of the user entitlement. The rule of thumb is, if the host is always available and the tasks to be completed are not long-running, then it may be game. For example, if you are provisioning a SharePoint portal, you may need to make web service calls to the web server that hosts the SharePoint portal. This is applicable because the SharePoint portal is likely to be located in a centralized location that is always online and accessible by the ILM server. That way ILM can reliably perform the tasks without error. If you have experience with ILM, you know that errors can bring the whole system to a screeching halt!

Given the nature of many user entitlements, ILM may not be the best solution for managing the related tasks directly. You would not want ILM to perform long-running tasks or ones where connectivity may be an issue. In addition, ILM may not be able to perform tasks until some other action has completed. The most common scenario asked about is the creation of home directories for users on large networks. Most likely, the home directories are hosted on file servers that are located close to the physical location of the user and far away from the ILM server on a WAN. First of all, ILM may not even be able to reliably connect to the file server. Second, the file server may connect to an Active Directory domain controller located in the same site where replication is scheduled on a less-than-optimal timeframe. If ILM just finished creating a new user account on some centralized domain controller, the home directory could not even be created until that new user account is replicated to the remote site. Finally, home directory management would fall under the “long-running task” category because it will likely include such capabilities as moving or synchronizing files from one location to another, archiving folder structures for inactive accounts or setting granular permissions on the hierarchy. Another example of a user entitlement that ILM could not perform directly would include the ability to “push a button” on some remote computer at some specific time with the right information at hand (such as a CSV import file). These types of user entitlements are best performed through asynchronous processes.

The first solution that most Microsoft-based solution architects think of when implementing an asynchronous process is the incorporation of MSMQ. If you are unfamiliar with MSMQ (message queuing), it provides the capability for a program executing inside of ILM to call a procedure (to perform a specific task) and have it run at a different time or even on a different computer. This allows ILM to continue doing what it is doing without worrying about how long the task will take to perform or even if the server has connectivity to perform the task. This is a very viable solution, but may be difficult to setup and maintain. In addition, getting the proper information to the target of the message (the program actually performing the task) can be a challenge without writing data to some centralized location such as a SQL Server database.

Now we finally get to the solution. Instead of having ILM perform tasks directory or sending messages to MSMQ, I propose the use of custom Windows Services to perform user entitlements. Once again, allow me to use the home directory provisioning example to illustrate. You can have a custom Home Directory Windows Service running on multiple file servers performing only the tasks that pertain to their server.  In addition, because it is running asynchronously from ILM, it can automatically deal with such issues as network connectivity, AD replication and error recovery. Error recovery is important because if something happens, such as having the network go down while moving a home directory, the windows service can be made smart enough to continue where it left off when the network comes back online. This keeps ILM running smoothly and makes system administrators happy because they don’t have to fix anything manually. The beauty of it all is that ILM can still orchestrate and even react when the tasks have been completed.

How does it work? You can implement a simple SQL Server management agent that exports a subset of the ILM MetaVerse out to a SQL Server table.  The table is populated with an exact replica of only those objects and attributes in the MetaVerse that you want to deal with (using provisioning logic).  You can then have one or more Windows Services running that monitors that table for changes.  For example, you could export out the UID and homeDirectory to a table, and have the Windows Service maintain another copy of the table with the data that it last utilized during execution.  The Windows Service can now not only determine when the ILM data has changed, but it can also perform deltas and know exactly how the data has changed.

By now I am sure you realize that tasks can be accomplished asynchronously via one mechanism or another, but you may be wondering how ILM can be notified when the task has completed. There are two different solutions. The home directory example still applies for the following reason… if the user’s home directory has not been created, you most likely would not want the user to be able to login. Since ILM will likely manage the userAccountControl for user accounts (enabling or disabling), ILM will need to know that the home directory is online before enabling the account. Or, you may want to go ahead and enable the account, but not specify a home directory for the user until it is available.

Solution A) Use a synchronization field...

1. Make the Active Directory MA (ADMA) the authoritative contributor of the homeDirectory attribute.
2. Create a new string attribute 'homeDirectorySync' in the MetaVerse and add it to person.
3. Upon projection & modification of the MetaVerse person, the value of homeDirectorySync is set (leaving homeDirectory in tact).
4. In the ADMA export flow for userAccountControl, if the value of homeDirectory does not match the value of homeDirectorySync, ensure the account is disabled.  The AD account is created/modified as disabled and the value for homeDirectory will be blank on creation.
5. A new record is written in the monitored table for the Home Directory Service using the homeDirectorySync attribute.
6. The Service creates/moves/archives the Home Directory, and when complete it writes the value of the AD User homeDirectory attribute using ADSI (DirectoryServices).
7. The next ADMA import into ILM will now flow the value of homeDirectory into the MetaVerse and the values of homeDirectory and homeDirectorySync are the same.
8. In the ADMA export flow, enable the account because the values are in sync.

Solution B) Use a Provisioned Actions MA...

1. Create a new SQL Server MA called 'Provisioned Actions' that is based on a table with four fields (UniqueID, objectClass, objectId, actionId).
2. Upon projection & modification of the MV person, the value for homeDirectory is NOT set.
3. During the ADMA export, a null/unchanged homeDirectory is specified with the account enabled (this is how the customer may want it).
4. A new record is written in the monitored table for the Home Directory Service with an export flow that sets the appropriate value for the homeDirectory.
5. The Service creates/moves/archives the Home Directory, and when complete it writes a record to the Provisioned Actions table.  For example, a SQL record may have the values of (UniqueID=GUID, objectClass=person, objectId=UID, actionId=HomeDirCreated). 
6. A join rule would be made to match the 'Provisioned Actions' objectId field to the MV UID attribute according to the objectClass specified in the record (ex: person). 
7. Create authoritative flows for the 'Provisioned Actions' MA that drive the value of MetaVerse attributes of the specified objectClass.   When the authoritative attribute flow occurs, it will see that the actionId indicates that the Home Directory has been created and it sets the value of the MV homeDirectory attribute.
8. During the next ILM Provisioning, any  'Provisioned Actions' csentries are Deprovisioned while not revoking it's contributing MV values.
9. On the next export to AD, the homeDirectory is set to the appropriate value.
10. On the next export to  'Provisioned Actions', the record is deleted.

Both solutions are equally effective.  I have put both to use in other scenarios effectively.  For example, the Provisioned Actions can be quite useful for "tickling" an MVEntry to fire off the provisioning rules to re-evaluate such events as a user being added to a security group in AD through nested group membership.

User entitlements can be effectively managed by ILM through the use of both synchronous and asynchronous processes. The solutions provided are only a couple of many potential solutions that may be tailored to suit the needs of the enterprise deployment. A little ingenuity and creativity is all that’s needed to put ILM to work when the solution is not clear.