Certificate practices using IdP with MS AD LDAP

[Douglas E. Engert]

On 4/22/2013 5:29 PM, David Bantz wrote:
> It must be fairly common for IdP deployments to depend upon LDAP from AD component of a Domain Controller.   I am inquiring about strategies for this dependency - specifically, the use of X.509 certificates for establishing encrypted communications between the IdP and AD LDAP.
>
> We're exploring a number of options in response to our Windows Server group recently determining they will exclusively use the internal Microsoft certificate generator and private CA for use within the Domain.  I am soliciting the experience of other institutions with similar deployments.  Do you:
>
>
> a) Import the certificate for the Domain's private CA into the default root CA store for use by the IdP to enable ldaps?

No. But do import the Windows Enterprise rootCA and any intermediate certificates for use with the x509-login-handler.
via Apache. (Also use some U.S. government issued smatc card and import thoses certificates too.

>
> b) Import the certificate for the Domain's private CA into an alternate location for java trusted CA?

No.

>
> In either case, how do you ensure that both the private CA and other well-known CAs have up-to-date certificates in that store?

The rootCA and Intermediate CAs are under the Windows Admin, and don't change very often. They let us know.

>
> c) Require the Domain to use a widely known trusted root CA such as the Comodo certificates available via InCommon?

No. The domain (even without Shibboleth) is very dependent on the CA, and works best if it is
self contained.

>
> d) Combine the use of the private CA internal to the Domain and use a different certificate signed by well-known trusted CA for the externally facing LDAP connection (which our Windows Server Group denotes as a "service certificate" rather than the more familiar "server certificate," a term I had not heard previously and would like to understand!)?
>
> e) Configure the IdP and AD in a "trusted" or "secure" subnet and allow unencrypted ldap communication?

Sort of. The bindDN to ldap is a service account that can only read AD. There is no sensitive data being read
from AD by the IDP.

For Password Protected Transport the IDP's login.config uses
the com.sun.security.auth.module.Krb5LoginModule to do Kerberos
authentication to AD, followed by an ldap lookup using the service account
for the BindDN to verify a few selected attributes about the user,
including if the account is locked (the test  of the userAccountControl bit)

  userFilter="(&(samAccountName={0})(extensionAttribute5=Y)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))"

(We only want to authenticate real people not service accounts or admin accounts.
extensionAttribute5=Y is local and says it is a real person.)

Thus using the above 2 modules, no user passwords are exposed.

>
> f) Some better alternative I didn't think of?
>


GSS-API to LDAP. If there is a Kerberos ticket cache available
to the IDP. (The vt middleware says it supports GSSAPI, but
I have not tried it, and don't see an example of how to specify it. )

For example on a Unix system where the user has kerboros tickets:

/usr/bin/ldapsearch -Y GSSAPI -H ldap://your.domain:3268 -b dc=your,dc=domain cn=xxxxx

will access the Global catalog. Substitute your domain and domain components above.
Then using klist you will see a ticket for ldap/a.DC.your.domain at YOUR.DOMAIN
If you use an administrator principal, you can update AD too.


Better? maybe not, but is an alternative.


> I will summarize responses to the list, so you can reply directly to dabantz at alaska.edu if you don't think your response needs to go directly to the entire list.
>
> Thank you!
>
> David Bantz
> U Alaska IAM
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
>

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444