Replace FreeIPA CA with privacyIDEA CA

Question
1

Hello, Cornelius!
Thank you for implementing new great features. Currently I’m discovering
privacyIDEA functions with hope to replace our FreeIPA based CA server with
privacyIDEA CA.
Unfortunately I didn’t found anything about CRL or OCSP with privacyIDEA.
Does it implemented already?

2

Cornelius Kölbel cornelius.koelbel@netknights.it writes:

thanks for the insight.
Yes the OTP functionality of FreeIPA is a bit limited. Also, they only
support TOTP AFAIK.

To quite true. With “ipa otptoken-add-yubikey” you can add your Yubikey
in HOTP-mode. As described earlier - FreeIPA is much more restricted in
defining policies for 2FA, so I’ll have 2FA completly in privacyidea.

I’m running FreeIPA 4.2 on Fedora 23 where CA seems to work quite well.
And I like the idea that certmonger automatically refreshes expired
certificates.

I’m also not quite sure what tasks are better done in privacyidea and
what are better done in FreeIPA…

Jochen–
The only problem with troubleshooting is that the trouble shoots back.

3

Hi,

thanks for the insight.
Yes the OTP functionality of FreeIPA is a bit limited. Also, they only
support TOTP AFAIK.

So your main system is FreeIPA 3 on CentOS 6 with no CA and no OTP.

FreeIPA4 would also support externel RADIUS/OTP-Server. I already
successfully tested this.

But then you would have

  • FreeIPA3 for kerberos/LDAP
  • FreeIPA4 for CA?
  • privacyIDEA through FreeIPA for OTP

Admitted, this is quite a zoo.

Please note: privacyIDEA requires python 2.7 to run smoothly. So either
you somehow manage to install python2.7 on CentOS6 or you take CentOS7
or Ubuntu14.04 for privacyIDEA.

As far as PAM is concerned, your can either rely on pam_python or use
pam_radius. I assume in your environment you could use a RADIUS-server
anyway. So if you are running a RADIUS server on the privacyIDEA
machine(s) you can as well use pam_radius.

As far as CRL and OCSP is concerned:

privacyIDEA does not “own” the whole webserver. In case of Apache you
are running mod_wsgi and you can put privacyIDEA (or also several
instances of privacyIDEA) into any URL location you wish to.
See
http://privacyidea.readthedocs.org/en/latest/installation/system/wsgiscript.html#running-apache-instances

So you can run the CRL through a cron job and publish the CRL in some
other web server directory. You could (I do not know the size and
requirements of your network) also use openssl mini ocsp with the
underlying SSL stuff.

This way you “could” go for it just now.

Nevertheless I think there are still things to think about like

  • certificate templates
  • certificates on smartcards
  • triggering of CRLs

The triggering of CRLs might be an interesting thing:
Trigger CRL generation each time a certificate was revoked in
privacyIDEA.

As a matter of fact you can revoke a token - also a user can revoke his
own tokens. This way he should also be able to revoke his certificate.
There we could add a hook, that - if a certificate is revoked - a new
CRL would be published.

This is all quite interesting stuff. It seems more of a project to me
with some conceptual work to discuss. But you might already know, that I
also help in such cases with my company
https://netknights.it/en/leistungen/

Kind regards
CorneliusAm Freitag, den 15.01.2016, 04:59 -0800 schrieb MKS:

Hello,

    Important questions are: 
    
    1. Why do you want to replace FeeIPA?

I thought I’d be able to use FreeIPA’s OTP (added since 4.2 version),
but unfortunately it’s impossible to have in same time enforceable OTP
+password for one locations and just password for other one, and if
user is allowed to use password also - he can bypass OTP in any time.
I even tried to setup separate dedicated FreeIPA for OTP, but FreeIPA
doesn’t allow sync hashed userPassword, only on first time with
migrate-ds, it is hardcoded. Without such synchronization it’s useless
after user will change his password on main ipa.

    2. What did you not like about FreeIPA/Dogtag?

We use Centos6 on production, which has FreeIPA 3.0 version, so they
haven’t CA support. Currently I able to sync “usercertificate” field
between FreeIPA 4.2 CA and FreeIPA 3.0 without replication configured
between them. But having separate FreeIPA just for CA is a bit
uncomfortable for us, because we need periodically sync new users from
production FreeIPA, enroll certificates for them, and then sync
certificates field back.

    3. What are you expecting from privacyIDEA?

First of all I’m planning to use privacyIDEA as centralized place for
TFA. I used google authenticator for sshd via pam for a long time, but
looks like privacyIDEA could get me more comfortable solution here,
despite that it looks like I’d have to use pam_radius and different
radius related modules for apache,nginx, etc., because run pam_python
doesn’t looks to be quite good decision for production, especially for
Centos6 hosts …
It would be very helpful if users would be able to self enroll/revoke
S/MIME certificates for them via privacyIDEA, ability to sync this
certificates from privacyIDEA to FreeIPA “usercertificate” field would
be also excellent )
Since privacyIDEA already has a webserver, it would be logical to have
OCSP/CRL on same host.
Also it’s good to know that privacyIDEA could be used with
AuthorizedKeysCommand, but since we have sssd, which doing same things
for ssh public keys from FreeIPA, it’s just ‘nice to have’ feature for
me at the moment.

    privacyIDEA does not try to be a CA. The design is to rather
    connect to 
    existing CAs to get user certificates from these CAs. 
    This is why there is the functionality to define CA
    connectors. 
    https://github.com/privacyidea/privacyidea/blob/master/privacyidea/lib/caconnectors/localca.py 
    
    At the moment there is only the localCA connector to connect
    to openssl 
    commands. OpenSSL and the openssl.cnf already work like a CA
    without the 
    need for privacyIDEA. 
    But the design idea is, to also be able to connect to other
    CAs. Even to 
    a Microsoft CA that would be responsible for issuing the CRL
    and 
    providing the OCSP. 
    This is why there is no CRL and OCSP functionality at the
    moment. 
    
    privacyIDEA tries to ease the certificate handling/management
    of 
    existing CAs. 
    
    I am curious what you think!

As you could see, I need a basic CA level for my current needs, they
could be completely covered by CA.pl, or XCA. I just wander would
privacyIDEA be able to cover not just TFA related needs, since I’m
really impressed by it’s features amount.

–
You received this message because you are subscribed to the Google
Groups “privacyidea” group.
To unsubscribe from this group and stop receiving emails from it, send
an email to privacyidea+unsubscribe@googlegroups.com.
To post to this group, send email to privacyidea@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/privacyidea/1ea9d75f-4821-4ab8-af52-68f23ae82f99%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

–
Cornelius Kölbel
@cornelinux
+49 151 2960 1417

NetKnights GmbH
http://www.netknights.it
Landgraf-Karl-Str. 19, 34131 Kassel, Germany
Tel: +49 561 3166797, Fax: +49 561 3166798

Amtsgericht Kassel, HRB 16405
Geschäftsführer: Cornelius Kölbel

signature.asc (836 Bytes)

4

Hello,

Important questions are:

  1. Why do you want to replace FeeIPA?

I thought I’d be able to use FreeIPA’s OTP (added since 4.2 version), but
unfortunately it’s impossible to have in same time enforceable OTP+password
for one locations and just password for other one, and if user is allowed
to use password also - he can bypass OTP in any time. I even tried to setup
separate dedicated FreeIPA for OTP, but FreeIPA doesn’t allow sync hashed
userPassword, only on first time with migrate-ds, it is hardcoded. Without
such synchronization it’s useless after user will change his password on
main ipa.

  1. What did you not like about FreeIPA/Dogtag?

We use Centos6 on production, which has FreeIPA 3.0 version, so they
haven’t CA support. Currently I able to sync “usercertificate” field
between FreeIPA 4.2 CA and FreeIPA 3.0 without replication configured
between them. But having separate FreeIPA just for CA is a bit
uncomfortable for us, because we need periodically sync new users from
production FreeIPA, enroll certificates for them, and then sync
certificates field back.

  1. What are you expecting from privacyIDEA?

First of all I’m planning to use privacyIDEA as centralized place for TFA.
I used google authenticator for sshd via pam for a long time, but looks
like privacyIDEA could get me more comfortable solution here, despite that
it looks like I’d have to use pam_radius and different radius related
modules for apache,nginx, etc., because run pam_python doesn’t looks to be
quite good decision for production, especially for Centos6 hosts …
It would be very helpful if users would be able to self enroll/revoke
S/MIME certificates for them via privacyIDEA, ability to sync this
certificates from privacyIDEA to FreeIPA “usercertificate” field would be
also excellent )
Since privacyIDEA already has a webserver, it would be logical to have
OCSP/CRL on same host.
Also it’s good to know that privacyIDEA could be used with
AuthorizedKeysCommand, but since we have sssd, which doing same things for
ssh public keys from FreeIPA, it’s just ‘nice to have’ feature for me at
the moment.

privacyIDEA does not try to be a CA. The design is to rather connect to
existing CAs to get user certificates from these CAs.
This is why there is the functionality to define CA connectors.

https://github.com/privacyidea/privacyidea/blob/master/privacyidea/lib/caconnectors/localca.py

At the moment there is only the localCA connector to connect to openssl
commands. OpenSSL and the openssl.cnf already work like a CA without the
need for privacyIDEA.
But the design idea is, to also be able to connect to other CAs. Even to
a Microsoft CA that would be responsible for issuing the CRL and
providing the OCSP.
This is why there is no CRL and OCSP functionality at the moment.

privacyIDEA tries to ease the certificate handling/management of
existing CAs.

I am curious what you think!

As you could see, I need a basic CA level for my current needs, they could
be completely covered by CA.pl, or XCA. I just wander would privacyIDEA be
able to cover not just TFA related needs, since I’m really impressed by
it’s features amount.

5

Hello Askon,

thanks a lot for the credit.

Important questions are:

  1. Why do you want to replace FeeIPA?
  2. What did you not like about FreeIPA/Dogtag?
  3. What are you expecting from privacyIDEA?

privacyIDEA does not try to be a CA. The design is to rather connect to
existing CAs to get user certificates from these CAs.
This is why there is the functionality to define CA connectors.

At the moment there is only the localCA connector to connect to openssl
commands. OpenSSL and the openssl.cnf already work like a CA without the
need for privacyIDEA.
But the design idea is, to also be able to connect to other CAs. Even to
a Microsoft CA that would be responsible for issuing the CRL and
providing the OCSP.
This is why there is no CRL and OCSP functionality at the moment.

privacyIDEA tries to ease the certificate handling/management of
existing CAs.

I am curious what you think!

Kind regards
CorneliusAm Donnerstag, den 14.01.2016, 14:30 -0800 schrieb MKS:

Hello, Cornelius!
Thank you for implementing new great features. Currently I’m
discovering privacyIDEA functions with hope to replace our FreeIPA
based CA server with privacyIDEA CA.
Unfortunately I didn’t found anything about CRL or OCSP with
privacyIDEA. Does it implemented already?

–
You received this message because you are subscribed to the Google
Groups “privacyidea” group.
To unsubscribe from this group and stop receiving emails from it, send
an email to privacyidea+unsubscribe@googlegroups.com.
To post to this group, send email to privacyidea@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/privacyidea/35428a3c-3f21-4526-b81b-28fb63022537%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

–
Cornelius Kölbel
@cornelinux
+49 151 2960 1417

NetKnights GmbH
http://www.netknights.it
Landgraf-Karl-Str. 19, 34131 Kassel, Germany
Tel: +49 561 3166797, Fax: +49 561 3166798

Amtsgericht Kassel, HRB 16405
Geschäftsführer: Cornelius Kölbel

signature.asc (836 Bytes)