Re: [Freeipa-users] Exposing LDAP attributes with hyphens in their names?
Hi,
see also this recent commit to get an idea how to deal with attributes
with "weird" names:
<https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=6adf86378108cdf8b0825277431419a5e803aeb5>.
On 11.5.2016 17:19, Jeffery Harrell wrote:
I’ve read Extending FreeIPA back to front (several times!) but I could
spend more time alone with an iPad and a copy of the Guide. Thanks for
the link.
On May 11, 2016 at 3:28:55 AM, Martin Kosek (mko...@redhat.com
<mailto:mko...@redhat.com>) wrote:
On 05/06/2016 07:12 PM, Jeffery Harrell wrote:
> Hi. I’m very new to IPA; I only picked it up a couple weeks ago. So this may
be
> a remedial question.
>
> I’d like to expose, both via the CLI and the GUI, certain LDAP attributes
which
> have hyphens in their names — e.g., "apple-user-homeurl.” The Param class
> rejects these attributes because of the hyphens; the name of the Param doesn’t
> conform to the regular expression so an exception gets thrown. This code does
> not work:
>
> |user.user.takes_params = user.user.takes_params + ( Str(
'apple-user-homeurl?',
> cli_name='appleuserhomeurl', label=_('Apple User Home URL'), doc=_('Apple user
> home URL.'), ), ) |
>
> Is there a sensible way of getting around that, or will I have to subclass
Param
> and write a whole bunch of new code to get this to work?
>
> Thanks very much.
>
> Jeffery
Did you check the documentation we have so far?
http://www.freeipa.org/images/5/5b/FreeIPA33-extending-freeipa.pdf
http://abbra.fedorapeople.org/guide.html
CCing Jan for reference.
Martin
--
Jan Cholasta
--
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
Re: [Freeipa-users] Looking for documentation for Python API
On 11.5.2016 10:52, Martin Kosek wrote: On 05/07/2016 09:07 AM, Joshua J. Kugler wrote: On Friday, May 06, 2016 09:04:59 Martin Basti wrote: since IPA4.2 web UI contains API browser (IPA Server/API Browser) So for example for caacl-add: api.Command.caacl_add(u'argument-ca-acl-name', description=u"optional description") you can try commands in "ipa console" it contains initialized API, just call api.Command.() API.txt provides the same information as API browser, but browser looks better :) Feel free to ask anything, if you identified gaps in docs which are hard to understand for non-IPA developer feel free report it, or feel free to create howTo in freeipa.org page. Thanks for the pointers. I'm looking at automating some user and group additions, group editing, etc. Am I right in assuming that anything that uses the api.Command. will require a kinit before it is run, even if it is via the Python API? If I want to use a user/pass from the script itself (and not have a shell script which does kinit, then fires off my Python script) would I be better off hitting the web API with sessions and JSON-RPC as detailed here: https://vda.li/en/posts/2015/05/28/talking-to-freeipa-api-with-sessions/ Put another way, since I want to hit the API from a system that might not have sssd installed, nor has joined the realm, I assume it would be *impossible* to use api.Command. as it relies on a Kerberos ticket? To put it yet another way: is there a way to hand a user/pass to the Python API and authenticate that way. The API itself can be hit with user/password, as noted in Alexander's blog. If you want to use the actual Python API, Kerberos may be the only way. But I think Jan or Petr may had some other (hacky) way to pass user+password there too. I don't think we support anything but Kerberos on the client side in our Python API. It might be possible to somehow emulate what the web UI does, but I haven't personally ever attempted to do that. Petr, have you? Those are the questions I did not see addressed in the docs that I found. There were lots of examples of invoking commands, but I never saw anything about authenticating to the server before running the commands. Thanks again for the pointers, and if there is documentation I missed, feel free to point me in that direction. -- Jan Cholasta -- 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
Re: [Freeipa-users] change CA subject or "friendly name"?
Hi, On 12.4.2016 01:08, Fraser Tweedale wrote: On Mon, Apr 11, 2016 at 11:43:17AM -0400, Anthony Clark wrote: Hello All, I'm in the process of deploying FreeIPA 4 in a development environment. One of my testers has imported the ca.pem file into Windows, and indicates that it displays as: Issued to: Certificate Authority Issued by: Certificate Authority Friendly Name: This will unfortunately cause confusion among certain end users, so I was wondering if there's a way to change those attributes? Ideally without reinstalling everything, but thankfully we're still early in the process so it's OK if do blow everything away. Do I need to generate a new CA outside of FreeIPA and then use ipa-cacert-manage to "renew" the base CA? Thanks, Anthony Clark Hi Anthony, After a brief investigation it appears that ``Friendly Name'' is a property that can be set in a Windows certificate store, and is not part of, or derived from, the certificate itself. Here are a couple of TechNet articles that might help: - https://technet.microsoft.com/en-us/library/cc740218%28v=ws.10%29.aspx - https://blogs.technet.microsoft.com/pki/2008/12/12/defining-the-friendly-name-certificate-property/ As for "Issued to" and "Issued by", I guess these are derived from the subject and issuer name fields of the certificate, which currently can't be changed for our CA certificate. We have a ticket to fix this for quite some time: <https://fedorahosted.org/freeipa/ticket/2614>. -- Jan Cholasta -- 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
Re: [Freeipa-users] Adding FreeIPA to an existing infrastructure
On 18.4.2016 12:20, Martin Kosek wrote: On 04/12/2016 12:14 PM, Remco Kranenburg wrote: Thanks for all the pointers. I'm tentatively moving forward with a CA-less and DNS-less IPA server, with Letsencrypt certificates. I think this is also the setup that is used by the demo at <https://ipa.demo1.freeipa.org/ipa/ui/>. Is there some documentation about this setup? I installed this FreeIPA Demo server with Dogtag CA and then used something like this to setup the root cert: # do this once before taking snapshot of the VM dnf install letsencrypt -y ipa-cacert-manage install le-root-ca.pem -n le-root-ca -t ,, ipa-certupdate -v ipa-cacert-manage install le-authority-x1.pem -n le-authority-x1 -t C,, ipa-certupdate -v and then generated LE certificate: # generate CSR certutil -R -d /etc/httpd/alias/ -k Server-Cert -f /etc/httpd/alias/pwdfile.txt -s "CN=$(hostname)" --extSAN "dns:$(hostname)" -a -o /root/httpd-csr.pem openssl req -in /root/httpd-csr.pem -outform der -out /root/httpd-csr.der # httpd process prevents letsencrypt from working, stop it service httpd stop # get a new cert letsencrypt certonly --csr /root/httpd-csr.der --email ...@redhat.com --agree-tos # remove old cert certutil -D -d /etc/httpd/alias/ -n Server-Cert # add the new cert certutil -A -d /etc/httpd/alias/ -n Server-Cert -t ,, -a -i /root/_cert.pem # start httpd with the new cert service httpd start but you probably do not want this as you are not installing CA piece. I'm trying to install a Letsencrypt certificate into FreeIPA, but when I run the installation: ipa-server-install --http-cert-file cert.pem --http-cert-file privkey.pem --dirsrv-cert-file cert.pem --dirsrv-cert-file privkey.pem It asks for my "Apache Server private key unlock password", even though the key from Letsencrypt is not encrypted with a passphrase. Try using empty passphrase: --http-pin= --dirsrv-pin= When I give a bogus password, it gives me another error: ipa.ipapython.install.cli.install_tool(Server): ERRORThe full certificate chain is not present in cert.pem, privkey.pem Letsencrypt provides me with a few files: cert.pem, chain.pem, fullchain.pem, privkey.pem. Even when I also add chain.pem and fullchain.pem, it gives me the same error. The error is legit, you have to specify the full CA certificate chain using --ca-cert-file. CCing JanC, he is the man to help with this one. Martin -- Jan Cholasta -- 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
Re: [Freeipa-users] CA-less vs CA-ful FreeIPA 4.2 installation
Hi Peter, On 9.2.2016 00:26, Peter Pakos wrote: Hi, I now have a CA-less installation of FreeIPA 4.2 which seems to be working OK. The initial server was installed with the following command: ipa-server-install \ -U \ -r IPA.WANDISCO.COM \ -n ipa.wandisco.com \ -p '' \ -a '' \ --mkhomedir \ --setup-dns \ --no-forwarders \ --no-dnssec-validation \ --dirsrv-cert-file=/root/ssl/GandiWildcardIPA.pfx \ --dirsrv-pin='' \ --http-cert-file=/root/ssl/GandiWildcardIPA.pfx \ --http-pin='' \ --dirsrv-cert-name=GandiWildcardIPA \ --http-cert-name=GandiWildcardIPA \ --idstart=1100 \ --ca-cert-file=/root/ssl/star.ipa.wandisco.com.crt Both LDAP and HTTP certificates are correctly installed. My question is, how do I renew LDAP/HTTP certificates? I'm struggling to find a step-by-step instructions on how to do this without breaking anything. This is one of the last tests I need to perform before moving this FreeIPA setup into production. Any info is greatly appreciated. Currently you have to manually replace the certificates once you manually renew them with your CA. To replace the certificates, follow the guide I posted a month ago: <https://www.redhat.com/archives/freeipa-users/2016-January/msg00023.html>. Honza -- Jan Cholasta -- 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
Re: [Freeipa-users] Using external certificate in IPA 4.1
Hi, On 4.2.2016 17:45, Martin Kosek wrote: On 02/03/2016 06:02 PM, Ossi Ahosalmi wrote: I'm trying to use our organizations wildcard certificate in IPA. Certificate is signed by a trusted CA. Running: ipa-server-certinstall -w -d with next combinations: - separate .key, .crt and ca chain, all in PEM format - .crt and ca bundled into one file, .key as a separate file - everything bundled together into one .p12 pkcs12 file I always end up with this error: "The full certificate chain is not present in ." My CA file contains the whole chain and works in all other programs, just not in IPA. CCing Jan, but I think you are hitting https://fedorahosted.org/freeipa/ticket/5603 Actually I think it's #4786, but if that was fixed, you would hit #5603 as well. Honza -- Jan Cholasta -- 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
Re: [Freeipa-users] Using 3rd party certificates for HTTP/LDAP
On 18.1.2016 09:07, Martin Kosek wrote: On 01/15/2016 05:34 PM, Peter Pakos wrote: On 15/01/2016 15:55, Rob Crittenden wrote: I've re-run ipa-certupdate in verbose mode and I could see that it removes all certificates in different databases (/etc/httpd/alias, /etc/pki/nssdb, /etc/pki/pki-tomcat/alias) and then re-adds them (apart from /etc/pki/pki-tomcat/alias). Yup, looks like this part is missing. Perhaps the assumption was that the CA would be authoritative in this regard. Is this a bug? Should this be logged somewhere so it can be looked into? Yes, <https://fedorahosted.org/freeipa/ticket/5600>. Updating the CA certs you'd want to add them to LDAP, replacing the older ones, and then ipa-certupdate will do the rest. You'd need to run this on all clients and servers. This sounds like a lot of manual work will be involved when it comes to renewal. And without clear and up-to-date information and possibly step-by-step instructions the effort needed to get this sorted is doubled. Please note that it took us many hours to get a 3rd party SSL certificate installed (you would think a very simple task). And the truth is that without this mailing list and #freeipa channel we would still be stuck trying to get to the bottom of this. CCing Honza. Do we have all the respective tickets filed, so that we can improve and speed up the user experience? There's <https://fedorahosted.org/freeipa/ticket/4322> for automatic CA certificate distribution and <https://fedorahosted.org/freeipa/ticket/4785> and <https://fedorahosted.org/freeipa/ticket/4786> for ipa-server-certinstall fixes. If there's anything missing, pleaes file a new ticket. -- Jan Cholasta -- 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
Re: [Freeipa-users] ipa-certupdate not installing root certificates in /etc/pki/pki-tomcat/alias/
Hi Peter, On 18.1.2016 01:32, Peter Pakos wrote: Hi, I have FreeIPA 4.2 (CA-ful) install on Centos 7.2 with 3rd party SSL certificates installed for HTTP/LDAP. When I run "ipa-certupdate" I can see that the 3rd party root certificates are being removed from databases (/etc/httpd/alias, /etc/pki/nssdb, /etc/pki/pki-tomcat/alias) and then re-added (apart from /etc/pki/pki-tomcat/alias). Without the 3rd party root certificates in /etc/pki/pki-tomcat/alias, the service pki-tomcatd is unable to start up. This is the complete process I'm following to install 3rd party certificate (please let me know if I'm doing anything wrong): ### 3rd party SSL certificate install ## # Gandi *.ipa.wandisco.com certificate chain # AddTrust.pem -> USERTrustRSAAddTrustCA.pem -> GandiStandardSSLCA2.pem -> star.ipa.wandisco.com.crt $ openssl verify -verbose -CAfile <(cat AddTrust.pem USERTrustRSAAddTrustCA.pem GandiStandardSSLCA2.pem) star.ipa.wandisco.com.crt star.ipa.wandisco.com.crt: OK # Bug in ipa-cacert-manage, comment out lines 349-352 $ vim /usr/lib/python2.7/site-packages/ipaserver/install/ipa_cacert_manage.py $ ipa-cacert-manage install AddTrust.pem -n AddTrust -t C,C,C $ ipa-cacert-manage install USERTrustRSAAddTrustCA.pem -n USERTrustRSAAddTrustCA -t C,C,C $ ipa-cacert-manage install GandiStandardSSLCA2.pem -n GandiStandardSSLCA2 -t C,C,C # Add root certificates to databases <- THIS IS WHERE THE ABOVE ROOT CERTIFICATES SHOULD BE INSTALLED IN /etc/pki/pki-tomcat/alias BUT THEY AREN'T $ ipa-certupdate # Create PKCS12 certificate file including private key and full chain $ openssl pkcs12 -export -out star.ipa.wandisco.com.pfx -inkey star.ipa.wandisco.com.key -in star.ipa.wandisco.com.crt -certfile <(cat AddTrust.pem USERTrustRSAAddTrustCA.pem GandiStandardSSLCA2.pem) -name 'GandiWildcardIPA' # Install PKCS12 certificate to LDAP and HTTP databases: $ pk12util -d /etc/dirsrv/slapd-IPA-WANDISCO-COM/ -i star.ipa.wandisco.com.pfx $ pk12util -d /etc/httpd/alias/ -i star.ipa.wandisco.com.pfx # Stop IPA $ ipactl stop # Edit /etc/dirsrv/slapd-IPA-WANDISCO-COM/dse.ldif to point dirsrv to new certificate # Replace: nsSSLPersonalitySSL: Server-Cert # with: nsSSLPersonalitySSL: GandiWildcardIPA # Edit /etc/httpd/conf.d/nss.conf to point httpd to new certificate # Replace: NSSNickname Server-Cert # with: NSSNickname GandiWildcardIPA # Start IPA $ ipactl start # In order to fix this, I have to manually add root certificates to the database: $ certutil -A -d /etc/pki/pki-tomcat/alias/ -n AddTrust -t C,C,C -a < AddTrust.pem $ certutil -A -d /etc/pki/pki-tomcat/alias/ -n USERTrustRSAAddTrustCA -t C,C,C -a < USERTrustRSAAddTrustCA.pem $ certutil -A -d /etc/pki/pki-tomcat/alias/ -n GandiStandardSSLCA2 -t C,C,C -a < GandiStandardSSLCA2.pem Should this not be done automatically by ipa-certupdate? It should: <https://fedorahosted.org/freeipa/ticket/5600>. Are the above steps correct for installing 3rd party certificates in FreeIPA 4.2? Should I change anything? Looks OK to me. We are planning to move these nodes into production very soon, any help would be much appreciated! Honza -- Jan Cholasta -- 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
Re: [Freeipa-users] CA-less vs CA-ful FreeIPA 4.2 installation
On 18.1.2016 12:42, Martin Kosek wrote: On 01/18/2016 12:05 PM, Peter Pakos wrote: On 18/01/2016 08:06, Martin Kosek wrote: I am hoping that this is well explained here: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/install-examples.html#install-ca-options Some useful notes are also Dmitri Pal's blog post: http://rhelblog.redhat.com/2015/06/02/identity-management-and-certificates/ Thanks for the docs. I'm trying to get my head around this... if I have a working CA-ful FreeIPA setup and then install 3rd party SSL certificates for HTTP/LDAP only (including 3 root CA certs from the chain) - does this replace original self-signed CA that FreeIPA generated (and becomes External CA install) or does CA stay untouched and I can still take advantage of all the goodies that come with CA-ful install like automatic certificates renewals (apart from HTTP/LDAP ones)? Or does this became a multi CA install? BTW, I can see that the root certificates are getting added to /etc/ipa/ca.crt. You should be still able to benefit from all the goodies the CA-ful FreeIPA has. As you noticed above, all root CA certs should be added to ca.crt (see help for ipa-certupdate tool), it is used to update certs on server/client and add the new CA certificates. I'm also thinking ahead, when it comes to renewing certificates when they expire in 1 year time, which install type would cause less problems? In CA-ful installation, client certificates or FreeIPA CA subsystem certificates should just renew automatically. In CA-less, you need to take care to renew them manually with your 3rd party certificate provider. So in my CA-ful install with 3rd party SSL certificate installed, how would the renewal look? All certificates issued by FreeIPA CA should be renewed automatically by certmonger (if configured). External certificates should needs to be renewed manually. Honza, does certmonger already warns about non-IPA certificates that are getting close to expiration date or is this rather an RFE for future? It's an RFE, covered by my "certmonger everywhere" proposal: <https://www.redhat.com/archives/freeipa-devel/2015-December/msg00475.html> (the part about uniform certmonger configuration). I understand that I would have to install new HTTP/LDAP certificates manually as they were signed by external CA, but would all certificates issued by FreeIPA CA still renew automatically? They should, yes. I've failed to find any useful info covering the above points, so if you know anything, please just let me know. I think the important point is that even if you choose to install with CA-less for now, you can switch to CA-ful later via ipa-ca-install: http://www.freeipa.org/page/V4/CA-less_to_CA-full_conversion Thank you, your help is much appreciated! -- Jan Cholasta -- 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
Re: [Freeipa-users] Using 3rd party certificates for HTTP/LDAP
Hi Peter, On 21.12.2015 17:43, Peter Pakos wrote: Hi, I tried to install a wildcard SSL certificate for HTTP/LDAP in our FreeIPA 4.1 (Centos 7.1) installation by following instructions from wiki page at http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP: Unfortunately ipa-server-certinstall is currently broken. We plan to fix it some day, see <https://fedorahosted.org/freeipa/ticket/4785> and <https://fedorahosted.org/freeipa/ticket/4786>. # ipa-server-certinstall -w -d shdc01.ipa.wandisco.com.pem Directory Manager password: Enter private key unlock password: Command /usr/bin/certutil' '-d' '/etc/httpd/alias' '-D' '-n' 'Server-Cert returned non-zero exit status 255 After this I was unable to start httpd service, error_log revealed the following error messages: [Wed Nov 25 18:15:44.262751 2015] [:error] [pid 22124] Certificate not found: 'Server-Cert' In order to resurrect the service I had to change NSSNickname in /etc/httpd/conf.d/nss.conf to match the new certificate's nickname. Although the httpd service started, I couldn't get into Authentication tab in FreeIPA UI - I kept getting the following error message: "Unable to communicate with CMS (Service Unavailable)". [root@shdc01 ~]# yum list installed | grep ipa-server ipa-server.x86_64 4.1.0-18.el7.centos.4 @updates [root@shdc01 ~]# cat /etc/redhat-release CentOS Linux release 7.1.1503 (Core) At this point I was forced to restore our FreeIPA installation from a snapshot as I wasn't able to fix it (I got some useful hints from #freeipa Freenode channel however we still didn't manage to fully resurrect the server). My question is, what is the correct way of installing a 3rd party certificate for HTTP/LDAP that will actually work? 1. Install the CA certificate chain of the issuer of the 3rd party certificate to IPA using "ipa-cacert-manage install" 2. Run "ipa-certupdate" to update CA certificate related IPA configuration. 3. Manually import the server certificate into the /etc/dirsrv/slapd-REALM NSS database, configure the correct nickname in LDAP in the nsSSLPersonalitySSL attribute of cn=RSA,cn=encryption,cn=config and restart DS. 4. Manually import the server certificate into the /etc/httpd/alias NSS database, configure the correct nickname in /etc/httpd/conf.d/nss.conf using the NSSNickname directive and restart httpd. Many thanks in advance. BTW, I also added a comment describing this problem to the ticket at https://fedorahosted.org/freeipa/ticket/5496. Honza -- Jan Cholasta -- 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
Re: [Freeipa-users] Using 3rd party certificates for HTTP/LDAP
On 4.1.2016 14:10, Peter Pakos wrote: Hi Jan, On 04/01/2016 12:44, Jan Cholasta wrote: 1. Install the CA certificate chain of the issuer of the 3rd party certificate to IPA using "ipa-cacert-manage install" 2. Run "ipa-certupdate" to update CA certificate related IPA configuration. 3. Manually import the server certificate into the /etc/dirsrv/slapd-REALM NSS database, configure the correct nickname in LDAP in the nsSSLPersonalitySSL attribute of cn=RSA,cn=encryption,cn=config and restart DS. 4. Manually import the server certificate into the /etc/httpd/alias NSS database, configure the correct nickname in /etc/httpd/conf.d/nss.conf using the NSSNickname directive and restart httpd. Would it be the same procedure for FreIPA 4.2 shipped with Centos 7.2? Yes. -- Jan Cholasta -- 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
Re: [Freeipa-users] Yum update broke CA/CS - pki-tomcatd not starting
tl /var/log/pki/pki-tomcat/localhost.2015-12-11.log SEVERE: Servlet.service() for servlet [caGetStatus] in context with path [/ca] threw exception java.io.IOException: CS server is not ready to serve. /var/log/dirsrv/slapd-PLANWEE-LOCAL/errors [11/Dec/2015:01:02:19 +0200] - slapd started. Listening on All Interfaces port 389 for LDAP requests [11/Dec/2015:01:02:19 +0200] - Listening on All Interfaces port 636 for LDAPS requests [11/Dec/2015:01:02:19 +0200] - Listening on /var/run/slapd-PLANWEE-LOCAL.socket for LDAPI requests [11/Dec/2015:01:02:19 +0200] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [11/Dec/2015:01:02:19 +0200] slapi_ldap_bind - Error: could not perform interactive bind for id [] authentication mechanism [GSSAPI]: error -1 (Can't contact LDAP server) /var/log/pki/pki-tomcat/ca/debug Internal Database Error encountered: Could not connect to LDAP server host ipa1.backend.planwee.local port 636 Error netscape.ldap.LDAPException: IO Error creating JSS SSL Socket (-1) Environment: CentOS 7 IPA 4.1 The problem looks the same as this: https://access.redhat.com/solutions/2022123 Unfortunately I cannot view resolution. is this related to expired CA certificates? If you have expired certificates (you can check with "# getcert list | grep expires"), it could cause issues like that also. The article you are referring to is rather around wrong CA certificate trust attributes in /var/lib/pki/pki-tomcat/alias/ or /etc/dirsrv/slapd-EXAMPLE-COM/ NSS databases. You can check that with # certutil -L -d /var/lib/pki/pki-tomcat/alias/ # certutil -L -d /etc/dirsrv/slapd-EXAMPLE-COM/ BTW, if you want to see the whole article or other articles from the large KB, I would suggest getting a subscription :-) -- Jan Cholasta -- 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
Re: [Freeipa-users] ipa-replica-prepare error
Dne 30.7.2015 v 17:28 Orion Poplawski napsal(a):
On 07/28/2015 11:09 PM, Jan Cholasta wrote:
Dne 20.7.2015 v 19:52 Orion Poplawski napsal(a):
On 07/20/2015 12:57 AM, Jan Cholasta wrote:
Dne 15.7.2015 v 20:57 Orion Poplawski napsal(a):
On 07/14/2015 11:53 PM, Jan Cholasta wrote:
# ipa-replica-prepare -v ipa1.nwra.com --dirsrv_pkcs12=nwra.com.p12
--dirsrv_pin=XX --http_pkcs12=nwra.com.p12 --http_pin=XX
Directory Manager (existing master) password:
(SEC_ERROR_LIBRARY_FAILURE) security library failure.
I was able to debug this in gdb and tracked it down to a low entropy
condition. Details noted in https://fedorahosted.org/freeipa/ticket/5117.
Looks like prng_instantiate is being called 2-3 times and there just isn't
enough entropy:
Breakpoint 1, prng_instantiate (rng=0x7fffe5f9d3a0 theGlobalRng,
bytes=bytes@entry=0x7fffc220 \304(\336\350F8\375㨟\177\325\017+\302
\230\e\215\bf\201Rw;\300\260\330\366\315\342\235\034]\374J\324\263,
len=110) at drbg.c:160
160 if (len PRNG_SEEDLEN) {
1: len = 110
(gdb) c
Continuing.
Breakpoint 1, prng_instantiate (rng=rng@entry=0x7fffe5f9f620 testContext,
bytes=bytes@entry=0x2153b70
\216\234\r%u\\004\371\305y\020\213#y7\024\237,\307\v9\370\356\357\225\f\227Y\374\n\205A\240;\025\002,
len=len@entry=32) at drbg.c:160
160 if (len PRNG_SEEDLEN) {
1: len = 32
PRNG_SEEDLEN is 55 I think.
I wouldn't have thought that this might be the cause.
Thank you for the investigation!
--
Jan Cholasta
--
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
Re: [Freeipa-users] CA-less replica setup and trouble with cert chain
Hi, Dne 29.7.2015 v 00:56 Mike Oliver napsal(a): Hi folks, We're trying to add a FreeIPA (4.1; CentOS 7) replica to our infrastructure and keep running into an issue that prevents us from preparing the replica. We're using the CA-less setup where FreeIPA is using a wildcard certificate provided by RapidSSL. I started trying to create the replica using the information provided here : https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/creating-the-replica.html But since we're not using a CA, it tells me that I need to specify --http-cert-file and --dirsrv-cert-file. I create a p12 file that includes the wildcard cert and the rest of the certs in the chain with: $ openssl pkcs12 -export -in wildcard-with-intermediates.crt -inkey wildcard.key -name replica01 -out replica01.mydomain.com.p12 I then check to see if all the necessary certs were added to the p12 file: $ pk12util -l replica01.mydomain.com.p12 I see our wildcard certificate, RapidSSL's intermediate certificate, and the entry for Equifax/GeoTrust, that signed RapidSSL's certificate. Then I run 'ipa-replica-prepare' on the existing FreeIPA server. $ ipa-replica-prepare replica01.mydomain.com \ --http-cert-file=replica01.mydomain.com.p12 \ --dirsrv-cert-file=replica01.mydomain.com.p12 \ --ca /etc/ipa/ca.crt \ -v Note that you can use the .crt and .key files directly: $ ipa-replica-prepare replica01.mydomain.com --http-cert-file=wildcard-with-intermediates.crt --http-cert-file=wildcard.key --dirsrv-cert-file=wildcard-with-intermediates.crt --dirsrv-cert-file=wildcard.key I get the following error after the debug output reports a series of calls to certutil: ipa: DEBUG: stderr= ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG: File /usr/lib/python2.7/site-packages/ipapython/admintool.py, line 169, in execute self.ask_for_options() File /usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py, line 262, in ask_for_options options.http_cert_name) File /usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py, line 162, in load_pkcs12 host_name=self.replica_fqdn) File /usr/lib/python2.7/site-packages/ipaserver/install/installutils.py, line 799, in load_pkcs12 (, .join(cert_files))) ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG: The ipa-replica-prepare command failed, exception: ScriptError: The full certificate chain is not present in replica01.mydomain.com.p12 ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: ERROR: The full certificate chain is not present in replicate01.mydomain.com.p12 The chain certainly looks to be complete given the output of pk12util, but it's possible I'm just building the file wrong for use with FreeIPA. What exactly is '--http-cert-file' and '--dirsrv-cert-file' expecting and how should I go about generating the certificate used by 'ipa-replica-prepare' with a CA-less configuration? If the chain is complete, there should be a self-signed CA certificate at the top. For you that would be the Equifax/GeoTrust certificate. If it's not self-signed, it means the chain is in fact not complete. Thanks all, Honza -- Jan Cholasta -- 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
Re: [Freeipa-users] ipa-replica-prepare error
Dne 20.7.2015 v 19:52 Orion Poplawski napsal(a): On 07/20/2015 12:57 AM, Jan Cholasta wrote: Dne 15.7.2015 v 20:57 Orion Poplawski napsal(a): On 07/14/2015 11:53 PM, Jan Cholasta wrote: # ipa-replica-prepare -v ipa1.nwra.com --dirsrv_pkcs12=nwra.com.p12 --dirsrv_pin=XX --http_pkcs12=nwra.com.p12 --http_pin=XX Directory Manager (existing master) password: (SEC_ERROR_LIBRARY_FAILURE) security library failure. Not much :( Seems to be very early. I can't find an ipa-replica-prepare.log file. That's weird, there should be ~50 lines of output before ipa-replica-prepare prompts you for directory manager password. I didn't have any luck in reproducing the issue so far. Could you please try this: $ mkdir tmpdb $ certutil -N -d tmpdb $ pk12util -i nwra.com.p12 $ certutil -L -d tmpdb # look for nickname of certificate which has trust attributes of u,u,u $ certutil -O -d tmpdb -n nickname # use the nickname from above I would like to see the output of the last 2 commands. [root@europa ~]# pk12util -i nwra.com.p12 -d tmpdb Enter Password or Pin for NSS Certificate DB: Enter password for PKCS12 file: pk12util: no nickname for cert in PKCS12 file. pk12util: using nickname: *.nwra.com - COMODO CA Limited pk12util: PKCS12 IMPORT SUCCESSFUL [root@europa ~]# certutil -L -d tmpdb Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI COMODO RSA Domain Validation Secure Server CA - COMODO CA Limited ,, AddTrust External CA Root - AddTrust AB ,, *.nwra.com - COMODO CA Limited u,u,u COMODO RSA Certification Authority - AddTrust AB ,, [root@europa ~]# certutil -O -d tmpdb -n '*.nwra.com - COMODO CA Limited' AddTrust External CA Root - AddTrust AB [CN=AddTrust External CA Root,OU=AddTrust External TTP Network,O=AddTrust AB,C=SE] COMODO RSA Certification Authority - AddTrust AB [CN=COMODO RSA Certification Authority,O=COMODO CA Limited,L=Salford,ST=Greater Manchester,C=GB] COMODO RSA Domain Validation Secure Server CA - COMODO CA Limited [CN=COMODO RSA Domain Validation Secure Server CA,O=COMODO CA Limited,L=Salford,ST=Greater Manchester,C=GB] *.nwra.com - COMODO CA Limited [CN=*.nwra.com,OU=PositiveSSL Wildcard,OU=Domain Control Validated] Thanks. Unfortunately it looks perfectly fine, so I still have no idea what's wrong. This is a long shot, but coult you try running ipa-replica-prepare in strace and post the log of that? # strace -o ipa-replica-prepare-strace.log ipa-replica-prepare ipa1.nwra.com --dirsrv_pkcs12=nwra.com.p12 --dirsrv_pin=XX --http_pkcs12=nwra.com.p12 --http_pin=XX -- Jan Cholasta -- 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
Re: [Freeipa-users] ipa-replica-prepare error
Dne 15.7.2015 v 20:57 Orion Poplawski napsal(a): On 07/14/2015 11:53 PM, Jan Cholasta wrote: Hi, Dne 10.7.2015 v 22:33 Orion Poplawski napsal(a): On 07/08/2015 11:31 AM, Orion Poplawski wrote: But then when I go to make a replica: # ipa-replica-prepare ipa1.nwra.com --dirsrv_pkcs12=nwra.com.p12 --dirsrv_pin=XX --http_pkcs12=nwra.com.p12 --http_pin=XX Directory Manager (existing master) password: (SEC_ERROR_LIBRARY_FAILURE) security library failure. Which looks like others are experiencing (with not resolution that I could see) https://www.redhat.com/archives/freeipa-users/2015-April/msg00514.html Unfortunately this error code can mean almost anything, NSS isn't particularly helpful with errors. Putting AddTrustExternalCARoot into nwra.com.p12 doesn't appear to help. Filed https://fedorahosted.org/freeipa/ticket/5117 Without ipa-replica-prepare log or pk12util output it's really hard to tell what's going on. Could you provide the output of the following commands: # pk12util -l nwra.com.p12 Certificate(has private key): Data: Version: 3 (0x2) Serial Number: 00:d1:3f:8c:79:cf:1c:87:53:f0:05:7c:f6:56:18:3a: 5c Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption Issuer: CN=COMODO RSA Domain Validation Secure Server CA,O=COMODO CA Limited,L=Salford,ST=Greater Manchester,C=GB Validity: Not Before: Thu Oct 11 00:00:00 2012 Not After : Sun Jan 10 23:59:59 2016 Subject: CN=*.nwra.com,OU=PositiveSSL Wildcard,OU=Domain Control Val idated Subject Public Key Info: Public Key Algorithm: PKCS #1 RSA Encryption RSA Public Key: Modulus: d8:08:80:96:8f:f0:80:86:cd:f0:e7:6a:11:7f:8e:fb: 4b:95:6a:42:93:c7:cf:c3:76:80:bd:a6:cc:6c:fd:e2: 89:1a:3f:97:c1:3d:2d:fe:e4:4a:90:c5:aa:33:97:b3: 54:cc:67:73:57:2d:cb:9f:d0:27:ea:f0:d8:9b:5d:24: 94:2f:f5:84:06:d4:04:e8:83:c5:b2:40:b1:59:2c:f8: 4f:73:9c:41:fc:8d:46:3d:be:46:e7:9f:15:5d:8c:a5: 47:23:de:e2:cf:b3:be:97:ed:0c:82:3e:00:29:b7:8b: a0:86:92:ec:07:00:8b:35:77:1c:27:ba:c8:a0:80:dc: 9a:69:dd:99:89:df:b4:70:f6:f6:8c:23:8b:f9:1d:bf: ba:07:32:36:17:bc:25:e7:fb:7a:b0:11:86:de:88:59: 51:ed:e5:de:5e:14:e5:c0:28:ce:d3:5b:92:38:de:fa: 4b:15:9d:62:13:69:31:5a:0d:21:6e:2e:a6:c6:ae:30: 94:95:ce:e6:6c:dc:22:71:b4:1a:3a:f9:ec:4b:72:e4: 9d:82:ba:6b:a5:46:b0:b7:5a:23:22:d3:92:57:5b:bf: 55:fd:70:df:36:13:9c:a9:df:50:6e:62:43:23:13:eb: f5:ef:ee:c7:15:e0:46:37:21:9b:3d:86:ea:2c:c7:01 Exponent: 65537 (0x10001) Signed Extensions: Name: Certificate Authority Key Identifier Key ID: 90:af:6a:3a:94:5a:0b:d8:90:ea:12:56:73:df:43:b4: 3a:28:da:e7 Name: Certificate Subject Key ID Data: e9:88:f0:50:0f:f6:09:89:5c:3d:53:70:38:ca:82:22: 42:7e:21:e3 Name: Certificate Key Usage Critical: True Usages: Digital Signature Key Encipherment Name: Certificate Basic Constraints Critical: True Data: Is not a CA. Name: Extended Key Usage TLS Web Server Authentication Certificate TLS Web Client Authentication Certificate Name: Certificate Policies Data: Policy Name: OID.1.3.6.1.4.1.6449.1.2.2.7 Policy Qualifier Name: PKIX CPS Pointer Qualifier Policy Qualifier Data: https://secure.comodo.com/CPS; Policy Name: OID.2.23.140.1.2.1 Name: CRL Distribution Points Distribution point: URI: http://crl.comodoca.com/COMODORSADomainValidationSecure ServerCA.crl Name: Authority Information Access Method: PKIX CA issuers access method Location: URI: http://crt.comodoca.com/COMODORSADomainValidationSecure ServerCA.crt Method: PKIX Online Certificate Status Protocol Location: URI: http://ocsp.comodoca.com; Name: Certificate Subject Alt Name DNS name: *.nwra.com DNS name: nwra.com Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption Signature: 54:10:0f:42:9a:1f:42:df:1d:4e:e2:b8:bb:9f:c2:fc: e1:d7:b7:02:c5:9f:ed:5a:f1:d7:b4:58:23:ab:3c:a7: d3:9a:8d:71:f5:f4:a1:8b:02:0f:ce:ec:79:30:90:09: 41:fe:03:0d:0a:ee:44:ea:f0:9b:c0:e4
Re: [Freeipa-users] ipa-replica-prepare error
Hi, Dne 10.7.2015 v 22:33 Orion Poplawski napsal(a): On 07/08/2015 11:31 AM, Orion Poplawski wrote: But then when I go to make a replica: # ipa-replica-prepare ipa1.nwra.com --dirsrv_pkcs12=nwra.com.p12 --dirsrv_pin=XX --http_pkcs12=nwra.com.p12 --http_pin=XX Directory Manager (existing master) password: (SEC_ERROR_LIBRARY_FAILURE) security library failure. Which looks like others are experiencing (with not resolution that I could see) https://www.redhat.com/archives/freeipa-users/2015-April/msg00514.html Unfortunately this error code can mean almost anything, NSS isn't particularly helpful with errors. Putting AddTrustExternalCARoot into nwra.com.p12 doesn't appear to help. Filed https://fedorahosted.org/freeipa/ticket/5117 Without ipa-replica-prepare log or pk12util output it's really hard to tell what's going on. Could you provide the output of the following commands: # pk12util -l nwra.com.p12 # ipa-replica-prepare -v ipa1.nwra.com --dirsrv_pkcs12=nwra.com.p12 --dirsrv_pin=XX --http_pkcs12=nwra.com.p12 --http_pin=XX ? Honza -- Jan Cholasta -- 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
Re: [Freeipa-users] using pathlen:0 for freeipa's CA certificate?
Dne 15.5.2015 v 09:31 Martin Kosek napsal(a): On 05/15/2015 09:22 AM, Fraser Tweedale wrote: On Fri, May 15, 2015 at 07:59:27AM +0200, Jan Cholasta wrote: Hi, Dne 5.5.2015 v 10:43 Martin Kosek napsal(a): On 05/04/2015 01:19 PM, Harald Dunkel wrote: Hi folks, Instead of a self-signed certificate I would like to use an external CA to sign freeipa's CSR (ipa-server-install --external-ca). Question: Is pathlen:0, e.g. basicConstraints=critical,CA:TRUE, pathlen:0 sufficient for freeipa's CA certificate? I would say it should be sufficient for FreeIPA CA for now, given it does not allow subordinate CAs. However, I am still CCing Fraser and Honza for reference, in case there would be some limitation in Dogtag/our CA certificate that would limit use of the basicConstraints extension. I'm not aware of any. Yes, currently it is sufficient. When FreeIPA has sub-CAs capability, a pathLenConstraint of zero will prevent the creation of valid sub-CAs. Martin, Jan, this is a situation I had not considered. I propose that we should detect pathLenConstraint and error out if sub-CAs creation is attempted at a depth that cannot be valid. If you agree I will add to design document. I agree. Please also add a ticket for this part. The check can be IMO added to FreeIPA 4.2.1, it is not critical for 4.2 GA. I believe there would be other things to check as well, e.g. directoryName name constraints. Note that this basiConstrain would surely prevent you from using the upcoming feature http://www.freeipa.org/page/V4/Sub-CAs but this is OK with you, I assume. BTW, Fraser, we should record a task to properly watch for the pathlen limitation and have nice error messages around it when admin attempts to use Sub-CAs. Final note, there is a related ticket: https://fedorahosted.org/freeipa/ticket/3466 Martin Honza -- Jan Cholasta -- Jan Cholasta -- 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
Re: [Freeipa-users] using pathlen:0 for freeipa's CA certificate?
Hi, Dne 5.5.2015 v 10:43 Martin Kosek napsal(a): On 05/04/2015 01:19 PM, Harald Dunkel wrote: Hi folks, Instead of a self-signed certificate I would like to use an external CA to sign freeipa's CSR (ipa-server-install --external-ca). Question: Is pathlen:0, e.g. basicConstraints=critical,CA:TRUE, pathlen:0 sufficient for freeipa's CA certificate? I would say it should be sufficient for FreeIPA CA for now, given it does not allow subordinate CAs. However, I am still CCing Fraser and Honza for reference, in case there would be some limitation in Dogtag/our CA certificate that would limit use of the basicConstraints extension. I'm not aware of any. Note that this basiConstrain would surely prevent you from using the upcoming feature http://www.freeipa.org/page/V4/Sub-CAs but this is OK with you, I assume. BTW, Fraser, we should record a task to properly watch for the pathlen limitation and have nice error messages around it when admin attempts to use Sub-CAs. Final note, there is a related ticket: https://fedorahosted.org/freeipa/ticket/3466 Martin Honza -- Jan Cholasta -- 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
Re: [Freeipa-users] ipa-replica-prepare failing
Hi, yes, you can definitely use a different certificate in the meantime, although it can't be self-signed. Honza Dne 20.4.2015 v 14:17 David Dejaeghere napsal(a): Hi, Let me know how I can assist. In the meantime could I setup a replica using a different certificate? Self signed or anything like that? Regards, D 2015-04-17 15:27 GMT+02:00 Jan Cholasta jchol...@redhat.com mailto:jchol...@redhat.com: Hi, I don't have any new information. I'm trying to reproduce the problem but had no luck so far. Honza Dne 17.4.2015 v 15:23 David Dejaeghere napsal(a): Hi, Any more things I can try out? How do we proceed? Kind Regards, D 2015-04-15 11:48 GMT+02:00 David Dejaeghere david.dejaegh...@gmail.com mailto:david.dejaegh...@gmail.com mailto:david.dejaegh...@gmail.com mailto:david.dejaegh...@gmail.com: Hi Honza, That gave me the exact same output. Any ideas? Regards, D 2015-04-15 7:33 GMT+02:00 Jan Cholasta jchol...@redhat.com mailto:jchol...@redhat.com mailto:jchol...@redhat.com mailto:jchol...@redhat.com: Hi, Dne 14.4.2015 v 19:47 Rob Crittenden napsal(a): David Dejaeghere wrote: Hi Rob, So you want to output of the command using pk12 with server cert and key? or with the ca chain in there too? Oddly enough it is failing in exactly the same place. Those GoDaddy CA certs are still being loaded from somewhere, I'm not sure where, and I suspect that is the source of the problem. They are in the default CA certificate bundle (in the ca-certificate package). I guess NSS loads it automatically. I'm going to forward the log to a colleague who has worked on this code more recently than I have. Maybe he will have an idea. Could you try if the following works? # mv /usr/share/pki/ca-trust-__source/ca-bundle.trust.crt /root/ca-bundle.trust.crt # update-ca-trust # ipa-replica-prepare ... # mv /root/ca-bundle.trust.crt /usr/share/pki/ca-trust-__source/ca-bundle.trust.crt # update-ca-trust rob Honza -- Jan Cholasta -- Jan Cholasta -- Jan Cholasta -- 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
Re: [Freeipa-users] ipa-replica-prepare failing
Hi, I don't have any new information. I'm trying to reproduce the problem but had no luck so far. Honza Dne 17.4.2015 v 15:23 David Dejaeghere napsal(a): Hi, Any more things I can try out? How do we proceed? Kind Regards, D 2015-04-15 11:48 GMT+02:00 David Dejaeghere david.dejaegh...@gmail.com mailto:david.dejaegh...@gmail.com: Hi Honza, That gave me the exact same output. Any ideas? Regards, D 2015-04-15 7:33 GMT+02:00 Jan Cholasta jchol...@redhat.com mailto:jchol...@redhat.com: Hi, Dne 14.4.2015 v 19:47 Rob Crittenden napsal(a): David Dejaeghere wrote: Hi Rob, So you want to output of the command using pk12 with server cert and key? or with the ca chain in there too? Oddly enough it is failing in exactly the same place. Those GoDaddy CA certs are still being loaded from somewhere, I'm not sure where, and I suspect that is the source of the problem. They are in the default CA certificate bundle (in the ca-certificate package). I guess NSS loads it automatically. I'm going to forward the log to a colleague who has worked on this code more recently than I have. Maybe he will have an idea. Could you try if the following works? # mv /usr/share/pki/ca-trust-__source/ca-bundle.trust.crt /root/ca-bundle.trust.crt # update-ca-trust # ipa-replica-prepare ... # mv /root/ca-bundle.trust.crt /usr/share/pki/ca-trust-__source/ca-bundle.trust.crt # update-ca-trust rob Honza -- Jan Cholasta -- Jan Cholasta -- 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
Re: [Freeipa-users] ipa-replica-prepare failing
Hi, Dne 14.4.2015 v 19:47 Rob Crittenden napsal(a): David Dejaeghere wrote: Hi Rob, So you want to output of the command using pk12 with server cert and key? or with the ca chain in there too? Oddly enough it is failing in exactly the same place. Those GoDaddy CA certs are still being loaded from somewhere, I'm not sure where, and I suspect that is the source of the problem. They are in the default CA certificate bundle (in the ca-certificate package). I guess NSS loads it automatically. I'm going to forward the log to a colleague who has worked on this code more recently than I have. Maybe he will have an idea. Could you try if the following works? # mv /usr/share/pki/ca-trust-source/ca-bundle.trust.crt /root/ca-bundle.trust.crt # update-ca-trust # ipa-replica-prepare ... # mv /root/ca-bundle.trust.crt /usr/share/pki/ca-trust-source/ca-bundle.trust.crt # update-ca-trust rob Honza -- Jan Cholasta -- 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
Re: [Freeipa-users] Replica with external ca + custom subject in certificate
Dne 8.4.2015 v 17:43 James James napsal(a): It's a little bit more clear. Thanks. I have created a new ipa 4.1 replica but when I want run : # ipa-cacert-manage renew --self-signed I've got this message : [root@ipa-devel-centos7 ~]# ipa-cacert-manage renew --self-signed CA is not configured on this system You can run ipa-cacert-manage only on IPA servers with CA installed. If I want to install the CA I've got this message : [root@ipa-devel-centos7 system]# ipa-ca-install --password=mypassorwd -U CA is already installed. This command is used to install CA in CA-less IPA environment. The error message is a bit misleading and we have a ticket for that: https://fedorahosted.org/freeipa/ticket/4492. Should I have to promote the replica to a standalone master before installing the CA ? You need to run ipa-ca-install with the replica info file used to create the replica to install the CA: # ipa-ca-install path to replica info file Any hints will be appreciated... James 2015-04-08 7:27 GMT+02:00 Jan Cholasta jchol...@redhat.com mailto:jchol...@redhat.com: Dne 7.4.2015 v 15:31 Martin Kosek napsal(a): On 04/07/2015 02:08 PM, James James wrote: I will try to give a better explanation : I have a CentOS 6.6 with ipa 3.0 named ipa-master. ipa-master has been installed with an external CA about 3 years ago and I will have to renew the certificate soon. I have created a test server (ipa-dev) with the same configuration (centos 6.6 and ipa 3.0) to test the renewal process. I want the new ipa-dev sever to be installed with an external CA. In the same time my external CA has changed and wants the emailAddress field in the certificate request 's subject. CSR during installation with external CA is produced by Dogtag, so you are constrained with the options and capabilities provided by ipa-server-install. Maybe it would be possible to modify the CSR and update the Subject manually, but I expect it would crash the installer later (JanC may know more (CCed)) The subject name identifies the CA in server (and other) certificates. If you change it, you break the trust chain from the CA certificate to the server certificates and that will break all SSL in IPA. If it is not possible to add emailAddress in the subject, is it possible to migrate my ipa-master CA system from an external CA to a CA-less or self-signed CA ? It is, with ipa-cacert-manage - see links below. You can change your external CA to self-signed CA in IPA 4.1 or newer by running: # ipa-cacert-manage renew --self-signed You can't change external CA to CA-less. Thanks. 2015-04-07 13:48 GMT+02:00 Martin Kosek mko...@redhat.com mailto:mko...@redhat.com: On 04/07/2015 01:44 PM, James James wrote: ok. Is there a way to migrate from an external CA to a CA-less or a self-signed CA ? Yes, you can use ipa-cacert-manage tool introduced in FreeIPA 4.1.0: https://www.freeipa.org/page/__Howto/CA_Certificate_Renewal https://www.freeipa.org/page/Howto/CA_Certificate_Renewal https://www.freeipa.org/page/__V4/CA_certificate_renewal https://www.freeipa.org/page/V4/CA_certificate_renewal (Although I am still not sure about your use case and if this would help you) 2015-04-07 12:51 GMT+02:00 Martin Kosek mko...@redhat.com mailto:mko...@redhat.com: On 04/03/2015 11:39 AM, James James wrote: Hello, I want to initialize a new replica with an external CA. My Certificate Authority wants a CSR with the field emailAddress in the subject like : /C=FR/O=TESTO/OU=TESTOU/CN=*.e__xample.com/emailAddress=none@__none.com http://example.com/emailAddress=n...@none.com I am not a bit confused. Do you plan to have FreeIPA *without* a CA or with own CA signed by external CA? FreeIPA supports these kinds of setups right now: http://www.freeipa.org/page/__PKI#Blending_in_PKI___infrastructure http://www.freeipa.org/page/PKI#Blending_in_PKI_infrastructure
Re: [Freeipa-users] Replica with external ca + custom subject in certificate
Dne 7.4.2015 v 15:31 Martin Kosek napsal(a): On 04/07/2015 02:08 PM, James James wrote: I will try to give a better explanation : I have a CentOS 6.6 with ipa 3.0 named ipa-master. ipa-master has been installed with an external CA about 3 years ago and I will have to renew the certificate soon. I have created a test server (ipa-dev) with the same configuration (centos 6.6 and ipa 3.0) to test the renewal process. I want the new ipa-dev sever to be installed with an external CA. In the same time my external CA has changed and wants the emailAddress field in the certificate request 's subject. CSR during installation with external CA is produced by Dogtag, so you are constrained with the options and capabilities provided by ipa-server-install. Maybe it would be possible to modify the CSR and update the Subject manually, but I expect it would crash the installer later (JanC may know more (CCed)) The subject name identifies the CA in server (and other) certificates. If you change it, you break the trust chain from the CA certificate to the server certificates and that will break all SSL in IPA. If it is not possible to add emailAddress in the subject, is it possible to migrate my ipa-master CA system from an external CA to a CA-less or self-signed CA ? It is, with ipa-cacert-manage - see links below. You can change your external CA to self-signed CA in IPA 4.1 or newer by running: # ipa-cacert-manage renew --self-signed You can't change external CA to CA-less. Thanks. 2015-04-07 13:48 GMT+02:00 Martin Kosek mko...@redhat.com: On 04/07/2015 01:44 PM, James James wrote: ok. Is there a way to migrate from an external CA to a CA-less or a self-signed CA ? Yes, you can use ipa-cacert-manage tool introduced in FreeIPA 4.1.0: https://www.freeipa.org/page/Howto/CA_Certificate_Renewal https://www.freeipa.org/page/V4/CA_certificate_renewal (Although I am still not sure about your use case and if this would help you) 2015-04-07 12:51 GMT+02:00 Martin Kosek mko...@redhat.com: On 04/03/2015 11:39 AM, James James wrote: Hello, I want to initialize a new replica with an external CA. My Certificate Authority wants a CSR with the field emailAddress in the subject like : /C=FR/O=TESTO/OU=TESTOU/CN=*.example.com/emailAddress=n...@none.com I am not a bit confused. Do you plan to have FreeIPA *without* a CA or with own CA signed by external CA? FreeIPA supports these kinds of setups right now: http://www.freeipa.org/page/PKI#Blending_in_PKI_infrastructure How can I do with the ipa-server-install command ? I have been trying for few days but I still can't. Thanks for your help. CCing Honza who should know the definitive answer. However, FreeIPA was not very flexible in configuring special subjects for it's CA certificate (i.e. cn=Certificate Authority, ou=...) or hosts in case of CA-less setup. -- Jan Cholasta -- 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
Re: [Freeipa-users] Troubleshooting SSO
: session_new: allocate
(allocated 0 max 10)
Mar 30 13:33:47 mid-ipa-vp01 sshd[13750]: debug3: session_unused: session
id 0 unused
Mar 30 13:33:47 mid-ipa-vp01 sshd[13750]: debug1: session_new: session 0
Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug3:
mm_request_receive_expect entering: type 29
Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug3: mm_request_receive
entering
Mar 30 13:33:47 mid-ipa-vp01 sshd[13750]: debug1: SELinux support enabled
Mar 30 13:33:47 mid-ipa-vp01 sshd[13750]: debug3: ssh_selinux_setup_pty:
setting TTY context on /dev/pts/2
Mar 30 13:33:47 mid-ipa-vp01 sshd[13750]: debug3: ssh_selinux_setup_pty:
done
Mar 30 13:33:47 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send
entering: type 29
Mar 30 13:33:47 mid-ipa-vp01 sshd[13750]: debug3: mm_answer_pty: tty
/dev/pts/2 ptyfd 5
Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug1: session_pty_req: session
0 alloc /dev/pts/2
Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug1:
server_input_channel_req: channel 0 request shell reply 1
Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug1: session_by_channel:
session 0 channel 0
Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug1:
session_input_channel_req: session 0 req shell
Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: Starting session: shell on pts/2
for adm-faru03@test.osuwmc from 10.80.5.239 port 65333
Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug2: fd 3 setting TCP_NODELAY
Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug3: packet_set_tos: set
IP_TOS 0x10
Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug2: channel 0: rfd 14 isatty
Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug2: fd 14 setting O_NONBLOCK
Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug3: fd 12 is O_NONBLOCK
Mar 30 13:33:47 mid-ipa-vp01 sshd[13762]: debug1: Setting controlling tty
using TIOCSCTTY.
Mar 30 13:33:47 mid-ipa-vp01 sshd[13762]: debug3: mm_request_send
entering: type 124
Mar 30 13:33:47 mid-ipa-vp01 sshd[13762]: debug3:
mm_request_receive_expect entering: type 125
Mar 30 13:33:47 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive
entering
Mar 30 13:33:47 mid-ipa-vp01 sshd[13762]: debug3: mm_request_receive
entering
Mar 30 13:33:47 mid-ipa-vp01 sshd[13750]: debug3: monitor_read: checking
request 124
Mar 30 13:33:47 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send
entering: type 125
Mar 30 13:33:47 mid-ipa-vp01 sshd[13762]: debug3: Copy environment:
KRB5CCNAME=FILE:/tmp/krb5cc_1398410_B30vDK
Mar 30 13:33:47 mid-ipa-vp01 sshd[13762]: debug3: Copy environment:
SELINUX_ROLE_REQUESTED=
Mar 30 13:33:47 mid-ipa-vp01 sshd[13762]: debug3: Copy environment:
SELINUX_LEVEL_REQUESTED=
Mar 30 13:33:47 mid-ipa-vp01 sshd[13762]: debug3: Copy environment:
SELINUX_USE_CURRENT_RANGE=
Mar 30 13:33:47 mid-ipa-vp01 sshd[13762]: debug3: Copy environment:
XDG_SESSION_ID=10
Mar 30 13:33:47 mid-ipa-vp01 sshd[13762]: debug3: Copy environment:
XDG_RUNTIME_DIR=/run/user/1398410
Just in case, here is my krb5.conf
includedir /var/lib/sss/pubconf/krb5.include.d/
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
default_realm = UNIX.TEST.OSUWMC
dns_lookup_realm = true
dns_lookup_kdc = true
rdns = false
ticket_lifetime = 24h
forwardable = yes
udp_preference_limit = 0
# default_ccache_name = KEYRING:persistent:%{uid}
[realms]
UNIX.TEST.OSUWMC = {
kdc = mid-ipa-vp01.unix.test.osuwmc:88
master_kdc = mid-ipa-vp01.unix.test.osuwmc:88
admin_server = mid-ipa-vp01.unix.test.osuwmc:749
default_domain = unix.test.osuwmc
pkinit_anchors = FILE:/etc/ipa/ca.crt
# auth_to_local =
RULE:[1:$1@$0](^.*@TEST.OSUWMC$)s/@TEST.OSUWMC/@test.osuwmc/
# auth_to_local = RULE:[1:$1 $0](^ *
TEST.OSUWMC$)s/@TEST.OSUWMC/@test.osuwmc/
auth_to_local = DEFAULT
}
[domain_realm]
.unix.test.osuwmc = UNIX.TEST.OSUWMC
unix.test.osuwmc = UNIX.TEST.OSUWMC
[dbmodules]
UNIX.TEST.OSUWMC = {
db_library = ipadb.so
}
I'm not sure if this would be of any help to you, but in case you have
GSSAPI credential delegation enabled in PuTTY, you also need to allow
them to be delegated to the IPA server using:
$ ipa host-mod ipa server fqdn --ok-as-delegate=1
Honza
--
Jan Cholasta
--
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
Re: [Freeipa-users] nsAccountLock attribute
Hi, Dne 1.4.2015 v 07:09 Prashant Bapat napsal(a): Hi , Is there a way of making the nsAccountLock attribute (User enable/disable) to be anonymously readable ? I'm trying to implement a SSH key lookup sshd authorized key command script. Based on this attribute the user will be allowed to login. I need this to be anonymously readable. Tried setting the permissions but it does not work. Any other ideas on this ? If your SSH server is a properly configured IPA host (i.e. you had run ipa-client-install or ipa-server-install on it), rejecting locked user login should work automatically, without having to configure anything. Thanks for your help. --Prashant -- Jan Cholasta -- 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
Re: [Freeipa-users] IPA 4.1.0 in RHEL 7.1
Dne 12.3.2015 v 08:25 Martin Kosek napsal(a): On 03/11/2015 09:05 PM, Dmitri Pal wrote: On 03/11/2015 03:15 PM, Erinn Looney-Triggs wrote: ... Third, there appears to be a behavior change from in ipalib. I cleaned up a little inventory script for ansible, you can take a look at it here: https://github.com/ansible/ansible/blob/devel/plugins/inventory/freeipa.py Before RHEL 7.1 the call to api.Command.hostgroup_find()['result'] on line 30 worked, now it fails: Traceback (most recent call last): File ./freeipa.py, line 133, in module list_groups(api) File ./freeipa.py, line 71, in list_groups result = api.Command.host_find()['result'] File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 439, in __call__ ret = self.run(*args, **options) File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 755, in run return self.forward(*args, **options) File /usr/lib/python2.7/site-packages/ipalib/frontend.py, line 776, in forward return self.Backend.rpcclient.forward(self.name, *args, **kw) File /usr/lib/python2.7/site-packages/ipalib/rpc.py, line 880, in forward command = getattr(self.conn, name) File /usr/lib/python2.7/site-packages/ipalib/backend.py, line 97, in __get_conn self.id, threading.currentThread().getName()) AttributeError: no context.rpcclient in thread 'MainThread' Is this expected? Is this a regression? Some things changed. I would leave for developers to take a look and provide more guidance. Erinn, it may help us if you share the whole sequence how you bootstrap and authenticatoin the API. Honza, was there any related change causing ^^^? https://fedorahosted.org/freeipa/ticket/3299 There is api.Backend.xmlclient.connect() in the code, but JSON-RPC is now used by default. This can be fixed by calling api.Backend.rpcclient.connect() instead. -- Jan Cholasta -- 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
Re: [Freeipa-users] ipa-server setup with external CA fails
/Mar/2015:17:17:24][localhost-startStop-1]: SignedAuditEventFactory: create() message=[AuditEvent=CIMC_CERT_VERIFICATION][SubjectID=$System$][Outcome=F ai lure][CertNickName=ocspSigningCert cert-pki-ca] CIMC certificate verification [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: verifySystemCerts() cert tag=sslserver [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: verifySystemCertByNickname(): calling isCertValid() [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: verifySystemCertByNickname() failed:Server-Cert cert-pki-ca [10/Mar/2015:17:17:24][localhost-startStop-1]: SignedAuditEventFactory: create() message=[AuditEvent=CIMC_CERT_VERIFICATION][SubjectID=$System$][Outcome=F ai lure][CertNickName=Server-Cert cert-pki-ca] CIMC certificate verification [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: verifySystemCerts() cert tag=subsystem [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: verifySystemCertByNickname(): calling isCertValid() [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: verifySystemCertByNickname() failed:subsystemCert cert-pki-ca [10/Mar/2015:17:17:24][localhost-startStop-1]: SignedAuditEventFactory: create() message=[AuditEvent=CIMC_CERT_VERIFICATION][SubjectID=$System$][Outcome=F ai lure][CertNickName=subsystemCert cert-pki-ca] CIMC certificate verification [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: verifySystemCerts() cert tag=audit_signing [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: verifySystemCertByNickname(): calling isCertValid() [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: verifySystemCertByNickname() passed:auditSigningCert cert-pki-ca [10/Mar/2015:17:17:24][localhost-startStop-1]: SignedAuditEventFactory: create() message=[AuditEvent=CIMC_CERT_VERIFICATION][SubjectID=$System$][Outcome=S uc cess][CertNickName=auditSigningCert cert-pki-ca] CIMC certificate verification [10/Mar/2015:17:17:24][localhost-startStop-1]: SignedAuditEventFactory: create() message=[AuditEvent=SELFTESTS_EXECUTION][SubjectID=$System$][Outcome=Fail ur e] self tests execution (see selftests.log for details) The selftests.log contradicts itself and I¹m not really sure where to look next. Any ideas? Joshua Which version is it? A similar problem have been seen with the early IPA 3.3 version and was related to the format of the cert file returned by AD. AFAIR it contains more certs that we expected. Something along those lines. I am CCing Jan Cholasta who was fixing very similar error in IPA 3.3.3 in RHEL-7.0 (should have been fixed in RHEL-7.1), he should have more context. I am also CCing Endi from Dogtag team, he may also have some idea from PKI side. HTH, Martin I would like to see /root/ipa.crt and /etc/pki/pki-tomcat/ca/CS.cfg. Without them, I can't really tell what's wrong. -- Jan Cholasta -- 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
Re: [Freeipa-users] Promoting ipa 4.1 on Centos 7 replica to master
Hi, I have updated http://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master with information for IPA 4.0+. Honza Dne 15.1.2015 v 17:46 Rui Gomes napsal(a): Hello Rob, Thank you for the quick reply, I will give it a go, I wasn't sure if the links would work since most the of configuration for the dogtag in centos7 is different and commands like: getcert list -d /var/lib/pki-ca/alias -n subsystemCert cert-pki-ca | grep post-save Do not apply, I will try to accommodate for the difference in versions, I might bug you guys again :) Regards Rui Gomes - Original Message - From: Rob Crittenden rcrit...@redhat.com To: Rui Gomes rgo...@rvx.is, freeipa-users@redhat.com Sent: Thursday, 15 January, 2015 16:20:46 Subject: Re: [Freeipa-users] Promoting ipa 4.1 on Centos 7 replica to master Rui Gomes wrote: Hello Guys, I been seeing planting of email about promoting replicas to masters but does articles do not seem to apply to ipa 4.1/centos 7 combo. I had a ipa 3.0 master on centos 6.4 that died recently(I can still access the file system), and I would like to promote my 4.1 replica to the master. I tried: http://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master and: http://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/promoting-replica.html But they don't seem relevant to that specific setup, centos 7/ipa 4.1 can you guys give me some pointer how can I get my 4.1 replica to master? Regards Rui Gomes Every server in IPA is a master, the only distinction being whether it has a CA installed or not, and to a lesser extend DNS (all masters have the data, some may just not run the service). So if you have a master with a CA then you have a full IPA master. The only thing that distinguishes one master from another is due to order of installation due to two things that should only be done on one master: generate the CRL and handle CA subsysutem certificate renewal. The first IPA master installed is given these duties. To switch the CRL generator use the first link. The page is going to be updated soon to reflect how renewal should be handled on 4.0+ servers. The renewal master is now stored in LDAP so switching it is a lot easier. rob -- Jan Cholasta -- 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
Re: [Freeipa-users] I think I trashed my FreeIPA CA - how to recover?
Dne 15.1.2015 v 15:29 Bill Peck napsal(a): On Thu, Jan 15, 2015 at 3:26 AM, Jan Cholasta jchol...@redhat.com mailto:jchol...@redhat.com wrote: Hi, Dne 14.1.2015 v 14:54 Brian Topping napsal(a): Hi Martin, thanks for your response! What I realize now is the certificate CRL points to the server that no longer exists and I'd like to get that cleaned up. I found http://www.freeipa.org/page/__Howto/Promote_CA_to_Renewal___and_CRL_Master http://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master http://www.freeipa.org/page/__Howto/Promote_CA_to_Renewal___and_CRL_Master http://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master, is that relevant for my situation? Yes, this is the procedure to follow for servers older than FreeIPA 4.1. Jan is that correct? If yes, the page deserves a warning/update. This is the procedure to follow on IPA 4.0. On IPA = 4.0, the information about renewal master is stored in LDAP, but you still have to handle CRL master manually. I'm still not clear what needs to be done on IPA = 4.0 when promoting a new CRL master. Can that page be updated to state these instructions are for IPA 4.0 and include the manual piece you mention for IPA = 4.0? Thanks I have updated the page with information for current versions of IPA. Ooof! I forgot that vendor repos were so far behind. I'm still at 3.3.3-28. Is it reasonable and desirable to run one of my two servers with the image documented at http://seven.centos.org/2014/__12/freeipa-4-1-2-and-centos http://seven.centos.org/2014/12/freeipa-4-1-2-and-centos? I'm interested in integrating Shiro or some other RBAC against IPA at some point in the next few months, but I'd wait if the Docker image is a prelude to 4.x hitting vendor repos soon. Cheers, Brian Honza -- Jan Cholasta -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/__mailman/listinfo/freeipa-users https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project -- Jan Cholasta -- 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
Re: [Freeipa-users] I think I trashed my FreeIPA CA - how to recover?
Hi, Dne 14.1.2015 v 14:54 Brian Topping napsal(a): Hi Martin, thanks for your response! What I realize now is the certificate CRL points to the server that no longer exists and I'd like to get that cleaned up. I found http://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master http://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master, is that relevant for my situation? Yes, this is the procedure to follow for servers older than FreeIPA 4.1. Jan is that correct? If yes, the page deserves a warning/update. This is the procedure to follow on IPA 4.0. On IPA = 4.0, the information about renewal master is stored in LDAP, but you still have to handle CRL master manually. Ooof! I forgot that vendor repos were so far behind. I'm still at 3.3.3-28. Is it reasonable and desirable to run one of my two servers with the image documented at http://seven.centos.org/2014/12/freeipa-4-1-2-and-centos? I'm interested in integrating Shiro or some other RBAC against IPA at some point in the next few months, but I'd wait if the Docker image is a prelude to 4.x hitting vendor repos soon. Cheers, Brian Honza -- Jan Cholasta -- 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
Re: [Freeipa-users] Antwort: Re: Antwort: Re: Antwort: Re: Multiple Domains and SSH
Right, I forgot that this is the way IPA sent multi-value primary keys before version 4.0, sorry. If you require working web UI, the only alternative is adding a host entry for each hostname then. Dne 21.11.2014 v 13:56 Christoph Kaminski napsal(a): no have added it in 2 fqdn attributes MfG Christoph Kaminski Von: Jan Cholasta jchol...@redhat.com An: Christoph Kaminski christoph.kamin...@biotronik.com Kopie: freeipa-users@redhat.com freeipa-users@redhat.com Datum: 21.11.2014 11:09 Betreff: Re: Antwort: Re: Antwort: Re: [Freeipa-users] Multiple Domains and SSH It seems you added ipaclient.mgmt.hss.int,ipaclient.hss.int to fqdn, instead of adding ipaclient.mgmt.hss.int and ipaclient.hss.int separately. Dne 21.11.2014 v 11:05 Christoph Kaminski napsal(a): with ipa 3.3.0 work your second solution but if I do it then I get errors in the gui if I go to the hosts settings there Error: ipaclient.mgmt.hss.int,ipaclient.hss.int: host not found both names are in configured as A Record in dns MfG Christoph Kaminski Von: Jan Cholasta jchol...@redhat.com An: Christoph Kaminski christoph.kamin...@biotronik.com Kopie: Jakub Hrozek jhro...@redhat.com, Dmitri Pal d...@redhat.com, freeipa-users@redhat.com freeipa-users@redhat.com Datum: 20.11.2014 13:08 Betreff: Re: Antwort: Re: [Freeipa-users] Multiple Domains and SSH Hi, Dne 19.11.2014 v 09:45 Christoph Kaminski napsal(a): this is an example of a host here and the ways how can I reach it via ssh: (they are all in dns forward and reverse resolving) (note I redacted the hostnames and IP addresses in the output below) host host.mgmt host.mgmt has address 192.168.1.1 host 192.168.1.1 1.1.168.192.in-addr.arpa domain name pointer host.mgmt. host host.mydom.int host.mydom.int has address 192.168.2.1 host 192.168.2.1 1.2.168.192.in-addr.arpa domain name pointer host.mydom.int. host host.mydom.net host.mydom.net has address 192.168.3.1 host 192.168.3.1 1.3.168.192.in-addr.arpa domain name pointer host.mydom.net. So it's a host with multiple IP addresses? You have 2 options then: 1. Add a host entry with the SSH public key to IPA for each of the hostnames then, as Dmitri suggested. 2. Manually add the additional hostnames to the fqdn attribute of the host entry using ldapmodify. MfG Christoph Kaminski Von: Jan Cholasta jchol...@redhat.com An: Jakub Hrozek jhro...@redhat.com, d...@redhat.com Kopie: freeipa-users@redhat.com Datum: 19.11.2014 07:53 Betreff: Re: [Freeipa-users] Multiple Domains and SSH Gesendet von: freeipa-users-boun...@redhat.com Hi, Dne 18.11.2014 v 23:53 Jakub Hrozek napsal(a): On 18 Nov 2014, at 23:12, Dmitri Pal d...@redhat.com wrote: On 11/18/2014 01:07 AM, Christoph Kaminski wrote: Hi I can reach each host here via ssh on multiple domains: host.mydom.int host mydom.net host.mgmt sss_ssh_knownhostproxy does work only on the domain which I have use to register to ipa (mgmt), on the other domains I get ever The authenticity of host 'host.mydom.int (no hostip for proxy command)' can't be established why? Because it does not know that the hostnames refer to the same host. Do you have a reverse DNS record set up for the host? Does it point to the same hostname that you used to register the host in IPA? And other hosts in those domains are not registered? May be you should try to add a host entry and SSH digest to IPA even if they are not enrolled? This would work too. Maybe Honza would have some tips for debugging... See pages 13-16 of http://www.freeipa.org/images/1/10/Freeipa30_SSSD_OpenSSH_integration.pdf. Honza -- Jan Cholasta -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org http://freeipa.org/ http://freeipa.org/http://freeipa.org/for more info on the project www.biotronik.comhttp://www.biotronik.com http://www.biotronik.com/http://www.biotronik.com/ *BIOTRONIK - excellence for life* Established with the development of the first German pacemaker in 1963, BIOTRONIK has upheld the highest quality standards in the fields of cardiac rhythm management and vascular intervention in more than 100 countries worldwide. We’ve developed advanced technologies and products
Re: [Freeipa-users] Antwort: Re: Multiple Domains and SSH
Hi, Dne 19.11.2014 v 09:45 Christoph Kaminski napsal(a): this is an example of a host here and the ways how can I reach it via ssh: (they are all in dns forward and reverse resolving) (note I redacted the hostnames and IP addresses in the output below) host host.mgmt host.mgmt has address 192.168.1.1 host 192.168.1.1 1.1.168.192.in-addr.arpa domain name pointer host.mgmt. host host.mydom.int host.mydom.int has address 192.168.2.1 host 192.168.2.1 1.2.168.192.in-addr.arpa domain name pointer host.mydom.int. host host.mydom.net host.mydom.net has address 192.168.3.1 host 192.168.3.1 1.3.168.192.in-addr.arpa domain name pointer host.mydom.net. So it's a host with multiple IP addresses? You have 2 options then: 1. Add a host entry with the SSH public key to IPA for each of the hostnames then, as Dmitri suggested. 2. Manually add the additional hostnames to the fqdn attribute of the host entry using ldapmodify. MfG Christoph Kaminski Von: Jan Cholasta jchol...@redhat.com An: Jakub Hrozek jhro...@redhat.com, d...@redhat.com Kopie: freeipa-users@redhat.com Datum: 19.11.2014 07:53 Betreff: Re: [Freeipa-users] Multiple Domains and SSH Gesendet von: freeipa-users-boun...@redhat.com Hi, Dne 18.11.2014 v 23:53 Jakub Hrozek napsal(a): On 18 Nov 2014, at 23:12, Dmitri Pal d...@redhat.com wrote: On 11/18/2014 01:07 AM, Christoph Kaminski wrote: Hi I can reach each host here via ssh on multiple domains: host.mydom.int host mydom.net host.mgmt sss_ssh_knownhostproxy does work only on the domain which I have use to register to ipa (mgmt), on the other domains I get ever The authenticity of host 'host.mydom.int (no hostip for proxy command)' can't be established why? Because it does not know that the hostnames refer to the same host. Do you have a reverse DNS record set up for the host? Does it point to the same hostname that you used to register the host in IPA? And other hosts in those domains are not registered? May be you should try to add a host entry and SSH digest to IPA even if they are not enrolled? This would work too. Maybe Honza would have some tips for debugging... See pages 13-16 of http://www.freeipa.org/images/1/10/Freeipa30_SSSD_OpenSSH_integration.pdf. Honza -- Jan Cholasta -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org http://freeipa.org/for more info on the project www.biotronik.com http://www.biotronik.com *BIOTRONIK - excellence for life* Established with the development of the first German pacemaker in 1963, BIOTRONIK has upheld the highest quality standards in the fields of cardiac rhythm management and vascular intervention in more than 100 countries worldwide. We’ve developed advanced technologies and products such as BIOTRONIK Home Monitoring®, Closed Loop Stimulation (CLS) and Orsiro, the industry’s first hybrid drug eluting stent. BIOTRONIK also offers the broadest portfolio of cardiac devices with ProMRI®, an advanced technology that gives patients access to magnetic resonance (MR) scanning. BIOTRONIK SE Co. KG Woermannkehre 1, 12359 Berlin, Germany Sitz der Gesellschaft: Berlin, Registergericht: Berlin HRA 6501 Vertreten durch ihre Komplementärin: BIOTRONIK MT SE Sitz der Gesellschaft: Berlin, Registergericht: Berlin HRB 118866 B Geschäftsführende Direktoren: Christoph Böhmer, Dr. Lothar Krings This e-mail and the information it contains including attachments are confidential and meant only for use by the intended recipient(s); disclosure or copying is strictly prohibited. If you are not addressed, but in the possession of this e-mail, please notify the sender immediately and delete the document. Honza -- Jan Cholasta -- 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
Re: [Freeipa-users] Multiple Domains and SSH
Hi, Dne 18.11.2014 v 23:53 Jakub Hrozek napsal(a): On 18 Nov 2014, at 23:12, Dmitri Pal d...@redhat.com wrote: On 11/18/2014 01:07 AM, Christoph Kaminski wrote: Hi I can reach each host here via ssh on multiple domains: host.mydom.int host mydom.net host.mgmt sss_ssh_knownhostproxy does work only on the domain which I have use to register to ipa (mgmt), on the other domains I get ever The authenticity of host 'host.mydom.int (no hostip for proxy command)' can't be established why? Because it does not know that the hostnames refer to the same host. Do you have a reverse DNS record set up for the host? Does it point to the same hostname that you used to register the host in IPA? And other hosts in those domains are not registered? May be you should try to add a host entry and SSH digest to IPA even if they are not enrolled? This would work too. Maybe Honza would have some tips for debugging... See pages 13-16 of http://www.freeipa.org/images/1/10/Freeipa30_SSSD_OpenSSH_integration.pdf. Honza -- Jan Cholasta -- 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
Re: [Freeipa-users] Third party SSL certificate renewal
Hi Dragan, first of all sorry for the delay, I was on leave last week. Dne 24.10.2014 v 20:31 Dragan Prostran napsal(a): Hi Jan, I'm grateful for your help. I've researched how to follow your recommendations above, but I'm not having a lot of luck. According to old posts in this mailing list, https://www.redhat.com/archives/freeipa-users/2013-May/msg00199.html, the command ipa-server-certinstall is the way to go. That said, I found an issue you've filed to allow for this, and it was implemented in FreeIPA 3.3: https://fedorahosted.org/freeipa/ticket/3641 Unfortunately, this system is running FreeIPA 3.0: # rpm -qa | grep -P ipa[_-] ipa-pki-common-theme-9.0.3-7.el6.noarch ipa-server-selinux-3.0.0-26.el6_4.4.x86_64 ipa-pki-ca-theme-9.0.3-7.el6.noarch ipa-client-3.0.0-26.el6_4.4.x86_64 ipa-admintools-3.0.0-26.el6_4.4.x86_64 libipa_hbac-1.9.2-82.10.el6_4.x86_64 libipa_hbac-python-1.9.2-82.10.el6_4.x86_64 ipa-python-3.0.0-26.el6_4.4.x86_64 ipa-server-3.0.0-26.el6_4.4.x86_64 # I've found these instructions: http://www.freeipa.org/page/Howto/CA_Certificate_Renewal. I've read those instructions, and I believe I may have a misconception about this process. The procedure calls to: # cp /root/ipa.crt /usr/share/ipa/html/ca.crt # cp /root/ipa.crt /etc/ipa/ca.crt Can you clear up what /root/ipa.crt ought to contain? I assume it ought to contain *only* the root CA certificate which is the *first* key in the bundle provided by the 3rd party Certificate Authority. Is that correct? The instructions you have found do not apply entirely in your situation. The file /etc/ipa/ca.crt should contain only the *leaf* CA cert, i.e. the one with subject name equal to issuer name in your LDAP/HTTP server certs. The file /usr/share/ipa/html/ca.crt should contain the whole CA cert chain. The files /etc/ip/ca.crt already exists, but it is a single certificate. The file I have, issued alongside with the certificate by GoDaddy, is a CA bundle. It contains 3 public keys in sequence in a single file. Could you please be more detailed as to how to accomplish this: you need to import the CA certificate to NSS databases at /etc/dirsrv/slapd-DIRSRV_REDACTED, /etc/httpd/alias and /etc/pki/nssdb, copy it to /etc/ipa/ca.crt and /usr/share/ipa/html/ca.crt and update cn=CAcert,cn=ipa,cn=etc,dc=example,dc=com in LDAP with it. Once you have the correct CA cert in /etc/ipa/ca.crt, you can run the following command to import the cert to each NSS database: # certutil -d path -A -n nickname -t C,, -a -i /etc/ipa/ca.crt (use any nickname you like) For the LDAP update, see Update the CA in LDAP in the instructions you have found. I certainly hope these are not inappropriate questions: I'd just like to ensure this is done correctly. Thank you. Don't worry, these are very appropriate questions ;-) --- Dragan Prostran On Fri, Oct 24, 2014 at 6:12 AM, Jan Cholasta jchol...@redhat.com wrote: Hi, Dne 24.10.2014 v 04:36 Dragan Prostran napsal(a): Hello, This is my first time posting to this list, so if I've made a faux pas or mistake, please do correct me. Can anyone please point me to the correct method to renewing 3rd party SSL certificates used by FreeIPA 3.0? I suspect I've not done this correctly. Here is what has worked correctly so far: 1. FreeIPA is installed and configured to work correctly. It uses 3rd party SSL certificates. I have access to the CSR, the certificate, the private key, and the new CA bundle. 2. I have successfully followed these instructions to update the SSL certificates used by Apache to serve the FreeIPA web interface: http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP. Of note is that there are 2 IPA servers, and the procedure has been followed on both. 3. Upon visiting the FreeIPA web interface, I can see that the certificate is valid, and expires in the future. Login to FreeIPA and modifying (for example) an LDAP password, work correctly. 4. 3rd party services that take advantage of LDAP work correctly. I can login and authenticate via LDAP. Here is what does not work correctly: 1. A distinct, 3rd party webservice that takes advantage of LDAP *via SSL* no longer is able to authenticate. Prior to certificate update mentioned, this did work correctly. I must admit I'm unfamiliar with LDAP (via SSL), and so instead of troubleshooting that service, I had a closer look at the FreeIPA instance. The 3rd party webservice needs to trust the CA certificate of the LDAP server certificate in order for this to work. 2. When connected to the FreeIPA instance, and issuing 'ipa user-status username', the following error is returned: ipa: ERROR: cert validation failed for CN=CERT_CN_REDACTED,OU=Domain Control Validated ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as not trusted by the user.) ipa: ERROR: cert validation failed for CN=CERT_CN_REDACTED,OU=Domain Control Validated ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked
Re: [Freeipa-users] Third party SSL certificate renewal
/ca.crt and update cn=CAcert,cn=ipa,cn=etc,dc=example,dc=com in LDAP with it. --- Dragan Prostran Honza -- Jan Cholasta -- 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
Re: [Freeipa-users] migration 3.3-4.1 CA change
Hi, Dne 23.10.2014 v 08:47 Petr Spacek napsal(a): On 22.10.2014 22:06, William Graboyes wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hello List, So the whole not being able to change the CA easily is becoming a regular point of contention in meetings. If I have read the e-mails on this list correctly this issue is fixed in 4.1. After spending a large amount of time thinking about this, I believe I have come to a solution that will appease management, my coworkers, and myself. Here is what I am thinking of doing. I am thinking I will install FC21 VM with free-IPA (which should be 4.1) then migrating my current install over there, followed by changing the CA to that of my contracted CA and third party issuer. The questions that come to mind are: 1) how does one migrate the information over to a new install, in this case 3.3 to 4.1 on separate servers? You should be able to simply add FreeIPA 4.1 replica to existing 3.3 deployment. Please make sure that your 3.3 it updated with latest packages, older versions of DS had some problems with replication to newest version AFAIK. 2) is there any documentation on the process of changing the CA in 4.1? Honza, can you add some details? You can fid more info at http://www.freeipa.org/page/V4/CA_certificate_renewal 3) am I insane for wanting to introduce FC21 into my environment? 4) has anyone done this, and what was your experience with doing so? Honza -- Jan Cholasta -- 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
Re: [Freeipa-users] Installing a new Cert
Hi, Dne 25.8.2014 v 03:04 Chris Whittle napsal(a): Trying to do this http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP And I keep getting Error unable to get local issuer certificate getting chain. Where are you getting this error? ipa-server-certinstall, or httpd, or somewhere else? What version of ipa do you have installed? I'm wondering if it's because of this from the doc The certificate in mysite.crt must be signed by the CA used when installing FreeIPA. but it might not either... In this case you should get a file.p12 is not signed by /etc/ipa/ca.crt, or the full certificate chain is not present in the PKCS#12 file error in ipa-server-certinstall. Any ideas? Honza -- Jan Cholasta -- 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
Re: [Freeipa-users] ca.crt contains more than one certificate
Hi,
Dne 8.8.2014 v 14:46 Nicklas Björk napsal(a):
Trying to upgrade from FreeIPA 3.0 running on CentOS 6 to 3.3 on CentOS
7 using migration. I seem to have run into some certificate problems and
the replica installation halts half-way through. We have a simple
CA-structure, where FreeIPA has been installed as a sub-ca directly
under ca root ca.
A replica bundle was created on the master using:
ipa-replica-prepare replica.example.net --ip-address 192.168.100.2
the gpg-file was copied to replica:/var/lib/ipa and the following
command was executed:
ipa-replica-install --mkhomedir -d --setup-ca --setup-dns
--no-forwarders /var/lib/ipa/replica-info-replica.example.net.gpg
During the first attempt, I was instructed to also run
copy-schema-to-ca.py on the master server, which has been done. The
replica installation halts complainig that ca.crt contains more than one
certificate. Both the FreeIPA CA and the Root CA certificates are in
that file.
Debug output in /var/log/ipareplica-install.log tells the following:
2014-08-08T12:22:08Z DEBUG [17/34]: configuring ssl for ds instance
2014-08-08T12:22:08Z DEBUG Loading Index file from
'/var/lib/ipa/sysrestore/sysrestore.index'
2014-08-08T12:22:08Z DEBUG Starting external process
2014-08-08T12:22:08Z DEBUG args=/usr/bin/certutil -d
/etc/dirsrv/slapd-EXAMPLE-NET/ -N -f
/etc/dirsrv/slapd-EXAMPLE-NET//pwdfile.txt
2014-08-08T12:22:08Z DEBUG Process finished, return code=0
2014-08-08T12:22:08Z DEBUG stdout=
2014-08-08T12:22:08Z DEBUG stderr=
2014-08-08T12:22:08Z DEBUG Starting external process
2014-08-08T12:22:08Z DEBUG args=/usr/bin/pk12util -d
/etc/dirsrv/slapd-EXAMPLE-NET/ -i
/tmp/tmpNOzZ3cipa/realm_info/dscert.p12 -k
/etc/dirsrv/slapd-EXAMPLE-NET//pwdfile.txt -v -w /dev/stdin
2014-08-08T12:22:08Z DEBUG Process finished, return code=0
2014-08-08T12:22:08Z DEBUG stdout=pk12util: PKCS12 IMPORT SUCCESSFUL
2014-08-08T12:22:08Z DEBUG stderr=
2014-08-08T12:22:08Z DEBUG Starting external process
2014-08-08T12:22:08Z DEBUG args=/usr/bin/certutil -d
/etc/dirsrv/slapd-EXAMPLE-NET/ -L
2014-08-08T12:22:08Z DEBUG Process finished, return code=0
2014-08-08T12:22:08Z DEBUG stdout=
Certificate Nickname Trust
Attributes
SSL,S/MIME,JAR/XPI
Server-Cert u,u,u
CN=Example Root CA,O=Example AB,,
EXAMPLE.NET IPA CA ,,
2014-08-08T12:22:08Z DEBUG stderr=
2014-08-08T12:22:08Z DEBUG Starting external process
2014-08-08T12:22:08Z DEBUG args=/usr/bin/certutil -d
/etc/dirsrv/slapd-EXAMPLE-NET/ -A -n CA -t CT,CT, -a
2014-08-08T12:22:08Z DEBUG Process finished, return code=0
2014-08-08T12:22:08Z DEBUG stdout=
2014-08-08T12:22:08Z DEBUG stderr=
2014-08-08T12:22:08Z DEBUG File
/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py,
line 638, in run_script
return_value = main_function()
File /usr/sbin/ipa-replica-install, line 664, in main
ds = install_replica_ds(config)
File /usr/sbin/ipa-replica-install, line 189, in install_replica_ds
ca_file=config.dir + /ca.crt,
File
/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py, line
360, in create_replica
self.start_creation(runtime=60)
File /usr/lib/python2.7/site-packages/ipaserver/install/service.py,
line 364, in start_creation
method()
File
/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py, line
606, in enable_ssl
ca_file=self.ca_file)
File /usr/lib/python2.7/site-packages/ipaserver/install/certs.py,
line 841, in create_from_pkcs12
self.nssdb.import_pem_cert('CA', 'CT,CT,', ca_file)
File /usr/lib/python2.7/site-packages/ipaserver/install/certs.py,
line 240, in import_pem_cert
location)
2014-08-08T12:22:08Z DEBUG The ipa-replica-install command failed,
exception: ValueError: /tmp/tmpNOzZ3cipa/realm_info/ca.crt contains more
than one certificate
Is there anything obvious that is wrong or odd with this setup or process?
It seems you somehow ended up with more than one certificate in
/etc/ipa/ca.crt on the master. It should contain only the IPA CA
certificate, if you delete all other certificates from it and re-run
ipa-replica-prepare, you should be able to successfully install the
replica using ipa-replica-install.
Best regards
Nicklas Björk
Honza
--
Jan Cholasta
--
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
Re: [Freeipa-users] FreeIPA + Foreman 1.5
on the system rather than a part of the template and it would check the package version available and use only applicable options. Again here I would like to hear the opinion of the list. It seems to me that all integration options are available in 6.4 (see above). The only exception is SUDO which needs to be configured manuallyP: - /etc/nsswitch.conf - NIS domain name - /etc/sssd/sssd.conf - configuration is different based on SSSD version. In 6.4 and 6.4, you need to manually configure SSSD SUDO LDAP provider (slide 12 in http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf), in 6.6/7.0 you will be able to just add sudo service in SSSD and utilize SSSD SUDO IPA provider. With FreeIPA 4.0, you do not need to do anything, you have SUDO client configuration for free. HTH, Martin -- Jan Cholasta ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] using 3rd party cert not self sign cert in ipa
On 25.3.2014 10:27, barry...@gmail.com wrote: Dear all: whe install it already genrate a self sign cert called mydomain.com http://mydomain.com . and run ca service. now i want to check if it ok to install 3rd party replcacing ..so to httpd my ldap it will be https: my co domain (official cert ). and replcabelow. /etc/ipa/ca.crt /usr/share/ipa/html/ca.crt You don't have to touch these files if you only want to install your own certificates for HTTP and LDAP. Is it possible ? or any side effect on the infrsturture if chane the cert,. http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP I saw some info on web ...but i now already launch and many users connected. if i replaced the cert will it make the ldap invalid for exisiting users.??? You must make sure the CA certificate that signed your HTTP and LDAP certificates is trusted on your client systems. If you do that, everything should work fine. Regafs Barry Honza -- Jan Cholasta ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] install with external CA failed
: SSL Flags: User Email Flags: User Object Signing Flags: User ... and so on... Any suggestions from anyone who has gotten an external-ca install to work? Robert -- Senior Software Engineer @ Parsons Honza -- Jan Cholasta ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Odd problem with SSSD and SSH keys
OK, there is definitely something going on in the client then. Are there multiple domains configured in sssd.conf? On 15.1.2014 13:56, Bret Wortman wrote: The fingerprint does match. On 01/15/2014 03:33 AM, Jan Cholasta wrote: On 14.1.2014 12:34, Bret Wortman wrote: The key in /etc/ssh/ssh_host_rsa_key.pub matches what's in IPA for the host in question. It should not have had any connectivity issues; it's co-located with several of our IPA masters. Can you also check if the MD5 fingerprint reported by ssh (e.g. 2a:1e:1c:87:33:44:fb:87:ab:6f:ee:80:d5:21:7e:ab in your original post) matches the MD5 fingerprint for the host in IPA? -- Jan Cholasta ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Odd problem with SSSD and SSH keys
I think you can just comment out the whole [domain/] section in sssd.conf and restart sssd. Does that solve the problem? If not, could you please post your sssd.conf here? On 16.1.2014 11:21, Bret Wortman wrote: Yes, though there should be only one. We ended up somehow with foo.com and .foo.com and I'm not sure how to reduce us properly to just foo.com. Bret Wortman http://bretwortman.com/ http://twitter.com/BretWortman On Jan 16, 2014, at 4:42 AM, Jan Cholasta jchol...@redhat.com wrote: OK, there is definitely something going on in the client then. Are there multiple domains configured in sssd.conf? On 15.1.2014 13:56, Bret Wortman wrote: The fingerprint does match. On 01/15/2014 03:33 AM, Jan Cholasta wrote: On 14.1.2014 12:34, Bret Wortman wrote: The key in /etc/ssh/ssh_host_rsa_key.pub matches what's in IPA for the host in question. It should not have had any connectivity issues; it's co-located with several of our IPA masters. Can you also check if the MD5 fingerprint reported by ssh (e.g. 2a:1e:1c:87:33:44:fb:87:ab:6f:ee:80:d5:21:7e:ab in your original post) matches the MD5 fingerprint for the host in IPA? -- Jan Cholasta -- Jan Cholasta ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Odd problem with SSSD and SSH keys
I'm glad that fixed it, but I would still be interested in what went wrong. Could you tell me what was the difference between foo.com and .foo.com domain configuration? I'm also curious how did such configuration got into sssd.conf in the first place, ipa-client-install should have created only one domain. On 16.1.2014 18:19, Bret Wortman wrote: It did. I just needed the motivation to figure out which version was correct. So I experimented on my own workstation this morning before anyone else got in and rolled out a corrected version. Thanks for your help, everyone! On 01/16/2014 11:52 AM, Jan Cholasta wrote: I think you can just comment out the whole [domain/] section in sssd.conf and restart sssd. Does that solve the problem? If not, could you please post your sssd.conf here? On 16.1.2014 11:21, Bret Wortman wrote: Yes, though there should be only one. We ended up somehow with foo.com and .foo.com and I'm not sure how to reduce us properly to just foo.com. Bret Wortman http://bretwortman.com/ http://twitter.com/BretWortman On Jan 16, 2014, at 4:42 AM, Jan Cholasta jchol...@redhat.com wrote: OK, there is definitely something going on in the client then. Are there multiple domains configured in sssd.conf? On 15.1.2014 13:56, Bret Wortman wrote: The fingerprint does match. On 01/15/2014 03:33 AM, Jan Cholasta wrote: On 14.1.2014 12:34, Bret Wortman wrote: The key in /etc/ssh/ssh_host_rsa_key.pub matches what's in IPA for the host in question. It should not have had any connectivity issues; it's co-located with several of our IPA masters. Can you also check if the MD5 fingerprint reported by ssh (e.g. 2a:1e:1c:87:33:44:fb:87:ab:6f:ee:80:d5:21:7e:ab in your original post) matches the MD5 fingerprint for the host in IPA? -- Jan Cholasta -- Jan Cholasta ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Odd problem with SSSD and SSH keys
On 14.1.2014 12:34, Bret Wortman wrote: The key in /etc/ssh/ssh_host_rsa_key.pub matches what's in IPA for the host in question. It should not have had any connectivity issues; it's co-located with several of our IPA masters. Can you also check if the MD5 fingerprint reported by ssh (e.g. 2a:1e:1c:87:33:44:fb:87:ab:6f:ee:80:d5:21:7e:ab in your original post) matches the MD5 fingerprint for the host in IPA? I'd be happy to run sss_ssh_knownhostsproxy manually but haven't been able to locate the proxy command to use via Google yet. Any guidance? I don't think you need to do that, it will just update /var/lib/sss/pubconf/known_hosts again. On 01/14/2014 05:43 AM, Jan Cholasta wrote: On 13.1.2014 22:18, Jakub Hrozek wrote: On Mon, Jan 13, 2014 at 02:44:29PM -0500, Bret Wortman wrote: They're definitely different. I deleted the one in the file, then tried again. It put the bad key back in the file. I blew the whole file away and the same thing happened. Where is this key coming from if not from IPA? Can you try running sss_ssh_knownhostsproxy manually to see what key does it return? The keys are propagated to the file from the sssd database. If the client was offline, the client could use stale records. Can you verify the client has no connectivity issues? Honza (CC-ed) might have some more hints. Compare the public key in /etc/ssh/ssh_host_rsa_key.pub on the host with the public key for that host in IPA. If they do not match, the host key was changed after IPA client was installed and the host record in IPA must be manually updated with the new key. Honza -- Jan Cholasta ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Odd problem with SSSD and SSH keys
On 13.1.2014 22:18, Jakub Hrozek wrote: On Mon, Jan 13, 2014 at 02:44:29PM -0500, Bret Wortman wrote: They're definitely different. I deleted the one in the file, then tried again. It put the bad key back in the file. I blew the whole file away and the same thing happened. Where is this key coming from if not from IPA? Can you try running sss_ssh_knownhostsproxy manually to see what key does it return? The keys are propagated to the file from the sssd database. If the client was offline, the client could use stale records. Can you verify the client has no connectivity issues? Honza (CC-ed) might have some more hints. Compare the public key in /etc/ssh/ssh_host_rsa_key.pub on the host with the public key for that host in IPA. If they do not match, the host key was changed after IPA client was installed and the host record in IPA must be manually updated with the new key. Honza -- Jan Cholasta ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Globalsign External CA Certificate Import Failure
Hi, On 3.1.2014 22:13, James Scollard wrote: Thanks for the reply, Version: Package freeipa-server-3.3.3-2.fc19.x86_64 already installed and latest version... I'm not sure I understand the answer. I created the CSR and they signed it using their automation, and returned the new ones to me for installation, which failed. SUN.WEATHER.COM is a valid Kerberos domain name, but not a valid O=. The node itself is x.sun.weather.com, we have a wildcard certificate for sun.weather.com, and this domain controller needs the certificate for the domain for setup to complete. What am I doing wrong here? I sense some confusion about ipa-server-install options here. You use a wildcard server certificate as IPA's CA certificate, which is obviously not correct. It seems to me you are trying to do one of the following: a) Set up IPA using your own server certificate. This is achieved using the --*_pkcs12 options. You must create a PKCS#12 file with the certificate and its private key in order to do this. Assuming you save the PKCS#12 file to /root/ldapm6x00.sun.weather.com.p12, the command line should look something like: # ipa-server-install --dirsrv_pkcs12=/root/ldapm6x00.sun.weather.com.p12 --http_pkcs12=/root/ldapm6x00.sun.weather.com.p12 --root-ca-file=/root/sun.weather.com.crt b) Set up IPA including a IPA-managed CA, with the CA being a subordinate of some external CA. This is where you should use the --external* options. First run ipa-server-install with --external-ca, which will create a CSR for IPA CA certificate in /root/ipa.csr. Then sign the CSR with the external CA to get the IPA CA certificate. Finally, run ipa-server-install with --external_cert_file pointing to the IPA CA certificate and --external_ca_file pointing to CA certificate of the external CA. On 1/3/14 3:58 PM, Rob Crittenden wrote: James Scollard wrote: When attempting to run the second part of the installation with an external CA (Globalsign) using my signed certificate and CA certificate chain I get the following; [root@ldapm6x00 ~]# ipa-server-install --external_cert_file=/root/ldapm6x00.sun.weather.com.crt --external_ca_file=/root/sun.weather.com.crt The log file for this installation can be found in /var/log/ipaserver-install.log Directory Manager password: Subject of the external certificate is not correct (got CN=*.sun.weather.com,O=The Weather Channel Interactive\, Inc,L=Atlanta,ST=Georgia,C=US, expected CN=Certificate Authority,O=SUN.WEATHER.COM). CN= and O= are correct, so why is IPA refusing to use the certificate? It appears to be expecting bogus data instead of using the provided identity. This doesnt appear to be an issue with the certificate, although I have never installed FreeIPA with a Globalsign certificate. I did nto see this problem with Network Solutions wildcard certificates though. Any suggestions would be appreciated. This isn't related to the external CA, it just can't modify the subject of the IPA CA, which it did in this case. I'm not even entirely sure what it would mean to have the CA certificate itself be a wildcard cert. Doesn't seem to be a valid use-case though. Looks like this validation was added in in v3. rob Honza -- Jan Cholasta ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Cross-realm trust with AD and ssh keys management
On 25.9.2013 10:17, Martin Kosek wrote: On 09/24/2013 04:40 PM, Alexander Bokovoy wrote: On Tue, 24 Sep 2013, Alexandre Ellert wrote: Hi, I've successfully setup a testing environment with an IPA server (RHEL 6.4) and a cross realm trust with my Active Directory (Win2008 R2). Authentication works both with AD passwords and Kerberos GSS-API. Now, I'm trying to find the way to manage ssh key which belong to AD users. It seems that I can do that only with users declared on IPA domain. Can you confirm that ? Yes. AD users do not exist physically in IPA LDAP, therefore there is no object to assign attributes into. Does winsync method provide a way to add ssh key to an AD user ? Under winsync AD users would become 'normal' LDAP objects in IPA, therefore you can assign additional values/attributes to them. Though note that winsync, one would loose all the SSO capabilities... Alexander, I am just thinking about possibilities. We now have the concept of external groups in FreeIPA which one can then use as members of normal POSIX groups and use them in HBAC or other policies. Would it be possible to create external users, i.e. user entries identified by FQDN/SID and then be able to assign selected set of user attributes (like SSH public key, home directory, shell...) which could then be leveraged by SSSD? Martin I think that if you add proper schema to AD, you can have SSSD directly use SSH public keys stored in AD. Honza -- Jan Cholasta ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Wildcard SSL
On 16.9.2013 01:20, Andrew Lau wrote: On Mon, Sep 16, 2013 at 4:23 AM, Dmitri Pal d...@redhat.com mailto:d...@redhat.com wrote: On 09/14/2013 04:00 AM, Andrew Lau wrote: Hi, I have a reverse proxy infront of many of my hosts, each of the virtual hosts have their own SSL cert, currently with FreeIPA I'm adding hosts for each virtual host and then creating a cert. From what I've found, it doesn't seem to be possible to do a wildcard ssl through FreeIPA, I tried exporting the ca root private key to manually sign a wildcard cert with no success. I may have done that wrong. Any suggestions? Is this what you are looking for? https://fedorahosted.org/freeipa/ticket/3475 It is currently on a distant roadmap but help always welcome. Thanks, Andrew ___ Freeipa-users mailing list Freeipa-users@redhat.com mailto:Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ http://www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com mailto:Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users Yeah. Is there any way of manually doing that now by pulling the root ca and key out to sign a cert? You can do it manually via Dogtag. First, import the client cert from /root/ca-agent.p12 found on your IPA server to your web browser. Then, navigate your web browser to https://ipaserver:8443/ca/ee/ca/profileSelect?profileId=caServerCert, paste the wildcard CSR in the form and submit it. Then, navigate your web browser to https://ipaserver:8443/ca/agent/ca/listRequests.html, find your request and approve it. This should give you the signed certificate. Honza -- Jan Cholasta ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Export SSL Cert
On 20.9.2013 10:14, Andrew Lau wrote: Hi, On my ever quest to finally get freeipa working behind a reverse proxy, the final thing was is it possible to export the private key and cert of the freeipa http cert? I would like to put the SSL cert on the reverse proxy but it seems I'm not having any luck getting the private key out from the certdb. Thanks. Hi, you can use pk12util to export it to PKCS#12 file, which contains both the certificate and the private key: # pk12util -o file.p12 -n Server-Cert -d /etc/httpd/alias -k /etc/httpd/alias/pwdfile.txt Honza -- Jan Cholasta ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] one last SSH question
On 17.7.2013 16:22, Armstrong, Kenneth Lawrence wrote: Ok, hopefully my last SSH key question. I've been following the instructions here: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/host-keys.html#installing-host-keys and here: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/openssh-sssd.html I have my host's public key set, it shows up in the web UI, and I have these lines added to the end of the /etc/ssh/ssh_config file on the client machine (that is also a member of the IdM domain): ProxyCommand /usr/bin/sss_ssh_knownhostsproxy -p %p -d LINUXTEST.LIBERTY.EDU %h UserKnownHostsFile2 .ssh/sss_known_hosts I have reloaded the SSH service on the client. I go to connect from my client to my linuxtest server (which happens to be my IdM server), and I get this: [karmstrong@linuxclient mailto:karmstrong@linuxclient ~]$ ssh karmstr...@linuxtest.liberty.edu mailto:karmstr...@linuxtest.liberty.edu The authenticity of host 'linuxtest.liberty.edu (no hostip for proxy command)' can't be established. RSA key fingerprint is ad:22:28:8d:91:81:3c:07:47:9d:5a:0d:09:33:18:e1. Are you sure you want to continue connecting (yes/no)? no Host key verification failed. The public key fingerprint matches what is set on the host's page in the IdM interface. I do not have a known_hosts in the karmstrong .ssh directory. I have also tried adding the FQDN, and FQDN,ip address into the SSH key on the IdM server through the Web UI, but I still get the bit about not finding an IP for the proxy command to use when it tries to authenticate the host. I have also verified that there is a PTR record in DNS for the host itself, so I believe that it is not a name resolution error. Am I missing something? No. The documentation is wrong for some reason. This is what you should have in ssh_config: ProxyCommand /usr/bin/sss_ssh_knownhostsproxy -p %p %h GlobalKnownHostsFile /var/lib/sss/pubconf/known_hosts Honza -- Jan Cholasta ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Question about design of ldap dns
On 15.7.2013 11:17, James Hogarth wrote: Hi guys, I'm just picking up the nice to have ticket of configure the default TTL as part of my general TTL refactor work seeing as the exposing and modification of TTL in the UI is unlikely to be complete before 3.3 freeze (mostly working but a few bugs remaining) : https://fedorahosted.org/bind-dyndb-ldap/ticket/70 https://fedorahosted.org/freeipa/ticket/2956 The approach I'm considering is to make the record capable of an individual TTL by just appending the TTL to the record so it would look like: dn: idnsName=bar, idnsName=example.com http://example.com, cn=dns, dc=example, dc=com idnsName: bar ARecord: 192.168.1.100 7200 This is an approach that matches how things like MX and SRV are dealt with (except those have numbers at the front) and would require much simpler modifications. Then there would be a precedence to the actual TTL used in this order: 1) If a TTL is in the record data use that 2) If a TTL is in the idnsName data (the current dnsTTL attribute) then use that 3) If a TTL is in the zone data (as per the ticket name to be decided) then use that 4) If a TTL is specified in the named.conf configuration for the bind-dyndb-ldap plugin then use that. Although potentially not as nice as making each data entry a first class citizen as an object in LDAP such as for an example: dn: aRecord=192.168.1.100,idnsName=bar, idnsName=example.com http://example.com, cn=dns, dc=example, dc=com aRecordName: bar aRecordData: 192.168.1.100 aRecordTTL: 7200 It'd require far less upheaval in terms of migrations and testing... What are your thoughts on this before I start digging into this part of the code base? Cheers, James There's a third option: group DNS records by both name and TTL, instead of just name, like this: dn: idnsName=bar+dNSTTL=7200,idnsName=example.com idnsName: bar dNSTTL: 7200 aRecord: 1.2.3.4 dn: idnsName=bar+dNSTTL=3600,idnsName=example.com idnsName: bar dNSTTL: 3600 aRecord: 5.6.7.8 This way you don't have to change the format of existing attributes nor add new attributes. Honza -- Jan Cholasta ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Freeipa -ssh keys
On 23.4.2013 20:20, naresh reddy wrote: Hi Rob I am sorry for coming back again i can see client can get the ssh keys from the server but still fails please suggest. By client you mean the machine that you are trying to ssh to, i.e. the machine that has sshd running? If not, make sure sss_ssh_authorizedkeys works on the machine with sshd, because that's the one that matters here. Also, what version of OpenSSH do you have installed? Honza -- Jan Cholasta ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Allow IPA users to create SSH tunnel with no shell
Hi,
this should work and you don't even have to set the shell to
/sbin/nologin (depends on whether you want the users to be able to login
to the system by other means or not), as the command directive in
authorized_keys takes precedence.
The tricky part is escaping the value correctly (there is shell
escaping, IPA CSV quote escaping and authorized_keys quote escaping in
effect):
$ ipa user-mod user --sshpubkey='command=/usr/bin/perl -e '\''$|=1;
print \Tunnel created, use your webbrowser to connect to the
tool\n\;while(1) { print localtime(time) . \\n\; sleep
60}'\'',permitopen=localhost:8834,no-agent-forwarding,no-X11-forwarding
ssh-rsa ...'
Honza
On 17.12.2012 03:23, Peter Brown wrote:
Hi Albert,
Have you tried putting that command in the public key for the user in
freeipa and setting the user shell to /sbin/nologin or the equivalent?
On 15 December 2012 02:09, Albert Adams bite...@gmail.com
mailto:bite...@gmail.com wrote:
In our environment we have several systems where users require
access to the system to setup an SSH tunnel but should not have a
shell on the system. Prior to rolling out IPA we accomplished this
with the authorized_keys file as follows:
command=/usr/bin/perl -e '$|=1; print \Tunnel created, use your
webbrowser to connect to the tool\n\;while(1) { print
localtime(time) . \\n\; sleep
60}',permitopen=localhost:8834,no-agent-forwarding,no-X11-forwarding
Is there a way to accomplish this in IPA?
Regards,
Albert
___
Freeipa-users mailing list
Freeipa-users@redhat.com mailto:Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
--
Jan Cholasta
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Do we need ipa-client-update script?
Dne 21.9.2012 10:45, Petr Spacek napsal(a): Hello users, we have a question for client machine administrators: On 09/21/2012 10:12 AM, Martin Kosek wrote: snip ..., that it may be useful to implement a script like ipa-client-update which would be capable of updating client information (and could be entered in a cron for example) without a need to re-enroll client. Such script could for example: * update SSH keys of the client * update a list of IPA DNS servers in #3095 * ... Martin Would it be useful at all? What other information should updater maintain? Ad https://fedorahosted.org/freeipa/ticket/3095: IMHO DNS configuration on client side is job for DHCP or Puppet. Isn't it? There is a couple of tickets that are related to this issue: https://fedorahosted.org/freeipa/ticket/1609 https://fedorahosted.org/freeipa/ticket/2655 Honza -- Jan Cholasta ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] unable to activate the ssh service in sssd config
Dne 3.8.2012 08:58, Роман Бамбурин napsal(a): hi, i trying to install freeipa-client and i have error unable to activate the ssh service in sssd config . What i need to do to resolve this problem? Thanks. Hi, you need to add the ssh service to /etc/sssd/sssd.conf manually. In order to do that, you need to modify this line in the [sssd] section: services = nss, pam to: services = nss, pam, ssh and add a new empty [ssh] section at the end of the file. Honza -- Jan Cholasta ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] dead in the water IPA server
Hi, It seems that your system ate all the available memory and the kernel decided to kill a directory server instance to free some. The kernel agent responsible for this is called the out-of-memory killer, you can read more about it and how to configure it not to kill important processes here: http://lwn.net/Articles/317814/ On 7.5.2012 02:22, Steven Jones wrote: Interesting memory message.as attached I take it it isnt good? cant login that is for sure so whatever is behind the web gui is dead if nothing else... regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 -- Jan Cholasta ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
