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”
AD FS 2012 R2 ships with the InsideCorporateNetwork Claim. It evaluates to “True” when a request is received directly at AD FS, or “False”, if a request is received at the WAP. This Claim doesn’t exist in AD FS 2.0/2.1, and it’s fair to say this is one of the more poorly understood differences in behaviour across the versions.
I’ve recently been asked to find out if it’s possible to create an InsideCorporateNetwork Claim in AD FS 2.0/2.1. The benefit of creating it for the older versions is that InsideCorporateNetwork would be usable in exactly the same way that we use it in AD FS 2012 R2 and later, which opens up the following options: Continue reading “Creating an InsideCorporateNetwork Claim for AD FS 2.x”
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.
Over the last couple of years we’ve started doing less AD FS work, with the advent of Password Hash Sync for Azure AD sign-on, and Microsoft’s continued investment in Azure AD Premium. We’ve also seen a few organisations struggle to operate AD FS successfully, even if I personally like the technology. So I’ve changed our approach to unveil all of this with as much realism as possible, and to draw some feature comparisons in both directions. We also spend a lot of time talking about expectations of SSO, and how the ways we think about SSO on the web aren’t quite as automatic as what we get with Windows hashes and tickets.
So… what this means is that we don’t do as much AD FS work anymore, and when Microsoft released a hotfix for AD FS in the August 2014 update rollup, it didn’t catch my eye. This hotfix and the related configuration that needs to be added to the AD FS trust with Azure AD are documented in the newer Configure Persistent Single Sign-On article, and I first picked up on this configuration in the Azure MFA article for AD FS. At any rate, this configuration specifies two new Issuance Transformation Claims Rules for the AD FS Relying Party Trust with Azure AD (AKA “Microsoft Office 365 Identity Platform”):
Continue reading “Keeping AD FS Integrated Windows Authentication (IWA/WIA) Clients Signed In”
Many people think of AD FS as merely a federated authentication service. And with a name like Active Directory Federation Services, it’s easy to see why. However, it also has the capacity to make authorisation decisions within its Claims Engine. This may be most familiar as the Office 365 Client Access Policies, but those policies are basically just a flavour of AD FS Issuance Authorisation Rules. An AD FS Issuance Authorisation rule provides a gate at AD FS, where permissions can be granted or denied to authentic users, per-Relying Party, before giving the user Claims for the requested Relying Party. In most cases we will think about these rules as coarse controls, to block a wide category of requests, such as those originating from outside the network, for members of a group, or for any combination of request-based, device-based and user attribute-based Claims. We can even create authorisation rules based on the user’s Identity Provider, or from additional factors of authentication. We will typically still implement most of our authorisation logic within the Relying Parties we are authenticating to, but in some cases it’s very useful to control access at this intermediary tier – especially if a large class of users, devices or networks should be treated as higher risk.
These concepts are not new, and the TechNet documentation I reference here dates back to the earliest wave of AD FS 2.0 RTW content:
Ultimately, I think these articles do answer the question of how to create an AD FS Issuance Authorisation rule, but I can’t point very clearly to the place on these pages that spells it out, and I do think there is a lot of confusing information about this in other places which may lead people astray. Namely, there is a lot of information that only concerns itself with the default Active Directory Claims Provider Rules and the Claims that come from request headers. Also, some of the most referenced AD FS + SharePoint content seems to have been written without authorisation rules in-mind. I want to try to clear some of that up in this post.
I’ve added a fairly significant update regarding the new MFA stage in the pipeline half-way down this post.
Continue reading “The Rules of AD FS Claims Rules”
Back in February, I posted a question on the Geneva forum about Adjusting token lifetimes at the Web Application Proxy (WAP) for external access:
Does the Web Application Proxy or AD FS have any separate controls for adjusting token lifetimes to a different value via WAP than directly at AD FS? I can see there’s a session cookie for EdgeAccessCookie that WAP issues but this seems to be entirely undocumented at present. I’ve poked around in C:\Windows\ADFS\Config\microsoft.identityServer.proxyservice.exe.config (also undocumented as far as I can tell) but I’m not finding anything there either. We used to have some of these controls (sort of) with TMG/UAG. Are they totally gone now? With the AD FS Proxy this was less of an issue because it was only publishing AD FS but this is something that I’d hope to be able to control with a Reverse Proxy. Any ideas?
I didn’t get any replies, but after carrying out some tests of my own, I noticed the EdgeAccessCookie, and found a bit of information on TechNet:
After the user is authenticated, the AD FS server issues a security token, the ‘edge token’, containing the following information and redirects the HTTPS request back to the Web Application Proxy server:
- The resource identifier that the user attempted to access.
- The user’s identity as a user principal name (UPN).
- The expiry of the access grant approval; that is, the user is granted access for a limited period of time, after which they are required to authenticate again.
- Signature of the information in the edge token.
Web Application Proxy receives the redirected HTTPS request from the AD FS server with the edge token and validates and uses the token as follows:
- Validates that the edge token signature is from the federation service that is configured in the Web Application Proxy configuration.
- Validates that the token was issued for the correct application.
- Validates that the token has not expired.
- Uses the user identity when required; for example to obtain a Kerberos ticket if the backend server is configured to use Integrated Windows authentication.
If the edge token is valid, Web Application Proxy forwards the HTTPS request to the published web application using either HTTP or HTTPS.
This quickly became one of those things where there was insufficient documentation and limited project time, so I had to put this inquiry on hold. Then in July, I posted a question on the Application Proxy blog (a great resource), to see if this is something that they planned to document. The response that I got from Ian Parramore was unexpected and pleasing:
Continue reading “Coordinating AD FS 2012 R2 token lifetimes to reduce logon prompts, enforce revocation and limit session duration over public networks”
Windows Server 2012 R2 introduces a number deep changes to the way that AD FS works, which means that as practitioners, we need to look for solutions to problems in new, unexpected places. For instance, in the old world, if AD FS was completely unresponsive, the first place I would look after AD FS itself would be IIS. In AD FS 2012 R2, IIS doesn’t play a role. Requests are still served by the HTTP.SYS kernel driver but we interact with it using NETSH HTTP, which connects to the driver via the User Mode HTTP Server API. IIS and other familiar components would also interact with this API previously, but they provided a friendlier layer of abstraction between an administrator and the API. Interacting with HTTP.SYS using NETSH HTTP brings a learning curve with it, particularly when it comes to understanding what is and is not controlled here. Also, there is no GUI and the security that HTTP.SYS enforces is stricter than the abstracted layer that IIS has historically opened up. This web server architecture change and other new differences add to the difficulty of tracking down problems when things don’t work as expected, as detailed in this post.
Continue reading “Things that don’t update when changing an AD FS URL in Windows Server 2012 R2”
After a brief diversion, I’m returning to my series on SharePoint with RMS. This post finishes off the baseline considerations, although there’s a lot more to say. But at last, in this post, we’ve reached the point where we know that RMS thinks I’m cool – so now what? Or if you prefer, I’m taking a look at the RMS Use License that is typically embedded in Microsoft Office documents, or in other cases might be associated with a client’s machine.
The Use License that RMS issues acts like an offline enforcer of allowed rights. The rights granted by RMS and the duration they persist define what a user can do with their offline copy of RMS-protected content and how long they can continue to take those actions before they need to re-visit SharePoint and the RMS infrastructure in order to claim fresh rights. Since rights persistence is defined by the owner(s) of a SharePoint list, the impact of those settings should be well understood by any users that have this control.This post focuses on what a user can do offline once RMS has done its job, and the user’s experience once those rights expire, bringing the tension between valid offline access versus timely rights revocation to the fore.
You will notice I’m talking about offline access a lot here. When I say “offline” in reference to RMS-protected content, I mean the documents that have already been encrypted by RMS and decrypted/opened by a user. I say the files are offline because the original unencrypted content still resides in the SharePoint content database. Any edits that RMS allows a user to make to the offline content need to be saved back to SharePoint if they will persist over time. Continue reading “RMS Use Licenses, Offline Access and Rights Revocation with SharePoint 2010”
When helping our clients with Office 365 deployments, we sometimes find that DirSync has been associated with a trial tenant that is about to expire and/or was originally created with a provisional name, or similar. In any case, a public DNS name can only be verified once in Office 365, which associates that namespace with the Office 365 and Azure AD tenancies. So if we want to move DirSync (which is also a prerequisite for ADFS) to a new tenancy, then we need to back it out from the first tenant and re-associate it with the second. Unfortunately, that process isn’t exceptionally quick, but there are some manual steps that you can carry out in order to accelerate the change. As we do this more often, our list of things to check is growing, so this list may change, but this is where we’re at today. Please feel free to comment if you feel we’re overlooking anything.
Continue reading “Moving an Office 365 DirSync/ADFS domain from one Azure AD tenant to another”
Last week, Microsoft released Windows Server 2012 R2 Preview. Some information about new features like the Web Application Proxy role began to emerge from recent industry events, but there isn’t an awful lot to absorb at the moment. Having played around with the preview for a few days, I’m pleased to report that the new features look good. While there are always niggles and unsupported scenarios, the features themselves are bringing Microsoft’s Identity and Access Management (IAM) offerings nearer to parity with the industry leaders. These changes should be of particular interest for SharePoint on-premises and Office 365 customers, as a number of scenarios that were on the bleeding edge of ADFS/UAG capabilities have been brought into the fold with some important enhancements to ADFS, which isn’t just for federation anymore.
In short, we get a new Claims-Aware Reverse Proxy, Device Claims in and outside of the network, Multiple-Factor Authentication and other enhancements for making access control decisions on more than just a username and password. I’ve discussed all of these topics routinely over the last couple of years in SharePoint on-premises and Office 365 contexts, but the current provisions in ADFS and UAG are not as elegant as what we find in the preview, so I’m keenly exploring the new functionality and will try to keep the content flowing. In this post I will focus on the features themselves, as there’s a lot of new stuff and the implementation of this functionality will only be clear with a bit more information than what you’ll find online today. I’m kind of rushing this out after limited use because I know there’s a big appetite for knowledge about the Microsoft Reverse Proxy roadmap, so apologies for the incompleteness in advance.
Continue reading “Significant Identity and Access Management Improvements in Windows Server 2012 R2”