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 authentication. 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 access. 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 testing. 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 tl-ldap-certalias.
