Bugzilla – Bug 3069
tl-ldap-certalias or similar for AD environments
Last modified: 2013-10-28 11:01:04
You need to
before you can comment on or make changes to this bug.
We might want to adapt tl-nds-certalias, or create a similar script, for
AD-based smart card environments, rather then eDirectories.
We've investigated this a bit more and determined a suitable course of action.
Smart cards in the Microsoft world require that the certificates on the cards
have a special attribute that specify the user and AD realm. In regards to
SITHS, that leaves two options:
1. Make sure the HCC includes the necessary Microsoft fields.
2. Add an extra certificate to the card that will only be used for AD
Until we have proper PKI support (bug 2739), we can only easily support model 1
as that's the only one that retains the public key in a database for us to
The proposed architecture is to fetch everything from HSA, which is a LDAP
directory containing all user attributes as well as the certificates
themselves. We will extract the public key from the certificate and the
username from the special Microsoft fields.
Since we cannot rely on certificates disappearing from HSA when they are
revoked, we also need to pay attention to expiration dates and revocation
lists. We probably won't need OCSP support right now, but can rely on the CRL
downloaded via HTTP. We probably need to write proper cache management though
to avoid torturing the CRL server too much.
Using 4.1.0 and tl-ldap-certalias with AD 2008R2 fails, but after some
investigation there seems to be a pretty easy fix to the problem.
tl-ldap-certalias has an undocumented configuration option which is not
distributed with our tl-ldap-certalias.hconf which is named filter. This is
used to filter out user objects with classtypes posixAccount however AD doesnt
have this class type but the required attributes in its default schema so if i
set filter to (&(objectclass=user)(uidNumber=*)) it works as expected.
Commit 27979 implements ldap_schema configuration to tl-ldap-certalias.hconf
which specifies what schema the target LDAP server is using.
I derived the meaning of ldap_schema meaning from sss-ldap and our supported
values are rfc2307 and AD.
Commit 27980, updates the TAG with information about ldap_schema and iis use.
Testing tl-ldap-certalias against Active Directory at customers site.
I stumbled upon a ldap iterator issue at the customers site, enumerated users
included a user object without proper attributes. See bug #4871 for more
information. I temporarly added a check to overcome this problem to continue
At the customers site I found they had several certificates per user and
authorized_keys was populated with everything available, I created bug #4872
about that issue.
This works as expected as tested at customers site using the new