ADFS on Windows Server 2012R2 in Azure sptting “Not a valid Win32 FileTime” exception on passive authentication

active-directoryadfs

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.

Best Answer

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
Related Topic