I know what you're thinking - this is the worst name for a blog post ever...... (or possibly what has that picture got to do with any of this).
This post is describing what the new kerberos constrained delegation (KCD) feature for Azure Active directory domain services (AADDS) makes possible. Now before you stop reading at this point let me tell you what this enables (and actually the same thing was always possible with 'normal' AD the new stuff is just making it possible in AADDS).
Say you have a windows authenticated IIS site (these are incredibly common in most enterprises) if you are logged on to the domain and have your kerberos ticket you can then transparently access the website as yourself. All lovely stuff.
What happens though if you want to modernize that login to use AAD instead (this is surprisingly not that easy to achieve by just changing IIS), or expose that internal website securely to the internet with minimal effort, or indeed allow transparent login to a domain inside Azure that is different to the domain you have a kerberos ticket for on your workstation/laptop?
In fact what if you want to do all three of those in one hit?
Enter App proxy into the arena......
App proxy enables all of these things for you in a surprisingly easy way - so lets walk through those few simple steps.
In my example case i have a windows authenticated IIS site (using kerberos) and i want to be able to transparently log into that using the AAD token i already have from my windows 10 login (assuming you have AAD joined machines rather than AD ones) - otherwise any access to most Microsoft sites would trigger an AAD login and you are likely to have a token from that process.
So lets go through how this is configured.
First up we need to install the app proxy connector - if you navigate to the AAD pages of the Azure portal you'll see this link:
Click on that and you'll see this screen
You'll then need to download the app proxy agent software by clicking on the link in the portal
Save it away somewhere then copy it to the server you want to install it on (in my case I'm installing it on the same server as the IIS site - but that doesn't have to be the case)
Go through the installer (somehow the installer seems a little retro)
Login to azure AD as part of the process - you will need certain elevated rights (as you might expect) to be able to do this - i cheated and activated GA via PIM but there will be a lesser role that can do this I'm pretty sure (probably mentioned in the docs.....)
And we're installed - you might need to mess with the proxy setting depending on your network setup.
Now the connector is there and has punched an outward hole to the internet (one way) . Now we need to assign that connector to a group to then make reference too when we link to an 'enterprise application' in AAD.
To do this we choose create connector group and give it a name - can be anything but has to be at least 4 characters
Once that is in place we choose configure the app (this is where it creates an enterprise app to tie this stuff together)
We give it a name and configure appropriate urls etc - one is the internal website address that this will ultimately access and the other is the external name we'll be able to reach the website at. We then mention the connector group we created earlier to link the app to the connector agent we installed. There are some other properties of the bottom of the pic but i left all those to default.
Once that is created we then need to find the enterprise app in AAD
We then click into that and we need to do a couple of things here - the first thing (as with any AAD app) is to assign users/groups from the directory we want to grant access to - so just go to the add user button and pick the appropriate identity. Once that is in place they'll be able to access the external url and get to the site (if they have a token) - or they'll be forced to pass AAD authentication at that point
The next bit is the clever part as at this point the website is reachable but users will be forced to authenticate again using the username/password for the AD domain that the IIS site is configured against. To prevent that we enable windows authenticated pass through (using kerberos delegation)
To do that we choose the 'integrated windows authenticated' option from the single sign on blade within the enterprise application
In that we need to enter 2 bits of information -first is the spn - this (in my case) was in the following format (http/servername - take care as this is not a url it is the protocol followed by / followed by servername - at first glance the tendency is to read it like a url and enter the wrong thing)
The second part if the identity we want to pass through - there are various options here - you need to choose the one that contains the username format that is known by your AD controllers - the list of options should enable any use case i would thing
In my case that looked like the following
The next bit is the new feature in AADDS to enable the delegation (note this is only possible in powershell and not through the AD GUI). For normal AD though it is possible in the GUI if you are going that route - the AADDS limitation is because it is a 'PaaS' service and you don't get full enterprise admin rights against the domain and the change is blocked.
This is the simple bit of powershell (you'll need the AD modules for powershell installed to have the cmdlets it wants to use)
$rich = Get-ADComputer -identity servername
set-adcomputer servername -PrincipalsAllowedToDelegateToAccount $rich
Once that is done and all the AAD/app proxy things have had chance to fully deploy and setup (seemed to take about 5 mins for me).
You'll then be able to do a fully modernized AAD login to an external site which will then transparently log you on to your 'legacy' AD authenticated IIS site
So in my test case - i could visit the site below, i already had an AAD token so i completely transparently logged on the the IIS site and you can see (though i redacted the import part) that I've logged on using a kerberos ticket as the server was allowed to delegate and use my AD identity to log me in.
I think this is an amazing feature - it's very simple and secure and if you've ever looked into AAD enabling IIS a damn site easier.
App proxy really is one of the killer features of Azure - i just don't think it's that widely understood/publicized so people haven't realized how good it is.
The picture by the way is mean to illustrate the delegating of the authority (the egg....) to someone else - tenuous at best i think......
Good stuff Rich.
ReplyDelete