Meeting the InCommon Assurance profile criteria using Active Directory

[Brian Arkills <>]

You dig up  the most interesting documents, Jeff. :)

 

RODCs have only a subset of all accounts & passwords. And additionally, as you've noted RODCs issue tokens with a different version number than RWDCs (read-write DCs or what most folks just call DCs). That version number is only relevant because there is also another additional capability, namely account revocation checking at the session level. In other words, with vanilla Kerberos, once you have a TGT, you can get as many TGS tickets when you want, even if the underlying account is no longer valid. Microsoft has added additional checking such that prior to issuing a TGS, it checks to make sure that the TGT is still valid to be used to issue a TGS. If your RODC has been compromised, you can revoke its version number, which means that any token issued by that RODC can no longer be used to get a TGS. See 3.3.5.5.1 of that document for the revocation checking stuff. This is also covered in a cursory manner in section 5.1.3 (or at http://msdn.microsoft.com/en-us/library/dd973899.aspx which is the same content as your link, but not in PDF format).

 

One thing this does bring to attention is that the account revocation checking features here are something we might reference in an alternative means write-ups. Those features are relevant whether you are using a RODC or a RWDC. I believe KILE is WS2012 DCs only though ... but I could be wrong about that.

 

From: [mailto:] On Behalf Of Capehart,Jeffrey D
Sent: Thursday, May 23, 2013 7:55 AM
To:
Subject: [AD-Assurance] Do Kerberos keys use variable salt?

 

I was reading a Microsoft document about MS-KILE which is the Kerberos V5 protocol extensions that Microsoft has added.  These may only apply to newer (Server 2012) versions of Kerberos, but it was interesting to note the variable salting.

 

If I read this correctly, the only way to get a variably salted hash is to use an Approved Algorithm.  I guess that doesn’t help us much.

 

Would Read-Only Domain Controllers change anything with respect to the 4.2.3.4 criteria for stored authentication secrets, in case of compromise of the KDC?

 

3.1.1.2 Cryptographic Material

Kerberos V5 establishes a secret key that is shared by a principal and the KDC and a session key that forms the basis for privacy or integrity in the communication channel between client and server. When KILE creates an AES128 key, the password MUST be converted from a Unicode (UTF16) string to a UTF8 string ([UNICODE], chapter 3.9). KILE concatenates the following information to use as the key salt for principals:

§ User accounts: < DNS of the realm, converted to upper case> | <user name>

§ Computer accounts: < DNS name of the realm, converted to upper case > | "host" | < computer name, converted to lower case with trailing "$" stripped off > | "." | < DNS name of the realm, converted to lower case >

 

The [MS-KILE] Kerberos Protocol Extensions
http://download.microsoft.com/download/a/e/6/ae6e4142-aa58-45c6-8dcf-a657e5900cd3/%5BMS-KILE%5D.pdf

 

 

5.1.1 RODC Key Version Numbers

Because read-only domain controllers (RODCs) can be deployed in less secure locations, RODCs have different key version numbers (section 3.1.5.8) to ensure they are using a different key than the domain's DCs. This protects the domain if an RODC is compromised.

 

 

Jeff

 

Jeff Capehart, CISA
IT Audit Manager
University of Florida - Office of Internal Audit
(352) 273-1882

http://oia.ufl.edu