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.