Azure AD Single Sign-On Basic Auth Popup

Posted on Leave a commentPosted in AADConnect, AADSync, Azure Active Directory, Azure AD, AzureAD, conditional access, microsoft, modern authentication, SSO

When configuring Azure AD SSO as part of Pass-Through Authentication (PTA) or with Password Hash Authentication (PHA) you need now (since March 2018) to only configure a single URL in the Intranet Zone in Windows. That URL is https://autologon.microsoftazuread-sso.com and this can be rolled out as a registry preference via Group Policy. Before March 2018 there was a second URL that was needed in the intranet zone, but that is no longer required (see notes).

So this short blog post is how to fix SSO when you do see a popup for this second URL though it is no longer required. The popup looks like:

image

It has OK and Cancel on it as well, but my screengrab I made when I saw the issue was not brilliant, so I “fixed” the bottom of the image so its approx. correct!

The URL is aadg.windows.net.nsatc.net. Adding this to Local Intranet Zone even though it is not needed does not fix the issue. The issue is caused because on Windows 10 (version 1703 and maybe others) someone has enabled Enhanced Protected Mode. Azure SSO does not work when Enhanced Protected Mode is enabled. This is not a setting that is enabled on client machines by default.

Enhanced Protected Mode provides additional protection against malicious websites by using 64-bit processes on 64-bit versions of Windows. For computers running at least Windows 8, Enhanced Protected Mode also limits the locations Internet Explorer can read from in the registry and the file system.

It is probable that Enhanced Protected Mode is enabled via Group Policy. It will either have the value Isolation (or Isolation64bit) set to a value of PMEM at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main or HKEY_CURRENT_USER\SOFTWARE\Microsoft\Internet Explorer\Main or the policy equivalent at  HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Internet Explorer\Main or HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\Internet Explorer\Main when set via GPO settings.

This issue is listed in the Azure AD SSO known issues page at https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-troubleshoot-sso. The reason why Enhanced Protected Mode does not work with Azure AD SSO is that whilst Enhanced Protected Mode is enabled, Internet Explorer has no access to corporate domain credentials.

Configuring Hybrid Device Join On Active Directory with SSO

Posted on 15 CommentsPosted in Azure Active Directory, Azure AD, AzureAD, device, device registration, hybrid

The instructions from Microsoft at https://docs.microsoft.com/en-us/azure/active-directory/device-management-hybrid-azuread-joined-devices-setup are missing some of the steps on setting up hybrid device join to Azure AD. This is a complete list of steps when Pass-Thru auth with SSO is enabled on the domain.

  1. Enable SSO – this is covered elsewhere. You can also do hybrid device join on a federated domain, though this is not covered here.
  2. On your AADConnect server ensure that the MSOnline PowerShell add in is installed – this is the AdministrationConfig-3.msi executable that is needed to run cmdlets like Get-MSOLUser. Is only supported by the MSOnline PowerShell module version 1.1.166.0. To download this module, use this link
  3. Open an administrative PowerShell
  4. cd 'C:\Program Files\Microsoft Azure Active Directory Connect\AdPrep'
  5. Import-Module .\AdSyncPrep.psm1
  6. This will enable the AD module and import some scripts for device writeback and device registration. We are looking at device registration here
  7. $aadAdminCred = Get-Credential

    #Enter a global admin credential

  8. Initialize-ADSyncDomainJoinedComputerSync –AdConnectorAccount [connector account name] -AzureADCredentials $aadAdminCred

    #[connector account name] is the name of your domain (domain.local for example) as shown in the AADConnect Synchronization Service Manager –

  9. You should see the message “Initializing your Active Directory forest to sync Windows 10 domain joined computers to Azure AD.” followed by “Configuration Complete”. Errors about Azure Registration mean you are running the wrong version of the Azure AD PowerShell cmdlets
  10. The required settings in AD (for one forest) are now done. If you have multiple forests, return to the above referenced document and run the script to register the Devices Registration Configuration node to AD
  11. If you have conditional access available (have at least one Azure AD Premium licence assigned to your admin account) then you can add Trusted Sites to Azure AD to control where MFA prompts for device join will happen outside of. Add each office public NATed IP address with /32 (or whatever is needed at the end) into Azure Active Directory (under portal.azure.com) > Conditional Access > Named Locations > New Location
    image
  12. Add the same IPs to the “Configure MFA trusted IPs” link on the same page that you see the IP’s listed above
  13. Your list of devices under Azure Active Directory should now increase as users reboot Windows 10 1703 machines and later. See the above document about the GPO setting needed to role this out to older versions of Windows (Workplace Join settings)

Azure AD SSO and Disabled Computer Accounts

Posted on 5 CommentsPosted in Authentication, Azure Active Directory, Azure AD, Office, Office 365, SSO

When you set up Azure AD SSO, the Azure AD Connect application creates a computer account called AZUREADSSOACC. Do not disable this account, or SSO stops working.

I’ve had a few clients in the past week disable this when generally disabling all the computer accounts that have not logged in for X days.

Therefore if you have Azure AD SSO enabled, I suggest updating your documentation on disabling computer accounts – ‘cause not all computer accounts actually login as computers (I’m thinking Cluster services here as well) and consider actually whether or not disabling accounts for computers that are not logging in any more is necessary.

Then also take the AZUREADSSOACC account and set a description on it saying do not disable!

image

AADConnect Password Reset Date Sync Issues

Posted on 2 CommentsPosted in AADConnect, active directory, Azure Active Directory, Azure AD, sync error

Got this error the other day at a client and found nothing listed on Internet search for it, which of course means only I have this issue! But even so, lets get to see what it means and how to fix it.

The error turned up in the AADConnect tool and it reported sync-generic-failure on the Delta Synchronization stage when pulling data from Active Directory.

Error in evaluation of expression: IIF(IsPresent([pwdLastSet]),CStr(FormatDateTime(DateFromNum([pwdLastSet]),”yyyyMMddHHmmss.0Z”)),NULL) 
. Sync Rule: In from AD – User AccountEnabled
Destination: pwdLastSet

Following the above error was the entire stack dump of the issue (a few pages of errors) which are visible by clicking the sync-generic-failure link in AADConnect and clicking the Stack Trace button. Buried inside the stack dump are a few “InnerException” errors. These point out the real cause of the issue.

InnerException=>
Argument 1 to function DateFromNum is out of range.

and

InnerException=>
Not a valid Win32 FileTime.
Parameter name: fileTime

   at System.DateTime.FromFileTimeUtc(Int64 fileTime)
   at SyncRuleExpressions.FunctionLibrary.DateTimeFunctions.DateFromNum(Value[] arguments)

This shows that the user in question (which is listed by DN in the stack dump) has an invalid value for the pwdLastSet attribute.

So we opened up the user and viewed the pwdLastSet value and it read -1

Now this value is valid – it is used in code and scripts to set this attribute to the current date and time, as normally this value is set by a script and so setting -1 means that you want the time for the last password set to be now.

In my clients domain either the script failed or something else did not work, and the property was set and stayed at -1 in the directory. Viewing this attribute in adsiedit showed it to be <never> and double-clicking this attribute showed the value to be -1.

In the end the fix was simple – we retyped -1 into the field in adsiedit and clicked OK. This time the attribute updated to the current date and time. Now that the attribute was a valid date/time, the AADConnect sync rule worked and the object was synced to Azure AD.

Azure MFA 503 Error When Authenticating

Posted on Leave a commentPosted in Azure, Azure Active Directory, MFA, Multi-Factor Authentication, Office 365

If you have installed version 7 of Azure MFA Server on-premises (7.0.0.9 or 7.0.2.1 at the time of writing) and have enabled IIS authentication with Forms Based authentication and the Native App, but when you need to authenticate you are presented with a 503 DLL error. The reason for this is that version 7 removed support for 32 bit Windows, but if the application pool in IIS for the website you are running is a 32 bit pool then the 64 bit DLL provided by MFA for authentication will not run. If you change the pool to 64 bit then the MFA authentication DLL will work, and your phone call/text or mobile app verification should occur. Of course, if you change the application pool to 64bit make sure that other DLLs used by the application are not 32 bit and so the application itself, rather than MFA, would not fail.

If the application is 32 bit and therefore the application pool needs to be using 32bit MFA DLL’s then you either need to upgrade your application to 64 bit or downgrade MFA Server to version 6.3. To obtain version 6.3 you need to raise a support call with Microsoft.

OU Filtering in AADConnect–What They Grey Boxes Mean

Posted on Leave a commentPosted in AADConnect, az, Azure Active Directory, Azure AD, dirsync, Office 365

So I had the chance to check this today. If you do OU filtering in the DirSync tools you will get an OU structure with various grey boxes in it. Here is an example:

image

It appears that both clip_image003and image are options in the sync tool. You get the first (grey with a tick ) if you select that box and untick some child objects. You get the second (grey box, no tick) if you unselect the parent and then individually select child OU’s.

If you do the second option (and get image)and then add a new OU under the parent it is not selected in the sync engine by default. Unfortunatly you cannot do this for the root of the domain during initial setup of AADConnect, as you need to select the domain in the provisioning wizard before unselecting OU’s). You can later go into the sync tool and change the domain to default unselected (image) by unselecting everything and then just selecting the OU’s you need. In this way you can be sure that later OU’s are not auto selected for syncing.

Remote Desktop And Login With AzureAD Account

Posted on Leave a commentPosted in Azure Active Directory, remote desktop

If you join a Windows 10 PC to Azure AD and then try and login to that PC over remote desktop you are in for a barrel of laughs! Or not!

The way to get it to work is as follows:

  1. Ensure that Windows 10 PC is running Version 1511 or later (type WinVer from the Run dialog)
  2. Ensure the target PC is enabled for Remote Desktop
  3. Ensure the Network Level Authentication is disabled
  4. Run MSTSC on your PC (the source) and enter the target PN name, your username (email address) and click Save As (which you will find under “Show Options”):
    image
  5. Close the Remote Desktop Connection window without connecting.
  6. Open the saved RDP file in Notepad
  7. Add the following to the bottom of the text in Notepad as shows:

enablecredsspsupport:i:0

  1. In Notepad this appears as:
    image
  2. Save the RDP file and then double-click it to connect. You will now be able to login with your AzureAD account over Remote Desktop
  3. If you cannot login, check the alternative name that your device uses for your user account. On the AzureAD joined computer, logged in as the target user, run “whoami” from the command line. It will report something like AzureAD\firstlast. You could try that value (both AzureAD and the name) as your username.

Upgrading Azure Multi-Factor Authentication Server

Posted on Leave a commentPosted in Azure, Azure Active Directory, MFA, Multi-Factor Authentication, Office 365

A new version of Azure MFA Server was released at the end of March 2016, version 7.0.0.9. This provides an in place upgrade to the previous version 6.3.1.1. This version is based on .NET 4.5 and not .NET 2.0, which is the big change in the product, along with new end user functionality in the ADFS Adapter. Note the upgrading the ADFS Adapter piece is prone to issues, which I have documented here.

This blog post just outlines the standard upgrade process. It takes about 10 minutes and the service is uninstalled and reinstalled, but leaves the database and settings in place – so it requires downtime or a load balancer. If you have more than one MFA server in a cluster then the older versions still running 6.3.1.1 will still work for users but the administration screens are read only once at least one server is upgraded. All servers should therefore be upgraded in a short interval.

Before upgrading, take a copy of the “Program Files\Multi-Factor Authentication Server” folder as a backup is useful, especially if you have the ADFS Adapter installed as the service name has changed and that breaks ADFS Server.

Then, the following are just the sequence of screenshots from the installation (upgrade) so you know what to expect:

The old version has a 2013 splashscreen:

image

The MFA admin page points out that a new version is available:

image

Ensure you have the May 2014 Cumulative Update on your Windows Server 2012 R2 boxes (you ought to regardless of this prompt):

image

Visual C++ (x86 and x64) versions will be installed:

image

image

image

image

image

image

Then there follows a long pause of a good few minutes. Hang in there, the old software is still in place and running. The new installer will start shortly:

image

image

And complete in less time than you waited for the installation to start:

image

The service restarts and this machine is now running the 7.0… version

If you start the admin console you will see that it is copyright 2016:

image

You will also get prompts about upgrading any of the installed components. If you look in Programs and Features at this time you will see that there might be some components still on version 6.3.1:

image

 

You will also see that the admin portal is running mixed versions:

image

If you open the admin console on another node, you will be warned about the mixed versions:

image

As long as you upgrade all the components one after the other you should get no issues, so I don’t recommend an order for these components to be installed in, but I do not recommend leaving them not upgraded:

image

image

I also recommend installing the required components in advance, as that is quicker. For an upgrade you need to install ASP.NET45 under IIS Application Development in Server Manager. You will return here at the end to uninstall .NET 2/3.5 if appropriate.

image

When it comes to upgrading though, I do recommend you upgrade on component and then the next. Don’t start them all at once – though you will be prompted all at once to do this. So pick one, click Yes and wait for that to complete. It will take a few minutes for each installer to start, so be patient:

image

Note that the installer does not suggest the correct Application Pool for each component. So make sure you select the correct one each time.

image

image

image

Then move onto the next installer. If you closed the Yes/No prompt for each installer you can reach it via that area of the admin console:

image

Remember to set the Application Pool correctly as well:

image

Like the User Portal installer, there is not much to see so close the installer when finished. Ensure you are running the latest .NET updates as well though:

image

I have documented the ADFS Adapter upgrade on this post, as there are specific issues with it.

If once you have upgraded all the previously installed components, you visit Programs and Features you can see that the Mobile App is not upgraded. The mobile app is not installed via the admin console, so the console will not prompt about the install. To install the Mobile App run MultiFactorAuthenticationMobileAppWebServiceSetup64.msi from C:\Program Files\Multi-Factor Authentication Server. You will need to start this installer from an administrative cmd prompt:

image

Again, change the Application Pool to the correct value for the application. It will show the Virtual Directory as well here, and unlike this example, this is recommended to be something easy to type on a mobile device. Upgrading the app does not recall the previous virtual directory name, and so you should ensure that you enter that here as well. If you upgrade it and do not change the Virtual Directory name then you need to uninstall it and reinstall it, but remember to copy the upgraded web.config from the virtual directory first. It contains the username and password of the SDK user account.

image

Upon completion of all nodes in the MFA cluster, the admin portal shows all versions the same:

image

Finally, note that though you may pick the Application Pools during the various installers, new pools with new names (starting ASP.NET v4.0) are created but not used. The old app pools are upgraded to .NET 4.0 and I recommend removing the unused pools at your convenience as both the unused and used pools are the same apart from in name:

image image

image

Password Writeback Errors

Posted on 9 CommentsPosted in Azure, Azure Active Directory, Group Policy, IAmMEC, Office 365, password

I had been struggling with password writeback testing and was coming across the following set of errors, and found that searching for them uncovered nothing online. So I wrote this blog to remind me and help you solve these issues. These errors are all visible in the Application log of the Event Viewer.

User Restrictions

The following error is because the user has “user cannot change password” option set in Active Directory:

EventID 33004: TrackingId: 7344da2c-ab9d-42ef-adea-4a17d07fdeb9, Reason: Synchronization Engine returned an error hr=80230626, message=The password could not be updated because the management agent credentials were denied access., Context: cloudAnchor: User_9b83f544-ba22-4ffb-bff5-c1c2374d654c, SourceAnchorValue: F39SWQrM2EidaboN8UC8Ww==, UserPrincipalName: ethan@contoso.co.uk, Details: Microsoft.CredentialManagement.OnPremisesPasswordReset.Shared.PasswordResetException: Synchronization Engine returned an error hr=80230626, message=The password could not be updated because the management agent credentials were denied access.
   at AADPasswordReset.SynchronizationEngineManagedHandle.ThrowSyncEngineError(Int32 hr)
   at AADPasswordReset.SynchronizationEngineManagedHandle.ChangePassword(String cloudAnchor, String sourceAnchor, String oldPassword, String newPassword)
   at Microsoft.CredentialManagement.OnPremisesPasswordReset.PasswordResetCredentialManager.ChangePassword(String encryptedChangePasswordRequestString, String publicKeyEncryptedSymmetricKey, String publicKeyEncryptedSymmetricIV)

And also, as the second error generated:

Event ID 6329: An unexpected error has occurred during a password set operation.
“BAIL: MMS(5716): ..\server.cpp(11139): 0x80230626 (The password could not be updated because the management agent credentials were denied access.)
Azure AD Sync 1.0.8641.0″

image

Group Policy Restrictions

Its possible that the errors you see for password writeback in the application log are due to restrictions on the user’s password that they have chosen. If the password is not complex enough then you get a warning in the password reset page the user is visiting in Azure, but you can also get this is a Group Policy restriction is in place even if you have set a strong password. The text in the error message in the Azure password change portal reads “This password does not meet your corporate password policy. Please make sure to use a mix of upper and lowercase letters, numbers, symbols, and to update your password to one that you haven’t used previously.”. Therefore though Azure accepted the passwords (original and new) the on-premises server rejected them with the following:

Event ID 33008: TrackingId: 3c8c78dc-9167-4286-9384-e2f0e777af87, Reason: Synchronization Engine returned an error hr=80230619, message=A restriction prevents the password from being changed to the current one specified., Context: cloudAnchor: User_9b83f544-ba22-4ffb-bff5-c1c2374d654c, SourceAnchorValue: F39SWQrM2EidaboN8UC8Ww==, UserPrincipalName: ethan@contoso.co.uk, Details: Microsoft.CredentialManagement.OnPremisesPasswordReset.Shared.PasswordResetException: Synchronization Engine returned an error hr=80230619, message=A restriction prevents the password from being changed to the current one specified.
   at AADPasswordReset.SynchronizationEngineManagedHandle.ThrowSyncEngineError(Int32 hr)
   at AADPasswordReset.SynchronizationEngineManagedHandle.ChangePassword(String cloudAnchor, String sourceAnchor, String oldPassword, String newPassword)
   at Microsoft.CredentialManagement.OnPremisesPasswordReset.PasswordResetCredentialManager.ChangePassword(String encryptedChangePasswordRequestString, String publicKeyEncryptedSymmetricKey, String publicKeyEncryptedSymmetricIV)

and

Event ID 6329: An unexpected error has occurred during a password set operation.
“BAIL: MMS(5236): ..\server.cpp(11139): 0x80230619 (A restriction prevents the password from being changed to the current one specified.)
Azure AD Sync 1.0.8641.0″

This of course seems self explanatory – your password is not complex enough for your rules on-premises but complex enough to get past the Azure initial checks that it imposes.

image

This error though is especially annoying in test scenarios where you have turned off all the complexity checks. To test why you are getting this error, first check its a password change error and not something else, and try and change the users password on-premises. You should get the same restriction. Then use the cmd prompt to check the password settings for the user.

</p> <p>net user username /domain</p> <p>

This will report the following:

User name                    user1
Full Name                    First Last
Comment
User’s comment
Country/region code          000 (System Default)
Account active               Yes
Account expires              Never

Password last set            7/7/2015 3:19:00 PM
Password expires             Never
Password changeable          7/8/2015 3:19:00 PM
Password required            Yes
User may change password     Yes

Workstations allowed         All
Logon script
User profile
Home directory
Last logon                   7/8/2015 10:31:05 AM

Logon hours allowed          All

Local Group Memberships
Global Group memberships     *Domain Users
The command completed successfully.

image

In this example, notice the highlighted. Here there password minimum age requirement in Group Policy has been removed:

image

But the domain controller (after running gpupdate to force the change to the domain controller) still enforces a single day to allow the change to occur.

For test scenarios, modify group policy to 0 days (rather than not defined) and probably increase the max age from the suggested default of 30 days:

image

After running gpupdate, you get the following for the net user command:

Password last set            7/8/2015 10:42:05 AM
Password expires             Never
Password changeable          7/8/2015 10:42:05 AM

Now you should be able to change your password in Azure against an on-premises user.

Strong Password Required

In the password change portal, the user is required to enter a strong password regardless of any restrictions that you have on-premises. So even if you are testing and have removed all history and complex and renewal requirements for the password, Azure will ensure that a strong password of 7 or more characters is entered regardless of your on-premises policy. In fact, Azure does not know your on-premises policy for password restrictions and enforces its own in addition to the one you have.

You get errors in the portal that read “Strong password required. Combine at least three of the following: uppercase letters, lowercase letters, numbers, and symbols.”. You also cannot reset the password to the same and the errors you get look like the following options:

image image image image 

Success

For completion of the blog, here is what you should see in the event log when it is working:

Event ID 31006: TrackingId: f430189d-984c-41d5-a4a6-333c66ffae1f, ChangePasswordRequestStart, Details: ethan@contosochemists.co.uk

Event ID 31007: TrackingId: f430189d-984c-41d5-a4a6-333c66ffae1f, ChangePasswordSuccess, Details: Context: cloudAnchor: User_9b83f544-ba22-4ffb-bff5-c1c2374d654c, SourceAnchorValue: F39SWQrM2EidaboN8UC8Ww==, UserPrincipalName: ethan@contosochemists.co.uk