If you’ve made it to this post because you are troubleshooting your AD FS sign in with Office 365 due to “AADSTS50008: SAML token is invalid” I still recommend you do all the standard troubleshooting steps provided in this article below the image:

AADSTS50008https://support.microsoft.com/en-us/kb/3015526

Generally speaking, if you’re getting issued a token from your AD FS server and Microsoft’s STS is stopping you from logging in, it would be because of your token signing certificate:

Has your Token-Signing Certificate changed since you last told Microsoft?

 

It’s never a bad idea to re-run the following:

Update-MsolFederatedDomain -DomainName [verified domain]

Executing this MSOL cmdlet will get Microsoft’s STS service to check your Metadata, which in turn will update any certificate changes you may have made. If you’re really clever you can go to your WS-Federation Metadata and check what you’re telling the world is your public token signing certificate.

  1. Navigate to https://<AD FS Namespace>.com.au/federationmetadata/2007-06/federationmetadata.xml in Internet Explorer.
  2. Search for KeyDescriptor use=”signing” in the metadata document.
  3. If you copy the raw certificate data from <X509Certificate> into a text file and save with extension ‘cer‘ you can validate it matches what’s in your AD FS console > Service > Certificates > Token-Signing

Good, we have that under control. I experienced an issue the other day where I still got the error post running this cmdlet and performing the above nifty check….. Head scratches. Firstly, I know that my AD FS services has processed my sign on attempt and given me the required information to take to Office 365 and log in. Secondly, I know that my signing certificate is correct. Still the error remains;

We received a bad request.
Additional technical information:
Correlation ID: 82121251-3634-4afb-8014-fb5298d6f2c9
Timestamp: 2016-03-04 00:25:35Z
AADSTS50008: SAML token is invalid

My issue was a little unique but worth a notable mention on the internet. In my scenario, If I left my browser page up with the error shown above for a length of time, suddenly if my browser refreshed I would get dropped into whatever it was I was trying to authenticate to. So my authentication was successful with Microsoft after a point in time. I highlight those words cause I literally had to say them out loud to myself before I found the fix. Looking at the AD FS servers where my token is issued from, I took a quick look at the time. I then took a look at the time on the AD workstation I was trying from, they both seemed to be in synchronisation with each other.  What about from my BYOD Surface that I use at Kloud which uses a internet time source?

Great Scott! 7 minutes difference!

My token was being accepted by Office 365, but only once Microsoft had caught up to the future from which I had came from. This isn’t unreasonable from Microsoft to not allow my issued token until that time had actually happened in Microsoft cloud land. This wasn’t an issue that showed its face as easily with internal applications as all domain controllers and workstations were following orders from the time source in the domain. The problem was that the domain couldn’t synchronise with a internet time source at the time master. So it was slowly but surely sneaking ahead. Once we had come back from the future, the issue with ‘AADSTS50008: SAML token is invalid’ was resolved and authentication was instantaneous on the first attempt once again.

I don’t want to put the fear of the ‘internet time gods’ on you, I believe that there is some kind of threshold that Microsoft will allow. Just not in 10 minutes time or maybe tomorrow, in the future.  Possibly the magic number for token timestamp issuance is plus or minus 5 minutes. Once I rolled the AD FS servers time back within a couple of minutes/seconds of the internet time gods, tokens were accepted. Now over to the AD and Network teams to restore order on a wider scale.

Category:
ADFS, Identity and Access Management
Tags:
, , ,

Join the conversation! 3 Comments

  1. Hi

    Very nice article. I have one question about MFA. I am trying to combine two rules. I am able to perform MFA for users in a group and if they are outside corporate network with this command.

    Set-AdfsRelyingPartyTrust –TargetRelyingParty $rp –AdditionalAuthenticationRules ‘c: [Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid”, Value == “GROUPSID”] && [Type == “http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork”, Value == “false”] => issue(Type = “http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod”, Value = “http://schemas.microsoft.com/claims/multipleauthn”);’

    But I want to do MFA with users in MFA work and if devices are not workplace joined. But may be syntax is wrong or this rules cannot be applied. Would you be able to help out in this one.

    I am trying this command but getting error.
    Set-AdfsRelyingPartyTrust –TargetRelyingParty $rp –AdditionalAuthenticationRules ‘c: [Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid”, Value == “GROUPSID”] && NOT EXISTS([type==”http://schemas.microsoft.com/2012/01/devicecontext/claims/registrationid”]) => issue (type=”http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod”, value = “http://schemas.microsoft.com/claims/multipleauthn”);’

    Reply

    Reply
    • Your Claim rule seems correct based on this:
      ‘NOT EXISTS([type==”http://schemas.microsoft.com/2012/01/devicecontext/claims/registrationid”])
      https://technet.microsoft.com/en-us/library/dn280949.aspx

      Have you allowed the Certificate/Smart Card Port on your WAP servers?
      On the AD FS side of things, it’s worth mentioning that any firewalls in front of the Web Application Proxy (WAP) will need to allow port 49443/TCP inbound, as this is the port the AD FS Smartcard Authentication Service listens on. Evidence of this requirement in the Windows Firewall snap-in. AD FS creates a firewall rule during the installation allowing 49443/TCP inbound.

      Reply
  2. Thanks Arran. I had the same issue and by correcting the time on the ADFS server, the issue got resolved.

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: