Register For Azure AD MFA From On-Premises Or Known Networks Only

Posted on 4 CommentsPosted in Azure Active Directory, Azure AD, conditional access, enterprise mobility + security, Office 365, security, self-service password reset, sspr

A long request within Azure AD/Office 365 has been the request to be able to register your security info from a known location or only on certain other conditions. Well it looks like this has appeared in Azure AD in the last few days!!

Its visible under Azure AD > Conditional Access > New/Existing Policy > Cloud Apps or Actions:

image

So, what does this look like in practice? Lets put this preview to the test.

Create the Conditional Access Policy for User Actions

Open the Azure AD portal at https://aad.portal.azure.com and click Enterprise Applications

From here click Conditional Access (this is also accessible under Azure AD > Security as well)

Click Add Policy and give the policy a name. I have chosen “Register Security Information On-Premises” for here

Click Users and Groups. I have selected “Users and Groups” rather than “All Users” as I plan to test this out first! I have picked the group that I use for testing Conditional Access changes. Eventually I will change this to All Users so that no-one can register security info apart from when on a trusted location. Note that this would also I think include guest users – I need to test that! Guest users are by their very nature not on my network but I might have MFA required for them – so they need to register, but I don’t want to apply the below to them

image

Select Cloud Apps or Actions (this was recently renamed to support this functionality we are describing here)

Select User Actions in the slider and check the option for Register Security Information (Preview)

Select Conditions and select the conditions you want to apply when users are registering security information. Its probably location based, so I will set that up here.

Select Locations, click Yes under Configure and select Any Location under Include and then under Exclude select Trusted Locations. Note that you need to have set up trusted locations in Conditional Access as well – I’m going to assume the public IP of all your offices is added and marked as trusted.

This setting will ensure that all locations other than trusted locations cannot register security information – note that this is the reverse of what you might expect. We need to block the locations we don’t want to access the MFA/SSPR registration process rather than the reverse. This is because we are required to add a control to the rules

image

With Azure AD P2 licences you could user a sign-in risk condition, ensuring that registration does not happen on medium or high risk sign-ins!

Click Done to bring you back to the first blade of settings and set Enable Policy to On to turn on this feature

Under Access Controls, click Grant and choose Block Access – be very careful here – don’t block all your access to everything!

image

Click Done

This takes us back to the first blade in the Conditional Access settings.

Click On in the Enable Policy slider

Now the Create button is available – this is not available if you do not create the reverse of what you might expect to do – block unknown locations rather than allow trusted locations!

image

Click Create

You will get your notification – you can test this in a few minutes:

image

Enable The New Combined MFA/SSPR Registration Page

Though I noticed that this conditional access restriction works against the older MFA registration page, Microsoft have said in their release blog article for this feature that it will only work against the new MFA/SSPR combined registration page. Therefore you should turn this on for your users impacted by the above policy – initially for your pilot users and then for all users.

See https://techcommunity.microsoft.com/t5/Azure-Active-Directory-Identity/Cool-enhancements-to-the-Azure-AD-combined-MFA-and-password/ba-p/354271 for more on setting up the combined MFA/SSPR registration page.

Testing Register Security Information (Preview)

In an in-private browser session on the Wi-Fi of your favourite coffee company, browse to https://aka.ms/mfasetup (as this is not a trusted location!)

After logging in you would expect to be take to the registration page for MFA and SSPR – but you are not!

image

Repeat your test from on-premises, and you will get the MFA and SSPR registration pages (or both if you have the new combined MFA+SSPR wizard enabled):

Note that for a brand new user where you have SSPR enabled, they are required to register by default every 180 days. This will mean they have to register at first login – therefore first login needs to be from a trusted network (in this example) – you could use Trusted Device as the only place to register from, but adding a user to a trusted device requires MFA by default, so watch out for an issue here and if you want to do this, test it very well.

I have not had the opportunity to test this with the 180 day refresh of your settings – presumably that should work from any location and only changing them would be blocked, but this is something that needs to be tried out.

Read Only And Document Download Restrictions in SharePoint Online

Posted on Leave a commentPosted in AADConnect, AADSync, active directory, Azure Active Directory, Azure AD, compliance, conditional access, device, download, enterprise mobility + security, exchange online, microsoft, Office 365, OneDrive, OneDrive For Business, sharepoint, Uncategorized

Read Only And Document Download Restrictions in SharePoint Online

Both SharePoint Online (including OneDrive for Business) and Exchange Online allow a read only mode to be implemented based on certain user or device or network conditions.

For these settings in Exchange Online see my other post at https://c7solutions.com/2018/12/read-only-and-attachment-download-restrictions-in-exchange-online.

When this is enabled documents can be viewed in the browser only and not downloaded. So how to do this.

Step 1: Create a Conditional Access Policy in Azure AD

You need an Azure AD Premium P1 licence for this feature.

Here I created a policy that applied to one user and no other policy settings. This would mean this user is always in ReadOnly mode.

In real world scenarios you would more likely create a policy that applied to a group and not individual users and forced ReadOnly only when other conditions such as non-compliant device (i.e. home computer) where in use. The steps for this are:

imageimageimageimage

The pictures, as you cannot create the policies in the cmdline, are as follows:

  1. New policy with a name. Here it is “Limited View for ZacharyP”
  2. Under “Users and Groups” I selected my one test user. Here you are more likely to pick the users for whom data leakage is an issue
  3. Under “Cloud apps” select Office 365 SharePoint Online. I have also selected Exchange Online, as the same idea exists in that service as well
  4. Under Session, and this is the important one, select “Use app enforced restrictions”.

SharePoint Online will then implement read only viewing for all users that fall into this policy you have just created.

Step 3: View the results

Ensure the user is licensed for SharePoint Online (and a mailbox if you are testing Exchange Online) and an Azure AD Premium P1 licence and ensure there is a document library with documents in it for testing!

Login as the user under the conditions you have set in the policy (in my example, the conditions where for the specific user only, but you could do network or device conditions as well.

SharePoint and OneDrive Wizard Driven Setup

For reference, in the SharePoint Admin Centre and Policies > Access Control > Unmanaged Devices, here you turn on “Allow limited web-only access” or “Block access” to do the above process of creating the conditional access rule for you, but with pre-canned conditions:

image

In the classic SharePoint Admin Center it is found under that Access Control menu, and in SharePoint PowerShell use Set-SPOTenant -ConditionalAccessPolicy AllowLimitedAccess

Turning the settings on in SharePoint creates the Conditional Access policies for you, so for my demo I disabled those as the one I made for had different conditions and included SharePoint as well as a service. This is as shown for SharePoint – the banner is across the top and the Download link on the ribbon is missing:

image

And for OneDrive, which is automatic when you turn it on for SharePoint:

image

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.

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.