On Mon, Mar 07, 2016 at 09:58:20AM +0100, Natxo Asenjo wrote:
> On Mon, Mar 7, 2016 at 9:14 AM, Martin Kosek <mko...@redhat.com> wrote:
> > On 03/05/2016 06:00 AM, Rob Crittenden wrote:
> > > Natxo Asenjo wrote:
> > >>
> > >> By the way, revoking the certificate does not block applications using
> > >> it from ldap.
> > >>
> > >> I can still access the ldap server using this cert/key pair *after*
> > >> revoking the certificate using ipa cert-revoke <serialnr>. In order to
> > >> block it I need to remove the seeAlso value of the user account, or the
> > >> certificate attribute.
> > >>
> > >> I do not know if this is a security issue, but maybe worthwhile
> > >> documenting just in case.
> > >
> > > SSL/TLS servers don't automatically check for cert revocation. You need
> > > to add the CRL to the 389-ds NSS database periodically. I don't know for
> > > sure but I don't think 389-ds can use OCSP to validate incoming client
> > > certs. There is an IPA ticket in the backlog to investigate this for the
> > > web and ldap servers: https://fedorahosted.org/freeipa/ticket/3542
> > >
> > > And yeah, as you discovered, managing the value of CmapLdapAttr is a
> > > poor man's revocation.
> >
> > I saved Natxo's contributed article here:
> >
> > http://www.freeipa.org/page/Howto/Client_Certificate_Authentication_with_LDAP
> > for now.
> >
> Thanks!
> > My take on this is that it probably works, but I am curious actually what
> > problem you are solving. Are you interested only in allowing Certificate
> > authentication with FreeIPA LDAP or rather in allowing certificate
> > authentication in your application, whatever are the means?
> >
> both :-). Having name/password combinations in application settings is less
> desirable than having certificate/key paths. I know both accomplish the
> same thing (authenticate to the directory), but having certificates is less
> controversial (no need for third parties to know *that* password that is
> probably being used somewhere else as well, for instance. Having a simple
> way to 'revoke' the access is nice as well.
> > If this is the case, would leveraging SSSD Smart Card/certificate
> > authentication help? At minimum, it can lookup users by certificate:
> >
> > https://fedorahosted.org/sssd/wiki/DesignDocs/LookupUsersByCertificate
> >
> > With leveraging SSSD, you should be able to avoid manual user mapping in

Yes, but as you can see on the page SSSD currently requires that the whole
certificate is stored in the IPA user entry. But if your applications a
web-based mod_lookup_identity might be what you are looking for
http://www.adelton.com/apache/mod_lookup_identity/ .

> > FreeIPA LDAP. I am not sure though how the revocation would work. CCing
> > Sumit
> > on this one

SSSD itself can use OCSP or CRLs added to the systems NSS database
/etc/pki/nss when the authentication is run through SSSD which means
that SSSD must have access to the Smartcard. For other applications like
e.g. apache revocation must be configured in the application becasue
currently SSSD only checks if a certificate is valid during
authentication but not when the user is looked up by a certificate
because this check might delay the user lookup considerable.
Additionally e.g. in the apache use case the user lookup only happens
after the whole TLS/SSL handshake is finished and authentication is
successful but authentication should only be successful if the
certificate is valid.


> Interesting, I did not know about this possibility of sssd. I need to read
> it through, it might address our needs. Thanks for pointing me to it.
> What in my opinion would be really interesting would be to have something
> similar to the submission port on smtp servers. A different instance of the
> directory where only some kind of authentication are possible.
> Right now when using port 389 I can choose between a combination of SASL
> mechanisms, and if in dse.ldif anonymous auth and minssf are modified, then
> I can force the usage of secure protocols. What I would like is to have a
> way to disable password authentication mechanisms on a ldap port, while
> keeping it enabled on the other. So we could close one port to the outside
> world, and keep it open on the LAN, for instance.
> Is this even possible?
> --
> Groeten,
> natxo

> -- 
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project

Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project

Reply via email to