Re: [Freeipa-users] Broken dirsrv and SSL certificate in CA-less install of FreeIPA 4.4 on CentOS 7.3
Access log: https://files.pakos.uk/access.txt Error log: https://files.pakos.uk/ipareplica-install.log.txt I hope it helps. On 29 December 2016 at 12:52, Peter Pakos <pe...@pakos.uk> wrote: > Hi guys, > > I'm facing yet another problem with CA-less install of FreeIPA replica and > 3rd party SSL certificate. > > Few days ago I deployed a new CA-less server (ipa02) by running the > following command: > > ipa-server-install \ >> -r PAKOS.UK \ >> -n pakos.uk \ >> -p 'password' \ >> -a 'password' \ >> --mkhomedir \ >> --setup-dns \ >> --no-forwarders \ >> --no-dnssec-validation \ >> --dirsrv-cert-file=/root/ssl/star.pakos.uk.pfx \ >> --dirsrv-pin='' \ >> --http-cert-file=/root/ssl/star.pakos.uk.pfx \ >> --http-pin='' \ >> --http-cert-name=AlphaWildcardIPA \ >> --idstart=1000 > > > This server appears to be working OK. > > Then yesterday I deployed a client (ipa01): > > ipa-client-install \ >> -p admin \ >> -w 'password' \ >> --mkhomedir > > > Next, I promoted it to IPA server: > > ipa-replica-install \ >> -w 'password' \ >> --mkhomedir \ >> --setup-dns \ >> --no-forwarders \ >> --no-dnssec-validation \ >> --dirsrv-cert-file=/root/ssl/star.pakos.uk.pfx \ >> --dirsrv-pin='' \ >> --dirsrv-cert-name=AlphaWildcardIPA \ >> --http-cert-file=/root/ssl/star.pakos.uk.pfx \ >> --http-pin='' \ >> --http-cert-name=AlphaWildcardIPA > > > After it finished, I've noticed that dirsrv wasn't running on port 636 on > ipa01. > > Further investigation revealed that the SSL wildcard certificate > (AlphaWildcardIPA) wasn't installed in dirsrv DB and CA certificates were > named oddly (CA 1 and CA 2): > > [root@ipa01 ~]# certutil -L -d /etc/httpd/alias/ > > Certificate Nickname Trust Attributes > > SSL,S/MIME,JAR/XPI > > AlphaWildcardIPA u,u,u > CA 1 ,, > CA 2 C,, > > > [root@ipa01 ~]# certutil -L -d /etc/dirsrv/slapd-PAKOS-UK/ > > Certificate Nickname Trust Attributes > > SSL,S/MIME,JAR/XPI > > GlobalSign Root CA - GlobalSign nv-sa,, > AlphaSSL CA - SHA256 - G2 - GlobalSign nv-sa C,, > > > This is what I found in the error log: > > [29/Dec/2016:01:43:58.852745536 +] 389-Directory/1.3.5.10 B2016.341. > starting up > [29/Dec/2016:01:43:58.867642515 +] default_mr_indexer_create: warning - > plugin [caseIgnoreIA5Match] does not handle caseExactIA5Match > [29/Dec/2016:01:43:58.889866051 +] schema-compat-plugin - scheduled > schema-compat-plugin tree scan in about 5 seconds after the server startup! > [29/Dec/2016:01:43:58.905267535 +] NSACLPlugin - The ACL target > cn=groups,cn=compat,dc=pakos,dc=uk does not exist > [29/Dec/2016:01:43:58.907051833 +] NSACLPlugin - The ACL target > cn=computers,cn=compat,dc=pakos,dc=uk does not exist > [29/Dec/2016:01:43:58.908396407 +] NSACLPlugin - The ACL target > cn=ng,cn=compat,dc=pakos,dc=uk does not exist > [29/Dec/2016:01:43:58.909758735 +] NSACLPlugin - The ACL target > ou=sudoers,dc=pakos,dc=uk does not exist > [29/Dec/2016:01:43:58.911133739 +] NSACLPlugin - The ACL target > cn=users,cn=compat,dc=pakos,dc=uk does not exist > [29/Dec/2016:01:43:58.912416230 +] NSACLPlugin - The ACL target > cn=vaults,cn=kra,dc=pakos,dc=uk does not exist > [29/Dec/2016:01:43:58.913644794 +] NSACLPlugin - The ACL target > cn=vaults,cn=kra,dc=pakos,dc=uk does not exist > [29/Dec/2016:01:43:58.914901802 +] NSACLPlugin - The ACL target > cn=vaults,cn=kra,dc=pakos,dc=uk does not exist > [29/Dec/2016:01:43:58.916158004 +] NSACLPlugin - The ACL target > cn=vaults,cn=kra,dc=pakos,dc=uk does not exist > [29/Dec/2016:01:43:58.917409810 +] NSACLPlugin - The ACL target > cn=vaults,cn=kra,dc=pakos,dc=uk does not exist > [29/Dec/2016:01:43:58.918636743 +] NSACLPlugin - The ACL target > cn=vaults,cn=kra,dc=pakos,dc=uk does not exist > [29/Dec/2016:01:43:58.919904210 +] NSACLPlugin - The ACL target > cn=vaults,cn=kra,dc=pakos,dc=uk does not exist > [29/Dec/2016:01:43:58.921175543 +] NSACLPlugin - The ACL target > cn=vaults,cn=kra,dc=pakos,dc=uk does not exist > [29/Dec/2016:01:43:58.922417264 +] NSACLPlugin - The ACL target > cn=vaults,cn=kra,dc=pakos,dc=uk does
[Freeipa-users] Broken dirsrv and SSL certificate in CA-less install of FreeIPA 4.4 on CentOS 7.3
Hi guys, I'm facing yet another problem with CA-less install of FreeIPA replica and 3rd party SSL certificate. Few days ago I deployed a new CA-less server (ipa02) by running the following command: ipa-server-install \ > -r PAKOS.UK \ > -n pakos.uk \ > -p 'password' \ > -a 'password' \ > --mkhomedir \ > --setup-dns \ > --no-forwarders \ > --no-dnssec-validation \ > --dirsrv-cert-file=/root/ssl/star.pakos.uk.pfx \ > --dirsrv-pin='' \ > --http-cert-file=/root/ssl/star.pakos.uk.pfx \ > --http-pin='' \ > --http-cert-name=AlphaWildcardIPA \ > --idstart=1000 This server appears to be working OK. Then yesterday I deployed a client (ipa01): ipa-client-install \ > -p admin \ > -w 'password' \ > --mkhomedir Next, I promoted it to IPA server: ipa-replica-install \ > -w 'password' \ > --mkhomedir \ > --setup-dns \ > --no-forwarders \ > --no-dnssec-validation \ > --dirsrv-cert-file=/root/ssl/star.pakos.uk.pfx \ > --dirsrv-pin='' \ > --dirsrv-cert-name=AlphaWildcardIPA \ > --http-cert-file=/root/ssl/star.pakos.uk.pfx \ > --http-pin='' \ > --http-cert-name=AlphaWildcardIPA After it finished, I've noticed that dirsrv wasn't running on port 636 on ipa01. Further investigation revealed that the SSL wildcard certificate (AlphaWildcardIPA) wasn't installed in dirsrv DB and CA certificates were named oddly (CA 1 and CA 2): [root@ipa01 ~]# certutil -L -d /etc/httpd/alias/ Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI AlphaWildcardIPA u,u,u CA 1 ,, CA 2 C,, [root@ipa01 ~]# certutil -L -d /etc/dirsrv/slapd-PAKOS-UK/ Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI GlobalSign Root CA - GlobalSign nv-sa,, AlphaSSL CA - SHA256 - G2 - GlobalSign nv-sa C,, This is what I found in the error log: [29/Dec/2016:01:43:58.852745536 +] 389-Directory/1.3.5.10 B2016.341. starting up [29/Dec/2016:01:43:58.867642515 +] default_mr_indexer_create: warning - plugin [caseIgnoreIA5Match] does not handle caseExactIA5Match [29/Dec/2016:01:43:58.889866051 +] schema-compat-plugin - scheduled schema-compat-plugin tree scan in about 5 seconds after the server startup! [29/Dec/2016:01:43:58.905267535 +] NSACLPlugin - The ACL target cn=groups,cn=compat,dc=pakos,dc=uk does not exist [29/Dec/2016:01:43:58.907051833 +] NSACLPlugin - The ACL target cn=computers,cn=compat,dc=pakos,dc=uk does not exist [29/Dec/2016:01:43:58.908396407 +] NSACLPlugin - The ACL target cn=ng,cn=compat,dc=pakos,dc=uk does not exist [29/Dec/2016:01:43:58.909758735 +] NSACLPlugin - The ACL target ou=sudoers,dc=pakos,dc=uk does not exist [29/Dec/2016:01:43:58.911133739 +] NSACLPlugin - The ACL target cn=users,cn=compat,dc=pakos,dc=uk does not exist [29/Dec/2016:01:43:58.912416230 +] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=pakos,dc=uk does not exist [29/Dec/2016:01:43:58.913644794 +] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=pakos,dc=uk does not exist [29/Dec/2016:01:43:58.914901802 +] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=pakos,dc=uk does not exist [29/Dec/2016:01:43:58.916158004 +] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=pakos,dc=uk does not exist [29/Dec/2016:01:43:58.917409810 +] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=pakos,dc=uk does not exist [29/Dec/2016:01:43:58.918636743 +] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=pakos,dc=uk does not exist [29/Dec/2016:01:43:58.919904210 +] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=pakos,dc=uk does not exist [29/Dec/2016:01:43:58.921175543 +] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=pakos,dc=uk does not exist [29/Dec/2016:01:43:58.922417264 +] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=pakos,dc=uk does not exist [29/Dec/2016:01:43:58.923818252 +] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=pakos,dc=uk does not exist [29/Dec/2016:01:43:58.925218237 +] NSACLPlugin - The ACL target cn=vaults,cn=kra,dc=pakos,dc=uk does not exist [29/Dec/2016:01:43:58.928474915 +] NSACLPlugin - The ACL target cn=ad,cn=etc,dc=pakos,dc=uk does not exist [29/Dec/2016:01:43:58.943158867 +] NSACLPlugin - The ACL target cn=casigningcert cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=pakos,dc=uk does not exist [29/Dec/2016:01:43:58.944679679 +] NSACLPlugin - The ACL target cn=casigningcert cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=pakos,dc=uk does not exist [29/Dec/2016:01:43:59.060335708 +] NSACLPlugin - The ACL target cn=automember rebuild membership,cn=tasks,cn=config does not exist [29/Dec/2016:01:43:59.066618653
Re: [Freeipa-users] SSSD with LDAP not showing secondary groups
Jakub Hrozek wrote: > I'm glad it works now, but why did you choose to use the LDAP back end > over the IPA back end? By using LDAP, you gain the ability to not enroll > clients with ipa-client-install, but you loose the ease of > manageability, HBAC, easy SUDO integration, not to mention you need to > put passwords into the config file.. > > Well, we wanted a quick solution for migrating all our servers (a mixture of Centos, Debian, SLES, Ubuntu) from using SSSD with an old LDAP server to auth against FreeIPA. Since we have all our servers puppetized and using sudoers files, it was the best approach I could think of. Can you think of a better way of tackling this? Now that the dust settles down after the migration, we started enrolling infrastructure servers to FreeIPA using ipa-client-install. -- Kind regards, Peter Pakos -- 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 install - problem with CA certificates - PLEASE HELP!
A massive thank you to Jan Cholasta for handholding me while I was getting this problem fixed. This is how we did it... 1. List all CA certificates in LDAP directory: ldapsearch -b cn=certificates,cn=ipa,$basedn 2. Using ldapdelete (or LDAP browser), get rid of all certificates that shouldn't be there, in my case there were 2 called "CA 1" and "CA 2" 3. On each server, list all certificates in the following databases ($db): - /etc/httpd/alias/ - /etc/dirsrv/slapd-IPA-YOUR-REALM/ - /etc/pki/nssdb/ - /etc/ipa/nssdb/ certutil -L -d $db 4. On each server, delete duplicated certificates ($nick = Certificate Nickname) from the above databases. Please note, this step removed both correct and incorrect certificates: certutil -D -d $db -n "$nick" 5. We had a conflict between one of our intermediate CA certificates supplied by Gandi and a system certificate (potentially installed by ca-certificates package) therefore we had to run the following command on every server to stop the system cert being loaded into httpd database: modutil -dbdir /etc/httpd/alias -disable 'Root Certs' -force 6. Lastly, we ran the following command on every server to load correct certificates into all databases: ipa-certupdate At this point we had a fully functioning system again with the correct SSL certificate chain being served by both httpd and dirsrv services. Please note, an incorrect CA certificate was re-added to the LDAP directory later on when I deployed a new node and I had to repeat step 2 before running ipa-certupdate on the new replica. Once again, I would like to thank Jan for his input - keep up the good work! -- Kind regards, Peter Pakos -- 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 install - problem with CA certificates - PLEASE HELP!
A massive thank you to Jan Cholasta for handholding me while I was getting this problem fixed. This is how we did it... 1. List all CA certificates in LDAP directory: ldapsearch -b cn=certificates,cn=ipa,$basedn 2. Using ldapdelete, get rid of all certificates that shouldn't be there, in my case there were 2 called "CA 1" and "CA 2" 3. List all certificates in the following databases ($db): - /etc/httpd/alias/ - /etc/dirsrv/slapd-IPA-YOUR-REALM/ - /etc/pki/nssdb/ - /etc/ipa/nssdb/ certutil -L -d $db 4. Delete incorrect certificates from the above databases: -- Kind regards, Peter Pakos -- 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 install - problem with CA certificates - PLEASE HELP!
I've now set up a test box using exactly the same install command, SSL
certificate etc...
The /etc/ipa/ca.crt contains only 3 certificates but they are not CA
certificates that were included in the PKCS12 file:
[root@dupa temp]# for i in {1..3}; do echo cert${i}; openssl x509 -in
cert${i} -noout -text | grep -i 'issuer:\|subject:'; done
cert1
Issuer: C=US, ST=New Jersey, L=Jersey City, O=The USERTRUST
Network, CN=USERTrust RSA Certification Authority
Subject: C=US, ST=New Jersey, L=Jersey City, O=The USERTRUST
Network, CN=USERTrust RSA Certification Authority
cert2
Issuer: C=SE, O=AddTrust AB, OU=AddTrust External TTP Network,
CN=AddTrust External CA Root
Subject: C=US, ST=New Jersey, L=Jersey City, O=The USERTRUST
Network, CN=USERTrust RSA Certification Authority
cert3
Issuer: C=US, ST=New Jersey, L=Jersey City, O=The USERTRUST
Network, CN=USERTrust RSA Certification Authority
Subject: C=FR, ST=Paris, L=Paris, O=Gandi, CN=Gandi Standard SSL CA 2
So out of the box, the certificate "USERTrust RSA Certification
Authority" is listed there twice.
[root@dupa temp]# certutil -L -d /etc/pki/nssdb/
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
AddTrust External CA Root - AddTrust AB ,,
USERTrust RSA Certification Authority - AddTrust AB ,,
Gandi Standard SSL CA 2 - The USERTRUST Network C,,
[root@dupa temp]# certutil -L -d /etc/httpd/alias/
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
GandiWildcardIPA u,u,u
AddTrust External CA Root - AddTrust AB ,,
USERTrust RSA Certification Authority - AddTrust AB ,,
Gandi Standard SSL CA 2 - The USERTRUST Network C,,
[root@dupa temp]# certutil -L -d /etc/dirsrv/slapd-IPA-WANDISCO-COM/
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
GandiWildcardIPA u,u,u
AddTrust External CA Root - AddTrust AB ,,
USERTrust RSA Certification Authority - AddTrust AB ,,
Gandi Standard SSL CA 2 - The USERTRUST Network C,,
Please note, in the databases the certificate "USERTrust RSA
Certification Authority - AddTrust AB" is only listed once.
How do I fix our production installation?
--
Kind regards,
Peter Pakos
--
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
[Freeipa-users] CA-less install - problem with CA certificates - PLEASE HELP!
=The USERTRUST Network/CN=USERTrust RSA Certification Authority verify error:num=19:self signed certificate in certificate chain verify return:0 --- Certificate chain 0 s:/OU=Domain Control Validated/OU=Gandi Standard Wildcard SSL/CN=*. ipa.wandisco.com i:/C=FR/ST=Paris/L=Paris/O=Gandi/CN=Gandi Standard SSL CA 2 1 s:/C=FR/ST=Paris/L=Paris/O=Gandi/CN=Gandi Standard SSL CA 2 i:/C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority 2 s:/C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority i:/C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority Please correct me if I'm wrong, but I think that in order to fix this we will need to remove the incorrectly added certificate "USERTrust RSA Certification Authority - AddTrust AB", but which one since there 2 with exactly the same nickname? I haven't made any further changes to any of the servers as I would like to get your input first. Please get back to me as soon as possible, it is very important for us to recover from this state in a timely manner. I'm available on #freeipa under nickname peterpakos. Thanks in advance for your help. -- Kind regards, Peter Pakos -- 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] SSSD with LDAP not showing secondary groups
On 17 July 2016 at 09:03, Alexander Bokovoy <aboko...@redhat.com> wrote: > Your sssd configuration does not mention what DN is used to bind to the > LDAP server to retrieve the data. This means you are using anonymous > bind. Since FreeIPA 4.0 there is a number of attributes that are not > available to anonymous binds, including 'member' and 'memberof'. Thus, > SSSD does not see membership information when using anonymous binds. > > In normally enrolled IPA clients host/ipa.client@IPA.REALM Kerberos > principal is used to bind to LDAP with GSSAPI when SSSD talks to LDAP > server, thus all binds are authenticated and 'member'/'memberof' > attributes are accessible. > > So you either need to enroll machines to IPA and switch your sssd.conf > to use 'ipa' providers instead of ldap, or define a system account that > can be used to bind to LDAP by your sssd clients. In short term > perspective that would probably be an easier fix. For the latter see > sssd-ldap(5), ldap_default_bind_dn, ldap_default_authtok options. Bingo! Adding the following lines to /etc/sssd/sssd.conf has fixed the issue for us: ldap_schema = rfc2307bis ldap_default_bind_dn = *dn* ldap_default_authtok = *password* Many thanks! -- Kind regards, Peter Pakos -- 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] SSSD with LDAP not showing secondary groups
On 17 July 2016 at 09:03, Alexander Bokovoy <aboko...@redhat.com> wrote: > > Your sssd configuration does not mention what DN is used to bind to the > LDAP server to retrieve the data. This means you are using anonymous > bind. Since FreeIPA 4.0 there is a number of attributes that are not > available to anonymous binds, including 'member' and 'memberof'. Thus, > SSSD does not see membership information when using anonymous binds. > > In normally enrolled IPA clients host/ipa.client@IPA.REALM Kerberos > principal is used to bind to LDAP with GSSAPI when SSSD talks to LDAP > server, thus all binds are authenticated and 'member'/'memberof' > attributes are accessible. > > So you either need to enroll machines to IPA and switch your sssd.conf > to use 'ipa' providers instead of ldap, or define a system account that > can be used to bind to LDAP by your sssd clients. In short term > perspective that would probably be an easier fix. For the latter see > sssd-ldap(5), ldap_default_bind_dn, ldap_default_authtok options. Interesting, I'll look into this and report back. -- Kind regards, Peter Pakos -- 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] SSSD with LDAP not showing secondary groups
On 17 July 2016 at 03:48, Sullivan, Daniel [AAA] < dsulliv...@bsd.uchicago.edu> wrote: > > Out of curousity is there any reason you are not using the IPA provider > instead of LDAP (in SSSD)? > We initially want to switch hundreds of servers via Puppet change. At a later stage we'll look at joining them using ipa-client. Quick update, I can see group members and list of secondary groups when I use compat tree: ldap_search_base = cn=compat,dc=ipa,dc=wandisco,dc=com ldap_group_search_base = cn=groups,cn=compat,dc=ipa,dc=wandisco,dc=com ldap_user_search_base = cn=users,cn=compat,dc=ipa,dc=wandisco,dc=com Not sure if using compat tree is the best approach here though. -- Kind regards, Peter Pakos -- 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] SSSD with LDAP not showing secondary groups
I did try setting ldap_schema to rfc2307 (I think this is the default setting) rfc2307bis and ipa, but it didn't make any difference. I also tried setting ldap_group_member = member ldap_user_member_of = memberOf but again, it made no difference. On 17 July 2016 at 03:38, Sullivan, Daniel [AAA] < dsulliv...@bsd.uchicago.edu> wrote: > Have you tried different settings for ldap_schema (should be easy to test)? > > http://linux.die.net/man/5/sssd-ldap > > Dan > > -- Kind regards, Peter Pakos -- 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
[Freeipa-users] SSSD with LDAP not showing secondary groups
Hi, I'm about to move our FreeIPA platform into production on Monday but I've just noticed a worrying issue with sssd - getent group is not showing group members and id is not showing secondary groups. Currently all our servers are configured with sssd using our old LDAP (389-ds) as a backend. It works great, id shows all my secondary groups: # id peter.pakos uid=1396(peter.pakos) gid=511(Engineering) groups=511(Engineering),718(DevOps),701(SSHAllow) After re-configuring sssd to use FreeIPA's LDAP directory, id is only showing primary group, the secondary groups are missing: # id peter.pakos uid=1396(peter.pakos) gid=511(engineering) groups=511(engineering) Similarly, getent is not showing group members: # getent group engineering engineering:*:511: Environment: # cat /etc/redhat-release CentOS Linux release 7.2.1511 (Core) # ipa --version VERSION: 4.2.0, API_VERSION: 2.156 This is an example sssd.conf file I'm using in my tests: [domain/ipa.wandisco.com] ldap_tls_reqcert = demand ldap_id_use_start_tls = True cache_credentials = True ldap_search_base = cn=accounts,dc=ipa,dc=wandisco,dc=com ldap_group_search_base = cn=groups,cn=accounts,dc=ipa,dc=wandisco,dc=com ldap_user_search_base = cn=users,cn=accounts,dc=ipa,dc=wandisco,dc=com id_provider = ldap auth_provider = ldap chpass_provider = ldap ldap_uri = ldaps://shdc01.ipa.wandisco.com, ldaps://shdc02.ipa.wandisco.com, ldaps://ashb01.ipa.wandisco.com, ldaps://ashb02.ipa.wandisco.com, ldaps://frem01.ipa.wandisco.com ldap_tls_cacert = /etc/ipa/ca.crt [sssd] services = nss, pam config_file_version = 2 domains = ipa.wandisco.com [nss] [pam] [sudo] [autofs] [ssh] Am I missing anything in the sssd configuration? Any advice would be greatly appreciated. -- Kind regards, Peter Pakos -- 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 Consistency Checker
Just a quick heads-up, The newest version of the ipa_check_consistency script comes with Nagios/Opsview plug-in functionality and some further improvements. Feel free to take it for a spin! https://github.com/peterpakos/ipa_check_consistency -- Kind regards, Peter Pakos -- 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, 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. -- Kind regards, Peter Pakos -- 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
[Freeipa-users] FreeIPA Consistency Checker
Hi, I just wanted to share a little script that I've created to check consistency across FreeIPA servers. https://github.com/peterpakos/ipa_check_consistency I hope you will like it. Please note, it's been tested only with FreeIPA 4.2 (Centos 7.2) so I'm not sure if it works with other versions. Please feel free to try it and if you have any improvement ideas then log them via GitHub. Thanks. -- Kind regards, Peter Pakos -- 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, I now have 3rd party SSL certificate successfully installed for LDAP and HTTP but I'm having issues with joining new clients to FreeIPA servers. When I run "ipa-client-install --mkhomedir" on Centos 6 machine I get the following error: "Joining realm failed: libcurl failed to execute the HTTP POST transaction. Peer certificate cannot be authenticated with known CA certificates" /var/log/ipaclient-install.log shows: "2016-01-24T22:06:26Z ERROR Joining realm failed: libcurl failed to execute the HTTP POST transaction. Peer certificate cannot be authenticated with known CA certificates" I was under the impression that the 3rd party certificate's chain will be included in the CA certificate that the client gets from the servers and that it will successfully join the realm. I specified the root certificate using --ca-cert-file= option and the install completed OK but is this really necessary? I do hope there is a better solution. Many thanks. -- Kind regards, Peter Pakos -- 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/01/2016 08:15, Jan Cholasta wrote: 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. I think that covers everything. Thank you. -- Kind regards, Peter Pakos -- 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/
On 18/01/2016 08:37, Jan Cholasta wrote: Are the above steps correct for installing 3rd party certificates in FreeIPA 4.2? Should I change anything? Looks OK to me. Thanks for verifying my instructions. -- Kind regards, Peter Pakos -- 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/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. 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? 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? 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! -- Kind regards, Peter Pakos -- 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
[Freeipa-users] ipa-certupdate not installing root certificates in /etc/pki/pki-tomcat/alias/
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? Are the above steps correct for installing 3rd party certificates in FreeIPA 4.2? Should I change anything? We are planning to move these nodes into production very soon, any help would be much appreciated! -- Kind regards, Peter Pakos -- 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 15/01/2016 15:04, Rob Crittenden wrote: Discussed in IRC last night but for the sake of history, he needed to add the CA's to the dogtag NSS database in /var/lib/pki/pki-tomcat/alias/ with a trust of C,,. Yes, I added new root certificates to /etc/pki/pki-tomcat/alias and I was able to start all services. I've noticed that ipa-certupdate command removes them and we're back to square one. Why is it doing this? Which database is it retrieving certificates from? 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). Also, what is the correct process for renewing 3rd party certificate? Will it be pushed automatically to all servers/clients? I don't want to be in trouble when it comes to renewing it. Thanks. -- Kind regards, Peter Pakos -- 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 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? 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. -- Kind regards, Peter Pakos -- 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
[Freeipa-users] CA-less vs CA-ful FreeIPA 4.2 installation
Hi, We've been testing FreeIPA system for a while now and we're getting closer to moving it into production. I'm considering both CA-less and CA-ful installation types. I hope you guys can help me make my mind and choose the right decision. What are the pros and cons of each install type? What exactly are we loosing if we choose CA-less install? One of our requirements is to have a 3rd party HTTP and LDAP certificates installed - which install path would be more suitable? 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? I've failed to find any useful info covering the above points, so if you know anything, please just let me know. I would appreciate your input. Thanks in advance. -- Kind regards, Peter Pakos -- 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 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" I have a wildcard SSL certificate from Gandi, the whole certificate chain looks like this: AddTrust.pem -> USERTrustRSAAddTrustCA.pem -> GandiStandardSSLCA2.pem -> star.ipa.wandisco.com.crt I can validate this chain by running: $ openssl verify -verbose -CAfile <(cat AddTrust.pem USERTrustRSAAddTrustCA.pem GandiStandardSSLCA2.pem) star.ipa.wandisco.com.crt star.ipa.wandisco.com.crt: OK I've installed those CA certificates using the following commands (due to a known bug with ipa-cacert-manage, as per Jan's recommendation, I had to comment out few lines in /usr/lib/python2.7/site-packages/ipaserver/install/ipa_cacert_manage.py for this to work): $ ipa-cacert-manage install AddTrust.pem -n AddTrust -t ,, $ ipa-cacert-manage install USERTrustRSAAddTrustCA.pem -n USERTrustRSAAddTrustCA -t ,, $ ipa-cacert-manage install GandiStandardSSLCA2.pem -n GandiStandardSSLCA2 -t ,, Then I created a PKCS12 certificate out of Wildcard certificate and private key: $ openssl pkcs12 -export -out star.ipa.wandisco.com.p12 -inkey star.ipa.wandisco.com.key -in star.ipa.wandisco.com.crt -name 'GandiWildcardIPA' and then installed it in both NSS databases: $ pk12util -d /etc/dirsrv/slapd-IPA-WANDISCO-COM/ -i star.ipa.wandisco.com.p12 $ pk12util -d /etc/httpd/alias/ -i star.ipa.wandisco.com.p12 I could see the certificates being installed by running: $ certutil -d /etc/dirsrv/slapd-IPA-WANDISCO-COM/ -L $ certutil -d /etc/httpd/alias/ -L Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI ipaCert u,u,u Server-Cert u,u,u IPA.WANDISCO.COM IPA CA CT,C,C AddTrust ,, USERTrustRSAAddTrustCA ,, GandiWildcardIPA u,u,u Signing-Cert u,u,u GandiStandardSSLCA2 ,, 2. Run "ipa-certupdate" to update CA certificate related IPA configuration. Done. 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. I've stopped IPA (ipactl stop) and edited /etc/dirsrv/slapd-IPA-WANDISCO-COM/dse.ldif to replace: nsSSLPersonalitySSL: Server-Cert for: nsSSLPersonalitySSL: GandiWildcardIPA 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. I've edited /etc/httpd/conf.d/nss.conf and replaced: NSSNickname Server-Cert for: NSSNickname GandiWildcardIPA Next, I've tried to start IPA (ipactl start) but this failed: ipactl start Starting Directory Service Starting krb5kdc Service Starting kadmin Service Starting named Service Starting ipa_memcached Service Starting httpd Service Starting pki-tomcatd Service Failed to start pki-tomcatd Service Shutting down Aborting ipactl It seems that pki-tomcatd did not start, so I looked in /var/log/pki/pki-tomcat/catalina.log and noticed this (not sure how relevant this is): http://fpaste.org/310861/14527938/ /var/log/pki/pki-tomcat/ca/system log shows: 0.localhost-startStop-1 - [14/Jan/2016:17:47:49 UTC] [8] [3] In Ldap (bound) connection pool to host node01.ipa.wandisco.com port 636, Cannot connect to LDAP server. Error: netscape.ldap.LDAPException: IO Error creating JSS SSL Socket (-1) At this stage I can revert LDAP/HTTPS certs' nickname to Server-Cert and successfully start IPA. Using 3rd party certificates for both LDAP and HTTPS is one of the requirements of FreeIPA POC I'm working on at the moment and without this ironed out we won't be able to take FreeIPA servers into full production. I hope it's just a minor mistake on my behalf and I would appreciate if anyone could glance through the above and let me know how I could progress this. Many thanks in advance. spako @ #freeipa -- Kind regards, Peter Pakos -- 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 14/01/2016 18:51, Rob Crittenden wrote: You need to add the new root certs to the pki NSS database. As far as I can see those 3 new CA certs are already in the database (unless you're talking about a different db): $ certutil -d /etc/pki/nssdb/ -L Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI IPA.WANDISCO.COM IPA CA CT,C,C AddTrust ,, USERTrustRSAAddTrustCA ,, GandiStandardSSLCA2 ,, Please advise. -- Kind regards, Peter Pakos -- 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 04/01/2016 12:44, Jan Cholasta wrote: 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. Is there any chance you can confirm the exact commands I need to run to accomplish the above steps? I don't want to risk breaking our production servers. BTW, do we have an up-to-date documentation about this process in FreeIPA 4.2? I failed to find one. Many thanks in advance. -- Kind regards, Peter Pakos -- 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 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? TIA -- Kind regards, Peter Pakos -- 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
[Freeipa-users] Using 3rd party certificates for HTTP/LDAP
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: # 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? Many thanks in advance. BTW, I also added a comment describing this problem to the ticket at https://fedorahosted.org/freeipa/ticket/5496. -- Kind regards, Peter Pakos -- 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
