BM-Bloggers

The blogs of Black Marble staff

Azure AD Connect–Upgrade to 1.1.533.0 and Change of Source Anchor to mS-DS-ConsistencyGuid

As I blogged yesterday, I upgraded our instance of Azure AD Connect to what was, at the time, the latest version, 1.1.524.0. Subsequently, Microsoft Security Advisory 4033453 was published indicating that an upgrade to version 1.1.533.0 was very strongly recommended.

As before, the upgrade went smoothly, however there were a couple of additional points of note during the upgrade:

  1. Running the Azure AD Connect msi gave the following warning (note that I appended the version number to the file name in this example):
    Azure AD Connect 1.1.533 SmartScreen Warning
    I’m assuming that this will be fixed shortly Smile
  2. Once the upgrade was complete, the following warning was shown:
    Source Anchor Using objectGUID
    ’Azure Active Directory is configured to use AD attribute objectGUID as the source anchor attribute. It is strongly recommended that you let Azure manage the source anchor for you. Please run the wizard again and select Configure Source Anchor.
    Re-running the wizard and selecting the ‘Configure Source Anchor’ task allowed Azure AD Connect to pick ‘mS-DS-ConsistencyGuid’ as the source anchor, and all configuration occurs automatically. At the end of the process however another warning is shown indicating that if ADFS is managed externally to Azure AD Connect, then claim rule changes are required to align the new Source Anchor with the value returned and users may not be able to log in unless these changes are made.
    In our case, this means that changes need to be made to the ADFS rules for the Office 365 relying party trust.. To make these changes, the following steps were taken:
    1. On the ADFS Server, expand ADFS, then Trust Relationships, then click on Relying Party Trusts. Right-click the ‘Microsoft Office 365 Identity Platform’ and select ‘Edit Claim Rules…’:
      O365 Relying Party Trust
    2. Select rule 1 and click the ‘Edit Rule…’ button.
    3. The original rule was:
      c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"]
        => issue(store = "Active Directory", types = ("http://schemas.xmlsoap.org/claims/UPN", "http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"), query = "samAccountName={0};userPrincipalName,objectGUID;{1}", param = regexreplace(c.Value, "(?<domain>[^\\]+)\\(?<user>.+)", "${user}"), param = c.Value);
      The only change that was required was to change objectGUID to mS-DS-ConsistencyGuid, I.e.
      c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"]
        => issue(store = "Active Directory", types = ("http://schemas.xmlsoap.org/claims/UPN", "http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"), query = "samAccountName={0};userPrincipalName,mS-DS-ConsistencyGuid;{1}", param = regexreplace(c.Value, "(?<domain>[^\\]+)\\(?<user>.+)", "${user}"), param = c.Value);
    4. Save the rule and double-check that you can authenticate to Office 365.

Some background to the issue of ImmutableID and the value to select for Source Anchor for Office 365 can be found at https://blog.msresource.net/2015/05/20/revisiting-the-microsoft-online-immutable-id-design-decision/

Azure AD Self-Service Password Reset Issues

We recently saw an issue with Azure AD self-service password reset (SSPR). It’s been working fine for us for ages, ever since we first configured it using DirSync, but recently users started seeing the following message:

Please Contact Your Admin

Get back into your account

Please contact your admin

We’ve detected that your user account password is not managed by Microsoft. As a result, we are unable to automatically reset your password.

You will need to contact your admin or helpdesk for any further assistance.

As we’d made no changes, we were obviously concerned!

Initially I took the following steps to try and resolve the issue:

  1. Ensured that the OS patch levels of the servers (Azure AD Connect, ADFS, WAP) were up-to-date, which they were.
  2. Upgraded Azure AD Connect to the most recent version. The version we were running was a little behind, but not significantly so. During the upgrade process, the wizard takes you through what you’d normally see if you reconfigure Azure AD Connect and select the ‘customize synchronization options’ task. The optional features selected were still the same as we’d picked the previous time we’d upgraded, and included ‘password writeback’.

Unfortunately none of the steps taken above made any difference.

Looking in the configuration page for Azure AD in the old portal, I noticed that the ‘Password write back service status’ was still set to ‘Not configured’:

Password Write Back Service Status Not Configured 

Which, bearing in mind I’d just upgraded Azure AD Connect and been through the configuration wizard and seen that this option was ticked, should not as far as I was concerned be the case.

To correct the issue therefore, I took the following steps:

  1. Launched the configuration of Azure AD Connect and selected the ‘customize synchronization options’ task.
  2. When presented with the optional features configuration page of the wizard, unticked the ‘password writeback’ option and then completed the configuration.
  3. Repeated the above steps, but this time ensured that the ‘password writeback’ option was ticked:
    Azure AD Connect Password Writeback Config Option

Checking the configuration page in the old Azure Portal again, the status of the ‘Password write back service’ is now ‘Configured’ and the correct SSPR prompts are again being displayed to users.