Meeting the InCommon Assurance profile criteria using Active Directory

[David Walker <>]

Thanks, Brian.  Even though it may not involve an Alternative Means statement, it's still useful for our recommended Means statements, so I'll change the question to your suggested text.

David

On Mon, 2013-05-06 at 22:12 +0000, Brian Arkills wrote:

I've got a follow-up on this question:

 

                Is it possible to configure AD so that the NetUserChangePassword and NetUserSetInfo protocols use only NIST approved algorithms for encryption?

 

Our reference material on this (from prior thread) is: http://support.microsoft.com/kb/264480

 

I've been researching a slightly different topic (for the UW) which directly intersects with this material. I've discovered: http://forums.asp.net/316534/ShowPost.aspx which is a massively long post filled with help from (then ASP MVP) Ryan Dunn on writing code to support AD password changes. I have a book from Ryan Dunn and Joe Kaplan which also covers this material--see "The .NET Developer's Guide to Directory Services Programming" (pages 376-386). What I've gleaned from these two sources is that:

 

If you use the System.DirectoryServices framework or the underlying ADSI interface it relies on, the SetPassword and ChangePassword methods prefer:

                1. LDAP write-password over SSL

                2. Kerberos change/set password protocol

                3. NetUser* protocol

in that order.

 

So if System.DirectoryServices is being used to manage passwords, one solution that avoids the NetUser* protocol methods is to ensure you've enabled LDAPS on all DCs. In other words, you avoid using the NetUser* protocol by enabling a preferred method that does leverage a known protected channel.

 

Based on a bit of reading elsewhere, I suspect this is true of other interfaces (like the ctrl-alt-delete change password button) which I think leverage the same ADSI stuff--but I believe this is largely dependent on the client and the libraries it supports.

 

One other thing to note is that you could certainly craft a solution for this issue that included the following elements:

a) We've disabled the change password permissions for all users, which means NetUserChangePassword is useless.

b) All password set activities are constrained to a known set of user accounts and known processes, all of which leverage a protected channel mechanism, i.e. NetUserSetInfo is not in use in our environment to set passwords.

 

So I'm personally left thinking this question isn't significant, but we may still want to ask it to figure out whether we need to recommend the above or some other solution that requires NIST approved algorithms for the encryption on the protected channel communication.

 

Assuming we leave this question, we should add some context that makes it clear that our concern is about the strength of the protected channel of communicating the password information. Something like:

 

                Is it possible to configure AD so that the NetUserChangePassword and NetUserSetInfo protocols require NIST approved algorithms for encrypting the session over which the password data is passed?

 

-B