Token2 Hardware OAuth Tokens and Azure AD Access

Posted on Leave a commentPosted in active directory, Azure Active Directory, Azure AD, AzureAD, MFA, multi-factor auth, phone factor, token2

This blog post walks through the process of logging into Azure AD resources (Office 365, other SaaS applications registered in Azure AD and on-premises applications that utilise Azure AD App Proxy).

First step is to order your desired hardware. For this article we are looking at the devices manufactured by Token2 (www.token2.com). These include credit card style and dongle type devices. The options are available at https://www.token2.com/site/page/product-comparison

For the purposes of this blog post I have been using the TOTP emulator on the Token2 website. This allows you to create virtual TOTP devices and step through and test the entire process without buying a physical token. The TOTP device emulator can be found at https://www.token2.com/site/page/totp-toolset. Each time you browse to this site a new device is emulated, but using key=XXXX, where XXXX is the 32 character device seed. Longer testing will require you to keep a record of the seed ID and use it in the emulator, or keep the browser window open.

Step 1: Order Devices

For this, I am using the emulator mentioned above, but you would order a number of devices and upon arrival request the unique secret identifiers for each device over encrypted email. In Feb 2019 a programmable device with time sync is being released which will allow you to set the secrets yourself and ensure that clock drift on the device is not a reason for them to stop working after a few years!

The secret is required for upload to Azure AD and is required in the form of a CSV file with six columns:

upn,serial number,secret key,timeinterval,manufacturer,model

For example, it could look like this for a two emulated devices:

upn,serial number,secret key,timeinterval,manufacturer,model
user1@token2.com,2300000000001,BMUOZOAFVH4ZYRXU7SFRIIQ3FQNKTDVL,30,Token2,miniOTP-1

user2@token2.com,2300000000002,R5AGIKGVCCGIV275IDTCI2HWDQK3PK2R,30,Token2,miniOTP-1

Ensure each UPN in the first column matches the device you are issuing to the user and upload the CSV file to Azure AD. This is done from Azure Portal > Azure Active Directory left menu > MFA (in Security area) > OAUTH tokens (in settings area):

image

Click Upload and browse for your CSV file. As long as there are no errors it will upload fine. Errors are displayed in the notifications area. Once the upload is complete click Refresh to see the imported hardware tokens. Tokens assigned to users that do not exist will appear after the user is created, if the user is created within 30 days.

I have in the below screenshot uploaded one token for a test user.

image

The token needs activating before it can be used. Activation is to confirm the token works and so you will need the next six digit sequence from the device and so have physical access to the device. End user activation is planned, but as of writing in Jan 2019 the administrator needs to activate the hardware token.

Click Activate and enter the current TOTP six digit number. The CSV file contains information about the time change for the device, which is 30 seconds for these Token2 devices, and so you need to enter the current, previous or next ID (next ID is shown in the emulator and not on the hardware token).

image

Click Activate button when the six digit code is entered. The green ticky ticky next to the number just means you have entered a six digit number, and not that it is the correct number!

After activation you will see the Activated column ticked.

image

You can now distribute the token to the user.

Step 2: Require token for login

Other blog posts and documentation on the internet cover the requirements for forcing the user to use an MFA device, so here I will just cover what is different when tokens are used. Firstly the user does not need to register their device – the upload of the CSV file and the activation of the token by the administrator covers this step. This does mean though that the user needs the token before they next are required to login with the MFA device or they will not be able to login. Therefore distribution of token following activation, or activation before MFA requirement is currently needed. End user activation which is coming soon will reduce this distribution gap.

Secondly, the code from an Authenticator app (such as Microsoft Authenticator or Google Authenticator) can be used as well as the code from the hardware token device (if the app is registered as well). Microsoft allow multiple devices to provide codes, so the user message on-screen at login will not say “Enter the code from your token2 device” but currently says “Please type in the code displayed on your authenticator app from your device”, but the current code from your hardware device and not only a registered app will work here as well. This is probably the most confusing stage of the process. The hardware token works wherever authenticator app is displayed – maybe this will change.

Finally, the user will only be required for an MFA login if either MFA is enabled for the account or conditional access enabled and the login or application access triggers an MFA requirement. The second of these is the better one to use. The admin configuration to force the user to enter their token one time code though is as follows:

  1. Ensure that MFA service settings allows verification code from mobile app or hardware token as shown:
    image
  2. Ensure that the IP range where MFA is skipped is not the range the user is currently located on, otherwise the user will not be prompted for their MFA token. This IP range is configured in the above settings as well.
  3. Ensure that the user requires MFA to login from the MFA users page as shown. Select the user and click Enable:
    image  image
  4. Or, if using Conditional Access, that the Grant option includes MFA as one of the requirements as shown:#
    image
  5. In the first step above you can see that phone calls, text and notification through app are all also enabled. These do not need to be enabled for the hardware device to work.
  6. The user needs an Azure AD P1 or P2 licence to use hardware tokens.

Step 3: The user login experience

When the user logs in or accesses an app that is MFA restricted via Conditional Access they will see the MFA login prompt as shown:

image

The code entered needs to come from their hardware device, as shown below:

image

The token changes every 30 seconds and is valid for a short while either side of the time it is displayed for on the device. Over time tokens will suffer from clock skew and eventually stop working. The new token2 programmable tokens available in Feb 2019 can have their clocks resynced to fix this issue.

As mentioned above, any registered authenticator app or hardware token uploaded against the user will work – the UX asks for an app at present, maybe this wording will get more clarification when the user has a token registered as well.

Step 4: User experience

Apart from the login, the other place where a user will see their token listed is the My account > Security and Privacy option (click your picture in an Office 365 app to see My account menu). If you have MFA enabled for the user (not just Conditional Access) then the user will see “Additional security verification” on the Security & Privacy page. Here is says “Update your phone numbers used for account security” – but this will list your hardware token as well. This is shown below:

image

In the above you can see that the user has an iPhone as well as the token, where the hardware token ID matches the serial number on the device that they hold, as well as a phone in this scenario. This allows the user to have a backup MFA method of more than one authenticator (Microsoft Authenticator on iPhone or MFA by phone call in this case) as well as the Authenticator app or hardware token. Your users can now have up to five devices in any combination of hardware or software based OATH tokens and the Microsoft Authenticator app. This gives them the ability to have backup devices ready when they need them and to use different types of credentials in different environments.

The use of a hardware token and its OAUTH code currently still requires a password before MFA token. Password-less token only is expected later in 2019.

Improving Password Security In the Cloud and On-Premises

Posted on 1 CommentPosted in active directory, Azure Active Directory, Azure AD, AzureAD, EM+S, enterprise mobility + security, microsoft, Office 365, password, security

Passwords are well known to be generally insecure the way users create them. They don’t like “complex” passwords such as p9Y8Li!uk%al and so if they are forced to create a “complex” password due to a policy in say Active Directory, or because their password has expired and they need to generate a new one, they will go for something that is easy to remember and matches the “complexity” rules required by their IT department. This means users will go for passwords such as WorldCup2018! and Summ3r!!. Both these exceed 8 characters, both have mixed case, both have symbols and numbers – so both are complex passwords. Except they are not – they are easy to guess. For example, you can tell the date of this blog post from my suggestions! Users will not tend to pick passwords that are really random and malicious actors know this. So current password guidance from NIST and UK National Cyber Security Centre is to have non-expiring unknown, not simple passwords that are changed on compromise. Non-expiring allows the user to remember it if they need to (though a password manager is better) and as it is unknown beforehand (or unique) means its not on any existing password guess list that might exist.

So how can we ensure that users will choose these passwords! One is end user training, but another just released feature in the Microsoft Cloud is to block common passwords and password lists. This feature is called Azure AD Password Protection. With the password management settings in Azure AD, cloud accounts have been blocked from common passwords for a while (passwords that Microsoft see being used to attempt non-owner access on accounts) but with the password authentication restrictions you can link this to block lists and implement it with password changes that happen on domain controllers.

So how does all this work, and what sort of changes can I expect with my passwords.

Well what to expect can look like this:

image

Note all the below is what I currently know Microsoft do. This is based on info made public in June 2018 and is subject to change as Microsoft’s security graph and machine learning determines change is needed to keep accounts secure.

Password Scoring

First, each password is scored when changed or set by an administrator or a user on first use. A password with a score less than 5 is not allowed. For example:

Spring2018 = [spring] + [2018] = 2 points

Spring2018asdfj236 = [spring] + [2018] + [asdf] + [f] + [j] + [2] + [3] + [6] = 8 points

This shows that common phrases (like Spring and 2018) can be allowed as part of password that also contains stuff that is hard to guess. In this, the asdf pattern is something straight from a Qwerty keyboard and so gets a low score. In addition to the score needing to exceed 5, other complexity rules such as certain characters and length are still required if you enforce those options.

Common and Blocked Lists

Microsoft provide the common password lists, and these change as Microsoft see different passwords getting used in account attacks. You provide a custom blocked list. This can contain up to 1000 words, and Microsoft apply fuzzy logic to yours and the common list. For example we added all our office locations as shown:

image

This means that both capetown and C@p3t0wn would be blocked. The @=a, the 3=e and the 0=o. So the more complex one is really not complex at all as it contains common replacements.

In terms of licences, the banned password list that Microsoft provides is licence free to all cloud accounts. You need AAD Basic if you want to add your own custom banned password list. For accounts in Windows Server Active Directory you need the Azure AD Premium (P1) licence for all synced users to allow downloading of the banned password list as well as customising it with your words so that Active Directory can apply it to all users on-premises to block bad passwords (even those users not synced to AzureAD).

Hybrid Password Change Events Protected

The checks on whether a password change should be stopped is included in hybrid scenarios using self-service password reset, password hash sync, and pass-through authentication, though changes to the custom banned password list may take a few hours to be applied to the list that is downloaded to your domain controllers.

On-Premises Changes

There is an agent that is installed on the domain controllers. Password changes are passed to the agent and it checks the password against the common list and your blocked list. The agent does the password check, and it checks it against the most recently downloaded list from Azure AD. The password for on-premises is not passed up to Azure AD, the list is downloaded from Azure AD and processed locally on the domain controller. This download is done by the Azure AD password protection proxy. The list is then downloaded once per hour per AD site to include the latest changes. If your Azure AD password protection proxy fails, then you just use the last list that was successfully downloaded. Password changes are still allowed even if you lose internet access.

Note that the Azure AD password protection proxy is not the same as the Pass-Through Authentication agent or the AAD Connect Health agent. The Azure AD password protection proxy can though be installed on the same servers as the PTA or Connect Health agent. Provisioning new servers for the proxy download service are not required.

The Azure AD password protection proxy wakes up hourly, checks SYSVOL to see the timestamp of the most recently downloaded copy and decides if a new copy is needed. Therefore if your intra-site replication is within the hour, proxy agents in other sites might not need to download the list as the latest is already available via DFSR between the domain controllers.

The Azure AD password protection proxy does not need to run on a domain controller, so your domain controllers do not need internet access to obtain the latest list. The Azure AD password protection proxy downloads the list and places it in SYSVOL so that DFSR replication can take it to the domain controller that needs it.

Getting Started

To set a custom password block list, in the Azure Portal visit the Azure AD page, click Security and then click Authentication Methods (in the Manage section). Enter your banned passwords, lower case will do as Microsoft apply fuzzy logic as described above to match your list to similar other values. Your list should include common words to your organization, such as location, office address keywords, functions and features of what the company does etc.

For Active Directory, download the agent (from the Microsoft Download Center) to one or more servers (for fault tolerance). These will download the latest list and place it in SYSVOL so that the domain controllers can process it. Two servers in two sites would probably ensure one of them is always able to download the latest copy of the list.

The documentation is found at https://aka.ms/deploypasswordprotection.

Microsoft suggests that any deployment start in audit mode. Audit mode is the default initial setting where passwords can continue to be set even if they would be blocked. Those that would fail in Enforce mode are allowed in Audit mode, but when in audit mode entries in the event log record the fact that the password would fail if enforce was turned on. Once proxy server(s) and DC agents are fully deployed in audit mode, regular monitoring should be done in order to determine what impact password policy enforcement would have on users and the environment if the policy was enforced.

This audit mode allows you to update in-house policy, extend training programs and offer password advice and see what users are doing that would be considered weak. Once you are happy that users are able to respond to an password change error because the password is too weak, move to enforce mode. Enforce mode should kick in within a few hours of you changing it in the cloud.

Installing the Proxy and DC Agent

Domain Controllers need to be running Windows Server 2012 and later, though there are no requirements for specific domain or forest functional levels. Visit the Microsoft Download Center to download both the agent and the password protection proxy. The proxy is installed and then configured on a few (two at most during preview) servers in a forest. The agent is installed on all domain controllers as password changes can be enacted on any of them.

To install the agent, run AzureADPasswordProtectionProxy.msi on the server that has internet connectivity to Azure AD. This could be your domain controller, but it would need internet access to do this.

To configure the agent, you need to run once Import-Module AzureADPasswordProtection followed by Register-AzureADPasswordProtectionProxy and then once the proxy is registered, register the forest as well with Register-AzureADPasswordProtectionForest all from an administrative PowerShell session (enterprise admin and global admin roles required). Registering the server adds information to the Active Directory domain partition about the server and port the proxy servers can be found at and registering the forest settings ensure that information about the service is stored in the configuration partition.

Import-Module AzureADPasswordProtection 
Get-Service AzureADPasswordProtectionProxy | FL
$tenantAdminCreds = Get-Credential
Register-AzureADPasswordProtectionProxy -AzureCredential $tenantAdminCreds
Register-AzureADPasswordProtectionForest -AzureCredential $tenantAdminCreds

If you get an error that reads “InvalidOperation: (:) [Register-AzureADPasswordProtectionProxy], AggregateException” then this is because your AzureAD requires MFA for device join. The proxy does not support MFA for device join during the preview – you need to disable this setting in Azure AD for the period covering the time you make these changes – you can turn it back on again (as on is recommended) once you are finished configuring your proxy servers. This setting is found at:

  • Navigate to Azure Active Directory -> Devices -> Device settings
  • Set “Require Multi-Factor Auth to join devices” to “No”
  • As shown
    image
  • Then once the registration of your two proxies is complete, reverse this change and turn it back on again.

Once at least one proxy is installed, you can install the agent on your domain controllers. This is the AzureADPasswordProtectionDCAgent.msi and once installed requires a restart of the server to take its role within the password change process.

The PowerShell cmdlet Get-AzureADPasswordProtectionDCAgent will report the state of the DCAgent and the date/time stamp of the last downloaded password block list that the agent knows about.

image

Changes In Forest

Once the domain controller the agent is installed on is rebooted, it comes back online, finds the server(s) running the proxy application and asks it to download the latest password block list. The proxy downloads this to C:\Windows\SYSVOL\domain\Policies\{4A9AB66B-4365-4C2A-996C-58ED9927332D}. Within this locations I see the AzureADPasswordProtection folder, containing three subfolders called Azure (empty), Configuration (initially empty) and PasswordPolicies (also initially empty).

In the Configuration partition at CN=Azure AD Password Protection,CN=Services,CN=Configuration,DC=domain,DC=com some settings about the service are persisted. If the domain controller has the agent installed then

CN=AzureADConnectPasswordPolicyDCAgent,CN=<DomainControllerName>,OU=Domain Controllers,DC=domain,DC=com is created.

And then on each domain controller, in the Event Viewer, you get Application and Services Logs > Microsoft > AzureADPasswordProxy with DCAgent on the DC’s and ProxyService on the proxy servers. The following EventID’s have been seen:

  • DCAgent/30016: Forest registration has not happened yet
  • DCAgent/30001: The password for the specified user was accepted because an Azure password policy is not available yet.
  • DCAgent/30009: [audit mode] The password reset was allowed, but would have been rejected as the password used was on Microsoft’s block list
  • DCAgent/10014: Password compliant with the current Azure password policy
  • DCAgent/10015: The reset password for the specified user was validated as compliant with the current Azure password policy.
  • DCAgent/10017: Password reset rejected because it did not comply with the current Azure password policy
  • DCAgent/30016: The service is now enforcing the following Azure password policy along with the date/time stamp of the policy file it is using. This entry will state if audit or enforce mode is in play as well.

 

  • ProxyService/30000: A proxy registration message was sent to Azure and a successful response was received.
  • ProxyService/30001: A new proxy certificate credential was successfully persisted.
  • ProxyService/20000: A new password block list was downloaded.

Further log IDs and meanings can be found at https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-password-ban-bad-on-premises-troubleshoot

Once the proxy starts to work, the above empty folders begin to populate. In my case in the preview it took over 2 hours from installing the proxy as well as the documented installation and configuration PowerShell cmdlets listed above to get the proxy to download anything. The above listed Configuration folder contained some cfge files and the above listed PasswordPolicies contains what I assume is the downloaded password block list, compressed as its only 12KB. This is the .ppe file and there is one of these per hour downloaded. Older versions of this download are deleted by the proxy service automatically.

Audit Mode

Using the above Event ID’s you can track the users who have changed to weak passwords (in that they are on your or Microsoft’s banned password list) when the user or admin sets (or resets) the users password. Audit mode does not stop the user choosing the password that would “normally have been rejected” but will record different Event IDs depending upon the activity and which block list it would have failed against. Event id DCAgent/30009 for example has the message “The reset password for the specified user would normally have been rejected because it matches at least one of the tokens present in the Microsoft global banned password list of the current Azure password policy. The current Azure password policy is configured for audit-only mode so the password was accepted.”. This message is a failure against Microsoft’s list on password set. The user doing a password change and the Microsoft list gets DCAgent/30010 Event ID recorded instead.

Using these two Event ID’s along with DCAgent/30007 (logged when password set but fails your custom list) and or DCAgent/30008 (password changed, fails your custom list) allows you to audit the impact of the new policy before you enforce it.

Enforce Mode

This mode ensures that password set or change events cannot have passwords that would fail the list policies. This is enabled in the password policy in Azure AD as shown:

image

Once this is enabled it takes a few hours to be picked up by the proxy servers and then for the agent to start rejecting banned passwords.

When a user changes their password in enforce mode they get the following error (different graphic depending upon Windows versions). If the admin changing the password uses a blocked password then they see the left hand graphic as well (Active Directory Users and Computers).

image or image

This is no different to the old error you get when your password complexity, length or history is not met. Therefore there is no indication to the user that the password they chose might be banned rather than not allowed for the given reasons. So though password policy with a banned list is an excellent step forward, there needs to be help desk and end user awareness and communications (even if they are just a simple notification) as the user would not be able to tell from the client error they get. Maybe Microsoft have plans to update the client error?

Password changes that fail once enforce mode is enabled get Event ID’s such as DCAgent/30002, DCAgent/30003, DCAgent/30004 and DCAgent/30005 depending upon which password list the fail happened against and the method of password set or change. For example when I used the password Oxford123, as “oxford” is in the custom banned password list, Event ID 30003 returns “The reset password for the specified user was rejected because it matched at least one of the tokens present in the per-tenant banned password list of the current Azure password policy”. As mentioned above, the sequence of 123 following the banned word is not enough to make to score more than 5 points and so the password change is rejected.

On the other hand, 0xf0rdEng1and! was allowed as England was not on my banned list an so although my new password contained a banned word, there were enough other components of the password to make it secure enough. Based on the above mentioned scoring of 5 or more is required to have a password accepted, [Oxford] + [E] + [n] + [g] + [1] + [a] + [n] + [d] + [!], a total of 9. 9 >= 5 and so the password is accepted.

Finally, when testing users, other password policies like the date that the password can next be changed and “user cannot change password” property etc. will take effect over the banned password list. For example, if you have a cannot change password for 5 days setting, and you set the users password as an administrator – that will work or fail based on the password you enter, but if you change the password as the user within that time period, that will fail as five days have not gone by and not because the user picked a guessable password.

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)

OWA and Conditional Access: Inconsistent Error Reports

Posted on 1 CommentPosted in AzureAD, conditional access, EM+S, enterprise mobility + security, exchange, exchange online, Exchange Online Protection, IAmMEC, Outlook

Here is a good error message. Its good, because I could not find any references to it on Google and the fault was nothing to do with the error message:

image

The error says “something went wrong” and “Ref A: a long string of Hex Ref B: AMSEDGE0319 Ref C: Date Time”. The server name in Ref B will change as well. It also says “more details” and if you click that there are no more details, but that text changes to “fewer details”. As far as I have seen, this only appears on Outlook Web Access (OWA).

The error appears under these conditions:

  1. You are enabled for Enterprise Mobility + Security licences in Azure AD
  2. Conditional Access rules are enabled
  3. The device you are on, or the location you are at etc (see the specifics of the conditional access rule) mean that you are outside the conditions allowed to access Outlook Web Access
  4. You browsed directly to https://outlook.office.com or https://outlook.office365.com

What you see in the error message is OWA’s way of telling you that you cannot get to that site from where you are. That you have failed the conditional access tests.

On the other hand, if you visit the Office 365 portal or MyApps (https://portal.office.com or https://myapps.microsoft.com) and click the Mail icon in your Office 365 menu or on the portal homepage then you get a page that says (in the language of your browser):

image or in Welsh, image

This says “you can’t get there from here” and the reasons why you have failed conditional access.

If you were on a device or location that allowed you to connect (such as a device managed by Intune and compliant with Intune rules) then going to OWA directly will work, as will going via the menu.

So how can you avoid this odd error message for your users. For this, you need to replace outlook.office.com with your own custom URL. For OWA you can create a DNS CNAME in your domain for (lets say) webmail that points to outlook.office365.com (for this it will not work if you point the CNAME to outlook.office.com). Your users can now go to webmail.yourdomain.com. This will redirect the user via Azure AD for login and token generation, and as you are redirected via Azure AD you will always see the proper, language relevant, conditional access page.