Meeting the InCommon Assurance profile criteria using Active Directory

[Eric Goodman <>]

So go figure, but it’s not a straightforward problem to answer. Who would have guessed?

 

According to:

 

http://support.microsoft.com/kb/264480

 

There are 6 Windows password set and change protocols. These are:

 

1.       The NetUserChangePassword protocol

2.       The NetUserSetInfo protocol

3.       The Kerberos change-password protocol (IETF Internet Draft Draft-ietf-cat-kerb-chg-password-02.txt) [port 464]

4.       Kerberos set-password protocol (IETF Internet Draft Draft-ietf-cat-kerberos-set-passwd-00.txt) [port 464]

5.       Lightweight Directory Access Protocol (LDAP) write-password attribute (if 128-bit Secure Sockets Layer [SSL] is used)

6.       XACT-SMB for pre-Microsoft Windows NT (LAN Manager) compatibility

 

               

(1) and (2) are API level protocols that do not impose any restrictions on the “on the wire” protocol. The application level API passes the new (and old) password as plain strings, so security/encryption is only at the level of the “on the wire” protocol used. From the same document:

 

The NetUserChangePassword function does not control how the oldpassword and newpassword parameters are secured when sent over the network to a remote server. Any encryption of these parameters is handled by the Remote Procedure Call (RPC) mechanism supported by the network redirector that provides the network transport. Encryption is also controlled by the security mechanisms supported by the local computer and the security mechanisms supported by remote network server or domain specified in the domainname parameter. 

 

My Analysis: I’m not fully clear on how secure this means the protocol is. It seems like it’s as secure as the least secure supported RPC encryption mechanism on the domain controller. In previous threads, Ron and Lee identified that RPC calls used for DC-DC replication use Kerberos for encryption, and so presuming adequate Kerberos security meet Silver requirements.

 

My only concern here is that I haven’t yet found a reference that clarifies that this holds true for ALL RPC communications in Windows. (For example, one of the documents Lee quoted states: “To keep data secure while it is in transit between sites, RPC over IP replication uses both authentication (with the Kerberos version 5 (V5) authentication protocol) and data encryption”. It’s not clear whether this is saying that replication uses authentication and data encryption as a function of using RPC, or that it is doing that *in addition* to making RPC calls. See http://msdn.microsoft.com/en-us/library/windows/desktop/aa378646(v=vs.85).aspx , which says “To complete a secure remote procedure call, additional steps are necessary.“ (My emphasis). Other followup articles that seem related to this issue: http://technet.microsoft.com/en-us/library/cc781010(v=ws.10).aspx and http://blogs.technet.com/b/askds/archive/2011/04/08/restrictions-for-unauthenticated-rpc-clients-the-group-policy-that-punches-your-domain-in-the-face.aspx

 

 

(3) and (4) use the standard Kerberos “request/reply message” protocol, which employs the same level of Kerberos encryption as is used in TGT request/replies, etc. (See http://tools.ietf.org/html/draft-ietf-krb-wg-kerberos-set-passwd-02). That seems to indicate that this is as secure as any other Kerberos-secured data exchange.

 

My Analysis: These appear to be as secure as any Kerberos messaging supported in your Windows environment.

 

 

(5) looks good if we assume the parenthetical is an enforced requirement. From the few supporting comments I’ve found, the LDAP API does enforce 128-bit SSL for this operation. I see several references that you will receive errors if you try to write a password to the DC via LDAP without using 128 bit SSL. That said, most of the comments I’m using for this “confirmation” are from blog posting and help forum discussions; I haven’t found an authoritative source on that yet.

 

My Analysis: On the face of it, this is de-facto secure, given the apparent 128-bit SSL requirement.

 

 

I’m so far unable to find any clear statements on (6).

 

My Analysis: On the basis of the phrase “LAN Manager compatibility”, I presume this is insecure, but only supported if LAN Manager compatibility is enabled.

 

 

Overall Analysis: The security of Windows password set/change messages seems to the least secure element of:

 

·         Supported RPC encryption

·         Supported Kerberos encryption

·         LDAP with 128-bit SSL

·         Support for LAN Manager compatibilty

 

Since you can’t enable LAN Manager compatibility and be in compliance with Silver and since LDAP enforces 128-bit SSL the only potential relevant considerations left seem to be RPC and Kerberos encryption settings, which appear to be the same settings we’ve already discussed in the document.

 

 

Conclusion: My first pass review is that the only new gap raised by password change/set messaging is around whether the RPC calls used to perform (1) and (2) style changes requires encryption and how one can audit for it if not. All other concerns are duplicates of existing gaps around AD Silver compliance (both the basic cookbook and alternative means elements) for securing Windows password-handling communications in general.

 

 

I welcome others’ review of these comments, as there’s a reasonable amount of interpretation and inference in the above. As you can probably tell, I’m particularly unsure of my review of the RPC elements.

 

Have a good weekend all!

 

--- Eric