[Freeipa-users] user certificate ldap EXTERNAL authentication

[Natxo Asenjo]

On Mon, Mar 7, 2016 at 9:14 AM, Martin Kosek <mkosek at 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
> FreeIPA LDAP. I am not sure though how the revocation would work. CCing
> Sumit
> on this one


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20160307/01a60f1d/attachment.htm>