KDC interoperability with MIT Kerberos implementations when using Read Only Domain Controllers

Article ID: 2716037 - View products that this article applies to.
Expand all | Collapse all

Summary

This article describes circumstances under which devices implementing MIT Kerberos libraries will fail authentication when used in conjunction with a Windows 2008 or 2008R2 domain which utilises Read Only Domain Controllers (RODC). This article describes the symptoms and configurations under which the issue may present itself and suggests potential workarounds. In addition it explains the underlying reason for the failure. 

Symptoms

In an environment with one or more RODCs authentication may fail when interacting with certain MIT based Kerberos devices in one of the following scenarios.

·          The client is an MIT device which received a TGT from Windows KDC on RODC

·          The client passes a TGT generated by Windows KDC on RODC to MIT Device which in turn uses the TGT to request a TGS on behalf of the calling user.

In both scenarios the TGT will have been issued by an RODC where the  msDS-SecondaryKrbTgtNumber associated with the krbtgt account for that RODC will have a value greater than 32767.



In the first scenario the client will receive the error KRB_ERR_S_PRINCIPAL_UNKNOWN in response to any TGS request.

In the second scenario the TGS request will be silently dropped by the Windows Key Distribution Center KDC and a TCP connection Reset response will be issued.

In this circumstance capturing the traffic from the device you will see that the Key Version Number (KVNO) in the outgoing request is prepended with a 0 making the entire KVNO a 5 bytes in length.

Windows KDCs will always reject a 5 byte KVNO as they consider this to be malformed.

Note: Other clients may be unaffected and depending upon network topology the issue may be intermittent on affected clients


Cause

The issue occurs because of a difference in the way the Microsoft and MIT Kerberos standards encode and intepret the KVNO value. In a Microsoft Kerberos environment and when using RODCs the 4 bytes of KVNO are actually intepreted as two 2 byte values. For example the decimal KVNO 2870149121 in hex is AB 13 00 01. The first pair of octets represent the RODC's unique ID and the second pair represent the version number of the key. Together these uniquely identify to the KDC which principal and secret were used to create the key. In an MIT based Kerberos implementation the KVNO is treated as a single 32 bit value, however this in itself does not cause an issue. Crucially the encoding of the value differs between Microsoft and MIT Kerberos implementations, MIT Kerberos encodes and decodes the entire KVNO as a 32bit value using ASN.1 DER rules whereas the Windows KDC decodes only the lower 16bits of the KVNO as an ASN.1 DER integer and accepts the upper 16 bits as the RODCID without decoding.

Due to the differences in the encoding/decoding behaviour an MIT based Kerberos client will prepend a 0 to the KVNO value. This is because it encodes the entire KVNO strictly as an ASN.1 DER integer using twos-complement notation. Using this notation the high bit of a value is deducted from the sum of the preceding bits to derive the encoded value. Therefore the high bit of the encoded value must always be 0 if it is to be decoded as a positive or unsigned integer. This means that when the 16th bit of an RODC Unique ID is 1, ie when the RODC ID is 0x8000 (decimal 32768) or greater, it will cause an MIT implementation to prepend a 0 and thus generate a 5 byte KVNO.


Workaround

There are 2 options to mitigate the impact of this issue 

  1. Prevent users and services accessing MIT Kerberos clients from authenticating via an RODC. This can be done by denying the RODC the ability to replicate the password for the account or group of accounts via the PAssword Replication Policy. 
  2. Pre-create the RODC account discarding any which have RODC unique IDs over 32768

More information

Further Reading
http://msdn.microsoft.com/en-us/library/cc233896(v=prot.10).aspx



Note This is a "FAST PUBLISH" article created directly from within the Microsoft support organization. The information contained herein is provided as-is in response to emerging issues. As a result of the speed in making it available, the materials may include typographical errors and may be revised at any time without notice. See Terms of Use for other considerations.

Properties

Article ID: 2716037 - Last Review: August 23, 2012 - Revision: 3.0
Applies to
  • Windows Server 2008 Datacenter
  • Windows Server 2008 Datacenter without Hyper-V
  • Windows Server 2008 Enterprise
  • Windows Server 2008 Enterprise without Hyper-V
  • Windows Server 2008 R2 Datacenter
  • Windows Server 2008 R2 Datacenter without Hyper-V
  • Windows Server 2008 R2 Enterprise
  • Windows Server 2008 R2 Enterprise without Hyper-V
  • Windows Server 2008 R2 Service Pack 1
  • Windows Server 2008 R2 Standard
  • Windows Server 2008 R2 Standard without Hyper-V
  • Windows Server 2008 Service Pack 2
  • Windows Server 2008 Standard
  • Windows Server 2008 Standard without Hyper-V
Keywords: 
KB2716037

Give Feedback

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com