The purpose of this post is to describe a work-around to permit Veeam Backup for Microsoft Office 365 (VBO) – or any other apps which require it – to continue to use Legacy Authentication from a designated, trusted location, while forcing all other accounts to use Modern Authentication.

Licensing Note: We will accomplish this using Azure AD Conditional Access (CA) policies.

CA policies require Azure AD Premium P1 or Azure AD Premium P2 licenses within your tenant, for your users.  Azure AD P1 and P2 are included in the Microsoft Enterprise Mobility + Security E3 (P1) and EMS E5 (P2) licenses, as well as Microsoft 365 E3 (P1) and Microsoft 365 E5 (P2) licenses.  Azure AD P1 or P2 are *not* included in Microsoft 365 Business.

Background

A few months ago, Veeam released Version 3 of its backup solution for Office 365 – Veeam Backup for Office 365 (a.k.a. “VBO”).  The long anticipated feature was VBO V3’s ability to make use of Modern Authentication within Azure Active Directory (Azure AD).  In theory, this would allow Legacy Authentication to be disabled and make it more secure.

Apparently, Veeam Backup for Office 365 still requires Legacy Authentication to be enabled in order to backup parts of SharePoint Online (SPO) as Microsoft has not provided (as of this writing) Modern Authentication capable API endpoints to do so.

Modern Authentication

Modern Authentication in Azure AD enables your Azure AD tenant to utilize features like Multi-Factor Authentication (MFA) for client applications which support it.  It accomplishes this by presenting the client application with an OAuth Token it can use (and reuse) to access your Office 365 online application resources (e.g. Exchange Online).

If you have MFA enabled and have signed into Outlook 365 (2016+) on a desktop, or setup Outlook for Mobile, or even Apple Mail for iOS 11 (or later), you may have noticed the sign-in credentials prompt appears to be a web page presented within the application you are using.  This is because it actually *is* a web page, served up by Azure AD and Microsoft Online Services as you would see when you login with a browser.  This is done to support Azure AD MFA.

Legacy Authentication

Leaving Legacy Authentication enabled is a security risk because it allows users who have enabled ‘app passwords‘ to bypass the MFA requirement while authenticating.  This exposes these accounts to potential unauthorized access.

While going through a security review on an Azure AD tenant, one of the recommended actions was to enable the new, Microsoft-provided Conditional Access policy named ‘Baseline policy: Block legacy authentication (Preview)‘.

The purpose of this policy is to prevent/block legacy authentication sign-ins to Azure AD.  Examples are older versions of Outlook and other Office applications, as well as older mobile clients (e.g. the Mail app on iOS devices before iOS 11).

The problem with this baseline policy is it affects everyone within your Azure AD tenant, including the VBO backup account.  This would prevent VBO from fully backing up all of the meta data for SharePoint Online and other services.

Disable or Prevent Legacy Auth?

There are ways to Disable Legacy Authentication, they include changing access control settings within the SharePoint Admin portal, or PowerShell commands executed against your Azure AD tenant, but disabling Legacy Auth altogether would prevent VBO from properly and fully carrying out its job.

What if instead we Prevent (block) Legacy Auth for all user accounts *except* the VBO account (as it still requires it)?

The Solution

Instead of enabling the default baseline Conditional Access policy to block all users from being able to perform Legacy Authentication against an Azure AD tenant, let’s setup two (2) new CA policies to prevent all accounts except the VBO account from being able to perform Legacy Auth.

Before we create a any CA policies, if you have not already done so, we must define a Named Location to identify the authentication requests coming from the VBO account and handle them differently from the rest.

Named Locations

In order to identify legitimate sign-in requests coming from your VBO server(s), we must create a Named Location within Conditional Access.

Step 1 – Within the Azure Portal, navigate to Azure Active Directory, then click on Conditional Access, and then click on Named locations.

Step 2 – Click on + New location

Step 3 – Give your location a name, select IP ranges and enter one or more IP ranges for your Veeam Backup for Microsoft Office 365 (VBO) server(s).

Note: the IP ranges are entered in CIDR notation.  For a single IP address, enter it with a trailing "/32" as in: 192.168.101.22/32.  Do *not* use a private IP address; the above is just an example.  Use a public IP address.

At this point, you have a Named Location you can use within a Conditional Access Policy’s location condition.  We will do this next.

Restrict the VBO Account

In order to restrict the VBO (or some other application’s) account to only be permitted to sign-in from a particular location, we need to create a Conditional Access policy to by default, Block access for this user account, except when signing in from the Named Location we created in the previous section.

Warning and Disclaimer: Conditional Access Policies can completely lock you and your organization out of Azure and Office 365.  Neither I nor this site can be held responsible for your, your organization's, or any third-party's actions.

Take extreme care when creating Conditional Access Policies within Azure AD by ensuring to EXCLUDE at least one Global Administrator within your tenant within each policy you create or modify until you are certain the policy will not lock out other administrators or unintended end-users.

Step 1 – Within the Azure Portal, navigate to Azure Active Directory, then click on Conditional Access, and then click on Policies.

Step 2 – Click on + New policy

Step 3 – Provide a name for your policy as I did here.

Step 4 – Under ‘Assignments’ click on Users and groups, under the ‘Include’ tab, click on Select users and groups and check the Users and groups check box.

Step 5 – Click on Select as shown by the red arrow in the next screen shot, search for your Veeam VBO Backup Account and add it to the list.  Click Done.

Step 6 – Under ‘Assignments’ click on Conditions, then click on Locations, and click to enable this condition by clicking on Yes under ‘Configure’ as seen in the next screen shot.

Step 7 – Under the ‘Include’ tab, ensure Any location is selected.

Step 8 – Click on the ‘Exclude’ tab and select the Selected locations option.  Click on Select and pick the Named Location we created in the previous section for your VBO server(s).  Click on Done.  Click Done again.

Step 9 – Important: As per the highlight two screen shots back, under ‘Access controls’ click on Grant and select Block access, then click Done.

Step 10 – Under ‘Enable policy’ select On to enable it and click Done.

You are done setting up the new policy to restrict your VBO backup account to only sign-in from a specific location.  Next, let’s block Legacy Authentication for all other user accounts within the Azure AD tenant.

Prevent/Block Legacy Authentication

We are not finished just yet.  Let’s accomplish the end goal – Preventing Legacy Authentication for all other user accounts within Azure AD.  We will need to create another new CA policy for this.

Step 1 – Once again, within the Azure Portal, navigate to Azure Active Directory, then click on Conditional Access, and then click on Policies.

Step 2 – Click on + New policy

Step 3 – Provide a descriptive name for your policy as I did here (e.g. Block Legacy Authentication Clients).

Step 4 – Under ‘Assignments’ click on Users and groups, under the ‘Include’ tab, click on All users.

Step 5 – Click on the ‘Exclude’ tab and choose Users and groups, then click on Select excluded users and add your Veeam Backup account along with at least one Azure Global Administrator until you confirm all is good after testing.  Click Done to close the panel.

Step 6 – Under ‘Assignments’ click on Conditions, then click on Client apps.  Start by selecting Yes under ‘Configure’ to enable this section.

Step 7 – Place a checkbox next to only the following two options (as seen in the next screen shot): Mobile apps and desktop clients as well as Other clients.  Now click Done and click Done once again to return to the policy panel.

Step 8 – As per the highlight on the previous screen shot, under ‘Access controls’ click on Grant and select Block access, then click Done.

Step 9 – Under ‘Enable policy’ select On to enable it and click Done.

We have finished creating policies.  Now we have to confirm and test them.

Confirm

Use the What If tool in Azure AD to test the Conditional Access policies we created.  This will allow you to ‘mock’ test based on settings such as User, IP address, etc. whether the rules we created permit or block access to users.

Also, you would want to test everything out for yourself and your end users, as well as the VBO backup account immediately or by waiting for its next scheduled backup interval.

Troubleshooting

If you run into trouble, make sure your Veeam VBO Backup account is *not* included in some other policy within Conditional Access, as this might be preventing it from authenticating as expected.  Use the What If tool mentioned in the previous section.  Worst case, disable the policies we just created and retest.

Conclusion

I just showed you how to better secure your Microsoft Azure AD tenant by preventing Legacy Authentication from taking place for all user accounts except the Veeam Backup for Microsoft Office 365 (VBO) user account, while restricting the VBO user account to only sign-in from a trusted IP address location.

The post Prevent Legacy Auth in Azure AD while satisfying Veeam VBO 365 and other apps appeared first on Darius Liktorius.

I would like to thank all of the attendees and the volunteers who made this year’s event amazing!

Check out my session’s presentation on SQL Server in the Cloud

The post Presentation at SQL Saturday #864 South Florida appeared first on Darius Liktorius.

Microsoft states the following in their documentation:

The UserType has no relation to how the user signs in, the directory role of the user, and so on. This property simply indicates the user's relationship to the host organization and allows the organization to enforce policies that depend on this property.

The same documentation goes on to state:

There may be cases where you want to give your guest users higher privileges. You can add a guest user to any role and even remove the default guest user restrictions in the directory to give a user the same privileges as members.

It's possible to turn off the default limitations so that a guest user in the company directory has the same permissions as a member user.

So they actually are different…  What if you do not want to turn off the default limitations for all guest users, but one or more external user(s) need elevated access to manage your entire Azure Directory?  For example, you are working with a consulting firm like NetCorp, and you need their team to have administrative access into your Azure AD Tenant.

How about adding the External User as a Member instead of a Guest?

This is accomplished through PowerShell using the New-AzureADMSInvitation function.  This used to be possible to do through the Portal, though it appears the feature was taken away.

The following is an example of what the call would look like:

New-AzureADMSInvitation -InvitedUserEmailAddress "someuser@someothertenant.onmicrosoft.com" -InviteRedirectUrl "https://www.yourdomain.com" -SendInvitationMessage $false -InvitedUserType "Member"

It’s important to address some of the parameters used in the above example.

First, the InvitedUserType parameter is set to “Member” to override the default value of Guest.

Second, a user will have to accept the invitation by accessing a redemption URL while logged in as the invited user.  By default, this invitation will arrive via email.  An edge case caveat here would be if the invited user does not have a mailbox associated with the given Azure AD User’s login.  The SendInvitationMessage parameter controls whether an email invitation is sent.  In our example above, we are turning off this functionality.

Third, the InviteRedirectUrl parameter is required, but can be a ‘bum’ URL – so long as the invited user knows this.  Otherwise, it is best to redirect the user to your organization’s website homepage, or maybe the Azure Portal (e.g. https://portal.azure.com).

The resulting output is as follows.  Please note, if you set SendInvitationMessage to $false, you must take note of the value in the InviteRedeemUrl and provide it to the invited user.  Preferably, with instructions on how to access it (while logged in as themselves).

Id                      : ********-****-****-****-************
InvitedUserDisplayName  : John Doe
InvitedUserEmailAddress : someuser@someothertenant.onmicrosoft.com
SendInvitationMessage   : False

InviteRedeemUrl         : https://invitations.microsoft.com/redeem/?tenant=********-****-****-****-************&user=**********-****-****-***********&ticket=Omgm11231YaPSYkw5Yz21jj1010mnzsd0wP25%2f23aqSQ9u%2bZfTRM%3d&ver=2.0

InviteRedirectUrl       : https://www.yourdomain.com
InvitedUser             : class User {
                            Id: *********-****-****-****-**********
                            OdataType:
                          }
InvitedUserType         : Member
Status                  : PendingAcceptance

I hope this was as helpful to you as it was for the customer I was serving today.

The post Add a User as a Member from a different Azure AD Tenant appeared first on Darius Liktorius.

I would like to thank all of the numerous attendees and the volunteers who made this year’s event a success!

Check out my session’s presentation on Microsoft Azure vs Amazon Web Services (AWS).

The post Presentation at South Florida Code Camp 2019 appeared first on Darius Liktorius.

An Internet domain name with a hyphen (minus symbol) in it.  Let’s call is domain-name.com.

When you setup DKIM for Office 365, the DKIM ‘selector’ entries you have to create within your domain’s DNS zone are of type CNAME, and they refer to custom entries, hosted by Microsoft for your Office 365 tenant.

An example of this is as follows, per Microsoft:

Host name: selector1._domainkey
Points to address or value: selector1-<domainGUID>._domainkey.<initialDomain> 
TTL: 3600

Host name: selector2._domainkey
Points to address or value: selector2-<domainGUID>._domainkey.<initialDomain> 
TTL: 3600

Where:

• For Office 365, the selectors will always be “selector1” or “selector2”.
• domainGUID is the same as the domainGUID in the customized MX record for your custom domain that appears before mail.protection.outlook.com. For example, in the following MX record for the domain contoso.com, the domainGUID is contoso-com:

contoso.com. 3600 IN MX 5 contoso-com.mail.protection.outlook.com

• initialDomain is the domain that you used when you signed up for Office 365. Initial domains always end in onmicrosoft.com. For information about determining your initial domain, see Domains FAQ.

Note: The domain name portion (<domainGUID>) of the Fully Qualified Domain Name (FQDN) of contoso.com which is contoso and its Top Level Domain (TLD), .com are not separated as expected with a period in the ‘target’ value of the CNAME records.

Instead, they are separated with a hyphen (minus symbol) as in: contoso-com

So if the delimiter between your domain name and TLD is a hyphen, what happens if your domain itself contains a hyphen (e.g. domain-name.com)?

This is where the trouble comes, but how do you resolve it?

Once you have added your domain name within the Office 365 Admin Portal, under Setup > Domains, and you click on the domain name, take a look at the expected DNS record entries.  Under the proposed MX (mail exchange) record for your domain name, you may be surprised to see extra characters after your domain name, such as “0c” and the original hyphen from your domain name (domain-name.com) completely removed:

domain-name.com. 3600 IN MX 5 domainname-com0c.mail.protection.outlook.com

This subtle change is key to a successful DKIM setup for a domain with a hyphen in its name.

So then we know your DKIM selector CNAME entry target values should read as follows:

selector1-domainname-com0c._domainkey.domainname.onmicrosoft.com

selector2-domainname-com0c._domainkey.domainname.onmicrosoft.com

There you have it!

If this was helpful to you, please share it by Tweeting about your newfound discovery!

The post Office 365, DKIM, and a naughty domain name appeared first on Darius Liktorius.

Within the Exchange Admin Center (EAC), under protection > dkim, for each domain, the Enable option was completely missing.

It was a long shot, but I tried enabling it using PowerShell for Exchange Online with the New-DkimSigningConfig command for each domain as follows:

New-DkimSigningConfig -DomainName contoso.com -Enabled $true

ref: Microsoft Docs

Here is what the output looks like upon successfully calling New-DkimSigningConfig:

PS C:\Users\contosoadmin> New-DkimSigningConfig -DomainName mydomain.com -Enabled $true
WARNING: The config was created but can't be enabled because the CNAME records
aren't published. Publish the following two CNAME records, and then enable the
config by using Set-DkimSigningConfig.
selector1-mydomain-com._domainkey.myO365org.onmicrosoft.com
selector2-mydomain-com._domainkey.myO365org.onmicrosoft.com

Domain        Enabled
------        -------
mydomain.com  False

Then, back within the Exchange Admin Center (EAC), under protection > dkim, I can now select the domain I just created a new DKIM Signing Config for, and click to Enable it as seen in the following screen shot.

Before you can Enable it though, you have to add the expected CNAME records to DNS.  I have a separate post covering the required DNS additions.

Thankfully, this worked, and now next to each domain within EAC, DKIM shows as enabled, and presents the expected options “Disable” and “Rotate” (to rotate the DKIM key):

If this post was helpful to you, please Tweet and share it with others.

The post Where oh where did my DKIM go? appeared first on Darius Liktorius.