0

I'm receiving this error logged under ADFS Tracing - Debug:

ServiceHostManager.LogFailedAuthenticationInfo: Token of type 'http://schemas.microsoft.com/ws/2006/05/identitymodel/tokens/UserName' validation failed with following exception details:
 System.ArgumentOutOfRangeException: Not a valid Win32 FileTime.
Parameter name: fileTime
   at System.DateTime.FromFileTimeUtc(Int64 fileTime)
   at Microsoft.IdentityServer.Service.Tokens.LsaLogonUserHelper.GetPasswordExpiryDetails(SafeLsaReturnBufferHandle profileHandle, DateTime& nextPasswordChange, DateTime& lastPasswordChange)
   at Microsoft.IdentityServer.Service.Tokens.LsaLogonUserHelper.GetLsaLogonUserInfo(SafeHGlobalHandle pLogonInfo, Int32 logonInfoSize, DateTime& nextPasswordChange, DateTime& lastPasswordChange, String authenticationType, String issuerName)
   at Microsoft.IdentityServer.Service.Tokens.LsaLogonUserHelper.GetLsaLogonUser(UserNameSecurityToken token, DateTime& nextPasswordChange, DateTime& lastPasswordChange, String issuerName)
   at Microsoft.IdentityServer.Service.Tokens.MSISWindowsUserNameSecurityTokenHandler.ValidateTokenInternal(SecurityToken token)
   at Microsoft.IdentityServer.Service.Tokens.MSISWindowsUserNameSecurityTokenHandler.ValidateToken(SecurityToken token)

I'm trying to write a simple proof of concept C# Service Provider using passive authentication.

From the C# SP, I'm creating a SAMLRequest and redirecting the browser to ADFS.

ADFS is prompting for forms credentials, and when entered, posts back to my SAML2.0 resource consumer with this status:

<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Responder"/>

I have two claim rules set up for this relying party.

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]
 => issue(store = "Active Directory", types = ("http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"), query = ";mail;{0}", param = c.Value);

And

c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"]
 => issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified");

I am utterly puzzled by the "Not a valid Win32 FileTime" exception, because it looks as though something in the depths of ADFS is trying to treat something as a timestamp that apparently isn't holding a valid timestamp.

This is a Windows Server 2012 R2 Datacenter edition server created from an Azure VM template. All I've done to it is installed ADFS and AD for testing purposes.

Not that I think it should make a difference, but the server timezone defaults to UTC.

  • It is not 100% clear when the error happens. I assume after authentication, but try an IdPInitiatedSignOn with the same user. Same error? In that case it is not related to your SP. – paullem Aug 4 '15 at 6:18
1

It turns out that the "Not a valid Win32 FileTime" exception was a red herring. When I went to test it the following day with these claims configured, I was getting this statuscode:

<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:InvalidNameIDPolicy"/>

I must have inadvertently had some junk claims configured when I was getting the Win32 FileTime error.

Digging further into the InvalidNameIDPolicy status, I noticed that the NameID format in my request was:

urn:oasis:names:tc:SAML:2.0:nameid-format:unspecified

And it appears that this is either invalid, or unrecognized by ADFS. Switching to request to specify the following NameID format policy solved the issue:

urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.