Re: [Freeipa-users] sec_error_reused_issuer_and_serial
The only way to get around it, because you are using the same domain name, is to use different browsers to visit each site. Firefox for sitea, chrome for siteb. It's got to do with the fact that the Parent certificate name (generated automatically during install) is the same on both and because the domain matches then firefox throws the ssl warning. I have the same thing in my environments for production and dr where the domain name is the same in both. Regards, Les From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Winfried de Heiden Sent: Tuesday, 22 September 2015 10:27 PM To: freeipa-users@redhat.com Subject: [Freeipa-users] sec_error_reused_issuer_and_serial Hi all, Playing around with freeipa on Fedora 22 after installing I cannot access the UI. Firefox will tell "sec_error_reused_issuer_and_serial". I allready have an Freeipa (Fedora 21 based) and somewhere there seems to be a conflict in the certificates. After using a different domain name all goes well. I want to test and try a few things on a test Freeipa server using the same domain name. Deleting all certicates in Firefox or even trying a new and clean profile did not help. How can I avoid this conflict? Winfried -- 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] sec_error_reused_issuer_and_serial
> -Original Message- > From: Fraser Tweedale [mailto:ftwee...@redhat.com] > Sent: Wednesday, 23 September 2015 10:59 AM > To: Les Stott > Cc: Winfried de Heiden; freeipa-users@redhat.com > Subject: Re: [Freeipa-users] sec_error_reused_issuer_and_serial > > On Tue, Sep 22, 2015 at 09:52:38PM +, Les Stott wrote: > > The only way to get around it, because you are using the same domain > > name, is to use different browsers to visit each site. > > Firefox for sitea, chrome for siteb. > > > It is not the only way; you can flush your browser cache / offline data for > the > site and cause the browswer to forget about the issuer. > Certainly with Firefox this is possible (I don't use Chromium). > This never worked for me. Or if it did, it made siteb accessible, but then sitea had the ssl error and vice versa. > Or you can use separate Firefox profiles (again I am unsure if Chromium has > this feature) for the separate installations. > > Or for installations / experimentation, you can specify a different > "Organization" component of the root issuer DN when installing FreeIPA. I > include a "timestamp" when installing test servers: > > ipa-server-install --subject 'O=IPA.LOCAL 201508311610' Never knew about that option. It would make sense if something like that was the default I think Thanks for the info. Regards, Les > > Hope that helps! > Fraser > > > It's got to do with the fact that the Parent certificate name (generated > automatically during install) is the same on both and because the domain > matches then firefox throws the ssl warning. > > > > I have the same thing in my environments for production and dr where the > domain name is the same in both. > > > > Regards, > > > > Les > > > > From: freeipa-users-boun...@redhat.com > > [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Winfried de > > Heiden > > Sent: Tuesday, 22 September 2015 10:27 PM > > To: freeipa-users@redhat.com > > Subject: [Freeipa-users] sec_error_reused_issuer_and_serial > > > > Hi all, > > > > Playing around with freeipa on Fedora 22 after installing I cannot access > > the > UI. Firefox will tell "sec_error_reused_issuer_and_serial". > > > > I allready have an Freeipa (Fedora 21 based) and somewhere there seems > to be a conflict in the certificates. After using a different domain name all > goes well. > > > > I want to test and try a few things on a test Freeipa server using the same > domain name. Deleting all certicates in Firefox or even trying a new and clean > profile did not help. How can I avoid this conflict? > > > > Winfried > > > > > -- > > Manage your subscription for the Freeipa-users mailing list: > > https://www.redhat.com/mailman/listinfo/freeipa-users > > Go to http://freeipa.org for more info on the project -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] freeipa and User Private Groups
Jakub, Thanks for the follow up. We try and stick to standard rhel/epel repo's (due to policy) so I am not able to install a non-standard version of sssd. I have decided to disable the User Private Group plugin and convert ipausers to a posix group. There was nothing I could see that required us to use UPG's. This setup is working for me now. Thanks, Les -Original Message- From: freeipa-users-boun...@redhat.com [mailto:freeipa-users- boun...@redhat.com] On Behalf Of Jakub Hrozek Sent: Tuesday, 14 July 2015 6:42 PM To: freeipa-users@redhat.com Subject: Re: [Freeipa-users] freeipa and User Private Groups On Mon, Jul 13, 2015 at 09:11:09AM +, Les Stott wrote: Hi All, Running ipa-3.0.0-42.el6 and sssd-1.11.6-30.el6_6.3.x86_64 So, by default, when you create a user in freeipa, That user will be set to have a primary group that is hidden and not a POSIX group. This means that when the user logs in to a host, they will see something like... id: cannot find name for group ID group_number It is not expected to not be able to return the name of the user group and I don't see that in my setup. I was suspecting rhbz#1165074 but your sssd should already have that bug fixed. Can you see if the packages from https://copr.fedoraproject.org/coprs/lslebodn/sssd-1-12/ also show that behaviour? If yes, can you get us sssd logs as described here: https://fedorahosted.org/sssd/wiki/Troubleshooting running the id command shows no name returned for this group. I understand you can disable private groups globally, however it is discouraged. I also realise you can simply create POSIX groups when creating users. In the spirit of trying to stick with the defaults Is there a way to avoid the login error where id can't retrieve the group name from a UPG? Thanks, Les -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] freeipa and User Private Groups
Hi All, Running ipa-3.0.0-42.el6 and sssd-1.11.6-30.el6_6.3.x86_64 So, by default, when you create a user in freeipa, That user will be set to have a primary group that is hidden and not a POSIX group. This means that when the user logs in to a host, they will see something like... id: cannot find name for group ID group_number running the id command shows no name returned for this group. I understand you can disable private groups globally, however it is discouraged. I also realise you can simply create POSIX groups when creating users. In the spirit of trying to stick with the defaults Is there a way to avoid the login error where id can't retrieve the group name from a UPG? Thanks, Les -- 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] CentOS 6.6 Installation Issues
Randall, Check your apache error logs for any errors and the modules loaded via httpd.conf. The ipa server log does show that it can reach apache for most things. I had a similar issue not too long ago when trying to install a CA replica on an existing ipa server, which is pretty much the same process that the master server install does. I found that I was missing modules in httpd.conf and errors were popping up about mod_proxy. As it turned out, not having those modules loaded caused the installer to fail. See https://www.redhat.com/archives/freeipa-users/2015-February/msg00041.html for the solution that helped me, hopefully it helps you too. Regards, Les -Original Message- From: freeipa-users-boun...@redhat.com [mailto:freeipa-users- boun...@redhat.com] On Behalf Of Rob Crittenden Sent: Thursday, 18 June 2015 12:26 PM To: Randall Harrison; freeipa-users@redhat.com Subject: Re: [Freeipa-users] CentOS 6.6 Installation Issues Randall Harrison wrote: Hey Rob, I tried the install again with Java 1.7 and no joy. Do you recommend a clean install with 1.7? Be sure the CA is completely uninstalled. The installer sometimes doesn't record that a CA has been partially installed causing the uninstall to skip it, which causes subsequent installs to fail. Do this: # ipa-server-install --uninstal # /usr/bin/pkiremove -pki_instance_root=/var/lib -pki_instance_name=pki- ca --force Then try the install again. rob On Jun 17, 2015 6:15 AM, Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com wrote: Randall Harrison wrote: Hello freeipa! I am having difficulty installing freeipa on a freshly installed CentOS6.6 box. I have not had this problem on previous CentOS releases, and it installed with no problems on a CentOS7.1 box. Here is a list of steps I took to install: 1.) Disable SElinux and IPtables (for testing purposes only) 2.) reboot 3.) yum update 4.) reboot 5.) yum install ipa-server bind bind-dyndb-ldap 6.) ipa-server-install --setup-dns 7.) the install scrip errors out I have attached the ipa-server install log and pki-ca log. All help is appreciated! Randy Can you see what version of java is installed? You want 1.7.x and not 1.8.x. rob -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] clarification on expired password behaviour
From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Dmitri Pal Sent: Thursday, 26 March 2015 12:52 PM To: freeipa-users@redhat.com Subject: Re: [Freeipa-users] clarification on expired password behaviour On 03/25/2015 09:14 PM, Les Stott wrote: Hi All, Running freeipa 3.0.0.42 on rhel 6.6, all standard packages. I also have freeradius installed which is used for network devices (cisco, brocade, f5, ucs etc) to authenticate users. Freeradius is using the ldap store in FreeIPA as an authentication backend. All is working fine. But I would like clarification on the following... A user account in freeipa is showing up as having an expired password. This is confirmed by logging into the freeipa web interface or ssh and seeing a prompt to change password immediately. If I choose to not set the password, it remains expired. Now, if I try to access a network device that is using radius based auth, using the account with the expired password, it successfully logs in even though the password is expired. Is this normal? i.e. a password can still be used even if it's in an expired state? I understand that going via radius using freeipa as an ldap backend is not the normal process. Is there a way to make password authentication fail if a password is expired when used in this scenario? Thanks in advance, Regards, Les https://fedorahosted.org/freeipa/ticket/1539 You can see the details in the ticket. The workaround will be to use kinit instead of LDAP for authentication in freeradius or use pam and leverage SSSD as an IPA client on the RADIUS server. Thanks Dmitri. In fact the radius server is installed on the freeipa server and talks locally via loopback. I will look at kinit and sssd options. Regards, Les -- 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-getcert list fails to report correctly - RESOLVED
-Original Message- From: Martin Kosek [mailto:mko...@redhat.com] Sent: Wednesday, 25 February 2015 10:35 PM To: Les Stott; Rob Crittenden; freeipa-users@redhat.com; Endi Dewata; Jan Cholasta Subject: Re: [Freeipa-users] ipa-getcert list fails to report correctly - RESOLVED On 02/25/2015 03:11 AM, Les Stott wrote: -Original Message- From: freeipa-users-boun...@redhat.com [mailto:freeipa-users- boun...@redhat.com] On Behalf Of Les Stott Sent: Monday, 23 February 2015 8:01 PM To: Rob Crittenden; Martin Kosek; freeipa-users@redhat.com; Endi Dewata; Jan Cholasta Subject: Re: [Freeipa-users] ipa-getcert list fails to report correctly -Original Message- From: freeipa-users-boun...@redhat.com [mailto:freeipa-users- boun...@redhat.com] On Behalf Of Les Stott Sent: Monday, 23 February 2015 12:18 PM To: Rob Crittenden; Martin Kosek; freeipa-users@redhat.com; Endi Dewata; Jan Cholasta Subject: Re: [Freeipa-users] ipa-getcert list fails to report correctly -Original Message- From: Rob Crittenden [mailto:rcrit...@redhat.com] Sent: Saturday, 21 February 2015 1:39 AM To: Martin Kosek; Les Stott; freeipa-users@redhat.com; Endi Dewata; Jan Cholasta Subject: Re: [Freeipa-users] ipa-getcert list fails to report correctly Martin Kosek wrote: On 02/20/2015 06:56 AM, Les Stott wrote: Hi all, The following is blocking the ability for me to install a CA replica. Environment: RHEL 6.6 IPA 3.0.0-42 PKI 9.0.3-38 On the master the following is happening: ipa-getcert list Number of certificates and requests being tracked: 5. (but it shows no certificate details in the output) Running getcert list shows complete output. Also, when trying to browse https://master.mydomain.com/ca/ee/ca/getCertChain i get a failed response. The apache error logs on the master show [Thu Feb 19 23:23:23 2015] [error] SSL Library Error: -12271 SSL client cannot verify your certificate The reason I am trying to browse that address is because that's what the ipa-ca-install setup is failing at (it complains that the CA certificate is not in proper format, in fact it's not able to get it at all). I know from another working ipa setup that Browsing to the above address provides valid xml content and ipa-getcert list shows certificate details and not just the number of tracked certificates. Been trying for a long time to figure out the issues without luck. I would greatly appreciate any help to troubleshoot and resolve the above issues. Regards, Les Endi or JanC, would you have any advise for Les? To me, it looks like the Apache does not have proper certificate installed. My ipa-getcert on RHEL-6.6 shows 3 Server-Certs tracked, making it in total of 8 certs tracked: # ipa-getcert list Number of certificates and requests being tracked: 8. Request ID '201402': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-IDM-LAB-BOS-REDHAT- COM',nicknam e='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-IDM-LAB-BOS-REDHAT- COM/pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-IDM-LAB-BOS-REDHAT- COM',nicknam e='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=EXAMPLE.COM subject: CN=vm-086.example.com,O=EXAMPLE.COM expires: 2016-11-11 00:00:01 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes Request ID '201447': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server- Cert' ,token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA/pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server- Cert' ,token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=EXAMPLE.COM subject: CN=vm-086.example.com,O=EXAMPLE.COM expires: 2016-11-11 00:00:46 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes Request ID '2014000302': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',toke n= 'N SS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',toke n= 'N SS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=EXAMPLE.COM subject: CN=vm-086.example.com,O=EXAMPLE.COM
Re: [Freeipa-users] ipa-getcert list fails to report correctly - RESOLVED
-Original Message- From: Endi Sukma Dewata [mailto:edew...@redhat.com] Sent: Thursday, 26 February 2015 1:50 AM To: Martin Kosek Cc: Les Stott; Rob Crittenden; freeipa-users@redhat.com; Jan Cholasta Subject: Re: [Freeipa-users] ipa-getcert list fails to report correctly - RESOLVED On 2/25/2015 6:35 PM, Martin Kosek wrote: yum -y remove pki-selinux pki-ca pki-common pki-setup pki-silent pki-java-tools pki-symkey pki-util pki-native-tools ipa-server-selinux ipa-server ipa-client ipa-admintools ipa-python ipa-pki-ca-theme ipa-pki-common-theme 389-ds-base 389-ds-base-libs userdel pkisrv userdel pkiuser This should not be needed at all, AFAIK. This may not be related to this problem, but sometimes reinstalling the packages is necessary to resolve installation problem. For example: https://fedorahosted.org/freeipa/ticket/4591 In this ticket reinstalling 389-ds-base will recreate the missing folder. I didn't actually see this issue when I ran thought reinstall, but then I did remove and reinstall 389-ds-base which would have re-created it. Regards, Les -- 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-getcert list fails to report correctly - RESOLVED
-Original Message- From: freeipa-users-boun...@redhat.com [mailto:freeipa-users- boun...@redhat.com] On Behalf Of Les Stott Sent: Monday, 23 February 2015 8:01 PM To: Rob Crittenden; Martin Kosek; freeipa-users@redhat.com; Endi Dewata; Jan Cholasta Subject: Re: [Freeipa-users] ipa-getcert list fails to report correctly -Original Message- From: freeipa-users-boun...@redhat.com [mailto:freeipa-users- boun...@redhat.com] On Behalf Of Les Stott Sent: Monday, 23 February 2015 12:18 PM To: Rob Crittenden; Martin Kosek; freeipa-users@redhat.com; Endi Dewata; Jan Cholasta Subject: Re: [Freeipa-users] ipa-getcert list fails to report correctly -Original Message- From: Rob Crittenden [mailto:rcrit...@redhat.com] Sent: Saturday, 21 February 2015 1:39 AM To: Martin Kosek; Les Stott; freeipa-users@redhat.com; Endi Dewata; Jan Cholasta Subject: Re: [Freeipa-users] ipa-getcert list fails to report correctly Martin Kosek wrote: On 02/20/2015 06:56 AM, Les Stott wrote: Hi all, The following is blocking the ability for me to install a CA replica. Environment: RHEL 6.6 IPA 3.0.0-42 PKI 9.0.3-38 On the master the following is happening: ipa-getcert list Number of certificates and requests being tracked: 5. (but it shows no certificate details in the output) Running getcert list shows complete output. Also, when trying to browse https://master.mydomain.com/ca/ee/ca/getCertChain i get a failed response. The apache error logs on the master show [Thu Feb 19 23:23:23 2015] [error] SSL Library Error: -12271 SSL client cannot verify your certificate The reason I am trying to browse that address is because that's what the ipa-ca-install setup is failing at (it complains that the CA certificate is not in proper format, in fact it's not able to get it at all). I know from another working ipa setup that Browsing to the above address provides valid xml content and ipa-getcert list shows certificate details and not just the number of tracked certificates. Been trying for a long time to figure out the issues without luck. I would greatly appreciate any help to troubleshoot and resolve the above issues. Regards, Les Endi or JanC, would you have any advise for Les? To me, it looks like the Apache does not have proper certificate installed. My ipa-getcert on RHEL-6.6 shows 3 Server-Certs tracked, making it in total of 8 certs tracked: # ipa-getcert list Number of certificates and requests being tracked: 8. Request ID '201402': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-IDM-LAB-BOS-REDHAT- COM',nicknam e='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-IDM-LAB-BOS-REDHAT-COM/pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-IDM-LAB-BOS-REDHAT- COM',nicknam e='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=EXAMPLE.COM subject: CN=vm-086.example.com,O=EXAMPLE.COM expires: 2016-11-11 00:00:01 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes Request ID '201447': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server- Cert' ,token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA/pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server- Cert' ,token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=EXAMPLE.COM subject: CN=vm-086.example.com,O=EXAMPLE.COM expires: 2016-11-11 00:00:46 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes Request ID '2014000302': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',toke n= 'N SS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',toke n= 'N SS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=EXAMPLE.COM subject: CN=vm-086.example.com,O=EXAMPLE.COM expires: 2016-11-11 00:03:02 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment
Re: [Freeipa-users] bug in pki during install of CA replica and workaround/solution - RESOLVED
Have resolved the issues below by completely removing FreeIPA and starting from scratch. Here is the procedure to completely remove FreeIPA so you can start again. ipa-server-install --uninstall certutil -d /etc/httpd/alias -D -n Server-Cert certutil -d /etc/httpd/alias -D -n MYDOMAIN.COM IPA CA certutil -d /etc/httpd/alias -D -n ipaCert certutil -d /etc/httpd/alias -D -n Signing-Cert yum -y remove pki-selinux pki-ca pki-common pki-setup pki-silent pki-java-tools pki-symkey pki-util pki-native-tools ipa-server-selinux ipa-server ipa-client ipa-admintools ipa-python ipa-pki-ca-theme ipa-pki-common-theme 389-ds-base 389-ds-base-libs userdel pkisrv userdel pkiuser rm -rf /etc/pki-ca /var/lib/pki-ca /var/log/pki-ca /etc/certmonger /etc/sysconfig/pki-ca /etc/sysconfig/pki /var/run/pki-ca.pid /usr/share/pki /etc/ipa /var/log/ipa* reboot Now you have a clean slate. Then install works as normal for IPA Server, Replica and CA Replica installations. Hope this saves someone else time in the future. Regards, Les -Original Message- From: freeipa-users-boun...@redhat.com [mailto:freeipa-users- boun...@redhat.com] On Behalf Of Les Stott Sent: Wednesday, 18 February 2015 6:27 PM To: freeipa-users@redhat.com Subject: Re: [Freeipa-users] bug in pki during install of CA replica and workaround/solution Has anyone got any ideas on the below errors I am now receiving? Thanks in advance, Les I will test this out (update to 3.7.19-260) next week as I've got a few more CA replicas to setup. I'm still having issues. Different one this time. As I have previously worked around the install of CA replicas in my production Production environment as above, I went to setup CA replication in DR (both environments are completely separate). Make sure I did a yum update for all packages, including selinux-policy, and also making sure all needed modules were loaded in httpd.conf I proceeded to retry installation of CA replication. However, it failed with the following: Note: sb2sys01.domain.com is the replica I am trying to install (abbreviated below) # Attempting to connect to: sb2sys01.domain.com:9445 Connected. Posting Query = https://sb2sys01.domain.com:9445//ca/admin/console/config/wizard?p=7; op=nextxml=true__password=path=ca.p12 RESPONSE STATUS: HTTP/1.1 200 OK RESPONSE HEADER: Server: Apache-Coyote/1.1 RESPONSE HEADER: Content-Type: application/xml;charset=UTF-8 RESPONSE HEADER: Date: Fri, 13 Feb 2015 08:09:35 GMT RESPONSE HEADER: Connection: close ?xml version=1.0 encoding=UTF-8? !-- BEGIN COPYRIGHT BLOCK END COPYRIGHT BLOCK -- response paneladmin/console/config/restorekeycertpanel.vm/panel res/ updateStatusfailure/updateStatus password/ errorStringThe pkcs12 file is not correct./errorString size19/size Error in RestoreKeyCertPanel(): updateStatus returns failure ERROR: ConfigureCA: RestoreKeyCertPanel() failure ERROR: unable to create CA In /var/log/pki-ca/catalina.out I see... CMS Warning: FAILURE: Cannot build CA chain. Error java.security.cert.CertificateException: Certificate is not a PKCS #11 certificate|FAILURE: authz instance DirAclAuthz initialization failed certificate|and skipped, error=Property internaldb.ldapconn.port missing value| Server is started. Nothing gets populated in /etc/pki-ca/CS.cfg (based on comparison with a working system). grep DirAclAuthz /etc/pki-ca/CS.cfg authz.impl.DirAclAuthz.class=com.netscape.cms.authorization.DirAclAuth z authz.instance.DirAclAuthz.ldap=internaldb authz.instance.DirAclAuthz.pluginName=DirAclAuthz authz.instance.DirAclAuthz.ldap._000=## authz.instance.DirAclAuthz.ldap._001=## Internal Database authz.instance.DirAclAuthz.ldap._002=## authz.instance.DirAclAuthz.ldap.basedn= authz.instance.DirAclAuthz.ldap.maxConns=15 authz.instance.DirAclAuthz.ldap.minConns=3 authz.instance.DirAclAuthz.ldap.ldapauth.authtype=BasicAuth authz.instance.DirAclAuthz.ldap.ldapauth.bindDN=cn=Directory Manager authz.instance.DirAclAuthz.ldap.ldapauth.bindPWPrompt=Internal LDAP Database authz.instance.DirAclAuthz.ldap.ldapauth.clientCertNickname= authz.instance.DirAclAuthz.ldap.ldapconn.host= authz.instance.DirAclAuthz.ldap.ldapconn.port= authz.instance.DirAclAuthz.ldap.ldapconn.secureConn=false authz.instance.DirAclAuthz.ldap.multipleSuffix.enable=false The CA cert looks ok to me on the master. It does get copied to the replica in /usr/share/ipa/html/ca.crt I don't see any errors in httpd error or access logs on the master or the intended replica. The ipa-pki-proxy.conf config has the profilesubmit section. # matches for ee port LocationMatch ^/ca/ee/ca/checkRequest|^/ca/ee/ca/getCertChain|^/ca/ee/ca/getTokenI nfo|^/ca/ee/ca/tokenAuthenticate|^/ca/ocsp|^/ca/ee/ca
Re: [Freeipa-users] ipa-getcert list fails to report correctly
-Original Message- From: freeipa-users-boun...@redhat.com [mailto:freeipa-users- boun...@redhat.com] On Behalf Of Les Stott Sent: Monday, 23 February 2015 12:18 PM To: Rob Crittenden; Martin Kosek; freeipa-users@redhat.com; Endi Dewata; Jan Cholasta Subject: Re: [Freeipa-users] ipa-getcert list fails to report correctly -Original Message- From: Rob Crittenden [mailto:rcrit...@redhat.com] Sent: Saturday, 21 February 2015 1:39 AM To: Martin Kosek; Les Stott; freeipa-users@redhat.com; Endi Dewata; Jan Cholasta Subject: Re: [Freeipa-users] ipa-getcert list fails to report correctly Martin Kosek wrote: On 02/20/2015 06:56 AM, Les Stott wrote: Hi all, The following is blocking the ability for me to install a CA replica. Environment: RHEL 6.6 IPA 3.0.0-42 PKI 9.0.3-38 On the master the following is happening: ipa-getcert list Number of certificates and requests being tracked: 5. (but it shows no certificate details in the output) Running getcert list shows complete output. Also, when trying to browse https://master.mydomain.com/ca/ee/ca/getCertChain i get a failed response. The apache error logs on the master show [Thu Feb 19 23:23:23 2015] [error] SSL Library Error: -12271 SSL client cannot verify your certificate The reason I am trying to browse that address is because that's what the ipa-ca-install setup is failing at (it complains that the CA certificate is not in proper format, in fact it's not able to get it at all). I know from another working ipa setup that Browsing to the above address provides valid xml content and ipa-getcert list shows certificate details and not just the number of tracked certificates. Been trying for a long time to figure out the issues without luck. I would greatly appreciate any help to troubleshoot and resolve the above issues. Regards, Les Endi or JanC, would you have any advise for Les? To me, it looks like the Apache does not have proper certificate installed. My ipa-getcert on RHEL-6.6 shows 3 Server-Certs tracked, making it in total of 8 certs tracked: # ipa-getcert list Number of certificates and requests being tracked: 8. Request ID '201402': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-IDM-LAB-BOS-REDHAT- COM',nicknam e='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-IDM-LAB-BOS-REDHAT-COM/pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-IDM-LAB-BOS-REDHAT- COM',nicknam e='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=EXAMPLE.COM subject: CN=vm-086.example.com,O=EXAMPLE.COM expires: 2016-11-11 00:00:01 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes Request ID '201447': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert' ,token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA/pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert' ,token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=EXAMPLE.COM subject: CN=vm-086.example.com,O=EXAMPLE.COM expires: 2016-11-11 00:00:46 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes Request ID '2014000302': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token= 'N SS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token= 'N SS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=EXAMPLE.COM subject: CN=vm-086.example.com,O=EXAMPLE.COM expires: 2016-11-11 00:03:02 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes What is actually in your Apache NSS database? # certutil -L -d /etc/httpd/alias/ Martin Remember ipa-getcert is just a shortcut for certificates using the certmonger CA named IPA, so it's more a filter than anything else. I don't know why it wouldn't display any output but I'd file a bug. I think we'd
Re: [Freeipa-users] ipa-getcert list fails to report correctly
-Original Message- From: Rob Crittenden [mailto:rcrit...@redhat.com] Sent: Saturday, 21 February 2015 1:39 AM To: Martin Kosek; Les Stott; freeipa-users@redhat.com; Endi Dewata; Jan Cholasta Subject: Re: [Freeipa-users] ipa-getcert list fails to report correctly Martin Kosek wrote: On 02/20/2015 06:56 AM, Les Stott wrote: Hi all, The following is blocking the ability for me to install a CA replica. Environment: RHEL 6.6 IPA 3.0.0-42 PKI 9.0.3-38 On the master the following is happening: ipa-getcert list Number of certificates and requests being tracked: 5. (but it shows no certificate details in the output) Running getcert list shows complete output. Also, when trying to browse https://master.mydomain.com/ca/ee/ca/getCertChain i get a failed response. The apache error logs on the master show [Thu Feb 19 23:23:23 2015] [error] SSL Library Error: -12271 SSL client cannot verify your certificate The reason I am trying to browse that address is because that's what the ipa-ca-install setup is failing at (it complains that the CA certificate is not in proper format, in fact it's not able to get it at all). I know from another working ipa setup that Browsing to the above address provides valid xml content and ipa-getcert list shows certificate details and not just the number of tracked certificates. Been trying for a long time to figure out the issues without luck. I would greatly appreciate any help to troubleshoot and resolve the above issues. Regards, Les Endi or JanC, would you have any advise for Les? To me, it looks like the Apache does not have proper certificate installed. My ipa-getcert on RHEL-6.6 shows 3 Server-Certs tracked, making it in total of 8 certs tracked: # ipa-getcert list Number of certificates and requests being tracked: 8. Request ID '201402': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-IDM-LAB-BOS-REDHAT- COM',nicknam e='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-IDM-LAB-BOS-REDHAT-COM/pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-IDM-LAB-BOS-REDHAT- COM',nicknam e='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=EXAMPLE.COM subject: CN=vm-086.example.com,O=EXAMPLE.COM expires: 2016-11-11 00:00:01 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes Request ID '201447': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert' ,token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA/pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert' ,token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=EXAMPLE.COM subject: CN=vm-086.example.com,O=EXAMPLE.COM expires: 2016-11-11 00:00:46 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes Request ID '2014000302': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='N SS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='N SS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=EXAMPLE.COM subject: CN=vm-086.example.com,O=EXAMPLE.COM expires: 2016-11-11 00:03:02 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes What is actually in your Apache NSS database? # certutil -L -d /etc/httpd/alias/ Martin Remember ipa-getcert is just a shortcut for certificates using the certmonger CA named IPA, so it's more a filter than anything else. I don't know why it wouldn't display any output but I'd file a bug. I think we'd need to see the getcert list output to try to figure out what is going on. As for the SSL error fetching the cert chain I think Martin may be onto something. The request is proxied through Apache. I think the client here might be the Apache proxy client. I believe this command replicates what Apache is doing, you might give it a try on the master. This will get the chain directly from dogtag, bypassing Apache: $ curl -v --cacert /etc/ipa/ca.crt https://`hostname`:9444/ca/ee
[Freeipa-users] ipa-getcert list fails to report correctly
Hi all, The following is blocking the ability for me to install a CA replica. Environment: RHEL 6.6 IPA 3.0.0-42 PKI 9.0.3-38 On the master the following is happening: ipa-getcert list Number of certificates and requests being tracked: 5. (but it shows no certificate details in the output) Running getcert list shows complete output. Also, when trying to browse https://master.mydomain.com/ca/ee/ca/getCertChain i get a failed response. The apache error logs on the master show [Thu Feb 19 23:23:23 2015] [error] SSL Library Error: -12271 SSL client cannot verify your certificate The reason I am trying to browse that address is because that's what the ipa-ca-install setup is failing at (it complains that the CA certificate is not in proper format, in fact it's not able to get it at all). I know from another working ipa setup that Browsing to the above address provides valid xml content and ipa-getcert list shows certificate details and not just the number of tracked certificates. Been trying for a long time to figure out the issues without luck. I would greatly appreciate any help to troubleshoot and resolve the above issues. Regards, Les -- 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] bug in pki during install of CA replica and workaround/solution
Has anyone got any ideas on the below errors I am now receiving? Thanks in advance, Les I will test this out (update to 3.7.19-260) next week as I've got a few more CA replicas to setup. I'm still having issues. Different one this time. As I have previously worked around the install of CA replicas in my production Production environment as above, I went to setup CA replication in DR (both environments are completely separate). Make sure I did a yum update for all packages, including selinux-policy, and also making sure all needed modules were loaded in httpd.conf I proceeded to retry installation of CA replication. However, it failed with the following: Note: sb2sys01.domain.com is the replica I am trying to install (abbreviated below) # Attempting to connect to: sb2sys01.domain.com:9445 Connected. Posting Query = https://sb2sys01.domain.com:9445//ca/admin/console/config/wizard?p=7; op=nextxml=true__password=path=ca.p12 RESPONSE STATUS: HTTP/1.1 200 OK RESPONSE HEADER: Server: Apache-Coyote/1.1 RESPONSE HEADER: Content-Type: application/xml;charset=UTF-8 RESPONSE HEADER: Date: Fri, 13 Feb 2015 08:09:35 GMT RESPONSE HEADER: Connection: close ?xml version=1.0 encoding=UTF-8? !-- BEGIN COPYRIGHT BLOCK END COPYRIGHT BLOCK -- response paneladmin/console/config/restorekeycertpanel.vm/panel res/ updateStatusfailure/updateStatus password/ errorStringThe pkcs12 file is not correct./errorString size19/size Error in RestoreKeyCertPanel(): updateStatus returns failure ERROR: ConfigureCA: RestoreKeyCertPanel() failure ERROR: unable to create CA In /var/log/pki-ca/catalina.out I see... CMS Warning: FAILURE: Cannot build CA chain. Error java.security.cert.CertificateException: Certificate is not a PKCS #11 certificate|FAILURE: authz instance DirAclAuthz initialization failed and skipped, error=Property internaldb.ldapconn.port missing value| Server is started. Nothing gets populated in /etc/pki-ca/CS.cfg (based on comparison with a working system). grep DirAclAuthz /etc/pki-ca/CS.cfg authz.impl.DirAclAuthz.class=com.netscape.cms.authorization.DirAclAuthz authz.instance.DirAclAuthz.ldap=internaldb authz.instance.DirAclAuthz.pluginName=DirAclAuthz authz.instance.DirAclAuthz.ldap._000=## authz.instance.DirAclAuthz.ldap._001=## Internal Database authz.instance.DirAclAuthz.ldap._002=## authz.instance.DirAclAuthz.ldap.basedn= authz.instance.DirAclAuthz.ldap.maxConns=15 authz.instance.DirAclAuthz.ldap.minConns=3 authz.instance.DirAclAuthz.ldap.ldapauth.authtype=BasicAuth authz.instance.DirAclAuthz.ldap.ldapauth.bindDN=cn=Directory Manager authz.instance.DirAclAuthz.ldap.ldapauth.bindPWPrompt=Internal LDAP Database authz.instance.DirAclAuthz.ldap.ldapauth.clientCertNickname= authz.instance.DirAclAuthz.ldap.ldapconn.host= authz.instance.DirAclAuthz.ldap.ldapconn.port= authz.instance.DirAclAuthz.ldap.ldapconn.secureConn=false authz.instance.DirAclAuthz.ldap.multipleSuffix.enable=false The CA cert looks ok to me on the master. It does get copied to the replica in /usr/share/ipa/html/ca.crt I don't see any errors in httpd error or access logs on the master or the intended replica. The ipa-pki-proxy.conf config has the profilesubmit section. # matches for ee port LocationMatch ^/ca/ee/ca/checkRequest|^/ca/ee/ca/getCertChain|^/ca/ee/ca/getTokenI nfo|^/ca/ee/ca/tokenAuthenticate|^/ca/ocsp|^/ca/ee/ca/updateNumberR ange|^/ca/ee/ca/getCRL|^/ca/ee/ca/profileSubmit I can confirm that pki-cad does start (but is unconfigured) and that it does listen on port 9445. # netstat -apn |grep 9445 tcp0 0 :::9445 :::* LISTEN 31264/java # service pki-cad status pki-ca (pid 31264) is running... [ OK ] 'pki-ca' must still be CONFIGURED! (see /var/log/pki-ca-install.log) I am not sure what to try next. Appreciate any help to get over this error. Thanks, Les -- 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] bug in pki during install of CA replica and workaround/solution
-Original Message- From: freeipa-users-boun...@redhat.com [mailto:freeipa-users- boun...@redhat.com] On Behalf Of Les Stott Sent: Saturday, 7 February 2015 9:39 AM To: freeipa-users@redhat.com Subject: Re: [Freeipa-users] bug in pki during install of CA replica and workaround/solution -Original Message- From: Endi Sukma Dewata [mailto:edew...@redhat.com] Sent: Saturday, 7 February 2015 1:53 AM To: Martin Kosek; Les Stott; freeipa-users@redhat.com; Matthew Harmsen Subject: Re: [Freeipa-users] bug in pki during install of CA replica and workaround/solution On 2/6/2015 8:39 AM, Martin Kosek wrote: Reinstalling the pki-selinux rpm (found references in some other forum posts) via yum reinstall pki-selinux is not enough to help. The solution is as follows: yum downgrade pki-selinux pki-ca pki-common pki-setup pki-silent pki-java-tools pki-symkey pki-util pki-native-tools which takes components back to 9.0.3-32 then yum -y update pki-selinux pki-ca pki-common pki-setup pki-silent pki-java-tools pki-symkey pki-util pki-native-tools then (after cleaning up half installed pki components) ipa-ca-install /var/lib/ipa/replica-info-sb1sys02.mydomain.gpg Then, the CA replication completes successfully. Regards, Les I saw this one around, e.g. in: http://www.redhat.com/archives/freeipa-devel/2014- May/msg00507.html Did you try reinstalling pki-selinux before ipa-server-install? Endi/Matthew, do we have a bug/fix for this? Thanks, Martin Yes, we have a ticket for this: https://fedorahosted.org/pki/ticket/1243 The default selinux-policy is version 3.7.19-231. It needs to be updated to at least version 3.7.19-260. -- Endi S. Dewata I will test this out (update to 3.7.19-260) next week as I've got a few more CA replicas to setup. I'm still having issues. Different one this time. As I have previously worked around the install of CA replicas in my production Production environment as above, I went to setup CA replication in DR (both environments are completely separate). Make sure I did a yum update for all packages, including selinux-policy, and also making sure all needed modules were loaded in httpd.conf I proceeded to retry installation of CA replication. However, it failed with the following: Note: sb2sys01.domain.com is the replica I am trying to install (abbreviated below) # Attempting to connect to: sb2sys01.domain.com:9445 Connected. Posting Query = https://sb2sys01.domain.com:9445//ca/admin/console/config/wizard?p=7op=nextxml=true__password=path=ca.p12 RESPONSE STATUS: HTTP/1.1 200 OK RESPONSE HEADER: Server: Apache-Coyote/1.1 RESPONSE HEADER: Content-Type: application/xml;charset=UTF-8 RESPONSE HEADER: Date: Fri, 13 Feb 2015 08:09:35 GMT RESPONSE HEADER: Connection: close ?xml version=1.0 encoding=UTF-8? !-- BEGIN COPYRIGHT BLOCK END COPYRIGHT BLOCK -- response paneladmin/console/config/restorekeycertpanel.vm/panel res/ updateStatusfailure/updateStatus password/ errorStringThe pkcs12 file is not correct./errorString size19/size Error in RestoreKeyCertPanel(): updateStatus returns failure ERROR: ConfigureCA: RestoreKeyCertPanel() failure ERROR: unable to create CA In /var/log/pki-ca/catalina.out I see... CMS Warning: FAILURE: Cannot build CA chain. Error java.security.cert.CertificateException: Certificate is not a PKCS #11 certificate|FAILURE: authz instance DirAclAuthz initialization failed and skipped, error=Property internaldb.ldapconn.port missing value| Server is started. Nothing gets populated in /etc/pki-ca/CS.cfg (based on comparison with a working system). grep DirAclAuthz /etc/pki-ca/CS.cfg authz.impl.DirAclAuthz.class=com.netscape.cms.authorization.DirAclAuthz authz.instance.DirAclAuthz.ldap=internaldb authz.instance.DirAclAuthz.pluginName=DirAclAuthz authz.instance.DirAclAuthz.ldap._000=## authz.instance.DirAclAuthz.ldap._001=## Internal Database authz.instance.DirAclAuthz.ldap._002=## authz.instance.DirAclAuthz.ldap.basedn= authz.instance.DirAclAuthz.ldap.maxConns=15 authz.instance.DirAclAuthz.ldap.minConns=3 authz.instance.DirAclAuthz.ldap.ldapauth.authtype=BasicAuth authz.instance.DirAclAuthz.ldap.ldapauth.bindDN=cn=Directory Manager authz.instance.DirAclAuthz.ldap.ldapauth.bindPWPrompt=Internal LDAP Database authz.instance.DirAclAuthz.ldap.ldapauth.clientCertNickname= authz.instance.DirAclAuthz.ldap.ldapconn.host= authz.instance.DirAclAuthz.ldap.ldapconn.port= authz.instance.DirAclAuthz.ldap.ldapconn.secureConn=false authz.instance.DirAclAuthz.ldap.multipleSuffix.enable=false The CA cert looks ok to me on the master. It does get copied to the replica in /usr/share/ipa/html/ca.crt I don't see any errors in httpd error or access logs on the master or the intended replica. The ipa-pki
Re: [Freeipa-users] bug in pki during install of CA replica and workaround/solution
-Original Message- From: Martin Kosek [mailto:mko...@redhat.com] Sent: Saturday, 7 February 2015 1:40 AM To: Les Stott; freeipa-users@redhat.com; Matthew Harmsen; Endi Dewata Subject: Re: [Freeipa-users] bug in pki during install of CA replica and workaround/solution On 02/06/2015 06:59 AM, Les Stott wrote: Hi, I found a bug in the pki packages and CA replica installation. Environment: Rhel 6.6 IPA Server 3.0.0-42 Pki components: pki-symkey-9.0.3-38.el6_6.x86_64 pki-common-9.0.3-38.el6_6.noarch pki-setup-9.0.3-38.el6_6.noarch pki-selinux-9.0.3-38.el6_6.noarch pki-java-tools-9.0.3-38.el6_6.noarch pki-ca-9.0.3-38.el6_6.noarch ipa-pki-common-theme-9.0.3-7.el6.noarch ipa-pki-ca-theme-9.0.3-7.el6.noarch pki-native-tools-9.0.3-38.el6_6.x86_64 pki-util-9.0.3-38.el6_6.noarch pki-silent-9.0.3-38.el6_6.noarch Selinux: Permissive when running a CA replica installation it fails because pki-cad cannot start due to selinux context issues. Samples from the ipareplica-ca-install.log... = 2015-02-05T08:20:04Z DEBUG stderr=[error] FAILED run_comman[ OK ]/service pki-cad restart pki-ca), exit status=1 output=Stopping pki-ca: /usr/bin/runcon: invalid context: unconfined_u:system_r:pki_ca_script_t:s0: Invalid argument 2015-02-05T08:20:04Z DEBUG duration: 6 seconds 2015-02-05T08:20:04Z DEBUG [3/16]: configuring certificate server instance # Attempting to connect to: sb1sys02.mydomain.com:9445 Exception in LoginPanel(): java.lang.NullPointerException ERROR: ConfigureCA: LoginPanel() failure ERROR: unable to create CA ### ### # 2015-02-05T08:20:04Z DEBUG stderr=Exception: Unable to Send Request:java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused == In short pki-cad fails to start and stops the installer. Reinstalling the pki-selinux rpm (found references in some other forum posts) via yum reinstall pki-selinux is not enough to help. The solution is as follows: yum downgrade pki-selinux pki-ca pki-common pki-setup pki-silent pki-java-tools pki-symkey pki-util pki-native-tools which takes components back to 9.0.3-32 then yum -y update pki-selinux pki-ca pki-common pki-setup pki-silent pki-java-tools pki-symkey pki-util pki-native-tools then (after cleaning up half installed pki components) ipa-ca-install /var/lib/ipa/replica-info-sb1sys02.mydomain.gpg Then, the CA replication completes successfully. Regards, Les I saw this one around, e.g. in: http://www.redhat.com/archives/freeipa-devel/2014-May/msg00507.html Did you try reinstalling pki-selinux before ipa-server-install? Yes, tried this. But it was not enough. Endi/Matthew, do we have a bug/fix for this? Thanks, Martin -- 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] bug in pki during install of CA replica and workaround/solution
-Original Message- From: Endi Sukma Dewata [mailto:edew...@redhat.com] Sent: Saturday, 7 February 2015 1:53 AM To: Martin Kosek; Les Stott; freeipa-users@redhat.com; Matthew Harmsen Subject: Re: [Freeipa-users] bug in pki during install of CA replica and workaround/solution On 2/6/2015 8:39 AM, Martin Kosek wrote: Reinstalling the pki-selinux rpm (found references in some other forum posts) via yum reinstall pki-selinux is not enough to help. The solution is as follows: yum downgrade pki-selinux pki-ca pki-common pki-setup pki-silent pki-java-tools pki-symkey pki-util pki-native-tools which takes components back to 9.0.3-32 then yum -y update pki-selinux pki-ca pki-common pki-setup pki-silent pki-java-tools pki-symkey pki-util pki-native-tools then (after cleaning up half installed pki components) ipa-ca-install /var/lib/ipa/replica-info-sb1sys02.mydomain.gpg Then, the CA replication completes successfully. Regards, Les I saw this one around, e.g. in: http://www.redhat.com/archives/freeipa-devel/2014- May/msg00507.html Did you try reinstalling pki-selinux before ipa-server-install? Endi/Matthew, do we have a bug/fix for this? Thanks, Martin Yes, we have a ticket for this: https://fedorahosted.org/pki/ticket/1243 The default selinux-policy is version 3.7.19-231. It needs to be updated to at least version 3.7.19-260. -- Endi S. Dewata I will test this out (update to 3.7.19-260) next week as I've got a few more CA replicas to setup. Thanks, Les -- 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] bug in pki during install of CA replica and workaround/solution
Hi, I found a bug in the pki packages and CA replica installation. Environment: Rhel 6.6 IPA Server 3.0.0-42 Pki components: pki-symkey-9.0.3-38.el6_6.x86_64 pki-common-9.0.3-38.el6_6.noarch pki-setup-9.0.3-38.el6_6.noarch pki-selinux-9.0.3-38.el6_6.noarch pki-java-tools-9.0.3-38.el6_6.noarch pki-ca-9.0.3-38.el6_6.noarch ipa-pki-common-theme-9.0.3-7.el6.noarch ipa-pki-ca-theme-9.0.3-7.el6.noarch pki-native-tools-9.0.3-38.el6_6.x86_64 pki-util-9.0.3-38.el6_6.noarch pki-silent-9.0.3-38.el6_6.noarch Selinux: Permissive when running a CA replica installation it fails because pki-cad cannot start due to selinux context issues. Samples from the ipareplica-ca-install.log... = 2015-02-05T08:20:04Z DEBUG stderr=[error] FAILED run_comman[ OK ]/service pki-cad restart pki-ca), exit status=1 output=Stopping pki-ca: /usr/bin/runcon: invalid context: unconfined_u:system_r:pki_ca_script_t:s0: Invalid argument 2015-02-05T08:20:04Z DEBUG duration: 6 seconds 2015-02-05T08:20:04Z DEBUG [3/16]: configuring certificate server instance # Attempting to connect to: sb1sys02.mydomain.com:9445 Exception in LoginPanel(): java.lang.NullPointerException ERROR: ConfigureCA: LoginPanel() failure ERROR: unable to create CA ### 2015-02-05T08:20:04Z DEBUG stderr=Exception: Unable to Send Request:java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused == In short pki-cad fails to start and stops the installer. Reinstalling the pki-selinux rpm (found references in some other forum posts) via yum reinstall pki-selinux is not enough to help. The solution is as follows: yum downgrade pki-selinux pki-ca pki-common pki-setup pki-silent pki-java-tools pki-symkey pki-util pki-native-tools which takes components back to 9.0.3-32 then yum -y update pki-selinux pki-ca pki-common pki-setup pki-silent pki-java-tools pki-symkey pki-util pki-native-tools then (after cleaning up half installed pki components) ipa-ca-install /var/lib/ipa/replica-info-sb1sys02.mydomain.gpg Then, the CA replication completes successfully. Regards, Les -- 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 Replication Installation Failing - SOLVED!
Guys, Thanks for your help. You pointed me in the right direction (checking the apache logs). In the end, it was missing modules in httpd.conf on the Master. I saw this error in /var/log/httpd/error_log [Wed Feb 04 21:26:00 2015] [warn] proxy: No protocol handler was valid for the URL /ca/admin/ca/getStatus. If you are using a DSO version of mod_proxy, make sure the proxy submodules are included in the configuration using LoadModule. [Wed Feb 04 21:26:00 2015] [warn] proxy: No protocol handler was valid for the URL /ca/admin/ca/getCertChain. If you are using a DSO version of mod_proxy, make sure the proxy submodules are included in the configuration using LoadModule. These modules were not being loaded... LoadModule proxy_ftp_module modules/mod_proxy_ftp.so LoadModule proxy_http_module modules/mod_proxy_http.so LoadModule proxy_ajp_module modules/mod_proxy_ajp.so LoadModule proxy_connect_module modules/mod_proxy_connect.so Now it works. (well I have a different issue now with setting up a second replica ca, but that's another story and better in a new thread) Thanks, Les -Original Message- From: Rob Crittenden [mailto:rcrit...@redhat.com] Sent: Thursday, 5 February 2015 2:24 AM To: Les Stott; freeipa-users@redhat.com Cc: Ade Lee Subject: Re: [Freeipa-users] CA Replication Installation Failing Les Stott wrote: Has anyone got any ideas on this? I am stuck with not being able to deploy a CA Replica and this is halting rollout of the project. Help please... Regards, What is the version of IPA on the master you are connecting to? Can you confirm on the existing master that /etc/httpd/conf.d/ipa-pki- proxy.conf has /ca/ee/ca/profileSubmit in it: # matches for ee port LocationMatch ^/ca/ee/ca/checkRequest|^/ca/ee/ca/getCertChain|^/ca/ ee/ca/getTokenInfo|^/ca/ee/ca/tokenAuthenticate|^/ca/ocsp|^/ca/ee/ca/ updateNumberRange|^/ca/ee/ca/getCRL|^/ca/ee/ca/profileSubmit rob Les -Original Message- From: freeipa-users-boun...@redhat.com [mailto:freeipa-users- boun...@redhat.com] On Behalf Of Les Stott Sent: Friday, 30 January 2015 4:48 PM To: freeipa-users@redhat.com Subject: Re: [Freeipa-users] CA Replication Installation Failing -Original Message- From: freeipa-users-boun...@redhat.com [mailto:freeipa-users- boun...@redhat.com] On Behalf Of Les Stott Sent: Wednesday, 10 December 2014 6:22 PM To: freeipa-users@redhat.com Subject: Re: [Freeipa-users] CA Replication Installation Failing -Original Message- From: Ade Lee [mailto:a...@redhat.com] Sent: Wednesday, 10 December 2014 5:05 AM To: Les Stott Cc: freeipa-users@redhat.com Subject: Re: [Freeipa-users] CA Replication Installation Failing On Tue, 2014-12-09 at 07:48 +, Les Stott wrote: __ From: freeipa-users-boun...@redhat.com [freeipa-users-boun...@redhat.com] on behalf of Dmitri Pal [d...@redhat.com] Sent: Tuesday, December 09, 2014 3:49 PM To: freeipa-users@redhat.com Subject: Re: [Freeipa-users] CA Replication Installation Failing On 12/08/2014 11:04 PM, Les Stott wrote: Does anyone have any ideas on the below errors when trying to add CA replication to an existing replica? People who might be able to help are or PTO right now. Is your installation older than 2 years? No, December 2013 was when it was originally built. Did you generate a new replica package or use the original one? I used the original replica file for serverb, based on instructions i came across. I can try regenerating the replica file. Interestingly, now that you mention it, servera had to be restored a couple of months back. Perhaps this is an issue and regenerating the replica file for serverb will be required. I will try this. I think that this is a safe bet to be the problem. The error in the log snippet you posted says: errorStringThe pkcs12 file is not correct./errorString This indicates that the clone CA was unable to decode the pkcs12 file in the replica. Perhaps the certs changed -- or the DM password changed? Ade I regenerated the replica file and retired the CA replica setup, but it failed at the same point with the same error. I am thinking that the next step is to uninstall the ipa replica to cleanup, remove all traces and re-add as a replica on serverb. I wonder if the cert that its having an issue with is the one on serverB under /etc/ipa/ca.crt which is from Dec 2013. I will try that in a couple of days as I have to schedule this work in as its in production. Regards, Les May be the problem is that the cert that is in that package already expired? original replica file was created on Dec 16 2013. Cert is not set to expire until 2015-12-17. Just a thought... The simplest workaround IMO would
Re: [Freeipa-users] CA Replication Installation Failing
Has anyone got any ideas on this? I am stuck with not being able to deploy a CA Replica and this is halting rollout of the project. Help please... Regards, Les -Original Message- From: freeipa-users-boun...@redhat.com [mailto:freeipa-users- boun...@redhat.com] On Behalf Of Les Stott Sent: Friday, 30 January 2015 4:48 PM To: freeipa-users@redhat.com Subject: Re: [Freeipa-users] CA Replication Installation Failing -Original Message- From: freeipa-users-boun...@redhat.com [mailto:freeipa-users- boun...@redhat.com] On Behalf Of Les Stott Sent: Wednesday, 10 December 2014 6:22 PM To: freeipa-users@redhat.com Subject: Re: [Freeipa-users] CA Replication Installation Failing -Original Message- From: Ade Lee [mailto:a...@redhat.com] Sent: Wednesday, 10 December 2014 5:05 AM To: Les Stott Cc: freeipa-users@redhat.com Subject: Re: [Freeipa-users] CA Replication Installation Failing On Tue, 2014-12-09 at 07:48 +, Les Stott wrote: __ From: freeipa-users-boun...@redhat.com [freeipa-users-boun...@redhat.com] on behalf of Dmitri Pal [d...@redhat.com] Sent: Tuesday, December 09, 2014 3:49 PM To: freeipa-users@redhat.com Subject: Re: [Freeipa-users] CA Replication Installation Failing On 12/08/2014 11:04 PM, Les Stott wrote: Does anyone have any ideas on the below errors when trying to add CA replication to an existing replica? People who might be able to help are or PTO right now. Is your installation older than 2 years? No, December 2013 was when it was originally built. Did you generate a new replica package or use the original one? I used the original replica file for serverb, based on instructions i came across. I can try regenerating the replica file. Interestingly, now that you mention it, servera had to be restored a couple of months back. Perhaps this is an issue and regenerating the replica file for serverb will be required. I will try this. I think that this is a safe bet to be the problem. The error in the log snippet you posted says: errorStringThe pkcs12 file is not correct./errorString This indicates that the clone CA was unable to decode the pkcs12 file in the replica. Perhaps the certs changed -- or the DM password changed? Ade I regenerated the replica file and retired the CA replica setup, but it failed at the same point with the same error. I am thinking that the next step is to uninstall the ipa replica to cleanup, remove all traces and re-add as a replica on serverb. I wonder if the cert that its having an issue with is the one on serverB under /etc/ipa/ca.crt which is from Dec 2013. I will try that in a couple of days as I have to schedule this work in as its in production. Regards, Les May be the problem is that the cert that is in that package already expired? original replica file was created on Dec 16 2013. Cert is not set to expire until 2015-12-17. Just a thought... The simplest workaround IMO would be to prepare Server C, install it with CA and then decommission replica B. Do not forget to clean replication agreements on master. But that would be work around, would not solve this specific problem, it will kill it. I actually do have serverc and serverd. I planned to have CA replication on at least 2 other servers, but held off on trying on serverc due to issues with serverb. I'll report back what i find after regenerating the replica file and re-trying to setup CA replication. After a bit of a hiatus I have revisited this issue and I still have it. Just to re-iterate the problem... Trying to setup a ca replica on an already installed replica fails in rhel 6.6, ipa-3.0.0.42, pki 9.0.3-38. /usr/sbin/ipa-ca-install -p xx -w xx -U /var/lib/ipa/replica-info- myhost.mydomain.com.gpg It fails showing CRITICAL failed to configure ca instance Configuring certificate server (pki-cad): Estimated time 3 minutes 30 seconds [1/16]: creating certificate server user [2/16]: creating pki-ca instance [3/16]: configuring certificate server instance Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. It doesn't matter if I run it interactively or unattended. I have done this on similar servers that were rhel 6.5, pki-9.0.3-32, ipa 3.0.0- 37 without any issue. The /var/log/ipareplica-ca-install.log shows the following error about White Spaces: # Attempting to connect to: mymaster.mydomain.com:9445 Connected. Posting Query = https:// mymaster.mydomain.com:9445//ca/admin/console
Re: [Freeipa-users] CA Replication Installation Failing
-Original Message- From: freeipa-users-boun...@redhat.com [mailto:freeipa-users- boun...@redhat.com] On Behalf Of Les Stott Sent: Wednesday, 10 December 2014 6:22 PM To: freeipa-users@redhat.com Subject: Re: [Freeipa-users] CA Replication Installation Failing -Original Message- From: Ade Lee [mailto:a...@redhat.com] Sent: Wednesday, 10 December 2014 5:05 AM To: Les Stott Cc: freeipa-users@redhat.com Subject: Re: [Freeipa-users] CA Replication Installation Failing On Tue, 2014-12-09 at 07:48 +, Les Stott wrote: __ From: freeipa-users-boun...@redhat.com [freeipa-users-boun...@redhat.com] on behalf of Dmitri Pal [d...@redhat.com] Sent: Tuesday, December 09, 2014 3:49 PM To: freeipa-users@redhat.com Subject: Re: [Freeipa-users] CA Replication Installation Failing On 12/08/2014 11:04 PM, Les Stott wrote: Does anyone have any ideas on the below errors when trying to add CA replication to an existing replica? People who might be able to help are or PTO right now. Is your installation older than 2 years? No, December 2013 was when it was originally built. Did you generate a new replica package or use the original one? I used the original replica file for serverb, based on instructions i came across. I can try regenerating the replica file. Interestingly, now that you mention it, servera had to be restored a couple of months back. Perhaps this is an issue and regenerating the replica file for serverb will be required. I will try this. I think that this is a safe bet to be the problem. The error in the log snippet you posted says: errorStringThe pkcs12 file is not correct./errorString This indicates that the clone CA was unable to decode the pkcs12 file in the replica. Perhaps the certs changed -- or the DM password changed? Ade I regenerated the replica file and retired the CA replica setup, but it failed at the same point with the same error. I am thinking that the next step is to uninstall the ipa replica to cleanup, remove all traces and re-add as a replica on serverb. I wonder if the cert that its having an issue with is the one on serverB under /etc/ipa/ca.crt which is from Dec 2013. I will try that in a couple of days as I have to schedule this work in as its in production. Regards, Les May be the problem is that the cert that is in that package already expired? original replica file was created on Dec 16 2013. Cert is not set to expire until 2015-12-17. Just a thought... The simplest workaround IMO would be to prepare Server C, install it with CA and then decommission replica B. Do not forget to clean replication agreements on master. But that would be work around, would not solve this specific problem, it will kill it. I actually do have serverc and serverd. I planned to have CA replication on at least 2 other servers, but held off on trying on serverc due to issues with serverb. I'll report back what i find after regenerating the replica file and re-trying to setup CA replication. After a bit of a hiatus I have revisited this issue and I still have it. Just to re-iterate the problem... Trying to setup a ca replica on an already installed replica fails in rhel 6.6, ipa-3.0.0.42, pki 9.0.3-38. /usr/sbin/ipa-ca-install -p xx -w xx -U /var/lib/ipa/replica-info-myhost.mydomain.com.gpg It fails showing CRITICAL failed to configure ca instance Configuring certificate server (pki-cad): Estimated time 3 minutes 30 seconds [1/16]: creating certificate server user [2/16]: creating pki-ca instance [3/16]: configuring certificate server instance Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. It doesn't matter if I run it interactively or unattended. I have done this on similar servers that were rhel 6.5, pki-9.0.3-32, ipa 3.0.0-37 without any issue. The /var/log/ipareplica-ca-install.log shows the following error about White Spaces: # Attempting to connect to: mymaster.mydomain.com:9445 Connected. Posting Query = https:// mymaster.mydomain.com:9445//ca/admin/console/config/wizard?sdomainURL=https%3A%2F%2Fmymaster.mydomain.com%3A443sdomainName=choice=existingdomainp=3op=nextxml=true RESPONSE STATUS: HTTP/1.1 200 OK RESPONSE HEADER: Server: Apache-Coyote/1.1 RESPONSE HEADER: Content-Type: application/xml;charset=UTF-8 RESPONSE HEADER: Date: Fri, 30 Jan 2015 05:05:04 GMT RESPONSE HEADER: Connection: close ?xml version=1.0 encoding=UTF-8? response paneladmin/console/config/securitydomainpanel.vm/panel https_agent_port443/https_agent_port machineNamemymaster.mydomain.com/machineName res/ cstypeCA/cstype initCommand
Re: [Freeipa-users] CA Replication Installation Failing
Does anyone have any ideas on the below errors when trying to add CA replication to an existing replica? Thanks in advance, Les From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Les Stott Sent: Tuesday, 2 December 2014 6:17 PM To: freeipa-users@redhat.com Subject: [Freeipa-users] CA Replication Installation Failing Hi All, I have RHEL6 with ipa servers running standard ipa server 3.0.0-42. Pki components are also standard version 9.0.3-38. Servera is the master Serverb is the replica Both have been running for many, many months. Serverb was initially setup as a replica, but not a CA replica. I am now trying to add CA Replication to serverb but it is failing midway through and I cannot figure out why. Annoyingly, I used the same method/command to setup a CA replica on test servers and it completed without issue. Here is what I get(for the sake of brevity, I am excluding the lines for connection check which were all OK) = /usr/sbin/ipa-ca-install /var/lib/ipa/replica-info-serverb.mydomain.com.gpg Directory Manager (existing master) password: Get credentials to log in to remote master ad...@mydomain.commailto:ad...@mydomain.com password: Execute check on remote master Connection check OK Configuring directory server for the CA (pkids): Estimated time 30 seconds [1/3]: creating directory server user [2/3]: creating directory server instance [3/3]: restarting directory server Done configuring directory server for the CA (pkids). Configuring certificate server (pki-cad): Estimated time 3 minutes 30 seconds [1/16]: creating certificate server user [2/16]: creating pki-ca instance [3/16]: configuring certificate server instance ipa : CRITICAL failed to configure ca instance Command '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname serverb.mydomain.com -cs_port 9445 -client_certdb_dir /tmp/tmp-t3aHM7 -client_certdb_pwd -preop_pin exoyO2y7bawG5yjZMACM -domain_name IPA -admin_user admin -admin_email root@localhost -admin_password -agent_name ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa -agent_cert_subject CN=ipa-ca-agent,O=MYDOMAIN.COM -ldap_host serverb.mydomain.com -ldap_port 7389 -bind_dn cn=Directory Manager -bind_password -base_dn o=ipaca -db_name ipaca -key_size 2048 -key_type rsa -key_algorithm SHA256withRSA -save_p12 true -backup_pwd -subsystem_name pki-cad -token_name internal -ca_subsystem_cert_subject_name CN=CA Subsystem,O=MYDOMAIN.COM -ca_subsystem_cert_subject_name CN=CA Subsystem,O=MYDOMAIN.COM -ca_ocsp_cert_subject_name CN=OCSP Subsystem,O=MYDOMAIN.COM -ca_server_cert_subject_name CN=serverb.mydomain.com,O=MYDOMAIN.COM -ca_audit_signing_cert_subject_name CN=CA Audit,O=MYDOMAIN.COM -ca_sign_cert_subject_name CN=Certificate Authority,O=MYDOMAIN.COM -external false -clone true -clone_p12_file ca.p12 -clone_p12_password -sd_hostname servera.mydomain.com -sd_admin_port 443 -sd_admin_name admin -sd_admin_password -clone_start_tls true -clone_uri https://servera.mydomain.com:443' returned non-zero exit status 255 Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. Configuration of CA failed = Additional excerpt from the log file /var/log/ipareplica-ca-install.log at the point of failure = # Attempting to connect to: serverb.mydomain.com:9445 Connected. Posting Query = https://serverb.mydomain.com:9445//ca/admin/console/config/wizard?p=7op=nextxml=true__password=path=ca.p12https://serverb.mydomain.com:9445/ca/admin/console/config/wizard?p=7op=nextxml=true__password=path=ca.p12 RESPONSE STATUS: HTTP/1.1 200 OK RESPONSE HEADER: Server: Apache-Coyote/1.1 RESPONSE HEADER: Content-Type: application/xml;charset=UTF-8 RESPONSE HEADER: Date: Tue, 02 Dec 2014 05:44:19 GMT RESPONSE HEADER: Connection: close ?xml version=1.0 encoding=UTF-8? !-- BEGIN COPYRIGHT BLOCK This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; version 2 of the License. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. Copyright (C) 2007 Red Hat, Inc. All rights reserved. END COPYRIGHT BLOCK -- response paneladmin/console/config/restorekeycertpanel.vm/panel res/ updateStatusfailure/updateStatus password/ errorStringThe pkcs12 file
Re: [Freeipa-users] CA Replication Installation Failing
From: freeipa-users-boun...@redhat.com [freeipa-users-boun...@redhat.com] on behalf of Dmitri Pal [d...@redhat.com] Sent: Tuesday, December 09, 2014 3:49 PM To: freeipa-users@redhat.com Subject: Re: [Freeipa-users] CA Replication Installation Failing On 12/08/2014 11:04 PM, Les Stott wrote: Does anyone have any ideas on the below errors when trying to add CA replication to an existing replica? People who might be able to help are or PTO right now. Is your installation older than 2 years? No, December 2013 was when it was originally built. Did you generate a new replica package or use the original one? I used the original replica file for serverb, based on instructions i came across. I can try regenerating the replica file. Interestingly, now that you mention it, servera had to be restored a couple of months back. Perhaps this is an issue and regenerating the replica file for serverb will be required. I will try this. May be the problem is that the cert that is in that package already expired? original replica file was created on Dec 16 2013. Cert is not set to expire until 2015-12-17. Just a thought... The simplest workaround IMO would be to prepare Server C, install it with CA and then decommission replica B. Do not forget to clean replication agreements on master. But that would be work around, would not solve this specific problem, it will kill it. I actually do have serverc and serverd. I planned to have CA replication on at least 2 other servers, but held off on trying on serverc due to issues with serverb. I'll report back what i find after regenerating the replica file and re-trying to setup CA replication. Thanks, Les Thanks in advance, Les From: freeipa-users-boun...@redhat.commailto:freeipa-users-boun...@redhat.com [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Les Stott Sent: Tuesday, 2 December 2014 6:17 PM To: freeipa-users@redhat.commailto:freeipa-users@redhat.com Subject: [Freeipa-users] CA Replication Installation Failing Hi All, I have RHEL6 with ipa servers running standard ipa server 3.0.0-42. Pki components are also standard version 9.0.3-38. Servera is the master Serverb is the replica Both have been running for many, many months. Serverb was initially setup as a replica, but not a CA replica. I am now trying to add CA Replication to serverb but it is failing midway through and I cannot figure out why. Annoyingly, I used the same method/command to setup a CA replica on test servers and it completed without issue. Here is what I get….(for the sake of brevity, I am excluding the lines for connection check which were all OK) = /usr/sbin/ipa-ca-install /var/lib/ipa/replica-info-serverb.mydomain.com.gpg Directory Manager (existing master) password: Get credentials to log in to remote master ad...@mydomain.commailto:ad...@mydomain.com password: Execute check on remote master Connection check OK Configuring directory server for the CA (pkids): Estimated time 30 seconds [1/3]: creating directory server user [2/3]: creating directory server instance [3/3]: restarting directory server Done configuring directory server for the CA (pkids). Configuring certificate server (pki-cad): Estimated time 3 minutes 30 seconds [1/16]: creating certificate server user [2/16]: creating pki-ca instance [3/16]: configuring certificate server instance ipa : CRITICAL failed to configure ca instance Command '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname serverb.mydomain.com -cs_port 9445 -client_certdb_dir /tmp/tmp-t3aHM7 -client_certdb_pwd -preop_pin exoyO2y7bawG5yjZMACM -domain_name IPA -admin_user admin -admin_email root@localhost -admin_password -agent_name ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa -agent_cert_subject CN=ipa-ca-agent,O=MYDOMAIN.COM -ldap_host serverb.mydomain.com -ldap_port 7389 -bind_dn cn=Directory Manager -bind_password -base_dn o=ipaca -db_name ipaca -key_size 2048 -key_type rsa -key_algorithm SHA256withRSA -save_p12 true -backup_pwd -subsystem_name pki-cad -token_name internal -ca_subsystem_cert_subject_name CN=CA Subsystem,O=MYDOMAIN.COM -ca_subsystem_cert_subject_name CN=CA Subsystem,O=MYDOMAIN.COM -ca_ocsp_cert_subject_name CN=OCSP Subsystem,O=MYDOMAIN.COM -ca_server_cert_subject_name CN=serverb.mydomain.com,O=MYDOMAIN.COM -ca_audit_signing_cert_subject_name CN=CA Audit,O=MYDOMAIN.COM -ca_sign_cert_subject_name CN=Certificate Authority,O=MYDOMAIN.COM -external false -clone true -clone_p12_file ca.p12 -clone_p12_password -sd_hostname servera.mydomain.com -sd_admin_port 443 -sd_admin_name admin -sd_admin_password -clone_start_tls true -clone_uri https://servera.mydomain.com:443' returned non-zero exit status 255 Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. Configuration of CA failed
[Freeipa-users] CA Replication Installation Failing
Hi All, I have RHEL6 with ipa servers running standard ipa server 3.0.0-42. Pki components are also standard version 9.0.3-38. Servera is the master Serverb is the replica Both have been running for many, many months. Serverb was initially setup as a replica, but not a CA replica. I am now trying to add CA Replication to serverb but it is failing midway through and I cannot figure out why. Annoyingly, I used the same method/command to setup a CA replica on test servers and it completed without issue. Here is what I get(for the sake of brevity, I am excluding the lines for connection check which were all OK) = /usr/sbin/ipa-ca-install /var/lib/ipa/replica-info-serverb.mydomain.com.gpg Directory Manager (existing master) password: Get credentials to log in to remote master ad...@mydomain.com password: Execute check on remote master Connection check OK Configuring directory server for the CA (pkids): Estimated time 30 seconds [1/3]: creating directory server user [2/3]: creating directory server instance [3/3]: restarting directory server Done configuring directory server for the CA (pkids). Configuring certificate server (pki-cad): Estimated time 3 minutes 30 seconds [1/16]: creating certificate server user [2/16]: creating pki-ca instance [3/16]: configuring certificate server instance ipa : CRITICAL failed to configure ca instance Command '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname serverb.mydomain.com -cs_port 9445 -client_certdb_dir /tmp/tmp-t3aHM7 -client_certdb_pwd -preop_pin exoyO2y7bawG5yjZMACM -domain_name IPA -admin_user admin -admin_email root@localhost -admin_password -agent_name ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa -agent_cert_subject CN=ipa-ca-agent,O=MYDOMAIN.COM -ldap_host serverb.mydomain.com -ldap_port 7389 -bind_dn cn=Directory Manager -bind_password -base_dn o=ipaca -db_name ipaca -key_size 2048 -key_type rsa -key_algorithm SHA256withRSA -save_p12 true -backup_pwd -subsystem_name pki-cad -token_name internal -ca_subsystem_cert_subject_name CN=CA Subsystem,O=MYDOMAIN.COM -ca_subsystem_cert_subject_name CN=CA Subsystem,O=MYDOMAIN.COM -ca_ocsp_cert_subject_name CN=OCSP Subsystem,O=MYDOMAIN.COM -ca_server_cert_subject_name CN=serverb.mydomain.com,O=MYDOMAIN.COM -ca_audit_signing_cert_subject_name CN=CA Audit,O=MYDOMAIN.COM -ca_sign_cert_subject_name CN=Certificate Authority,O=MYDOMAIN.COM -external false -clone true -clone_p12_file ca.p12 -clone_p12_password -sd_hostname servera.mydomain.com -sd_admin_port 443 -sd_admin_name admin -sd_admin_password -clone_start_tls true -clone_uri https://servera.mydomain.com:443' returned non-zero exit status 255 Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. Configuration of CA failed = Additional excerpt from the log file /var/log/ipareplica-ca-install.log at the point of failure = # Attempting to connect to: serverb.mydomain.com:9445 Connected. Posting Query = https://serverb.mydomain.com:9445//ca/admin/console/config/wizard?p=7op=nextxml=true__password=path=ca.p12 RESPONSE STATUS: HTTP/1.1 200 OK RESPONSE HEADER: Server: Apache-Coyote/1.1 RESPONSE HEADER: Content-Type: application/xml;charset=UTF-8 RESPONSE HEADER: Date: Tue, 02 Dec 2014 05:44:19 GMT RESPONSE HEADER: Connection: close ?xml version=1.0 encoding=UTF-8? !-- BEGIN COPYRIGHT BLOCK This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; version 2 of the License. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. Copyright (C) 2007 Red Hat, Inc. All rights reserved. END COPYRIGHT BLOCK -- response paneladmin/console/config/restorekeycertpanel.vm/panel res/ updateStatusfailure/updateStatus password/ errorStringThe pkcs12 file is not correct./errorString size19/size titleImport Keys and Certificates/title panels Vector Panel Idwelcome/Id NameWelcome/Name /Panel Panel Idmodule/Id NameKey Store/Name /Panel Panel Idconfighsmlogin/Id NameConfigHSMLogin/Name /Panel Panel Idsecuritydomain/Id NameSecurity Domain/Name /Panel Panel Idsecuritydomain/Id NameDisplay Certificate Chain/Name
Re: [Freeipa-users] how to overcome same serial number in cert issue on different master servers?
-Original Message- From: Rob Crittenden [mailto:rcrit...@redhat.com] Sent: Wednesday, 12 November 2014 6:33 AM To: Fraser Tweedale; Les Stott Cc: freeipa-users@redhat.com Subject: Re: [Freeipa-users] how to overcome same serial number in cert issue on different master servers? Fraser Tweedale wrote: On Tue, Nov 11, 2014 at 04:17:37AM +, Les Stott wrote: -Original Message- From: Fraser Tweedale [mailto:ftwee...@redhat.com] Sent: Tuesday, 11 November 2014 1:59 PM To: Les Stott Cc: freeipa-users@redhat.com Subject: Re: [Freeipa-users] how to overcome same serial number in cert issue on different master servers? On Tue, Nov 11, 2014 at 02:11:55AM +, Les Stott wrote: -Original Message- From: Fraser Tweedale [mailto:ftwee...@redhat.com] Sent: Tuesday, 11 November 2014 12:51 PM To: Les Stott Cc: freeipa-users@redhat.com Subject: Re: [Freeipa-users] how to overcome same serial number in cert issue on different master servers? On Tue, Nov 11, 2014 at 01:40:50AM +, Les Stott wrote: Hi, I have a standard rhel6 deployment for FreeIPA in two environments. One environment is in our Production Data Center, The Other in our DR Data Center. Both environments are setup with the same domain (mydomain.com) for FreeIPA. This is to support dr/failover etc. In each environment, there is a master. In Prod its serverA.mydomain.com, In DR its serverB.mydomain.com. The master in each environment gets a generated certificate by IPA. This certificate shows a Serial Number of 0A My problem is that because the certificates have the same Organization, OU and Serial Number, I can only browse to one of them (using Firefox). If I browse to https://serverA.mydomain.com/ipa/ui/ and accept the certificate it works fine. If I then try to browse to https://serverB.mydomain.com/ipa/ui/ it comes up with the following error: Your certificate contains the same serial number as another certificate issued by the certificate authority. Please get a new certificate containing a unique serial number. (Error code: sec_error_reused_issuer_and_serial) If I remove the stored browser certificate for serverA, then browse to serverB, and accept the certificate, it works, but then the same serial number error pops up for browsing serverA. Note: both environments were built separately and are not linked in anyway (no replication between prod/dr). Is there a way to generate unique serial numbers for the masters? Thanks in advance, Les Hi Les, Ideally, you should prevent this situation by using different common names (CN) for your CAs and server certifications across the different environments. If this is not possible, you can configure the Dogtag CA to use random serial numbers: http://dogtagpki.org/wiki/Random_Certificate_Serial_Numbers#How_to_U se_Random_Certificate_Serial_Numbers This does not guarantee that you will not get serial number collisions, but reduces the likelihood. Thanks for the quick reply. In this case the common name is different between both environments. In prod the master was serverA, in DR the master was serverB. It just happened that way. So having a different CommonName doesn't help. Do the CA certificates bear the same commonName? This is probably what Firefox uses to determine if there are serial number collisions. It appears so. The certificate for the CA on the master serverA shows: Issued To Common Name (CN) serverA.mydomain.com Organization (O) mydomain.com Organizational Unit (OU) Not part of certificate Serial Number 0A Issued By: Common Name (CN) Certificate Authority Organization (O) mydomain.com Organizational Unit (OU) Not part of certificate The certificate for the CA on the master serverB shows: Issued To Common Name (CN) serverB.mydomain.com Organization (O) mydomain.com Organizational Unit (OU) Not part of certificate Serial Number 0A Issued By: Common Name (CN) Certificate Authority Organization (O) mydomain.com Organizational Unit (OU) Not part of certificate Shouldn't the Common Name of the CA be different? Or is it the same in order to make CA replication easier? Both environments were probably set up with the same CN for the CA (perhaps a default name). I don't think this has anything to do with replication. Is there a way to re-issue certificates for the masters so they get unique serial numbers (without making the systems blow up)? You can manually renew a certificate using Certmonger: http://www.freeipa.org/page/Certmonger#Manually_renew_a_certificate You should enable random serial numbers before doing this. The problem here isn't the server certs, it's the CA certs. He has two CA's with the same subjects and serial numbers claiming to be the same thing. Honza added the ipa-cacert
[Freeipa-users] how to overcome same serial number in cert issue on different master servers?
Hi, I have a standard rhel6 deployment for FreeIPA in two environments. One environment is in our Production Data Center, The Other in our DR Data Center. Both environments are setup with the same domain (mydomain.com) for FreeIPA. This is to support dr/failover etc. In each environment, there is a master. In Prod its serverA.mydomain.com, In DR its serverB.mydomain.com. The master in each environment gets a generated certificate by IPA. This certificate shows a Serial Number of 0A My problem is that because the certificates have the same Organization, OU and Serial Number, I can only browse to one of them (using Firefox). If I browse to https://serverA.mydomain.com/ipa/ui/ and accept the certificate it works fine. If I then try to browse to https://serverB.mydomain.com/ipa/ui/ it comes up with the following error: Your certificate contains the same serial number as another certificate issued by the certificate authority. Please get a new certificate containing a unique serial number. (Error code: sec_error_reused_issuer_and_serial) If I remove the stored browser certificate for serverA, then browse to serverB, and accept the certificate, it works, but then the same serial number error pops up for browsing serverA. Note: both environments were built separately and are not linked in anyway (no replication between prod/dr). Is there a way to generate unique serial numbers for the masters? Thanks in advance, Les -- 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] how to overcome same serial number in cert issue on different master servers?
-Original Message- From: Fraser Tweedale [mailto:ftwee...@redhat.com] Sent: Tuesday, 11 November 2014 12:51 PM To: Les Stott Cc: freeipa-users@redhat.com Subject: Re: [Freeipa-users] how to overcome same serial number in cert issue on different master servers? On Tue, Nov 11, 2014 at 01:40:50AM +, Les Stott wrote: Hi, I have a standard rhel6 deployment for FreeIPA in two environments. One environment is in our Production Data Center, The Other in our DR Data Center. Both environments are setup with the same domain (mydomain.com) for FreeIPA. This is to support dr/failover etc. In each environment, there is a master. In Prod its serverA.mydomain.com, In DR its serverB.mydomain.com. The master in each environment gets a generated certificate by IPA. This certificate shows a Serial Number of 0A My problem is that because the certificates have the same Organization, OU and Serial Number, I can only browse to one of them (using Firefox). If I browse to https://serverA.mydomain.com/ipa/ui/ and accept the certificate it works fine. If I then try to browse to https://serverB.mydomain.com/ipa/ui/ it comes up with the following error: Your certificate contains the same serial number as another certificate issued by the certificate authority. Please get a new certificate containing a unique serial number. (Error code: sec_error_reused_issuer_and_serial) If I remove the stored browser certificate for serverA, then browse to serverB, and accept the certificate, it works, but then the same serial number error pops up for browsing serverA. Note: both environments were built separately and are not linked in anyway (no replication between prod/dr). Is there a way to generate unique serial numbers for the masters? Thanks in advance, Les Hi Les, Ideally, you should prevent this situation by using different common names (CN) for your CAs and server certifications across the different environments. If this is not possible, you can configure the Dogtag CA to use random serial numbers: http://dogtagpki.org/wiki/Random_Certificate_Serial_Numbers#How_to_U se_Random_Certificate_Serial_Numbers This does not guarantee that you will not get serial number collisions, but reduces the likelihood. Thanks for the quick reply. In this case the common name is different between both environments. In prod the master was serverA, in DR the master was serverB. It just happened that way. So having a different CommonName doesn't help. I'll look into the dogtag random certificate serial number generation. Does anyone know of a correct way to re-issue the cert's for each master with a random serial number? Thanks, Les -- 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] how to overcome same serial number in cert issue on different master servers?
-Original Message- From: Fraser Tweedale [mailto:ftwee...@redhat.com] Sent: Tuesday, 11 November 2014 1:59 PM To: Les Stott Cc: freeipa-users@redhat.com Subject: Re: [Freeipa-users] how to overcome same serial number in cert issue on different master servers? On Tue, Nov 11, 2014 at 02:11:55AM +, Les Stott wrote: -Original Message- From: Fraser Tweedale [mailto:ftwee...@redhat.com] Sent: Tuesday, 11 November 2014 12:51 PM To: Les Stott Cc: freeipa-users@redhat.com Subject: Re: [Freeipa-users] how to overcome same serial number in cert issue on different master servers? On Tue, Nov 11, 2014 at 01:40:50AM +, Les Stott wrote: Hi, I have a standard rhel6 deployment for FreeIPA in two environments. One environment is in our Production Data Center, The Other in our DR Data Center. Both environments are setup with the same domain (mydomain.com) for FreeIPA. This is to support dr/failover etc. In each environment, there is a master. In Prod its serverA.mydomain.com, In DR its serverB.mydomain.com. The master in each environment gets a generated certificate by IPA. This certificate shows a Serial Number of 0A My problem is that because the certificates have the same Organization, OU and Serial Number, I can only browse to one of them (using Firefox). If I browse to https://serverA.mydomain.com/ipa/ui/ and accept the certificate it works fine. If I then try to browse to https://serverB.mydomain.com/ipa/ui/ it comes up with the following error: Your certificate contains the same serial number as another certificate issued by the certificate authority. Please get a new certificate containing a unique serial number. (Error code: sec_error_reused_issuer_and_serial) If I remove the stored browser certificate for serverA, then browse to serverB, and accept the certificate, it works, but then the same serial number error pops up for browsing serverA. Note: both environments were built separately and are not linked in anyway (no replication between prod/dr). Is there a way to generate unique serial numbers for the masters? Thanks in advance, Les Hi Les, Ideally, you should prevent this situation by using different common names (CN) for your CAs and server certifications across the different environments. If this is not possible, you can configure the Dogtag CA to use random serial numbers: http://dogtagpki.org/wiki/Random_Certificate_Serial_Numbers#How_to_U se_Random_Certificate_Serial_Numbers This does not guarantee that you will not get serial number collisions, but reduces the likelihood. Thanks for the quick reply. In this case the common name is different between both environments. In prod the master was serverA, in DR the master was serverB. It just happened that way. So having a different CommonName doesn't help. Do the CA certificates bear the same commonName? This is probably what Firefox uses to determine if there are serial number collisions. It appears so. The certificate for the CA on the master serverA shows: Issued To Common Name (CN) serverA.mydomain.com Organization (O) mydomain.com Organizational Unit (OU) Not part of certificate Serial Number 0A Issued By: Common Name (CN) Certificate Authority Organization (O) mydomain.com Organizational Unit (OU) Not part of certificate The certificate for the CA on the master serverB shows: Issued To Common Name (CN) serverB.mydomain.com Organization (O) mydomain.com Organizational Unit (OU) Not part of certificate Serial Number 0A Issued By: Common Name (CN) Certificate Authority Organization (O) mydomain.com Organizational Unit (OU) Not part of certificate Shouldn't the Common Name of the CA be different? Or is it the same in order to make CA replication easier? Is there a way to re-issue certificates for the masters so they get unique serial numbers (without making the systems blow up)? Thanks, Les -- 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] can ipa-client-install be updated to call username/password from a file?
FYI... I used OTP for this. Works a treat! Thanks again Dmitri. Regards, Les From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Les Stott Sent: Thursday, 2 October 2014 8:21 AM To: freeipa-users@redhat.com Subject: Re: [Freeipa-users] can ipa-client-install be updated to call username/password from a file? Thanks to Dmitri, Petr, Tamas and Yiorgos for all your suggestions. I will try them out today. Regards, Les From: freeipa-users-boun...@redhat.commailto:freeipa-users-boun...@redhat.com [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Dmitri Pal Sent: Thursday, 2 October 2014 3:09 AM To: freeipa-users@redhat.commailto:freeipa-users@redhat.com Subject: Re: [Freeipa-users] can ipa-client-install be updated to call username/password from a file? On 10/01/2014 05:44 AM, Yiorgos Stamoulis wrote: On 01/10/14 08:19, Les Stott wrote: Hi, I am using freeipa in a rhel6 environment with ipa-3.0.0-37.el6 client. I am working on doing an unattended ipa client installation. I have it working with the following /usr/sbin/ipa-client-install -p admin -w admin_password -U --no-ntp While this works, while it runs, the admin_password value is visable in the output of a ps -ef command on the host when installing the ipa client. # ps -ef |grep ipa root 30284 30283 43 03:31 ?00:00:01 /usr/bin/python -E /usr/sbin/ipa-client-install -p admin -w plain_text_password -U --no-ntp This represents a challenge to security, even though its only minor (as in its only there for a minute or so), but its still there and it is the admin password. Can ipa-client-install be updated to include a parameter to retrieve the admin password from a file? i.e. /usr/bin/python -E /usr/sbin/ipa-client-install -p admin -from-file /tmp/credentials -U --no-ntp That would then protect the admin password. I am not familiar with python coding. Thanks in advance, Les Hi Les, in addition to the answers you have already received, you can create a user with the 'host enrollment' permission only, so even if the credentials are compromised the damage is minimized. I am using this on 4.0.3 but looking at an older installation the same seems available in 3.0 too. Best Regards Yiorgos Or you can use OTPs. The OTPs were actually invented for exactly this use case. You register host and generate OTP at that time. Then you pass it to your enrollment script and it is used once. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- 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] can ipa-client-install be updated to call username/password from a file?
Hi, I am using freeipa in a rhel6 environment with ipa-3.0.0-37.el6 client. I am working on doing an unattended ipa client installation. I have it working with the following /usr/sbin/ipa-client-install -p admin -w admin_password -U --no-ntp While this works, while it runs, the admin_password value is visable in the output of a ps -ef command on the host when installing the ipa client. # ps -ef |grep ipa root 30284 30283 43 03:31 ?00:00:01 /usr/bin/python -E /usr/sbin/ipa-client-install -p admin -w plain_text_password -U --no-ntp This represents a challenge to security, even though its only minor (as in its only there for a minute or so), but its still there and it is the admin password. Can ipa-client-install be updated to include a parameter to retrieve the admin password from a file? i.e. /usr/bin/python -E /usr/sbin/ipa-client-install -p admin -from-file /tmp/credentials -U --no-ntp That would then protect the admin password. I am not familiar with python coding. Thanks in advance, Les -- 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] can ipa-client-install be updated to call username/password from a file?
Thanks to Dmitri, Petr, Tamas and Yiorgos for all your suggestions. I will try them out today. Regards, Les From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Dmitri Pal Sent: Thursday, 2 October 2014 3:09 AM To: freeipa-users@redhat.com Subject: Re: [Freeipa-users] can ipa-client-install be updated to call username/password from a file? On 10/01/2014 05:44 AM, Yiorgos Stamoulis wrote: On 01/10/14 08:19, Les Stott wrote: Hi, I am using freeipa in a rhel6 environment with ipa-3.0.0-37.el6 client. I am working on doing an unattended ipa client installation. I have it working with the following /usr/sbin/ipa-client-install -p admin -w admin_password -U --no-ntp While this works, while it runs, the admin_password value is visable in the output of a ps -ef command on the host when installing the ipa client. # ps -ef |grep ipa root 30284 30283 43 03:31 ?00:00:01 /usr/bin/python -E /usr/sbin/ipa-client-install -p admin -w plain_text_password -U --no-ntp This represents a challenge to security, even though its only minor (as in its only there for a minute or so), but its still there and it is the admin password. Can ipa-client-install be updated to include a parameter to retrieve the admin password from a file? i.e. /usr/bin/python -E /usr/sbin/ipa-client-install -p admin -from-file /tmp/credentials -U --no-ntp That would then protect the admin password. I am not familiar with python coding. Thanks in advance, Les Hi Les, in addition to the answers you have already received, you can create a user with the 'host enrollment' permission only, so even if the credentials are compromised the damage is minimized. I am using this on 4.0.3 but looking at an older installation the same seems available in 3.0 too. Best Regards Yiorgos Or you can use OTPs. The OTPs were actually invented for exactly this use case. You register host and generate OTP at that time. Then you pass it to your enrollment script and it is used once. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- 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] ntp and srv records
We have ntp setup on two servers and configured normally via /etc/ntp* etc. All clients and servers reference the same ntp servers, and all would be on the same time. This doesn't require ntp SRV records. So I personally don't thing ntp srv records are necessary and can't see an issue. But wanted to check to be sure Les -Original Message- From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Petr Spacek Sent: Thursday, 21 August 2014 4:52 PM To: freeipa-users@redhat.com Subject: Re: [Freeipa-users] ntp and srv records On 21.8.2014 06:17, Les Stott wrote: Hi All, Am about to start rolling out clinet installs on rhel6 hosts with dns autodiscovery. Enviroment: rhel6, ipa-3.0.0-37.el6. I already have setup SRV records for Kerberos and ldap etc. Are the following ntp records as SRV records necessary also? Technically not but they are highly recommended (assuming that your IPA servers are running a NTP server). ;ntp server _ntp._udp IN SRV 0 100 123ntp1.mydomain.com. _ntp._udp IN SRV 0 100 123ntp2.mydomain.com. I've seen some guides that don't reference them, others that do. I don't see any adverse effects on the two freeipa servers (master + replica) that are currently running without the ntp srv records. The adverse effect will probably manifest on client side. Things (Kerberos :-) will break if time on client is too far away from time on server. -- Petr^2 Spacek -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
[Freeipa-users] ntp and srv records
Hi All, Am about to start rolling out clinet installs on rhel6 hosts with dns autodiscovery. Enviroment: rhel6, ipa-3.0.0-37.el6. I already have setup SRV records for Kerberos and ldap etc. Are the following ntp records as SRV records necessary also? ;ntp server _ntp._udp IN SRV 0 100 123ntp1.mydomain.com. _ntp._udp IN SRV 0 100 123ntp2.mydomain.com. I've seen some guides that don't reference them, others that do. I don't see any adverse effects on the two freeipa servers (master + replica) that are currently running without the ntp srv records. Thanks in advance, Regards, Les -- 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] HBAC - expected behaviour?
That helps, and I read http://www.freeipa.org/page/Howto/HBAC_and_allow_all Now I understand how it works and the expected behaviour. Thanks. Les -Original Message- From: Martin Kosek [mailto:mko...@redhat.com] Sent: Tuesday, 4 February 2014 6:30 PM To: Les Stott; freeipa-users@redhat.com Subject: Re: [Freeipa-users] HBAC - expected behaviour? On 02/04/2014 05:11 AM, Les Stott wrote: Hi, Running freeipa 3.0.0-37.el6 on rhel 6.4 and just had a query about HBAC rules and how the global allow_all rule applies. I configured a rule for a single host (host1) allowing access via ssh to only a single user (john) via ssh. i.e. # ipa hbacrule-show host1_access Rule name: host1_access Description: Only john can access host1 Enabled: TRUE Users: john Hosts: host1.domain.com Services: sshd When I run the hbac test against the rule, checking another user jane, it works as expected to deny access to jane. But if I include the allow_all rule in the test jane is granted access and can login. I also proved this by actually using ssh to login. If I access the host host1 and remove allow_all from its defined HBAC rules in the web ui, jane can still access host1 via ssh (actually tested login). In the end, for the rule to work as expected (jane to be disallowed access to host1), I've had to modify the allow_all HBAC rule and set it to apply to all hosts except host1. # ipa hbacrule-show allow_all Rule name: allow_all User category: all sourcehostcategory: all Service category: all Description: Allow all users to access any host from any host Enabled: TRUE Hosts: host2.domain.com, host3.domain.com, host4.domain.com Is this how its supposed to be? Or is it a bug in this older version? I would have thought that if the host didn't have the hbac rule allow_all applied to it, just the restrictive host1_access rule, that allow_all wouldn't apply. Thanks, Les Hello Les, I am not aware of any recent bugs in HBAC, this is likely a configuration issue. This is how the default HBAC allow_all looks like: # ipa hbacrule-show allow_all Rule name: allow_all User category: all Host category: all sourcehostcategory: all Service category: all Description: Allow all users to access any host from any host Enabled: TRUE Host category: all means that the rule is effective for all hosts. By selectively specifying the hosts, you disabled this selector. Does it help? Martin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] HBAC - expected behaviour?
Hi, Running freeipa 3.0.0-37.el6 on rhel 6.4 and just had a query about HBAC rules and how the global allow_all rule applies. I configured a rule for a single host (host1) allowing access via ssh to only a single user (john) via ssh. i.e. # ipa hbacrule-show host1_access Rule name: host1_access Description: Only john can access host1 Enabled: TRUE Users: john Hosts: host1.domain.com Services: sshd When I run the hbac test against the rule, checking another user jane, it works as expected to deny access to jane. But if I include the allow_all rule in the test jane is granted access and can login. I also proved this by actually using ssh to login. If I access the host host1 and remove allow_all from its defined HBAC rules in the web ui, jane can still access host1 via ssh (actually tested login). In the end, for the rule to work as expected (jane to be disallowed access to host1), I've had to modify the allow_all HBAC rule and set it to apply to all hosts except host1. # ipa hbacrule-show allow_all Rule name: allow_all User category: all sourcehostcategory: all Service category: all Description: Allow all users to access any host from any host Enabled: TRUE Hosts: host2.domain.com, host3.domain.com, host4.domain.com Is this how its supposed to be? Or is it a bug in this older version? I would have thought that if the host didn't have the hbac rule allow_all applied to it, just the restrictive host1_access rule, that allow_all wouldn't apply. Thanks, Les ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] export users/groups from one ipa server to another
Thanks Martin. Ipa migrate-ds worked a treat. I'll get users to login to an ipa client so that it generates the Kerberos hash (like I had to originally) For reference I did have to specify the correct containers for users and groups... ipa migrate-ds --user-container=cn=users,cn=accounts --group-container=cn=groups,cn=accounts --with-compat ldap://dr-ipa.mydomain.com:389 I still would like a way to dump users out to a file, for backup purposes, such as an ldif file. If anyone has a script to do that I'd appreciate it. Regards, Les -Original Message- From: Martin Kosek [mailto:mko...@redhat.com] Sent: Friday, 17 January 2014 6:46 PM To: Les Stott; freeipa-users@redhat.com Subject: Re: [Freeipa-users] export users/groups from one ipa server to another On 01/17/2014 07:24 AM, Les Stott wrote: Hi All, Looking for the quickest and easiest way to export users from one freeipa server and install on another. I have an existing freeipa server, 3.0.0 standard rhel6 in a DR environment. I am setting up an identical freeipa server in a Production Environment. The two environments will not be configured to talk to each other. They will both have there own replicas. I simply want to export the users and groups I created in freeipa in DR, and import them (preserving details and passwords) into the freeipa server in Production. What is the recommendation? Is there an ipa tool? Or will ldif exports suffice? Thanks in advance, Les I think the best way would be to use the ipa migrate-ds command. It should work both with stand alone Directory Servers and IPA too. You may just need to play with --userignoreobjectclass amd userignoreattribute to not migrate Kerberos related attributes and objectclasses if for example your other DS has a different realm. Martin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] export users/groups from one ipa server to another
Hi All, Looking for the quickest and easiest way to export users from one freeipa server and install on another. I have an existing freeipa server, 3.0.0 standard rhel6 in a DR environment. I am setting up an identical freeipa server in a Production Environment. The two environments will not be configured to talk to each other. They will both have there own replicas. I simply want to export the users and groups I created in freeipa in DR, and import them (preserving details and passwords) into the freeipa server in Production. What is the recommendation? Is there an ipa tool? Or will ldif exports suffice? Thanks in advance, Les ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] HP ILO Authentication via LDAP (or even kerberos)
I had seen that thread... https://www.redhat.com/archives/freeipa-users/2013-November/msg00019.html all it says is... On 11/05/2013 02:51 PM, KodaK wrote: If I use the whole connection string: uid=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com I can authenticate. Which i can do successfully, but its not great to have to tell everyone your username for ilo is uid=blah,cn=users,cn=accounts..etc There is also mentioned in that thread... The HP iLO documentation doesn't list using the uid value as a supported form of specifying the login. You can use the CN value or the full DN. They say that DOMAIN\user and user domain forms are also accepted, but that likely only works against Active Directory. CN doesn't work. full DN does. I don't see any reference to a workaround via compat plugin in that thread. Have you got any more info on the compat workaround? Thanks, Les From: freeipa-users-boun...@redhat.com [freeipa-users-boun...@redhat.com] on behalf of Dmitri Pal [d...@redhat.com] Sent: Wednesday, January 15, 2014 3:30 AM To: freeipa-users@redhat.com Subject: Re: [Freeipa-users] HP ILO Authentication via LDAP (or even kerberos) On 01/13/2014 10:44 PM, Les Stott wrote: Been banging my head against the wall on this one for a few days, trying to get a workable configuration for HP ILO to authenticate via FreeIPA. I have a standard rhel6 environment (64 bit 6.4) with freeipa server (ipa-3.0.0-37.el6). The following works for me…… HP ILO4 Firmware 1.22 Default Directory Schema Directory Server Address: fqdn_of_myfreeipaserver Directory Server LDAP Port: 636 Directory User Context 1: cn=users,cn=accounts,dc=mydomain,dc=com Directory Groups: cn=sys_admins,cn=groups,cn=accounts,dc=mydomain,dc=com ….but only if I login with my full dn…. Username: uid=less,cn=users,cn=accounts,dc=mydomain,dc=com The test settings button in the ILO works only with the full dn. It doesn’t work if I use the uid (less), or the cn (Les Stott). I can then login to ILO with …. Username: uid=less,cn=users,cn=accounts,dc=mydomain,dc=com If I try to login with the cn, Les Stott I see an error in the logs… [13/Jan/2014:22:36:29 -0500] ipalockout_postop - [file ipa_lockout.c, line 473]: Failed to retrieve entry CN=Les Stott,cn=users,cn=accounts,dc=mydomain,dc=com: 32 I’ve read a lot of things about getting this to work. Apparently there are issues with HP ILO requiring the username in cn format but its in uid format in freeipa. You should also be able to login with your cn, but that doesn’t work. I had a crack at trying Kerberos authentication as well, but it doesn’t work and errors with “Additional Pre-authentication required”. Has anyone successfully been able to get HP ILO to work with FreeIPA such that you can login with just the username (i.e. “less”) or the CN (i.e. “Les Stott”)? Are schema changes required? Alternatively has anyone been able to get HP ILO to work with Kerberos auth to FreeIPA? Any help would be greatly appreciated. Regards, Les ___ Freeipa-users mailing list Freeipa-users@redhat.commailto:Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users Have you searched freeipa-users archives? The issue sounds familiar and I vaguely recalled there was a workaround. This is the thread https://www.redhat.com/archives/freeipa-users/2013-November/msg00019.html I think you can use compat plugin on the IPA to expose the tree in the way HP ILO expects. -- 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 https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] HP ILO Authentication via LDAP (or even kerberos)
Still no joy. Although I don't profess to be a schema changing expert.
Compat plugin was already enabled. Ipa version is 3.0.0-37.el6
So I modified /etc/dirsrv/slapd-MYDOMAIN-COM/dse.ldif...
Under
dn: cn=users,cn=Schema Compatibility,cn=plugins,cn=config
I set the following...
schema-compat-entry-attribute: cn=%{cn}
schema-compat-entry-rdn: cn=%{cn}
Left the rest as default.
When I ldapsearch against the compat tree, I see it working the way I want
(i.e. dn starts with cn instead of uid).
ldapsearch -x -b cn=compat,dc=mydomain,dc=com cn=Les Stott
# Les Stott, users, compat, mydomain.com
dn: cn=Les Stott,cn=users,cn=compat,dc=mydomain,dc=com
ILO Search context was set as: cn=users,cn=compat,dc=mydomain,dc=com
So it looks good, but when I test from ILO it fails still.
Try..
Les Stott
...It cant bind
[14/Jan/2014:21:52:31 -0500] conn=47 op=0 BIND dn=CN=Les
Stott,cn=users,cn=compat,dc=mydomain,dc=com method=128 version=2
[14/Jan/2014:21:52:31 -0500] conn=47 op=0 RESULT err=49 tag=97 nentries=0
etime=0
[14/Jan/2014:21:52:31 -0500] conn=47 op=1 UNBIND
[14/Jan/2014:21:52:31 -0500] conn=48 op=0 BIND dn=Les Stott authzid=(null),
invalid bind dn
[14/Jan/2014:21:52:31 -0500] conn=48 op=0 RESULT err=34 tag=97 nentries=0
etime=0
[14/Jan/2014:21:52:31 -0500] conn=48 op=1 BIND dn=CN=Les
Stott,cn=users,cn=compat,dc=mydomain,dc=com method=128 version=2
[14/Jan/2014:21:52:31 -0500] conn=48 op=1 RESULT err=49 tag=97 nentries=0
etime=0
[14/Jan/2014:21:52:31 -0500] conn=48 op=2 UNBIND
[14/Jan/2014:21:52:31 -0500] conn=50 op=0 BIND dn=CN=Les
Stott,cn=users,cn=compat,dc=mydomain,dc=com method=128 version=2
[14/Jan/2014:21:52:31 -0500] conn=50 op=0 RESULT err=49 tag=97 nentries=0
etime=0
[14/Jan/2014:21:52:31 -0500] conn=50 op=1 UNBIND
Is it just not supporting to bind against the compat tree in 3.0.0.37? or am I
doing something wrong?
Regards,
Les
From: Dmitri Pal [mailto:d...@redhat.com]
Sent: Wednesday, 15 January 2014 8:36 AM
To: Les Stott
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] HP ILO Authentication via LDAP (or even kerberos)
On 01/14/2014 04:01 PM, Les Stott wrote:
I had seen that thread...
https://www.redhat.com/archives/freeipa-users/2013-November/msg00019.html
all it says is...
On 11/05/2013 02:51 PM, KodaK wrote:
If I use the whole connection string:
uid=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com
I can authenticate.
Which i can do successfully, but its not great to have to tell everyone your
username for ilo is uid=blah,cn=users,cn=accounts..etc
There is also mentioned in that thread...
The HP iLO documentation doesn't list using the uid value as a supported form
of specifying the login. You can use the CN value or the full DN. They say
that DOMAIN\user and user domain forms are also accepted, but that likely
only works against Active Directory.
CN doesn't work. full DN does.
I don't see any reference to a workaround via compat plugin in that thread.
Have you got any more info on the compat workaround?
You can create a compat tree using compat plugin of IPA. It is used for NIS,
support of Solaris clients and for AD trusts in latest IPA.
As a simple test you can enable the plugin:
ipa-compat-manage enable
That will expose the tree on the cn=compat hive but using 2307 schema.
You can then change the configuration of the plugin to use uid value instead of
CN in this view, i.e expose CN as uid.
Then you can point your HP ILO to that tree.
AFAIU in the past it was not possible because we did not allow bind against
compat tree but now we allow it so it should work with the latest IPA 3.3.x
bits.
Details on how to change compat configuration can be found in the plugin
configuration here:
https://git.fedorahosted.org/cgit/slapi-nis.git/tree/doc
I am not sure that would 100% work but IMO worth a shot.
Thanks,
Les
From: freeipa-users-boun...@redhat.commailto:freeipa-users-boun...@redhat.com
[freeipa-users-boun...@redhat.commailto:freeipa-users-boun...@redhat.com] on
behalf of Dmitri Pal [d...@redhat.commailto:d...@redhat.com]
Sent: Wednesday, January 15, 2014 3:30 AM
To: freeipa-users@redhat.commailto:freeipa-users@redhat.com
Subject: Re: [Freeipa-users] HP ILO Authentication via LDAP (or even kerberos)
On 01/13/2014 10:44 PM, Les Stott wrote:
Been banging my head against the wall on this one for a few days, trying to get
a workable configuration for HP ILO to authenticate via FreeIPA.
I have a standard rhel6 environment (64 bit 6.4) with freeipa server
(ipa-3.0.0-37.el6).
The following works for me..
HP ILO4 Firmware 1.22
Default Directory Schema
Directory Server Address: fqdn_of_myfreeipaserver
Directory Server LDAP Port: 636
Directory User Context 1: cn=users,cn=accounts,dc=mydomain,dc=com
Directory Groups: cn=sys_admins,cn=groups,cn=accounts,dc=mydomain,dc=com
but only if I login with my full dn
Username: uid=less,cn=users,cn=accounts,dc=mydomain,dc=com
The test
Re: [Freeipa-users] HP ILO Authentication via LDAP (or even kerberos)
I can confirm that the password was typed in correctly. Maybe its not matching
the account because it's the compat tree?
Also, each authentication tries multiple bind combinations, 3 or 4 different
combinations show up in the logs for 1 authentication attempt.
From the ILO help..iLO attempts to contact the directory service by
distinguished name, and then applies the search contexts in order until
successful.
I'm beginning to think this is too hardwould hate to have to fall back to
AD instead for central auth for ILO.
Regards,
Les
From: Rich Megginson [mailto:rmegg...@redhat.com]
Sent: Wednesday, 15 January 2014 2:13 PM
To: Les Stott; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] HP ILO Authentication via LDAP (or even kerberos)
On 01/14/2014 07:57 PM, Les Stott wrote:
Still no joy. Although I don't profess to be a schema changing expert.
Compat plugin was already enabled. Ipa version is 3.0.0-37.el6
So I modified /etc/dirsrv/slapd-MYDOMAIN-COM/dse.ldif...
Under
dn: cn=users,cn=Schema Compatibility,cn=plugins,cn=config
I set the following...
schema-compat-entry-attribute: cn=%{cn}
schema-compat-entry-rdn: cn=%{cn}
Left the rest as default.
When I ldapsearch against the compat tree, I see it working the way I want
(i.e. dn starts with cn instead of uid).
ldapsearch -x -b cn=compat,dc=mydomain,dc=com cn=Les Stott
# Les Stott, users, compat, mydomain.com
dn: cn=Les Stott,cn=users,cn=compat,dc=mydomain,dc=com
ILO Search context was set as: cn=users,cn=compat,dc=mydomain,dc=com
So it looks good, but when I test from ILO it fails still.
Try..
Les Stott
...It cant bind
[14/Jan/2014:21:52:31 -0500] conn=47 op=0 BIND dn=CN=Les
Stott,cn=users,cn=compat,dc=mydomain,dc=com method=128 version=2
[14/Jan/2014:21:52:31 -0500] conn=47 op=0 RESULT err=49 tag=97 nentries=0
etime=0
[14/Jan/2014:21:52:31 -0500] conn=47 op=1 UNBIND
[14/Jan/2014:21:52:31 -0500] conn=48 op=0 BIND dn=Les Stott authzid=(null),
invalid bind dn
[14/Jan/2014:21:52:31 -0500] conn=48 op=0 RESULT err=34 tag=97 nentries=0
etime=0
[14/Jan/2014:21:52:31 -0500] conn=48 op=1 BIND dn=CN=Les
Stott,cn=users,cn=compat,dc=mydomain,dc=com method=128 version=2
[14/Jan/2014:21:52:31 -0500] conn=48 op=1 RESULT err=49 tag=97 nentries=0
etime=0
[14/Jan/2014:21:52:31 -0500] conn=48 op=2 UNBIND
[14/Jan/2014:21:52:31 -0500] conn=50 op=0 BIND dn=CN=Les
Stott,cn=users,cn=compat,dc=mydomain,dc=com method=128 version=2
[14/Jan/2014:21:52:31 -0500] conn=50 op=0 RESULT err=49 tag=97 nentries=0
etime=0
[14/Jan/2014:21:52:31 -0500] conn=50 op=1 UNBIND
Is it just not supporting to bind against the compat tree in 3.0.0.37? or am I
doing something wrong?
Not sure, but err=49 means wrong password, and err=34 means invalid DN (Les
Stott is not a DN).
Regards,
Les
From: Dmitri Pal [mailto:d...@redhat.com]
Sent: Wednesday, 15 January 2014 8:36 AM
To: Les Stott
Cc: freeipa-users@redhat.commailto:freeipa-users@redhat.com
Subject: Re: [Freeipa-users] HP ILO Authentication via LDAP (or even kerberos)
On 01/14/2014 04:01 PM, Les Stott wrote:
I had seen that thread...
https://www.redhat.com/archives/freeipa-users/2013-November/msg00019.html
all it says is...
On 11/05/2013 02:51 PM, KodaK wrote:
If I use the whole connection string:
uid=jebalicki,cn=users,cn=accounts,dc=unix,dc=magellanhealth,dc=com
I can authenticate.
Which i can do successfully, but its not great to have to tell everyone your
username for ilo is uid=blah,cn=users,cn=accounts..etc
There is also mentioned in that thread...
The HP iLO documentation doesn't list using the uid value as a supported form
of specifying the login. You can use the CN value or the full DN. They say
that DOMAIN\user and user domain forms are also accepted, but that likely
only works against Active Directory.
CN doesn't work. full DN does.
I don't see any reference to a workaround via compat plugin in that thread.
Have you got any more info on the compat workaround?
You can create a compat tree using compat plugin of IPA. It is used for NIS,
support of Solaris clients and for AD trusts in latest IPA.
As a simple test you can enable the plugin:
ipa-compat-manage enable
That will expose the tree on the cn=compat hive but using 2307 schema.
You can then change the configuration of the plugin to use uid value instead of
CN in this view, i.e expose CN as uid.
Then you can point your HP ILO to that tree.
AFAIU in the past it was not possible because we did not allow bind against
compat tree but now we allow it so it should work with the latest IPA 3.3.x
bits.
Details on how to change compat configuration can be found in the plugin
configuration here:
https://git.fedorahosted.org/cgit/slapi-nis.git/tree/doc
I am not sure that would 100% work but IMO worth a shot.
Thanks,
Les
From: freeipa-users-boun...@redhat.commailto:freeipa-users-boun...@redhat.com
[freeipa-users-boun...@redhat.commailto:freeipa-users-boun...@redhat.com
[Freeipa-users] HP ILO Authentication via LDAP (or even kerberos)
Been banging my head against the wall on this one for a few days, trying to get a workable configuration for HP ILO to authenticate via FreeIPA. I have a standard rhel6 environment (64 bit 6.4) with freeipa server (ipa-3.0.0-37.el6). The following works for me.. HP ILO4 Firmware 1.22 Default Directory Schema Directory Server Address: fqdn_of_myfreeipaserver Directory Server LDAP Port: 636 Directory User Context 1: cn=users,cn=accounts,dc=mydomain,dc=com Directory Groups: cn=sys_admins,cn=groups,cn=accounts,dc=mydomain,dc=com but only if I login with my full dn Username: uid=less,cn=users,cn=accounts,dc=mydomain,dc=com The test settings button in the ILO works only with the full dn. It doesn't work if I use the uid (less), or the cn (Les Stott). I can then login to ILO with Username: uid=less,cn=users,cn=accounts,dc=mydomain,dc=com If I try to login with the cn, Les Stott I see an error in the logs... [13/Jan/2014:22:36:29 -0500] ipalockout_postop - [file ipa_lockout.c, line 473]: Failed to retrieve entry CN=Les Stott,cn=users,cn=accounts,dc=mydomain,dc=com: 32 I've read a lot of things about getting this to work. Apparently there are issues with HP ILO requiring the username in cn format but its in uid format in freeipa. You should also be able to login with your cn, but that doesn't work. I had a crack at trying Kerberos authentication as well, but it doesn't work and errors with Additional Pre-authentication required. Has anyone successfully been able to get HP ILO to work with FreeIPA such that you can login with just the username (i.e. less) or the CN (i.e. Les Stott)? Are schema changes required? Alternatively has anyone been able to get HP ILO to work with Kerberos auth to FreeIPA? Any help would be greatly appreciated. Regards, Les ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Question: re replica install
Thanks Rob. -Original Message- From: Rob Crittenden [mailto:rcrit...@redhat.com] Sent: Thursday, 19 December 2013 12:08 PM To: Les Stott; freeipa-users@redhat.com Subject: Re: [Freeipa-users] Question: re replica install Les Stott wrote: Hi All, (RHEL 6.4, FreeIPA 3.0.0-37) Say I want to install a replica server in a restricted network, but I don't want to enable http management on the replica. I am pretty sure the following is true, but ask the question just to be sure Can a replica work (for authentication and replication) without http? I cant see a switch on ipa-replica-install to not setup http, so I imagine if the above was possible I could... 1.Install the replica 2.Let it configure http 3.Turn off http You'd probably run into wierd corner-case problems, and how DNS is configured might work around some of them, until it doesn't. I think the most likely pain points would be the ipa tool and certmonger. certmonger will use the IPA configured in /etc/ipa/default.conf, so as long as you ensure that points to one of the other masters you'll probably be ok. But that is only on the clients. On the master itself renewal of the IPA server certs will likely fail. The ipa tool, which by default also uses default.conf, will fail over to other masters, but you might notice a delay. What might be a better idea would be to firewall it rather than shutting down the service. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Question: re replica install
Hi All, (RHEL 6.4, FreeIPA 3.0.0-37) Say I want to install a replica server in a restricted network, but I don't want to enable http management on the replica. I am pretty sure the following is true, but ask the question just to be sure Can a replica work (for authentication and replication) without http? I cant see a switch on ipa-replica-install to not setup http, so I imagine if the above was possible I could... 1. Install the replica 2. Let it configure http 3. Turn off http Thanks, Les ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Trouble with replica install
Hi, Running ipa-server-3.0.0-37.el6.x86_64 on rhel6. Already setup master server, now trying to install replica (which I've done before and its worked fine). The replica install gets all the way to the end but errors out. For the most part, it looks like it is complete, but I want to be sure there are no lingering issues. The error I see in the log is...(domain and ip's changed) 2013-12-16T09:26:50Z DEBUG stderr=Hostname: replica.mydomain.com Realm: MYDOMAIN.COM DNS Domain: mydomain.com IPA Server: replica.mydomain.com BaseDN: dc=mydomain,dc=com Domain mydomain.com is already configured in existing SSSD config, creating a new one. The old /etc/sssd/sssd.conf is backed up and will be restored during uninstall. Configured /etc/sssd/sssd.conf trying https://replica.mydomain.com/ipa/xml Forwarding 'env' to server u'https://replica.mydomain.com/ipa/xml' Traceback (most recent call last): File /usr/sbin/ipa-client-install, line 2377, in module sys.exit(main()) File /usr/sbin/ipa-client-install, line 2363, in main rval = install(options, env, fstore, statestore) File /usr/sbin/ipa-client-install, line 2167, in install remote_env = api.Command['env'](server=True)['result'] File /usr/lib/python2.6/site-packages/ipalib/frontend.py, line 435, in __call__ ret = self.run(*args, **options) File /usr/lib/python2.6/site-packages/ipalib/frontend.py, line 1073, in run return self.forward(*args, **options) File /usr/lib/python2.6/site-packages/ipalib/frontend.py, line 769, in forward return self.Backend.xmlclient.forward(self.name, *args, **kw) File /usr/lib/python2.6/site-packages/ipalib/rpc.py, line 776, in forward raise NetworkError(uri=server, error=e.errmsg) ipalib.errors.NetworkError: cannot connect to u'https://replica.mydomain.com/ipa/xml': Internal Server Error 2013-12-16T09:26:50Z INFO File /usr/lib/python2.6/site-packages/ipaserver/install/installutils.py, line 614, in run_script return_value = main_function() File /usr/sbin/ipa-replica-install, line 527, in main raise RuntimeError(Failed to configure the client) 2013-12-16T09:26:50Z INFO The ipa-replica-install command failed, exception: RuntimeError: Failed to configure the client --- Apache logs the following error at the same time... [Mon Dec 16 04:26:50 2013] [crit] [client 192.168.0.13] configuration error: couldn't check access. No groups file?: /ipa/xml, referer: https://replica.mydomain.com/ipa/xml I can login to the gui and it seems ok, but I'm rolling this into production so I've got to get it right. I'm hoping this is just some bug because its an older freeipa on redhat (minimal install) etc. selinux is in permissive mode, but it's the same as on the master server, so it should be the issue. Is this error critical? How can I fix it? Thanks in advance, Les ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Trouble with replica install
Sorry, when I said selinux is in permissive mode, but it's the same as on the master server, so it should be the issue. It should have read as selinux is in permissive mode, but it's the same as on the master server, so it should NOT be the issue. Les From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Les Stott Sent: Monday, 16 December 2013 8:47 PM To: freeipa-users@redhat.com Subject: [Freeipa-users] Trouble with replica install Hi, Running ipa-server-3.0.0-37.el6.x86_64 on rhel6. Already setup master server, now trying to install replica (which I've done before and its worked fine). The replica install gets all the way to the end but errors out. For the most part, it looks like it is complete, but I want to be sure there are no lingering issues. The error I see in the log is...(domain and ip's changed) 2013-12-16T09:26:50Z DEBUG stderr=Hostname: replica.mydomain.com Realm: MYDOMAIN.COM DNS Domain: mydomain.com IPA Server: replica.mydomain.com BaseDN: dc=mydomain,dc=com Domain mydomain.com is already configured in existing SSSD config, creating a new one. The old /etc/sssd/sssd.conf is backed up and will be restored during uninstall. Configured /etc/sssd/sssd.conf trying https://replica.mydomain.com/ipa/xml Forwarding 'env' to server u'https://replica.mydomain.com/ipa/xml' Traceback (most recent call last): File /usr/sbin/ipa-client-install, line 2377, in module sys.exit(main()) File /usr/sbin/ipa-client-install, line 2363, in main rval = install(options, env, fstore, statestore) File /usr/sbin/ipa-client-install, line 2167, in install remote_env = api.Command['env'](server=True)['result'] File /usr/lib/python2.6/site-packages/ipalib/frontend.py, line 435, in __call__ ret = self.run(*args, **options) File /usr/lib/python2.6/site-packages/ipalib/frontend.py, line 1073, in run return self.forward(*args, **options) File /usr/lib/python2.6/site-packages/ipalib/frontend.py, line 769, in forward return self.Backend.xmlclient.forward(self.name, *args, **kw) File /usr/lib/python2.6/site-packages/ipalib/rpc.py, line 776, in forward raise NetworkError(uri=server, error=e.errmsg) ipalib.errors.NetworkError: cannot connect to u'https://replica.mydomain.com/ipa/xml': Internal Server Error 2013-12-16T09:26:50Z INFO File /usr/lib/python2.6/site-packages/ipaserver/install/installutils.py, line 614, in run_script return_value = main_function() File /usr/sbin/ipa-replica-install, line 527, in main raise RuntimeError(Failed to configure the client) 2013-12-16T09:26:50Z INFO The ipa-replica-install command failed, exception: RuntimeError: Failed to configure the client --- Apache logs the following error at the same time... [Mon Dec 16 04:26:50 2013] [crit] [client 192.168.0.13] configuration error: couldn't check access. No groups file?: /ipa/xml, referer: https://replica.mydomain.com/ipa/xml I can login to the gui and it seems ok, but I'm rolling this into production so I've got to get it right. I'm hoping this is just some bug because its an older freeipa on redhat (minimal install) etc. selinux is in permissive mode, but it's the same as on the master server, so it should be the issue. Is this error critical? How can I fix it? Thanks in advance, Les ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Trouble with replica install
Petr, The below was the error from apache error logs Apache logs the following error at the same time... [Mon Dec 16 04:26:50 2013] [crit] [client 192.168.0.13] configuration error: couldn't check access. No groups file?: /ipa/xml, referer: https://replica.mydomain.com/ipa/xml Other lines in the /var/log/httpd/error log at the same time... [Mon Dec 16 04:26:49 2013] [error] ipa: INFO: *** PROCESS START *** [Mon Dec 16 04:26:49 2013] [error] ipa: INFO: *** PROCESS START *** [Mon Dec 16 04:26:50 2013] [crit] [client 192.168.0.13] configuration error: couldn't check access. No groups file?: /ipa/xml, referer: https://replica.mydomain.com/ipa/xml [Mon Dec 16 04:29:01 2013] [notice] caught SIGTERM, shutting down [Mon Dec 16 04:29:02 2013] [notice] SELinux policy enabled; httpd running as context unconfined_u:system_r:httpd_t:s0 Regards, Les From: Petr Spacek [pspa...@redhat.com] Sent: Monday, December 16, 2013 10:38 PM To: Les Stott; freeipa-users@redhat.com Subject: Re: [Freeipa-users] Trouble with replica install On 16.12.2013 10:55, Les Stott wrote: Sorry, when I said selinux is in permissive mode, but it's the same as on the master server, so it should be the issue. It should have read as selinux is in permissive mode, but it's the same as on the master server, so it should NOT be the issue. Les From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Les Stott Sent: Monday, 16 December 2013 8:47 PM To: freeipa-users@redhat.com Subject: [Freeipa-users] Trouble with replica install Hi, Running ipa-server-3.0.0-37.el6.x86_64 on rhel6. Already setup master server, now trying to install replica (which I've done before and its worked fine). The replica install gets all the way to the end but errors out. For the most part, it looks like it is complete, but I want to be sure there are no lingering issues. The error I see in the log is...(domain and ip's changed) 2013-12-16T09:26:50Z DEBUG stderr=Hostname: replica.mydomain.com Realm: MYDOMAIN.COM DNS Domain: mydomain.com IPA Server: replica.mydomain.com BaseDN: dc=mydomain,dc=com Domain mydomain.com is already configured in existing SSSD config, creating a new one. The old /etc/sssd/sssd.conf is backed up and will be restored during uninstall. Configured /etc/sssd/sssd.conf trying https://replica.mydomain.com/ipa/xml Forwarding 'env' to server u'https://replica.mydomain.com/ipa/xml' Traceback (most recent call last): File /usr/sbin/ipa-client-install, line 2377, in module sys.exit(main()) File /usr/sbin/ipa-client-install, line 2363, in main rval = install(options, env, fstore, statestore) File /usr/sbin/ipa-client-install, line 2167, in install remote_env = api.Command['env'](server=True)['result'] File /usr/lib/python2.6/site-packages/ipalib/frontend.py, line 435, in __call__ ret = self.run(*args, **options) File /usr/lib/python2.6/site-packages/ipalib/frontend.py, line 1073, in run return self.forward(*args, **options) File /usr/lib/python2.6/site-packages/ipalib/frontend.py, line 769, in forward return self.Backend.xmlclient.forward(self.name, *args, **kw) File /usr/lib/python2.6/site-packages/ipalib/rpc.py, line 776, in forward raise NetworkError(uri=server, error=e.errmsg) ipalib.errors.NetworkError: cannot connect to u'https://replica.mydomain.com/ipa/xml': Internal Server Error Please look into /var/log/httpd/errors.log on server replica.mydomain.com and check error messages there. Petr^2 Spacek 2013-12-16T09:26:50Z INFO File /usr/lib/python2.6/site-packages/ipaserver/install/installutils.py, line 614, in run_script return_value = main_function() File /usr/sbin/ipa-replica-install, line 527, in main raise RuntimeError(Failed to configure the client) 2013-12-16T09:26:50Z INFO The ipa-replica-install command failed, exception: RuntimeError: Failed to configure the client --- Apache logs the following error at the same time... [Mon Dec 16 04:26:50 2013] [crit] [client 192.168.0.13] configuration error: couldn't check access. No groups file?: /ipa/xml, referer: https://replica.mydomain.com/ipa/xml I can login to the gui and it seems ok, but I'm rolling this into production so I've got to get it right. I'm hoping this is just some bug because its an older freeipa on redhat (minimal install) etc. selinux is in permissive mode, but it's the same as on the master server, so it should be the issue. Is this error critical? How can I fix it? Thanks in advance, Les ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Trouble with replica install - SOLVED
Figured it out. Missing apache modules (not loaded). One of the following LoadModule auth_basic_module modules/mod_auth_basic.so LoadModule auth_digest_module modules/mod_auth_digest.so LoadModule authn_file_module modules/mod_authn_file.so LoadModule authn_alias_module modules/mod_authn_alias.so LoadModule authn_anon_module modules/mod_authn_anon.so LoadModule authn_dbm_module modules/mod_authn_dbm.so LoadModule authn_default_module modules/mod_authn_default.so LoadModule authz_host_module modules/mod_authz_host.so LoadModule authz_user_module modules/mod_authz_user.so LoadModule authz_owner_module modules/mod_authz_owner.so LoadModule authz_groupfile_module modules/mod_authz_groupfile.so LoadModule authz_dbm_module modules/mod_authz_dbm.so LoadModule authz_default_module modules/mod_authz_default.so LoadModule authnz_ldap_module modules/mod_authnz_ldap.so I'm not sure which one, i just matched what was on the master and reinstalled the replica - no errors. Been a long day so i don't feel like going through one by one, uninstalling/reinstalling etc. I imagine its probably mod_authz_groupfile.so, but others are probably needed too. Regards, Les From: Les Stott Sent: Monday, December 16, 2013 11:44 PM To: freeipa-users@redhat.com Subject: RE: [Freeipa-users] Trouble with replica install Petr, The below was the error from apache error logs Apache logs the following error at the same time... [Mon Dec 16 04:26:50 2013] [crit] [client 192.168.0.13] configuration error: couldn't check access. No groups file?: /ipa/xml, referer: https://replica.mydomain.com/ipa/xml Other lines in the /var/log/httpd/error log at the same time... [Mon Dec 16 04:26:49 2013] [error] ipa: INFO: *** PROCESS START *** [Mon Dec 16 04:26:49 2013] [error] ipa: INFO: *** PROCESS START *** [Mon Dec 16 04:26:50 2013] [crit] [client 192.168.0.13] configuration error: couldn't check access. No groups file?: /ipa/xml, referer: https://replica.mydomain.com/ipa/xml [Mon Dec 16 04:29:01 2013] [notice] caught SIGTERM, shutting down [Mon Dec 16 04:29:02 2013] [notice] SELinux policy enabled; httpd running as context unconfined_u:system_r:httpd_t:s0 Regards, Les From: Petr Spacek [pspa...@redhat.com] Sent: Monday, December 16, 2013 10:38 PM To: Les Stott; freeipa-users@redhat.com Subject: Re: [Freeipa-users] Trouble with replica install On 16.12.2013 10:55, Les Stott wrote: Sorry, when I said selinux is in permissive mode, but it's the same as on the master server, so it should be the issue. It should have read as selinux is in permissive mode, but it's the same as on the master server, so it should NOT be the issue. Les From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Les Stott Sent: Monday, 16 December 2013 8:47 PM To: freeipa-users@redhat.com Subject: [Freeipa-users] Trouble with replica install Hi, Running ipa-server-3.0.0-37.el6.x86_64 on rhel6. Already setup master server, now trying to install replica (which I've done before and its worked fine). The replica install gets all the way to the end but errors out. For the most part, it looks like it is complete, but I want to be sure there are no lingering issues. The error I see in the log is...(domain and ip's changed) 2013-12-16T09:26:50Z DEBUG stderr=Hostname: replica.mydomain.com Realm: MYDOMAIN.COM DNS Domain: mydomain.com IPA Server: replica.mydomain.com BaseDN: dc=mydomain,dc=com Domain mydomain.com is already configured in existing SSSD config, creating a new one. The old /etc/sssd/sssd.conf is backed up and will be restored during uninstall. Configured /etc/sssd/sssd.conf trying https://replica.mydomain.com/ipa/xml Forwarding 'env' to server u'https://replica.mydomain.com/ipa/xml' Traceback (most recent call last): File /usr/sbin/ipa-client-install, line 2377, in module sys.exit(main()) File /usr/sbin/ipa-client-install, line 2363, in main rval = install(options, env, fstore, statestore) File /usr/sbin/ipa-client-install, line 2167, in install remote_env = api.Command['env'](server=True)['result'] File /usr/lib/python2.6/site-packages/ipalib/frontend.py, line 435, in __call__ ret = self.run(*args, **options) File /usr/lib/python2.6/site-packages/ipalib/frontend.py, line 1073, in run return self.forward(*args, **options) File /usr/lib/python2.6/site-packages/ipalib/frontend.py, line 769, in forward return self.Backend.xmlclient.forward(self.name, *args, **kw) File /usr/lib/python2.6/site-packages/ipalib/rpc.py, line 776, in forward raise NetworkError(uri=server, error=e.errmsg) ipalib.errors.NetworkError: cannot connect to u'https://replica.mydomain.com/ipa/xml': Internal Server Error Please look into /var/log/httpd/errors.log on server replica.mydomain.com and check error
Re: [Freeipa-users] Trouble with replica install - SOLVED
Alexander, I think it was a case of a manually locked down (post install) system that had been previously built. The master was on a vm that was a newer build, but not done in the same way as the older server, so it had a more default out of the box configuration. At least now I now to check this before installing the replica on existing machines. Regards, Les -Original Message- From: Alexander Bokovoy [mailto:aboko...@redhat.com] Sent: Tuesday, 17 December 2013 12:52 AM To: Les Stott Cc: freeipa-users@redhat.com Subject: Re: [Freeipa-users] Trouble with replica install - SOLVED On Mon, 16 Dec 2013, Les Stott wrote: Figured it out. Missing apache modules (not loaded). One of the following LoadModule auth_basic_module modules/mod_auth_basic.so LoadModule auth_digest_module modules/mod_auth_digest.so LoadModule authn_file_module modules/mod_authn_file.so LoadModule authn_alias_module modules/mod_authn_alias.so LoadModule authn_anon_module modules/mod_authn_anon.so LoadModule authn_dbm_module modules/mod_authn_dbm.so LoadModule authn_default_module modules/mod_authn_default.so LoadModule authz_host_module modules/mod_authz_host.so LoadModule authz_user_module modules/mod_authz_user.so LoadModule authz_owner_module modules/mod_authz_owner.so LoadModule authz_groupfile_module modules/mod_authz_groupfile.so LoadModule authz_dbm_module modules/mod_authz_dbm.so LoadModule authz_default_module modules/mod_authz_default.so LoadModule authnz_ldap_module modules/mod_authnz_ldap.so I'm not sure which one, i just matched what was on the master and reinstalled the replica - no errors. Been a long day so i don't feel like going through one by one, uninstalling/reinstalling etc. I imagine its probably mod_authz_groupfile.so, but others are probably needed too. I wonder if this server was refurbished from some other task where original configuration was already changed. FreeIPA install scripts assumes non-modified configuration files. -- / Alexander Bokovoy ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] gssapi sasl error - only picking up short hostname when running ipa-client-install (and failing) - SOLVED
Alexander, Petr, Martin,
Sorry for the delay, was the weekend.
With your guidance I have figured out the issue. Using tcpdump I saw some
references to a NIS domain that had been setup on the box. This was different
to the domain name I setup for freeipa. Arp was also only showing short
hostnames.
I modified /etc/nsswitch.conf so that nis was not in the picture
Hosts files dns
Then the ipa-client-install ran without problems. (It reset nsswitch.conf back
to include nis afterwards)
Installing keyutils fixed the other error too.
Thanks for all your help.
Regards,
Les
-Original Message-
From: Alexander Bokovoy [mailto:aboko...@redhat.com]
Sent: Saturday, 30 November 2013 12:32 AM
To: Les Stott
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] gssapi sasl error - only picking up short hostname
when running ipa-client-install (and failing)
On Fri, 29 Nov 2013, Les Stott wrote:
Hi,
Recently installed freeipa on two servers in multi-master mode. We want to
have a central authentication system for many hosts. Environment is RHEL 6.4
for servers, RHEL 6.1 for the first client host, standard rpm packages used -
ipa-server-3.0.0-26.el6_4.4.x86_64 and ipa-client-3.0.0-37.el6.x86_64.
I am now trying to add the first linux host to freeipa via ipa-client-install.
When I run ipa-client-install on a host in debug mode it fails with
errors below (I have changed hostnames and ip's,
freeipa-1.mydomain.com 192.168.1.22 and freeipa-2.mydomain.com
192.168.1.23, host client - host1 192.168.1.15)
trying to retrieve CA cert via LDAP from ldap://freeipa-1.mydomain.com
get_ca_cert_from_ldap() error: Local error SASL(-1): generic failure:
GSSAPI Error: Unspecified GSS failure. Minor code may provide more
information (Server ldap/freeip...@mydomain.com not found in Kerberos
database)
{'info': 'SASL(-1): generic failure: GSSAPI Error: Unspecified GSS
failure. Minor code may provide more information (Server
ldap/freeip...@mydomain.com not found in Kerberos database)', 'desc':
'Local error'}
The Kerberos logs on the server (free-ipa-1) show Nov 29 01:46:14
freeipa-1.mydomain.com krb5kdc[1616](info): TGS_REQ (4 etypes {18 17 16
23}) 192.168.1.15: UNKNOWN_SERVER: authtime 0, admin@ MYDOMAIN.COM for
HTTP/ freeip...@mydomain.com, Server not found in Kerberos database
The logs indicate that the service name is being used with the short hostname
(HTTP/ freeip...@mydomain.commailto:freeip...@mydomain.com). The FreeIPA
server has records for HTTP/
freeipa-1.mydomain@mydomain.commailto:freeipa-1.mydomain@mydomain.com.
I can see these in the web interface. I believe this is where it is stumbling.
I've been banging my head against the wall on this one for a couple of days.
Everything I've found says make sure you have working dns, make sure you can
reverse lookup ip's, make sure hostnames are fqdn, make sure /etc/hosts on
server has ip's for servers listed with fqdn first and shortname second. I've
done all that.
I am using external dns (not integrated with freeipa), and have populated all
records required as per sample config files provided during install. My time
servers are other servers too, but that shouldn't matter, everything is in
sync.
; for Kerberos Auto Discovery
; ldap servers
_ldap._tcp IN SRV 0 100 389freeipa-1.mydomain.com.
_ldap._tcp IN SRV 0 100 389freeipa-2.mydomain.com.
;kerberos realm
_kerberos IN TXT MYDOMAIN.COM
; kerberos servers
_kerberos._tcp IN SRV 0 100 88 freeipa-1.mydomain.com.
_kerberos._tcp IN SRV 0 100 88 freeipa-2.mydomain.com.
_kerberos._udp IN SRV 0 100 88 freeipa-1.mydomain.com.
_kerberos._ucp IN SRV 0 100 88 freeipa-2.mydomain.com.
_kerberos-master._tcp IN SRV 0 100 88 freeipa-1.mydomain.com.
_kerberos-master._tcp IN SRV 0 100 88 freeipa-2.mydomain.com.
_kerberos-master._udp IN SRV 0 100 88 freeipa-1.mydomain.com.
_kerberos-master._udp IN SRV 0 100 88 freeipa-2.mydomain.com.
_kpasswd._tcp IN SRV 0 100 464freeipa-1.mydomain.com.
_kpasswd._tcp IN SRV 0 100 464freeipa-2.mydomain.com.
_kpasswd._udp IN SRV 0 100 464freeipa-1.mydomain.com.
_kpasswd._udp IN SRV 0 100 464freeipa-2.mydomain.com.
;ntp server
_ntp._udp IN SRV 0 100 123ntp1.mydomain.com.
_ntp._udp IN SRV 0 100 123ntp2.mydomain.com.
Reverse dns entries are also available and both freeipa servers and the host I
am trying to configure ipa-client on can do lookups and receive fqdn's. They
can all do reverse lookups that resolve correctly.
I have read that when using SASL/GSSAPI (Kerberos) authentication, its
possible that the service provider sets the principal name (SPN) to
ldap/servername in the TGS_REQ based on a dns query of the PTR record. I do
have PTR's configured, and they have FQDN's
[Freeipa-users] gssapi sasl error - only picking up short hostname when running ipa-client-install (and failing)
Hi,
Recently installed freeipa on two servers in multi-master mode. We want to have
a central authentication system for many hosts. Environment is RHEL 6.4 for
servers, RHEL 6.1 for the first client host, standard rpm packages used -
ipa-server-3.0.0-26.el6_4.4.x86_64 and ipa-client-3.0.0-37.el6.x86_64.
I am now trying to add the first linux host to freeipa via ipa-client-install.
When I run ipa-client-install on a host in debug mode it fails with errors
below (I have changed hostnames and ip's, freeipa-1.mydomain.com 192.168.1.22
and freeipa-2.mydomain.com 192.168.1.23, host client - host1 192.168.1.15)
trying to retrieve CA cert via LDAP from ldap://freeipa-1.mydomain.com
get_ca_cert_from_ldap() error: Local error SASL(-1): generic failure: GSSAPI
Error: Unspecified GSS failure. Minor code may provide more information
(Server ldap/freeip...@mydomain.com not found in Kerberos database)
{'info': 'SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.
Minor code may provide more information (Server ldap/freeip...@mydomain.com not
found in Kerberos database)', 'desc': 'Local error'}
The Kerberos logs on the server (free-ipa-1) show
Nov 29 01:46:14 freeipa-1.mydomain.com krb5kdc[1616](info): TGS_REQ (4 etypes
{18 17 16 23}) 192.168.1.15: UNKNOWN_SERVER: authtime 0, admin@ MYDOMAIN.COM
for HTTP/ freeip...@mydomain.com, Server not found in Kerberos database
The logs indicate that the service name is being used with the short hostname
(HTTP/ freeip...@mydomain.commailto:freeip...@mydomain.com). The FreeIPA
server has records for HTTP/
freeipa-1.mydomain@mydomain.commailto:freeipa-1.mydomain@mydomain.com.
I can see these in the web interface. I believe this is where it is stumbling.
I've been banging my head against the wall on this one for a couple of days.
Everything I've found says make sure you have working dns, make sure you can
reverse lookup ip's, make sure hostnames are fqdn, make sure /etc/hosts on
server has ip's for servers listed with fqdn first and shortname second. I've
done all that.
I am using external dns (not integrated with freeipa), and have populated all
records required as per sample config files provided during install. My time
servers are other servers too, but that shouldn't matter, everything is in sync.
; for Kerberos Auto Discovery
; ldap servers
_ldap._tcp IN SRV 0 100 389freeipa-1.mydomain.com.
_ldap._tcp IN SRV 0 100 389freeipa-2.mydomain.com.
;kerberos realm
_kerberos IN TXT MYDOMAIN.COM
; kerberos servers
_kerberos._tcp IN SRV 0 100 88 freeipa-1.mydomain.com.
_kerberos._tcp IN SRV 0 100 88 freeipa-2.mydomain.com.
_kerberos._udp IN SRV 0 100 88 freeipa-1.mydomain.com.
_kerberos._ucp IN SRV 0 100 88 freeipa-2.mydomain.com.
_kerberos-master._tcp IN SRV 0 100 88 freeipa-1.mydomain.com.
_kerberos-master._tcp IN SRV 0 100 88 freeipa-2.mydomain.com.
_kerberos-master._udp IN SRV 0 100 88 freeipa-1.mydomain.com.
_kerberos-master._udp IN SRV 0 100 88 freeipa-2.mydomain.com.
_kpasswd._tcp IN SRV 0 100 464freeipa-1.mydomain.com.
_kpasswd._tcp IN SRV 0 100 464freeipa-2.mydomain.com.
_kpasswd._udp IN SRV 0 100 464freeipa-1.mydomain.com.
_kpasswd._udp IN SRV 0 100 464freeipa-2.mydomain.com.
;ntp server
_ntp._udp IN SRV 0 100 123ntp1.mydomain.com.
_ntp._udp IN SRV 0 100 123ntp2.mydomain.com.
Reverse dns entries are also available and both freeipa servers and the host I
am trying to configure ipa-client on can do lookups and receive fqdn's. They
can all do reverse lookups that resolve correctly.
I have read that when using SASL/GSSAPI (Kerberos) authentication, its possible
that the service provider sets the principal name (SPN) to ldap/servername in
the TGS_REQ based on a dns query of the PTR record. I do have PTR's configured,
and they have FQDN's. Is it true that this happens with GSSAPI? If so how can I
get around that?
Reverse Zone File for 192.168.1
22 PTR freeipa-1.mydomain.com.
23 PTR freeipa-2.mydomain.com.
Nslookup results for each IP:
22.1.168.192.in-addr.arpa name = freeipa-1.mydomain.com.
23.1.168.192.in-addr.arpa name = freeipa-2.mydomain.com.
I can authenticate using kinit before running the script and it still doesn't
work.
The short version of running the install shows:
Discovery was successful!
Hostname: host1.mydomain.com
Realm: MYDOMAIN.COM
DNS Domain: mydomain.com
IPA Server: freeipa-1.mydomain.com
BaseDN: dc=mydomain,dc=com
It authenticates correctly with the admin user for enrolling the host, but
joining the realm fails.
I've tried everything I can think of.
Please help.
Thanks,
Les
___
Freeipa-users mailing list
Freeipa-users@redhat.com
Re: [Freeipa-users] gssapi sasl error - only picking up short hostname when running ipa-client-install (and failing)
Martin,
there is no entries in /etc/hosts for the freeipa servers on the client.
the clients hosts own entry is there with fqdn first.
Because you mentioned it, i added the hostname of both freeipa server to the
hosts file on the client. It actually ran and setup the client. However it did
get the following errors at the end after it did kerberos config
===
Configured /etc/krb5.conf for IPA realm MYDOMAIN.COM
Traceback (most recent call last):
File /usr/sbin/ipa-client-install, line 2377, in module
sys.exit(main())
File /usr/sbin/ipa-client-install, line 2363, in main
rval = install(options, env, fstore, statestore)
File /usr/sbin/ipa-client-install, line 2135, in install
delete_persistent_client_session_data(host_principal)
File /usr/lib/python2.6/site-packages/ipalib/rpc.py, line 124, in
delete_persistent_client_session_data
kernel_keyring.del_key(keyname)
File /usr/lib/python2.6/site-packages/ipapython/kernel_keyring.py, line 99,
in del_key
real_key = get_real_key(key)
File /usr/lib/python2.6/site-packages/ipapython/kernel_keyring.py, line 45,
in get_real_key
(stdout, stderr, rc) = run(['keyctl', 'search', KEYRING, KEYTYPE, key],
raiseonerr=False)
File /usr/lib/python2.6/site-packages/ipapython/ipautil.py, line 295, in run
close_fds=True, env=env, cwd=cwd)
File /usr/lib64/python2.6/subprocess.py, line 639, in __init__
errread, errwrite)
File /usr/lib64/python2.6/subprocess.py, line 1220, in _execute_child
raise child_exception
OSError: [Errno 2] No such file or directory
===
Is that normal?
Do i need to add entries to the hosts file on every client?
Regards,
Les
From: Martin Kosek [mko...@redhat.com]
Sent: Friday, November 29, 2013 8:49 PM
To: Les Stott; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] gssapi sasl error - only picking up short hostname
when running ipa-client-install (and failing)
On 11/29/2013 09:16 AM, Les Stott wrote:
Hi,
Recently installed freeipa on two servers in multi-master mode. We want to
have a central authentication system for many hosts. Environment is RHEL 6.4
for servers, RHEL 6.1 for the first client host, standard rpm packages used -
ipa-server-3.0.0-26.el6_4.4.x86_64 and ipa-client-3.0.0-37.el6.x86_64.
I am now trying to add the first linux host to freeipa via ipa-client-install.
When I run ipa-client-install on a host in debug mode it fails with errors
below (I have changed hostnames and ip's, freeipa-1.mydomain.com
192.168.1.22 and freeipa-2.mydomain.com 192.168.1.23, host client - host1
192.168.1.15)
trying to retrieve CA cert via LDAP from ldap://freeipa-1.mydomain.com
get_ca_cert_from_ldap() error: Local error SASL(-1): generic failure: GSSAPI
Error: Unspecified GSS failure. Minor code may provide more information
(Server ldap/freeip...@mydomain.com not found in Kerberos database)
{'info': 'SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.
Minor code may provide more information (Server ldap/freeip...@mydomain.com
not found in Kerberos database)', 'desc': 'Local error'}
The Kerberos logs on the server (free-ipa-1) show
Nov 29 01:46:14 freeipa-1.mydomain.com krb5kdc[1616](info): TGS_REQ (4 etypes
{18 17 16 23}) 192.168.1.15: UNKNOWN_SERVER: authtime 0, admin@ MYDOMAIN.COM
for HTTP/ freeip...@mydomain.com, Server not found in Kerberos database
The logs indicate that the service name is being used with the short hostname
(HTTP/ freeip...@mydomain.commailto:freeip...@mydomain.com). The FreeIPA
server has records for HTTP/
freeipa-1.mydomain@mydomain.commailto:freeipa-1.mydomain@mydomain.com.
I can see these in the web interface. I believe this is where it is
stumbling.
I've been banging my head against the wall on this one for a couple of days.
Everything I've found says make sure you have working dns, make sure you can
reverse lookup ip's, make sure hostnames are fqdn, make sure /etc/hosts on
server has ip's for servers listed with fqdn first and shortname second. I've
done all that.
What about /etc/hosts on the clients? Do they also have FQDN first in case they
have server IP in there?
Martin
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
