Home » azureAD

Tag: azureAD

AppStream Domain Joined SAML Fleet not authenticating after AD domain prompt


A customer had an AD Domain joined fleet and configured through SAML (the only way you CAN log into an AD joined fleet) and after the password prompt the session was looping and asking for their domain credentials over and over again.


After investigating the provided troubleshooting steps something was still blocking the AD joined fleet from logging in at the domain password prompt, though authentication was fine for the Image builders.





As a prerequisite for AD Domain joined fleets you cannot have an AD Logon banner displayed as it prevents the AppStream service from connecting into / accessing the streamed desktop.

In some scenarions customers will have the logon banner only display for Users and not Administrators (so you never see the prompt on an Image builder for example even if its in the same OU and of course the GPOs dont apply when accessing the Image builder with the built in AppStream administrator/template user/test users.

Snippet from the Prerequisites Page specific to this scenario: (please use the above URL for the most up to date information)

Group Policy Settings

  • Computer Configuration > Administrative Templates > Windows Components > Windows Logon Options > Disable or Enable software Secure Attention Sequence — Set this to Enabled for Services.
  • Computer Configuration > Administrative Templates > System > Logon > Exclude credential providers — Ensure that the following CLSID is not listed: e7c1bab5-4b49-4e64-a966-8d99686f8c7c
  • Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > Interactive Logon > Interactive Logon: Message text for users attempting to log on — Set this to Not defined.
  • Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > Interactive Logon > Interactive Logon: Message title for users attempting to log on — Set this to Not defined.

As part of a simple deployment or for your simple proof of concepts we recommend you simply ensure the OU your AppStream computer objects are being created under has GPO inheritance blocked and there are no higher level GPOS forced to apply. Get the service running and confirmed as accessible and then slowly start applying the company requried GPOS for look feel and security.

Azure Active Directory synchronisation attempts failing

Unhealth identity synchronization notification.

Azure Active Directory did not register a synchronization attempt from the identity synchronization tool in the last 24 hours for <Company>


There are a large number of reasons why this might be affecting you, however in this specific instance we needed to ensure the Microsoft Azure Active Directory Connect was not stuck at ‘required to upgrade’ screen.

Connect to the AD where you have installed the Sync tool and confirm.

Perform the upgrade as necessary

I then had to spend nearly as hour trying to discover what username / password was configured on this damned account as it was not working with my Azure portal login (portal.azure.com).

As this was a partner subscription from the Microsoft Action pack the original configuration was setup under portal.office.com, also as password synchronisation was setup as part of the AD sync, the previously updated on prem passwords had not synced with Office – so no one could log in with their new passwords.


  1. I ran password recovery for the @xxx.onmicrosoft.com account
  2. Accessed the portal.office.com and confirmed all else was ok with the subscription

  3. Setup On Prem AD Sync again with the recently reset user and password.

  4. Finally we can complete the upgrade.
  5. Upgrade completed


Azure Source Anchor Upgrade from objectGUID

Post setup (or reconfiguration) of Azure AD Synchronization there is a prompt

Azure Active Directory is configured to use AD attribute objectGUID as the source anchor attribute. Its strongly recommended that you let Azure manage the source anchor for you. Please run the wizard again and select Configure Source Anchor.

Why should we do this?

Upgrading this from objectGUID to ms-DS-ConsistencyGUID is best practise and allows for easy recover of accidentally deleted on-premise user accounts.

Walk Through Steps

  1. Run the Azure AD Connector Wizard and select the Source Anchor option
  2. Select Configure Source Anchor

  3. Click ‘Configure’ to commit the settings appropriately

  4. Success