From Less at imagine-sw.com Sun Dec 1 23:34:07 2013 From: Less at imagine-sw.com (Les Stott) Date: Sun, 1 Dec 2013 23:34:07 +0000 Subject: [Freeipa-users] gssapi sasl error - only picking up short hostname when running ipa-client-install (and failing) - SOLVED Message-ID: <4ED173A868981548967B4FCA270722260211A6@AACMBXP04.exchserver.com> 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:abokovoy at redhat.com] Sent: Saturday, 30 November 2013 12:32 AM To: Les Stott Cc: freeipa-users at 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/freeipa-1 at 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/freeipa-1 at 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/ freeipa-1 at MYDOMAIN.COM, Server not found in Kerberos database > >The logs indicate that the service name is being used with the short hostname (HTTP/ freeipa-1 at MYDOMAIN.COM). The FreeIPA server has records for HTTP/ freeipa-1.mydomain.com at 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 389 freeipa-1.mydomain.com. >_ldap._tcp IN SRV 0 100 389 freeipa-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 464 freeipa-1.mydomain.com. >_kpasswd._tcp IN SRV 0 100 464 freeipa-2.mydomain.com. >_kpasswd._udp IN SRV 0 100 464 freeipa-1.mydomain.com. >_kpasswd._udp IN SRV 0 100 464 freeipa-2.mydomain.com. > >;ntp server >_ntp._udp IN SRV 0 100 123 ntp1.mydomain.com. >_ntp._udp IN SRV 0 100 123 ntp2.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. Can you show your resolv.conf? Can it be that it actually misses domain mydomain.com stanza? -- / Alexander Bokovoy From dpal at redhat.com Mon Dec 2 04:18:30 2013 From: dpal at redhat.com (Dmitri Pal) Date: Sun, 01 Dec 2013 23:18:30 -0500 Subject: [Freeipa-users] [SOLVED] Re: gssapi sasl error - only picking up short hostname when running ipa-client-install (and failing) - SOLVED In-Reply-To: <4ED173A868981548967B4FCA270722260211A6@AACMBXP04.exchserver.com> References: <4ED173A868981548967B4FCA270722260211A6@AACMBXP04.exchserver.com> Message-ID: <529C0A16.6080306@redhat.com> On 12/01/2013 06:34 PM, Les Stott wrote: > 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:abokovoy at redhat.com] > Sent: Saturday, 30 November 2013 12:32 AM > To: Les Stott > Cc: freeipa-users at 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/freeipa-1 at 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/freeipa-1 at 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/ freeipa-1 at MYDOMAIN.COM, Server not found in Kerberos database >> >> The logs indicate that the service name is being used with the short hostname (HTTP/ freeipa-1 at MYDOMAIN.COM). The FreeIPA server has records for HTTP/ freeipa-1.mydomain.com at 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 389 freeipa-1.mydomain.com. >> _ldap._tcp IN SRV 0 100 389 freeipa-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 464 freeipa-1.mydomain.com. >> _kpasswd._tcp IN SRV 0 100 464 freeipa-2.mydomain.com. >> _kpasswd._udp IN SRV 0 100 464 freeipa-1.mydomain.com. >> _kpasswd._udp IN SRV 0 100 464 freeipa-2.mydomain.com. >> >> ;ntp server >> _ntp._udp IN SRV 0 100 123 ntp1.mydomain.com. >> _ntp._udp IN SRV 0 100 123 ntp2.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. > Can you show your resolv.conf? > Can it be that it actually misses > domain mydomain.com > stanza? > > > > -- > / Alexander Bokovoy > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users Marking the thread as solved. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From mkosek at redhat.com Mon Dec 2 08:05:46 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 02 Dec 2013 09:05:46 +0100 Subject: [Freeipa-users] Ubuntu 12.04 and FreeIPA In-Reply-To: References: Message-ID: <529C3F5A.1060501@redhat.com> On 11/27/2013 06:43 PM, Andrew Precht wrote: > Hi users, > I'm trying to get Ubuntu 12.04 to use FreeIPA as its directory service. I'm > getting this error: > > host_mod: 2.58 client incompatible with 2.46 server at u' > https://ipa1.example.com/ipa/xml' > > Failed to upload host SSH public keys. > > > This seems to be the same as: > https://fedorahosted.org/freeipa/ticket/3931 which > is marked as: (closed defect: fixed) > > Is there a work around? > > Thanks, > > Andrew Hello Andrew, This is indeed a bug fixed in the FreeIPA 3.3.2. I see 2 options for your case: 1) Manually upload host's SSH public keys after the client was enrolled, using the following command $ ipa host-mod $CLIENT_FQDN --sshpubkey='$SSH_PUBKEY' 2) Manually apply the 2 patches in the ticket 3931 to your ipa-client-install script as you are using FreeIPA client below version 3.3.2. Then the SSH pubkey should upload automatically: https://fedorahosted.org/freeipa/changeset/96ab7002ac2acfc129dd73f1fc9b023a6fbf3723/ https://fedorahosted.org/freeipa/changeset/960c67aca8be1981e5748c3f1f6ab031f115846e/ HTH, Martin From rcritten at redhat.com Mon Dec 2 15:40:48 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 02 Dec 2013 10:40:48 -0500 Subject: [Freeipa-users] Dogtag not working? In-Reply-To: <5298FAA2.8060000@gmail.com> References: <5297C8D2.4080407@gmail.com> <5298FAA2.8060000@gmail.com> Message-ID: <529CAA00.4060000@redhat.com> Erinn Looney-Triggs wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 11/28/2013 03:50 PM, Erinn Looney-Triggs wrote: >> In the process of prepping a replication host for changing over the >> CA I had to use certmonger to generate another certificate on my >> secondary IPA server. Unfortunately it seems to fail every single >> time. Here is what I am running and here is what I am getting: >> >> ipa-getcert request -k private/ipa2.abaqis.com.key -f >> certs/ipa2.abaqis.com.crt -g 2048 >> >> The request appears to work, however when checking the list I >> receive the following: >> >> ipa-getcert list -r Number of certificates and requests being >> tracked: 9. Request ID '20131128202128': status: CA_UNREACHABLE >> ca-error: Server failed request, will retry: 4301 (RPC failed at >> server. Certificate operation cannot be completed: FAILURE >> (Authentication Error)). stuck: yes key pair storage: >> type=FILE,location='/etc/pki/tls/private/ipa2.abaqis.com.key' >> certificate: >> type=FILE,location='/etc/pki/tls/certs/ipa2.abaqis.com.crt' CA: >> IPA issuer: subject: expires: unknown pre-save command: post-save >> command: track: yes auto-renew: yes >> >> Fine, I check the http logs and get about the same: [Thu Nov 28 >> 22:03:06 2013] [error] ipa: ERROR: >> ipaserver.plugins.dogtag.ra.request_certificate(): FAILURE >> (Authentication Error) >> >> Now as I understand it ipa-getcert is going to theserver listed in >> /etc/ipa/default.conf, which in this case is ipa2.abaqis.com (the >> request is coming from the same host). The host principle in >> /etc/krb5.keytab is used for authentication. >> >> I have tested against the primary ipa server and everything works >> as it should. However, any requests going against ipa2 for >> certificates are failing. >> >> At this point I am stuck, so any suggestions are welcome. >> >> -Erinn >> >> > > Replying to myself here, and narrowing this down a bit further this > seems to be a straight auth problem against my secondary ipa server. > All command work against the primary, all certificate commands against > the secondary fail. > > It appears to be confined to dogtag (other commands like ipa user-show > work), but how exactly dogtag handles auth I am not clear on. It > appears as though mod_auth_kerb handles most things and that is > definitely working. However any access against dogtag components is > failing, so dogtag must/should/may be handling auth internally in a > way that is failing. > > Anyway, suggestions are still welcome, Run this on the replica and see if it is being tracked by certmonger # getcert list -d /etc/httpd/alias -n ipaCert If not, see if the a cert with the nickname ipaCert is in /etc/httpd/alias: # certutil -L -d /etc/httpd/alias -n ipaCert If so, see if you have the key: # certutil -K -d /etc/httpd/alias -n ipaCert -f /etc/httpd/alias/pwdfile.txt This is the RA agent certificate that IPA uses to authenticate to dogtag. If it doesn't exist, or is expired, or is the wrong one, then authentication will fail. The cert is shared amongst all the IPA masters, so if it is working on one master then fixing the replica should be straightforward assuming it already has the key. rob From erinn.looneytriggs at gmail.com Mon Dec 2 15:48:21 2013 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Mon, 02 Dec 2013 07:48:21 -0800 Subject: [Freeipa-users] Dogtag not working? In-Reply-To: <529CAA00.4060000@redhat.com> References: <5297C8D2.4080407@gmail.com> <5298FAA2.8060000@gmail.com> <529CAA00.4060000@redhat.com> Message-ID: <529CABC5.5000804@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/02/2013 07:40 AM, Rob Crittenden wrote: > Erinn Looney-Triggs wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> On 11/28/2013 03:50 PM, Erinn Looney-Triggs wrote: >>> In the process of prepping a replication host for changing over >>> the CA I had to use certmonger to generate another certificate >>> on my secondary IPA server. Unfortunately it seems to fail >>> every single time. Here is what I am running and here is what I >>> am getting: >>> >>> ipa-getcert request -k private/ipa2.abaqis.com.key -f >>> certs/ipa2.abaqis.com.crt -g 2048 >>> >>> The request appears to work, however when checking the list I >>> receive the following: >>> >>> ipa-getcert list -r Number of certificates and requests being >>> tracked: 9. Request ID '20131128202128': status: >>> CA_UNREACHABLE ca-error: Server failed request, will retry: >>> 4301 (RPC failed at server. Certificate operation cannot be >>> completed: FAILURE (Authentication Error)). stuck: yes key pair >>> storage: >>> type=FILE,location='/etc/pki/tls/private/ipa2.abaqis.com.key' >>> certificate: >>> type=FILE,location='/etc/pki/tls/certs/ipa2.abaqis.com.crt' >>> CA: IPA issuer: subject: expires: unknown pre-save command: >>> post-save command: track: yes auto-renew: yes >>> >>> Fine, I check the http logs and get about the same: [Thu Nov >>> 28 22:03:06 2013] [error] ipa: ERROR: >>> ipaserver.plugins.dogtag.ra.request_certificate(): FAILURE >>> (Authentication Error) >>> >>> Now as I understand it ipa-getcert is going to theserver listed >>> in /etc/ipa/default.conf, which in this case is ipa2.abaqis.com >>> (the request is coming from the same host). The host principle >>> in /etc/krb5.keytab is used for authentication. >>> >>> I have tested against the primary ipa server and everything >>> works as it should. However, any requests going against ipa2 >>> for certificates are failing. >>> >>> At this point I am stuck, so any suggestions are welcome. >>> >>> -Erinn >>> >>> >> >> Replying to myself here, and narrowing this down a bit further >> this seems to be a straight auth problem against my secondary ipa >> server. All command work against the primary, all certificate >> commands against the secondary fail. >> >> It appears to be confined to dogtag (other commands like ipa >> user-show work), but how exactly dogtag handles auth I am not >> clear on. It appears as though mod_auth_kerb handles most things >> and that is definitely working. However any access against dogtag >> components is failing, so dogtag must/should/may be handling auth >> internally in a way that is failing. >> >> Anyway, suggestions are still welcome, > > Run this on the replica and see if it is being tracked by > certmonger > > # getcert list -d /etc/httpd/alias -n ipaCert > > If not, see if the a cert with the nickname ipaCert is in > /etc/httpd/alias: > > # certutil -L -d /etc/httpd/alias -n ipaCert > > If so, see if you have the key: > > # certutil -K -d /etc/httpd/alias -n ipaCert -f > /etc/httpd/alias/pwdfile.txt > > This is the RA agent certificate that IPA uses to authenticate to > dogtag. If it doesn't exist, or is expired, or is the wrong one, > then authentication will fail. > > The cert is shared amongst all the IPA masters, so if it is working > on one master then fixing the replica should be straightforward > assuming it already has the key. > > rob getcert list -d /etc/httpd/alias -n ipaCert Number of certificates and requests being tracked: 9. Request ID '20130221171049': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' certificate: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB' CA: dogtag-ipa-retrieve-agent-submit issuer: CN=Certificate Authority,O=ABAQIS.COM subject: CN=IPA RA,O=ABAQIS.COM expires: 2013-12-10 03:23:26 UTC eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: /usr/lib64/ipa/certmonger/restart_httpd track: yes auto-renew: yes All the components appear to be there, the certificate is valid until the 10th as you can see about. The other two commands worked fine as well and everything appears to me to be valid. However, I am still getting the auth errors, and I note in the log, what I assume to be the first ipa server attempting to connect and getting auth errors as well. - -Erinn -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) iQEcBAEBAgAGBQJSnKu/AAoJENetaK3v/E7P208IAJOLZ3gAouWOgTMyWeFyePGV bwjnkfzkCzoyZuzqyqfTg9AwfxhVClcG6jxadd4CIdA1sUYdvYQGyPubjyMX3W1T Yfvx4y7z4DTcCwyxl5VTmqcTJe7yEhD48Cn+5fNb0fJZZpc6ngG1u4HvZKpZ/KmX i3Ck0e2sDuIGPAf35c3Gg2fPmCDu9TXzu2MbujpAhBMsqo+YrizNkp2P6tdkHINw gIBXl/DcSV4vbC7DSaSXMCNzJk77EdYihbtAccpJZXznmsbWWVhsxBTQNfmum5Fe G8xjUhSJljDLd0iXewUVpa6i7MZrzRjNzsF1ikKFFecHw/QTHRE1iHJUR1LVv4g= =Hisv -----END PGP SIGNATURE----- From rcritten at redhat.com Mon Dec 2 16:03:50 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 02 Dec 2013 11:03:50 -0500 Subject: [Freeipa-users] Dogtag not working? In-Reply-To: <529CABC5.5000804@gmail.com> References: <5297C8D2.4080407@gmail.com> <5298FAA2.8060000@gmail.com> <529CAA00.4060000@redhat.com> <529CABC5.5000804@gmail.com> Message-ID: <529CAF66.2050106@redhat.com> Erinn Looney-Triggs wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 12/02/2013 07:40 AM, Rob Crittenden wrote: >> Erinn Looney-Triggs wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>> >>> On 11/28/2013 03:50 PM, Erinn Looney-Triggs wrote: >>>> In the process of prepping a replication host for changing over >>>> the CA I had to use certmonger to generate another certificate >>>> on my secondary IPA server. Unfortunately it seems to fail >>>> every single time. Here is what I am running and here is what I >>>> am getting: >>>> >>>> ipa-getcert request -k private/ipa2.abaqis.com.key -f >>>> certs/ipa2.abaqis.com.crt -g 2048 >>>> >>>> The request appears to work, however when checking the list I >>>> receive the following: >>>> >>>> ipa-getcert list -r Number of certificates and requests being >>>> tracked: 9. Request ID '20131128202128': status: >>>> CA_UNREACHABLE ca-error: Server failed request, will retry: >>>> 4301 (RPC failed at server. Certificate operation cannot be >>>> completed: FAILURE (Authentication Error)). stuck: yes key pair >>>> storage: >>>> type=FILE,location='/etc/pki/tls/private/ipa2.abaqis.com.key' >>>> certificate: >>>> type=FILE,location='/etc/pki/tls/certs/ipa2.abaqis.com.crt' >>>> CA: IPA issuer: subject: expires: unknown pre-save command: >>>> post-save command: track: yes auto-renew: yes >>>> >>>> Fine, I check the http logs and get about the same: [Thu Nov >>>> 28 22:03:06 2013] [error] ipa: ERROR: >>>> ipaserver.plugins.dogtag.ra.request_certificate(): FAILURE >>>> (Authentication Error) >>>> >>>> Now as I understand it ipa-getcert is going to theserver listed >>>> in /etc/ipa/default.conf, which in this case is ipa2.abaqis.com >>>> (the request is coming from the same host). The host principle >>>> in /etc/krb5.keytab is used for authentication. >>>> >>>> I have tested against the primary ipa server and everything >>>> works as it should. However, any requests going against ipa2 >>>> for certificates are failing. >>>> >>>> At this point I am stuck, so any suggestions are welcome. >>>> >>>> -Erinn >>>> >>>> >>> >>> Replying to myself here, and narrowing this down a bit further >>> this seems to be a straight auth problem against my secondary ipa >>> server. All command work against the primary, all certificate >>> commands against the secondary fail. >>> >>> It appears to be confined to dogtag (other commands like ipa >>> user-show work), but how exactly dogtag handles auth I am not >>> clear on. It appears as though mod_auth_kerb handles most things >>> and that is definitely working. However any access against dogtag >>> components is failing, so dogtag must/should/may be handling auth >>> internally in a way that is failing. >>> >>> Anyway, suggestions are still welcome, >> >> Run this on the replica and see if it is being tracked by >> certmonger >> >> # getcert list -d /etc/httpd/alias -n ipaCert >> >> If not, see if the a cert with the nickname ipaCert is in >> /etc/httpd/alias: >> >> # certutil -L -d /etc/httpd/alias -n ipaCert >> >> If so, see if you have the key: >> >> # certutil -K -d /etc/httpd/alias -n ipaCert -f >> /etc/httpd/alias/pwdfile.txt >> >> This is the RA agent certificate that IPA uses to authenticate to >> dogtag. If it doesn't exist, or is expired, or is the wrong one, >> then authentication will fail. >> >> The cert is shared amongst all the IPA masters, so if it is working >> on one master then fixing the replica should be straightforward >> assuming it already has the key. >> >> rob > > getcert list -d /etc/httpd/alias -n ipaCert > Number of certificates and requests being tracked: 9. > Request ID '20130221171049': > status: MONITORING > stuck: no > key pair storage: > type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > certificate: > type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS > Certificate DB' > CA: dogtag-ipa-retrieve-agent-submit > issuer: CN=Certificate Authority,O=ABAQIS.COM > subject: CN=IPA RA,O=ABAQIS.COM > expires: 2013-12-10 03:23:26 UTC > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: > post-save command: /usr/lib64/ipa/certmonger/restart_httpd > track: yes > auto-renew: yes > > All the components appear to be there, the certificate is valid until > the 10th as you can see about. The other two commands worked fine as > well and everything appears to me to be valid. > > However, I am still getting the auth errors, and I note in the log, > what I assume to be the first ipa server attempting to connect and > getting auth errors as well. Ok, I'm a little unclear on something. Can any of your IPA masters communicate with dogtag? I thought that one master could and one couldn't. A simple way to find out is: # ipa cert-show 1 This shows some random cert. If you get cert output then things are working. If not the logs will probably confirm the auth failure. Next step is to run this on each master: # certutil -L -d /etc/httpd/alias -n ipaCert | grep Serial The serial numbers should be the same. I wonder if you'll find the to be different. The serial number should match this value: # ldapsearch -x -h localhost -p 7389 -b uid=ipara,ou=People,o=ipaca description The second integer in description is the serial number. rob From erinn.looneytriggs at gmail.com Mon Dec 2 17:29:34 2013 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Mon, 02 Dec 2013 09:29:34 -0800 Subject: [Freeipa-users] Dogtag not working? In-Reply-To: <529CAF66.2050106@redhat.com> References: <5297C8D2.4080407@gmail.com> <5298FAA2.8060000@gmail.com> <529CAA00.4060000@redhat.com> <529CABC5.5000804@gmail.com> <529CAF66.2050106@redhat.com> Message-ID: <529CC37E.4070202@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/02/2013 08:03 AM, Rob Crittenden wrote: > Erinn Looney-Triggs wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> On 12/02/2013 07:40 AM, Rob Crittenden wrote: >>> Erinn Looney-Triggs wrote: >>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>> >>>> On 11/28/2013 03:50 PM, Erinn Looney-Triggs wrote: >>>>> In the process of prepping a replication host for changing >>>>> over the CA I had to use certmonger to generate another >>>>> certificate on my secondary IPA server. Unfortunately it >>>>> seems to fail every single time. Here is what I am running >>>>> and here is what I am getting: >>>>> >>>>> ipa-getcert request -k private/ipa2.abaqis.com.key -f >>>>> certs/ipa2.abaqis.com.crt -g 2048 >>>>> >>>>> The request appears to work, however when checking the list >>>>> I receive the following: >>>>> >>>>> ipa-getcert list -r Number of certificates and requests >>>>> being tracked: 9. Request ID '20131128202128': status: >>>>> CA_UNREACHABLE ca-error: Server failed request, will >>>>> retry: 4301 (RPC failed at server. Certificate operation >>>>> cannot be completed: FAILURE (Authentication Error)). >>>>> stuck: yes key pair storage: >>>>> type=FILE,location='/etc/pki/tls/private/ipa2.abaqis.com.key' >>>>> >>>>> certificate: >>>>> type=FILE,location='/etc/pki/tls/certs/ipa2.abaqis.com.crt' >>>>> >>>>> CA: IPA issuer: subject: expires: unknown pre-save command: >>>>> post-save command: track: yes auto-renew: yes >>>>> >>>>> Fine, I check the http logs and get about the same: [Thu >>>>> Nov 28 22:03:06 2013] [error] ipa: ERROR: >>>>> ipaserver.plugins.dogtag.ra.request_certificate(): FAILURE >>>>> (Authentication Error) >>>>> >>>>> Now as I understand it ipa-getcert is going to theserver >>>>> listed in /etc/ipa/default.conf, which in this case is >>>>> ipa2.abaqis.com (the request is coming from the same host). >>>>> The host principle in /etc/krb5.keytab is used for >>>>> authentication. >>>>> >>>>> I have tested against the primary ipa server and >>>>> everything works as it should. However, any requests going >>>>> against ipa2 for certificates are failing. >>>>> >>>>> At this point I am stuck, so any suggestions are welcome. >>>>> >>>>> -Erinn >>>>> >>>>> >>>> >>>> Replying to myself here, and narrowing this down a bit >>>> further this seems to be a straight auth problem against my >>>> secondary ipa server. All command work against the primary, >>>> all certificate commands against the secondary fail. >>>> >>>> It appears to be confined to dogtag (other commands like ipa >>>> user-show work), but how exactly dogtag handles auth I am >>>> not clear on. It appears as though mod_auth_kerb handles most >>>> things and that is definitely working. However any access >>>> against dogtag components is failing, so dogtag >>>> must/should/may be handling auth internally in a way that is >>>> failing. >>>> >>>> Anyway, suggestions are still welcome, >>> >>> Run this on the replica and see if it is being tracked by >>> certmonger >>> >>> # getcert list -d /etc/httpd/alias -n ipaCert >>> >>> If not, see if the a cert with the nickname ipaCert is in >>> /etc/httpd/alias: >>> >>> # certutil -L -d /etc/httpd/alias -n ipaCert >>> >>> If so, see if you have the key: >>> >>> # certutil -K -d /etc/httpd/alias -n ipaCert -f >>> /etc/httpd/alias/pwdfile.txt >>> >>> This is the RA agent certificate that IPA uses to authenticate >>> to dogtag. If it doesn't exist, or is expired, or is the wrong >>> one, then authentication will fail. >>> >>> The cert is shared amongst all the IPA masters, so if it is >>> working on one master then fixing the replica should be >>> straightforward assuming it already has the key. >>> >>> rob >> >> getcert list -d /etc/httpd/alias -n ipaCert Number of >> certificates and requests being tracked: 9. Request ID >> '20130221171049': status: MONITORING stuck: no key pair storage: >> type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS >> >> Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >> certificate: >> type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS >> >> Certificate DB' >> CA: dogtag-ipa-retrieve-agent-submit issuer: CN=Certificate >> Authority,O=ABAQIS.COM subject: CN=IPA RA,O=ABAQIS.COM expires: >> 2013-12-10 03:23:26 UTC eku: id-kp-serverAuth,id-kp-clientAuth >> pre-save command: post-save command: >> /usr/lib64/ipa/certmonger/restart_httpd track: yes auto-renew: >> yes >> >> All the components appear to be there, the certificate is valid >> until the 10th as you can see about. The other two commands >> worked fine as well and everything appears to me to be valid. >> >> However, I am still getting the auth errors, and I note in the >> log, what I assume to be the first ipa server attempting to >> connect and getting auth errors as well. > > Ok, I'm a little unclear on something. Can any of your IPA masters > communicate with dogtag? I thought that one master could and one > couldn't. > > A simple way to find out is: > > # ipa cert-show 1 > > This shows some random cert. If you get cert output then things > are working. If not the logs will probably confirm the auth > failure. > > Next step is to run this on each master: > > # certutil -L -d /etc/httpd/alias -n ipaCert | grep Serial > > The serial numbers should be the same. I wonder if you'll find the > to be different. > > The serial number should match this value: > > # ldapsearch -x -h localhost -p 7389 -b > uid=ipara,ou=People,o=ipaca description > > The second integer in description is the serial number. > > rob Yep that is correct, on one instance I can communicate on the other I can't. Let's call them primary and secondary, the primary was the original install from whence all the others came. ipa cert-show 1 on primary works, fails on secondary. Running certutil -L -d /etc/httpd/alias -n ipaCert | grep Serial on primary renders this: Serial Number: 136 (0x88) Serial Number: 92 (0x5c) Running against secondary gives only this: Serial Number: 92 (0x5c) So it looks like that is probably the cause of all this mess, though how the primary got two certs? I dunno. Finally running the ldap query on both hosts confirms that 136 is the serial for the cert in question, so it appears that this somehow got messed up on the secondary. Sooo, with all that known (and thank you for the help, I figured it was something like this but reading the dogtag docs was taking me a good long while to suss out the issue), how does one fix it? - -Erinn -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) iQEcBAEBAgAGBQJSnMN6AAoJENetaK3v/E7PkpUH/RXcGhMAl3Zo+42+Qju9SNuT oFYDPXJc2fGGl21ZHeRyUaH+fYUtCQM6MEUyL14Vx1cQg+QcwCAkIsuYgWvPIdaf liMtDmP/e5bwZJmghMj7SI2ivteZbfc4SAHhOV/YK6URdmAL9819lXeShesXi3fW h5JeTklJQTVaEsR/NYlVn5XuppnGivKQMEzmACkAyRMzVnsrKuBGn0Tu512BFhTI RU7rv78vKymH5LNsMk8R2EUedyMFTSkYDdDhziiq2fBP1ATEW7Cd0aeB3voTB9Ty BgPf3aFqzuvuQL9Z/sUlgBMRAlFpr8h1B/pl36A1fpJhn451tsaYECfUieHV4CU= =vjbw -----END PGP SIGNATURE----- From rcritten at redhat.com Mon Dec 2 18:18:19 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 02 Dec 2013 13:18:19 -0500 Subject: [Freeipa-users] Dogtag not working? In-Reply-To: <529CC37E.4070202@gmail.com> References: <5297C8D2.4080407@gmail.com> <5298FAA2.8060000@gmail.com> <529CAA00.4060000@redhat.com> <529CABC5.5000804@gmail.com> <529CAF66.2050106@redhat.com> <529CC37E.4070202@gmail.com> Message-ID: <529CCEEB.4070005@redhat.com> Erinn Looney-Triggs wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 12/02/2013 08:03 AM, Rob Crittenden wrote: >> Erinn Looney-Triggs wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>> >>> On 12/02/2013 07:40 AM, Rob Crittenden wrote: >>>> Erinn Looney-Triggs wrote: >>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> >>>>> On 11/28/2013 03:50 PM, Erinn Looney-Triggs wrote: >>>>>> In the process of prepping a replication host for changing >>>>>> over the CA I had to use certmonger to generate another >>>>>> certificate on my secondary IPA server. Unfortunately it >>>>>> seems to fail every single time. Here is what I am running >>>>>> and here is what I am getting: >>>>>> >>>>>> ipa-getcert request -k private/ipa2.abaqis.com.key -f >>>>>> certs/ipa2.abaqis.com.crt -g 2048 >>>>>> >>>>>> The request appears to work, however when checking the list >>>>>> I receive the following: >>>>>> >>>>>> ipa-getcert list -r Number of certificates and requests >>>>>> being tracked: 9. Request ID '20131128202128': status: >>>>>> CA_UNREACHABLE ca-error: Server failed request, will >>>>>> retry: 4301 (RPC failed at server. Certificate operation >>>>>> cannot be completed: FAILURE (Authentication Error)). >>>>>> stuck: yes key pair storage: >>>>>> type=FILE,location='/etc/pki/tls/private/ipa2.abaqis.com.key' >>>>>> >>>>>> > certificate: >>>>>> type=FILE,location='/etc/pki/tls/certs/ipa2.abaqis.com.crt' >>>>>> >>>>>> > CA: IPA issuer: subject: expires: unknown pre-save command: >>>>>> post-save command: track: yes auto-renew: yes >>>>>> >>>>>> Fine, I check the http logs and get about the same: [Thu >>>>>> Nov 28 22:03:06 2013] [error] ipa: ERROR: >>>>>> ipaserver.plugins.dogtag.ra.request_certificate(): FAILURE >>>>>> (Authentication Error) >>>>>> >>>>>> Now as I understand it ipa-getcert is going to theserver >>>>>> listed in /etc/ipa/default.conf, which in this case is >>>>>> ipa2.abaqis.com (the request is coming from the same host). >>>>>> The host principle in /etc/krb5.keytab is used for >>>>>> authentication. >>>>>> >>>>>> I have tested against the primary ipa server and >>>>>> everything works as it should. However, any requests going >>>>>> against ipa2 for certificates are failing. >>>>>> >>>>>> At this point I am stuck, so any suggestions are welcome. >>>>>> >>>>>> -Erinn >>>>>> >>>>>> >>>>> >>>>> Replying to myself here, and narrowing this down a bit >>>>> further this seems to be a straight auth problem against my >>>>> secondary ipa server. All command work against the primary, >>>>> all certificate commands against the secondary fail. >>>>> >>>>> It appears to be confined to dogtag (other commands like ipa >>>>> user-show work), but how exactly dogtag handles auth I am >>>>> not clear on. It appears as though mod_auth_kerb handles most >>>>> things and that is definitely working. However any access >>>>> against dogtag components is failing, so dogtag >>>>> must/should/may be handling auth internally in a way that is >>>>> failing. >>>>> >>>>> Anyway, suggestions are still welcome, >>>> >>>> Run this on the replica and see if it is being tracked by >>>> certmonger >>>> >>>> # getcert list -d /etc/httpd/alias -n ipaCert >>>> >>>> If not, see if the a cert with the nickname ipaCert is in >>>> /etc/httpd/alias: >>>> >>>> # certutil -L -d /etc/httpd/alias -n ipaCert >>>> >>>> If so, see if you have the key: >>>> >>>> # certutil -K -d /etc/httpd/alias -n ipaCert -f >>>> /etc/httpd/alias/pwdfile.txt >>>> >>>> This is the RA agent certificate that IPA uses to authenticate >>>> to dogtag. If it doesn't exist, or is expired, or is the wrong >>>> one, then authentication will fail. >>>> >>>> The cert is shared amongst all the IPA masters, so if it is >>>> working on one master then fixing the replica should be >>>> straightforward assuming it already has the key. >>>> >>>> rob >>> >>> getcert list -d /etc/httpd/alias -n ipaCert Number of >>> certificates and requests being tracked: 9. Request ID >>> '20130221171049': status: MONITORING stuck: no key pair storage: >>> type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS >>> >>> > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >>> certificate: >>> type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS >>> >>> > Certificate DB' >>> CA: dogtag-ipa-retrieve-agent-submit issuer: CN=Certificate >>> Authority,O=ABAQIS.COM subject: CN=IPA RA,O=ABAQIS.COM expires: >>> 2013-12-10 03:23:26 UTC eku: id-kp-serverAuth,id-kp-clientAuth >>> pre-save command: post-save command: >>> /usr/lib64/ipa/certmonger/restart_httpd track: yes auto-renew: >>> yes >>> >>> All the components appear to be there, the certificate is valid >>> until the 10th as you can see about. The other two commands >>> worked fine as well and everything appears to me to be valid. >>> >>> However, I am still getting the auth errors, and I note in the >>> log, what I assume to be the first ipa server attempting to >>> connect and getting auth errors as well. >> >> Ok, I'm a little unclear on something. Can any of your IPA masters >> communicate with dogtag? I thought that one master could and one >> couldn't. >> >> A simple way to find out is: >> >> # ipa cert-show 1 >> >> This shows some random cert. If you get cert output then things >> are working. If not the logs will probably confirm the auth >> failure. >> >> Next step is to run this on each master: >> >> # certutil -L -d /etc/httpd/alias -n ipaCert | grep Serial >> >> The serial numbers should be the same. I wonder if you'll find the >> to be different. >> >> The serial number should match this value: >> >> # ldapsearch -x -h localhost -p 7389 -b >> uid=ipara,ou=People,o=ipaca description >> >> The second integer in description is the serial number. >> >> rob > > Yep that is correct, on one instance I can communicate on the other I > can't. Let's call them primary and secondary, the primary was the > original install from whence all the others came. > > ipa cert-show 1 on primary works, fails on secondary. > > Running certutil -L -d /etc/httpd/alias -n ipaCert | grep Serial on > primary renders this: > > Serial Number: 136 (0x88) > Serial Number: 92 (0x5c) > > Running against secondary gives only this: > Serial Number: 92 (0x5c) > > So it looks like that is probably the cause of all this mess, though > how the primary got two certs? I dunno. > > Finally running the ldap query on both hosts confirms that 136 is the > serial for the cert in question, so it appears that this somehow got > messed up on the secondary. > > Sooo, with all that known (and thank you for the help, I figured it > was something like this but reading the dogtag docs was taking me a > good long while to suss out the issue), how does one fix it? NSS uses a database to store its certificates so it's possible (and legal) to have multiple certs for the same private key. NSS picks the best one (e.g. the one that's valid). So what you need to do on the primary is: # certutil -L -d /etc/httpd/alias -n ipaCert -a > /tmp/ra.crt Edit that file. there will be two certs in BEGIN/END blocks. If memory serves the last one is the one you want, so remove the first. You can double-check this after updating the file with: # openssl x509 -text -in /tmp/ra.crt It should have only the cert with the latest serial #. Now add it to your cert database: # certutil -A -n ipaCert -d /etc/httpd/alias -t u,u,u -a -i /tmp/ra.crt # service httpd restart Things should work now. rob From erinn.looneytriggs at gmail.com Tue Dec 3 06:43:48 2013 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Mon, 02 Dec 2013 22:43:48 -0800 Subject: [Freeipa-users] Dogtag not working? In-Reply-To: <529CCEEB.4070005@redhat.com> References: <5297C8D2.4080407@gmail.com> <5298FAA2.8060000@gmail.com> <529CAA00.4060000@redhat.com> <529CABC5.5000804@gmail.com> <529CAF66.2050106@redhat.com> <529CC37E.4070202@gmail.com> <529CCEEB.4070005@redhat.com> Message-ID: <529D7DA4.601@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/02/2013 10:18 AM, Rob Crittenden wrote: > Erinn Looney-Triggs wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> On 12/02/2013 08:03 AM, Rob Crittenden wrote: >>> Erinn Looney-Triggs wrote: >>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>> >>>> On 12/02/2013 07:40 AM, Rob Crittenden wrote: >>>>> Erinn Looney-Triggs wrote: >>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>>> >>>>>> On 11/28/2013 03:50 PM, Erinn Looney-Triggs wrote: >>>>>>> In the process of prepping a replication host for >>>>>>> changing over the CA I had to use certmonger to >>>>>>> generate another certificate on my secondary IPA >>>>>>> server. Unfortunately it seems to fail every single >>>>>>> time. Here is what I am running and here is what I am >>>>>>> getting: >>>>>>> >>>>>>> ipa-getcert request -k private/ipa2.abaqis.com.key -f >>>>>>> certs/ipa2.abaqis.com.crt -g 2048 >>>>>>> >>>>>>> The request appears to work, however when checking the >>>>>>> list I receive the following: >>>>>>> >>>>>>> ipa-getcert list -r Number of certificates and >>>>>>> requests being tracked: 9. Request ID '20131128202128': >>>>>>> status: CA_UNREACHABLE ca-error: Server failed request, >>>>>>> will retry: 4301 (RPC failed at server. Certificate >>>>>>> operation cannot be completed: FAILURE (Authentication >>>>>>> Error)). stuck: yes key pair storage: >>>>>>> type=FILE,location='/etc/pki/tls/private/ipa2.abaqis.com.key' >>>>>>> >>>>>>> >> >>>>>>> certificate: >>>>>>> type=FILE,location='/etc/pki/tls/certs/ipa2.abaqis.com.crt' >>>>>>> >>>>>>> >> >>>>>>> CA: IPA issuer: subject: expires: unknown pre-save command: >>>>>>> post-save command: track: yes auto-renew: yes >>>>>>> >>>>>>> Fine, I check the http logs and get about the same: >>>>>>> [Thu Nov 28 22:03:06 2013] [error] ipa: ERROR: >>>>>>> ipaserver.plugins.dogtag.ra.request_certificate(): >>>>>>> FAILURE (Authentication Error) >>>>>>> >>>>>>> Now as I understand it ipa-getcert is going to >>>>>>> theserver listed in /etc/ipa/default.conf, which in >>>>>>> this case is ipa2.abaqis.com (the request is coming >>>>>>> from the same host). The host principle in >>>>>>> /etc/krb5.keytab is used for authentication. >>>>>>> >>>>>>> I have tested against the primary ipa server and >>>>>>> everything works as it should. However, any requests >>>>>>> going against ipa2 for certificates are failing. >>>>>>> >>>>>>> At this point I am stuck, so any suggestions are >>>>>>> welcome. >>>>>>> >>>>>>> -Erinn >>>>>>> >>>>>>> >>>>>> >>>>>> Replying to myself here, and narrowing this down a bit >>>>>> further this seems to be a straight auth problem against >>>>>> my secondary ipa server. All command work against the >>>>>> primary, all certificate commands against the secondary >>>>>> fail. >>>>>> >>>>>> It appears to be confined to dogtag (other commands like >>>>>> ipa user-show work), but how exactly dogtag handles auth >>>>>> I am not clear on. It appears as though mod_auth_kerb >>>>>> handles most things and that is definitely working. >>>>>> However any access against dogtag components is failing, >>>>>> so dogtag must/should/may be handling auth internally in >>>>>> a way that is failing. >>>>>> >>>>>> Anyway, suggestions are still welcome, >>>>> >>>>> Run this on the replica and see if it is being tracked by >>>>> certmonger >>>>> >>>>> # getcert list -d /etc/httpd/alias -n ipaCert >>>>> >>>>> If not, see if the a cert with the nickname ipaCert is in >>>>> /etc/httpd/alias: >>>>> >>>>> # certutil -L -d /etc/httpd/alias -n ipaCert >>>>> >>>>> If so, see if you have the key: >>>>> >>>>> # certutil -K -d /etc/httpd/alias -n ipaCert -f >>>>> /etc/httpd/alias/pwdfile.txt >>>>> >>>>> This is the RA agent certificate that IPA uses to >>>>> authenticate to dogtag. If it doesn't exist, or is expired, >>>>> or is the wrong one, then authentication will fail. >>>>> >>>>> The cert is shared amongst all the IPA masters, so if it >>>>> is working on one master then fixing the replica should be >>>>> straightforward assuming it already has the key. >>>>> >>>>> rob >>>> >>>> getcert list -d /etc/httpd/alias -n ipaCert Number of >>>> certificates and requests being tracked: 9. Request ID >>>> '20130221171049': status: MONITORING stuck: no key pair >>>> storage: >>>> type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS >>>> >>>> >> >>>> Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >>>> certificate: >>>> type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS >>>> >>>> >> >>>> Certificate DB' >>>> CA: dogtag-ipa-retrieve-agent-submit issuer: CN=Certificate >>>> Authority,O=ABAQIS.COM subject: CN=IPA RA,O=ABAQIS.COM >>>> expires: 2013-12-10 03:23:26 UTC eku: >>>> id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save >>>> command: /usr/lib64/ipa/certmonger/restart_httpd track: yes >>>> auto-renew: yes >>>> >>>> All the components appear to be there, the certificate is >>>> valid until the 10th as you can see about. The other two >>>> commands worked fine as well and everything appears to me to >>>> be valid. >>>> >>>> However, I am still getting the auth errors, and I note in >>>> the log, what I assume to be the first ipa server attempting >>>> to connect and getting auth errors as well. >>> >>> Ok, I'm a little unclear on something. Can any of your IPA >>> masters communicate with dogtag? I thought that one master >>> could and one couldn't. >>> >>> A simple way to find out is: >>> >>> # ipa cert-show 1 >>> >>> This shows some random cert. If you get cert output then >>> things are working. If not the logs will probably confirm the >>> auth failure. >>> >>> Next step is to run this on each master: >>> >>> # certutil -L -d /etc/httpd/alias -n ipaCert | grep Serial >>> >>> The serial numbers should be the same. I wonder if you'll find >>> the to be different. >>> >>> The serial number should match this value: >>> >>> # ldapsearch -x -h localhost -p 7389 -b >>> uid=ipara,ou=People,o=ipaca description >>> >>> The second integer in description is the serial number. >>> >>> rob >> >> Yep that is correct, on one instance I can communicate on the >> other I can't. Let's call them primary and secondary, the primary >> was the original install from whence all the others came. >> >> ipa cert-show 1 on primary works, fails on secondary. >> >> Running certutil -L -d /etc/httpd/alias -n ipaCert | grep Serial >> on primary renders this: >> >> Serial Number: 136 (0x88) Serial Number: 92 (0x5c) >> >> Running against secondary gives only this: Serial Number: 92 >> (0x5c) >> >> So it looks like that is probably the cause of all this mess, >> though how the primary got two certs? I dunno. >> >> Finally running the ldap query on both hosts confirms that 136 is >> the serial for the cert in question, so it appears that this >> somehow got messed up on the secondary. >> >> Sooo, with all that known (and thank you for the help, I figured >> it was something like this but reading the dogtag docs was taking >> me a good long while to suss out the issue), how does one fix >> it? > > NSS uses a database to store its certificates so it's possible > (and legal) to have multiple certs for the same private key. NSS > picks the best one (e.g. the one that's valid). > > So what you need to do on the primary is: > > # certutil -L -d /etc/httpd/alias -n ipaCert -a > /tmp/ra.crt > > Edit that file. there will be two certs in BEGIN/END blocks. If > memory serves the last one is the one you want, so remove the > first. You can double-check this after updating the file with: > > # openssl x509 -text -in /tmp/ra.crt > > It should have only the cert with the latest serial #. > > Now add it to your cert database: > > # certutil -A -n ipaCert -d /etc/httpd/alias -t u,u,u -a -i > /tmp/ra.crt # service httpd restart > > Things should work now. > > rob > Rob, Thanks so much for the help. It was the first certificate but other than that you were spot on, we can't all be perfect ;). That fixed the issue and I am now able to do cert operations on both hosts. Any idea how this situation could have come about? - -Erinn -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) iQEcBAEBAgAGBQJSnX2dAAoJENetaK3v/E7P8rEIALrZScud0/26PR8XuRutdOCc 5HtplJCSlEIYRcj0Kov9v79YEu9BR94MK2DgrrPPp3owHLzmyaKvR/0HP5/GrnKC DijRPckqEwrKICMmol3IqFZGPg2xwygI5voG6artPGfVi58lphXacFC+Yu3OQk64 jxrUHnrCVXWXqqerZsBurXfXAf4JYp0mem+IUzjNhKCKSYjje9Mnnc9rJHiRSY5q xwjvz+3OcAKae/OS7hBI1exNwxRwdhnIM+fxz2waCbLMKVEGikrj2wcljMw3sLog Vg0+i7FqSaAo81KekSw0u9VmbO7ouwLoYLspRZRBs3TY72Zjq6ArFnisQI9m4NE= =9Cdi -----END PGP SIGNATURE----- From rcritten at redhat.com Tue Dec 3 13:45:06 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 03 Dec 2013 08:45:06 -0500 Subject: [Freeipa-users] Dogtag not working? In-Reply-To: <529D7DA4.601@gmail.com> References: <5297C8D2.4080407@gmail.com> <5298FAA2.8060000@gmail.com> <529CAA00.4060000@redhat.com> <529CABC5.5000804@gmail.com> <529CAF66.2050106@redhat.com> <529CC37E.4070202@gmail.com> <529CCEEB.4070005@redhat.com> <529D7DA4.601@gmail.com> Message-ID: <529DE062.6060705@redhat.com> Erinn Looney-Triggs wrote: > > Rob, > Thanks so much for the help. It was the first certificate but other > than that you were spot on, we can't all be perfect ;). That fixed the > issue and I am now able to do cert operations on both hosts. > > Any idea how this situation could have come about? It would seem that the certificate was automatically renewed on primary but secondary didn't pick it up (not sure if it was configured to do so). rob From sprokhorov at intech-global.com Tue Dec 3 10:33:52 2013 From: sprokhorov at intech-global.com (=?UTF-8?B?0J/RgNC+0YXQvtGA0L7QsiDQodC10YDQs9C10Lk=?=) Date: Tue, 03 Dec 2013 14:33:52 +0400 Subject: [Freeipa-users] Problems with FreeIPA-client configuration on OpenSUSE 12.2 Message-ID: <529DB390.8030104@intech-global.com> Hello community, I have problems with FreeIPA-client configuration on OpenSUSE 12.2, and I think I can't fix it without your help. I have following errors in my /var/log/messages, when I try login in by freeipa account: ############################################################ Dec 2 18:21:24 linux-l3wy sshd[12481]: Invalid user admin from 192.168.0.159 Dec 2 18:21:24 linux-l3wy sshd[12481]: input_userauth_request: invalid user admin [preauth] Dec 2 18:21:24 linux-l3wy sssd_be: No worthy mechs found Dec 2 18:21:24 linux-l3wy sshd[12481]: Postponed keyboard-interactive for invalid user admin from 192.168.0.159 port 38175 ssh2 [preauth] Dec 2 18:21:41 linux-l3wy sshd[12484]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.0.159 user=admin Dec 2 18:21:41 linux-l3wy sshd[12484]: pam_sss(sshd:auth): received for user admin: 10 (User not known to the underlying authentication module) Dec 2 18:21:41 linux-l3wy sshd[12481]: error: PAM: User not known to the underlying authentication module for illegal user admin from 192.168.0.159 Dec 2 18:21:41 linux-l3wy sshd[12481]: Failed keyboard-interactive/pam for invalid user admin from 192.168.0.159 port 38175 ssh2 Dec 2 18:21:41 linux-l3wy sshd[12481]: Postponed keyboard-interactive for invalid user admin from 192.168.0.159 port 38175 ssh2 [preauth] Dec 2 18:21:50 linux-l3wy sshd[12481]: Connection closed by 192.168.0.159 [preauth] ############################################################ About client configuration: My installed packages sssd-ldap-1.11.2-110.6.x86_64 sssd-ipa-1.11.2-110.6.x86_64 sssd-1.11.2-110.6.x86_64 sssd-tools-1.11.2-110.6.x86_64 sssd-krb5-common-1.11.2-110.6.x86_64 *//etc/sss/**/d/sssd.conf:/* ############################################################ [domain/example.com] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = example.com id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = client1.example.com chpass_provider = ipa ipa_server = _srv_, ipa.example.com ldap_tls_cacert = /etc/ipa/ca.crt [sssd] services = nss, pam, ssh config_file_version = 2 domains = example.com debug_level=9 ############################################################ /etc/krb5.conf: ############################################################ [libdefaults] default_realm = EXAMPLE.COM #dns_lookup_realm = false #dns_lookup_kdc = false dns_lookup_realm = true dns_lookup_kdc = true rdns = false ticket_lifetime = 24h forwardable = yes #allow_weak_crypto = true [realms] example.COM = { pkinit_anchors = FILE:/etc/ipa/ca.crt #kdc = ipa.example.com:88 #admin_server = ipa.example.com:749 #default_domain = example.com } [domain_realm] .example.com = example.COM example.com = example.COM [logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log ############################################################ P.S. Thank you for your time, and sorry for my English. -- Sergey Prokhorov System Engineer e-mail: sprokhorov at intech-global.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From erinn.looneytriggs at gmail.com Tue Dec 3 16:19:47 2013 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Tue, 03 Dec 2013 08:19:47 -0800 Subject: [Freeipa-users] Dogtag not working? In-Reply-To: <529DE062.6060705@redhat.com> References: <5297C8D2.4080407@gmail.com> <5298FAA2.8060000@gmail.com> <529CAA00.4060000@redhat.com> <529CABC5.5000804@gmail.com> <529CAF66.2050106@redhat.com> <529CC37E.4070202@gmail.com> <529CCEEB.4070005@redhat.com> <529D7DA4.601@gmail.com> <529DE062.6060705@redhat.com> Message-ID: <529E04A3.2050006@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/03/2013 05:45 AM, Rob Crittenden wrote: > Erinn Looney-Triggs wrote: > >> >> Rob, Thanks so much for the help. It was the first certificate >> but other than that you were spot on, we can't all be perfect ;). >> That fixed the issue and I am now able to do cert operations on >> both hosts. >> >> Any idea how this situation could have come about? > > It would seem that the certificate was automatically renewed on > primary but secondary didn't pick it up (not sure if it was > configured to do so). > > rob Ok well I guess my concern here is how to determine whether this will happen again in the future. So where abouts would I check to see if it was configured to pick up the change? - -Erinn -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) iQEcBAEBAgAGBQJSngSWAAoJENetaK3v/E7Pm+YIAKO4I8TVXoNKic7GwFIn/xV1 Unl9EozNW+/BKckbt4nkNL28WnNKHNqVZfjeEy+zyHONAUDkzJyvjD9Lb/Qep7bB /5x5r1wFxfVNEaN/gcmm80RF4LAOxLOYWh3r/lm/pWmE8Wv2jDbRj9NjxOAVkAbX wsZRNXHXJJRZNjOYhESbdaTf5c/ZsTTjWoSCuBUi1cBy5WJaj7skl9iOfUvsKLyw IKp/HvK00gem4Ffb/htzHB2ahP7++QDR29BNpzD9+BL2U41NFaIHVCyPtBnsIcFi Dqei2xfsVpVfIFPBbXhbzYa9UrjAus1Ix7VbHp7NTNNvVTcZUGqS6XG1Li2xQHM= =oZif -----END PGP SIGNATURE----- From jhrozek at redhat.com Tue Dec 3 16:25:50 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 3 Dec 2013 17:25:50 +0100 Subject: [Freeipa-users] Problems with FreeIPA-client configuration on OpenSUSE 12.2 In-Reply-To: <529DB390.8030104@intech-global.com> References: <529DB390.8030104@intech-global.com> Message-ID: <20131203162550.GQ12859@hendrix.redhat.com> On Tue, Dec 03, 2013 at 02:33:52PM +0400, ???????? ?????? wrote: > Hello community, I have problems with FreeIPA-client configuration > on OpenSUSE 12.2, and I think I can't fix it without your help. I > have following errors in my /var/log/messages, when I try login in > by freeipa account: > > ############################################################ > Dec 2 18:21:24 linux-l3wy sshd[12481]: Invalid user admin from > 192.168.0.159 > Dec 2 18:21:24 linux-l3wy sshd[12481]: input_userauth_request: > invalid user admin [preauth] > Dec 2 18:21:24 linux-l3wy sssd_be: No worthy mechs found > Dec 2 18:21:24 linux-l3wy sshd[12481]: Postponed > keyboard-interactive for invalid user admin from 192.168.0.159 port > 38175 ssh2 [preauth] > Dec 2 18:21:41 linux-l3wy sshd[12484]: pam_sss(sshd:auth): > authentication failure; logname= uid=0 euid=0 tty=ssh ruser= > rhost=192.168.0.159 user=admin > Dec 2 18:21:41 linux-l3wy sshd[12484]: pam_sss(sshd:auth): received > for user admin: 10 (User not known to the underlying authentication > module) > Dec 2 18:21:41 linux-l3wy sshd[12481]: error: PAM: User not known > to the underlying authentication module for illegal user admin from > 192.168.0.159 > Dec 2 18:21:41 linux-l3wy sshd[12481]: Failed > keyboard-interactive/pam for invalid user admin from 192.168.0.159 > port 38175 ssh2 > Dec 2 18:21:41 linux-l3wy sshd[12481]: Postponed > keyboard-interactive for invalid user admin from 192.168.0.159 port > 38175 ssh2 [preauth] > Dec 2 18:21:50 linux-l3wy sshd[12481]: Connection closed by > 192.168.0.159 [preauth] > ############################################################ > > About client configuration: > My installed packages > sssd-ldap-1.11.2-110.6.x86_64 > sssd-ipa-1.11.2-110.6.x86_64 > sssd-1.11.2-110.6.x86_64 > sssd-tools-1.11.2-110.6.x86_64 > sssd-krb5-common-1.11.2-110.6.x86_64 Hi, are you able to run "getent passwd admin" from the command line? SSH is complaining that admin is not a known account. From rcritten at redhat.com Tue Dec 3 17:45:24 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 03 Dec 2013 12:45:24 -0500 Subject: [Freeipa-users] Dogtag not working? In-Reply-To: <529D7DA4.601@gmail.com> References: <5297C8D2.4080407@gmail.com> <5298FAA2.8060000@gmail.com> <529CAA00.4060000@redhat.com> <529CABC5.5000804@gmail.com> <529CAF66.2050106@redhat.com> <529CC37E.4070202@gmail.com> <529CCEEB.4070005@redhat.com> <529D7DA4.601@gmail.com> Message-ID: <529E18B4.3080401@redhat.com> Erinn Looney-Triggs wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 12/02/2013 10:18 AM, Rob Crittenden wrote: >> Erinn Looney-Triggs wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>> >>> On 12/02/2013 08:03 AM, Rob Crittenden wrote: >>>> Erinn Looney-Triggs wrote: >>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> >>>>> On 12/02/2013 07:40 AM, Rob Crittenden wrote: >>>>>> Erinn Looney-Triggs wrote: >>>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>>>> >>>>>>> On 11/28/2013 03:50 PM, Erinn Looney-Triggs wrote: >>>>>>>> In the process of prepping a replication host for >>>>>>>> changing over the CA I had to use certmonger to >>>>>>>> generate another certificate on my secondary IPA >>>>>>>> server. Unfortunately it seems to fail every single >>>>>>>> time. Here is what I am running and here is what I am >>>>>>>> getting: >>>>>>>> >>>>>>>> ipa-getcert request -k private/ipa2.abaqis.com.key -f >>>>>>>> certs/ipa2.abaqis.com.crt -g 2048 >>>>>>>> >>>>>>>> The request appears to work, however when checking the >>>>>>>> list I receive the following: >>>>>>>> >>>>>>>> ipa-getcert list -r Number of certificates and >>>>>>>> requests being tracked: 9. Request ID '20131128202128': >>>>>>>> status: CA_UNREACHABLE ca-error: Server failed request, >>>>>>>> will retry: 4301 (RPC failed at server. Certificate >>>>>>>> operation cannot be completed: FAILURE (Authentication >>>>>>>> Error)). stuck: yes key pair storage: >>>>>>>> type=FILE,location='/etc/pki/tls/private/ipa2.abaqis.com.key' >>>>>>>> >>>>>>>> >>> >>>>>>>> > certificate: >>>>>>>> type=FILE,location='/etc/pki/tls/certs/ipa2.abaqis.com.crt' >>>>>>>> >>>>>>>> >>> >>>>>>>> > CA: IPA issuer: subject: expires: unknown pre-save command: >>>>>>>> post-save command: track: yes auto-renew: yes >>>>>>>> >>>>>>>> Fine, I check the http logs and get about the same: >>>>>>>> [Thu Nov 28 22:03:06 2013] [error] ipa: ERROR: >>>>>>>> ipaserver.plugins.dogtag.ra.request_certificate(): >>>>>>>> FAILURE (Authentication Error) >>>>>>>> >>>>>>>> Now as I understand it ipa-getcert is going to >>>>>>>> theserver listed in /etc/ipa/default.conf, which in >>>>>>>> this case is ipa2.abaqis.com (the request is coming >>>>>>>> from the same host). The host principle in >>>>>>>> /etc/krb5.keytab is used for authentication. >>>>>>>> >>>>>>>> I have tested against the primary ipa server and >>>>>>>> everything works as it should. However, any requests >>>>>>>> going against ipa2 for certificates are failing. >>>>>>>> >>>>>>>> At this point I am stuck, so any suggestions are >>>>>>>> welcome. >>>>>>>> >>>>>>>> -Erinn >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> Replying to myself here, and narrowing this down a bit >>>>>>> further this seems to be a straight auth problem against >>>>>>> my secondary ipa server. All command work against the >>>>>>> primary, all certificate commands against the secondary >>>>>>> fail. >>>>>>> >>>>>>> It appears to be confined to dogtag (other commands like >>>>>>> ipa user-show work), but how exactly dogtag handles auth >>>>>>> I am not clear on. It appears as though mod_auth_kerb >>>>>>> handles most things and that is definitely working. >>>>>>> However any access against dogtag components is failing, >>>>>>> so dogtag must/should/may be handling auth internally in >>>>>>> a way that is failing. >>>>>>> >>>>>>> Anyway, suggestions are still welcome, >>>>>> >>>>>> Run this on the replica and see if it is being tracked by >>>>>> certmonger >>>>>> >>>>>> # getcert list -d /etc/httpd/alias -n ipaCert >>>>>> >>>>>> If not, see if the a cert with the nickname ipaCert is in >>>>>> /etc/httpd/alias: >>>>>> >>>>>> # certutil -L -d /etc/httpd/alias -n ipaCert >>>>>> >>>>>> If so, see if you have the key: >>>>>> >>>>>> # certutil -K -d /etc/httpd/alias -n ipaCert -f >>>>>> /etc/httpd/alias/pwdfile.txt >>>>>> >>>>>> This is the RA agent certificate that IPA uses to >>>>>> authenticate to dogtag. If it doesn't exist, or is expired, >>>>>> or is the wrong one, then authentication will fail. >>>>>> >>>>>> The cert is shared amongst all the IPA masters, so if it >>>>>> is working on one master then fixing the replica should be >>>>>> straightforward assuming it already has the key. >>>>>> >>>>>> rob >>>>> >>>>> getcert list -d /etc/httpd/alias -n ipaCert Number of >>>>> certificates and requests being tracked: 9. Request ID >>>>> '20130221171049': status: MONITORING stuck: no key pair >>>>> storage: >>>>> type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS >>>>> >>>>> >>> >>>>> > Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >>>>> certificate: >>>>> type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS >>>>> >>>>> >>> >>>>> > Certificate DB' >>>>> CA: dogtag-ipa-retrieve-agent-submit issuer: CN=Certificate >>>>> Authority,O=ABAQIS.COM subject: CN=IPA RA,O=ABAQIS.COM >>>>> expires: 2013-12-10 03:23:26 UTC eku: >>>>> id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save >>>>> command: /usr/lib64/ipa/certmonger/restart_httpd track: yes >>>>> auto-renew: yes >>>>> >>>>> All the components appear to be there, the certificate is >>>>> valid until the 10th as you can see about. The other two >>>>> commands worked fine as well and everything appears to me to >>>>> be valid. >>>>> >>>>> However, I am still getting the auth errors, and I note in >>>>> the log, what I assume to be the first ipa server attempting >>>>> to connect and getting auth errors as well. >>>> >>>> Ok, I'm a little unclear on something. Can any of your IPA >>>> masters communicate with dogtag? I thought that one master >>>> could and one couldn't. >>>> >>>> A simple way to find out is: >>>> >>>> # ipa cert-show 1 >>>> >>>> This shows some random cert. If you get cert output then >>>> things are working. If not the logs will probably confirm the >>>> auth failure. >>>> >>>> Next step is to run this on each master: >>>> >>>> # certutil -L -d /etc/httpd/alias -n ipaCert | grep Serial >>>> >>>> The serial numbers should be the same. I wonder if you'll find >>>> the to be different. >>>> >>>> The serial number should match this value: >>>> >>>> # ldapsearch -x -h localhost -p 7389 -b >>>> uid=ipara,ou=People,o=ipaca description >>>> >>>> The second integer in description is the serial number. >>>> >>>> rob >>> >>> Yep that is correct, on one instance I can communicate on the >>> other I can't. Let's call them primary and secondary, the primary >>> was the original install from whence all the others came. >>> >>> ipa cert-show 1 on primary works, fails on secondary. >>> >>> Running certutil -L -d /etc/httpd/alias -n ipaCert | grep Serial >>> on primary renders this: >>> >>> Serial Number: 136 (0x88) Serial Number: 92 (0x5c) >>> >>> Running against secondary gives only this: Serial Number: 92 >>> (0x5c) >>> >>> So it looks like that is probably the cause of all this mess, >>> though how the primary got two certs? I dunno. >>> >>> Finally running the ldap query on both hosts confirms that 136 is >>> the serial for the cert in question, so it appears that this >>> somehow got messed up on the secondary. >>> >>> Sooo, with all that known (and thank you for the help, I figured >>> it was something like this but reading the dogtag docs was taking >>> me a good long while to suss out the issue), how does one fix >>> it? >> >> NSS uses a database to store its certificates so it's possible >> (and legal) to have multiple certs for the same private key. NSS >> picks the best one (e.g. the one that's valid). >> >> So what you need to do on the primary is: >> >> # certutil -L -d /etc/httpd/alias -n ipaCert -a > /tmp/ra.crt >> >> Edit that file. there will be two certs in BEGIN/END blocks. If >> memory serves the last one is the one you want, so remove the >> first. You can double-check this after updating the file with: >> >> # openssl x509 -text -in /tmp/ra.crt >> >> It should have only the cert with the latest serial #. >> >> Now add it to your cert database: >> >> # certutil -A -n ipaCert -d /etc/httpd/alias -t u,u,u -a -i >> /tmp/ra.crt # service httpd restart >> >> Things should work now. >> >> rob >> > > Rob, > Thanks so much for the help. It was the first certificate but other > than that you were spot on, we can't all be perfect ;). That fixed the > issue and I am now able to do cert operations on both hosts. > > Any idea how this situation could have come about? The way it is supposed to work is this: certmonger on primary should be tracking ipaCert and handled renewal. This involves renewing the cert, stuffing it into /etc/httpd/alias, updating an entry in the dogtag CA server and then stuffing the cert into the IPA LDAP database under cn=ca_renewal,cn=ipa,cn=etc,$SUFFIX. certmonger on secondary should also be tracking ipaCert but it instead watches the cn=ca_renewal for an updated cert and if one appears, it will update it locally. So either the cert never got stuffed into cn=ca_renewal or secondary isn't tracking the cert, or something I haven't thought of. rob From andrewprecht06 at gmail.com Tue Dec 3 18:28:15 2013 From: andrewprecht06 at gmail.com (Andrew Precht) Date: Tue, 3 Dec 2013 10:28:15 -0800 Subject: [Freeipa-users] sssd errors in Ubuntu 12.04 Message-ID: Hi IPA users, I'm having trouble getting the FreeIPA client to work in Ubuntu 12.04. I'm working my way through the Red Hat sssd troubleshooting guide: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/SSSD-Troubleshooting.html When I try a:* ldapsearch -x -ZZ -h test.example.com -b dc=example,dc=com* I get: *ldap_start_tls: Connect error (-11) additional info: (unknown error code)* I have copied the /etc/ipa/ca.crt from the ipa server to the ubuntu client and the sssd.conf has: *ldap_tls_cacert = /etc/ipa/ca.crt* My syslog file has no mention of a non-trusted certificate. Any ideas on where to look next? Thanks Andrew Precht -------------- next part -------------- An HTML attachment was scrubbed... URL: From tsoucy at salesforce.com Tue Dec 3 18:51:37 2013 From: tsoucy at salesforce.com (Terry Soucy) Date: Tue, 3 Dec 2013 14:51:37 -0400 Subject: [Freeipa-users] sssd errors in Ubuntu 12.04 In-Reply-To: References: Message-ID: Are you able to connect without a Start TLS? ldapsearch -x -h test.example.com -b dc=example,dc=com -w supersecretpassphrase If that works, then you have no ldap issues, and should be able to go straight to getting sssd running with a keytab. If you want to test the keytab, you can export it to a system, and run .. kinit -kt /path/to/keytab Then take a look to see if you have a ticket ... klist If you have a ticket, then you should be able to auth to the ldap server using SASL ldapsearch -Y GSSAPI -h test.example.com blah blah blah. I have IPA setup with Ubuntu 12 clients, so I'm happy to lend a hand if you need more information along the way. Terry On Tue, Dec 3, 2013 at 2:28 PM, Andrew Precht wrote: > Hi IPA users, > I'm having trouble getting the FreeIPA client to work in Ubuntu 12.04. I'm > working my way through the Red Hat sssd troubleshooting guide: > https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/SSSD-Troubleshooting.html > > When I try a:* ldapsearch -x -ZZ -h test.example.com > -b dc=example,dc=com* > > I get: *ldap_start_tls: Connect error (-11) additional info: (unknown > error code)* > > I have copied the /etc/ipa/ca.crt from the ipa server to the ubuntu client > and the sssd.conf has: *ldap_tls_cacert = /etc/ipa/ca.crt* > > My syslog file has no mention of a non-trusted certificate. > > Any ideas on where to look next? > > Thanks Andrew Precht > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -- Terry Soucy - Systems Engineer Salesforce MarketingCloud - http://www.salesforce.com (o) 506.631.7445 (c) 506.609.3247 | (e) tsoucy at salesforce.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From erinn.looneytriggs at gmail.com Tue Dec 3 18:57:46 2013 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Tue, 03 Dec 2013 10:57:46 -0800 Subject: [Freeipa-users] CA expiration and renewal In-Reply-To: <529643F3.9020907@redhat.com> References: <52842407.80504@gmail.com> <52939269.1070405@redhat.com> <52963840.8090703@gmail.com> <529643F3.9020907@redhat.com> Message-ID: <529E29AA.90300@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/27/2013 11:11 AM, Rob Crittenden wrote: > Erinn Looney-Triggs wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> >> >> On 11/25/2013 11:09 AM, Rob Crittenden wrote: >>> Erinn Looney-Triggs wrote: >>>> Folks just wanted to touch base again before the American >>>> holiday season starts. My CA, which is subordinate to AD CS >>>> will be expiring on December 9th, I submitted a bug, y'all >>>> drew up docs etc for a plan (thanks). Now I just wanted to >>>> see how it was going and if need be what manual steps I will >>>> need to take to renew the certificate. >>>> >>>> Thanks again for the great work, >>> >>> We're working on an a set of tools to make this easier. For >>> now I've appended some manual instructions onto a page still >>> in progress. >>> >>> http://www.freeipa.org/page/Howto/CA_Certificate_Renewal#Manual_Procedure_in_IPA_3.0 >>> >>> >>> >>> >>> >>> Some parts may be still be a little rough or hard to understand. >>> Let me know if you have any problems or corrections. >>> >>> rob >> >> Rob, >> >> Thanks for the instructions, a few questions. >> >> What sort of interruption in service could this create? > > Services will be restarted during this process including your > LDAP, Apache and CA instances. Downtime should be relatively short, > no more than a few minutes combined. > >> Can you expand on this section a little bit: Replace the value of >> ca.signing.cert in /etc/pki-ca/CS.cfg. This is the base64 value >> of the certificate. You can obtain this by removing the BEGIN/END >> blocks from ipa.crt and compressing it into a single line. > > A PEM cert looks like: > > -----BEGIN CERTIFICATE----- > MIIB/zCCAWigAwIBAgICA+gwDQYJKoZIhvcNAQEFBQAwKTEnMCUGA1UEAxMeSVBB > IFRlc3QgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTEwMDIyMzIyMzMxNVoXDTIw > MDIyMzIyMzMxNVowKTEnMCUGA1UEAxMeSVBBIFRlc3QgQ2VydGlmaWNhdGUgQXV0 > aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+G6ultyLaXqzBlypA > DnOsinkMTlZZssTFQh/QUMi1F1fcn8QUlmsl9a+l6w6hfZm7P8z3sVwsjLQcDWA4 > KxOh+LmIsNL4OKx4wKF1q/pSt1PATRU5Pgu2+3wlwJO0H7cl4QfavoOLwmxAZf/l > ZNIy/5czvSWFWj7EJj16ty9BeQIDAQABozYwNDARBglghkgBhvhCAQEEBAMCAAcw > DwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAsQwDQYJKoZIhvcNAQEFBQAD > gYEAl0gIshwNkhyfNe1XMLswPeOgH5YN1BUuKXzbv1fuSIkArjwLODr4cOdXzQvt > yaiX6Z+pRC/sK8MgLhPxV2X9QVQdzKfLkVGIdboCt1j3EXxSUCZeIuSKouitkWYe > eSH9DQkYDp/oKgANLWnY7CNorPz6xQktp1pB0DGohV1BeTA= -----END > CERTIFICATE----- > > You need to drop the BEGIN/END blocks then combine all the lines > into a single line, so you have a unified base64 blog. It will look > like: > > ca.signing.cert=MII...B0DGohV1BeTA= > > I was afraid wrapping woudl destroy my demonstration so I used > ellipses instead. > >> Thanks and happy Thanksgiving, > > You're welcome. You too. > > rob > Ok I have done the steps as outlined. One small suggestion and one question came up. Suggestion: for the ldapmodify command indicate that a ctl-d is necessary to end input. Most folks will know this, but some may not. For the client section you have me copy the newly signed subordnate CA certificate into /etc/ipa/ca.crt. However, on my hosts that was actually a copy of the AD CS certificate, not the subordinate certificate. In the case of a subordinate installation do you want the root or the subordinate CA? It would seem that the root would be broader, but I just want to make sure. - -Erinn -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) iQEcBAEBAgAGBQJSnimlAAoJENetaK3v/E7PojIH/1O8r4O6BRs87ZXpnkE8wqPS Ym6wIRIZDl+H4tAr/QCrJKdIXG40wGQEQfvyE28voEgNFnRTIN0OHdflSyNlLIKK +yMqEfjotLuepsv2GiJS7JcaoEo3cSTBU/OMGWxXnNXwiuqD6MQZoTh9sMOYJM+f IC2hPQHx4HPPXn20nwI2YXbvukPMm2igy7mpgqQqn0roKNCaxr0HSX0bY5i9Xjtq 8PTIV2tHeqkv+bCj57ZT8/80CPX+pXfBFN+aD0/9+xgsLoD1lZTqo0+Vt6mq+9Ex 00DIpdYAweTNAELWgcb3JtSjH9vDs3IyqQ2SlTEOo6T5PpUnEX3r9FxQE/G1gtc= =1nY9 -----END PGP SIGNATURE----- From erinn.looneytriggs at gmail.com Tue Dec 3 23:07:12 2013 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Tue, 03 Dec 2013 15:07:12 -0800 Subject: [Freeipa-users] Dogtag not working? In-Reply-To: <529E18B4.3080401@redhat.com> References: <5297C8D2.4080407@gmail.com> <5298FAA2.8060000@gmail.com> <529CAA00.4060000@redhat.com> <529CABC5.5000804@gmail.com> <529CAF66.2050106@redhat.com> <529CC37E.4070202@gmail.com> <529CCEEB.4070005@redhat.com> <529D7DA4.601@gmail.com> <529E18B4.3080401@redhat.com> Message-ID: <529E6420.8070706@gmail.com> On 12/3/2013 9:45 AM, Rob Crittenden wrote: > Erinn Looney-Triggs wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 12/02/2013 10:18 AM, Rob Crittenden wrote: >>> Erinn Looney-Triggs wrote: >>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>> >>>> On 12/02/2013 08:03 AM, Rob Crittenden wrote: >>>>> Erinn Looney-Triggs wrote: >>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>>> >>>>>> On 12/02/2013 07:40 AM, Rob Crittenden wrote: >>>>>>> Erinn Looney-Triggs wrote: >>>>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>>>>> >>>>>>>> On 11/28/2013 03:50 PM, Erinn Looney-Triggs wrote: >>>>>>>>> In the process of prepping a replication host for >>>>>>>>> changing over the CA I had to use certmonger to >>>>>>>>> generate another certificate on my secondary IPA >>>>>>>>> server. Unfortunately it seems to fail every single >>>>>>>>> time. Here is what I am running and here is what I am >>>>>>>>> getting: >>>>>>>>> >>>>>>>>> ipa-getcert request -k private/ipa2.abaqis.com.key -f >>>>>>>>> certs/ipa2.abaqis.com.crt -g 2048 >>>>>>>>> >>>>>>>>> The request appears to work, however when checking the >>>>>>>>> list I receive the following: >>>>>>>>> >>>>>>>>> ipa-getcert list -r Number of certificates and >>>>>>>>> requests being tracked: 9. Request ID '20131128202128': >>>>>>>>> status: CA_UNREACHABLE ca-error: Server failed request, >>>>>>>>> will retry: 4301 (RPC failed at server. Certificate >>>>>>>>> operation cannot be completed: FAILURE (Authentication >>>>>>>>> Error)). stuck: yes key pair storage: >>>>>>>>> type=FILE,location='/etc/pki/tls/private/ipa2.abaqis.com.key' >>>>>>>>> >>>>>>>>> >>>> >>>>>>>>> >> certificate: >>>>>>>>> type=FILE,location='/etc/pki/tls/certs/ipa2.abaqis.com.crt' >>>>>>>>> >>>>>>>>> >>>> >>>>>>>>> >> CA: IPA issuer: subject: expires: unknown pre-save command: >>>>>>>>> post-save command: track: yes auto-renew: yes >>>>>>>>> >>>>>>>>> Fine, I check the http logs and get about the same: >>>>>>>>> [Thu Nov 28 22:03:06 2013] [error] ipa: ERROR: >>>>>>>>> ipaserver.plugins.dogtag.ra.request_certificate(): >>>>>>>>> FAILURE (Authentication Error) >>>>>>>>> >>>>>>>>> Now as I understand it ipa-getcert is going to >>>>>>>>> theserver listed in /etc/ipa/default.conf, which in >>>>>>>>> this case is ipa2.abaqis.com (the request is coming >>>>>>>>> from the same host). The host principle in >>>>>>>>> /etc/krb5.keytab is used for authentication. >>>>>>>>> >>>>>>>>> I have tested against the primary ipa server and >>>>>>>>> everything works as it should. However, any requests >>>>>>>>> going against ipa2 for certificates are failing. >>>>>>>>> >>>>>>>>> At this point I am stuck, so any suggestions are >>>>>>>>> welcome. >>>>>>>>> >>>>>>>>> -Erinn >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> Replying to myself here, and narrowing this down a bit >>>>>>>> further this seems to be a straight auth problem against >>>>>>>> my secondary ipa server. All command work against the >>>>>>>> primary, all certificate commands against the secondary >>>>>>>> fail. >>>>>>>> >>>>>>>> It appears to be confined to dogtag (other commands like >>>>>>>> ipa user-show work), but how exactly dogtag handles auth >>>>>>>> I am not clear on. It appears as though mod_auth_kerb >>>>>>>> handles most things and that is definitely working. >>>>>>>> However any access against dogtag components is failing, >>>>>>>> so dogtag must/should/may be handling auth internally in >>>>>>>> a way that is failing. >>>>>>>> >>>>>>>> Anyway, suggestions are still welcome, >>>>>>> >>>>>>> Run this on the replica and see if it is being tracked by >>>>>>> certmonger >>>>>>> >>>>>>> # getcert list -d /etc/httpd/alias -n ipaCert >>>>>>> >>>>>>> If not, see if the a cert with the nickname ipaCert is in >>>>>>> /etc/httpd/alias: >>>>>>> >>>>>>> # certutil -L -d /etc/httpd/alias -n ipaCert >>>>>>> >>>>>>> If so, see if you have the key: >>>>>>> >>>>>>> # certutil -K -d /etc/httpd/alias -n ipaCert -f >>>>>>> /etc/httpd/alias/pwdfile.txt >>>>>>> >>>>>>> This is the RA agent certificate that IPA uses to >>>>>>> authenticate to dogtag. If it doesn't exist, or is expired, >>>>>>> or is the wrong one, then authentication will fail. >>>>>>> >>>>>>> The cert is shared amongst all the IPA masters, so if it >>>>>>> is working on one master then fixing the replica should be >>>>>>> straightforward assuming it already has the key. >>>>>>> >>>>>>> rob >>>>>> >>>>>> getcert list -d /etc/httpd/alias -n ipaCert Number of >>>>>> certificates and requests being tracked: 9. Request ID >>>>>> '20130221171049': status: MONITORING stuck: no key pair >>>>>> storage: >>>>>> type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS >>>>>> >>>>>> >>>> >>>>>> >> Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' >>>>>> certificate: >>>>>> type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS >>>>>> >>>>>> >>>> >>>>>> >> Certificate DB' >>>>>> CA: dogtag-ipa-retrieve-agent-submit issuer: CN=Certificate >>>>>> Authority,O=ABAQIS.COM subject: CN=IPA RA,O=ABAQIS.COM >>>>>> expires: 2013-12-10 03:23:26 UTC eku: >>>>>> id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save >>>>>> command: /usr/lib64/ipa/certmonger/restart_httpd track: yes >>>>>> auto-renew: yes >>>>>> >>>>>> All the components appear to be there, the certificate is >>>>>> valid until the 10th as you can see about. The other two >>>>>> commands worked fine as well and everything appears to me to >>>>>> be valid. >>>>>> >>>>>> However, I am still getting the auth errors, and I note in >>>>>> the log, what I assume to be the first ipa server attempting >>>>>> to connect and getting auth errors as well. >>>>> >>>>> Ok, I'm a little unclear on something. Can any of your IPA >>>>> masters communicate with dogtag? I thought that one master >>>>> could and one couldn't. >>>>> >>>>> A simple way to find out is: >>>>> >>>>> # ipa cert-show 1 >>>>> >>>>> This shows some random cert. If you get cert output then >>>>> things are working. If not the logs will probably confirm the >>>>> auth failure. >>>>> >>>>> Next step is to run this on each master: >>>>> >>>>> # certutil -L -d /etc/httpd/alias -n ipaCert | grep Serial >>>>> >>>>> The serial numbers should be the same. I wonder if you'll find >>>>> the to be different. >>>>> >>>>> The serial number should match this value: >>>>> >>>>> # ldapsearch -x -h localhost -p 7389 -b >>>>> uid=ipara,ou=People,o=ipaca description >>>>> >>>>> The second integer in description is the serial number. >>>>> >>>>> rob >>>> >>>> Yep that is correct, on one instance I can communicate on the >>>> other I can't. Let's call them primary and secondary, the primary >>>> was the original install from whence all the others came. >>>> >>>> ipa cert-show 1 on primary works, fails on secondary. >>>> >>>> Running certutil -L -d /etc/httpd/alias -n ipaCert | grep Serial >>>> on primary renders this: >>>> >>>> Serial Number: 136 (0x88) Serial Number: 92 (0x5c) >>>> >>>> Running against secondary gives only this: Serial Number: 92 >>>> (0x5c) >>>> >>>> So it looks like that is probably the cause of all this mess, >>>> though how the primary got two certs? I dunno. >>>> >>>> Finally running the ldap query on both hosts confirms that 136 is >>>> the serial for the cert in question, so it appears that this >>>> somehow got messed up on the secondary. >>>> >>>> Sooo, with all that known (and thank you for the help, I figured >>>> it was something like this but reading the dogtag docs was taking >>>> me a good long while to suss out the issue), how does one fix >>>> it? >>> >>> NSS uses a database to store its certificates so it's possible >>> (and legal) to have multiple certs for the same private key. NSS >>> picks the best one (e.g. the one that's valid). >>> >>> So what you need to do on the primary is: >>> >>> # certutil -L -d /etc/httpd/alias -n ipaCert -a > /tmp/ra.crt >>> >>> Edit that file. there will be two certs in BEGIN/END blocks. If >>> memory serves the last one is the one you want, so remove the >>> first. You can double-check this after updating the file with: >>> >>> # openssl x509 -text -in /tmp/ra.crt >>> >>> It should have only the cert with the latest serial #. >>> >>> Now add it to your cert database: >>> >>> # certutil -A -n ipaCert -d /etc/httpd/alias -t u,u,u -a -i >>> /tmp/ra.crt # service httpd restart >>> >>> Things should work now. >>> >>> rob >>> >> >> Rob, >> Thanks so much for the help. It was the first certificate but other >> than that you were spot on, we can't all be perfect ;). That fixed the >> issue and I am now able to do cert operations on both hosts. >> >> Any idea how this situation could have come about? > > The way it is supposed to work is this: > > certmonger on primary should be tracking ipaCert and handled renewal. > This involves renewing the cert, stuffing it into /etc/httpd/alias, > updating an entry in the dogtag CA server and then stuffing the cert > into the IPA LDAP database under cn=ca_renewal,cn=ipa,cn=etc,$SUFFIX. > > certmonger on secondary should also be tracking ipaCert but it instead > watches the cn=ca_renewal for an updated cert and if one appears, it > will update it locally. > > So either the cert never got stuffed into cn=ca_renewal or secondary > isn't tracking the cert, or something I haven't thought of. > > rob Hmm ok, well I can confirm that the ipaCert value is correct and the latest certificate. certmonger on the primary did another renewal last night, which of course landed me in the same place on the secondary, so I manually imported again. I will look into certmonger and it's config on the secondary, as it doesn't seem to be pulling down the most recent cert from LDAP. -Erinn From isaev at fintech.ru Wed Dec 4 09:59:57 2013 From: isaev at fintech.ru (=?koi8-r?B?6dPBxdcg98nUwczJyiDhzsHUz8zYxdfJ3g==?=) Date: Wed, 4 Dec 2013 09:59:57 +0000 Subject: [Freeipa-users] How to disable user automatically when he becomes locked Message-ID: <69303615BE133645963548DD4A3BFCB3BDB81E@E2K7.fintech.ru> Dear Freeipa users and developers, We need to alter the default behavior of the IdM server in the situation when user exceeds the limit of incorrect password login attempts. By default the user is getting locked in this case, but we need to disable him fully. How can we manage this situation? Thank you Vitaly Isaev Software engineer Information security department Fintech JSC, Moscow, Russia -------------- next part -------------- An HTML attachment was scrubbed... URL: From natxo.asenjo at gmail.com Wed Dec 4 10:44:04 2013 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Wed, 4 Dec 2013 11:44:04 +0100 Subject: [Freeipa-users] How to disable user automatically when he becomes locked In-Reply-To: <69303615BE133645963548DD4A3BFCB3BDB81E@E2K7.fintech.ru> References: <69303615BE133645963548DD4A3BFCB3BDB81E@E2K7.fintech.ru> Message-ID: On Wed, Dec 4, 2013 at 10:59 AM, ????? ??????? ??????????? wrote: > Dear Freeipa users and developers, > > > > We need to alter the default behavior of the IdM server in the situation > when user exceeds the limit of incorrect password login attempts. > > By default the user is getting locked in this case, but we need to disable > him fully. As in, delete the user? Because locking the account is disabling it unless I misunderstand it. I cannot log in, my cron jobs will fail, I cannot use any ldap/kerberos service because my account is disabled. What do you need exactly? Or maybe you refer to the fact that the lock is temporary (standard 600 seconds, after which you may try logging in again? In that case, change that in the password policies (in the web interface, policy tab, then password policy, then open the global_policy, then edit the lockout duration field and update it. -- Groet, Natxo From natxo.asenjo at gmail.com Wed Dec 4 10:53:58 2013 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Wed, 4 Dec 2013 11:53:58 +0100 Subject: [Freeipa-users] How to disable user automatically when he becomes locked In-Reply-To: References: <69303615BE133645963548DD4A3BFCB3BDB81E@E2K7.fintech.ru> Message-ID: On Wed, Dec 4, 2013 at 11:44 AM, Natxo Asenjo wrote: > On Wed, Dec 4, 2013 at 10:59 AM, ????? ??????? ??????????? > wrote: >> Dear Freeipa users and developers, >> >> >> >> We need to alter the default behavior of the IdM server in the situation >> when user exceeds the limit of incorrect password login attempts. >> >> By default the user is getting locked in this case, but we need to disable >> him fully. > > As in, delete the user? Because locking the account is disabling it > unless I misunderstand it. I cannot log in, my cron jobs will fail, I > cannot use any ldap/kerberos service because my account is disabled. > > What do you need exactly? Or maybe you refer to the fact that the lock > is temporary (standard 600 seconds, after which you may try logging in > again? In that case, change that in the password policies (in the web > interface, policy tab, then password policy, then open the > global_policy, then edit the lockout duration field and update it. for completeness, the same in the cli as an admin user: To get the values: $ ipa pwpolicy-show Group: global_policy Max lifetime (days): 90 Min lifetime (hours): 1 History size: 0 Character classes: 0 Min length: 8 Max failures: 6 Failure reset interval: 60 Lockout duration: 600 To change a value: $ ipa pwpolicy-mod global_policy --lockouttime=INT (where INT is the number of seconds you want the lock to be implemented, set it to a huge number, like 946080000 in practice 30 ( 3600 secs * 24 hours * 365 days * 30 years ) years is like a life sentence ;-) - the accounts). From mkosek at redhat.com Wed Dec 4 11:05:19 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 04 Dec 2013 12:05:19 +0100 Subject: [Freeipa-users] How to disable user automatically when he becomes locked In-Reply-To: References: <69303615BE133645963548DD4A3BFCB3BDB81E@E2K7.fintech.ru> Message-ID: <529F0C6F.6060405@redhat.com> On 12/04/2013 11:53 AM, Natxo Asenjo wrote: > On Wed, Dec 4, 2013 at 11:44 AM, Natxo Asenjo wrote: >> On Wed, Dec 4, 2013 at 10:59 AM, ????? ??????? ??????????? >> wrote: >>> Dear Freeipa users and developers, >>> >>> >>> >>> We need to alter the default behavior of the IdM server in the situation >>> when user exceeds the limit of incorrect password login attempts. >>> >>> By default the user is getting locked in this case, but we need to disable >>> him fully. >> >> As in, delete the user? Because locking the account is disabling it >> unless I misunderstand it. I cannot log in, my cron jobs will fail, I >> cannot use any ldap/kerberos service because my account is disabled. >> >> What do you need exactly? Or maybe you refer to the fact that the lock >> is temporary (standard 600 seconds, after which you may try logging in >> again? In that case, change that in the password policies (in the web >> interface, policy tab, then password policy, then open the >> global_policy, then edit the lockout duration field and update it. > > for completeness, the same in the cli as an admin user: > > To get the values: > $ ipa pwpolicy-show > Group: global_policy > Max lifetime (days): 90 > Min lifetime (hours): 1 > History size: 0 > Character classes: 0 > Min length: 8 > Max failures: 6 > Failure reset interval: 60 > Lockout duration: 600 > > To change a value: > $ ipa pwpolicy-mod global_policy --lockouttime=INT > > (where INT is the number of seconds you want the lock to be > implemented, set it to a huge number, like 946080000 in practice 30 ( > 3600 secs * 24 hours * 365 days * 30 years ) years is like a life > sentence ;-) - the accounts). > Right, though I am not sure if it would not hit Kerberos limitation for too large timestamps. Alternatively, you can set the Lockout Duration to 0, this should lock out the account permanently after the number of tries was breached. Note that there is a related bug fix in FreeIPA 3.2.0: https://fedorahosted.org/freeipa/ticket/3433 Martin From natxo.asenjo at gmail.com Wed Dec 4 11:10:37 2013 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Wed, 4 Dec 2013 12:10:37 +0100 Subject: [Freeipa-users] How to disable user automatically when he becomes locked In-Reply-To: <529F0C6F.6060405@redhat.com> References: <69303615BE133645963548DD4A3BFCB3BDB81E@E2K7.fintech.ru> <529F0C6F.6060405@redhat.com> Message-ID: On Wed, Dec 4, 2013 at 12:05 PM, Martin Kosek wrote: > On 12/04/2013 11:53 AM, Natxo Asenjo wrote: >> On Wed, Dec 4, 2013 at 11:44 AM, Natxo Asenjo wrote: >>> On Wed, Dec 4, 2013 at 10:59 AM, ????? ??????? ??????????? >>> wrote: >> To change a value: >> $ ipa pwpolicy-mod global_policy --lockouttime=INT >> >> (where INT is the number of seconds you want the lock to be >> implemented, set it to a huge number, like 946080000 in practice 30 ( >> 3600 secs * 24 hours * 365 days * 30 years ) years is like a life >> sentence ;-) - the accounts). >> > > Right, though I am not sure if it would not hit Kerberos limitation for too > large timestamps. > > Alternatively, you can set the Lockout Duration to 0, this should lock out the > account permanently after the number of tries was breached. cool, is that documented? I could not find it in ipa help pwpolicy-mod From mkosek at redhat.com Wed Dec 4 11:53:20 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 04 Dec 2013 12:53:20 +0100 Subject: [Freeipa-users] How to disable user automatically when he becomes locked In-Reply-To: References: <69303615BE133645963548DD4A3BFCB3BDB81E@E2K7.fintech.ru> <529F0C6F.6060405@redhat.com> Message-ID: <529F17B0.4010100@redhat.com> On 12/04/2013 12:10 PM, Natxo Asenjo wrote: > On Wed, Dec 4, 2013 at 12:05 PM, Martin Kosek wrote: >> On 12/04/2013 11:53 AM, Natxo Asenjo wrote: >>> On Wed, Dec 4, 2013 at 11:44 AM, Natxo Asenjo wrote: >>>> On Wed, Dec 4, 2013 at 10:59 AM, ????? ??????? ??????????? >>>> wrote: >>> To change a value: >>> $ ipa pwpolicy-mod global_policy --lockouttime=INT >>> >>> (where INT is the number of seconds you want the lock to be >>> implemented, set it to a huge number, like 946080000 in practice 30 ( >>> 3600 secs * 24 hours * 365 days * 30 years ) years is like a life >>> sentence ;-) - the accounts). >>> >> >> Right, though I am not sure if it would not hit Kerberos limitation for too >> large timestamps. >> >> Alternatively, you can set the Lockout Duration to 0, this should lock out the >> account permanently after the number of tries was breached. > > cool, is that documented? I could not find it in ipa help pwpolicy-mod That's a good question. I did not find any trace of it so I filed a ticket to document it: https://fedorahosted.org/freeipa/ticket/4065 Martin From isaev at fintech.ru Wed Dec 4 11:43:02 2013 From: isaev at fintech.ru (=?utf-8?B?0JjRgdCw0LXQsiDQktC40YLQsNC70LjQuSDQkNC90LDRgtC+0LvRjNC10LI=?= =?utf-8?B?0LjRhw==?=) Date: Wed, 4 Dec 2013 11:43:02 +0000 Subject: [Freeipa-users] How to disable user automatically when he becomes locked In-Reply-To: <529F0C6F.6060405@redhat.com> References: <69303615BE133645963548DD4A3BFCB3BDB81E@E2K7.fintech.ru> <529F0C6F.6060405@redhat.com> Message-ID: <69303615BE133645963548DD4A3BFCB3BDB839@E2K7.fintech.ru> Thank you for your responses! In terms of IdM "lock" state and "disable" state are different: when user becomes locked after several failed login attempts, he is still enabled. The locked state is not shown neither in "ipa user-show" or "ipa user-find --all" commands output, nor in Web GUI... Locked user is brought up to life with "ipa user-unlock" command, but not with "ipa user-enable" command. So the lockout duration set to 0 could be a deal for us (we are using v. 3.0.0). But can we receive a notification in the case of lockout event? How can we check if the user is locked? Can we see this event in any IdM log? Thanks a lot, ??????? ????? ???????-??????????? ?????? ?????????? ? ????????? ???? ??????????? ?????????????? ???????????? ??? ???????? -----Original Message----- From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Martin Kosek Sent: Wednesday, December 04, 2013 3:07 PM To: Natxo Asenjo; freeipa-users at redhat.com Subject: Re: [Freeipa-users] How to disable user automatically when he becomes locked On 12/04/2013 11:53 AM, Natxo Asenjo wrote: > On Wed, Dec 4, 2013 at 11:44 AM, Natxo Asenjo wrote: >> On Wed, Dec 4, 2013 at 10:59 AM, ????? ??????? ??????????? >> wrote: >>> Dear Freeipa users and developers, >>> >>> >>> >>> We need to alter the default behavior of the IdM server in the >>> situation when user exceeds the limit of incorrect password login attempts. >>> >>> By default the user is getting locked in this case, but we need to >>> disable him fully. >> >> As in, delete the user? Because locking the account is disabling it >> unless I misunderstand it. I cannot log in, my cron jobs will fail, I >> cannot use any ldap/kerberos service because my account is disabled. >> >> What do you need exactly? Or maybe you refer to the fact that the >> lock is temporary (standard 600 seconds, after which you may try >> logging in again? In that case, change that in the password policies >> (in the web interface, policy tab, then password policy, then open >> the global_policy, then edit the lockout duration field and update it. > > for completeness, the same in the cli as an admin user: > > To get the values: > $ ipa pwpolicy-show > Group: global_policy > Max lifetime (days): 90 > Min lifetime (hours): 1 > History size: 0 > Character classes: 0 > Min length: 8 > Max failures: 6 > Failure reset interval: 60 > Lockout duration: 600 > > To change a value: > $ ipa pwpolicy-mod global_policy --lockouttime=INT > > (where INT is the number of seconds you want the lock to be > implemented, set it to a huge number, like 946080000 in practice 30 ( > 3600 secs * 24 hours * 365 days * 30 years ) years is like a life > sentence ;-) - the accounts). > Right, though I am not sure if it would not hit Kerberos limitation for too large timestamps. Alternatively, you can set the Lockout Duration to 0, this should lock out the account permanently after the number of tries was breached. Note that there is a related bug fix in FreeIPA 3.2.0: https://fedorahosted.org/freeipa/ticket/3433 Martin _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users From rcritten at redhat.com Wed Dec 4 15:15:49 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 04 Dec 2013 10:15:49 -0500 Subject: [Freeipa-users] CA expiration and renewal In-Reply-To: <529E29AA.90300@gmail.com> References: <52842407.80504@gmail.com> <52939269.1070405@redhat.com> <52963840.8090703@gmail.com> <529643F3.9020907@redhat.com> <529E29AA.90300@gmail.com> Message-ID: <529F4725.8000304@redhat.com> Erinn Looney-Triggs wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 11/27/2013 11:11 AM, Rob Crittenden wrote: >> Erinn Looney-Triggs wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>> >>> >>> >>> On 11/25/2013 11:09 AM, Rob Crittenden wrote: >>>> Erinn Looney-Triggs wrote: >>>>> Folks just wanted to touch base again before the American >>>>> holiday season starts. My CA, which is subordinate to AD CS >>>>> will be expiring on December 9th, I submitted a bug, y'all >>>>> drew up docs etc for a plan (thanks). Now I just wanted to >>>>> see how it was going and if need be what manual steps I will >>>>> need to take to renew the certificate. >>>>> >>>>> Thanks again for the great work, >>>> >>>> We're working on an a set of tools to make this easier. For >>>> now I've appended some manual instructions onto a page still >>>> in progress. >>>> >>>> http://www.freeipa.org/page/Howto/CA_Certificate_Renewal#Manual_Procedure_in_IPA_3.0 >>>> >>>> >>>> >>>> >>>> >>>> > Some parts may be still be a little rough or hard to understand. >>>> Let me know if you have any problems or corrections. >>>> >>>> rob >>> >>> Rob, >>> >>> Thanks for the instructions, a few questions. >>> >>> What sort of interruption in service could this create? >> >> Services will be restarted during this process including your >> LDAP, Apache and CA instances. Downtime should be relatively short, >> no more than a few minutes combined. >> >>> Can you expand on this section a little bit: Replace the value of >>> ca.signing.cert in /etc/pki-ca/CS.cfg. This is the base64 value >>> of the certificate. You can obtain this by removing the BEGIN/END >>> blocks from ipa.crt and compressing it into a single line. >> >> A PEM cert looks like: >> >> -----BEGIN CERTIFICATE----- >> MIIB/zCCAWigAwIBAgICA+gwDQYJKoZIhvcNAQEFBQAwKTEnMCUGA1UEAxMeSVBB >> IFRlc3QgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTEwMDIyMzIyMzMxNVoXDTIw >> MDIyMzIyMzMxNVowKTEnMCUGA1UEAxMeSVBBIFRlc3QgQ2VydGlmaWNhdGUgQXV0 >> aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+G6ultyLaXqzBlypA >> DnOsinkMTlZZssTFQh/QUMi1F1fcn8QUlmsl9a+l6w6hfZm7P8z3sVwsjLQcDWA4 >> KxOh+LmIsNL4OKx4wKF1q/pSt1PATRU5Pgu2+3wlwJO0H7cl4QfavoOLwmxAZf/l >> ZNIy/5czvSWFWj7EJj16ty9BeQIDAQABozYwNDARBglghkgBhvhCAQEEBAMCAAcw >> DwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAsQwDQYJKoZIhvcNAQEFBQAD >> gYEAl0gIshwNkhyfNe1XMLswPeOgH5YN1BUuKXzbv1fuSIkArjwLODr4cOdXzQvt >> yaiX6Z+pRC/sK8MgLhPxV2X9QVQdzKfLkVGIdboCt1j3EXxSUCZeIuSKouitkWYe >> eSH9DQkYDp/oKgANLWnY7CNorPz6xQktp1pB0DGohV1BeTA= -----END >> CERTIFICATE----- >> >> You need to drop the BEGIN/END blocks then combine all the lines >> into a single line, so you have a unified base64 blog. It will look >> like: >> >> ca.signing.cert=MII...B0DGohV1BeTA= >> >> I was afraid wrapping woudl destroy my demonstration so I used >> ellipses instead. >> >>> Thanks and happy Thanksgiving, >> >> You're welcome. You too. >> >> rob >> > > Ok I have done the steps as outlined. One small suggestion and one > question came up. > > Suggestion: for the ldapmodify command indicate that a ctl-d is > necessary to end input. Most folks will know this, but some may not. > > For the client section you have me copy the newly signed subordnate CA > certificate into /etc/ipa/ca.crt. However, on my hosts that was > actually a copy of the AD CS certificate, not the subordinate > certificate. In the case of a subordinate installation do you want the > root or the subordinate CA? It would seem that the root would be > broader, but I just want to make sure. > The IPA CA cert should be sufficient. rob From mkosek at redhat.com Wed Dec 4 15:28:06 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 04 Dec 2013 16:28:06 +0100 Subject: [Freeipa-users] How to disable user automatically when he becomes locked In-Reply-To: <69303615BE133645963548DD4A3BFCB3BDB839@E2K7.fintech.ru> References: <69303615BE133645963548DD4A3BFCB3BDB81E@E2K7.fintech.ru> <529F0C6F.6060405@redhat.com> <69303615BE133645963548DD4A3BFCB3BDB839@E2K7.fintech.ru> Message-ID: <529F4A06.90208@redhat.com> On 12/04/2013 12:43 PM, ????? ??????? ??????????? wrote: > Thank you for your responses! > > In terms of IdM "lock" state and "disable" state are different: when user becomes locked after several failed login attempts, he is still enabled. The locked state is not shown neither in "ipa user-show" or "ipa user-find --all" commands output, nor in Web GUI... > Locked user is brought up to life with "ipa user-unlock" command, but not with "ipa user-enable" command. This is correct. > So the lockout duration set to 0 could be a deal for us (we are using v. 3.0.0). But can we receive a notification in the case of lockout event? How can we check if the user is locked? Can we see this event in any IdM log? "Lockout status" is not an attribute on it's own (as compared to user-lock/user-unlock locking). It is rather a state of a KDC which based on the password policy (ipa pwpolicy-show) and user attributes krbloginfailedcount and krblastpwdchange can decide if the user is locked out or not. We have prepared a "user-status" command to at least help gathering this all this information from all KDCs. See help in "ipa help user-status". If you want to search for all disabled users, could you base it on an ldapsearch like the following one? ldapsearch -h $IPA_SERVER -Y GSSAPI -b 'cn=users,cn=accounts,dc=example,dc=com' '(krbLoginFailedCount=3)' It could give you the list of users who already hit the lockout count leading to the permanent lockout. Note that there are RFEs already filed that improve the situation in this area: https://fedorahosted.org/freeipa/ticket/3700 : [RFE] Failed login replication https://fedorahosted.org/freeipa/ticket/2792 : [RFE] Allow quering user lock status and unlocking user in UI Martin > > > Thanks a lot, > > ??????? ????? > ???????-??????????? > ?????? ?????????? ? ????????? ???? > ??????????? ?????????????? ???????????? > ??? ???????? > > > -----Original Message----- > From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Martin Kosek > Sent: Wednesday, December 04, 2013 3:07 PM > To: Natxo Asenjo; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] How to disable user automatically when he becomes locked > > On 12/04/2013 11:53 AM, Natxo Asenjo wrote: >> On Wed, Dec 4, 2013 at 11:44 AM, Natxo Asenjo wrote: >>> On Wed, Dec 4, 2013 at 10:59 AM, ????? ??????? ??????????? >>> wrote: >>>> Dear Freeipa users and developers, >>>> >>>> >>>> >>>> We need to alter the default behavior of the IdM server in the >>>> situation when user exceeds the limit of incorrect password login attempts. >>>> >>>> By default the user is getting locked in this case, but we need to >>>> disable him fully. >>> >>> As in, delete the user? Because locking the account is disabling it >>> unless I misunderstand it. I cannot log in, my cron jobs will fail, I >>> cannot use any ldap/kerberos service because my account is disabled. >>> >>> What do you need exactly? Or maybe you refer to the fact that the >>> lock is temporary (standard 600 seconds, after which you may try >>> logging in again? In that case, change that in the password policies >>> (in the web interface, policy tab, then password policy, then open >>> the global_policy, then edit the lockout duration field and update it. >> >> for completeness, the same in the cli as an admin user: >> >> To get the values: >> $ ipa pwpolicy-show >> Group: global_policy >> Max lifetime (days): 90 >> Min lifetime (hours): 1 >> History size: 0 >> Character classes: 0 >> Min length: 8 >> Max failures: 6 >> Failure reset interval: 60 >> Lockout duration: 600 >> >> To change a value: >> $ ipa pwpolicy-mod global_policy --lockouttime=INT >> >> (where INT is the number of seconds you want the lock to be >> implemented, set it to a huge number, like 946080000 in practice 30 ( >> 3600 secs * 24 hours * 365 days * 30 years ) years is like a life >> sentence ;-) - the accounts). >> > > Right, though I am not sure if it would not hit Kerberos limitation for too large timestamps. > > Alternatively, you can set the Lockout Duration to 0, this should lock out the account permanently after the number of tries was breached. Note that there is a related bug fix in FreeIPA 3.2.0: > https://fedorahosted.org/freeipa/ticket/3433 > > Martin > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > From mitkany at gmail.com Wed Dec 4 15:52:58 2013 From: mitkany at gmail.com (Dimitar Georgievski) Date: Wed, 4 Dec 2013 10:52:58 -0500 Subject: [Freeipa-users] Install FreeIPA on CentOS 6.4 Message-ID: hi, I plan to install FreeIPA on CentOS 6.4. Initially FreeIPA should provide secure authentication and authorization for system (shell) accounts (users and groups) by integration with SSSD. There is already a DNS server and FreeIPA should integrate with it. I am looking for some guidelines for installing FreeIPA on CentOS 6.x, possibly from packages, and selectively enabling FreeIPA components. If these questions sound trivial that's because I am new to FreeIPA :-) Thanks, Dimitar -------------- next part -------------- An HTML attachment was scrubbed... URL: From chorn at fluxcoil.net Wed Dec 4 16:01:55 2013 From: chorn at fluxcoil.net (Christian Horn) Date: Wed, 4 Dec 2013 17:01:55 +0100 Subject: [Freeipa-users] Install FreeIPA on CentOS 6.4 In-Reply-To: References: Message-ID: <20131204160155.GA8603@fluxcoil.net> Hi, On Wed, Dec 04, 2013 at 10:52:58AM -0500, Dimitar Georgievski wrote: > > I plan to install FreeIPA on CentOS 6.4. Initially FreeIPA should provide > secure authentication and authorization for system (shell) accounts (users > and groups) by integration with SSSD. > There is already a DNS server and FreeIPA should integrate with it. > > I am looking for some guidelines for installing FreeIPA on CentOS 6.x, > possibly from packages, and selectively enabling FreeIPA components. If > these questions sound trivial that's because I am new to FreeIPA :-) The "Identity Management Guide" from the RHEL product documentation might be a good first step. It is linked from here: https://access.redhat.com/site/documentation/Red_Hat_Enterprise_Linux/ Christian From dpal at redhat.com Wed Dec 4 16:04:47 2013 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 04 Dec 2013 11:04:47 -0500 Subject: [Freeipa-users] Install FreeIPA on CentOS 6.4 In-Reply-To: References: Message-ID: <529F529F.3000503@redhat.com> On 12/04/2013 10:52 AM, Dimitar Georgievski wrote: > hi, > > I plan to install FreeIPA on CentOS 6.4. Initially FreeIPA should > provide secure authentication and authorization for system (shell) > accounts (users and groups) by integration with SSSD. > There is already a DNS server and FreeIPA should integrate with it. > > I am looking for some guidelines for installing FreeIPA on CentOS > 6.x, possibly from packages, and selectively enabling FreeIPA > components. If these questions sound trivial that's because I am new > to FreeIPA :-) > > Thanks, > > Dimitar > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users Here some good references: http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/index.html https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html-single/Identity_Management_Guide/index.html -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From erinn.looneytriggs at gmail.com Wed Dec 4 17:58:20 2013 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Wed, 04 Dec 2013 09:58:20 -0800 Subject: [Freeipa-users] CA expiration and renewal In-Reply-To: <529F4725.8000304@redhat.com> References: <52842407.80504@gmail.com> <52939269.1070405@redhat.com> <52963840.8090703@gmail.com> <529643F3.9020907@redhat.com> <529E29AA.90300@gmail.com> <529F4725.8000304@redhat.com> Message-ID: <529F6D3C.3070609@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/04/2013 07:15 AM, Rob Crittenden wrote: > Erinn Looney-Triggs wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> On 11/27/2013 11:11 AM, Rob Crittenden wrote: >>> Erinn Looney-Triggs wrote: >>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>> >>>> >>>> >>>> On 11/25/2013 11:09 AM, Rob Crittenden wrote: >>>>> Erinn Looney-Triggs wrote: >>>>>> Folks just wanted to touch base again before the >>>>>> American holiday season starts. My CA, which is >>>>>> subordinate to AD CS will be expiring on December 9th, I >>>>>> submitted a bug, y'all drew up docs etc for a plan >>>>>> (thanks). Now I just wanted to see how it was going and >>>>>> if need be what manual steps I will need to take to renew >>>>>> the certificate. >>>>>> >>>>>> Thanks again for the great work, >>>>> >>>>> We're working on an a set of tools to make this easier. >>>>> For now I've appended some manual instructions onto a page >>>>> still in progress. >>>>> >>>>> http://www.freeipa.org/page/Howto/CA_Certificate_Renewal#Manual_Procedure_in_IPA_3.0 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >> >>>>> Some parts may be still be a little rough or hard to understand. >>>>> Let me know if you have any problems or corrections. >>>>> >>>>> rob >>>> >>>> Rob, >>>> >>>> Thanks for the instructions, a few questions. >>>> >>>> What sort of interruption in service could this create? >>> >>> Services will be restarted during this process including your >>> LDAP, Apache and CA instances. Downtime should be relatively >>> short, no more than a few minutes combined. >>> >>>> Can you expand on this section a little bit: Replace the >>>> value of ca.signing.cert in /etc/pki-ca/CS.cfg. This is the >>>> base64 value of the certificate. You can obtain this by >>>> removing the BEGIN/END blocks from ipa.crt and compressing it >>>> into a single line. >>> >>> A PEM cert looks like: >>> >>> -----BEGIN CERTIFICATE----- >>> MIIB/zCCAWigAwIBAgICA+gwDQYJKoZIhvcNAQEFBQAwKTEnMCUGA1UEAxMeSVBB >>> >>> IFRlc3QgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTEwMDIyMzIyMzMxNVoXDTIw >>> MDIyMzIyMzMxNVowKTEnMCUGA1UEAxMeSVBBIFRlc3QgQ2VydGlmaWNhdGUgQXV0 >>> >>> aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+G6ultyLaXqzBlypA >>> DnOsinkMTlZZssTFQh/QUMi1F1fcn8QUlmsl9a+l6w6hfZm7P8z3sVwsjLQcDWA4 >>> >>> KxOh+LmIsNL4OKx4wKF1q/pSt1PATRU5Pgu2+3wlwJO0H7cl4QfavoOLwmxAZf/l >>> ZNIy/5czvSWFWj7EJj16ty9BeQIDAQABozYwNDARBglghkgBhvhCAQEEBAMCAAcw >>> >>> DwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAsQwDQYJKoZIhvcNAQEFBQAD >>> gYEAl0gIshwNkhyfNe1XMLswPeOgH5YN1BUuKXzbv1fuSIkArjwLODr4cOdXzQvt >>> >>> yaiX6Z+pRC/sK8MgLhPxV2X9QVQdzKfLkVGIdboCt1j3EXxSUCZeIuSKouitkWYe >>> eSH9DQkYDp/oKgANLWnY7CNorPz6xQktp1pB0DGohV1BeTA= -----END >>> CERTIFICATE----- >>> >>> You need to drop the BEGIN/END blocks then combine all the >>> lines into a single line, so you have a unified base64 blog. It >>> will look like: >>> >>> ca.signing.cert=MII...B0DGohV1BeTA= >>> >>> I was afraid wrapping woudl destroy my demonstration so I used >>> ellipses instead. >>> >>>> Thanks and happy Thanksgiving, >>> >>> You're welcome. You too. >>> >>> rob >>> >> >> Ok I have done the steps as outlined. One small suggestion and >> one question came up. >> >> Suggestion: for the ldapmodify command indicate that a ctl-d is >> necessary to end input. Most folks will know this, but some may >> not. >> >> For the client section you have me copy the newly signed >> subordnate CA certificate into /etc/ipa/ca.crt. However, on my >> hosts that was actually a copy of the AD CS certificate, not the >> subordinate certificate. In the case of a subordinate >> installation do you want the root or the subordinate CA? It would >> seem that the root would be broader, but I just want to make >> sure. >> > > The IPA CA cert should be sufficient. > > rob > Thanks, and just for an update, the switch over was made, certmonger is happily updating certs now on all hosts and everything just appears to be working thus far, minus the replication of the agent certificate which I am still looking into. Thanks for the help, - -Erinn -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) iQEcBAEBAgAGBQJSn20zAAoJENetaK3v/E7P4S4IAKkc3eLYtcMJrABCBQclg0OT IVrsAOY/ZlCt6BZBD+Vg/qSNk+/jSOIa4UDmWp9r9ixpguebl3CfcvNx128pSdlJ NbUBha9ijKmMYFbwwAYzR++BJA7i0zCyZ/VNykGU9o6N35On5rpqCM0OoSvy4kOc Op+pWUZ9jIJ0ljgC0R8bt+UrdnuP+uoNqmBsO3DuhPlc4kGEVRvfPUidN21HUmaj Vh+TPmlqZtaR5GPM515nYcABAvlGuyO8RZyMJUSfW45b+Nt3sIEji0mlaVyS6qyA 0TY1u8mH+f1VgRxeUgmTWW4QnnHSgwPL5VHUpgeWm5wyEOBeMp5vLE1kAVCcTGc= =VitN -----END PGP SIGNATURE----- From sprokhorov at intech-global.com Thu Dec 5 08:02:12 2013 From: sprokhorov at intech-global.com (=?UTF-8?B?0J/RgNC+0YXQvtGA0L7QsiDQodC10YDQs9C10Lk=?=) Date: Thu, 05 Dec 2013 12:02:12 +0400 Subject: [Freeipa-users] Problems with FreeIPA-client configuration on OpenSUSE 12.2 In-Reply-To: <529DB390.8030104@intech-global.com> References: <529DB390.8030104@intech-global.com> Message-ID: <52A03304.1080904@intech-global.com> Hello community, I have problems with FreeIPA-client configuration on OpenSUSE 12.2, and I think I can't fix it without your help. I have following errors in my /var/log/messages, when I try login in by freeipa account: ############################################################ Dec 2 18:21:24 linux-l3wy sshd[12481]: Invalid user admin from 192.168.0.159 Dec 2 18:21:24 linux-l3wy sshd[12481]: input_userauth_request: invalid user admin [preauth] Dec 2 18:21:24 linux-l3wy sssd_be: No worthy mechs found Dec 2 18:21:24 linux-l3wy sshd[12481]: Postponed keyboard-interactive for invalid user admin from 192.168.0.159 port 38175 ssh2 [preauth] Dec 2 18:21:41 linux-l3wy sshd[12484]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.0.159 user=admin Dec 2 18:21:41 linux-l3wy sshd[12484]: pam_sss(sshd:auth): received for user admin: 10 (User not known to the underlying authentication module) Dec 2 18:21:41 linux-l3wy sshd[12481]: error: PAM: User not known to the underlying authentication module for illegal user admin from 192.168.0.159 Dec 2 18:21:41 linux-l3wy sshd[12481]: Failed keyboard-interactive/pam for invalid user admin from 192.168.0.159 port 38175 ssh2 Dec 2 18:21:41 linux-l3wy sshd[12481]: Postponed keyboard-interactive for invalid user admin from 192.168.0.159 port 38175 ssh2 [preauth] Dec 2 18:21:50 linux-l3wy sshd[12481]: Connection closed by 192.168.0.159 [preauth] ############################################################ About client configuration: My installed packages sssd-ldap-1.11.2-110.6.x86_64 sssd-ipa-1.11.2-110.6.x86_64 sssd-1.11.2-110.6.x86_64 sssd-tools-1.11.2-110.6.x86_64 sssd-krb5-common-1.11.2-110.6.x86_64 *//etc/sss/**/d/sssd.conf:/* ############################################################ [domain/example.com] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = example.com id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = client1.example.com chpass_provider = ipa ipa_server = _srv_, ipa.example.com ldap_tls_cacert = /etc/ipa/ca.crt [sssd] services = nss, pam, ssh config_file_version = 2 domains = example.com debug_level=9 ############################################################ /etc/krb5.conf: ############################################################ [libdefaults] default_realm = EXAMPLE.COM #dns_lookup_realm = false #dns_lookup_kdc = false dns_lookup_realm = true dns_lookup_kdc = true rdns = false ticket_lifetime = 24h forwardable = yes #allow_weak_crypto = true [realms] example.COM = { pkinit_anchors = FILE:/etc/ipa/ca.crt #kdc = ipa.example.com:88 #admin_server = ipa.example.com:749 #default_domain = example.com } [domain_realm] .example.com = example.COM example.com = example.COM [logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log ############################################################ P.S. Thank you for your time, and sorry for my English. -- Sergey Prokhorov System Engineer e-mail:sprokhorov at intech-global.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Thu Dec 5 08:49:11 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 5 Dec 2013 09:49:11 +0100 Subject: [Freeipa-users] Problems with FreeIPA-client configuration on OpenSUSE 12.2 In-Reply-To: <52A03304.1080904@intech-global.com> References: <529DB390.8030104@intech-global.com> <52A03304.1080904@intech-global.com> Message-ID: <20131205084911.GB5496@hendrix.redhat.com> On Thu, Dec 05, 2013 at 12:02:12PM +0400, ???????? ?????? wrote: > > Hello community, I have problems with FreeIPA-client configuration > on OpenSUSE 12.2, and I think I can't fix it without your help. I > have following errors in my /var/log/messages, when I try login in > by freeipa account: > > ############################################################ > Dec 2 18:21:24 linux-l3wy sshd[12481]: Invalid user admin from > 192.168.0.159 > Dec 2 18:21:24 linux-l3wy sshd[12481]: input_userauth_request: > invalid user admin [preauth] > Dec 2 18:21:24 linux-l3wy sssd_be: No worthy mechs found > Dec 2 18:21:24 linux-l3wy sshd[12481]: Postponed > keyboard-interactive for invalid user admin from 192.168.0.159 port > 38175 ssh2 [preauth] > Dec 2 18:21:41 linux-l3wy sshd[12484]: pam_sss(sshd:auth): > authentication failure; logname= uid=0 euid=0 tty=ssh ruser= > rhost=192.168.0.159 user=admin > Dec 2 18:21:41 linux-l3wy sshd[12484]: pam_sss(sshd:auth): received > for user admin: 10 (User not known to the underlying authentication > module) > Dec 2 18:21:41 linux-l3wy sshd[12481]: error: PAM: User not known > to the underlying authentication module for illegal user admin from > 192.168.0.159 > Dec 2 18:21:41 linux-l3wy sshd[12481]: Failed > keyboard-interactive/pam for invalid user admin from 192.168.0.159 > port 38175 ssh2 > Dec 2 18:21:41 linux-l3wy sshd[12481]: Postponed > keyboard-interactive for invalid user admin from 192.168.0.159 port > 38175 ssh2 [preauth] > Dec 2 18:21:50 linux-l3wy sshd[12481]: Connection closed by > 192.168.0.159 [preauth] > ############################################################ Hi Sergey, are you able to run "getent passwd admin" from the command line? SSH is complaining that admin is not a known account. I suspect that for whatevet reason the sssd is unable to connect to the IPA servers. getent passwd admin or id admin don't return anything, you should put debug_level=6 into the [domain] section, restart sssd and then check out /var/log/sssd/sssd_example.com log. From mkosek at redhat.com Thu Dec 5 09:35:43 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 05 Dec 2013 10:35:43 +0100 Subject: [Freeipa-users] CA expiration and renewal In-Reply-To: <529F6D3C.3070609@gmail.com> References: <52842407.80504@gmail.com> <52939269.1070405@redhat.com> <52963840.8090703@gmail.com> <529643F3.9020907@redhat.com> <529E29AA.90300@gmail.com> <529F4725.8000304@redhat.com> <529F6D3C.3070609@gmail.com> Message-ID: <52A048EF.5000708@redhat.com> On 12/04/2013 06:58 PM, Erinn Looney-Triggs wrote: > On 12/04/2013 07:15 AM, Rob Crittenden wrote: >> Erinn Looney-Triggs wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>> >>> On 11/27/2013 11:11 AM, Rob Crittenden wrote: >>>> Erinn Looney-Triggs wrote: >>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> >>>>> >>>>> >>>>> On 11/25/2013 11:09 AM, Rob Crittenden wrote: >>>>>> Erinn Looney-Triggs wrote: >>>>>>> Folks just wanted to touch base again before the American >>>>>>> holiday season starts. My CA, which is subordinate to AD CS >>>>>>> will be expiring on December 9th, I submitted a bug, y'all >>>>>>> drew up docs etc for a plan (thanks). Now I just wanted to see >>>>>>> how it was going and if need be what manual steps I will need >>>>>>> to take to renew the certificate. >>>>>>> >>>>>>> Thanks again for the great work, >>>>>> >>>>>> We're working on an a set of tools to make this easier. For now >>>>>> I've appended some manual instructions onto a page still in >>>>>> progress. >>>>>> >>>>>> http://www.freeipa.org/page/Howto/CA_Certificate_Renewal#Manual_Procedure_in_IPA_3.0 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>> >>>>>> > >>>>>> Some parts may be still be a little rough or hard to understand. >>>>>> Let me know if you have any problems or corrections. >>>>>> >>>>>> rob >>>>> >>>>> Rob, >>>>> >>>>> Thanks for the instructions, a few questions. >>>>> >>>>> What sort of interruption in service could this create? >>>> >>>> Services will be restarted during this process including your LDAP, >>>> Apache and CA instances. Downtime should be relatively short, no >>>> more than a few minutes combined. >>>> >>>>> Can you expand on this section a little bit: Replace the value of >>>>> ca.signing.cert in /etc/pki-ca/CS.cfg. This is the base64 value of >>>>> the certificate. You can obtain this by removing the BEGIN/END >>>>> blocks from ipa.crt and compressing it into a single line. >>>> >>>> A PEM cert looks like: >>>> >>>> -----BEGIN CERTIFICATE----- >>>> MIIB/zCCAWigAwIBAgICA+gwDQYJKoZIhvcNAQEFBQAwKTEnMCUGA1UEAxMeSVBB >>>> >>>> > IFRlc3QgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTEwMDIyMzIyMzMxNVoXDTIw >>>> MDIyMzIyMzMxNVowKTEnMCUGA1UEAxMeSVBBIFRlc3QgQ2VydGlmaWNhdGUgQXV0 >>>> >>>> > aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+G6ultyLaXqzBlypA >>>> DnOsinkMTlZZssTFQh/QUMi1F1fcn8QUlmsl9a+l6w6hfZm7P8z3sVwsjLQcDWA4 >>>> >>>> > KxOh+LmIsNL4OKx4wKF1q/pSt1PATRU5Pgu2+3wlwJO0H7cl4QfavoOLwmxAZf/l >>>> ZNIy/5czvSWFWj7EJj16ty9BeQIDAQABozYwNDARBglghkgBhvhCAQEEBAMCAAcw >>>> >>>> > DwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAsQwDQYJKoZIhvcNAQEFBQAD >>>> gYEAl0gIshwNkhyfNe1XMLswPeOgH5YN1BUuKXzbv1fuSIkArjwLODr4cOdXzQvt >>>> >>>> > yaiX6Z+pRC/sK8MgLhPxV2X9QVQdzKfLkVGIdboCt1j3EXxSUCZeIuSKouitkWYe >>>> eSH9DQkYDp/oKgANLWnY7CNorPz6xQktp1pB0DGohV1BeTA= -----END >>>> CERTIFICATE----- >>>> >>>> You need to drop the BEGIN/END blocks then combine all the lines >>>> into a single line, so you have a unified base64 blog. It will look >>>> like: >>>> >>>> ca.signing.cert=MII...B0DGohV1BeTA= >>>> >>>> I was afraid wrapping woudl destroy my demonstration so I used >>>> ellipses instead. >>>> >>>>> Thanks and happy Thanksgiving, >>>> >>>> You're welcome. You too. >>>> >>>> rob >>>> >>> >>> Ok I have done the steps as outlined. One small suggestion and one >>> question came up. >>> >>> Suggestion: for the ldapmodify command indicate that a ctl-d is >>> necessary to end input. Most folks will know this, but some may not. >>> >>> For the client section you have me copy the newly signed subordnate CA >>> certificate into /etc/ipa/ca.crt. However, on my hosts that was >>> actually a copy of the AD CS certificate, not the subordinate >>> certificate. In the case of a subordinate installation do you want the >>> root or the subordinate CA? It would seem that the root would be >>> broader, but I just want to make sure. >>> > >> The IPA CA cert should be sufficient. > >> rob > > > Thanks, and just for an update, the switch over was made, certmonger is > happily updating certs now on all hosts and everything just appears to be > working thus far, minus the replication of the agent certificate which I > am still looking into. > > Thanks for the help, > > -Erinn Great, I am glad to hear that. Note that we were investigating renewing certificates and clones and found out an issue in Python readline that prevented a renewal of the IPA agent certificate: https://fedorahosted.org/freeipa/ticket/4064 Could this be the reason of your issues? Did you saw a crash of certmonger during the renewal? It was found out to be happening due to the aforementioned bug. Thanks, Martin From mitkany at gmail.com Thu Dec 5 17:03:19 2013 From: mitkany at gmail.com (Dimitar Georgievski) Date: Thu, 5 Dec 2013 12:03:19 -0500 Subject: [Freeipa-users] Install FreeIPA on CentOS 6.4 In-Reply-To: <529F529F.3000503@redhat.com> References: <529F529F.3000503@redhat.com> Message-ID: Christian/Dmitri, Thank you both for the links. I found that I could follow the RedHat's guide for installing and configuring FreeIPA on CentOS 6.4. My biggest worry was the installation part which has a long list of dependencies. Thanks Dimitar On Wed, Dec 4, 2013 at 11:04 AM, Dmitri Pal wrote: > On 12/04/2013 10:52 AM, Dimitar Georgievski wrote: > > hi, > > I plan to install FreeIPA on CentOS 6.4. Initially FreeIPA should > provide secure authentication and authorization for system (shell) accounts > (users and groups) by integration with SSSD. > There is already a DNS server and FreeIPA should integrate with it. > > I am looking for some guidelines for installing FreeIPA on CentOS 6.x, > possibly from packages, and selectively enabling FreeIPA components. If > these questions sound trivial that's because I am new to FreeIPA :-) > > Thanks, > > Dimitar > > > _______________________________________________ > Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users > > Here some good references: > http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/index.html > > https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html-single/Identity_Management_Guide/index.html > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs?www.redhat.com/carveoutcosts/ > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mmercier at gmail.com Thu Dec 5 18:47:24 2013 From: mmercier at gmail.com (Michael Mercier) Date: Thu, 5 Dec 2013 13:47:24 -0500 Subject: [Freeipa-users] ipa: ERROR: Certificate operation cannot be completed: Failure decoding Certificate Signing Request Message-ID: Hello, A few details to begin: The IPA system consists of 3 servers running on fully patched CentOS 6.5 (updated Monday night). DNS is integrated with the IPA system. ipa-*-3.0.0-37. mod_nss-1.0.8-19 openssl-1.0.1e-16 The system was upgraded from 2.2 Yesterday, I revoked a certificate for an old system and signed a certificate for the replacement system (same hostname) with no apparent issues. Today, I am attempting to sign a certificate for a new system and I am seeing the following error from the command line (with debug=True in /etc/ipa/default.conf): ipa cert-request principal: ipa: ERROR: Certificate operation cannot be completed: Failure decoding Certificate Signing Request The GUI responds with: IPA ERROR 4310 Certificate operation cannot be completed: Failure decoding Certificate Signing Request I have no issues running 'openssl req -text -noout -verify -in ? on the request file. I did do a 'yum update? on the system today (after experiencing the errors), with openssl and mod_nss being upgraded on all servers. All systems were rebooted after the upgrade and the problem still exists. I did see an older thread with a similar issue, but that seemed to involve updating expired certs and Rob did not seem to be able to reproduce the error. Maybe I am experiencing the same problem? Anyone have an idea where a good place to start looking is? Thanks, Mike From erinn.looneytriggs at gmail.com Thu Dec 5 20:03:53 2013 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Thu, 05 Dec 2013 12:03:53 -0800 Subject: [Freeipa-users] CA expiration and renewal In-Reply-To: <52A048EF.5000708@redhat.com> References: <52842407.80504@gmail.com> <52939269.1070405@redhat.com> <52963840.8090703@gmail.com> <529643F3.9020907@redhat.com> <529E29AA.90300@gmail.com> <529F4725.8000304@redhat.com> <529F6D3C.3070609@gmail.com> <52A048EF.5000708@redhat.com> Message-ID: <52A0DC29.9070704@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/05/2013 01:35 AM, Martin Kosek wrote: > On 12/04/2013 06:58 PM, Erinn Looney-Triggs wrote: >> On 12/04/2013 07:15 AM, Rob Crittenden wrote: >>> Erinn Looney-Triggs wrote: >>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>> >>>> On 11/27/2013 11:11 AM, Rob Crittenden wrote: >>>>> Erinn Looney-Triggs wrote: >>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>>> >>>>>> >>>>>> >>>>>> On 11/25/2013 11:09 AM, Rob Crittenden wrote: >>>>>>> Erinn Looney-Triggs wrote: >>>>>>>> Folks just wanted to touch base again before the >>>>>>>> American holiday season starts. My CA, which is >>>>>>>> subordinate to AD CS will be expiring on December >>>>>>>> 9th, I submitted a bug, y'all drew up docs etc for a >>>>>>>> plan (thanks). Now I just wanted to see how it was >>>>>>>> going and if need be what manual steps I will need to >>>>>>>> take to renew the certificate. >>>>>>>> >>>>>>>> Thanks again for the great work, >>>>>>> >>>>>>> We're working on an a set of tools to make this easier. >>>>>>> For now I've appended some manual instructions onto a >>>>>>> page still in progress. >>>>>>> >>>>>>> http://www.freeipa.org/page/Howto/CA_Certificate_Renewal#Manual_Procedure_in_IPA_3.0 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>> >>>>>>> >> >>>>>>> > >>>>>>> Some parts may be still be a little rough or hard to understand. >>>>>>> Let me know if you have any problems or corrections. >>>>>>> >>>>>>> rob >>>>>> >>>>>> Rob, >>>>>> >>>>>> Thanks for the instructions, a few questions. >>>>>> >>>>>> What sort of interruption in service could this create? >>>>> >>>>> Services will be restarted during this process including >>>>> your LDAP, Apache and CA instances. Downtime should be >>>>> relatively short, no more than a few minutes combined. >>>>> >>>>>> Can you expand on this section a little bit: Replace the >>>>>> value of ca.signing.cert in /etc/pki-ca/CS.cfg. This is >>>>>> the base64 value of the certificate. You can obtain this >>>>>> by removing the BEGIN/END blocks from ipa.crt and >>>>>> compressing it into a single line. >>>>> >>>>> A PEM cert looks like: >>>>> >>>>> -----BEGIN CERTIFICATE----- >>>>> MIIB/zCCAWigAwIBAgICA+gwDQYJKoZIhvcNAQEFBQAwKTEnMCUGA1UEAxMeSVBB >>>>> >>>>> >> >>>>> IFRlc3QgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTEwMDIyMzIyMzMxNVoXDTIw >>>>> MDIyMzIyMzMxNVowKTEnMCUGA1UEAxMeSVBBIFRlc3QgQ2VydGlmaWNhdGUgQXV0 >>>>> >>>>> >> >>>>> aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+G6ultyLaXqzBlypA >>>>> DnOsinkMTlZZssTFQh/QUMi1F1fcn8QUlmsl9a+l6w6hfZm7P8z3sVwsjLQcDWA4 >>>>> >>>>> >> >>>>> KxOh+LmIsNL4OKx4wKF1q/pSt1PATRU5Pgu2+3wlwJO0H7cl4QfavoOLwmxAZf/l >>>>> ZNIy/5czvSWFWj7EJj16ty9BeQIDAQABozYwNDARBglghkgBhvhCAQEEBAMCAAcw >>>>> >>>>> >> >>>>> DwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAsQwDQYJKoZIhvcNAQEFBQAD >>>>> gYEAl0gIshwNkhyfNe1XMLswPeOgH5YN1BUuKXzbv1fuSIkArjwLODr4cOdXzQvt >>>>> >>>>> >> >>>>> yaiX6Z+pRC/sK8MgLhPxV2X9QVQdzKfLkVGIdboCt1j3EXxSUCZeIuSKouitkWYe >>>>> eSH9DQkYDp/oKgANLWnY7CNorPz6xQktp1pB0DGohV1BeTA= -----END >>>>> CERTIFICATE----- >>>>> >>>>> You need to drop the BEGIN/END blocks then combine all the >>>>> lines into a single line, so you have a unified base64 >>>>> blog. It will look like: >>>>> >>>>> ca.signing.cert=MII...B0DGohV1BeTA= >>>>> >>>>> I was afraid wrapping woudl destroy my demonstration so I >>>>> used ellipses instead. >>>>> >>>>>> Thanks and happy Thanksgiving, >>>>> >>>>> You're welcome. You too. >>>>> >>>>> rob >>>>> >>>> >>>> Ok I have done the steps as outlined. One small suggestion >>>> and one question came up. >>>> >>>> Suggestion: for the ldapmodify command indicate that a ctl-d >>>> is necessary to end input. Most folks will know this, but >>>> some may not. >>>> >>>> For the client section you have me copy the newly signed >>>> subordnate CA certificate into /etc/ipa/ca.crt. However, on >>>> my hosts that was actually a copy of the AD CS certificate, >>>> not the subordinate certificate. In the case of a subordinate >>>> installation do you want the root or the subordinate CA? It >>>> would seem that the root would be broader, but I just want to >>>> make sure. >>>> >> >>> The IPA CA cert should be sufficient. >> >>> rob >> >> >> Thanks, and just for an update, the switch over was made, >> certmonger is happily updating certs now on all hosts and >> everything just appears to be working thus far, minus the >> replication of the agent certificate which I am still looking >> into. >> >> Thanks for the help, >> >> -Erinn > > Great, I am glad to hear that. Note that we were investigating > renewing certificates and clones and found out an issue in Python > readline that prevented a renewal of the IPA agent certificate: > > https://fedorahosted.org/freeipa/ticket/4064 > > Could this be the reason of your issues? Did you saw a crash of > certmonger during the renewal? It was found out to be happening due > to the aforementioned bug. > > Thanks, Martin > That seems very likely, however abrt didn't catch anything, and there doesn't appear to be any tmp file wreckage left anywhere. I can't find anything in the logs indicating failure, all signs point to success for the renewal: Dec 3 20:47:25 ipa2 certmonger: Certificate named "Server-Cert" in token "NSS Certificate DB" in database "/etc/dirsrv/slapd-ABAQIS-COM" will not be valid afte r 20131210032326. Dec 3 20:47:25 ipa2 certmonger: Certificate named "Server-Cert" in token "NSS Certificate DB" in database "/etc/dirsrv/slapd-PKI-IPA" will not be valid after 20131210032326. Dec 3 20:47:25 ipa2 certmonger: Certificate named "auditSigningCert cert-pki-ca" in token "NSS Certificate DB" in database "/var/lib/pki-ca/alias" will not be valid after 20131210032326. Dec 3 20:47:25 ipa2 certmonger: Certificate named "ocspSigningCert cert-pki-ca" in token "NSS Certificate DB" in database "/var/lib/pki-ca/alias" will not be valid after 20131210032326. Dec 3 20:47:25 ipa2 certmonger: Certificate named "subsystemCert cert-pki-ca" in token "NSS Certificate DB" in database "/var/lib/pki-ca/alias" will not be valid after 20131210032326. Dec 3 20:47:25 ipa2 certmonger: Certificate named "ipaCert" in token "NSS Certificate DB" in database "/etc/httpd/alias" will not be valid after 20131210032326. Dec 3 20:47:26 ipa2 certmonger: Certificate named "Server-Cert" in token "NSS Certificate DB" in database "/etc/dirsrv/slapd-PKI-IPA" issued by CA and saved. Dec 3 20:47:26 ipa2 certmonger: Certificate named "Server-Cert" in token "NSS Certificate DB" in database "/etc/dirsrv/slapd-ABAQIS-COM" issued by CA and saved. Dec 3 20:47:26 ipa2 python: Updating certificate for auditSigningCert cert-pki-ca Dec 3 20:47:26 ipa2 python: Updating certificate for ocspSigningCert cert-pki-ca Dec 3 20:47:27 ipa2 python: Updating certificate for subsystemCert cert-pki-ca Dec 3 20:47:27 ipa2 python: Updating certificate for ipaCert Dec 3 20:47:28 ipa2 python: certmonger stopping pki-cad Dec 3 20:48:04 ipa2 python: certmonger started pki-cad, nickname 'auditSigningCert cert-pki-ca' Dec 3 20:48:04 ipa2 certmonger: Certificate named "auditSigningCert cert-pki-ca" in token "NSS Certificate DB" in database "/var/lib/pki-ca/alias" issued by CA and saved. Dec 3 20:48:08 ipa2 python: certmonger stopping pki-cad Dec 3 20:48:44 ipa2 python: certmonger started pki-cad, nickname 'ocspSigningCert cert-pki-ca' Dec 3 20:48:44 ipa2 certmonger: Certificate named "ocspSigningCert cert-pki-ca" in token "NSS Certificate DB" in database "/var/lib/pki-ca/alias" issued by CA and saved. Dec 3 20:48:48 ipa2 python: certmonger stopping pki-cad Dec 3 20:49:24 ipa2 python: certmonger started pki-cad, nickname 'subsystemCert cert-pki-ca' Dec 3 20:49:24 ipa2 certmonger: Certificate named "subsystemCert cert-pki-ca" in token "NSS Certificate DB" in database "/var/lib/pki-ca/alias" issued by CA and saved. Dec 3 20:49:27 ipa2 python: certmonger restarted httpd Dec 3 20:49:29 ipa2 certmonger: Certificate named "ipaCert" in token "NSS Certificate DB" in database "/etc/httpd/alias" issued by CA and saved. Sorry for the word wrap there. Certmonger continued to run throughout it appears. The dates line up correctly, certmonger on the primary renewed on the 3rd and the secondary failed to get the new certificate which led straight back to the same place. - -Erinn -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) iQEcBAEBAgAGBQJSoNwkAAoJENetaK3v/E7PdnIIAKZGdafIitLcx8umSt3DSVDy nP+0o1XgFIoSjYmr2n3c0fuxrlGf8NC4IgNSMYJ8HOHiMo45Gd+sqWvBEio//jys dQcUEmCB3Amyc28SARnijMAzUucaScCFITctXf3IkeTjBniKx4OzDyLJflpi1xkU FTF8l9bovOWDWABjQEOXZuLUX5+wYXgmcpK0xophW1A0pr/WX6XdNPv4v7lHaqrV knw/uMXj36XJOFXWbRob3/54LiZJT9fsRIxKz2A11ZPIAo1GARlAb0FoVznoy8cm EiIuCeRZfMgaaxNJ2GZlY+NTqTmY2yITuuWNh2LERSqHf1MRvd1PwnTAQvdRmh8= =nO8F -----END PGP SIGNATURE----- From rcritten at redhat.com Thu Dec 5 20:18:59 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 05 Dec 2013 15:18:59 -0500 Subject: [Freeipa-users] CA expiration and renewal In-Reply-To: <52A0DC29.9070704@gmail.com> References: <52842407.80504@gmail.com> <52939269.1070405@redhat.com> <52963840.8090703@gmail.com> <529643F3.9020907@redhat.com> <529E29AA.90300@gmail.com> <529F4725.8000304@redhat.com> <529F6D3C.3070609@gmail.com> <52A048EF.5000708@redhat.com> <52A0DC29.9070704@gmail.com> Message-ID: <52A0DFB3.80301@redhat.com> Erinn Looney-Triggs wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 12/05/2013 01:35 AM, Martin Kosek wrote: >> On 12/04/2013 06:58 PM, Erinn Looney-Triggs wrote: >>> On 12/04/2013 07:15 AM, Rob Crittenden wrote: >>>> Erinn Looney-Triggs wrote: >>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> >>>>> On 11/27/2013 11:11 AM, Rob Crittenden wrote: >>>>>> Erinn Looney-Triggs wrote: >>>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 11/25/2013 11:09 AM, Rob Crittenden wrote: >>>>>>>> Erinn Looney-Triggs wrote: >>>>>>>>> Folks just wanted to touch base again before the >>>>>>>>> American holiday season starts. My CA, which is >>>>>>>>> subordinate to AD CS will be expiring on December >>>>>>>>> 9th, I submitted a bug, y'all drew up docs etc for a >>>>>>>>> plan (thanks). Now I just wanted to see how it was >>>>>>>>> going and if need be what manual steps I will need to >>>>>>>>> take to renew the certificate. >>>>>>>>> >>>>>>>>> Thanks again for the great work, >>>>>>>> >>>>>>>> We're working on an a set of tools to make this easier. >>>>>>>> For now I've appended some manual instructions onto a >>>>>>>> page still in progress. >>>>>>>> >>>>>>>> http://www.freeipa.org/page/Howto/CA_Certificate_Renewal#Manual_Procedure_in_IPA_3.0 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>> >>>>>>>> >>> >>>>>>>> >> >>>>>>>> > Some parts may be still be a little rough or hard to understand. >>>>>>>> Let me know if you have any problems or corrections. >>>>>>>> >>>>>>>> rob >>>>>>> >>>>>>> Rob, >>>>>>> >>>>>>> Thanks for the instructions, a few questions. >>>>>>> >>>>>>> What sort of interruption in service could this create? >>>>>> >>>>>> Services will be restarted during this process including >>>>>> your LDAP, Apache and CA instances. Downtime should be >>>>>> relatively short, no more than a few minutes combined. >>>>>> >>>>>>> Can you expand on this section a little bit: Replace the >>>>>>> value of ca.signing.cert in /etc/pki-ca/CS.cfg. This is >>>>>>> the base64 value of the certificate. You can obtain this >>>>>>> by removing the BEGIN/END blocks from ipa.crt and >>>>>>> compressing it into a single line. >>>>>> >>>>>> A PEM cert looks like: >>>>>> >>>>>> -----BEGIN CERTIFICATE----- >>>>>> MIIB/zCCAWigAwIBAgICA+gwDQYJKoZIhvcNAQEFBQAwKTEnMCUGA1UEAxMeSVBB >>>>>> >>>>>> >>> >>>>>> > IFRlc3QgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTEwMDIyMzIyMzMxNVoXDTIw >>>>>> MDIyMzIyMzMxNVowKTEnMCUGA1UEAxMeSVBBIFRlc3QgQ2VydGlmaWNhdGUgQXV0 >>>>>> >>>>>> >>> >>>>>> > aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+G6ultyLaXqzBlypA >>>>>> DnOsinkMTlZZssTFQh/QUMi1F1fcn8QUlmsl9a+l6w6hfZm7P8z3sVwsjLQcDWA4 >>>>>> >>>>>> >>> >>>>>> > KxOh+LmIsNL4OKx4wKF1q/pSt1PATRU5Pgu2+3wlwJO0H7cl4QfavoOLwmxAZf/l >>>>>> ZNIy/5czvSWFWj7EJj16ty9BeQIDAQABozYwNDARBglghkgBhvhCAQEEBAMCAAcw >>>>>> >>>>>> >>> >>>>>> > DwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAsQwDQYJKoZIhvcNAQEFBQAD >>>>>> gYEAl0gIshwNkhyfNe1XMLswPeOgH5YN1BUuKXzbv1fuSIkArjwLODr4cOdXzQvt >>>>>> >>>>>> >>> >>>>>> > yaiX6Z+pRC/sK8MgLhPxV2X9QVQdzKfLkVGIdboCt1j3EXxSUCZeIuSKouitkWYe >>>>>> eSH9DQkYDp/oKgANLWnY7CNorPz6xQktp1pB0DGohV1BeTA= -----END >>>>>> CERTIFICATE----- >>>>>> >>>>>> You need to drop the BEGIN/END blocks then combine all the >>>>>> lines into a single line, so you have a unified base64 >>>>>> blog. It will look like: >>>>>> >>>>>> ca.signing.cert=MII...B0DGohV1BeTA= >>>>>> >>>>>> I was afraid wrapping woudl destroy my demonstration so I >>>>>> used ellipses instead. >>>>>> >>>>>>> Thanks and happy Thanksgiving, >>>>>> >>>>>> You're welcome. You too. >>>>>> >>>>>> rob >>>>>> >>>>> >>>>> Ok I have done the steps as outlined. One small suggestion >>>>> and one question came up. >>>>> >>>>> Suggestion: for the ldapmodify command indicate that a ctl-d >>>>> is necessary to end input. Most folks will know this, but >>>>> some may not. >>>>> >>>>> For the client section you have me copy the newly signed >>>>> subordnate CA certificate into /etc/ipa/ca.crt. However, on >>>>> my hosts that was actually a copy of the AD CS certificate, >>>>> not the subordinate certificate. In the case of a subordinate >>>>> installation do you want the root or the subordinate CA? It >>>>> would seem that the root would be broader, but I just want to >>>>> make sure. >>>>> >>> >>>> The IPA CA cert should be sufficient. >>> >>>> rob >>> >>> >>> Thanks, and just for an update, the switch over was made, >>> certmonger is happily updating certs now on all hosts and >>> everything just appears to be working thus far, minus the >>> replication of the agent certificate which I am still looking >>> into. >>> >>> Thanks for the help, >>> >>> -Erinn >> >> Great, I am glad to hear that. Note that we were investigating >> renewing certificates and clones and found out an issue in Python >> readline that prevented a renewal of the IPA agent certificate: >> >> https://fedorahosted.org/freeipa/ticket/4064 >> >> Could this be the reason of your issues? Did you saw a crash of >> certmonger during the renewal? It was found out to be happening due >> to the aforementioned bug. >> >> Thanks, Martin >> > > That seems very likely, however abrt didn't catch anything, and there > doesn't appear to be any tmp file wreckage left anywhere. I can't find > anything in the logs indicating failure, all signs point to success > for the renewal: > > > Dec 3 20:47:25 ipa2 certmonger: Certificate named "Server-Cert" in > token "NSS Certificate DB" in database "/etc/dirsrv/slapd-ABAQIS-COM" > will not be valid afte > r 20131210032326. > Dec 3 20:47:25 ipa2 certmonger: Certificate named "Server-Cert" in > token "NSS Certificate DB" in database "/etc/dirsrv/slapd-PKI-IPA" > will not be valid after 20131210032326. > Dec 3 20:47:25 ipa2 certmonger: Certificate named "auditSigningCert > cert-pki-ca" in token "NSS Certificate DB" in database > "/var/lib/pki-ca/alias" will not be valid after 20131210032326. > Dec 3 20:47:25 ipa2 certmonger: Certificate named "ocspSigningCert > cert-pki-ca" in token "NSS Certificate DB" in database > "/var/lib/pki-ca/alias" will not be valid after 20131210032326. > Dec 3 20:47:25 ipa2 certmonger: Certificate named "subsystemCert > cert-pki-ca" in token "NSS Certificate DB" in database > "/var/lib/pki-ca/alias" will not be valid after 20131210032326. > Dec 3 20:47:25 ipa2 certmonger: Certificate named "ipaCert" in token > "NSS Certificate DB" in database "/etc/httpd/alias" will not be valid > after 20131210032326. > Dec 3 20:47:26 ipa2 certmonger: Certificate named "Server-Cert" in > token "NSS Certificate DB" in database "/etc/dirsrv/slapd-PKI-IPA" > issued by CA and saved. > Dec 3 20:47:26 ipa2 certmonger: Certificate named "Server-Cert" in > token "NSS Certificate DB" in database "/etc/dirsrv/slapd-ABAQIS-COM" > issued by CA and saved. > Dec 3 20:47:26 ipa2 python: Updating certificate for auditSigningCert > cert-pki-ca > Dec 3 20:47:26 ipa2 python: Updating certificate for ocspSigningCert > cert-pki-ca > Dec 3 20:47:27 ipa2 python: Updating certificate for subsystemCert > cert-pki-ca > Dec 3 20:47:27 ipa2 python: Updating certificate for ipaCert > Dec 3 20:47:28 ipa2 python: certmonger stopping pki-cad > Dec 3 20:48:04 ipa2 python: certmonger started pki-cad, nickname > 'auditSigningCert cert-pki-ca' > Dec 3 20:48:04 ipa2 certmonger: Certificate named "auditSigningCert > cert-pki-ca" in token "NSS Certificate DB" in database > "/var/lib/pki-ca/alias" issued by CA and saved. > Dec 3 20:48:08 ipa2 python: certmonger stopping pki-cad > Dec 3 20:48:44 ipa2 python: certmonger started pki-cad, nickname > 'ocspSigningCert cert-pki-ca' > Dec 3 20:48:44 ipa2 certmonger: Certificate named "ocspSigningCert > cert-pki-ca" in token "NSS Certificate DB" in database > "/var/lib/pki-ca/alias" issued by CA and saved. > Dec 3 20:48:48 ipa2 python: certmonger stopping pki-cad > Dec 3 20:49:24 ipa2 python: certmonger started pki-cad, nickname > 'subsystemCert cert-pki-ca' > Dec 3 20:49:24 ipa2 certmonger: Certificate named "subsystemCert > cert-pki-ca" in token "NSS Certificate DB" in database > "/var/lib/pki-ca/alias" issued by CA and saved. > Dec 3 20:49:27 ipa2 python: certmonger restarted httpd > Dec 3 20:49:29 ipa2 certmonger: Certificate named "ipaCert" in token > "NSS Certificate DB" in database "/etc/httpd/alias" issued by CA and > saved. > > > Sorry for the word wrap there. Certmonger continued to run throughout > it appears. The dates line up correctly, certmonger on the primary > renewed on the 3rd and the secondary failed to get the new certificate > which led straight back to the same place. But you were able to fix it again, right? I wonder if there are any AVCs around renewal time. rob From rcritten at redhat.com Thu Dec 5 20:20:23 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 05 Dec 2013 15:20:23 -0500 Subject: [Freeipa-users] ipa: ERROR: Certificate operation cannot be completed: Failure decoding Certificate Signing Request In-Reply-To: References: Message-ID: <52A0E007.3050705@redhat.com> Michael Mercier wrote: > Hello, > > A few details to begin: > > The IPA system consists of 3 servers running on fully patched CentOS 6.5 (updated Monday night). DNS is integrated with the IPA system. > > ipa-*-3.0.0-37. > mod_nss-1.0.8-19 > openssl-1.0.1e-16 > > > The system was upgraded from 2.2 > > > > Yesterday, I revoked a certificate for an old system and signed a certificate for the replacement system (same hostname) with no apparent issues. > > Today, I am attempting to sign a certificate for a new system and I am seeing the following error from the command line (with debug=True in /etc/ipa/default.conf): > > ipa cert-request > principal: > > ipa: ERROR: Certificate operation cannot be completed: Failure decoding Certificate Signing Request > > The GUI responds with: > IPA ERROR 4310 > Certificate operation cannot be completed: Failure decoding Certificate Signing Request > > I have no issues running 'openssl req -text -noout -verify -in ? on the request file. > > I did do a 'yum update? on the system today (after experiencing the errors), with openssl and mod_nss being upgraded on all servers. All systems were rebooted after the upgrade and the problem still exists. > > I did see an older thread with a similar issue, but that seemed to involve updating expired certs and Rob did not seem to be able to reproduce the error. Maybe I am experiencing the same problem? > > Anyone have an idea where a good place to start looking is? The Failure decoding is a duplicate error message in a couple of different places. I'd recommend modifying it per the other thread so we can know exactly where it failed and why. rob From dpal at redhat.com Thu Dec 5 20:28:30 2013 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 05 Dec 2013 15:28:30 -0500 Subject: [Freeipa-users] ipa: ERROR: Certificate operation cannot be completed: Failure decoding Certificate Signing Request In-Reply-To: <52A0E007.3050705@redhat.com> References: <52A0E007.3050705@redhat.com> Message-ID: <52A0E1EE.7000901@redhat.com> On 12/05/2013 03:20 PM, Rob Crittenden wrote: > Michael Mercier wrote: >> Hello, >> >> A few details to begin: >> >> The IPA system consists of 3 servers running on fully patched CentOS >> 6.5 (updated Monday night). DNS is integrated with the IPA system. >> >> ipa-*-3.0.0-37. >> mod_nss-1.0.8-19 >> openssl-1.0.1e-16 >> >> >> The system was upgraded from 2.2 >> >> >> >> Yesterday, I revoked a certificate for an old system and signed a >> certificate for the replacement system (same hostname) with no >> apparent issues. >> >> Today, I am attempting to sign a certificate for a new system and I >> am seeing the following error from the command line (with debug=True >> in /etc/ipa/default.conf): >> >> ipa cert-request >> principal: >> >> ipa: ERROR: Certificate operation cannot be completed: Failure >> decoding Certificate Signing Request >> >> The GUI responds with: >> IPA ERROR 4310 >> Certificate operation cannot be completed: Failure decoding >> Certificate Signing Request >> >> I have no issues running 'openssl req -text -noout -verify -in >> ? on the request file. >> >> I did do a 'yum update? on the system today (after experiencing the >> errors), with openssl and mod_nss being upgraded on all servers. All >> systems were rebooted after the upgrade and the problem still exists. >> >> I did see an older thread with a similar issue, but that seemed to >> involve updating expired certs and Rob did not seem to be able to >> reproduce the error. Maybe I am experiencing the same problem? >> >> Anyone have an idea where a good place to start looking is? > > The Failure decoding is a duplicate error message in a couple of > different places. I'd recommend modifying it per the other thread so > we can know exactly where it failed and why. > > rob > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users Rob do we need a ticket for that? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From erinn.looneytriggs at gmail.com Thu Dec 5 20:39:47 2013 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Thu, 05 Dec 2013 12:39:47 -0800 Subject: [Freeipa-users] CA expiration and renewal In-Reply-To: <52A0DFB3.80301@redhat.com> References: <52842407.80504@gmail.com> <52939269.1070405@redhat.com> <52963840.8090703@gmail.com> <529643F3.9020907@redhat.com> <529E29AA.90300@gmail.com> <529F4725.8000304@redhat.com> <529F6D3C.3070609@gmail.com> <52A048EF.5000708@redhat.com> <52A0DC29.9070704@gmail.com> <52A0DFB3.80301@redhat.com> Message-ID: <52A0E493.4010204@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/05/2013 12:18 PM, Rob Crittenden wrote: > Erinn Looney-Triggs wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> On 12/05/2013 01:35 AM, Martin Kosek wrote: >>> On 12/04/2013 06:58 PM, Erinn Looney-Triggs wrote: >>>> On 12/04/2013 07:15 AM, Rob Crittenden wrote: >>>>> Erinn Looney-Triggs wrote: >>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>>> >>>>>> On 11/27/2013 11:11 AM, Rob Crittenden wrote: >>>>>>> Erinn Looney-Triggs wrote: >>>>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 11/25/2013 11:09 AM, Rob Crittenden wrote: >>>>>>>>> Erinn Looney-Triggs wrote: >>>>>>>>>> Folks just wanted to touch base again before the >>>>>>>>>> American holiday season starts. My CA, which is >>>>>>>>>> subordinate to AD CS will be expiring on >>>>>>>>>> December 9th, I submitted a bug, y'all drew up >>>>>>>>>> docs etc for a plan (thanks). Now I just wanted >>>>>>>>>> to see how it was going and if need be what >>>>>>>>>> manual steps I will need to take to renew the >>>>>>>>>> certificate. >>>>>>>>>> >>>>>>>>>> Thanks again for the great work, >>>>>>>>> >>>>>>>>> We're working on an a set of tools to make this >>>>>>>>> easier. For now I've appended some manual >>>>>>>>> instructions onto a page still in progress. >>>>>>>>> >>>>>>>>> http://www.freeipa.org/page/Howto/CA_Certificate_Renewal#Manual_Procedure_in_IPA_3.0 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> >>>>>>>>> >>>> >>>>>>>>> >>> >>>>>>>>> >> >>>>>>>>> Some parts may be still be a little rough or hard to understand. >>>>>>>>> Let me know if you have any problems or >>>>>>>>> corrections. >>>>>>>>> >>>>>>>>> rob >>>>>>>> >>>>>>>> Rob, >>>>>>>> >>>>>>>> Thanks for the instructions, a few questions. >>>>>>>> >>>>>>>> What sort of interruption in service could this >>>>>>>> create? >>>>>>> >>>>>>> Services will be restarted during this process >>>>>>> including your LDAP, Apache and CA instances. Downtime >>>>>>> should be relatively short, no more than a few minutes >>>>>>> combined. >>>>>>> >>>>>>>> Can you expand on this section a little bit: Replace >>>>>>>> the value of ca.signing.cert in /etc/pki-ca/CS.cfg. >>>>>>>> This is the base64 value of the certificate. You can >>>>>>>> obtain this by removing the BEGIN/END blocks from >>>>>>>> ipa.crt and compressing it into a single line. >>>>>>> >>>>>>> A PEM cert looks like: >>>>>>> >>>>>>> -----BEGIN CERTIFICATE----- >>>>>>> MIIB/zCCAWigAwIBAgICA+gwDQYJKoZIhvcNAQEFBQAwKTEnMCUGA1UEAxMeSVBB >>>>>>> >>>>>>> >>>> >>>>>>> >> >>>>>>> IFRlc3QgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTEwMDIyMzIyMzMxNVoXDTIw >>>>>>> MDIyMzIyMzMxNVowKTEnMCUGA1UEAxMeSVBBIFRlc3QgQ2VydGlmaWNhdGUgQXV0 >>>>>>> >>>>>>> >>>> >>>>>>> >> >>>>>>> aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+G6ultyLaXqzBlypA >>>>>>> DnOsinkMTlZZssTFQh/QUMi1F1fcn8QUlmsl9a+l6w6hfZm7P8z3sVwsjLQcDWA4 >>>>>>> >>>>>>> >>>> >>>>>>> >> >>>>>>> KxOh+LmIsNL4OKx4wKF1q/pSt1PATRU5Pgu2+3wlwJO0H7cl4QfavoOLwmxAZf/l >>>>>>> ZNIy/5czvSWFWj7EJj16ty9BeQIDAQABozYwNDARBglghkgBhvhCAQEEBAMCAAcw >>>>>>> >>>>>>> >>>> >>>>>>> >> >>>>>>> DwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAsQwDQYJKoZIhvcNAQEFBQAD >>>>>>> gYEAl0gIshwNkhyfNe1XMLswPeOgH5YN1BUuKXzbv1fuSIkArjwLODr4cOdXzQvt >>>>>>> >>>>>>> >>>> >>>>>>> >> >>>>>>> yaiX6Z+pRC/sK8MgLhPxV2X9QVQdzKfLkVGIdboCt1j3EXxSUCZeIuSKouitkWYe >>>>>>> eSH9DQkYDp/oKgANLWnY7CNorPz6xQktp1pB0DGohV1BeTA= >>>>>>> -----END CERTIFICATE----- >>>>>>> >>>>>>> You need to drop the BEGIN/END blocks then combine all >>>>>>> the lines into a single line, so you have a unified >>>>>>> base64 blog. It will look like: >>>>>>> >>>>>>> ca.signing.cert=MII...B0DGohV1BeTA= >>>>>>> >>>>>>> I was afraid wrapping woudl destroy my demonstration so >>>>>>> I used ellipses instead. >>>>>>> >>>>>>>> Thanks and happy Thanksgiving, >>>>>>> >>>>>>> You're welcome. You too. >>>>>>> >>>>>>> rob >>>>>>> >>>>>> >>>>>> Ok I have done the steps as outlined. One small >>>>>> suggestion and one question came up. >>>>>> >>>>>> Suggestion: for the ldapmodify command indicate that a >>>>>> ctl-d is necessary to end input. Most folks will know >>>>>> this, but some may not. >>>>>> >>>>>> For the client section you have me copy the newly signed >>>>>> subordnate CA certificate into /etc/ipa/ca.crt. However, >>>>>> on my hosts that was actually a copy of the AD CS >>>>>> certificate, not the subordinate certificate. In the case >>>>>> of a subordinate installation do you want the root or the >>>>>> subordinate CA? It would seem that the root would be >>>>>> broader, but I just want to make sure. >>>>>> >>>> >>>>> The IPA CA cert should be sufficient. >>>> >>>>> rob >>>> >>>> >>>> Thanks, and just for an update, the switch over was made, >>>> certmonger is happily updating certs now on all hosts and >>>> everything just appears to be working thus far, minus the >>>> replication of the agent certificate which I am still >>>> looking into. >>>> >>>> Thanks for the help, >>>> >>>> -Erinn >>> >>> Great, I am glad to hear that. Note that we were investigating >>> renewing certificates and clones and found out an issue in >>> Python readline that prevented a renewal of the IPA agent >>> certificate: >>> >>> https://fedorahosted.org/freeipa/ticket/4064 >>> >>> Could this be the reason of your issues? Did you saw a crash >>> of certmonger during the renewal? It was found out to be >>> happening due to the aforementioned bug. >>> >>> Thanks, Martin >>> >> >> That seems very likely, however abrt didn't catch anything, and >> there doesn't appear to be any tmp file wreckage left anywhere. I >> can't find anything in the logs indicating failure, all signs >> point to success for the renewal: >> >> >> Dec 3 20:47:25 ipa2 certmonger: Certificate named "Server-Cert" >> in token "NSS Certificate DB" in database >> "/etc/dirsrv/slapd-ABAQIS-COM" will not be valid afte r >> 20131210032326. Dec 3 20:47:25 ipa2 certmonger: Certificate >> named "Server-Cert" in token "NSS Certificate DB" in database >> "/etc/dirsrv/slapd-PKI-IPA" will not be valid after >> 20131210032326. Dec 3 20:47:25 ipa2 certmonger: Certificate >> named "auditSigningCert cert-pki-ca" in token "NSS Certificate >> DB" in database "/var/lib/pki-ca/alias" will not be valid after >> 20131210032326. Dec 3 20:47:25 ipa2 certmonger: Certificate >> named "ocspSigningCert cert-pki-ca" in token "NSS Certificate DB" >> in database "/var/lib/pki-ca/alias" will not be valid after >> 20131210032326. Dec 3 20:47:25 ipa2 certmonger: Certificate >> named "subsystemCert cert-pki-ca" in token "NSS Certificate DB" >> in database "/var/lib/pki-ca/alias" will not be valid after >> 20131210032326. Dec 3 20:47:25 ipa2 certmonger: Certificate >> named "ipaCert" in token "NSS Certificate DB" in database >> "/etc/httpd/alias" will not be valid after 20131210032326. Dec 3 >> 20:47:26 ipa2 certmonger: Certificate named "Server-Cert" in >> token "NSS Certificate DB" in database >> "/etc/dirsrv/slapd-PKI-IPA" issued by CA and saved. Dec 3 >> 20:47:26 ipa2 certmonger: Certificate named "Server-Cert" in >> token "NSS Certificate DB" in database >> "/etc/dirsrv/slapd-ABAQIS-COM" issued by CA and saved. Dec 3 >> 20:47:26 ipa2 python: Updating certificate for auditSigningCert >> cert-pki-ca Dec 3 20:47:26 ipa2 python: Updating certificate for >> ocspSigningCert cert-pki-ca Dec 3 20:47:27 ipa2 python: Updating >> certificate for subsystemCert cert-pki-ca Dec 3 20:47:27 ipa2 >> python: Updating certificate for ipaCert Dec 3 20:47:28 ipa2 >> python: certmonger stopping pki-cad Dec 3 20:48:04 ipa2 python: >> certmonger started pki-cad, nickname 'auditSigningCert >> cert-pki-ca' Dec 3 20:48:04 ipa2 certmonger: Certificate named >> "auditSigningCert cert-pki-ca" in token "NSS Certificate DB" in >> database "/var/lib/pki-ca/alias" issued by CA and saved. Dec 3 >> 20:48:08 ipa2 python: certmonger stopping pki-cad Dec 3 20:48:44 >> ipa2 python: certmonger started pki-cad, nickname >> 'ocspSigningCert cert-pki-ca' Dec 3 20:48:44 ipa2 certmonger: >> Certificate named "ocspSigningCert cert-pki-ca" in token "NSS >> Certificate DB" in database "/var/lib/pki-ca/alias" issued by CA >> and saved. Dec 3 20:48:48 ipa2 python: certmonger stopping >> pki-cad Dec 3 20:49:24 ipa2 python: certmonger started pki-cad, >> nickname 'subsystemCert cert-pki-ca' Dec 3 20:49:24 ipa2 >> certmonger: Certificate named "subsystemCert cert-pki-ca" in >> token "NSS Certificate DB" in database "/var/lib/pki-ca/alias" >> issued by CA and saved. Dec 3 20:49:27 ipa2 python: certmonger >> restarted httpd Dec 3 20:49:29 ipa2 certmonger: Certificate >> named "ipaCert" in token "NSS Certificate DB" in database >> "/etc/httpd/alias" issued by CA and saved. >> >> >> Sorry for the word wrap there. Certmonger continued to run >> throughout it appears. The dates line up correctly, certmonger on >> the primary renewed on the 3rd and the secondary failed to get >> the new certificate which led straight back to the same place. > > But you were able to fix it again, right? > > I wonder if there are any AVCs around renewal time. > > rob > Yep manually moving over and importing worked just fine, as is everything is good for the next two years until the whole cycle repeats. But I reckon this would be a very good thing to get sussed out. Yeah there are AVC messages: node=ipa2.abaqis.com type=PATH msg=audit(1386103646.841:451293): item=0 name="/var/run/certmonger/tmp-xETTca/ccache" inode=944 dev=fd:03 mode=0100600 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:var_run_t:s0 nametype=NORMAL node=ipa2.abaqis.com type=CWD msg=audit(1386103646.841:451293): cwd="/" node=ipa2.abaqis.com type=SYSCALL msg=audit(1386103646.841:451293): arch=c000003e syscall=4 success=yes exit=0 a0=36e1fd5 a1=7fffcc37ea40 a2=7fffcc37ea40 a3=4 items=1 ppid=3731 pid=23883 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="dogtag-ipa-retr" exe="/usr/bin/python" subj=system_u:system_r:certmonger_t:s0 key=(null) node=ipa2.abaqis.com type=AVC msg=audit(1386103646.841:451293): avc: denied { getattr } for pid=23883 comm="dogtag-ipa-retr" path="/var/run/certmonger/tmp-xETTca/ccache" dev=dm-3 ino=944 scontext=system_u:system_r:certmonger_t:s0 tcontext=system_u:object_r:var_run_t:s0 tclass=file We get this after pumping through audit2allow: #============= certmonger_t ============== #!!!! The source type 'certmonger_t' can write to a 'file' of the following types: # certmonger_var_lib_t, certmonger_var_run_t, cert_t, dirsrv_config_t, root_t, cluster_conf_t, cluster_var_lib_t, cluster_var_run_t allow certmonger_t var_run_t:file { setattr read lock create write getattr unlink open }; Running a restorecon on /var only gets one thing which doesn't seem related: restorecon reset /var/run/pki-ca.pid context system_u:object_r:var_run_t:s0->system_u:object_r:pki_ca_var_run_t:s0 - -Erinn -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) iQEcBAEBAgAGBQJSoOSMAAoJENetaK3v/E7PB34H/2VSQ4m+gwnR2Zyu9/jWkTMz Up9fwysNyPI9nFrlFfLavkixmZmOyU+GGMsqlBedfaKuc07JH8ZtYdVlKkZihcux wCvjaGfxZdvXZ2RnzyldUO0vN+cEb2TxtLLAZzTfs6LyZiryLcs0R1SpKGpWjXdp jqeZXyavXDBTEa3KrkKSTys24wXukHvaOkdrxcKOoryMLb3o+cTQfmORuuZlzJDO pWX+QrZSMPTUBDaE8eCX8gFKbhHkRwerc3YB5jcbqZiRqBue2L1I9nJYZwWED+dV GMXA1/wMCaB7PRRv8XvG8G7iCFBMp+88Td8GGCrgVxk4wnhjIzAtGxffbwf0Sd4= =Lviw -----END PGP SIGNATURE----- From rcritten at redhat.com Thu Dec 5 20:41:05 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 05 Dec 2013 15:41:05 -0500 Subject: [Freeipa-users] ipa: ERROR: Certificate operation cannot be completed: Failure decoding Certificate Signing Request In-Reply-To: <52A0E1EE.7000901@redhat.com> References: <52A0E007.3050705@redhat.com> <52A0E1EE.7000901@redhat.com> Message-ID: <52A0E4E1.9050100@redhat.com> Dmitri Pal wrote: > On 12/05/2013 03:20 PM, Rob Crittenden wrote: >> Michael Mercier wrote: >>> Hello, >>> >>> A few details to begin: >>> >>> The IPA system consists of 3 servers running on fully patched CentOS >>> 6.5 (updated Monday night). DNS is integrated with the IPA system. >>> >>> ipa-*-3.0.0-37. >>> mod_nss-1.0.8-19 >>> openssl-1.0.1e-16 >>> >>> >>> The system was upgraded from 2.2 >>> >>> >>> >>> Yesterday, I revoked a certificate for an old system and signed a >>> certificate for the replacement system (same hostname) with no >>> apparent issues. >>> >>> Today, I am attempting to sign a certificate for a new system and I >>> am seeing the following error from the command line (with debug=True >>> in /etc/ipa/default.conf): >>> >>> ipa cert-request >>> principal: >>> >>> ipa: ERROR: Certificate operation cannot be completed: Failure >>> decoding Certificate Signing Request >>> >>> The GUI responds with: >>> IPA ERROR 4310 >>> Certificate operation cannot be completed: Failure decoding >>> Certificate Signing Request >>> >>> I have no issues running 'openssl req -text -noout -verify -in >>> ? on the request file. >>> >>> I did do a 'yum update? on the system today (after experiencing the >>> errors), with openssl and mod_nss being upgraded on all servers. All >>> systems were rebooted after the upgrade and the problem still exists. >>> >>> I did see an older thread with a similar issue, but that seemed to >>> involve updating expired certs and Rob did not seem to be able to >>> reproduce the error. Maybe I am experiencing the same problem? >>> >>> Anyone have an idea where a good place to start looking is? >> >> The Failure decoding is a duplicate error message in a couple of >> different places. I'd recommend modifying it per the other thread so >> we can know exactly where it failed and why. >> >> rob >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > Rob do we need a ticket for that? Already fixed in master and 3.3.3, https://fedorahosted.org/freeipa/ticket/3988 rob rob From rcritten at redhat.com Thu Dec 5 20:48:35 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 05 Dec 2013 15:48:35 -0500 Subject: [Freeipa-users] CA expiration and renewal In-Reply-To: <52A0E493.4010204@gmail.com> References: <52842407.80504@gmail.com> <52939269.1070405@redhat.com> <52963840.8090703@gmail.com> <529643F3.9020907@redhat.com> <529E29AA.90300@gmail.com> <529F4725.8000304@redhat.com> <529F6D3C.3070609@gmail.com> <52A048EF.5000708@redhat.com> <52A0DC29.9070704@gmail.com> <52A0DFB3.80301@redhat.com> <52A0E493.4010204@gmail.com> Message-ID: <52A0E6A3.4010509@redhat.com> Erinn Looney-Triggs wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 12/05/2013 12:18 PM, Rob Crittenden wrote: >> Erinn Looney-Triggs wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>> >>> On 12/05/2013 01:35 AM, Martin Kosek wrote: >>>> On 12/04/2013 06:58 PM, Erinn Looney-Triggs wrote: >>>>> On 12/04/2013 07:15 AM, Rob Crittenden wrote: >>>>>> Erinn Looney-Triggs wrote: >>>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>>>> >>>>>>> On 11/27/2013 11:11 AM, Rob Crittenden wrote: >>>>>>>> Erinn Looney-Triggs wrote: >>>>>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 11/25/2013 11:09 AM, Rob Crittenden wrote: >>>>>>>>>> Erinn Looney-Triggs wrote: >>>>>>>>>>> Folks just wanted to touch base again before the >>>>>>>>>>> American holiday season starts. My CA, which is >>>>>>>>>>> subordinate to AD CS will be expiring on >>>>>>>>>>> December 9th, I submitted a bug, y'all drew up >>>>>>>>>>> docs etc for a plan (thanks). Now I just wanted >>>>>>>>>>> to see how it was going and if need be what >>>>>>>>>>> manual steps I will need to take to renew the >>>>>>>>>>> certificate. >>>>>>>>>>> >>>>>>>>>>> Thanks again for the great work, >>>>>>>>>> >>>>>>>>>> We're working on an a set of tools to make this >>>>>>>>>> easier. For now I've appended some manual >>>>>>>>>> instructions onto a page still in progress. >>>>>>>>>> >>>>>>>>>> http://www.freeipa.org/page/Howto/CA_Certificate_Renewal#Manual_Procedure_in_IPA_3.0 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>> >>>>>>>>>> >>>>> >>>>>>>>>> >>>> >>>>>>>>>> >>> >>>>>>>>>> > Some parts may be still be a little rough or hard to understand. >>>>>>>>>> Let me know if you have any problems or >>>>>>>>>> corrections. >>>>>>>>>> >>>>>>>>>> rob >>>>>>>>> >>>>>>>>> Rob, >>>>>>>>> >>>>>>>>> Thanks for the instructions, a few questions. >>>>>>>>> >>>>>>>>> What sort of interruption in service could this >>>>>>>>> create? >>>>>>>> >>>>>>>> Services will be restarted during this process >>>>>>>> including your LDAP, Apache and CA instances. Downtime >>>>>>>> should be relatively short, no more than a few minutes >>>>>>>> combined. >>>>>>>> >>>>>>>>> Can you expand on this section a little bit: Replace >>>>>>>>> the value of ca.signing.cert in /etc/pki-ca/CS.cfg. >>>>>>>>> This is the base64 value of the certificate. You can >>>>>>>>> obtain this by removing the BEGIN/END blocks from >>>>>>>>> ipa.crt and compressing it into a single line. >>>>>>>> >>>>>>>> A PEM cert looks like: >>>>>>>> >>>>>>>> -----BEGIN CERTIFICATE----- >>>>>>>> MIIB/zCCAWigAwIBAgICA+gwDQYJKoZIhvcNAQEFBQAwKTEnMCUGA1UEAxMeSVBB >>>>>>>> >>>>>>>> >>>>> >>>>>>>> >>> >>>>>>>> > IFRlc3QgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTEwMDIyMzIyMzMxNVoXDTIw >>>>>>>> MDIyMzIyMzMxNVowKTEnMCUGA1UEAxMeSVBBIFRlc3QgQ2VydGlmaWNhdGUgQXV0 >>>>>>>> >>>>>>>> >>>>> >>>>>>>> >>> >>>>>>>> > aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+G6ultyLaXqzBlypA >>>>>>>> DnOsinkMTlZZssTFQh/QUMi1F1fcn8QUlmsl9a+l6w6hfZm7P8z3sVwsjLQcDWA4 >>>>>>>> >>>>>>>> >>>>> >>>>>>>> >>> >>>>>>>> > KxOh+LmIsNL4OKx4wKF1q/pSt1PATRU5Pgu2+3wlwJO0H7cl4QfavoOLwmxAZf/l >>>>>>>> ZNIy/5czvSWFWj7EJj16ty9BeQIDAQABozYwNDARBglghkgBhvhCAQEEBAMCAAcw >>>>>>>> >>>>>>>> >>>>> >>>>>>>> >>> >>>>>>>> > DwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAsQwDQYJKoZIhvcNAQEFBQAD >>>>>>>> gYEAl0gIshwNkhyfNe1XMLswPeOgH5YN1BUuKXzbv1fuSIkArjwLODr4cOdXzQvt >>>>>>>> >>>>>>>> >>>>> >>>>>>>> >>> >>>>>>>> > yaiX6Z+pRC/sK8MgLhPxV2X9QVQdzKfLkVGIdboCt1j3EXxSUCZeIuSKouitkWYe >>>>>>>> eSH9DQkYDp/oKgANLWnY7CNorPz6xQktp1pB0DGohV1BeTA= >>>>>>>> -----END CERTIFICATE----- >>>>>>>> >>>>>>>> You need to drop the BEGIN/END blocks then combine all >>>>>>>> the lines into a single line, so you have a unified >>>>>>>> base64 blog. It will look like: >>>>>>>> >>>>>>>> ca.signing.cert=MII...B0DGohV1BeTA= >>>>>>>> >>>>>>>> I was afraid wrapping woudl destroy my demonstration so >>>>>>>> I used ellipses instead. >>>>>>>> >>>>>>>>> Thanks and happy Thanksgiving, >>>>>>>> >>>>>>>> You're welcome. You too. >>>>>>>> >>>>>>>> rob >>>>>>>> >>>>>>> >>>>>>> Ok I have done the steps as outlined. One small >>>>>>> suggestion and one question came up. >>>>>>> >>>>>>> Suggestion: for the ldapmodify command indicate that a >>>>>>> ctl-d is necessary to end input. Most folks will know >>>>>>> this, but some may not. >>>>>>> >>>>>>> For the client section you have me copy the newly signed >>>>>>> subordnate CA certificate into /etc/ipa/ca.crt. However, >>>>>>> on my hosts that was actually a copy of the AD CS >>>>>>> certificate, not the subordinate certificate. In the case >>>>>>> of a subordinate installation do you want the root or the >>>>>>> subordinate CA? It would seem that the root would be >>>>>>> broader, but I just want to make sure. >>>>>>> >>>>> >>>>>> The IPA CA cert should be sufficient. >>>>> >>>>>> rob >>>>> >>>>> >>>>> Thanks, and just for an update, the switch over was made, >>>>> certmonger is happily updating certs now on all hosts and >>>>> everything just appears to be working thus far, minus the >>>>> replication of the agent certificate which I am still >>>>> looking into. >>>>> >>>>> Thanks for the help, >>>>> >>>>> -Erinn >>>> >>>> Great, I am glad to hear that. Note that we were investigating >>>> renewing certificates and clones and found out an issue in >>>> Python readline that prevented a renewal of the IPA agent >>>> certificate: >>>> >>>> https://fedorahosted.org/freeipa/ticket/4064 >>>> >>>> Could this be the reason of your issues? Did you saw a crash >>>> of certmonger during the renewal? It was found out to be >>>> happening due to the aforementioned bug. >>>> >>>> Thanks, Martin >>>> >>> >>> That seems very likely, however abrt didn't catch anything, and >>> there doesn't appear to be any tmp file wreckage left anywhere. I >>> can't find anything in the logs indicating failure, all signs >>> point to success for the renewal: >>> >>> >>> Dec 3 20:47:25 ipa2 certmonger: Certificate named "Server-Cert" >>> in token "NSS Certificate DB" in database >>> "/etc/dirsrv/slapd-ABAQIS-COM" will not be valid afte r >>> 20131210032326. Dec 3 20:47:25 ipa2 certmonger: Certificate >>> named "Server-Cert" in token "NSS Certificate DB" in database >>> "/etc/dirsrv/slapd-PKI-IPA" will not be valid after >>> 20131210032326. Dec 3 20:47:25 ipa2 certmonger: Certificate >>> named "auditSigningCert cert-pki-ca" in token "NSS Certificate >>> DB" in database "/var/lib/pki-ca/alias" will not be valid after >>> 20131210032326. Dec 3 20:47:25 ipa2 certmonger: Certificate >>> named "ocspSigningCert cert-pki-ca" in token "NSS Certificate DB" >>> in database "/var/lib/pki-ca/alias" will not be valid after >>> 20131210032326. Dec 3 20:47:25 ipa2 certmonger: Certificate >>> named "subsystemCert cert-pki-ca" in token "NSS Certificate DB" >>> in database "/var/lib/pki-ca/alias" will not be valid after >>> 20131210032326. Dec 3 20:47:25 ipa2 certmonger: Certificate >>> named "ipaCert" in token "NSS Certificate DB" in database >>> "/etc/httpd/alias" will not be valid after 20131210032326. Dec 3 >>> 20:47:26 ipa2 certmonger: Certificate named "Server-Cert" in >>> token "NSS Certificate DB" in database >>> "/etc/dirsrv/slapd-PKI-IPA" issued by CA and saved. Dec 3 >>> 20:47:26 ipa2 certmonger: Certificate named "Server-Cert" in >>> token "NSS Certificate DB" in database >>> "/etc/dirsrv/slapd-ABAQIS-COM" issued by CA and saved. Dec 3 >>> 20:47:26 ipa2 python: Updating certificate for auditSigningCert >>> cert-pki-ca Dec 3 20:47:26 ipa2 python: Updating certificate for >>> ocspSigningCert cert-pki-ca Dec 3 20:47:27 ipa2 python: Updating >>> certificate for subsystemCert cert-pki-ca Dec 3 20:47:27 ipa2 >>> python: Updating certificate for ipaCert Dec 3 20:47:28 ipa2 >>> python: certmonger stopping pki-cad Dec 3 20:48:04 ipa2 python: >>> certmonger started pki-cad, nickname 'auditSigningCert >>> cert-pki-ca' Dec 3 20:48:04 ipa2 certmonger: Certificate named >>> "auditSigningCert cert-pki-ca" in token "NSS Certificate DB" in >>> database "/var/lib/pki-ca/alias" issued by CA and saved. Dec 3 >>> 20:48:08 ipa2 python: certmonger stopping pki-cad Dec 3 20:48:44 >>> ipa2 python: certmonger started pki-cad, nickname >>> 'ocspSigningCert cert-pki-ca' Dec 3 20:48:44 ipa2 certmonger: >>> Certificate named "ocspSigningCert cert-pki-ca" in token "NSS >>> Certificate DB" in database "/var/lib/pki-ca/alias" issued by CA >>> and saved. Dec 3 20:48:48 ipa2 python: certmonger stopping >>> pki-cad Dec 3 20:49:24 ipa2 python: certmonger started pki-cad, >>> nickname 'subsystemCert cert-pki-ca' Dec 3 20:49:24 ipa2 >>> certmonger: Certificate named "subsystemCert cert-pki-ca" in >>> token "NSS Certificate DB" in database "/var/lib/pki-ca/alias" >>> issued by CA and saved. Dec 3 20:49:27 ipa2 python: certmonger >>> restarted httpd Dec 3 20:49:29 ipa2 certmonger: Certificate >>> named "ipaCert" in token "NSS Certificate DB" in database >>> "/etc/httpd/alias" issued by CA and saved. >>> >>> >>> Sorry for the word wrap there. Certmonger continued to run >>> throughout it appears. The dates line up correctly, certmonger on >>> the primary renewed on the 3rd and the secondary failed to get >>> the new certificate which led straight back to the same place. >> >> But you were able to fix it again, right? >> >> I wonder if there are any AVCs around renewal time. >> >> rob >> > > Yep manually moving over and importing worked just fine, as is > everything is good for the next two years until the whole cycle > repeats. But I reckon this would be a very good thing to get sussed out. > > Yeah there are AVC messages: > > node=ipa2.abaqis.com type=PATH msg=audit(1386103646.841:451293): > item=0 name="/var/run/certmonger/tmp-xETTca/ccache" inode=944 > dev=fd:03 mode=0100600 ouid=0 ogid=0 rdev=00:00 > obj=system_u:object_r:var_run_t:s0 nametype=NORMAL > node=ipa2.abaqis.com type=CWD msg=audit(1386103646.841:451293): cwd="/" > node=ipa2.abaqis.com type=SYSCALL msg=audit(1386103646.841:451293): > arch=c000003e syscall=4 success=yes exit=0 a0=36e1fd5 a1=7fffcc37ea40 > a2=7fffcc37ea40 a3=4 items=1 ppid=3731 pid=23883 auid=4294967295 uid=0 > gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) > ses=4294967295 comm="dogtag-ipa-retr" exe="/usr/bin/python" > subj=system_u:system_r:certmonger_t:s0 key=(null) > node=ipa2.abaqis.com type=AVC msg=audit(1386103646.841:451293): avc: > denied { getattr } for pid=23883 comm="dogtag-ipa-retr" > path="/var/run/certmonger/tmp-xETTca/ccache" dev=dm-3 ino=944 > scontext=system_u:system_r:certmonger_t:s0 > tcontext=system_u:object_r:var_run_t:s0 tclass=file > > We get this after pumping through audit2allow: > #============= certmonger_t ============== > #!!!! The source type 'certmonger_t' can write to a 'file' of the > following types: > # certmonger_var_lib_t, certmonger_var_run_t, cert_t, dirsrv_config_t, > root_t, cluster_conf_t, cluster_var_lib_t, cluster_var_run_t > > allow certmonger_t var_run_t:file { setattr read lock create write > getattr unlink open }; > > Running a restorecon on /var only gets one thing which doesn't seem > related: > restorecon reset /var/run/pki-ca.pid context > system_u:object_r:var_run_t:s0->system_u:object_r:pki_ca_var_run_t:s0 Ok that explains it then. The renewal script can't get a kerberos ticket. https://fedorahosted.org/freeipa/ticket/4070 thanks rob From erinn.looneytriggs at gmail.com Thu Dec 5 20:39:47 2013 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Thu, 05 Dec 2013 12:39:47 -0800 Subject: [Freeipa-users] CA expiration and renewal In-Reply-To: <52A0DFB3.80301@redhat.com> References: <52842407.80504@gmail.com> <52939269.1070405@redhat.com> <52963840.8090703@gmail.com> <529643F3.9020907@redhat.com> <529E29AA.90300@gmail.com> <529F4725.8000304@redhat.com> <529F6D3C.3070609@gmail.com> <52A048EF.5000708@redhat.com> <52A0DC29.9070704@gmail.com> <52A0DFB3.80301@redhat.com> Message-ID: <52A0E493.4010204@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/05/2013 12:18 PM, Rob Crittenden wrote: > Erinn Looney-Triggs wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> On 12/05/2013 01:35 AM, Martin Kosek wrote: >>> On 12/04/2013 06:58 PM, Erinn Looney-Triggs wrote: >>>> On 12/04/2013 07:15 AM, Rob Crittenden wrote: >>>>> Erinn Looney-Triggs wrote: >>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>>> >>>>>> On 11/27/2013 11:11 AM, Rob Crittenden wrote: >>>>>>> Erinn Looney-Triggs wrote: >>>>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 11/25/2013 11:09 AM, Rob Crittenden wrote: >>>>>>>>> Erinn Looney-Triggs wrote: >>>>>>>>>> Folks just wanted to touch base again before the >>>>>>>>>> American holiday season starts. My CA, which is >>>>>>>>>> subordinate to AD CS will be expiring on >>>>>>>>>> December 9th, I submitted a bug, y'all drew up >>>>>>>>>> docs etc for a plan (thanks). Now I just wanted >>>>>>>>>> to see how it was going and if need be what >>>>>>>>>> manual steps I will need to take to renew the >>>>>>>>>> certificate. >>>>>>>>>> >>>>>>>>>> Thanks again for the great work, >>>>>>>>> >>>>>>>>> We're working on an a set of tools to make this >>>>>>>>> easier. For now I've appended some manual >>>>>>>>> instructions onto a page still in progress. >>>>>>>>> >>>>>>>>> http://www.freeipa.org/page/Howto/CA_Certificate_Renewal#Manual_Procedure_in_IPA_3.0 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> >>>>>>>>> >>>> >>>>>>>>> >>> >>>>>>>>> >> >>>>>>>>> Some parts may be still be a little rough or hard to understand. >>>>>>>>> Let me know if you have any problems or >>>>>>>>> corrections. >>>>>>>>> >>>>>>>>> rob >>>>>>>> >>>>>>>> Rob, >>>>>>>> >>>>>>>> Thanks for the instructions, a few questions. >>>>>>>> >>>>>>>> What sort of interruption in service could this >>>>>>>> create? >>>>>>> >>>>>>> Services will be restarted during this process >>>>>>> including your LDAP, Apache and CA instances. Downtime >>>>>>> should be relatively short, no more than a few minutes >>>>>>> combined. >>>>>>> >>>>>>>> Can you expand on this section a little bit: Replace >>>>>>>> the value of ca.signing.cert in /etc/pki-ca/CS.cfg. >>>>>>>> This is the base64 value of the certificate. You can >>>>>>>> obtain this by removing the BEGIN/END blocks from >>>>>>>> ipa.crt and compressing it into a single line. >>>>>>> >>>>>>> A PEM cert looks like: >>>>>>> >>>>>>> -----BEGIN CERTIFICATE----- >>>>>>> MIIB/zCCAWigAwIBAgICA+gwDQYJKoZIhvcNAQEFBQAwKTEnMCUGA1UEAxMeSVBB >>>>>>> >>>>>>> >>>> >>>>>>> >> >>>>>>> IFRlc3QgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTEwMDIyMzIyMzMxNVoXDTIw >>>>>>> MDIyMzIyMzMxNVowKTEnMCUGA1UEAxMeSVBBIFRlc3QgQ2VydGlmaWNhdGUgQXV0 >>>>>>> >>>>>>> >>>> >>>>>>> >> >>>>>>> aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+G6ultyLaXqzBlypA >>>>>>> DnOsinkMTlZZssTFQh/QUMi1F1fcn8QUlmsl9a+l6w6hfZm7P8z3sVwsjLQcDWA4 >>>>>>> >>>>>>> >>>> >>>>>>> >> >>>>>>> KxOh+LmIsNL4OKx4wKF1q/pSt1PATRU5Pgu2+3wlwJO0H7cl4QfavoOLwmxAZf/l >>>>>>> ZNIy/5czvSWFWj7EJj16ty9BeQIDAQABozYwNDARBglghkgBhvhCAQEEBAMCAAcw >>>>>>> >>>>>>> >>>> >>>>>>> >> >>>>>>> DwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAsQwDQYJKoZIhvcNAQEFBQAD >>>>>>> gYEAl0gIshwNkhyfNe1XMLswPeOgH5YN1BUuKXzbv1fuSIkArjwLODr4cOdXzQvt >>>>>>> >>>>>>> >>>> >>>>>>> >> >>>>>>> yaiX6Z+pRC/sK8MgLhPxV2X9QVQdzKfLkVGIdboCt1j3EXxSUCZeIuSKouitkWYe >>>>>>> eSH9DQkYDp/oKgANLWnY7CNorPz6xQktp1pB0DGohV1BeTA= >>>>>>> -----END CERTIFICATE----- >>>>>>> >>>>>>> You need to drop the BEGIN/END blocks then combine all >>>>>>> the lines into a single line, so you have a unified >>>>>>> base64 blog. It will look like: >>>>>>> >>>>>>> ca.signing.cert=MII...B0DGohV1BeTA= >>>>>>> >>>>>>> I was afraid wrapping woudl destroy my demonstration so >>>>>>> I used ellipses instead. >>>>>>> >>>>>>>> Thanks and happy Thanksgiving, >>>>>>> >>>>>>> You're welcome. You too. >>>>>>> >>>>>>> rob >>>>>>> >>>>>> >>>>>> Ok I have done the steps as outlined. One small >>>>>> suggestion and one question came up. >>>>>> >>>>>> Suggestion: for the ldapmodify command indicate that a >>>>>> ctl-d is necessary to end input. Most folks will know >>>>>> this, but some may not. >>>>>> >>>>>> For the client section you have me copy the newly signed >>>>>> subordnate CA certificate into /etc/ipa/ca.crt. However, >>>>>> on my hosts that was actually a copy of the AD CS >>>>>> certificate, not the subordinate certificate. In the case >>>>>> of a subordinate installation do you want the root or the >>>>>> subordinate CA? It would seem that the root would be >>>>>> broader, but I just want to make sure. >>>>>> >>>> >>>>> The IPA CA cert should be sufficient. >>>> >>>>> rob >>>> >>>> >>>> Thanks, and just for an update, the switch over was made, >>>> certmonger is happily updating certs now on all hosts and >>>> everything just appears to be working thus far, minus the >>>> replication of the agent certificate which I am still >>>> looking into. >>>> >>>> Thanks for the help, >>>> >>>> -Erinn >>> >>> Great, I am glad to hear that. Note that we were investigating >>> renewing certificates and clones and found out an issue in >>> Python readline that prevented a renewal of the IPA agent >>> certificate: >>> >>> https://fedorahosted.org/freeipa/ticket/4064 >>> >>> Could this be the reason of your issues? Did you saw a crash >>> of certmonger during the renewal? It was found out to be >>> happening due to the aforementioned bug. >>> >>> Thanks, Martin >>> >> >> That seems very likely, however abrt didn't catch anything, and >> there doesn't appear to be any tmp file wreckage left anywhere. I >> can't find anything in the logs indicating failure, all signs >> point to success for the renewal: >> >> >> Dec 3 20:47:25 ipa2 certmonger: Certificate named "Server-Cert" >> in token "NSS Certificate DB" in database >> "/etc/dirsrv/slapd-ABAQIS-COM" will not be valid afte r >> 20131210032326. Dec 3 20:47:25 ipa2 certmonger: Certificate >> named "Server-Cert" in token "NSS Certificate DB" in database >> "/etc/dirsrv/slapd-PKI-IPA" will not be valid after >> 20131210032326. Dec 3 20:47:25 ipa2 certmonger: Certificate >> named "auditSigningCert cert-pki-ca" in token "NSS Certificate >> DB" in database "/var/lib/pki-ca/alias" will not be valid after >> 20131210032326. Dec 3 20:47:25 ipa2 certmonger: Certificate >> named "ocspSigningCert cert-pki-ca" in token "NSS Certificate DB" >> in database "/var/lib/pki-ca/alias" will not be valid after >> 20131210032326. Dec 3 20:47:25 ipa2 certmonger: Certificate >> named "subsystemCert cert-pki-ca" in token "NSS Certificate DB" >> in database "/var/lib/pki-ca/alias" will not be valid after >> 20131210032326. Dec 3 20:47:25 ipa2 certmonger: Certificate >> named "ipaCert" in token "NSS Certificate DB" in database >> "/etc/httpd/alias" will not be valid after 20131210032326. Dec 3 >> 20:47:26 ipa2 certmonger: Certificate named "Server-Cert" in >> token "NSS Certificate DB" in database >> "/etc/dirsrv/slapd-PKI-IPA" issued by CA and saved. Dec 3 >> 20:47:26 ipa2 certmonger: Certificate named "Server-Cert" in >> token "NSS Certificate DB" in database >> "/etc/dirsrv/slapd-ABAQIS-COM" issued by CA and saved. Dec 3 >> 20:47:26 ipa2 python: Updating certificate for auditSigningCert >> cert-pki-ca Dec 3 20:47:26 ipa2 python: Updating certificate for >> ocspSigningCert cert-pki-ca Dec 3 20:47:27 ipa2 python: Updating >> certificate for subsystemCert cert-pki-ca Dec 3 20:47:27 ipa2 >> python: Updating certificate for ipaCert Dec 3 20:47:28 ipa2 >> python: certmonger stopping pki-cad Dec 3 20:48:04 ipa2 python: >> certmonger started pki-cad, nickname 'auditSigningCert >> cert-pki-ca' Dec 3 20:48:04 ipa2 certmonger: Certificate named >> "auditSigningCert cert-pki-ca" in token "NSS Certificate DB" in >> database "/var/lib/pki-ca/alias" issued by CA and saved. Dec 3 >> 20:48:08 ipa2 python: certmonger stopping pki-cad Dec 3 20:48:44 >> ipa2 python: certmonger started pki-cad, nickname >> 'ocspSigningCert cert-pki-ca' Dec 3 20:48:44 ipa2 certmonger: >> Certificate named "ocspSigningCert cert-pki-ca" in token "NSS >> Certificate DB" in database "/var/lib/pki-ca/alias" issued by CA >> and saved. Dec 3 20:48:48 ipa2 python: certmonger stopping >> pki-cad Dec 3 20:49:24 ipa2 python: certmonger started pki-cad, >> nickname 'subsystemCert cert-pki-ca' Dec 3 20:49:24 ipa2 >> certmonger: Certificate named "subsystemCert cert-pki-ca" in >> token "NSS Certificate DB" in database "/var/lib/pki-ca/alias" >> issued by CA and saved. Dec 3 20:49:27 ipa2 python: certmonger >> restarted httpd Dec 3 20:49:29 ipa2 certmonger: Certificate >> named "ipaCert" in token "NSS Certificate DB" in database >> "/etc/httpd/alias" issued by CA and saved. >> >> >> Sorry for the word wrap there. Certmonger continued to run >> throughout it appears. The dates line up correctly, certmonger on >> the primary renewed on the 3rd and the secondary failed to get >> the new certificate which led straight back to the same place. > > But you were able to fix it again, right? > > I wonder if there are any AVCs around renewal time. > > rob > Yep manually moving over and importing worked just fine, as is everything is good for the next two years until the whole cycle repeats. But I reckon this would be a very good thing to get sussed out. Yeah there are AVC messages: node=ipa2.abaqis.com type=PATH msg=audit(1386103646.841:451293): item=0 name="/var/run/certmonger/tmp-xETTca/ccache" inode=944 dev=fd:03 mode=0100600 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:var_run_t:s0 nametype=NORMAL node=ipa2.abaqis.com type=CWD msg=audit(1386103646.841:451293): cwd="/" node=ipa2.abaqis.com type=SYSCALL msg=audit(1386103646.841:451293): arch=c000003e syscall=4 success=yes exit=0 a0=36e1fd5 a1=7fffcc37ea40 a2=7fffcc37ea40 a3=4 items=1 ppid=3731 pid=23883 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="dogtag-ipa-retr" exe="/usr/bin/python" subj=system_u:system_r:certmonger_t:s0 key=(null) node=ipa2.abaqis.com type=AVC msg=audit(1386103646.841:451293): avc: denied { getattr } for pid=23883 comm="dogtag-ipa-retr" path="/var/run/certmonger/tmp-xETTca/ccache" dev=dm-3 ino=944 scontext=system_u:system_r:certmonger_t:s0 tcontext=system_u:object_r:var_run_t:s0 tclass=file We get this after pumping through audit2allow: #============= certmonger_t ============== #!!!! The source type 'certmonger_t' can write to a 'file' of the following types: # certmonger_var_lib_t, certmonger_var_run_t, cert_t, dirsrv_config_t, root_t, cluster_conf_t, cluster_var_lib_t, cluster_var_run_t allow certmonger_t var_run_t:file { setattr read lock create write getattr unlink open }; Running a restorecon on /var only gets one thing which doesn't seem related: restorecon reset /var/run/pki-ca.pid context system_u:object_r:var_run_t:s0->system_u:object_r:pki_ca_var_run_t:s0 - -Erinn -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) iQEcBAEBAgAGBQJSoOSMAAoJENetaK3v/E7PB34H/2VSQ4m+gwnR2Zyu9/jWkTMz Up9fwysNyPI9nFrlFfLavkixmZmOyU+GGMsqlBedfaKuc07JH8ZtYdVlKkZihcux wCvjaGfxZdvXZ2RnzyldUO0vN+cEb2TxtLLAZzTfs6LyZiryLcs0R1SpKGpWjXdp jqeZXyavXDBTEa3KrkKSTys24wXukHvaOkdrxcKOoryMLb3o+cTQfmORuuZlzJDO pWX+QrZSMPTUBDaE8eCX8gFKbhHkRwerc3YB5jcbqZiRqBue2L1I9nJYZwWED+dV GMXA1/wMCaB7PRRv8XvG8G7iCFBMp+88Td8GGCrgVxk4wnhjIzAtGxffbwf0Sd4= =Lviw -----END PGP SIGNATURE----- From dbmacartney at gmail.com Thu Dec 5 22:32:51 2013 From: dbmacartney at gmail.com (Dale Macartney) Date: Thu, 05 Dec 2013 22:32:51 +0000 Subject: [Freeipa-users] Adding Display Pictures/Avatars into FreeIPA Message-ID: <52A0FF13.4080003@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi folks Just a quick mail from me before I call it a night. Today I've added user display pictures/avatars into FreeIPA, detailed here. https://www.dalemacartney.com/2013/12/05/adding-display-picturesavatars-red-hat-idmfreeipa/ As well as pulling those images into a GNOME3 desktop session, detailed here. https://www.dalemacartney.com/2013/12/05/loading-display-picturesavatars-red-hat-idmfreeipa-gnome3/ Would love some feedback if anyone is interested in these items. G'night all. Dale -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSoP8RAAoJEAJsWS61tB+qfMgP/244KCvHZsQEVEym1ZZOMwXt zcznmRoik6sGKac1CWYO+BkPvHjEN+/IEKEW35x6OYfhSRcmJ72GFXXnOCG2ZR8c ppFcj41qZBtOKSHwrpmpLbUCa1BqAD8TAwaF4mfqy5ykqGu6z5j8M7xVPXU0GBig xzqYoEdJ23ZaSroxC+FPWB17D1IEezgiCQ7Ti9goZRv1WaH3GNvMHG8wIblM5zKG 7PqUkrvGxsNaV5ueFkJKnOqvLdJtcLMswmEcj5noUqTDRJZzygMZgsr65r5eId9k fnHSVKUOpxW6WEg2FfM7bAfhN4PyvjnMQppfp/1varplywvp4bZNngCJRKgIRZ45 Jl4rWWJrwlr5nXzBZjCm/n8s3d0OziUQqOTZvHp6ijNoGnLksUQuYgdXWJDI5Mz9 Zb5x4DrYhlOHR0sG8tUK0ezSEF/UL+4MySjNaljM2cBKC/GMjIRWG5Dz8rKI2W2I fBg20mYNdIracpfzN01Kl4bbJitVKaFsWF4QgkLMCAFfdNmktrXNnBVl6OpQduLy +zGswEL4KrDw0hsWH/6aTjEtElLInhS50ONJIXZzv0mNxJMnZUiEdxrdg5GCConh 83v9DSyc7AAPN2CJ1/AtdKh/PohNPy6CaLOFRvfEGwuUX1k47gx29F0JZ80W233o HVUWHwCtaRr/ecg48R7U =vyRU -----END PGP SIGNATURE----- From simo at redhat.com Thu Dec 5 22:58:05 2013 From: simo at redhat.com (Simo Sorce) Date: Thu, 05 Dec 2013 17:58:05 -0500 Subject: [Freeipa-users] Adding Display Pictures/Avatars into FreeIPA In-Reply-To: <52A0FF13.4080003@gmail.com> References: <52A0FF13.4080003@gmail.com> Message-ID: <1386284285.3255.98.camel@willson.li.ssimo.org> On Thu, 2013-12-05 at 22:32 +0000, Dale Macartney wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi folks > > Just a quick mail from me before I call it a night. > > Today I've added user display pictures/avatars into FreeIPA, detailed here. > > https://www.dalemacartney.com/2013/12/05/adding-display-picturesavatars-red-hat-idmfreeipa/ > > As well as pulling those images into a GNOME3 desktop session, detailed > here. > > https://www.dalemacartney.com/2013/12/05/loading-display-picturesavatars-red-hat-idmfreeipa-gnome3/ > > Would love some feedback if anyone is interested in these items. > > G'night all. > Great stuff Dale, I wonder if ipa user-mod --addattr could be used to load the avatar, instead of using ldap commands. Simo. -- Simo Sorce * Red Hat, Inc * New York From isaev at fintech.ru Fri Dec 6 06:53:59 2013 From: isaev at fintech.ru (=?utf-8?B?0JjRgdCw0LXQsiDQktC40YLQsNC70LjQuSDQkNC90LDRgtC+0LvRjNC10LI=?= =?utf-8?B?0LjRhw==?=) Date: Fri, 6 Dec 2013 06:53:59 +0000 Subject: [Freeipa-users] How to disable user automatically when he becomes locked In-Reply-To: <529F4A06.90208@redhat.com> References: <69303615BE133645963548DD4A3BFCB3BDB81E@E2K7.fintech.ru> <529F0C6F.6060405@redhat.com> <69303615BE133645963548DD4A3BFCB3BDB839@E2K7.fintech.ru> <529F4A06.90208@redhat.com> Message-ID: <69303615BE133645963548DD4A3BFCB3BDCA2C@E2K7.fintech.ru> Thank you, Martin, it's a good way out, we will follow your approach. Vitaly Isaev Software engineer Information security department Fintech JSC, Moscow, Russia -----Original Message----- From: Martin Kosek [mailto:mkosek at redhat.com] Sent: Thursday, December 05, 2013 10:41 AM To: ????? ??????? ???????????; Natxo Asenjo; freeipa-users at redhat.com Subject: Re: [Freeipa-users] How to disable user automatically when he becomes locked On 12/04/2013 12:43 PM, ????? ??????? ??????????? wrote: > Thank you for your responses! > > In terms of IdM "lock" state and "disable" state are different: when user becomes locked after several failed login attempts, he is still enabled. The locked state is not shown neither in "ipa user-show" or "ipa user-find --all" commands output, nor in Web GUI... > Locked user is brought up to life with "ipa user-unlock" command, but not with "ipa user-enable" command. This is correct. > So the lockout duration set to 0 could be a deal for us (we are using v. 3.0.0). But can we receive a notification in the case of lockout event? How can we check if the user is locked? Can we see this event in any IdM log? "Lockout status" is not an attribute on it's own (as compared to user-lock/user-unlock locking). It is rather a state of a KDC which based on the password policy (ipa pwpolicy-show) and user attributes krbloginfailedcount and krblastpwdchange can decide if the user is locked out or not. We have prepared a "user-status" command to at least help gathering this all this information from all KDCs. See help in "ipa help user-status". If you want to search for all disabled users, could you base it on an ldapsearch like the following one? ldapsearch -h $IPA_SERVER -Y GSSAPI -b 'cn=users,cn=accounts,dc=example,dc=com' '(krbLoginFailedCount=3)' It could give you the list of users who already hit the lockout count leading to the permanent lockout. Note that there are RFEs already filed that improve the situation in this area: https://fedorahosted.org/freeipa/ticket/3700 : [RFE] Failed login replication https://fedorahosted.org/freeipa/ticket/2792 : [RFE] Allow quering user lock status and unlocking user in UI Martin > > > Thanks a lot, > > ??????? ????? > ???????-??????????? > ?????? ?????????? ? ????????? ???? > ??????????? ?????????????? ???????????? ??? ???????? > > > -----Original Message----- > From: freeipa-users-bounces at redhat.com > [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Martin Kosek > Sent: Wednesday, December 04, 2013 3:07 PM > To: Natxo Asenjo; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] How to disable user automatically when he > becomes locked > > On 12/04/2013 11:53 AM, Natxo Asenjo wrote: >> On Wed, Dec 4, 2013 at 11:44 AM, Natxo Asenjo wrote: >>> On Wed, Dec 4, 2013 at 10:59 AM, ????? ??????? ??????????? >>> wrote: >>>> Dear Freeipa users and developers, >>>> >>>> >>>> >>>> We need to alter the default behavior of the IdM server in the >>>> situation when user exceeds the limit of incorrect password login attempts. >>>> >>>> By default the user is getting locked in this case, but we need to >>>> disable him fully. >>> >>> As in, delete the user? Because locking the account is disabling it >>> unless I misunderstand it. I cannot log in, my cron jobs will fail, >>> I cannot use any ldap/kerberos service because my account is disabled. >>> >>> What do you need exactly? Or maybe you refer to the fact that the >>> lock is temporary (standard 600 seconds, after which you may try >>> logging in again? In that case, change that in the password policies >>> (in the web interface, policy tab, then password policy, then open >>> the global_policy, then edit the lockout duration field and update it. >> >> for completeness, the same in the cli as an admin user: >> >> To get the values: >> $ ipa pwpolicy-show >> Group: global_policy >> Max lifetime (days): 90 >> Min lifetime (hours): 1 >> History size: 0 >> Character classes: 0 >> Min length: 8 >> Max failures: 6 >> Failure reset interval: 60 >> Lockout duration: 600 >> >> To change a value: >> $ ipa pwpolicy-mod global_policy --lockouttime=INT >> >> (where INT is the number of seconds you want the lock to be >> implemented, set it to a huge number, like 946080000 in practice 30 >> ( >> 3600 secs * 24 hours * 365 days * 30 years ) years is like a life >> sentence ;-) - the accounts). >> > > Right, though I am not sure if it would not hit Kerberos limitation for too large timestamps. > > Alternatively, you can set the Lockout Duration to 0, this should lock out the account permanently after the number of tries was breached. Note that there is a related bug fix in FreeIPA 3.2.0: > https://fedorahosted.org/freeipa/ticket/3433 > > Martin > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > From pspacek at redhat.com Fri Dec 6 07:43:15 2013 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 06 Dec 2013 08:43:15 +0100 Subject: [Freeipa-users] Adding Display Pictures/Avatars into FreeIPA In-Reply-To: <1386284285.3255.98.camel@willson.li.ssimo.org> References: <52A0FF13.4080003@gmail.com> <1386284285.3255.98.camel@willson.li.ssimo.org> Message-ID: <52A18013.7060303@redhat.com> On 5.12.2013 23:58, Simo Sorce wrote: > On Thu, 2013-12-05 at 22:32 +0000, Dale Macartney wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi folks >> >> Just a quick mail from me before I call it a night. >> >> Today I've added user display pictures/avatars into FreeIPA, detailed here. >> >> https://www.dalemacartney.com/2013/12/05/adding-display-picturesavatars-red-hat-idmfreeipa/ >> >> As well as pulling those images into a GNOME3 desktop session, detailed >> here. >> >> https://www.dalemacartney.com/2013/12/05/loading-display-picturesavatars-red-hat-idmfreeipa-gnome3/ >> >> Would love some feedback if anyone is interested in these items. >> >> G'night all. >> > > Great stuff Dale, I wonder if ipa user-mod --addattr could be used to > load the avatar, instead of using ldap commands. > > Simo. > I linked your articles from FreeIPA wiki: http://www.freeipa.org/page/HowTos#Fancy_things_.28user_Avatars_etc..29 Re: https://www.dalemacartney.com/2013/12/05/adding-display-picturesavatars-red-hat-idmfreeipa/ > In LDAP based systems, the attribute is ?jpegPhoto? and in Active Directory, although ?jpegPhoto? is available, Microsoft applications seem to use the ?thumbnailPhoto? value. You could do a experiment with attribute aliases. As usual - try this in a staging environment first, I haven't tested that! Modify /etc/dirsrv/slapd-EXAMPLE-COM/schema/06inetorgperson.ldif attributeTypes: ( 0.9.2342.19200300.100.1.60 NAME 'jpegPhoto' to NAME ('jpegPhoto', 'thumbnailPhoto') and restart directory server. Please let us know how it works :-) -- Petr^2 Spacek From jhrozek at redhat.com Fri Dec 6 08:03:49 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 6 Dec 2013 09:03:49 +0100 Subject: [Freeipa-users] Problems with FreeIPA-client configuration on OpenSUSE 12.2 In-Reply-To: <20131205084911.GB5496@hendrix.redhat.com> References: <529DB390.8030104@intech-global.com> <52A03304.1080904@intech-global.com> <20131205084911.GB5496@hendrix.redhat.com> Message-ID: <20131206080349.GB14531@hendrix.redhat.com> On Thu, Dec 05, 2013 at 09:49:11AM +0100, Jakub Hrozek wrote: > On Thu, Dec 05, 2013 at 12:02:12PM +0400, ???????? ?????? wrote: > > > > Hello community, I have problems with FreeIPA-client configuration > > on OpenSUSE 12.2, and I think I can't fix it without your help. I > > have following errors in my /var/log/messages, when I try login in > > by freeipa account: > > > > ############################################################ > > Dec 2 18:21:24 linux-l3wy sshd[12481]: Invalid user admin from > > 192.168.0.159 > > Dec 2 18:21:24 linux-l3wy sshd[12481]: input_userauth_request: > > invalid user admin [preauth] > > Dec 2 18:21:24 linux-l3wy sssd_be: No worthy mechs found > > Dec 2 18:21:24 linux-l3wy sshd[12481]: Postponed > > keyboard-interactive for invalid user admin from 192.168.0.159 port > > 38175 ssh2 [preauth] > > Dec 2 18:21:41 linux-l3wy sshd[12484]: pam_sss(sshd:auth): > > authentication failure; logname= uid=0 euid=0 tty=ssh ruser= > > rhost=192.168.0.159 user=admin > > Dec 2 18:21:41 linux-l3wy sshd[12484]: pam_sss(sshd:auth): received > > for user admin: 10 (User not known to the underlying authentication > > module) > > Dec 2 18:21:41 linux-l3wy sshd[12481]: error: PAM: User not known > > to the underlying authentication module for illegal user admin from > > 192.168.0.159 > > Dec 2 18:21:41 linux-l3wy sshd[12481]: Failed > > keyboard-interactive/pam for invalid user admin from 192.168.0.159 > > port 38175 ssh2 > > Dec 2 18:21:41 linux-l3wy sshd[12481]: Postponed > > keyboard-interactive for invalid user admin from 192.168.0.159 port > > 38175 ssh2 [preauth] > > Dec 2 18:21:50 linux-l3wy sshd[12481]: Connection closed by > > 192.168.0.159 [preauth] > > ############################################################ > > Hi Sergey, > > are you able to run "getent passwd admin" from the command line? SSH is > complaining that admin is not a known account. > > I suspect that for whatevet reason the sssd is unable to connect to the > IPA servers. getent passwd admin or id admin don't return anything, you > should put debug_level=6 into the [domain] section, restart sssd and > then check out /var/log/sssd/sssd_example.com log. btw Sergey sent me the SSSD logs directly and it seems he was missing cyrus-sasl-gssapi, which sounds like SUSE packaging bug. From dbmacartney at gmail.com Fri Dec 6 09:10:10 2013 From: dbmacartney at gmail.com (Dale Macartney) Date: Fri, 06 Dec 2013 09:10:10 +0000 Subject: [Freeipa-users] Adding Display Pictures/Avatars into FreeIPA In-Reply-To: <1386284285.3255.98.camel@willson.li.ssimo.org> References: <52A0FF13.4080003@gmail.com> <1386284285.3255.98.camel@willson.li.ssimo.org> Message-ID: <52A19472.3000507@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/12/13 22:58, Simo Sorce wrote: > On Thu, 2013-12-05 at 22:32 +0000, Dale Macartney wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi folks >> >> Just a quick mail from me before I call it a night. >> >> Today I've added user display pictures/avatars into FreeIPA, detailed here. >> >> https://www.dalemacartney.com/2013/12/05/adding-display-picturesavatars-red-hat-idmfreeipa/ >> >> As well as pulling those images into a GNOME3 desktop session, detailed >> here. >> >> https://www.dalemacartney.com/2013/12/05/loading-display-picturesavatars-red-hat-idmfreeipa-gnome3/ >> >> Would love some feedback if anyone is interested in these items. >> >> G'night all. >> > > Great stuff Dale, I wonder if ipa user-mod --addattr could be used to > load the avatar, instead of using ldap commands. > > Simo. G'day Simo Thanks for the suggestion however I haven't been able to do it with an ipa command for this task. I've tried the following: [root at ds01 ~]# ipa user-mod --addattr="objectClass=jpegPhoto" --addattr="jpegPhoto:< file:///root/hulk.jpg" bbanner ipa: ERROR: invalid 'addattr': Invalid format. Should be name=value [root at ds01 ~]# [root at ds01 ~]# [root at ds01 ~]# ipa user-mod --addattr="objectClass=jpegPhoto" --addattr="jpegPhoto:/root/hulk.jpg" bbanner ipa: ERROR: invalid 'addattr': Invalid format. Should be name=value [root at ds01 ~]# ipa user-mod --addattr="objectClass=jpegPhoto" --addattr="jpegPhoto=< file:///root/hulk.jpg" bbanner ipa: ERROR: unknown object class "jpegPhoto" [root at ds01 ~]# ipa user-mod --addattr="jpegPhoto=< file:///root/hulk.jpg" bbanner - ----------------------- Modified user "bbanner" - ----------------------- User login: bbanner First name: Bruce Last name: Banner Home directory: /home/bbanner Login shell: /bin/sh Email address: bbanner at example.com UID: 212800012 GID: 212800012 Account disabled: False Password: False Member of groups: ipausers Kerberos keys available: False [root at ds01 ~]# ipa user-show --all bbanner dn: uid=bbanner,cn=users,cn=accounts,dc=example,dc=com User login: bbanner First name: Bruce Last name: Banner Full name: Bruce Banner Display name: Bruce Banner Initials: BB Home directory: /home/bbanner GECOS field: Bruce Banner Login shell: /bin/sh Kerberos principal: bbanner at EXAMPLE.COM Email address: bbanner at example.com UID: 212800012 GID: 212800012 Account disabled: False Password: False Member of groups: ipausers Kerberos keys available: False ipauniqueid: b4009286-5e53-11e3-9d5e-001a4a0000bb jpegphoto: PCBmaWxlOi8vL3Jvb3QvaHVsay5qcGc= krbpwdpolicyreference: cn=global_policy,cn=EXAMPLE.COM,cn=kerberos,dc=example,dc=com mepmanagedentry: cn=bbanner,cn=groups,cn=accounts,dc=example,dc=com objectclass: top, person, organizationalperson, inetorgperson, inetuser, posixaccount, krbprincipalaux, krbticketpolicyaux, ipaobject, ipasshuser, ipaSshGroupOfPubKeys, mepOriginEntry [root at ds01 ~]# You can see that the last command of " ipa user-mod --addattr="jpegPhoto=< file:///root/hulk.jpg" bbanner" however as the jpegPhoto attribute is encoded with base64, it appears to be encoding the characters "< file:///root/hulk.jpg" instead of the image file. The above details from showing the user after the change only shows the following text for jpegPhoto jpegphoto: PCBmaWxlOi8vL3Jvb3QvaHVsay5qcGc= When using ldapmodify, that attribute looks like the following [root at ds01 ~]# ipa user-show --all bbanner dn: uid=bbanner,cn=users,cn=accounts,dc=example,dc=com User login: bbanner First name: Bruce Last name: Banner Full name: Bruce Banner Display name: Bruce Banner Initials: BB Home directory: /home/bbanner GECOS field: Bruce Banner Login shell: /bin/sh Kerberos principal: bbanner at EXAMPLE.COM Email address: bbanner at example.com UID: 212800012 GID: 212800012 Account disabled: False Password: False Member of groups: ipausers Kerberos keys available: False ipauniqueid: b4009286-5e53-11e3-9d5e-001a4a0000bb jpegphoto: /9j/4AAQSkZJRgABAgAAAQABAAD/4AAcT2NhZCRSZXY6IDE0Nzk3ICQAAAAAAAAAABj/2wCEAAIEBAYIBggICAgICAgICAgKCgoKCgoKCgoKCgoKCgoKCgoKCgwMDAwMDAwMDA0MDAwMDAwMDAwODw0MDgwMDAwBAhAQICAgICAgIEBAQEBAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgP/AABEIAHgAeAMBEQACEQEDEQH/xACVAAACAwEBAQEAAAAAAAAAAAAGBwQFCAMJAgEBAAIDAQEBAAAAAAAAAAAAAAMEAgUGAQAHEAABAgQDBAcHAQUGBwAAAAABAgMABBEhBRIxEyJBUQYyYXGhsfAHFEJSgZHRchUjYsHhFyRDgqLxFjNTY5LC4hEBAAMAAgICAgMAAAAAAAAAAAECEQMSITETQVFhBCIy/9oADAMBAAIRAxEAPwDyylFuEUICFDUEXjYMcNW5Z6lcyY88nNMO15x5wUZDlvrHkURSecdeQdjXtP38o4gIX2mJFsPzIdIAqEJBFf1G1vVIxFuT8LmKhj+1x2WSUyMpJBR1LzWc053oi3OhMZWaTP21MGpgPthmJlSP2kMPlJdI/eObAKUU/KhkEFS1aJJyhOphH4v2L2a+wX2j9GMTddlkYMpiQYb2jk66uq0iyc+UJV1j8INBzEVvSfy5oUxae6AMvqdDjj7ShTdUEEk65UjNXLqBat7xcxNyWQiq9mzEwht6SU661MIzs2utP6zQVTxSog8BWsXvyyQmrOuJdD5xGdaRuINDn3VD9QVQjupfgYvK8xCakg9LlJvSvYa+X5jVkFKtETcEjrexdyqACt3XVQ7LfcG8cREraqi3lTziQQgZR2R4JILceQRlM17/ALx4URLYk5CTM9NO0Ashuikkr4aEa8E1vzEYa/J9L+tWIukvS6bxJ3fIDCDRtGUJ+q8uvaTpwhSK4uilWtSTWu9w599/KLF52adHWWoqVWw6x/1GnnHAxqjpBNoQtll1SS+kJcVWm58m7S3EgWPKAvB159tIQUOrcUn5hlpzyd+lTEkRnL9M8TYVVuZmNwp2dXXN2l90FVBTkKAwHq4eWLe1zEZsS0y6ltc0k5H1lNdokDdC6nerc1IsYUmmpQYeF9IcKxJpSFNNMTXw0SQCTpqrL3GtK6iFotNUJgPz+GTDCyl1tST3UHruMfRK21mpMWZky65mKSSDWsF0HHRuRcr1Se6PbAmLT3NxPwn19I92AxyUmgodYZKpuHyaluppxOulB3/7xV3t4NQy17R8eS9Ne6tL/u8vupA1Uv43Promp04R89rH23DLyVUPLvv6+kaBxXr8/XGCOOdImEsWhQZ1A04cL/0gaS1alyogJRmqLnkT38uZiGvKRzxHLT0YI65HNHnF7ITJQ4FJVlI7aeYPiIXlx6ISs0J7CG3SHcyElKyF5k7vNBBPeQSCLiKek5JSz0qw3Fegsum7aH6arcJV9dQO+gj5/N7Nd1MSU6fdAeqZWVok3VsqfzBgXeQuojRMdAcSWUISltSq0LalIT41+1Il80p9SyxH2S4S84VSM+mijZLlFf62yfEVjU1/kKaeNkb2n9HnujOHoW+6znmCpLIbVmXUC6qEcK2UQQOFTDvfs50eNT721dUs1ueOpP1PHnwi/SlTnrdvhDQbjSp1qfCCOJhZQn4syuz1w7LQIVeN1J305koFf0nnbwB10gQLudqtsoGRpsG5KqKJ7hc9wFI4gDymleN/vDaa3okhPK1fKvkaQJ1SZd6Dhtf+zyff2K5Q1CFEuIVwqnVJqfsKit4o59l5CisUeV8VIzeNcgKmnq1C1174JhUS4Zjs9LKzsukV4V9fiFpqLp6YJ7SJ6XfDylLzV3wk2VT1yikmhhnT2h9LJjFJ4zDzqlq4JKlKyJ+UZictdcotG246KaZIqWQVrCcpIPL+nPSL+S5kDo277vt122hUU23qJ+TgO8/QRnvk+jvVWJ6Pv5Mxy5TfMTbxHDjB+4vVClpDaBWw3spoXPnPytIPipVof7Z7ICJMhvCtd07/ABG0+W3y+J7IV0ulmVSVVWWjZRucvZenOFdehMd6P50obLeQpC1lSVpcqFWRRFtOPGl+EWESiWf7PebaC1CsusqRmHNPiCLKvqNK0h7XFBlUlVdaClPX3tDDrbXsxk0OSs4oKTTZZi2TRSSPiFdRwINxqNYy1p/tAcs9Zh9a98caFJBqgGnGleFeR4wJxFzGtq15RNAQsSEy5TdsfoD/ALcYUHLfEpDLUqVVRUAkAW7eXV4698aKsquYbF9kfRVp2VmZt5AUmuRuum7dRt9o+UfyuXzEQ2/FTQH05xhlx9Mq23lbYSE0G6qvxKOUnXhXSLfhr9kOSWfVOPBrJtFFCz1DrQX489OHGN4z0ybuFFgsNusqNWt1xvjTnbgdK84zVjA1Rs2fdKpzFbm0WPnrv9m6NOceVi7wfDk4hOvPPLal0JO8coSlCeATY3Og4mFZkYeY3IyvujZk07dT5yZyndG7kSEVvuipJNOJ0EGiVaSmLYIpKUIzJWyhopISQQFZfmFTvbxKT1VaRbRYJlGYUoAJrdJI/wDE/wA41Zl6VewroujFEPtlxDOZtwtqV/1B/h/5hcE1jC8k5MG8YRJqk6xcnE5KnNnwSlViOZ5/g8IEILcKZbZQpx4glW7l6x/PbFdYyM5zEUtSWcFKSfr37t9Yq6x5MSCEOsziZdSm85CHEZUih2qlKyZqGpvQlWiRakXnos9AGG1YdgbbTVAlLYbqnXPqtVr7xuOenZHwKZ7Wbz1DC3SDBi49t0qOZYvrX/NxtqdY+01tnhh5qT8y0wnOFl4FKNwJooFX8ZURQcbAnhreNfWWdlAw7EXmVhQFRW/8Q7eNuRg9oebBwfGG8QTMTE2wE+5yu0OQZeoMqFZDTXdTQcKqJjMTUUXdHcf6PrkFB1Di5kLzJaSndf3aAZjZtKdVKUe6sJdJemRLP9JJuY2bctJyjLKEpQkbWqafH1SK14i1u+HMVyM5Kzam0pflWWkrOXaS5SWwa7qspv2GgqIWkNgfpVhhlsTfa+Ut6fxpzcftWNjSfBtpP2cY1MSTOdtSkpOtOz8G1ReMzyRo2suIc41Prvi9MPgvGutY85q3amj1ian+XrwhXB9Xk+8iZZGUFJSKkVypHOhr5iAV9iSP/Zy0j9oID9NkEOONp5qpQa0PbS3lFTz+j3H7aQ6TTrrbWRF8xP31pr9RWPl/FDT3kmZXG00O0TWlu3x8bxtZqo9CWITcndS0BSldVCbn7CvnY6xdViSsg5tpsu1LCWQvkakfU8+Qi1mSzUnRBp11uYalm6JOWuc0QlNN41sd7TLmy0uRwjNSqLEx0r6IY21MkLZSGgnOlTW62tB4gJAG7xAJOto1lbQQHUh0VU1JOzzfvLOybbUhtRS8hxzNvoqmuTKi6SsArVpSEJkmefRuXemmXHC0UtVScpV1lU6yUk1T81KRmZNMf9N2s/SmbCUlaGVMpXb/ALSa6+WutI3FP8mlhLIMuoN8A2nMkWub/wBO+EbAM3JcjSm0pIUTpAkzNlsAVlBW6hBN8tM1O8jyijm61xwEjl610Zj+k5PVoF2dx9pfO0SUVBSd31/KIoiiaxp95H7wiuWml/PjzivihvQnMuIaASmq1HX+I9t/pWLSIVqTIIyL2hyqcPPRI5Dy7RELSZhfpmPdXg4UJWlWqFVUEngQk/L1hltXnCuaJr0B6NS+FuYM0rZvF15a84ClNpUn4RtMpyDUnUk2EZyWemTAw2QcRiTmFTF5ScZM3KAuBzIpNnmkOdvW7T9YdANL/hQBClNpRlUGwodXaK0uEnhxFIUTBuLyjaMqUJRVpzIrLYDLqn6DWlqawkg88ZqRozMzxpWemVlJXuqJqpe6DqimUIV86a6ExuN9IFYG3q7XPqqhJ62vGGPy4RTTSuUXkrIwGJRzKFZT/Pv52in1ZC1Mk/s7vIob2VWn0F4pdNq+afNEIzVCRaDQ8Glruew1i1JPpK/ira9O0/N/SIuuOxWTU1/9vRiYQvwaTnn1/wB22RVc5VnMT2UAPfSFbTA61VheJKyuLl1EOLCAUbwzEdXKDXu4QDx+SbTXQvGVsPKkJyY90KaIyzSFN0roM4smvAGxF4rbEzn6TPPsS7U2r/m4XNIXYpKXGl7q0pKeCkHMeAPOEazqvM7EukM2hLWUryOlNyq6hQUUrKfh4XFaUhOZFAmMTiJaUmpt9RcCEKUco3lAnfHHf+EZteJgUeZdefGM9KXcRnS8hBblkrytNKUCpCeBVlCUlVLUTRKeqkUqT9E648nvzMs00ClVVvV2nNI/J1rwirwMinG1J4U9dsXa4TBNrylJvw19acuMDwxr7w6XdcWSnOclzl19fSOWGSHz+9oiu6ONj+n8RCHkJS696oKC7y1K1UKkcNB64xGXRhNKcThbz1AFZ0oBzCu/1iATU003erWp1EL19kJI6VnX2F5mXFtKoRmQopNDqLHjpSNYE0dgvtQnGNkiZYZmWW1hVB+6cqE5RvJBFr2KbxmZ4oTaM/tm6OvtTHveDOOuTM1LKWmrakhiXG6MyqFS1aKTRKaXBtSK34v2igYbjSMRwecS0lbbRdcCG17wbY6+yz/K2TlQTSqdYo7VySZ+yk7tPd0qACUst5hxAy5kkgU13eApFVKCXiOHMz0ouSeWZdp5BClV6qfgUa36+U5b1vWkcrPl558410bncODG3S1lcTZTdxmRYpV/GetUcNI+ibqZYuv11+nr8wyOY7zSFCtK9tPxy5RmtWoSewyt0m/r13RZxZFQ/wB5aVbN3iG3hRLlLgJShSndVHsHyjzhCTAPdUELPKsWiCwT1+daH1+YWdNQOybuHrZFDNbF8JzJSQM5RTJmUnKaJoVipGmU1qOQrpZYUg1obHiDr43jVhOdI88lIYWb0N9O31pANSbm6Ays03hsyjKoIfaWb6VFrV5j6GkfPuT2UO1547WxNmU7TerU9X4bmtrfiKdBeTeEYpM4c8WVuJzUyml1lI6thXIezjePVQZIxqZnVs7CZStNrVuAtH0rXvoQKxqIdZ/fQR+YvYMG2Jm1/X356RksXmu7bYWqp3e45vXKJvLtElXiDr9vXjAEUlGFuqTVrLn0BSKG/CmvZw74lqJVYzgUxL7zjZRU9WoVl+x8DeNBFi6kSw4nIF/FdKuBH9OMEky4LG/mO0SUGzid7LfiOzsMFTEbM4h0/v5dqb69VJ3XTX4idd3UDjfnHig2lcK6IqcrNpxiSbzJ6iUubuSquugbylUSkVIANbgQPtIZ99CsBwyaWw6zLuIZZTmWZpCMyngpWRLZBNGEINVlQqtzUmgEUtpQN/FHkhKmWUhDZOW2gbQNaAdZRuAm1KxnSKs/ZDjeHmdWCkrNGW/iv/iLpe/WANLX7II41s5PrwfBlTrq2jMNNIb2ahurzJra9/1WrAvt5gtOJIx33lx1lLS20hwFHWr2Chr+njwNou8AZG6SyDzD1es2bJUBbuPaI0VZMi5MsBUmqqn165xltafEMtqScwzDy8IYL4ImJ4oF0oPKo/29c4GGsJPFdm6pYGWoNALivj308ogWUU3OPPLJIBCjavD1qbQ4kIXcEbcw8hvP7xRK05wAA6NUtqBoUOJsDa8EiQdJiUngnMlKcq60roUkcKH7EGHphY6JJKRZffSClKa3K6qSP9Ir9hSAkm+sC6N4kmRztvzS2PlzNTCECmpS6gkV4EKqBYxn7SRELypeWZO1ogAZ1ZhQkfpT8A1A58IroAKTDOmGHTGIu59xtkgt2zld76WTQaVoAKxdTVwFdLvaMVTbgk6+76ZaApqOVPtUQ/WjzPE103xKZa2My8641ly5TfdHUrx3e+LaKDhhjGHWQQ2VJSrUCw8PD6wXEn4vGH1JUCapX1greHj56xHHDo2m6Sbnjbh2/wDyI+etZqMU1+HXTKfWnoRZEJDzqk1Kan7fiHCaksTqnu0ht4SNSinFoQK31KeA4m3Lx0gIbTeAYRvJIFUFKRUkZKdxIPfxpFfMgKf2lYThSGG1hoNvZqbRISlZ/UpI30cgQSDeHaWRY4l1vB2rayeHI+HnF1JvGl5Hp5ictJpl2iU9auc7t/0mp+appGexDqS2IYnic0twvzCiFa0NE05ISPMmsaGCuFwiWFSkKOU+ufnDqK5ZlkVABoDbs8IW1ISpw6VpvZxX4hlPlTWA6i4NyDal7NKq/JXd+nG/ZHdLrBWCPilGVGulN6p+kc1N/9k= krbpwdpolicyreference: cn=global_policy,cn=EXAMPLE.COM,cn=kerberos,dc=example,dc=com mepmanagedentry: cn=bbanner,cn=groups,cn=accounts,dc=example,dc=com objectclass: top, person, organizationalperson, inetorgperson, inetuser, posixaccount, krbprincipalaux, krbticketpolicyaux, ipaobject, ipasshuser, ipaSshGroupOfPubKeys, mepOriginEntry [root at ds01 ~]# Any ideas? I think getting this working via ipa user-mod would be a better option as I don't like having people using the Directory manager account when they don't need to. > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSoZRwAAoJEAJsWS61tB+qsHsP/0m6PsFOjTEcCg7LJFV4DXiE fQHkeVXupApSa/OhutAxfQWt827EUhjwXmijEZ/zx2nvEMHT35LKV+ahuUAK3vqR IK18AjaoC9dRDX8jeth6r+iAT54D4eTywbs/SofjduQRmFE3/Hn+x0haXmKgTLhW khSIGvSuai7kdnKPuthhwtMclBLZxvLfSzmr5auJ7J8bn/2ThLvJVdWzgafIk+3l 5oWSqzeU+TFJP/m8abM45DMWsytBcvAxV9QmPouKUhHzrAkQnycP5+74+DfQMGGe 2SVpYTDWToB3yH/kziaiKSnqiSbmOBAmzo3BvdMjb6Dl3xWtxe1nqWjE+w+lC0NM zndPF2SKw7G4Tj0voykJeg3LlgjI7Sc+RvMmQ6PhoZ5oTgHDyl6GSw/IRpzJU7KY j2nS83HTgeAoRpruIb8brkt8bgt8FJ+bbiq8qCpS7ZU15h+2e+z+vw5c0R4IktY8 skKYHc8p3r34J8LHUTbWrjMgHRxMCDTMs7X/dccD3cKspLFiwjjlJWa080XIvkLl A1B0y4qzQqD9GyQoFqZOQY1RElVvfJqoTbGsZ0W8IGkoyWsDiek8J/dNhSTVyig6 hXJ5fGHGYrGRNm32re2uA4vzBK+JWzmzNHxUNy4JYvfhPP7yPgcO/cjV2QBJ9Su3 huHeBHif6xVk32enSqAR =sy64 -----END PGP SIGNATURE----- From mkosek at redhat.com Fri Dec 6 09:48:34 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 06 Dec 2013 10:48:34 +0100 Subject: [Freeipa-users] Adding Display Pictures/Avatars into FreeIPA In-Reply-To: <52A19472.3000507@gmail.com> References: <52A0FF13.4080003@gmail.com> <1386284285.3255.98.camel@willson.li.ssimo.org> <52A19472.3000507@gmail.com> Message-ID: <52A19D72.1070305@redhat.com> On 12/06/2013 10:10 AM, Dale Macartney wrote: > > > On 05/12/13 22:58, Simo Sorce wrote: >> On Thu, 2013-12-05 at 22:32 +0000, Dale Macartney wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>> >>> Hi folks >>> >>> Just a quick mail from me before I call it a night. >>> >>> Today I've added user display pictures/avatars into FreeIPA, detailed > here. >>> >>> > https://www.dalemacartney.com/2013/12/05/adding-display-picturesavatars-red-hat-idmfreeipa/ >>> >>> > As well as pulling those images into a GNOME3 desktop session, detailed >>> here. >>> >>> > https://www.dalemacartney.com/2013/12/05/loading-display-picturesavatars-red-hat-idmfreeipa-gnome3/ >>> >>> > Would love some feedback if anyone is interested in these items. >>> >>> G'night all. >>> > >> Great stuff Dale, I wonder if ipa user-mod --addattr could be used to >> load the avatar, instead of using ldap commands. > >> Simo. > G'day Simo Thanks for the suggestion however I haven't been able to do it > with an ipa command for this task. > > I've tried the following: > > [root at ds01 ~]# ipa user-mod --addattr="objectClass=jpegPhoto" > --addattr="jpegPhoto:< file:///root/hulk.jpg" bbanner ipa: ERROR: invalid > 'addattr': Invalid format. Should be name=value [root at ds01 ~]# [root at ds01 > ~]# [root at ds01 ~]# ipa user-mod --addattr="objectClass=jpegPhoto" > --addattr="jpegPhoto:/root/hulk.jpg" bbanner ipa: ERROR: invalid > 'addattr': Invalid format. Should be name=value [root at ds01 ~]# ipa > user-mod --addattr="objectClass=jpegPhoto" --addattr="jpegPhoto=< > file:///root/hulk.jpg" bbanner ipa: ERROR: unknown object class > "jpegPhoto" [root at ds01 ~]# ipa user-mod --addattr="jpegPhoto=< > file:///root/hulk.jpg" bbanner ----------------------- Modified user > "bbanner" ----------------------- User login: bbanner First name: Bruce > Last name: Banner Home directory: /home/bbanner Login shell: /bin/sh Email > address: bbanner at example.com UID: 212800012 GID: 212800012 Account > disabled: False Password: False Member of groups: ipausers Kerberos keys > available: False [root at ds01 ~]# ipa user-show --all bbanner dn: > uid=bbanner,cn=users,cn=accounts,dc=example,dc=com User login: bbanner > First name: Bruce Last name: Banner Full name: Bruce Banner Display name: > Bruce Banner Initials: BB Home directory: /home/bbanner GECOS field: Bruce > Banner Login shell: /bin/sh Kerberos principal: bbanner at EXAMPLE.COM Email > address: bbanner at example.com UID: 212800012 GID: 212800012 Account > disabled: False Password: False Member of groups: ipausers Kerberos keys > available: False ipauniqueid: b4009286-5e53-11e3-9d5e-001a4a0000bb > jpegphoto: PCBmaWxlOi8vL3Jvb3QvaHVsay5qcGc= krbpwdpolicyreference: > cn=global_policy,cn=EXAMPLE.COM,cn=kerberos,dc=example,dc=com > mepmanagedentry: cn=bbanner,cn=groups,cn=accounts,dc=example,dc=com > objectclass: top, person, organizationalperson, inetorgperson, inetuser, > posixaccount, krbprincipalaux, krbticketpolicyaux, ipaobject, ipasshuser, > ipaSshGroupOfPubKeys, mepOriginEntry [root at ds01 ~]# > > You can see that the last command of " ipa user-mod --addattr="jpegPhoto=< > file:///root/hulk.jpg" bbanner" however as the jpegPhoto attribute is > encoded with base64, it appears to be encoding the characters "< > file:///root/hulk.jpg" instead of the image file. > > The above details from showing the user after the change only shows the > following text for jpegPhoto jpegphoto: PCBmaWxlOi8vL3Jvb3QvaHVsay5qcGc= > > When using ldapmodify, that attribute looks like the following > > [root at ds01 ~]# ipa user-show --all bbanner dn: > uid=bbanner,cn=users,cn=accounts,dc=example,dc=com User login: bbanner > First name: Bruce Last name: Banner Full name: Bruce Banner Display name: > Bruce Banner Initials: BB Home directory: /home/bbanner GECOS field: Bruce > Banner Login shell: /bin/sh Kerberos principal: bbanner at EXAMPLE.COM Email > address: bbanner at example.com UID: 212800012 GID: 212800012 Account > disabled: False Password: False Member of groups: ipausers Kerberos keys > available: False ipauniqueid: b4009286-5e53-11e3-9d5e-001a4a0000bb > jpegphoto: > /9j/4AAQSkZJRgABAgAAAQABAAD/4AAcT2NhZCRSZXY6IDE0Nzk3ICQAAAAAAAAAABj/2wCEAAIEBAYIBggICAgICAgICAgKCgoKCgoKCgoKCgoKCgoKCgoKCgwMDAwMDAwMDA0MDAwMDAwMDAwODw0MDgwMDAwBAhAQICAgICAgIEBAQEBAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgP/AABEIAHgAeAMBEQACEQEDEQH/xACVAAACAwEBAQEAAAAAAAAAAAAGBwQFCAMJAgEBAAIDAQEBAAAAAAAAAAAAAAMEAgUGAQAHEAABAgQDBAcHAQUGBwAAAAABAgMABBEhBRIxEyJBUQYyYXGhsfAHFEJSgZHRchUjYsHhFyRDgqLxFjNTY5LC4hEBAAMAAgICAgMAAAAAAAAAAAECEQMSITETQVFhBCIy/9oADAMBAAIRAxEAPwDyylFuEUICFDUEXjYMcNW5Z6lcyY88nNMO15x5wUZDlvrHkURSecdeQdjXtP38o4gIX2mJFsPzIdIAqEJBFf1G1vVIxFuT8LmKhj+1x2WSUyMpJBR1LzWc053oi3OhMZWaTP21MGpgPthmJlSP2kMPlJdI/eObAKUU/KhkEFS1aJJyhOphH4v2L2a+wX2j9GMTddlkYMpiQYb2jk66uq0iyc+UJV1j8INBzEVvSfy5oUxae6AMvqdDjj7ShTdUEEk65UjNXLqBat7xcxNyWQiq9mzEwht6SU661MIzs2utP6zQVTxSog8BWsXvyyQmrOuJdD5xGdaRuINDn3VD9QVQjupfgYvK8xCakg9LlJvSvYa+X5jVkFKtETcEjrexdyqACt3XVQ7LfcG8cREraqi3lTziQQgZR2R4JILceQRlM17/ALx4URLYk5CTM9NO0Ashuikkr4aEa8E1vzEYa/J9L+tWIukvS6bxJ3fIDCDRtGUJ+q8! uv! > > aTpwhSK4uilWtSTWu9w599/KLF52adHWWoqVWw6x/1GnnHAxqjpBNoQtll1SS+kJcVWm58m7S3EgWPKAvB159tIQUOrcUn5hlpzyd+lTEkRnL9M8TYVVuZmNwp2dXXN2l90FVBTkKAwHq4eWLe1zEZsS0y6ltc0k5H1lNdokDdC6nerc1IsYUmmpQYeF9IcKxJpSFNNMTXw0SQCTpqrL3GtK6iFotNUJgPz+GTDCyl1tST3UHruMfRK21mpMWZky65mKSSDWsF0HHRuRcr1Se6PbAmLT3NxPwn19I92AxyUmgodYZKpuHyaluppxOulB3/7xV3t4NQy17R8eS9Ne6tL/u8vupA1Uv43Promp04R89rH23DLyVUPLvv6+kaBxXr8/XGCOOdImEsWhQZ1A04cL/0gaS1alyogJRmqLnkT38uZiGvKRzxHLT0YI65HNHnF7ITJQ4FJVlI7aeYPiIXlx6ISs0J7CG3SHcyElKyF5k7vNBBPeQSCLiKek5JSz0qw3Fegsum7aH6arcJV9dQO+gj5/N7Nd1MSU6fdAeqZWVok3VsqfzBgXeQuojRMdAcSWUISltSq0LalIT41+1Il80p9SyxH2S4S84VSM+mijZLlFf62yfEVjU1/kKaeNkb2n9HnujOHoW+6znmCpLIbVmXUC6qEcK2UQQOFTDvfs50eNT721dUs1ueOpP1PHnwi/SlTnrdvhDQbjSp1qfCCOJhZQn4syuz1w7LQIVeN1J305koFf0nnbwB10gQLudqtsoGRpsG5KqKJ7hc9wFI4gDymleN/vDaa3okhPK1fKvkaQJ1SZd6Dhtf+zyff2K5Q1CFEuIVwqnVJqfsKit4o59l5CisUeV8VIzeNcgKmnq1C1174JhUS4Zjs9LKzsukV4V9fiFpqLp6YJ7SJ6XfDylLzV3wk2VT1yikmhhnT2h9LJjFJ4zDzqlq4JKlKyJ+UZictdcotG246KaZIqWQVrCcpI! > PL+nPSL+S5kDo277vt122hUU23qJ+TgO8/QRnvk+jvVWJ6Pv5Mxy5TfMTbxHDjB+4vVClp > DaBWw3spoXPnPytIPipVof7Z7ICJMhvCtd07/ABG0+W3y+J7IV0ulmVSVVWWjZRucvZenOFdehMd6P50obLeQpC1lSVpcqFWRRFtOPGl+EWESiWf7PebaC1CsusqRmHNPiCLKvqNK0h7XFBlUlVdaClPX3tDDrbXsxk0OSs4oKTTZZi2TRSSPiFdRwINxqNYy1p/tAcs9Zh9a98caFJBqgGnGleFeR4wJxFzGtq15RNAQsSEy5TdsfoD/ALcYUHLfEpDLUqVVRUAkAW7eXV4698aKsquYbF9kfRVp2VmZt5AUmuRuum7dRt9o+UfyuXzEQ2/FTQH05xhlx9Mq23lbYSE0G6qvxKOUnXhXSLfhr9kOSWfVOPBrJtFFCz1DrQX489OHGN4z0ybuFFgsNusqNWt1xvjTnbgdK84zVjA1Rs2fdKpzFbm0WPnrv9m6NOceVi7wfDk4hOvPPLal0JO8coSlCeATY3Og4mFZkYeY3IyvujZk07dT5yZyndG7kSEVvuipJNOJ0EGiVaSmLYIpKUIzJWyhopISQQFZfmFTvbxKT1VaRbRYJlGYUoAJrdJI/wDE/wA41Zl6VewroujFEPtlxDOZtwtqV/1B/h/5hcE1jC8k5MG8YRJqk6xcnE5KnNnwSlViOZ5/g8IEILcKZbZQpx4glW7l6x/PbFdYyM5zEUtSWcFKSfr37t9Yq6x5MSCEOsziZdSm85CHEZUih2qlKyZqGpvQlWiRakXnos9AGG1YdgbbTVAlLYbqnXPqtVr7xuOenZHwKZ7Wbz1DC3SDBi49t0qOZYvrX/NxtqdY+01tnhh5qT8y0wnOFl4FKNwJooFX8ZURQcbAnhreNfWWdlAw7EXmVhQFRW/8Q7eNuRg9oebBwfGG8QTMTE2wE+5yu0OQZeoMqFZDTXdTQcKqJjMTUUXdHcf6PrkFB1Di5kLzJaSndf3aAZjZtKdVKUe6sJdJemRLP9JJuY2bctJyjL! KE! > > pQkbWqafH1SK14i1u+HMVyM5Kzam0pflWWkrOXaS5SWwa7qspv2GgqIWkNgfpVhhlsTfa+Ut6fxpzcftWNjSfBtpP2cY1MSTOdtSkpOtOz8G1ReMzyRo2suIc41Prvi9MPgvGutY85q3amj1ian+XrwhXB9Xk+8iZZGUFJSKkVypHOhr5iAV9iSP/Zy0j9oID9NkEOONp5qpQa0PbS3lFTz+j3H7aQ6TTrrbWRF8xP31pr9RWPl/FDT3kmZXG00O0TWlu3x8bxtZqo9CWITcndS0BSldVCbn7CvnY6xdViSsg5tpsu1LCWQvkakfU8+Qi1mSzUnRBp11uYalm6JOWuc0QlNN41sd7TLmy0uRwjNSqLEx0r6IY21MkLZSGgnOlTW62tB4gJAG7xAJOto1lbQQHUh0VU1JOzzfvLOybbUhtRS8hxzNvoqmuTKi6SsArVpSEJkmefRuXemmXHC0UtVScpV1lU6yUk1T81KRmZNMf9N2s/SmbCUlaGVMpXb/ALSa6+WutI3FP8mlhLIMuoN8A2nMkWub/wBO+EbAM3JcjSm0pIUTpAkzNlsAVlBW6hBN8tM1O8jyijm61xwEjl610Zj+k5PVoF2dx9pfO0SUVBSd31/KIoiiaxp95H7wiuWml/PjzivihvQnMuIaASmq1HX+I9t/pWLSIVqTIIyL2hyqcPPRI5Dy7RELSZhfpmPdXg4UJWlWqFVUEngQk/L1hltXnCuaJr0B6NS+FuYM0rZvF15a84ClNpUn4RtMpyDUnUk2EZyWemTAw2QcRiTmFTF5ScZM3KAuBzIpNnmkOdvW7T9YdANL/hQBClNpRlUGwodXaK0uEnhxFIUTBuLyjaMqUJRVpzIrLYDLqn6DWlqawkg88ZqRozMzxpWemVlJXuqJqpe6DqimUIV86a6ExuN9IFYG3q7XPqqhJ62vGGPy4RTTSuUXkrIwGJRzKFZT/Pv52in1ZC1Mk/s7vIob2VWn! > 0F4pdNq+afNEIzVCRaDQ8Glruew1i1JPpK/ira9O0/N/SIuuOxWTU1/9vRiYQvwaTnn1/w > B22RVc5VnMT2UAPfSFbTA61VheJKyuLl1EOLCAUbwzEdXKDXu4QDx+SbTXQvGVsPKkJyY90KaIyzSFN0roM4smvAGxF4rbEzn6TPPsS7U2r/m4XNIXYpKXGl7q0pKeCkHMeAPOEazqvM7EukM2hLWUryOlNyq6hQUUrKfh4XFaUhOZFAmMTiJaUmpt9RcCEKUco3lAnfHHf+EZteJgUeZdefGM9KXcRnS8hBblkrytNKUCpCeBVlCUlVLUTRKeqkUqT9E648nvzMs00ClVVvV2nNI/J1rwirwMinG1J4U9dsXa4TBNrylJvw19acuMDwxr7w6XdcWSnOclzl19fSOWGSHz+9oiu6ONj+n8RCHkJS696oKC7y1K1UKkcNB64xGXRhNKcThbz1AFZ0oBzCu/1iATU003erWp1EL19kJI6VnX2F5mXFtKoRmQopNDqLHjpSNYE0dgvtQnGNkiZYZmWW1hVB+6cqE5RvJBFr2KbxmZ4oTaM/tm6OvtTHveDOOuTM1LKWmrakhiXG6MyqFS1aKTRKaXBtSK34v2igYbjSMRwecS0lbbRdcCG17wbY6+yz/K2TlQTSqdYo7VySZ+yk7tPd0qACUst5hxAy5kkgU13eApFVKCXiOHMz0ouSeWZdp5BClV6qfgUa36+U5b1vWkcrPl558410bncODG3S1lcTZTdxmRYpV/GetUcNI+ibqZYuv11+nr8wyOY7zSFCtK9tPxy5RmtWoSewyt0m/r13RZxZFQ/wB5aVbN3iG3hRLlLgJShSndVHsHyjzhCTAPdUELPKsWiCwT1+daH1+YWdNQOybuHrZFDNbF8JzJSQM5RTJmUnKaJoVipGmU1qOQrpZYUg1obHiDr43jVhOdI88lIYWb0N9O31pANSbm6Ays03hsyjKoIfaWb6VFrV5j6GkfPuT2UO1547WxNmU7TerU9X4bmtrfiKdBeTeEYpM4c8WVuJzUyml1lI6thXIez! je! > > PVQZIxqZnVs7CZStNrVuAtH0rXvoQKxqIdZ/fQR+YvYMG2Jm1/X356RksXmu7bYWqp3e45vXKJvLtElXiDr9vXjAEUlGFuqTVrLn0BSKG/CmvZw74lqJVYzgUxL7zjZRU9WoVl+x8DeNBFi6kSw4nIF/FdKuBH9OMEky4LG/mO0SUGzid7LfiOzsMFTEbM4h0/v5dqb69VJ3XTX4idd3UDjfnHig2lcK6IqcrNpxiSbzJ6iUubuSquugbylUSkVIANbgQPtIZ99CsBwyaWw6zLuIZZTmWZpCMyngpWRLZBNGEINVlQqtzUmgEUtpQN/FHkhKmWUhDZOW2gbQNaAdZRuAm1KxnSKs/ZDjeHmdWCkrNGW/iv/iLpe/WANLX7II41s5PrwfBlTrq2jMNNIb2ahurzJra9/1WrAvt5gtOJIx33lx1lLS20hwFHWr2Chr+njwNou8AZG6SyDzD1es2bJUBbuPaI0VZMi5MsBUmqqn165xltafEMtqScwzDy8IYL4ImJ4oF0oPKo/29c4GGsJPFdm6pYGWoNALivj308ogWUU3OPPLJIBCjavD1qbQ4kIXcEbcw8hvP7xRK05wAA6NUtqBoUOJsDa8EiQdJiUngnMlKcq60roUkcKH7EGHphY6JJKRZffSClKa3K6qSP9Ir9hSAkm+sC6N4kmRztvzS2PlzNTCECmpS6gkV4EKqBYxn7SRELypeWZO1ogAZ1ZhQkfpT8A1A58IroAKTDOmGHTGIu59xtkgt2zld76WTQaVoAKxdTVwFdLvaMVTbgk6+76ZaApqOVPtUQ/WjzPE103xKZa2My8641ly5TfdHUrx3e+LaKDhhjGHWQQ2VJSrUCw8PD6wXEn4vGH1JUCapX1greHj56xHHDo2m6Sbnjbh2/wDyI+etZqMU1+HXTKfWnoRZEJDzqk1Kan7fiHCaksTqnu0ht4SNSinFoQK31KeA4m3Lx0gIbTeAYRvJIFUFKRU! > kZKdxIPfxpFfMgKf2lYThSGG1hoNvZqbRISlZ/UpI30cgQSDeHaWRY4l1vB2rayeHI+HnF > 1JvGl5Hp5ictJpl2iU9auc7t/0mp+appGexDqS2IYnic0twvzCiFa0NE05ISPMmsaGCuFwiWFSkKOU+ufnDqK5ZlkVABoDbs8IW1ISpw6VpvZxX4hlPlTWA6i4NyDal7NKq/JXd+nG/ZHdLrBWCPilGVGulN6p+kc1N/9k= > > krbpwdpolicyreference: > cn=global_policy,cn=EXAMPLE.COM,cn=kerberos,dc=example,dc=com > mepmanagedentry: cn=bbanner,cn=groups,cn=accounts,dc=example,dc=com > objectclass: top, person, organizationalperson, inetorgperson, inetuser, > posixaccount, krbprincipalaux, krbticketpolicyaux, ipaobject, ipasshuser, > ipaSshGroupOfPubKeys, mepOriginEntry [root at ds01 ~]# > > > Any ideas? I think getting this working via ipa user-mod would be a better > option as I don't like having people using the Directory manager account > when they don't need to. First, not that users do not need to use DM account. Even when using ldapmodify they can bind as their regular user and change their own attribute. You would just probably need to add appropriate selfservice permission (ipa help selfservice). As for the attribute change, you indeed need to bass the BASE64 contents of the file as the --setattr or --addattr options expects just a raw value on the input. This should be working: # wget https://www.dalemacartney.com/wp-content/uploads/2013/12/ejabberd_avatar.png # ipa user-mod tuser1 --setattr="jpegphoto=`base64 ejabberd_avatar.png -w 0`" I did not test it on ejabberd, but the value was there. Alternatively, you could also extend the User object in FreeIPA and add new attribute definition: # cat /usr/lib/python2.6/site-packages/ipalib/plugins/user-jpegphoto.py from ipalib.plugins.user import user from ipalib.parameters import Bytes from ipalib.text import _ /usr/lib/python2.6/site-packages/ipalib/plugins/user-jpegphoto.py user.takes_params += ( Bytes('jpegphoto?', label=_('JPEG Photo'), ), ) # service httpd reload # ipa user-mod tuser1 --jpegphoto=`base64 ejabberd_avatar.png -w 0` but it does not add that much added value. Ideally, it would be great if you could define a File type attribute and have it be encoded automatically. But in my tests, it did not work out of the box, the framework could not handle binary values. That may be an idea for improvement of the framework. Martin From simo at redhat.com Fri Dec 6 13:56:58 2013 From: simo at redhat.com (Simo Sorce) Date: Fri, 06 Dec 2013 08:56:58 -0500 Subject: [Freeipa-users] Adding Display Pictures/Avatars into FreeIPA In-Reply-To: <52A19472.3000507@gmail.com> References: <52A0FF13.4080003@gmail.com> <1386284285.3255.98.camel@willson.li.ssimo.org> <52A19472.3000507@gmail.com> Message-ID: <1386338218.3255.107.camel@willson.li.ssimo.org> On Fri, 2013-12-06 at 09:10 +0000, Dale Macartney wrote: > > Any ideas? I think getting this working via ipa user-mod would be a > better option as I don't like having people using the Directory > manager > account when they don't need to. > As Martin mentioned you don't need to use DM: Usee: ldapmodify -Y GSSAPI instead of: ldapmodify -x -D -w It would certainly nice to make jpegphoto a recognize attribute, so that when --jpegphoto is passed (or --addattr=jpegphoto, the framework takes the value, assume it is a local file, opens it and slurps the contents in. Maybe you can open a RFE to let the framework support jpegphoto natively ? Simo. -- Simo Sorce * Red Hat, Inc * New York From mmercier at gmail.com Fri Dec 6 17:16:31 2013 From: mmercier at gmail.com (Michael Mercier) Date: Fri, 6 Dec 2013 12:16:31 -0500 Subject: [Freeipa-users] ipa: ERROR: Certificate operation cannot be completed: Failure decoding Certificate Signing Request In-Reply-To: <52A0E007.3050705@redhat.com> References: <52A0E007.3050705@redhat.com> Message-ID: <0C9612C7-FD9F-4D1C-BCEB-162BD61AE2FF@gmail.com> On Dec 5, 2013, at 3:20 PM, Rob Crittenden wrote: > Michael Mercier wrote: >> Hello, >> >> A few details to begin: >> >> The IPA system consists of 3 servers running on fully patched CentOS 6.5 (updated Monday night). DNS is integrated with the IPA system. >> >> ipa-*-3.0.0-37. >> mod_nss-1.0.8-19 >> openssl-1.0.1e-16 >> >> >> The system was upgraded from 2.2 >> >> >> >> Yesterday, I revoked a certificate for an old system and signed a certificate for the replacement system (same hostname) with no apparent issues. >> >> Today, I am attempting to sign a certificate for a new system and I am seeing the following error from the command line (with debug=True in /etc/ipa/default.conf): >> >> ipa cert-request >> principal: >> >> ipa: ERROR: Certificate operation cannot be completed: Failure decoding Certificate Signing Request >> >> The GUI responds with: >> IPA ERROR 4310 >> Certificate operation cannot be completed: Failure decoding Certificate Signing Request >> >> I have no issues running 'openssl req -text -noout -verify -in ? on the request file. >> >> I did do a 'yum update? on the system today (after experiencing the errors), with openssl and mod_nss being upgraded on all servers. All systems were rebooted after the upgrade and the problem still exists. >> >> I did see an older thread with a similar issue, but that seemed to involve updating expired certs and Rob did not seem to be able to reproduce the error. Maybe I am experiencing the same problem? >> >> Anyone have an idea where a good place to start looking is? > > The Failure decoding is a duplicate error message in a couple of different places. I'd recommend modifying it per the other thread so we can know exactly where it failed and why. Here is the exact message after applying the patch? ipa: ERROR: Certificate operation cannot be completed: Failure decoding Certificate Signing Request: [Errno -8183] (SEC_ERROR_BAD_DER) security library: improperly formatted DER-encoded message. Note: I used java keytool to create the CSR, could that be the problem? Thanks, Mike > > rob -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Fri Dec 6 18:39:51 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 06 Dec 2013 13:39:51 -0500 Subject: [Freeipa-users] ipa: ERROR: Certificate operation cannot be completed: Failure decoding Certificate Signing Request In-Reply-To: <0C9612C7-FD9F-4D1C-BCEB-162BD61AE2FF@gmail.com> References: <52A0E007.3050705@redhat.com> <0C9612C7-FD9F-4D1C-BCEB-162BD61AE2FF@gmail.com> Message-ID: <52A219F7.9050105@redhat.com> Michael Mercier wrote: > > On Dec 5, 2013, at 3:20 PM, Rob Crittenden > wrote: > >> Michael Mercier wrote: >>> Hello, >>> >>> A few details to begin: >>> >>> The IPA system consists of 3 servers running on fully patched CentOS >>> 6.5 (updated Monday night). DNS is integrated with the IPA system. >>> >>> ipa-*-3.0.0-37. >>> mod_nss-1.0.8-19 >>> openssl-1.0.1e-16 >>> >>> >>> The system was upgraded from 2.2 >>> >>> >>> >>> Yesterday, I revoked a certificate for an old system and signed a >>> certificate for the replacement system (same hostname) with no >>> apparent issues. >>> >>> Today, I am attempting to sign a certificate for a new system and I >>> am seeing the following error from the command line (with debug=True >>> in /etc/ipa/default.conf): >>> >>> ipa cert-request >>> principal: >>> >>> ipa: ERROR: Certificate operation cannot be completed: Failure >>> decoding Certificate Signing Request >>> >>> The GUI responds with: >>> IPA ERROR 4310 >>> Certificate operation cannot be completed: Failure decoding >>> Certificate Signing Request >>> >>> I have no issues running 'openssl req -text -noout -verify -in >>> ? on the request file. >>> >>> I did do a 'yum update? on the system today (after experiencing the >>> errors), with openssl and mod_nss being upgraded on all servers. All >>> systems were rebooted after the upgrade and the problem still exists. >>> >>> I did see an older thread with a similar issue, but that seemed to >>> involve updating expired certs and Rob did not seem to be able to >>> reproduce the error. Maybe I am experiencing the same problem? >>> >>> Anyone have an idea where a good place to start looking is? >> >> The Failure decoding is a duplicate error message in a couple of >> different places. I'd recommend modifying it per the other thread so >> we can know exactly where it failed and why. > > Here is the exact message after applying the patch? > > ipa: ERROR: Certificate operation cannot be completed: Failure decoding > Certificate Signing Request: [Errno -8183] (SEC_ERROR_BAD_DER) security > library: improperly formatted DER-encoded message. > > Note: I used java keytool to create the CSR, could that be the problem? Possible I guess. If you convert that to a DER (openssl can do this pretty easily) you can try /usr/lib[64]/nss/unsupported/derdump -i /path/to/file. This may tell you approximately where it is blowing up rob From dpal at redhat.com Sat Dec 7 19:22:56 2013 From: dpal at redhat.com (Dmitri Pal) Date: Sat, 07 Dec 2013 14:22:56 -0500 Subject: [Freeipa-users] Adding Display Pictures/Avatars into FreeIPA In-Reply-To: <1386338218.3255.107.camel@willson.li.ssimo.org> References: <52A0FF13.4080003@gmail.com> <1386284285.3255.98.camel@willson.li.ssimo.org> <52A19472.3000507@gmail.com> <1386338218.3255.107.camel@willson.li.ssimo.org> Message-ID: <52A37590.9010903@redhat.com> On 12/06/2013 08:56 AM, Simo Sorce wrote: > Maybe you can open a RFE to let the framework support jpegphoto > natively ? Simo. Yes, that would be really nice. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dbmacartney at gmail.com Sun Dec 8 20:04:25 2013 From: dbmacartney at gmail.com (Dale Macartney) Date: Sun, 08 Dec 2013 20:04:25 +0000 Subject: [Freeipa-users] Adding Display Pictures/Avatars into FreeIPA In-Reply-To: <52A37590.9010903@redhat.com> References: <52A0FF13.4080003@gmail.com> <1386284285.3255.98.camel@willson.li.ssimo.org> <52A19472.3000507@gmail.com> <1386338218.3255.107.camel@willson.li.ssimo.org> <52A37590.9010903@redhat.com> Message-ID: <52A4D0C9.5020303@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/12/13 19:22, Dmitri Pal wrote: > On 12/06/2013 08:56 AM, Simo Sorce wrote: >> Maybe you can open a RFE to let the framework support jpegphoto >> natively ? Simo. > > Yes, that would be really nice. > Here you go folks, first trac ticket so be gentle!! :-) https://fedorahosted.org/freeipa/ticket/4073 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSpNDHAAoJEAJsWS61tB+qaSIQAML3oEsiw14IeKBUjqRViszA 7soZ/9ya+aDGa4sPhsfbH0vpu2SwZkZrdH+Xdmm58OiU3m0UBGfFs7Pg2Kddw9Ud 4B+Ohsk32JkdYlCJsGV3BRt0m1vfjNwv4B2ettAokYcKTYFCkqsZnOVidqwO81iP m1pYB0AWBoYeCGlx/GeC0EvWaqx769KvTmmUly033oISkgrJbYoedXtqXYVAJYaQ Zx73Oc53mWKxJcDHwsTaLSS4E7v2Q9Jnw40sBId/3SilDZqWoHsFJNuf+MjF7VBC bGcWlC6+y9wS8gP0BSeXrsuRGXtNmye1L4lgwLiqa5OpK18jP1iefjJMMJTe19EB w/4FTsSew26xlcST8BStiSKI9RUlo3vh2/ApubYrtDeXhrNK0HCm2JL5n2sPE/ml mDrgid2eJfqT4cSGlZ+Fv7ki0s9F2kJgZN1tM13+n6S1N2ja0wXP9Wfg9/jhdmby xeT5jCTMKhDsfqX4VdRmbF7gOXvN1n28O8nL5amhM/Q40oPNv+tn83n/r2IVsTBr mS6N3M8XMVn0uP8KgjXEU6rlFI3TFv6Dyctv4PsOqDo6CK2dXSAJz7gOjtqsaKIP 8G0GhOQKdfS/u3JZeDkbAi5jXqBaS210U8G5oA+hZpzhDN9jTt/dtQ0LsT5LQELV zZTGR/7im1RGCT9C7hia =l2LI -----END PGP SIGNATURE----- From mkosek at redhat.com Mon Dec 9 08:55:23 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 09 Dec 2013 09:55:23 +0100 Subject: [Freeipa-users] Adding Display Pictures/Avatars into FreeIPA In-Reply-To: <52A4D0C9.5020303@gmail.com> References: <52A0FF13.4080003@gmail.com> <1386284285.3255.98.camel@willson.li.ssimo.org> <52A19472.3000507@gmail.com> <1386338218.3255.107.camel@willson.li.ssimo.org> <52A37590.9010903@redhat.com> <52A4D0C9.5020303@gmail.com> Message-ID: <52A5857B.3000508@redhat.com> On 12/08/2013 09:04 PM, Dale Macartney wrote: > > > On 07/12/13 19:22, Dmitri Pal wrote: >> On 12/06/2013 08:56 AM, Simo Sorce wrote: >>> Maybe you can open a RFE to let the framework support jpegphoto >>> natively ? Simo. > >> Yes, that would be really nice. > > Here you go folks, first trac ticket so be gentle!! :-) > > https://fedorahosted.org/freeipa/ticket/4073 We are always gentle for users' contributions ;-) I replied to your ticket. We will deal with the ticket on our next triage meeting. Unfortunately, some changes to the framework are needed to accept the binary files, otherwise this ticket would be a real quickie. Martin From Johan.Petersson at sscspace.com Mon Dec 9 22:21:32 2013 From: Johan.Petersson at sscspace.com (Johan Petersson) Date: Mon, 9 Dec 2013 22:21:32 +0000 Subject: [Freeipa-users] IPA and AD Home Directory Message-ID: <558C15177F5E714F83334217C9A197DF0122DD1042@SSC-MBX2.ssc.internal> Hi, In my test environment i am planning to add a AD to my current IPA configuration and i would like my IPA users to be able to log in through windows to the AD and still have their IPA shared home directory. IPA is Red Hat 6.5 and AD is Windows 2012 Server. Home Directories are currently shared through NFS and Kerberos Is there a preferred way to connect the AD to IPA for this functionality? Thanks, Johan This e-mail is private and confidential between the sender and the addressee. In the event of misdirection, the recipient is prohibited from using, copying or disseminating it or any information in it. Please notify the above if any misdirection. -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Mon Dec 9 22:34:52 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 10 Dec 2013 00:34:52 +0200 Subject: [Freeipa-users] IPA and AD Home Directory In-Reply-To: <558C15177F5E714F83334217C9A197DF0122DD1042@SSC-MBX2.ssc.internal> References: <558C15177F5E714F83334217C9A197DF0122DD1042@SSC-MBX2.ssc.internal> Message-ID: <20131209223452.GB8297@redhat.com> On Mon, 09 Dec 2013, Johan Petersson wrote: >Hi, > >In my test environment i am planning to add a AD to my current IPA >configuration and i would like my IPA users to be able to log in >through windows to the AD and still have their IPA shared home >directory. > >IPA is Red Hat 6.5 and AD is Windows 2012 Server. > >Home Directories are currently shared through NFS and Kerberos > >Is there a preferred way to connect the AD to IPA for this >functionality? Using IPA identities to log-in to Windows machines is not implemented yet. -- / Alexander Bokovoy From mkosek at redhat.com Tue Dec 10 08:41:20 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 10 Dec 2013 09:41:20 +0100 Subject: [Freeipa-users] IPA and AD Home Directory In-Reply-To: <20131209223452.GB8297@redhat.com> References: <558C15177F5E714F83334217C9A197DF0122DD1042@SSC-MBX2.ssc.internal> <20131209223452.GB8297@redhat.com> Message-ID: <52A6D3B0.3000909@redhat.com> On 12/09/2013 11:34 PM, Alexander Bokovoy wrote: > On Mon, 09 Dec 2013, Johan Petersson wrote: >> Hi, >> >> In my test environment i am planning to add a AD to my current IPA >> configuration and i would like my IPA users to be able to log in >> through windows to the AD and still have their IPA shared home >> directory. >> >> IPA is Red Hat 6.5 and AD is Windows 2012 Server. >> >> Home Directories are currently shared through NFS and Kerberos >> >> Is there a preferred way to connect the AD to IPA for this >> functionality? > Using IPA identities to log-in to Windows machines is not implemented > yet. Hello Johan, I would like to elaborate more on this topic. What is currently already working and supported is the AD->IPA authentication. You can SSO from Windows to Linux machine controlled by FreeIPA already. The second part (IPA->AD) is much more complicated, it requires additional MS-specific interfaces implemented on IPA side. This is a feature we are working on in FreeIPA 3.4 (i.e. the next version). We would like to publish a working version (at least PoC) when it is released. This is the upstream ticket tracking the effort: https://fedorahosted.org/freeipa/ticket/2586 This is the related information on our community wiki: http://www.freeipa.org/page/Trusts http://www.freeipa.org/page/V3/Trust_GC_support HTH, Martin From alfred.condor at gmail.com Tue Dec 10 16:20:19 2013 From: alfred.condor at gmail.com (Alfredo Vazquez) Date: Tue, 10 Dec 2013 10:20:19 -0600 Subject: [Freeipa-users] IPA and AD Home Directory In-Reply-To: <52A6D3B0.3000909@redhat.com> References: <558C15177F5E714F83334217C9A197DF0122DD1042@SSC-MBX2.ssc.internal> <20131209223452.GB8297@redhat.com> <52A6D3B0.3000909@redhat.com> Message-ID: Hi Everyone, my question is as follows: As Ipa authenticate a server to a Windows 7 client so that the login is correct, I hope your help GREETINGS 2013/12/10 Martin Kosek > On 12/09/2013 11:34 PM, Alexander Bokovoy wrote: > > On Mon, 09 Dec 2013, Johan Petersson wrote: > >> Hi, > >> > >> In my test environment i am planning to add a AD to my current IPA > >> configuration and i would like my IPA users to be able to log in > >> through windows to the AD and still have their IPA shared home > >> directory. > >> > >> IPA is Red Hat 6.5 and AD is Windows 2012 Server. > >> > >> Home Directories are currently shared through NFS and Kerberos > >> > >> Is there a preferred way to connect the AD to IPA for this > >> functionality? > > Using IPA identities to log-in to Windows machines is not implemented > > yet. > > Hello Johan, > > I would like to elaborate more on this topic. What is currently already > working > and supported is the AD->IPA authentication. You can SSO from Windows to > Linux > machine controlled by FreeIPA already. > > The second part (IPA->AD) is much more complicated, it requires additional > MS-specific interfaces implemented on IPA side. This is a feature we are > working on in FreeIPA 3.4 (i.e. the next version). We would like to > publish a > working version (at least PoC) when it is released. > > This is the upstream ticket tracking the effort: > https://fedorahosted.org/freeipa/ticket/2586 > > This is the related information on our community wiki: > http://www.freeipa.org/page/Trusts > http://www.freeipa.org/page/V3/Trust_GC_support > > HTH, > Martin > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Tue Dec 10 23:43:12 2013 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 10 Dec 2013 18:43:12 -0500 Subject: [Freeipa-users] IPA and AD Home Directory In-Reply-To: References: <558C15177F5E714F83334217C9A197DF0122DD1042@SSC-MBX2.ssc.internal> <20131209223452.GB8297@redhat.com> <52A6D3B0.3000909@redhat.com> Message-ID: <52A7A710.6010101@redhat.com> On 12/10/2013 11:20 AM, Alfredo Vazquez wrote: > Hi Everyone, my question is as follows: > As Ipa authenticate a server to a Windows 7 client so that the login > is correct, I hope your help So you are saying that you want the IPA users connecting via Windows 7 clients be able to access servers in AD domain? As it was explained below it is yet not possible. > > GREETINGS > > > 2013/12/10 Martin Kosek > > > On 12/09/2013 11:34 PM, Alexander Bokovoy wrote: > > On Mon, 09 Dec 2013, Johan Petersson wrote: > >> Hi, > >> > >> In my test environment i am planning to add a AD to my current IPA > >> configuration and i would like my IPA users to be able to log in > >> through windows to the AD and still have their IPA shared home > >> directory. > >> > >> IPA is Red Hat 6.5 and AD is Windows 2012 Server. > >> > >> Home Directories are currently shared through NFS and Kerberos > >> > >> Is there a preferred way to connect the AD to IPA for this > >> functionality? > > Using IPA identities to log-in to Windows machines is not > implemented > > yet. > > Hello Johan, > > I would like to elaborate more on this topic. What is currently > already working > and supported is the AD->IPA authentication. You can SSO from > Windows to Linux > machine controlled by FreeIPA already. > > The second part (IPA->AD) is much more complicated, it requires > additional > MS-specific interfaces implemented on IPA side. This is a feature > we are > working on in FreeIPA 3.4 (i.e. the next version). We would like > to publish a > working version (at least PoC) when it is released. > > This is the upstream ticket tracking the effort: > https://fedorahosted.org/freeipa/ticket/2586 > > This is the related information on our community wiki: > http://www.freeipa.org/page/Trusts > http://www.freeipa.org/page/V3/Trust_GC_support > > HTH, > Martin > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > -- > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From walid.shaari at linux.com Wed Dec 11 19:25:01 2013 From: walid.shaari at linux.com (Walid A. Shaari) Date: Wed, 11 Dec 2013 22:25:01 +0300 Subject: [Freeipa-users] Fwd: /etc/services map migration from NIS to IPA In-Reply-To: References: Message-ID: Hi, the only ipa services i am able to see is the Kerberos concept of service principle, how about services map as in /etc/services that is managed by NIS, i can only see the following page not updated from 14 months ago https://fedorahosted.org/freeipa/ticket/2638 kind regards Walid -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed Dec 11 19:40:30 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 11 Dec 2013 14:40:30 -0500 Subject: [Freeipa-users] Fwd: /etc/services map migration from NIS to IPA In-Reply-To: References: Message-ID: <52A8BFAE.5060805@redhat.com> Walid A. Shaari wrote: > Hi, > > the only ipa services i am able to see is the Kerberos concept of > service principle, how about services map as in /etc/services that is > managed by NIS, i can only see the following page not updated from 14 > months ago > > https://fedorahosted.org/freeipa/ticket/2638 > As you can see, it isn't a high priority. The work should be fairly straightforward but it is a question of effort vs payback. What are you using the services map for? rob From dpal at redhat.com Wed Dec 11 19:40:44 2013 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 11 Dec 2013 14:40:44 -0500 Subject: [Freeipa-users] Fwd: /etc/services map migration from NIS to IPA In-Reply-To: References: Message-ID: <52A8BFBC.5000307@redhat.com> On 12/11/2013 02:25 PM, Walid A. Shaari wrote: > Hi, > > the only ipa services i am able to see is the Kerberos concept of > service principle, how about services map as in /etc/services that is > managed by NIS, i can only see the following page not updated from 14 > months ago > > https://fedorahosted.org/freeipa/ticket/2638 > > kind regards > > Walid > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users You can load the services into IPA and manage them using LDAP. This would work as with any other LDAP server. The ticket is about making it nice to manage as we manage other things in IPA using CLI/UI. If you are interested to contribute management interface for CLI/UI to do it via ipa command line and GUI we would be glad to help you with this effort. If you have some Python skills it should not be that hard. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From walid.shaari at linux.com Wed Dec 11 19:51:25 2013 From: walid.shaari at linux.com (Walid A. Shaari) Date: Wed, 11 Dec 2013 22:51:25 +0300 Subject: [Freeipa-users] Fwd: /etc/services map migration from NIS to IPA In-Reply-To: <52A8BFAE.5060805@redhat.com> References: <52A8BFAE.5060805@redhat.com> Message-ID: for non IANA application ports used by geo scientific applications. if i had a choice i would have pushed the vendors to register and get standard IANA approved ports On 11 December 2013 22:40, Rob Crittenden wrote: > Walid A. Shaari wrote: > >> Hi, >> >> the only ipa services i am able to see is the Kerberos concept of >> service principle, how about services map as in /etc/services that is >> managed by NIS, i can only see the following page not updated from 14 >> months ago >> >> https://fedorahosted.org/freeipa/ticket/2638 >> >> > As you can see, it isn't a high priority. > > The work should be fairly straightforward but it is a question of effort > vs payback. > > What are you using the services map for? > > rob > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Wed Dec 11 20:03:52 2013 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 11 Dec 2013 15:03:52 -0500 Subject: [Freeipa-users] Fwd: /etc/services map migration from NIS to IPA In-Reply-To: References: <52A8BFBC.5000307@redhat.com> Message-ID: <52A8C528.8070701@redhat.com> On 12/11/2013 02:52 PM, Walid wrote: > time is of an issue, where shall i start looking? can you give me a > hint/url, or reference that i can start from Absolutely. Start here: http://www.freeipa.org/page/Contribute/Code Take a look here: http://www.freeipa.org/page/General_considerations Learn this: http://abbra.fedorapeople.org/guide.html Create a proposal/design page on wiki http://www.freeipa.org/page/V3_Proposals using http://www.freeipa.org/page/Feature_template Look at the code here: https://git.fedorahosted.org/git/freeipa Develop patches following style guide http://www.freeipa.org/page/Python_Coding_Style Send then to the list Address feedback and resubmit Observe patches merge Enjoy the benefits! Do not hesitate to ask questions at any point of your journey, we are here to help. > > > On 11 December 2013 22:40, Dmitri Pal > wrote: > > On 12/11/2013 02:25 PM, Walid A. Shaari wrote: >> Hi, >> >> the only ipa services i am able to see is the Kerberos concept of >> service principle, how about services map as in /etc/services >> that is managed by NIS, i can only see the following page not >> updated from 14 months ago >> >> https://fedorahosted.org/freeipa/ticket/2638 >> >> kind regards >> >> Walid >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > You can load the services into IPA and manage them using LDAP. > This would work as with any other LDAP server. The ticket is about > making it nice to manage as we manage other things in IPA using > CLI/UI. > If you are interested to contribute management interface for > CLI/UI to do it via ipa command line and GUI we would be glad to > help you with this effort. If you have some Python skills it > should not be that hard. > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From npmccallum at redhat.com Wed Dec 11 20:47:02 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 11 Dec 2013 15:47:02 -0500 Subject: [Freeipa-users] Announcing FreeOTP for Android Message-ID: <1386794822.25062.66.camel@localhost.localdomain> I?d like to announce the general availability of FreeOTP for Android. It is available for install now in the Google Play store[1]. FreeOTP is a multi-factor authentication client based on the HOTP and TOTP standards. FreeOTP features: * A FLOSS code base * Support for HOTP or TOTP * Native QR code scanning * Adherence to the Android UI design principles * Tablet support We anticipate that FreeOTP should work with any server providing HOTP or TOTP support, including the upcoming OTP support[2] in FreeIPA. So, if you fancy a bit of adventure, please try FreeOTP! We welcome your feedback. Please also don?t forget to leave your positive reviews on Google Play so that it will be easier for other Android users to find out about FreeOTP. We have also developed FreeOTP for iOS and are currently working to bring it to the Apple App Store. Please stay tuned for future news! The FreeOTP project is hosted on Fedora Hosted[3]. We welcome your feedback and contributions. [1] https://play.google.com/store/apps/details?id=org.fedorahosted.freeotp [2] http://www.freeipa.org/page/V3/OTP [3] http://freeotp.fedorahosted.org From walid.shaari at gmail.com Wed Dec 11 20:23:39 2013 From: walid.shaari at gmail.com (Walid) Date: Wed, 11 Dec 2013 23:23:39 +0300 Subject: [Freeipa-users] Fwd: /etc/services map migration from NIS to IPA In-Reply-To: <52A8C528.8070701@redhat.com> References: <52A8BFBC.5000307@redhat.com> <52A8C528.8070701@redhat.com> Message-ID: Thanks, will take a look and see what i can do On 11 December 2013 23:03, Dmitri Pal wrote: > On 12/11/2013 02:52 PM, Walid wrote: > > time is of an issue, where shall i start looking? can you give me a > hint/url, or reference that i can start from > > > Absolutely. > Start here: > http://www.freeipa.org/page/Contribute/Code > Take a look here: > http://www.freeipa.org/page/General_considerations > Learn this: > http://abbra.fedorapeople.org/guide.html > Create a proposal/design page on wiki > http://www.freeipa.org/page/V3_Proposals > using http://www.freeipa.org/page/Feature_template > Look at the code here: > https://git.fedorahosted.org/git/freeipa > Develop patches following style guide > http://www.freeipa.org/page/Python_Coding_Style > Send then to the list > Address feedback and resubmit > Observe patches merge > Enjoy the benefits! > > > Do not hesitate to ask questions at any point of your journey, we are here > to help. > > > > > On 11 December 2013 22:40, Dmitri Pal wrote: > >> On 12/11/2013 02:25 PM, Walid A. Shaari wrote: >> >> Hi, >> >> the only ipa services i am able to see is the Kerberos concept of >> service principle, how about services map as in /etc/services that is >> managed by NIS, i can only see the following page not updated from 14 >> months ago >> >> https://fedorahosted.org/freeipa/ticket/2638 >> >> kind regards >> >> Walid >> >> >> _______________________________________________ >> Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users >> >> >> You can load the services into IPA and manage them using LDAP. This would >> work as with any other LDAP server. The ticket is about making it nice to >> manage as we manage other things in IPA using CLI/UI. >> If you are interested to contribute management interface for CLI/UI to do >> it via ipa command line and GUI we would be glad to help you with this >> effort. If you have some Python skills it should not be that hard. >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager for IdM portfolio >> Red Hat Inc. >> >> >> ------------------------------- >> Looking to carve out IT costs?www.redhat.com/carveoutcosts/ >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs?www.redhat.com/carveoutcosts/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Thu Dec 12 08:27:48 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 12 Dec 2013 09:27:48 +0100 Subject: [Freeipa-users] Fwd: /etc/services map migration from NIS to IPA In-Reply-To: References: <52A8BFBC.5000307@redhat.com> <52A8C528.8070701@redhat.com> Message-ID: <52A97384.3030807@redhat.com> Walid, I updated http://www.freeipa.org/page/Contribute/Code and added missing information mentioned by Dmitri. It should be now easier to follow the process of contributing to FreeIPA just by following this page and the links it points to. HTH, Martin On 12/11/2013 09:23 PM, Walid wrote: > Thanks, will take a look and see what i can do > > > On 11 December 2013 23:03, Dmitri Pal wrote: > >> On 12/11/2013 02:52 PM, Walid wrote: >> >> time is of an issue, where shall i start looking? can you give me a >> hint/url, or reference that i can start from >> >> >> Absolutely. >> Start here: >> http://www.freeipa.org/page/Contribute/Code >> Take a look here: >> http://www.freeipa.org/page/General_considerations >> Learn this: >> http://abbra.fedorapeople.org/guide.html >> Create a proposal/design page on wiki >> http://www.freeipa.org/page/V3_Proposals >> using http://www.freeipa.org/page/Feature_template >> Look at the code here: >> https://git.fedorahosted.org/git/freeipa >> Develop patches following style guide >> http://www.freeipa.org/page/Python_Coding_Style >> Send then to the list >> Address feedback and resubmit >> Observe patches merge >> Enjoy the benefits! >> >> >> Do not hesitate to ask questions at any point of your journey, we are here >> to help. >> >> >> >> >> On 11 December 2013 22:40, Dmitri Pal wrote: >> >>> On 12/11/2013 02:25 PM, Walid A. Shaari wrote: >>> >>> Hi, >>> >>> the only ipa services i am able to see is the Kerberos concept of >>> service principle, how about services map as in /etc/services that is >>> managed by NIS, i can only see the following page not updated from 14 >>> months ago >>> >>> https://fedorahosted.org/freeipa/ticket/2638 >>> >>> kind regards >>> >>> Walid >>> >>> >>> _______________________________________________ >>> Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users >>> >>> >>> You can load the services into IPA and manage them using LDAP. This would >>> work as with any other LDAP server. The ticket is about making it nice to >>> manage as we manage other things in IPA using CLI/UI. >>> If you are interested to contribute management interface for CLI/UI to do >>> it via ipa command line and GUI we would be glad to help you with this >>> effort. If you have some Python skills it should not be that hard. >>> >>> -- >>> Thank you, >>> Dmitri Pal >>> >>> Sr. Engineering Manager for IdM portfolio >>> Red Hat Inc. >>> >>> >>> ------------------------------- >>> Looking to carve out IT costs?www.redhat.com/carveoutcosts/ >>> >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> >> >> >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager for IdM portfolio >> Red Hat Inc. >> >> >> ------------------------------- >> Looking to carve out IT costs?www.redhat.com/carveoutcosts/ >> >> > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > From mkosek at redhat.com Thu Dec 12 14:53:45 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 12 Dec 2013 15:53:45 +0100 Subject: [Freeipa-users] Wiki: Troubleshooting FreeIPA Message-ID: <52A9CDF9.1000704@redhat.com> Hello FreeIPA users! I would like to let you know that we have revived the FreeIPA wiki troubleshooting page: http://www.freeipa.org/page/Troubleshooting It contains both advises that should help you investigate the issues yourselves or, alternatively, help you report the issue and provide all the information needed for proper investigation by members of this list. This will help us avoid unnecessary turn around when we are just asking for the right data or advising procedures for common and known pitfalls. Feedback, proposed additions to the page for common scenarios we missed are very welcome. -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. From abontempi at dbmsrl.com Thu Dec 12 15:01:40 2013 From: abontempi at dbmsrl.com (Andrea Bontempi) Date: Thu, 12 Dec 2013 16:01:40 +0100 (CET) Subject: [Freeipa-users] NSPR Error -8015 In-Reply-To: <1583624831.147609.1386859971864.JavaMail.root@dbmsrl.com> Message-ID: <934866456.147652.1386860500841.JavaMail.root@dbmsrl.com> Hi I have a strange error on one FreeIPA client (on my other client doesn't occur) when i try to call the FreeIPA admin tools (example: ipa ping) On the CLI the error prints: > ipa: ERROR: cannot connect to u'https://myipaserver/ipa/xml': [Errno -8015] error (-8015) unknown The client working perfectly in the FreeIPA network, it's only a problem of CLI command. I try to connect through the python API, and i obtain this traceback: >Traceback (most recent call last): > File "", line 1, in > File "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line 435, in __cal >l__ > ret = self.run(*args, **options) > File "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line 748, in run > return self.forward(*args, **options) > File "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line 769, in forwa >rd > return self.Backend.xmlclient.forward(self.name, *args, **kw) > File "/usr/lib/python2.6/site-packages/ipalib/rpc.py", line 743, in forward > raise NetworkError(uri=server, error=str(e)) >NetworkError: cannot connect to u'https://myipaserver/ipa/xml': [ >Errno -8015] error (-8015) unknown On the line 743 we found: > except NSPRError, e: > raise NetworkError(uri=server, error=str(e)) Can someone help me? Thank you Andrea Bontempi From rcritten at redhat.com Thu Dec 12 15:38:45 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 12 Dec 2013 10:38:45 -0500 Subject: [Freeipa-users] NSPR Error -8015 In-Reply-To: <934866456.147652.1386860500841.JavaMail.root@dbmsrl.com> References: <934866456.147652.1386860500841.JavaMail.root@dbmsrl.com> Message-ID: <52A9D885.7040309@redhat.com> Andrea Bontempi wrote: > Hi > > I have a strange error on one FreeIPA client (on my other client doesn't occur) when i try to call the FreeIPA admin tools (example: ipa ping) > > On the CLI the error prints: > >> ipa: ERROR: cannot connect to u'https://myipaserver/ipa/xml': [Errno -8015] error (-8015) unknown > > The client working perfectly in the FreeIPA network, it's only a problem of CLI command. > > I try to connect through the python API, and i obtain this traceback: > >> Traceback (most recent call last): >> File "", line 1, in >> File "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line 435, in __cal >> l__ >> ret = self.run(*args, **options) >> File "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line 748, in run >> return self.forward(*args, **options) >> File "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line 769, in forwa >> rd >> return self.Backend.xmlclient.forward(self.name, *args, **kw) >> File "/usr/lib/python2.6/site-packages/ipalib/rpc.py", line 743, in forward >> raise NetworkError(uri=server, error=str(e)) >> NetworkError: cannot connect to u'https://myipaserver/ipa/xml': [ >> Errno -8015] error (-8015) unknown > > On the line 743 we found: > >> except NSPRError, e: >> raise NetworkError(uri=server, error=str(e)) > > Can someone help me? > That error is SEC_ERROR_LEGACY_DATABASE which is less scary than it sounds. It seems that NSS throws that when it doesn't know how to open its database. Check for the existence of /etc/pki/nssdb/*.db and make sure it is world readable. The IPA CA should exist in it too: # certutil -L -d /etc/pki/nssdb rob From sbingram at gmail.com Thu Dec 12 21:26:02 2013 From: sbingram at gmail.com (Stephen Ingram) Date: Thu, 12 Dec 2013 13:26:02 -0800 Subject: [Freeipa-users] fine-grained permissions for DNS tasks Message-ID: Is it possible to restrict user to say a DNS Administrator role for only one domain in the system? Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayoung at redhat.com Thu Dec 12 22:38:39 2013 From: ayoung at redhat.com (Adam Young) Date: Thu, 12 Dec 2013 17:38:39 -0500 Subject: [Freeipa-users] fine-grained permissions for DNS tasks In-Reply-To: References: Message-ID: <52AA3AEF.30904@redhat.com> On 12/12/2013 04:26 PM, Stephen Ingram wrote: > Is it possible to restrict user to say a DNS Administrator role for > only one domain in the system? > > Steve > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users Yes. Read up here. http://adam.younglogic.com/2012/02/dns-managers-in-freeipa/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Fri Dec 13 09:01:19 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 13 Dec 2013 10:01:19 +0100 Subject: [Freeipa-users] fine-grained permissions for DNS tasks In-Reply-To: <52AA3AEF.30904@redhat.com> References: <52AA3AEF.30904@redhat.com> Message-ID: <52AACCDF.70002@redhat.com> On 12/12/2013 11:38 PM, Adam Young wrote: > On 12/12/2013 04:26 PM, Stephen Ingram wrote: >> Is it possible to restrict user to say a DNS Administrator role for only one >> domain in the system? >> >> Steve >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > Yes. Read up here. > > http://adam.younglogic.com/2012/02/dns-managers-in-freeipa/ ... or you can use the dnszone-add-permission command to have a per-zone permission with almost zero effort. This command was introduced in FreeIPA 3.0, it will create a permission that will give the assigned users read/write/delete access to specified zone and it's records. See http://fedoraproject.org/wiki/QA:Testcase_freeipav3_dns_delegation for testing instructions. HTH, Martin From Less at imagine-sw.com Mon Dec 16 09:46:58 2013 From: Less at imagine-sw.com (Les Stott) Date: Mon, 16 Dec 2013 09:46:58 +0000 Subject: [Freeipa-users] Trouble with replica install Message-ID: <4ED173A868981548967B4FCA2707222602A807@AACMBXP04.exchserver.com> 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 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Less at imagine-sw.com Mon Dec 16 09:55:54 2013 From: Less at imagine-sw.com (Les Stott) Date: Mon, 16 Dec 2013 09:55:54 +0000 Subject: [Freeipa-users] Trouble with replica install In-Reply-To: <4ED173A868981548967B4FCA2707222602A807@AACMBXP04.exchserver.com> References: <4ED173A868981548967B4FCA2707222602A807@AACMBXP04.exchserver.com> Message-ID: <4ED173A868981548967B4FCA2707222602A835@AACMBXP04.exchserver.com> 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-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Les Stott Sent: Monday, 16 December 2013 8:47 PM To: freeipa-users at 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 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Mon Dec 16 11:38:26 2013 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 16 Dec 2013 12:38:26 +0100 Subject: [Freeipa-users] Trouble with replica install In-Reply-To: <4ED173A868981548967B4FCA2707222602A835@AACMBXP04.exchserver.com> References: <4ED173A868981548967B4FCA2707222602A807@AACMBXP04.exchserver.com> <4ED173A868981548967B4FCA2707222602A835@AACMBXP04.exchserver.com> Message-ID: <52AEE632.6000705@redhat.com> 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-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Les Stott > Sent: Monday, 16 December 2013 8:47 PM > To: freeipa-users at 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 > 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 From Less at imagine-sw.com Mon Dec 16 12:44:34 2013 From: Less at imagine-sw.com (Les Stott) Date: Mon, 16 Dec 2013 12:44:34 +0000 Subject: [Freeipa-users] Trouble with replica install In-Reply-To: <52AEE632.6000705@redhat.com> References: <4ED173A868981548967B4FCA2707222602A807@AACMBXP04.exchserver.com> <4ED173A868981548967B4FCA2707222602A835@AACMBXP04.exchserver.com>, <52AEE632.6000705@redhat.com> Message-ID: <4ED173A868981548967B4FCA2707222602A98F@AACMBXP04.exchserver.com> 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 [pspacek at redhat.com] Sent: Monday, December 16, 2013 10:38 PM To: Les Stott; freeipa-users at 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-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Les Stott > Sent: Monday, 16 December 2013 8:47 PM > To: freeipa-users at 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 > 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 From Less at imagine-sw.com Mon Dec 16 13:32:42 2013 From: Less at imagine-sw.com (Les Stott) Date: Mon, 16 Dec 2013 13:32:42 +0000 Subject: [Freeipa-users] Trouble with replica install - SOLVED Message-ID: <4ED173A868981548967B4FCA2707222602A9E6@AACMBXP04.exchserver.com> 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 at 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 [pspacek at redhat.com] Sent: Monday, December 16, 2013 10:38 PM To: Les Stott; freeipa-users at 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-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Les Stott > Sent: Monday, 16 December 2013 8:47 PM > To: freeipa-users at 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 > 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 From abokovoy at redhat.com Mon Dec 16 13:52:25 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 16 Dec 2013 15:52:25 +0200 Subject: [Freeipa-users] Trouble with replica install - SOLVED In-Reply-To: <4ED173A868981548967B4FCA2707222602A9E6@AACMBXP04.exchserver.com> References: <4ED173A868981548967B4FCA2707222602A9E6@AACMBXP04.exchserver.com> Message-ID: <20131216135225.GM21264@redhat.com> 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 From yves at degauquier.net Mon Dec 16 14:46:39 2013 From: yves at degauquier.net (yves at degauquier.net) Date: Mon, 16 Dec 2013 15:46:39 +0100 Subject: [Freeipa-users] FreeIPA integration with AIX and sudo Message-ID: Hi, I'm trying to integrate on AIX environment (as clients) a centralized authentication and authorization with freeipa, and using sudo also with sudo rules on freeipa. I followed several how-to and notes found by googeling, but still have problem with sudo. Everything is fine wiith root account (sudo -l list all sudo rules), but with a user from freeipa I have "Memory fault". Does anybody have good experience with FreeIPA (installed on CentOS), AIX (6.1) and sudo (from Perzl)? Thanks in advance, Yves From bret.wortman at damascusgrp.com Mon Dec 16 15:40:47 2013 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Mon, 16 Dec 2013 10:40:47 -0500 Subject: [Freeipa-users] Replica master in strange state -- how to resolve? Message-ID: <52AF1EFF.7050502@damascusgrp.com> I had a replica that was completely failing to respond to its clients, so I removed it by first running "ipa-replica-manage del" on the replica master, then "ipa-server-install -U --uninstall" on the replica. I regenereated the replica file and, upon trying to re-initialize the replica, received this error: : The host fsipa.spx.net already exists on the master server. You should remove it before proceeding: % ipa host-del fsipa.damascusgrp.com [root at fsipa ~]# On the master: [root at ipamaster ~]# ipa host-del fsipa.damascusgrp.com ipa: ERROR: invalid 'hostname': An IPA master host cannot be deleted or disabled [root at ipamaster ~]# ipa host-show fsipa.damascusgrp.com Host name: fsipa.damascusgrp.com Principal name: host/fsipa.damascusgrp.com at DAMASCUSGRP.COM Password: False Keytab: True Managed by: fsipa.damascusgrp.com SSH public key fingerprint: ... : [root at ipamaster ~]# ipa-replica-manage del fsipa.damascusgrp.com 'ipamaster.damascusgrp.com' has no replication agreement for 'fsipa.damascusgrp.com' [root at ipamaster ~]# What's the right way to clean this up without making the situation worse? -- *Bret Wortman* http://damascusgrp.com/ http://about.me/wortmanbret -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 51f7de33e4b08d2bdb8b4860 Type: image/png Size: 28526 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3766 bytes Desc: S/MIME Cryptographic Signature URL: From sakodak at gmail.com Mon Dec 16 18:38:30 2013 From: sakodak at gmail.com (KodaK) Date: Mon, 16 Dec 2013 12:38:30 -0600 Subject: [Freeipa-users] FreeIPA integration with AIX and sudo In-Reply-To: References: Message-ID: I am an unfortunate AIX sufferer as well. I've gotten through setting this up. First, what version of sudo are you running on the AIX box? On Mon, Dec 16, 2013 at 8:46 AM, wrote: > Hi, > > I'm trying to integrate on AIX environment (as clients) a centralized > authentication and authorization with freeipa, and using sudo also with > sudo rules on freeipa. > > I followed several how-to and notes found by googeling, but still have > problem with sudo. > > Everything is fine wiith root account (sudo -l list all sudo rules), but > with a user from freeipa I have "Memory fault". > > Does anybody have good experience with FreeIPA (installed on CentOS), AIX > (6.1) and sudo (from Perzl)? > > Thanks in advance, > > Yves > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -- The government is going to read our mail anyway, might as well make it tough for them. GPG Public key ID: B6A1A7C6 -------------- next part -------------- An HTML attachment was scrubbed... URL: From yves at degauquier.net Mon Dec 16 23:19:20 2013 From: yves at degauquier.net (Yves Degauquier) Date: Tue, 17 Dec 2013 00:19:20 +0100 Subject: [Freeipa-users] FreeIPA integration with AIX and sudo In-Reply-To: References: Message-ID: <52AF8A78.5050801@degauquier.net> Hi, I'm running the Sudo version 1.8.8 downloaded as RPM on http://www.oss4aix.org/download/RPMS/sudo/ Authentication is fine, but sudo is wrong. If in /etc/security/user for default stanza I don't mention SYSTEM = "KRB5ALDAP" registry = LDAP then when running sudo with a freeipa user it return the message that the id of the user is wrong. If I mention the 2 lines, then I have a Memory fault message. On 16/12/13 19:38, KodaK wrote: > I am an unfortunate AIX sufferer as well. I've gotten through setting > this up. > > First, what version of sudo are you running on the AIX box? > > > On Mon, Dec 16, 2013 at 8:46 AM, > wrote: > > Hi, > > I'm trying to integrate on AIX environment (as clients) a > centralized authentication and authorization with freeipa, and > using sudo also with sudo rules on freeipa. > > I followed several how-to and notes found by googeling, but still > have problem with sudo. > > Everything is fine wiith root account (sudo -l list all sudo > rules), but with a user from freeipa I have "Memory fault". > > Does anybody have good experience with FreeIPA (installed on > CentOS), AIX (6.1) and sudo (from Perzl)? > > Thanks in advance, > > Yves > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > -- > The government is going to read our mail anyway, might as well make it > tough for them. GPG Public key ID: B6A1A7C6 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Less at imagine-sw.com Mon Dec 16 23:36:39 2013 From: Less at imagine-sw.com (Les Stott) Date: Mon, 16 Dec 2013 23:36:39 +0000 Subject: [Freeipa-users] Trouble with replica install - SOLVED In-Reply-To: <20131216135225.GM21264@redhat.com> References: <4ED173A868981548967B4FCA2707222602A9E6@AACMBXP04.exchserver.com> <20131216135225.GM21264@redhat.com> Message-ID: <4ED173A868981548967B4FCA2707222602B0DE@AACMBXP04.exchserver.com> 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:abokovoy at redhat.com] Sent: Tuesday, 17 December 2013 12:52 AM To: Les Stott Cc: freeipa-users at 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 From galens at capaccess.org Mon Dec 16 23:46:50 2013 From: galens at capaccess.org (Galen Brownsmith) Date: Mon, 16 Dec 2013 18:46:50 -0500 Subject: [Freeipa-users] i could use some help with installing FreeIPA Message-ID: My install fails on the invocation of pkispawn with a Socket Error in the pki-ca-spawn log ; anyone have any ideas? (It isn't the issue with special characters in the DM's password, as my Directory Manager and IPA Admin passwords may be 32 characters long, but only contain [A-Za-z0-9_] ) Configuration and Error Messages follow. Target System: Fedora19 64bit LXC Container running on top of a Fedora19 64bit host. Kernel 3.11.10, Q9550 Intel CPU. Attempting to install freeipa server 3.3.3 . SEllinux has been set to 'disabled' on the host and container. /etc/hosts: # IP FQDN Alias(es) 127.0.0.1 localhost.localdomain localhost localhost4 192.168.253.94 woeg.marphod.net woeg # Peers 192.168.253.99 skete.marphod.net skete wiki.marphod.net wiki www.marphod.net www [... several more machines] /etc/resolv.conf ; generated by /usr/sbin/dhclient-script search marphod.net nameserver 192.168.253.1 /etc/sysconfig/network: NETWORKING=yes HOSTNAME=woeg.marphod.net No software firewall on the Container: # iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Not using NetworkManager. The machine has a virtual nic, and is connected to the bridge on the host, and can interact with the outside world. Installation commands: # ipa-server-install --uninstall -U # pkidestroy -s CA -i pki-tomcat # ipa-server-install -N -d --no-host-dns I select the defaults during the interactive install. During installation, everything seems to run fine up to the invocation of pkispawn. I then get the errors: Installing CA into /var/lib/pki/pki-tomcat. Storing deployment configuration into /etc/sysconfig/pki/tomcat/pki-tomcat/ca/deployment.cfg. Installation failed. ipa : DEBUG stderr=Job for pki-tomcatd at pki-tomcat.servicefailed. See 'systemctl status pki-tomcatd at pki-tomcat.service' and 'journalctl -xn' for details. pkispawn : ERROR ....... server failed to restart ipa : CRITICAL failed to configure ca instance Command '/usr/sbin/pkispawn -s CA -f /tmp/tmpwNB5bU' returned non-zero exit status 1 ipa : DEBUG File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 622, in run_script return_value = main_function() File "/usr/sbin/ipa-server-install", line 1074, in main dm_password, subject_base=options.subject) File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 478, in configure_instance self.start_creation(runtime=210) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 364, in start_creation method() File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 604, in __spawn_instance raise RuntimeError('Configuration of CA failed') ipa : DEBUG The ipa-server-install command failed, exception: RuntimeError: Configuration of CA failed Configuration of CA failed the relevant errors from /var/log/pki/pki-ca-spawn.timestamp.log: (the ... skipping... is from the file) ...skipping... y still be down 2013-12-16 18:12:23 pkispawn : DEBUG ........... No connection - exception thrown: Cannot connect to proxy. Socket error: [Errno 111] Connection refused. 2013-12-16 18:12:24 pkispawn : DEBUG ........... No connection - server may still be down 2013-12-16 18:12:24 pkispawn : DEBUG ........... No connection - exception thrown: Cannot connect to proxy. Socket error: [Errno 111] Connection refused. 2013-12-16 18:12:25 pkispawn : DEBUG ........... No connection - server may still be down ... (error repeated 12 more times) ... 2013-12-16 18:12:39 pkispawn : ERROR ....... server failed to restart 2013-12-16 18:12:39 pkispawn : DEBUG ....... Error Type: SystemExit 2013-12-16 18:12:39 pkispawn : DEBUG ....... Error Message: 1 2013-12-16 18:12:39 pkispawn : DEBUG ....... File "/usr/sbin/pkispawn", line 374, in main rv = instance.spawn() File "/usr/lib/python2.7/site-packages/pki/deployment/configuration.py", line 102, in spawn sys.exit(1) ---------------------------------------------------------------------- That's the news from the Mystic River, where all the alliums are strong, all the degu are good looking, and all the stuffed animals are above average. "May the ducks of your life quack ever harmoniously" - A. Yelton galens at capaccess.org galens at marphod.net marphod at gmail.com & others -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Tue Dec 17 01:41:22 2013 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 16 Dec 2013 20:41:22 -0500 Subject: [Freeipa-users] Replica master in strange state -- how to resolve? In-Reply-To: <52AF1EFF.7050502@damascusgrp.com> References: <52AF1EFF.7050502@damascusgrp.com> Message-ID: <52AFABC2.3030700@redhat.com> On 12/16/2013 10:40 AM, Bret Wortman wrote: > I had a replica that was completely failing to respond to its clients, > so I removed it by first running "ipa-replica-manage del" on the > replica master, then "ipa-server-install -U --uninstall" on the > replica. I regenereated the replica file and, upon trying to > re-initialize the replica, received this error: > > : > The host fsipa.spx.net already exists on the master server. > You should remove it before proceeding: > % ipa host-del fsipa.damascusgrp.com > [root at fsipa ~]# > > On the master: > > [root at ipamaster ~]# ipa host-del fsipa.damascusgrp.com > ipa: ERROR: invalid 'hostname': An IPA master host cannot be deleted > or disabled > [root at ipamaster ~]# ipa host-show fsipa.damascusgrp.com > Host name: fsipa.damascusgrp.com > Principal name: host/fsipa.damascusgrp.com at DAMASCUSGRP.COM > Password: False > Keytab: True > Managed by: fsipa.damascusgrp.com > SSH public key fingerprint: ... > : > [root at ipamaster ~]# ipa-replica-manage del fsipa.damascusgrp.com > 'ipamaster.damascusgrp.com' has no replication agreement for > 'fsipa.damascusgrp.com' > [root at ipamaster ~]# > > What's the right way to clean this up without making the situation worse? Do you use IPA DNS? What does DNS say about fsipa.damascusgrp.com and fsipa.spx.net? > > > -- > *Bret Wortman* > > http://damascusgrp.com/ > http://about.me/wortmanbret > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 28526 bytes Desc: not available URL: From dpal at redhat.com Tue Dec 17 01:46:45 2013 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 16 Dec 2013 20:46:45 -0500 Subject: [Freeipa-users] i could use some help with installing FreeIPA In-Reply-To: References: Message-ID: <52AFAD05.6060003@redhat.com> On 12/16/2013 06:46 PM, Galen Brownsmith wrote: > My install fails on the invocation of pkispawn with a Socket Error in > the pki-ca-spawn log ; anyone have any ideas? (It isn't the issue > with special characters in the DM's password, as my Directory Manager > and IPA Admin passwords may be 32 characters long, but only contain > [A-Za-z0-9_] ) > > Configuration and Error Messages follow. > > Target System: Fedora19 64bit LXC Container running on top of a > Fedora19 64bit host. Kernel 3.11.10, Q9550 Intel CPU. > Attempting to install freeipa server 3.3.3 . SEllinux has been set to > 'disabled' on the host and container. > > /etc/hosts: > # IP FQDN Alias(es) > 127.0.0.1 localhost.localdomain localhost localhost4 > 192.168.253.94 woeg.marphod.net > woeg > > # Peers > 192.168.253.99 skete.marphod.net > skete wiki.marphod.net > wiki www.marphod.net > www > [... several more machines] > > /etc/resolv.conf > ; generated by /usr/sbin/dhclient-script > search marphod.net > nameserver 192.168.253.1 > > /etc/sysconfig/network: > NETWORKING=yes > HOSTNAME=woeg.marphod.net > > No software firewall on the Container: > # iptables -L > Chain INPUT (policy ACCEPT) > target prot opt source destination > > Chain FORWARD (policy ACCEPT) > target prot opt source destination > > Chain OUTPUT (policy ACCEPT) > target prot opt source destination > > > Not using NetworkManager. The machine has a virtual nic, and is > connected to the bridge on the host, and can interact with the outside > world. > > Installation commands: > # ipa-server-install --uninstall -U > # pkidestroy -s CA -i pki-tomcat > # ipa-server-install -N -d --no-host-dns > > I select the defaults during the interactive install. > > During installation, everything seems to run fine up to the invocation > of pkispawn. I then get the errors: > > Installing CA into /var/lib/pki/pki-tomcat. > Storing deployment configuration into > /etc/sysconfig/pki/tomcat/pki-tomcat/ca/deployment.cfg. > Installation failed. > > ipa : DEBUG stderr=Job for pki-tomcatd at pki-tomcat.service > failed. See 'systemctl status pki-tomcatd at pki-tomcat.service' and > 'journalctl -xn' for details. > pkispawn : ERROR ....... server failed to restart > > ipa : CRITICAL failed to configure ca instance Command > '/usr/sbin/pkispawn -s CA -f /tmp/tmpwNB5bU' returned non-zero exit > status 1 > ipa : DEBUG File > "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", > line 622, in run_script > return_value = main_function() > > File "/usr/sbin/ipa-server-install", line 1074, in main > dm_password, subject_base=options.subject) > > File > "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", > line 478, in configure_instance > self.start_creation(runtime=210) > > File > "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line > 364, in start_creation > method() > > File > "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", > line 604, in __spawn_instance > raise RuntimeError('Configuration of CA failed') > > ipa : DEBUG The ipa-server-install command failed, > exception: RuntimeError: Configuration of CA failed > Configuration of CA failed > > > the relevant errors from /var/log/pki/pki-ca-spawn.timestamp.log: (the > ... skipping... is from the file) > > ...skipping... > y still be down > 2013-12-16 18:12:23 pkispawn : DEBUG ........... No connection - > exception thrown: Cannot connect to proxy. Socket error: [Errno 111] > Connection refused. > 2013-12-16 18:12:24 pkispawn : DEBUG ........... No connection - > server may still be down > 2013-12-16 18:12:24 pkispawn : DEBUG ........... No connection - > exception thrown: Cannot connect to proxy. Socket error: [Errno 111] > Connection refused. > 2013-12-16 18:12:25 pkispawn : DEBUG ........... No connection - > server may still be down > ... > (error repeated 12 more times) > ... > 2013-12-16 18:12:39 pkispawn : ERROR ....... server failed to > restart > 2013-12-16 18:12:39 pkispawn : DEBUG ....... Error Type: SystemExit > 2013-12-16 18:12:39 pkispawn : DEBUG ....... Error Message: 1 > 2013-12-16 18:12:39 pkispawn : DEBUG ....... File > "/usr/sbin/pkispawn", line 374, in main > rv = instance.spawn() > File > "/usr/lib/python2.7/site-packages/pki/deployment/configuration.py", > line 102, in spawn > sys.exit(1) > > You are trying it in a container. I do not know whether this makes a difference. It might be due to the fact that underlying directory server has not started. Please look at the pki instance DS logs to determine whether the DS instance was installed and configured correctly. http://www.freeipa.org/page/Troubleshooting#Server_Installation Please publish these logs here. > > > > > ---------------------------------------------------------------------- > That's the news from the Mystic River, where all the alliums are > strong, all the degu are good looking, and all the stuffed animals are > above average. > "May the ducks of your life quack ever harmoniously" - A. Yelton > galens at capaccess.org galens at marphod.net > marphod at gmail.com > & others > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Tue Dec 17 03:30:16 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 16 Dec 2013 22:30:16 -0500 Subject: [Freeipa-users] i could use some help with installing FreeIPA In-Reply-To: <52AFAD05.6060003@redhat.com> References: <52AFAD05.6060003@redhat.com> Message-ID: <52AFC548.6070302@redhat.com> Dmitri Pal wrote: > On 12/16/2013 06:46 PM, Galen Brownsmith wrote: >> My install fails on the invocation of pkispawn with a Socket Error in >> the pki-ca-spawn log ; anyone have any ideas? (It isn't the issue >> with special characters in the DM's password, as my Directory Manager >> and IPA Admin passwords may be 32 characters long, but only contain >> [A-Za-z0-9_] ) >> >> Configuration and Error Messages follow. >> >> Target System: Fedora19 64bit LXC Container running on top of a >> Fedora19 64bit host. Kernel 3.11.10, Q9550 Intel CPU. >> Attempting to install freeipa server 3.3.3 . SEllinux has been set to >> 'disabled' on the host and container. >> >> /etc/hosts: >> # IP FQDN Alias(es) >> 127.0.0.1 localhost.localdomain localhost localhost4 >> 192.168.253.94 woeg.marphod.net woeg >> >> # Peers >> 192.168.253.99 skete.marphod.net skete >> wiki.marphod.net wiki www.marphod.net >> www >> [... several more machines] >> >> /etc/resolv.conf >> ; generated by /usr/sbin/dhclient-script >> search marphod.net >> nameserver 192.168.253.1 >> >> /etc/sysconfig/network: >> NETWORKING=yes >> HOSTNAME=woeg.marphod.net >> >> No software firewall on the Container: >> # iptables -L >> Chain INPUT (policy ACCEPT) >> target prot opt source destination >> >> Chain FORWARD (policy ACCEPT) >> target prot opt source destination >> >> Chain OUTPUT (policy ACCEPT) >> target prot opt source destination >> >> >> Not using NetworkManager. The machine has a virtual nic, and is >> connected to the bridge on the host, and can interact with the outside >> world. >> >> Installation commands: >> # ipa-server-install --uninstall -U >> # pkidestroy -s CA -i pki-tomcat >> # ipa-server-install -N -d --no-host-dns >> >> I select the defaults during the interactive install. >> >> During installation, everything seems to run fine up to the invocation >> of pkispawn. I then get the errors: >> >> Installing CA into /var/lib/pki/pki-tomcat. >> Storing deployment configuration into >> /etc/sysconfig/pki/tomcat/pki-tomcat/ca/deployment.cfg. >> Installation failed. >> >> ipa : DEBUG stderr=Job for pki-tomcatd at pki-tomcat.service >> failed. See 'systemctl status pki-tomcatd at pki-tomcat.service' and >> 'journalctl -xn' for details. >> pkispawn : ERROR ....... server failed to restart >> >> ipa : CRITICAL failed to configure ca instance Command >> '/usr/sbin/pkispawn -s CA -f /tmp/tmpwNB5bU' returned non-zero exit >> status 1 >> ipa : DEBUG File >> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", >> line 622, in run_script >> return_value = main_function() >> >> File "/usr/sbin/ipa-server-install", line 1074, in main >> dm_password, subject_base=options.subject) >> >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", >> line 478, in configure_instance >> self.start_creation(runtime=210) >> >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line >> 364, in start_creation >> method() >> >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", >> line 604, in __spawn_instance >> raise RuntimeError('Configuration of CA failed') >> >> ipa : DEBUG The ipa-server-install command failed, >> exception: RuntimeError: Configuration of CA failed >> Configuration of CA failed >> >> >> the relevant errors from /var/log/pki/pki-ca-spawn.timestamp.log: (the >> ... skipping... is from the file) >> >> ...skipping... >> y still be down >> 2013-12-16 18:12:23 pkispawn : DEBUG ........... No connection - >> exception thrown: Cannot connect to proxy. Socket error: [Errno 111] >> Connection refused. >> 2013-12-16 18:12:24 pkispawn : DEBUG ........... No connection - >> server may still be down >> 2013-12-16 18:12:24 pkispawn : DEBUG ........... No connection - >> exception thrown: Cannot connect to proxy. Socket error: [Errno 111] >> Connection refused. >> 2013-12-16 18:12:25 pkispawn : DEBUG ........... No connection - >> server may still be down >> ... >> (error repeated 12 more times) >> ... >> 2013-12-16 18:12:39 pkispawn : ERROR ....... server failed to >> restart >> 2013-12-16 18:12:39 pkispawn : DEBUG ....... Error Type: SystemExit >> 2013-12-16 18:12:39 pkispawn : DEBUG ....... Error Message: 1 >> 2013-12-16 18:12:39 pkispawn : DEBUG ....... File >> "/usr/sbin/pkispawn", line 374, in main >> rv = instance.spawn() >> File >> "/usr/lib/python2.7/site-packages/pki/deployment/configuration.py", >> line 102, in spawn >> sys.exit(1) >> >> > > You are trying it in a container. I do not know whether this makes a > difference. > It might be due to the fact that underlying directory server has not > started. > Please look at the pki instance DS logs to determine whether the DS > instance was installed and configured correctly. > http://www.freeipa.org/page/Troubleshooting#Server_Installation > Please publish these logs here. I'm not entirely sure that IPA works in a container. I think that Nathaniel looked at this a few months ago but I can't recall his findings. rob From rcritten at redhat.com Tue Dec 17 03:37:24 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 16 Dec 2013 22:37:24 -0500 Subject: [Freeipa-users] Replica master in strange state -- how to resolve? In-Reply-To: <52AFABC2.3030700@redhat.com> References: <52AF1EFF.7050502@damascusgrp.com> <52AFABC2.3030700@redhat.com> Message-ID: <52AFC6F4.6060407@redhat.com> Dmitri Pal wrote: > On 12/16/2013 10:40 AM, Bret Wortman wrote: >> I had a replica that was completely failing to respond to its clients, >> so I removed it by first running "ipa-replica-manage del" on the >> replica master, then "ipa-server-install -U --uninstall" on the >> replica. I regenereated the replica file and, upon trying to >> re-initialize the replica, received this error: >> >> : >> The host fsipa.spx.net already exists on the master server. >> You should remove it before proceeding: >> % ipa host-del fsipa.damascusgrp.com >> [root at fsipa ~]# >> >> On the master: >> >> [root at ipamaster ~]# ipa host-del fsipa.damascusgrp.com >> ipa: ERROR: invalid 'hostname': An IPA master host cannot be deleted >> or disabled >> [root at ipamaster ~]# ipa host-show fsipa.damascusgrp.com >> Host name: fsipa.damascusgrp.com >> Principal name: host/fsipa.damascusgrp.com at DAMASCUSGRP.COM >> Password: False >> Keytab: True >> Managed by: fsipa.damascusgrp.com >> SSH public key fingerprint: ... >> : >> [root at ipamaster ~]# ipa-replica-manage del fsipa.damascusgrp.com >> 'ipamaster.damascusgrp.com' has no replication agreement for >> 'fsipa.damascusgrp.com' >> [root at ipamaster ~]# >> >> What's the right way to clean this up without making the situation worse? > > Do you use IPA DNS? > What does DNS say about fsipa.damascusgrp.com and fsipa.spx.net? It would appear that the replica uninstallation was a bit incomplete. The lack of replication may be part of, or the cause of, the problem. I guess I would start by double-checking that the remaining master doesn't have an RUV record for the old one: # ipa-replica-manage list-ruv If so you can use the clean-ruv command to clean things up. Be very careful what number you plug in there. This is one of those "with great power comes great responsibility" commands. As for the remaining master entries, you'll need to use ldapdelete to remove them. Something like this: # ldapdelete -x -D 'cn=directory manager' -W r cn=replica-to-delete.example.com,cn=masters,cn=ipa,cn=etc,dc=greyoak,dc=com ^D My syntax may be a bit off but you basically want to delete this entry and all its children. If you're nervous stick in the -n option and it will tell you what its going to do without deleting anything. Newer IPA has a new command in ipa-replica-manage to make this cleanup easier. Once those entries are gone you can delete the host entry and proceed on your way. rob From galens at capaccess.org Tue Dec 17 06:39:20 2013 From: galens at capaccess.org (Galen Brownsmith) Date: Tue, 17 Dec 2013 01:39:20 -0500 Subject: [Freeipa-users] i could use some help with installing FreeIPA In-Reply-To: <52AFC548.6070302@redhat.com> References: <52AFAD05.6060003@redhat.com> <52AFC548.6070302@redhat.com> Message-ID: > Please look at the pki instance DS logs to determine whether the DS > instance was installed and configured correctly. > http://www.freeipa.org/page/Troubleshooting#Server_Installation > Please publish these logs here. Full logs attached. Admittedly, I'm not sure how to increase the logging level. slapd isn't running when I'm in an uninstalled state so I can't issue lldapmodify, and i don't know where to add commands to increase logging during the installation process. It doesn't look like it is an issue with the directory server. The full log follows, but the only warnings and error in /var/log/dirsrv/slapd-MARPHOD-NET/errors are ones that look (to me) normal during configuration and installation.: [17/Dec/2013:01:06:51 -0500] - WARNING: Import is running with nsslapd-db-private-import-mem on; No other process is allowed to access the database ... [17/Dec/2013:01:06:53 -0500] - Db home directory is not set. Possibly nsslapd-directory (optionally nsslapd-db-home-directory) is missing in the config file. ... [17/Dec/2013:01:06:53 -0500] - Db home directory is not set. Possibly nsslapd-directory (optionally nsslapd-db-home-directory) is missing in the config file. [17/Dec/2013:01:11:44 -0500] schema-compat-plugin - warning: no entries set up under cn=computers, cn=compat,dc=marphod,dc=net [17/Dec/2013:01:11:44 -0500] schema-compat-plugin - warning: no entries set up under cn=ng, cn=compat,dc=marphod,dc=net [17/Dec/2013:01:11:44 -0500] schema-compat-plugin - warning: no entries set up under ou=sudoers,dc=marphod,dc=net [17/Dec/2013:01:11:44 -0500] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=marphod,dc=net--no CoS Templates found, which should be added before the CoS Definition. There are some errors in the access log, but they seem to be in response to failed searches: [17/Dec/2013:01:11:40 -0500] conn=17 op=2 SRCH base="cn=Schema Compatibility,cn=plugins,cn=config" scope=0 filter="(objectClass=*)" attrs="aci * attributeTypes objectClasses aci" [17/Dec/2013:01:11:40 -0500] conn=17 op=2 RESULT err=32 tag=101 nentries=0 etime=0 ... [17/Dec/2013:01:11:40 -0500] conn=17 op=6 SRCH base="cn=users,cn=Schema Compatibility,cn=plugins,cn=config" scope=0 filter="(objectClass=*)" attrs="aci * attributeTypes objectClasses aci" [17/Dec/2013:01:11:40 -0500] conn=17 op=6 RESULT err=32 tag=101 nentries=0 etime=0 ... [17/Dec/2013:01:11:40 -0500] conn=17 op=10 SRCH base="cn=computers,cn=Schema Compatibility,cn=plugins,cn=config" scope=0 filter="(objectClass=*)" attrs="aci * attributeTypes objectClasses aci" [17/Dec/2013:01:11:40 -0500] conn=17 op=10 RESULT err=32 tag=101 nentries=0 etime=0 ... [17/Dec/2013:01:11:40 -0500] conn=17 op=12 SRCH base="cn=ng,cn=Schema Compatibility,cn=plugins,cn=config" scope=0 filter="(objectClass=*)" attrs="aci * attributeTypes objectClasses aci" [17/Dec/2013:01:11:40 -0500] conn=17 op=12 RESULT err=32 tag=101 nentries=0 etime=0 ... [17/Dec/2013:01:11:40 -0500] conn=17 op=14 SRCH base="cn=groups,cn=Schema Compatibility,cn=plugins,cn=config" scope=0 filter="(objectClass=*)" attrs="aci * attributeTypes objectClasses aci" [17/Dec/2013:01:11:40 -0500] conn=17 op=14 RESULT err=32 tag=101 nentries=0 etime=0 ... [17/Dec/2013:01:11:44 -0500] conn=3 op=2 SRCH base="o=ipaca" scope=0 filter="(objectClass=*)" attrs=ALL [17/Dec/2013:01:11:44 -0500] conn=3 op=2 RESULT err=32 tag=101 nentries=0 etime=0 systemctl also reports that dirsrv at MARPHOD-NET is running fine # systemctl status dirsrv at MARPHOD-NET dirsrv at MARPHOD-NET.service - 389 Directory Server MARPHOD-NET. Loaded: loaded (/usr/lib/systemd/system/dirsrv at .service; enabled) Active: active (running) since Tue 2013-12-17 01:11:44 EST; 9min ago Main PID: 647 (ns-slapd) CGroup: name=systemd:/user/1000.user/1.session/system/dirsrv at .service/dirsrv at MARPHOD-NET.service ??647 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-MARPHOD-NET -i /var/... Dec 17 01:11:44 woeg.marphod.net systemd[1]: Started 389 Directory Server MA.... ---------------------------------------------------------------------- That's the news from the Mystic River, where all the alliums are strong, all the degu are good looking, and all the stuffed animals are above average. "May the ducks of your life quack ever harmoniously" - A. Yelton galens at capaccess.org galens at marphod.net marphod at gmail.com & others On Mon, Dec 16, 2013 at 10:30 PM, Rob Crittenden wrote: > > Dmitri Pal wrote: >> >> On 12/16/2013 06:46 PM, Galen Brownsmith wrote: >>> >>> My install fails on the invocation of pkispawn with a Socket Error in >>> the pki-ca-spawn log ; anyone have any ideas? (It isn't the issue >>> with special characters in the DM's password, as my Directory Manager >>> and IPA Admin passwords may be 32 characters long, but only contain >>> [A-Za-z0-9_] ) >>> >>> Configuration and Error Messages follow. >>> >>> Target System: Fedora19 64bit LXC Container running on top of a >>> Fedora19 64bit host. Kernel 3.11.10, Q9550 Intel CPU. >>> Attempting to install freeipa server 3.3.3 . SEllinux has been set to >>> 'disabled' on the host and container. >>> >>> /etc/hosts: >>> # IP FQDN Alias(es) >>> 127.0.0.1 localhost.localdomain localhost localhost4 >>> 192.168.253.94 woeg.marphod.net woeg >>> >>> # Peers >>> 192.168.253.99 skete.marphod.net skete >>> wiki.marphod.net wiki www.marphod.net >>> www >>> >>> [... several more machines] >>> >>> /etc/resolv.conf >>> ; generated by /usr/sbin/dhclient-script >>> search marphod.net >>> nameserver 192.168.253.1 >>> >>> /etc/sysconfig/network: >>> NETWORKING=yes >>> HOSTNAME=woeg.marphod.net >>> >>> >>> No software firewall on the Container: >>> # iptables -L >>> Chain INPUT (policy ACCEPT) >>> target prot opt source destination >>> >>> Chain FORWARD (policy ACCEPT) >>> target prot opt source destination >>> >>> Chain OUTPUT (policy ACCEPT) >>> target prot opt source destination >>> >>> >>> Not using NetworkManager. The machine has a virtual nic, and is >>> connected to the bridge on the host, and can interact with the outside >>> world. >>> >>> Installation commands: >>> # ipa-server-install --uninstall -U >>> # pkidestroy -s CA -i pki-tomcat >>> # ipa-server-install -N -d --no-host-dns >>> >>> I select the defaults during the interactive install. >>> >>> During installation, everything seems to run fine up to the invocation >>> of pkispawn. I then get the errors: >>> >>> Installing CA into /var/lib/pki/pki-tomcat. >>> Storing deployment configuration into >>> /etc/sysconfig/pki/tomcat/pki-tomcat/ca/deployment.cfg. >>> Installation failed. >>> >>> ipa : DEBUG stderr=Job for pki-tomcatd at pki-tomcat.service >>> failed. See 'systemctl status pki-tomcatd at pki-tomcat.service' and >>> 'journalctl -xn' for details. >>> pkispawn : ERROR ....... server failed to restart >>> >>> ipa : CRITICAL failed to configure ca instance Command >>> '/usr/sbin/pkispawn -s CA -f /tmp/tmpwNB5bU' returned non-zero exit >>> status 1 >>> ipa : DEBUG File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", >>> line 622, in run_script >>> return_value = main_function() >>> >>> File "/usr/sbin/ipa-server-install", line 1074, in main >>> dm_password, subject_base=options.subject) >>> >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", >>> line 478, in configure_instance >>> self.start_creation(runtime=210) >>> >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line >>> 364, in start_creation >>> method() >>> >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", >>> line 604, in __spawn_instance >>> raise RuntimeError('Configuration of CA failed') >>> >>> ipa : DEBUG The ipa-server-install command failed, >>> exception: RuntimeError: Configuration of CA failed >>> Configuration of CA failed >>> >>> >>> the relevant errors from /var/log/pki/pki-ca-spawn.timestamp.log: (the >>> ... skipping... is from the file) >>> >>> ...skipping... >>> y still be down >>> 2013-12-16 18:12:23 pkispawn : DEBUG ........... No connection - >>> exception thrown: Cannot connect to proxy. Socket error: [Errno 111] >>> Connection refused. >>> 2013-12-16 18:12:24 pkispawn : DEBUG ........... No connection - >>> server may still be down >>> 2013-12-16 18:12:24 pkispawn : DEBUG ........... No connection - >>> exception thrown: Cannot connect to proxy. Socket error: [Errno 111] >>> Connection refused. >>> 2013-12-16 18:12:25 pkispawn : DEBUG ........... No connection - >>> server may still be down >>> ... >>> (error repeated 12 more times) >>> ... >>> 2013-12-16 18:12:39 pkispawn : ERROR ....... server failed to >>> restart >>> 2013-12-16 18:12:39 pkispawn : DEBUG ....... Error Type: SystemExit >>> 2013-12-16 18:12:39 pkispawn : DEBUG ....... Error Message: 1 >>> 2013-12-16 18:12:39 pkispawn : DEBUG ....... File >>> "/usr/sbin/pkispawn", line 374, in main >>> rv = instance.spawn() >>> File >>> "/usr/lib/python2.7/site-packages/pki/deployment/configuration.py", >>> line 102, in spawn >>> sys.exit(1) >>> >>> >> >> You are trying it in a container. I do not know whether this makes a >> difference. >> It might be due to the fact that underlying directory server has not >> started. >> Please look at the pki instance DS logs to determine whether the DS >> instance was installed and configured correctly. >> http://www.freeipa.org/page/Troubleshooting#Server_Installation >> Please publish these logs here. > > > I'm not entirely sure that IPA works in a container. I think that Nathaniel looked at this a few months ago but I can't recall his findings. > > rob > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- A non-text attachment was scrubbed... Name: access Type: application/octet-stream Size: 60877 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: errors Type: application/octet-stream Size: 5645 bytes Desc: not available URL: From abokovoy at redhat.com Tue Dec 17 09:14:34 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 17 Dec 2013 11:14:34 +0200 Subject: [Freeipa-users] WARNING: Do not upgrade FreeIPA deployments to Fedora 20 final (yet) Message-ID: <20131217091434.GW21264@redhat.com> Greetings! As many of you are aware, Fedora Project releases Fedora 20 today, Tuesday, December 17th. This post serves as a warning against upgrading your FreeIPA deployments to Fedora 20 using release images. Please check Fedora 20 Common Bugs page https://fedoraproject.org/wiki/Common_F20_bugs for the complete list of issues. FreeIPA relies heavily on 389-ds Directory Server. Fedora 20 introduces new version series of 389-ds, 1.3.2.x. Along with multiple enhancements, unfortunately, few bugs went into the version currently available in Fedora 20 stable tree. These bugs are causing crashes under certain conditions and we don't recommend updating your existing configurations due to these consequences. As an update to the Fedora 20 Common Bugs page, over last night fellow developers from 389-ds and slapi-nis projects have fixed https://bugzilla.redhat.com/show_bug.cgi?id=1043546 and https://bugzilla.redhat.com/show_bug.cgi?id=1041732 but there will be some delay before the builds featuring the fixes will appear in Fedora 20 updates repository. Remaining bugs are under investigation. I'll post an update note once we'll get remaining issues fixed and packages pushed to Fedora 20 updates repository. -- / Alexander Bokovoy From bret.wortman at damascusgrp.com Tue Dec 17 13:16:41 2013 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Tue, 17 Dec 2013 08:16:41 -0500 Subject: [Freeipa-users] Replica master in strange state -- how to resolve? In-Reply-To: <52AFC6F4.6060407@redhat.com> References: <52AF1EFF.7050502@damascusgrp.com> <52AFABC2.3030700@redhat.com> <52AFC6F4.6060407@redhat.com> Message-ID: <52B04EB9.2060908@damascusgrp.com> On 12/16/2013 10:37 PM, Rob Crittenden wrote: > Dmitri Pal wrote: >> On 12/16/2013 10:40 AM, Bret Wortman wrote: >>> I had a replica that was completely failing to respond to its clients, >>> so I removed it by first running "ipa-replica-manage del" on the >>> replica master, then "ipa-server-install -U --uninstall" on the >>> replica. I regenereated the replica file and, upon trying to >>> re-initialize the replica, received this error: >>> >>> : >>> The host fsipa.spx.net already exists on the master server. >>> You should remove it before proceeding: >>> % ipa host-del fsipa.damascusgrp.com >>> [root at fsipa ~]# >>> >>> On the master: >>> >>> [root at ipamaster ~]# ipa host-del fsipa.damascusgrp.com >>> ipa: ERROR: invalid 'hostname': An IPA master host cannot be deleted >>> or disabled >>> [root at ipamaster ~]# ipa host-show fsipa.damascusgrp.com >>> Host name: fsipa.damascusgrp.com >>> Principal name: host/fsipa.damascusgrp.com at DAMASCUSGRP.COM >>> Password: False >>> Keytab: True >>> Managed by: fsipa.damascusgrp.com >>> SSH public key fingerprint: ... >>> : >>> [root at ipamaster ~]# ipa-replica-manage del fsipa.damascusgrp.com >>> 'ipamaster.damascusgrp.com' has no replication agreement for >>> 'fsipa.damascusgrp.com' >>> [root at ipamaster ~]# >>> >>> What's the right way to clean this up without making the situation >>> worse? >> >> Do you use IPA DNS? Yes >> What does DNS say about fsipa.damascusgrp.com and fsipa.spx.net? > > It would appear that the replica uninstallation was a bit incomplete. > The lack of replication may be part of, or the cause of, the problem. > > I guess I would start by double-checking that the remaining master > doesn't have an RUV record for the old one: > > # ipa-replica-manage list-ruv > This returns nothing, so I'm assuming that's good. > If so you can use the clean-ruv command to clean things up. Be very > careful what number you plug in there. This is one of those "with > great power comes great responsibility" commands. > > As for the remaining master entries, you'll need to use ldapdelete to > remove them. > > Something like this: > > # ldapdelete -x -D 'cn=directory manager' -W r > cn=replica-to-delete.example.com,cn=masters,cn=ipa,cn=etc,dc=greyoak,dc=com > > ^D > # ldapdelete -x -D 'cn=directory manager' -W -r cn=fsipa.damascusgrp.com,cn=masters,cn=ipa,cn=etc,dc=damascusgrp,dc=com ^D ldap_delete: Operations error (1) ldap_delete: Operation not allowed on non-leaf (66) # > My syntax may be a bit off but you basically want to delete this entry > and all its children. If you're nervous stick in the -n option and it > will tell you what its going to do without deleting anything. > Actually, the "-n" option just distracted me for 5 minutes -- it had me chasing syntax until I realized that it was just not doing anything and not reporting anything either. Dropping it led to the error above. > Newer IPA has a new command in ipa-replica-manage to make this cleanup > easier. > Looking forward to upgrading, then. Replica management is a headache for us, but given the benefits IPA has brought, it's worth it. Thanks for all your help. > Once those entries are gone you can delete the host entry and proceed > on your way. > > rob > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3766 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Tue Dec 17 14:15:18 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 17 Dec 2013 09:15:18 -0500 Subject: [Freeipa-users] Replica master in strange state -- how to resolve? In-Reply-To: <52B04EB9.2060908@damascusgrp.com> References: <52AF1EFF.7050502@damascusgrp.com> <52AFABC2.3030700@redhat.com> <52AFC6F4.6060407@redhat.com> <52B04EB9.2060908@damascusgrp.com> Message-ID: <52B05C76.70103@redhat.com> Bret Wortman wrote: > > On 12/16/2013 10:37 PM, Rob Crittenden wrote: >> Dmitri Pal wrote: >>> On 12/16/2013 10:40 AM, Bret Wortman wrote: >>>> I had a replica that was completely failing to respond to its clients, >>>> so I removed it by first running "ipa-replica-manage del" on the >>>> replica master, then "ipa-server-install -U --uninstall" on the >>>> replica. I regenereated the replica file and, upon trying to >>>> re-initialize the replica, received this error: >>>> >>>> : >>>> The host fsipa.spx.net already exists on the master server. >>>> You should remove it before proceeding: >>>> % ipa host-del fsipa.damascusgrp.com >>>> [root at fsipa ~]# >>>> >>>> On the master: >>>> >>>> [root at ipamaster ~]# ipa host-del fsipa.damascusgrp.com >>>> ipa: ERROR: invalid 'hostname': An IPA master host cannot be deleted >>>> or disabled >>>> [root at ipamaster ~]# ipa host-show fsipa.damascusgrp.com >>>> Host name: fsipa.damascusgrp.com >>>> Principal name: host/fsipa.damascusgrp.com at DAMASCUSGRP.COM >>>> Password: False >>>> Keytab: True >>>> Managed by: fsipa.damascusgrp.com >>>> SSH public key fingerprint: ... >>>> : >>>> [root at ipamaster ~]# ipa-replica-manage del fsipa.damascusgrp.com >>>> 'ipamaster.damascusgrp.com' has no replication agreement for >>>> 'fsipa.damascusgrp.com' >>>> [root at ipamaster ~]# >>>> >>>> What's the right way to clean this up without making the situation >>>> worse? >>> >>> Do you use IPA DNS? > > Yes >>> What does DNS say about fsipa.damascusgrp.com and fsipa.spx.net? >> >> It would appear that the replica uninstallation was a bit incomplete. >> The lack of replication may be part of, or the cause of, the problem. >> >> I guess I would start by double-checking that the remaining master >> doesn't have an RUV record for the old one: >> >> # ipa-replica-manage list-ruv >> > This returns nothing, so I'm assuming that's good. > >> If so you can use the clean-ruv command to clean things up. Be very >> careful what number you plug in there. This is one of those "with >> great power comes great responsibility" commands. >> >> As for the remaining master entries, you'll need to use ldapdelete to >> remove them. >> >> Something like this: >> >> # ldapdelete -x -D 'cn=directory manager' -W r >> cn=replica-to-delete.example.com,cn=masters,cn=ipa,cn=etc,dc=greyoak,dc=com >> >> ^D >> > # ldapdelete -x -D 'cn=directory manager' -W -r > cn=fsipa.damascusgrp.com,cn=masters,cn=ipa,cn=etc,dc=damascusgrp,dc=com > ^D > ldap_delete: Operations error (1) > ldap_delete: Operation not allowed on non-leaf (66) > # Strange. The -r is for recursion and should delete all the children too. Oh well. Instead try this: ldapsearch -LLL -x -D 'cn=Directory manager' -W -b cn=fsipa.damascusgrp.com,cn=masters,cn=ipa,cn=etc,dc=damascusgrp,dc=com dn Those are all the dns to pass to ldapdelete. Delete the leaf nodes (the service entries) first, then the fsipa value. >> My syntax may be a bit off but you basically want to delete this entry >> and all its children. If you're nervous stick in the -n option and it >> will tell you what its going to do without deleting anything. >> > Actually, the "-n" option just distracted me for 5 minutes -- it had me > chasing syntax until I realized that it was just not doing anything and > not reporting anything either. Dropping it led to the error above. Right, -n is to show what would be done without actually doing anything. It is handy with a command like this, especially when using recursion. cheers rob > >> Newer IPA has a new command in ipa-replica-manage to make this cleanup >> easier. >> > Looking forward to upgrading, then. Replica management is a headache for > us, but given the benefits IPA has brought, it's worth it. Thanks for > all your help. > >> Once those entries are gone you can delete the host entry and proceed >> on your way. >> >> rob >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > From bret.wortman at damascusgrp.com Tue Dec 17 14:24:52 2013 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Tue, 17 Dec 2013 09:24:52 -0500 Subject: [Freeipa-users] Replica master in strange state -- how to resolve? In-Reply-To: <52B05C76.70103@redhat.com> References: <52AF1EFF.7050502@damascusgrp.com> <52AFABC2.3030700@redhat.com> <52AFC6F4.6060407@redhat.com> <52B04EB9.2060908@damascusgrp.com> <52B05C76.70103@redhat.com> Message-ID: <52B05EB4.5080202@damascusgrp.com> On 12/17/2013 09:15 AM, Rob Crittenden wrote: > Bret Wortman wrote: >> >> On 12/16/2013 10:37 PM, Rob Crittenden wrote: >>> Dmitri Pal wrote: >>>> On 12/16/2013 10:40 AM, Bret Wortman wrote: >>>>> I had a replica that was completely failing to respond to its >>>>> clients, >>>>> so I removed it by first running "ipa-replica-manage del" on the >>>>> replica master, then "ipa-server-install -U --uninstall" on the >>>>> replica. I regenereated the replica file and, upon trying to >>>>> re-initialize the replica, received this error: >>>>> >>>>> : >>>>> The host fsipa.spx.net already exists on the master server. >>>>> You should remove it before proceeding: >>>>> % ipa host-del fsipa.damascusgrp.com >>>>> [root at fsipa ~]# >>>>> >>>>> On the master: >>>>> >>>>> [root at ipamaster ~]# ipa host-del fsipa.damascusgrp.com >>>>> ipa: ERROR: invalid 'hostname': An IPA master host cannot be deleted >>>>> or disabled >>>>> [root at ipamaster ~]# ipa host-show fsipa.damascusgrp.com >>>>> Host name: fsipa.damascusgrp.com >>>>> Principal name: host/fsipa.damascusgrp.com at DAMASCUSGRP.COM >>>>> Password: False >>>>> Keytab: True >>>>> Managed by: fsipa.damascusgrp.com >>>>> SSH public key fingerprint: ... >>>>> : >>>>> [root at ipamaster ~]# ipa-replica-manage del fsipa.damascusgrp.com >>>>> 'ipamaster.damascusgrp.com' has no replication agreement for >>>>> 'fsipa.damascusgrp.com' >>>>> [root at ipamaster ~]# >>>>> >>>>> What's the right way to clean this up without making the situation >>>>> worse? >>>> >>>> Do you use IPA DNS? >> >> Yes >>>> What does DNS say about fsipa.damascusgrp.com and fsipa.spx.net? >>> >>> It would appear that the replica uninstallation was a bit incomplete. >>> The lack of replication may be part of, or the cause of, the problem. >>> >>> I guess I would start by double-checking that the remaining master >>> doesn't have an RUV record for the old one: >>> >>> # ipa-replica-manage list-ruv >>> >> This returns nothing, so I'm assuming that's good. >> >>> If so you can use the clean-ruv command to clean things up. Be very >>> careful what number you plug in there. This is one of those "with >>> great power comes great responsibility" commands. >>> >>> As for the remaining master entries, you'll need to use ldapdelete to >>> remove them. >>> >>> Something like this: >>> >>> # ldapdelete -x -D 'cn=directory manager' -W r >>> cn=replica-to-delete.example.com,cn=masters,cn=ipa,cn=etc,dc=greyoak,dc=com >>> >>> >>> ^D >>> >> # ldapdelete -x -D 'cn=directory manager' -W -r >> cn=fsipa.damascusgrp.com,cn=masters,cn=ipa,cn=etc,dc=damascusgrp,dc=com >> ^D >> ldap_delete: Operations error (1) >> ldap_delete: Operation not allowed on non-leaf (66) >> # > > Strange. The -r is for recursion and should delete all the children too. > > Oh well. Instead try this: > > ldapsearch -LLL -x -D 'cn=Directory manager' -W -b > cn=fsipa.damascusgrp.com,cn=masters,cn=ipa,cn=etc,dc=damascusgrp,dc=com dn > > > Those are all the dns to pass to ldapdelete. Delete the leaf nodes > (the service entries) first, then the fsipa value. > Worked like a champ. Thanks. >>> My syntax may be a bit off but you basically want to delete this entry >>> and all its children. If you're nervous stick in the -n option and it >>> will tell you what its going to do without deleting anything. >>> >> Actually, the "-n" option just distracted me for 5 minutes -- it had me >> chasing syntax until I realized that it was just not doing anything and >> not reporting anything either. Dropping it led to the error above. > > Right, -n is to show what would be done without actually doing > anything. It is handy with a command like this, especially when using > recursion. Sorry, I wasn't clear -- when I used "-n", it just returned immediately. Didn't show it doing anything, probably because of the error above, but it didn't report that error either; just swallowed it. > > cheers > > rob > >> >>> Newer IPA has a new command in ipa-replica-manage to make this cleanup >>> easier. >>> >> Looking forward to upgrading, then. Replica management is a headache for >> us, but given the benefits IPA has brought, it's worth it. Thanks for >> all your help. >> >>> Once those entries are gone you can delete the host entry and proceed >>> on your way. >>> >>> rob >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3766 bytes Desc: S/MIME Cryptographic Signature URL: From sakodak at gmail.com Tue Dec 17 16:15:17 2013 From: sakodak at gmail.com (KodaK) Date: Tue, 17 Dec 2013 10:15:17 -0600 Subject: [Freeipa-users] WARNING: Do not upgrade FreeIPA deployments to Fedora 20 final (yet) In-Reply-To: <20131217091434.GW21264@redhat.com> References: <20131217091434.GW21264@redhat.com> Message-ID: I took a look at the bugs page and I didn't see it mentioned, but I'm asking anyway: is anyone aware of any client-side issues on fedora IRT IPA? We have some fedora workstations that auth against IPA in RHEL 6. On Tue, Dec 17, 2013 at 3:14 AM, Alexander Bokovoy wrote: > Greetings! > > As many of you are aware, Fedora Project releases Fedora 20 today, > Tuesday, December 17th. This post serves as a warning against upgrading > your FreeIPA deployments to Fedora 20 using release images. Please check > Fedora 20 Common Bugs page https://fedoraproject.org/wiki/Common_F20_bugs > for the complete list of issues. > > FreeIPA relies heavily on 389-ds Directory Server. Fedora 20 introduces > new version series of 389-ds, 1.3.2.x. Along with multiple enhancements, > unfortunately, few bugs went into the version currently available in > Fedora 20 stable tree. These bugs are causing crashes under certain > conditions and we don't recommend updating your existing configurations > due to these consequences. > > As an update to the Fedora 20 Common Bugs page, over last night fellow > developers from 389-ds and slapi-nis projects have fixed > https://bugzilla.redhat.com/show_bug.cgi?id=1043546 and > https://bugzilla.redhat.com/show_bug.cgi?id=1041732 but there will be > some delay before the builds featuring the fixes will appear in Fedora > 20 updates repository. Remaining bugs are under investigation. > > I'll post an update note once we'll get remaining issues fixed and packages > pushed to Fedora 20 updates repository. > > -- > / Alexander Bokovoy > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -- The government is going to read our mail anyway, might as well make it tough for them. GPG Public key ID: B6A1A7C6 -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Tue Dec 17 16:39:36 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 17 Dec 2013 18:39:36 +0200 Subject: [Freeipa-users] WARNING: Do not upgrade FreeIPA deployments to Fedora 20 final (yet) In-Reply-To: References: <20131217091434.GW21264@redhat.com> Message-ID: <20131217163936.GE21264@redhat.com> On Tue, 17 Dec 2013, KodaK wrote: >I took a look at the bugs page and I didn't see it mentioned, but I'm >asking anyway: > >is anyone aware of any client-side issues on fedora IRT IPA? We have some >fedora workstations that auth against IPA in RHEL 6. We are unaware of any problems with Fedora clients versus RHEL 6 IPA server. Obviously, some IPA CLI commands will not work against the older server but still will be visible in the CLI help, but the rest should be working. -- / Alexander Bokovoy From mitkany at gmail.com Tue Dec 17 23:34:19 2013 From: mitkany at gmail.com (Dimitar Georgievski) Date: Tue, 17 Dec 2013 18:34:19 -0500 Subject: [Freeipa-users] Sudo issues with FreeIPA Message-ID: Hi, I am running FreeIPA 3.3.3 on CentOS 6.5. Everything works fine except that I have problem enforcing sudo policies on the hosts that are part of the managed domain. When trying to run the following simple command as a user managed by FreeIPA I got the following response: *> sudo /usr/bin/vim test.txt* *jsmith is not allowed to run sudo on myhost. This incident will be reported.* I might have missed in the configuration of the serve or SSSD on the client host. Is there any guideline for sudo integration with FreeIPA? The following is the SSSD configuration on the client host: [domain/example.net] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = example.net id_provider = ipa auth_provider = ipa access_provider = ipa sudo_provider = ldap ldap_tls_cacert = /etc/ipa/ca.crt ipa_hostname = ipaserver.example.net chpass_provider = ipa ipa_server = _srv_ ipa_backup_server = replica.example.net dns_discovery_domain = example.net [sssd] services = nss, pam, ssh, sudo config_file_version = 2 domains = example.net [nss] [pam] [sudo] debug_level = 0x3ff0 [autofs] [ssh] [pac] Thanks, Dimitar -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Tue Dec 17 23:47:58 2013 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 17 Dec 2013 18:47:58 -0500 Subject: [Freeipa-users] Sudo issues with FreeIPA In-Reply-To: References: Message-ID: <52B0E2AE.4080307@redhat.com> On 12/17/2013 06:34 PM, Dimitar Georgievski wrote: > Hi, > > I am running FreeIPA 3.3.3 on CentOS 6.5. Everything works fine > except that I have problem enforcing sudo policies on the hosts that > are part of the managed domain. > > When trying to run the following simple command as a user managed by > FreeIPA I got the following response: > > /> sudo /usr/bin/vim test.txt > / > /jsmith is not allowed to run sudo on myhost. This incident will be > reported./ > / > / > / /I might have missed in the configuration of the serve or SSSD on > the client host. > > Is there any guideline for sudo integration with FreeIPA? > > The following is the SSSD configuration on the client host: > > [domain/example.net ] > > cache_credentials = True > krb5_store_password_if_offline = True > ipa_domain = example.net > id_provider = ipa > auth_provider = ipa > access_provider = ipa > sudo_provider = ldap > ldap_tls_cacert = /etc/ipa/ca.crt > ipa_hostname = ipaserver.example.net > chpass_provider = ipa > ipa_server = _srv_ > ipa_backup_server = replica.example.net > > > dns_discovery_domain = example.net > > > > [sssd] > services = nss, pam, ssh, sudo > config_file_version = 2 > > domains = example.net > [nss] > > [pam] > > [sudo] > debug_level = 0x3ff0 > > [autofs] > > [ssh] > > [pac] > > Thanks, > > Dimitar > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Less at imagine-sw.com Wed Dec 18 00:03:51 2013 From: Less at imagine-sw.com (Les Stott) Date: Wed, 18 Dec 2013 00:03:51 +0000 Subject: [Freeipa-users] Question: re replica install Message-ID: <4ED173A868981548967B4FCA2707222602BAFE@AACMBXP04.exchserver.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nagerjj at gmail.com Wed Dec 18 01:23:36 2013 From: nagerjj at gmail.com (Joshua Nager) Date: Tue, 17 Dec 2013 20:23:36 -0500 Subject: [Freeipa-users] freeipa client wont install on host where a ipa server guest is already installed. Message-ID: <002401cefb8f$c6bcf350$5436d9f0$@gmail.com> Greetings, I have a question on a Free-ipa install. I am running freeipa as a guest KVM virtual machine. I have found myself running into a problem when trying to install ipa-client on the host which the guest resides. Upon trying to install the ipa-client I am given the msg that I must first uninstall the ipa server. Has anyone experienced this and how might I get around this problem? Thank you in advance. Regards, -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpazdziora at redhat.com Wed Dec 18 01:27:45 2013 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Wed, 18 Dec 2013 09:27:45 +0800 Subject: [Freeipa-users] freeipa client wont install on host where a ipa server guest is already installed. In-Reply-To: <002401cefb8f$c6bcf350$5436d9f0$@gmail.com> References: <002401cefb8f$c6bcf350$5436d9f0$@gmail.com> Message-ID: <20131218012745.GR3298@redhat.com> On Tue, Dec 17, 2013 at 08:23:36PM -0500, Joshua Nager wrote: > > I am running freeipa as a guest KVM virtual machine. I have found myself > running into a problem when trying to install ipa-client on the host which > the guest resides. > > Upon trying to install the ipa-client I am given the msg that I must first > uninstall the ipa server. What is the OS version and the exact message that you get? > Has anyone experienced this and how might I get around this problem? Are you sure you don't have the IPA server installed on both the KVM guest *and* on the host? -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat From mitkany at gmail.com Wed Dec 18 03:40:20 2013 From: mitkany at gmail.com (Dimitar Georgievski) Date: Tue, 17 Dec 2013 22:40:20 -0500 Subject: [Freeipa-users] Sudo issues with FreeIPA In-Reply-To: <52B0E2AE.4080307@redhat.com> References: <52B0E2AE.4080307@redhat.com> Message-ID: Thanks Dmitri. Those settings for ldap in sssd.conf fixed the issue. Dimitar On Tue, Dec 17, 2013 at 6:47 PM, Dmitri Pal wrote: > On 12/17/2013 06:34 PM, Dimitar Georgievski wrote: > > Hi, > > I am running FreeIPA 3.3.3 on CentOS 6.5. Everything works fine except > that I have problem enforcing sudo policies on the hosts that are part of > the managed domain. > > When trying to run the following simple command as a user managed by > FreeIPA I got the following response: > > > *> sudo /usr/bin/vim test.txt * > *jsmith is not allowed to run sudo on myhost. This incident will be > reported.* > > I might have missed in the configuration of the serve or SSSD on the > client host. > > Is there any guideline for sudo integration with FreeIPA? > > The following is the SSSD configuration on the client host: > > [domain/example.net] > > cache_credentials = True > krb5_store_password_if_offline = True > ipa_domain = example.net > id_provider = ipa > auth_provider = ipa > access_provider = ipa > sudo_provider = ldap > ldap_tls_cacert = /etc/ipa/ca.crt > ipa_hostname = ipaserver.example.net > chpass_provider = ipa > ipa_server = _srv_ > ipa_backup_server = replica.example.net > > > dns_discovery_domain = example.net > > > > [sssd] > services = nss, pam, ssh, sudo > config_file_version = 2 > > domains = example.net > [nss] > > [pam] > > [sudo] > debug_level = 0x3ff0 > > [autofs] > > [ssh] > > [pac] > > Thanks, > > Dimitar > > > _______________________________________________ > Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users > > > http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs?www.redhat.com/carveoutcosts/ > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From npmccallum at redhat.com Wed Dec 18 14:47:21 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 18 Dec 2013 09:47:21 -0500 Subject: [Freeipa-users] i could use some help with installing FreeIPA In-Reply-To: <52AFC548.6070302@redhat.com> References: <52AFAD05.6060003@redhat.com> <52AFC548.6070302@redhat.com> Message-ID: <1387378041.1948.98.camel@localhost.localdomain> On Mon, 2013-12-16 at 22:30 -0500, Rob Crittenden wrote: > Dmitri Pal wrote: > > On 12/16/2013 06:46 PM, Galen Brownsmith wrote: > >> My install fails on the invocation of pkispawn with a Socket Error in > >> the pki-ca-spawn log ; anyone have any ideas? (It isn't the issue > >> with special characters in the DM's password, as my Directory Manager > >> and IPA Admin passwords may be 32 characters long, but only contain > >> [A-Za-z0-9_] ) > >> > >> Configuration and Error Messages follow. > >> > >> Target System: Fedora19 64bit LXC Container running on top of a > >> Fedora19 64bit host. Kernel 3.11.10, Q9550 Intel CPU. > >> Attempting to install freeipa server 3.3.3 . SEllinux has been set to > >> 'disabled' on the host and container. > >> > >> /etc/hosts: > >> # IP FQDN Alias(es) > >> 127.0.0.1 localhost.localdomain localhost localhost4 > >> 192.168.253.94 woeg.marphod.net woeg > >> > >> # Peers > >> 192.168.253.99 skete.marphod.net skete > >> wiki.marphod.net wiki www.marphod.net > >> www > >> [... several more machines] > >> > >> /etc/resolv.conf > >> ; generated by /usr/sbin/dhclient-script > >> search marphod.net > >> nameserver 192.168.253.1 > >> > >> /etc/sysconfig/network: > >> NETWORKING=yes > >> HOSTNAME=woeg.marphod.net > >> > >> No software firewall on the Container: > >> # iptables -L > >> Chain INPUT (policy ACCEPT) > >> target prot opt source destination > >> > >> Chain FORWARD (policy ACCEPT) > >> target prot opt source destination > >> > >> Chain OUTPUT (policy ACCEPT) > >> target prot opt source destination > >> > >> > >> Not using NetworkManager. The machine has a virtual nic, and is > >> connected to the bridge on the host, and can interact with the outside > >> world. > >> > >> Installation commands: > >> # ipa-server-install --uninstall -U > >> # pkidestroy -s CA -i pki-tomcat > >> # ipa-server-install -N -d --no-host-dns > >> > >> I select the defaults during the interactive install. > >> > >> During installation, everything seems to run fine up to the invocation > >> of pkispawn. I then get the errors: > >> > >> Installing CA into /var/lib/pki/pki-tomcat. > >> Storing deployment configuration into > >> /etc/sysconfig/pki/tomcat/pki-tomcat/ca/deployment.cfg. > >> Installation failed. > >> > >> ipa : DEBUG stderr=Job for pki-tomcatd at pki-tomcat.service > >> failed. See 'systemctl status pki-tomcatd at pki-tomcat.service' and > >> 'journalctl -xn' for details. > >> pkispawn : ERROR ....... server failed to restart > >> > >> ipa : CRITICAL failed to configure ca instance Command > >> '/usr/sbin/pkispawn -s CA -f /tmp/tmpwNB5bU' returned non-zero exit > >> status 1 > >> ipa : DEBUG File > >> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", > >> line 622, in run_script > >> return_value = main_function() > >> > >> File "/usr/sbin/ipa-server-install", line 1074, in main > >> dm_password, subject_base=options.subject) > >> > >> File > >> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", > >> line 478, in configure_instance > >> self.start_creation(runtime=210) > >> > >> File > >> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line > >> 364, in start_creation > >> method() > >> > >> File > >> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", > >> line 604, in __spawn_instance > >> raise RuntimeError('Configuration of CA failed') > >> > >> ipa : DEBUG The ipa-server-install command failed, > >> exception: RuntimeError: Configuration of CA failed > >> Configuration of CA failed > >> > >> > >> the relevant errors from /var/log/pki/pki-ca-spawn.timestamp.log: (the > >> ... skipping... is from the file) > >> > >> ...skipping... > >> y still be down > >> 2013-12-16 18:12:23 pkispawn : DEBUG ........... No connection - > >> exception thrown: Cannot connect to proxy. Socket error: [Errno 111] > >> Connection refused. > >> 2013-12-16 18:12:24 pkispawn : DEBUG ........... No connection - > >> server may still be down > >> 2013-12-16 18:12:24 pkispawn : DEBUG ........... No connection - > >> exception thrown: Cannot connect to proxy. Socket error: [Errno 111] > >> Connection refused. > >> 2013-12-16 18:12:25 pkispawn : DEBUG ........... No connection - > >> server may still be down > >> ... > >> (error repeated 12 more times) > >> ... > >> 2013-12-16 18:12:39 pkispawn : ERROR ....... server failed to > >> restart > >> 2013-12-16 18:12:39 pkispawn : DEBUG ....... Error Type: SystemExit > >> 2013-12-16 18:12:39 pkispawn : DEBUG ....... Error Message: 1 > >> 2013-12-16 18:12:39 pkispawn : DEBUG ....... File > >> "/usr/sbin/pkispawn", line 374, in main > >> rv = instance.spawn() > >> File > >> "/usr/lib/python2.7/site-packages/pki/deployment/configuration.py", > >> line 102, in spawn > >> sys.exit(1) > >> > >> > > > > You are trying it in a container. I do not know whether this makes a > > difference. > > It might be due to the fact that underlying directory server has not > > started. > > Please look at the pki instance DS logs to determine whether the DS > > instance was installed and configured correctly. > > http://www.freeipa.org/page/Troubleshooting#Server_Installation > > Please publish these logs here. > > I'm not entirely sure that IPA works in a container. I think that > Nathaniel looked at this a few months ago but I can't recall his findings. For me, it mostly just worked with http://fedoraproject.org/wiki/Features/SystemdLightweightContainers. It requires disabling selinux, however, so I eventually abandoned it. Perhaps the selinux problem has been solved by now? Nathaniel From abokovoy at redhat.com Wed Dec 18 15:30:12 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 18 Dec 2013 17:30:12 +0200 Subject: [Freeipa-users] i could use some help with installing FreeIPA In-Reply-To: <1387378041.1948.98.camel@localhost.localdomain> References: <52AFAD05.6060003@redhat.com> <52AFC548.6070302@redhat.com> <1387378041.1948.98.camel@localhost.localdomain> Message-ID: <20131218153012.GJ21264@redhat.com> On Wed, 18 Dec 2013, Nathaniel McCallum wrote: >On Mon, 2013-12-16 at 22:30 -0500, Rob Crittenden wrote: >> Dmitri Pal wrote: >> > On 12/16/2013 06:46 PM, Galen Brownsmith wrote: >> >> My install fails on the invocation of pkispawn with a Socket Error in >> >> the pki-ca-spawn log ; anyone have any ideas? (It isn't the issue >> >> with special characters in the DM's password, as my Directory Manager >> >> and IPA Admin passwords may be 32 characters long, but only contain >> >> [A-Za-z0-9_] ) >> >> >> >> Configuration and Error Messages follow. >> >> >> >> Target System: Fedora19 64bit LXC Container running on top of a >> >> Fedora19 64bit host. Kernel 3.11.10, Q9550 Intel CPU. >> >> Attempting to install freeipa server 3.3.3 . SEllinux has been set to >> >> 'disabled' on the host and container. >> >> >> >> /etc/hosts: >> >> # IP FQDN Alias(es) >> >> 127.0.0.1 localhost.localdomain localhost localhost4 >> >> 192.168.253.94 woeg.marphod.net woeg >> >> >> >> # Peers >> >> 192.168.253.99 skete.marphod.net skete >> >> wiki.marphod.net wiki www.marphod.net >> >> www >> >> [... several more machines] >> >> >> >> /etc/resolv.conf >> >> ; generated by /usr/sbin/dhclient-script >> >> search marphod.net >> >> nameserver 192.168.253.1 >> >> >> >> /etc/sysconfig/network: >> >> NETWORKING=yes >> >> HOSTNAME=woeg.marphod.net >> >> >> >> No software firewall on the Container: >> >> # iptables -L >> >> Chain INPUT (policy ACCEPT) >> >> target prot opt source destination >> >> >> >> Chain FORWARD (policy ACCEPT) >> >> target prot opt source destination >> >> >> >> Chain OUTPUT (policy ACCEPT) >> >> target prot opt source destination >> >> >> >> >> >> Not using NetworkManager. The machine has a virtual nic, and is >> >> connected to the bridge on the host, and can interact with the outside >> >> world. >> >> >> >> Installation commands: >> >> # ipa-server-install --uninstall -U >> >> # pkidestroy -s CA -i pki-tomcat >> >> # ipa-server-install -N -d --no-host-dns >> >> >> >> I select the defaults during the interactive install. >> >> >> >> During installation, everything seems to run fine up to the invocation >> >> of pkispawn. I then get the errors: >> >> >> >> Installing CA into /var/lib/pki/pki-tomcat. >> >> Storing deployment configuration into >> >> /etc/sysconfig/pki/tomcat/pki-tomcat/ca/deployment.cfg. >> >> Installation failed. >> >> >> >> ipa : DEBUG stderr=Job for pki-tomcatd at pki-tomcat.service >> >> failed. See 'systemctl status pki-tomcatd at pki-tomcat.service' and >> >> 'journalctl -xn' for details. >> >> pkispawn : ERROR ....... server failed to restart >> >> >> >> ipa : CRITICAL failed to configure ca instance Command >> >> '/usr/sbin/pkispawn -s CA -f /tmp/tmpwNB5bU' returned non-zero exit >> >> status 1 >> >> ipa : DEBUG File >> >> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", >> >> line 622, in run_script >> >> return_value = main_function() >> >> >> >> File "/usr/sbin/ipa-server-install", line 1074, in main >> >> dm_password, subject_base=options.subject) >> >> >> >> File >> >> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", >> >> line 478, in configure_instance >> >> self.start_creation(runtime=210) >> >> >> >> File >> >> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line >> >> 364, in start_creation >> >> method() >> >> >> >> File >> >> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", >> >> line 604, in __spawn_instance >> >> raise RuntimeError('Configuration of CA failed') >> >> >> >> ipa : DEBUG The ipa-server-install command failed, >> >> exception: RuntimeError: Configuration of CA failed >> >> Configuration of CA failed >> >> >> >> >> >> the relevant errors from /var/log/pki/pki-ca-spawn.timestamp.log: (the >> >> ... skipping... is from the file) >> >> >> >> ...skipping... >> >> y still be down >> >> 2013-12-16 18:12:23 pkispawn : DEBUG ........... No connection - >> >> exception thrown: Cannot connect to proxy. Socket error: [Errno 111] >> >> Connection refused. >> >> 2013-12-16 18:12:24 pkispawn : DEBUG ........... No connection - >> >> server may still be down >> >> 2013-12-16 18:12:24 pkispawn : DEBUG ........... No connection - >> >> exception thrown: Cannot connect to proxy. Socket error: [Errno 111] >> >> Connection refused. >> >> 2013-12-16 18:12:25 pkispawn : DEBUG ........... No connection - >> >> server may still be down >> >> ... >> >> (error repeated 12 more times) >> >> ... >> >> 2013-12-16 18:12:39 pkispawn : ERROR ....... server failed to >> >> restart >> >> 2013-12-16 18:12:39 pkispawn : DEBUG ....... Error Type: SystemExit >> >> 2013-12-16 18:12:39 pkispawn : DEBUG ....... Error Message: 1 >> >> 2013-12-16 18:12:39 pkispawn : DEBUG ....... File >> >> "/usr/sbin/pkispawn", line 374, in main >> >> rv = instance.spawn() >> >> File >> >> "/usr/lib/python2.7/site-packages/pki/deployment/configuration.py", >> >> line 102, in spawn >> >> sys.exit(1) >> >> >> >> >> > >> > You are trying it in a container. I do not know whether this makes a >> > difference. >> > It might be due to the fact that underlying directory server has not >> > started. >> > Please look at the pki instance DS logs to determine whether the DS >> > instance was installed and configured correctly. >> > http://www.freeipa.org/page/Troubleshooting#Server_Installation >> > Please publish these logs here. >> >> I'm not entirely sure that IPA works in a container. I think that >> Nathaniel looked at this a few months ago but I can't recall his findings. > >For me, it mostly just worked with >http://fedoraproject.org/wiki/Features/SystemdLightweightContainers. It >requires disabling selinux, however, so I eventually abandoned it. >Perhaps the selinux problem has been solved by now? It is not, unfortunately. Audit code in the kernel is still unaware about lightweight containers. -- / Alexander Bokovoy From joe at flatiron.com Wed Dec 18 19:43:18 2013 From: joe at flatiron.com (Joe Mou) Date: Wed, 18 Dec 2013 14:43:18 -0500 Subject: [Freeipa-users] IPA replica directory server hung Message-ID: I have a broken IPA replica that appears to be suffering from a hung directory server. The master seems to be working fine, but LDAP requests to the replica hang indefinitely. I attached gdb to ns-slapd and suspect a deadlock in cos_cache.c. Thread 7 seems to be hung on an LDAP delete for a user account that we recently removed. Every time the directory server is started, it tries to issue this delete, apparently to sync the replica. I have been unsuccessful in trying to remove the offending replica because ipa-replica-manage seems to need to make LDAP requests against the replica. For example: $ ipa-replica-manage del p-ipa-wd02.prod.the.flatiron.com ^CConnection to 'p-ipa-wd02.prod.the.flatiron.com' failed: Insufficient access: SASL(0): successful result: Unable to delete replica 'p-ipa-wd02.prod.the.flatiron.com' ^CTraceback (most recent call last): File "/usr/sbin/ipa-replica-manage", line 1252, in main() KeyboardInterrupt Backtraces of the suspicious threads and log excerpts are at http://p.flatiron.com/~jmou/ipa/ . I was only able to install a limited set of debugging symbols; let me know if I can be of more help. Any help in fixing this replica or even just removing it would be greatly appreciated! Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- Thread 41 (Thread 0x7f0f6353b700 (LWP 1127)): #0 0x00007f0f72f11565 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 No symbol table info available. #1 0x00007f0f6dc9bf63 in __db_hybrid_mutex_suspend () from /lib64/libdb-5.3.so No symbol table info available. #2 0x00007f0f6dc9b440 in __db_tas_mutex_lock () from /lib64/libdb-5.3.so No symbol table info available. #3 0x00007f0f6dd4085a in __lock_get_internal () from /lib64/libdb-5.3.so No symbol table info available. #4 0x00007f0f6dd41460 in __lock_get () from /lib64/libdb-5.3.so No symbol table info available. #5 0x00007f0f6dd6bc2a in __db_lget () from /lib64/libdb-5.3.so No symbol table info available. #6 0x00007f0f6dcb84f4 in __bam_search () from /lib64/libdb-5.3.so No symbol table info available. #7 0x00007f0f6dca3996 in __bamc_search () from /lib64/libdb-5.3.so No symbol table info available. #8 0x00007f0f6dca53af in __bamc_get () from /lib64/libdb-5.3.so No symbol table info available. #9 0x00007f0f6dd58ff6 in __dbc_iget () from /lib64/libdb-5.3.so No symbol table info available. #10 0x00007f0f6dd67704 in __dbc_get_pp () from /lib64/libdb-5.3.so No symbol table info available. #11 0x00007f0f69c9c740 in idl_new_fetch (be=0x7f0f75e1e750, db=, inkey=0x7f0f6352dca0, txn=0x0, a=0x7f0f75ee68d0, flag_err=0x7f0f6353466c, allidslimit=100000) at ldap/servers/slapd/back-ldbm/idl_new.c:231 ret = 0 idl_rc = 0 cursor = 0x7f0f75fa5ce0 idl = 0x0 key = {data = 0x7f0f6352de00, size = 10, ulen = 10, dlen = 0, doff = 0, app_data = 0x0, flags = 2056} data = {data = 0x7f0f6352bbb0, size = 8192, ulen = 8192, dlen = 0, doff = 0, app_data = 0x0, flags = 2048} id = 0 count = 0 buffer = "memberOf-default", '\000' ... ptr = dataret = {data = 0x0, size = 0, ulen = 0, dlen = 0, doff = 0, app_data = 0x0, flags = 0} s_txn = {back_txn_txn = 0x0} li = #12 0x00007f0f69c9c3cd in idl_fetch_ext (be=be at entry=0x7f0f75e1e750, db=, key=key at entry=0x7f0f6352dca0, txn=txn at entry=0x0, a=, err=err at entry=0x7f0f6353466c, allidslimit=allidslimit at entry=100000) at ldap/servers/slapd/back-ldbm/idl_shim.c:130 No locals. #13 0x00007f0f69caa451 in index_read_ext_allids (pb=pb at entry=0x7f0f54079140, be=be at entry=0x7f0f75e1e750, type=type at entry=0x7f0f54075910 "objectclass", indextype=indextype at entry=0x7f0f69ceb937 "eq", val=, txn=txn at entry=0x7f0f63531f50, err=err at entry=0x7f0f6353466c, unindexed=unindexed at entry=0x7f0f63531f44, allidslimit=allidslimit at entry=100000) at ldap/servers/slapd/back-ldbm/index.c:1048 db = 0x7f0f75fa5720 db_txn = 0x0 key = {data = 0x7f0f6352de00, size = 10, ulen = 10, dlen = 0, doff = 0, app_data = 0x0, flags = 2048} idl = 0x0 prefix = tmpbuf = 0x0 buf = "=referral\000\377\377\000\000\000\000\344\337Rc\017\177\000\000\020\062\aT\017\177\000\000\000\000\000\000\000\000\000\000\331\022\367t\017\177", '\000' , "\002\000\000\000\300\347\341u\017\177\000\000\230\336Rc\017\177\000\000\020\062\aT\017\177\000\000\000\000\000\000\000\000\000\000\020\062\aT\017\177\000\000\200\216\303u\017\177", '\000' , "\006", '\000' , "\060\000\000\000\000\000\000\000\017\001\000\000\000\000\000\000\336\002\365t\017\177\000\000\320\336Rc\017\177\000\000\370\305\002T\017\177\000\000\001", '\000' ... typebuf = "objectclass\000\017\177\000\000\367D\261R\000\000\000\000\200\306\002T\017\177\000\000\070\027\321u\017\177\000\000\240\335Rc\017\177\000\000\000\000\000\000\000\000\000\000\260\026\321u\017\177\000\000\260\335Rc\017\177\000\000l\335Rc\017\177\000\000\060\231$v\017\177\000\000`;\313u\001", '\000' , "\377\377\377\377\377\377\377\377\001", '\000' , "\377\377\377\377", '\000' , "\364\206\377\377P\347\341u\017\177\000\000`;\313u\017\177\000\000\000\000\000\000\000\000\000\000 at 8\aT\017\177\000\000\000\000\000\000\000\000\000\000\020w\000T\017\177\000\000\370D\261R", '\000' ... ai = 0x7f0f75ee68d0 basetmp = 0x0 basetype = retry_count = 0 encrypted_val = 0x0 is_and = 0 ai_flags = 0 #14 0x00007f0f69c957ce in keys2idl (pb=pb at entry=0x7f0f54079140, be=be at entry=0x7f0f75e1e750, type=0x7f0f54075910 "objectclass", indextype=indextype at entry=0x7f0f69ceb937 "eq", ivals=, err=err at entry=0x7f0f6353466c, unindexed=unindexed at entry=0x7f0f63531f44, txn=txn at entry=0x7f0f63531f50, allidslimit=allidslimit at entry=100000) at ldap/servers/slapd/back-ldbm/filterindex.c:966 idl2 = idl = 0x0 i = 0 #15 0x00007f0f69c95ef3 in ava_candidates (pb=pb at entry=0x7f0f54079140, be=be at entry=0x7f0f75e1e750, f=f at entry=0x7f0f54076220, ftype=, err=0x7f0f6353466c, allidslimit=100000, range=0, nextf=0x0) at ldap/servers/slapd/back-ldbm/filterindex.c:317 tmp = {bv = {bv_len = 8, bv_val = 0x7f0f540758c0 "referral"}, v_csnset = 0x0, v_flags = 0} ptr = {0x7f0f63531fa0, 0x0} fake = {bv = {bv_len = 8, bv_val = 0x7f0f63532040 "referral"}, v_csnset = 0x0, v_flags = 1536} buf = "referral", '\000' ... type = 0x7f0f54075910 "objectclass" indextype = 0x7f0f69ceb937 "eq" sv = {bv = {bv_len = 8, bv_val = 0x7f0f63532040 "referral"}, v_csnset = 0x0, v_flags = 1536} bval = 0x7f0f54076248 ivals = 0x7f0f63531f70 idl = 0x0 unindexed = 0 sattr = {a_type = 0x7f0f54075c40 "objectClass", a_present_values = {num = 0, max = 0, sorted = 0x0, va = 0x0}, a_flags = 4, a_plugin = 0x7f0f75b47f20, a_deleted_values = {num = 0, max = 0, sorted = 0x0, va = 0x0}, a_listtofree = 0x0, a_next = 0x0, a_deletioncsn = 0x0, a_mr_eq_plugin = 0x7f0f75af89e0, a_mr_ord_plugin = 0x0, a_mr_sub_plugin = 0x0} txn = {back_txn_txn = 0x0} pr_idx = -1 #16 0x00007f0f69c9658d in filter_candidates_ext (pb=pb at entry=0x7f0f54079140, be=be at entry=0x7f0f75e1e750, base=base at entry=0x7f0f54074740 "dc=the,dc=flatiron,dc=com", f=f at entry=0x7f0f54076220, nextf=nextf at entry=0x0, range=range at entry=0, err=err at entry=0x7f0f6353466c, allidslimit=allidslimit at entry=100000) at ldap/servers/slapd/back-ldbm/filterindex.c:140 li = result = 0x0 ftype = #17 0x00007f0f69c9747b in list_candidates (pb=pb at entry=0x7f0f54079140, be=be at entry=0x7f0f75e1e750, base=base at entry=0x7f0f54074740 "dc=the,dc=flatiron,dc=com", flist=flist at entry=0x7f0f54019640, ftype=, err=0x7f0f6353466c, allidslimit=100000) at ldap/servers/slapd/back-ldbm/filterindex.c:806 idl = 0x7f0f540795a0 tmp = tmp2 = f = 0x7f0f54076220 nextf = 0x0 isnot = 0 f_count = le_count = ge_count = is_bounded_range = low_val = 0x0 high_val = 0x0 t1 = 0x7f0f74f3cace "H\211k\b\210\003H\203\304\bH\211\330[]\303f\220UH\211\365SH\211\373H\203\354\b\350/\315\376\377H\211\356H\211\337\350t\253\376\377H\203\304\bH\211\330[]\303f.\017\037\204" fpairs = {0x0, 0x0} tpairs = {0x0, 0x0} vpairs = {0x0, 0x0} is_and = 0 #18 0x00007f0f69c9645b in filter_candidates_ext (pb=pb at entry=0x7f0f54079140, be=be at entry=0x7f0f75e1e750, base=base at entry=0x7f0f54074740 "dc=the,dc=flatiron,dc=com", f=0x7f0f54019640, nextf=nextf at entry=0x0, range=range at entry=0, err=err at entry=0x7f0f6353466c, allidslimit=allidslimit at entry=100000) at ldap/servers/slapd/back-ldbm/filterindex.c:173 li = result = 0x0 ftype = #19 0x00007f0f69ccd52d in subtree_candidates (pb=pb at entry=0x7f0f54079140, be=0x7f0f75e1e750, base=base at entry=0x7f0f54074740 "dc=the,dc=flatiron,dc=com", e=e at entry=0x7f0f7611c130, filter=0x7f0f54001ec0, managedsait=0, allids_before_scopingp=allids_before_scopingp at entry=0x7f0f6353465c, err=err at entry=0x7f0f6353466c) at ldap/servers/slapd/back-ldbm/ldbm_search.c:1185 focref = 0x7f0f54076220 forr = 0x7f0f54019640 ftop = candidates = has_tombstone_filter = isroot = 0 li = allidslimit = 100000 #20 0x00007f0f69ccea7d in build_candidate_list (candidates=0x7f0f63534698, lookup_returned_allidsp=0x7f0f6353465c, scope=, base=0x7f0f54074740 "dc=the,dc=flatiron,dc=com", e=, be=, pb=0x7f0f54079140) at ldap/servers/slapd/back-ldbm/ldbm_search.c:992 filter = 0x7f0f54001ec0 err = 0 li = 0x7f0f75cb3b60 managedsait = 0 r = 0 #21 ldbm_back_search (pb=0x7f0f54079140) at ldap/servers/slapd/back-ldbm/ldbm_search.c:661 rc = time_up = 0 vlv_response_control = {targetPosition = 0, contentCount = 0, result = 0} vlv_rc = 32527 lookthrough_limit = 0 abandoned = 0 be = 0x7f0f75e1e750 inst = 0x7f0f75d116b0 li = 0x7f0f75cb3b60 e = 0x7f0f7611c130 candidates = 0x0 base = 0x7f0f54074740 "dc=the,dc=flatiron,dc=com" basesdn = 0x7f0f54074610 scope = 2 controls = 0x0 operation = 0x7f0f540793f0 addr = 0x7f0f540794c8 estimate = 0 sort = 0 vlv = sort_spec = 0x0 is_sorting_critical = is_sorting_critical_orig = 0 sort_control = 0x0 virtual_list_view = 0 vlv_spec = 0x0 is_vlv_critical = 0 vlv_request_control = {beforeCount = 0, afterCount = 0, tag = 0, index = 0, contentCount = 0, value = {bv_len = 0, bv_val = 0x0}} sr = tmp_err = -1 tmp_desc = 0x0 lookup_returned_allids = 0 backend_count = 0 print_once = 1 txn = {back_txn_txn = 0x0} rc = #22 0x00007f0f74f72a90 in op_shared_search (pb=pb at entry=0x7f0f54079140, send_result=send_result at entry=1) at ldap/servers/slapd/opshared.c:803 be_suffix = 0x7f0f75c307b0 err = 0 next_be = 0x0 base = 0x7f0f54076960 "dc=the,dc=flatiron,dc=com" normbase = fstr = 0x7f0f6bd7b898 "(&(|(objectclass=cosSuperDefinition)(objectclass=cosDefinition))(objectclass=ldapsubentry))" scope = 2 be = 0x7f0f75e1e750 be_single = 0x0 be_list = {0x7f0f75e1e750, 0x0 } referral_list = {0x0 , 0x63676e696d616e22, 0x2273747865746e6f, 0x0 } attrlistbuf = '\000' attrliststr = attrs = 0x0 rc = -1 internal_op = basesdn = 0x7f0f540761b0 sdn = 0x7f0f54074610 operation = 0x7f0f540793f0 referral = 0x0 proxydn = 0x0 proxystr = 0x0 proxy_err = errtext = 0x0 errorbuf = '\000' ... nentries = 0 pnentries = 0 flag_search_base_found = 0 flag_no_such_object = 0 flag_referral = 0 flag_psearch = err_code = 0 ctrlp = 0x0 ctl_value = 0x0 iscritical = 0 be_name = index = -1 sent_result = 0 pr_stat = 0 pagesize = -1 estimate = 0 curr_search_count = pr_be = pr_search_result = 0x0 pr_idx = -1 orig_sdn = 0x0 free_sdn = 1 #23 0x00007f0f74f7fcae in search_internal_callback_pb (pb=pb at entry=0x7f0f54079140, callback_data=callback_data at entry=0x7f0f6353ad80, prc=prc at entry=0x0, psec=psec at entry=0x7f0f6bd77df0 , prec=prec at entry=0x0) at ldap/servers/slapd/plugin_internal_op.c:812 controls = 0x0 op = 0x7f0f540793f0 filter = 0x7f0f54001ec0 fstr = 0x7f0f54075980 "(&(|(objectclass=cosSuperDefinition)(objectclass=cosDefinition))(objectclass=ldapsubentry))" callback_handler_data = {p_res_callback = 0x0, p_srch_entry_callback = 0x7f0f6bd77df0 , p_ref_entry_callback = 0x0, callback_data = 0x7f0f6353ad80} scope = 2 ifstr = 0x7f0f6bd7b898 "(&(|(objectclass=cosSuperDefinition)(objectclass=cosDefinition))(objectclass=ldapsubentry))" opresult = 0 rc = 0 tmp_attrs = 0x0 #24 0x00007f0f74f801a9 in slapi_search_internal_callback_pb (pb=pb at entry=0x7f0f54079140, callback_data=callback_data at entry=0x7f0f6353ad80, prc=prc at entry=0x0, psec=psec at entry=0x7f0f6bd77df0 , prec=prec at entry=0x0) at ldap/servers/slapd/plugin_internal_op.c:593 No locals. #25 0x00007f0f6bd79b7b in cos_cache_add_dn_defs (vattr_cacheable=0x7f0f540138c8, pDefs=0x7f0f540138a0, dn=0x7f0f54076960 "dc=the,dc=flatiron,dc=com") at ldap/servers/plugins/cos/cos_cache.c:1072 pDnSearch = 0x7f0f54079140 info = {pDefs = 0x7f0f540138a0, vattr_cacheable = 0, ret = -1} #26 cos_cache_build_definition_list (vattr_cacheable=0x7f0f540138c8, pDefs=0x7f0f540138a0) at ldap/servers/plugins/cos/cos_cache.c:674 suffixVals = 0x7f0f54075b80 attrType = 0x7f0f540777c0 "namingContexts" attrs = {0x7f0f6bd7c1cc "namingcontexts", 0x0} valIndex = ret = 0 suffixIndex = cos_def_available = 0 pSuffixSearch = 0x7f0f54074eb0 pSuffixList = 0x7f0f54076460 suffixAttr = 0x7f0f54077740 firstTime = 1 #27 cos_cache_create () at ldap/servers/plugins/cos/cos_cache.c:487 ret = -1 pNewCache = 0x7f0f540138a0 firstTime = 1 #28 0x00007f0f6bd7a3bf in cos_cache_wait_on_change (arg=) at ldap/servers/plugins/cos/cos_cache.c:451 No locals. #29 0x00007f0f7356bed1 in _pt_root () from /lib64/libnspr4.so No symbol table info available. #30 0x00007f0f72f0dc53 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #31 0x00007f0f72c3adbd in clone () from /lib64/libc.so.6 No symbol table info available. Thread 7 (Thread 0x7f0f3dfeb700 (LWP 1162)): #0 0x00007f0f72f13ddd in __lll_lock_wait () from /lib64/libpthread.so.0 No symbol table info available. #1 0x00007f0f72f0fbd7 in _L_lock_974 () from /lib64/libpthread.so.0 No symbol table info available. #2 0x00007f0f72f0fb80 in pthread_mutex_lock () from /lib64/libpthread.so.0 No symbol table info available. #3 0x00007f0f73566959 in PR_Lock () from /lib64/libnspr4.so No symbol table info available. #4 0x00007f0f74f9889a in slapi_lock_mutex (mutex=) at ldap/servers/slapd/slapi2nspr.c:101 No locals. #5 0x00007f0f6bd7aaec in cos_cache_change_notify (pb=pb at entry=0x7f0f4803f7f0) at ldap/servers/plugins/cos/cos_cache.c:3366 dn = 0x7f0f76081090 "cn=pm-abstractor,cn=groups,cn=accounts,dc=the,dc=flatiron,dc=com" sdn = 0x7f0f760811e0 do_update = 1 e = 0x7f0f4803a0a0 be = 0x7f0f75e1e750 rc = 0 optype = 8 #6 0x00007f0f6bd75c7d in cos_post_op (pb=0x7f0f4803f7f0) at ldap/servers/plugins/cos/cos.c:306 No locals. #7 0x00007f0f74f7bcd5 in plugin_call_func (list=0x7f0f75c72a90, operation=operation at entry=521, pb=pb at entry=0x7f0f4803f7f0, call_one=call_one at entry=0) at ldap/servers/slapd/plugin.c:1453 n = func = 0x7f0f6bd75c60 rc = return_value = 0 count = 0 #8 0x00007f0f74f7be3a in plugin_call_list (pb=0x7f0f4803f7f0, operation=521, list=) at ldap/servers/slapd/plugin.c:1415 No locals. #9 plugin_call_plugins (pb=pb at entry=0x7f0f4803f7f0, whichfunction=whichfunction at entry=521) at ldap/servers/slapd/plugin.c:398 p = 0x7f0f75cb4e50 plugin_list_number = 6 rc = 0 do_op = #10 0x00007f0f74f6c562 in op_shared_modify (pb=pb at entry=0x7f0f4803f7f0, pw_change=pw_change at entry=0, old_pw=0x0) at ldap/servers/slapd/modify.c:1109 rc = 0 be = 0x7f0f75e1e750 pse = 0x7f0f4803a0a0 referral = 0x0 e = 0x0 dn = 0x7f0f76081090 "cn=pm-abstractor,cn=groups,cn=accounts,dc=the,dc=flatiron,dc=com" normdn = sdn = 0x7f0f760811e0 passin_sdn = 1 mods = 0x7f0f48032710 pw_mod = tmpmods = 0x7f0f48032920 smods = {mods = 0x0, num_elements = 0, num_mods = 0, iterator = 0, free_mods = 0} repl_op = 0 internal_op = 32 lastmod = 1 skip_modified_attrs = 0 unhashed_pw_attr = 0x0 operation = 0x7f0f48039310 errorbuf = "\000\000\000\000\000\000\000\000\000\000\003H\017\177\000\000#\000\000\000\000\000\000\000\f\000\003H\017\177\000\000\000\000\000\000\000\000\000\000\200\335\002H\017\177\000\000\060\335\002H\017\177\000\000\274\377\375=\017\177\000\000\000\000\000\000\000\000\000\000\200\335\002H\017\177\000\000\360\313\002H\017\177\000\000\260\330\002H\017\177\000\000\000\000\000\000\000\000\000\000\260 \376=\017\177\000\000\220 \376=\017\177\000\000\004\363\362t\017\177", '\000' , "\377\377\377\377", '\000' ... err = lc_mod = p = i = proxydn = 0x0 proxy_err = errtext = 0x0 #11 0x00007f0f74f6cf94 in modify_internal_pb (pb=pb at entry=0x7f0f4803f7f0) at ldap/servers/slapd/modify.c:627 controls = 0x0 pwpolicy_ctrl = 0 op = 0x7f0f48039310 opresult = 0 normalized_mods = 0x7f0f48032920 mods = 0x7f0f3dfe2010 mod = 0x7f0f48032928 smods = {mods = 0x7f0f00000000, num_elements = 1962335489, num_mods = 32527, iterator = 1208219632, free_mods = 32527} pw_change = old_pw = 0x0 #12 0x00007f0f74f6daa3 in slapi_modify_internal_pb (pb=pb at entry=0x7f0f4803f7f0) at ldap/servers/slapd/modify.c:482 No locals. #13 0x00007f0f693baa14 in memberof_del_dn_type_callback (e=0x7f0f760811e0, callback_data=) at ldap/servers/plugins/memberof/memberof.c:500 rc = 0 mod = {mod_op = 1, mod_type = 0x7f0f4802c100 "member", mod_vals = {modv_strvals = 0x7f0f3dfe2020, modv_bvals = 0x7f0f3dfe2020}} mods = {0x7f0f3dfe2030, 0x0} val = {0x7f0f48001940 "uid=c-pammelton,cn=users,cn=accounts,dc=the,dc=flatiron,dc=com", 0x0} mod_pb = 0x7f0f4803f7f0 #14 0x00007f0f74f8e107 in send_ldap_search_entry_ext (pb=pb at entry=0x7f0f4802d140, e=0x7f0f760811e0, ectrls=ectrls at entry=0x0, attrs=0x0, attrsonly=0, send_result=send_result at entry=0, nentries=nentries at entry=0, urls=urls at entry=0x0) at ldap/servers/slapd/result.c:1266 conn = 0x0 op = 0x7f0f4802d410 ber = 0x0 i = rc = 0 logit = 0 alluserattrs = noattrs = some_named_attrs = dontsendattr = 0x0 operation = 0x7f0f4802d410 real_attrs_only = 0 ctrlp = 0x0 ecopy = 0x0 searchctrlp = 0x0 #15 0x00007f0f74f8ef6c in send_ldap_search_entry (pb=pb at entry=0x7f0f4802d140, e=, ectrls=ectrls at entry=0x0, attrs=, attrsonly=) at ldap/servers/slapd/result.c:825 No locals. #16 0x00007f0f74f71329 in iterate (pb=pb at entry=0x7f0f4802d140, pnentries=pnentries at entry=0x7f0f3dfe2438, pagesize=pagesize at entry=-1, pr_statp=pr_statp at entry=0x7f0f3dfe23b4, be=0x7f0f4802d140, send_result=1) at ldap/servers/slapd/opshared.c:1444 gerentry = 0x0 operation = 0x7f0f4802d410 rc = 0 rval = 1 attrsonly = 0 done = 0 e = 0x7f0f760811e0 attrs = 0x0 pr_stat = 0 pr_idx = -1 #17 0x00007f0f74f717bd in send_results_ext (pb=pb at entry=0x7f0f4802d140, nentries=nentries at entry=0x7f0f3dfe2438, pagesize=-1, pr_stat=pr_stat at entry=0x7f0f3dfe23b4, send_result=1) at ldap/servers/slapd/opshared.c:1682 be = 0x7f0f75e1e750 rc = #18 0x00007f0f74f72e91 in op_shared_search (pb=pb at entry=0x7f0f4802d140, send_result=send_result at entry=1) at ldap/servers/slapd/opshared.c:853 be_suffix = 0x7f0f75c307b0 err = 0 next_be = 0x0 base = 0x7f0f75d0e510 "dc=the,dc=flatiron,dc=com" normbase = fstr = 0x7f0f4802c440 "(member=uid=c-pammelton,cn=users,cn=accounts,dc=the,dc=flatiron,dc=com)" scope = 2 be = 0x7f0f75e1e750 be_single = 0x0 be_list = {0x7f0f75e1e750, 0x0 , 0x7f0f73554db0 , 0xffffffff00000000, 0x7f0f3dfe2e13, 0x0, 0x0, 0x0, 0x7f0f74fc4a11, 0x7f0f3dfe2e60, 0x0, 0xa, 0x7f0f74fc4a10, 0x7f0f3dfe3fb8, 0x7f0f7355519e , 0x0, 0x0, 0x0, 0x7f0f3dfe2c3f, 0x7f0f3dfe2c40, 0x0, 0x7f0f3dfe2d90, 0x7f0f3dfe2d91, 0x0, 0x0, 0x0, 0x2000000000000000, 0x7f0f3dfe4140, 0x0 , 0x31303100, 0x8aa9804e8d558400, 0x0, 0x7f0f3dfe2f60, 0x1d, 0x7f0f3dfe3760, 0x7f0f74fc49e0, 0x7f0f3dfe3fb8, 0x7f0f3dfe4140, 0x7f0f735561d2 , 0x7f0f73554ec0 , 0x7f0f3dfe3760, 0x7f0f3dfe3796, 0x800, 0x0, 0x7f0f73566bd0 , 0x7f0f75394b28, 0x7f0f74f63bb4 , 0xa, 0x7f0f74fbca36, 0x7f0f3dfe4298, 0x35, 0x7f0f751fa3e0 , 0x52b144f7, 0x0, 0x52b144f7, 0x7f0f3dfe2f20, 0x0, 0x7f0f3dfe3070, 0x7f0f3dfe3071, 0x0, 0x0, 0x0, 0x2000000000000000, 0x7f0f74fba69a, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x2f6365442f38315b, 0x3a36303a33313032, 0x302b2039313a3734, 0x205d303030, 0x0 , 0x30390000, 0x8aa9804e8d558400, 0x0, 0x7f0f3dfe3240, 0x1d, 0x7f0f3dfe3a40, 0x7f0f74fbca10, 0x7f0f3dfe4298, 0x7f0f3dfe4414, 0x7f0f735561d2 , 0x7f0f73554ec0 , 0x7f0f3dfe3a40, 0x7f0f3dfe3b8e, 0x800, 0x0, 0x7f0f73566bd0 , 0x7f0f753949be, 0x7f0f74f63bb4 , 0x0, 0x0, 0x0, 0x14d, 0x7f0f751fa3e0 , 0x52b144f7, 0x0, 0x52b144f7, 0x0 , 0x2f6365442f38315b, 0x3a36303a33313032, 0x302b2039313a3734, 0x205d303030, 0x0 , 0x1, 0x7f0f3dfe3549, 0x7f0f3dfe3540, 0x7f0f74fa33a9 , 0x7f0f3dfe3540, 0x7f0f74fa3f35 , 0x7f0f3dfe3498, 0x7f0f48008bf0, 0x0, 0x0, 0x0, 0x7f0f3dfe3520, 0x7f0f3dfe3610, 0x1, 0x0, 0x1, 0x1, 0x7f0f70fad9ff , 0x1, 0x7f0f00000000, 0x7f0f00000000, 0x7f0f00000001, 0x7f0f3dfe35d0, 0x7f0f74fa3f35 , 0x20, 0x0, 0xa, 0x7f0f3dfe3540, 0x9, 0x7f0f76238118, 0x6f7a736e64617069, 0x7f0f4800656e, 0x7f0f48008bf0, 0x7f0f70fad308 , 0x148003be0, 0x1, 0x7f0f3dfe3588, 0x7f0f3dfe3580, 0x7f0f00000001, 0x7f0f3dfe3618, 0x7f0f30017640, 0x0, 0x7f0f3dfe3610, 0x1, 0x7f0f30017648, 0x7f0f74f34f36 , 0xa3...} referral_list = {0x0, 0x7f0f74f34f36 , 0x0, 0x7f0f69c89f56 , 0x7f0f75cb4c90, 0x0, 0x7f0f4802b4f0, 0x7f0f69c9184c , 0x0, 0x1, 0x0, 0x7f0f751eeb7c , 0x7f0f3dfe4478, 0x7f0f75e1e750, 0xf7, 0x7f0f69c9c79b , 0x0, 0x7f0f3dfe88a8, 0x7f0f3dfe4460, 0x7f0fffff86f4, 0x7f0f3dfe44b0, 0x7f0f3dfe4480, 0x0, 0x7f0f75e1e750, 0x0, 0xffffffff, 0x7f0f762bf6b0, 0x7f0f4802b650, 0x7f0f3dfe6760, 0x2500000025, 0x0, 0x0, 0x800, 0x7f0f3dfe4580, 0x7f0f3dfe4510, 0x200000002000, 0x0, 0x0, 0x800, 0x7f0f69c89f56 , 0x0, 0x4, 0x0, 0x0, 0x0, 0x1, 0x22a010004, 0x656432663d010025, 0x6132362d32383036, 0x38382d3365313136, 0x622d386166626162, 0x38633065343136, 0x229010004, 0x656432663d010025, 0x6132362d31383036, 0x38382d3365313136, 0x622d386166626162, 0x38633065343136, 0x208010004, 0x656364663d010025, 0x3830352d32383831, 0x38382d3365313164, 0x622d386166626162, 0x38633065343136, 0x207010004, 0x656364663d010025, 0x3830352d31383831, 0x38382d3365313164, 0x622d386166626162, 0x38633065343136, 0x1e5010004, 0x323562653d010025, 0x6636342d32303766, 0x34622d3365313164, 0x632d333831613561, 0x65353863383066, 0x1e4010004, 0x323562653d010025, 0x6636342d31303766, 0x34622d3365313164, 0x632d333831613561, 0x65353863383066, 0x1d9010004, 0x656163653d010025, 0x3835342d32303365, 0x34622d3365313138, 0x632d333831613561, 0x65353863383066, 0x1d8010004, 0x656163653d010025, 0x3835342d31303365, 0x34622d3365313138, 0x632d333831613561, 0x65353863383066, 0x1be010004, 0x333562653d010025, 0x3135332d32303334, 0x38382d3365313133, 0x622d386166626162, 0x38633065343136, 0x1bd010004, 0x333562653d010025, 0x3135332d31303334, 0x38382d3365313133, 0x622d386166626162, 0x38633065343136, 0x1a2010004, 0x363139663d010025, 0x6366322d31306633, 0x34622d3365313165, 0x632d333831613561, 0x65353863383066, 0x185010004, 0x626463663d010025, 0x3036322d33303662, 0x38382d3365313162, 0x622d386166626162, 0x38633065343136, 0x184010004, 0x626463663d010025, 0x3036322d32303662, 0x38382d3365313162, 0x622d386166626162, 0x38633065343136, 0x183010004, 0x626463663d010025, 0x3036322d31303662, 0x38382d3365313162, 0x622d386166626162, 0x38633065343136, 0x163010004, 0x313966663d010025, 0x3863312d32306665, 0x38382d3365313163, 0x622d386166626162, 0x38633065343136, 0x162010004, 0x313966663d010025, 0x3863312d31306665, 0x38382d3365313163, 0x622d386166626162, 0x38633065343136, 0x15e010004, 0x343863663d010025, 0x6362312d32303966, 0x38382d3365313166, 0x622d386166626162, 0x38633065343136, 0x15d010004, 0x343863663d010025, 0x6362312d31303966, 0x38382d3365313166, 0x622d386166626162, 0x38633065343136, 0x13a010004, 0x316433663d010025, 0x6235312d31303936, 0x38382d3365313138, 0x622d386166626162, 0x38633065343136, 0xf7010004, 0x666666663d010025, 0x6666662d66666666, 0x66662d6666666666, 0x662d666666666666, 0x66666666666666, 0x8d010004, 0x323438653d010025, 0x3730312d35313865, 0x38382d3365313161, 0x622d386166626162, 0x38633065343136, 0x8c010004, 0x323438653d010025, 0x3730312d33313865, 0x38382d3365313161, 0x622d386166626162, 0x38633065343136, 0x8b010004, 0x323438653d010025, 0x3730312d31313865, 0x38382d3365313161, 0x622d386166626162, 0x38633065343136, 0x8a010004, 0x323438653d010025, 0x3730312d30313865, 0x38382d3365313161, 0x622d386166626162, 0x38633065343136, 0x89010004, 0x323438653d010025, 0x3730312d66303865, 0x38382d3365313161, 0x622d386166626162, 0x38633065343136, 0x88010004, 0x323438653d010025, 0x3730312d65303865, 0x38382d3365313161...} attrlistbuf = "\023\000\000\000\000\000\000\000@\033\000H\017\177\000\000\220=\356u\017\177\000\000\000\000\000\000\000\000\000\000@\232\002H\017\177\000\000\001\000\000\000\000\000\000\000 at m\356u\017\177\000\000@\033\000H\017\177\000\000 \232\002H\017\177\000\000P\347\341u\017\177\000\000\000\000\000\000\000\000\000\000O\325\311i\017\177\000\000\b\000\000\000\000\000\000\000 d\376=\017\177\000\000 at m\356u\017\177\000\000@\033\000H\017\177\000\000 \232\002H\017\177\000\000P\347\341u\017\177\000\000\000\000\000\000\000\000\000\000\066O\363t\017\177\000\000\001\000\000\000\000\000\000\000\a\277\312i\017\177", '\000' , "\003\000\000\000\000\000\000\000"... attrliststr = attrs = 0x0 rc = 0 internal_op = basesdn = 0x7f0f4802c520 sdn = 0x7f0f4802c880 operation = 0x7f0f4802d410 referral = 0x0 proxydn = 0x0 proxystr = 0x0 proxy_err = errtext = 0x0 errorbuf = "\000\300,v\017\177\000\000\060\036\000H\017\177\000\000\000\000\000\000\000\000\000\000\340b\356u\017\177", '\000' , "\200h\376=\017\177\000\000%\000\000\000%", '\000' , "\b", '\000' , "=ffffffff-ffffffff-ffffffff-ffffffff\000queid", '\000' ... nentries = 0 pnentries = 1 flag_search_base_found = 1 flag_no_such_object = 0 flag_referral = 0 flag_psearch = err_code = 0 ctrlp = 0x0 ctl_value = 0x0 iscritical = 0 be_name = index = -1 sent_result = 0 pr_stat = 0 pagesize = -1 estimate = 0 curr_search_count = pr_be = pr_search_result = 0x0 pr_idx = -1 orig_sdn = 0x0 free_sdn = 1 #19 0x00007f0f74f7fcae in search_internal_callback_pb (pb=pb at entry=0x7f0f4802d140, callback_data=callback_data at entry=0x7f0f3dfe88a0, prc=prc at entry=0x0, psec=psec at entry=0x7f0f693ba980 , prec=prec at entry=0x0) at ldap/servers/slapd/plugin_internal_op.c:812 controls = 0x0 op = 0x7f0f4802d410 filter = 0x7f0f4802d620 fstr = 0x7f0f4802c680 "(member=uid=c-pammelton,cn=users,cn=accounts,dc=the,dc=flatiron,dc=com)" callback_handler_data = {p_res_callback = 0x0, p_srch_entry_callback = 0x7f0f693ba980 , p_ref_entry_callback = 0x0, callback_data = 0x7f0f3dfe88a0} scope = 2 ifstr = 0x7f0f4802c440 "(member=uid=c-pammelton,cn=users,cn=accounts,dc=the,dc=flatiron,dc=com)" opresult = 0 rc = 0 tmp_attrs = 0x0 #20 0x00007f0f74f801a9 in slapi_search_internal_callback_pb (pb=pb at entry=0x7f0f4802d140, callback_data=callback_data at entry=0x7f0f3dfe88a0, prc=prc at entry=0x0, psec=psec at entry=0x7f0f693ba980 , prec=prec at entry=0x0) at ldap/servers/slapd/plugin_internal_op.c:593 No locals. #21 0x00007f0f693bb074 in memberof_call_foreach_dn (sdn=sdn at entry=0x7f0f4800a300, types=types at entry=0x7f0f3dfe8890, callback=callback at entry=0x7f0f693ba980 , callback_data=callback_data at entry=0x7f0f3dfe88a0, pb=0x7f0f7633c290) at ldap/servers/plugins/memberof/memberof.c:605 search_pb = 0x7f0f4802d140 base_sdn = be = escaped_filter_val = 0x0 filter_str = 0x7f0f4802c440 "(member=uid=c-pammelton,cn=users,cn=accounts,dc=the,dc=flatiron,dc=com)" cookie = 0x7f0f4802d3f0 "" all_backends = 0 types_name_len = num_types = dn_len = free_it = 1 i = #22 0x00007f0f693bd8aa in memberof_del_dn_from_groups (pb=0x7f0f7633c290, config=0x7f0f3dfe88b0, sdn=0x7f0f4800a300) at ldap/servers/plugins/memberof/memberof.c:470 data = {dn = 0x7f0f48001940 "uid=c-pammelton,cn=users,cn=accounts,dc=the,dc=flatiron,dc=com", type = 0x7f0f4802c100 "member"} i = groupattrs = {0x7f0f4802c100 "member", 0x0} #23 memberof_postop_del (pb=0x7f0f7633c290) at ldap/servers/plugins/memberof/memberof.c:419 e = 0x7f0f4800e0f0 configCopy = {groupattrs = 0x7f0f4802c120, memberof_attr = 0x7f0f4802d120 "memberOf", allBackends = 0, group_filter = 0x7f0f4802cd00, group_slapiattrs = 0x7f0f4802bab0} sdn = 0x7f0f4800a300 caller_id = 0x0 #24 0x00007f0f74f7bcd5 in plugin_call_func (list=0x7f0f75cc47d0, operation=operation at entry=563, pb=pb at entry=0x7f0f7633c290, call_one=call_one at entry=0) at ldap/servers/slapd/plugin.c:1453 n = func = 0x7f0f693bd6f0 rc = return_value = 0 count = 6 #25 0x00007f0f74f7be3a in plugin_call_list (pb=0x7f0f7633c290, operation=563, list=) at ldap/servers/slapd/plugin.c:1415 No locals. #26 plugin_call_plugins (pb=pb at entry=0x7f0f7633c290, whichfunction=whichfunction at entry=563) at ldap/servers/slapd/plugin.c:398 p = 0x7f0f75cb4e50 plugin_list_number = 20 rc = 0 do_op = #27 0x00007f0f69cbb8b7 in ldbm_back_delete (pb=0x7f0f7633c290) at ldap/servers/slapd/back-ldbm/ldbm_delete.c:1087 be = 0x7f0f75e1e750 inst = 0x7f0f75d116b0 li = 0x7f0f75cb3b60 e = 0x7f0f760988f0 tombstone = 0x7f0f48012e60 original_tombstone = 0x7f0f48016af0 dn = 0x7f0f48001940 "uid=c-pammelton,cn=users,cn=accounts,dc=the,dc=flatiron,dc=com" txn = {back_txn_txn = 0x7f0f48001b40} parent_txn = 0x0 retval = 0 msg = errbuf = 0x0 retry_count = disk_full = 0 parent_found = ruv_c_init = 1 parent_modify_c = {new_entry_in_cache = 0, old_entry = 0x7f0f760deb20, new_entry = 0x7f0f48011b20, smods = 0x7f0f48011860, attr_encrypt = 1} ruv_c = {new_entry_in_cache = 0, old_entry = 0x7f0f4c0525c0, new_entry = 0x7f0f4802b610, smods = 0x7f0f48012c60, attr_encrypt = 1} rc = 0 ldap_result_code = 0 ldap_result_message = 0x0 sdnp = 0x7f0f4800a300 e_uniqueid = 0x7f0f48012b70 "8c43b101-470211e3-88babfa8-b614e0c8" nscpEntrySDN = {flag = 4 '\004', udn = 0x0, dn = 0x0, ndn = 0x7f0f48012e10 "uid=c-pammelton,cn=users,cn=accounts,dc=the,dc=flatiron,dc=com", ndn_len = 62} operation = 0x7f0f7633d7c0 opcsn = 0x7f0f48004ed0 is_fixup_operation = 0 is_ruv = 0 is_replicated_operation = 8 is_tombstone_entry = delete_tombstone_entry = 0 create_tombstone_entry = 1 tombstone_in_cache = 1 e_in_cache = addr = 0x7f0f7633d898 addordel_flags = 38 entryusn_str = 0x0 orig_entry = 0x0 parentsdn = {flag = 0 '\000', udn = 0x0, dn = 0x0, ndn = 0x0, ndn_len = 0} opreturn = 0 free_delete_existing_entry = 1 not_an_error = 0 #28 0x00007f0f74f384b0 in op_shared_delete (pb=pb at entry=0x7f0f7633c290) at ldap/servers/slapd/delete.c:364 rc = 0 rawdn = 0x7f0f48008410 "uid=c-pammelton,cn=users,cn=accounts,dc=the,dc=flatiron,dc=com" dn = be = 0x7f0f75e1e750 internal_op = 0 sdn = 0x7f0f4800a300 operation = 0x7f0f7633d7c0 referral = 0x0 ecopy = 0x0 errorbuf = '\000' ... err = proxydn = 0x0 proxystr = 0x0 proxy_err = errtext = 0x0 #29 0x00007f0f74f38743 in do_delete (pb=0x7f0f7633c290) at ldap/servers/slapd/delete.c:128 operation = 0x7f0f7633d7c0 ber = 0x7f0f7627b460 rawdn = 0x7f0f48008410 "uid=c-pammelton,cn=users,cn=accounts,dc=the,dc=flatiron,dc=com" err = #30 0x00007f0f7543ad98 in connection_dispatch_operation (pb=, op=0x7f0f7633d7c0, conn=0x7f0f600ae428) at ldap/servers/slapd/connection.c:587 minssf = 0 minssf_exclude_rootdse = enable_nagle = 1 pop_cork = 0 #31 connection_threadmain () at ldap/servers/slapd/connection.c:2348 is_timedout = 0 curtime = pb = 0x7f0f7633c290 interval = 10000 conn = 0x7f0f600ae428 op = 0x7f0f7633d7c0 tag = 74 need_wakeup = 0 need_conn_release = thread_turbo_flag = 0 ret = more_data = 0 replication_connection = doshutdown = 0 #32 0x00007f0f7356bed1 in _pt_root () from /lib64/libnspr4.so No symbol table info available. #33 0x00007f0f72f0dc53 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #34 0x00007f0f72c3adbd in clone () from /lib64/libc.so.6 No symbol table info available. From rmeggins at redhat.com Wed Dec 18 19:54:34 2013 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 18 Dec 2013 12:54:34 -0700 Subject: [Freeipa-users] IPA replica directory server hung In-Reply-To: References: Message-ID: <52B1FD7A.7070105@redhat.com> On 12/18/2013 12:43 PM, Joe Mou wrote: > I have a broken IPA replica that appears to be suffering from a hung > directory server. The master seems to be working fine, but LDAP > requests to the replica hang indefinitely. I attached gdb to ns-slapd > and suspect a deadlock in cos_cache.c. > > Thread 7 seems to be hung on an LDAP delete for a user account that we > recently removed. Every time the directory server is started, it tries > to issue this delete, apparently to sync the replica. > > I have been unsuccessful in trying to remove the offending replica > because ipa-replica-manage seems to need to make LDAP requests against > the replica. For example: > > $ ipa-replica-manage del p-ipa-wd02.prod.the.flatiron.com > > ^CConnection to 'p-ipa-wd02.prod.the.flatiron.com > ' failed: Insufficient > access: SASL(0): successful result: > Unable to delete replica 'p-ipa-wd02.prod.the.flatiron.com > ' > > ^CTraceback (most recent call last): > File "/usr/sbin/ipa-replica-manage", line 1252, in > main() > KeyboardInterrupt > > Backtraces of the suspicious threads and log excerpts are at > http://p.flatiron.com/~jmou/ipa/ > . I was only able to install a > limited set of debugging symbols; let me know if I can be of more help. > > Any help in fixing this replica or even just removing it would be > greatly appreciated! What is your platform? rpm -q 389-ds-base There were some hangs with rhel 6.4.z. Please update to the latest 389-ds-base (1.2.11.15-30 or later) and nss 3.15.3 or later. > > Joe > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Thu Dec 19 01:08:05 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 18 Dec 2013 20:08:05 -0500 Subject: [Freeipa-users] Question: re replica install In-Reply-To: <4ED173A868981548967B4FCA2707222602BAFE@AACMBXP04.exchserver.com> References: <4ED173A868981548967B4FCA2707222602BAFE@AACMBXP04.exchserver.com> Message-ID: <52B246F5.10104@redhat.com> 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 From nagerjj at gmail.com Thu Dec 19 01:40:04 2013 From: nagerjj at gmail.com (Joshua Nager) Date: Wed, 18 Dec 2013 20:40:04 -0500 Subject: [Freeipa-users] freeipa client wont install on host where a ipa server guest is already installed. In-Reply-To: <52B24597.1080902@redhat.com> References: <002401cefb8f$c6bcf350$5436d9f0$@gmail.com> <20131218012745.GR3298@redhat.com> <52B24597.1080902@redhat.com> Message-ID: <000301cefc5b$43e86410$cbb92c30$@gmail.com> Does this mean I should be able to login with the credentials supplied by the ipa-server? If so, I can not. The host box does not recognize any user accounts in the ipa domain at all. Any help is much appreciated as I would love to get this working. -----Original Message----- From: Rob Crittenden [mailto:rcritten at redhat.com] Sent: Wednesday, December 18, 2013 8:02 PM To: Jan Pazdziora; Joshua Nager Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] freeipa client wont install on host where a ipa server guest is already installed. Jan Pazdziora wrote: > On Tue, Dec 17, 2013 at 08:23:36PM -0500, Joshua Nager wrote: >> >> I am running freeipa as a guest KVM virtual machine. I have found >> myself running into a problem when trying to install ipa-client on >> the host which the guest resides. >> >> Upon trying to install the ipa-client I am given the msg that I must >> first uninstall the ipa server. > > What is the OS version and the exact message that you get? > >> Has anyone experienced this and how might I get around this problem? > > Are you sure you don't have the IPA server installed on both the KVM > guest *and* on the host? > Right, an IPA server is already configured as a client of itself. rob From rcritten at redhat.com Thu Dec 19 01:02:15 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 18 Dec 2013 20:02:15 -0500 Subject: [Freeipa-users] freeipa client wont install on host where a ipa server guest is already installed. In-Reply-To: <20131218012745.GR3298@redhat.com> References: <002401cefb8f$c6bcf350$5436d9f0$@gmail.com> <20131218012745.GR3298@redhat.com> Message-ID: <52B24597.1080902@redhat.com> Jan Pazdziora wrote: > On Tue, Dec 17, 2013 at 08:23:36PM -0500, Joshua Nager wrote: >> >> I am running freeipa as a guest KVM virtual machine. I have found myself >> running into a problem when trying to install ipa-client on the host which >> the guest resides. >> >> Upon trying to install the ipa-client I am given the msg that I must first >> uninstall the ipa server. > > What is the OS version and the exact message that you get? > >> Has anyone experienced this and how might I get around this problem? > > Are you sure you don't have the IPA server installed on both the KVM > guest *and* on the host? > Right, an IPA server is already configured as a client of itself. rob From Less at imagine-sw.com Thu Dec 19 03:04:20 2013 From: Less at imagine-sw.com (Les Stott) Date: Thu, 19 Dec 2013 03:04:20 +0000 Subject: [Freeipa-users] Question: re replica install In-Reply-To: <52B246F5.10104@redhat.com> References: <4ED173A868981548967B4FCA2707222602BAFE@AACMBXP04.exchserver.com> <52B246F5.10104@redhat.com> Message-ID: <4ED173A868981548967B4FCA2707222602C9B3@AACMBXP04.exchserver.com> Thanks Rob. -----Original Message----- From: Rob Crittenden [mailto:rcritten at redhat.com] Sent: Thursday, 19 December 2013 12:08 PM To: Les Stott; freeipa-users at 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 From joe at flatiron.com Thu Dec 19 09:19:16 2013 From: joe at flatiron.com (Joe Mou) Date: Thu, 19 Dec 2013 04:19:16 -0500 Subject: [Freeipa-users] IPA replica directory server hung In-Reply-To: <52B1FD7A.7070105@redhat.com> References: <52B1FD7A.7070105@redhat.com> Message-ID: Thanks for the speedy reply. I am running on Fedora 19. $ rpm -q 389-ds-base 389-ds-base-1.3.1.16-1.fc19.x86_64 $ rpm -q nss nss-3.15.3-1.fc19.x86_64 On Wed, Dec 18, 2013 at 2:54 PM, Rich Megginson wrote: > On 12/18/2013 12:43 PM, Joe Mou wrote: > > I have a broken IPA replica that appears to be suffering from a hung > directory server. The master seems to be working fine, but LDAP requests to > the replica hang indefinitely. I attached gdb to ns-slapd and suspect a > deadlock in cos_cache.c. > > Thread 7 seems to be hung on an LDAP delete for a user account that we > recently removed. Every time the directory server is started, it tries to > issue this delete, apparently to sync the replica. > > I have been unsuccessful in trying to remove the offending replica > because ipa-replica-manage seems to need to make LDAP requests against the > replica. For example: > > $ ipa-replica-manage del p-ipa-wd02.prod.the.flatiron.com > > ^CConnection to 'p-ipa-wd02.prod.the.flatiron.com' failed: Insufficient > access: SASL(0): successful result: > Unable to delete replica 'p-ipa-wd02.prod.the.flatiron.com' > > ^CTraceback (most recent call last): > File "/usr/sbin/ipa-replica-manage", line 1252, in > main() > KeyboardInterrupt > > Backtraces of the suspicious threads and log excerpts are at > http://p.flatiron.com/~jmou/ipa/ . I was only able to install a limited > set of debugging symbols; let me know if I can be of more help. > > Any help in fixing this replica or even just removing it would be > greatly appreciated! > > > What is your platform? rpm -q 389-ds-base > > There were some hangs with rhel 6.4.z. Please update to the latest > 389-ds-base (1.2.11.15-30 or later) and nss 3.15.3 or later. > > > Joe > > > _______________________________________________ > Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lslebodn at redhat.com Thu Dec 19 12:27:50 2013 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Thu, 19 Dec 2013 13:27:50 +0100 Subject: [Freeipa-users] freeipa client wont install on host where a ipa server guest is already installed. In-Reply-To: <000301cefc5b$43e86410$cbb92c30$@gmail.com> References: <002401cefb8f$c6bcf350$5436d9f0$@gmail.com> <20131218012745.GR3298@redhat.com> <52B24597.1080902@redhat.com> <000301cefc5b$43e86410$cbb92c30$@gmail.com> Message-ID: <20131219122749.GD3418@mail.corp.redhat.com> On (18/12/13 20:40), Joshua Nager wrote: >Does this mean I should be able to login with the credentials supplied by >the ipa-server? If so, I can not. >The host box does not recognize any user accounts in the ipa domain at all. > >Any help is much appreciated as I would love to get this working. > Is sssd running on this machine? If answer is YES, then you should enable verbose logging in the sssd. (put debug_level = 7 into sssd section and domain section) SSSD log files should contain usefull information for debugging after restarting sssd daemon. LS From rmeggins at redhat.com Thu Dec 19 15:07:18 2013 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 19 Dec 2013 08:07:18 -0700 Subject: [Freeipa-users] IPA replica directory server hung In-Reply-To: References: <52B1FD7A.7070105@redhat.com> Message-ID: <52B30BA6.9020307@redhat.com> On 12/19/2013 02:19 AM, Joe Mou wrote: > Thanks for the speedy reply. I am running on Fedora 19. > > $ rpm -q 389-ds-base > 389-ds-base-1.3.1.16-1.fc19.x86_64 > $ rpm -q nss > nss-3.15.3-1.fc19.x86_64 Not sure what's going on, but let's see if we can get it "unstuck". It seems there is a conflict between the Class of Service plugin and the Member Of plugin. I think we may be able to disable the CoS plugin to allow the deletion to proceed. Do the following search to see what CoS definitions there are: ldapsearch -xLLL -D "cn=directory manager" -W -b dc=the,dc=flatiron,dc=com '(objectclass=ldapsubentry)' > > > On Wed, Dec 18, 2013 at 2:54 PM, Rich Megginson > wrote: > > On 12/18/2013 12:43 PM, Joe Mou wrote: >> I have a broken IPA replica that appears to be suffering from a >> hung directory server. The master seems to be working fine, but >> LDAP requests to the replica hang indefinitely. I attached gdb to >> ns-slapd and suspect a deadlock in cos_cache.c. >> >> Thread 7 seems to be hung on an LDAP delete for a user account >> that we recently removed. Every time the directory server is >> started, it tries to issue this delete, apparently to sync the >> replica. >> >> I have been unsuccessful in trying to remove the offending >> replica because ipa-replica-manage seems to need to make LDAP >> requests against the replica. For example: >> >> $ ipa-replica-manage del p-ipa-wd02.prod.the.flatiron.com >> >> ^CConnection to 'p-ipa-wd02.prod.the.flatiron.com >> ' failed: Insufficient >> access: SASL(0): successful result: >> Unable to delete replica 'p-ipa-wd02.prod.the.flatiron.com >> ' >> >> ^CTraceback (most recent call last): >> File "/usr/sbin/ipa-replica-manage", line 1252, in >> main() >> KeyboardInterrupt >> >> Backtraces of the suspicious threads and log excerpts are at >> http://p.flatiron.com/~jmou/ipa/ >> . I was only able to install >> a limited set of debugging symbols; let me know if I can be of >> more help. >> >> Any help in fixing this replica or even just removing it would be >> greatly appreciated! > > What is your platform? rpm -q 389-ds-base > > There were some hangs with rhel 6.4.z. Please update to the > latest 389-ds-base (1.2.11.15-30 or later) and nss 3.15.3 or later. > >> >> Joe >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe at flatiron.com Thu Dec 19 16:19:12 2013 From: joe at flatiron.com (Joe Mou) Date: Thu, 19 Dec 2013 08:19:12 -0800 Subject: [Freeipa-users] IPA replica directory server hung In-Reply-To: <52B30BA6.9020307@redhat.com> References: <52B1FD7A.7070105@redhat.com> <52B30BA6.9020307@redhat.com> Message-ID: Here are the results of that command: $ ldapsearch -xLLL -D "cn=directory manager" -W -b dc=the,dc=flatiron,dc=com '(objectclass=ldapsubentry)' Enter LDAP Password: dn: cn=Password Policy,cn=accounts,dc=the,dc=flatiron,dc=com cn: Password Policy cosspecifier: memberOf cosAttribute: krbPwdPolicyReference override costemplatedn: cn=cosTemplates,cn=accounts,dc=the,dc=flatiron,dc=com objectClass: top objectClass: ldapsubentry objectClass: cosSuperDefinition objectClass: cosClassicDefinition description: Password Policy based on group membership On Thu, Dec 19, 2013 at 7:07 AM, Rich Megginson wrote: > On 12/19/2013 02:19 AM, Joe Mou wrote: > > Thanks for the speedy reply. I am running on Fedora 19. > > $ rpm -q 389-ds-base > 389-ds-base-1.3.1.16-1.fc19.x86_64 > $ rpm -q nss > nss-3.15.3-1.fc19.x86_64 > > > Not sure what's going on, but let's see if we can get it "unstuck". It > seems there is a conflict between the Class of Service plugin and the > Member Of plugin. I think we may be able to disable the CoS plugin to > allow the deletion to proceed. > > Do the following search to see what CoS definitions there are: > ldapsearch -xLLL -D "cn=directory manager" -W -b dc=the,dc=flatiron,dc=com > '(objectclass=ldapsubentry)' > > > > > On Wed, Dec 18, 2013 at 2:54 PM, Rich Megginson wrote: > >> On 12/18/2013 12:43 PM, Joe Mou wrote: >> >> I have a broken IPA replica that appears to be suffering from a hung >> directory server. The master seems to be working fine, but LDAP requests to >> the replica hang indefinitely. I attached gdb to ns-slapd and suspect a >> deadlock in cos_cache.c. >> >> Thread 7 seems to be hung on an LDAP delete for a user account that we >> recently removed. Every time the directory server is started, it tries to >> issue this delete, apparently to sync the replica. >> >> I have been unsuccessful in trying to remove the offending replica >> because ipa-replica-manage seems to need to make LDAP requests against the >> replica. For example: >> >> $ ipa-replica-manage del p-ipa-wd02.prod.the.flatiron.com >> >> ^CConnection to 'p-ipa-wd02.prod.the.flatiron.com' failed: Insufficient >> access: SASL(0): successful result: >> Unable to delete replica 'p-ipa-wd02.prod.the.flatiron.com' >> >> ^CTraceback (most recent call last): >> File "/usr/sbin/ipa-replica-manage", line 1252, in >> main() >> KeyboardInterrupt >> >> Backtraces of the suspicious threads and log excerpts are at >> http://p.flatiron.com/~jmou/ipa/ . I was only able to install a limited >> set of debugging symbols; let me know if I can be of more help. >> >> Any help in fixing this replica or even just removing it would be >> greatly appreciated! >> >> >> What is your platform? rpm -q 389-ds-base >> >> There were some hangs with rhel 6.4.z. Please update to the latest >> 389-ds-base (1.2.11.15-30 or later) and nss 3.15.3 or later. >> >> >> Joe >> >> >> _______________________________________________ >> Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abontempi at dbmsrl.com Thu Dec 19 16:57:06 2013 From: abontempi at dbmsrl.com (Andrea Bontempi) Date: Thu, 19 Dec 2013 17:57:06 +0100 (CET) Subject: [Freeipa-users] Full certificate renewal In-Reply-To: <443921656.171488.1387471407536.JavaMail.root@dbmsrl.com> Message-ID: <675002636.171522.1387472226133.JavaMail.root@dbmsrl.com> What I want to do is a bit borderline :-) The scenario is: FreeIPA 3.0.0 (external-ca) with all certificates expired (also Root CA) Certmonger can't proceed to automatically renew the certificates. We can't release a certificate valid in the past (so we can't set the date in the past) What i did: I proceed to replace all certificate in the various nss db, included the re-sign of the certificate, where is needed. It partial works, the FreeIPA instance return up, but non completely. That is the issue: [root at ipa config]# ipa cert-show Serial number: 1 ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (Not Found) [root at ipa config]#getcert list [...] Request ID '20131115101732': status: CA_UNREACHABLE ca-error: Server failed request, will retry: 4301 (RPC failed at server. Certificate operation cannot be completed: Unable to communicate with CMS (Not Found)). stuck: yes 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=DBMSRL.COM subject: CN=ipa.intra.dbmsrl.com,O=INTRA.DBMSRL.COM expires: 2014-03-19 11:01:14 UTC pre-save command: post-save command: /usr/lib64/ipa/certmonger/restart_dirsrv PKI-IPA track: yes auto-renew: yes Request ID '20131115101901': status: NEED_CSR ca-error: Error setting up ccache for local "host" service using default keytab: Cannot contact any KDC for realm 'INTRA.DBMSRL.COM'. stuck: no key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=INTRA.DBMSRL.COM subject: CN=ipa.intra.dbmsrl.com,O=INTRA.DBMSRL.COM expires: 2013-12-14 15:27:08 UTC eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: /usr/lib64/ipa/certmonger/restart_httpd track: yes auto-renew: yes And in the pki-ca log i found this exception: Failed to create jss service: java.lang.SecurityException: Unable to initialize security library at com.netscape.cmscore.security.JssSubsystem.init(JssSubsystem.java:272) at com.netscape.cmscore.apps.CMSEngine.initSubsystem(CMSEngine.java:866) at com.netscape.cmscore.apps.CMSEngine.initSubsystems(CMSEngine.java:795) at com.netscape.cmscore.apps.CMSEngine.init(CMSEngine.java:306) at com.netscape.certsrv.apps.CMS.init(CMS.java:153) at com.netscape.certsrv.apps.CMS.start(CMS.java:1530) at com.netscape.cms.servlet.base.CMSStartServlet.init(CMSStartServlet.java:85) at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1173) at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:993) at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4187) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4496) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:526) at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1041) at org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:964) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:502) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1277) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:321) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053) at org.apache.catalina.core.StandardHost.start(StandardHost.java:722) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443) at org.apache.catalina.core.StandardService.start(StandardService.java:516) at org.apache.catalina.core.StandardServer.start(StandardServer.java:710) at org.apache.catalina.startup.Catalina.start(Catalina.java:593) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:622) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:289) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:414) I have no idea what is missing, can someone help me? Thank you Andrea Bontempi From rmeggins at redhat.com Thu Dec 19 18:01:38 2013 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 19 Dec 2013 11:01:38 -0700 Subject: [Freeipa-users] IPA replica directory server hung In-Reply-To: References: <52B1FD7A.7070105@redhat.com> <52B30BA6.9020307@redhat.com> Message-ID: <52B33482.7040104@redhat.com> On 12/19/2013 09:19 AM, Joe Mou wrote: > Here are the results of that command: > > $ ldapsearch -xLLL -D "cn=directory manager" -W -b > dc=the,dc=flatiron,dc=com '(objectclass=ldapsubentry)' > Enter LDAP Password: > dn: cn=Password Policy,cn=accounts,dc=the,dc=flatiron,dc=com > cn: Password Policy > cosspecifier: memberOf > cosAttribute: krbPwdPolicyReference override > costemplatedn: cn=cosTemplates,cn=accounts,dc=the,dc=flatiron,dc=com > objectClass: top > objectClass: ldapsubentry > objectClass: cosSuperDefinition > objectClass: cosClassicDefinition > description: Password Policy based on group membership Ok. Looks like IPA uses CoS for password policy based on group membership using the memberof attribute in each user's entry. I think we can temporarily disable this. First, save the above entry to a file e.g. pwpolicycos.ldif Next, ipactl restart Just after the directory server is restarted, delete this entry: ldapdelete -x -D "cn=directory manager" -W "cn=Password Policy,cn=accounts,dc=the,dc=flatiron,dc=com" Once everything is working again, add back the entry: ldapmodify -x -D "cn=directory manager" -W -a -f pwpolicycos.ldif > > > On Thu, Dec 19, 2013 at 7:07 AM, Rich Megginson > wrote: > > On 12/19/2013 02:19 AM, Joe Mou wrote: >> Thanks for the speedy reply. I am running on Fedora 19. >> >> $ rpm -q 389-ds-base >> 389-ds-base-1.3.1.16-1.fc19.x86_64 >> $ rpm -q nss >> nss-3.15.3-1.fc19.x86_64 > > Not sure what's going on, but let's see if we can get it > "unstuck". It seems there is a conflict between the Class of > Service plugin and the Member Of plugin. I think we may be able > to disable the CoS plugin to allow the deletion to proceed. > > Do the following search to see what CoS definitions there are: > ldapsearch -xLLL -D "cn=directory manager" -W -b > dc=the,dc=flatiron,dc=com '(objectclass=ldapsubentry)' > > >> >> >> On Wed, Dec 18, 2013 at 2:54 PM, Rich Megginson >> > wrote: >> >> On 12/18/2013 12:43 PM, Joe Mou wrote: >>> I have a broken IPA replica that appears to be suffering >>> from a hung directory server. The master seems to be working >>> fine, but LDAP requests to the replica hang indefinitely. I >>> attached gdb to ns-slapd and suspect a deadlock in cos_cache.c. >>> >>> Thread 7 seems to be hung on an LDAP delete for a user >>> account that we recently removed. Every time the directory >>> server is started, it tries to issue this delete, apparently >>> to sync the replica. >>> >>> I have been unsuccessful in trying to remove the offending >>> replica because ipa-replica-manage seems to need to make >>> LDAP requests against the replica. For example: >>> >>> $ ipa-replica-manage del p-ipa-wd02.prod.the.flatiron.com >>> >>> ^CConnection to 'p-ipa-wd02.prod.the.flatiron.com >>> ' failed: >>> Insufficient access: SASL(0): successful result: >>> Unable to delete replica 'p-ipa-wd02.prod.the.flatiron.com >>> ' >>> >>> ^CTraceback (most recent call last): >>> File "/usr/sbin/ipa-replica-manage", line 1252, in >>> main() >>> KeyboardInterrupt >>> >>> Backtraces of the suspicious threads and log excerpts are at >>> http://p.flatiron.com/~jmou/ipa/ >>> . I was only able to >>> install a limited set of debugging symbols; let me know if I >>> can be of more help. >>> >>> Any help in fixing this replica or even just removing it >>> would be greatly appreciated! >> >> What is your platform? rpm -q 389-ds-base >> >> There were some hangs with rhel 6.4.z. Please update to the >> latest 389-ds-base (1.2.11.15-30 or later) and nss 3.15.3 or >> later. >> >>> >>> Joe >>> >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe at flatiron.com Thu Dec 19 22:17:30 2013 From: joe at flatiron.com (Joe Mou) Date: Thu, 19 Dec 2013 14:17:30 -0800 Subject: [Freeipa-users] IPA replica directory server hung In-Reply-To: <52B33482.7040104@redhat.com> References: <52B1FD7A.7070105@redhat.com> <52B30BA6.9020307@redhat.com> <52B33482.7040104@redhat.com> Message-ID: On Thu, Dec 19, 2013 at 10:01 AM, Rich Megginson wrote: > On 12/19/2013 09:19 AM, Joe Mou wrote: > > Here are the results of that command: > > $ ldapsearch -xLLL -D "cn=directory manager" -W -b > dc=the,dc=flatiron,dc=com '(objectclass=ldapsubentry)' > Enter LDAP Password: > dn: cn=Password Policy,cn=accounts,dc=the,dc=flatiron,dc=com > cn: Password Policy > cosspecifier: memberOf > cosAttribute: krbPwdPolicyReference override > costemplatedn: cn=cosTemplates,cn=accounts,dc=the,dc=flatiron,dc=com > objectClass: top > objectClass: ldapsubentry > objectClass: cosSuperDefinition > objectClass: cosClassicDefinition > description: Password Policy based on group membership > > > Ok. Looks like IPA uses CoS for password policy based on group membership > using the memberof attribute in each user's entry. > > I think we can temporarily disable this. > > First, save the above entry to a file e.g. pwpolicycos.ldif > > Next, ipactl restart > Just after the directory server is restarted, delete this entry: > ldapdelete -x -D "cn=directory manager" -W "cn=Password > Policy,cn=accounts,dc=the,dc=flatiron,dc=com" > > Once everything is working again, add back the entry: > > ldapmodify -x -D "cn=directory manager" -W -a -f pwpolicycos.ldif > Thanks Rich, that partially worked. The replica gets unstuck and is able to service requests. But it looks like mutations are still not working completely correctly. For example if I do a `ipa user-add joe-test --first=joe --last=test` then that command hangs. At this point the directory server gets wedged, apparently similarly to before. However this time restarting the directory server unsticks it. Only certain operations seem to break, as updating a user's job title works fine. Backtraces are available: http://p.flatiron.com/~jmou/ipa/stacktrace.1387489013.txt Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Thu Dec 19 22:43:52 2013 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 19 Dec 2013 15:43:52 -0700 Subject: [Freeipa-users] IPA replica directory server hung In-Reply-To: References: <52B1FD7A.7070105@redhat.com> <52B30BA6.9020307@redhat.com> <52B33482.7040104@redhat.com> Message-ID: <52B376A8.1030804@redhat.com> On 12/19/2013 03:17 PM, Joe Mou wrote: > On Thu, Dec 19, 2013 at 10:01 AM, Rich Megginson > wrote: > > On 12/19/2013 09:19 AM, Joe Mou wrote: >> Here are the results of that command: >> >> $ ldapsearch -xLLL -D "cn=directory manager" -W -b >> dc=the,dc=flatiron,dc=com '(objectclass=ldapsubentry)' >> Enter LDAP Password: >> dn: cn=Password Policy,cn=accounts,dc=the,dc=flatiron,dc=com >> cn: Password Policy >> cosspecifier: memberOf >> cosAttribute: krbPwdPolicyReference override >> costemplatedn: cn=cosTemplates,cn=accounts,dc=the,dc=flatiron,dc=com >> objectClass: top >> objectClass: ldapsubentry >> objectClass: cosSuperDefinition >> objectClass: cosClassicDefinition >> description: Password Policy based on group membership > > Ok. Looks like IPA uses CoS for password policy based on group > membership using the memberof attribute in each user's entry. > > I think we can temporarily disable this. > > First, save the above entry to a file e.g. pwpolicycos.ldif > > Next, ipactl restart > Just after the directory server is restarted, delete this entry: > ldapdelete -x -D "cn=directory manager" -W "cn=Password > Policy,cn=accounts,dc=the,dc=flatiron,dc=com" > > Once everything is working again, add back the entry: > > ldapmodify -x -D "cn=directory manager" -W -a -f pwpolicycos.ldif > > > Thanks Rich, that partially worked. The replica gets unstuck and is > able to service requests. But it looks like mutations are still not > working completely correctly. For example if I do a `ipa user-add > joe-test --first=joe --last=test` then that command hangs. At this > point the directory server gets wedged, apparently similarly to > before. However this time restarting the directory server unsticks it. > Only certain operations seem to break, as updating a user's job title > works fine. Backtraces are available: > http://p.flatiron.com/~jmou/ipa/stacktrace.1387489013.txt > > Please open a ticket at https://fedorahosted.org/389/newticket - you can attach stack traces to the ticket > Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe at flatiron.com Fri Dec 20 01:14:29 2013 From: joe at flatiron.com (Joe Mou) Date: Thu, 19 Dec 2013 17:14:29 -0800 Subject: [Freeipa-users] IPA replica directory server hung In-Reply-To: <52B376A8.1030804@redhat.com> References: <52B1FD7A.7070105@redhat.com> <52B30BA6.9020307@redhat.com> <52B33482.7040104@redhat.com> <52B376A8.1030804@redhat.com> Message-ID: Thanks for your help Rich. The ticket is https://fedorahosted.org/389/ticket/47649 On Thu, Dec 19, 2013 at 2:43 PM, Rich Megginson wrote: > On 12/19/2013 03:17 PM, Joe Mou wrote: > > On Thu, Dec 19, 2013 at 10:01 AM, Rich Megginson wrote: > >> On 12/19/2013 09:19 AM, Joe Mou wrote: >> >> Here are the results of that command: >> >> $ ldapsearch -xLLL -D "cn=directory manager" -W -b >> dc=the,dc=flatiron,dc=com '(objectclass=ldapsubentry)' >> Enter LDAP Password: >> dn: cn=Password Policy,cn=accounts,dc=the,dc=flatiron,dc=com >> cn: Password Policy >> cosspecifier: memberOf >> cosAttribute: krbPwdPolicyReference override >> costemplatedn: cn=cosTemplates,cn=accounts,dc=the,dc=flatiron,dc=com >> objectClass: top >> objectClass: ldapsubentry >> objectClass: cosSuperDefinition >> objectClass: cosClassicDefinition >> description: Password Policy based on group membership >> >> >> Ok. Looks like IPA uses CoS for password policy based on group >> membership using the memberof attribute in each user's entry. >> >> I think we can temporarily disable this. >> >> First, save the above entry to a file e.g. pwpolicycos.ldif >> >> Next, ipactl restart >> Just after the directory server is restarted, delete this entry: >> ldapdelete -x -D "cn=directory manager" -W "cn=Password >> Policy,cn=accounts,dc=the,dc=flatiron,dc=com" >> >> Once everything is working again, add back the entry: >> >> ldapmodify -x -D "cn=directory manager" -W -a -f pwpolicycos.ldif >> > > Thanks Rich, that partially worked. The replica gets unstuck and is able > to service requests. But it looks like mutations are still not working > completely correctly. For example if I do a `ipa user-add joe-test > --first=joe --last=test` then that command hangs. At this point the > directory server gets wedged, apparently similarly to before. However this > time restarting the directory server unsticks it. Only certain operations > seem to break, as updating a user's job title works fine. Backtraces are > available: http://p.flatiron.com/~jmou/ipa/stacktrace.1387489013.txt > > > Please open a ticket at https://fedorahosted.org/389/newticket - you can > attach stack traces to the ticket > > Joe > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret.wortman at damascusgrp.com Fri Dec 20 14:06:51 2013 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Fri, 20 Dec 2013 09:06:51 -0500 Subject: [Freeipa-users] Can't delete user Message-ID: <52B44EFB.6060507@damascusgrp.com> Has anyone seen a problem where a user account can't be deleted either through the CLI or the web interface? In both methods, the attempt just hangs and I'm not sure what of the messages I'm seeing in /var/log/messages are relevant. I do know that the Kerberos server seems to be involved, because during and after the hang, I can't kinit.... -- *Bret Wortman* http://damascusgrp.com/ http://about.me/wortmanbret -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3766 bytes Desc: S/MIME Cryptographic Signature URL: From dpal at redhat.com Fri Dec 20 14:12:09 2013 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 20 Dec 2013 09:12:09 -0500 Subject: [Freeipa-users] Can't delete user In-Reply-To: <52B44EFB.6060507@damascusgrp.com> References: <52B44EFB.6060507@damascusgrp.com> Message-ID: <52B45039.7020706@redhat.com> On 12/20/2013 09:06 AM, Bret Wortman wrote: > Has anyone seen a problem where a user account can't be deleted either > through the CLI or the web interface? In both methods, the attempt > just hangs and I'm not sure what of the messages I'm seeing in > /var/log/messages are relevant. > > I do know that the Kerberos server seems to be involved, because > during and after the hang, I can't kinit.... Please take a look here http://www.freeipa.org/page/Troubleshooting We need more information and logs. > > > -- > *Bret Wortman* > > http://damascusgrp.com/ > http://about.me/wortmanbret > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret.wortman at damascusgrp.com Fri Dec 20 15:22:52 2013 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Fri, 20 Dec 2013 10:22:52 -0500 Subject: [Freeipa-users] Can't delete user In-Reply-To: <52B45039.7020706@redhat.com> References: <52B44EFB.6060507@damascusgrp.com> <52B45039.7020706@redhat.com> Message-ID: <52B460CC.8020605@damascusgrp.com> The problem is knowing where to look, and what I'm seeing doesn't point well to any particular puzzle piece. I'll debug after the holidays. This isn't worth the headache today, for me or anyone else. :-) On 12/20/2013 09:12 AM, Dmitri Pal wrote: > On 12/20/2013 09:06 AM, Bret Wortman wrote: >> Has anyone seen a problem where a user account can't be deleted >> either through the CLI or the web interface? In both methods, the >> attempt just hangs and I'm not sure what of the messages I'm seeing >> in /var/log/messages are relevant. >> >> I do know that the Kerberos server seems to be involved, because >> during and after the hang, I can't kinit.... > > > Please take a look here http://www.freeipa.org/page/Troubleshooting > We need more information and logs. > > >> >> >> -- >> *Bret Wortman* >> >> http://damascusgrp.com/ >> http://about.me/wortmanbret >> >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3766 bytes Desc: S/MIME Cryptographic Signature URL: From abontempi at dbmsrl.com Fri Dec 20 15:33:47 2013 From: abontempi at dbmsrl.com (Andrea Bontempi) Date: Fri, 20 Dec 2013 16:33:47 +0100 (CET) Subject: [Freeipa-users] Full certificate renewal In-Reply-To: <675002636.171522.1387472226133.JavaMail.root@dbmsrl.com> References: <675002636.171522.1387472226133.JavaMail.root@dbmsrl.com> Message-ID: <292941256.173992.1387553627896.JavaMail.root@dbmsrl.com> SOLVED I forgot to update the certificates in /etc/pki-ca/CS.cfg Andrea Bontempi From mitkany at gmail.com Fri Dec 20 23:42:37 2013 From: mitkany at gmail.com (Dimitar Georgievski) Date: Fri, 20 Dec 2013 18:42:37 -0500 Subject: [Freeipa-users] Sudo issues with FreeIPA In-Reply-To: References: <52B0E2AE.4080307@redhat.com> Message-ID: Hi Dmitri, One follow up question about the management of the SSSD local cache. I've tried to clean cache entries with the sss_cache utility, but it looks like this utility is not working. I was able to confirm with ldbsearch that records for specific entries were not removed from the cache. This seems to be a bug. I can use ldpdel with a restart of the SSSD daemon, but just wanted to confirm with you. I suspect you would know more about this problem. Unfortunately I wasn't able to find any info yet about this potential bug. thanks Dimitar On Tue, Dec 17, 2013 at 10:40 PM, Dimitar Georgievski wrote: > Thanks Dmitri. Those settings for ldap in sssd.conf fixed the issue. > > Dimitar > > > On Tue, Dec 17, 2013 at 6:47 PM, Dmitri Pal wrote: > >> On 12/17/2013 06:34 PM, Dimitar Georgievski wrote: >> >> Hi, >> >> I am running FreeIPA 3.3.3 on CentOS 6.5. Everything works fine except >> that I have problem enforcing sudo policies on the hosts that are part of >> the managed domain. >> >> When trying to run the following simple command as a user managed by >> FreeIPA I got the following response: >> >> >> *> sudo /usr/bin/vim test.txt * >> *jsmith is not allowed to run sudo on myhost. This incident will be >> reported.* >> >> I might have missed in the configuration of the serve or SSSD on the >> client host. >> >> Is there any guideline for sudo integration with FreeIPA? >> >> The following is the SSSD configuration on the client host: >> >> [domain/example.net] >> >> cache_credentials = True >> krb5_store_password_if_offline = True >> ipa_domain = example.net >> id_provider = ipa >> auth_provider = ipa >> access_provider = ipa >> sudo_provider = ldap >> ldap_tls_cacert = /etc/ipa/ca.crt >> ipa_hostname = ipaserver.example.net >> chpass_provider = ipa >> ipa_server = _srv_ >> ipa_backup_server = replica.example.net >> >> >> dns_discovery_domain = example.net >> >> >> >> [sssd] >> services = nss, pam, ssh, sudo >> config_file_version = 2 >> >> domains = example.net >> [nss] >> >> [pam] >> >> [sudo] >> debug_level = 0x3ff0 >> >> [autofs] >> >> [ssh] >> >> [pac] >> >> Thanks, >> >> Dimitar >> >> >> _______________________________________________ >> Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users >> >> >> http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager for IdM portfolio >> Red Hat Inc. >> >> >> ------------------------------- >> Looking to carve out IT costs?www.redhat.com/carveoutcosts/ >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lslebodn at redhat.com Sat Dec 21 20:28:13 2013 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Sat, 21 Dec 2013 21:28:13 +0100 Subject: [Freeipa-users] Sudo issues with FreeIPA In-Reply-To: References: <52B0E2AE.4080307@redhat.com> Message-ID: <20131221202812.GA8291@mail.corp.redhat.com> On (20/12/13 18:42), Dimitar Georgievski wrote: >Hi Dmitri, > >One follow up question about the management of the SSSD local cache. I've >tried to clean cache entries with the sss_cache utility, but it looks like >this utility is not working. I was able to confirm with ldbsearch that >records for specific entries were not removed from the cache. > >This seems to be a bug. I can use ldpdel with a restart of the SSSD daemon, >but just wanted to confirm with you. I suspect you would know more about >this problem. Unfortunately I wasn't able to find any info yet about this >potential bug. > >thanks > >Dimitar > sss_cache does not remove users from cache (sss_cache -U) This utility sets expiration of account to the past (unix time with value 1), because user needs to be able authenticate offline. Entry will be removed from cache if user try to authenticate online and entry is removed from LDAP. LS From abokovoy at redhat.com Sun Dec 22 10:42:27 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Sun, 22 Dec 2013 05:42:27 -0500 (EST) Subject: [Freeipa-users] WARNING: Do not upgrade FreeIPA deployments to Fedora 20 final (yet) In-Reply-To: <20131217091434.GW21264@redhat.com> References: <20131217091434.GW21264@redhat.com> Message-ID: <81614488.131679.1387708947601.JavaMail.root@redhat.com> Hi, an update on the issue of upgrading Fedora 19 to Fedora 20 for FreeIPA deployments. An updated 389-ds-base package, 1.3.2.9-1.fc20 is in updates-testing repository. Updated slapi-nis package, 0.52-1.fc20, is in updates-testing as well. I've tested that using fedora-upgrade tool to upgrade from Fedora 19 to Fedora 20 does work if you have updates-testing repository enabled and that FreeIPA is continuing to work afterwards. I've initiated move of 389-ds-base to updates stable repository. Once it reach out there, I'll lift a warning on freeipa.org and publish a final update. Happy holidays! ----- Original Message ----- > From: "Alexander Bokovoy" > To: freeipa-users at redhat.com > Sent: Tuesday, December 17, 2013 11:14:34 AM > Subject: [Freeipa-users] WARNING: Do not upgrade FreeIPA deployments to Fedora 20 final (yet) > > Greetings! > > As many of you are aware, Fedora Project releases Fedora 20 today, > Tuesday, December 17th. This post serves as a warning against upgrading > your FreeIPA deployments to Fedora 20 using release images. Please check > Fedora 20 Common Bugs page https://fedoraproject.org/wiki/Common_F20_bugs > for the complete list of issues. > > FreeIPA relies heavily on 389-ds Directory Server. Fedora 20 introduces > new version series of 389-ds, 1.3.2.x. Along with multiple enhancements, > unfortunately, few bugs went into the version currently available in > Fedora 20 stable tree. These bugs are causing crashes under certain > conditions and we don't recommend updating your existing configurations > due to these consequences. > > As an update to the Fedora 20 Common Bugs page, over last night fellow > developers from 389-ds and slapi-nis projects have fixed > https://bugzilla.redhat.com/show_bug.cgi?id=1043546 and > https://bugzilla.redhat.com/show_bug.cgi?id=1041732 but there will be > some delay before the builds featuring the fixes will appear in Fedora > 20 updates repository. Remaining bugs are under investigation. > > I'll post an update note once we'll get remaining issues fixed and packages > pushed to Fedora 20 updates repository. > > -- > / Alexander Bokovoy > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -- / Alexander Bokovoy From dmaksic988 at gmail.com Sun Dec 22 15:49:36 2013 From: dmaksic988 at gmail.com (Danijel Maksic) Date: Sun, 22 Dec 2013 16:49:36 +0100 Subject: [Freeipa-users] Integrate bio-metric authentication with FreeIPA Message-ID: Hello, I'm interested in using FreeIPA but I can not find a way to integrate bio-metric authentication. Is there a way to do this? Could you direct me to some text or tutorial? Thanks and Best Regards, Danijel Maksic -------------- next part -------------- An HTML attachment was scrubbed... URL: From mitkany at gmail.com Mon Dec 23 15:16:49 2013 From: mitkany at gmail.com (Dimitar Georgievski) Date: Mon, 23 Dec 2013 10:16:49 -0500 Subject: [Freeipa-users] Sudo issues with FreeIPA In-Reply-To: <20131221202812.GA8291@mail.corp.redhat.com> References: <52B0E2AE.4080307@redhat.com> <20131221202812.GA8291@mail.corp.redhat.com> Message-ID: Hi Lukas, Does the LDAP entry need to be removed or just modified? Could the LDAP entry be a sudo policy assigned to the user? In my tests with modified sudo policies the cache entries would persists even after they were invalidated and the user re-authenticated with the LDAP server. Unless I wanted to wait for a smart refresh of the cache I had to delete the entry from the cache with ldbdel and then restart the SSSD daemon. I wonder if there is a better way to refresh the cache on demand. Thanks, Dimitar On Sat, Dec 21, 2013 at 3:28 PM, Lukas Slebodnik wrote: > On (20/12/13 18:42), Dimitar Georgievski wrote: > >Hi Dmitri, > > > >One follow up question about the management of the SSSD local cache. I've > >tried to clean cache entries with the sss_cache utility, but it looks like > >this utility is not working. I was able to confirm with ldbsearch that > >records for specific entries were not removed from the cache. > > > >This seems to be a bug. I can use ldpdel with a restart of the SSSD > daemon, > >but just wanted to confirm with you. I suspect you would know more about > >this problem. Unfortunately I wasn't able to find any info yet about this > >potential bug. > > > >thanks > > > >Dimitar > > > sss_cache does not remove users from cache (sss_cache -U) > This utility sets expiration of account to the past (unix time with value > 1), > because user needs to be able authenticate offline. > Entry will be removed from cache if user try to > authenticate online and entry is removed from LDAP. > > LS > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ovalousek at vendavo.com Mon Dec 23 15:52:54 2013 From: ovalousek at vendavo.com (Ondrej Valousek) Date: Mon, 23 Dec 2013 15:52:54 +0000 Subject: [Freeipa-users] Sudo issues with FreeIPA In-Reply-To: References: <52B0E2AE.4080307@redhat.com> <20131221202812.GA8291@mail.corp.redhat.com>, Message-ID: <1B2E2C093FF3B7459F3C605C42E4B5040DFABED6@exmb1> There is the sss_cache command which should be able to handle this. But it lookus like it can handle everything BUT sudo rules :( Ondrej ________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Dimitar Georgievski [mitkany at gmail.com] Sent: Monday, December 23, 2013 4:16 PM To: Lukas Slebodnik Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Sudo issues with FreeIPA Hi Lukas, Does the LDAP entry need to be removed or just modified? Could the LDAP entry be a sudo policy assigned to the user? In my tests with modified sudo policies the cache entries would persists even after they were invalidated and the user re-authenticated with the LDAP server. Unless I wanted to wait for a smart refresh of the cache I had to delete the entry from the cache with ldbdel and then restart the SSSD daemon. I wonder if there is a better way to refresh the cache on demand. Thanks, Dimitar On Sat, Dec 21, 2013 at 3:28 PM, Lukas Slebodnik > wrote: On (20/12/13 18:42), Dimitar Georgievski wrote: >Hi Dmitri, > >One follow up question about the management of the SSSD local cache. I've >tried to clean cache entries with the sss_cache utility, but it looks like >this utility is not working. I was able to confirm with ldbsearch that >records for specific entries were not removed from the cache. > >This seems to be a bug. I can use ldpdel with a restart of the SSSD daemon, >but just wanted to confirm with you. I suspect you would know more about >this problem. Unfortunately I wasn't able to find any info yet about this >potential bug. > >thanks > >Dimitar > sss_cache does not remove users from cache (sss_cache -U) This utility sets expiration of account to the past (unix time with value 1), because user needs to be able authenticate offline. Entry will be removed from cache if user try to authenticate online and entry is removed from LDAP. LS -------------- next part -------------- An HTML attachment was scrubbed... URL: From jasondbecker at gmail.com Mon Dec 23 19:57:55 2013 From: jasondbecker at gmail.com (Jason Becker) Date: Mon, 23 Dec 2013 12:57:55 -0700 Subject: [Freeipa-users] FreeIPA Server Install - Why --no-ntp? Message-ID: Section 2.1.4.5. NTP in the Fedora 18 / 3.1.5 Guide states: "If a server is being installed on a virtual machine, that server *should not* run an NTP server. To disable NTP for FreeIPA, use the *--no-ntp*option." There is no further explanation. I would like to install FreeIPA Server on a vSphere VM where NTP is recommended as part of their timekeeping best practices for Linux guests. Please advise. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From lslebodn at redhat.com Mon Dec 23 20:34:01 2013 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Mon, 23 Dec 2013 21:34:01 +0100 Subject: [Freeipa-users] Sudo issues with FreeIPA In-Reply-To: References: <52B0E2AE.4080307@redhat.com> <20131221202812.GA8291@mail.corp.redhat.com> Message-ID: <20131223203401.GA5380@mail.corp.redhat.com> On (23/12/13 10:16), Dimitar Georgievski wrote: >Hi Lukas, > >Does the LDAP entry need to be removed or just modified? Could the LDAP >entry be a sudo policy assigned to the user? > sudo rules are special case, I didn't noticed anything about sudo rules in the previous mail. There is periodical task in the sssd for refreshing sudo rules because of current ldap schema. >In my tests with modified sudo policies the cache entries would persists >even after they were invalidated and the user re-authenticated with the >LDAP server. Unless I wanted to wait for a smart refresh of the cache I >had to delete the entry from the cache with ldbdel and then restart the >SSSD daemon. > >I wonder if there is a better way to refresh the cache on demand. sss_cache does not work with sudo rules. If you are testing something, you can manually remove sssd cache (rm /var/lib/sss/db/cache_*.ldb). If you don't like behaviour in production, you can decrease interval of refresh update. man sssd-sudo -> THE SUDO RULE CACHING MECHANISM and for sudo configuration options: man sssd-ldap -> SUDO OPTIONS LS From simo at redhat.com Mon Dec 23 20:57:05 2013 From: simo at redhat.com (Simo Sorce) Date: Mon, 23 Dec 2013 15:57:05 -0500 Subject: [Freeipa-users] FreeIPA Server Install - Why --no-ntp? In-Reply-To: References: Message-ID: <1387832225.19564.403.camel@willson.li.ssimo.org> On Mon, 2013-12-23 at 12:57 -0700, Jason Becker wrote: > Section 2.1.4.5. NTP in the Fedora 18 / 3.1.5 Guide states: > > "If a server is being installed on a virtual machine, that server *should > not* run an NTP server. To disable NTP for FreeIPA, use the *--no-ntp*option." > > There is no further explanation. > > I would like to install FreeIPA Server on a vSphere VM where NTP is > recommended as part of their timekeeping best practices for Linux guests. Often happens that VMs do not do very good time keeping, so using a VM as the central NTP server is not really advised, you should instead get a good source for NTP external to the virtualized environment and you that one as the time source for your network. Of course if your virtualization environment guarantees a good clock, go for it. The recommendation is in the spirit of avoiding issues in the common case, that up to the time of the writing was not very good :) Simo. -- Simo Sorce * Red Hat, Inc * New York From arthur at deus.pro Thu Dec 26 05:59:28 2013 From: arthur at deus.pro (Arthur Faizullin) Date: Thu, 26 Dec 2013 11:59:28 +0600 Subject: [Freeipa-users] sssd off after authconfig update Message-ID: <52BBC5C0.2060007@deus.pro> Hi! As I mentioned earlier in my previous topic, when I do: # authconfig ??--enablemkhomedir ??update that somehow makes sssd off (disables autostart), so I should do: # chkconfig sssd on os: EL6 (CentOS) ipa version: 3.0 (from repository) That is not a big problem, but anyway that is not right. If it is normal way, then it is not mentioned in documentation. Is it something to open bug-report? (and what is it about: documentation or software?) _____________________________ Best regards, Arthur Fayzullin From chorn at fluxcoil.net Thu Dec 26 06:19:24 2013 From: chorn at fluxcoil.net (Christian Horn) Date: Thu, 26 Dec 2013 07:19:24 +0100 Subject: [Freeipa-users] sssd off after authconfig update In-Reply-To: <52BBC5C0.2060007@deus.pro> References: <52BBC5C0.2060007@deus.pro> Message-ID: <20131226061924.GA9242@fluxcoil.net> Hi, On Thu, Dec 26, 2013 at 11:59:28AM +0600, Arthur Faizullin wrote: > > As I mentioned earlier in my previous topic, when I do: > # authconfig ??--enablemkhomedir ??update > that somehow makes sssd off (disables autostart), so I should do: > # chkconfig sssd on > os: EL6 (CentOS) > ipa version: 3.0 (from repository) > That is not a big problem, but anyway that is not right. > If it is normal way, then it is not mentioned in documentation. Well, when calling authconfig you do not provide any new data (IPA servers or such) which could be used by sssd. Is the following leaving sssd enabled? # authconfig --enablemkhomedir --enablesssd --update Christian From mail at willsheldon.com Fri Dec 27 17:50:16 2013 From: mail at willsheldon.com (Will Sheldon) Date: Fri, 27 Dec 2013 09:50:16 -0800 Subject: [Freeipa-users] ipa-client-install 2.58 client incompatible with 2.49 server Message-ID: Hello :) I'm trying to setup a ubuntu 12.04.3 client running freeipa-client 3.2.0-0ubuntu1~precise1 form the apt repo at http://ppa.launchpad.net/freeipa/ppa/ubuntu The server is a (fully updated) centos 6.5 box running ipa-server.x86_64 3.0.0-37.el6 The script mostly works on a stock install, but there is an error uploading SSH keys, This appears to be called from the ipa-client-install script line 1436: result = api.Command['host_mod'](unicode(hostname), Which generates the following output when run: stderr= Caught fault 901 from server https://ipa.[domain].com/ipa/xml: 2.58 client incompatible with 2.49 server at u'https://ipa.[domain].com/ipa/xml' host_mod: 2.58 client incompatible with 2.49 server at u'https://ipa. [domain].com/ipa/xml' Failed to upload host SSH public keys. I understand that this is not a critical failure and that I can manually upload the host keys if needed but the bit I don't understand is where the version numbers come from. How do I revert the api to version 2.49 to match the server? What is best practice here, should I be using a different source for the client install script? Is there a copy of the correct client files stashed on the server somewhere? Would anyone be interested in helping with development of a yum and apt repo on the server to make all this easier? -- Kind regards, Will Sheldon -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Sat Dec 28 17:50:33 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Sat, 28 Dec 2013 12:50:33 -0500 Subject: [Freeipa-users] ipa-client-install 2.58 client incompatible with 2.49 server In-Reply-To: References: Message-ID: <52BF0F69.6010502@redhat.com> Will Sheldon wrote: > > Hello :) > > I'm trying to setup a ubuntu 12.04.3 client running freeipa-client > 3.2.0-0ubuntu1~precise1 form the apt repo at > http://ppa.launchpad.net/freeipa/ppa/ubuntu > The server is a (fully updated) centos 6.5 box running ipa-server.x86_64 > 3.0.0-37.el6 > > The script mostly works on a stock install, but there is an error > uploading SSH keys, This appears to be called from the > ipa-client-install script line 1436: > > result = api.Command['host_mod'](unicode(hostname), > > Which generates the following output when run: > > stderr= > Caught fault 901 from server https://ipa.[domain].com/ipa/xml: 2.58 > client incompatible with 2.49 server at u'https://ipa.[domain].com/ipa/xml' > host_mod: 2.58 client incompatible with 2.49 server at > u'https://ipa.[domain].com/ipa/xml' > Failed to upload host SSH public keys. > > I understand that this is not a critical failure and that I can manually > upload the host keys if needed but the bit I don't understand is where > the version numbers come from. The API version is baked into the client and server. We generally provide a backwards compatible server, but right now not the client (so a new client can't always have 100% success talking to an old server). We are actually working on this, especially for client enrollment, to make things work more smoothly. > How do I revert the api to version 2.49 to match the server? You'd have to modify ipapython/version.py on each client before enrollment. For enrollment I can't think of any side-effects, but if you ever tried the IPA admin tool on such a client then some odd things could happen. > What is best practice here, should I be using a different source for the > client install script? I don't know what is available for Debian/Ubuntu clients these days. It is being worked on very hard though I think the focus is on the latest source which explains the mismatch. > Is there a copy of the correct client files stashed on the server somewhere? > Would anyone be interested in helping with development of a yum and apt > repo on the server to make all this easier? The server being the IPA server, so it can distribute the client bits? An interesting idea. rob From arthur at deus.pro Sun Dec 29 07:13:53 2013 From: arthur at deus.pro (Arthur) Date: Sun, 29 Dec 2013 11:13:53 +0400 Subject: [Freeipa-users] sssd off after authconfig update In-Reply-To: <20131226061924.GA9242@fluxcoil.net> References: <52BBC5C0.2060007@deus.pro> <20131226061924.GA9242@fluxcoil.net> Message-ID: <52BFCBB1.5030302@deus.pro> Ok. I'll try to check that. I am away right now. 26.12.2013 10:19, Christian Horn ?????: > Hi, > > On Thu, Dec 26, 2013 at 11:59:28AM +0600, Arthur Faizullin wrote: >> As I mentioned earlier in my previous topic, when I do: >> # authconfig ??--enablemkhomedir ??update >> that somehow makes sssd off (disables autostart), so I should do: >> # chkconfig sssd on >> os: EL6 (CentOS) >> ipa version: 3.0 (from repository) >> That is not a big problem, but anyway that is not right. >> If it is normal way, then it is not mentioned in documentation. > Well, when calling authconfig you do not provide any new data > (IPA servers or such) which could be used by sssd. Is the following > leaving sssd enabled? > > # authconfig --enablemkhomedir --enablesssd --update > > > Christian > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From andrew.holway at gmail.com Sun Dec 29 10:33:34 2013 From: andrew.holway at gmail.com (Andrew Holway) Date: Sun, 29 Dec 2013 10:33:34 +0000 Subject: [Freeipa-users] Domain Controllers Message-ID: Hello, I am trying to work out how to organise some domain controllers. I understand that you can only have one domain controller per domain and one domain per domain controller. corp.com is controlled by a corporate active directory. We would like to create two linux subdomains controlled by freeipa however we don't (yet) require any trust between the corporate active directory and freeipa. vct.corp.com test.corp.com However as these are effectively two domains I believe each would require its own freeIPA server. Is it true that, in order to support these two subdomains we would have to put them under a 'master' subdomain to give them a common domain element? vct.linux.corp.com test.linux.corp.com Thanks, Andrew From t.sailer at alumni.ethz.ch Sun Dec 29 10:40:38 2013 From: t.sailer at alumni.ethz.ch (Thomas Sailer) Date: Sun, 29 Dec 2013 11:40:38 +0100 Subject: [Freeipa-users] Upgrading freeipa server from f18 to f20 Message-ID: <52BFFC26.109@alumni.ethz.ch> I've updated the machine running freeipa from f18 to f20. Now I still have the old pki-base package (pki-base-10.0.6-1.fc18.noarch). Trying to upgrade it results in the following message: error: lua script failed: [string "%pretrans(pki-base-10.1.0-1.fc20.noarch)"]:22: Unable to upgrade to Fedora 20. There are Dogtag 9 instances that will no longer work since they require Tomcat 6, and Tomcat 6 is no longer available in Fedora 20. Please follow these instructions to migrate the instances to Dogtag 10: http://pki.fedoraproject.org/wiki/Migrating_Dogtag_9_Instances_to_Dogtag_10 Error in PRETRANS scriptlet in rpm package pki-base-10.1.0-1.fc20.noarch The above mentioned wiki page suggests that the easiest way to upgrade dogtag is by creating a replica. However, ipa-replica-prepare fails with: [Errno 2] No such file or directory: '/etc/pki/pki-tomcat/password.conf' There isn't even a directory named /etc/pki/pki-tomcat This server has separate dirserv instances for PKI and the rest. Does anyone have an idea how to do the dogtag upgrade? Tom From simo at redhat.com Sun Dec 29 14:47:36 2013 From: simo at redhat.com (Simo Sorce) Date: Sun, 29 Dec 2013 09:47:36 -0500 Subject: [Freeipa-users] Domain Controllers In-Reply-To: References: Message-ID: <1388328456.26102.2.camel@willson.li.ssimo.org> On Sun, 2013-12-29 at 10:33 +0000, Andrew Holway wrote: > Hello, > > I am trying to work out how to organise some domain controllers. I > understand that you can only have one domain controller per domain and > one domain per domain controller. > > corp.com is controlled by a corporate active directory. We would like > to create two linux subdomains controlled by freeipa however we don't > (yet) require any trust between the corporate active directory and > freeipa. > > vct.corp.com > test.corp.com > > However as these are effectively two domains I believe each would > require its own freeIPA server. > > Is it true that, in order to support these two subdomains we would > have to put them under a 'master' subdomain to give them a common > domain element? > > vct.linux.corp.com > test.linux.corp.com No it is not necessary to have 2 different domains, unlike Active Directory, FreeIPA can manage clients in multiple DNS domains within a single REALM. It requires a bit of caution in setting up FreeIPA, and in some cases some configuration in older clients to associate the REALM to the DNS name, but it is possible to have a single domain serve multiple DNS domains. Also it is not true you can have only one Domain Controlle rper Domain, you can have multiple DCs per Domain that replicate data between them. FreeIPA in particular supports only multi-master configurations. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Sun Dec 29 14:49:42 2013 From: simo at redhat.com (Simo Sorce) Date: Sun, 29 Dec 2013 09:49:42 -0500 Subject: [Freeipa-users] Upgrading freeipa server from f18 to f20 In-Reply-To: <52BFFC26.109@alumni.ethz.ch> References: <52BFFC26.109@alumni.ethz.ch> Message-ID: <1388328582.26102.4.camel@willson.li.ssimo.org> On Sun, 2013-12-29 at 11:40 +0100, Thomas Sailer wrote: > I've updated the machine running freeipa from f18 to f20. > > Now I still have the old pki-base package > (pki-base-10.0.6-1.fc18.noarch). Trying to upgrade it results in the > following message: > > error: lua script failed: [string > "%pretrans(pki-base-10.1.0-1.fc20.noarch)"]:22: Unable to upgrade to > Fedora 20. There are Dogtag 9 instances > that will no longer work since they require Tomcat 6, and > Tomcat 6 is no longer available in Fedora 20. > > Please follow these instructions to migrate the instances to > Dogtag 10: > > http://pki.fedoraproject.org/wiki/Migrating_Dogtag_9_Instances_to_Dogtag_10 > Error in PRETRANS scriptlet in rpm package pki-base-10.1.0-1.fc20.noarch > > The above mentioned wiki page suggests that the easiest way to upgrade > dogtag is by creating a replica. > > However, ipa-replica-prepare fails with: > [Errno 2] No such file or directory: '/etc/pki/pki-tomcat/password.conf' > > There isn't even a directory named /etc/pki/pki-tomcat > > This server has separate dirserv instances for PKI and the rest. > > Does anyone have an idea how to do the dogtag upgrade? Unfortunately you should have created the replica *before* the upgrade. Have you tried downgrading all dogtag and tomcat packages to the fc18 ones ? Simo. -- Simo Sorce * Red Hat, Inc * New York From aellert at numeezy.com Mon Dec 30 09:48:11 2013 From: aellert at numeezy.com (Alexandre Ellert) Date: Mon, 30 Dec 2013 10:48:11 +0100 Subject: [Freeipa-users] named failure Message-ID: <23ABE75B-1C04-48F6-8D78-F5A179E65B22@numeezy.com> Hi, This night, named crashed on my IPA server (Centos 6.5) : Dec 29 02:27:02 ipa-master named[1537]: received control channel command 'reload' Dec 29 02:27:03 ipa-master named[1537]: ldap_helper.c:640: REQUIRE(pthread_kill(ldap_inst->watcher, 10) == 0) failed, back trace Dec 29 02:27:03 ipa-master named[1537]: #0 0x7f6f443a0eff in ?? Dec 29 02:27:03 ipa-master named[1537]: #1 0x7f6f42d0c89a in ?? Dec 29 02:27:03 ipa-master named[1537]: #2 0x7f6f3e48acbf in ?? Dec 29 02:27:03 ipa-master named[1537]: #3 0x7f6f3e48efd6 in ?? Dec 29 02:27:03 ipa-master named[1537]: #4 0x7f6f3e48f591 in ?? Dec 29 02:27:03 ipa-master named[1537]: #5 0x7f6f43bfca54 in ?? Dec 29 02:27:03 ipa-master named[1537]: #6 0x7f6f443c1b87 in ?? Dec 29 02:27:03 ipa-master named[1537]: #7 0x7f6f443c4726 in ?? Dec 29 02:27:03 ipa-master named[1537]: #8 0x7f6f443c4b36 in ?? Dec 29 02:27:03 ipa-master named[1537]: #9 0x7f6f443c4cf8 in ?? Dec 29 02:27:03 ipa-master named[1537]: #10 0x7f6f44399f55 in ?? Dec 29 02:27:03 ipa-master named[1537]: #11 0x7f6f4439d616 in ?? Dec 29 02:27:03 ipa-master named[1537]: #12 0x7f6f42d2b2f8 in ?? Dec 29 02:27:03 ipa-master named[1537]: #13 0x7f6f426e09d1 in ?? Dec 29 02:27:03 ipa-master named[1537]: #14 0x7f6f41c41b6d in ?? Dec 29 02:27:03 ipa-master named[1537]: exiting (due to assertion failure) DNS was setup during installation time and didn't notify any problem since this server is in production (several months). Can you please advice about how to investigate to find the root cause of this crash ? Should I worry about that or is this just a isolated case ? Thanks for your support. Alexandre. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tompos at martos.bme.hu Mon Dec 30 17:28:28 2013 From: tompos at martos.bme.hu (Tamas Papp) Date: Mon, 30 Dec 2013 18:28:28 +0100 Subject: [Freeipa-users] CA replication Message-ID: <52C1AD3C.4020604@martos.bme.hu> hi All, I'm trying to replicate the CA server: $ ipa-replica-install -p XXXXXXX --setup-ca -d --mkhomedir replica-info-ipa11.bpo.cxn.gpg Without --setup-ca it works correctly. The output of the above command: [...] ipa : DEBUG Starting external process ipa : DEBUG args=/bin/systemctl is-enabled dirsrv.target ipa : DEBUG Process finished, return code=1 ipa : DEBUG stdout=disabled ipa : DEBUG stderr= ipa : DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state' ipa : DEBUG Starting external process ipa : DEBUG args=/bin/systemctl disable dirsrv.target ipa : DEBUG Process finished, return code=0 ipa : DEBUG stdout= ipa : DEBUG stderr= ipa : DEBUG duration: 0 seconds ipa : DEBUG Done configuring directory server (dirsrv). Done configuring directory server (dirsrv). ipa : DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' ipa : DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' ipa : DEBUG Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds ipa : DEBUG [1/19]: creating certificate server user [1/19]: creating certificate server user ipa : DEBUG ca user pkiuser exists ipa : DEBUG duration: 0 seconds ipa : DEBUG [2/19]: configuring certificate server instance [2/19]: configuring certificate server instance ipa : DEBUG Contents of pkispawn configuration file (/tmp/tmpoRxk1S): [CA] pki_security_domain_name = IPA pki_enable_proxy = True pki_restart_configured_instance = False pki_backup_keys = True pki_backup_password = XXXXXXXX pki_client_database_dir = /tmp/tmp-XPC2YR pki_client_database_password = XXXXXXXX pki_client_database_purge = False pki_client_pkcs12_password = XXXXXXXX pki_admin_name = admin pki_admin_uid = admin pki_admin_email = root at localhost pki_admin_password = XXXXXXXX pki_admin_nickname = ipa-ca-agent pki_admin_subject_dn = cn=ipa-ca-agent,O=CXN pki_client_admin_cert_p12 = /root/ca-agent.p12 pki_ds_ldap_port = 389 pki_ds_password = XXXXXXXX pki_ds_base_dn = o=ipaca pki_ds_database = ipaca pki_subsystem_subject_dn = cn=CA Subsystem,O=CXN pki_ocsp_signing_subject_dn = cn=OCSP Subsystem,O=CXN pki_ssl_server_subject_dn = cn=ipa11.bpo.cxn,O=CXN pki_audit_signing_subject_dn = cn=CA Audit,O=CXN pki_ca_signing_subject_dn = cn=Certificate Authority,O=CXN pki_subsystem_nickname = subsystemCert cert-pki-ca pki_ocsp_signing_nickname = ocspSigningCert cert-pki-ca pki_ssl_server_nickname = Server-Cert cert-pki-ca pki_audit_signing_nickname = auditSigningCert cert-pki-ca pki_ca_signing_nickname = caSigningCert cert-pki-ca pki_security_domain_hostname = ipa12.bpo.cxn pki_security_domain_https_port = 443 pki_security_domain_user = admin pki_security_domain_password = XXXXXXXX pki_clone = True pki_clone_pkcs12_path = /tmp/ca.p12 pki_clone_pkcs12_password = XXXXXXXX pki_clone_replication_security = TLS pki_clone_replication_master_port = 389 pki_clone_replication_clone_port = 389 pki_clone_replicate_schema = False pki_clone_uri = https://ipa12.bpo.cxn:443 ipa : DEBUG Starting external process ipa : DEBUG args=/usr/sbin/pkispawn -s CA -f /tmp/tmpoRxk1S And it's waiting here forever, not even timeout. strace output of pkispawn shows up it's trying to get data from the local ldap service: open("/etc/hosts", O_RDONLY|O_CLOEXEC) = 4 fstat(4, {st_mode=S_IFREG|0644, st_size=281, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f46307e2000 read(4, "127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4\n::1 localhost localhost.localdomain localhost6 localhost6.localdomain6\n\n10.0.0.73\tipa12.bpo.cxn ipa12\n10.128.0.5\tipa31.bph.cxn ipa31\n10.128.0.6\tipa32.bph.cxn ipa32\n10.0.0.12\tipa11.bpo.cxn ipa11\n", 4096) = 281 read(4, "", 4096) = 0 close(4) = 0 munmap(0x7f46307e2000, 4096) = 0 socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 4 fcntl(4, F_SETFD, FD_CLOEXEC) = 0 setsockopt(4, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0 setsockopt(4, SOL_TCP, TCP_NODELAY, [1], 4) = 0 connect(4, {sa_family=AF_INET, sin_port=htons(389), sin_addr=inet_addr("10.0.0.12")}, 16) = 0 write(4, "0%\2\1\1c \4\0\n\1\0\n\1\0\2\1\0\2\1\0\1\1\0\207\vobjectClass0\0", 39) = 39 poll([{fd=4, events=POLLIN|POLLPRI}], 1, 4294967295 If I run ldapsearch -x -h ipa11, then indeed, I can see the same behaviour. strace output of ns-slapd: [pid 2028] accept(6, {sa_family=AF_INET6, sin6_port=htons(59587), inet_pton(AF_INET6, "::ffff:10.0.0.12", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 24 [pid 2028] fcntl(24, F_GETFL) = 0x2 (flags O_RDWR) [pid 2028] fcntl(24, F_SETFL, O_RDWR|O_NONBLOCK) = 0 [pid 2028] fcntl(24, F_DUPFD, 64) = 109 [pid 2028] close(24) = 0 [pid 2028] setsockopt(109, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0 [pid 2028] setsockopt(109, SOL_TCP, TCP_NODELAY, [0], 4) = 0 [pid 2028] getsockname(109, {sa_family=AF_INET6, sin6_port=htons(389), inet_pton(AF_INET6, "::ffff:10.0.0.12", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 0 [pid 2028] poll([{fd=28, events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}, {fd=109, events=POLLIN}, {fd=64, events=POLLIN}, {fd=66, events=POLLIN}, {fd=65, events=POLLIN}], 8, 250) = 1 ([{fd=109, revents=POLLIN}]) [pid 2028] poll([{fd=28, events=POLLIN}, {fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}, {fd=64, events=POLLIN}, {fd=66, events=POLLIN}, {fd=65, events=POLLIN}], 7, 250 [pid 2030] <... select resumed> ) = 0 (Timeout) (Yes, it is ip6) Both servers are KVMs, the source is F19, destination is F20. What do I miss? Thanks, tamas From dpal at redhat.com Tue Dec 31 23:38:02 2013 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 31 Dec 2013 18:38:02 -0500 Subject: [Freeipa-users] Integrate bio-metric authentication with FreeIPA In-Reply-To: References: Message-ID: <52C3555A.3060100@redhat.com> On 12/22/2013 10:49 AM, Danijel Maksic wrote: > Hello, > > I'm interested in using FreeIPA but I can not find a way to integrate > bio-metric authentication. > Is there a way to do this? Could you direct me to some text or tutorial? > > Thanks and Best Regards, > > Danijel Maksic > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users Can you describe in more details how biometric authentication would work device/component/protocol wise? Usage scenario would be a good start. Just describe the result you are looking for and we will try to figure out what can be done to make this happen. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Tue Dec 31 23:45:37 2013 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 31 Dec 2013 18:45:37 -0500 Subject: [Freeipa-users] named failure In-Reply-To: <23ABE75B-1C04-48F6-8D78-F5A179E65B22@numeezy.com> References: <23ABE75B-1C04-48F6-8D78-F5A179E65B22@numeezy.com> Message-ID: <52C35721.50401@redhat.com> On 12/30/2013 04:48 AM, Alexandre Ellert wrote: > Hi, > > This night, named crashed on my IPA server (Centos 6.5) : > > Dec 29 02:27:02 ipa-master named[1537]: received control channel > command 'reload' > Dec 29 02:27:03 ipa-master named[1537]: ldap_helper.c:640: > REQUIRE(pthread_kill(ldap_inst->watcher, 10) == 0) failed, back trace > Dec 29 02:27:03 ipa-master named[1537]: #0 0x7f6f443a0eff in ?? > Dec 29 02:27:03 ipa-master named[1537]: #1 0x7f6f42d0c89a in ?? > Dec 29 02:27:03 ipa-master named[1537]: #2 0x7f6f3e48acbf in ?? > Dec 29 02:27:03 ipa-master named[1537]: #3 0x7f6f3e48efd6 in ?? > Dec 29 02:27:03 ipa-master named[1537]: #4 0x7f6f3e48f591 in ?? > Dec 29 02:27:03 ipa-master named[1537]: #5 0x7f6f43bfca54 in ?? > Dec 29 02:27:03 ipa-master named[1537]: #6 0x7f6f443c1b87 in ?? > Dec 29 02:27:03 ipa-master named[1537]: #7 0x7f6f443c4726 in ?? > Dec 29 02:27:03 ipa-master named[1537]: #8 0x7f6f443c4b36 in ?? > Dec 29 02:27:03 ipa-master named[1537]: #9 0x7f6f443c4cf8 in ?? > Dec 29 02:27:03 ipa-master named[1537]: #10 0x7f6f44399f55 in ?? > Dec 29 02:27:03 ipa-master named[1537]: #11 0x7f6f4439d616 in ?? > Dec 29 02:27:03 ipa-master named[1537]: #12 0x7f6f42d2b2f8 in ?? > Dec 29 02:27:03 ipa-master named[1537]: #13 0x7f6f426e09d1 in ?? > Dec 29 02:27:03 ipa-master named[1537]: #14 0x7f6f41c41b6d in ?? > Dec 29 02:27:03 ipa-master named[1537]: exiting (due to assertion failure) > > DNS was setup during installation time and didn't notify any problem > since this server is in production (several months). > > Can you please advice about how to investigate to find the root cause > of this crash ? > Should I worry about that or is this just a isolated case ? > > Thanks for your support. > > Alexandre. > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users We have not heard about it so it might be an isolated case. Withe the rest you need to wait till after the holidays, sorry. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: