Identity Engineering

Today I'm releasing a new add-on for the FIM/MIM portal. The Lithnet User Verification Module allows IT staff to use the MIM portal to send an SMS code sent to a user's mobile phone. This is useful in scenarios where a user calls the service desk and needs to be verified before the service desk can take an action such as resetting a password or asking for a change to a group that they own. If you have your users registered for SMS-based self-service password reset, then this module is ready for you to use today. It will use the same SmsServiceProvider.dll you created to enable SSPR, and will get the user's mobile number from the msIdmOtpMobilePhone attribute. There are lots of configuration options available , so if you want to get the mobile number from a different attribute, you can certainly do that. You can also customize the attributes displayed by the tool, change the length of the security code, and even restrict access to the tool to a particular set of...

In 2015, I released the first version of the REST API for the FIM/MIM Service. I designed it to abstract away the complexities of the native SOAP endpoint, and open up the possibilities of integrating with FIM from operating systems and libraries outside of the Windows/.NET ecosystem. It's been used by many awesome public and private projects since then. Check out Peter Stapf's guide on using it to create PowerApps . Features have been added over time, usually by request, which means now, using simple JSON calls, you can perform the following tasks Create resources Modify resources Delete resources Get a resource Get the current user's permissions on a resource Search for resources Full localization support Getting approval requests Approving or rejecting requests However, I needed to make some changes to the API that would have broken compatibility with existing versions, so I decided to add another endpoint to this API, and release a new version. Both ve...

Update: December 2018: Microsoft have provided an option to disable unauthenticated binds in Windows Server 2019 A caution to anyone that uses applications that rely on LDAP authentication against Active Directory, or Active Directory Lightweight Directory Services to do so. Both services will appear to accept a blank password for any users when performing a simple bind. While behind the scenes, that's not what is happening, if your application doesn't check for and reject a logon attempt with the blank password itself, it might incorrectly assume a successful authentication against LDAP. This post details how I came to learn about this behaviour, how wide spread the problem is, and what can be done about it. The discovery A few weeks ago, I was at my desk, enjoying my lunch, when I received a call from a customer in a panic. He told me that our AD LDS server was allowing people to access his application without typing in a password. I assumed he was talking about anonym...

Problem There is a known issue with FIM/MIM that causes the synchronization service to stop responding, requiring you to kill miiserver.exe with task manager and restart the service. Cause This is triggered when the following two conditions occur A delta import on the FIM MA finishes A synchronization run on another MA is in progress Investigation When the FIM MA goes to write its delta watermark, it does so by updating the value in its MA configuration. Unlike other MAs, this requires a full MA config update (the same as if you changed a flow rule or other setting in the MA config), which increments the version number, and requires an exclusive database lock. A synchronization running at the same time reads the same database table and causes a deadlock situation that is never resolved. Evidence that this behaviour is different from other MAs can be seen by running the following command using Lithnet MIIS PowerShell . The FIM MA will always have a much higher versio...

Recently, we had an issue where four specific users would not sync into Azure AD. There were no noticeable differences in attributes between these users and ones that were working. Compounding the issue was a rather unhelpful error message The cause of the error is not clear. This operation will be retried during the next synchronization. If the issue persists, contact Technical Support With a little help from Microsoft support, we were able to resolve the issue using the following steps First, create a new user in Office 365 with a default domain UPN (eg org.onmicrosoft.com) Get the users ObjectGUID from AD Set the ImmutableID attribute on the new account to be the ObjectGUID of the AD account Run a delta sync or wait for next scheduled sync. At this point, the AD user will be joined with the Azure user account, and the user's attributes will be updated appropriately. For example, if you receive the following error in an email user1@lithnet.io The caus...

One of the first things I do when building a new FIM service instance is to create an admin account for myself, so I can use PowerShell tools, log into the portal etc without having to use things like runas to log in as the built-in admin account. While you can create a resource manually in the portal, you can't easily set the binary ObjectSID value on the resource, and without that, you can't log in. Manipulating binary attributes quite tricky to do with the out of box tools. To set the users up properly, you usually have to flow them in from the AD MA with the ObjectSID present. Which can take quite a bit of effort. I prefer to cheat, and get my own account into the portal via script. The Lithnet FIM/MIM Service PowerShell Module  has first-class support for binary attributes, so using this to add the ObjectSID is just as easy as it is to set a string value. This script will add the specified AD user to the FIM/MIM service and add them to the administrators...

The Lithnet FIM/MIM Service PowerShell module (LithnetRMA) allows you to not only drastically reduce the code you have to write to perform basic create, update and delete operations, but it’s significantly faster than the out-of-box FimAutomation module too. I love hearing reports from people about how they were able to cut hours off the execution time of their existing scripts by converting them to use LithnetRMA! Read about how Jon got a script down from 22 hours to 6 mins using the Lithnet #fim2010 PowerShell module. Awesome! https://t.co/bVr1dHx7ey — Ryan Newington (@RyanLNewington) October 9, 2015 Read about Ike's performance improvements using Lithnet #fim2010 PowerShell module - 12 hours down to 30 minutes! http://t.co/KVpv4qreV1 — Ryan Newington (@RyanLNewington) September 2, 2015 One of the biggest speed advantages that LithnetRMA has over the out-of-box FIMAutomation module is that it supports composite updates. Composite updates combine multiple updates ...

Thanks to all who came along to my session at Microsoft Ignite today. Here are the resources I presented at today’s session WIN332 – From Fortran to FIM: Dragging your identity management system of our the dark ages. Resources for Engineers and Admins Lithnet ACMA Codeless business rules engine ACMA is a fast, efficient, codeless way of implementing business rules that can create and transform information within your FIM/MIM implementation. ACMA comes with a UI editor for your rules file, a PowerShell module for modifying ACMA objects directly, and a unit testing engine that allows you to test all the rules you have created. Check out the video link below for a more detailed demonstration of the capabilities of ACMA Lithnet Universal MA Rules Extension (UMARE) UMARE is a codeless rules extension for FIM/MIM. It can be used on any MA to perform transform operations on incoming and outgoing identity data. With over 40 transforms available out of the box, including very common scena...

There are many systems out there that just don’t support delta imports. Deltas are important for ensuring speedy and efficient operation of the FIM synchronization engine. While we can’t invent true deltas when the connected system doesn’t provide the information, sometimes its enough to just provide FIM the deltas of what it has changed. This is especially relevant for systems where FIM is mostly responsible for the data in the connected system. What would be handy, is if at export time, we could provide FIM with the confirmed changes made in the target system. While FIM allows us to say that an export was successful, it still expects to confirm those changes took place on the next import operation. What if we could construct our import CSEntryChange objects at export time? The Lithnet.MetadirectoryServices library contains a set of helper classes to make writing management agents and rules extensions a little bit easier. One of the tools it contains is a CSEntryChangeQueue clas...

Summary The FIM Service allows you to query for resources using a subset of the XPath 2.0 dialect. It provides a quite powerful mechanism for searching for resources, but has more than a few curiosities when it comes to constructing queries for different attribute types. The Lithnet FIM Service PowerShell module includes three cmdlets to help take the guess work out of constructing your XPath queries. New-XPathQuery The New-XPathQuery cmdlet creates a predicate that forms part of an XPath expression. The query is the Attribute = ‘value’ component of the expression New-XPathQueryGroup An XPath query group contains multiple XPath query objects, or other query groups, that are combined together with an ‘and’ or ‘or’ operator. New-XPathExpression The XPath expression wraps the query or query group with the appropriate syntax defining the object type (eg /Person[query] ) Working with different attribute types The cmdlets generate the correct syntax for each attribute type,...