On 2017-01-17 12:56, David Kupka wrote:
> Hi Christian,
> 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
> cn=users,cn=accounts
> 2) respect the value of nsAccountLock that is set to true for all staged
> users.
> But it would be nice to have this scenario (stageuser.uid == user.uid)
> implemented as a part of [1].

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
identify user.

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.

* 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.


Attachment: signature.asc
Description: OpenPGP digital signature

Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to