On ti, 17 tammi 2017, Christian Heimes wrote:
On 2017-01-17 12:56, David Kupka wrote:
uniqueness of uid is not checked in staging area on purpose, it may be
changed multiple times before the stageuser is transformed into user
(activated). The uid uniqueness is then checked during activation.
Third party application that use FreeIPA's LDAP should:
1) search for users (and usercertificate attribute) only in
2) respect the value of nsAccountLock that is set to true for all staged
But it would be nice to have this scenario (stageuser.uid == user.uid)
implemented as a part of .
Can we safely assume that all parts of FreeIPA, Kerberos and all 3rd
party application *always* use the FreeIPA API or LDAP to validate a
user cert? Some applications may just validate the certificate and
OCSP/CRL for client cert authentication with e.g. mod_ssl.
Consider this scenario:
1) IT issues a smart card for a staging user. The smart card contains a
valid private/public key pair for FreeIPA.
2) HR sends the smart card to a new hire.
3) HR creates a standard user with same login as staging user
4) New hire uses the smart card to log into a system that only verifies
validity of cert (signature, dates, OCSP status) and uses subject to
The certificate validity for a future users should have
validity.notBefore property set. A login before that time should not be
possible with systems like (4) describes.
Even if we 'fix' the issue with non-unique UIDs in staging, it stays
dangerous to hand a valid certificate to a not-yet-valid user. At least
we should try to reduce risks with a couple of measures:
* Add a "valid from" field to stage users and set the cert's valid from
date accordingly. That renders the public key useless until the
estimated first day on the job.
According to RFC 3280, validity is the mandatory part of the x.509
certificate. Granted, certmonger does not allow you to set
validity.notBefore to some externally defined value, but this is
something we could implement. You can already achieve that with your own
certificate signing request. And it this case we deal with externally
provided user certificates, so we could have no ability to influence
what happens at all.
* Lock the smart card with a PIN and don't release the PIN until the
user has been moved from staging area to user area. This arrangement
makes the smart card inaccessible. We could use the KRA to store the PIN.
This is just a process, not a technical solution. Someone needs to
communicate PIN separate to the smartcard to a new hire anyway.
/ Alexander Bokovoy
Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code