Identity Engineering

One of the things that I've always believed was missing from MIM and its predecessors was the ability to automatically 'run' the sync engine. The supported way of 'automating' the sync engine is to develop scripts that call the MIIS WMI methods. However, those scripts usually just cycle through the management agents and run profiles in a predetermined order, at a predetermined interval. Over the years, I've often thought that there must be a better way than this! When we consider the various operations that can be performed on each management agent, the clues to how to do this start to become clear. Delta import Performed when a change occurs in a connected system Delta synchronization Performed when an import operation stages changes in a connector space Export Performed when a synchronization stages outbound changes in a connector space Confirming import Performed when an export leaves  unconfirmed imports in the connector space In all...

Microsoft Identity Manager and its predecessor, Forefront Identity Manager cater for self-service password reset (SSPR) scenarios with out of the box workflows that support SMS, email, and question/answer authentication. Self-service password reset is a very important capability for any organization, and when properly deployed, can significantly reduce calls to the service desk. However, even when SSPR is available in an organization, there will always be a percentage of password resets that the service desk performs. It could be that the user is not enrolled in SSPR, that they didn't know SSPR was available, or their registered SSPR mechanisms were no longer available (eg they have a new phone number, or no longer have access to their registered email address). In these cases, the service desk is usually called and a manual password reset is performed. This is not a scenario that is current supported by MIM directly, which typically results in ...

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...