Bug 3069

Summary: tl-ldap-certalias or similar for AD environments
Product: ThinLinc Reporter: Peter ├ůstrand <astrand@cendio.se>
Component: Smart cardAssignee: Henrik Andersson <hean01@cendio.se>
Status: CLOSED FIXED QA Contact: Bugzilla mail exporter <bugzilla-qa@cendio.se>
Severity: Enhancement    
Priority: P2 Keywords: hean01_tester, ossman_tester, relnotes
Version: trunk   
Target Milestone: 4.1.1   
Hardware: PC   
OS: Unknown   
Acceptance Criteria:

Description From cendio 2009-04-02 13:30:25
We might want to adapt tl-nds-certalias, or create a similar script, for
AD-based smart card environments, rather then eDirectories.
------- Comment #1 From cendio 2010-11-02 14:37:56 -------
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.
------- Comment #2 From cendio 2013-08-08 13:58:43 -------
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.
------- Comment #3 From cendio 2013-09-30 12:45:34 -------
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.
------- Comment #4 From cendio 2013-09-30 13:55:10 -------
Commit 27980, updates the TAG with information about ldap_schema and iis use.
------- Comment #5 From cendio 2013-10-24 16:23:26 -------
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.
------- Comment #6 From cendio 2013-10-28 11:01:04 -------
This works as expected as tested at customers site using the new