Identity Engineering

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 anonymo

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 version nu

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