My colleague Mike Parker has a great new series of posts up on securing Exchange Server 2016 with Azure AD. This option may seem counter-intuitive at a glance, but given that most organisations are on a trajectory from Exchange Server to Exchange Online, this configuration can consolidate access control for e-mail in a single location (for instance, over the duration of a migration or for long-term co-existence). It also means that Azure AD Conditional Access policies can be used for Exchange resources on and off-premises, which improves security while enabling mobility.
This configuration has two parts:
- Get most Exchange Server components to use OAuth 2.0. This is known as Hybrid Modern Authentication.
- Publish Outlook Web App (OWA) and the Exchange Control Panel (ECP) using the Azure AD Application Proxy.
The second step is necessary because these components are not currently supported for Hybrid Modern Authentication. The major pre-requisite for publishing an application with the Azure AD Application Proxy is that it should be authenticated with Kerberos and the Application Proxy Connector machine accounts need to be configured to use Constrained Delegation (KCD) for the OWA and ECP Service Principal Name (SPN). Mike’s article takes you through all of this step-by-step. My post deviates a bit from Mike’s guide to consider the idiosyncrasies of the Exchange Alternative Service Account Credential (ASA), which has underpinned Kerberos in Exchange Server since 2010 SP1. If you are familiar with configuring Kerberos, the ASA will almost certainly hold some surprises. Maybe even a fourth head.
Continue reading “Forget what you know about Kerberos before configuring Exchange Server to use Kerberos”
If you have a Microsoft Account (Live ID) username or alias that matches your Work or School Account (Azure AD) UPN, you will probably see a Home Realm Discovery prompt with annoying regularity. This is natural, and expected behaviour, but Microsoft has been taking steps to improve this experience, as detailed in their Cleaning up the #AzureAD and Microsoft account overlap article. Unsure if this is relevant to you? It is if you see this:
Interestingly, there is also now a link in some of these dialogue boxes which will prompt a user to resolve the issue by changing their conflicting Microsoft account username to some new alias. That prompt links to this support article. The basics of that process are:
- Add new alias
- Verify alias
- Make new alias primary
- Remove old alias
However, when I tried to make my new alias primary, the option was missing. I could only remove it. If I tried to remove the primary alias I was told to make the other alias primary first. Stuck! My colleague had five non-primary aliases, and just one of them was also missing this option. We tried a few things like signing on with the alias to see if that made a difference, but the option never appeared. Then, after a helpful suggestion from Oren Novotny I tried removing and adding the alias to see if that changed anything. Then, I couldn’t add it back at all. I would get this, “You can’t add a work or school/university email address as an alias to a personal Microsoft account. Please try another”, error:
This is precisely the restriction that Microsoft has put in place to prevent unnecessary Home Realm Discovery prompts, but we are unexpectedly seeing it when adding an alias. After a bit of testing, it appears that the restriction is scoped at the Azure AD Registered Domain Name. Organisations may register domain names with Azure AD either to prove ownership of a domain name for account creation, or for e-mail addresses/aliases. In my case (and my colleague’s), we added aliases to our Microsoft Accounts from registered domain names before Microsoft put this registered domain name restriction in place and we were trying to make these e-mail aliases our new primary Microsoft Account username after the restriction was introduced. The secondary issue here is that we hadn’t expected this restriction to take effect if the new alias didn’t in fact exist as an Azure AD username.
So… this all kind of makes sense once we put the pieces together, although it would be good if the Microsoft Account Manage How You Sign In to Microsoft page offered an explanation of why the alias cannot be made primary. This probably seems like the obscurest of issues, but I suspect many people will encounter it, since Microsoft are encouraging us to make a non-conflicting alias primary. The ultimate solution to this problem will require creation of a new alias in a namespace that hasn’t been registered with Azure AD.
Microsoft and other large software vendors often fall foul of criticisms that products overlap significantly, or that discreet functionality in one product has been written afresh when the facility is already mature in another technology. As I’ve grown to know it better, I think Microsoft’s Forefront Identity Manager (FIM) provides some interesting examples of the benefits and drawbacks of product re-use. I put these thoughts out as a set of considerations to counter the view that reuse is always a positive thing.
Note: I wrote this article a long time ago, and have always been on the fence about posting it because it’s an editorial rather than purely technical content. I’m not 100% certain this is the right place for this content, but I am publishing it here now rather than letting it rot. Because this was written a long time ago, some references are dated. Like this doesn’t speak of MIM, AADSync or AAD Connect in any detail, so put that knowledge to one side for now.
Continue reading “Product reuse at Microsoft as seen through a FIM lens”