Scripting the generation & creation of Microsoft Identity Manager Sets/Workflows/Sync & Management Policy Rules with the Lithnet Resource Management PowerShell Module

Introduction

Yes, that title is quite a mouthful. And this post is going to be quite long. But worth the read if you are having to create a number of rules in Microsoft/Forefront Identity Manager, or even more so the same rule in multiple environments (eg. Dev, Staging, Production).

My colleague David Minnelli introduced using the Lithnet RMA PowerShell Module and the Import-RMConfig cmdlet recently for bulk creation of MIM Sets and MPR’s. David has a lot of the background on Import-RMConfig and getting started with it. Give that a read for a more detailed background.

In this post I detail using Import-RMConfig to create a Set, Workflow, Synchronization Rule and Management Policy Rule to populate a Development AD Domain with Users from a Production AD Domain. This process is designed to run on a combined MIM Service/Sync Server. If your roles a separated (as they likely will be in a Production environment) you will need to run these scripts on the MIM Sync Server (so it can query the Management Agents, and you will need to add in a line to connect to the MIM Service (eg. Set-ResourceManagementClient ) at the beginning of the script.

In my environment I have two Active Directory Management Agents, each connected to an AD Forest as shown below.

On each of the AD MA’s I have a Constant Flow Attribute (named Source) configured to flow in a value representing the source AD Forest. I’m doing this in my environment as I have more than one production forest (hence the need for automation). You could simply use the Domain attribute for the Set criteria. That attribute is used in the Set later on. Mentioning it up front so it make sense.

Overview

The Import-RMConfig cmdlet uses XML and XOML files that contain the configuration required to create the Set, Workflow, Sync Rule and MPR in the FIM/MIM Service. The order that I approach the creation is, Sync Rule, Workflow, Set and finally the MPR.

Each of these objects as indicated above leverage an XML and/or XOML input file. I’ve simplified base templates and included them in the scripts.

The Sync Rule Script includes a prompt to choose a folder (you can create one through the GUI presented) to store the XML/XOML files to allow the Import-RMConfig to use them. Once generated you can simply reference the files with Import-RMConfig to replicate the creation in another environment.

Creating the Synchronization Rule

For creation of the Sync Rule we need to define which Management Agent will be the target for our Sync Rule. In my script I’ve automated that too (as I have a number to do). I’m querying the MIM Sync Server for all its Active Directory MA’s and then providing a dialog to allow you to choose the target MA for the Sync Rule. That dialog simply looks like the one below.

Creating the Sync Rule will finally ask you to give the Rule a name. This name will then be used as the base Display Name for the Set, MPR and Workflow (and a truncated version as the Rule ID’s).

The script below in the $SyncRuleXML section defines the rules of the Sync Rule. Mine is an Outbound Sync Rule, with a base set of attributes and transforming the users UPN and DN (for the differing Development AD namespace). Update lines 42 and 45 for the users UPN and DN your namespace.

Creating the Workflow

The Workflow script is pretty self-explanatory. A simple Action based workflow and is below.

Creating the Set

The Set is the group of objects that will be synchronized to the target management agent. As my Sync Rule is only for Users my Set is also only contains users. As stated in the Overview I have an attribute that defines the authoritative source for the objects. I’m also using that in my Set criteria.

Creating the Management Policy Rule

The MPR ties everything together. Here’s that part of the script.

Tying them all together

Here is the end to end automation, and the raw script that you could use as the basis for automating similar rule generation. The Sync Rule could easily be updated for Contacts or Groups. Remember the attributes and object classes are case sensitive’.

  • Through the Browse for Folder dialog I created a new folder named ProvisionDevAD

  • I provided a Display Name for the rules

  • I chose the target Management Agent

  • The SyncRule, Workflow, Set and MPR are created. The whole thing takes seconds.

  • Script Complete

Let’s take a look at the completed objects through the MIM Portal.

Sync Rule

The Sync Rule is present as we named it. Including the !__ prefix so it appears at the top of the list.

Outbound Sync Rule based on a MPR, Set and Workflow

The Resources will be created and if deleted de-provisioned.

And our base attribute flows.

Set

Our Set was created.

Our naming aligns with what we input

And a Criteria based Set. As per the Overview I have an attribute populated by a Constant flow rule that I based my set on. You’ll want to update for you environment.

Workflow

The Action Workflow was created

All looks great

And it applies our Sync Rule

MPR

And finally our MPR. Created as a Transition In MPR with Action Workflow

Set Transition and naming all aligned

The Transition Set configured for the Set that was created

And the Workflow configured with the Workflow that was just created

Summary

When you have a lot of Sync Rules to create, or you know you will need to re-create them numerous times, potentially in different environments automation is key. This just scratches the surface on what can be achieved, and made so much easier using the Lithnet PowerShell Modules.

Here’s is the full script. Note: You’ll need to make a couple of minor changes as indicated earlier, but you should be able to create a Provisioning Rule end to end pretty quick to validate the process. Then customize accordingly for your environment and requirements. Enjoy.

FIM: An object with DN “CN=BLAH” already exists in management agent “BLAH MA”

If you treat the FIM Synchronization Service well and your configuration is good, it will reward you and the ‘magic’ will happen. At my customer site, the ‘magic’ stopped working and I was faced with an increasing number of synchronization errors being ‘An object with DN “CN=<blah>” already exists in management agent “<blah> MA” ‘. For users that were already provisioned correctly, the FIM Synchronization Service was attempting to re-provision a duplicate object in the destination directory but obviously the account already existed. Why was this occurring and how to resolve it? To be honest it stumped me for quite a while until I remembered I was faced with the same scenario a few years ago with yet another FIM Synchronization Service with many 100s of thousands of objects.

Before I start, I’ll preface that this blog assumes a very good working knowledge of the Microsoft Forefront Identity Manager product, now known as Microsoft Identity Manager. Let’s delve deeper.

We should all know that best practise when making changes to any part of the FIM Synchronization Service configuration, or new or updates to FIM Service Synchronization Rules, you should do a Full Synchronization cycle to ensure the changes and rules are all processed against the objects in the solution. When you are working on a large solution with 100s of thousands of objects, it is not always possible to do this Full Sync cycle at will and it needs to be typically scheduled as a change over a weekend, maybe even a long weekend! We had attempted a full synchronization cycle on this customer solution in the past and it took just on 2 days to complete. So when you don’t have the opportunity perform this cycle, you use your prior knowledge, expertise and judge if the solution can continue to function if a change has been made. In my case, a new attribute flow in a Synchronization Rule which was not critical to the existing objects in the solution. So I thought I could avoid a Full Sync cycle and everything appeared to be working as expected.

Over a few weeks, these sync errors started to occur as illustrated below and they were increasing until I got to around 40 errors and further troubleshooting action needed to be taken.

The customer had rules in the solution to detect when an existing user account was disabled and perform some functions in the FIM Service. If the user account was re-enabled, the ‘provisioning’ MPR was triggered as the user was back as a member in the ‘provision accounts’ Transition Set. Workflows assigned a handful of Synchronization Rules against the user as Expected Rule Entries (EREs), which had already applied to the user when it first came to existence and provisioned. These duplicate EREs when flowed from the FIM Service to the FIM Synchronization Service were throwing the errors.

Back in the test environment, the ‘magic’ was still working with no errors thrown. What normally happens in this situation is if you happen to assign a provisioning Sync Rule to a user account, but that user already had one previously successfully ‘applied’ (and was already provisioned), this duplicate ERE would be processed by the Sync Service and also marked as ‘Applied’. It was smart enough to know that the provisioning event was not required because an existing ERE had already been assigned. When the Sync Service flows the status of the duplicate ERE back to the FIM Service, the duplicate is deleted and world order is restored with this ‘magic’. Sorry I find no way of easily describing it without detailing my scenario, so I hope you are still following me. So why was it not working in production?

I’m not sure of the internal innards of the Sync Service, but what I have found is when a delta import change of a Synchronization Rule flows into the Sync Service and a ‘Delta Sync’ is processed on this change, it seems to have an adverse effect on the other Sync Rules. Sync Rules that have previously been working fine start behaving badly and to put it simply, the ‘magic’ breaks.

The fix is to obviously perform a Full Synchronization on the whole solution because a configuration item has changed. However, without having the easy opportunity to do this, I needed to perform a Preview/Full Synchronization on each Synchronization Rule in the solution as illustrated below. Although no obvious change is shown in the preview window, it seems like each Sync Rule is re-processed/reset into good working order and the ‘magic’ is restored.

After performing this change against all Sync Rule objects, all synchronization errors have been cleared and the ‘magic’ now works as expected. I didn’t find much in the forums or public domain about this scenario, so I hope this helps somebody in the future. I’m now working on getting the full synchronization cycle actioned! Let me know in the comments below if this has saved you.

Diagnosing FIM/MIM ‘kerberos-no-logon-server’ error on an Active Directory Management Agent

Overview

I have a complex customer environment where Microsoft Identity Manager is managing identities across three Active Directory Forests. The Forests all serve different purposes and are contained in different network zones. Accordingly there are firewalls between the zone where the MIM Sync Server is located and two of the other AD Forests as shown in the graphic below.

As part of the project the maintainers of the network infrastructure had implemented rules to allow the MIM Sync server to connect to the other two AD Forests. I had successfully been able to create the Active Directory Management Agents for each of the Forests and perform synchronization imports.

The Error ‘kerberos-no-logon-server’

Everything was going well right up to the point I went to export changes to the two AD Forests that were separated by firewalls. I received the ‘kerberos-no-logon-server’ error as shown below from the run profile output.

I started investigating the error as I hadn’t encountered this one before. There were a few posts on the possibilities mainly dealing with properties of the AD MA’s configuration. But I did stumble on a mention of kerberos being used when provisioning users to Active Directory and setting the initial password. That aligned with what I was doing. I had provided the networking engineers with my firewall port requirements. Those are (no PCNS required for this implementation) ;

  • 389 TCP – LDAP
  • 636 TCP – LDAPS
  • 88 TCP – Kerberos
  • 464 TCP/UDP – Kerberos
  • 53 TCP – DNS
  • 3268 TCP/UDP – Global Catalog
  • 3269 TCP/UDP – Global Catalog
  • 135 TCP – RPC

My old school immediate thought was to Telnet to each of the ports to see if the firewall was allowing me through. But with a couple of forests to test against and UDP ports as well, it wasn’t going to be that easy. I found a nice little Test-Port function that did both TCP and UDP. I already had an older script for testing TCP ports via PowerShell. So I combined them.

Identifying the cause

As suspected connectivity to the forest where my MIM Sync Server was located was all good. The other two, not so much. GC connectivity wouldn’t give me the Kerberos error, but not having Kerberos Port 464 certainly would.

In the backwards and forwards with the networking team I had to test connectivity many times so I added a running output as well as a summary output. The running output highlighting ports that weren’t accessible.

Here’s the raw script if you’re in a similar situation. Get the Test-Port Function from the URL in line 1 to test UDP Port connectivity. Add additional ports to the arrays if required (eg. for PCNS), and update the forest names in lines 21-23.

Summary

I’m sure this is going to become more relevant in a Cloud/Hybrid world where MIM Servers will be in Azure, Active Directory Forests will be in different networks and separated by firewalls and Network Security Groups.

It all comes down to “Requirements”

In my l last post, I discussed the basic concepts of Identity Management. In this post I’m going to talk about the need to clearly identify the business requirements for IAM as a whole and not just to a specific technical need. More often than not IAM projects are spawn to satisfy a specific need, and realistically these today are around the adoption of specific cloud technologies, and Office 365 is the most obvious one.

The issue with doing this is that when you implement a solution for a single purpose without putting any consideration into the “What else” question that is always overlooked. Over the course of my career I’ve discovered that when the next requirement comes up within the business that requires an Identity Management solution, they are often left in a situation which either requires them to completely rebuild the solution that has already been built to provide the initial service offering, or they are required to setup a completely separate environment which then complicates and increases the overall support for the solutions that could have, more often than not, been delivered within the single system.

This brings us back to the title, requirements! So, what are requirements? And why are they so important? Simply put, requirements tell you what you want to achieve within the business with the technology you have or are about to invest in.

When thinking of requirements for any IAM solution, there are basic principles that you should always take into consideration. An IAM solution is built to satisfy 4 basic functions;

  1. Authentication
  2. Authorization
  3. User Management
  4. Central User Store

When establishing requirements within your business for any IAM solution it’s important to understand these basic functions, and what they could mean for your business. So lets break them down.

Authentication

Most would say this is pretty self-explanatory, but there’s often a lot more to this than what many think. For example, you want to enable a SaaS application such as TechnologyOne Finance. Do you want to provide a seamless authentication model with Single Sign-On (SSO) or do you want to keep the authentication separate from your local security domains to provide a higher level of security. Do you want to provide more of a Same Sign-On solution where they use their local username and password but are forced to login every time which can be a less inviting end user experience.

Authorization

Authorization within IAM simply put provides authorization workflows to requests for access to resources or the creation of new resources managed by the IAM solutions. Authorizations ensure that access compliance and government processes are followed with all managed resources.

User Management

User management is simply that, it manages the user objects of which it knows about, this includes any add moves or changes that occur to these objects throughout their lifecycle, and when a user leaves the organisation for whatever reason they are terminated through the standard business processes that are established as part of the requirements that have been defined.

Central User Repository

This is effectively where everything is stored, in Microsoft it’s referred to as the metaverse, in the Novell space it’s referred to as the Identity Vault. But it’s simply a central repository of all user objects, as well as the configuration items such as workflows, policy rules as well as various other configuration items.

A common misconception with requirements is technical teams will look for what the Requirements comparisontechnical requirements are to satisfy the solutions which is being built! But this is where things will often go wrong, business requirements come down to simple business logic of what are the primary business objectives. These business requirements will often create a bunch of technical requirements, but it must start with the basic business requirements.

Summary

So, to summarise, complex IAM solutions all come down to basic principles, what am I trying to achieve as a business? It is for this reason you need to start with the basics and understand the purpose of the solution being built. You wouldn’t want to build a house without plans or you wouldn’t want to build a road without understanding where it’s going. So why would you do the same with your Identity Management solutions.

An alternate method for dealing with Orphaned MetaVerse Objects

Update 21 April ’17. The LithnetMIISAutomation PS Module now has a -Force switch for Delete-CSObject

As often happens in development environments, data changes, configurations change and at some point you end up with a whole bunch of objects that are in no-mans land. This happened to me today. I had thousands of objects that we basically empty but had previously triggered to be exported to the MIM Service prior to them actually being deleted from the source management agent.

An example of one of the objects. A group with a Pending Export to the MIM Service.

A closer look at the object and there is no attribute data present as the source object had been removed.

And only a single connector, to the MIM Service which it will never reach as it doesn’t contain the mandatory attributes.

Normally to clean up such a mess you’d probably be looking at deleting the Connector Space for the MIM Service and then refreshing it from the MIM Service and these objects would be gone. However, this development environment is rather large, and that wasn’t something I had time or was prepared for at this time. So here’s how I worked around the issue.

Deleting spurious objects from the Connector Space

There’s two approaches;

  1. Select each of the errors, select the MIM Service Connector and select delete. That would work but I had thousands.
  2. Automate the process described in point 1. That’s the approach I took

Using the ever versatile Lithnet MIM Sync Powershell Module I retrieved the last run details for my MIM Service MA. I grabbed all the errors, inspected the errors for the ones that were failing creation to the MIM Service and then deleted the CSObject for that orphan.

Here’s where it got more than a little clink clink cowboy-ish. The Delete-CSObject cmdlet requires confirmation to delete the CSObject. There is not a switch to force the delete, or accept confirmation globally*. I wasn’t going to click Yes or press Enter 5000 times either.

So I wrote a small script that loops and checks for the Confirm disconnection dialog and sends the enter key to window.

Here’s the two little scripts.

This first script retrieves the last run details and loops through the errors.

This second script which I ran in a second separate PowerShell Runspace loops around and presses enter at the right time.

*I’ve submitted an enhancement request to Ryan to add a confirm parameter to Delete-CSObject

Bulk create and update related configuration objects in FIM/MIM using the Lithnet Import-RMConfig cmdlet

Working on a FIM implementation for a customer, I needed to bulk create and update a number of related Sets and MPRs which granted permissions to users. I could have performed this task a number of ways:

  • Manually create and update all objects
  • Scripted in PowerShell using FIM Automation
  • Scripted using the Lithnet FIM/MIM Service PowerShell Module

I’ve been successfully using the Lithnet FIM/MIM Service PowerShell Module in a number of scripts to query and bulk create objects in the FIM Service which has greatly improved the quality and simplicity of my PowerShell scripts compared to using the FIM Automation module. What I hadn’t used to date was the ability in the Lithnet module to use the Configuration Management features within FIM, so I thought I’d set myself a challenge to come upto speed with this feature and determine if it was a quicker method than using FIM Automation. I knew it was going to be quicker using the Lithnet module but since I needed to do some research and testing compared to knowing how to tackle it using FIM Automation, I needed to be 100% convinced.

This blog assumes a very good working knowledge of the Microsoft Forefront Identity Manager product, now known as Microsoft Identity Manager. If you haven’t used the Lithnet module yet, what are you waiting for! Ryan Newington has developed and released to the community this PowerShell module which cuts the amount of scripting required to manage FIM configuration and objects within the FIM Service. Using the Configuration Management features was a perfect set of functions I needed for my scenario which I will now describe.

Scenario

For this customer, they had a delegated permissions model where each of their 13 agencies had administrators that were able to manage a fixed set of user attributes just for their own users. Users from other agencies were not visible within their view within the FIM Portal, and to support this model, each agency has linked FIM Set and MPR objects to give this delegated administration. My customer engagement was to update this existing FIM implementation to add custom telephone-based attributes against each user, and create a new phone object type. The existing permissions needed to be updated to include the new telephony attributes, and new permissions were required for the phone objects linked to each agency. This customer had 13 agencies and the beauty was the naming convention the FIM solution had for Sets and MPRs, with the names of the common objects being the same with only the agency name being different. For example, each agency administrator Set object was called ‘_Agency (<agency>) Administrators’. This was the same for MPRs, so my task was made easier as I just need to develop a templated XML configuration file which I could easily update per agency. Follow me so far?

What I liked about the Configuration Management feature was the ability to easily reference other objects without needing to separately query the FIM Service to return an ‘ObjectID’ which you can then supply to your configuration. The Lithnet module takes care of the referencing.

The Lithnet module is located here, and the quickest way to learn about this Configuration Management feature is to read the Lithnet documentation here, and as suggested watch the recording from FIM contributor Ike Ugochuku and download his sample XML configuration here which is a great starting point – here.

Required Actions

For my scenario, I needed to perform the following:

  • Create a Set object to group all phone objects for each agency
  • Create a permissions-granting MPR object giving each agency Modify permissions to one attribute for phone objects, a ‘visibility’ boolean attribute. You’ll notice in the XML configuration below, the Set created above is referenced, showing the power of this Lithnet module
  • Create a permissions-granting MPR object giving each agency Read permissions to all attributes for phone objects
  • Update an existing permissions-granted MPR object giving each agency Modify permissions to one attribute for user objects, against the ‘visibility’ attribute
  • Update an existing permissions-granted MPR object giving each agency Read permissions to the new phone related attributes for user objects
  • Update an existing permissions-granted MPR object removing the Modify permissions for user self-service which has been assigned in error some time ago

Using the -Preview switch against a configuration XML file (sample listed below) for the first agency, a preview can be tested before applying.

On a second agency with some of the updates already applied, I performed a preview. It shows all objects exist and which individual change would be applied.

As a test against the second agency, I changed resource operation from ‘Add Update’ to ‘Add’. When attempting the preview again, it showed it is creating the Sets even though they already exist. This is not ideal for verification, so I changed it back to ‘Add Update’ which I recommend using.

Removing ‘Preview’ and committing the change against the first agency shows what is changed and committed to FIM.

Validating the changes with a preview once applied to confirm all changes had been committed.

Although I could have been smarter to script the process for the remaining agencies, I did a search-and-replace of the agency name in the configuration XML file, saved it and re-ran the import.

Last step was to check the FIM Service requests to confirm they have been completed.

My sample XML configuration file for an agency change is located here.

Tips

Some simple recommended tips based on my use of this Configuration Management feature:

  • ID is a required tag even if you don’t use it as a reference within your XML configuration file
  • When creating FIM objects, use the XML tag ‘Add Update’ so that the Preview function can be used to validate the changes you have performed. If you leave it as ‘Add’, the Preview will simply report that the object ‘would’ be created if executed, rather than query and check that the objects exists and no update is required
  • Case sensitivity of the XML tags as mentioned by Ike in his video. I didn’t test changing the case as the sample XML configuration files were working configuration

So how long did it all take?

My goal was to make the changes into production against the 13 agencies after successfully testing the FIM configuration in a test environment. After watching Ike’s video and reading Ryan’s wiki, it took about 15 minutes to customise the sample XML files and update the configuration in the production FIM instance for all 13 agencies. A huge time saving. Other colleagues have started using this functionality both for speed of implementation and consistency in configuration, and my colleague Darren Robinson has also saved a great deal of effort as detailed in his blog here.

What scenarios have you performed with this functionality? Let us know in the comments below.

Getting started configuring the latest Microsoft Identity Manager IBM Notes Management Agent with Domino v9.x

Lotus Notes. My old nemesis as both a user and as an administrator is back to haunt me again.

There’s a reasonable amount written by others on the trials and tribulations of getting the FIM/MIM Notes MA configured and working. However they are all referencing older versions of the MA and older versions of Domino. (If you are looking details on the previous versions checkout Michael’s great post here). The info on permissions is still valid, so make sure you’re on top of that.

The latest Notes MA (March 2017) is available from here and supports v9.x of Domino and v9.x of the Notes Client.

Here’s a couple of the differences straight up;

  • The v9 Lotus Notes Client does not require the v8 client requirements of setting up the MA using x86 architecture. Use “Process” as MA Architecture as per the documentation
  • I managed to get the v9.0.0 and v9.0.1 FP4 clients to work. The latest is v9.0.1 FP8 available from here
  • There are two technical references from Microsoft for the Notes MA. This is the old version. After some hunting I located the documentation for the latest release here. Yes the new version of the MA and the associated documentation only become available mid-March 2017

Here’s a couple of quick tips for getting up and running with the latest MIM Notes MA;

  • Install the v9.x Lotus Notes Client on the MIM Sync Server
    • Select Single User Install
  • Open the names.nsf and schema.nsf databases using the Notes ID you will be supplying to the Notes MA configuration

Enable Logging

Like anything, knowing what is going on, helps diagnose issues. This is how I enabled event log logging for the latest IBM Notes Management Agent

  • Edit the miiserver.exe.config file in the BIN folder. More than likely that will be in this path C:\Program Files\Microsoft Forefront Identity Manager\2010\Synchronization Service\Bin
  • Add the following lines as shown in the graphic below

<source name="ConnectorsLog" switchValue="Information">
   <listeners>
     <add name="ConnectorsLogListener" 
     type="System.Diagnostics.EventLogTraceListener, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
     initializeData="ForefrontIdentityManager.ManagementAgent"
     traceOutputOptions="LogicalOperationStack, DateTime, Timestamp, Callstack" />
  </listeners>
</source>

Restart the Forefront Identity Manager Synchronization Service in services and when you run the Notes MA you will then see output in the Event Log under Forefront Identity Manager Management Agent.

Change the following line substituting Error, WarningInformation or Verbose for what you want logged.

 <source name="ConnectorsLog" switchValue="Information">

If you want it to log to the Application Log then change the initializeData value to whatever you want. I used IBM Domino MA.

 <source name="ConnectorsLog" switchValue="Information">
    <listeners>
    <add name="ConnectorsLogListener" 
    type="System.Diagnostics.EventLogTraceListener, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
    initializeData="IBM Domino MA"
    traceOutputOptions="LogicalOperationStack, DateTime, Timestamp, Callstack" />
 </listeners>
    

… restart the Forefront Identity Manager Synchronization Service in services and when you run the Notes MA the logged data will land in the Application Log.

If you’ve used the Notes MA before, this should get you up and running with the latest.

Joining Identities between Active Directory and Azure Active Directory using Microsoft Identity Manager

Introduction

One of the foundations of Identity Management is the ability to join an identity between disparate connected systems. As we extend our management of identities into cloud services this adds a few twists.

A key concept is to use an anchor that is persistent. Something that doesn’t change through a users life-cycle. A user’s Security IDentifier (SID) in Active Directory is perfect. It doesn’t change when a user or group may get renamed.  What gets interesting is how the SID is represented when returned using different methods. That is what I quickly cover in this post.

Overview

The defacto method for connecting your OnPremise Active Directory to Azure Active Directory is to use Azure Active Directory Connect. AADC will synchronise users and groups SID’s to the corresponding object in AAD into the onPremisesSecurityIdentifier attribute. 

When the onPremisesSecurityIdentifier  attribute is retrieved via the GraphAPI the format looks like this: S-1-5-21-3878594291-2115959936-132693609-65242

Using an Active Directory Management Agent for FIM/MIM and synchronizing the objectSID from the OnPremise AD represents the value in the Metaverse in binary format which when viewed as text looks like this:  15000005210002431664623112825230126105190232781820

Translating SID formats so we can join identities

What we need to do is translate the string representation of the SID returned from the GraphAPI and AzureAD so that we have it in a binary format. Then we can then use those attributes in join rules to match users/groups between AzureAD and our OnPremise Active Directory.

 

In my environments I’m using the out of the box FIM/MIM Active Directory Management Agent. For Azure AD/Office 365 I’m using the Granfeldt PowerShell Management Agent to integrate with Azure AD via the GraphAPI.

overview1

On my AzureAD PowerShell Management Agent I have an attribute named AADonPremiseSID configured with the format as Binary in my PSMA Schema.ps1 as shown below.

$obj | Add-Member -Type NoteProperty -Name "AADonPremiseSID|Binary" -Value 0x10

On my Azure AD PSMA I have the following lines in my Import.ps1 which essentially takes the value retrieved from the GraphAPI S-1-5-21-3878594291-2115959936-132693609-65242 and converts it to a binary array that in text looks something like 15000005210002431664623112825230126105190232721825400 and stores it in the AADonPremiseSID binary attribute in the connector space.

# Create SID .NET object using SID string from AAD S-1-500-........ 
$sid = New-Object system.Security.Principal.SecurityIdentifier $user.onPremisesSecurityIdentifier
 
#Create a byte array for the length of the users SID
$BinarySid = new-object byte[]($sid.BinaryLength)

#Copy the binary SID into the byte array, starting at index 0
$sid.GetBinaryForm($BinarySid, 0)

#Add the SID to the user in the connector space
$obj.Add("AADonPremiseSID",$BinarySid)

This then lets me join my users (and groups using the same method) between AD and AAD.  Essentially a line to put it into Security Identifier format, two lines to convert it to a binary array and a line to store it in the connector space. Simple when you don’t over think it.

I’m posting this because I know I’m going to need to do this often. Hope it helps someone else too.

Error rebuilding MIMWAL – File MicrosoftServices.IdentityManagement.WorkflowActivityLibrary.dll not found

First published on Nivlesh’s blog at https://nivleshc.wordpress.com

A few days ago, I was going through the steps for compiling MIMWAL, as listed at http://ithinkthereforeidam.com/installing-the-mimwal/ and came across an interesting problem.

After I had rebuilt my Visual Studio package, I went to run Sign.cmd and kept getting the following error message

Signcmd_Error

Error: File “MicrosoftServices.IdentityManagement.WorkflowActivityLibrary.dll” Not Found. You need to compile WAL solution first! Make sure you use REBUILD Solution menu. Aborting script execution…

This was quite bizarre as I had not deviated from the steps listed in the above mentioned article. It was time to put on my Sherlock hat and find the culprit behind this error!

I opened the SolutionOutput folder and compared the contents to what was shown in the article and found something interesting. The dll mentioned in the error was indeed missing!

Also the file MicrosoftServices.IdentityManagement.WorkflowActivityLibrary.pdb was missing.

This meant that there must have been an error when rebuilding the package in Visual Studio. I alt+tabbed to my Visual Studio screen and in the output pane, saw something interesting. It showed that there had been some issues while copying  MicrosoftServices.IdentityManagement.WorkflowActivityLibrary.dll to the SourceOutput folder.

VisualStudioOutputPane_Error

The error

WorkflowActivityLibrary -> C:\MIMWAL-2.16.1028.0\src\WorkflowActivityLibrary\bin\Release\MicrosoftServices.IdentityManagement.WorkflowActivityLibrary.dll
1> Does C:\MIMWAL-2.16.1028.0\src\SolutionOutput specify a file name
1> or directory name on the target
1> (F = file, D = directory)? ?

seemed to indicate that when Visual Studio was trying to copy the two missing files, it hadn’t been able to determine if the destination folder  SourceOutput was a directory or a file. This resulted in Visual Studio skipping the copy of these files. Doing some investigation, I found that the MIMWAL source package didn’t contain a .\src\SourceOutput folder. This explained why Visual Studio was showing the above warnings.

Based on my findings, I found two solutions that helped resolve the issue

Solution 1

Rebuild the Visual Studio Package again. On the second try, since the SourceOutput directory now exists, the files will be successfully copied.

Solution 2

Before rebuilding the MIMWAL package, create a subfolder called SourceOutput inside the src folder

My preference is for Solution 2 as it means that I won’t get any errors.

After successfully rebuilding the MIMWAL package, I ran sign.cmd and this time around – Success! I got the expected result.

VisualStudioOutputPane_Success

Signcmd_Successful

I hope this blog helps anyone else who might be having issues with compiling MIMWAL and running sign.cmd

 

Standalone installation of the MIM Self Service Password Reset Portals ends prematurely

Today I was performing a standalone installation of the MIM Self Service Password Reset Portals (Enrollment and Reset). These Portals rely on IIS and not the normal prerequisites associated with the MIM Service Portal (SharePoint etc).  As such using PowerShell I’d only installed the Web Server Role with the usual dependencies.

On starting the MIM Service and Portal installation I got the dreaded Microsoft Identity Manager Service and Portal Setup Wizard ended prematurely dialog. So straight into debug mode running with an installation log as per the command below.

msiexec /i “f:\Service and Portal\Service and Portal.msi” /l*v c:\temp\install.log

InstallTerminatedPrematurely

Into the install.log file created from the installation process I see the following.

Looking into the install log I notice the following error.

InstallLogError

In a more readable form

SFXCA: Ensure that the proper version of the .NET Framework is installed, or that there is a matching supportedRuntime element in CustomAction.config. If you are binding to .NET 4 or greater add useLegacyV2RuntimeActivationPolicy=true to the element.
CustomAction GetIISVersionFromRegistry returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)

I have .NET Framework 4.5 installed. Could it be MIM 2016 SP1 still needed .NET Framework 3.5 ?

DotNETVersions

Taking a punt I installed .NET 3.5.

DOTNET35Install

Restarted the Install. Success.

Success

There you go. Even when you’re only looking to have the SSPR Portals installed you need to have .NET Framework 3.5 installed. And FYI I needed to have the Windows Server 2012 R2 media handy to get the sources for .NET Framework 3.5.