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.

Restarting VS Code fixed NPM INSTALL intermittent EPERM issues

Whilst doing some NPM build work for VSTS Extensions I kept getting intermittent EPERM errors about renaming Windows files during NPM install (as discussed on GitHub)l. When you get this it completely blocks any development.

As the Github issue discusses there are many possible reasons for this issue, and many proposed potential solutions. However the only one that worked for me was to restart VS Code; as this appeared to be locking the node_modules folder somehow. This was even though I could delete it via Windows Explorer without any problems.

A quick restart of VS Code and all was good again for a while, good enough to work with.

Duplicate project GUID blocking SonarQube analysis of Windows 10 Universal Projects

I have working on getting a Windows 10 Universal application analysed with SonarQube 6.x as part of a VSTS build. The problem has been that when the VSTS task to complete the SonarQube analysis ran I kept getting an error in the form

 

WARNING: Duplicate project GUID: "8ace107e-8e3c-4a1b-9920-e76eb1db5e53". Check that the project is only being built for a single platform/configuration and that that the project guid is unique. The project will not be analyzed by SonarQube. Project file: E:\Build1\_work\58\s\BlackMarble.Victory.Common.Module.csproj

… plus loads more similar lines.
The exclude flag has been set so the project will not be analyzed by SonarQube. Project file: E:\Build1\_work\58\s\BlackMarble.Victory.Ux.Common.csproj
… plus loads more similar lines.

WARNING: Duplicate project GUID: "1e7b2f4e-6de2-40ab-bff9-a0c63db47ca2". Check that the project is only being built for a single platform/configuration and that that the project guid is unique. The project will not be analyzed by SonarQube. 2017-06-09T15:50:41.9993583Z ##[error]No analysable projects were found but some duplicate project IDs were found. Possible cause: you are building multiple configurations (e.g. DEBUG|x86 and RELEASE|x64) at the same time, which is not supported by the SonarQube integration. Please build and analyse each configuration individually.
Generation of the sonar-properties file failed. Unable to complete SonarQube analysis.

Turns out the issue was that even though my CI build was only set to create an x86|Debug build the act of creating the .APPX package was causing both x64 and ARM builds to be build too, this was too much for SonarQube as it though I had a multiplatform build..

The answer was to pass a parameter into the Visual Studio build task to disable the creation of the .APPX package.

The parameter override required is /p:AppxBundle=Never. This overrides the setting of Always that was set in the .CSProj file.

 

image

Once this change was done analysis completed as expected. Just need to fix all the issues it found now!