I thought I would kick off my entries in our new company blog with a description of the project that lead to CSS winning Microsoft’s prestigious “2010 Core Infrastructure Solutions, Identity & Security Partner of the Year.”
The project involved an interesting use of the Forefront Identity Manager (FIM) synchronization engine to provide delegated Exchange provisioning. My hope in describing this project is to provide an example and maybe inspiration as to what you can use FIM to accomplish.
Product
Microsoft’s Forefront Identity Manager (FIM), provides a wide variety of services around managing identity including directory synchronization, group management, certificate management, workflow, delegation, and self-service password reset.
The Challenge
The client had three subsidiaries as a result of acquisition – each with its own Active Directory forest and email system – and each with varying levels of technical capabilities. One subsidiary managed their systems pretty well and another had no viable backup of their email system.
The company’s business objective was to get the company and its subsidiaries all on a centrally managed, stable email platform using the current version Exchange.
The challenge was that each subsidiary had its own Active Directory forest and politically it was not feasible to collapse the AD environment down to one domain or even one forest. From an administrative point of view each subsidiary maintained its own Active Directory and its own users.
The parent company did not want to grant any administrative rights in either the central Active Directory or Exchange system to the subsidiary administrators but did want to delegate user management and the provisioning of mailboxes to the subsidiaries. In addition, it was desired that subsidiary users could access the central Exchange environment with their subsidiary AD accounts without needing a separate login to access email.
Subsidiary administrators needed to be able to specify for their own users whether or not they possessed a mailbox in the central Exchange environment and whether that user could send email to the Internet or was restricted to internal company email. Finally, subsidiary administrators needed to be able to specify the SMTP addresses for their users and whether or not the user was to be listed in the global address book.
The Solution
The solution CSS employed was to have the subsidiary administrators put “hints” in their own Active Directories that FIM would read and then take the appropriate provisioning actions within the central environment.
The following diagram shows where FIM fit into the picture:
Providing the provisioning hints
The hints or provisioning directives provided by the subsidiary administrators needed to be stored somewhere in the subsidiary Active Directories to be visible to FIM. We used several of the “extension” attributes that are present is almost everyone’s AD schema. One attribute would contain the value of “None,” “Company,” or “Internet” to indicate if the user got a mailbox or not and if the mailbox had rights to send and receive to the Internet or was restricted to corporate email. Another was used to hold a list of SMTP addresses for the mailbox; and finally a third contained “True” or “False” to indicate if the user should be included in the GAL.
The subsidiary administrators had the rights to update attributes in their own directories, but there is no easy user interface to edit the extension attributes. (They were not on Server 2008 and they didn’t have the Exchange administrative tools installed.) We briefly considered having the administrators use ADSI Edit or similar directory editing tools but rejected the idea due to the potential risk for mistakes and damage. Since the subsidiary administrators used the standard Active Directory Users and Computers (ADUC) tool to manage their users, we chose to extend ADUC by adding an additional tab that exposed the extension attributes in an easy to understand fashion. Here is what it looks like:
After creating a user, all an administrator needed to do was switch to this tab and specify the Exchange details for the user.
Synchronization
About every ten minutes the FIM synchronization engine would look at the three subsidiary Active Directories to see if the subsidiary administrators had made any changes to users that required processing – and if they did, FIM performed the corresponding provisioning or deprovisioning work.
Provisioning to Exchange
Exchange supports access to mailboxes from accounts in remote Active Directory forests via a feature called “linked mailboxes.” To set this up, you need a placeholder account that owns the mailbox in the same forest that Exchange resides. This placeholder account needs to be mailbox enabled, but login disabled. When you mailbox enable the account, you indicate to Exchange that this is a linked mailbox and you specify the account in the remote forest that will have access to the mailbox.
Out of the box, FIM provisions standard Exchange mailboxes and can provision placeholder accounts, but it does not have the ability to create the linked mailboxes and does not deprovision an Exchange mailbox without also removing the underlying account.
To solve these issues, CSS created a custom management agent or “connector” for FIM to handle provisioning and deprovisioning Exchange mailboxes independently from the AD accounts. Under the covers, the management agent issues the appropriate PowerShell commands to find out what mailboxes currently exist, to create new regular or linked mailboxes, and to remove mailboxes from accounts.
One of the requirements was to allow the subsidiary administrators to specify what SMTP email addresses their users would have. The FIM synchronization engine can certainly flow this information out to Active Directory, but neither FIM nor AD will warn you if you put the same SMTP address on multiple mailboxes. To make matters more difficult, if you do put the same SMTP address on multiple mailboxes, inbound mail delivery to that SMTP address will fail silently.
To prevent this we created another custom management agent for FIM to process SMTP addresses. The agent again used Exchange PowerShell commands to request the assignment of SMTP addresses to mailboxes. The PowerShell interface to Exchange will check for duplicate SMTP addresses and issue a warning that we trapped and relayed back to the subsidiary administrator to inform them of the address conflict.
Finally, to handle the security requirement that some users got to send email to the Internet and others were restricted to company only email, we set up basic group management in FIM to place users that the subsidiary administrators had indicated were restricted to company only email into a Windows group and configured the appropriate security rules in Exchange.
Summary
The end result was CSS delegated the ability for administrators in a remote Active Directory forest to create and remove Exchange mailboxes, maintain email addresses, manipulate AD group membership, and affect the Global Address List all in a controlled fashion and without granting any administrative rights in the corporate central forest.
So if you have a similar need to delegate administrative options to non-privileged users such as maintaining Exchange mailboxes or group memberships, you might consider using FIM to do it.
As a closing note I will add that when we did this project for our client, we actually used the previous version of FIM (which was called ILM) because at the time FIM had not yet been released. The ILM tool we used became the synchronization engine in FIM and is only part of the functionality now provided by FIM. There are a lot more delegation options beyond what I described here in the current version of FIM.
