RC4 Kerberos and AD FS Issues

Posted on Leave a commentPosted in ADFS, kerberos, Office 365

It has become common place to consider the position of the RC4 cipher in TLS connections, but this is not something that you can take from a TLS connection (HTTPS) and assume the same for Kerberos connections. If you do disable RC4 for Kerberos then there are some things to consider, especially is you have ADFS servers in place and multiple forests that are trusted.

If RC4 is disabled in group policy and the trusted domain is Forest Functional Level 2003 then your ADFS logins across the trusts are not going to work. You need a FFL of 2008 (maybe R2) to support AES authentication across the trust (and to ensure the trust supports AES in the trust settings) before you can turn of RC4.

If you have disabled RC4 in the ADFS domain and you try and login with an account in a FFL 2003 trusted forest then Kerberos auth will fail, ADFS will be unable to read the token (the encryption type is wrong) and the fields of the SAML token are invalid. You get a lovely error in ADFS Debug logs that reads as follows (Event ID: 52):

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)

The GPO setting that removes RC4 encryption needs to be enabled on the domain controllers and on the ADFS servers. This policy is found under the “Network security: Configure encryption types allowed for Kerberos” option as per https://technet.microsoft.com/en-us/library/jj852180(v=ws.11).aspx with only DES and AES.

If this is your issue, then reenable RC4 for Kerberos on the domain controllers and recreate the trust between the forests. Recreating trust after enabling RC4 in GPO meant the new password’s RC4 related keys were stored in the trust object related user account’s password. Then TGT could be decrypted and used for Kerberos successfully.

ERROR_REPLICA_SYNC_FAILED_THE TARGET PRINCIPAL NAME IS INCORRECT

Posted on Leave a commentPosted in 2003, 2007, active directory, error, exchange, kerberos, virtual pc, virtual server

This rather imposing message is found if you try to force replication between to Active Directory Domain Controllers when one of the controllers machine account password is out of sync with the password as stored on the other domain controller.

I have seen this a number of times on Virtual PC or Virtual Server Active Directory deployments with more than one DC in the virtual environment.

So, how do you fix it:

  1. On the DC that is broken (the one that when using replmon reports the error above) set the Kerberos Key Distribution Center Service to manual and stop the service.
  2. From a command prompt on the broken DC enter the following:
    netdom resetpwd /s:name_of_working_DC /ud:domain\user /pd:*
    where domain\user is an administrator of the domain in the domain_name\user_name format. You will be prompted to enter your password.
  3. Upon pressing Enter, if the command fails then restart the broken DC and repeat the above command (this restart clears the Kerberos ticket cache and so clears the broken credential attempts that it has stored).
  4. Upon successful completion of the command in step 2 restart the broken DC. You must do this even if done already in step 3.
  5. Check that replication is working, and if so restart the Kerberos Key Distribution Center Service and set the service back to automatic.

This is a summary of Microsoft Knowledgebase Article 325850, with some more specific detail mentioned.