So I’m renewing my CISSP and will be making a push into the security space pretty hard in the next few months. Â Part of that will be doing things like in this post.
I am deep into identity and auth flows and have been doing a ton with ADFS/OAuth with Intune etc.
A few days ago it hit me that a person has the ability to modify the claims that ADFS sends to O365. Â That got me to thinking…
What will happen if O365 does its realm redirect where a user logs in as one person yet the claim for the UPN is different than the original? Â Will it work and if so, what are the ramifications of it?
So, here’s my general thinking of what I want to do (didn’t end up being how to do…keep reading):
- Setup ADFS and a federated domain in O365 (chrisgivens.com)
- Modify the O365 ADFS claims to be someone\something other than what the actual login implied.
- IE…I login as chris@chrisgivens.com, but the claim that is sent back is actually spoof@chrisgivens.com
- Share a site with spoof@chrisgivens.com
- See if it all works…
So…first part. Â ADFS. Â When you setup the O365 relay it adds in its own claims rules so that it gets what it is expecting. Â The general set of claims that get sent are:
- http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier
- http://schemas.xmlsoap.org/claims/UPN
- http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID
In addition to the other basic claims as seen here:
Ok, cool. Â So here’s my goal. Â Set it such that no matter who logs in, the identity and claims that get sent to O365 are really someone else! Â That requires a bit of claim manipulation. Â Here’s an example:
See what I’m doing? Â I’m setting the email to be something else other than the original value from the auth’d AD user! Â I do this for all the email claim fields. Â The though is that Azure AD will utilize the email\UPN as its “source of truth” for who the user is. Â Ok, great. Â So let’s try it out!
Going to the faithful login.microsoftonline.com, I enter in a set of credentials for my federated domain, and get redirected to ADFS. Â I log in to ADFS page, and the first go around, I got this error:
After removing competing claim rules and re-trying the login, this is the beauty you end up:
It worked…kinda. Â Notice that id. Â That is what I though was the valid ObjectGUID. Â Nope, its a bit different than that. Â So how the heck do I view the claims that ADFS is sending?
Well, good luck with that with the out of box logging of ADFS. Â You can attempt to follow this post to turn on all the verbose logging, but its only helpful for resolving the competing claims issue or the fact I did not have the SAML Consumer setup on the replying party.
So, what do you do? Â You swing over to Auth0.com and you setup your ADFS with them, then you can use all their cool debugging tools to see what is actually coming across! Â Awesome…
So, after looking at the logs and seeing the original claim rule applied, I see that the ObjectGUID is base64 encoded. Â So I copy it and paste it into my claim rule.
Ok, let’s try this again…I sign on, type a username and password, ADFS does its thing, I get redirected back to the site, and whala…I’m in as the other user! Â Holy shizer balls, it worked…
It wasn’t what I though would happen being that I had to find the ObjectGUID and that is what Azure AD goes off of, not the email claims.
So what does this mean? Â It means whoever has access to ADFS for the remote federated domain, can open up the ADSI edit tool, find the ObjectGUID for a user (or even use basic powershell such as “Get-ADUser username -Properties ObjectGUID | Select *”), paste in some rules and BAM…they are in as that user in the O365 application layer. Â
They do NOT have to be a domain admin to query Active Directory for ObjectGUID, nor do you have to be a domain admin to manage ADFS. Â You can simply be an ADFS Admin.
This is significant in that unlike a domain admin, when a domain admin changes a password or an AD object, the AD object changes are very likely audited and red flags thrown!
In my experience, a change to ADFS claim rules is very rarely audited and monitored and if it is, it is unlikely to throw up any major red flags. Â Any ADFS admin can make a change and login at any time and bam, you can be anyone, anytime. Â This leads to…log your ADFS 510 events:
Hope you trust whoever is running the target federated auth server (no matter what it is). Â Or that you trust whoever you are sharing things with if they are doing federation and not Azure AD directly!
I think it would be nice to be able to set in the configuration settings that I don’t want to allow my users to share data with a domain that has federation enabled and that it must be managed by Azure AD! Â Maybe even be able to set it at a very specific level such as Site/Web.