From pavel at zhukoff.net Thu Mar 1 12:35:57 2012 From: pavel at zhukoff.net (Pavel Zhukov) Date: Thu, 1 Mar 2012 16:35:57 +0400 Subject: [Freeipa-users] Can FreeIPA use FreeRADIUS as users provider Message-ID: <20120301123557.GA15020@work.zhukoff.net> Hi all I'm going to deploy "kerberised network" and have some questions. I've deployed FreeIPA server and enrolled hosts, it's OK, I've deployed RHEV and configured FreeIPA as DS, it's OK. FreeRADIUS is used for user login (thought Cisco FireWall or Cisco VPN) and contains user database (mysql). Is it possible to integrate FreeRADIUS server and FreeIPA? For security reasons replication of transfer) of passwords is impossible. possible scenario: User tries to access some resource (ssh for example) -> ssh server goes to kerberos (IPA) server -> IPA (LDAP?) goes to RADIUS (using kerberos if possible?) -> krb ticket -> login -- Best regards, Pavel Zhukov mailto:pavel at zhukoff.net From simo at redhat.com Thu Mar 1 14:11:41 2012 From: simo at redhat.com (Simo Sorce) Date: Thu, 01 Mar 2012 09:11:41 -0500 Subject: [Freeipa-users] Can FreeIPA use FreeRADIUS as users provider In-Reply-To: <20120301123557.GA15020@work.zhukoff.net> References: <20120301123557.GA15020@work.zhukoff.net> Message-ID: <1330611101.25597.149.camel@willson.li.ssimo.org> On Thu, 2012-03-01 at 16:35 +0400, Pavel Zhukov wrote: > Hi all > I'm going to deploy "kerberised network" and have some questions. > I've deployed FreeIPA server and enrolled hosts, it's OK, > I've deployed RHEV and configured FreeIPA as DS, it's OK. > > FreeRADIUS is used for user login (thought Cisco FireWall or Cisco > VPN) and contains user database (mysql). > > Is it possible to integrate FreeRADIUS server and FreeIPA? For > security reasons replication of transfer) of passwords is impossible. > > possible scenario: > User tries to access some resource (ssh for example) -> ssh server > goes to kerberos (IPA) server -> IPA (LDAP?) goes to RADIUS (using > kerberos if possible?) -> krb ticket -> login No doesn't work this way. But you can use LDAP as a backend for FreeRADIUS so that Radius goes to FreeIPA to try to authenticate users. Simo. -- Simo Sorce * Red Hat, Inc * New York From g17jimmy at gmail.com Thu Mar 1 14:19:34 2012 From: g17jimmy at gmail.com (Jimmy) Date: Thu, 1 Mar 2012 09:19:34 -0500 Subject: [Freeipa-users] Can FreeIPA use FreeRADIUS as users provider In-Reply-To: <1330611101.25597.149.camel@willson.li.ssimo.org> References: <20120301123557.GA15020@work.zhukoff.net> <1330611101.25597.149.camel@willson.li.ssimo.org> Message-ID: I have configured a freeradius server that uses the FreeIPA LDAP backend for user and device authentication. It's not at all difficult. On Thu, Mar 1, 2012 at 9:11 AM, Simo Sorce wrote: > On Thu, 2012-03-01 at 16:35 +0400, Pavel Zhukov wrote: > > Hi all > > I'm going to deploy "kerberised network" and have some questions. > > I've deployed FreeIPA server and enrolled hosts, it's OK, > > I've deployed RHEV and configured FreeIPA as DS, it's OK. > > > > FreeRADIUS is used for user login (thought Cisco FireWall or Cisco > > VPN) and contains user database (mysql). > > > > Is it possible to integrate FreeRADIUS server and FreeIPA? For > > security reasons replication of transfer) of passwords is impossible. > > > > possible scenario: > > User tries to access some resource (ssh for example) -> ssh server > > goes to kerberos (IPA) server -> IPA (LDAP?) goes to RADIUS (using > > kerberos if possible?) -> krb ticket -> login > > No doesn't work this way. > But you can use LDAP as a backend for FreeRADIUS so that Radius goes to > FreeIPA to try to authenticate users. > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > > _______________________________________________ > 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 pavel at zhukoff.net Thu Mar 1 14:21:42 2012 From: pavel at zhukoff.net (Pavel Zhukov) Date: Thu, 1 Mar 2012 18:21:42 +0400 Subject: [Freeipa-users] Can FreeIPA use FreeRADIUS as users provider In-Reply-To: <1330611101.25597.149.camel@willson.li.ssimo.org> References: <20120301123557.GA15020@work.zhukoff.net> <1330611101.25597.149.camel@willson.li.ssimo.org> Message-ID: <20120301142142.GB15020@work.zhukoff.net> Simo, thank you for your answer FreeRADIUS uses very customized (for complex network ACLs) MySQL schema and network team manages it. Unfortunately, I cannot change FreeRADIUS related infrastructure. -- Best regards, Pavel Zhukov mailto:pavel at zhukoff.net On Thu, 01 Mar 2012, Simo Sorce wrote: > On Thu, 2012-03-01 at 16:35 +0400, Pavel Zhukov wrote: > > Hi all > > I'm going to deploy "kerberised network" and have some questions. > > I've deployed FreeIPA server and enrolled hosts, it's OK, > > I've deployed RHEV and configured FreeIPA as DS, it's OK. > > > > FreeRADIUS is used for user login (thought Cisco FireWall or Cisco > > VPN) and contains user database (mysql). > > > > Is it possible to integrate FreeRADIUS server and FreeIPA? For > > security reasons replication of transfer) of passwords is impossible. > > > > possible scenario: > > User tries to access some resource (ssh for example) -> ssh server > > goes to kerberos (IPA) server -> IPA (LDAP?) goes to RADIUS (using > > kerberos if possible?) -> krb ticket -> login > > No doesn't work this way. > But you can use LDAP as a backend for FreeRADIUS so that Radius goes to > FreeIPA to try to authenticate users. > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > From danieljamesscott at gmail.com Thu Mar 1 16:07:20 2012 From: danieljamesscott at gmail.com (Dan Scott) Date: Thu, 1 Mar 2012 11:07:20 -0500 Subject: [Freeipa-users] CA replica installation failure In-Reply-To: <1330550920.4141.6.camel@aleeredhat.laptop> References: <1330549422.4141.3.camel@aleeredhat.laptop> <1330550920.4141.6.camel@aleeredhat.laptop> Message-ID: Hi, I tried with SELinux in permissive mode. It failed in the same way. Dan On Wed, Feb 29, 2012 at 16:28, Ade Lee wrote: > Its a little strange that its showing up as an error -- it shouldn't if > they are already set and they are of the right context. > > That said, its not really an error - and should not be a problem unless > its preventing the installation from completing successfully. > > Try doing the installation with selinux in permissive mode and see if it > makes a difference. > > Ade > > On Wed, 2012-02-29 at 16:18 -0500, Dan Scott wrote: >> On Wed, Feb 29, 2012 at 16:03, Ade Lee wrote: >> > Thats a pretty strange error. ?The ports there are supposed to be >> > reserved for pki_ca_port_t. >> > >> > Can you do the following for each of the ports? >> > semanage port -l |grep 9443 >> >> [root at fileserver3 ~]# semanage port -l |grep 9443 >> pki_ca_port_t ? ? ? ? ? ? ? ? ?tcp ? ? ?9180, 9701, 9443-9447 >> >> 944[456] don't match, but they're in the range, so they should be OK, right? >> >> Is it really an error? Or is it just indicating that the port has >> already been set. >> >> Thanks, >> >> Dan >> >> > Its probably best to completely remove the replica. You could try use >> > dogtag specific commands to uninstall and install the ca - but then the >> > rest of the ipa install scripts would be confused. >> > >> > Ade >> > >> > On Wed, 2012-02-29 at 13:44 -0500, Dan Scott wrote: >> >> Anyone have any suggestions for how I can fix this? >> >> >> >> Dan >> >> >> >> On Mon, Feb 27, 2012 at 21:06, Dan Scott wrote: >> >> > Hi, >> >> > >> >> > I'm having another problem with replica installation - just the CA this time >> >> > >> >> > It looks like there's a problem with SELinux and the pki-ca service: >> >> > >> >> > After configuration, the server can be operated by the command: >> >> > >> >> > ? ?/bin/systemctl restart pki-cad at pki-ca.service >> >> > >> >> > >> >> > 2012-02-27 20:33:45,729 DEBUG stderr=[error] Failed setting selinux >> >> > context pki_ca_port_t for 9180. ?Port already defined otherwise. >> >> > [error] Failed setting selinux context pki_ca_port_t for 9701. ?Port >> >> > already defined otherwise. >> >> > [error] Failed setting selinux context pki_ca_port_t for 9443. ?Port >> >> > already defined otherwise. >> >> > [error] Failed setting selinux context pki_ca_port_t for 9444. ?Port >> >> > already defined otherwise. >> >> > [error] Failed setting selinux context pki_ca_port_t for 9446. ?Port >> >> > already defined otherwise. >> >> > [error] Failed setting selinux context pki_ca_port_t for 9445. ?Port >> >> > already defined otherwise. >> >> > [error] Failed setting selinux context pki_ca_port_t for 9447. ?Port >> >> > already defined otherwise. >> >> > [error] FAILED run_command("/bin/systemctl restart >> >> > pki-cad at pki-ca.service"), exit status=1 output="Job failed. See system >> >> > logs and 'systemctl status' for details." >> >> > >> >> > 2012-02-27 20:33:45,729 DEBUG ? duration: 6 seconds >> >> > 2012-02-27 20:33:45,730 DEBUG ? [3/11]: configuring certificate server instance >> >> > [clip] >> >> > 2012-02-27 20:33:46,159 DEBUG stdout=libpath=/usr/lib64 >> >> > ####################################################################### >> >> > CRYPTO INIT WITH CERTDB:/tmp/tmp-cDdVph >> >> > tokenpwd:XXXXXXXX >> >> > ############################################# >> >> > Attempting to connect to: fileserver3.example.com:9445 >> >> > Exception in LoginPanel(): java.lang.NullPointerException >> >> > ERROR: ConfigureCA: LoginPanel() failure >> >> > ERROR: unable to create CA >> >> > >> >> > ####################################################################### >> >> > >> >> > 2012-02-27 20:33:46,159 DEBUG stderr=Exception: Unable to Send >> >> > Request:java.net.ConnectException: Connection refused >> >> > java.net.ConnectException: Connection refused >> >> > ? ? ? ?at java.net.PlainSocketImpl.socketConnect(Native Method) >> >> > ? ? ? ?at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:327) >> >> > ? ? ? ?at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:193) >> >> > ? ? ? ?at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:180) >> >> > ? ? ? ?at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384) >> >> > ? ? ? ?at java.net.Socket.connect(Socket.java:546) >> >> > ? ? ? ?at java.net.Socket.connect(Socket.java:495) >> >> > ? ? ? ?at java.net.Socket.(Socket.java:392) >> >> > ? ? ? ?at java.net.Socket.(Socket.java:235) >> >> > ? ? ? ?at HTTPClient.sslConnect(HTTPClient.java:326) >> >> > ? ? ? ?at ConfigureCA.LoginPanel(ConfigureCA.java:244) >> >> > ? ? ? ?at ConfigureCA.ConfigureCAInstance(ConfigureCA.java:1157) >> >> > ? ? ? ?at ConfigureCA.main(ConfigureCA.java:1672) >> >> > java.lang.NullPointerException >> >> > ? ? ? ?at ConfigureCA.LoginPanel(ConfigureCA.java:245) >> >> > ? ? ? ?at ConfigureCA.ConfigureCAInstance(ConfigureCA.java:1157) >> >> > ? ? ? ?at ConfigureCA.main(ConfigureCA.java:1672) >> >> > >> >> > /var/log/messages contains the following: >> >> > >> >> > Feb 27 20:40:45 localhost kpasswd[2198]: Error receiving request (104) >> >> > Connection reset by peer >> >> > Feb 27 20:57:26 localhost pkicontrol[2778]: /usr/bin/runcon: invalid >> >> > context: system_u:system_r:pki_ca_script_t:s0: Invalid argument >> >> > Feb 27 20:57:26 localhost systemd[1]: pki-cad at pki-ca.service: control >> >> > process exited, code=exited status=1 >> >> > Feb 27 20:57:26 localhost systemd[1]: Unit pki-cad at pki-ca.service >> >> > entered failed state. >> >> > >> >> > This is a fresh install of Fedora 16. There are no updates to apply. >> >> > >> >> > Any ideas? >> >> > >> >> > One more thing. Is there a way to remove and reinstall just the CA? Or >> >> > do I have to completely remove and re-install the entire IPA replica? >> >> > i.e. Is there something like ipa-ca-install --uninstall I couldn't see >> >> > the option anywhere. >> >> > >> >> > Thanks, >> >> > >> >> > Dan >> >> >> >> _______________________________________________ >> >> Freeipa-users mailing list >> >> Freeipa-users at redhat.com >> >> https://www.redhat.com/mailman/listinfo/freeipa-users >> > >> > > > From alee at redhat.com Thu Mar 1 17:48:47 2012 From: alee at redhat.com (Ade Lee) Date: Thu, 01 Mar 2012 12:48:47 -0500 Subject: [Freeipa-users] CA replica installation failure In-Reply-To: References: <1330549422.4141.3.camel@aleeredhat.laptop> <1330550920.4141.6.camel@aleeredhat.laptop> Message-ID: <1330624127.4141.34.camel@aleeredhat.laptop> Ok -- at this point, I need some logs to determine why the server is not starting. How about you zip up all the logs in /var/log/pki-ca as well as /var/pki-ca-install.log ? Ade On Thu, 2012-03-01 at 11:07 -0500, Dan Scott wrote: > Hi, > > I tried with SELinux in permissive mode. It failed in the same way. > > Dan > > On Wed, Feb 29, 2012 at 16:28, Ade Lee wrote: > > Its a little strange that its showing up as an error -- it shouldn't if > > they are already set and they are of the right context. > > > > That said, its not really an error - and should not be a problem unless > > its preventing the installation from completing successfully. > > > > Try doing the installation with selinux in permissive mode and see if it > > makes a difference. > > > > Ade > > > > On Wed, 2012-02-29 at 16:18 -0500, Dan Scott wrote: > >> On Wed, Feb 29, 2012 at 16:03, Ade Lee wrote: > >> > Thats a pretty strange error. The ports there are supposed to be > >> > reserved for pki_ca_port_t. > >> > > >> > Can you do the following for each of the ports? > >> > semanage port -l |grep 9443 > >> > >> [root at fileserver3 ~]# semanage port -l |grep 9443 > >> pki_ca_port_t tcp 9180, 9701, 9443-9447 > >> > >> 944[456] don't match, but they're in the range, so they should be OK, right? > >> > >> Is it really an error? Or is it just indicating that the port has > >> already been set. > >> > >> Thanks, > >> > >> Dan > >> > >> > Its probably best to completely remove the replica. You could try use > >> > dogtag specific commands to uninstall and install the ca - but then the > >> > rest of the ipa install scripts would be confused. > >> > > >> > Ade > >> > > >> > On Wed, 2012-02-29 at 13:44 -0500, Dan Scott wrote: > >> >> Anyone have any suggestions for how I can fix this? > >> >> > >> >> Dan > >> >> > >> >> On Mon, Feb 27, 2012 at 21:06, Dan Scott wrote: > >> >> > Hi, > >> >> > > >> >> > I'm having another problem with replica installation - just the CA this time > >> >> > > >> >> > It looks like there's a problem with SELinux and the pki-ca service: > >> >> > > >> >> > After configuration, the server can be operated by the command: > >> >> > > >> >> > /bin/systemctl restart pki-cad at pki-ca.service > >> >> > > >> >> > > >> >> > 2012-02-27 20:33:45,729 DEBUG stderr=[error] Failed setting selinux > >> >> > context pki_ca_port_t for 9180. Port already defined otherwise. > >> >> > [error] Failed setting selinux context pki_ca_port_t for 9701. Port > >> >> > already defined otherwise. > >> >> > [error] Failed setting selinux context pki_ca_port_t for 9443. Port > >> >> > already defined otherwise. > >> >> > [error] Failed setting selinux context pki_ca_port_t for 9444. Port > >> >> > already defined otherwise. > >> >> > [error] Failed setting selinux context pki_ca_port_t for 9446. Port > >> >> > already defined otherwise. > >> >> > [error] Failed setting selinux context pki_ca_port_t for 9445. Port > >> >> > already defined otherwise. > >> >> > [error] Failed setting selinux context pki_ca_port_t for 9447. Port > >> >> > already defined otherwise. > >> >> > [error] FAILED run_command("/bin/systemctl restart > >> >> > pki-cad at pki-ca.service"), exit status=1 output="Job failed. See system > >> >> > logs and 'systemctl status' for details." > >> >> > > >> >> > 2012-02-27 20:33:45,729 DEBUG duration: 6 seconds > >> >> > 2012-02-27 20:33:45,730 DEBUG [3/11]: configuring certificate server instance > >> >> > [clip] > >> >> > 2012-02-27 20:33:46,159 DEBUG stdout=libpath=/usr/lib64 > >> >> > ####################################################################### > >> >> > CRYPTO INIT WITH CERTDB:/tmp/tmp-cDdVph > >> >> > tokenpwd:XXXXXXXX > >> >> > ############################################# > >> >> > Attempting to connect to: fileserver3.example.com:9445 > >> >> > Exception in LoginPanel(): java.lang.NullPointerException > >> >> > ERROR: ConfigureCA: LoginPanel() failure > >> >> > ERROR: unable to create CA > >> >> > > >> >> > ####################################################################### > >> >> > > >> >> > 2012-02-27 20:33:46,159 DEBUG stderr=Exception: Unable to Send > >> >> > Request:java.net.ConnectException: Connection refused > >> >> > java.net.ConnectException: Connection refused > >> >> > at java.net.PlainSocketImpl.socketConnect(Native Method) > >> >> > at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:327) > >> >> > at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:193) > >> >> > at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:180) > >> >> > at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384) > >> >> > at java.net.Socket.connect(Socket.java:546) > >> >> > at java.net.Socket.connect(Socket.java:495) > >> >> > at java.net.Socket.(Socket.java:392) > >> >> > at java.net.Socket.(Socket.java:235) > >> >> > at HTTPClient.sslConnect(HTTPClient.java:326) > >> >> > at ConfigureCA.LoginPanel(ConfigureCA.java:244) > >> >> > at ConfigureCA.ConfigureCAInstance(ConfigureCA.java:1157) > >> >> > at ConfigureCA.main(ConfigureCA.java:1672) > >> >> > java.lang.NullPointerException > >> >> > at ConfigureCA.LoginPanel(ConfigureCA.java:245) > >> >> > at ConfigureCA.ConfigureCAInstance(ConfigureCA.java:1157) > >> >> > at ConfigureCA.main(ConfigureCA.java:1672) > >> >> > > >> >> > /var/log/messages contains the following: > >> >> > > >> >> > Feb 27 20:40:45 localhost kpasswd[2198]: Error receiving request (104) > >> >> > Connection reset by peer > >> >> > Feb 27 20:57:26 localhost pkicontrol[2778]: /usr/bin/runcon: invalid > >> >> > context: system_u:system_r:pki_ca_script_t:s0: Invalid argument > >> >> > Feb 27 20:57:26 localhost systemd[1]: pki-cad at pki-ca.service: control > >> >> > process exited, code=exited status=1 > >> >> > Feb 27 20:57:26 localhost systemd[1]: Unit pki-cad at pki-ca.service > >> >> > entered failed state. > >> >> > > >> >> > This is a fresh install of Fedora 16. There are no updates to apply. > >> >> > > >> >> > Any ideas? > >> >> > > >> >> > One more thing. Is there a way to remove and reinstall just the CA? Or > >> >> > do I have to completely remove and re-install the entire IPA replica? > >> >> > i.e. Is there something like ipa-ca-install --uninstall I couldn't see > >> >> > the option anywhere. > >> >> > > >> >> > Thanks, > >> >> > > >> >> > Dan > >> >> > >> >> _______________________________________________ > >> >> Freeipa-users mailing list > >> >> Freeipa-users at redhat.com > >> >> https://www.redhat.com/mailman/listinfo/freeipa-users > >> > > >> > > > > > From freeipa at noboost.org Fri Mar 2 02:16:41 2012 From: freeipa at noboost.org (Craig T) Date: Fri, 2 Mar 2012 05:16:41 +0300 Subject: [Freeipa-users] IPA & hostnames. Why not use `hostname -fqdn` instead of forcing `hostname` to be fully qualified? Message-ID: <20120302021640.GA32745@noboost.org> Hi, Server Side: RHEL6.2 ipa-admintools-2.1.3-9.el6.x86_64 ipa-client-2.1.3-9.el6.x86_64 ipa-pki-ca-theme-9.0.3-7.el6.noarch ipa-pki-common-theme-9.0.3-7.el6.noarch ipa-python-2.1.3-9.el6.x86_64 ipa-server-2.1.3-9.el6.x86_64 ipa-server-selinux-2.1.3-9.el6.x86_64 Client Side Config: Centos 6.2 ipa-client-2.1.3-9.el6.x86_64 ipa-python-2.1.3-9.el6.x86_64 Issue: IPA (via sssd) requires that a hostname (as returned by the `hostname` commmand) be fully qualified. This requirement has caused us no end of grief due to ripple effects not related to IPA, it breaks other software we use which expects hostname to be not fully qualified. We don't understand why IPA & sssd require that a machine's hostname be fully qualified when `hostname --fqdn` can be used instead? In our case we had hostname setup to be the machine name as in: # hostname foo # dnsdomainname bar.com.au # hostname --fqdn foo.bar.com.au Why doesn't IPA & SSD use the value returned by `hostname --fqdn`? Why must `hostname` itself be fully qualified when `hostname --fqdn` is available? Regards, Craig From ondrejv at s3group.cz Fri Mar 2 11:37:35 2012 From: ondrejv at s3group.cz (Ondrej Valousek) Date: Fri, 02 Mar 2012 12:37:35 +0100 Subject: [Freeipa-users] Virtualising FreeIPA domain controller Message-ID: <4F50B0FF.4050408@s3group.cz> I just got an information that it is a very bad idea to have virtual Domain controllers in Active Directory - server's (and potentially the whole AD) metadata gets corrupted once you 'pause' the machine - just to get a snapshot or backup. I am just wondering - there are many similarities between IPA and Active Directory - can we be affected by this, too? Thanks, Ondrej Proud winners of the prestigious Irish Software Exporter Award 2011 from Irish Exporters Association (IEA). Please, refer to our web site for more details regarding the award. -------- The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications at s3group.com. Thank You. Silicon and Software Systems Limited. Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgallagh at redhat.com Fri Mar 2 13:10:40 2012 From: sgallagh at redhat.com (Stephen Gallagher) Date: Fri, 02 Mar 2012 08:10:40 -0500 Subject: [Freeipa-users] IPA & hostnames. Why not use `hostname -fqdn` instead of forcing `hostname` to be fully qualified? In-Reply-To: <20120302021640.GA32745@noboost.org> References: <20120302021640.GA32745@noboost.org> Message-ID: <1330693840.28274.56.camel@sgallagh520.sgallagh.bos.redhat.com> On Fri, 2012-03-02 at 05:16 +0300, Craig T wrote: > Hi, > > Server Side: > RHEL6.2 > ipa-admintools-2.1.3-9.el6.x86_64 > ipa-client-2.1.3-9.el6.x86_64 > ipa-pki-ca-theme-9.0.3-7.el6.noarch > ipa-pki-common-theme-9.0.3-7.el6.noarch > ipa-python-2.1.3-9.el6.x86_64 > ipa-server-2.1.3-9.el6.x86_64 > ipa-server-selinux-2.1.3-9.el6.x86_64 > > > Client Side Config: > Centos 6.2 > ipa-client-2.1.3-9.el6.x86_64 > ipa-python-2.1.3-9.el6.x86_64 > > > Issue: > IPA (via sssd) requires that a hostname (as returned by the `hostname` > commmand) be fully qualified. > > This requirement has caused us no end of grief due to ripple effects not > related to IPA, it breaks other software we use which expects hostname > to be not fully qualified. > > We don't understand why IPA & sssd require that a machine's hostname be > fully qualified when `hostname --fqdn` can be used instead? > > In our case we had hostname setup to be the machine name as in: > > # hostname > foo > # dnsdomainname > bar.com.au > # hostname --fqdn > foo.bar.com.au > > Why doesn't IPA & SSD use the value returned by `hostname --fqdn`? > > Why must `hostname` itself be fully qualified when `hostname --fqdn` is > available? I think this requirement is only in place during ipa-client-install. sssd.conf has an option 'ipa_hostname=foo.bar.com.au' which it will use regardless of the value that 'hostname' returns. Is there some other place I'm missing? If so, that's probably a bug and should be reported as such. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From sigbjorn at nixtra.com Fri Mar 2 13:52:38 2012 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Fri, 2 Mar 2012 14:52:38 +0100 (CET) Subject: [Freeipa-users] SSSD (sssd_be) crashing on RHEL 6.2 Message-ID: <24111.213.225.75.97.1330696358.squirrel@www.nixtra.com> Hi, I'm experiencing that SSSD is now crashing at random times on _ALL_ RHEL 6.2 machines where we have installed SSSD connected to an IPA domain. SSSD can reach up to a month of uptime before sssd_be crashes. This happens on both physical and virtual machines. It happens at different machines at different times, sometimes during working hours, other times during the middle of the night. It's never happened on several machines at the same time. These machines does not have a GUI and the issue is similar but not directly related to the KDE screensaver lock as per my earlier posts. Also, the KDE screensaver issue was at RHEL 5. What happens is a line in the syslog about sssd_be crashing. sssd_be[1418] general protection ip:41d527 sp:7fff9e82ead0 error:0 in sssd_be[400000+4a000] sssd_be is then being restarted by the parent process, but is no longer usable. Any login via ssh to these machines will just hang. Has anyone else seen this issue? Regards, Siggi From sgallagh at redhat.com Fri Mar 2 14:04:15 2012 From: sgallagh at redhat.com (Stephen Gallagher) Date: Fri, 02 Mar 2012 09:04:15 -0500 Subject: [Freeipa-users] SSSD (sssd_be) crashing on RHEL 6.2 In-Reply-To: <24111.213.225.75.97.1330696358.squirrel@www.nixtra.com> References: <24111.213.225.75.97.1330696358.squirrel@www.nixtra.com> Message-ID: <1330697055.28274.64.camel@sgallagh520.sgallagh.bos.redhat.com> On Fri, 2012-03-02 at 14:52 +0100, Sigbjorn Lie wrote: > Hi, > > I'm experiencing that SSSD is now crashing at random times on _ALL_ RHEL 6.2 machines where we > have installed SSSD connected to an IPA domain. SSSD can reach up to a month of uptime before > sssd_be crashes. This happens on both physical and virtual machines. It happens at different > machines at different times, sometimes during working hours, other times during the middle of the > night. It's never happened on several machines at the same time. > > These machines does not have a GUI and the issue is similar but not directly related to the KDE > screensaver lock as per my earlier posts. Also, the KDE screensaver issue was at RHEL 5. > > What happens is a line in the syslog about sssd_be crashing. > > sssd_be[1418] general protection ip:41d527 sp:7fff9e82ead0 error:0 in sssd_be[400000+4a000] > > sssd_be is then being restarted by the parent process, but is no longer usable. Any login via ssh > to these machines will just hang. > > Has anyone else seen this issue? Can you try to get us a backtrace, please? "general protection" isn't enough information. Though it's interesting that it's "general protection" and not "segfault"... That's certainly new. Do you have abrtd running on these systems? If so, it should be able to capture a core dump when this happens again, which you can use to generate a backtrace for us. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From sigbjorn at nixtra.com Fri Mar 2 14:08:23 2012 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Fri, 2 Mar 2012 15:08:23 +0100 (CET) Subject: [Freeipa-users] SSSD (sssd_be) crashing on RHEL 6.2 In-Reply-To: <1330697055.28274.64.camel@sgallagh520.sgallagh.bos.redhat.com> References: <24111.213.225.75.97.1330696358.squirrel@www.nixtra.com> <1330697055.28274.64.camel@sgallagh520.sgallagh.bos.redhat.com> Message-ID: <26695.213.225.75.97.1330697303.squirrel@www.nixtra.com> On Fri, March 2, 2012 15:04, Stephen Gallagher wrote: > On Fri, 2012-03-02 at 14:52 +0100, Sigbjorn Lie wrote: > >> Hi, >> >> >> I'm experiencing that SSSD is now crashing at random times on _ALL_ RHEL 6.2 machines where we >> have installed SSSD connected to an IPA domain. SSSD can reach up to a month of uptime before >> sssd_be crashes. This happens on both physical and virtual machines. It happens at different >> machines at different times, sometimes during working hours, other times during the middle of >> the night. It's never happened on several machines at the same time. >> >> These machines does not have a GUI and the issue is similar but not directly related to the KDE >> screensaver lock as per my earlier posts. Also, the KDE screensaver issue was at RHEL 5. >> >> What happens is a line in the syslog about sssd_be crashing. >> >> >> sssd_be[1418] general protection ip:41d527 sp:7fff9e82ead0 error:0 in sssd_be[400000+4a000] >> >> sssd_be is then being restarted by the parent process, but is no longer usable. Any login via >> ssh to these machines will just hang. >> >> Has anyone else seen this issue? >> > > > Can you try to get us a backtrace, please? "general protection" isn't > enough information. Though it's interesting that it's "general protection" and not "segfault"... > That's certainly new. > > > Do you have abrtd running on these systems? If so, it should be able to > capture a core dump when this happens again, which you can use to generate a backtrace for us. > _______________________________________________ I certainly do have abrt, some of the dumps are quite large. I will send you these in a private email. Regards, Siggi From simo at redhat.com Fri Mar 2 14:11:31 2012 From: simo at redhat.com (Simo Sorce) Date: Fri, 02 Mar 2012 09:11:31 -0500 Subject: [Freeipa-users] IPA & hostnames. Why not use `hostname -fqdn` instead of forcing `hostname` to be fully qualified? In-Reply-To: <1330693840.28274.56.camel@sgallagh520.sgallagh.bos.redhat.com> References: <20120302021640.GA32745@noboost.org> <1330693840.28274.56.camel@sgallagh520.sgallagh.bos.redhat.com> Message-ID: <1330697491.25597.159.camel@willson.li.ssimo.org> On Fri, 2012-03-02 at 08:10 -0500, Stephen Gallagher wrote: > On Fri, 2012-03-02 at 05:16 +0300, Craig T wrote: > > Hi, > > > > Server Side: > > RHEL6.2 > > ipa-admintools-2.1.3-9.el6.x86_64 > > ipa-client-2.1.3-9.el6.x86_64 > > ipa-pki-ca-theme-9.0.3-7.el6.noarch > > ipa-pki-common-theme-9.0.3-7.el6.noarch > > ipa-python-2.1.3-9.el6.x86_64 > > ipa-server-2.1.3-9.el6.x86_64 > > ipa-server-selinux-2.1.3-9.el6.x86_64 > > > > > > Client Side Config: > > Centos 6.2 > > ipa-client-2.1.3-9.el6.x86_64 > > ipa-python-2.1.3-9.el6.x86_64 > > > > > > Issue: > > IPA (via sssd) requires that a hostname (as returned by the `hostname` > > commmand) be fully qualified. > > > > This requirement has caused us no end of grief due to ripple effects not > > related to IPA, it breaks other software we use which expects hostname > > to be not fully qualified. > > > > We don't understand why IPA & sssd require that a machine's hostname be > > fully qualified when `hostname --fqdn` can be used instead? > > > > In our case we had hostname setup to be the machine name as in: > > > > # hostname > > foo > > # dnsdomainname > > bar.com.au > > # hostname --fqdn > > foo.bar.com.au > > > > Why doesn't IPA & SSD use the value returned by `hostname --fqdn`? > > > > Why must `hostname` itself be fully qualified when `hostname --fqdn` is > > available? > > I think this requirement is only in place during ipa-client-install. > sssd.conf has an option 'ipa_hostname=foo.bar.com.au' which it will use > regardless of the value that 'hostname' returns. > > Is there some other place I'm missing? If so, that's probably a bug and > should be reported as such. There are kerberized programs that expect to use gethostname() and use that name to compose principals. If that name is not fully qualified they will break. Simo. -- Simo Sorce * Red Hat, Inc * New York From sgallagh at redhat.com Fri Mar 2 14:16:31 2012 From: sgallagh at redhat.com (Stephen Gallagher) Date: Fri, 02 Mar 2012 09:16:31 -0500 Subject: [Freeipa-users] SSSD (sssd_be) crashing on RHEL 6.2 In-Reply-To: <26695.213.225.75.97.1330697303.squirrel@www.nixtra.com> References: <24111.213.225.75.97.1330696358.squirrel@www.nixtra.com> <1330697055.28274.64.camel@sgallagh520.sgallagh.bos.redhat.com> <26695.213.225.75.97.1330697303.squirrel@www.nixtra.com> Message-ID: <1330697791.28274.67.camel@sgallagh520.sgallagh.bos.redhat.com> On Fri, 2012-03-02 at 15:08 +0100, Sigbjorn Lie wrote: > On Fri, March 2, 2012 15:04, Stephen Gallagher wrote: > > On Fri, 2012-03-02 at 14:52 +0100, Sigbjorn Lie wrote: > > > >> Hi, > >> > >> > >> I'm experiencing that SSSD is now crashing at random times on _ALL_ RHEL 6.2 machines where we > >> have installed SSSD connected to an IPA domain. SSSD can reach up to a month of uptime before > >> sssd_be crashes. This happens on both physical and virtual machines. It happens at different > >> machines at different times, sometimes during working hours, other times during the middle of > >> the night. It's never happened on several machines at the same time. > >> > >> These machines does not have a GUI and the issue is similar but not directly related to the KDE > >> screensaver lock as per my earlier posts. Also, the KDE screensaver issue was at RHEL 5. > >> > >> What happens is a line in the syslog about sssd_be crashing. > >> > >> > >> sssd_be[1418] general protection ip:41d527 sp:7fff9e82ead0 error:0 in sssd_be[400000+4a000] > >> > >> sssd_be is then being restarted by the parent process, but is no longer usable. Any login via > >> ssh to these machines will just hang. > >> > >> Has anyone else seen this issue? > >> > > > > > > Can you try to get us a backtrace, please? "general protection" isn't > > enough information. Though it's interesting that it's "general protection" and not "segfault"... > > That's certainly new. > > > > > > Do you have abrtd running on these systems? If so, it should be able to > > capture a core dump when this happens again, which you can use to generate a backtrace for us. > > _______________________________________________ > > I certainly do have abrt, some of the dumps are quite large. I will send you these in a private > email. > Thanks, can you also let me know the exact version of SSSD that you're running? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From sigbjorn at nixtra.com Fri Mar 2 14:20:54 2012 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Fri, 2 Mar 2012 15:20:54 +0100 (CET) Subject: [Freeipa-users] SSSD (sssd_be) crashing on RHEL 6.2 In-Reply-To: <1330697791.28274.67.camel@sgallagh520.sgallagh.bos.redhat.com> References: <24111.213.225.75.97.1330696358.squirrel@www.nixtra.com> <1330697055.28274.64.camel@sgallagh520.sgallagh.bos.redhat.com> <26695.213.225.75.97.1330697303.squirrel@www.nixtra.com> <1330697791.28274.67.camel@sgallagh520.sgallagh.bos.redhat.com> Message-ID: <21004.213.225.75.97.1330698054.squirrel@www.nixtra.com> On Fri, March 2, 2012 15:16, Stephen Gallagher wrote: > On Fri, 2012-03-02 at 15:08 +0100, Sigbjorn Lie wrote: > >> On Fri, March 2, 2012 15:04, Stephen Gallagher wrote: >> >>> On Fri, 2012-03-02 at 14:52 +0100, Sigbjorn Lie wrote: >>> >>> >>>> Hi, >>>> >>>> >>>> >>>> I'm experiencing that SSSD is now crashing at random times on _ALL_ RHEL 6.2 machines where >>>> we have installed SSSD connected to an IPA domain. SSSD can reach up to a month of uptime >>>> before sssd_be crashes. This happens on both physical and virtual machines. It happens at >>>> different machines at different times, sometimes during working hours, other times during >>>> the middle of the night. It's never happened on several machines at the same time. >>>> >>>> These machines does not have a GUI and the issue is similar but not directly related to the >>>> KDE >>>> screensaver lock as per my earlier posts. Also, the KDE screensaver issue was at RHEL 5. >>>> >>>> What happens is a line in the syslog about sssd_be crashing. >>>> >>>> >>>> >>>> sssd_be[1418] general protection ip:41d527 sp:7fff9e82ead0 error:0 in sssd_be[400000+4a000] >>>> >>>> >>>> sssd_be is then being restarted by the parent process, but is no longer usable. Any login >>>> via ssh to these machines will just hang. >>>> >>>> Has anyone else seen this issue? >>>> >>>> >>> >>> >>> Can you try to get us a backtrace, please? "general protection" isn't >>> enough information. Though it's interesting that it's "general protection" and not >>> "segfault"... >>> That's certainly new. >>> >>> >>> >>> Do you have abrtd running on these systems? If so, it should be able to >>> capture a core dump when this happens again, which you can use to generate a backtrace for us. >>> _______________________________________________ >>> >> >> I certainly do have abrt, some of the dumps are quite large. I will send you these in a private >> email. >> > > > Thanks, can you also let me know the exact version of SSSD that you're > running? > Sure. sssd-1.5.1-66.el6.x86_64 sssd-client-1.5.1-66.el6.x86_64 Rgds, Siggi From ondrejv at s3group.cz Fri Mar 2 14:21:56 2012 From: ondrejv at s3group.cz (Ondrej Valousek) Date: Fri, 02 Mar 2012 15:21:56 +0100 Subject: [Freeipa-users] IPA & hostnames. Why not use `hostname -fqdn` instead of forcing `hostname` to be fully qualified? In-Reply-To: <1330697491.25597.159.camel@willson.li.ssimo.org> References: <20120302021640.GA32745@noboost.org> <1330693840.28274.56.camel@sgallagh520.sgallagh.bos.redhat.com> <1330697491.25597.159.camel@willson.li.ssimo.org> Message-ID: <4F50D784.6000306@s3group.cz> > There are kerberized programs that expect to use gethostname() and use > that name to compose principals. If that name is not fully qualified > they will break. > > Simo. > Normally, you should have both: [root at ara tmp]# klist -k Keytab name: FILE:/etc/krb5.keytab KVNO Principal ---- -------------------------------------------------------------------------- 19 host/ara.prague.s3group.com at DUBLIN.AD.S3GROUP.COM 19 host/ara at DUBLIN.AD.S3GROUP.COM right? Ondrej Proud winners of the prestigious Irish Software Exporter Award 2011 from Irish Exporters Association (IEA). Please, refer to our web site for more details regarding the award. -------- The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications at s3group.com. Thank You. Silicon and Software Systems Limited. Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18 -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Fri Mar 2 14:25:17 2012 From: simo at redhat.com (Simo Sorce) Date: Fri, 02 Mar 2012 09:25:17 -0500 Subject: [Freeipa-users] Virtualising FreeIPA domain controller In-Reply-To: <4F50B0FF.4050408@s3group.cz> References: <4F50B0FF.4050408@s3group.cz> Message-ID: <1330698317.25597.172.camel@willson.li.ssimo.org> On Fri, 2012-03-02 at 12:37 +0100, Ondrej Valousek wrote: > I just got an information that it is a very bad idea to have virtual > Domain controllers in Active Directory - server's (and potentially the > whole AD) metadata gets corrupted once you 'pause' the machine - just > to get a snapshot or backup. > > I am just wondering - there are many similarities between IPA and > Active Directory - can we be affected by this, too? > Thanks, Well I do not know about just 'pausing' it sounds not plausible to me, except wrt clock skew which may cause krb auth and replication to fail. But if you restore such a snapshot after the original machine had a fatal accident then it may come with issues. I think the issue is due to the fact that the directory service in AD is not being shut down before the snapshot. This results in you snapshotting the underlying database in a potentially unclean state. You could run in similar issues if you do this with FreeIPA and you do not ipactl stop right before taking the snapshot, the DS database will be in an open state and potentially in the middle of a transaction. Normally if you recover such backup all that should happen is that at start-up DS will act as if an unclean shutdown was performed and simply recover. However you also need to put this in the context of multi-master replication. You cannot just try to recover a replica by simply restoring days old backup. The reason is that all other replicas have recorded that they have already sent you all the data that has changed since the backup and will not attempt to bring you up to speed. So you'll have potentially stale replication agreements and also an outdated and inconsistent (wrt the rest of the domain) database. And as soon as new replication messages will come in your "restored" replica will be unable to process some of the changes because they depend on other changes that it has never seen. That all said it is easy to recover from this situation in FreeIPA, just run a force resync from an up-to-date master and the replica will be brought up to speed immediately (at least wrt the main LDAP directory, if you also have a CA clone you will need to resync that too). I think this functionality is not available in AD, which is why restoring a snapshotted image may cause issues. Also another minor issue is that you need to make sure you sync the time of your replica if the snapshot take more then a few seconds. Ntpd will not be able to adjust the clock if the time is too skewed, so you may want to force a ntpdate command right after you resume operations after the snapshot. This may not be an exhaustive list of things you need to take care of, depending on which service you run on your machine, but is all I can think of. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Fri Mar 2 14:31:52 2012 From: simo at redhat.com (Simo Sorce) Date: Fri, 02 Mar 2012 09:31:52 -0500 Subject: [Freeipa-users] IPA & hostnames. Why not use `hostname -fqdn` instead of forcing `hostname` to be fully qualified? In-Reply-To: <4F50D784.6000306@s3group.cz> References: <20120302021640.GA32745@noboost.org> <1330693840.28274.56.camel@sgallagh520.sgallagh.bos.redhat.com> <1330697491.25597.159.camel@willson.li.ssimo.org> <4F50D784.6000306@s3group.cz> Message-ID: <1330698712.25597.179.camel@willson.li.ssimo.org> On Fri, 2012-03-02 at 15:21 +0100, Ondrej Valousek wrote: > > > There are kerberized programs that expect to use gethostname() and use > > that name to compose principals. If that name is not fully qualified > > they will break. > > > > Simo. > > > Normally, you should have both: > > [root at ara tmp]# klist -k > Keytab name: FILE:/etc/krb5.keytab > KVNO Principal > ---- > -------------------------------------------------------------------------- > 19 host/ara.prague.s3group.com at DUBLIN.AD.S3GROUP.COM > 19 host/ara at DUBLIN.AD.S3GROUP.COM > > right? No, unless you can alias them in the KDC. Our KDC can technically supports aliases now, but we haven't added these kind of aliases yet to it. And it is a bit controversial on whether we want to. In A windows domain you simply cannot have client residing in a DNA domain that is not the same as the domain controller. This is a pretty hard limitation and we do not want to add it to FreeIPA. Now why does it matter in this case ? It matter because, by forcing a single DNS Domain windows can univocally say a <-> a.b.c given the b.c part is forced on all clients joined to that domain. This does not hold true for FreeIPA. You could have foo.bar.example.com and foo.rab.example.com ie 2 host with the same short name but in different subdomains. if we alias both foo's and then we try to obtain a ticket for host/foo at REALM then the KDC does not know which foo you refer to. And if we alias only one then the second foo will simply fail to use the shortname. So the solution is to always use fully qualified names, which seem a pretty decent compromise that shouldn't really cause issues in the vast majority of cases. Simo. -- Simo Sorce * Red Hat, Inc * New York From ondrejv at s3group.cz Fri Mar 2 14:39:04 2012 From: ondrejv at s3group.cz (Ondrej Valousek) Date: Fri, 02 Mar 2012 15:39:04 +0100 Subject: [Freeipa-users] Virtualising FreeIPA domain controller In-Reply-To: <1330698317.25597.172.camel@willson.li.ssimo.org> References: <4F50B0FF.4050408@s3group.cz> <1330698317.25597.172.camel@willson.li.ssimo.org> Message-ID: <4F50DB88.80504@s3group.cz> > Well I do not know about just 'pausing' it sounds not plausible to me, > except wrt clock skew which may cause krb auth and replication to fail. > Yes, that's exactly what is happening. > But if you restore such a snapshot after the original machine had a > fatal accident then it may come with issues. It is enough just to 'resume' the VM host operation (after being paused) to cause problems. > I think the issue is due to the fact that the directory service in AD is > not being shut down before the snapshot. This results in you > snapshotting the underlying database in a potentially unclean state. > You could run in similar issues if you do this with FreeIPA and you do > not ipactl stop right before taking the snapshot, the DS database will > be in an open state and potentially in the middle of a transaction. Yes, I understand the consequences and how to deal with them in the IPA environment. But for most admins it seems to me better just to generally say "never virtualize this unless you well know what you are doing", right? Ondrej Proud winners of the prestigious Irish Software Exporter Award 2011 from Irish Exporters Association (IEA). Please, refer to our web site for more details regarding the award. -------- The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications at s3group.com. Thank You. Silicon and Software Systems Limited. Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18 -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Fri Mar 2 14:50:24 2012 From: simo at redhat.com (Simo Sorce) Date: Fri, 02 Mar 2012 09:50:24 -0500 Subject: [Freeipa-users] Virtualising FreeIPA domain controller In-Reply-To: <4F50DB88.80504@s3group.cz> References: <4F50B0FF.4050408@s3group.cz> <1330698317.25597.172.camel@willson.li.ssimo.org> <4F50DB88.80504@s3group.cz> Message-ID: <1330699824.26197.3.camel@willson.li.ssimo.org> On Fri, 2012-03-02 at 15:39 +0100, Ondrej Valousek wrote: > > > Well I do not know about just 'pausing' it sounds not plausible to me, > > except wrt clock skew which may cause krb auth and replication to fail. > > > Yes, that's exactly what is happening. This should be easily fixed by making sure to bring the clock back to proper date as soon as you un-pause. > > But if you restore such a snapshot after the original machine had a > > fatal accident then it may come with issues. > It is enough just to 'resume' the VM host operation (after being > paused) to cause problems. Ok, I do not think FreeIPA has this problem then, sound something AD specific. > > I think the issue is due to the fact that the directory service in AD is > > not being shut down before the snapshot. This results in you > > snapshotting the underlying database in a potentially unclean state. > > You could run in similar issues if you do this with FreeIPA and you do > > not ipactl stop right before taking the snapshot, the DS database will > > be in an open state and potentially in the middle of a transaction. > Yes, I understand the consequences and how to deal with them in the > IPA environment. But for most admins it seems to me better just to > generally say "never virtualize this unless you well know what you are > doing", right? I do not thikn there is any problem in virtualizing IPA. Pausing the machine (except for clock skew issues that can be easily resolved) shouldn't cause too many issues. You have a small window in which replication may temporarily stop (until the clock is set back right) and clients may fail to auth (again due to clock skew) but I don't think you will see any other issue. And if you ipactl stop before pausing then set clock back straight before ipactl start after unpausing you should see no problems at all. Simo. -- Simo Sorce * Red Hat, Inc * New York From ondrejv at s3group.cz Fri Mar 2 15:10:40 2012 From: ondrejv at s3group.cz (Ondrej Valousek) Date: Fri, 02 Mar 2012 16:10:40 +0100 Subject: [Freeipa-users] IPA & hostnames. Why not use `hostname -fqdn` instead of forcing `hostname` to be fully qualified? In-Reply-To: <1330698712.25597.179.camel@willson.li.ssimo.org> References: <20120302021640.GA32745@noboost.org> <1330693840.28274.56.camel@sgallagh520.sgallagh.bos.redhat.com> <1330697491.25597.159.camel@willson.li.ssimo.org> <4F50D784.6000306@s3group.cz> <1330698712.25597.179.camel@willson.li.ssimo.org> Message-ID: <4F50E2F0.7070302@s3group.cz> > No, unless you can alias them in the KDC. > Our KDC can technically supports aliases now, but we haven't added these > kind of aliases yet to it. And it is a bit controversial on whether we > want to. > > In A windows domain you simply cannot have client residing in a DNA > domain that is not the same as the domain controller. This is a pretty > hard limitation and we do not want to add it to FreeIPA. > > Now why does it matter in this case ? > It matter because, by forcing a single DNS Domain windows can univocally > say a<-> a.b.c given the b.c part is forced on all clients joined to > that domain. > This does not hold true for FreeIPA. You could have foo.bar.example.com > and foo.rab.example.com ie 2 host with the same short name but in > different subdomains. if we alias both foo's and then we try to obtain a > ticket for host/foo at REALM then the KDC does not know which foo you refer > to. And if we alias only one then the second foo will simply fail to use > the shortname. > > So the solution is to always use fully qualified names, which seem a > pretty decent compromise that shouldn't really cause issues in the vast > majority of cases. > > Simo. > I understand now, thanks. But still I see 2 limitations in this: 1. I dare to say most people do not care that they CAN join foo.rab.example.com machine to the bar.example.com domain - to me, it is only confusing. In fact, this is a complete new information to me. I still believe we should produce at least a small warning if we find that DNS domain <> IPA domain. 2. You see problems like this - there is nowhere said that your `hostname` must be FQDN as the OS itself happily accept both. Either case, the ipa-client-install script should be able to detect such a case and offer some solution at least (I have a faint feeling there is even BZ already opened against this). Ondrej Proud winners of the prestigious Irish Software Exporter Award 2011 from Irish Exporters Association (IEA). Please, refer to our web site for more details regarding the award. -------- The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications at s3group.com. Thank You. Silicon and Software Systems Limited. Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18 -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Fri Mar 2 15:20:40 2012 From: simo at redhat.com (Simo Sorce) Date: Fri, 02 Mar 2012 10:20:40 -0500 Subject: [Freeipa-users] IPA & hostnames. Why not use `hostname -fqdn` instead of forcing `hostname` to be fully qualified? In-Reply-To: <4F50E2F0.7070302@s3group.cz> References: <20120302021640.GA32745@noboost.org> <1330693840.28274.56.camel@sgallagh520.sgallagh.bos.redhat.com> <1330697491.25597.159.camel@willson.li.ssimo.org> <4F50D784.6000306@s3group.cz> <1330698712.25597.179.camel@willson.li.ssimo.org> <4F50E2F0.7070302@s3group.cz> Message-ID: <1330701640.26197.6.camel@willson.li.ssimo.org> On Fri, 2012-03-02 at 16:10 +0100, Ondrej Valousek wrote: > > > No, unless you can alias them in the KDC. > > Our KDC can technically supports aliases now, but we haven't added these > > kind of aliases yet to it. And it is a bit controversial on whether we > > want to. > > > > In A windows domain you simply cannot have client residing in a DNA > > domain that is not the same as the domain controller. This is a pretty > > hard limitation and we do not want to add it to FreeIPA. > > > > Now why does it matter in this case ? > > It matter because, by forcing a single DNS Domain windows can univocally > > say a <-> a.b.c given the b.c part is forced on all clients joined to > > that domain. > > This does not hold true for FreeIPA. You could have foo.bar.example.com > > and foo.rab.example.com ie 2 host with the same short name but in > > different subdomains. if we alias both foo's and then we try to obtain a > > ticket for host/foo at REALM then the KDC does not know which foo you refer > > to. And if we alias only one then the second foo will simply fail to use > > the shortname. > > > > So the solution is to always use fully qualified names, which seem a > > pretty decent compromise that shouldn't really cause issues in the vast > > majority of cases. > > > > Simo. > > > I understand now, thanks. But still I see 2 limitations in this: > 1. I dare to say most people do not care that they CAN join > foo.rab.example.com machine to the bar.example.com domain - to me, it > is only confusing. In fact, this is a complete new information to me. > I still believe we should produce at least a small warning if we find > that DNS domain <> IPA domain. Well if it were a bet you'd lost it :-) We already have multiple users doing exactly that and for good reasons as far as I can tell. > 2. You see problems like this - there is nowhere said that your > `hostname` must be FQDN as the OS itself happily accept both. > Either case, the ipa-client-install script should be able to detect > such a case and offer some solution at least (I have a faint feeling > there is even BZ already opened against this). If ipa-client-install is not detecting this situation I think it is a bug. Simo. -- Simo Sorce * Red Hat, Inc * New York From ondrejv at s3group.cz Fri Mar 2 15:38:56 2012 From: ondrejv at s3group.cz (Ondrej Valousek) Date: Fri, 02 Mar 2012 16:38:56 +0100 Subject: [Freeipa-users] IPA & hostnames. Why not use `hostname -fqdn` instead of forcing `hostname` to be fully qualified? In-Reply-To: <1330701640.26197.6.camel@willson.li.ssimo.org> References: <20120302021640.GA32745@noboost.org> <1330693840.28274.56.camel@sgallagh520.sgallagh.bos.redhat.com> <1330697491.25597.159.camel@willson.li.ssimo.org> <4F50D784.6000306@s3group.cz> <1330698712.25597.179.camel@willson.li.ssimo.org> <4F50E2F0.7070302@s3group.cz> <1330701640.26197.6.camel@willson.li.ssimo.org> Message-ID: <4F50E990.3090607@s3group.cz> Ok, we have slipped away a bit. Now I agree with Craig. We should be always using 'hostname --fqdn' instead of just 'hostname'. The sssd parameter Stephen offered (ipa_hostname) seems to me bit misleading. We should probably insist that hostname --fqdn is always correct and valid. Ondrej > If ipa-client-install is not detecting this situation I think it is a > bug. > > Simo. > Proud winners of the prestigious Irish Software Exporter Award 2011 from Irish Exporters Association (IEA). Please, refer to our web site for more details regarding the award. -------- The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications at s3group.com. Thank You. Silicon and Software Systems Limited. Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgallagh at redhat.com Fri Mar 2 16:19:54 2012 From: sgallagh at redhat.com (Stephen Gallagher) Date: Fri, 02 Mar 2012 11:19:54 -0500 Subject: [Freeipa-users] SSSD (sssd_be) crashing on RHEL 6.2 In-Reply-To: <21004.213.225.75.97.1330698054.squirrel@www.nixtra.com> References: <24111.213.225.75.97.1330696358.squirrel@www.nixtra.com> <1330697055.28274.64.camel@sgallagh520.sgallagh.bos.redhat.com> <26695.213.225.75.97.1330697303.squirrel@www.nixtra.com> <1330697791.28274.67.camel@sgallagh520.sgallagh.bos.redhat.com> <21004.213.225.75.97.1330698054.squirrel@www.nixtra.com> Message-ID: <1330705194.28274.72.camel@sgallagh520.sgallagh.bos.redhat.com> On Fri, 2012-03-02 at 15:20 +0100, Sigbjorn Lie wrote: > On Fri, March 2, 2012 15:16, Stephen Gallagher wrote: > > On Fri, 2012-03-02 at 15:08 +0100, Sigbjorn Lie wrote: > > > >> On Fri, March 2, 2012 15:04, Stephen Gallagher wrote: > >> > >>> On Fri, 2012-03-02 at 14:52 +0100, Sigbjorn Lie wrote: > >>> > >>> > >>>> Hi, > >>>> > >>>> > >>>> > >>>> I'm experiencing that SSSD is now crashing at random times on _ALL_ RHEL 6.2 machines where > >>>> we have installed SSSD connected to an IPA domain. SSSD can reach up to a month of uptime > >>>> before sssd_be crashes. This happens on both physical and virtual machines. It happens at > >>>> different machines at different times, sometimes during working hours, other times during > >>>> the middle of the night. It's never happened on several machines at the same time. > >>>> > >>>> These machines does not have a GUI and the issue is similar but not directly related to the > >>>> KDE > >>>> screensaver lock as per my earlier posts. Also, the KDE screensaver issue was at RHEL 5. > >>>> > >>>> What happens is a line in the syslog about sssd_be crashing. > >>>> > >>>> > >>>> > >>>> sssd_be[1418] general protection ip:41d527 sp:7fff9e82ead0 error:0 in sssd_be[400000+4a000] > >>>> > >>>> > >>>> sssd_be is then being restarted by the parent process, but is no longer usable. Any login > >>>> via ssh to these machines will just hang. > >>>> > >>>> Has anyone else seen this issue? > >>>> > >>>> > >>> > >>> > >>> Can you try to get us a backtrace, please? "general protection" isn't > >>> enough information. Though it's interesting that it's "general protection" and not > >>> "segfault"... > >>> That's certainly new. > >>> > >>> > >>> > >>> Do you have abrtd running on these systems? If so, it should be able to > >>> capture a core dump when this happens again, which you can use to generate a backtrace for us. > >>> _______________________________________________ > >>> > >> > >> I certainly do have abrt, some of the dumps are quite large. I will send you these in a private > >> email. > >> > > > > > > Thanks, can you also let me know the exact version of SSSD that you're > > running? > > > > Sure. > > sssd-1.5.1-66.el6.x86_64 > sssd-client-1.5.1-66.el6.x86_64 I've opened https://fedorahosted.org/sssd/ticket/1226 to track the crash you're seeing. All three of the backtraces you sent me had the same information (included in the ticket; it contains no private data). This is only happening during "graceful" shutdown when sssd_be receives a SIGTERM and is cancelling all pending requests. It's possible that the actual behavior you're seeing is unrelated to this crash, though. Because a crash at shutdown (or restart) should still be properly recovering. This is a serious issue though, so let's get this out of the picture and see what else happens after that. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From orquidea.peramor at gmail.com Fri Mar 2 19:12:43 2012 From: orquidea.peramor at gmail.com (Orquidea Salt mas) Date: Fri, 2 Mar 2012 20:12:43 +0100 Subject: [Freeipa-users] =?iso-8859-1?q?Reb=E9late_by_self-management=2C_f?= =?iso-8859-1?q?irst_project_of_free_software_by_which_we_bet_all_/?= =?iso-8859-1?q?_Reb=E9late_por_la_autogesti=F3n=2C_primer_proyecto?= =?iso-8859-1?q?_de_software_libre_por_el_que_apostamos_todas?= Message-ID: Ingl?s : Many already we have contributed to the first project of free software dedicated to self-management in this campaign of collective financing, it collaborates and it spreads!/ Beginning campaign collective financing http://www.goteo.org/project/rebelaos-publicacion-por-la-autogestion?lang=en Login to enter with user of social networks and for would register in Goteo : http://www.goteo.org/user/login?lang=en Rebelaos! Publication by self-management A massive publication that floods the public transport, the work centers, the parks, the consumption centers, by means of distribution of 500,000 gratuitous units, acting simultaneously in all sides and nowhere. We announce the main tool of a vestibule Web for the management of self-sustaining resources by means of Drupal, in addition in the publication there will be an article dedicated to free software, hardware, It is being prepared in ingl?s, the machinery You can see more details in the index of the publication https://n-1.cc/pg/file/read/1151902/indexresumen-de-los-contenidos-pdf . A computer system that allows us to share resources in all the scopes of our life so that we do not have to generate means different for each subject nor for each territory. A point of contact digitalis to generate projects of life outside Capitalism and to margin of the State. A tool to spread and to impel the social transformation through the resources that will set out in their contents around self-management, the autoorganizaci?n, the disobedience and the collective action. In which the capitalist system goes to the collapse, in a while immersed in a deep systemic crisis (ecological, political and economic, but mainly of values), where individual and collective of people they are being lacking of his fundamental rights, is necessary to develop a horizontal collective process where all the human beings we pruned to interact in equality of conditions and freedom. To interact means to relate to us (as much human as economically), to communicate to us, to cover our basic needs, to generate and to protect communal properties, to know and to provide collective solutions us problematic that our lives interfere. We want abrir a breach within normality in the monotonous life state-capitalist, a day anyone, that finally will not be any day. By means of this publication we try: - To drive a horizontal collective process where all and all we pruned to interact in equality of conditions and freedom. - To create communications network between the people it jeopardize with the change and arranged to act. - To find collective solutions to problematic that our lives interfere - To facilitate the access to resources that make possible self-management. - To participate in the construction of networks of mutual support, generated horizontals, asamblearias and from the base. - To publish all this information in an attractive format stops to facilitate the access to all the society. There are 15 days remaining for the upcoming March 15, the day that will come Rebelaos!, Magazine for the selfmanagement Today, we issue the cover of Rebelaos! (Castilian version) that can be displayed on the following link: https://n-1.cc/pg/file/read/1200503/portada-15-de-marzo-rebelaos The contents of the store owners to us by 15 March. Do you? Do you keep on 15 March? In addition, we have over 200 distribution nodes, distributed throughout the Spanish state. Check the map: https://afinidadrebelde.crowdmap.com/ On the other hand, the funding campaign continues to move and still have 12 days to collect the remaining 6,000 euros. We can all make a bit for all the grains of sand become a great beach on March 15. You can access the co-financing campaign: http://www.goteo.org/project/rebelaos-publicacion-por-la-autogestion Rebel Affinity group www.rebelaos.net ------------------------------------------------------------------------------- Castellano: Muchos ya hemos aportado al primer proyecto de software libre dedicado a la la financiaci?n colectiva, colabora y diffunde !!!!! Inicio campa?a financiaci?n colectiva goteo.org www.goteo.org/project/rebelaos-publicacion-por-la-autogestion Link para registrarse en Goteo y acceder a redes sociales para colaborar en la difus?n http://www.goteo.org/user/login ?Rebelaos! Publicaci?n por la autogesti?n Una publicaci?n masiva que inunde el transporte p?blico, los centros de trabajo, los parques, los centros de consumo, mediante la distribuci?n de 500.000 ejemplares gratuitos, actuando simult?neamente en todos lados y en ninguna parte. Anunciamos la herramienta principal de un portal web para la gesti?n de recursos autogestionados mediante Drupal, adem?s en la publicaci?n habr? un art?culo dedicado al software libre, el hardware, la maquinaria... Puedes ver m?s detalles en el ?ndice de la publicaci?n https://n-1.cc/pg/file/read/1151902/indexresumen-de-los-contenidos-pdf Un sistema inf?rmatico que nos permita compartir recursos en todos los ?mbitos de nuestra vida de forma que no tengamos que generar un medio distinto para cada tema ni para cada territorio. Un punto de encuentro digital para generar proyectos de vida fuera del capitalismo y al margen del Estado. Una herramienta para difundir e impulsar la transformaci?n social a trav?s de los recursos que se propondr?n en sus contenidos en torno a la autogesti?n, la autoorganizaci?n, la desobediencia y la acci?n colectiva. En un momento en que el sistema capitalista se dirige al colapso, inmerso en una profunda crisis sist?mica (ecol?gica, pol?tica y econ?mica, pero principalmente de valores), donde individuos y colectivos de personas est?n siendo desprovistos de sus derechos fundamentales, es necesario desarrollar un proceso colectivo horizontal donde todos los seres humanos podamos interactuar en igualdad de condiciones y en libertad. Interactuar significa relacionarnos (tanto humana como econ?micamente), comunicarnos, cubrir nuestras necesidades b?sicas, generar y proteger bienes comunes, conocernos y dar soluciones colectivas a problem?ticas que interfieren nuestras vidas. Queremos abrir una brecha dentro de la normalidad en la mon?tona vida estatal-capitalista, un d?a cualquiera, que finalmente no ser? cualquier d?a. Mediante esta publicaci?n pretendemos: - Impulsar un proceso colectivo horizontal donde todos y todas podamos interactuar en igualdad de condiciones y en libertad. - Crear red de comunicaciones entre las personas comprometidas con el cambio y dispuestas a actuar. - Encontrar soluciones colectivas a problem?ticas que interfieren nuestras vidas. - Facilitar el acceso a recursos que posibiliten la autogesti?n. - Participar en la construcci?n de redes de apoyo mutuo, horizontales, asamblearias y generadas desde la base. - Publicar toda esta informaci?n en un formato atractivo para facilitar el acceso a toda la sociedad. Son 15 los d?as que restan para el pr?ximo 15 de marzo, d?a en el que ver? la luz ?Rebelaos!, publicaci?n por la autogesti?n. Hoy, hacemos p?blica la portada de ?Rebelaos! (versi?n en castellano) que pod?is visualizar en el siguiente enlace: https://n-1.cc/pg/file/read/1200503/portada-15-de-marzo-rebelaos El contenido de los titulares nos los guardamos para el 15 de marzo. ?Y t?? ?Te guardas el 15 de marzo? Adem?s, ya hemos superado los 200 nodos de distribuci?n, repartidos por todo el estado espa?ol. Ver el mapa: https://afinidadrebelde.crowdmap.com/ Por otro lado, la campa?a de financiaci?n contin?a avanzando y todav?a quedan 12 d?as para reunir los 6.000 euros que restan. Todas podemos aportar un poco para que todos los granitos de arena se conviertan en una gran playa el 15 de marzo. Pod?is acceder a la campa?a de cofinanciaci?n en: http://www.goteo.org/project/rebelaos-publicacion-por-la-autogestion Colectivo Afinidad Rebelde www.rebelaos.net From chorn at fluxcoil.net Sat Mar 3 10:56:55 2012 From: chorn at fluxcoil.net (Christian Horn) Date: Sat, 3 Mar 2012 11:56:55 +0100 Subject: [Freeipa-users] IPA, samba, and secondary groups In-Reply-To: References: Message-ID: <20120303105655.GA18164@fluxcoil.net> Hi, On Wed, Feb 29, 2012 at 11:24:25AM -0500, Kelvin Edmison wrote: > > I am running into an issue where users cannot access a samba volume if > their only access is via a secondary group. For example, if testuser's > primary group is ipausers, and secondary groups include testgroup, and the > samba mount permissions are adminuser:testgroup:rwxrwx---, then testuser > cannot read or write to the samba mount. If the testuser is change so that > its primary group is testgroup, then testuser can access the volume. > > In this case, samba is running on a separate CentOS 5 server, configured to > access IPA via LDAP. It is a requirement that I support > userid/password-based access to the samba server, as I cannot roll all my > users onto kerberos right away. > > Doe anyone have any insight as to what is going on and how it can be fixed? I did see something similiar recently, the ldapsam backend in samba was used. You might want to try out 'ldapsam:trusted = no' in smb.conf . Christian From dpal at redhat.com Sat Mar 3 23:09:26 2012 From: dpal at redhat.com (Dmitri Pal) Date: Sat, 03 Mar 2012 18:09:26 -0500 Subject: [Freeipa-users] Can FreeIPA use FreeRADIUS as users provider In-Reply-To: <20120301142142.GB15020@work.zhukoff.net> References: <20120301123557.GA15020@work.zhukoff.net> <1330611101.25597.149.camel@willson.li.ssimo.org> <20120301142142.GB15020@work.zhukoff.net> Message-ID: <4F52A4A6.4020405@redhat.com> On 03/01/2012 09:21 AM, Pavel Zhukov wrote: > Simo, thank you for your answer > FreeRADIUS uses very customized (for complex network ACLs) MySQL schema and network team > manages it. Unfortunately, I cannot change FreeRADIUS related > infrastructure. > AuthHub is your friend then. https://fedorahosted.org/AuthHub/ I am CC Nathaniel who is the developer on this project. I know he is looking into RADIUS integration. Any help would be appreciated. -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Sat Mar 3 23:18:06 2012 From: dpal at redhat.com (Dmitri Pal) Date: Sat, 03 Mar 2012 18:18:06 -0500 Subject: [Freeipa-users] IPA & hostnames. Why not use `hostname -fqdn` instead of forcing `hostname` to be fully qualified? In-Reply-To: <4F50E990.3090607@s3group.cz> References: <20120302021640.GA32745@noboost.org> <1330693840.28274.56.camel@sgallagh520.sgallagh.bos.redhat.com> <1330697491.25597.159.camel@willson.li.ssimo.org> <4F50D784.6000306@s3group.cz> <1330698712.25597.179.camel@willson.li.ssimo.org> <4F50E2F0.7070302@s3group.cz> <1330701640.26197.6.camel@willson.li.ssimo.org> <4F50E990.3090607@s3group.cz> Message-ID: <4F52A6AE.1010606@redhat.com> On 03/02/2012 10:38 AM, Ondrej Valousek wrote: > Ok, we have slipped away a bit. Now I agree with Craig. > We should be always using 'hostname --fqdn' instead of just 'hostname'. > > The sssd parameter Stephen offered (ipa_hostname) seems to me bit > misleading. We should probably insist that hostname --fqdn is always > correct and valid. > Ondrej > >> If ipa-client-install is not detecting this situation I think it is a >> bug. >> >> Simo. >> Have we opened a bug? > > ------------------------------------------------------------------------ > Proud winners of the prestigious Irish Software Exporter Award 2011 > from Irish Exporters Association (IEA). Please, refer to our web site > for more details regarding the award. > ------------------------------------------------------------------------ > The information contained in this e-mail and in any attachments is > confidential and is designated solely for the attention of the > intended recipient(s). If you are not an intended recipient, you must > not use, disclose, copy, distribute or retain this e-mail or any part > thereof. If you have received this e-mail in error, please notify the > sender by return e-mail and delete all copies of this e-mail from your > computer system(s). Please direct any additional queries to: > communications at s3group.com. Thank You. Silicon and Software Systems > Limited. Registered in Ireland no. 378073. Registered Office: South > County Business Park, Leopardstown, Dublin 18 > ------------------------------------------------------------------------ > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, 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 Mon Mar 5 14:52:19 2012 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 05 Mar 2012 09:52:19 -0500 Subject: [Freeipa-users] Can FreeIPA use FreeRADIUS as users provider In-Reply-To: <4F52A4A6.4020405@redhat.com> References: <20120301123557.GA15020@work.zhukoff.net> <1330611101.25597.149.camel@willson.li.ssimo.org> <20120301142142.GB15020@work.zhukoff.net> <4F52A4A6.4020405@redhat.com> Message-ID: <1330959139.17348.2.camel@diogenes.lan> On Sat, 2012-03-03 at 18:09 -0500, Dmitri Pal wrote: > On 03/01/2012 09:21 AM, Pavel Zhukov wrote: > > Simo, thank you for your answer > > FreeRADIUS uses very customized (for complex network ACLs) MySQL schema and network team > > manages it. Unfortunately, I cannot change FreeRADIUS related > > infrastructure. > > > AuthHub is your friend then. > https://fedorahosted.org/AuthHub/ > > I am CC Nathaniel who is the developer on this project. I know he is > looking into RADIUS integration. Any help would be appreciated. So the answer is that AuthHub will support RADIUS very soon (it is currently our highest priority). This means that krb5 >= 1.10 + AuthHub will soon support RADIUS. When this support will hit FreeIPA directly, I'm not sure. But we can definitely use as much help testing AuthHub as possible. Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From sigbjorn at nixtra.com Mon Mar 5 21:28:37 2012 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Mon, 05 Mar 2012 22:28:37 +0100 Subject: [Freeipa-users] SSSD (sssd_be) crashing on RHEL 6.2 In-Reply-To: <1330705194.28274.72.camel@sgallagh520.sgallagh.bos.redhat.com> References: <24111.213.225.75.97.1330696358.squirrel@www.nixtra.com> <1330697055.28274.64.camel@sgallagh520.sgallagh.bos.redhat.com> <26695.213.225.75.97.1330697303.squirrel@www.nixtra.com> <1330697791.28274.67.camel@sgallagh520.sgallagh.bos.redhat.com> <21004.213.225.75.97.1330698054.squirrel@www.nixtra.com> <1330705194.28274.72.camel@sgallagh520.sgallagh.bos.redhat.com> Message-ID: <4F553005.9000404@nixtra.com> On 03/02/2012 05:19 PM, Stephen Gallagher wrote: > On Fri, 2012-03-02 at 15:20 +0100, Sigbjorn Lie wrote: >> On Fri, March 2, 2012 15:16, Stephen Gallagher wrote: >>> On Fri, 2012-03-02 at 15:08 +0100, Sigbjorn Lie wrote: >>> >>>> On Fri, March 2, 2012 15:04, Stephen Gallagher wrote: >>>> >>>>> On Fri, 2012-03-02 at 14:52 +0100, Sigbjorn Lie wrote: >>>>> >>>>> >>>>>> Hi, >>>>>> >>>>>> >>>>>> >>>>>> I'm experiencing that SSSD is now crashing at random times on _ALL_ RHEL 6.2 machines where >>>>>> we have installed SSSD connected to an IPA domain. SSSD can reach up to a month of uptime >>>>>> before sssd_be crashes. This happens on both physical and virtual machines. It happens at >>>>>> different machines at different times, sometimes during working hours, other times during >>>>>> the middle of the night. It's never happened on several machines at the same time. >>>>>> >>>>>> These machines does not have a GUI and the issue is similar but not directly related to the >>>>>> KDE >>>>>> screensaver lock as per my earlier posts. Also, the KDE screensaver issue was at RHEL 5. >>>>>> >>>>>> What happens is a line in the syslog about sssd_be crashing. >>>>>> >>>>>> >>>>>> >>>>>> sssd_be[1418] general protection ip:41d527 sp:7fff9e82ead0 error:0 in sssd_be[400000+4a000] >>>>>> >>>>>> >>>>>> sssd_be is then being restarted by the parent process, but is no longer usable. Any login >>>>>> via ssh to these machines will just hang. >>>>>> >>>>>> Has anyone else seen this issue? >>>>>> >>>>>> >>>>> >>>>> Can you try to get us a backtrace, please? "general protection" isn't >>>>> enough information. Though it's interesting that it's "general protection" and not >>>>> "segfault"... >>>>> That's certainly new. >>>>> >>>>> >>>>> >>>>> Do you have abrtd running on these systems? If so, it should be able to >>>>> capture a core dump when this happens again, which you can use to generate a backtrace for us. >>>>> _______________________________________________ >>>>> >>>> I certainly do have abrt, some of the dumps are quite large. I will send you these in a private >>>> email. >>>> >>> >>> Thanks, can you also let me know the exact version of SSSD that you're >>> running? >>> >> Sure. >> >> sssd-1.5.1-66.el6.x86_64 >> sssd-client-1.5.1-66.el6.x86_64 > I've opened https://fedorahosted.org/sssd/ticket/1226 to track the crash > you're seeing. All three of the backtraces you sent me had the same > information (included in the ticket; it contains no private data). > > This is only happening during "graceful" shutdown when sssd_be receives > a SIGTERM and is cancelling all pending requests. It's possible that the > actual behavior you're seeing is unrelated to this crash, though. > Because a crash at shutdown (or restart) should still be properly > recovering. > > This is a serious issue though, so let's get this out of the picture and > see what else happens after that. Thanks. I see from the bugzilla ticket that you have not been able to re-produce the issue. I would like to mention that one thing these machines share in common that's using sssd, is that we utilize Nagios for monitoring where a monitoring user is logging in using ssh to check various services. There are approx 20 services being checked every 5 minutes, approx 240 logins per hour. We also use HBAC rules for access control. And we have "options rotate", and "options timeout:4" set in resolv.conf on our clients. We also have a modified krb5.conf file having multiple kerberos realms, enabling dns kdc lookups, and disabling dns realm lookups. Not that I see how anything of that could be related, but that is what I can think of that's been modified after a stock ipa-client-install. Regards, Siggi From rcritten at redhat.com Mon Mar 5 22:28:12 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 05 Mar 2012 17:28:12 -0500 Subject: [Freeipa-users] Announcing FreeIPA v2.1.90 beta 1 Release Message-ID: <4F553DFC.7060302@redhat.com> The FreeIPA team is proud to announce version 2.1.90 beta 1. This will eventually become FreeIPA v2.2.0. It can be downloaded from http://www.freeipa.org/Downloads or from our development repo (http://freeipa.org/downloads/freeipa-devel.repo). Fedora 16 and 17 builds are available. Builds for Fedora 15 are no longer being provided. Packages that FreeIPA requires are not available in Fedora 15. == Highlights in 2.1.90 beta 1 == * Forms-based login. If Kerberos negotiate authentication fails you have the option of logging in using a form using username and password. Or you can go directly to /ipa/ui/login.html if you do not have/cannot get a Kerberos ticket. This is the preferred alternative login mechanism over enabling KrbMethodK5Passwd. * Logout from the UI * Support for SSH known-hosts with sssd 1.8.0. This will create a known-hosts file dynamically based on information stored in IPA. * DNS forwarders now configurable via IPA * Configurable by DNS zone: query policy, transfer policy, forward policy and forward and reverse synchronization. * More consistent hostname validation * Recommendation that the compat plugin be disabled during migration (unnecessary overhead) * On new installations the default users group, ipausers, is now non-POSIX == Upgrading == We tested upgrades from 2.1.4 successfully but this is beta code. We do not recommend upgrading a production server. Installing updated rpms is all that is required to upgrade from 2.1.4. It is unlikely that downgrading to a previous release once 2.1.90 is installed will work. Upgrading directly from the alpha may work but is untested. == Feedback == Please provide comments, bugs and other feedback via the freeipa-devel mailing list: http://www.redhat.com/mailman/listinfo/freeipa-devel == Detailed Changelog since 2.1.90 beta 1 == Jan Cholasta (1): * Configure SSH features of SSSD in ipa-client-install. John Dennis (8): * update translation pot file and PY_EXPLICIT_FILES list * update po files * created Transifex resource, adjust tx config file to point to it. * Tweak the session auth to reflect developer consensus. * Implement session activity timeout * Implement password based session login * Log a message when returning non-success HTTP result Martin Kosek (21): * Ease zonemgr restrictions * Update schema for bind-dyndb-ldap * Global DNS options * Query and transfer ACLs for DNS zones * Add DNS conditional forwarding * Add API for PTR sync control * Add gidnumber minvalue * Add reverse DNS record when forward is created * Sanitize UDP checks in conncheck * Add client hostname requirements to man page * Add SSHFP update policy for existing zones * Improve dns error message * Improve dnsrecord-add interactive mode * Improve hostname and domain name validation * Improve FQDN handling in DNS and host plugins * Improve hostname verification in install tools * Fix typos in ipa-replica-manage man page * Remove memberPrincipal for deleted replicas * Fix encoding for setattr/addattr/delattr * Add help for new structured DNS framework * Improve dnsrecord interactive help Ondrej Hamada (3): * Validate attributes in permission-add * Migration warning when compat enabled * ipa-client-install not calling authconfig Petr Viktorin (6): * Make ipausers a non-posix group on new installs * Add extra checking function to XMLRPC test framework * Add common helper for interactive prompts * Make sure the nolog argument to ipautil.run is not a bare string * Use stricter semantics when checking IP address for DNS records * Use stricter semantics when checking IP address for DNS records * Use reboot from /sbin Petr Voborn?k (18): * Fixed content type check in login_password * Improved usability of login dialog * Removed CSV creation from UI * Fixed problem when attributes_widget was displaying empty option * Added missing configuration options * Static metadata update - new DNS options * New checkboxes option: Mutual exclusive * DNS Zone UI: added new attributes * DNS UI: added A,AAAA create reverse options to adder dialog * Fixed displaying of A6 Record * New UI for DNS global configuration * Multiple fields for one attribute * Added attrs to permission when target is group or filter * Moved is_empty method from field to IPA object * Making validators to return true result if empty * Fixed DNS record add handling of 4304 error * Added unsupported_validator * Fixed redirection in Add and edit in automember hostgroup. * Fixed selection of single value in combobox * Added logout button * Forms based authentication UI Rob Crittenden (37): * Limit the change password permission so it can't change admin passwords * Don't allow "Modify Group membership" permission to manage admins * Add the -v option to sslget to provide more verbose errors * Make sure memberof is in replication attribute exclusion list. * Don't check for schema uniqueness when comparing in ldapupdate. * Add Conflicts on mod_ssl because it interferes with mod_proxy and dogtag * Don't allow IPA master hosts or important services be deleted. * Catch public exceptions when creating the LDAP context in WSGI. * Don't consider virtual attributes when validating custom objectclasses * Add Requires to ipa-client on oddjob-mkhomedir * Fix managing winsync replication agreements with ipa-replica-manage * Check for duplicate winsync agreement before trying to set one up. * Remove unused kpasswd.keytab and ldappwd files if they exist. * Make sure 389-ds is running when adding memcache service in upgrade. * Don't run restorecon if SELinux is disabled or not present. * Limit allowed characters in a netgroup name to alpha, digit, -, _ and . * Don't call memberof task when re-initializing a replica. * Fix bad merge of not calling memberof task when re-initializing a replica * Add support defaultNamingContext and add --basedn to migrate-ds * Fix nested netgroups in NIS. * Warn that deleting replica is irreversible, try to detect reconnection. * Don't set migrated user's GID to that of default users group. * Don't delete system users that are added during installation. * Only apply validation rules when adding and updating. * subclass HTTP_Status from plugable.Plugin, fix not_found tests * Make hostnames adhere to new standards in HBAC tests * Fix WSGI error handling * Add status command to retrieve user lockout status * Add support for sudoOrder * Make hostnames adhere to new standards in hbactest plugin tests * Fix API.txt and VERSION to reflect new sudoOrder option. * Add --noac option to ipa-client-install man page * Do kinit in client before connecting to backend * Only warn if ipa-getkeytab doesn't get all requested enctypes. * Fix NSS no_init in the NSSHTTPS class Simo Sorce (4): * ipa-kdb: Fix ACL evaluator * policy: add function to check lockout policy * ipa-kdb: fix delegation acl check * Fix ticket checks when using either s4u2proxy or a delegated krbtgt From kelvin at kindsight.net Tue Mar 6 03:12:14 2012 From: kelvin at kindsight.net (Kelvin Edmison) Date: Mon, 05 Mar 2012 22:12:14 -0500 Subject: [Freeipa-users] IPA, samba, and secondary groups In-Reply-To: <20120303105655.GA18164@fluxcoil.net> Message-ID: On 12-03-03 5:56 AM, "Christian Horn" wrote: > Hi, > > On Wed, Feb 29, 2012 at 11:24:25AM -0500, Kelvin Edmison wrote: >> >> I am running into an issue where users cannot access a samba volume if >> their only access is via a secondary group. For example, if testuser's >> primary group is ipausers, and secondary groups include testgroup, and the >> samba mount permissions are adminuser:testgroup:rwxrwx---, then testuser >> cannot read or write to the samba mount. If the testuser is change so that >> its primary group is testgroup, then testuser can access the volume. >> >> In this case, samba is running on a separate CentOS 5 server, configured to >> access IPA via LDAP. It is a requirement that I support >> userid/password-based access to the samba server, as I cannot roll all my >> users onto kerberos right away. >> >> Doe anyone have any insight as to what is going on and how it can be fixed? > > I did see something similiar recently, the ldapsam backend in samba was > used. > You might want to try out 'ldapsam:trusted = no' in smb.conf . That was it exactly. Many thanks for the pointer! Kelvin From dpal at redhat.com Wed Mar 7 17:32:18 2012 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 07 Mar 2012 12:32:18 -0500 Subject: [Freeipa-users] Announcing FreeIPA v2.1.90 beta 1 Release In-Reply-To: <4F553DFC.7060302@redhat.com> References: <4F553DFC.7060302@redhat.com> Message-ID: <4F579BA2.8020704@redhat.com> On 03/05/2012 05:28 PM, Rob Crittenden wrote: > The FreeIPA team is proud to announce version 2.1.90 beta 1. This will > eventually become FreeIPA v2.2.0. > > It can be downloaded from http://www.freeipa.org/Downloads or from our > development repo (http://freeipa.org/downloads/freeipa-devel.repo). > Fedora 16 and 17 builds are available. > It is actually http://www.freeipa.org/page/Downloads. > Builds for Fedora 15 are no longer being provided. Packages that > FreeIPA requires are not available in Fedora 15. > > == Highlights in 2.1.90 beta 1 == > > * Forms-based login. If Kerberos negotiate authentication fails you > have the option of logging in using a form using username and > password. Or you can go directly to /ipa/ui/login.html if you do not > have/cannot get a Kerberos ticket. This is the preferred alternative > login mechanism over enabling KrbMethodK5Passwd. > * Logout from the UI > * Support for SSH known-hosts with sssd 1.8.0. This will create a > known-hosts file dynamically based on information stored in IPA. > * DNS forwarders now configurable via IPA > * Configurable by DNS zone: query policy, transfer policy, forward > policy and forward and reverse synchronization. > * More consistent hostname validation > * Recommendation that the compat plugin be disabled during migration > (unnecessary overhead) > * On new installations the default users group, ipausers, is now > non-POSIX > > == Upgrading == > > We tested upgrades from 2.1.4 successfully but this is beta code. We > do not recommend upgrading a production server. > > Installing updated rpms is all that is required to upgrade from 2.1.4. > > It is unlikely that downgrading to a previous release once 2.1.90 is > installed will work. > > Upgrading directly from the alpha may work but is untested. > > == Feedback == > > Please provide comments, bugs and other feedback via the freeipa-devel > mailing list: http://www.redhat.com/mailman/listinfo/freeipa-devel > > == Detailed Changelog since 2.1.90 beta 1 == > > Jan Cholasta (1): > * Configure SSH features of SSSD in ipa-client-install. > > John Dennis (8): > * update translation pot file and PY_EXPLICIT_FILES list > * update po files > * created Transifex resource, adjust tx config file to point to it. > * Tweak the session auth to reflect developer consensus. > * Implement session activity timeout > * Implement password based session login > * Log a message when returning non-success HTTP result > > Martin Kosek (21): > * Ease zonemgr restrictions > * Update schema for bind-dyndb-ldap > * Global DNS options > * Query and transfer ACLs for DNS zones > * Add DNS conditional forwarding > * Add API for PTR sync control > * Add gidnumber minvalue > * Add reverse DNS record when forward is created > * Sanitize UDP checks in conncheck > * Add client hostname requirements to man page > * Add SSHFP update policy for existing zones > * Improve dns error message > * Improve dnsrecord-add interactive mode > * Improve hostname and domain name validation > * Improve FQDN handling in DNS and host plugins > * Improve hostname verification in install tools > * Fix typos in ipa-replica-manage man page > * Remove memberPrincipal for deleted replicas > * Fix encoding for setattr/addattr/delattr > * Add help for new structured DNS framework > * Improve dnsrecord interactive help > > Ondrej Hamada (3): > * Validate attributes in permission-add > * Migration warning when compat enabled > * ipa-client-install not calling authconfig > > Petr Viktorin (6): > * Make ipausers a non-posix group on new installs > * Add extra checking function to XMLRPC test framework > * Add common helper for interactive prompts > * Make sure the nolog argument to ipautil.run is not a bare string > * Use stricter semantics when checking IP address for DNS records > * Use stricter semantics when checking IP address for DNS records > * Use reboot from /sbin > > Petr Voborn?k (18): > * Fixed content type check in login_password > * Improved usability of login dialog > * Removed CSV creation from UI > * Fixed problem when attributes_widget was displaying empty option > * Added missing configuration options > * Static metadata update - new DNS options > * New checkboxes option: Mutual exclusive > * DNS Zone UI: added new attributes > * DNS UI: added A,AAAA create reverse options to adder dialog > * Fixed displaying of A6 Record > * New UI for DNS global configuration > * Multiple fields for one attribute > * Added attrs to permission when target is group or filter > * Moved is_empty method from field to IPA object > * Making validators to return true result if empty > * Fixed DNS record add handling of 4304 error > * Added unsupported_validator > * Fixed redirection in Add and edit in automember hostgroup. > * Fixed selection of single value in combobox > * Added logout button > * Forms based authentication UI > > Rob Crittenden (37): > * Limit the change password permission so it can't change admin > passwords > * Don't allow "Modify Group membership" permission to manage admins > * Add the -v option to sslget to provide more verbose errors > * Make sure memberof is in replication attribute exclusion list. > * Don't check for schema uniqueness when comparing in ldapupdate. > * Add Conflicts on mod_ssl because it interferes with mod_proxy and > dogtag > * Don't allow IPA master hosts or important services be deleted. > * Catch public exceptions when creating the LDAP context in WSGI. > * Don't consider virtual attributes when validating custom objectclasses > * Add Requires to ipa-client on oddjob-mkhomedir > * Fix managing winsync replication agreements with ipa-replica-manage > * Check for duplicate winsync agreement before trying to set one up. > * Remove unused kpasswd.keytab and ldappwd files if they exist. > * Make sure 389-ds is running when adding memcache service in upgrade. > * Don't run restorecon if SELinux is disabled or not present. > * Limit allowed characters in a netgroup name to alpha, digit, -, _ > and . > * Don't call memberof task when re-initializing a replica. > * Fix bad merge of not calling memberof task when re-initializing a > replica > * Add support defaultNamingContext and add --basedn to migrate-ds > * Fix nested netgroups in NIS. > * Warn that deleting replica is irreversible, try to detect > reconnection. > * Don't set migrated user's GID to that of default users group. > * Don't delete system users that are added during installation. > * Only apply validation rules when adding and updating. > * subclass HTTP_Status from plugable.Plugin, fix not_found tests > * Make hostnames adhere to new standards in HBAC tests > * Fix WSGI error handling > * Add status command to retrieve user lockout status > * Add support for sudoOrder > * Make hostnames adhere to new standards in hbactest plugin tests > * Fix API.txt and VERSION to reflect new sudoOrder option. > * Add --noac option to ipa-client-install man page > * Do kinit in client before connecting to backend > * Only warn if ipa-getkeytab doesn't get all requested enctypes. > * Fix NSS no_init in the NSSHTTPS class > > Simo Sorce (4): > * ipa-kdb: Fix ACL evaluator > * policy: add function to check lockout policy > * ipa-kdb: fix delegation acl check > * Fix ticket checks when using either s4u2proxy or a delegated krbtgt > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From sylvainangers at gmail.com Wed Mar 7 18:38:34 2012 From: sylvainangers at gmail.com (Sylvain Angers) Date: Wed, 7 Mar 2012 13:38:34 -0500 Subject: [Freeipa-users] need info on AD / IPA coexistence In-Reply-To: <1330058876.18690.117.camel@willson.li.ssimo.org> References: <74B15185-79AA-40FB-80D2-87E737E2D840@redhat.com> <833D8E48405E064EBC54C84EC6B36E404CBBF614@STAWINCOX10MBX1.staff.vuw.ac.nz> <1330058876.18690.117.camel@willson.li.ssimo.org> Message-ID: 2012/2/23 Simo Sorce > On Thu, 2012-02-23 at 21:12 -0500, Brian Cook wrote: > > I would not expect that there would be any problem with AD and IPA > > coexisting when the realm names are different, but I have heard > > reports that there are problems, especially when Linux clients are > > configured to use AD for DNS. Trying to figure out what the problem > > is. I understand your delegated dns setup. What if the customer must > > use AD for all DNS? > > The only "problem" you may have is that you have to manually set all the > SRV and TXT records. > It's tedious but nothing heart breaking. > > Clients will not be able to do DNS updates if the DNS is not managed by > IPA. > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > Hello All, We are facing the same difficulties here with coexistence with Microsoft AD on the same network Whenever I run ipa-client-install # ipa-client-install --server=server.abcd.ca --domain=abcd.ca --realm=UNIX DNS domain 'unix' is not configured for automatic KDC address lookup. KDC address will be set to fixed value. Discovery was successful! Hostname: client.abcd.ca Realm: UNIX DNS Domain: abcd.ca IPA Server: server.abcd.ca BaseDN: dc=unix Continue to configure the system with these values? [no]: yes User authorized to enroll computers: admin Synchronizing time with KDC... Password for admin at UNIX: Enrolled in IPA realm UNIX Created /etc/ipa/default.conf Configured /etc/sssd/sssd.conf Configured /etc/krb5.conf for IPA realm UNIX SSSD enabled *Unable to find 'admin' user with 'getent passwd admin'!* Recognized configuration: SSSD NTP enabled Client configuration complete. and when I sniff via wireshark while doing getent passwd admin, I get many time this snipet, with all the Microsoft AD server in the loop 165.115.52.21 = our windows dns server 165.115.40.149 = our ipa client 165.115.40.144 165.115.126.210 = windows AD domain controller 165.115.212.167 = windows AD domain controller 31.784008 165.115.52.21 -> 165.115.40.149 DNS Standard query response A 165.115.52.21 31.784308 165.115.40.149 -> 165.115.52.21 TCP 37236 > ldap [SYN] Seq=0 Win=14600 Len=0 MSS=1460 TSV=5217133 TSER=0 WS=7 31.784518 165.115.52.21 -> 165.115.40.149 TCP ldap > 37236 [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1460 WS=0 TSV=0 TSER=0 31.784538 165.115.40.149 -> 165.115.52.21 TCP 37236 > ldap [ACK] Seq=1 Ack=1 Win=14720 Len=0 TSV=5217133 TSER=0 31.784873 165.115.40.149 -> 165.115.52.21 LDAP searchRequest(1) "" baseObject 31.785487 165.115.52.21 -> 165.115.40.149 TCP [TCP segment of a reassembled PDU] 31.785505 165.115.40.149 -> 165.115.52.21 TCP 37236 > ldap [ACK] Seq=229 Ack=1449 Win=17536 Len=0 TSV=5217134 TSER=13371643 31.785522 165.115.52.21 -> 165.115.40.149 LDAP searchResEntry(1) "" 31.785531 165.115.40.149 -> 165.115.52.21 TCP 37236 > ldap [ACK] Seq=229 Ack=2314 Win=20480 Len=0 TSV=5217134 TSER=13371643 31.786016 165.115.40.149 -> 165.115.52.21 DNS Standard query A jac-rg-i01.cn.ca 31.786301 165.115.52.21 -> 165.115.40.149 DNS Standard query response A 165.115.126.210 31.790918 165.115.40.149 -> 165.115.126.210 KRB5 AS-REQ 31.826597 165.115.126.210 -> 165.115.40.149 KRB5 KRB Error: KRB5KDC_ERR_C_PRINCIPAL_UNKNOWN 31.827485 165.115.40.149 -> 165.115.52.21 LDAP unbindRequest(2) 31.827518 165.115.40.149 -> 165.115.52.21 TCP 37236 > ldap [FIN, ACK] Seq=236 Ack=2314 Win=20480 Len=0 TSV=5217176 TSER=13371643 31.827763 165.115.52.21 -> 165.115.40.149 TCP ldap > 37236 [ACK] Seq=2314 Ack=237 Win=65300 Len=0 TSV=13371643 TSER=5217176 31.827786 165.115.52.21 -> 165.115.40.149 TCP ldap > 37236 [FIN, ACK] Seq=2314 Ack=237 Win=65300 Len=0 TSV=13371643 TSER=5217176 31.827795 165.115.40.149 -> 165.115.52.21 TCP 37236 > ldap [ACK] Seq=237 Ack=2315 Win=20480 Len=0 TSV=5217177 TSER=13371643 31.827856 165.115.40.149 -> 165.115.52.21 DNS Standard query A gnp-yd-i01.cn.ca 31.828112 165.115.52.21 -> 165.115.40.149 DNS Standard query response A 165.115.207.219 31.828393 165.115.40.149 -> 165.115.207.219 TCP 56123 > ldap [SYN] Seq=0 Win=14600 Len=0 MSS=1460 TSV=5217177 TSER=0 WS=7 31.860256 165.115.207.219 -> 165.115.40.149 TCP ldap > 56123 [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1360 WS=0 TSV=0 TSER=0 31.860313 165.115.40.149 -> 165.115.207.219 TCP 56123 > ldap [ACK] Seq=1 Ack=1 Win=14720 Len=0 TSV=5217209 TSER=0 31.860488 165.115.40.149 -> 165.115.207.219 LDAP searchRequest(1) "" baseObject 31.901748 165.115.207.219 -> 165.115.40.149 TCP [TCP segment of a reassembled PDU] 31.901767 165.115.40.149 -> 165.115.207.219 TCP 56123 > ldap [ACK] Seq=229 Ack=1349 Win=17536 Len=0 TSV=5217251 TSER=15563619 31.907040 165.115.207.219 -> 165.115.40.149 LDAP searchResEntry(1) "" 31.907054 165.115.40.149 -> 165.115.207.219 TCP 56123 > ldap [ACK] Seq=229 Ack=2314 Win=20224 Len=0 TSV=5217256 TSER=15563619 31.907540 165.115.40.149 -> 165.115.52.21 DNS Standard query A prg-yd-i02.cn.ca 31.907883 165.115.52.21 -> 165.115.40.149 DNS Standard query response A 165.115.212.167 31.911870 165.115.40.149 -> 165.115.212.167 KRB5 AS-REQ 31.995533 165.115.212.167 -> 165.115.40.149 KRB5 KRB Error: KRB5KDC_ERR_C_PRINCIPAL_UNKNOWN 31.996253 165.115.40.149 -> 165.115.207.219 LDAP unbindRequest(2) it does this snippet on every AD server before geting back empty We wonder if we need to create a subdomain with FREEIP master of that subdomain... Any help would be appreciate Regards -- Sylvain Angers -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Wed Mar 7 19:11:41 2012 From: simo at redhat.com (Simo Sorce) Date: Wed, 07 Mar 2012 14:11:41 -0500 Subject: [Freeipa-users] need info on AD / IPA coexistence In-Reply-To: References: <74B15185-79AA-40FB-80D2-87E737E2D840@redhat.com> <833D8E48405E064EBC54C84EC6B36E404CBBF614@STAWINCOX10MBX1.staff.vuw.ac.nz> <1330058876.18690.117.camel@willson.li.ssimo.org> Message-ID: <1331147501.26197.103.camel@willson.li.ssimo.org> On Wed, 2012-03-07 at 13:38 -0500, Sylvain Angers wrote: > > Hello All, > We are facing the same difficulties here with coexistence with > Microsoft AD > on the same network > > Whenever I run ipa-client-install > > # ipa-client-install --server=server.abcd.ca --domain=abcd.ca > --realm=UNIX > DNS domain 'unix' is not configured for automatic KDC address lookup. > KDC address will be set to fixed value. > > Discovery was successful! > Hostname: client.abcd.ca > Realm: UNIX > DNS Domain: abcd.ca > IPA Server: server.abcd.ca > BaseDN: dc=unix > > is abcd.ca your windows domain ? although we support specifying a realm that is not identical to the DNS domain I strongly suggest you do not do so if you do not want to experience some trouble and to assing to your UNIX domain it's own DNS domain that matches the realm. If you do not do that things can still work, but not w/o some minor annoyances. For example discovery will fail as you find out because the DNS domain is owned by the AD realm. You also have to make sure you properly map realms to domains correctly in various clients. Simo. -- Simo Sorce * Red Hat, Inc * New York From ondrejv at s3group.cz Thu Mar 8 07:31:30 2012 From: ondrejv at s3group.cz (Ondrej Valousek) Date: Thu, 08 Mar 2012 08:31:30 +0100 Subject: [Freeipa-users] need info on AD / IPA coexistence In-Reply-To: <1331147501.26197.103.camel@willson.li.ssimo.org> References: <74B15185-79AA-40FB-80D2-87E737E2D840@redhat.com> <833D8E48405E064EBC54C84EC6B36E404CBBF614@STAWINCOX10MBX1.staff.vuw.ac.nz> <1330058876.18690.117.camel@willson.li.ssimo.org> <1331147501.26197.103.camel@willson.li.ssimo.org> Message-ID: <4F586052.8070705@s3group.cz> Side note: You can manage AD integrated DNS from unix host easily with just 'nsupdate -g' - so theoretically (ok I undestand you have to have a proper Kerberos TGT...) IPA client could be able to autoconfigure (create all the necessary SRV records) AD DNS, too. Not sure if we even wanted that. but theoretically, it should be possible. Ondrej On 03/07/2012 08:11 PM, Simo Sorce wrote: > On Wed, 2012-03-07 at 13:38 -0500, Sylvain Angers wrote: >> Hello All, >> We are facing the same difficulties here with coexistence with >> Microsoft AD >> on the same network >> >> Whenever I run ipa-client-install >> >> # ipa-client-install --server=server.abcd.ca --domain=abcd.ca >> --realm=UNIX >> DNS domain 'unix' is not configured for automatic KDC address lookup. >> KDC address will be set to fixed value. >> >> Discovery was successful! >> Hostname: client.abcd.ca >> Realm: UNIX >> DNS Domain: abcd.ca >> IPA Server: server.abcd.ca >> BaseDN: dc=unix >> >> > is abcd.ca your windows domain ? > > although we support specifying a realm that is not identical to the DNS > domain I strongly suggest you do not do so if you do not want to > experience some trouble and to assing to your UNIX domain it's own DNS > domain that matches the realm. If you do not do that things can still > work, but not w/o some minor annoyances. > For example discovery will fail as you find out because the DNS domain > is owned by the AD realm. You also have to make sure you properly map > realms to domains correctly in various clients. > > Simo. > The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications at s3group.com. Thank You. Silicon and Software Systems Limited. Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sylvainangers at gmail.com Thu Mar 8 12:40:10 2012 From: sylvainangers at gmail.com (Sylvain Angers) Date: Thu, 8 Mar 2012 07:40:10 -0500 Subject: [Freeipa-users] need info on AD / IPA coexistence In-Reply-To: <4F586052.8070705@s3group.cz> References: <74B15185-79AA-40FB-80D2-87E737E2D840@redhat.com> <833D8E48405E064EBC54C84EC6B36E404CBBF614@STAWINCOX10MBX1.staff.vuw.ac.nz> <1330058876.18690.117.camel@willson.li.ssimo.org> <1331147501.26197.103.camel@willson.li.ssimo.org> <4F586052.8070705@s3group.cz> Message-ID: >is abcd.ca your windows domain ? yes in this example ipa-server-install -a xxxxxxxxxxxxxxxxxx \ --hostname=ipa1.unix.abcd.ca \ -n unix.abcd.ca \ -p xxxxxxxxxxxxxxxxxxx \ -r UNIX.ABCD.CA \ --subject=subject_DN \ #Sets the base element for the subject DN of the issued certificates. This defaults to O=realm. --forwarder=ad_dns.abcd.ca \ --no-reverse \ #???? Does not create a reverse DNS zone when the DNS domain is set up. --setup-dns \ --idmax=number \ #???Sets the upper bound for IDs which can be assigned by the IPA server. The default value is the ID start value plus 199999. --idstart=10000 #???? will have to check with AD I guess IPA server will become unix master DNS for UNIX current unix server fqdn will remain on abcd.ca current unix server will have dns,ntp,kdc,ldap from ipa realm will be equal to domain name = unix.abcd.ca When I will have resolve "getent passwd admin" issue I believe I will be able to su - admin on any unix server and will be able to start thinking about what next like winsync then create ipa slave = ipa2.unix.abcd.ca Define SRV in bind unix.abcd.ca test all our supported Unix platform, especially AIX, Does anyone was successful to hook their HP ilo, RHEV manager to IPA? Will have to convince many people to achieve this set-up, but I am sure it worth it! Thank you! you guys Rock! Sylvain 2012/3/8 Ondrej Valousek > ** > Side note: > You can manage AD integrated DNS from unix host easily with just 'nsupdate > -g' - so theoretically (ok I undestand you have to have a proper Kerberos > TGT...) IPA client could be able to autoconfigure (create all the necessary > SRV records) AD DNS, too. Not sure if we even wanted that. but > theoretically, it should be possible. > > Ondrej > > > On 03/07/2012 08:11 PM, Simo Sorce wrote: > > On Wed, 2012-03-07 at 13:38 -0500, Sylvain Angers wrote: > > Hello All, > We are facing the same difficulties here with coexistence with > Microsoft AD > on the same network > > Whenever I run ipa-client-install > > # ipa-client-install --server=server.abcd.ca --domain=abcd.ca > --realm=UNIX > DNS domain 'unix' is not configured for automatic KDC address lookup. > KDC address will be set to fixed value. > > Discovery was successful! > Hostname: client.abcd.ca > Realm: UNIX > DNS Domain: abcd.ca > IPA Server: server.abcd.ca > BaseDN: dc=unix > > > > is abcd.ca your windows domain ? > > although we support specifying a realm that is not identical to the DNS > domain I strongly suggest you do not do so if you do not want to > experience some trouble and to assing to your UNIX domain it's own DNS > domain that matches the realm. If you do not do that things can still > work, but not w/o some minor annoyances. > For example discovery will fail as you find out because the DNS domain > is owned by the AD realm. You also have to make sure you properly map > realms to domains correctly in various clients. > > Simo. > > > > ------------------------------ > The information contained in this e-mail and in any attachments is > confidential and is designated solely for the attention of the intended > recipient(s). If you are not an intended recipient, you must not use, > disclose, copy, distribute or retain this e-mail or any part thereof. If > you have received this e-mail in error, please notify the sender by return > e-mail and delete all copies of this e-mail from your computer system(s). > Please direct any additional queries to: communications at s3group.com. > Thank You. Silicon and Software Systems Limited. Registered in Ireland no. > 378073. Registered Office: South County Business Park, Leopardstown, Dublin > 18 > ------------------------------ > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -- Sylvain Angers -------------- next part -------------- An HTML attachment was scrubbed... URL: From sylvainangers at gmail.com Thu Mar 8 14:46:03 2012 From: sylvainangers at gmail.com (Sylvain Angers) Date: Thu, 8 Mar 2012 09:46:03 -0500 Subject: [Freeipa-users] need info on AD / IPA coexistence Message-ID: Hi Again Our current Linux/AIX servers fqdn should remain on abcd.ca domain I need an advice: Should the ipa server fqdn be ipa.abcd.ca or ipa.unix.abcd.ca? and on the Linux/AIX server, should we add entry of both dns (ipa and Microsoft AD) in resolv.conf? domain unix.abcd.ca search unix.abcd.ca abcd.ca nameserver ipa_adress nameserver ad_adress Thanks -- Sylvain Angers -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Thu Mar 8 15:02:57 2012 From: simo at redhat.com (Simo Sorce) Date: Thu, 08 Mar 2012 10:02:57 -0500 Subject: [Freeipa-users] need info on AD / IPA coexistence In-Reply-To: References: Message-ID: <1331218977.9238.16.camel@willson.li.ssimo.org> On Thu, 2012-03-08 at 09:46 -0500, Sylvain Angers wrote: > Hi Again > Our current Linux/AIX servers fqdn should remain on abcd.ca domain > > I need an advice: Should the ipa server fqdn be ipa.abcd.ca or > ipa.unix.abcd.ca? You can have machines on a different DNS domain with FreeIPA. So you can use unix.abcd.ca for your IPA server and still install clients in abcd.ca. I think the onlt thing you should take care of is to make sure a abcd.ca -> UNIX.ABCD.CA mapping in krb5.conf under the [domain_realm] section is available on all machines of the domain to avoid issues resolving the correct realm for clients in the other domain. On clients this should be autometed in the very last release but the ipa server needs to be configured after install. > and on the Linux/AIX server, should we add entry of both dns (ipa and > Microsoft AD) in resolv.conf? No, that would not work. What you should do is ask your DNS admin to delegate you the unix.abcd.ca zone. Once that is done it doesn't matter which DNS you are querying they will know who to ask. If delegation is not possible you could still use named forwarders in both IPA and AD so that each DNS server still know where to forward requests for the specific domain. This again will allow you to use whatever DNS your network uses and have queries properly forwarded around. > domain unix.abcd.ca > search unix.abcd.ca abcd.ca > nameserver ipa_adress > nameserver ad_adress > No, don't do this as a way to not configure the DNS servers, it won't work and will cause really confusing mis-behaviors if the DNS servers themselves do not know how to talk to each other. If delegation of zones or forwarding is properly set up though then this scheme would allow you to have a fallback when either infrastructure is temporarily unreachable. > Simo. -- Simo Sorce * Red Hat, Inc * New York From sylvainangers at gmail.com Thu Mar 8 16:54:34 2012 From: sylvainangers at gmail.com (Sylvain Angers) Date: Thu, 8 Mar 2012 11:54:34 -0500 Subject: [Freeipa-users] need info on AD / IPA coexistence In-Reply-To: <1331218977.9238.16.camel@willson.li.ssimo.org> References: <1331218977.9238.16.camel@willson.li.ssimo.org> Message-ID: Alright! I am now requesting to our DNS team please delegate dns zone "unix.abcd.ca" to ??? Question: is the ipa server fqdn, be ipaserver.unix.abcd.ca or ipaserver.abcd.ca? does it matter? thanks 2012/3/8 Simo Sorce > On Thu, 2012-03-08 at 09:46 -0500, Sylvain Angers wrote: > > Hi Again > > Our current Linux/AIX servers fqdn should remain on abcd.ca domain > > > > I need an advice: Should the ipa server fqdn be ipa.abcd.ca or > > ipa.unix.abcd.ca? > > You can have machines on a different DNS domain with FreeIPA. > So you can use unix.abcd.ca for your IPA server and still install > clients in abcd.ca. > > I think the onlt thing you should take care of is to make sure a > abcd.ca -> UNIX.ABCD.CA mapping in krb5.conf under the [domain_realm] > section is available on all machines of the domain to avoid issues > resolving the correct realm for clients in the other domain. > > On clients this should be autometed in the very last release but the ipa > server needs to be configured after install. > > > and on the Linux/AIX server, should we add entry of both dns (ipa and > > Microsoft AD) in resolv.conf? > > No, that would not work. What you should do is ask your DNS admin to > delegate you the unix.abcd.ca zone. Once that is done it doesn't matter > which DNS you are querying they will know who to ask. > If delegation is not possible you could still use named forwarders in > both IPA and AD so that each DNS server still know where to forward > requests for the specific domain. This again will allow you to use > whatever DNS your network uses and have queries properly forwarded > around. > > > domain unix.abcd.ca > > search unix.abcd.ca abcd.ca > > nameserver ipa_adress > > nameserver ad_adress > > > No, don't do this as a way to not configure the DNS servers, it won't > work and will cause really confusing mis-behaviors if the DNS servers > themselves do not know how to talk to each other. > > If delegation of zones or forwarding is properly set up though then this > scheme would allow you to have a fallback when either infrastructure is > temporarily unreachable. > > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > > -- Sylvain Angers -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Thu Mar 8 17:04:06 2012 From: simo at redhat.com (Simo Sorce) Date: Thu, 08 Mar 2012 12:04:06 -0500 Subject: [Freeipa-users] need info on AD / IPA coexistence In-Reply-To: References: <1331218977.9238.16.camel@willson.li.ssimo.org> Message-ID: <1331226246.9238.23.camel@willson.li.ssimo.org> On Thu, 2012-03-08 at 11:54 -0500, Sylvain Angers wrote: > Alright! > > I am now requesting to our DNS team > > please delegate dns zone "unix.abcd.ca" to ??? the ip address of your ipa server, they will know what questions to ask :) > Question: is the ipa server fqdn, be ipaserver.unix.abcd.ca or > ipaserver.abcd.ca? > does it matter? It does, the IPa server DNS domain is what matters for the first master. So it should be .unix.abcd.ca So that DNS domain = unix.abcd.ca and realm = UNIX.ABCD.CA (if you use the standard configuration). Simo. -- Simo Sorce * Red Hat, Inc * New York From bcook at redhat.com Thu Mar 8 17:07:07 2012 From: bcook at redhat.com (Brian Cook) Date: Thu, 8 Mar 2012 09:07:07 -0800 Subject: [Freeipa-users] need info on AD / IPA coexistence In-Reply-To: References: <1331218977.9238.16.camel@willson.li.ssimo.org> Message-ID: If your AD realm is ABCD.CA and you want your unix realm to be UNIX.ABCD.CA then your FQDN should be ipaserver.unix.abcd.ca When you delegate the zone from AD, you should have at least two IPA servers running bind listed. ipaserver1.unix.abcd.ad ipaserver2.unix.abcd.ad That way if one is down, you can still resolve names. --- Brian Cook Solutions Architect, Red Hat, Inc. 407-212-7079 On Mar 8, 2012, at 8:54 AM, Sylvain Angers wrote: > Alright! > > I am now requesting to our DNS team > > please delegate dns zone "unix.abcd.ca" to ??? > Question: is the ipa server fqdn, be ipaserver.unix.abcd.ca or ipaserver.abcd.ca? > > does it matter? > > thanks > > 2012/3/8 Simo Sorce > On Thu, 2012-03-08 at 09:46 -0500, Sylvain Angers wrote: > > Hi Again > > Our current Linux/AIX servers fqdn should remain on abcd.ca domain > > > > I need an advice: Should the ipa server fqdn be ipa.abcd.ca or > > ipa.unix.abcd.ca? > > You can have machines on a different DNS domain with FreeIPA. > So you can use unix.abcd.ca for your IPA server and still install > clients in abcd.ca. > > I think the onlt thing you should take care of is to make sure a > abcd.ca -> UNIX.ABCD.CA mapping in krb5.conf under the [domain_realm] > section is available on all machines of the domain to avoid issues > resolving the correct realm for clients in the other domain. > > On clients this should be autometed in the very last release but the ipa > server needs to be configured after install. > > > and on the Linux/AIX server, should we add entry of both dns (ipa and > > Microsoft AD) in resolv.conf? > > No, that would not work. What you should do is ask your DNS admin to > delegate you the unix.abcd.ca zone. Once that is done it doesn't matter > which DNS you are querying they will know who to ask. > If delegation is not possible you could still use named forwarders in > both IPA and AD so that each DNS server still know where to forward > requests for the specific domain. This again will allow you to use > whatever DNS your network uses and have queries properly forwarded > around. > > > domain unix.abcd.ca > > search unix.abcd.ca abcd.ca > > nameserver ipa_adress > > nameserver ad_adress > > > No, don't do this as a way to not configure the DNS servers, it won't > work and will cause really confusing mis-behaviors if the DNS servers > themselves do not know how to talk to each other. > > If delegation of zones or forwarding is properly set up though then this > scheme would allow you to have a fallback when either infrastructure is > temporarily unreachable. > > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > > > > > -- > Sylvain Angers > > _______________________________________________ > 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 bcook at redhat.com Thu Mar 8 17:08:23 2012 From: bcook at redhat.com (Brian Cook) Date: Thu, 8 Mar 2012 09:08:23 -0800 Subject: [Freeipa-users] need info on AD / IPA coexistence In-Reply-To: <1331226246.9238.23.camel@willson.li.ssimo.org> References: <1331218977.9238.16.camel@willson.li.ssimo.org> <1331226246.9238.23.camel@willson.li.ssimo.org> Message-ID: Also, I would not use 'delegation record' from AD, use conditional forwarding for *.unix.abcd.ca. Your AD admins should know how to do it. --- Brian Cook Solutions Architect, Red Hat, Inc. 407-212-7079 On Mar 8, 2012, at 9:04 AM, Simo Sorce wrote: > On Thu, 2012-03-08 at 11:54 -0500, Sylvain Angers wrote: >> Alright! >> >> I am now requesting to our DNS team >> >> please delegate dns zone "unix.abcd.ca" to ??? > > the ip address of your ipa server, they will know what questions to > ask :) > >> Question: is the ipa server fqdn, be ipaserver.unix.abcd.ca or >> ipaserver.abcd.ca? > >> does it matter? > > It does, the IPa server DNS domain is what matters for the first master. > So it should be .unix.abcd.ca > > So that DNS domain = unix.abcd.ca and realm = UNIX.ABCD.CA (if you use > the standard configuration). > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > > _______________________________________________ > 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 Steven.Jones at vuw.ac.nz Thu Mar 8 20:14:21 2012 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Thu, 8 Mar 2012 20:14:21 +0000 Subject: [Freeipa-users] IPA clashing with selinux on users home directories Message-ID: <833D8E48405E064EBC54C84EC6B36E404CBDA995@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, I am setting up some IPA users what I have noticed is if I or they type startx to start a gui locking the .Xauthority fails, if I setenforce 0 then it works fine.....I have never seen this behaviour before and googling suggests its an IPA and selinux conflict. and in fact when I create a local user they get an instant gui from running startx... regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 From sgallagh at redhat.com Thu Mar 8 20:43:43 2012 From: sgallagh at redhat.com (Stephen Gallagher) Date: Thu, 08 Mar 2012 15:43:43 -0500 Subject: [Freeipa-users] IPA clashing with selinux on users home directories In-Reply-To: <833D8E48405E064EBC54C84EC6B36E404CBDA995@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E404CBDA995@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <1331239423.2897.20.camel@sgallagh520.sgallagh.bos.redhat.com> On Thu, 2012-03-08 at 20:14 +0000, Steven Jones wrote: > Hi, > > I am setting up some IPA users what I have noticed is if I or they type > startx to start a gui locking the .Xauthority fails, if I setenforce 0 > then it works fine.....I have never seen this behaviour before and > googling suggests its an IPA and selinux conflict. > > and in fact when I create a local user they get an instant gui from > running startx... > I'm guessing you're creating your home directories with the help of pam_mkhomedir.so. This won't work with SELinux. You need to install and use pam_oddjob_mkhomedir.so instead, which will properly set up SELinux contexts for your users. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From Steven.Jones at vuw.ac.nz Thu Mar 8 21:27:36 2012 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Thu, 8 Mar 2012 21:27:36 +0000 Subject: [Freeipa-users] IPA clashing with selinux on users home directories In-Reply-To: <1331239423.2897.20.camel@sgallagh520.sgallagh.bos.redhat.com> References: <833D8E48405E064EBC54C84EC6B36E404CBDA995@STAWINCOX10MBX1.staff.vuw.ac.nz>, <1331239423.2897.20.camel@sgallagh520.sgallagh.bos.redhat.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E404CBDAB2B@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, I used ipa-client-install --mkhomedir How do I change that so it will do so properly? regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Stephen Gallagher [sgallagh at redhat.com] Sent: Friday, 9 March 2012 9:43 a.m. To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] IPA clashing with selinux on users home directories On Thu, 2012-03-08 at 20:14 +0000, Steven Jones wrote: > Hi, > > I am setting up some IPA users what I have noticed is if I or they type > startx to start a gui locking the .Xauthority fails, if I setenforce 0 > then it works fine.....I have never seen this behaviour before and > googling suggests its an IPA and selinux conflict. > > and in fact when I create a local user they get an instant gui from > running startx... > I'm guessing you're creating your home directories with the help of pam_mkhomedir.so. This won't work with SELinux. You need to install and use pam_oddjob_mkhomedir.so instead, which will properly set up SELinux contexts for your users. From simo at redhat.com Thu Mar 8 21:35:08 2012 From: simo at redhat.com (Simo Sorce) Date: Thu, 08 Mar 2012 16:35:08 -0500 Subject: [Freeipa-users] IPA clashing with selinux on users home directories In-Reply-To: <833D8E48405E064EBC54C84EC6B36E404CBDAB2B@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E404CBDA995@STAWINCOX10MBX1.staff.vuw.ac.nz> , <1331239423.2897.20.camel@sgallagh520.sgallagh.bos.redhat.com> <833D8E48405E064EBC54C84EC6B36E404CBDAB2B@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <1331242508.9238.26.camel@willson.li.ssimo.org> On Thu, 2012-03-08 at 21:27 +0000, Steven Jones wrote: > Hi, > > I used ipa-client-install --mkhomedir > > How do I change that so it will do so properly? > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > ________________________________________ > From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Stephen Gallagher [sgallagh at redhat.com] > Sent: Friday, 9 March 2012 9:43 a.m. > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] IPA clashing with selinux on users home directories > > On Thu, 2012-03-08 at 20:14 +0000, Steven Jones wrote: > > Hi, > > > > I am setting up some IPA users what I have noticed is if I or they type > > startx to start a gui locking the .Xauthority fails, if I setenforce 0 > > then it works fine.....I have never seen this behaviour before and > > googling suggests its an IPA and selinux conflict. > > > > and in fact when I create a local user they get an instant gui from > > running startx... > > > > I'm guessing you're creating your home directories with the help of > pam_mkhomedir.so. This won't work with SELinux. You need to install and > use pam_oddjob_mkhomedir.so instead, which will properly set up SELinux > contexts for your users. If you install oddjob_homedir before running ipa-client-install then it should pick that up automatically. We already have a patch upstream to require oddjob-mkhomedir at rpm install. Simo. -- Simo Sorce * Red Hat, Inc * New York From Steven.Jones at vuw.ac.nz Thu Mar 8 21:36:51 2012 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Thu, 8 Mar 2012 21:36:51 +0000 Subject: [Freeipa-users] IPA clashing with selinux on users home directories In-Reply-To: <1331242508.9238.26.camel@willson.li.ssimo.org> References: <833D8E48405E064EBC54C84EC6B36E404CBDA995@STAWINCOX10MBX1.staff.vuw.ac.nz> , <1331239423.2897.20.camel@sgallagh520.sgallagh.bos.redhat.com> <833D8E48405E064EBC54C84EC6B36E404CBDAB2B@STAWINCOX10MBX1.staff.vuw.ac.nz>, <1331242508.9238.26.camel@willson.li.ssimo.org> Message-ID: <833D8E48405E064EBC54C84EC6B36E404CBDAB7C@STAWINCOX10MBX1.staff.vuw.ac.nz> Thanks, I can put that in Sat. regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: Simo Sorce [simo at redhat.com] Sent: Friday, 9 March 2012 10:35 a.m. To: Steven Jones Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] IPA clashing with selinux on users home directories On Thu, 2012-03-08 at 21:27 +0000, Steven Jones wrote: > Hi, > > I used ipa-client-install --mkhomedir > > How do I change that so it will do so properly? > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > ________________________________________ > From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Stephen Gallagher [sgallagh at redhat.com] > Sent: Friday, 9 March 2012 9:43 a.m. > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] IPA clashing with selinux on users home directories > > On Thu, 2012-03-08 at 20:14 +0000, Steven Jones wrote: > > Hi, > > > > I am setting up some IPA users what I have noticed is if I or they type > > startx to start a gui locking the .Xauthority fails, if I setenforce 0 > > then it works fine.....I have never seen this behaviour before and > > googling suggests its an IPA and selinux conflict. > > > > and in fact when I create a local user they get an instant gui from > > running startx... > > > > I'm guessing you're creating your home directories with the help of > pam_mkhomedir.so. This won't work with SELinux. You need to install and > use pam_oddjob_mkhomedir.so instead, which will properly set up SELinux > contexts for your users. If you install oddjob_homedir before running ipa-client-install then it should pick that up automatically. We already have a patch upstream to require oddjob-mkhomedir at rpm install. Simo. -- Simo Sorce * Red Hat, Inc * New York From heco0701 at stcloudstate.edu Fri Mar 9 17:44:24 2012 From: heco0701 at stcloudstate.edu (Hemminger, Corey Lee. [heco0701@stcloudstate.edu]) Date: Fri, 9 Mar 2012 17:44:24 +0000 Subject: [Freeipa-users] Winsync setup error In-Reply-To: References: Message-ID: I've installed fedora 16 and freeipa 2.1.4 and am trying to create the winsync to a AD2008 server per the documentation and I got to step 7.3. I used command: ipa-replica-manage connect --winsync --binddn cn=user1,cn=user,dc=domain1,dc=com--bindpw 'xxxx(xxx' --passsync 'xxxx(xxx' --cacert /etc/openldap/cacerts/ADcert.cerADserver.domain1.com -v And it gave me an error: INFO:root:Failed to connect to AD serverADserver.domain1.com INFO:root:The error was: {'info': '80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 52e, v1db1', 'desc': 'Invalid credentials'} Failed to setup winsync replication Any help is greatly appreciated. Thanks, Corey -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Fri Mar 9 21:00:16 2012 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 09 Mar 2012 16:00:16 -0500 Subject: [Freeipa-users] Winsync setup error In-Reply-To: References: Message-ID: <4F5A6F60.7030403@redhat.com> On 03/09/2012 12:44 PM, Hemminger, Corey Lee. [heco0701 at stcloudstate.edu] wrote: > I've installed fedora 16 and freeipa 2.1.4 and am trying to create the > winsync to a AD2008 server per the documentation and I got to step > 7.3. I used command: > > ipa-replica-manage connect --winsync --binddn > cn=user1,cn=user,dc=domain1,dc=com--bindpw 'xxxx(xxx' --passsync > 'xxxx(xxx' --cacert > /etc/openldap/cacerts/ADcert.cerADserver.domain1.com > -v > I assume spaces are just dropped by cut and paste but please check. Also please check that you have the correct bind dn (did you mean ...,cn=users,dc=...?) and bind password. > And it gave me an error: > > INFO:root:Failed to connect to AD serverADserver.domain1.com > > INFO:root:The error was: {'info': '80090308 : LdapErr: > DSID-0C0903A9, comment: AcceptSecurityContext error, data 52e, v1db1', > 'desc': 'Invalid credentials'} > Failed to setup winsync replication > > Any help is greatly appreciated. > > Thanks, > Corey > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From heco0701 at stcloudstate.edu Sat Mar 10 17:31:20 2012 From: heco0701 at stcloudstate.edu (Hemminger, Corey Lee. [heco0701@stcloudstate.edu]) Date: Sat, 10 Mar 2012 17:31:20 +0000 Subject: [Freeipa-users] Freeipa-users Digest, Vol 44, Issue 14 In-Reply-To: References: Message-ID: <7173ABEE-0E28-4423-A50B-123BE96A25BB@stcloudstate.edu> Yes I did mean cn=users and the spaces are in since I copied and pasted and sent the email from my iPhone. I had trouble with the bindpw password since it had special characters in it and had to Add the single quotes to get the command to execute properly. Corey On Mar 10, 2012, at 11:01 AM, "freeipa-users-request at redhat.com" wrote: > Send Freeipa-users mailing list submissions to > freeipa-users at redhat.com > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.redhat.com/mailman/listinfo/freeipa-users > or, via email, send a message with subject or body 'help' to > freeipa-users-request at redhat.com > > You can reach the person managing the list at > freeipa-users-owner at redhat.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Freeipa-users digest..." > > > Today's Topics: > > 1. Winsync setup error > (Hemminger, Corey Lee. [heco0701 at stcloudstate.edu]) > 2. Re: Winsync setup error (Dmitri Pal) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 9 Mar 2012 17:44:24 +0000 > From: "Hemminger, Corey Lee. [heco0701 at stcloudstate.edu]" > > To: "" > Cc: "freeipa-users at redhat.com" > Subject: [Freeipa-users] Winsync setup error > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > I've installed fedora 16 and freeipa 2.1.4 and am trying to create the winsync to a AD2008 server per the documentation and I got to step 7.3. I used command: > > ipa-replica-manage connect --winsync --binddn cn=user1,cn=user,dc=domain1,dc=com--bindpw 'xxxx(xxx' --passsync 'xxxx(xxx' --cacert /etc/openldap/cacerts/ADcert.cerADserver.domain1.com -v > > And it gave me an error: > > INFO:root:Failed to connect to AD serverADserver.domain1.com > INFO:root:The error was: {'info': '80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 52e, v1db1', 'desc': 'Invalid credentials'} > Failed to setup winsync replication > > Any help is greatly appreciated. > > Thanks, > Corey > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Message: 2 > Date: Fri, 09 Mar 2012 16:00:16 -0500 > From: Dmitri Pal > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Winsync setup error > Message-ID: <4F5A6F60.7030403 at redhat.com> > Content-Type: text/plain; charset="iso-8859-1" > > On 03/09/2012 12:44 PM, Hemminger, Corey Lee. > [heco0701 at stcloudstate.edu] wrote: >> I've installed fedora 16 and freeipa 2.1.4 and am trying to create the >> winsync to a AD2008 server per the documentation and I got to step >> 7.3. I used command: >> >> ipa-replica-manage connect --winsync --binddn >> cn=user1,cn=user,dc=domain1,dc=com--bindpw 'xxxx(xxx' --passsync >> 'xxxx(xxx' --cacert >> /etc/openldap/cacerts/ADcert.cerADserver.domain1.com >> -v >> > I assume spaces are just dropped by cut and paste but please check. > Also please check that you have the correct bind dn (did you mean > ...,cn=users,dc=...?) and bind password. > > >> And it gave me an error: >> >> INFO:root:Failed to connect to AD serverADserver.domain1.com >> >> INFO:root:The error was: {'info': '80090308 : LdapErr: >> DSID-0C0903A9, comment: AcceptSecurityContext error, data 52e, v1db1', >> 'desc': 'Invalid credentials'} >> Failed to setup winsync replication >> >> Any help is greatly appreciated. >> >> Thanks, >> Corey >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IPA project, > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > End of Freeipa-users Digest, Vol 44, Issue 14 > ********************************************* From sbingram at gmail.com Sun Mar 11 02:54:50 2012 From: sbingram at gmail.com (Stephen Ingram) Date: Sat, 10 Mar 2012 18:54:50 -0800 Subject: [Freeipa-users] 2.1.90 rc1 testing on F17 alpha Message-ID: I'm testing the new FreeIPA 2.1.90 rc1 on a fresh Fedora 17 alpha this weekend. I started by installing the freeipa-server package and the dns packages hoping they would pull in all of the dependencies. 1. I received the error message: 2012-03-11T01:52:51Z DEBUG stderr=Can't locate File/Slurp.pm in @INC (@INC conta ins: /usr/local/lib/perl5 /usr/local/share/perl5 /usr/lib/perl5/vendor_perl /usr /share/perl5/vendor_perl /usr/lib/perl5 /usr/share/perl5 .) at /usr/bin/pkicreate line 25. Adding the package perl-File-Slurp-9999.19-3.fc17.noarch.rpm seemed to fix the problem. 2. I also noticed that the ipa-server-install --uninstall was not exiting properly. Adding the missing package, perl-XML-LibXML-1.90-1.fc17.i686.rpm (and dependencies) allowed a proper uninstall. 3. Now, I've run into the same issue as Dan Scott (https://www.redhat.com/archives/freeipa-users/2012-February/msg00301.html) with the CA instance. The log complains loudly about not being able to assign the selinux context for the dogtag ports, however, I'm not sure that caused the error. I think the real cause of the error is that the dogtag server cannot be started so when the ipa install script tries to configure the CA, it fails since it can't connect to the server. Trying to start the server manually, I get: Mar 10 18:39:38 f17a pkicontrol[1325]: chown: changing ownership of `/var/run/pki-ca.pid': Operation not permitted Mar 10 18:39:38 f17a pkicontrol[1325]: touch: cannot touch `/var/log/pki-ca/catalina.out': Permission denied All of these seem to be owned by root: -rw-r--r--. root root system_u:object_r:pki_ca_var_run_t:s0 pki-ca.pid -rw-r--r--. root root system_u:object_r:pki_ca_log_t:s0 /var/log/pki-ca/catalina.out As I'm still not to up on the new systemd stuff, I'm not sure what to do next. Any suggestions? Steve From abokovoy at redhat.com Sun Mar 11 06:49:07 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Sun, 11 Mar 2012 08:49:07 +0200 Subject: [Freeipa-users] 2.1.90 rc1 testing on F17 alpha In-Reply-To: References: Message-ID: <20120311064907.GB32454@redhat.com> On Sat, 10 Mar 2012, Stephen Ingram wrote: > I'm testing the new FreeIPA 2.1.90 rc1 on a fresh Fedora 17 alpha this > weekend. I started by installing the freeipa-server package and the > dns packages hoping they would pull in all of the dependencies. > > 1. I received the error message: > > 2012-03-11T01:52:51Z DEBUG stderr=Can't locate File/Slurp.pm in @INC (@INC conta > ins: /usr/local/lib/perl5 /usr/local/share/perl5 /usr/lib/perl5/vendor_perl /usr > /share/perl5/vendor_perl /usr/lib/perl5 /usr/share/perl5 .) at > /usr/bin/pkicreate line 25. > > Adding the package perl-File-Slurp-9999.19-3.fc17.noarch.rpm seemed to > fix the problem. Known issue. We are waiting for dogtag packages being rebuilt. The last time they've been built for F17/Rawhide, there was regression in 'file' package that caused to not recognize auto dependencies in perl executables. > 2. I also noticed that the ipa-server-install --uninstall was not > exiting properly. > > Adding the missing package, perl-XML-LibXML-1.90-1.fc17.i686.rpm (and > dependencies) allowed a proper uninstall. Same here. > 3. Now, I've run into the same issue as Dan Scott > (https://www.redhat.com/archives/freeipa-users/2012-February/msg00301.html) > with the CA instance. The log complains loudly about not being able to > assign the selinux context for the dogtag ports, however, I'm not sure > that caused the error. I think the real cause of the error is that the > dogtag server cannot be started so when the ipa install script tries > to configure the CA, it fails since it can't connect to the server. > > Trying to start the server manually, I get: > > Mar 10 18:39:38 f17a pkicontrol[1325]: chown: changing ownership of > `/var/run/pki-ca.pid': Operation not permitted > Mar 10 18:39:38 f17a pkicontrol[1325]: touch: cannot touch > `/var/log/pki-ca/catalina.out': Permission denied > > All of these seem to be owned by root: > > -rw-r--r--. root root system_u:object_r:pki_ca_var_run_t:s0 pki-ca.pid > -rw-r--r--. root root system_u:object_r:pki_ca_log_t:s0 > /var/log/pki-ca/catalina.out SELinux policy in existing dogtag packages is broken. It is already fixed in the development tree but no new package is available yet as I said above. As SELinux policy for dogtag is broken, appropriate operations that pkicreate was supposed to perform went wrong. > As I'm still not to up on the new systemd stuff, I'm not sure what to > do next. Any suggestions? Please try with permissive mode and clear VM. -- / Alexander Bokovoy From sbingram at gmail.com Sun Mar 11 07:22:55 2012 From: sbingram at gmail.com (Stephen Ingram) Date: Sat, 10 Mar 2012 23:22:55 -0800 Subject: [Freeipa-users] 2.1.90 rc1 testing on F17 alpha In-Reply-To: <20120311064907.GB32454@redhat.com> References: <20120311064907.GB32454@redhat.com> Message-ID: On Sat, Mar 10, 2012 at 10:49 PM, Alexander Bokovoy wrote: > On Sat, 10 Mar 2012, Stephen Ingram wrote: > >> I'm testing the new FreeIPA 2.1.90 rc1 on a fresh Fedora 17 alpha this >> weekend. I started by installing the freeipa-server package and the >> dns packages hoping they would pull in all of the dependencies. ...snip... > SELinux policy in existing dogtag packages is broken. It is already > fixed in the development tree but no new package is available yet as I > said above. As SELinux policy for dogtag is broken, appropriate > operations that pkicreate was supposed to perform went wrong. > >> As I'm still not to up on the new systemd stuff, I'm not sure what to >> do next. Any suggestions? > Please try with permissive mode and clear VM. Tried in permissive mode. Almost made it all the way through. Permissions are correct on those files (/run/pki-ca.pid and /var/log/pki-ca/catalina.out) now. Install stopped with error during the LDAP updates with "unexpected error - 'set' object does not support item assignment". IPA server install logs say: ... 2012-03-11T07:15:05Z DEBUG ( 1.3.6.1.4.1.15953.9.1.10 NAME 'sudoOrder' DESC 'an integer to order the sudoRole entries' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 X-ORIGIN 'SUDO' ) 2012-03-11T07:15:05Z DEBUG 'set' object does not support item assignment File "/sbin/ipa-server-install", line 1092, in rval = main() File "/sbin/ipa-server-install", line 1005, in main ds.apply_updates() File "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line 425, in apply_updates ld.update(files) File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 817, in update self.__run_updates(dn_list, all_updates) File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 771, in __run_updates self.__update_record(all_updates[dn]) File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 657, in __update_record updated = self.is_schema_updated(entry.toDict()) File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 589, in is_schema_updated s = ldap.schema.SubSchema(s) File "/usr/lib/python2.7/site-packages/ldap/schema/subentry.py", line 125, in __init__ self.non_unique_names[se_class][se_id] = None Steve From abokovoy at redhat.com Sun Mar 11 08:20:29 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Sun, 11 Mar 2012 10:20:29 +0200 Subject: [Freeipa-users] 2.1.90 rc1 testing on F17 alpha In-Reply-To: References: <20120311064907.GB32454@redhat.com> Message-ID: <20120311082029.GC32454@redhat.com> On Sat, 10 Mar 2012, Stephen Ingram wrote: > On Sat, Mar 10, 2012 at 10:49 PM, Alexander Bokovoy wrote: > > On Sat, 10 Mar 2012, Stephen Ingram wrote: > > > >> I'm testing the new FreeIPA 2.1.90 rc1 on a fresh Fedora 17 alpha this > >> weekend. I started by installing the freeipa-server package and the > >> dns packages hoping they would pull in all of the dependencies. > > ...snip... > > > SELinux policy in existing dogtag packages is broken. It is already > > fixed in the development tree but no new package is available yet as I > > said above. As SELinux policy for dogtag is broken, appropriate > > operations that pkicreate was supposed to perform went wrong. > > > >> As I'm still not to up on the new systemd stuff, I'm not sure what to > >> do next. Any suggestions? > > Please try with permissive mode and clear VM. > > Tried in permissive mode. Almost made it all the way through. > Permissions are correct on those files (/run/pki-ca.pid and > /var/log/pki-ca/catalina.out) now. > > Install stopped with error during the LDAP updates with "unexpected > error - 'set' object does not support item assignment". IPA server > install logs say: > > ... > > 2012-03-11T07:15:05Z DEBUG ( 1.3.6.1.4.1.15953.9.1.10 NAME > 'sudoOrder' DESC 'an integer to order the sudoRole entries' > EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX > 1.3.6.1.4.1.1466.115.121.1.27 X-ORIGIN 'SUDO' ) > 2012-03-11T07:15:05Z DEBUG 'set' object does not support item > assignment File "/sbin/ipa-server-install", line 1092, in > rval = main() > > File "/sbin/ipa-server-install", line 1005, in main ds.apply_updates() > > File "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", > line 425, in apply_updates ld.update(files) > > File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", > line 817, in update self.__run_updates(dn_list, all_updates) > > File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", > line 771, in __run_updates self.__update_record(all_updates[dn]) > > File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", > line 657, in __update_record updated = > self.is_schema_updated(entry.toDict()) > > File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", > line 589, in is_schema_updated s = ldap.schema.SubSchema(s) > > File "/usr/lib/python2.7/site-packages/ldap/schema/subentry.py", > line 125, in __init__ self.non_unique_names[se_class][se_id] = None This should already be fixed already with https://fedorahosted.org/freeipa/changeset/93d2666ce119b464b0cb0feb45310a8a46e2385c/ You are using RC1, we have released beta1 last week, it should include the fix: https://www.redhat.com/archives/freeipa-devel/2012-March/msg00087.html Could you please try beta1? -- / Alexander Bokovoy From sbingram at gmail.com Sun Mar 11 17:15:12 2012 From: sbingram at gmail.com (Stephen Ingram) Date: Sun, 11 Mar 2012 10:15:12 -0700 Subject: [Freeipa-users] 2.1.90 rc1 testing on F17 alpha In-Reply-To: <20120311082029.GC32454@redhat.com> References: <20120311064907.GB32454@redhat.com> <20120311082029.GC32454@redhat.com> Message-ID: On Sun, Mar 11, 2012 at 12:20 AM, Alexander Bokovoy wrote: > On Sat, 10 Mar 2012, Stephen Ingram wrote: ...snip... > You are using RC1, we have released beta1 last week, it should include > the fix: > https://www.redhat.com/archives/freeipa-devel/2012-March/msg00087.html > > Could you please try beta1? Sorry, I assumed that since F17 was still a work in progress that it would have the latest version. Updating worked. One thing, the uninstall program did not remove the lock file directory (/run/lock/dirsrv), which for some reason was owned by memcached:memcached. This caused the first install to fail. Maybe it's a good idea for the install program to at least check permissions on this directory? I know someone could be running another directory instance, but pkisrv:dirsrv aren't the normal permissions either, no? Steve From natxo.asenjo at gmail.com Sun Mar 11 20:09:17 2012 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Sun, 11 Mar 2012 21:09:17 +0100 Subject: [Freeipa-users] automount questions Message-ID: hi, First question: according to the docs in http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/configuring-automount.html#Configuring_Automount-Configuring_autofs_on_Linuxwhen configuring autofs you can choose to enter LDAP_URI in two ways, the lazy on (+1) or the specific one. The 'lazy' one requires a srv record query, in the specific one one enters the ldap server we want to query. In my limited experience, the srv record query does not work., the other one does. This is the relevant piece of /etc/sysconfig/autofs config that does not work: LDAP_URI="ldap:///ipa.domain.nx" if I query this domain for an srv ldap record it works: [root at ipaclient01 sysconfig]# dig -t srv _ldap._tcp.ipa.domain.nx +short 0 100 389 kdc.ipa.domain.nx. But autofs cannot find it: Mar 11 20:44:39 ipaclient01 automount[3236]: Starting automounter version 5.0.5-39.el6_2.1, master map auto.master Mar 11 20:44:39 ipaclient01 automount[3236]: using kernel protocol version 5.02 Mar 11 20:44:39 ipaclient01 automount[3236]: lookup_nss_read_master: reading master files auto.master Mar 11 20:44:39 ipaclient01 automount[3236]: parse_init: parse(sun): init gathered global options: (null) Mar 11 20:44:39 ipaclient01 automount[3236]: lookup_read_master: lookup(file): read entry /misc Mar 11 20:44:39 ipaclient01 automount[3236]: lookup_read_master: lookup(file): read entry /net Mar 11 20:44:39 ipaclient01 automount[3236]: lookup_read_master: lookup(file): read entry +auto.master Mar 11 20:44:39 ipaclient01 automount[3236]: lookup_nss_read_master: reading master files auto.master Mar 11 20:44:39 ipaclient01 automount[3236]: parse_init: parse(sun): init gathered global options: (null) Mar 11 20:44:39 ipaclient01 automount[3236]: lookup_nss_read_master: reading master ldap auto.master Mar 11 20:44:39 ipaclient01 automount[3236]: parse_server_string: lookup(ldap): Attempting to parse LDAP information from string "auto.master". Mar 11 20:44:39 ipaclient01 automount[3236]: parse_server_string: lookup(ldap): mapname auto.master Mar 11 20:44:39 ipaclient01 automount[3236]: parse_ldap_config: lookup(ldap): ldap authentication configured with the following options: Mar 11 20:44:39 ipaclient01 automount[3236]: parse_ldap_config: lookup(ldap): use_tls: 0, tls_required: 0, auth_required: 2, sasl_mech: GSSAPI Mar 11 20:44:39 ipaclient01 automount[3236]: parse_ldap_config: lookup(ldap): user: (null), secret: unspecified, client principal: host/ipaclient01.ipa.domain.nx at IPA.DOMAIN.NX c redential cache: (null) Mar 11 20:44:39 ipaclient01 automount[3236]: parse_init: parse(sun): init gathered global options: (null) Mar 11 20:44:39 ipaclient01 automount[3236]: get_dc_list: Could not turn dn "ipa.domain.nx" into a domain Mar 11 20:44:39 ipaclient01 automount[3236]: do_reconnect: lookup(ldap): failed to find available server When I enter the LDAP_URI="kdc.ipa.domain.nx" with an specific search base, it works perfectly. Second question: is it normal that one has to restart the autofs service after adding an automount key in a direct map for the client to see it? If I do not do it, then the client does not see the new key so it cannot mount it either. Third question: is it safe to restart the autofs service when people have mounted shares on a client? Thanks in advance. -- Groeten, natxo -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbingram at gmail.com Sun Mar 11 20:22:50 2012 From: sbingram at gmail.com (Stephen Ingram) Date: Sun, 11 Mar 2012 13:22:50 -0700 Subject: [Freeipa-users] 2.1.90 rc1 testing on F17 alpha In-Reply-To: References: <20120311064907.GB32454@redhat.com> <20120311082029.GC32454@redhat.com> Message-ID: Now I've made it to the WebUI. Login works great (also via the new form auth). Click on IPA Server tab and then Configuration yields: IPA Error 4208 - get-effective-rights: missing subject: Invalid syntax This also happens at several other points in the UI. For example, click one DNS zone and then the Settings tab within, or the Hosts section within the Identity tab and clicking Settings. It seems that any attempt to configure settings yields this error. Directory server error logs point specifically to the NSACLPlugin: NSACLPlugin - get-effective-rights: missing subject Failed to get effective rights for entry (idnsname=17.168.192.in-addr.arpa.,cn=dns,dc=4test,dc=net), rc=21 I'm guessing some incorrect ACLs? Steve From Steven.Jones at vuw.ac.nz Sun Mar 11 21:45:47 2012 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Sun, 11 Mar 2012 21:45:47 +0000 Subject: [Freeipa-users] Winsync agreements, what happens if it breaks? Message-ID: <833D8E48405E064EBC54C84EC6B36E404CBDBD11@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, If I have a winsync agreement from AD to IPA, and this does uni-directional password from AD to IPA and for some reason this temporarily breaks, say a network failure..... 1) Is there a time limit to -re-establish before it becomes "stale"? 2_ Once the communications is functioning again will the differences catch up? say someone changes their AD password while the winsync was broken.....will it sync later anyway? regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 From dpal at redhat.com Sun Mar 11 21:53:54 2012 From: dpal at redhat.com (Dmitri Pal) Date: Sun, 11 Mar 2012 17:53:54 -0400 Subject: [Freeipa-users] 2.1.90 rc1 testing on F17 alpha In-Reply-To: References: <20120311064907.GB32454@redhat.com> <20120311082029.GC32454@redhat.com> Message-ID: <4F5D1EF2.8090206@redhat.com> On 03/11/2012 01:15 PM, Stephen Ingram wrote: > On Sun, Mar 11, 2012 at 12:20 AM, Alexander Bokovoy wrote: >> On Sat, 10 Mar 2012, Stephen Ingram wrote: > ...snip... > >> You are using RC1, we have released beta1 last week, it should include >> the fix: >> https://www.redhat.com/archives/freeipa-devel/2012-March/msg00087.html >> >> Could you please try beta1? > Sorry, I assumed that since F17 was still a work in progress that it > would have the latest version. Updating worked. One thing, the > uninstall program did not remove the lock file directory > (/run/lock/dirsrv), which for some reason was owned by > memcached:memcached. This caused the first install to fail. Maybe it's > a good idea for the install program to at least check permissions on > this directory? I know someone could be running another directory > instance, but pkisrv:dirsrv aren't the normal permissions either, no? > Known issue. Patch is on the list. > Steve > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Sun Mar 11 21:55:19 2012 From: dpal at redhat.com (Dmitri Pal) Date: Sun, 11 Mar 2012 17:55:19 -0400 Subject: [Freeipa-users] 2.1.90 rc1 testing on F17 alpha In-Reply-To: References: <20120311064907.GB32454@redhat.com> <20120311082029.GC32454@redhat.com> Message-ID: <4F5D1F47.9060903@redhat.com> On 03/11/2012 04:22 PM, Stephen Ingram wrote: > Now I've made it to the WebUI. Login works great (also via the new > form auth). Click on IPA Server tab and then Configuration yields: > > IPA Error 4208 - get-effective-rights: missing subject: Invalid syntax > > This also happens at several other points in the UI. For example, > click one DNS zone and then the Settings tab within, or the Hosts > section within the Identity tab and clicking Settings. It seems that > any attempt to configure settings yields this error. > > Directory server error logs point specifically to the NSACLPlugin: > > NSACLPlugin - get-effective-rights: missing subject > Failed to get effective rights for entry > (idnsname=17.168.192.in-addr.arpa.,cn=dns,dc=4test,dc=net), rc=21 > > I'm guessing some incorrect ACLs? > We will need to investigate. Petr, Martin any idea? > Steve > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From Steven.Jones at vuw.ac.nz Mon Mar 12 01:36:55 2012 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Mon, 12 Mar 2012 01:36:55 +0000 Subject: [Freeipa-users] Uni-directional agreements. Message-ID: <833D8E48405E064EBC54C84EC6B36E404CBDD5B7@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, Reading section 7.2...this looks like a bi-directional agreement.....I want to do a uni-directional agreement, so I want a one way password sync out of AD into IPA and when a new user is created that user get created in IPA and get an IPA UID. So can I set lower permissions? I would assume so.... "7.2. Setting up Active Directory for Synchronization Synchronizing user accounts alone is enabled within IPA, so all that is necessary is to set up a sync agreement (Section 7.3.2, ?Creating Synchronization Agreements?). On the Windows server, it is necessary to create the user that the IPA server will use to connect to the Active Directory domain. The process for creating a user in Active Directory is covered in the Windows server documentation at http://technet.microsoft.com/en-us/library/cc732336.aspx. The new user account must have the proper permissions: ? Grant the sync user account Replicating directory changes rights to the synchronized Active Directory subtree. Replicator rights are required for the sync user to perform synchronization operations. Replicator rights are described in http://support.microsoft.com/kb/303972. ? Add the sync user as a member of the Account Operator and Enterprise Read-Only Domain controller groups. It is not necessary for the user to belong to the full Domain Admin group." regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 From mkosek at redhat.com Mon Mar 12 07:34:22 2012 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 12 Mar 2012 08:34:22 +0100 Subject: [Freeipa-users] 2.1.90 rc1 testing on F17 alpha In-Reply-To: <4F5D1F47.9060903@redhat.com> References: <20120311064907.GB32454@redhat.com> <20120311082029.GC32454@redhat.com> <4F5D1F47.9060903@redhat.com> Message-ID: <1331537662.1491.6.camel@balmora.brq.redhat.com> On Sun, 2012-03-11 at 17:55 -0400, Dmitri Pal wrote: > On 03/11/2012 04:22 PM, Stephen Ingram wrote: > > Now I've made it to the WebUI. Login works great (also via the new > > form auth). Click on IPA Server tab and then Configuration yields: > > > > IPA Error 4208 - get-effective-rights: missing subject: Invalid syntax > > > > This also happens at several other points in the UI. For example, > > click one DNS zone and then the Settings tab within, or the Hosts > > section within the Identity tab and clicking Settings. It seems that > > any attempt to configure settings yields this error. > > > > Directory server error logs point specifically to the NSACLPlugin: > > > > NSACLPlugin - get-effective-rights: missing subject > > Failed to get effective rights for entry > > (idnsname=17.168.192.in-addr.arpa.,cn=dns,dc=4test,dc=net), rc=21 > > > > I'm guessing some incorrect ACLs? > > > > We will need to investigate. > Petr, Martin any idea? > Looks like 389-ds can't parse/read the ACI. Rich, has anything changed in this area in F-17? These should be the relevant ACIs: dn: $SUFFIX changetype: modify add: aci aci: (target = "ldap:///idnsname=*,cn=dns,$SUFFIX")(version 3.0;acl "permission:add dns entries";allow (add) groupdn = "ldap:///cn=add dns entries,cn=permissions,cn=pbac,$SUFFIX";) aci: (target = "ldap:///idnsname=*,cn=dns,$SUFFIX")(version 3.0;acl "permission:remove dns entries"; allow (delete) groupdn = "ldap:///cn=remove dns entries,cn=permissions,cn=pbac,$SUFFIX";) aci: (targetattr = "idnsname || cn || idnsallowdynupdate || dnsttl || dnsclass || arecord || aaaarecord || a6record || nsrecord || cnamerecord || ptrrecord || srvrecord || txtrecord || mxrecord || mdrecord || hinforecord || minforecord || afsdbrecord || sigrecord || keyrecord || locrecord || nxtrecord || naptrrecord || kxrecord || certrecord || dnamerecord || dsrecord || sshfprecord || rrsigrecord || nsecrecord || idnsname || idnszoneactive || idnssoamname || idnssoarname || idnssoaserial || idnssoarefresh || idnssoaretry || idnssoaexpire || idnssoaminimum || idnsupdatepolicy")(target = "ldap:///idnsname=*,cn=dns,$SUFFIX")(version 3.0;acl "permission:update dns entries";allow (write) groupdn = "ldap:///cn=update dns entries,cn=permissions,cn=pbac,$SUFFIX";) Thanks, Martin From ondrejv at s3group.cz Mon Mar 12 08:34:15 2012 From: ondrejv at s3group.cz (Ondrej Valousek) Date: Mon, 12 Mar 2012 09:34:15 +0100 Subject: [Freeipa-users] automount questions In-Reply-To: References: Message-ID: <4F5DB507.8050801@s3group.cz> Your LDAP_URI is incorrect. Please make sure you follow the documentation exactly. Perhaps you actually wanted to say: LDAP_URI="ldap:///dc=ipa,dc=domain,dc=nx" Alternatively, if you do not specify the LDAP_URI parameter at all, autofs will try SRV lookup against your default dnsdomain. Also, there is no nee for debugging automount with -d now, you can also try: automount -m which causes automount to dump all tables. Ondrej On 03/11/2012 09:09 PM, Natxo Asenjo wrote: > hi, > > First question: according to the docs in > http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/configuring-automount.html#Configuring_Automount-Configuring_autofs_on_Linux > when configuring autofs you can choose to enter LDAP_URI in two ways, the lazy on (+1) or the specific one. > > The 'lazy' one requires a srv record query, in the specific one one enters the ldap server we want to query. > > In my limited experience, the srv record query does not work., the other one does. > > This is the relevant piece of /etc/sysconfig/autofs config that does not work: > > LDAP_URI="ldap:///ipa.domain.nx" > > if I query this domain for an srv ldap record it works: > > [root at ipaclient01 sysconfig]# dig -t srv _ldap._tcp.ipa.domain.nx +short > 0 100 389 kdc.ipa.domain.nx. > > But autofs cannot find it: > > Mar 11 20:44:39 ipaclient01 automount[3236]: Starting automounter version 5.0.5-39.el6_2.1, master map auto.master > Mar 11 20:44:39 ipaclient01 automount[3236]: using kernel protocol version 5.02 > Mar 11 20:44:39 ipaclient01 automount[3236]: lookup_nss_read_master: reading master files auto.master > Mar 11 20:44:39 ipaclient01 automount[3236]: parse_init: parse(sun): init gathered global options: (null) > Mar 11 20:44:39 ipaclient01 automount[3236]: lookup_read_master: lookup(file): read entry /misc > Mar 11 20:44:39 ipaclient01 automount[3236]: lookup_read_master: lookup(file): read entry /net > Mar 11 20:44:39 ipaclient01 automount[3236]: lookup_read_master: lookup(file): read entry +auto.master > Mar 11 20:44:39 ipaclient01 automount[3236]: lookup_nss_read_master: reading master files auto.master > Mar 11 20:44:39 ipaclient01 automount[3236]: parse_init: parse(sun): init gathered global options: (null) > Mar 11 20:44:39 ipaclient01 automount[3236]: lookup_nss_read_master: reading master ldap auto.master > Mar 11 20:44:39 ipaclient01 automount[3236]: parse_server_string: lookup(ldap): Attempting to parse LDAP information from string > "auto.master". > Mar 11 20:44:39 ipaclient01 automount[3236]: parse_server_string: lookup(ldap): mapname auto.master > Mar 11 20:44:39 ipaclient01 automount[3236]: parse_ldap_config: lookup(ldap): ldap authentication configured with the following options: > Mar 11 20:44:39 ipaclient01 automount[3236]: parse_ldap_config: lookup(ldap): use_tls: 0, tls_required: 0, auth_required: 2, sasl_mech: GSSAPI > Mar 11 20:44:39 ipaclient01 automount[3236]: parse_ldap_config: lookup(ldap): user: (null), secret: unspecified, client principal: > host/ipaclient01.ipa.domain.nx at IPA.DOMAIN.NX c > redential cache: (null) > Mar 11 20:44:39 ipaclient01 automount[3236]: parse_init: parse(sun): init gathered global options: (null) > Mar 11 20:44:39 ipaclient01 automount[3236]: get_dc_list: Could not turn dn "ipa.domain.nx" into a domain > Mar 11 20:44:39 ipaclient01 automount[3236]: do_reconnect: lookup(ldap): failed to find available server > > When I enter the LDAP_URI="kdc.ipa.domain.nx" with an specific search base, it works perfectly. > > Second question: is it normal that one has to restart the autofs service after adding an automount key in a direct map for the client to > see it? If I do not do it, then the client does not see the new key so it cannot mount it either. > > Third question: is it safe to restart the autofs service when people have mounted shares on a client? > > Thanks in advance. > -- > Groeten, > natxo > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications at s3group.com. Thank You. Silicon and Software Systems Limited. Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Mon Mar 12 14:04:56 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 12 Mar 2012 10:04:56 -0400 Subject: [Freeipa-users] Winsync agreements, what happens if it breaks? In-Reply-To: <833D8E48405E064EBC54C84EC6B36E404CBDBD11@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E404CBDBD11@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <4F5E0288.3070900@redhat.com> Steven Jones wrote: > Hi, > > If I have a winsync agreement from AD to IPA, and this does uni-directional password from AD to IPA and for some reason this temporarily breaks, say a network failure..... winsync doesn't do password changes, passsync does. > 1) Is there a time limit to -re-establish before it becomes "stale"? I believe it will try forever. > 2_ Once the communications is functioning again will the differences catch up? say someone changes their AD password while the winsync was broken.....will it sync later anyway? winsync uses a pull model so yeah, once the connection is made it will catch up to any AD changes made and will forward any applicable IPA-side changes. I believe there is a cap on the either the number of age of changes that 389-ds replication will store, which I believe is configurable. I believe the passsync service will retry, I'm not sure how many times, etc. Rich may know. rob From rmeggins at redhat.com Mon Mar 12 14:18:06 2012 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 12 Mar 2012 08:18:06 -0600 Subject: [Freeipa-users] Winsync agreements, what happens if it breaks? In-Reply-To: <833D8E48405E064EBC54C84EC6B36E404CBDBD11@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E404CBDBD11@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <4F5E059E.9070700@redhat.com> On 03/11/2012 03:45 PM, Steven Jones wrote: > Hi, > > If I have a winsync agreement from AD to IPA, and this does uni-directional password from AD to IPA and for some reason this temporarily breaks, say a network failure..... If you are talking about password sync from AD to IPA, and only that, then this is only concerning the PassSync service you install on your AD domain controllers > > 1) Is there a time limit to -re-establish before it becomes "stale"? No. It will keep trying indefinitely. > > 2_ Once the communications is functioning again will the differences catch up? Yes. > say someone changes their AD password while the winsync was broken.....will it sync later anyway? It depends on what you mean by "broken". If the PassSync service is not running, then no password changes will be stored, so none will be replayed. > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From rmeggins at redhat.com Mon Mar 12 14:19:55 2012 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 12 Mar 2012 08:19:55 -0600 Subject: [Freeipa-users] 2.1.90 rc1 testing on F17 alpha In-Reply-To: <1331537662.1491.6.camel@balmora.brq.redhat.com> References: <20120311064907.GB32454@redhat.com> <20120311082029.GC32454@redhat.com> <4F5D1F47.9060903@redhat.com> <1331537662.1491.6.camel@balmora.brq.redhat.com> Message-ID: <4F5E060B.7070306@redhat.com> On 03/12/2012 01:34 AM, Martin Kosek wrote: > On Sun, 2012-03-11 at 17:55 -0400, Dmitri Pal wrote: >> On 03/11/2012 04:22 PM, Stephen Ingram wrote: >>> Now I've made it to the WebUI. Login works great (also via the new >>> form auth). Click on IPA Server tab and then Configuration yields: >>> >>> IPA Error 4208 - get-effective-rights: missing subject: Invalid syntax >>> >>> This also happens at several other points in the UI. For example, >>> click one DNS zone and then the Settings tab within, or the Hosts >>> section within the Identity tab and clicking Settings. It seems that >>> any attempt to configure settings yields this error. >>> >>> Directory server error logs point specifically to the NSACLPlugin: >>> >>> NSACLPlugin - get-effective-rights: missing subject >>> Failed to get effective rights for entry >>> (idnsname=17.168.192.in-addr.arpa.,cn=dns,dc=4test,dc=net), rc=21 >>> >>> I'm guessing some incorrect ACLs? >>> >> We will need to investigate. >> Petr, Martin any idea? >> > Looks like 389-ds can't parse/read the ACI. Rich, has anything changed > in this area in F-17? F-17? Nothing specific to F-17. Is this error with the latest 1.2.10.2 or .3 in F-17 updates or updates-testing? > These should be the relevant ACIs: > > dn: $SUFFIX > changetype: modify > add: aci > aci: (target = "ldap:///idnsname=*,cn=dns,$SUFFIX")(version 3.0;acl "permission:add dns entries";allow (add) groupdn = "ldap:///cn=add dns entries,cn=permissions,cn=pbac,$SUFFIX";) > aci: (target = "ldap:///idnsname=*,cn=dns,$SUFFIX")(version 3.0;acl "permission:remove dns entries"; allow (delete) groupdn = "ldap:///cn=remove dns entries,cn=permissions,cn=pbac,$SUFFIX";) > aci: (targetattr = "idnsname || cn || idnsallowdynupdate || dnsttl || dnsclass || arecord || aaaarecord || a6record || nsrecord || cnamerecord || ptrrecord || srvrecord || txtrecord || mxrecord || mdrecord || hinforecord || minforecord || afsdbrecord || sigrecord || keyrecord || locrecord || nxtrecord || naptrrecord || kxrecord || certrecord || dnamerecord || dsrecord || sshfprecord || rrsigrecord || nsecrecord || idnsname || idnszoneactive || idnssoamname || idnssoarname || idnssoaserial || idnssoarefresh || idnssoaretry || idnssoaexpire || idnssoaminimum || idnsupdatepolicy")(target = "ldap:///idnsname=*,cn=dns,$SUFFIX")(version 3.0;acl "permission:update dns entries";allow (write) groupdn = "ldap:///cn=update dns entries,cn=permissions,cn=pbac,$SUFFIX";) > > Thanks, > Martin > From natxo.asenjo at gmail.com Mon Mar 12 16:28:36 2012 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Mon, 12 Mar 2012 17:28:36 +0100 Subject: [Freeipa-users] automount questions In-Reply-To: <4F5DB507.8050801@s3group.cz> References: <4F5DB507.8050801@s3group.cz> Message-ID: On Mon, Mar 12, 2012 at 9:34 AM, Ondrej Valousek wrote: > Your LDAP_URI is incorrect. Please make sure you follow the documentation > exactly. > Perhaps you actually wanted to say: > > LDAP_URI="ldap:///dc=ipa,dc=domain,dc=nx" > argh, you're right. But .. if I do not specify a ldap search base, it still does not work. With a search base it works great. I can live with this :-) > Alternatively, if you do not specify the LDAP_URI parameter at all, autofs > will try SRV lookup against your default dnsdomain. > Also, there is no nee for debugging automount with -d now, you can also > try: > > automount -m > > which causes automount to dump all tables. > awesoeme! Thanks for the tip. -- natxo -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Mon Mar 12 16:42:07 2012 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 12 Mar 2012 17:42:07 +0100 Subject: [Freeipa-users] automount questions In-Reply-To: References: Message-ID: <20120312164206.GF18789@zeppelin.brq.redhat.com> I wasn't sure about these two questions so I went ahead and asked the Red Hat autofs maintainer -- I don't think he follows this list. Below are his replies. On Sun, Mar 11, 2012 at 09:09:17PM +0100, Natxo Asenjo wrote: > Second question: is it normal that one has to restart the autofs service > after adding an automount key in a direct map for the client to see it? If > I do not do it, then the client does not see the new key so it cannot > mount it either. > You need to send SIGHUP to the deamon to force rereading of a map. When I was working on the autofs/sssd integration effort, we spoke briefly with Ian about possibilities of better ways to reread a map, but nothing has surfaced yet. > Third question: is it safe to restart the autofs service when people have > mounted shares on a client? The short answer is yes, long answer is it depends :-) While the mounts that are currently active will continue and will be completely unaware of the autofs service restart, the automounter deamon will not be servicing requests until it processes the maps again after a restart. From sbingram at gmail.com Mon Mar 12 17:06:50 2012 From: sbingram at gmail.com (Stephen Ingram) Date: Mon, 12 Mar 2012 10:06:50 -0700 Subject: [Freeipa-users] 2.1.90 rc1 testing on F17 alpha In-Reply-To: <4F5E060B.7070306@redhat.com> References: <20120311064907.GB32454@redhat.com> <20120311082029.GC32454@redhat.com> <4F5D1F47.9060903@redhat.com> <1331537662.1491.6.camel@balmora.brq.redhat.com> <4F5E060B.7070306@redhat.com> Message-ID: On Mon, Mar 12, 2012 at 7:19 AM, Rich Megginson wrote: > On 03/12/2012 01:34 AM, Martin Kosek wrote: >> >> On Sun, 2012-03-11 at 17:55 -0400, Dmitri Pal wrote: >>> >>> On 03/11/2012 04:22 PM, Stephen Ingram wrote: >>>> >>>> Now I've made it to the WebUI. Login works great (also via the new >>>> form auth). Click on IPA Server tab and then Configuration yields: >>>> >>>> IPA Error 4208 - get-effective-rights: missing subject: Invalid syntax >>>> >>>> This also happens at several other points in the UI. For example, >>>> click one DNS zone and then the Settings tab within, or the Hosts >>>> section within the Identity tab and clicking Settings. It seems that >>>> any attempt to configure settings yields this error. >>>> >>>> Directory server error logs point specifically to the NSACLPlugin: >>>> >>>> NSACLPlugin - get-effective-rights: missing subject >>>> Failed to get effective rights for entry >>>> (idnsname=17.168.192.in-addr.arpa.,cn=dns,dc=4test,dc=net), rc=21 >>>> >>>> I'm guessing some incorrect ACLs? >>>> >>> We will need to investigate. >>> Petr, Martin any idea? >>> >> Looks like 389-ds can't parse/read the ACI. Rich, has anything changed >> in this area in F-17? > > F-17? ?Nothing specific to F-17. ?Is this error with the latest 1.2.10.2 or > .3 in F-17 updates or updates-testing? I'm using 1.2.10.3 from the fedora 17 updates repo. IPA is from freeipa-devel repo. > >> These should be the relevant ACIs: >> >> dn: $SUFFIX >> changetype: modify >> add: aci >> aci: (target = "ldap:///idnsname=*,cn=dns,$SUFFIX")(version 3.0;acl >> "permission:add dns entries";allow (add) groupdn = "ldap:///cn=add dns >> entries,cn=permissions,cn=pbac,$SUFFIX";) >> aci: (target = "ldap:///idnsname=*,cn=dns,$SUFFIX")(version 3.0;acl >> "permission:remove dns entries"; ? allow (delete) groupdn = >> "ldap:///cn=remove dns entries,cn=permissions,cn=pbac,$SUFFIX";) >> aci: (targetattr = "idnsname || cn || idnsallowdynupdate || dnsttl || >> dnsclass || arecord || ? ? ? ? ? aaaarecord || a6record || nsrecord || >> cnamerecord || ptrrecord || srvrecord || txtrecord || mxrecord ? || mdrecord >> || hinforecord || minforecord || afsdbrecord || sigrecord || keyrecord || >> locrecord || ? ? nxtrecord || naptrrecord || kxrecord || certrecord || >> dnamerecord || dsrecord || sshfprecord || ? ? ? ?rrsigrecord || nsecrecord >> || idnsname || idnszoneactive || idnssoamname || idnssoarname || >> idnssoaserial || idnssoarefresh || idnssoaretry || idnssoaexpire || >> idnssoaminimum || ? ? ? ? ? ? ? ? ?idnsupdatepolicy")(target = >> "ldap:///idnsname=*,cn=dns,$SUFFIX")(version 3.0;acl "permission:update >> ?dns entries";allow (write) groupdn = "ldap:///cn=update dns >> entries,cn=permissions,cn=pbac,$SUFFIX";) Steve From rmeggins at redhat.com Mon Mar 12 17:23:09 2012 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 12 Mar 2012 11:23:09 -0600 Subject: [Freeipa-users] 2.1.90 rc1 testing on F17 alpha In-Reply-To: References: <20120311064907.GB32454@redhat.com> <20120311082029.GC32454@redhat.com> <4F5D1F47.9060903@redhat.com> <1331537662.1491.6.camel@balmora.brq.redhat.com> <4F5E060B.7070306@redhat.com> Message-ID: <4F5E30FD.6000406@redhat.com> On 03/12/2012 11:06 AM, Stephen Ingram wrote: > On Mon, Mar 12, 2012 at 7:19 AM, Rich Megginson wrote: >> On 03/12/2012 01:34 AM, Martin Kosek wrote: >>> On Sun, 2012-03-11 at 17:55 -0400, Dmitri Pal wrote: >>>> On 03/11/2012 04:22 PM, Stephen Ingram wrote: >>>>> Now I've made it to the WebUI. Login works great (also via the new >>>>> form auth). Click on IPA Server tab and then Configuration yields: >>>>> >>>>> IPA Error 4208 - get-effective-rights: missing subject: Invalid syntax >>>>> >>>>> This also happens at several other points in the UI. For example, >>>>> click one DNS zone and then the Settings tab within, or the Hosts >>>>> section within the Identity tab and clicking Settings. It seems that >>>>> any attempt to configure settings yields this error. >>>>> >>>>> Directory server error logs point specifically to the NSACLPlugin: >>>>> >>>>> NSACLPlugin - get-effective-rights: missing subject >>>>> Failed to get effective rights for entry >>>>> (idnsname=17.168.192.in-addr.arpa.,cn=dns,dc=4test,dc=net), rc=21 >>>>> >>>>> I'm guessing some incorrect ACLs? >>>>> >>>> We will need to investigate. >>>> Petr, Martin any idea? >>>> >>> Looks like 389-ds can't parse/read the ACI. Rich, has anything changed >>> in this area in F-17? >> F-17? Nothing specific to F-17. Is this error with the latest 1.2.10.2 or >> .3 in F-17 updates or updates-testing? > I'm using 1.2.10.3 from the fedora 17 updates repo. IPA is from > freeipa-devel repo. This error means there is an empty GER control value sent with the request. Did the client code change recently? ipaserver/plugins/ldap2.py get_effective_rights() looks correct > >>> These should be the relevant ACIs: >>> >>> dn: $SUFFIX >>> changetype: modify >>> add: aci >>> aci: (target = "ldap:///idnsname=*,cn=dns,$SUFFIX")(version 3.0;acl >>> "permission:add dns entries";allow (add) groupdn = "ldap:///cn=add dns >>> entries,cn=permissions,cn=pbac,$SUFFIX";) >>> aci: (target = "ldap:///idnsname=*,cn=dns,$SUFFIX")(version 3.0;acl >>> "permission:remove dns entries"; allow (delete) groupdn = >>> "ldap:///cn=remove dns entries,cn=permissions,cn=pbac,$SUFFIX";) >>> aci: (targetattr = "idnsname || cn || idnsallowdynupdate || dnsttl || >>> dnsclass || arecord || aaaarecord || a6record || nsrecord || >>> cnamerecord || ptrrecord || srvrecord || txtrecord || mxrecord || mdrecord >>> || hinforecord || minforecord || afsdbrecord || sigrecord || keyrecord || >>> locrecord || nxtrecord || naptrrecord || kxrecord || certrecord || >>> dnamerecord || dsrecord || sshfprecord || rrsigrecord || nsecrecord >>> || idnsname || idnszoneactive || idnssoamname || idnssoarname || >>> idnssoaserial || idnssoarefresh || idnssoaretry || idnssoaexpire || >>> idnssoaminimum || idnsupdatepolicy")(target = >>> "ldap:///idnsname=*,cn=dns,$SUFFIX")(version 3.0;acl "permission:update >>> dns entries";allow (write) groupdn = "ldap:///cn=update dns >>> entries,cn=permissions,cn=pbac,$SUFFIX";) > Steve From dpal at redhat.com Mon Mar 12 18:40:24 2012 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 12 Mar 2012 14:40:24 -0400 Subject: [Freeipa-users] 2.1.90 rc1 testing on F17 alpha In-Reply-To: <4F5E30FD.6000406@redhat.com> References: <20120311064907.GB32454@redhat.com> <20120311082029.GC32454@redhat.com> <4F5D1F47.9060903@redhat.com> <1331537662.1491.6.camel@balmora.brq.redhat.com> <4F5E060B.7070306@redhat.com> <4F5E30FD.6000406@redhat.com> Message-ID: <4F5E4318.9060701@redhat.com> On 03/12/2012 01:23 PM, Rich Megginson wrote: > On 03/12/2012 11:06 AM, Stephen Ingram wrote: >> On Mon, Mar 12, 2012 at 7:19 AM, Rich Megginson >> wrote: >>> On 03/12/2012 01:34 AM, Martin Kosek wrote: >>>> On Sun, 2012-03-11 at 17:55 -0400, Dmitri Pal wrote: >>>>> On 03/11/2012 04:22 PM, Stephen Ingram wrote: >>>>>> Now I've made it to the WebUI. Login works great (also via the new >>>>>> form auth). Click on IPA Server tab and then Configuration yields: >>>>>> >>>>>> IPA Error 4208 - get-effective-rights: missing subject: Invalid >>>>>> syntax >>>>>> >>>>>> This also happens at several other points in the UI. For example, >>>>>> click one DNS zone and then the Settings tab within, or the Hosts >>>>>> section within the Identity tab and clicking Settings. It seems that >>>>>> any attempt to configure settings yields this error. >>>>>> >>>>>> Directory server error logs point specifically to the NSACLPlugin: >>>>>> >>>>>> NSACLPlugin - get-effective-rights: missing subject >>>>>> Failed to get effective rights for entry >>>>>> (idnsname=17.168.192.in-addr.arpa.,cn=dns,dc=4test,dc=net), rc=21 >>>>>> >>>>>> I'm guessing some incorrect ACLs? >>>>>> >>>>> We will need to investigate. >>>>> Petr, Martin any idea? >>>>> >>>> Looks like 389-ds can't parse/read the ACI. Rich, has anything changed >>>> in this area in F-17? >>> F-17? Nothing specific to F-17. Is this error with the latest >>> 1.2.10.2 or >>> .3 in F-17 updates or updates-testing? >> I'm using 1.2.10.3 from the fedora 17 updates repo. IPA is from >> freeipa-devel repo. > This error means there is an empty GER control value sent with the > request. Did the client code change recently? > ipaserver/plugins/ldap2.py get_effective_rights() looks correct openldap? >> >>>> These should be the relevant ACIs: >>>> >>>> dn: $SUFFIX >>>> changetype: modify >>>> add: aci >>>> aci: (target = "ldap:///idnsname=*,cn=dns,$SUFFIX")(version 3.0;acl >>>> "permission:add dns entries";allow (add) groupdn = "ldap:///cn=add dns >>>> entries,cn=permissions,cn=pbac,$SUFFIX";) >>>> aci: (target = "ldap:///idnsname=*,cn=dns,$SUFFIX")(version 3.0;acl >>>> "permission:remove dns entries"; allow (delete) groupdn = >>>> "ldap:///cn=remove dns entries,cn=permissions,cn=pbac,$SUFFIX";) >>>> aci: (targetattr = "idnsname || cn || idnsallowdynupdate || dnsttl || >>>> dnsclass || arecord || aaaarecord || a6record || nsrecord || >>>> cnamerecord || ptrrecord || srvrecord || txtrecord || mxrecord || >>>> mdrecord >>>> || hinforecord || minforecord || afsdbrecord || sigrecord || >>>> keyrecord || >>>> locrecord || nxtrecord || naptrrecord || kxrecord || certrecord || >>>> dnamerecord || dsrecord || sshfprecord || rrsigrecord || >>>> nsecrecord >>>> || idnsname || idnszoneactive || idnssoamname || idnssoarname || >>>> idnssoaserial || idnssoarefresh || idnssoaretry || idnssoaexpire || >>>> idnssoaminimum || idnsupdatepolicy")(target = >>>> "ldap:///idnsname=*,cn=dns,$SUFFIX")(version 3.0;acl >>>> "permission:update >>>> dns entries";allow (write) groupdn = "ldap:///cn=update dns >>>> entries,cn=permissions,cn=pbac,$SUFFIX";) >> Steve > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rmeggins at redhat.com Mon Mar 12 19:20:02 2012 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 12 Mar 2012 13:20:02 -0600 Subject: [Freeipa-users] 2.1.90 rc1 testing on F17 alpha In-Reply-To: <4F5E4318.9060701@redhat.com> References: <20120311064907.GB32454@redhat.com> <20120311082029.GC32454@redhat.com> <4F5D1F47.9060903@redhat.com> <1331537662.1491.6.camel@balmora.brq.redhat.com> <4F5E060B.7070306@redhat.com> <4F5E30FD.6000406@redhat.com> <4F5E4318.9060701@redhat.com> Message-ID: <4F5E4C62.1040302@redhat.com> On 03/12/2012 12:40 PM, Dmitri Pal wrote: > On 03/12/2012 01:23 PM, Rich Megginson wrote: >> On 03/12/2012 11:06 AM, Stephen Ingram wrote: >>> On Mon, Mar 12, 2012 at 7:19 AM, Rich Megginson >>> wrote: >>>> On 03/12/2012 01:34 AM, Martin Kosek wrote: >>>>> On Sun, 2012-03-11 at 17:55 -0400, Dmitri Pal wrote: >>>>>> On 03/11/2012 04:22 PM, Stephen Ingram wrote: >>>>>>> Now I've made it to the WebUI. Login works great (also via the new >>>>>>> form auth). Click on IPA Server tab and then Configuration yields: >>>>>>> >>>>>>> IPA Error 4208 - get-effective-rights: missing subject: Invalid >>>>>>> syntax >>>>>>> >>>>>>> This also happens at several other points in the UI. For example, >>>>>>> click one DNS zone and then the Settings tab within, or the Hosts >>>>>>> section within the Identity tab and clicking Settings. It seems that >>>>>>> any attempt to configure settings yields this error. >>>>>>> >>>>>>> Directory server error logs point specifically to the NSACLPlugin: >>>>>>> >>>>>>> NSACLPlugin - get-effective-rights: missing subject >>>>>>> Failed to get effective rights for entry >>>>>>> (idnsname=17.168.192.in-addr.arpa.,cn=dns,dc=4test,dc=net), rc=21 >>>>>>> >>>>>>> I'm guessing some incorrect ACLs? >>>>>>> >>>>>> We will need to investigate. >>>>>> Petr, Martin any idea? >>>>>> >>>>> Looks like 389-ds can't parse/read the ACI. Rich, has anything changed >>>>> in this area in F-17? >>>> F-17? Nothing specific to F-17. Is this error with the latest >>>> 1.2.10.2 or >>>> .3 in F-17 updates or updates-testing? >>> I'm using 1.2.10.3 from the fedora 17 updates repo. IPA is from >>> freeipa-devel repo. >> This error means there is an empty GER control value sent with the >> request. Did the client code change recently? >> ipaserver/plugins/ldap2.py get_effective_rights() looks correct > > openldap? could be - or could be python-ldap related - python-ldap 2.4 switched to using pyasn1 to do some encoding that used to be done by the ldap library. > >>>>> These should be the relevant ACIs: >>>>> >>>>> dn: $SUFFIX >>>>> changetype: modify >>>>> add: aci >>>>> aci: (target = "ldap:///idnsname=*,cn=dns,$SUFFIX")(version 3.0;acl >>>>> "permission:add dns entries";allow (add) groupdn = "ldap:///cn=add dns >>>>> entries,cn=permissions,cn=pbac,$SUFFIX";) >>>>> aci: (target = "ldap:///idnsname=*,cn=dns,$SUFFIX")(version 3.0;acl >>>>> "permission:remove dns entries"; allow (delete) groupdn = >>>>> "ldap:///cn=remove dns entries,cn=permissions,cn=pbac,$SUFFIX";) >>>>> aci: (targetattr = "idnsname || cn || idnsallowdynupdate || dnsttl || >>>>> dnsclass || arecord || aaaarecord || a6record || nsrecord || >>>>> cnamerecord || ptrrecord || srvrecord || txtrecord || mxrecord || >>>>> mdrecord >>>>> || hinforecord || minforecord || afsdbrecord || sigrecord || >>>>> keyrecord || >>>>> locrecord || nxtrecord || naptrrecord || kxrecord || certrecord || >>>>> dnamerecord || dsrecord || sshfprecord || rrsigrecord || >>>>> nsecrecord >>>>> || idnsname || idnszoneactive || idnssoamname || idnssoarname || >>>>> idnssoaserial || idnssoarefresh || idnssoaretry || idnssoaexpire || >>>>> idnssoaminimum || idnsupdatepolicy")(target = >>>>> "ldap:///idnsname=*,cn=dns,$SUFFIX")(version 3.0;acl >>>>> "permission:update >>>>> dns entries";allow (write) groupdn = "ldap:///cn=update dns >>>>> entries,cn=permissions,cn=pbac,$SUFFIX";) >>> Steve >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > From dpal at redhat.com Mon Mar 12 19:39:44 2012 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 12 Mar 2012 15:39:44 -0400 Subject: [Freeipa-users] 2.1.90 rc1 testing on F17 alpha In-Reply-To: <4F5E4C62.1040302@redhat.com> References: <20120311064907.GB32454@redhat.com> <20120311082029.GC32454@redhat.com> <4F5D1F47.9060903@redhat.com> <1331537662.1491.6.camel@balmora.brq.redhat.com> <4F5E060B.7070306@redhat.com> <4F5E30FD.6000406@redhat.com> <4F5E4318.9060701@redhat.com> <4F5E4C62.1040302@redhat.com> Message-ID: <4F5E5100.4010200@redhat.com> On 03/12/2012 03:20 PM, Rich Megginson wrote: > On 03/12/2012 12:40 PM, Dmitri Pal wrote: >> On 03/12/2012 01:23 PM, Rich Megginson wrote: >>> On 03/12/2012 11:06 AM, Stephen Ingram wrote: >>>> On Mon, Mar 12, 2012 at 7:19 AM, Rich Megginson >>>> wrote: >>>>> On 03/12/2012 01:34 AM, Martin Kosek wrote: >>>>>> On Sun, 2012-03-11 at 17:55 -0400, Dmitri Pal wrote: >>>>>>> On 03/11/2012 04:22 PM, Stephen Ingram wrote: >>>>>>>> Now I've made it to the WebUI. Login works great (also via the new >>>>>>>> form auth). Click on IPA Server tab and then Configuration yields: >>>>>>>> >>>>>>>> IPA Error 4208 - get-effective-rights: missing subject: Invalid >>>>>>>> syntax >>>>>>>> >>>>>>>> This also happens at several other points in the UI. For example, >>>>>>>> click one DNS zone and then the Settings tab within, or the Hosts >>>>>>>> section within the Identity tab and clicking Settings. It seems >>>>>>>> that >>>>>>>> any attempt to configure settings yields this error. >>>>>>>> >>>>>>>> Directory server error logs point specifically to the NSACLPlugin: >>>>>>>> >>>>>>>> NSACLPlugin - get-effective-rights: missing subject >>>>>>>> Failed to get effective rights for entry >>>>>>>> (idnsname=17.168.192.in-addr.arpa.,cn=dns,dc=4test,dc=net), rc=21 >>>>>>>> >>>>>>>> I'm guessing some incorrect ACLs? >>>>>>>> >>>>>>> We will need to investigate. >>>>>>> Petr, Martin any idea? >>>>>>> >>>>>> Looks like 389-ds can't parse/read the ACI. Rich, has anything >>>>>> changed >>>>>> in this area in F-17? >>>>> F-17? Nothing specific to F-17. Is this error with the latest >>>>> 1.2.10.2 or >>>>> .3 in F-17 updates or updates-testing? >>>> I'm using 1.2.10.3 from the fedora 17 updates repo. IPA is from >>>> freeipa-devel repo. >>> This error means there is an empty GER control value sent with the >>> request. Did the client code change recently? >>> ipaserver/plugins/ldap2.py get_effective_rights() looks correct >> >> openldap? > could be - or could be python-ldap related - python-ldap 2.4 switched > to using pyasn1 to do some encoding that used to be done by the ldap > library. How can we check? >> >>>>>> These should be the relevant ACIs: >>>>>> >>>>>> dn: $SUFFIX >>>>>> changetype: modify >>>>>> add: aci >>>>>> aci: (target = "ldap:///idnsname=*,cn=dns,$SUFFIX")(version 3.0;acl >>>>>> "permission:add dns entries";allow (add) groupdn = >>>>>> "ldap:///cn=add dns >>>>>> entries,cn=permissions,cn=pbac,$SUFFIX";) >>>>>> aci: (target = "ldap:///idnsname=*,cn=dns,$SUFFIX")(version 3.0;acl >>>>>> "permission:remove dns entries"; allow (delete) groupdn = >>>>>> "ldap:///cn=remove dns entries,cn=permissions,cn=pbac,$SUFFIX";) >>>>>> aci: (targetattr = "idnsname || cn || idnsallowdynupdate || >>>>>> dnsttl || >>>>>> dnsclass || arecord || aaaarecord || a6record || >>>>>> nsrecord || >>>>>> cnamerecord || ptrrecord || srvrecord || txtrecord || mxrecord || >>>>>> mdrecord >>>>>> || hinforecord || minforecord || afsdbrecord || sigrecord || >>>>>> keyrecord || >>>>>> locrecord || nxtrecord || naptrrecord || kxrecord || >>>>>> certrecord || >>>>>> dnamerecord || dsrecord || sshfprecord || rrsigrecord || >>>>>> nsecrecord >>>>>> || idnsname || idnszoneactive || idnssoamname || idnssoarname || >>>>>> idnssoaserial || idnssoarefresh || idnssoaretry || idnssoaexpire || >>>>>> idnssoaminimum || idnsupdatepolicy")(target = >>>>>> "ldap:///idnsname=*,cn=dns,$SUFFIX")(version 3.0;acl >>>>>> "permission:update >>>>>> dns entries";allow (write) groupdn = "ldap:///cn=update dns >>>>>> entries,cn=permissions,cn=pbac,$SUFFIX";) >>>> Steve >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >> > -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rmeggins at redhat.com Mon Mar 12 19:41:48 2012 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 12 Mar 2012 13:41:48 -0600 Subject: [Freeipa-users] 2.1.90 rc1 testing on F17 alpha In-Reply-To: <4F5E5100.4010200@redhat.com> References: <20120311064907.GB32454@redhat.com> <20120311082029.GC32454@redhat.com> <4F5D1F47.9060903@redhat.com> <1331537662.1491.6.camel@balmora.brq.redhat.com> <4F5E060B.7070306@redhat.com> <4F5E30FD.6000406@redhat.com> <4F5E4318.9060701@redhat.com> <4F5E4C62.1040302@redhat.com> <4F5E5100.4010200@redhat.com> Message-ID: <4F5E517C.1010501@redhat.com> On 03/12/2012 01:39 PM, Dmitri Pal wrote: > On 03/12/2012 03:20 PM, Rich Megginson wrote: >> On 03/12/2012 12:40 PM, Dmitri Pal wrote: >>> On 03/12/2012 01:23 PM, Rich Megginson wrote: >>>> On 03/12/2012 11:06 AM, Stephen Ingram wrote: >>>>> On Mon, Mar 12, 2012 at 7:19 AM, Rich Megginson >>>>> wrote: >>>>>> On 03/12/2012 01:34 AM, Martin Kosek wrote: >>>>>>> On Sun, 2012-03-11 at 17:55 -0400, Dmitri Pal wrote: >>>>>>>> On 03/11/2012 04:22 PM, Stephen Ingram wrote: >>>>>>>>> Now I've made it to the WebUI. Login works great (also via the new >>>>>>>>> form auth). Click on IPA Server tab and then Configuration yields: >>>>>>>>> >>>>>>>>> IPA Error 4208 - get-effective-rights: missing subject: Invalid >>>>>>>>> syntax >>>>>>>>> >>>>>>>>> This also happens at several other points in the UI. For example, >>>>>>>>> click one DNS zone and then the Settings tab within, or the Hosts >>>>>>>>> section within the Identity tab and clicking Settings. It seems >>>>>>>>> that >>>>>>>>> any attempt to configure settings yields this error. >>>>>>>>> >>>>>>>>> Directory server error logs point specifically to the NSACLPlugin: >>>>>>>>> >>>>>>>>> NSACLPlugin - get-effective-rights: missing subject >>>>>>>>> Failed to get effective rights for entry >>>>>>>>> (idnsname=17.168.192.in-addr.arpa.,cn=dns,dc=4test,dc=net), rc=21 >>>>>>>>> >>>>>>>>> I'm guessing some incorrect ACLs? >>>>>>>>> >>>>>>>> We will need to investigate. >>>>>>>> Petr, Martin any idea? >>>>>>>> >>>>>>> Looks like 389-ds can't parse/read the ACI. Rich, has anything >>>>>>> changed >>>>>>> in this area in F-17? >>>>>> F-17? Nothing specific to F-17. Is this error with the latest >>>>>> 1.2.10.2 or >>>>>> .3 in F-17 updates or updates-testing? >>>>> I'm using 1.2.10.3 from the fedora 17 updates repo. IPA is from >>>>> freeipa-devel repo. >>>> This error means there is an empty GER control value sent with the >>>> request. Did the client code change recently? >>>> ipaserver/plugins/ldap2.py get_effective_rights() looks correct >>> openldap? >> could be - or could be python-ldap related - python-ldap 2.4 switched >> to using pyasn1 to do some encoding that used to be done by the ldap >> library. > How can we check? You can use the debug flag in python-ldap when creating the ldap connection > >>>>>>> These should be the relevant ACIs: >>>>>>> >>>>>>> dn: $SUFFIX >>>>>>> changetype: modify >>>>>>> add: aci >>>>>>> aci: (target = "ldap:///idnsname=*,cn=dns,$SUFFIX")(version 3.0;acl >>>>>>> "permission:add dns entries";allow (add) groupdn = >>>>>>> "ldap:///cn=add dns >>>>>>> entries,cn=permissions,cn=pbac,$SUFFIX";) >>>>>>> aci: (target = "ldap:///idnsname=*,cn=dns,$SUFFIX")(version 3.0;acl >>>>>>> "permission:remove dns entries"; allow (delete) groupdn = >>>>>>> "ldap:///cn=remove dns entries,cn=permissions,cn=pbac,$SUFFIX";) >>>>>>> aci: (targetattr = "idnsname || cn || idnsallowdynupdate || >>>>>>> dnsttl || >>>>>>> dnsclass || arecord || aaaarecord || a6record || >>>>>>> nsrecord || >>>>>>> cnamerecord || ptrrecord || srvrecord || txtrecord || mxrecord || >>>>>>> mdrecord >>>>>>> || hinforecord || minforecord || afsdbrecord || sigrecord || >>>>>>> keyrecord || >>>>>>> locrecord || nxtrecord || naptrrecord || kxrecord || >>>>>>> certrecord || >>>>>>> dnamerecord || dsrecord || sshfprecord || rrsigrecord || >>>>>>> nsecrecord >>>>>>> || idnsname || idnszoneactive || idnssoamname || idnssoarname || >>>>>>> idnssoaserial || idnssoarefresh || idnssoaretry || idnssoaexpire || >>>>>>> idnssoaminimum || idnsupdatepolicy")(target = >>>>>>> "ldap:///idnsname=*,cn=dns,$SUFFIX")(version 3.0;acl >>>>>>> "permission:update >>>>>>> dns entries";allow (write) groupdn = "ldap:///cn=update dns >>>>>>> entries,cn=permissions,cn=pbac,$SUFFIX";) >>>>> Steve >>>> _______________________________________________ >>>> Freeipa-users mailing list >>>> Freeipa-users at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-users > From sbingram at gmail.com Mon Mar 12 19:46:25 2012 From: sbingram at gmail.com (Stephen Ingram) Date: Mon, 12 Mar 2012 12:46:25 -0700 Subject: [Freeipa-users] 2.1.90 rc1 testing on F17 alpha In-Reply-To: <1331537662.1491.6.camel@balmora.brq.redhat.com> References: <20120311064907.GB32454@redhat.com> <20120311082029.GC32454@redhat.com> <4F5D1F47.9060903@redhat.com> <1331537662.1491.6.camel@balmora.brq.redhat.com> Message-ID: On Mon, Mar 12, 2012 at 12:34 AM, Martin Kosek wrote: > On Sun, 2012-03-11 at 17:55 -0400, Dmitri Pal wrote: >> On 03/11/2012 04:22 PM, Stephen Ingram wrote: >> > Now I've made it to the WebUI. Login works great (also via the new >> > form auth). Click on IPA Server tab and then Configuration yields: >> > >> > IPA Error 4208 - get-effective-rights: missing subject: Invalid syntax >> > >> > This also happens at several other points in the UI. For example, >> > click one DNS zone and then the Settings tab within, or the Hosts >> > section within the Identity tab and clicking Settings. It seems that >> > any attempt to configure settings yields this error. >> > >> > Directory server error logs point specifically to the NSACLPlugin: >> > >> > NSACLPlugin - get-effective-rights: missing subject >> > Failed to get effective rights for entry >> > (idnsname=17.168.192.in-addr.arpa.,cn=dns,dc=4test,dc=net), rc=21 >> > >> > I'm guessing some incorrect ACLs? >> > >> >> We will need to investigate. >> Petr, Martin any idea? >> > > Looks like 389-ds can't parse/read the ACI. Rich, has anything changed > in this area in F-17? These should be the relevant ACIs: > > dn: $SUFFIX > changetype: modify > add: aci > aci: (target = "ldap:///idnsname=*,cn=dns,$SUFFIX")(version 3.0;acl "permission:add dns entries";allow (add) groupdn = "ldap:///cn=add dns entries,cn=permissions,cn=pbac,$SUFFIX";) > aci: (target = "ldap:///idnsname=*,cn=dns,$SUFFIX")(version 3.0;acl "permission:remove dns entries"; ? allow (delete) groupdn = "ldap:///cn=remove dns entries,cn=permissions,cn=pbac,$SUFFIX";) > aci: (targetattr = "idnsname || cn || idnsallowdynupdate || dnsttl || dnsclass || arecord || ? ? ? ? ? aaaarecord || a6record || nsrecord || cnamerecord || ptrrecord || srvrecord || txtrecord || mxrecord ? || mdrecord || hinforecord || minforecord || afsdbrecord || sigrecord || keyrecord || locrecord || ? ? nxtrecord || naptrrecord || kxrecord || certrecord || dnamerecord || dsrecord || sshfprecord || ? ? ? ?rrsigrecord || nsecrecord || idnsname || idnszoneactive || idnssoamname || idnssoarname || ? ? ? ? ? ? idnssoaserial || idnssoarefresh || idnssoaretry || idnssoaexpire || idnssoaminimum || ? ? ? ? ? ? ? ? ?idnsupdatepolicy")(target = "ldap:///idnsname=*,cn=dns,$SUFFIX")(version 3.0;acl "permission:update ? ?dns entries";allow (write) groupdn = "ldap:///cn=update dns entries,cn=permissions,cn=pbac,$SUFFIX";) Just in case, I just checked the directory, and, indeed this exact set of aci's do exist. From rcritten at redhat.com Mon Mar 12 20:09:44 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 12 Mar 2012 16:09:44 -0400 Subject: [Freeipa-users] 2.1.90 rc1 testing on F17 alpha In-Reply-To: <4F5E4318.9060701@redhat.com> References: <20120311064907.GB32454@redhat.com> <20120311082029.GC32454@redhat.com> <4F5D1F47.9060903@redhat.com> <1331537662.1491.6.camel@balmora.brq.redhat.com> <4F5E060B.7070306@redhat.com> <4F5E30FD.6000406@redhat.com> <4F5E4318.9060701@redhat.com> Message-ID: <4F5E5808.8020208@redhat.com> Dmitri Pal wrote: > On 03/12/2012 01:23 PM, Rich Megginson wrote: >> On 03/12/2012 11:06 AM, Stephen Ingram wrote: >>> On Mon, Mar 12, 2012 at 7:19 AM, Rich Megginson >>> wrote: >>>> On 03/12/2012 01:34 AM, Martin Kosek wrote: >>>>> On Sun, 2012-03-11 at 17:55 -0400, Dmitri Pal wrote: >>>>>> On 03/11/2012 04:22 PM, Stephen Ingram wrote: >>>>>>> Now I've made it to the WebUI. Login works great (also via the new >>>>>>> form auth). Click on IPA Server tab and then Configuration yields: >>>>>>> >>>>>>> IPA Error 4208 - get-effective-rights: missing subject: Invalid >>>>>>> syntax >>>>>>> >>>>>>> This also happens at several other points in the UI. For example, >>>>>>> click one DNS zone and then the Settings tab within, or the Hosts >>>>>>> section within the Identity tab and clicking Settings. It seems that >>>>>>> any attempt to configure settings yields this error. >>>>>>> >>>>>>> Directory server error logs point specifically to the NSACLPlugin: >>>>>>> >>>>>>> NSACLPlugin - get-effective-rights: missing subject >>>>>>> Failed to get effective rights for entry >>>>>>> (idnsname=17.168.192.in-addr.arpa.,cn=dns,dc=4test,dc=net), rc=21 >>>>>>> >>>>>>> I'm guessing some incorrect ACLs? >>>>>>> >>>>>> We will need to investigate. >>>>>> Petr, Martin any idea? >>>>>> >>>>> Looks like 389-ds can't parse/read the ACI. Rich, has anything changed >>>>> in this area in F-17? >>>> F-17? Nothing specific to F-17. Is this error with the latest >>>> 1.2.10.2 or >>>> .3 in F-17 updates or updates-testing? >>> I'm using 1.2.10.3 from the fedora 17 updates repo. IPA is from >>> freeipa-devel repo. >> This error means there is an empty GER control value sent with the >> request. Did the client code change recently? >> ipaserver/plugins/ldap2.py get_effective_rights() looks correct > > > openldap? Could also be python-ldap, we ran into a schema handling problem already. It may be possible to duplicate this from the command line using the --rights option. This executes the same GER control. I'll have to refresh my F-17 install, it is ancient by current standards. You could test with something like: # ipa user-show --all --rights admin If it worked it would include attributelevelrights with a huge list of values. This represents the rights you have on the various attributes (read, write, etc). The UI uses this to determine what it will allow you to edit. regards rob From sbingram at gmail.com Mon Mar 12 20:42:32 2012 From: sbingram at gmail.com (Stephen Ingram) Date: Mon, 12 Mar 2012 13:42:32 -0700 Subject: [Freeipa-users] 2.1.90 rc1 testing on F17 alpha In-Reply-To: <4F5E5808.8020208@redhat.com> References: <20120311064907.GB32454@redhat.com> <20120311082029.GC32454@redhat.com> <4F5D1F47.9060903@redhat.com> <1331537662.1491.6.camel@balmora.brq.redhat.com> <4F5E060B.7070306@redhat.com> <4F5E30FD.6000406@redhat.com> <4F5E4318.9060701@redhat.com> <4F5E5808.8020208@redhat.com> Message-ID: On Mon, Mar 12, 2012 at 1:09 PM, Rob Crittenden wrote: ...snip... > Could also be python-ldap, we ran into a schema handling problem already. > > It may be possible to duplicate this from the command line using the > --rights option. This executes the same GER control. I'll have to refresh my > F-17 install, it is ancient by current standards. > > You could test with something like: > > # ipa user-show --all --rights admin > > If it worked it would include attributelevelrights with a huge list of > values. This represents the rights you have on the various attributes (read, > write, etc). The UI uses this to determine what it will allow you to edit. Here is the result: [root at f17a yum.repos.d]# ipa user-show --all --rights admin ipa: ERROR: get-effective-rights: missing subject: Invalid syntax. I would be happy to try the debug flag in python-ldap, but not sure how to do. Steve From rmeggins at redhat.com Mon Mar 12 21:10:53 2012 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 12 Mar 2012 15:10:53 -0600 Subject: [Freeipa-users] 2.1.90 rc1 testing on F17 alpha In-Reply-To: References: <20120311064907.GB32454@redhat.com> <20120311082029.GC32454@redhat.com> <4F5D1F47.9060903@redhat.com> <1331537662.1491.6.camel@balmora.brq.redhat.com> <4F5E060B.7070306@redhat.com> <4F5E30FD.6000406@redhat.com> <4F5E4318.9060701@redhat.com> <4F5E5808.8020208@redhat.com> Message-ID: <4F5E665D.1010700@redhat.com> On 03/12/2012 02:42 PM, Stephen Ingram wrote: > On Mon, Mar 12, 2012 at 1:09 PM, Rob Crittenden wrote: > > ...snip... > >> Could also be python-ldap, we ran into a schema handling problem already. >> >> It may be possible to duplicate this from the command line using the >> --rights option. This executes the same GER control. I'll have to refresh my >> F-17 install, it is ancient by current standards. >> >> You could test with something like: >> >> # ipa user-show --all --rights admin >> >> If it worked it would include attributelevelrights with a huge list of >> values. This represents the rights you have on the various attributes (read, >> write, etc). The UI uses this to determine what it will allow you to edit. > Here is the result: > > [root at f17a yum.repos.d]# ipa user-show --all --rights admin > ipa: ERROR: get-effective-rights: missing subject: Invalid syntax. > > I would be happy to try the debug flag in python-ldap, but not sure how to do. I know how to do it hacking the code that uses python-ldap, but I'm not sure how to do it without hacking the code. > > Steve > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From sbingram at gmail.com Mon Mar 12 22:44:09 2012 From: sbingram at gmail.com (Stephen Ingram) Date: Mon, 12 Mar 2012 15:44:09 -0700 Subject: [Freeipa-users] 2.1.90 rc1 testing on F17 alpha In-Reply-To: <4F5E665D.1010700@redhat.com> References: <20120311064907.GB32454@redhat.com> <20120311082029.GC32454@redhat.com> <4F5D1F47.9060903@redhat.com> <1331537662.1491.6.camel@balmora.brq.redhat.com> <4F5E060B.7070306@redhat.com> <4F5E30FD.6000406@redhat.com> <4F5E4318.9060701@redhat.com> <4F5E5808.8020208@redhat.com> <4F5E665D.1010700@redhat.com> Message-ID: On Mon, Mar 12, 2012 at 2:10 PM, Rich Megginson wrote: > On 03/12/2012 02:42 PM, Stephen Ingram wrote: >> >> On Mon, Mar 12, 2012 at 1:09 PM, Rob Crittenden >> ?wrote: >> >> ...snip... >> >>> Could also be python-ldap, we ran into a schema handling problem already. >>> >>> It may be possible to duplicate this from the command line using the >>> --rights option. This executes the same GER control. I'll have to refresh >>> my >>> F-17 install, it is ancient by current standards. >>> >>> You could test with something like: >>> >>> # ipa user-show --all --rights admin >>> >>> If it worked it would include attributelevelrights with a huge list of >>> values. This represents the rights you have on the various attributes >>> (read, >>> write, etc). The UI uses this to determine what it will allow you to >>> edit. >> >> Here is the result: >> >> [root at f17a yum.repos.d]# ipa user-show --all --rights admin >> ipa: ERROR: get-effective-rights: missing subject: Invalid syntax. >> >> I would be happy to try the debug flag in python-ldap, but not sure how to >> do. > > I know how to do it hacking the code that uses python-ldap, but I'm not sure > how to do it without hacking the code. Can I just change the OPT_DEBUG_LEVEL to 4096 in ipaserver/ipaldap.py or do I also need to change the settings in each area where an ldap connection is initiated? Steve From rmeggins at redhat.com Mon Mar 12 22:47:09 2012 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 12 Mar 2012 16:47:09 -0600 Subject: [Freeipa-users] 2.1.90 rc1 testing on F17 alpha In-Reply-To: References: <20120311064907.GB32454@redhat.com> <20120311082029.GC32454@redhat.com> <4F5D1F47.9060903@redhat.com> <1331537662.1491.6.camel@balmora.brq.redhat.com> <4F5E060B.7070306@redhat.com> <4F5E30FD.6000406@redhat.com> <4F5E4318.9060701@redhat.com> <4F5E5808.8020208@redhat.com> <4F5E665D.1010700@redhat.com> Message-ID: <4F5E7CED.9030701@redhat.com> On 03/12/2012 04:44 PM, Stephen Ingram wrote: > On Mon, Mar 12, 2012 at 2:10 PM, Rich Megginson wrote: >> On 03/12/2012 02:42 PM, Stephen Ingram wrote: >>> On Mon, Mar 12, 2012 at 1:09 PM, Rob Crittenden >>> wrote: >>> >>> ...snip... >>> >>>> Could also be python-ldap, we ran into a schema handling problem already. >>>> >>>> It may be possible to duplicate this from the command line using the >>>> --rights option. This executes the same GER control. I'll have to refresh >>>> my >>>> F-17 install, it is ancient by current standards. >>>> >>>> You could test with something like: >>>> >>>> # ipa user-show --all --rights admin >>>> >>>> If it worked it would include attributelevelrights with a huge list of >>>> values. This represents the rights you have on the various attributes >>>> (read, >>>> write, etc). The UI uses this to determine what it will allow you to >>>> edit. >>> Here is the result: >>> >>> [root at f17a yum.repos.d]# ipa user-show --all --rights admin >>> ipa: ERROR: get-effective-rights: missing subject: Invalid syntax. >>> >>> I would be happy to try the debug flag in python-ldap, but not sure how to >>> do. >> I know how to do it hacking the code that uses python-ldap, but I'm not sure >> how to do it without hacking the code. > Can I just change the OPT_DEBUG_LEVEL to 4096 in ipaserver/ipaldap.py > or do I also need to change the settings in each area where an ldap > connection is initiated? Good question - any IPA developers want to chime in? > > Steve From ondrejv at s3group.cz Tue Mar 13 08:52:04 2012 From: ondrejv at s3group.cz (Ondrej Valousek) Date: Tue, 13 Mar 2012 09:52:04 +0100 Subject: [Freeipa-users] automount questions In-Reply-To: <20120312164206.GF18789@zeppelin.brq.redhat.com> References: <20120312164206.GF18789@zeppelin.brq.redhat.com> Message-ID: <4F5F0AB4.9080606@s3group.cz> > You need to send SIGHUP to the deamon to force rereading of a map. When > I was working on the autofs/sssd integration effort, we spoke briefly > with Ian about possibilities of better ways to reread a map, but nothing > has surfaced yet. > I do not have such an experience. For me, there is no need to restart autofs to make it aware of the new automount key. But I am using indirect maps only. >> Third question: is it safe to restart the autofs service when people have >> mounted shares on a client? > The short answer is yes, long answer is it depends :-) It depends, exactly. Be especially cautious when updating automount package. Yum usually restarts the daemon as the last step - and sometimes it happens that the daemon crashes with a core dump instead of exiting normally. It that happens, all user shells lose information about the current working directory which can cause funny behaviour. Ondrej The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications at s3group.com. Thank You. Silicon and Software Systems Limited. Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Tue Mar 13 09:04:32 2012 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 13 Mar 2012 10:04:32 +0100 Subject: [Freeipa-users] automount questions In-Reply-To: <4F5F0AB4.9080606@s3group.cz> References: <20120312164206.GF18789@zeppelin.brq.redhat.com> <4F5F0AB4.9080606@s3group.cz> Message-ID: <20120313090432.GB24553@hendrix.redhat.com> On Tue, Mar 13, 2012 at 09:52:04AM +0100, Ondrej Valousek wrote: > You need to send SIGHUP to the deamon to force rereading of a map. When > I was working on the autofs/sssd integration effort, we spoke briefly > with Ian about possibilities of better ways to reread a map, but nothing > has surfaced yet. > > > I do not have such an experience. For me, there is no need to restart > autofs to make it aware of the new automount key. But I am using indirect > maps only. Right, currently this affects direct maps only. With SSSD integration, there's one extra glitch that if automounter starts before SSSD does, the automounter only gets "Connection refused" from the sss module and does not retry reading the maps. From ondrejv at s3group.cz Tue Mar 13 09:16:46 2012 From: ondrejv at s3group.cz (Ondrej Valousek) Date: Tue, 13 Mar 2012 10:16:46 +0100 Subject: [Freeipa-users] automount questions In-Reply-To: <20120313090432.GB24553@hendrix.redhat.com> References: <20120312164206.GF18789@zeppelin.brq.redhat.com> <4F5F0AB4.9080606@s3group.cz> <20120313090432.GB24553@hendrix.redhat.com> Message-ID: <4F5F107E.3080708@s3group.cz> > Right, currently this affects direct maps only. With SSSD integration, > there's one extra glitch that if automounter starts before SSSD does, > the automounter only gets "Connection refused" from the sss module and > does not retry reading the maps. That's nasty and should be probably fixed. I can imagine having to restart sssd for whatever reason - autofs should be able to handle this elegantly (i.e. retry connection). -- The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications at s3group.com. Thank You. Silicon and Software Systems Limited. Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Tue Mar 13 09:22:51 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 13 Mar 2012 10:22:51 +0100 Subject: [Freeipa-users] 2.1.90 rc1 testing on F17 alpha In-Reply-To: <4F5E517C.1010501@redhat.com> References: <20120311064907.GB32454@redhat.com> <20120311082029.GC32454@redhat.com> <4F5D1F47.9060903@redhat.com> <1331537662.1491.6.camel@balmora.brq.redhat.com> <4F5E060B.7070306@redhat.com> <4F5E30FD.6000406@redhat.com> <4F5E4318.9060701@redhat.com> <4F5E4C62.1040302@redhat.com> <4F5E5100.4010200@redhat.com> <4F5E517C.1010501@redhat.com> Message-ID: <1331630571.24319.5.camel@balmora.brq.redhat.com> On Mon, 2012-03-12 at 13:41 -0600, Rich Megginson wrote: > On 03/12/2012 01:39 PM, Dmitri Pal wrote: > > On 03/12/2012 03:20 PM, Rich Megginson wrote: > >> On 03/12/2012 12:40 PM, Dmitri Pal wrote: > >>> On 03/12/2012 01:23 PM, Rich Megginson wrote: > >>>> On 03/12/2012 11:06 AM, Stephen Ingram wrote: > >>>>> On Mon, Mar 12, 2012 at 7:19 AM, Rich Megginson > >>>>> wrote: > >>>>>> On 03/12/2012 01:34 AM, Martin Kosek wrote: > >>>>>>> On Sun, 2012-03-11 at 17:55 -0400, Dmitri Pal wrote: > >>>>>>>> On 03/11/2012 04:22 PM, Stephen Ingram wrote: > >>>>>>>>> Now I've made it to the WebUI. Login works great (also via the new > >>>>>>>>> form auth). Click on IPA Server tab and then Configuration yields: > >>>>>>>>> > >>>>>>>>> IPA Error 4208 - get-effective-rights: missing subject: Invalid > >>>>>>>>> syntax > >>>>>>>>> > >>>>>>>>> This also happens at several other points in the UI. For example, > >>>>>>>>> click one DNS zone and then the Settings tab within, or the Hosts > >>>>>>>>> section within the Identity tab and clicking Settings. It seems > >>>>>>>>> that > >>>>>>>>> any attempt to configure settings yields this error. > >>>>>>>>> > >>>>>>>>> Directory server error logs point specifically to the NSACLPlugin: > >>>>>>>>> > >>>>>>>>> NSACLPlugin - get-effective-rights: missing subject > >>>>>>>>> Failed to get effective rights for entry > >>>>>>>>> (idnsname=17.168.192.in-addr.arpa.,cn=dns,dc=4test,dc=net), rc=21 > >>>>>>>>> > >>>>>>>>> I'm guessing some incorrect ACLs? > >>>>>>>>> > >>>>>>>> We will need to investigate. > >>>>>>>> Petr, Martin any idea? > >>>>>>>> > >>>>>>> Looks like 389-ds can't parse/read the ACI. Rich, has anything > >>>>>>> changed > >>>>>>> in this area in F-17? > >>>>>> F-17? Nothing specific to F-17. Is this error with the latest > >>>>>> 1.2.10.2 or > >>>>>> .3 in F-17 updates or updates-testing? > >>>>> I'm using 1.2.10.3 from the fedora 17 updates repo. IPA is from > >>>>> freeipa-devel repo. > >>>> This error means there is an empty GER control value sent with the > >>>> request. Did the client code change recently? > >>>> ipaserver/plugins/ldap2.py get_effective_rights() looks correct > >>> openldap? > >> could be - or could be python-ldap related - python-ldap 2.4 switched > >> to using pyasn1 to do some encoding that used to be done by the ldap > >> library. > > How can we check? > You can use the debug flag in python-ldap when creating the ldap connection I did some more poking in this issue and I found that the problem is in new python-ldap library in F-17. When I updated this component to python-ldap-2.4.6-2.fc17.x86_64 I got the very same error. This is the BZ against python-ldap that I filed: https://bugzilla.redhat.com/show_bug.cgi?id=802675 I have a Python script that can reproduce this issue in a much less complicated environment (attached). Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: testaci.py Type: text/x-python Size: 675 bytes Desc: not available URL: From eivind at aminor.no Tue Mar 13 10:27:52 2012 From: eivind at aminor.no (Eivind Olsen) Date: Tue, 13 Mar 2012 11:27:52 +0100 Subject: [Freeipa-users] Slight confusion about groups, netgroups, sudo rules etc. Message-ID: Hello. I'm currently looking at implementing IPA in a mixed environment, consisting of RHEL6, RHEL5 and Solaris 10 systems. The IPA server(s) is the most recent one bundled with RHEL 6.2. I have some general rules I'll need to follow as best as I can, but I'm not really sure how to do this in IPA without it seeming like a huge work-around. This seems easy enough had it been for a pure RHEL6 environment, but with Solaris there's no SSSD, I apparantly might need to downgrade the encryption types for "older" Solaris 10, etc. All of this is making my head dizzy, and I'd appreciate any help and pointers to clear my mind :) Examples of the basic rules are (there's more of them, it's not only for the DNS servers for example, but the other cases can be solved in the same way): - all sysadmins should be allowed to log into every system in the realm - all sysadmins should be allowed to run certain commands (or to make it easy, any command) through the use of "sudo", on all systems - some users will be part of certain groups, giving them permission to log into certain servers and run a set of commands through "sudo", for example: members of the dns-managers group should be allowed to ssh into the DNS servers (which consist of both RHEL6 and Solaris 10), and run certain commands through "sudo" - certain other users will be allowed to log into some systems, but without any additional access through "sudo" (the fact that they're allowed to log into system X doesn't mean they should be allowed to become root, etc). I've read a suggestion about making a host group for the Red Hat systems, a netgroup for the Solaris systems, and creating a user group which is added as a member of both the host group and netgroup. But, will I still need to worry about the old issue of Solaris apparantly not coping well with users that have >16 additional groups to their name? I have also read about having to add / change compatibility plugins, having to downgrade the algorithm for the Solaris 10 encryption type for older Solaris 10 releases, etc. And there's probably a few more things I need to watch out for and that aren't directly mentioned in the IPA documentation. Oh, in case it matters - there's no common NFS home directories, so I'll also need to automatically create the home directories (I've got this bit sorted on RHEL6 with help from oddjob-mkhomedir). For Solaris, I've read suggestions about using executable autofs maps to create home directories in /export/home and have tham loopback-mounted to /home so they match the homeDirectory attribute. Regards Eivind "Confused" Olsen From dimitris.tsompanidis at comeon.com Tue Mar 13 12:37:34 2012 From: dimitris.tsompanidis at comeon.com (Dimitris Tsompanidis) Date: Tue, 13 Mar 2012 13:37:34 +0100 Subject: [Freeipa-users] Reset password in WebUI: Insufficient access: Invalid credentials Message-ID: <4F5F3F8E.1070200@comeon.com> Hi, I am deploying FreeIPA for the company I work for and it has been a good experience so far, apart from the fact that users can not reset their passwords throught the web UI. Users use Firefox to log into their accounts, they can update their contact details just fine, but when they try to reset their passwords, they get "Insufficient access: Invalid credentials". At one point, I restarted FreeIPA and a couple of users were able to reset their passwords but the rest of them keep getting the same error. However, when users ssh to a Suse server running Krb5 against FreeIPA, the password change works either by getting the "password expired" notice or by running kpasswd. My guess is that I do something wrong in the user-creation procedure or that I missed something in the default policy that I should know. I could get over this by just using ssh for password resets but I'm planning on activating business users' account in the near future and ssh is definitely out of the question. I should also point out that we're using FreeIPA only for authentication on servers (SSH, Jira, etc) but not on the desktop machines and I'm running FreeIPA 2.1.4-4 on Fedora16. Any comments are appreciated. -- Dimitris Tsompanidis From dpal at redhat.com Tue Mar 13 12:41:27 2012 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 13 Mar 2012 08:41:27 -0400 Subject: [Freeipa-users] Slight confusion about groups, netgroups, sudo rules etc. In-Reply-To: References: Message-ID: <4F5F4077.20409@redhat.com> On 03/13/2012 06:27 AM, Eivind Olsen wrote: > Hello. > > I'm currently looking at implementing IPA in a mixed environment, > consisting of RHEL6, RHEL5 and Solaris 10 systems. The IPA server(s) is > the most recent one bundled with RHEL 6.2. > > I have some general rules I'll need to follow as best as I can, but I'm > not really sure how to do this in IPA without it seeming like a huge > work-around. This seems easy enough had it been for a pure RHEL6 > environment, but with Solaris there's no SSSD, I apparantly might need to > downgrade the encryption types for "older" Solaris 10, etc. All of this is > making my head dizzy, and I'd appreciate any help and pointers to clear my > mind :) > > Examples of the basic rules are (there's more of them, it's not only for > the DNS servers for example, but the other cases can be solved in the same > way): > - all sysadmins should be allowed to log into every system in the realm > - all sysadmins should be allowed to run certain commands (or to make it > easy, any command) through the use of "sudo", on all systems > - some users will be part of certain groups, giving them permission to log > into certain servers and run a set of commands through "sudo", for > example: members of the dns-managers group should be allowed to ssh into > the DNS servers (which consist of both RHEL6 and Solaris 10), and run > certain commands through "sudo" > - certain other users will be allowed to log into some systems, but > without any additional access through "sudo" (the fact that they're > allowed to log into system X doesn't mean they should be allowed to become > root, etc). > > I've read a suggestion about making a host group for the Red Hat systems, > a netgroup for the Solaris systems, and creating a user group which is > added as a member of both the host group and netgroup. But, will I still > need to worry about the old issue of Solaris apparantly not coping well > with users that have >16 additional groups to their name? > > I have also read about having to add / change compatibility plugins, > having to downgrade the algorithm for the Solaris 10 encryption type for > older Solaris 10 releases, etc. And there's probably a few more things I > need to watch out for and that aren't directly mentioned in the IPA > documentation. > > Oh, in case it matters - there's no common NFS home directories, so I'll > also need to automatically create the home directories (I've got this bit > sorted on RHEL6 with help from oddjob-mkhomedir). For Solaris, I've read > suggestions about using executable autofs maps to create home directories > in /export/home and have tham loopback-mounted to /home so they match the > homeDirectory attribute. > The following bug captures best of our knowledge about Solaris setups https://bugzilla.redhat.com/show_bug.cgi?id=801883 so some of the info from this bug might be helpful for you. For the specific questions you ask above I will let more knowledgeable people to chime in. > Regards > Eivind "Confused" Olsen > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Tue Mar 13 12:43:32 2012 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 13 Mar 2012 08:43:32 -0400 Subject: [Freeipa-users] Reset password in WebUI: Insufficient access: Invalid credentials In-Reply-To: <4F5F3F8E.1070200@comeon.com> References: <4F5F3F8E.1070200@comeon.com> Message-ID: <4F5F40F4.6040904@redhat.com> On 03/13/2012 08:37 AM, Dimitris Tsompanidis wrote: > Hi, > > I am deploying FreeIPA for the company I work for and it has been a > good experience so far, apart from the fact that users can not reset > their passwords throught the web UI. > > Users use Firefox to log into their accounts, they can update their > contact details just fine, but when they try to reset their passwords, > they get "Insufficient access: Invalid credentials". > At one point, I restarted FreeIPA and a couple of users were able to > reset their passwords but the rest of them keep getting the same error. > However, when users ssh to a Suse server running Krb5 against FreeIPA, > the password change works either by getting the "password expired" > notice or by running kpasswd. > My guess is that I do something wrong in the user-creation procedure > or that I missed something in the default policy that I should know. > > I could get over this by just using ssh for password resets but I'm > planning on activating business users' account in the near future and > ssh is definitely out of the question. > I should also point out that we're using FreeIPA only for > authentication on servers (SSH, Jira, etc) but not on the desktop > machines and I'm running FreeIPA 2.1.4-4 on Fedora16. > > Any comments are appreciated. > Do you set the password for the user after you create user account using ipa passwd command? -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From simo at redhat.com Tue Mar 13 13:26:06 2012 From: simo at redhat.com (Simo Sorce) Date: Tue, 13 Mar 2012 09:26:06 -0400 Subject: [Freeipa-users] Reset password in WebUI: Insufficient access: Invalid credentials In-Reply-To: <4F5F3F8E.1070200@comeon.com> References: <4F5F3F8E.1070200@comeon.com> Message-ID: <1331645166.9238.128.camel@willson.li.ssimo.org> On Tue, 2012-03-13 at 13:37 +0100, Dimitris Tsompanidis wrote: > Hi, > > I am deploying FreeIPA for the company I work for and it has been a good > experience so far, apart from the fact that users can not reset their > passwords throught the web UI. > > Users use Firefox to log into their accounts, they can update their > contact details just fine, but when they try to reset their passwords, > they get "Insufficient access: Invalid credentials". > At one point, I restarted FreeIPA and a couple of users were able to > reset their passwords but the rest of them keep getting the same error. > However, when users ssh to a Suse server running Krb5 against FreeIPA, > the password change works either by getting the "password expired" > notice or by running kpasswd. > My guess is that I do something wrong in the user-creation procedure or > that I missed something in the default policy that I should know. > > I could get over this by just using ssh for password resets but I'm > planning on activating business users' account in the near future and > ssh is definitely out of the question. > I should also point out that we're using FreeIPA only for authentication > on servers (SSH, Jira, etc) but not on the desktop machines and I'm > running FreeIPA 2.1.4-4 on Fedora16. > > Any comments are appreciated. Sorry Dimitris, unfortunately this is currently a limitation with our webUI, password changes on password expiration do not work through the webUI, and that's the default state when you create and give a first password to new users. Simo. -- Simo Sorce * Red Hat, Inc * New York From dimitris.tsompanidis at comeon.com Tue Mar 13 13:51:47 2012 From: dimitris.tsompanidis at comeon.com (Dimitris Tsompanidis) Date: Tue, 13 Mar 2012 14:51:47 +0100 Subject: [Freeipa-users] Reset password in WebUI: Insufficient access: Invalid credentials In-Reply-To: <1331645166.9238.128.camel@willson.li.ssimo.org> References: <4F5F3F8E.1070200@comeon.com> <1331645166.9238.128.camel@willson.li.ssimo.org> Message-ID: <4F5F50F3.2090500@comeon.com> On 13/03/2012 14:26, Simo Sorce wrote: > > Sorry Dimitris, unfortunately this is currently a limitation with our > webUI, password changes on password expiration do not work through the > webUI, and that's the default state when you create and give a first > password to new users. > > Simo. > Although this also is a problem (in my book), I've learned to live with it and that's why I try to 1) set a default initial password as admin 2) change it myself by logging through the console as the user 3) give the 2nd temporary password to the user. However, people still can not change to a new password through the web UI. The process I use on the 2nd step is to ssh into another server as the user and do the password change there. Also, Dmitri Pal mentioned > Do you set the password for the user after you create user account using > ipa passwd command? I also tried this. > kinit admin > ipa passwd testuser [temp pass #1] > kinit testuser > ipa passwd [temp pass #2] but the user still can not reset his password through the web UI. Dimitris Tsompanidis System administrator at ComeOn! dimitris.tsompanidis at comeon.com From pvoborni at redhat.com Tue Mar 13 13:53:44 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 13 Mar 2012 14:53:44 +0100 Subject: [Freeipa-users] Reset password in WebUI: Insufficient access: Invalid credentials In-Reply-To: <1331645166.9238.128.camel@willson.li.ssimo.org> References: <4F5F3F8E.1070200@comeon.com> <1331645166.9238.128.camel@willson.li.ssimo.org> Message-ID: <4F5F5168.2040303@redhat.com> On 03/13/2012 02:26 PM, Simo Sorce wrote: > On Tue, 2012-03-13 at 13:37 +0100, Dimitris Tsompanidis wrote: >> Hi, >> >> I am deploying FreeIPA for the company I work for and it has been a good >> experience so far, apart from the fact that users can not reset their >> passwords throught the web UI. >> >> Users use Firefox to log into their accounts, they can update their >> contact details just fine, but when they try to reset their passwords, >> they get "Insufficient access: Invalid credentials". >> At one point, I restarted FreeIPA and a couple of users were able to >> reset their passwords but the rest of them keep getting the same error. >> However, when users ssh to a Suse server running Krb5 against FreeIPA, >> the password change works either by getting the "password expired" >> notice or by running kpasswd. >> My guess is that I do something wrong in the user-creation procedure or >> that I missed something in the default policy that I should know. >> >> I could get over this by just using ssh for password resets but I'm >> planning on activating business users' account in the near future and >> ssh is definitely out of the question. >> I should also point out that we're using FreeIPA only for authentication >> on servers (SSH, Jira, etc) but not on the desktop machines and I'm >> running FreeIPA 2.1.4-4 on Fedora16. >> >> Any comments are appreciated. > > Sorry Dimitris, unfortunately this is currently a limitation with our > webUI, password changes on password expiration do not work through the > webUI, and that's the default state when you create and give a first > password to new users. > > Simo. > > I'll just add, that user can change password in WebUI, but not after reset (as simo wrote). In this case I think the message "Insufficient access: Invalid credentials" means that the password doesn't meet password policy requirements. It is a know bug in 2.1.x. It is fixed in 2.2. https://fedorahosted.org/freeipa/ticket/2315 -- Petr Vobornik From sylvainangers at gmail.com Tue Mar 13 18:59:14 2012 From: sylvainangers at gmail.com (Sylvain Angers) Date: Tue, 13 Mar 2012 14:59:14 -0400 Subject: [Freeipa-users] need info on AD / IPA coexistence In-Reply-To: References: <1331218977.9238.16.camel@willson.li.ssimo.org> <1331226246.9238.23.camel@willson.li.ssimo.org> Message-ID: 2012/3/8 Brian Cook > Also, I would not use 'delegation record' from AD, use conditional > forwarding for *.unix.abcd.ca. Your AD admins should know how to do it. > > --- > Brian Cook > Solutions Architect, Red Hat, Inc. > 407-212-7079 > > > > > On Mar 8, 2012, at 9:04 AM, Simo Sorce wrote: > > On Thu, 2012-03-08 at 11:54 -0500, Sylvain Angers wrote: > > Alright! > > > I am now requesting to our DNS team > > > please delegate dns zone "unix.abcd.ca" to ??? > > > the ip address of your ipa server, they will know what questions to > ask :) > > Question: is the ipa server fqdn, be ipaserver.unix.abcd.ca or > > ipaserver.abcd.ca? > > > does it matter? > > > It does, the IPa server DNS domain is what matters for the first master. > So it should be .unix.abcd.ca > > So that DNS domain = unix.abcd.ca and realm = UNIX.ABCD.CA (if you use > the standard configuration). > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > > Hello Still have same issue "unable to find 'admin' user with 'getent passwd admin'! I redid both client and servers, no selinux,no firewall Our dns teams did set soa unix.cnppd.lab to point to my ipa server I had to put a manual entry in /etc/hosts 165.115.118.21 mtl-ipa01d.unix.cnppd.lab mtl-ipa01d then did set my ipa server with the following *ipa-server-install -a xxxxxxx --hostname=mtl-ipa01d.unix.cnppd.lab -n unix.cnppd.lab -p xxxxx -r UNIX.CNPPD.LAB --setup-dns --forwarder=165.115.52.21--fowarder=165.115.51.21* Server host name [mtl-ipa01d.unix.cnppd.lab]: Warning: skipping DNS resolution of host mtl-ipa01d.unix.cnppd.lab The IPA Master Server will be configured with Hostname: mtl-ipa01d.unix.cnppd.lab IP address: 165.115.118.21 Domain name: unix.cnppd.lab Do you want to configure the reverse zone? [yes]: Please specify the reverse zone name [118.115.165.in-addr.arpa.]: Using reverse zone 118.115.165.in-addr.arpa. Restarting the directory server Restarting the KDC Restarting the web server Configuring named: [1/9]: adding DNS container [2/9]: setting up our zone [3/9]: setting up reverse zone [4/9]: setting up our own record [5/9]: setting up kerberos principal [6/9]: setting up named.conf [7/9]: restarting named [8/9]: configuring named to start on boot [9/9]: changing resolv.conf to point to ourselves done configuring named. ============================================================================== Setup complete I did set my client with [root at mtl-vdi01d ~]# ipa-client-install --server=mtl-ipa01d.unix.cnppd.lab --domain=UNIX.CNPPD.LAB --realm=UNIX.CNPPD.LAB --mkhomedir Discovery was successful! Hostname: mtl-vdi01d.cn.ca Realm: UNIX.CNPPD.LAB DNS Domain: UNIX.CNPPD.LAB IPA Server: mtl-ipa01d.unix.cnppd.lab BaseDN: dc=unix,dc=cnppd,dc=lab Continue to configure the system with these values? [no]: yes User authorized to enroll computers: admin Synchronizing time with KDC... Password for admin at UNIX.CNPPD.LAB: Enrolled in IPA realm UNIX.CNPPD.LAB Created /etc/ipa/default.conf Configured[root at mtl-vdi01d ~]# ipa-client-install --server=mtl-ipa01d.unix.cnppd.lab --domain=UNIX.CNPPD.LAB --realm=UNIX.CNPPD.LAB --mkhomedir Discovery was successful! Hostname: mtl-vdi01d.cn.ca Realm: UNIX.CNPPD.LAB DNS Domain: UNIX.CNPPD.LAB IPA Server: mtl-ipa01d.unix.cnppd.lab BaseDN: dc=unix,dc=cnppd,dc=lab Continue to configure the system with these values? [no]: yes User authorized to enroll computers: admin Synchronizing time with KDC... Password for admin at UNIX.CNPPD.LAB: Enrolled in IPA realm UNIX.CNPPD.LAB Created /etc/ipa/default.conf Configured /etc/sssd/sssd.conf Configured /etc/krb5.conf for IPA realm UNIX.CNPPD.LAB SSSD enabled Unable to find 'admin' user with 'getent passwd admin'! Recognized configuration: SSSD NTP enabled Client configuration complete. /etc/sssd/sssd.conf Configured /etc/krb5.conf for IPA realm UNIX.CNPPD.LAB SSSD enabled Unable to find 'admin' user with 'getent passwd admin'! Recognized configuration: SSSD NTP enabled Client configuration complete. you can see that ipa did enroll my client [root at mtl-ipa01d ~]# ipa host-find --------------- 2 hosts matched --------------- Host name: mtl-ipa01d.unix.cnppd.lab Principal name: host/mtl-ipa01d.unix.cnppd.lab at UNIX.CNPPD.LAB Keytab: True Password: False Managed by: mtl-ipa01d.unix.cnppd.lab Host name: mtl-vdi01d.cn.ca Certificate: MIIDhTCCAm2gAwIBAgIBDDANBgkqhkiG9w0BAQsFADA5MRcwFQYDVQQKEw5VTklYLkNOUFBELkxBQjEeMBwGA1UEAxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTEyMDMxMzE4Mjc0MVoXDTE0MDMxNDE4Mjc0MVowNDEXMBUGA1UEChMOVU5JWC5DTlBQRC5MQUIxGTAXBgNVBAMTEG10bC12ZGkwMWQuY24uY2EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKTPD8p7Ttxn87Y/2CCu54GDTd/CS77irN6OYj9IznqMusHAIWsVVu5m0aT77iULYzO9lKmKCL9RuSnZuqsoppFZk8UJu1KAGKv2FQi7zck28P2t6XRhHXcLRRTq5Mzfd/QjFmCv3oxTP2gd/0rLZUTHJkTzqyYIMlExfQqnEBJCzfzukyFUB5S+X2DthiGOM7vcKPXlmG+VstebtsZ1FkE9LquyWGhSBjqycZM350zRwQP6MLKU4ZX11mit6+/AvRrOJW3Gw9JWRxDOullJG2mCjyFCsUKOX/Xz4VrJeSylIGJQk5kLfP2haSPhkKhG9FXy1vhwpXFF1GAa9DYvhvAgMBAAGjgZwwgZkwHwYDVR0jBBgwFoAUZtbp/CAAXZ/LZAKgUqcXPxgkOzcwRwYIKwYBBQUHAQEEOzA5MDcGCCsGAQUFBzABhitodHRwOi8vbXRsLWlwYTAxZC51bml4LmNucHBkLmxhYjo4MC9jYS9vY3NwMA4GA1UdDwEB/wQEAwIE8DAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwDQYJKoZIhvcNAQELBQADggEBAEPpr1rn+inQlxc+u7WAkyuRDd1af/ilUlldkB0n4l9Ni2Lkt+Gt7w6VYqS+/ZtqTPB/mQuISGDuqeEXSgWSc+1NQq1THgBACzfE5CbKWOcfGd/SnTqIA+/ITydintYB7SNQ0Vz6BOC9Uv/VmEPqD38ThR88qhK0+wmvdf2HyKOFAsu5Ty5qKaOyDHuhhA4AXEbQz8vRH3XQa/WtSf/zgRKiNeabEc5gWXEd9dSpm2UhW7oLuPlnKolI3IL1RUoc8WrKKLK1HdyrcNY+woZ2Jw4OCkyiGuWaNZHOEAmAlwmvQrFBlMsIPJfI/mxmAXufEO66AHf/747V2n1TvZrnkrQ= Principal name: host/mtl-vdi01d.cn.ca at UNIX.CNPPD.LAB Keytab: True Password: False Managed by: mtl-vdi01d.cn.ca Subject: CN=mtl-vdi01d.cn.ca,O=UNIX.CNPPD.LAB Serial Number: 12 Issuer: CN=Certificate Authority,O=UNIX.CNPPD.LAB Not Before: Tue Mar 13 18:27:41 2012 UTC Not After: Fri Mar 14 18:27:41 2014 UTC Fingerprint (MD5): 26:f6:9f:32:3d:a0:13:43:8e:16:1a:7f:d7:43:7e:51 Fingerprint (SHA1): 4b:28:b2:a4:33:16:27:fc:16:cc:35:54:68:fc:b4:45:85:3f:dc:1a ---------------------------- Number of entries returned 2 ---------------------------- [root at mtl-ipa01d ~]# I keep getting "unable to find 'admin' user with 'getent passwd admin'! Why is that? Thanks Sylvain -- Sylvain Angers -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbingram at gmail.com Tue Mar 13 20:44:31 2012 From: sbingram at gmail.com (Stephen Ingram) Date: Tue, 13 Mar 2012 13:44:31 -0700 Subject: [Freeipa-users] Fwd: manual client join In-Reply-To: <4EEF3DD8.7010009@redhat.com> References: <4ED68C4A.2090500@redhat.com> <4ED69937.80003@redhat.com> <4EDD2E63.8010005@redhat.com> <4EEF3DD8.7010009@redhat.com> Message-ID: On Mon, Dec 19, 2011 at 5:36 AM, John Dennis wrote: > Sorry, but currently on the command line the only way to specify a > certificate is via it's serial number. The serial number is the only > identifier guaranteed to be unique. However, I agree it's not convenient. > Would you like to open an RFE (Request for Enhancement) on > https://fedorahosted.org/freeipa/ I know it's been some time, but I've opened a ticket. I've never submitted an RFE before so I'm not sure I filled in the correct selections. I went for less urgent as this really isn't breaking anything--it's just more of an inconvenience. It's ticket #2528. Steve From sbingram at gmail.com Tue Mar 13 21:16:30 2012 From: sbingram at gmail.com (Stephen Ingram) Date: Tue, 13 Mar 2012 14:16:30 -0700 Subject: [Freeipa-users] manual client join In-Reply-To: <4EDA70D9.3080200@redhat.com> References: <4ED68C4A.2090500@redhat.com> <4ED69937.80003@redhat.com> <4EDA70D9.3080200@redhat.com> Message-ID: On Sat, Dec 3, 2011 at 10:56 AM, Dmitri Pal wrote: > On 11/30/2011 03:59 PM, Rob Crittenden wrote: >> Stephen Ingram wrote: >>> Rob- >>> >>> On Wed, Nov 30, 2011 at 12:04 PM, Rob >>> Crittenden ?wrote: >>>> Retrieve the CA certificate for the FreeIPA CA. >>>> >>>> # wget -O /etc/ipa/ca.crt http://ipa.example.com/ipa/config/ca.crt >>>> >>>> Create a separate Kerberos configuration to test the provided >>>> credentials. >>>> This enables a Kerberos connection to the FreeIPA XML-RPC server, >>>> necessary >>>> to join the FreeIPA client to the FreeIPA domain. This Kerberos >>>> configuration is ultimately discarded. >>>> >>>> - Basically just copy a working krb5.conf to /etc/krb5.conf and set >>>> up sssd >>>> or nss_ldap as documented. >>>> >>>> # kinit admin >>>> # ipa-join -s ipa.example.com -b dc=example,dc=com >>>> >>>> Or if using a one-time password you can skip the kinit and do >>>> >>>> # ipa-join -s ipa.example.com -b dc=example,dc=com -w Secret123 >>>> >>>> ipa-join lets IPA know a host is enrolled and retrieves a host >>>> principal and >>>> stores it into /etc/krb5.keytab. >>>> >>>> Enable certmonger, retrieve an SSL server certificate, and install the >>>> certificate in /etc/pki/nssdb. >>>> >>>> # service messagebus start >>>> # service certmonger start >>>> # certutil -A -d /etc/pki/nssdb -n 'IPA CA' -t CT,C,C -a -i >>>> /etc/ipa/ca.crt >>>> # ipa-getcert request -d /etc/pki/nssdb -n 'IPA Machine Certificate - >>>> client.example.com' -N 'cn=client.example.com,O=EXAMPLE.COM; -K >>>> host/client.example.com at EXAMPLE.COM >>>> >>>> Disable the nscd daemon. >>>> >>>> # service nscd stop >>>> # chkconfig nscd off >>> >>> Thanks, but aren't some of these steps assuming that ipa-client has >>> been installed on the system? For instance, instead of "# ipa-join -s >>> ipa.example.com -b dc=example,dc=com -w Secret123", can't I instead >>> use kadmin to retrieve the keytab and then securely copy it over to >>> the client system? And, in the case of the ca.crt, if there if IPA >>> itself is not installed, the ca would not go to /etc/ipa/ca.crt, no? I >>> realize that I will lose functionality by not having ipa-client, but >>> just trying to build a case for supporting legacy systems that I would >>> never want to take the time to adapt ipa-client for. >>> >>> Steve >> >> The only part assuming that is ipa-join itself. IPA does not support >> the direct use of kadmin or kadmin.local. On a supported platform >> you'd run: >> >> # ipa-getkeytab -s ipa.example.com -k /tmp/remote.keytab -p >> host/remote.example.com >> >> Then ship /tmp/remote.keytab to the machine and either use ktutil to >> combine it with /etc/krb5.keytab or replace krb5.keytab with it (and >> fix owner and permissions, and potentially SELinux context). >> >> certmonger gets its IPA configuration from /etc/ipa/default.conf. If >> you don't want or have certmonger then you can skip the CA bit >> altogether. Otherwise you'll need to copy in a working config. >> > > Should any part of this be documented? This might be beyond what you are thinking, however, to me, one of the best things about FreeIPA is that because of how flexible you've made it, I can use as much or as little as I want. These sorts of "small steps" might also make it easier to integrate into non-Redhat/Fedora or non-Linux systems. I have compiled and tested the suggestions offered to me by Rob and put them into an attached text document that roughly corresponds to the current section 3.4 of the FreeIPA documentation. It's probably a little rough, but should make a nice template to help supplement the existing documentation. Steve -------------- next part -------------- 3.4 Manual Configuring a Linux Client The ipa-client-install command automatically configures services like Kerberos, SSSD, PAM and NSS. However, there are some situations where the ipa-client-install command cannot be used on a system, or, its full capabilities are simply not required. In those instances, the FreeIPA client entries and services can be configured manually. The entire set of capabilities of FreeIPA can be obtained by installing and configuring SSSD and either using authconfig or editing the PAM configuration files by hand. In instances where only a subset of FreeIPA capabilities are desired, for example a Web service on a system using FreeIPA as an authentication source, only the necessary configuration changes need be implemented. 3.4.1 Retrieve CA Certificate from FreeIPA server 1. Retrieve CA certificate # mkdir /etc/ipa # wget -O /etc/ipa/ca.crt http://ipa.example.com/ipa/config/ca.crt 2. import CA certificate a. Using certutil (NSS): # certutil -A -d /etc/pki/nssdb -n 'IPA CA' -t CT,C,C -a -i /etc/ipa/ca.crt b. Using openssl: # openssl x509 -in /etc/ipa/ca.crt -text >> /etc/pki/tls/certs/ca-bundle.crt 3.4.2 Obtain and Import Host Certificate 1. Generate CSR for client machine a. Using certutil (NSS): # certutil -R -s "CN=client.example.com,O=EXAMPLE.COM" -d /etc/pki/nssdb -a > client.example.com.csr b. Using openssl: # openssl req -nodes -new -newkey rsa:2048 -keyout /etc/pki/tls/private/client.example.com.key \ -out /etc/pki/tls/certs/client.example.com.csr 2. Submit CSR to IPA to obtain certificate on IPA server: # ipa cert-request --principal host/client.example.com client.example.com.csr 3. Obtain certificate in PEM format on IPA server: # ipa host-show --out=/tmp/client.example.com.crt client.example.com 4. Import host certificate a. Using certutil (NSS): # certutil -A -d /etc/pki/nssdb -n 'IPA Machine Certificate - client.example.com' -t P,, -a -i client.example.com.crt b. Using openssl: copy client.example.com.crt to /etc/pki/tls/certs directory 3.4.3 Configure /etc/krb5.conf on client machine [libdefaults] default_realm = EXAMPLE.COM dns_lookup_realm = false dns_lookup_kdc = false rdns = false forwardable = yes ticket_lifetime = 24h [realms] EXAMPLE.COM = { kdc = ipaserver.example.com:88 admin_server = ipaserver.example.com:749 } [domain_realm] .example.com = EXAMPLE.COM example.com = EXAMPLE.COM 3.4.4 Obtain and Import Host Principal 1. Generate host principal in FreeIPA on IPA server: # ipa-join -h client.example.com -s ipa.example.com -b dc=example,dc=com 2. Output host principal on IPA server: # ipa-getkeytab -s ipa.example.com -k /tmp/client.example.com.keytab -p host/client.example.com 3. Securely transport keytab to client machine and then replace /etc/krb5.keytab or merge with existing keytab using ktutil. a. If replacing or creating new /etc/krb5.keytab, then: # chown root:root /etc/krb5.keytab # chmod 600 b. If using SELinux, then: # chcon -u unconfined_u -r object_r -t krb5_keytab_t -l s0 3.4.5 Disable nscd daemon # service nscd stop # chkconfig nscd off 3.4.6 Configure system to authenticate and authorize from IPA 1. If setting up legacy LDAP/KRB5 authentication a. Install nslcd daemon # yum install nss-pam-ldapd b. Configure /etc/nsswitch.conf, PAM files and nslcd daemon # authconfig --enableldap --ldapserver=ldaps://ipa.example.com --ldapbasedn=dc=example,dc=com --ldaploadcacert=http://ipa.example.com/ipa/config/ca.crt --disableldapstarttls --enablekrb5 --krb5kdc=ipa.example.com --krb5adminserver=ipa.example.com --krb5realm=EXAMPLE.COM --updateall If authconfig not available, edit /etc/nsswitch.conf, the PAM system authentication files and either the older PADL (/etc/ldap.conf) files or the newer LDAP nameservice daemon (/etc/nslcd.conf) by hand. (this will vary depending on operating system) 2. If using SSSD a. Install sssd daemon # yum install sssd b. Configure /etc/nsswitch.conf, PAM files and SSSD daemon # authconfig --enableldap --ldapserver=ldaps://ipa.example.com --ldapbasedn=dc=example,dc=com --ldaploadcacert=http://ipa.example.com/ipa/config/ca.crt --disableldapstarttls --enablekrb5 --krb5kdc=ipa.example.com --krb5adminserver=ipa.example.com --krb5realm=EXAMPLE.COM --enablesssd --enablesssdauth --updateall If authconfig not available, edit /etc/nsswitch.conf, the PAM system authentication files and the SSSD configuration files (/etc/sssd/sssd.conf) by hand. (examples in current documentation-will vary on other operating systems) From dpal at redhat.com Tue Mar 13 21:21:28 2012 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 13 Mar 2012 17:21:28 -0400 Subject: [Freeipa-users] need info on AD / IPA coexistence In-Reply-To: References: <1331218977.9238.16.camel@willson.li.ssimo.org> <1331226246.9238.23.camel@willson.li.ssimo.org> Message-ID: <4F5FBA58.4060105@redhat.com> On 03/13/2012 02:59 PM, Sylvain Angers wrote: > > > 2012/3/8 Brian Cook > > > Also, I would not use 'delegation record' from AD, use conditional > forwarding for *.unix.abcd.ca . Your AD > admins should know how to do it. > > --- > Brian Cook > Solutions Architect, Red Hat, Inc. > 407-212-7079 > > > > > On Mar 8, 2012, at 9:04 AM, Simo Sorce wrote: > >> On Thu, 2012-03-08 at 11:54 -0500, Sylvain Angers wrote: >>> Alright! >>> >>> I am now requesting to our DNS team >>> >>> please delegate dns zone "unix.abcd.ca " to ??? >> >> the ip address of your ipa server, they will know what questions to >> ask :) >> >>> Question: is the ipa server fqdn, be ipaserver.unix.abcd.ca >>> or >>> ipaserver.abcd.ca ? >> >>> does it matter? >> >> It does, the IPa server DNS domain is what matters for the first >> master. >> So it should be .unix.abcd.ca >> >> So that DNS domain = unix.abcd.ca and realm >> = UNIX.ABCD.CA (if you use >> the standard configuration). >> >> Simo. >> >> -- >> Simo Sorce * Red Hat, Inc * New York >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > Hello > > Still have same issue "unable to find 'admin' user with 'getent passwd > admin'! > > I redid both client and servers, no selinux,no firewall > > Our dns teams did set soa unix.cnppd.lab to point to my ipa server > > I had to put a manual entry in /etc/hosts > 165.115.118.21 mtl-ipa01d.unix.cnppd.lab mtl-ipa01d > > > then did set my ipa server with the following > *ipa-server-install -a xxxxxxx --hostname=mtl-ipa01d.unix.cnppd.lab -n > unix.cnppd.lab -p xxxxx -r UNIX.CNPPD.LAB --setup-dns > --forwarder=165.115.52.21--fowarder=165.115.51.21* > Server host name [mtl-ipa01d.unix.cnppd.lab]: > > Warning: skipping DNS resolution of host mtl-ipa01d.unix.cnppd.lab > The IPA Master Server will be configured with > Hostname: mtl-ipa01d.unix.cnppd.lab > IP address: 165.115.118.21 > Domain name: unix.cnppd.lab > > Do you want to configure the reverse zone? [yes]: > Please specify the reverse zone name [118.115.165.in-addr.arpa.]: > Using reverse zone 118.115.165.in-addr.arpa. > > > > Restarting the directory server > Restarting the KDC > Restarting the web server > Configuring named: > [1/9]: adding DNS container > [2/9]: setting up our zone > [3/9]: setting up reverse zone > [4/9]: setting up our own record > [5/9]: setting up kerberos principal > [6/9]: setting up named.conf > [7/9]: restarting named > [8/9]: configuring named to start on boot > [9/9]: changing resolv.conf to point to ourselves > done configuring named. > ============================================================================== > Setup complete > > > I did set my client with > [root at mtl-vdi01d ~]# ipa-client-install > --server=mtl-ipa01d.unix.cnppd.lab --domain=UNIX.CNPPD.LAB > --realm=UNIX.CNPPD.LAB --mkhomedir > Discovery was successful! > Hostname: mtl-vdi01d.cn.ca > Realm: UNIX.CNPPD.LAB > DNS Domain: UNIX.CNPPD.LAB > IPA Server: mtl-ipa01d.unix.cnppd.lab > BaseDN: dc=unix,dc=cnppd,dc=lab > > > Continue to configure the system with these values? [no]: yes > User authorized to enroll computers: admin > Synchronizing time with KDC... > Password for admin at UNIX.CNPPD.LAB: > > Enrolled in IPA realm UNIX.CNPPD.LAB > Created /etc/ipa/default.conf > Configured[root at mtl-vdi01d ~]# ipa-client-install > --server=mtl-ipa01d.unix.cnppd.lab --domain=UNIX.CNPPD.LAB > --realm=UNIX.CNPPD.LAB --mkhomedir > Discovery was successful! > Hostname: mtl-vdi01d.cn.ca > Realm: UNIX.CNPPD.LAB > DNS Domain: UNIX.CNPPD.LAB > IPA Server: mtl-ipa01d.unix.cnppd.lab > BaseDN: dc=unix,dc=cnppd,dc=lab > > > Continue to configure the system with these values? [no]: yes > User authorized to enroll computers: admin > Synchronizing time with KDC... > Password for admin at UNIX.CNPPD.LAB: > > Enrolled in IPA realm UNIX.CNPPD.LAB > Created /etc/ipa/default.conf > Configured /etc/sssd/sssd.conf > Configured /etc/krb5.conf for IPA realm UNIX.CNPPD.LAB > SSSD enabled > Unable to find 'admin' user with 'getent passwd admin'! > Recognized configuration: SSSD > NTP enabled > Client configuration complete. /etc/sssd/sssd.conf > Configured /etc/krb5.conf for IPA realm UNIX.CNPPD.LAB > SSSD enabled > Unable to find 'admin' user with 'getent passwd admin'! > Recognized configuration: SSSD > NTP enabled > Client configuration complete. > > you can see that ipa did enroll my client > > [root at mtl-ipa01d ~]# ipa host-find > --------------- > 2 hosts matched > --------------- > Host name: mtl-ipa01d.unix.cnppd.lab > Principal name: host/mtl-ipa01d.unix.cnppd.lab at UNIX.CNPPD.LAB > Keytab: True > Password: False > Managed by: mtl-ipa01d.unix.cnppd.lab > > Host name: mtl-vdi01d.cn.ca > Certificate: > MIIDhTCCAm2gAwIBAgIBDDANBgkqhkiG9w0BAQsFADA5MRcwFQYDVQQKEw5VTklYLkNOUFBELkxBQjEeMBwGA1UEAxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTEyMDMxMzE4Mjc0MVoXDTE0MDMxNDE4Mjc0MVowNDEXMBUGA1UEChMOVU5JWC5DTlBQRC5MQUIxGTAXBgNVBAMTEG10bC12ZGkwMWQuY24uY2EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKTPD8p7Ttxn87Y/2CCu54GDTd/CS77irN6OYj9IznqMusHAIWsVVu5m0aT77iULYzO9lKmKCL9RuSnZuqsoppFZk8UJu1KAGKv2FQi7zck28P2t6XRhHXcLRRTq5Mzfd/QjFmCv3oxTP2gd/0rLZUTHJkTzqyYIMlExfQqnEBJCzfzukyFUB5S+X2DthiGOM7vcKPXlmG+VstebtsZ1FkE9LquyWGhSBjqycZM350zRwQP6MLKU4ZX11mit6+/AvRrOJW3Gw9JWRxDOullJG2mCjyFCsUKOX/Xz4VrJeSylIGJQk5kLfP2haSPhkKhG9FXy1vhwpXFF1GAa9DYvhvAgMBAAGjgZwwgZkwHwYDVR0jBBgwFoAUZtbp/CAAXZ/LZAKgUqcXPxgkOzcwRwYIKwYBBQUHAQEEOzA5MDcGCCsGAQUFBzABhitodHRwOi8vbXRsLWlwYTAxZC51bml4LmNucHBkLmxhYjo4MC9jYS9vY3NwMA4GA1UdDwEB/wQEAwIE8DAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwDQYJKoZIhvcNAQELBQADggEBAEPpr1rn+inQlxc+u7WAkyuRDd1af/ilUlldkB0n4l9Ni2Lkt+Gt7w6VYqS+/ZtqTPB/mQuISGDuqeEXSgWSc+1NQq1THgBACzfE5CbKWOcfGd/SnTqIA+/ITydintYB7SNQ0Vz6BOC9Uv/VmEPqD38ThR88qhK0+wmvdf2HyKOFAsu5Ty5qKaOyDHuhhA4AXEbQz8vRH3XQa/WtSf/zgRKiNeabEc5gWXEd9dSpm2UhW7oLuPlnKolI3IL1RUoc8WrKKLK1HdyrcNY+woZ2Jw4OCkyiGuWaNZHOEAmAlwmvQrFBlMsIPJfI/mxmAXufEO66AHf/747V2n1TvZrnkrQ= > Principal name: host/mtl-vdi01d.cn.ca at UNIX.CNPPD.LAB > Keytab: True > Password: False > Managed by: mtl-vdi01d.cn.ca > Subject: CN=mtl-vdi01d.cn.ca ,O=UNIX.CNPPD.LAB > Serial Number: 12 > Issuer: CN=Certificate Authority,O=UNIX.CNPPD.LAB > Not Before: Tue Mar 13 18:27:41 2012 UTC > Not After: Fri Mar 14 18:27:41 2014 UTC > Fingerprint (MD5): 26:f6:9f:32:3d:a0:13:43:8e:16:1a:7f:d7:43:7e:51 > Fingerprint (SHA1): > 4b:28:b2:a4:33:16:27:fc:16:cc:35:54:68:fc:b4:45:85:3f:dc:1a > ---------------------------- > Number of entries returned 2 > ---------------------------- > [root at mtl-ipa01d ~]# > > > > I keep getting "unable to find 'admin' user with 'getent passwd admin'! > > Why is that? > > Thanks > > Sylvain > Did you run the client enrollment twice? Can you provide a ipaclient installation log? > > > -- > Sylvain Angers > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, 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 Mar 13 21:23:10 2012 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 13 Mar 2012 17:23:10 -0400 Subject: [Freeipa-users] manual client join In-Reply-To: References: <4ED68C4A.2090500@redhat.com> <4ED69937.80003@redhat.com> <4EDA70D9.3080200@redhat.com> Message-ID: <4F5FBABE.4080906@redhat.com> On 03/13/2012 05:16 PM, Stephen Ingram wrote: > On Sat, Dec 3, 2011 at 10:56 AM, Dmitri Pal wrote: >> On 11/30/2011 03:59 PM, Rob Crittenden wrote: >>> Stephen Ingram wrote: >>>> Rob- >>>> >>>> On Wed, Nov 30, 2011 at 12:04 PM, Rob >>>> Crittenden wrote: >>>>> Retrieve the CA certificate for the FreeIPA CA. >>>>> >>>>> # wget -O /etc/ipa/ca.crt http://ipa.example.com/ipa/config/ca.crt >>>>> >>>>> Create a separate Kerberos configuration to test the provided >>>>> credentials. >>>>> This enables a Kerberos connection to the FreeIPA XML-RPC server, >>>>> necessary >>>>> to join the FreeIPA client to the FreeIPA domain. This Kerberos >>>>> configuration is ultimately discarded. >>>>> >>>>> - Basically just copy a working krb5.conf to /etc/krb5.conf and set >>>>> up sssd >>>>> or nss_ldap as documented. >>>>> >>>>> # kinit admin >>>>> # ipa-join -s ipa.example.com -b dc=example,dc=com >>>>> >>>>> Or if using a one-time password you can skip the kinit and do >>>>> >>>>> # ipa-join -s ipa.example.com -b dc=example,dc=com -w Secret123 >>>>> >>>>> ipa-join lets IPA know a host is enrolled and retrieves a host >>>>> principal and >>>>> stores it into /etc/krb5.keytab. >>>>> >>>>> Enable certmonger, retrieve an SSL server certificate, and install the >>>>> certificate in /etc/pki/nssdb. >>>>> >>>>> # service messagebus start >>>>> # service certmonger start >>>>> # certutil -A -d /etc/pki/nssdb -n 'IPA CA' -t CT,C,C -a -i >>>>> /etc/ipa/ca.crt >>>>> # ipa-getcert request -d /etc/pki/nssdb -n 'IPA Machine Certificate - >>>>> client.example.com' -N 'cn=client.example.com,O=EXAMPLE.COM; -K >>>>> host/client.example.com at EXAMPLE.COM >>>>> >>>>> Disable the nscd daemon. >>>>> >>>>> # service nscd stop >>>>> # chkconfig nscd off >>>> Thanks, but aren't some of these steps assuming that ipa-client has >>>> been installed on the system? For instance, instead of "# ipa-join -s >>>> ipa.example.com -b dc=example,dc=com -w Secret123", can't I instead >>>> use kadmin to retrieve the keytab and then securely copy it over to >>>> the client system? And, in the case of the ca.crt, if there if IPA >>>> itself is not installed, the ca would not go to /etc/ipa/ca.crt, no? I >>>> realize that I will lose functionality by not having ipa-client, but >>>> just trying to build a case for supporting legacy systems that I would >>>> never want to take the time to adapt ipa-client for. >>>> >>>> Steve >>> The only part assuming that is ipa-join itself. IPA does not support >>> the direct use of kadmin or kadmin.local. On a supported platform >>> you'd run: >>> >>> # ipa-getkeytab -s ipa.example.com -k /tmp/remote.keytab -p >>> host/remote.example.com >>> >>> Then ship /tmp/remote.keytab to the machine and either use ktutil to >>> combine it with /etc/krb5.keytab or replace krb5.keytab with it (and >>> fix owner and permissions, and potentially SELinux context). >>> >>> certmonger gets its IPA configuration from /etc/ipa/default.conf. If >>> you don't want or have certmonger then you can skip the CA bit >>> altogether. Otherwise you'll need to copy in a working config. >>> >> Should any part of this be documented? > This might be beyond what you are thinking, however, to me, one of the > best things about FreeIPA is that because of how flexible you've made > it, I can use as much or as little as I want. These sorts of "small > steps" might also make it easier to integrate into non-Redhat/Fedora > or non-Linux systems. I have compiled and tested the suggestions > offered to me by Rob and put them into an attached text document that > roughly corresponds to the current section 3.4 of the FreeIPA > documentation. It's probably a little rough, but should make a nice > template to help supplement the existing documentation. > > Steve Thank you! We will take a look. -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Tue Mar 13 21:25:06 2012 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 13 Mar 2012 17:25:06 -0400 Subject: [Freeipa-users] Fwd: manual client join In-Reply-To: References: <4ED68C4A.2090500@redhat.com> <4ED69937.80003@redhat.com> <4EDD2E63.8010005@redhat.com> <4EEF3DD8.7010009@redhat.com> Message-ID: <4F5FBB32.8030308@redhat.com> On 03/13/2012 04:44 PM, Stephen Ingram wrote: > On Mon, Dec 19, 2011 at 5:36 AM, John Dennis wrote: >> Sorry, but currently on the command line the only way to specify a >> certificate is via it's serial number. The serial number is the only >> identifier guaranteed to be unique. However, I agree it's not convenient. >> Would you like to open an RFE (Request for Enhancement) on >> https://fedorahosted.org/freeipa/ > I know it's been some time, but I've opened a ticket. I've never > submitted an RFE before so I'm not sure I filled in the correct > selections. I went for less urgent as this really isn't breaking > anything--it's just more of an inconvenience. It's ticket #2528. > > Steve > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users Thank you! Just FYI, all tickets go into NEEDS_TRIAGE bucket first so that we do the correct processing and handling when we triage them. -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From sbingram at gmail.com Tue Mar 13 21:29:20 2012 From: sbingram at gmail.com (Stephen Ingram) Date: Tue, 13 Mar 2012 14:29:20 -0700 Subject: [Freeipa-users] Fwd: manual client join In-Reply-To: <4F5FBB32.8030308@redhat.com> References: <4ED68C4A.2090500@redhat.com> <4ED69937.80003@redhat.com> <4EDD2E63.8010005@redhat.com> <4EEF3DD8.7010009@redhat.com> <4F5FBB32.8030308@redhat.com> Message-ID: On Tue, Mar 13, 2012 at 2:25 PM, Dmitri Pal wrote: > Thank you! > Just FYI, all tickets go into NEEDS_TRIAGE bucket first so that we do > the correct processing and handling when we triage them. Got it. Sorry about that. I guess that's why it was the default. Steve From dpal at redhat.com Tue Mar 13 21:33:51 2012 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 13 Mar 2012 17:33:51 -0400 Subject: [Freeipa-users] Fwd: manual client join In-Reply-To: References: <4ED68C4A.2090500@redhat.com> <4ED69937.80003@redhat.com> <4EDD2E63.8010005@redhat.com> <4EEF3DD8.7010009@redhat.com> <4F5FBB32.8030308@redhat.com> Message-ID: <4F5FBD3F.4040207@redhat.com> On 03/13/2012 05:29 PM, Stephen Ingram wrote: > On Tue, Mar 13, 2012 at 2:25 PM, Dmitri Pal wrote: >> Thank you! >> Just FYI, all tickets go into NEEDS_TRIAGE bucket first so that we do >> the correct processing and handling when we triage them. > Got it. Sorry about that. I guess that's why it was the default. > > Steve NP. -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Wed Mar 14 02:46:03 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 13 Mar 2012 22:46:03 -0400 Subject: [Freeipa-users] need info on AD / IPA coexistence In-Reply-To: References: <1331218977.9238.16.camel@willson.li.ssimo.org> <1331226246.9238.23.camel@willson.li.ssimo.org> Message-ID: <4F60066B.4090203@redhat.com> Sylvain Angers wrote: > > > 2012/3/8 Brian Cook > > > Also, I would not use 'delegation record' from AD, use conditional > forwarding for *.unix.abcd.ca . Your AD admins > should know how to do it. > > --- > Brian Cook > Solutions Architect, Red Hat, Inc. > 407-212-7079 > > > > > On Mar 8, 2012, at 9:04 AM, Simo Sorce wrote: > >> On Thu, 2012-03-08 at 11:54 -0500, Sylvain Angers wrote: >>> Alright! >>> >>> I am now requesting to our DNS team >>> >>> please delegate dns zone "unix.abcd.ca " to ??? >> >> the ip address of your ipa server, they will know what questions to >> ask :) >> >>> Question: is the ipa server fqdn, be ipaserver.unix.abcd.ca >>> or >>> ipaserver.abcd.ca ? >> >>> does it matter? >> >> It does, the IPa server DNS domain is what matters for the first >> master. >> So it should be .unix.abcd.ca >> >> So that DNS domain = unix.abcd.ca and realm >> = UNIX.ABCD.CA (if you use >> the standard configuration). >> >> Simo. >> >> -- >> Simo Sorce * Red Hat, Inc * New York >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > Hello > > Still have same issue "unable to find 'admin' user with 'getent passwd > admin'! > > I redid both client and servers, no selinux,no firewall > > Our dns teams did set soa unix.cnppd.lab to point to my ipa server > > I had to put a manual entry in /etc/hosts > 165.115.118.21 mtl-ipa01d.unix.cnppd.lab mtl-ipa01d > > > then did set my ipa server with the following > *ipa-server-install -a xxxxxxx --hostname=mtl-ipa01d.unix.cnppd.lab -n > unix.cnppd.lab -p xxxxx -r UNIX.CNPPD.LAB --setup-dns > --forwarder=165.115.52.21--fowarder=165.115.51.21* > Server host name [mtl-ipa01d.unix.cnppd.lab]: > > Warning: skipping DNS resolution of host mtl-ipa01d.unix.cnppd.lab > The IPA Master Server will be configured with > Hostname: mtl-ipa01d.unix.cnppd.lab > IP address: 165.115.118.21 > Domain name: unix.cnppd.lab > > Do you want to configure the reverse zone? [yes]: > Please specify the reverse zone name [118.115.165.in-addr.arpa.]: > Using reverse zone 118.115.165.in-addr.arpa. > > > Restarting the directory server > Restarting the KDC > Restarting the web server > Configuring named: > [1/9]: adding DNS container > [2/9]: setting up our zone > [3/9]: setting up reverse zone > [4/9]: setting up our own record > [5/9]: setting up kerberos principal > [6/9]: setting up named.conf > [7/9]: restarting named > [8/9]: configuring named to start on boot > [9/9]: changing resolv.conf to point to ourselves > done configuring named. > ============================================================================== > Setup complete > > > I did set my client with > [root at mtl-vdi01d ~]# ipa-client-install > --server=mtl-ipa01d.unix.cnppd.lab --domain=UNIX.CNPPD.LAB > --realm=UNIX.CNPPD.LAB --mkhomedir > Discovery was successful! > Hostname: mtl-vdi01d.cn.ca > Realm: UNIX.CNPPD.LAB > DNS Domain: UNIX.CNPPD.LAB > IPA Server: mtl-ipa01d.unix.cnppd.lab > BaseDN: dc=unix,dc=cnppd,dc=lab > > > Continue to configure the system with these values? [no]: yes > User authorized to enroll computers: admin > Synchronizing time with KDC... > Password for admin at UNIX.CNPPD.LAB: > > Enrolled in IPA realm UNIX.CNPPD.LAB > Created /etc/ipa/default.conf > Configured[root at mtl-vdi01d ~]# ipa-client-install > --server=mtl-ipa01d.unix.cnppd.lab --domain=UNIX.CNPPD.LAB > --realm=UNIX.CNPPD.LAB --mkhomedir > Discovery was successful! > Hostname: mtl-vdi01d.cn.ca > Realm: UNIX.CNPPD.LAB > DNS Domain: UNIX.CNPPD.LAB > IPA Server: mtl-ipa01d.unix.cnppd.lab > BaseDN: dc=unix,dc=cnppd,dc=lab > > > Continue to configure the system with these values? [no]: yes > User authorized to enroll computers: admin > Synchronizing time with KDC... > Password for admin at UNIX.CNPPD.LAB: > > Enrolled in IPA realm UNIX.CNPPD.LAB > Created /etc/ipa/default.conf > Configured /etc/sssd/sssd.conf > Configured /etc/krb5.conf for IPA realm UNIX.CNPPD.LAB > SSSD enabled > Unable to find 'admin' user with 'getent passwd admin'! > Recognized configuration: SSSD > NTP enabled > Client configuration complete. /etc/sssd/sssd.conf > Configured /etc/krb5.conf for IPA realm UNIX.CNPPD.LAB > SSSD enabled > Unable to find 'admin' user with 'getent passwd admin'! > Recognized configuration: SSSD > NTP enabled > Client configuration complete. > > you can see that ipa did enroll my client > > [root at mtl-ipa01d ~]# ipa host-find > --------------- > 2 hosts matched > --------------- > Host name: mtl-ipa01d.unix.cnppd.lab > Principal name: host/mtl-ipa01d.unix.cnppd.lab at UNIX.CNPPD.LAB > Keytab: True > Password: False > Managed by: mtl-ipa01d.unix.cnppd.lab > > Host name: mtl-vdi01d.cn.ca > Certificate: > MIIDhTCCAm2gAwIBAgIBDDANBgkqhkiG9w0BAQsFADA5MRcwFQYDVQQKEw5VTklYLkNOUFBELkxBQjEeMBwGA1UEAxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTEyMDMxMzE4Mjc0MVoXDTE0MDMxNDE4Mjc0MVowNDEXMBUGA1UEChMOVU5JWC5DTlBQRC5MQUIxGTAXBgNVBAMTEG10bC12ZGkwMWQuY24uY2EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKTPD8p7Ttxn87Y/2CCu54GDTd/CS77irN6OYj9IznqMusHAIWsVVu5m0aT77iULYzO9lKmKCL9RuSnZuqsoppFZk8UJu1KAGKv2FQi7zck28P2t6XRhHXcLRRTq5Mzfd/QjFmCv3oxTP2gd/0rLZUTHJkTzqyYIMlExfQqnEBJCzfzukyFUB5S+X2DthiGOM7vcKPXlmG+VstebtsZ1FkE9LquyWGhSBjqycZM350zRwQP6MLKU4ZX11mit6+/AvRrOJW3Gw9JWRxDOullJG2mCjyFCsUKOX/Xz4VrJeSylIGJQk5kLfP2haSPhkKhG9FXy1vhwpXFF1GAa9DYvhvAgMBAAGjgZwwgZkwHwYDVR0jBBgwFoAUZtbp/CAAXZ/LZAKgUqcXPxgkOzcwRwYIKwYBBQUHAQEEOzA5MDcGCCsGAQUFBzABhitodHRwOi8vbXRsLWlwYTAxZC51bml4LmNucHBkLmxhYjo4MC9jYS9vY3NwMA4GA1UdDwEB/wQEAwIE8DAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwDQYJKoZIhvcNAQELBQADggEBAEPpr1rn+inQlxc+u7WAkyuRDd1af/ilUlldkB0n4l9Ni2Lkt+Gt7w6VYqS+/ZtqTPB/mQuISGDuqeEXSgWSc+1NQq1THgBACzfE5CbKWOcfGd/SnTqIA+/ITydi ntYB7SNQ0Vz6BOC9Uv/VmEPqD38ThR88qhK0+wmvdf2HyKOFAsu5Ty5qKaOyDHuhhA4AXEbQz8vRH3XQa/WtSf/zgRKiNeabEc5gWXEd9dSpm2UhW7oLuPlnKolI3IL1RUoc8WrKKLK1HdyrcNY+woZ2Jw4OCkyiGuWaNZHOEAmAlwmvQrFBlMsIPJfI/mxmAXufEO66AHf/747V2n1TvZrnkrQ= > Principal name: host/mtl-vdi01d.cn.ca at UNIX.CNPPD.LAB > Keytab: True > Password: False > Managed by: mtl-vdi01d.cn.ca > Subject: CN=mtl-vdi01d.cn.ca ,O=UNIX.CNPPD.LAB > Serial Number: 12 > Issuer: CN=Certificate Authority,O=UNIX.CNPPD.LAB > Not Before: Tue Mar 13 18:27:41 2012 UTC > Not After: Fri Mar 14 18:27:41 2014 UTC > Fingerprint (MD5): 26:f6:9f:32:3d:a0:13:43:8e:16:1a:7f:d7:43:7e:51 > Fingerprint (SHA1): > 4b:28:b2:a4:33:16:27:fc:16:cc:35:54:68:fc:b4:45:85:3f:dc:1a > ---------------------------- > Number of entries returned 2 > ---------------------------- > [root at mtl-ipa01d ~]# > > > > I keep getting "unable to find 'admin' user with 'getent passwd admin'! Can you check the sssd logs for any details? This is what does the user name resolution. You can read about sssd troubleshooting at https://fedorahosted.org/sssd/wiki/FAQ#Troubleshooting rob From g17jimmy at gmail.com Wed Mar 14 17:35:21 2012 From: g17jimmy at gmail.com (Jimmy) Date: Wed, 14 Mar 2012 13:35:21 -0400 Subject: [Freeipa-users] (no subject) Message-ID: My IPA server just stopped working with this error. I'm looking in to it, but if anyone knows what the issue is right off I'd appreciate any pointers you have. (when trying to do service ipa start) Starting dirsrv: PDH-CSP...[14/Mar/2012:17:24:34 +0000] - SSL alert: CERT_VerifyCertificateNow: verify certificate failed for cert Server-Cert of family cn=RSA,cn=encryption,cn=config (Netscape Portable Runtime error -8181 - Peer's Certificate has expired.) [ OK ] PKI-IPA...[14/Mar/2012:17:24:36 +0000] - SSL alert: CERT_VerifyCertificateNow: verify certificate failed for cert Server-Cert of family cn=RSA,cn=encryption,cn=config (Netscape Portable Runtime error -8181 - Peer's Certificate has expired.) [ OK ] I'm running on Fedora15, running IPA -- freeipa-server-2.1.1-1.fc15.x86_64. Thanks. From g17jimmy at gmail.com Wed Mar 14 18:10:40 2012 From: g17jimmy at gmail.com (Jimmy) Date: Wed, 14 Mar 2012 14:10:40 -0400 Subject: [Freeipa-users] (no subject) In-Reply-To: References: Message-ID: I changed the system date and it's functional now. I ran the command ` certutil -L -d /etc/httpd/alias -n Server-Cert` and see the expired cert. Looking at `ipa-getcert list` I see this-- Request ID '20110913154233': 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-XXXXX',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapdXXXXX//pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-XXXXX',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=XXXXX subject: CN=csp-idm.pdh.csp,O=XXXXX expires: 2012-03-11 15:42:32 UTC eku: id-kp-serverAuth track: yes auto-renew: yes It says "CA_UNREACHABLE", but ipactl status shows the CA running. Any ideas on why this is occurring? On Wed, Mar 14, 2012 at 1:35 PM, Jimmy wrote: > My IPA server just stopped working with this error. I'm looking in to > it, but if anyone knows what the issue is right off I'd appreciate any > pointers you have. > > (when trying to do service ipa start) > Starting dirsrv: > ? ?PDH-CSP...[14/Mar/2012:17:24:34 +0000] - SSL alert: > CERT_VerifyCertificateNow: verify certificate failed for cert > Server-Cert of family cn=RSA,cn=encryption,cn=config (Netscape > Portable Runtime error -8181 - Peer's Certificate has expired.) > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? [ ?OK ?] > ? ?PKI-IPA...[14/Mar/2012:17:24:36 +0000] - SSL alert: > CERT_VerifyCertificateNow: verify certificate failed for cert > Server-Cert of family cn=RSA,cn=encryption,cn=config (Netscape > Portable Runtime error -8181 - Peer's Certificate has expired.) > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? [ ?OK ?] > > > I'm running on Fedora15, running IPA -- freeipa-server-2.1.1-1.fc15.x86_64. > Thanks. > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From rcritten at redhat.com Wed Mar 14 18:22:32 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 14 Mar 2012 14:22:32 -0400 Subject: [Freeipa-users] (no subject) In-Reply-To: References: Message-ID: <4F60E1E8.6070103@redhat.com> Jimmy wrote: > I changed the system date and it's functional now. I ran the command ` > certutil -L -d /etc/httpd/alias -n Server-Cert` and see the expired > cert. Looking at `ipa-getcert list` I see this-- > > Request ID '20110913154233': > 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-XXXXX',nickname='Server-Cert',token='NSS > Certificate DB',pinfile='/etc/dirsrv/slapdXXXXX//pwdfile.txt' > certificate: > type=NSSDB,location='/etc/dirsrv/slapd-XXXXX',nickname='Server-Cert',token='NSS > Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=XXXXX > subject: CN=csp-idm.pdh.csp,O=XXXXX > expires: 2012-03-11 15:42:32 UTC > eku: id-kp-serverAuth > track: yes > auto-renew: yes > > It says "CA_UNREACHABLE", but ipactl status shows the CA running. Any > ideas on why this is occurring? The Apache error log may hold some clues. You might try: # ipa-getcert resubmit -i 20110913154233 Then watch the Apache log to see what it is doing. The CA logs are in /var/log/pki-ca and may provide some details as well. rob > > On Wed, Mar 14, 2012 at 1:35 PM, Jimmy wrote: >> My IPA server just stopped working with this error. I'm looking in to >> it, but if anyone knows what the issue is right off I'd appreciate any >> pointers you have. >> >> (when trying to do service ipa start) >> Starting dirsrv: >> PDH-CSP...[14/Mar/2012:17:24:34 +0000] - SSL alert: >> CERT_VerifyCertificateNow: verify certificate failed for cert >> Server-Cert of family cn=RSA,cn=encryption,cn=config (Netscape >> Portable Runtime error -8181 - Peer's Certificate has expired.) >> [ OK ] >> PKI-IPA...[14/Mar/2012:17:24:36 +0000] - SSL alert: >> CERT_VerifyCertificateNow: verify certificate failed for cert >> Server-Cert of family cn=RSA,cn=encryption,cn=config (Netscape >> Portable Runtime error -8181 - Peer's Certificate has expired.) >> [ OK ] >> >> >> I'm running on Fedora15, running IPA -- freeipa-server-2.1.1-1.fc15.x86_64. >> Thanks. >> >> _______________________________________________ >> 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 g17jimmy at gmail.com Wed Mar 14 19:03:05 2012 From: g17jimmy at gmail.com (Jimmy) Date: Wed, 14 Mar 2012 15:03:05 -0400 Subject: [Freeipa-users] (no subject) In-Reply-To: <4F60E1E8.6070103@redhat.com> References: <4F60E1E8.6070103@redhat.com> Message-ID: I can set the date to before 3/12(the cert expiry date) and things start just fine. The apache logs don't seem to hold much info other than "the cert is expired." CA logs have even less info. I did find a similar issue on the mailing list - http://comments.gmane.org/gmane.linux.redhat.freeipa.user/3104 - but I don't see a resolution, I don't see how the cert is supposed to get renewed. On Wed, Mar 14, 2012 at 2:22 PM, Rob Crittenden wrote: > Jimmy wrote: >> >> I changed the system date and it's functional now. I ran the command ` >> certutil -L -d /etc/httpd/alias -n Server-Cert` and see the expired >> cert. Looking at `ipa-getcert list` I see this-- >> >> Request ID '20110913154233': >> ? ? ? ? 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-XXXXX',nickname='Server-Cert',token='NSS >> Certificate DB',pinfile='/etc/dirsrv/slapdXXXXX//pwdfile.txt' >> ? ? ? ? certificate: >> >> type=NSSDB,location='/etc/dirsrv/slapd-XXXXX',nickname='Server-Cert',token='NSS >> Certificate DB' >> ? ? ? ? CA: IPA >> ? ? ? ? issuer: CN=Certificate Authority,O=XXXXX >> ? ? ? ? subject: CN=csp-idm.pdh.csp,O=XXXXX >> ? ? ? ? expires: 2012-03-11 15:42:32 UTC >> ? ? ? ? eku: id-kp-serverAuth >> ? ? ? ? track: yes >> ? ? ? ? auto-renew: yes >> >> It says "CA_UNREACHABLE", but ipactl status shows the CA running. Any >> ideas on why this is occurring? > > > The Apache error log may hold some clues. You might try: > > # ipa-getcert resubmit -i 20110913154233 > > Then watch the Apache log to see what it is doing. The CA logs are in > /var/log/pki-ca and may provide some details as well. > > rob > > >> >> On Wed, Mar 14, 2012 at 1:35 PM, Jimmy ?wrote: >>> >>> My IPA server just stopped working with this error. I'm looking in to >>> it, but if anyone knows what the issue is right off I'd appreciate any >>> pointers you have. >>> >>> (when trying to do service ipa start) >>> Starting dirsrv: >>> ? ?PDH-CSP...[14/Mar/2012:17:24:34 +0000] - SSL alert: >>> CERT_VerifyCertificateNow: verify certificate failed for cert >>> Server-Cert of family cn=RSA,cn=encryption,cn=config (Netscape >>> Portable Runtime error -8181 - Peer's Certificate has expired.) >>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? [ ?OK ?] >>> ? ?PKI-IPA...[14/Mar/2012:17:24:36 +0000] - SSL alert: >>> CERT_VerifyCertificateNow: verify certificate failed for cert >>> Server-Cert of family cn=RSA,cn=encryption,cn=config (Netscape >>> Portable Runtime error -8181 - Peer's Certificate has expired.) >>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? [ ?OK ?] >>> >>> >>> I'm running on Fedora15, running IPA -- >>> freeipa-server-2.1.1-1.fc15.x86_64. >>> Thanks. >>> >>> _______________________________________________ >>> 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 rcritten at redhat.com Wed Mar 14 19:09:46 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 14 Mar 2012 15:09:46 -0400 Subject: [Freeipa-users] (no subject) In-Reply-To: References: <4F60E1E8.6070103@redhat.com> Message-ID: <4F60ECFA.9050201@redhat.com> Jimmy wrote: > I can set the date to before 3/12(the cert expiry date) and things > start just fine. The apache logs don't seem to hold much info other > than "the cert is expired." CA logs have even less info. > > I did find a similar issue on the mailing list - > http://comments.gmane.org/gmane.linux.redhat.freeipa.user/3104 - but I > don't see a resolution, I don't see how the cert is supposed to get > renewed. certmonger is supposed to automatically renew it. It apparently tried and failed because the CA was unreachable. If you set the date back again and execute this command it will resubmit the request and perhaps the logs will contain the details we need. rob > > On Wed, Mar 14, 2012 at 2:22 PM, Rob Crittenden wrote: >> Jimmy wrote: >>> >>> I changed the system date and it's functional now. I ran the command ` >>> certutil -L -d /etc/httpd/alias -n Server-Cert` and see the expired >>> cert. Looking at `ipa-getcert list` I see this-- >>> >>> Request ID '20110913154233': >>> 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-XXXXX',nickname='Server-Cert',token='NSS >>> Certificate DB',pinfile='/etc/dirsrv/slapdXXXXX//pwdfile.txt' >>> certificate: >>> >>> type=NSSDB,location='/etc/dirsrv/slapd-XXXXX',nickname='Server-Cert',token='NSS >>> Certificate DB' >>> CA: IPA >>> issuer: CN=Certificate Authority,O=XXXXX >>> subject: CN=csp-idm.pdh.csp,O=XXXXX >>> expires: 2012-03-11 15:42:32 UTC >>> eku: id-kp-serverAuth >>> track: yes >>> auto-renew: yes >>> >>> It says "CA_UNREACHABLE", but ipactl status shows the CA running. Any >>> ideas on why this is occurring? >> >> >> The Apache error log may hold some clues. You might try: >> >> # ipa-getcert resubmit -i 20110913154233 >> >> Then watch the Apache log to see what it is doing. The CA logs are in >> /var/log/pki-ca and may provide some details as well. >> >> rob >> >> >>> >>> On Wed, Mar 14, 2012 at 1:35 PM, Jimmy wrote: >>>> >>>> My IPA server just stopped working with this error. I'm looking in to >>>> it, but if anyone knows what the issue is right off I'd appreciate any >>>> pointers you have. >>>> >>>> (when trying to do service ipa start) >>>> Starting dirsrv: >>>> PDH-CSP...[14/Mar/2012:17:24:34 +0000] - SSL alert: >>>> CERT_VerifyCertificateNow: verify certificate failed for cert >>>> Server-Cert of family cn=RSA,cn=encryption,cn=config (Netscape >>>> Portable Runtime error -8181 - Peer's Certificate has expired.) >>>> [ OK ] >>>> PKI-IPA...[14/Mar/2012:17:24:36 +0000] - SSL alert: >>>> CERT_VerifyCertificateNow: verify certificate failed for cert >>>> Server-Cert of family cn=RSA,cn=encryption,cn=config (Netscape >>>> Portable Runtime error -8181 - Peer's Certificate has expired.) >>>> [ OK ] >>>> >>>> >>>> I'm running on Fedora15, running IPA -- >>>> freeipa-server-2.1.1-1.fc15.x86_64. >>>> Thanks. >>>> >>>> _______________________________________________ >>>> 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 g17jimmy at gmail.com Wed Mar 14 19:22:19 2012 From: g17jimmy at gmail.com (Jimmy) Date: Wed, 14 Mar 2012 15:22:19 -0400 Subject: [Freeipa-users] (no subject) In-Reply-To: <4F60ECFA.9050201@redhat.com> References: <4F60E1E8.6070103@redhat.com> <4F60ECFA.9050201@redhat.com> Message-ID: I set the date back and ran the command and this is what I see in the httpd log. The ca directory does not exist, I verified it as missing. Any idea why this is? Did I miss something in the install of IPA? [Sun Jan 01 00:20:46 2012] [error] ipa: INFO: sslget 'https://XXXXXX:443/ca/agent/ca/displayBySerial' [Sun Jan 01 00:20:46 2012] [error] [client 192.168.201.102] File does not exist: /var/www/html/ca [Sun Jan 01 00:20:46 2012] [error] ipa: INFO: host/XXXX at XXXXXX: cert_request(u'MIIDQzCCAisCAQAwLDEQMA4GA1UEChMHUERILkNTUDEYMBYGA1UEAxMPY3NwLWlkbS5wZGguY3NwMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr0EHCdyTuteryFZ2bdEl+V4OATR/xk8ELthmvlwT/5qubZKwlCWS6yLawgdyCg9Yw737A7qGe0BPxHv6E+as10NxppEPsn9BOi+TPRIMYNMNNYmO2sce2pvkMkVBqsF7Gn7mF7e5+Bp c7ApnDGP7WLsAjbso8EvLUrqVMTNyiziCSHiNk+/Fi1Om6K5GKzKkqfEDex0RK+kpMswgcaZHhmW3i+y3UxFZsJjOg3R4fJAfC0+My2d1Vx4052+EgWAbSNpSj7zmLGM2+dkmgMo5Li7jjgJe8VsrqOV4L5IgqtGVJ0EOb7EP7gynbV oa74m4XrVwEP8rd/M5RxAnD1JPuwIDAQABoIHRMBoGCSqGSIb3DQEJFDENEwtTZXJ2ZXItQ2VydDCBsgYJKoZIhvcNAQkOMYGkMIGhMA4GA1UdDwEBAAQEAwIE8DB3BgNVHREBAQAEbTBroCwGCisGAQQBgjcUAgOgHgwcbGRhcC9jc 3AtaWRtLnBkaC5jc3BAUERILkNTUKA7BgYrBgEFAgKgMTAvoAkbB1BESC5DU1ChIjAgoAMCAQGhGTAXGwRsZGFwGw9jc3AtaWRtLnBkaC5jc3AwFgYDVR0lAQEABAwwCgYIKwYBBQUHAwEwDQYJKoZIhvcNAQELBQADggEBABD/Hwbg f5NJNUYt0+ntMDHiilMFkSaO6ryQ36/pCH1oR+vI+PCeClHewPo0v99h4Z8W8L7CQtDdNBUMl/JVHH5Lz7cBF8A/jXZQ+naV17EEuXncacM8AvYh5dL2yih+8RpPalEmSgz5rijtbSigfNGrZn0Mh3qOW1kbsz+GDaaT9wLFxvdJyqg dKds2tsp0KzHIMcJuw3cwOfH8zrBRV28XYhMLm0OOhj92uxgax5UPY2VyHP5UOtOnfuduU1ZXa+o8QIXqX7/HyDSCLGwiPJscAsp9cRzjn4KvqzZDOcdGEjXmCGfrmUiMcuzVyTDR2SdAWrHdbRmXeyVxmiBPzdk=', principal=u 'ldap/XXXXXXXX at XXXXXXX', add=True): CertificateOperationError On Wed, Mar 14, 2012 at 3:09 PM, Rob Crittenden wrote: > Jimmy wrote: >> >> I can set the date to before 3/12(the cert expiry date) and things >> start just fine. The apache logs don't seem to hold much info other >> than "the cert is expired." CA logs have even less info. >> >> I did find a similar issue on the mailing list - >> http://comments.gmane.org/gmane.linux.redhat.freeipa.user/3104 - but I >> don't see a resolution, I don't see how the cert is supposed to get >> renewed. > > > certmonger is supposed to automatically renew it. It apparently tried and > failed because the CA was unreachable. If you set the date back again and > execute this command it will resubmit the request and perhaps the logs will > contain the details we need. > > > rob > >> >> On Wed, Mar 14, 2012 at 2:22 PM, Rob Crittenden >> ?wrote: >>> >>> Jimmy wrote: >>>> >>>> >>>> I changed the system date and it's functional now. I ran the command ` >>>> certutil -L -d /etc/httpd/alias -n Server-Cert` and see the expired >>>> cert. Looking at `ipa-getcert list` I see this-- >>>> >>>> Request ID '20110913154233': >>>> ? ? ? ? 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-XXXXX',nickname='Server-Cert',token='NSS >>>> Certificate DB',pinfile='/etc/dirsrv/slapdXXXXX//pwdfile.txt' >>>> ? ? ? ? certificate: >>>> >>>> >>>> type=NSSDB,location='/etc/dirsrv/slapd-XXXXX',nickname='Server-Cert',token='NSS >>>> Certificate DB' >>>> ? ? ? ? CA: IPA >>>> ? ? ? ? issuer: CN=Certificate Authority,O=XXXXX >>>> ? ? ? ? subject: CN=csp-idm.pdh.csp,O=XXXXX >>>> ? ? ? ? expires: 2012-03-11 15:42:32 UTC >>>> ? ? ? ? eku: id-kp-serverAuth >>>> ? ? ? ? track: yes >>>> ? ? ? ? auto-renew: yes >>>> >>>> It says "CA_UNREACHABLE", but ipactl status shows the CA running. Any >>>> ideas on why this is occurring? >>> >>> >>> >>> The Apache error log may hold some clues. You might try: >>> >>> # ipa-getcert resubmit -i 20110913154233 >>> >>> Then watch the Apache log to see what it is doing. The CA logs are in >>> /var/log/pki-ca and may provide some details as well. >>> >>> rob >>> >>> >>>> >>>> On Wed, Mar 14, 2012 at 1:35 PM, Jimmy ? ?wrote: >>>>> >>>>> >>>>> My IPA server just stopped working with this error. I'm looking in to >>>>> it, but if anyone knows what the issue is right off I'd appreciate any >>>>> pointers you have. >>>>> >>>>> (when trying to do service ipa start) >>>>> Starting dirsrv: >>>>> ? ?PDH-CSP...[14/Mar/2012:17:24:34 +0000] - SSL alert: >>>>> CERT_VerifyCertificateNow: verify certificate failed for cert >>>>> Server-Cert of family cn=RSA,cn=encryption,cn=config (Netscape >>>>> Portable Runtime error -8181 - Peer's Certificate has expired.) >>>>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? [ ?OK ?] >>>>> ? ?PKI-IPA...[14/Mar/2012:17:24:36 +0000] - SSL alert: >>>>> CERT_VerifyCertificateNow: verify certificate failed for cert >>>>> Server-Cert of family cn=RSA,cn=encryption,cn=config (Netscape >>>>> Portable Runtime error -8181 - Peer's Certificate has expired.) >>>>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? [ ?OK ?] >>>>> >>>>> >>>>> I'm running on Fedora15, running IPA -- >>>>> freeipa-server-2.1.1-1.fc15.x86_64. >>>>> Thanks. >>>>> >>>>> _______________________________________________ >>>>> 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 sbingram at gmail.com Wed Mar 14 19:30:30 2012 From: sbingram at gmail.com (Stephen Ingram) Date: Wed, 14 Mar 2012 12:30:30 -0700 Subject: [Freeipa-users] (no subject) In-Reply-To: References: <4F60E1E8.6070103@redhat.com> <4F60ECFA.9050201@redhat.com> Message-ID: On Wed, Mar 14, 2012 at 12:22 PM, Jimmy wrote: > I set the date back and ran the command and this is what I see in the > httpd log. The ca directory does not exist, I verified it as missing. > Any idea why this is? Did I miss something in the install of IPA? > > [Sun Jan 01 00:20:46 2012] [error] ipa: INFO: sslget > 'https://XXXXXX:443/ca/agent/ca/displayBySerial' > [Sun Jan 01 00:20:46 2012] [error] [client 192.168.201.102] File does > not exist: /var/www/html/ca > [Sun Jan 01 00:20:46 2012] [error] ipa: INFO: host/XXXX at XXXXXX: > cert_request(u'MIIDQzCCAisCAQAwLDEQMA4GA1UEChMHUERILkNTUDEYMBYGA1UEAxMPY3NwLWlkbS5wZGguY3NwMIIBIjAN > BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr0EHCdyTuteryFZ2bdEl+V4OATR/xk8ELthmvlwT/5qubZKwlCWS6yLawgdyCg9Yw737A7qGe0BPxHv6E+as10NxppEPsn9BOi+TPRIMYNMNNYmO2sce2pvkMkVBqsF7Gn7mF7e5+Bp > c7ApnDGP7WLsAjbso8EvLUrqVMTNyiziCSHiNk+/Fi1Om6K5GKzKkqfEDex0RK+kpMswgcaZHhmW3i+y3UxFZsJjOg3R4fJAfC0+My2d1Vx4052+EgWAbSNpSj7zmLGM2+dkmgMo5Li7jjgJe8VsrqOV4L5IgqtGVJ0EOb7EP7gynbV > oa74m4XrVwEP8rd/M5RxAnD1JPuwIDAQABoIHRMBoGCSqGSIb3DQEJFDENEwtTZXJ2ZXItQ2VydDCBsgYJKoZIhvcNAQkOMYGkMIGhMA4GA1UdDwEBAAQEAwIE8DB3BgNVHREBAQAEbTBroCwGCisGAQQBgjcUAgOgHgwcbGRhcC9jc > 3AtaWRtLnBkaC5jc3BAUERILkNTUKA7BgYrBgEFAgKgMTAvoAkbB1BESC5DU1ChIjAgoAMCAQGhGTAXGwRsZGFwGw9jc3AtaWRtLnBkaC5jc3AwFgYDVR0lAQEABAwwCgYIKwYBBQUHAwEwDQYJKoZIhvcNAQELBQADggEBABD/Hwbg > f5NJNUYt0+ntMDHiilMFkSaO6ryQ36/pCH1oR+vI+PCeClHewPo0v99h4Z8W8L7CQtDdNBUMl/JVHH5Lz7cBF8A/jXZQ+naV17EEuXncacM8AvYh5dL2yih+8RpPalEmSgz5rijtbSigfNGrZn0Mh3qOW1kbsz+GDaaT9wLFxvdJyqg > dKds2tsp0KzHIMcJuw3cwOfH8zrBRV28XYhMLm0OOhj92uxgax5UPY2VyHP5UOtOnfuduU1ZXa+o8QIXqX7/HyDSCLGwiPJscAsp9cRzjn4KvqzZDOcdGEjXmCGfrmUiMcuzVyTDR2SdAWrHdbRmXeyVxmiBPzdk=', > principal=u > 'ldap/XXXXXXXX at XXXXXXX', add=True): CertificateOperationError Are you sure you are not missing some of your config files?(/etc/httpd/conf.d/ipa-pki-proxy.conf) There is no /var/www/html/ca. Your httpd config should redirect this to the certificate server. Steve From g17jimmy at gmail.com Wed Mar 14 19:41:03 2012 From: g17jimmy at gmail.com (Jimmy) Date: Wed, 14 Mar 2012 15:41:03 -0400 Subject: [Freeipa-users] (no subject) In-Reply-To: References: <4F60E1E8.6070103@redhat.com> <4F60ECFA.9050201@redhat.com> Message-ID: Good call Stephen. the /etc/httpd/conf.d/ipa-pki-proxy.conf is missing. I'm not sure how that is missing. Was there a separate step for the IPA install that took care of the CA? It's been 6 months since I installed so I don't remember right off. On Wed, Mar 14, 2012 at 3:30 PM, Stephen Ingram wrote: > On Wed, Mar 14, 2012 at 12:22 PM, Jimmy wrote: >> I set the date back and ran the command and this is what I see in the >> httpd log. The ca directory does not exist, I verified it as missing. >> Any idea why this is? Did I miss something in the install of IPA? >> >> [Sun Jan 01 00:20:46 2012] [error] ipa: INFO: sslget >> 'https://XXXXXX:443/ca/agent/ca/displayBySerial' >> [Sun Jan 01 00:20:46 2012] [error] [client 192.168.201.102] File does >> not exist: /var/www/html/ca >> [Sun Jan 01 00:20:46 2012] [error] ipa: INFO: host/XXXX at XXXXXX: >> cert_request(u'MIIDQzCCAisCAQAwLDEQMA4GA1UEChMHUERILkNTUDEYMBYGA1UEAxMPY3NwLWlkbS5wZGguY3NwMIIBIjAN >> BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr0EHCdyTuteryFZ2bdEl+V4OATR/xk8ELthmvlwT/5qubZKwlCWS6yLawgdyCg9Yw737A7qGe0BPxHv6E+as10NxppEPsn9BOi+TPRIMYNMNNYmO2sce2pvkMkVBqsF7Gn7mF7e5+Bp >> c7ApnDGP7WLsAjbso8EvLUrqVMTNyiziCSHiNk+/Fi1Om6K5GKzKkqfEDex0RK+kpMswgcaZHhmW3i+y3UxFZsJjOg3R4fJAfC0+My2d1Vx4052+EgWAbSNpSj7zmLGM2+dkmgMo5Li7jjgJe8VsrqOV4L5IgqtGVJ0EOb7EP7gynbV >> oa74m4XrVwEP8rd/M5RxAnD1JPuwIDAQABoIHRMBoGCSqGSIb3DQEJFDENEwtTZXJ2ZXItQ2VydDCBsgYJKoZIhvcNAQkOMYGkMIGhMA4GA1UdDwEBAAQEAwIE8DB3BgNVHREBAQAEbTBroCwGCisGAQQBgjcUAgOgHgwcbGRhcC9jc >> 3AtaWRtLnBkaC5jc3BAUERILkNTUKA7BgYrBgEFAgKgMTAvoAkbB1BESC5DU1ChIjAgoAMCAQGhGTAXGwRsZGFwGw9jc3AtaWRtLnBkaC5jc3AwFgYDVR0lAQEABAwwCgYIKwYBBQUHAwEwDQYJKoZIhvcNAQELBQADggEBABD/Hwbg >> f5NJNUYt0+ntMDHiilMFkSaO6ryQ36/pCH1oR+vI+PCeClHewPo0v99h4Z8W8L7CQtDdNBUMl/JVHH5Lz7cBF8A/jXZQ+naV17EEuXncacM8AvYh5dL2yih+8RpPalEmSgz5rijtbSigfNGrZn0Mh3qOW1kbsz+GDaaT9wLFxvdJyqg >> dKds2tsp0KzHIMcJuw3cwOfH8zrBRV28XYhMLm0OOhj92uxgax5UPY2VyHP5UOtOnfuduU1ZXa+o8QIXqX7/HyDSCLGwiPJscAsp9cRzjn4KvqzZDOcdGEjXmCGfrmUiMcuzVyTDR2SdAWrHdbRmXeyVxmiBPzdk=', >> principal=u >> 'ldap/XXXXXXXX at XXXXXXX', add=True): CertificateOperationError > > Are you sure you are not missing some of your config > files?(/etc/httpd/conf.d/ipa-pki-proxy.conf) There is no > /var/www/html/ca. Your httpd config should redirect this to the > certificate server. > > Steve From sbingram at gmail.com Wed Mar 14 19:47:42 2012 From: sbingram at gmail.com (Stephen Ingram) Date: Wed, 14 Mar 2012 12:47:42 -0700 Subject: [Freeipa-users] (no subject) In-Reply-To: References: <4F60E1E8.6070103@redhat.com> <4F60ECFA.9050201@redhat.com> Message-ID: On Wed, Mar 14, 2012 at 12:41 PM, Jimmy wrote: > Good call Stephen. the /etc/httpd/conf.d/ipa-pki-proxy.conf is > missing. I'm not sure how that is missing. Was there a separate step > for the IPA install that took care of the CA? It's been 6 months since > I installed so I don't remember right off. It's part of the freeipa-server package. I noticed that you are running version 2.1.1 of ipa. 2.1.4 is the latest in the non-devel repos. You might want to try a yum update as you might have other differing packages as well. Make sure you read about the changes in 2.1.4 which might affect machines you have already enrolled. Steve From g17jimmy at gmail.com Wed Mar 14 20:30:16 2012 From: g17jimmy at gmail.com (Jimmy) Date: Wed, 14 Mar 2012 16:30:16 -0400 Subject: [Freeipa-users] (no subject) In-Reply-To: References: <4F60E1E8.6070103@redhat.com> <4F60ECFA.9050201@redhat.com> Message-ID: Ok, I upgraded and that didn't go so well, now IPA doesn't start: >service ipa start Starting Directory Service Starting dirsrv: XXXXXX... [ OK ] PKI-IPA... [ OK ] Failed to read data from Directory Service: Failed to get list of services to probe status! Configured hostname 'XXXXXXXXX' does not match any master server in LDAP: No master found because of error: {'matched': 'dc=XXX,dc=XXX', 'desc': 'No such object'} Shutting down Shutting down dirsrv: XXXXXX... [ OK ] PKI-IPA... [ OK ] *BUT* /etc/httpd/conf.d/ipa-pki-proxy.conf exists now... On Wed, Mar 14, 2012 at 3:47 PM, Stephen Ingram wrote: > On Wed, Mar 14, 2012 at 12:41 PM, Jimmy wrote: >> Good call Stephen. the /etc/httpd/conf.d/ipa-pki-proxy.conf is >> missing. I'm not sure how that is missing. Was there a separate step >> for the IPA install that took care of the CA? It's been 6 months since >> I installed so I don't remember right off. > > It's part of the freeipa-server package. I noticed that you are > running version 2.1.1 of ipa. 2.1.4 is the latest in the non-devel > repos. You might want to try a yum update as you might have other > differing packages as well. Make sure you read about the changes in > 2.1.4 which might affect machines you have already enrolled. > > Steve From rcritten at redhat.com Wed Mar 14 20:33:23 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 14 Mar 2012 16:33:23 -0400 Subject: [Freeipa-users] (no subject) In-Reply-To: References: <4F60E1E8.6070103@redhat.com> <4F60ECFA.9050201@redhat.com> Message-ID: <4F610093.1030504@redhat.com> Jimmy wrote: > Ok, I upgraded and that didn't go so well, now IPA doesn't start: > >> service ipa start > Starting Directory Service > Starting dirsrv: > XXXXXX... [ OK ] > PKI-IPA... [ OK ] > Failed to read data from Directory Service: Failed to get list of > services to probe status! > Configured hostname 'XXXXXXXXX' does not match any master server in LDAP: > No master found because of error: {'matched': 'dc=XXX,dc=XXX', 'desc': > 'No such object'} > Shutting down > Shutting down dirsrv: > XXXXXX... [ OK ] > PKI-IPA... [ OK ] > > *BUT* /etc/httpd/conf.d/ipa-pki-proxy.conf exists now... That would suggest your hostname doesn't match the hostname that IPA was installed as. Start just dirsrv and see what masters are configured: ldapsearch -x -b cn=masters,cn=ipa,cn=etc,dc=example,dc=com rob > > On Wed, Mar 14, 2012 at 3:47 PM, Stephen Ingram wrote: >> On Wed, Mar 14, 2012 at 12:41 PM, Jimmy wrote: >>> Good call Stephen. the /etc/httpd/conf.d/ipa-pki-proxy.conf is >>> missing. I'm not sure how that is missing. Was there a separate step >>> for the IPA install that took care of the CA? It's been 6 months since >>> I installed so I don't remember right off. >> >> It's part of the freeipa-server package. I noticed that you are >> running version 2.1.1 of ipa. 2.1.4 is the latest in the non-devel >> repos. You might want to try a yum update as you might have other >> differing packages as well. Make sure you read about the changes in >> 2.1.4 which might affect machines you have already enrolled. >> >> Steve From sbingram at gmail.com Wed Mar 14 20:39:22 2012 From: sbingram at gmail.com (Stephen Ingram) Date: Wed, 14 Mar 2012 13:39:22 -0700 Subject: [Freeipa-users] (no subject) In-Reply-To: References: <4F60E1E8.6070103@redhat.com> <4F60ECFA.9050201@redhat.com> Message-ID: On Wed, Mar 14, 2012 at 1:30 PM, Jimmy wrote: > Ok, I upgraded and that didn't go so well, now IPA doesn't start: > >>service ipa start > Starting Directory Service > Starting dirsrv: > ? ?XXXXXX... ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? [ ?OK ?] > ? ?PKI-IPA... ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? [ ?OK ?] > Failed to read data from Directory Service: Failed to get list of > services to probe status! > Configured hostname 'XXXXXXXXX' does not match any master server in LDAP: > No master found because of error: {'matched': 'dc=XXX,dc=XXX', 'desc': > 'No such object'} > Shutting down > Shutting down dirsrv: > ? ?XXXXXX... ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? [ ?OK ?] > ? ?PKI-IPA... ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? [ ?OK ?] > > *BUT* /etc/httpd/conf.d/ipa-pki-proxy.conf exists now... Does output from "hostname" (or, the hostname in /etc/sysconfig/network) match what is in your /etc/hosts file for the server name? Does dc=XXX,dc=XXX match at least the domain part of your hostname? If I remember correctly, IPA requires a fully qualified hostname, not just the host part. I can't possibly imagine how this worked to begin with though if all of this is not correct. Steve From g17jimmy at gmail.com Wed Mar 14 20:45:11 2012 From: g17jimmy at gmail.com (Jimmy) Date: Wed, 14 Mar 2012 16:45:11 -0400 Subject: [Freeipa-users] (no subject) In-Reply-To: References: <4F60E1E8.6070103@redhat.com> <4F60ECFA.9050201@redhat.com> Message-ID: In response to the last to suggestions, here's what I see: hostname ipa.abc.xyz /etc/hosts: 192.168.201.102 ipa.abc.xyz ipa ldapsearch -x -b cn=masters,cn=ipa,cn=etc,dc=abc,dc=xyz # extended LDIF # # LDAPv3 # base with scope subtree # filter: (objectclass=*) # requesting: ALL # # search result search: 2 result: 32 No such object matchedDN: dc=abc,dc=xyz # numResponses: 1 From rmeggins at redhat.com Wed Mar 14 20:45:53 2012 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 14 Mar 2012 14:45:53 -0600 Subject: [Freeipa-users] (no subject) In-Reply-To: References: <4F60E1E8.6070103@redhat.com> <4F60ECFA.9050201@redhat.com> Message-ID: <4F610381.8020109@redhat.com> On 03/14/2012 02:45 PM, Jimmy wrote: > In response to the last to suggestions, here's what I see: > > hostname > ipa.abc.xyz > > /etc/hosts: > 192.168.201.102 ipa.abc.xyz ipa > > ldapsearch -x -b cn=masters,cn=ipa,cn=etc,dc=abc,dc=xyz > # extended LDIF > # > # LDAPv3 > # base with scope subtree > # filter: (objectclass=*) > # requesting: ALL > # > > # search result > search: 2 > result: 32 No such object > matchedDN: dc=abc,dc=xyz rpm -qi 389-ds-base > > # numResponses: 1 > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From g17jimmy at gmail.com Wed Mar 14 20:49:56 2012 From: g17jimmy at gmail.com (Jimmy) Date: Wed, 14 Mar 2012 16:49:56 -0400 Subject: [Freeipa-users] (no subject) In-Reply-To: <4F610381.8020109@redhat.com> References: <4F60E1E8.6070103@redhat.com> <4F60ECFA.9050201@redhat.com> <4F610381.8020109@redhat.com> Message-ID: rpm -qi 389-ds-base Name : 389-ds-base Version : 1.2.10.3 Release : 1.fc15 Architecture: x86_64 Install Date: Wed 04 Jan 2012 12:06:20 AM UTC Group : System Environment/Daemons Size : 4816676 License : GPLv2 with exceptions Signature : RSA/SHA256, Wed 07 Mar 2012 09:47:47 PM UTC, Key ID b4ebf579069c8460 Source RPM : 389-ds-base-1.2.10.3-1.fc15.src.rpm Build Date : Mon 05 Mar 2012 10:50:10 PM UTC Build Host : x86-11.phx2.fedoraproject.org Relocations : (not relocatable) Packager : Fedora Project Vendor : Fedora Project URL : http://port389.org/ Summary : 389 Directory Server (base) Description : 389 Directory Server is an LDAPv3 compliant server. The base package includes the LDAP server and command line utilities for server administration. On Wed, Mar 14, 2012 at 4:45 PM, Rich Megginson wrote: > On 03/14/2012 02:45 PM, Jimmy wrote: >> >> In response to the last to suggestions, here's what I see: >> >> hostname >> ipa.abc.xyz >> >> /etc/hosts: >> 192.168.201.102 ipa.abc.xyz ipa >> >> ldapsearch -x -b cn=masters,cn=ipa,cn=etc,dc=abc,dc=xyz >> # extended LDIF >> # >> # LDAPv3 >> # base ?with scope subtree >> # filter: (objectclass=*) >> # requesting: ALL >> # >> >> # search result >> search: 2 >> result: 32 No such object >> matchedDN: dc=abc,dc=xyz > > rpm -qi 389-ds-base >> >> >> # numResponses: 1 >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > From sigbjorn at nixtra.com Wed Mar 14 20:55:28 2012 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Wed, 14 Mar 2012 21:55:28 +0100 Subject: [Freeipa-users] need info on AD / IPA coexistence In-Reply-To: References: <74B15185-79AA-40FB-80D2-87E737E2D840@redhat.com> <833D8E48405E064EBC54C84EC6B36E404CBBF614@STAWINCOX10MBX1.staff.vuw.ac.nz> <1330058876.18690.117.camel@willson.li.ssimo.org> <1331147501.26197.103.camel@willson.li.ssimo.org> <4F586052.8070705@s3group.cz> Message-ID: <4F6105C0.7040802@nixtra.com> On 03/08/2012 01:40 PM, Sylvain Angers wrote: > > Does anyone was successful to hook their HP ilo, RHEV manager to IPA? > I've connected IPA to the RHEV manager, yes. It works fine. However it seem to require lookup up dns srv records to find the IPA servers, so I don't think it works unless you have your own DNS domain for IPA. Regards, Siggi From rmeggins at redhat.com Wed Mar 14 20:55:57 2012 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 14 Mar 2012 14:55:57 -0600 Subject: [Freeipa-users] (no subject) In-Reply-To: References: <4F60E1E8.6070103@redhat.com> <4F60ECFA.9050201@redhat.com> <4F610381.8020109@redhat.com> Message-ID: <4F6105DD.3010504@redhat.com> On 03/14/2012 02:49 PM, Jimmy wrote: > rpm -qi 389-ds-base > Name : 389-ds-base > Version : 1.2.10.3 > Release : 1.fc15 > Architecture: x86_64 > Install Date: Wed 04 Jan 2012 12:06:20 AM UTC > Group : System Environment/Daemons > Size : 4816676 > License : GPLv2 with exceptions > Signature : RSA/SHA256, Wed 07 Mar 2012 09:47:47 PM UTC, Key ID > b4ebf579069c8460 > Source RPM : 389-ds-base-1.2.10.3-1.fc15.src.rpm > Build Date : Mon 05 Mar 2012 10:50:10 PM UTC > Build Host : x86-11.phx2.fedoraproject.org > Relocations : (not relocatable) > Packager : Fedora Project > Vendor : Fedora Project > URL : http://port389.org/ > Summary : 389 Directory Server (base) > Description : > 389 Directory Server is an LDAPv3 compliant server. The base package includes > the LDAP server and command line utilities for server administration. dbscan -f /var/lib/dirsrv/slapd-YOUR-DOMAIN/db/userRoot/entryrdn.db4|grep cn=etc > > On Wed, Mar 14, 2012 at 4:45 PM, Rich Megginson wrote: >> On 03/14/2012 02:45 PM, Jimmy wrote: >>> In response to the last to suggestions, here's what I see: >>> >>> hostname >>> ipa.abc.xyz >>> >>> /etc/hosts: >>> 192.168.201.102 ipa.abc.xyz ipa >>> >>> ldapsearch -x -b cn=masters,cn=ipa,cn=etc,dc=abc,dc=xyz >>> # extended LDIF >>> # >>> # LDAPv3 >>> # base with scope subtree >>> # filter: (objectclass=*) >>> # requesting: ALL >>> # >>> >>> # search result >>> search: 2 >>> result: 32 No such object >>> matchedDN: dc=abc,dc=xyz >> rpm -qi 389-ds-base >>> >>> # numResponses: 1 >>> >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >> From g17jimmy at gmail.com Wed Mar 14 21:05:53 2012 From: g17jimmy at gmail.com (Jimmy) Date: Wed, 14 Mar 2012 17:05:53 -0400 Subject: [Freeipa-users] (no subject) In-Reply-To: <4F6105DD.3010504@redhat.com> References: <4F60E1E8.6070103@redhat.com> <4F60ECFA.9050201@redhat.com> <4F610381.8020109@redhat.com> <4F6105DD.3010504@redhat.com> Message-ID: This doesn't appear to be very good. If I drop the `grep` I see the data I would expect to see. dbscan -f /var/lib/dirsrv/slapd-YOUR-DOMAIN/db/userRoot/entryrdn.db4|grep cn=etc 22:cn=etc ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" C22:cn=etc C22:cn=etc C22:cn=etc C22:cn=etc C22:cn=etc C22:cn=etc C22:cn=etc C22:cn=etc ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" P22:cn=etc ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" From rmeggins at redhat.com Wed Mar 14 21:06:49 2012 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 14 Mar 2012 15:06:49 -0600 Subject: [Freeipa-users] (no subject) In-Reply-To: References: <4F60E1E8.6070103@redhat.com> <4F60ECFA.9050201@redhat.com> <4F610381.8020109@redhat.com> <4F6105DD.3010504@redhat.com> Message-ID: <4F610869.40501@redhat.com> On 03/14/2012 03:05 PM, Jimmy wrote: > This doesn't appear to be very good. If I drop the `grep` I see the > data I would expect to see. > > dbscan -f /var/lib/dirsrv/slapd-YOUR-DOMAIN/db/userRoot/entryrdn.db4|grep cn=etc > 22:cn=etc > ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" > ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" > C22:cn=etc > C22:cn=etc > C22:cn=etc > C22:cn=etc > C22:cn=etc > C22:cn=etc > C22:cn=etc > C22:cn=etc > ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" > ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" > ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" > ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" > P22:cn=etc > ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" > ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" > ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" > ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" find /var/lib/dirsrv/slapd-YOUR-DOMAIN/db -name DBVERSION -exec cat {} \; From g17jimmy at gmail.com Wed Mar 14 21:13:19 2012 From: g17jimmy at gmail.com (Jimmy) Date: Wed, 14 Mar 2012 17:13:19 -0400 Subject: [Freeipa-users] (no subject) In-Reply-To: <4F610869.40501@redhat.com> References: <4F60E1E8.6070103@redhat.com> <4F60ECFA.9050201@redhat.com> <4F610381.8020109@redhat.com> <4F6105DD.3010504@redhat.com> <4F610869.40501@redhat.com> Message-ID: bdb/4.8/libback-ldbm/newidl/rdn-format-2/dn-4514 bdb/4.8/libback-ldbm/newidl/rdn-format-2/dn-4514 On Wed, Mar 14, 2012 at 5:06 PM, Rich Megginson wrote: > On 03/14/2012 03:05 PM, Jimmy wrote: >> >> This doesn't appear to be very good. If I drop the `grep` I see the >> data I would expect to see. >> >> dbscan -f /var/lib/dirsrv/slapd-YOUR-DOMAIN/db/userRoot/entryrdn.db4|grep >> cn=etc >> 22:cn=etc >> ? ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >> ? ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >> C22:cn=etc >> C22:cn=etc >> C22:cn=etc >> C22:cn=etc >> C22:cn=etc >> C22:cn=etc >> C22:cn=etc >> C22:cn=etc >> ? ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >> ? ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >> ? ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >> ? ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >> P22:cn=etc >> ? ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >> ? ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >> ? ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >> ? ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" > > find /var/lib/dirsrv/slapd-YOUR-DOMAIN/db -name DBVERSION -exec cat {} \; From rmeggins at redhat.com Wed Mar 14 21:11:49 2012 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 14 Mar 2012 15:11:49 -0600 Subject: [Freeipa-users] (no subject) In-Reply-To: References: <4F60E1E8.6070103@redhat.com> <4F60ECFA.9050201@redhat.com> <4F610381.8020109@redhat.com> <4F6105DD.3010504@redhat.com> <4F610869.40501@redhat.com> Message-ID: <4F610995.2020500@redhat.com> On 03/14/2012 03:13 PM, Jimmy wrote: > bdb/4.8/libback-ldbm/newidl/rdn-format-2/dn-4514 > bdb/4.8/libback-ldbm/newidl/rdn-format-2/dn-4514 It appears that the entryrdn upgrade didn't work. Can you sanitize your /var/log/dirsrv/slapd-DOMAIN/errors file and post it to fpaste.org? > > On Wed, Mar 14, 2012 at 5:06 PM, Rich Megginson wrote: >> On 03/14/2012 03:05 PM, Jimmy wrote: >>> This doesn't appear to be very good. If I drop the `grep` I see the >>> data I would expect to see. >>> >>> dbscan -f /var/lib/dirsrv/slapd-YOUR-DOMAIN/db/userRoot/entryrdn.db4|grep >>> cn=etc >>> 22:cn=etc >>> ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>> ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>> C22:cn=etc >>> C22:cn=etc >>> C22:cn=etc >>> C22:cn=etc >>> C22:cn=etc >>> C22:cn=etc >>> C22:cn=etc >>> C22:cn=etc >>> ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>> ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>> ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>> ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>> P22:cn=etc >>> ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>> ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>> ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>> ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >> find /var/lib/dirsrv/slapd-YOUR-DOMAIN/db -name DBVERSION -exec cat {} \; From g17jimmy at gmail.com Wed Mar 14 21:26:20 2012 From: g17jimmy at gmail.com (Jimmy) Date: Wed, 14 Mar 2012 17:26:20 -0400 Subject: [Freeipa-users] (no subject) In-Reply-To: <4F610995.2020500@redhat.com> References: <4F60E1E8.6070103@redhat.com> <4F60ECFA.9050201@redhat.com> <4F610381.8020109@redhat.com> <4F6105DD.3010504@redhat.com> <4F610869.40501@redhat.com> <4F610995.2020500@redhat.com> Message-ID: http://fpaste.org/nSWh/ Here ya go Jimmy On Wed, Mar 14, 2012 at 5:11 PM, Rich Megginson wrote: > On 03/14/2012 03:13 PM, Jimmy wrote: >> >> bdb/4.8/libback-ldbm/newidl/rdn-format-2/dn-4514 >> bdb/4.8/libback-ldbm/newidl/rdn-format-2/dn-4514 > > It appears that the entryrdn upgrade didn't work. ?Can you sanitize your > /var/log/dirsrv/slapd-DOMAIN/errors file and post it to fpaste.org? > >> >> On Wed, Mar 14, 2012 at 5:06 PM, Rich Megginson >> ?wrote: >>> >>> On 03/14/2012 03:05 PM, Jimmy wrote: >>>> >>>> This doesn't appear to be very good. If I drop the `grep` I see the >>>> data I would expect to see. >>>> >>>> dbscan -f >>>> /var/lib/dirsrv/slapd-YOUR-DOMAIN/db/userRoot/entryrdn.db4|grep >>>> cn=etc >>>> 22:cn=etc >>>> ? ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>> ? ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>> C22:cn=etc >>>> C22:cn=etc >>>> C22:cn=etc >>>> C22:cn=etc >>>> C22:cn=etc >>>> C22:cn=etc >>>> C22:cn=etc >>>> C22:cn=etc >>>> ? ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>> ? ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>> ? ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>> ? ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>> P22:cn=etc >>>> ? ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>> ? ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>> ? ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>> ? ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>> >>> find /var/lib/dirsrv/slapd-YOUR-DOMAIN/db -name DBVERSION -exec cat {} \; > > From rmeggins at redhat.com Wed Mar 14 21:41:24 2012 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 14 Mar 2012 15:41:24 -0600 Subject: [Freeipa-users] (no subject) In-Reply-To: References: <4F60ECFA.9050201@redhat.com> <4F610381.8020109@redhat.com> <4F6105DD.3010504@redhat.com> <4F610869.40501@redhat.com> <4F610995.2020500@redhat.com> Message-ID: <4F611084.3010606@redhat.com> On 03/14/2012 03:26 PM, Jimmy wrote: > http://fpaste.org/nSWh/ Thanks. Looks like you are going to have to export your database to ldif, re-import it, and then re-initialize all of your replicas. http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Populating_Directory_Databases-Exporting_Data.html For ipa, the scripts are in /var/lib/dirsrv/scripts-YOUR-DOMAIN For ipa, your database is userRoot (so -n userRoot) so first, do db2ldif, then ldif2db, then use ipa-replica-manage to reinitialize all of your replicas > > Here ya go > Jimmy > > On Wed, Mar 14, 2012 at 5:11 PM, Rich Megginson wrote: >> On 03/14/2012 03:13 PM, Jimmy wrote: >>> bdb/4.8/libback-ldbm/newidl/rdn-format-2/dn-4514 >>> bdb/4.8/libback-ldbm/newidl/rdn-format-2/dn-4514 >> It appears that the entryrdn upgrade didn't work. Can you sanitize your >> /var/log/dirsrv/slapd-DOMAIN/errors file and post it to fpaste.org? >> >>> On Wed, Mar 14, 2012 at 5:06 PM, Rich Megginson >>> wrote: >>>> On 03/14/2012 03:05 PM, Jimmy wrote: >>>>> This doesn't appear to be very good. If I drop the `grep` I see the >>>>> data I would expect to see. >>>>> >>>>> dbscan -f >>>>> /var/lib/dirsrv/slapd-YOUR-DOMAIN/db/userRoot/entryrdn.db4|grep >>>>> cn=etc >>>>> 22:cn=etc >>>>> ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>>> ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>>> C22:cn=etc >>>>> C22:cn=etc >>>>> C22:cn=etc >>>>> C22:cn=etc >>>>> C22:cn=etc >>>>> C22:cn=etc >>>>> C22:cn=etc >>>>> C22:cn=etc >>>>> ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>>> ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>>> ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>>> ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>>> P22:cn=etc >>>>> ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>>> ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>>> ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>>> ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>> find /var/lib/dirsrv/slapd-YOUR-DOMAIN/db -name DBVERSION -exec cat {} \; >> From g17jimmy at gmail.com Wed Mar 14 21:51:07 2012 From: g17jimmy at gmail.com (Jimmy Caldwell) Date: Wed, 14 Mar 2012 17:51:07 -0400 Subject: [Freeipa-users] (no subject) In-Reply-To: <4F611084.3010606@redhat.com> References: <4F60ECFA.9050201@redhat.com> <4F610381.8020109@redhat.com> <4F6105DD.3010504@redhat.com> <4F610869.40501@redhat.com> <4F610995.2020500@redhat.com> <4F611084.3010606@redhat.com> Message-ID: <-512731158224897185@unknownmsgid> Is this a normal thing to occur during upgrade? If it was just a fluke I can revert to the snapshot from just before the upgrade and try again. Sent from my mobile device On Mar 14, 2012, at 17:44, Rich Megginson wrote: > On 03/14/2012 03:26 PM, Jimmy wrote: >> http://fpaste.org/nSWh/ > Thanks. Looks like you are going to have to export your database to ldif, re-import it, and then re-initialize all of your replicas. > > http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Populating_Directory_Databases-Exporting_Data.html > > For ipa, the scripts are in /var/lib/dirsrv/scripts-YOUR-DOMAIN > > For ipa, your database is userRoot (so -n userRoot) > > so first, do db2ldif, then ldif2db, then use ipa-replica-manage to reinitialize all of your replicas >> >> Here ya go >> Jimmy >> >> On Wed, Mar 14, 2012 at 5:11 PM, Rich Megginson wrote: >>> On 03/14/2012 03:13 PM, Jimmy wrote: >>>> bdb/4.8/libback-ldbm/newidl/rdn-format-2/dn-4514 >>>> bdb/4.8/libback-ldbm/newidl/rdn-format-2/dn-4514 >>> It appears that the entryrdn upgrade didn't work. Can you sanitize your >>> /var/log/dirsrv/slapd-DOMAIN/errors file and post it to fpaste.org? >>> >>>> On Wed, Mar 14, 2012 at 5:06 PM, Rich Megginson >>>> wrote: >>>>> On 03/14/2012 03:05 PM, Jimmy wrote: >>>>>> This doesn't appear to be very good. If I drop the `grep` I see the >>>>>> data I would expect to see. >>>>>> >>>>>> dbscan -f >>>>>> /var/lib/dirsrv/slapd-YOUR-DOMAIN/db/userRoot/entryrdn.db4|grep >>>>>> cn=etc >>>>>> 22:cn=etc >>>>>> ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>>>> ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>>>> C22:cn=etc >>>>>> C22:cn=etc >>>>>> C22:cn=etc >>>>>> C22:cn=etc >>>>>> C22:cn=etc >>>>>> C22:cn=etc >>>>>> C22:cn=etc >>>>>> C22:cn=etc >>>>>> ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>>>> ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>>>> ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>>>> ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>>>> P22:cn=etc >>>>>> ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>>>> ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>>>> ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>>>> ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>>> find /var/lib/dirsrv/slapd-YOUR-DOMAIN/db -name DBVERSION -exec cat {} \; >>> > From rmeggins at redhat.com Wed Mar 14 21:59:01 2012 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 14 Mar 2012 15:59:01 -0600 Subject: [Freeipa-users] (no subject) In-Reply-To: <-512731158224897185@unknownmsgid> References: <4F610381.8020109@redhat.com> <4F6105DD.3010504@redhat.com> <4F610869.40501@redhat.com> <4F610995.2020500@redhat.com> <4F611084.3010606@redhat.com> <-512731158224897185@unknownmsgid> Message-ID: <4F6114A5.3090507@redhat.com> On 03/14/2012 03:51 PM, Jimmy Caldwell wrote: > Is this a normal thing to occur during upgrade? Unfortunately, in this particular case, yes. > If it was just a fluke > I can revert to the snapshot from just before the upgrade and try > again. I think you will run into the same exact problem. > > Sent from my mobile device > > On Mar 14, 2012, at 17:44, Rich Megginson wrote: > >> On 03/14/2012 03:26 PM, Jimmy wrote: >>> http://fpaste.org/nSWh/ >> Thanks. Looks like you are going to have to export your database to ldif, re-import it, and then re-initialize all of your replicas. >> >> http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Populating_Directory_Databases-Exporting_Data.html >> >> For ipa, the scripts are in /var/lib/dirsrv/scripts-YOUR-DOMAIN >> >> For ipa, your database is userRoot (so -n userRoot) >> >> so first, do db2ldif, then ldif2db, then use ipa-replica-manage to reinitialize all of your replicas >>> Here ya go >>> Jimmy >>> >>> On Wed, Mar 14, 2012 at 5:11 PM, Rich Megginson wrote: >>>> On 03/14/2012 03:13 PM, Jimmy wrote: >>>>> bdb/4.8/libback-ldbm/newidl/rdn-format-2/dn-4514 >>>>> bdb/4.8/libback-ldbm/newidl/rdn-format-2/dn-4514 >>>> It appears that the entryrdn upgrade didn't work. Can you sanitize your >>>> /var/log/dirsrv/slapd-DOMAIN/errors file and post it to fpaste.org? >>>> >>>>> On Wed, Mar 14, 2012 at 5:06 PM, Rich Megginson >>>>> wrote: >>>>>> On 03/14/2012 03:05 PM, Jimmy wrote: >>>>>>> This doesn't appear to be very good. If I drop the `grep` I see the >>>>>>> data I would expect to see. >>>>>>> >>>>>>> dbscan -f >>>>>>> /var/lib/dirsrv/slapd-YOUR-DOMAIN/db/userRoot/entryrdn.db4|grep >>>>>>> cn=etc >>>>>>> 22:cn=etc >>>>>>> ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>>>>> ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>>>>> C22:cn=etc >>>>>>> C22:cn=etc >>>>>>> C22:cn=etc >>>>>>> C22:cn=etc >>>>>>> C22:cn=etc >>>>>>> C22:cn=etc >>>>>>> C22:cn=etc >>>>>>> C22:cn=etc >>>>>>> ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>>>>> ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>>>>> ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>>>>> ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>>>>> P22:cn=etc >>>>>>> ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>>>>> ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>>>>> ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>>>>> ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>>>> find /var/lib/dirsrv/slapd-YOUR-DOMAIN/db -name DBVERSION -exec cat {} \; From rmeggins at redhat.com Wed Mar 14 23:37:31 2012 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 14 Mar 2012 17:37:31 -0600 Subject: [Freeipa-users] (no subject) In-Reply-To: <4F6114A5.3090507@redhat.com> References: <4F610381.8020109@redhat.com> <4F6105DD.3010504@redhat.com> <4F610869.40501@redhat.com> <4F610995.2020500@redhat.com> <4F611084.3010606@redhat.com> <-512731158224897185@unknownmsgid> <4F6114A5.3090507@redhat.com> Message-ID: <4F612BBB.3070404@redhat.com> On 03/14/2012 03:59 PM, Rich Megginson wrote: > On 03/14/2012 03:51 PM, Jimmy Caldwell wrote: >> Is this a normal thing to occur during upgrade? > Unfortunately, in this particular case, yes. >> If it was just a fluke >> I can revert to the snapshot from just before the upgrade and try >> again. > I think you will run into the same exact problem. Another problem - according to http://fpaste.org/nSWh/ you were using 1.2.10.a1 - I'm not sure how that happened - on F-15, none of the alpha versions were pushed to Stable afaik (unlike F-16). We did not (nor normally do not) test upgrades from alpha versions to "stable" versions. According to https://admin.fedoraproject.org/updates/FEDORA-2011-13460/389-ds-base-1.2.10-0.1.a1.fc15 this was never pushed to Stable, only to Testing. >> >> Sent from my mobile device >> >> On Mar 14, 2012, at 17:44, Rich Megginson wrote: >> >>> On 03/14/2012 03:26 PM, Jimmy wrote: >>>> http://fpaste.org/nSWh/ >>> Thanks. Looks like you are going to have to export your database to >>> ldif, re-import it, and then re-initialize all of your replicas. >>> >>> http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Populating_Directory_Databases-Exporting_Data.html >>> >>> >>> For ipa, the scripts are in /var/lib/dirsrv/scripts-YOUR-DOMAIN >>> >>> For ipa, your database is userRoot (so -n userRoot) >>> >>> so first, do db2ldif, then ldif2db, then use ipa-replica-manage to >>> reinitialize all of your replicas >>>> Here ya go >>>> Jimmy >>>> >>>> On Wed, Mar 14, 2012 at 5:11 PM, Rich >>>> Megginson wrote: >>>>> On 03/14/2012 03:13 PM, Jimmy wrote: >>>>>> bdb/4.8/libback-ldbm/newidl/rdn-format-2/dn-4514 >>>>>> bdb/4.8/libback-ldbm/newidl/rdn-format-2/dn-4514 >>>>> It appears that the entryrdn upgrade didn't work. Can you >>>>> sanitize your >>>>> /var/log/dirsrv/slapd-DOMAIN/errors file and post it to fpaste.org? >>>>> >>>>>> On Wed, Mar 14, 2012 at 5:06 PM, Rich Megginson >>>>>> wrote: >>>>>>> On 03/14/2012 03:05 PM, Jimmy wrote: >>>>>>>> This doesn't appear to be very good. If I drop the `grep` I see >>>>>>>> the >>>>>>>> data I would expect to see. >>>>>>>> >>>>>>>> dbscan -f >>>>>>>> /var/lib/dirsrv/slapd-YOUR-DOMAIN/db/userRoot/entryrdn.db4|grep >>>>>>>> cn=etc >>>>>>>> 22:cn=etc >>>>>>>> ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>>>>>> ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>>>>>> C22:cn=etc >>>>>>>> C22:cn=etc >>>>>>>> C22:cn=etc >>>>>>>> C22:cn=etc >>>>>>>> C22:cn=etc >>>>>>>> C22:cn=etc >>>>>>>> C22:cn=etc >>>>>>>> C22:cn=etc >>>>>>>> ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>>>>>> ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>>>>>> ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>>>>>> ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>>>>>> P22:cn=etc >>>>>>>> ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>>>>>> ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>>>>>> ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>>>>>> ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>>>>> find /var/lib/dirsrv/slapd-YOUR-DOMAIN/db -name DBVERSION -exec >>>>>>> cat {} \; > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From hakan.hagenrud at atea.se Thu Mar 15 06:57:02 2012 From: hakan.hagenrud at atea.se (=?iso-8859-1?Q?Hagenrud_H=E5kan?=) Date: Thu, 15 Mar 2012 07:57:02 +0100 Subject: [Freeipa-users] Bind current mac clients? Message-ID: <63D5CEF6-DFC9-4BCB-96BD-D034B2285E9F@atea.se> Hello I just joined this list so please excuse if this question has been asked Is anyone out there binding mac clients (10.7.x) to IPA? I have tried it with some success. The mac-client can join the IPA domain and the Kerberos domain but no user from the domain can log in to the mac-computer. My guess is that I need to map the LDAP values from IPA with what the mac-client expects. Anyone? Thanks H?kan Hagenrud -------------- next part -------------- An HTML attachment was scrubbed... URL: From thildred at redhat.com Thu Mar 15 07:57:11 2012 From: thildred at redhat.com (Tim Hildred) Date: Thu, 15 Mar 2012 03:57:11 -0400 (EDT) Subject: [Freeipa-users] Role Required for Web Portal Access In-Reply-To: <6d8c36a8-81de-4f1b-8249-26be9561fac4@zmail11.collab.prod.int.phx2.redhat.com> Message-ID: Hey all; I preparing to use IPA as the Directory Server for my RHEV installation. Formerly in RHEV, you could change users passwords using the RHEV User Portal itself. With RHEV 3.0, this is no longer posssible. Instead, users need to be able to change their password using the IPA Web Administration Portal. I've set it up so that the IPA portal can be accessed using username and password rather than a Kerberos ticket. I've set all the users passwords to a default value. I'd like them to be able to log on to the IPA web UI, update only their own password (and other details about themselves), and carry on. Therefore, I don't want to give them admin roles, but some lesser, possibly custom role. Is this possible? Thanks! -- Tim Hildred Content Author - Engineering Content Services, Red Hat, Inc. Brisbane, Australia Email: thildred at redhat.com Mobile: +61 4 666 25242 IRC: thildred From mkosek at redhat.com Thu Mar 15 09:24:34 2012 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 15 Mar 2012 10:24:34 +0100 Subject: [Freeipa-users] Role Required for Web Portal Access In-Reply-To: References: Message-ID: <1331803474.27127.16.camel@balmora.brq.redhat.com> On Thu, 2012-03-15 at 03:57 -0400, Tim Hildred wrote: > Hey all; > I preparing to use IPA as the Directory Server for my RHEV installation. Formerly in RHEV, you could change users passwords using the RHEV User Portal itself. With RHEV 3.0, this is no longer posssible. Instead, users need to be able to change their password using the IPA Web Administration Portal. I've set it up so that the IPA portal can be accessed using username and password rather than a Kerberos ticket. I've set all the users passwords to a default value. > > I'd like them to be able to log on to the IPA web UI, update only their own password (and other details about themselves), and carry on. > > Therefore, I don't want to give them admin roles, but some lesser, possibly custom role. > > Is this possible? > > Thanks! Hello Tim, yes, this is possible. Any user can log in to WebUI and change his account details or set the new password. They don't need to have assigned any custom role, there are selfservice permissions that allow that (you can check them with `ipa selfservice-find`). Users with no admin role really see just the one tab with his account details so that he is not distracted with all IPA WebUI configuration options. Martin From g17jimmy at gmail.com Thu Mar 15 13:15:22 2012 From: g17jimmy at gmail.com (Jimmy) Date: Thu, 15 Mar 2012 09:15:22 -0400 Subject: [Freeipa-users] (no subject) In-Reply-To: <4F612BBB.3070404@redhat.com> References: <4F610381.8020109@redhat.com> <4F6105DD.3010504@redhat.com> <4F610869.40501@redhat.com> <4F610995.2020500@redhat.com> <4F611084.3010606@redhat.com> <-512731158224897185@unknownmsgid> <4F6114A5.3090507@redhat.com> <4F612BBB.3070404@redhat.com> Message-ID: The version 1.2.10.a1 is odd, because it was originally installed using yum. I didn't hack it together at all. I'll do the export/import and see how it goes. -Jimmy On Wed, Mar 14, 2012 at 7:37 PM, Rich Megginson wrote: > On 03/14/2012 03:59 PM, Rich Megginson wrote: >> >> On 03/14/2012 03:51 PM, Jimmy Caldwell wrote: >>> >>> Is this a normal thing to occur during upgrade? >> >> Unfortunately, in this particular case, yes. >>> >>> If it was just a fluke >>> I can revert to the snapshot from just before the upgrade and try >>> again. >> >> I think you will run into the same exact problem. > > > Another problem - according to http://fpaste.org/nSWh/ you were using > 1.2.10.a1 - I'm not sure how that happened - on F-15, none of the alpha > versions were pushed to Stable afaik (unlike F-16). ?We did not (nor > normally do not) test upgrades from alpha versions to "stable" versions. > ?According to > https://admin.fedoraproject.org/updates/FEDORA-2011-13460/389-ds-base-1.2.10-0.1.a1.fc15 > this was never pushed to Stable, only to Testing. > >>> >>> Sent from my mobile device >>> >>> On Mar 14, 2012, at 17:44, Rich Megginson ?wrote: >>> >>>> On 03/14/2012 03:26 PM, Jimmy wrote: >>>>> >>>>> http://fpaste.org/nSWh/ >>>> >>>> Thanks. ?Looks like you are going to have to export your database to >>>> ldif, re-import it, and then re-initialize all of your replicas. >>>> >>>> >>>> http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Populating_Directory_Databases-Exporting_Data.html >>>> >>>> For ipa, the scripts are in /var/lib/dirsrv/scripts-YOUR-DOMAIN >>>> >>>> For ipa, your database is userRoot (so -n userRoot) >>>> >>>> so first, do db2ldif, then ldif2db, then use ipa-replica-manage to >>>> reinitialize all of your replicas >>>>> >>>>> Here ya go >>>>> Jimmy >>>>> >>>>> On Wed, Mar 14, 2012 at 5:11 PM, Rich Megginson >>>>> wrote: >>>>>> >>>>>> On 03/14/2012 03:13 PM, Jimmy wrote: >>>>>>> >>>>>>> bdb/4.8/libback-ldbm/newidl/rdn-format-2/dn-4514 >>>>>>> bdb/4.8/libback-ldbm/newidl/rdn-format-2/dn-4514 >>>>>> >>>>>> It appears that the entryrdn upgrade didn't work. ?Can you sanitize >>>>>> your >>>>>> /var/log/dirsrv/slapd-DOMAIN/errors file and post it to fpaste.org? >>>>>> >>>>>>> On Wed, Mar 14, 2012 at 5:06 PM, Rich Megginson >>>>>>> ?wrote: >>>>>>>> >>>>>>>> On 03/14/2012 03:05 PM, Jimmy wrote: >>>>>>>>> >>>>>>>>> This doesn't appear to be very good. If I drop the `grep` I see the >>>>>>>>> data I would expect to see. >>>>>>>>> >>>>>>>>> dbscan -f >>>>>>>>> /var/lib/dirsrv/slapd-YOUR-DOMAIN/db/userRoot/entryrdn.db4|grep >>>>>>>>> cn=etc >>>>>>>>> 22:cn=etc >>>>>>>>> ? ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>>>>>>> ? ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>>>>>>> C22:cn=etc >>>>>>>>> C22:cn=etc >>>>>>>>> C22:cn=etc >>>>>>>>> C22:cn=etc >>>>>>>>> C22:cn=etc >>>>>>>>> C22:cn=etc >>>>>>>>> C22:cn=etc >>>>>>>>> C22:cn=etc >>>>>>>>> ? ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>>>>>>> ? ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>>>>>>> ? ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>>>>>>> ? ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>>>>>>> P22:cn=etc >>>>>>>>> ? ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>>>>>>> ? ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>>>>>>> ? ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>>>>>>> ? ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>>>>>> >>>>>>>> find /var/lib/dirsrv/slapd-YOUR-DOMAIN/db -name DBVERSION -exec cat >>>>>>>> {} \; >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > From dimitris.tsompanidis at comeon.com Thu Mar 15 13:36:51 2012 From: dimitris.tsompanidis at comeon.com (Dimitris Tsompanidis) Date: Thu, 15 Mar 2012 14:36:51 +0100 Subject: [Freeipa-users] Replica creation problem - IPv6? Message-ID: <4F61F073.4000005@comeon.com> Hi all, I'm trying to set up a FreeIPA replica on a new Fedora 16 VM. The process fails when ipa-replica-install starts checking for connectivity from the master server side towards the new replica. # ipa-replica-install -N /var/lib/ipa/replica-info-ldaps01.example.com.gpg [... lines of output ...] Execute check on remote master Remote master check failed with following error message(s): Connection check failed! Please fix your network settings according to error messages above. If the check results are not valid it can be skipped with --skip-conncheck parameter. Running the connectivity check on its own from the server gives me the following output: Check connection from master to remote replica 'ldaps01.example.com': Directory Service: Unsecure port (389): FAILED Directory Service: Secure port (636): FAILED Kerberos KDC: TCP (88): FAILED Kerberos KDC: UDP (88): OK Kerberos Kpasswd: TCP (464): FAILED Kerberos Kpasswd: UDP (464): OK HTTP Server: Unsecure port (80): FAILED HTTP Server: Secure port (443): FAILED Port check failed! Inaccessible port(s): 389, 636, 88, 464, 80, 443 To actually see what's going on, I run 'netstat -tuan' to see what ports are open while ipa-replica-install waits for me to type my admin password (just before the remote master check): [root at ldaps01 ~]# netstat -tuan Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN tcp 0 0 192.168.98.10:22 192.168.10.128:12548 ESTABLISHED tcp 0 48 192.168.98.10:22 192.168.10.128:12597 ESTABLISHED tcp 0 0 :::80 :::* LISTEN tcp 0 0 :::464 :::* LISTEN tcp 0 0 :::88 :::* LISTEN tcp 0 0 :::443 :::* LISTEN tcp 0 0 :::636 :::* LISTEN tcp 0 0 :::389 :::* LISTEN udp 0 0 192.168.98.10:123 0.0.0.0:* udp 0 0 127.0.0.1:123 0.0.0.0:* udp 0 0 0.0.0.0:123 0.0.0.0:* udp 0 0 :::464 :::* udp 0 0 :::88 :::* udp 0 0 :::123 :::* It seems that the replica procedure automatically binds to IPv6 addresses (although I've disabled IPv6 on eth0 and on loopback, remove IPv6 entries from /etc/hosts and /etc/resolve.conf). NTP listens on both ipv4 and ipv6 locahost but that's because I choose to handle it a separate service on its own. FreeIPA server is 2.1.4-5 on both ldap (master) and ldaps01 (slave). Regards, Dimitris -- Dimitris Tsompanidis -------------- next part -------------- An HTML attachment was scrubbed... URL: From kelvin at kindsight.net Thu Mar 15 15:20:06 2012 From: kelvin at kindsight.net (Kelvin Edmison) Date: Thu, 15 Mar 2012 10:20:06 -0500 Subject: [Freeipa-users] Replica creation problem - IPv6? In-Reply-To: <4F61F073.4000005@comeon.com> Message-ID: On 12-03-15 8:36 AM, "Dimitris Tsompanidis" wrote: > Hi all, > > I'm trying to set up a FreeIPA replica on a new Fedora 16 VM. > The process fails when ipa-replica-install starts checking for connectivity > from the master server side towards the new replica. > > > # ipa-replica-install -N /var/lib/ipa/replica-info-ldaps01.example.com.gpg > [... lines of output ...] > Execute check on remote master > > Remote master check failed with following error message(s): > > Connection check failed! > Please fix your network settings according to error messages above. > If the check results are not valid it can be skipped with --skip-conncheck > parameter. > > > Running the connectivity check on its own from the server gives me the > following output: > > Check connection from master to remote replica 'ldaps01.example.com': > Directory Service: Unsecure port (389): FAILED > Directory Service: Secure port (636): FAILED > Kerberos KDC: TCP (88): FAILED > Kerberos KDC: UDP (88): OK > Kerberos Kpasswd: TCP (464): FAILED > Kerberos Kpasswd: UDP (464): OK > HTTP Server: Unsecure port (80): FAILED > HTTP Server: Secure port (443): FAILED > Port check failed! Inaccessible port(s): 389, 636, 88, 464, 80, 443 > > > To actually see what's going on, I run 'netstat -tuan' to see what ports are > open while ipa-replica-install waits for me to type my admin password (just > before the remote master check): > > [root at ldaps01 ~]# netstat -tuan > Active Internet connections (servers and established) > Proto Recv-Q Send-Q Local Address Foreign Address > State > tcp 0 0 0.0.0.0:22 0.0.0.0:* > LISTEN > tcp 0 0 127.0.0.1:25 0.0.0.0:* > LISTEN > tcp 0 0 192.168.98.10:22 192.168.10.128:12548 > ESTABLISHED > tcp 0 48 192.168.98.10:22 192.168.10.128:12597 > ESTABLISHED > tcp 0 0 :::80 :::* > LISTEN > tcp 0 0 :::464 :::* > LISTEN > tcp 0 0 :::88 :::* > LISTEN > tcp 0 0 :::443 :::* > LISTEN > tcp 0 0 :::636 :::* > LISTEN > tcp 0 0 :::389 :::* > LISTEN > udp 0 0 192.168.98.10:123 0.0.0.0:* > udp 0 0 127.0.0.1:123 0.0.0.0:* > udp 0 0 0.0.0.0:123 0.0.0.0:* > udp 0 0 :::464 :::* > udp 0 0 :::88 :::* > udp 0 0 :::123 :::* > > It seems that the replica procedure automatically binds to IPv6 addresses > (although I've disabled IPv6 on eth0 and on loopback, remove IPv6 entries from > /etc/hosts and /etc/resolve.conf). > > NTP listens on both ipv4 and ipv6 locahost but that's because I choose to > handle it a separate service on its own. > > FreeIPA server is 2.1.4-5 on both ldap (master) and ldaps01 (slave). > > Regards, > Dimitris > The problem may be your firewall rules. run sudo /sbin/service iptables status to see the list of active firewall rules. Make sure that the list of open ports includes those in this ticket https://fedorahosted.org/freeipa/ticket/2110 Regards, Kelvin From dpal at redhat.com Thu Mar 15 14:46:56 2012 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 15 Mar 2012 10:46:56 -0400 Subject: [Freeipa-users] Bind current mac clients? In-Reply-To: <63D5CEF6-DFC9-4BCB-96BD-D034B2285E9F@atea.se> References: <63D5CEF6-DFC9-4BCB-96BD-D034B2285E9F@atea.se> Message-ID: <4F6200E0.1080608@redhat.com> On 03/15/2012 02:57 AM, Hagenrud H?kan wrote: > Hello > > I just joined this list so please excuse if this question has been asked > > Is anyone out there binding mac clients (10.7.x) to IPA? > > I have tried it with some success. The mac-client can join the IPA > domain and the Kerberos domain but no user from the domain can log in > to the mac-computer. My guess is that I need to map the LDAP values > from IPA with what the mac-client expects. Please search the archives. As I recall someone was doing it. There is also this http://freeipa.org/docs/1.2/Client_Setup_Guide/en-US/html/chap-Client_Configuration_Guide-Configuring_Macintosh_OS_X_as_an_IPA_Client.html But it is outdated and we are not sure if it works now. > > Anyone? > > Thanks > > H?kan Hagenrud > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dimitris.tsompanidis at comeon.com Thu Mar 15 14:47:39 2012 From: dimitris.tsompanidis at comeon.com (Dimitris Tsompanidis) Date: Thu, 15 Mar 2012 15:47:39 +0100 Subject: [Freeipa-users] Replica creation problem - IPv6? In-Reply-To: References: Message-ID: <4F62010B.7060700@comeon.com> On 15/03/2012 16:20, Kelvin Edmison wrote: > > > On 12-03-15 8:36 AM, "Dimitris Tsompanidis" > wrote: > >> Hi all, >> >> I'm trying to set up a FreeIPA replica on a new Fedora 16 VM. >> The process fails when ipa-replica-install starts checking for connectivity >> from the master server side towards the new replica. >> >> >> # ipa-replica-install -N /var/lib/ipa/replica-info-ldaps01.example.com.gpg >> [... lines of output ...] >> Execute check on remote master >> >> Remote master check failed with following error message(s): >> >> Connection check failed! >> Please fix your network settings according to error messages above. >> If the check results are not valid it can be skipped with --skip-conncheck >> parameter. >> >> >> Running the connectivity check on its own from the server gives me the >> following output: >> >> Check connection from master to remote replica 'ldaps01.example.com': >> Directory Service: Unsecure port (389): FAILED >> Directory Service: Secure port (636): FAILED >> Kerberos KDC: TCP (88): FAILED >> Kerberos KDC: UDP (88): OK >> Kerberos Kpasswd: TCP (464): FAILED >> Kerberos Kpasswd: UDP (464): OK >> HTTP Server: Unsecure port (80): FAILED >> HTTP Server: Secure port (443): FAILED >> Port check failed! Inaccessible port(s): 389, 636, 88, 464, 80, 443 >> >> >> To actually see what's going on, I run 'netstat -tuan' to see what ports are >> open while ipa-replica-install waits for me to type my admin password (just >> before the remote master check): >> >> [root at ldaps01 ~]# netstat -tuan >> Active Internet connections (servers and established) >> Proto Recv-Q Send-Q Local Address Foreign Address >> State >> tcp 0 0 0.0.0.0:22 0.0.0.0:* >> LISTEN >> tcp 0 0 127.0.0.1:25 0.0.0.0:* >> LISTEN >> tcp 0 0 192.168.98.10:22 192.168.10.128:12548 >> ESTABLISHED >> tcp 0 48 192.168.98.10:22 192.168.10.128:12597 >> ESTABLISHED >> tcp 0 0 :::80 :::* >> LISTEN >> tcp 0 0 :::464 :::* >> LISTEN >> tcp 0 0 :::88 :::* >> LISTEN >> tcp 0 0 :::443 :::* >> LISTEN >> tcp 0 0 :::636 :::* >> LISTEN >> tcp 0 0 :::389 :::* >> LISTEN >> udp 0 0 192.168.98.10:123 0.0.0.0:* >> udp 0 0 127.0.0.1:123 0.0.0.0:* >> udp 0 0 0.0.0.0:123 0.0.0.0:* >> udp 0 0 :::464 :::* >> udp 0 0 :::88 :::* >> udp 0 0 :::123 :::* >> >> It seems that the replica procedure automatically binds to IPv6 addresses >> (although I've disabled IPv6 on eth0 and on loopback, remove IPv6 entries from >> /etc/hosts and /etc/resolve.conf). >> >> NTP listens on both ipv4 and ipv6 locahost but that's because I choose to >> handle it a separate service on its own. >> >> FreeIPA server is 2.1.4-5 on both ldap (master) and ldaps01 (slave). >> >> Regards, >> Dimitris >> > The problem may be your firewall rules. run > sudo /sbin/service iptables status > to see the list of active firewall rules. > > Make sure that the list of open ports includes those in this ticket > https://fedorahosted.org/freeipa/ticket/2110 > > Regards, > Kelvin Firewalls on both machines are disabled and the firewall in between is wide open, especially in the master->slave direction where I allow everything. Dimitris From simo at redhat.com Thu Mar 15 14:54:33 2012 From: simo at redhat.com (Simo Sorce) Date: Thu, 15 Mar 2012 10:54:33 -0400 Subject: [Freeipa-users] Replica creation problem - IPv6? In-Reply-To: <4F62010B.7060700@comeon.com> References: <4F62010B.7060700@comeon.com> Message-ID: <1331823273.9238.224.camel@willson.li.ssimo.org> On Thu, 2012-03-15 at 15:47 +0100, Dimitris Tsompanidis wrote: > Firewalls on both machines are disabled and the firewall in between > is > wide open, especially in the master->slave direction where I allow > everything. > There is no master -> slave concept in FreeIPA, all servers are master and they work in a multi-master configuration, so all the proper communication channels need to be open both ways. Simo. -- Simo Sorce * Red Hat, Inc * New York From b.lingner at zik.hs-anhalt.de Thu Mar 15 09:33:41 2012 From: b.lingner at zik.hs-anhalt.de (Bennet Lingner) Date: Thu, 15 Mar 2012 10:33:41 +0100 Subject: [Freeipa-users] Windows Password Synchronization Error In-Reply-To: <4F60B9AB.3020706@redhat.com> References: <03b801cd01de$2a8f3c10$7fadb430$@zik.hs-anhalt.de> <4F60B9AB.3020706@redhat.com> Message-ID: Hi, Thank you for your reply. Version of freeipa and 389 packages: Freeipa server, python, admintools, client, server-selinux all in 2.1.4-5.fc16.i686 389-ds-base-1.2.10.3-1.fc16.i686 + libs Platform is Fedora 16 3.2.9-2.fc16.i686.PAE on AMD Opteron CPU Ldapmodify and ipa passwd are working perfectly, I?ve changed password in this ways and passwords were synchronized. So I conclude the problem is specific to AD Passsync? If it is so, do I have the possibility on AD side too to set or try something? Best regards. Bennet Lingner Von: Rich Megginson [mailto:rmeggins at redhat.com] Gesendet: Mittwoch, 14. M?rz 2012 16:31 An: Bennet Lingner Betreff: Re: Windows Password Synchronization Error On 03/14/2012 06:29 AM, Bennet Lingner wrote: Dear Mr. Megginson, I?ve seen in www, that you are very involved in 389 directory server, that?s why I decided to send this mail to you. I hope you can help me. I?m running a WIN2K8 R2 64 bit and a fedora Linux 32 bit with freeipa. In the future, please use the freeipa-users at redhat.com email list. Please also include the versions of your freeipa and 389 packages: rpm -qa|grep freeipa rpm -qa|grep 389 There is a win sync agreement, which works very well, even the passwords are synchronized. The only problem is that: If I set a new password on windows side with more than 2 special characters, e.g. ?!M?usel 10? or ?!R?diger 20? Then I get the passsync error: 03/14/12 12:26:13: Ldap error in ModifyPassword 1: Operations error 03/14/12 12:26:13: Modify Password failed for remote entry: uid= 03/14/12 12:26:13: Deferring password change for Do you have any idea, if that could be or something else, what can I do? What is your 389-ds-base version and platform? Can you use ldapmodify to change the user password to one of the above values? Can you use ipa-passwd? That is, is the problem specific to AD PassSync, or is it a problem with these types of passwords in general? Best regards. Mit freundlichen Gr??en Bennet Lingner Hochschule Anhalt - ZIK b.lingner at zik.hs-anhalt.de Tel. +49 (0) 3496 67-5420 Fax +49 (0) 3496 67-95420 Bernburger Stra?e 55 06366 K?then (Anhalt) Hochschule Anhalt (FH) * Bernburger Stra?e 55 * D 06366 K?then Pr?sident Prof. Dr. Dr. h.c. Dieter Orzessek * Tel.: +49 (0) 3496 67 1000 * Fax +49 (0) 3496 67 1099 Betriebsnummer 030 77 111 * Umsatzsteuernummer DE 8140 92 585 Zust?ndige Aufsichtsbeh?rde Kultusministerium des Landes Sachsen-Anhalt, PF 3765, 39012 Magdeburg -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5748 bytes Desc: not available URL: From b.lingner at zik.hs-anhalt.de Thu Mar 15 09:59:55 2012 From: b.lingner at zik.hs-anhalt.de (Bennet Lingner) Date: Thu, 15 Mar 2012 10:59:55 +0100 Subject: [Freeipa-users] Windows Password Synchronization Error References: <03b801cd01de$2a8f3c10$7fadb430$@zik.hs-anhalt.de> <4F60B9AB.3020706@redhat.com> Message-ID: Something more: On FreeIPA side there are built these errors too: [15/Mar/2012:10:02:02 +0100] encrypt_encode_key - [file ipapwd_encoding.c, line 451]: krb5_c_string_to_key failed [Invalid argument] [15/Mar/2012:10:02:02 +0100] ipapwd_gen_hashes - [file ipapwd_encoding.c, line 776]: key encryption/encoding failed Von: Bennet Lingner [mailto:b.lingner at zik.hs-anhalt.de] Gesendet: Donnerstag, 15. M?rz 2012 10:34 An: 'freeipa-users at redhat.com' Betreff: AW: Windows Password Synchronization Error Hi, Thank you for your reply. Version of freeipa and 389 packages: Freeipa server, python, admintools, client, server-selinux all in 2.1.4-5.fc16.i686 389-ds-base-1.2.10.3-1.fc16.i686 + libs Platform is Fedora 16 3.2.9-2.fc16.i686.PAE on AMD Opteron CPU Ldapmodify and ipa passwd are working perfectly, I?ve changed password in this ways and passwords were synchronized. So I conclude the problem is specific to AD Passsync? If it is so, do I have the possibility on AD side too to set or try something? Best regards. Bennet Lingner Von: Rich Megginson [mailto:rmeggins at redhat.com] Gesendet: Mittwoch, 14. M?rz 2012 16:31 An: Bennet Lingner Betreff: Re: Windows Password Synchronization Error On 03/14/2012 06:29 AM, Bennet Lingner wrote: Dear Mr. Megginson, I?ve seen in www, that you are very involved in 389 directory server, that?s why I decided to send this mail to you. I hope you can help me. I?m running a WIN2K8 R2 64 bit and a fedora Linux 32 bit with freeipa. In the future, please use the freeipa-users at redhat.com email list. Please also include the versions of your freeipa and 389 packages: rpm -qa|grep freeipa rpm -qa|grep 389 There is a win sync agreement, which works very well, even the passwords are synchronized. The only problem is that: If I set a new password on windows side with more than 2 special characters, e.g. ?!M?usel 10? or ?!R?diger 20? Then I get the passsync error: 03/14/12 12:26:13: Ldap error in ModifyPassword 1: Operations error 03/14/12 12:26:13: Modify Password failed for remote entry: uid= 03/14/12 12:26:13: Deferring password change for Do you have any idea, if that could be or something else, what can I do? What is your 389-ds-base version and platform? Can you use ldapmodify to change the user password to one of the above values? Can you use ipa-passwd? That is, is the problem specific to AD PassSync, or is it a problem with these types of passwords in general? Best regards. Mit freundlichen Gr??en Bennet Lingner Hochschule Anhalt - ZIK b.lingner at zik.hs-anhalt.de Tel. +49 (0) 3496 67-5420 Fax +49 (0) 3496 67-95420 Bernburger Stra?e 55 06366 K?then (Anhalt) Hochschule Anhalt (FH) * Bernburger Stra?e 55 * D 06366 K?then Pr?sident Prof. Dr. Dr. h.c. Dieter Orzessek * Tel.: +49 (0) 3496 67 1000 * Fax +49 (0) 3496 67 1099 Betriebsnummer 030 77 111 * Umsatzsteuernummer DE 8140 92 585 Zust?ndige Aufsichtsbeh?rde Kultusministerium des Landes Sachsen-Anhalt, PF 3765, 39012 Magdeburg -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5748 bytes Desc: not available URL: From bcook at redhat.com Thu Mar 15 15:17:00 2012 From: bcook at redhat.com (Brian Cook) Date: Thu, 15 Mar 2012 08:17:00 -0700 Subject: [Freeipa-users] Bind current mac clients? In-Reply-To: <63D5CEF6-DFC9-4BCB-96BD-D034B2285E9F@atea.se> References: <63D5CEF6-DFC9-4BCB-96BD-D034B2285E9F@atea.se> Message-ID: <52245E7B-4882-47B2-A3B8-DDC388650EBF@redhat.com> I wrote some instructions that I tested on Lion, I just haven't posted them anywhere yet. On IPA Server: ipa host-add --force client1.example.com ipa host-add-managedby --hosts=ipaserver.example.com client1.example.com ipa-getkeytab -s ipaserver.example.com -p host/client1.example.com -k /tmp/client1.keytab copy the keytab to /etc/krb5.keytab on the client. Ensure permissions are 600. use sudo ktutil -k /etc/krb5.keytab list to check the keytab #### client1.example.com $ sudo ktutil -k /etc/krb5.keytab list /etc/krb5.keytab: Vno Type Principal Aliases 1 aes256-cts-hmac-sha1-96 host/client1.example.com at EXAMPLE.COM 1 aes128-cts-hmac-sha1-96 host/client1.example.com at EXAMPLE.COM 1 des3-cbc-sha1 host/client1.example.com at EXAMPLE.COM 1 arcfour-hmac-md5 host/client1.example.com at EXAMPLE.COM #### /etc/krb5.conf #### for Mac OS X 10.7 Lion (Tested on 10.7.3) #Version 1.0 [logging] admin_server = FILE:/var/log/krb5kdc/kadmin.log kdc = FILE:/var/log/krb5kdc/kdc.log [domain_realm] example.com = EXAMPLE.COM .example.com = EXAMPLE.COM [libdefaults] default_realm = EXAMPLE.COM dns_lookup_realm = true dns_lookup_kdc = true ticket_lifetime = 24h forwardable = yes [realms] ###### End /etc/krb5.conf #### In /etc/ssh_config #### for Mac OS X 10.7 Lion (Tested on 10.7.3) GSSAPIAuthentication yes GSSAPIDelegateCredentials no GSSAPIKeyExchange yes GSSAPITrustDNS no #### End /etc/ssh_config #### In /etc/ssh/ssh_config #### RHEL 6.2 w/ ipa-server 2.1.3-9 GSSAPIAuthentication yes GSSAPICleanupCredentials yes #### end /etc/ssh/ssh_config Kerberos was swapped out from snow leopard to lion. Lion uses Heimdahl instead of Kerberos. If you need a realms section because you are setting DNS lookups to false in krb5.conf, you have to do it like this: [realms] EXAMPLE.COM = { admin_server = tcp/ipa0.example.com:749 default_domain = salab.redhat.com kdc = tcp/ipa0.example.com:88 } If you don't do tcp/ heimdahl uses UDP by default. Good Luck.. Brian -- Brian Cook Solutions Architect, Red Hat, Inc. 407-212-7079 On Mar 14, 2012, at 11:57 PM, Hagenrud H?kan wrote: > Hello > > I just joined this list so please excuse if this question has been asked > > Is anyone out there binding mac clients (10.7.x) to IPA? > > I have tried it with some success. The mac-client can join the IPA domain and the Kerberos domain but no user from the domain can log in to the mac-computer. My guess is that I need to map the LDAP values from IPA with what the mac-client expects. > > Anyone? > > Thanks > > H?kan Hagenrud > > _______________________________________________ > 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 pspacek at redhat.com Thu Mar 15 15:17:29 2012 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 15 Mar 2012 16:17:29 +0100 Subject: [Freeipa-users] Replica creation problem - IPv6? In-Reply-To: <1331823273.9238.224.camel@willson.li.ssimo.org> References: <4F62010B.7060700@comeon.com> <1331823273.9238.224.camel@willson.li.ssimo.org> Message-ID: <4F620809.6020308@redhat.com> On 03/15/2012 03:54 PM, Simo Sorce wrote: > On Thu, 2012-03-15 at 15:47 +0100, Dimitris Tsompanidis wrote: >> Firewalls on both machines are disabled and the firewall in between >> is >> wide open, especially in the master->slave direction where I allow >> everything. >> > There is no master -> slave concept in FreeIPA, all servers are master > and they work in a multi-master configuration, so all the proper > communication channels need to be open both ways. > > Simo. > I think it's not related to firewall, because daemons are not listening on IPv4 sockets. Please, try to "telnet 389" from affected machine. If it fails with "connection refused", there is really problem with socket creation. It strange problem... There is my blind shoot: Please, post your: - /etc/hosts file - output of "hostname" - output of "hostname -f" - /etc/gai.conf file Best regards, Petr^2 Spacek @ Red Hat @ Brno From bcook at redhat.com Thu Mar 15 15:18:28 2012 From: bcook at redhat.com (Brian Cook) Date: Thu, 15 Mar 2012 08:18:28 -0700 Subject: [Freeipa-users] So I guess there's no SME call today. Message-ID: <5AB8C652-D1EC-49E5-BF24-293B388470CF@redhat.com> ? --- Brian Cook Solutions Architect, Red Hat, Inc. 407-212-7079 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bcook at redhat.com Thu Mar 15 15:19:11 2012 From: bcook at redhat.com (Brian Cook) Date: Thu, 15 Mar 2012 08:19:11 -0700 Subject: [Freeipa-users] So I guess there's no SME call today. In-Reply-To: <5AB8C652-D1EC-49E5-BF24-293B388470CF@redhat.com> References: <5AB8C652-D1EC-49E5-BF24-293B388470CF@redhat.com> Message-ID: wrong list --- Brian Cook Solutions Architect, Red Hat, Inc. 407-212-7079 On Mar 15, 2012, at 8:18 AM, Brian Cook wrote: > ? > > --- > Brian Cook > Solutions Architect, Red Hat, Inc. > 407-212-7079 > > > > > _______________________________________________ > 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 g17jimmy at gmail.com Thu Mar 15 15:39:11 2012 From: g17jimmy at gmail.com (Jimmy) Date: Thu, 15 Mar 2012 11:39:11 -0400 Subject: [Freeipa-users] (no subject) In-Reply-To: References: <4F610381.8020109@redhat.com> <4F6105DD.3010504@redhat.com> <4F610869.40501@redhat.com> <4F610995.2020500@redhat.com> <4F611084.3010606@redhat.com> <-512731158224897185@unknownmsgid> <4F6114A5.3090507@redhat.com> <4F612BBB.3070404@redhat.com> Message-ID: I tried the export/import but the import fails. I tried it a couple different ways, creating a new, empty userRoot directory- and tried importing to the original userRoot. Both times it failed and removed the directory userRoot. I still have the orig userRoot dir. /var/lib/dirsrv/scripts-ABC-XYZ/ldif2db -n userRoot -i /dbexport/output.ldif importing data ... [10/Mar/2012:19:09:57 +0000] - I'm resizing my cache now...cache was 419196928 and is now 8000000 [10/Mar/2012:19:09:58 +0000] - All database threads now stopped [10/Mar/2012:19:09:58 +0000] - I'm resizing my cache now...cache was 419196928 and is now 8000000 [10/Mar/2012:19:09:58 +0000] - WARNING: Import is running with nsslapd-db-private-import-mem on; No other process is allowed to access the database [10/Mar/2012:19:09:58 +0000] - check_and_set_import_cache: pagesize: 4096, pages: 255859, procpages: 56195 [10/Mar/2012:19:09:58 +0000] - WARNING: After allocating import cache 409372KB, the available memory is 614064KB, which is less than the soft limit 1048576KB. You may want to decrease the import cache size and rerun import. [10/Mar/2012:19:09:58 +0000] - Import allocates 409372KB import cache. [10/Mar/2012:19:09:59 +0000] - import userRoot: Beginning import job... [10/Mar/2012:19:09:59 +0000] - import userRoot: Index buffering enabled with bucket size 100 [10/Mar/2012:19:09:59 +0000] - import userRoot: Processing file "/dbexport/output.ldif" [10/Mar/2012:19:09:59 +0000] - import userRoot: Finished scanning file "/dbexport/output.ldif" (328 entries) [10/Mar/2012:19:09:59 +0000] entryrdn-index - _entryrdn_insert_key: Same DN (dn: ou=profile,dc=abc,dc=xyz) is already in the entryrdn file with different ID 146. Expected ID is 327. [10/Mar/2012:19:09:59 +0000] - import userRoot: Duplicated DN detected: "ou=profile,dc=abc,dc=xyz": Entry ID: (327) [10/Mar/2012:19:09:59 +0000] - import userRoot: Aborting all Import threads... [10/Mar/2012:19:10:06 +0000] - import userRoot: Import threads aborted. [10/Mar/2012:19:10:06 +0000] - import userRoot: Closing files... [10/Mar/2012:19:10:06 +0000] - libdb: userRoot/krbPrincipalName.db4: unable to flush: No such file or directory [10/Mar/2012:19:10:06 +0000] - libdb: userRoot/sn.db4: unable to flush: No such file or directory [10/Mar/2012:19:10:06 +0000] - libdb: userRoot/uid.db4: unable to flush: No such file or directory [10/Mar/2012:19:10:06 +0000] - libdb: userRoot/givenName.db4: unable to flush: No such file or directory [10/Mar/2012:19:10:06 +0000] - libdb: userRoot/displayname.db4: unable to flush: No such file or directory [10/Mar/2012:19:10:06 +0000] - libdb: userRoot/cn.db4: unable to flush: No such file or directory [10/Mar/2012:19:10:06 +0000] - libdb: userRoot/telephoneNumber.db4: unable to flush: No such file or directory [10/Mar/2012:19:10:06 +0000] - libdb: userRoot/entryrdn.db4: unable to flush: No such file or directory [10/Mar/2012:19:10:06 +0000] - libdb: userRoot/entryusn.db4: unable to flush: No such file or directory [10/Mar/2012:19:10:06 +0000] - libdb: userRoot/nsuniqueid.db4: unable to flush: No such file or directory [10/Mar/2012:19:10:06 +0000] - libdb: userRoot/uidnumber.db4: unable to flush: No such file or directory [10/Mar/2012:19:10:06 +0000] - libdb: userRoot/objectclass.db4: unable to flush: No such file or directory [10/Mar/2012:19:10:06 +0000] - libdb: userRoot/gidnumber.db4: unable to flush: No such file or directory [10/Mar/2012:19:10:06 +0000] - libdb: userRoot/parentid.db4: unable to flush: No such file or directory [10/Mar/2012:19:10:06 +0000] - libdb: userRoot/id2entry.db4: unable to flush: No such file or directory [10/Mar/2012:19:10:06 +0000] - libdb: userRoot/aci.db4: unable to flush: No such file or directory [10/Mar/2012:19:10:07 +0000] - libdb: userRoot/memberOf.db4: unable to flush: No such file or directory [10/Mar/2012:19:10:07 +0000] - libdb: userRoot/member.db4: unable to flush: No such file or directory [10/Mar/2012:19:10:07 +0000] - libdb: userRoot/ou.db4: unable to flush: No such file or directory /var/lib/dirsrv/slapd-ABC-XYZ/db/userRoot: No such file or directory [10/Mar/2012:19:10:07 +0000] - All database threads now stopped [10/Mar/2012:19:10:07 +0000] - import userRoot: Import failed. On Thu, Mar 15, 2012 at 9:15 AM, Jimmy wrote: > The version 1.2.10.a1 is odd, because it was originally installed > using yum. I didn't hack it together at all. I'll do the export/import > and see how it goes. > -Jimmy > > On Wed, Mar 14, 2012 at 7:37 PM, Rich Megginson wrote: >> On 03/14/2012 03:59 PM, Rich Megginson wrote: >>> >>> On 03/14/2012 03:51 PM, Jimmy Caldwell wrote: >>>> >>>> Is this a normal thing to occur during upgrade? >>> >>> Unfortunately, in this particular case, yes. >>>> >>>> If it was just a fluke >>>> I can revert to the snapshot from just before the upgrade and try >>>> again. >>> >>> I think you will run into the same exact problem. >> >> >> Another problem - according to http://fpaste.org/nSWh/ you were using >> 1.2.10.a1 - I'm not sure how that happened - on F-15, none of the alpha >> versions were pushed to Stable afaik (unlike F-16). ?We did not (nor >> normally do not) test upgrades from alpha versions to "stable" versions. >> ?According to >> https://admin.fedoraproject.org/updates/FEDORA-2011-13460/389-ds-base-1.2.10-0.1.a1.fc15 >> this was never pushed to Stable, only to Testing. >> >>>> >>>> Sent from my mobile device >>>> >>>> On Mar 14, 2012, at 17:44, Rich Megginson ?wrote: >>>> >>>>> On 03/14/2012 03:26 PM, Jimmy wrote: >>>>>> >>>>>> http://fpaste.org/nSWh/ >>>>> >>>>> Thanks. ?Looks like you are going to have to export your database to >>>>> ldif, re-import it, and then re-initialize all of your replicas. >>>>> >>>>> >>>>> http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Populating_Directory_Databases-Exporting_Data.html >>>>> >>>>> For ipa, the scripts are in /var/lib/dirsrv/scripts-YOUR-DOMAIN >>>>> >>>>> For ipa, your database is userRoot (so -n userRoot) >>>>> >>>>> so first, do db2ldif, then ldif2db, then use ipa-replica-manage to >>>>> reinitialize all of your replicas >>>>>> >>>>>> Here ya go >>>>>> Jimmy >>>>>> >>>>>> On Wed, Mar 14, 2012 at 5:11 PM, Rich Megginson >>>>>> wrote: >>>>>>> >>>>>>> On 03/14/2012 03:13 PM, Jimmy wrote: >>>>>>>> >>>>>>>> bdb/4.8/libback-ldbm/newidl/rdn-format-2/dn-4514 >>>>>>>> bdb/4.8/libback-ldbm/newidl/rdn-format-2/dn-4514 >>>>>>> >>>>>>> It appears that the entryrdn upgrade didn't work. ?Can you sanitize >>>>>>> your >>>>>>> /var/log/dirsrv/slapd-DOMAIN/errors file and post it to fpaste.org? >>>>>>> >>>>>>>> On Wed, Mar 14, 2012 at 5:06 PM, Rich Megginson >>>>>>>> ?wrote: >>>>>>>>> >>>>>>>>> On 03/14/2012 03:05 PM, Jimmy wrote: >>>>>>>>>> >>>>>>>>>> This doesn't appear to be very good. If I drop the `grep` I see the >>>>>>>>>> data I would expect to see. >>>>>>>>>> >>>>>>>>>> dbscan -f >>>>>>>>>> /var/lib/dirsrv/slapd-YOUR-DOMAIN/db/userRoot/entryrdn.db4|grep >>>>>>>>>> cn=etc >>>>>>>>>> 22:cn=etc >>>>>>>>>> ? ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>>>>>>>> ? ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>>>>>>>> C22:cn=etc >>>>>>>>>> C22:cn=etc >>>>>>>>>> C22:cn=etc >>>>>>>>>> C22:cn=etc >>>>>>>>>> C22:cn=etc >>>>>>>>>> C22:cn=etc >>>>>>>>>> C22:cn=etc >>>>>>>>>> C22:cn=etc >>>>>>>>>> ? ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>>>>>>>> ? ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>>>>>>>> ? ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>>>>>>>> ? ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>>>>>>>> P22:cn=etc >>>>>>>>>> ? ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>>>>>>>> ? ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>>>>>>>> ? ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>>>>>>>> ? ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>>>>>>> >>>>>>>>> find /var/lib/dirsrv/slapd-YOUR-DOMAIN/db -name DBVERSION -exec cat >>>>>>>>> {} \; >>> >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> From pspacek at redhat.com Thu Mar 15 16:12:24 2012 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 15 Mar 2012 17:12:24 +0100 Subject: [Freeipa-users] Replica creation problem - IPv6? In-Reply-To: <4F620809.6020308@redhat.com> References: <4F62010B.7060700@comeon.com> <1331823273.9238.224.camel@willson.li.ssimo.org> <4F620809.6020308@redhat.com> Message-ID: <4F6214E8.3000304@redhat.com> On 03/15/2012 04:17 PM, Petr Spacek wrote: > On 03/15/2012 03:54 PM, Simo Sorce wrote: >> On Thu, 2012-03-15 at 15:47 +0100, Dimitris Tsompanidis wrote: >>> Firewalls on both machines are disabled and the firewall in between >>> is >>> wide open, especially in the master->slave direction where I allow >>> everything. >>> >> There is no master -> slave concept in FreeIPA, all servers are master >> and they work in a multi-master configuration, so all the proper >> communication channels need to be open both ways. >> >> Simo. >> > I think it's not related to firewall, because daemons are not listening > on IPv4 sockets. > > Please, try to "telnet 389" from affected machine. It isn't clear even for me, sorry :-) I want to say = IPv4 loopback. Please try "telnet 127.0.0.1 389". If netstat didn't lie, it should fail. Petr^2 Spacek > If it fails with "connection refused", there is really problem with > socket creation. > > > It strange problem... There is my blind shoot: > > Please, post your: > - /etc/hosts file > - output of "hostname" > - output of "hostname -f" > - /etc/gai.conf file > > > Best regards, > > Petr^2 Spacek @ Red Hat @ Brno From dimitris.tsompanidis at comeon.com Thu Mar 15 16:16:05 2012 From: dimitris.tsompanidis at comeon.com (Dimitris Tsompanidis) Date: Thu, 15 Mar 2012 17:16:05 +0100 Subject: [Freeipa-users] Replica creation problem - IPv6? In-Reply-To: <4F6214E8.3000304@redhat.com> References: <4F62010B.7060700@comeon.com> <1331823273.9238.224.camel@willson.li.ssimo.org> <4F620809.6020308@redhat.com> <4F6214E8.3000304@redhat.com> Message-ID: <4F6215C5.2000009@comeon.com> On 15/03/2012 17:12, Petr Spacek wrote: > On 03/15/2012 04:17 PM, Petr Spacek wrote: >> On 03/15/2012 03:54 PM, Simo Sorce wrote: >>> On Thu, 2012-03-15 at 15:47 +0100, Dimitris Tsompanidis wrote: >>>> Firewalls on both machines are disabled and the firewall in between >>>> is >>>> wide open, especially in the master->slave direction where I allow >>>> everything. >>>> >>> There is no master -> slave concept in FreeIPA, all servers are master >>> and they work in a multi-master configuration, so all the proper >>> communication channels need to be open both ways. >>> >>> Simo. >>> >> I think it's not related to firewall, because daemons are not listening >> on IPv4 sockets. >> >> Please, try to "telnet 389" from affected machine. > > It isn't clear even for me, sorry :-) > I want to say = IPv4 loopback. Please try > "telnet 127.0.0.1 389". > > If netstat didn't lie, it should fail. > > Petr^2 Spacek > >> If it fails with "connection refused", there is really problem with >> socket creation. >> >> >> It strange problem... There is my blind shoot: >> >> Please, post your: >> - /etc/hosts file >> - output of "hostname" >> - output of "hostname -f" >> - /etc/gai.conf file >> >> >> Best regards, >> >> Petr^2 Spacek @ Red Hat @ Brno > Being the impatient man that I am, I wiped the VM clean, reinstalled Fedora 16 and tried to avoid all the previous customization in the network settings (the one that was meant to disable IPv6) - it's pretty close to a vanilla installation, except for static IP and, of course, the FreeIPA guidelines. The installation and the replication went great. So, PEBKAC :) Just for discussion's sake, before I reinstalled I did try 'nc localhost 389' and various other ports and I got "connection refused". Thanks to all for the replies. From g17jimmy at gmail.com Thu Mar 15 16:45:06 2012 From: g17jimmy at gmail.com (Jimmy) Date: Thu, 15 Mar 2012 12:45:06 -0400 Subject: [Freeipa-users] (no subject) In-Reply-To: References: <4F610381.8020109@redhat.com> <4F6105DD.3010504@redhat.com> <4F610869.40501@redhat.com> <4F610995.2020500@redhat.com> <4F611084.3010606@redhat.com> <-512731158224897185@unknownmsgid> <4F6114A5.3090507@redhat.com> <4F612BBB.3070404@redhat.com> Message-ID: I looked at the ldif and found the lines the import was calling duplicates and removed one set of the dups. http://fpaste.org/jIun/ Why would this even happen, and will what I did cause other problems? thanks On Thu, Mar 15, 2012 at 11:39 AM, Jimmy wrote: > I tried the export/import but the import fails. I tried it a couple > different ways, creating a new, empty userRoot directory- and tried > importing to the original userRoot. Both times it failed and removed > the directory userRoot. I still have the orig userRoot dir. > > /var/lib/dirsrv/scripts-ABC-XYZ/ldif2db -n userRoot -i /dbexport/output.ldif > importing data ... > [10/Mar/2012:19:09:57 +0000] - I'm resizing my cache now...cache was > 419196928 and is now 8000000 > [10/Mar/2012:19:09:58 +0000] - All database threads now stopped > [10/Mar/2012:19:09:58 +0000] - I'm resizing my cache now...cache was > 419196928 and is now 8000000 > [10/Mar/2012:19:09:58 +0000] - WARNING: Import is running with > nsslapd-db-private-import-mem on; No other process is allowed to > access the database > [10/Mar/2012:19:09:58 +0000] - check_and_set_import_cache: pagesize: > 4096, pages: 255859, procpages: 56195 > [10/Mar/2012:19:09:58 +0000] - WARNING: After allocating import cache > 409372KB, the available memory is 614064KB, which is less than the > soft limit 1048576KB. You may want to decrease the import cache size > and rerun import. > [10/Mar/2012:19:09:58 +0000] - Import allocates 409372KB import cache. > [10/Mar/2012:19:09:59 +0000] - import userRoot: Beginning import job... > [10/Mar/2012:19:09:59 +0000] - import userRoot: Index buffering > enabled with bucket size 100 > [10/Mar/2012:19:09:59 +0000] - import userRoot: Processing file > "/dbexport/output.ldif" > [10/Mar/2012:19:09:59 +0000] - import userRoot: Finished scanning file > "/dbexport/output.ldif" (328 entries) > [10/Mar/2012:19:09:59 +0000] entryrdn-index - _entryrdn_insert_key: > Same DN (dn: ou=profile,dc=abc,dc=xyz) is already in the entryrdn file > with different ID 146. ?Expected ID is 327. > [10/Mar/2012:19:09:59 +0000] - import userRoot: Duplicated DN > detected: "ou=profile,dc=abc,dc=xyz": Entry ID: (327) > [10/Mar/2012:19:09:59 +0000] - import userRoot: Aborting all Import threads... > [10/Mar/2012:19:10:06 +0000] - import userRoot: Import threads aborted. > [10/Mar/2012:19:10:06 +0000] - import userRoot: Closing files... > [10/Mar/2012:19:10:06 +0000] - libdb: userRoot/krbPrincipalName.db4: > unable to flush: No such file or directory > [10/Mar/2012:19:10:06 +0000] - libdb: userRoot/sn.db4: unable to > flush: No such file or directory > [10/Mar/2012:19:10:06 +0000] - libdb: userRoot/uid.db4: unable to > flush: No such file or directory > [10/Mar/2012:19:10:06 +0000] - libdb: userRoot/givenName.db4: unable > to flush: No such file or directory > [10/Mar/2012:19:10:06 +0000] - libdb: userRoot/displayname.db4: unable > to flush: No such file or directory > [10/Mar/2012:19:10:06 +0000] - libdb: userRoot/cn.db4: unable to > flush: No such file or directory > [10/Mar/2012:19:10:06 +0000] - libdb: userRoot/telephoneNumber.db4: > unable to flush: No such file or directory > [10/Mar/2012:19:10:06 +0000] - libdb: userRoot/entryrdn.db4: unable to > flush: No such file or directory > [10/Mar/2012:19:10:06 +0000] - libdb: userRoot/entryusn.db4: unable to > flush: No such file or directory > [10/Mar/2012:19:10:06 +0000] - libdb: userRoot/nsuniqueid.db4: unable > to flush: No such file or directory > [10/Mar/2012:19:10:06 +0000] - libdb: userRoot/uidnumber.db4: unable > to flush: No such file or directory > [10/Mar/2012:19:10:06 +0000] - libdb: userRoot/objectclass.db4: unable > to flush: No such file or directory > [10/Mar/2012:19:10:06 +0000] - libdb: userRoot/gidnumber.db4: unable > to flush: No such file or directory > [10/Mar/2012:19:10:06 +0000] - libdb: userRoot/parentid.db4: unable to > flush: No such file or directory > [10/Mar/2012:19:10:06 +0000] - libdb: userRoot/id2entry.db4: unable to > flush: No such file or directory > [10/Mar/2012:19:10:06 +0000] - libdb: userRoot/aci.db4: unable to > flush: No such file or directory > [10/Mar/2012:19:10:07 +0000] - libdb: userRoot/memberOf.db4: unable to > flush: No such file or directory > [10/Mar/2012:19:10:07 +0000] - libdb: userRoot/member.db4: unable to > flush: No such file or directory > [10/Mar/2012:19:10:07 +0000] - libdb: userRoot/ou.db4: unable to > flush: No such file or directory > /var/lib/dirsrv/slapd-ABC-XYZ/db/userRoot: No such file or directory > [10/Mar/2012:19:10:07 +0000] - All database threads now stopped > [10/Mar/2012:19:10:07 +0000] - import userRoot: Import failed. > > > On Thu, Mar 15, 2012 at 9:15 AM, Jimmy wrote: >> The version 1.2.10.a1 is odd, because it was originally installed >> using yum. I didn't hack it together at all. I'll do the export/import >> and see how it goes. >> -Jimmy >> >> On Wed, Mar 14, 2012 at 7:37 PM, Rich Megginson wrote: >>> On 03/14/2012 03:59 PM, Rich Megginson wrote: >>>> >>>> On 03/14/2012 03:51 PM, Jimmy Caldwell wrote: >>>>> >>>>> Is this a normal thing to occur during upgrade? >>>> >>>> Unfortunately, in this particular case, yes. >>>>> >>>>> If it was just a fluke >>>>> I can revert to the snapshot from just before the upgrade and try >>>>> again. >>>> >>>> I think you will run into the same exact problem. >>> >>> >>> Another problem - according to http://fpaste.org/nSWh/ you were using >>> 1.2.10.a1 - I'm not sure how that happened - on F-15, none of the alpha >>> versions were pushed to Stable afaik (unlike F-16). ?We did not (nor >>> normally do not) test upgrades from alpha versions to "stable" versions. >>> ?According to >>> https://admin.fedoraproject.org/updates/FEDORA-2011-13460/389-ds-base-1.2.10-0.1.a1.fc15 >>> this was never pushed to Stable, only to Testing. >>> >>>>> >>>>> Sent from my mobile device >>>>> >>>>> On Mar 14, 2012, at 17:44, Rich Megginson ?wrote: >>>>> >>>>>> On 03/14/2012 03:26 PM, Jimmy wrote: >>>>>>> >>>>>>> http://fpaste.org/nSWh/ >>>>>> >>>>>> Thanks. ?Looks like you are going to have to export your database to >>>>>> ldif, re-import it, and then re-initialize all of your replicas. >>>>>> >>>>>> >>>>>> http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Populating_Directory_Databases-Exporting_Data.html >>>>>> >>>>>> For ipa, the scripts are in /var/lib/dirsrv/scripts-YOUR-DOMAIN >>>>>> >>>>>> For ipa, your database is userRoot (so -n userRoot) >>>>>> >>>>>> so first, do db2ldif, then ldif2db, then use ipa-replica-manage to >>>>>> reinitialize all of your replicas >>>>>>> >>>>>>> Here ya go >>>>>>> Jimmy >>>>>>> >>>>>>> On Wed, Mar 14, 2012 at 5:11 PM, Rich Megginson >>>>>>> wrote: >>>>>>>> >>>>>>>> On 03/14/2012 03:13 PM, Jimmy wrote: >>>>>>>>> >>>>>>>>> bdb/4.8/libback-ldbm/newidl/rdn-format-2/dn-4514 >>>>>>>>> bdb/4.8/libback-ldbm/newidl/rdn-format-2/dn-4514 >>>>>>>> >>>>>>>> It appears that the entryrdn upgrade didn't work. ?Can you sanitize >>>>>>>> your >>>>>>>> /var/log/dirsrv/slapd-DOMAIN/errors file and post it to fpaste.org? >>>>>>>> >>>>>>>>> On Wed, Mar 14, 2012 at 5:06 PM, Rich Megginson >>>>>>>>> ?wrote: >>>>>>>>>> >>>>>>>>>> On 03/14/2012 03:05 PM, Jimmy wrote: >>>>>>>>>>> >>>>>>>>>>> This doesn't appear to be very good. If I drop the `grep` I see the >>>>>>>>>>> data I would expect to see. >>>>>>>>>>> >>>>>>>>>>> dbscan -f >>>>>>>>>>> /var/lib/dirsrv/slapd-YOUR-DOMAIN/db/userRoot/entryrdn.db4|grep >>>>>>>>>>> cn=etc >>>>>>>>>>> 22:cn=etc >>>>>>>>>>> ? ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>>>>>>>>> ? ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>>>>>>>>> C22:cn=etc >>>>>>>>>>> C22:cn=etc >>>>>>>>>>> C22:cn=etc >>>>>>>>>>> C22:cn=etc >>>>>>>>>>> C22:cn=etc >>>>>>>>>>> C22:cn=etc >>>>>>>>>>> C22:cn=etc >>>>>>>>>>> C22:cn=etc >>>>>>>>>>> ? ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>>>>>>>>> ? ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>>>>>>>>> ? ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>>>>>>>>> ? ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>>>>>>>>> P22:cn=etc >>>>>>>>>>> ? ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>>>>>>>>> ? ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>>>>>>>>> ? ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>>>>>>>>> ? ID: 22; RDN: "cn=etc"; NRDN: "cn=etc" >>>>>>>>>> >>>>>>>>>> find /var/lib/dirsrv/slapd-YOUR-DOMAIN/db -name DBVERSION -exec cat >>>>>>>>>> {} \; >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-users mailing list >>>> Freeipa-users at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> >>> From g17jimmy at gmail.com Thu Mar 15 17:06:23 2012 From: g17jimmy at gmail.com (Jimmy) Date: Thu, 15 Mar 2012 13:06:23 -0400 Subject: [Freeipa-users] (no subject) In-Reply-To: References: <4F610381.8020109@redhat.com> <4F6105DD.3010504@redhat.com> <4F610869.40501@redhat.com> <4F610995.2020500@redhat.com> <4F611084.3010606@redhat.com> <-512731158224897185@unknownmsgid> <4F6114A5.3090507@redhat.com> <4F612BBB.3070404@redhat.com> Message-ID: I can now start the upgraded IPA, but now going to the IPA admin page I get this: ==== Not Found The requested URL /ipa was not found on this server. ==== From g17jimmy at gmail.com Thu Mar 15 17:21:00 2012 From: g17jimmy at gmail.com (Jimmy) Date: Thu, 15 Mar 2012 13:21:00 -0400 Subject: [Freeipa-users] (no subject) In-Reply-To: References: <4F610381.8020109@redhat.com> <4F6105DD.3010504@redhat.com> <4F610869.40501@redhat.com> <4F610995.2020500@redhat.com> <4F611084.3010606@redhat.com> <-512731158224897185@unknownmsgid> <4F6114A5.3090507@redhat.com> <4F612BBB.3070404@redhat.com> Message-ID: Restarted IPA and now the interface loads, but resubmitting the cert has this result - ipa-getcert resubmit -i 20110913154233 192.168.201.102 - - [10/Mar/2012:20:53:13 +0000] "POST /ipa/xml HTTP/1.1" 401 1775 192.168.201.102 - host/abc-ipa.abc.xyz at ABC.XYZ [10/Mar/2012:20:53:13 +0000] "POST /ipa/xml HTTP/1.1" 200 314 but the cert still shows these dates- Not Before: Tue Sep 13 15:43:37 2011 Not After : Sun Mar 11 15:43:37 2012 On Thu, Mar 15, 2012 at 1:06 PM, Jimmy wrote: > I can now start the upgraded IPA, but now going to the IPA admin page > I get this: > > ==== > > Not Found > > The requested URL /ipa was not found on this server. > > ==== From rcritten at redhat.com Thu Mar 15 17:33:53 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 15 Mar 2012 13:33:53 -0400 Subject: [Freeipa-users] (no subject) In-Reply-To: References: <4F610381.8020109@redhat.com> <4F6105DD.3010504@redhat.com> <4F610869.40501@redhat.com> <4F610995.2020500@redhat.com> <4F611084.3010606@redhat.com> <-512731158224897185@unknownmsgid> <4F6114A5.3090507@redhat.com> <4F612BBB.3070404@redhat.com> Message-ID: <4F622801.10600@redhat.com> Jimmy wrote: > Restarted IPA and now the interface loads, but resubmitting the cert > has this result - > > ipa-getcert resubmit -i 20110913154233 > 192.168.201.102 - - [10/Mar/2012:20:53:13 +0000] "POST /ipa/xml > HTTP/1.1" 401 1775 > 192.168.201.102 - host/abc-ipa.abc.xyz at ABC.XYZ [10/Mar/2012:20:53:13 > +0000] "POST /ipa/xml HTTP/1.1" 200 314 > > but the cert still shows these dates- > > Not Before: Tue Sep 13 15:43:37 2011 > Not After : Sun Mar 11 15:43:37 2012 The error log will contain more interesting information. What does the status show in the output of ipa-getcert list? rob > > > On Thu, Mar 15, 2012 at 1:06 PM, Jimmy wrote: >> I can now start the upgraded IPA, but now going to the IPA admin page >> I get this: >> >> ==== >> >> Not Found >> >> The requested URL /ipa was not found on this server. >> >> ==== > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From g17jimmy at gmail.com Thu Mar 15 18:15:13 2012 From: g17jimmy at gmail.com (Jimmy) Date: Thu, 15 Mar 2012 14:15:13 -0400 Subject: [Freeipa-users] (no subject) In-Reply-To: <4F622FC9.8040003@redhat.com> References: <4F6105DD.3010504@redhat.com> <4F610869.40501@redhat.com> <4F610995.2020500@redhat.com> <4F611084.3010606@redhat.com> <-512731158224897185@unknownmsgid> <4F6114A5.3090507@redhat.com> <4F612BBB.3070404@redhat.com> <4F622801.10600@redhat.com> <4F622FC9.8040003@redhat.com> Message-ID: I used yum to upgrade cert monger now the access_log has nothing new when I run the ipa-getcert, but error_log shows this: [Sat Mar 10 21:47:21 2012] [error] ipa: INFO: sslget 'https://xyz-ipa.abc.xyz:443/ca/agent/ca/displayBySerial' [Sat Mar 10 21:47:21 2012] [error] ipa: INFO: host/xyz-ipa.abc.xyz at ABC.XYZ: cert_request(u'MIIDQzCCAisCAQAwLDEQMA4GA1UEChMHUERILkNTUDEYMBYGA1UEAxMPY3NwLWlkbS5wZGguY3NwMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr0EHCdyTuteryFZ2bdEl+V4OATR/xk8ELthmvlwT/5qubZKwlCWS6yLawgdyCg9Yw737A7qGe0BPxHv6E+as10NxppEPsn9BOi+TPRIMYNMNNYmO2sce2pvkMkVBqsF7Gn7mF7e5+Bpc7ApnDGP7WLsAjbso8EvLUrqVMTNyiziCSHiNk+/Fi1Om6K5GKzKkqfEDex0RK+kpMswgcaZHhmW3i+y3UxFZsJjOg3R4fJAfC0+My2d1Vx4052+EgWAbSNpSj7zmLGM2+dkmgMo5Li7jjgJe8VsrqOV4L5IgqtGVJ0EOb7EP7gynbVoa74m4XrVwEP8rd/M5RxAnD1JPuwIDAQABoIHRMBoGCSqGSIb3DQEJFDENEwtTZXJ2ZXItQ2VydDCBsgYJKoZIhvcNAQkOMYGkMIGhMA4GA1UdDwEBAAQEAwIE8DB3BgNVHREBAQAEbTBroCwGCisGAQQBgjcUAgOgHgwcbGRhcC9jc3AtaWRtLnBkaC5jc3BAUERILkNTUKA7BgYrBgEFAgKgMTAvoAkbB1BESC5DU1ChIjAgoAMCAQGhGTAXGwRsZGFwGw9jc3AtaWRtLnBkaC5jc3AwFgYDVR0lAQEABAwwCgYIKwYBBQUHAwEwDQYJKoZIhvcNAQELBQADggEBABD/Hwbgf5NJNUYt0+ntMDHiilMFkSaO6ryQ36/pCH1oR+vI+PCeClHewPo0v99h4Z8W8L7CQtDdNBUMl/JVHH5Lz7cBF8A/jXZQ+naV17EEuXncacM8AvYh5dL2yih+8RpPalEmSgz5rijtbSigfNGrZn0Mh3qOW1kbsz+GDaaT9wLFxvdJyqgdKds2tsp0KzHIMcJuw3cwOfH8zrBRV28XYhMLm0OOhj92uxgax5UPY2VyHP5UOtOnfuduU1ZXa+o8QIXqX7/HyDSCLGwiPJscAsp9cRzjn4KvqzZDOcdGEjXmCGfrmUiMcuzVyTDR2SdAWrHdbRmXeyVxmiBPzdk=', principal=u'ldap/xyz-ipa.abc.xyz at ABC.XYZ', add=True): CertificateOperationError On Thu, Mar 15, 2012 at 2:07 PM, Rob Crittenden wrote: > Jimmy wrote: >> >> Which error log? the pki-ca error log has nothing and the httpd error >> log has nothing, and the httpd access log has this: (yes, the dates >> are set back a few days, bc the current cert expires on 3/11) >> >> 192.168.201.102 - - [10/Mar/2012:21:27:24 +0000] "POST /ipa/xml >> HTTP/1.1" 401 1775 >> 192.168.201.102 - host/abc-ipa.abc.xyz at ABC.XYZ [10/Mar/2012:21:27:25 >> +0000] "POST /ipa/xml HTTP/1.1" 200 314 >> >> here is the ipa-getcert list: >> >> http://fpaste.org/Dzr3/ > > > You need to update certmonger, it isn't setting a Referer HTTP header in its > request. That is now required by IPA. > > > rob > >> >> On Thu, Mar 15, 2012 at 1:33 PM, Rob Crittenden >> ?wrote: >>> >>> Jimmy wrote: >>>> >>>> >>>> Restarted IPA and now the interface loads, but resubmitting the cert >>>> has this result - >>>> >>>> ipa-getcert resubmit -i 20110913154233 >>>> 192.168.201.102 - - [10/Mar/2012:20:53:13 +0000] "POST /ipa/xml >>>> HTTP/1.1" 401 1775 >>>> 192.168.201.102 - host/abc-ipa.abc.xyz at ABC.XYZ [10/Mar/2012:20:53:13 >>>> +0000] "POST /ipa/xml HTTP/1.1" 200 314 >>>> >>>> but the cert still shows these dates- >>>> >>>> ?Not Before: Tue Sep 13 15:43:37 2011 >>>> ? ? ? ? ? ? Not After : Sun Mar 11 15:43:37 2012 >>> >>> >>> >>> The error log will contain more interesting information. >>> >>> What does the status show in the output of ipa-getcert list? >>> >>> rob >>> >>>> >>>> >>>> On Thu, Mar 15, 2012 at 1:06 PM, Jimmy ? ?wrote: >>>>> >>>>> >>>>> I can now start the upgraded IPA, but now going to the IPA admin page >>>>> I get this: >>>>> >>>>> ==== >>>>> >>>>> Not Found >>>>> >>>>> The requested URL /ipa was not found on this server. >>>>> >>>>> ==== >>>> >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-users mailing list >>>> Freeipa-users at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> >>> >>> > From rcritten at redhat.com Thu Mar 15 19:22:10 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 15 Mar 2012 15:22:10 -0400 Subject: [Freeipa-users] (no subject) In-Reply-To: References: <4F610869.40501@redhat.com> <4F610995.2020500@redhat.com> <4F611084.3010606@redhat.com> <-512731158224897185@unknownmsgid> <4F6114A5.3090507@redhat.com> <4F612BBB.3070404@redhat.com> <4F622801.10600@redhat.com> <4F622FC9.8040003@redhat.com> Message-ID: <4F624162.7020806@redhat.com> Jimmy wrote: > I used yum to upgrade cert monger now the access_log has nothing new > when I run the ipa-getcert, but error_log shows this: > > [Sat Mar 10 21:47:21 2012] [error] ipa: INFO: sslget > 'https://xyz-ipa.abc.xyz:443/ca/agent/ca/displayBySerial' > [Sat Mar 10 21:47:21 2012] [error] ipa: INFO: > host/xyz-ipa.abc.xyz at ABC.XYZ: > cert_request(u'MIIDQzCCAisCAQAwLDEQMA4GA1UEChMHUERILkNTUDEYMBYGA1UEAxMPY3NwLWlkbS5wZGguY3NwMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr0EHCdyTuteryFZ2bdEl+V4OATR/xk8ELthmvlwT/5qubZKwlCWS6yLawgdyCg9Yw737A7qGe0BPxHv6E+as10NxppEPsn9BOi+TPRIMYNMNNYmO2sce2pvkMkVBqsF7Gn7mF7e5+Bpc7ApnDGP7WLsAjbso8EvLUrqVMTNyiziCSHiNk+/Fi1Om6K5GKzKkqfEDex0RK+kpMswgcaZHhmW3i+y3UxFZsJjOg3R4fJAfC0+My2d1Vx4052+EgWAbSNpSj7zmLGM2+dkmgMo5Li7jjgJe8VsrqOV4L5IgqtGVJ0EOb7EP7gynbVoa74m4XrVwEP8rd/M5RxAnD1JPuwIDAQABoIHRMBoGCSqGSIb3DQEJFDENEwtTZXJ2ZXItQ2VydDCBsgYJKoZIhvcNAQkOMYGkMIGhMA4GA1UdDwEBAAQEAwIE8DB3BgNVHREBAQAEbTBroCwGCisGAQQBgjcUAgOgHgwcbGRhcC9jc3AtaWRtLnBkaC5jc3BAUERILkNTUKA7BgYrBgEFAgKgMTAvoAkbB1BESC5DU1ChIjAgoAMCAQGhGTAXGwRsZGFwGw9jc3AtaWRtLnBkaC5jc3AwFgYDVR0lAQEABAwwCgYIKwYBBQUHAwEwDQYJKoZIhvcNAQELBQADggEBABD/Hwbgf5NJNUYt0+ntMDHiilMFkSaO6ryQ36/pCH1oR+vI+PCeClHewPo0v99h4Z8W8L7CQtDdNBUMl/JVHH5Lz7cBF8A/jXZQ+naV17EEuXncacM8AvYh5dL2yih+8RpPalEmSgz5rijtbSigfNGrZn0Mh3qOW1kbsz+GDaaT9wLFxvdJyqgdKds2tsp0KzHIM cJuw3cwOfH8zrBRV28XYhMLm0OOhj92uxgax5UPY2VyHP5UOtOnfuduU1ZXa+o8QIXqX7/HyDSCLGwiPJscAsp9cRzjn4KvqzZDOcdGEjXmCGfrmUiMcuzVyTDR2SdAWrHdbRmXeyVxmiBPzdk=', > principal=u'ldap/xyz-ipa.abc.xyz at ABC.XYZ', add=True): > CertificateOperationError What does ipa-getcert list show? You may now have something in the CA logs too. rob > > > On Thu, Mar 15, 2012 at 2:07 PM, Rob Crittenden wrote: >> Jimmy wrote: >>> >>> Which error log? the pki-ca error log has nothing and the httpd error >>> log has nothing, and the httpd access log has this: (yes, the dates >>> are set back a few days, bc the current cert expires on 3/11) >>> >>> 192.168.201.102 - - [10/Mar/2012:21:27:24 +0000] "POST /ipa/xml >>> HTTP/1.1" 401 1775 >>> 192.168.201.102 - host/abc-ipa.abc.xyz at ABC.XYZ [10/Mar/2012:21:27:25 >>> +0000] "POST /ipa/xml HTTP/1.1" 200 314 >>> >>> here is the ipa-getcert list: >>> >>> http://fpaste.org/Dzr3/ >> >> >> You need to update certmonger, it isn't setting a Referer HTTP header in its >> request. That is now required by IPA. >> >> >> rob >> >>> >>> On Thu, Mar 15, 2012 at 1:33 PM, Rob Crittenden >>> wrote: >>>> >>>> Jimmy wrote: >>>>> >>>>> >>>>> Restarted IPA and now the interface loads, but resubmitting the cert >>>>> has this result - >>>>> >>>>> ipa-getcert resubmit -i 20110913154233 >>>>> 192.168.201.102 - - [10/Mar/2012:20:53:13 +0000] "POST /ipa/xml >>>>> HTTP/1.1" 401 1775 >>>>> 192.168.201.102 - host/abc-ipa.abc.xyz at ABC.XYZ [10/Mar/2012:20:53:13 >>>>> +0000] "POST /ipa/xml HTTP/1.1" 200 314 >>>>> >>>>> but the cert still shows these dates- >>>>> >>>>> Not Before: Tue Sep 13 15:43:37 2011 >>>>> Not After : Sun Mar 11 15:43:37 2012 >>>> >>>> >>>> >>>> The error log will contain more interesting information. >>>> >>>> What does the status show in the output of ipa-getcert list? >>>> >>>> rob >>>> >>>>> >>>>> >>>>> On Thu, Mar 15, 2012 at 1:06 PM, Jimmy wrote: >>>>>> >>>>>> >>>>>> I can now start the upgraded IPA, but now going to the IPA admin page >>>>>> I get this: >>>>>> >>>>>> ==== >>>>>> >>>>>> Not Found >>>>>> >>>>>> The requested URL /ipa was not found on this server. >>>>>> >>>>>> ==== >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Freeipa-users mailing list >>>>> Freeipa-users at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>> >>>> >>>> >> From g17jimmy at gmail.com Thu Mar 15 19:32:28 2012 From: g17jimmy at gmail.com (Jimmy) Date: Thu, 15 Mar 2012 15:32:28 -0400 Subject: [Freeipa-users] (no subject) In-Reply-To: <4F624162.7020806@redhat.com> References: <4F610869.40501@redhat.com> <4F610995.2020500@redhat.com> <4F611084.3010606@redhat.com> <-512731158224897185@unknownmsgid> <4F6114A5.3090507@redhat.com> <4F612BBB.3070404@redhat.com> <4F622801.10600@redhat.com> <4F622FC9.8040003@redhat.com> <4F624162.7020806@redhat.com> Message-ID: Still shows status: CA_UNREACHABLE http://fpaste.org/UrTJ/ On Thu, Mar 15, 2012 at 3:22 PM, Rob Crittenden wrote: > Jimmy wrote: >> >> I used yum to upgrade cert monger now the access_log has nothing new >> when I run the ipa-getcert, but error_log shows this: >> >> [Sat Mar 10 21:47:21 2012] [error] ipa: INFO: sslget >> 'https://xyz-ipa.abc.xyz:443/ca/agent/ca/displayBySerial' >> [Sat Mar 10 21:47:21 2012] [error] ipa: INFO: >> host/xyz-ipa.abc.xyz at ABC.XYZ: >> >> cert_request(u'MIIDQzCCAisCAQAwLDEQMA4GA1UEChMHUERILkNTUDEYMBYGA1UEAxMPY3NwLWlkbS5wZGguY3NwMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr0EHCdyTuteryFZ2bdEl+V4OATR/xk8ELthmvlwT/5qubZKwlCWS6yLawgdyCg9Yw737A7qGe0BPxHv6E+as10NxppEPsn9BOi+TPRIMYNMNNYmO2sce2pvkMkVBqsF7Gn7mF7e5+Bpc7ApnDGP7WLsAjbso8EvLUrqVMTNyiziCSHiNk+/Fi1Om6K5GKzKkqfEDex0RK+kpMswgcaZHhmW3i+y3UxFZsJjOg3R4fJAfC0+My2d1Vx4052+EgWAbSNpSj7zmLGM2+dkmgMo5Li7jjgJe8VsrqOV4L5IgqtGVJ0EOb7EP7gynbVoa74m4XrVwEP8rd/M5RxAnD1JPuwIDAQABoIHRMBoGCSqGSIb3DQEJFDENEwtTZXJ2ZXItQ2VydDCBsgYJKoZIhvcNAQkOMYGkMIGhMA4GA1UdDwEBAAQEAwIE8DB3BgNVHREBAQAEbTBroCwGCisGAQQBgjcUAgOgHgwcbGRhcC9jc3AtaWRtLnBkaC5jc3BAUERILkNTUKA7BgYrBgEFAgKgMTAvoAkbB1BESC5DU1ChIjAgoAMCAQGhGTAXGwRsZGFwGw9jc3AtaWRtLnBkaC5jc3AwFgYDVR0lAQEABAwwCgYIKwYBBQUHAwEwDQYJKoZIhvcNAQELBQADggEBABD/Hwbgf5NJNUYt0+ntMDHiilMFkSaO6ryQ36/pCH1oR+vI+PCeClHewPo0v99h4Z8W8L7CQtDdNBUMl/JVHH5Lz7cBF8A/jXZQ+naV17EEuXncacM8AvYh5dL2yih+8RpPalEmSgz5rijtbSigfNGrZn0Mh3qOW1kbsz+GDaaT9wLFxvdJyqgdKds2tsp0KzHIM > > cJuw3cwOfH8zrBRV28XYhMLm0OOhj92uxgax5UPY2VyHP5UOtOnfuduU1ZXa+o8QIXqX7/HyDSCLGwiPJscAsp9cRzjn4KvqzZDOcdGEjXmCGfrmUiMcuzVyTDR2SdAWrHdbRmXeyVxmiBPzdk=', >> >> principal=u'ldap/xyz-ipa.abc.xyz at ABC.XYZ', add=True): >> CertificateOperationError > > > What does ipa-getcert list show? > > You may now have something in the CA logs too. > > > rob >> >> >> >> On Thu, Mar 15, 2012 at 2:07 PM, Rob Crittenden >> ?wrote: >>> >>> Jimmy wrote: >>>> >>>> >>>> Which error log? the pki-ca error log has nothing and the httpd error >>>> log has nothing, and the httpd access log has this: (yes, the dates >>>> are set back a few days, bc the current cert expires on 3/11) >>>> >>>> 192.168.201.102 - - [10/Mar/2012:21:27:24 +0000] "POST /ipa/xml >>>> HTTP/1.1" 401 1775 >>>> 192.168.201.102 - host/abc-ipa.abc.xyz at ABC.XYZ [10/Mar/2012:21:27:25 >>>> +0000] "POST /ipa/xml HTTP/1.1" 200 314 >>>> >>>> here is the ipa-getcert list: >>>> >>>> http://fpaste.org/Dzr3/ >>> >>> >>> >>> You need to update certmonger, it isn't setting a Referer HTTP header in >>> its >>> request. That is now required by IPA. >>> >>> >>> rob >>> >>>> >>>> On Thu, Mar 15, 2012 at 1:33 PM, Rob Crittenden >>>> ?wrote: >>>>> >>>>> >>>>> Jimmy wrote: >>>>>> >>>>>> >>>>>> >>>>>> Restarted IPA and now the interface loads, but resubmitting the cert >>>>>> has this result - >>>>>> >>>>>> ipa-getcert resubmit -i 20110913154233 >>>>>> 192.168.201.102 - - [10/Mar/2012:20:53:13 +0000] "POST /ipa/xml >>>>>> HTTP/1.1" 401 1775 >>>>>> 192.168.201.102 - host/abc-ipa.abc.xyz at ABC.XYZ [10/Mar/2012:20:53:13 >>>>>> +0000] "POST /ipa/xml HTTP/1.1" 200 314 >>>>>> >>>>>> but the cert still shows these dates- >>>>>> >>>>>> ?Not Before: Tue Sep 13 15:43:37 2011 >>>>>> ? ? ? ? ? ? Not After : Sun Mar 11 15:43:37 2012 >>>>> >>>>> >>>>> >>>>> >>>>> The error log will contain more interesting information. >>>>> >>>>> What does the status show in the output of ipa-getcert list? >>>>> >>>>> rob >>>>> >>>>>> >>>>>> >>>>>> On Thu, Mar 15, 2012 at 1:06 PM, Jimmy ? ? ?wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> I can now start the upgraded IPA, but now going to the IPA admin page >>>>>>> I get this: >>>>>>> >>>>>>> ==== >>>>>>> >>>>>>> Not Found >>>>>>> >>>>>>> The requested URL /ipa was not found on this server. >>>>>>> >>>>>>> ==== >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Freeipa-users mailing list >>>>>> Freeipa-users at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>> >>>>> >>>>> >>>>> >>> > From rcritten at redhat.com Thu Mar 15 20:38:37 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 15 Mar 2012 16:38:37 -0400 Subject: [Freeipa-users] Windows Password Synchronization Error In-Reply-To: References: <03b801cd01de$2a8f3c10$7fadb430$@zik.hs-anhalt.de> <4F60B9AB.3020706@redhat.com> Message-ID: <4F62534D.20708@redhat.com> Bennet Lingner wrote: > Something more: > > On FreeIPA side there are built these errors too: > > [15/Mar/2012:10:02:02 +0100] encrypt_encode_key - [file > ipapwd_encoding.c, line 451]: krb5_c_string_to_key failed [Invalid argument] > > [15/Mar/2012:10:02:02 +0100] ipapwd_gen_hashes - [file > ipapwd_encoding.c, line 776]: key encryption/encoding failed It is failing trying to create a Kerberos key out of the password. I'm not sure why at the moment, that is a very strange message coming out of the krb5 libs. rob > > *Von:*Bennet Lingner [mailto:b.lingner at zik.hs-anhalt.de] > *Gesendet:* Donnerstag, 15. M?rz 2012 10:34 > *An:* 'freeipa-users at redhat.com' > *Betreff:* AW: Windows Password Synchronization Error > > Hi, > > Thank you for your reply. > > Version of freeipa and 389 packages: > > Freeipa server, python, admintools, client, server-selinux all in > 2.1.4-5.fc16.i686 > > 389-ds-base-1.2.10.3-1.fc16.i686 + libs > > Platform is Fedora 16 3.2.9-2.fc16.i686.PAE on AMD Opteron CPU > > Ldapmodify and ipa passwd are working perfectly, I?ve changed password > in this ways and passwords were synchronized. > > So I conclude the problem is specific to AD Passsync? > > If it is so, do I have the possibility on AD side too to set or try > something? > > Best regards. > > Bennet Lingner > > *Von:*Rich Megginson [mailto:rmeggins at redhat.com] > *Gesendet:* Mittwoch, 14. M?rz 2012 16:31 > *An:* Bennet Lingner > *Betreff:* Re: Windows Password Synchronization Error > > On 03/14/2012 06:29 AM, Bennet Lingner wrote: > > Dear Mr. Megginson, > > I?ve seen in www, that you are very involved in 389 directory server, > that?s why I decided to send this mail to you. > > I hope you can help me. > > I?m running a WIN2K8 R2 64 bit and a fedora Linux 32 bit with freeipa. > > In the future, please use the freeipa-users at redhat.com > email list. Please also include the > versions of your freeipa and 389 packages: > rpm -qa|grep freeipa > rpm -qa|grep 389 > > There is a win sync agreement, which works very well, even the passwords > are synchronized. > > The only problem is that: > > If I set a new password on windows side with more than 2 special > characters, e.g. ?!M?usel 10? or ?!R?diger 20? > > Then I get the passsync error: > > 03/14/12 12:26:13: Ldap error in ModifyPassword > > 1: Operations error > > 03/14/12 12:26:13: Modify Password failed for remote entry: uid=? > > 03/14/12 12:26:13: Deferring password change for ? > > Do you have any idea, if that could be or something else, what can I do? > > What is your 389-ds-base version and platform? > Can you use ldapmodify to change the user password to one of the above > values? Can you use ipa-passwd? That is, is the problem specific to AD > PassSync, or is it a problem with these types of passwords in general? > > Best regards. > > Mit freundlichen Gr??en > > Bennet Lingner > > *Hochschule Anhalt *- ZIK > > b.lingner at zik.hs-anhalt.de > > Tel. +49 (0) 3496 67-5420 > > Fax +49 (0) 3496 67-95420 > > Bernburger Stra?e 55 > > 06366 K?then (Anhalt) > > Hochschule Anhalt (FH) * Bernburger Stra?e 55 * D 06366 K?then > Pr?sident Prof. Dr. Dr. h.c. Dieter Orzessek * Tel.: +49 (0) 3496 67 > 1000 * Fax +49 (0) 3496 67 1099 > Betriebsnummer 030 77 111 * Umsatzsteuernummer DE 8140 92 585 > Zust?ndige Aufsichtsbeh?rde Kultusministerium des Landes Sachsen-Anhalt, > PF 3765, 39012 Magdeburg > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From rcritten at redhat.com Thu Mar 15 20:47:11 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 15 Mar 2012 16:47:11 -0400 Subject: [Freeipa-users] (no subject) In-Reply-To: References: <4F610995.2020500@redhat.com> <4F611084.3010606@redhat.com> <-512731158224897185@unknownmsgid> <4F6114A5.3090507@redhat.com> <4F612BBB.3070404@redhat.com> <4F622801.10600@redhat.com> <4F622FC9.8040003@redhat.com> <4F624162.7020806@redhat.com> Message-ID: <4F62554F.1030804@redhat.com> Jimmy wrote: > Still shows status: CA_UNREACHABLE > > http://fpaste.org/UrTJ/ If there was an Internal Server Error there should be an error in the Apache error log or something in the CA debug/transaction log (or both). Can you check those? rob > > On Thu, Mar 15, 2012 at 3:22 PM, Rob Crittenden wrote: >> Jimmy wrote: >>> >>> I used yum to upgrade cert monger now the access_log has nothing new >>> when I run the ipa-getcert, but error_log shows this: >>> >>> [Sat Mar 10 21:47:21 2012] [error] ipa: INFO: sslget >>> 'https://xyz-ipa.abc.xyz:443/ca/agent/ca/displayBySerial' >>> [Sat Mar 10 21:47:21 2012] [error] ipa: INFO: >>> host/xyz-ipa.abc.xyz at ABC.XYZ: >>> >>> cert_request(u'MIIDQzCCAisCAQAwLDEQMA4GA1UEChMHUERILkNTUDEYMBYGA1UEAxMPY3NwLWlkbS5wZGguY3NwMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr0EHCdyTuteryFZ2bdEl+V4OATR/xk8ELthmvlwT/5qubZKwlCWS6yLawgdyCg9Yw737A7qGe0BPxHv6E+as10NxppEPsn9BOi+TPRIMYNMNNYmO2sce2pvkMkVBqsF7Gn7mF7e5+Bpc7ApnDGP7WLsAjbso8EvLUrqVMTNyiziCSHiNk+/Fi1Om6K5GKzKkqfEDex0RK+kpMswgcaZHhmW3i+y3UxFZsJjOg3R4fJAfC0+My2d1Vx4052+EgWAbSNpSj7zmLGM2+dkmgMo5Li7jjgJe8VsrqOV4L5IgqtGVJ0EOb7EP7gynbVoa74m4XrVwEP8rd/M5RxAnD1JPuwIDAQABoIHRMBoGCSqGSIb3DQEJFDENEwtTZXJ2ZXItQ2VydDCBsgYJKoZIhvcNAQkOMYGkMIGhMA4GA1UdDwEBAAQEAwIE8DB3BgNVHREBAQAEbTBroCwGCisGAQQBgjcUAgOgHgwcbGRhcC9jc3AtaWRtLnBkaC5jc3BAUERILkNTUKA7BgYrBgEFAgKgMTAvoAkbB1BESC5DU1ChIjAgoAMCAQGhGTAXGwRsZGFwGw9jc3AtaWRtLnBkaC5jc3AwFgYDVR0lAQEABAwwCgYIKwYBBQUHAwEwDQYJKoZIhvcNAQELBQADggEBABD/Hwbgf5NJNUYt0+ntMDHiilMFkSaO6ryQ36/pCH1oR+vI+PCeClHewPo0v99h4Z8W8L7CQtDdNBUMl/JVHH5Lz7cBF8A/jXZQ+naV17EEuXncacM8AvYh5dL2yih+8RpPalEmSgz5rijtbSigfNGrZn0Mh3qOW1kbsz+GDaaT9wLFxvdJyqgdKds2tsp0KzH IM >> >> cJuw3cwOfH8zrBRV28XYhMLm0OOhj92uxgax5UPY2VyHP5UOtOnfuduU1ZXa+o8QIXqX7/HyDSCLGwiPJscAsp9cRzjn4KvqzZDOcdGEjXmCGfrmUiMcuzVyTDR2SdAWrHdbRmXeyVxmiBPzdk=', >>> >>> principal=u'ldap/xyz-ipa.abc.xyz at ABC.XYZ', add=True): >>> CertificateOperationError >> >> >> What does ipa-getcert list show? >> >> You may now have something in the CA logs too. >> >> >> rob >>> >>> >>> >>> On Thu, Mar 15, 2012 at 2:07 PM, Rob Crittenden >>> wrote: >>>> >>>> Jimmy wrote: >>>>> >>>>> >>>>> Which error log? the pki-ca error log has nothing and the httpd error >>>>> log has nothing, and the httpd access log has this: (yes, the dates >>>>> are set back a few days, bc the current cert expires on 3/11) >>>>> >>>>> 192.168.201.102 - - [10/Mar/2012:21:27:24 +0000] "POST /ipa/xml >>>>> HTTP/1.1" 401 1775 >>>>> 192.168.201.102 - host/abc-ipa.abc.xyz at ABC.XYZ [10/Mar/2012:21:27:25 >>>>> +0000] "POST /ipa/xml HTTP/1.1" 200 314 >>>>> >>>>> here is the ipa-getcert list: >>>>> >>>>> http://fpaste.org/Dzr3/ >>>> >>>> >>>> >>>> You need to update certmonger, it isn't setting a Referer HTTP header in >>>> its >>>> request. That is now required by IPA. >>>> >>>> >>>> rob >>>> >>>>> >>>>> On Thu, Mar 15, 2012 at 1:33 PM, Rob Crittenden >>>>> wrote: >>>>>> >>>>>> >>>>>> Jimmy wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> Restarted IPA and now the interface loads, but resubmitting the cert >>>>>>> has this result - >>>>>>> >>>>>>> ipa-getcert resubmit -i 20110913154233 >>>>>>> 192.168.201.102 - - [10/Mar/2012:20:53:13 +0000] "POST /ipa/xml >>>>>>> HTTP/1.1" 401 1775 >>>>>>> 192.168.201.102 - host/abc-ipa.abc.xyz at ABC.XYZ [10/Mar/2012:20:53:13 >>>>>>> +0000] "POST /ipa/xml HTTP/1.1" 200 314 >>>>>>> >>>>>>> but the cert still shows these dates- >>>>>>> >>>>>>> Not Before: Tue Sep 13 15:43:37 2011 >>>>>>> Not After : Sun Mar 11 15:43:37 2012 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> The error log will contain more interesting information. >>>>>> >>>>>> What does the status show in the output of ipa-getcert list? >>>>>> >>>>>> rob >>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Mar 15, 2012 at 1:06 PM, Jimmy wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I can now start the upgraded IPA, but now going to the IPA admin page >>>>>>>> I get this: >>>>>>>> >>>>>>>> ==== >>>>>>>> >>>>>>>> Not Found >>>>>>>> >>>>>>>> The requested URL /ipa was not found on this server. >>>>>>>> >>>>>>>> ==== >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Freeipa-users mailing list >>>>>>> Freeipa-users at redhat.com >>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>>> >>>>>> >>>>>> >>>>>> >>>> >> From g17jimmy at gmail.com Thu Mar 15 21:12:49 2012 From: g17jimmy at gmail.com (Jimmy) Date: Thu, 15 Mar 2012 17:12:49 -0400 Subject: [Freeipa-users] (no subject) In-Reply-To: <4F62554F.1030804@redhat.com> References: <4F610995.2020500@redhat.com> <4F611084.3010606@redhat.com> <-512731158224897185@unknownmsgid> <4F6114A5.3090507@redhat.com> <4F612BBB.3070404@redhat.com> <4F622801.10600@redhat.com> <4F622FC9.8040003@redhat.com> <4F624162.7020806@redhat.com> <4F62554F.1030804@redhat.com> Message-ID: error log: http://fpaste.org/efyf/ CA debug: http://fpaste.org/LemM/ CA localhost log: http://fpaste.org/q4MU/ That's all I can find the correspond to the time I ran the getcert. Jimmy On Thu, Mar 15, 2012 at 4:47 PM, Rob Crittenden wrote: > Jimmy wrote: >> >> Still shows status: CA_UNREACHABLE >> >> http://fpaste.org/UrTJ/ > > > If there was an Internal Server Error there should be an error in the Apache > error log or something in the CA debug/transaction log (or both). Can you > check those? > > rob > >> >> On Thu, Mar 15, 2012 at 3:22 PM, Rob Crittenden >> ?wrote: >>> >>> Jimmy wrote: >>>> >>>> >>>> I used yum to upgrade cert monger now the access_log has nothing new >>>> when I run the ipa-getcert, but error_log shows this: >>>> >>>> [Sat Mar 10 21:47:21 2012] [error] ipa: INFO: sslget >>>> 'https://xyz-ipa.abc.xyz:443/ca/agent/ca/displayBySerial' >>>> [Sat Mar 10 21:47:21 2012] [error] ipa: INFO: >>>> host/xyz-ipa.abc.xyz at ABC.XYZ: >>>> >>>> >>>> cert_request(u'MIIDQzCCAisCAQAwLDEQMA4GA1UEChMHUERILkNTUDEYMBYGA1UEAxMPY3NwLWlkbS5wZGguY3NwMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr0EHCdyTuteryFZ2bdEl+V4OATR/xk8ELthmvlwT/5qubZKwlCWS6yLawgdyCg9Yw737A7qGe0BPxHv6E+as10NxppEPsn9BOi+TPRIMYNMNNYmO2sce2pvkMkVBqsF7Gn7mF7e5+Bpc7ApnDGP7WLsAjbso8EvLUrqVMTNyiziCSHiNk+/Fi1Om6K5GKzKkqfEDex0RK+kpMswgcaZHhmW3i+y3UxFZsJjOg3R4fJAfC0+My2d1Vx4052+EgWAbSNpSj7zmLGM2+dkmgMo5Li7jjgJe8VsrqOV4L5IgqtGVJ0EOb7EP7gynbVoa74m4XrVwEP8rd/M5RxAnD1JPuwIDAQABoIHRMBoGCSqGSIb3DQEJFDENEwtTZXJ2ZXItQ2VydDCBsgYJKoZIhvcNAQkOMYGkMIGhMA4GA1UdDwEBAAQEAwIE8DB3BgNVHREBAQAEbTBroCwGCisGAQQBgjcUAgOgHgwcbGRhcC9jc3AtaWRtLnBkaC5jc3BAUERILkNTUKA7BgYrBgEFAgKgMTAvoAkbB1BESC5DU1ChIjAgoAMCAQGhGTAXGwRsZGFwGw9jc3AtaWRtLnBkaC5jc3AwFgYDVR0lAQEABAwwCgYIKwYBBQUHAwEwDQYJKoZIhvcNAQELBQADggEBABD/Hwbgf5NJNUYt0+ntMDHiilMFkSaO6ryQ36/pCH1oR+vI+PCeClHewPo0v99h4Z8W8L7CQtDdNBUMl/JVHH5Lz7cBF8A/jXZQ+naV17EEuXncacM8AvYh5dL2yih+8RpPalEmSgz5rijtbSigfNGrZn0Mh3qOW1kbsz+GDaaT9wLFxvdJyqgdKds2tsp0KzH > > IM >>> >>> >>> >>> cJuw3cwOfH8zrBRV28XYhMLm0OOhj92uxgax5UPY2VyHP5UOtOnfuduU1ZXa+o8QIXqX7/HyDSCLGwiPJscAsp9cRzjn4KvqzZDOcdGEjXmCGfrmUiMcuzVyTDR2SdAWrHdbRmXeyVxmiBPzdk=', >>>> >>>> >>>> principal=u'ldap/xyz-ipa.abc.xyz at ABC.XYZ', add=True): >>>> CertificateOperationError >>> >>> >>> >>> What does ipa-getcert list show? >>> >>> You may now have something in the CA logs too. >>> >>> >>> rob >>>> >>>> >>>> >>>> >>>> On Thu, Mar 15, 2012 at 2:07 PM, Rob Crittenden >>>> ?wrote: >>>>> >>>>> >>>>> Jimmy wrote: >>>>>> >>>>>> >>>>>> >>>>>> Which error log? the pki-ca error log has nothing and the httpd error >>>>>> log has nothing, and the httpd access log has this: (yes, the dates >>>>>> are set back a few days, bc the current cert expires on 3/11) >>>>>> >>>>>> 192.168.201.102 - - [10/Mar/2012:21:27:24 +0000] "POST /ipa/xml >>>>>> HTTP/1.1" 401 1775 >>>>>> 192.168.201.102 - host/abc-ipa.abc.xyz at ABC.XYZ [10/Mar/2012:21:27:25 >>>>>> +0000] "POST /ipa/xml HTTP/1.1" 200 314 >>>>>> >>>>>> here is the ipa-getcert list: >>>>>> >>>>>> http://fpaste.org/Dzr3/ >>>>> >>>>> >>>>> >>>>> >>>>> You need to update certmonger, it isn't setting a Referer HTTP header >>>>> in >>>>> its >>>>> request. That is now required by IPA. >>>>> >>>>> >>>>> rob >>>>> >>>>>> >>>>>> On Thu, Mar 15, 2012 at 1:33 PM, Rob Crittenden >>>>>> ?wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> Jimmy wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Restarted IPA and now the interface loads, but resubmitting the cert >>>>>>>> has this result - >>>>>>>> >>>>>>>> ipa-getcert resubmit -i 20110913154233 >>>>>>>> 192.168.201.102 - - [10/Mar/2012:20:53:13 +0000] "POST /ipa/xml >>>>>>>> HTTP/1.1" 401 1775 >>>>>>>> 192.168.201.102 - host/abc-ipa.abc.xyz at ABC.XYZ [10/Mar/2012:20:53:13 >>>>>>>> +0000] "POST /ipa/xml HTTP/1.1" 200 314 >>>>>>>> >>>>>>>> but the cert still shows these dates- >>>>>>>> >>>>>>>> ?Not Before: Tue Sep 13 15:43:37 2011 >>>>>>>> ? ? ? ? ? ? Not After : Sun Mar 11 15:43:37 2012 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> The error log will contain more interesting information. >>>>>>> >>>>>>> What does the status show in the output of ipa-getcert list? >>>>>>> >>>>>>> rob >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Mar 15, 2012 at 1:06 PM, Jimmy >>>>>>>> ?wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I can now start the upgraded IPA, but now going to the IPA admin >>>>>>>>> page >>>>>>>>> I get this: >>>>>>>>> >>>>>>>>> ==== >>>>>>>>> >>>>>>>>> Not Found >>>>>>>>> >>>>>>>>> The requested URL /ipa was not found on this server. >>>>>>>>> >>>>>>>>> ==== >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Freeipa-users mailing list >>>>>>>> Freeipa-users at redhat.com >>>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >>> > From rcritten at redhat.com Thu Mar 15 21:37:57 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 15 Mar 2012 17:37:57 -0400 Subject: [Freeipa-users] (no subject) In-Reply-To: References: <4F611084.3010606@redhat.com> <-512731158224897185@unknownmsgid> <4F6114A5.3090507@redhat.com> <4F612BBB.3070404@redhat.com> <4F622801.10600@redhat.com> <4F622FC9.8040003@redhat.com> <4F624162.7020806@redhat.com> <4F62554F.1030804@redhat.com> Message-ID: <4F626135.3030402@redhat.com> Jimmy wrote: > error log: http://fpaste.org/efyf/ > > CA debug: http://fpaste.org/LemM/ > > CA localhost log: http://fpaste.org/q4MU/ > > That's all I can find the correspond to the time I ran the getcert. I'd look at the catalina.log, is dogtag coming up ok? rob > > Jimmy > On Thu, Mar 15, 2012 at 4:47 PM, Rob Crittenden wrote: >> Jimmy wrote: >>> >>> Still shows status: CA_UNREACHABLE >>> >>> http://fpaste.org/UrTJ/ >> >> >> If there was an Internal Server Error there should be an error in the Apache >> error log or something in the CA debug/transaction log (or both). Can you >> check those? >> >> rob >> >>> >>> On Thu, Mar 15, 2012 at 3:22 PM, Rob Crittenden >>> wrote: >>>> >>>> Jimmy wrote: >>>>> >>>>> >>>>> I used yum to upgrade cert monger now the access_log has nothing new >>>>> when I run the ipa-getcert, but error_log shows this: >>>>> >>>>> [Sat Mar 10 21:47:21 2012] [error] ipa: INFO: sslget >>>>> 'https://xyz-ipa.abc.xyz:443/ca/agent/ca/displayBySerial' >>>>> [Sat Mar 10 21:47:21 2012] [error] ipa: INFO: >>>>> host/xyz-ipa.abc.xyz at ABC.XYZ: >>>>> >>>>> >>>>> cert_request(u'MIIDQzCCAisCAQAwLDEQMA4GA1UEChMHUERILkNTUDEYMBYGA1UEAxMPY3NwLWlkbS5wZGguY3NwMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr0EHCdyTuteryFZ2bdEl+V4OATR/xk8ELthmvlwT/5qubZKwlCWS6yLawgdyCg9Yw737A7qGe0BPxHv6E+as10NxppEPsn9BOi+TPRIMYNMNNYmO2sce2pvkMkVBqsF7Gn7mF7e5+Bpc7ApnDGP7WLsAjbso8EvLUrqVMTNyiziCSHiNk+/Fi1Om6K5GKzKkqfEDex0RK+kpMswgcaZHhmW3i+y3UxFZsJjOg3R4fJAfC0+My2d1Vx4052+EgWAbSNpSj7zmLGM2+dkmgMo5Li7jjgJe8VsrqOV4L5IgqtGVJ0EOb7EP7gynbVoa74m4XrVwEP8rd/M5RxAnD1JPuwIDAQABoIHRMBoGCSqGSIb3DQEJFDENEwtTZXJ2ZXItQ2VydDCBsgYJKoZIhvcNAQkOMYGkMIGhMA4GA1UdDwEBAAQEAwIE8DB3BgNVHREBAQAEbTBroCwGCisGAQQBgjcUAgOgHgwcbGRhcC9jc3AtaWRtLnBkaC5jc3BAUERILkNTUKA7BgYrBgEFAgKgMTAvoAkbB1BESC5DU1ChIjAgoAMCAQGhGTAXGwRsZGFwGw9jc3AtaWRtLnBkaC5jc3AwFgYDVR0lAQEABAwwCgYIKwYBBQUHAwEwDQYJKoZIhvcNAQELBQADggEBABD/Hwbgf5NJNUYt0+ntMDHiilMFkSaO6ryQ36/pCH1oR+vI+PCeClHewPo0v99h4Z8W8L7CQtDdNBUMl/JVHH5Lz7cBF8A/jXZQ+naV17EEuXncacM8AvYh5dL2yih+8RpPalEmSgz5rijtbSigfNGrZn0Mh3qOW1kbsz+GDaaT9wLFxvdJyqgdKds2tsp0K zH >> >> IM >>>> >>>> >>>> >>>> cJuw3cwOfH8zrBRV28XYhMLm0OOhj92uxgax5UPY2VyHP5UOtOnfuduU1ZXa+o8QIXqX7/HyDSCLGwiPJscAsp9cRzjn4KvqzZDOcdGEjXmCGfrmUiMcuzVyTDR2SdAWrHdbRmXeyVxmiBPzdk=', >>>>> >>>>> >>>>> principal=u'ldap/xyz-ipa.abc.xyz at ABC.XYZ', add=True): >>>>> CertificateOperationError >>>> >>>> >>>> >>>> What does ipa-getcert list show? >>>> >>>> You may now have something in the CA logs too. >>>> >>>> >>>> rob >>>>> >>>>> >>>>> >>>>> >>>>> On Thu, Mar 15, 2012 at 2:07 PM, Rob Crittenden >>>>> wrote: >>>>>> >>>>>> >>>>>> Jimmy wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> Which error log? the pki-ca error log has nothing and the httpd error >>>>>>> log has nothing, and the httpd access log has this: (yes, the dates >>>>>>> are set back a few days, bc the current cert expires on 3/11) >>>>>>> >>>>>>> 192.168.201.102 - - [10/Mar/2012:21:27:24 +0000] "POST /ipa/xml >>>>>>> HTTP/1.1" 401 1775 >>>>>>> 192.168.201.102 - host/abc-ipa.abc.xyz at ABC.XYZ [10/Mar/2012:21:27:25 >>>>>>> +0000] "POST /ipa/xml HTTP/1.1" 200 314 >>>>>>> >>>>>>> here is the ipa-getcert list: >>>>>>> >>>>>>> http://fpaste.org/Dzr3/ >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> You need to update certmonger, it isn't setting a Referer HTTP header >>>>>> in >>>>>> its >>>>>> request. That is now required by IPA. >>>>>> >>>>>> >>>>>> rob >>>>>> >>>>>>> >>>>>>> On Thu, Mar 15, 2012 at 1:33 PM, Rob Crittenden >>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Jimmy wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Restarted IPA and now the interface loads, but resubmitting the cert >>>>>>>>> has this result - >>>>>>>>> >>>>>>>>> ipa-getcert resubmit -i 20110913154233 >>>>>>>>> 192.168.201.102 - - [10/Mar/2012:20:53:13 +0000] "POST /ipa/xml >>>>>>>>> HTTP/1.1" 401 1775 >>>>>>>>> 192.168.201.102 - host/abc-ipa.abc.xyz at ABC.XYZ [10/Mar/2012:20:53:13 >>>>>>>>> +0000] "POST /ipa/xml HTTP/1.1" 200 314 >>>>>>>>> >>>>>>>>> but the cert still shows these dates- >>>>>>>>> >>>>>>>>> Not Before: Tue Sep 13 15:43:37 2011 >>>>>>>>> Not After : Sun Mar 11 15:43:37 2012 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> The error log will contain more interesting information. >>>>>>>> >>>>>>>> What does the status show in the output of ipa-getcert list? >>>>>>>> >>>>>>>> rob >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Mar 15, 2012 at 1:06 PM, Jimmy >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I can now start the upgraded IPA, but now going to the IPA admin >>>>>>>>>> page >>>>>>>>>> I get this: >>>>>>>>>> >>>>>>>>>> ==== >>>>>>>>>> >>>>>>>>>> Not Found >>>>>>>>>> >>>>>>>>>> The requested URL /ipa was not found on this server. >>>>>>>>>> >>>>>>>>>> ==== >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Freeipa-users mailing list >>>>>>>>> Freeipa-users at redhat.com >>>>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>> >> From g17jimmy at gmail.com Thu Mar 15 23:04:36 2012 From: g17jimmy at gmail.com (Jimmy Caldwell) Date: Thu, 15 Mar 2012 19:04:36 -0400 Subject: [Freeipa-users] (no subject) In-Reply-To: <4F626135.3030402@redhat.com> References: <4F611084.3010606@redhat.com> <-512731158224897185@unknownmsgid> <4F6114A5.3090507@redhat.com> <4F612BBB.3070404@redhat.com> <4F622801.10600@redhat.com> <4F622FC9.8040003@redhat.com> <4F624162.7020806@redhat.com> <4F62554F.1030804@redhat.com> <4F626135.3030402@redhat.com> Message-ID: <-1301663750125418285@unknownmsgid> I'll check that in the morning. Sent from my mobile device On Mar 15, 2012, at 17:38, Rob Crittenden wrote: > Jimmy wrote: >> error log: http://fpaste.org/efyf/ >> >> CA debug: http://fpaste.org/LemM/ >> >> CA localhost log: http://fpaste.org/q4MU/ >> >> That's all I can find the correspond to the time I ran the getcert. > > I'd look at the catalina.log, is dogtag coming up ok? > > rob > >> >> Jimmy >> On Thu, Mar 15, 2012 at 4:47 PM, Rob Crittenden wrote: >>> Jimmy wrote: >>>> >>>> Still shows status: CA_UNREACHABLE >>>> >>>> http://fpaste.org/UrTJ/ >>> >>> >>> If there was an Internal Server Error there should be an error in the Apache >>> error log or something in the CA debug/transaction log (or both). Can you >>> check those? >>> >>> rob >>> >>>> >>>> On Thu, Mar 15, 2012 at 3:22 PM, Rob Crittenden >>>> wrote: >>>>> >>>>> Jimmy wrote: >>>>>> >>>>>> >>>>>> I used yum to upgrade cert monger now the access_log has nothing new >>>>>> when I run the ipa-getcert, but error_log shows this: >>>>>> >>>>>> [Sat Mar 10 21:47:21 2012] [error] ipa: INFO: sslget >>>>>> 'https://xyz-ipa.abc.xyz:443/ca/agent/ca/displayBySerial' >>>>>> [Sat Mar 10 21:47:21 2012] [error] ipa: INFO: >>>>>> host/xyz-ipa.abc.xyz at ABC.XYZ: >>>>>> >>>>>> >>>>>> cert_request(u'MIIDQzCCAisCAQAwLDEQMA4GA1UEChMHUERILkNTUDEYMBYGA1UEAxMPY3NwLWlkbS5wZGguY3NwMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr0EHCdyTuteryFZ2bdEl+V4OATR/xk8ELthmvlwT/5qubZKwlCWS6yLawgdyCg9Yw737A7qGe0BPxHv6E+as10NxppEPsn9BOi+TPRIMYNMNNYmO2sce2pvkMkVBqsF7Gn7mF7e5+Bpc7ApnDGP7WLsAjbso8EvLUrqVMTNyiziCSHiNk+/Fi1Om6K5GKzKkqfEDex0RK+kpMswgcaZHhmW3i+y3UxFZsJjOg3R4fJAfC0+My2d1Vx4052+EgWAbSNpSj7zmLGM2+dkmgMo5Li7jjgJe8VsrqOV4L5IgqtGVJ0EOb7EP7gynbVoa74m4XrVwEP8rd/M5RxAnD1JPuwIDAQABoIHRMBoGCSqGSIb3DQEJFDENEwtTZXJ2ZXItQ2VydDCBsgYJKoZIhvcNAQkOMYGkMIGhMA4GA1UdDwEBAAQEAwIE8DB3BgNVHREBAQAEbTBroCwGCisGAQQBgjcUAgOgHgwcbGRhcC9jc3AtaWRtLnBkaC5jc3BAUERILkNTUKA7BgYrBgEFAgKgMTAvoAkbB1BESC5DU1ChIjAgoAMCAQGhGTAXGwRsZGFwGw9jc3AtaWRtLnBkaC5jc3AwFgYDVR0lAQEABAwwCgYIKwYBBQUHAwEwDQYJKoZIhvcNAQELBQADggEBABD/Hwbgf5NJNUYt0+ntMDHiilMFkSaO6ryQ36/pCH1oR+vI+PCeClHewPo0v99h4Z8W8L7CQtDdNBUMl/JVHH5Lz7cBF8A/jXZQ+naV17EEuXncacM8AvYh5dL2yih+8RpPalEmSgz5rijtbSigfNGrZn0Mh3qOW1kbsz+GDaaT9wLFxvdJyqgdKds2tsp0K > zH >>> >>> IM >>>>> >>>>> >>>>> >>>>> cJuw3cwOfH8zrBRV28XYhMLm0OOhj92uxgax5UPY2VyHP5UOtOnfuduU1ZXa+o8QIXqX7/HyDSCLGwiPJscAsp9cRzjn4KvqzZDOcdGEjXmCGfrmUiMcuzVyTDR2SdAWrHdbRmXeyVxmiBPzdk=', >>>>>> >>>>>> >>>>>> principal=u'ldap/xyz-ipa.abc.xyz at ABC.XYZ', add=True): >>>>>> CertificateOperationError >>>>> >>>>> >>>>> >>>>> What does ipa-getcert list show? >>>>> >>>>> You may now have something in the CA logs too. >>>>> >>>>> >>>>> rob >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Mar 15, 2012 at 2:07 PM, Rob Crittenden >>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> Jimmy wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Which error log? the pki-ca error log has nothing and the httpd error >>>>>>>> log has nothing, and the httpd access log has this: (yes, the dates >>>>>>>> are set back a few days, bc the current cert expires on 3/11) >>>>>>>> >>>>>>>> 192.168.201.102 - - [10/Mar/2012:21:27:24 +0000] "POST /ipa/xml >>>>>>>> HTTP/1.1" 401 1775 >>>>>>>> 192.168.201.102 - host/abc-ipa.abc.xyz at ABC.XYZ [10/Mar/2012:21:27:25 >>>>>>>> +0000] "POST /ipa/xml HTTP/1.1" 200 314 >>>>>>>> >>>>>>>> here is the ipa-getcert list: >>>>>>>> >>>>>>>> http://fpaste.org/Dzr3/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> You need to update certmonger, it isn't setting a Referer HTTP header >>>>>>> in >>>>>>> its >>>>>>> request. That is now required by IPA. >>>>>>> >>>>>>> >>>>>>> rob >>>>>>> >>>>>>>> >>>>>>>> On Thu, Mar 15, 2012 at 1:33 PM, Rob Crittenden >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Jimmy wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Restarted IPA and now the interface loads, but resubmitting the cert >>>>>>>>>> has this result - >>>>>>>>>> >>>>>>>>>> ipa-getcert resubmit -i 20110913154233 >>>>>>>>>> 192.168.201.102 - - [10/Mar/2012:20:53:13 +0000] "POST /ipa/xml >>>>>>>>>> HTTP/1.1" 401 1775 >>>>>>>>>> 192.168.201.102 - host/abc-ipa.abc.xyz at ABC.XYZ [10/Mar/2012:20:53:13 >>>>>>>>>> +0000] "POST /ipa/xml HTTP/1.1" 200 314 >>>>>>>>>> >>>>>>>>>> but the cert still shows these dates- >>>>>>>>>> >>>>>>>>>> Not Before: Tue Sep 13 15:43:37 2011 >>>>>>>>>> Not After : Sun Mar 11 15:43:37 2012 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> The error log will contain more interesting information. >>>>>>>>> >>>>>>>>> What does the status show in the output of ipa-getcert list? >>>>>>>>> >>>>>>>>> rob >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Thu, Mar 15, 2012 at 1:06 PM, Jimmy >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I can now start the upgraded IPA, but now going to the IPA admin >>>>>>>>>>> page >>>>>>>>>>> I get this: >>>>>>>>>>> >>>>>>>>>>> ==== >>>>>>>>>>> >>>>>>>>>>> Not Found >>>>>>>>>>> >>>>>>>>>>> The requested URL /ipa was not found on this server. >>>>>>>>>>> >>>>>>>>>>> ==== >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Freeipa-users mailing list >>>>>>>>>> Freeipa-users at redhat.com >>>>>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>> > From natxo.asenjo at gmail.com Fri Mar 16 10:19:43 2012 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Fri, 16 Mar 2012 11:19:43 +0100 Subject: [Freeipa-users] mobile users questions Message-ID: hi, How are you folks coping with mobile (laptop) users and their homedirs? Is there something like the offline files voor Windows networks? I found a patch for rsync (http://jrds.fr/rsynck) that kerberizes the rsyncd daemon. Has anybody experience with it? Is the patch upstream? This could be useful, I reckon. I would really like to hear your thoughts about this. So far I have only servers and workstations. With sssd laptop users can log in offline, but I am at a loss of how to reconcile the homedirs/personal files yet. -- Groeten, natxo -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Fri Mar 16 12:31:00 2012 From: simo at redhat.com (Simo Sorce) Date: Fri, 16 Mar 2012 08:31:00 -0400 Subject: [Freeipa-users] mobile users questions In-Reply-To: References: Message-ID: <1331901060.9238.251.camel@willson.li.ssimo.org> On Fri, 2012-03-16 at 11:19 +0100, Natxo Asenjo wrote: > hi, > > How are you folks coping with mobile (laptop) users and their > homedirs? Is there something like the offline files voor Windows > networks? > > I found a patch for rsync (http://jrds.fr/rsynck) that kerberizes the > rsyncd daemon. Has anybody experience with it? Is the patch upstream? > This could be useful, I reckon. > > I would really like to hear your thoughts about this. So far I have > only servers and workstations. With sssd laptop users can log in > offline, but I am at a loss of how to reconcile the homedirs/personal > files yet. You may want to take a look at this project: http://www.csync.org/ Simo. -- Simo Sorce * Red Hat, Inc * New York From g17jimmy at gmail.com Fri Mar 16 15:02:04 2012 From: g17jimmy at gmail.com (Jimmy) Date: Fri, 16 Mar 2012 11:02:04 -0400 Subject: [Freeipa-users] (no subject) In-Reply-To: <4F626135.3030402@redhat.com> References: <4F611084.3010606@redhat.com> <-512731158224897185@unknownmsgid> <4F6114A5.3090507@redhat.com> <4F612BBB.3070404@redhat.com> <4F622801.10600@redhat.com> <4F622FC9.8040003@redhat.com> <4F624162.7020806@redhat.com> <4F62554F.1030804@redhat.com> <4F626135.3030402@redhat.com> Message-ID: I didn't see a catalina.log on my system, but there is a catalina.out: http://fpaste.org/KgJn/ -J On Thu, Mar 15, 2012 at 5:37 PM, Rob Crittenden wrote: > Jimmy wrote: >> >> error log: http://fpaste.org/efyf/ >> >> CA debug: http://fpaste.org/LemM/ >> >> CA localhost log: http://fpaste.org/q4MU/ >> >> That's all I can find the correspond to the time I ran the getcert. > > > I'd look at the catalina.log, is dogtag coming up ok? > > rob > > >> >> Jimmy >> On Thu, Mar 15, 2012 at 4:47 PM, Rob Crittenden >> ?wrote: >>> >>> Jimmy wrote: >>>> >>>> >>>> Still shows status: CA_UNREACHABLE >>>> >>>> http://fpaste.org/UrTJ/ >>> >>> >>> >>> If there was an Internal Server Error there should be an error in the >>> Apache >>> error log or something in the CA debug/transaction log (or both). Can you >>> check those? >>> >>> rob >>> >>>> >>>> On Thu, Mar 15, 2012 at 3:22 PM, Rob Crittenden >>>> ?wrote: >>>>> >>>>> >>>>> Jimmy wrote: >>>>>> >>>>>> >>>>>> >>>>>> I used yum to upgrade cert monger now the access_log has nothing new >>>>>> when I run the ipa-getcert, but error_log shows this: >>>>>> >>>>>> [Sat Mar 10 21:47:21 2012] [error] ipa: INFO: sslget >>>>>> 'https://xyz-ipa.abc.xyz:443/ca/agent/ca/displayBySerial' >>>>>> [Sat Mar 10 21:47:21 2012] [error] ipa: INFO: >>>>>> host/xyz-ipa.abc.xyz at ABC.XYZ: >>>>>> >>>>>> >>>>>> >>>>>> cert_request(u'MIIDQzCCAisCAQAwLDEQMA4GA1UEChMHUERILkNTUDEYMBYGA1UEAxMPY3NwLWlkbS5wZGguY3NwMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr0EHCdyTuteryFZ2bdEl+V4OATR/xk8ELthmvlwT/5qubZKwlCWS6yLawgdyCg9Yw737A7qGe0BPxHv6E+as10NxppEPsn9BOi+TPRIMYNMNNYmO2sce2pvkMkVBqsF7Gn7mF7e5+Bpc7ApnDGP7WLsAjbso8EvLUrqVMTNyiziCSHiNk+/Fi1Om6K5GKzKkqfEDex0RK+kpMswgcaZHhmW3i+y3UxFZsJjOg3R4fJAfC0+My2d1Vx4052+EgWAbSNpSj7zmLGM2+dkmgMo5Li7jjgJe8VsrqOV4L5IgqtGVJ0EOb7EP7gynbVoa74m4XrVwEP8rd/M5RxAnD1JPuwIDAQABoIHRMBoGCSqGSIb3DQEJFDENEwtTZXJ2ZXItQ2VydDCBsgYJKoZIhvcNAQkOMYGkMIGhMA4GA1UdDwEBAAQEAwIE8DB3BgNVHREBAQAEbTBroCwGCisGAQQBgjcUAgOgHgwcbGRhcC9jc3AtaWRtLnBkaC5jc3BAUERILkNTUKA7BgYrBgEFAgKgMTAvoAkbB1BESC5DU1ChIjAgoAMCAQGhGTAXGwRsZGFwGw9jc3AtaWRtLnBkaC5jc3AwFgYDVR0lAQEABAwwCgYIKwYBBQUHAwEwDQYJKoZIhvcNAQELBQADggEBABD/Hwbgf5NJNUYt0+ntMDHiilMFkSaO6ryQ36/pCH1oR+vI+PCeClHewPo0v99h4Z8W8L7CQtDdNBUMl/JVHH5Lz7cBF8A/jXZQ+naV17EEuXncacM8AvYh5dL2yih+8RpPalEmSgz5rijtbSigfNGrZn0Mh3qOW1kbsz+GDaaT9wLFxvdJyqgdKds2tsp0K > > zH >>> >>> >>> IM >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> cJuw3cwOfH8zrBRV28XYhMLm0OOhj92uxgax5UPY2VyHP5UOtOnfuduU1ZXa+o8QIXqX7/HyDSCLGwiPJscAsp9cRzjn4KvqzZDOcdGEjXmCGfrmUiMcuzVyTDR2SdAWrHdbRmXeyVxmiBPzdk=', >>>>>> >>>>>> >>>>>> >>>>>> principal=u'ldap/xyz-ipa.abc.xyz at ABC.XYZ', add=True): >>>>>> CertificateOperationError >>>>> >>>>> >>>>> >>>>> >>>>> What does ipa-getcert list show? >>>>> >>>>> You may now have something in the CA logs too. >>>>> >>>>> >>>>> rob >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Mar 15, 2012 at 2:07 PM, Rob Crittenden >>>>>> ?wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> Jimmy wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Which error log? the pki-ca error log has nothing and the httpd >>>>>>>> error >>>>>>>> log has nothing, and the httpd access log has this: (yes, the dates >>>>>>>> are set back a few days, bc the current cert expires on 3/11) >>>>>>>> >>>>>>>> 192.168.201.102 - - [10/Mar/2012:21:27:24 +0000] "POST /ipa/xml >>>>>>>> HTTP/1.1" 401 1775 >>>>>>>> 192.168.201.102 - host/abc-ipa.abc.xyz at ABC.XYZ [10/Mar/2012:21:27:25 >>>>>>>> +0000] "POST /ipa/xml HTTP/1.1" 200 314 >>>>>>>> >>>>>>>> here is the ipa-getcert list: >>>>>>>> >>>>>>>> http://fpaste.org/Dzr3/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> You need to update certmonger, it isn't setting a Referer HTTP header >>>>>>> in >>>>>>> its >>>>>>> request. That is now required by IPA. >>>>>>> >>>>>>> >>>>>>> rob >>>>>>> >>>>>>>> >>>>>>>> On Thu, Mar 15, 2012 at 1:33 PM, Rob Crittenden >>>>>>>> ?wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Jimmy wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Restarted IPA and now the interface loads, but resubmitting the >>>>>>>>>> cert >>>>>>>>>> has this result - >>>>>>>>>> >>>>>>>>>> ipa-getcert resubmit -i 20110913154233 >>>>>>>>>> 192.168.201.102 - - [10/Mar/2012:20:53:13 +0000] "POST /ipa/xml >>>>>>>>>> HTTP/1.1" 401 1775 >>>>>>>>>> 192.168.201.102 - host/abc-ipa.abc.xyz at ABC.XYZ >>>>>>>>>> [10/Mar/2012:20:53:13 >>>>>>>>>> +0000] "POST /ipa/xml HTTP/1.1" 200 314 >>>>>>>>>> >>>>>>>>>> but the cert still shows these dates- >>>>>>>>>> >>>>>>>>>> ?Not Before: Tue Sep 13 15:43:37 2011 >>>>>>>>>> ? ? ? ? ? ? Not After : Sun Mar 11 15:43:37 2012 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> The error log will contain more interesting information. >>>>>>>>> >>>>>>>>> What does the status show in the output of ipa-getcert list? >>>>>>>>> >>>>>>>>> rob >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Thu, Mar 15, 2012 at 1:06 PM, Jimmy >>>>>>>>>> ?wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I can now start the upgraded IPA, but now going to the IPA admin >>>>>>>>>>> page >>>>>>>>>>> I get this: >>>>>>>>>>> >>>>>>>>>>> ==== >>>>>>>>>>> >>>>>>>>>>> Not Found >>>>>>>>>>> >>>>>>>>>>> The requested URL /ipa was not found on this server. >>>>>>>>>>> >>>>>>>>>>> ==== >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Freeipa-users mailing list >>>>>>>>>> Freeipa-users at redhat.com >>>>>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>> > From rcritten at redhat.com Fri Mar 16 15:08:11 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 16 Mar 2012 11:08:11 -0400 Subject: [Freeipa-users] (no subject) In-Reply-To: References: <4F6114A5.3090507@redhat.com> <4F612BBB.3070404@redhat.com> <4F622801.10600@redhat.com> <4F622FC9.8040003@redhat.com> <4F624162.7020806@redhat.com> <4F62554F.1030804@redhat.com> <4F626135.3030402@redhat.com> Message-ID: <4F63575B.6090805@redhat.com> Jimmy wrote: > I didn't see a catalina.log on my system, but there is a catalina.out: > > http://fpaste.org/KgJn/ That's the one. Looks like the CA isn't starting. Does /var/lib/pki-ca/logs/signedAudit/ca_audit exist? If so, what is the SELinux context (ls -lZ)? rob > > -J > > On Thu, Mar 15, 2012 at 5:37 PM, Rob Crittenden wrote: >> Jimmy wrote: >>> >>> error log: http://fpaste.org/efyf/ >>> >>> CA debug: http://fpaste.org/LemM/ >>> >>> CA localhost log: http://fpaste.org/q4MU/ >>> >>> That's all I can find the correspond to the time I ran the getcert. >> >> >> I'd look at the catalina.log, is dogtag coming up ok? >> >> rob >> >> >>> >>> Jimmy >>> On Thu, Mar 15, 2012 at 4:47 PM, Rob Crittenden >>> wrote: >>>> >>>> Jimmy wrote: >>>>> >>>>> >>>>> Still shows status: CA_UNREACHABLE >>>>> >>>>> http://fpaste.org/UrTJ/ >>>> >>>> >>>> >>>> If there was an Internal Server Error there should be an error in the >>>> Apache >>>> error log or something in the CA debug/transaction log (or both). Can you >>>> check those? >>>> >>>> rob >>>> >>>>> >>>>> On Thu, Mar 15, 2012 at 3:22 PM, Rob Crittenden >>>>> wrote: >>>>>> >>>>>> >>>>>> Jimmy wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> I used yum to upgrade cert monger now the access_log has nothing new >>>>>>> when I run the ipa-getcert, but error_log shows this: >>>>>>> >>>>>>> [Sat Mar 10 21:47:21 2012] [error] ipa: INFO: sslget >>>>>>> 'https://xyz-ipa.abc.xyz:443/ca/agent/ca/displayBySerial' >>>>>>> [Sat Mar 10 21:47:21 2012] [error] ipa: INFO: >>>>>>> host/xyz-ipa.abc.xyz at ABC.XYZ: >>>>>>> >>>>>>> >>>>>>> >>>>>>> cert_request(u'MIIDQzCCAisCAQAwLDEQMA4GA1UEChMHUERILkNTUDEYMBYGA1UEAxMPY3NwLWlkbS5wZGguY3NwMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr0EHCdyTuteryFZ2bdEl+V4OATR/xk8ELthmvlwT/5qubZKwlCWS6yLawgdyCg9Yw737A7qGe0BPxHv6E+as10NxppEPsn9BOi+TPRIMYNMNNYmO2sce2pvkMkVBqsF7Gn7mF7e5+Bpc7ApnDGP7WLsAjbso8EvLUrqVMTNyiziCSHiNk+/Fi1Om6K5GKzKkqfEDex0RK+kpMswgcaZHhmW3i+y3UxFZsJjOg3R4fJAfC0+My2d1Vx4052+EgWAbSNpSj7zmLGM2+dkmgMo5Li7jjgJe8VsrqOV4L5IgqtGVJ0EOb7EP7gynbVoa74m4XrVwEP8rd/M5RxAnD1JPuwIDAQABoIHRMBoGCSqGSIb3DQEJFDENEwtTZXJ2ZXItQ2VydDCBsgYJKoZIhvcNAQkOMYGkMIGhMA4GA1UdDwEBAAQEAwIE8DB3BgNVHREBAQAEbTBroCwGCisGAQQBgjcUAgOgHgwcbGRhcC9jc3AtaWRtLnBkaC5jc3BAUERILkNTUKA7BgYrBgEFAgKgMTAvoAkbB1BESC5DU1ChIjAgoAMCAQGhGTAXGwRsZGFwGw9jc3AtaWRtLnBkaC5jc3AwFgYDVR0lAQEABAwwCgYIKwYBBQUHAwEwDQYJKoZIhvcNAQELBQADggEBABD/Hwbgf5NJNUYt0+ntMDHiilMFkSaO6ryQ36/pCH1oR+vI+PCeClHewPo0v99h4Z8W8L7CQtDdNBUMl/JVHH5Lz7cBF8A/jXZQ+naV17EEuXncacM8AvYh5dL2yih+8RpPalEmSgz5rijtbSigfNGrZn0Mh3qOW1kbsz+GDaaT9wLFxvdJyqgdKds2tsp 0K >> >> zH >>>> >>>> >>>> IM >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> cJuw3cwOfH8zrBRV28XYhMLm0OOhj92uxgax5UPY2VyHP5UOtOnfuduU1ZXa+o8QIXqX7/HyDSCLGwiPJscAsp9cRzjn4KvqzZDOcdGEjXmCGfrmUiMcuzVyTDR2SdAWrHdbRmXeyVxmiBPzdk=', >>>>>>> >>>>>>> >>>>>>> >>>>>>> principal=u'ldap/xyz-ipa.abc.xyz at ABC.XYZ', add=True): >>>>>>> CertificateOperationError >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> What does ipa-getcert list show? >>>>>> >>>>>> You may now have something in the CA logs too. >>>>>> >>>>>> >>>>>> rob >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Mar 15, 2012 at 2:07 PM, Rob Crittenden >>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Jimmy wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Which error log? the pki-ca error log has nothing and the httpd >>>>>>>>> error >>>>>>>>> log has nothing, and the httpd access log has this: (yes, the dates >>>>>>>>> are set back a few days, bc the current cert expires on 3/11) >>>>>>>>> >>>>>>>>> 192.168.201.102 - - [10/Mar/2012:21:27:24 +0000] "POST /ipa/xml >>>>>>>>> HTTP/1.1" 401 1775 >>>>>>>>> 192.168.201.102 - host/abc-ipa.abc.xyz at ABC.XYZ [10/Mar/2012:21:27:25 >>>>>>>>> +0000] "POST /ipa/xml HTTP/1.1" 200 314 >>>>>>>>> >>>>>>>>> here is the ipa-getcert list: >>>>>>>>> >>>>>>>>> http://fpaste.org/Dzr3/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> You need to update certmonger, it isn't setting a Referer HTTP header >>>>>>>> in >>>>>>>> its >>>>>>>> request. That is now required by IPA. >>>>>>>> >>>>>>>> >>>>>>>> rob >>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Mar 15, 2012 at 1:33 PM, Rob Crittenden >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Jimmy wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Restarted IPA and now the interface loads, but resubmitting the >>>>>>>>>>> cert >>>>>>>>>>> has this result - >>>>>>>>>>> >>>>>>>>>>> ipa-getcert resubmit -i 20110913154233 >>>>>>>>>>> 192.168.201.102 - - [10/Mar/2012:20:53:13 +0000] "POST /ipa/xml >>>>>>>>>>> HTTP/1.1" 401 1775 >>>>>>>>>>> 192.168.201.102 - host/abc-ipa.abc.xyz at ABC.XYZ >>>>>>>>>>> [10/Mar/2012:20:53:13 >>>>>>>>>>> +0000] "POST /ipa/xml HTTP/1.1" 200 314 >>>>>>>>>>> >>>>>>>>>>> but the cert still shows these dates- >>>>>>>>>>> >>>>>>>>>>> Not Before: Tue Sep 13 15:43:37 2011 >>>>>>>>>>> Not After : Sun Mar 11 15:43:37 2012 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The error log will contain more interesting information. >>>>>>>>>> >>>>>>>>>> What does the status show in the output of ipa-getcert list? >>>>>>>>>> >>>>>>>>>> rob >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Thu, Mar 15, 2012 at 1:06 PM, Jimmy >>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I can now start the upgraded IPA, but now going to the IPA admin >>>>>>>>>>>> page >>>>>>>>>>>> I get this: >>>>>>>>>>>> >>>>>>>>>>>> ==== >>>>>>>>>>>> >>>>>>>>>>>> Not Found >>>>>>>>>>>> >>>>>>>>>>>> The requested URL /ipa was not found on this server. >>>>>>>>>>>> >>>>>>>>>>>> ==== >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Freeipa-users mailing list >>>>>>>>>>> Freeipa-users at redhat.com >>>>>>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>>> >> From g17jimmy at gmail.com Fri Mar 16 15:55:59 2012 From: g17jimmy at gmail.com (Jimmy) Date: Fri, 16 Mar 2012 11:55:59 -0400 Subject: [Freeipa-users] (no subject) In-Reply-To: <4F63575B.6090805@redhat.com> References: <4F6114A5.3090507@redhat.com> <4F612BBB.3070404@redhat.com> <4F622801.10600@redhat.com> <4F622FC9.8040003@redhat.com> <4F624162.7020806@redhat.com> <4F62554F.1030804@redhat.com> <4F626135.3030402@redhat.com> <4F63575B.6090805@redhat.com> Message-ID: The signedAudit directory had gotten moved by accident when I was cleaning up the log dir to make the logs easier to read. I moved it back to the right place and now I have a lot more logs. I'll sanitize the logs and paste them up. On Fri, Mar 16, 2012 at 11:08 AM, Rob Crittenden wrote: > Jimmy wrote: >> >> I didn't see a catalina.log on my system, but there is a catalina.out: >> >> http://fpaste.org/KgJn/ > > > That's the one. Looks like the CA isn't starting. > > Does /var/lib/pki-ca/logs/signedAudit/ca_audit exist? If so, what is the > SELinux context (ls -lZ)? > > rob > >> >> -J >> >> On Thu, Mar 15, 2012 at 5:37 PM, Rob Crittenden >> ?wrote: >>> >>> Jimmy wrote: >>>> >>>> >>>> error log: http://fpaste.org/efyf/ >>>> >>>> CA debug: http://fpaste.org/LemM/ >>>> >>>> CA localhost log: http://fpaste.org/q4MU/ >>>> >>>> That's all I can find the correspond to the time I ran the getcert. >>> >>> >>> >>> I'd look at the catalina.log, is dogtag coming up ok? >>> >>> rob >>> >>> >>>> >>>> Jimmy >>>> On Thu, Mar 15, 2012 at 4:47 PM, Rob Crittenden >>>> ?wrote: >>>>> >>>>> >>>>> Jimmy wrote: >>>>>> >>>>>> >>>>>> >>>>>> Still shows status: CA_UNREACHABLE >>>>>> >>>>>> http://fpaste.org/UrTJ/ >>>>> >>>>> >>>>> >>>>> >>>>> If there was an Internal Server Error there should be an error in the >>>>> Apache >>>>> error log or something in the CA debug/transaction log (or both). Can >>>>> you >>>>> check those? >>>>> >>>>> rob >>>>> >>>>>> >>>>>> On Thu, Mar 15, 2012 at 3:22 PM, Rob Crittenden >>>>>> ?wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> Jimmy wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I used yum to upgrade cert monger now the access_log has nothing new >>>>>>>> when I run the ipa-getcert, but error_log shows this: >>>>>>>> >>>>>>>> [Sat Mar 10 21:47:21 2012] [error] ipa: INFO: sslget >>>>>>>> 'https://xyz-ipa.abc.xyz:443/ca/agent/ca/displayBySerial' >>>>>>>> [Sat Mar 10 21:47:21 2012] [error] ipa: INFO: >>>>>>>> host/xyz-ipa.abc.xyz at ABC.XYZ: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> cert_request(u'MIIDQzCCAisCAQAwLDEQMA4GA1UEChMHUERILkNTUDEYMBYGA1UEAxMPY3NwLWlkbS5wZGguY3NwMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr0EHCdyTuteryFZ2bdEl+V4OATR/xk8ELthmvlwT/5qubZKwlCWS6yLawgdyCg9Yw737A7qGe0BPxHv6E+as10NxppEPsn9BOi+TPRIMYNMNNYmO2sce2pvkMkVBqsF7Gn7mF7e5+Bpc7ApnDGP7WLsAjbso8EvLUrqVMTNyiziCSHiNk+/Fi1Om6K5GKzKkqfEDex0RK+kpMswgcaZHhmW3i+y3UxFZsJjOg3R4fJAfC0+My2d1Vx4052+EgWAbSNpSj7zmLGM2+dkmgMo5Li7jjgJe8VsrqOV4L5IgqtGVJ0EOb7EP7gynbVoa74m4XrVwEP8rd/M5RxAnD1JPuwIDAQABoIHRMBoGCSqGSIb3DQEJFDENEwtTZXJ2ZXItQ2VydDCBsgYJKoZIhvcNAQkOMYGkMIGhMA4GA1UdDwEBAAQEAwIE8DB3BgNVHREBAQAEbTBroCwGCisGAQQBgjcUAgOgHgwcbGRhcC9jc3AtaWRtLnBkaC5jc3BAUERILkNTUKA7BgYrBgEFAgKgMTAvoAkbB1BESC5DU1ChIjAgoAMCAQGhGTAXGwRsZGFwGw9jc3AtaWRtLnBkaC5jc3AwFgYDVR0lAQEABAwwCgYIKwYBBQUHAwEwDQYJKoZIhvcNAQELBQADggEBABD/Hwbgf5NJNUYt0+ntMDHiilMFkSaO6ryQ36/pCH1oR+vI+PCeClHewPo0v99h4Z8W8L7CQtDdNBUMl/JVHH5Lz7cBF8A/jXZQ+naV17EEuXncacM8AvYh5dL2yih+8RpPalEmSgz5rijtbSigfNGrZn0Mh3qOW1kbsz+GDaaT9wLFxvdJyqgdKds2tsp > > 0K >>> >>> >>> zH >>>>> >>>>> >>>>> >>>>> IM >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> cJuw3cwOfH8zrBRV28XYhMLm0OOhj92uxgax5UPY2VyHP5UOtOnfuduU1ZXa+o8QIXqX7/HyDSCLGwiPJscAsp9cRzjn4KvqzZDOcdGEjXmCGfrmUiMcuzVyTDR2SdAWrHdbRmXeyVxmiBPzdk=', >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> principal=u'ldap/xyz-ipa.abc.xyz at ABC.XYZ', add=True): >>>>>>>> CertificateOperationError >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> What does ipa-getcert list show? >>>>>>> >>>>>>> You may now have something in the CA logs too. >>>>>>> >>>>>>> >>>>>>> rob >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Mar 15, 2012 at 2:07 PM, Rob Crittenden >>>>>>>> ?wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Jimmy wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Which error log? the pki-ca error log has nothing and the httpd >>>>>>>>>> error >>>>>>>>>> log has nothing, and the httpd access log has this: (yes, the >>>>>>>>>> dates >>>>>>>>>> are set back a few days, bc the current cert expires on 3/11) >>>>>>>>>> >>>>>>>>>> 192.168.201.102 - - [10/Mar/2012:21:27:24 +0000] "POST /ipa/xml >>>>>>>>>> HTTP/1.1" 401 1775 >>>>>>>>>> 192.168.201.102 - host/abc-ipa.abc.xyz at ABC.XYZ >>>>>>>>>> [10/Mar/2012:21:27:25 >>>>>>>>>> +0000] "POST /ipa/xml HTTP/1.1" 200 314 >>>>>>>>>> >>>>>>>>>> here is the ipa-getcert list: >>>>>>>>>> >>>>>>>>>> http://fpaste.org/Dzr3/ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> You need to update certmonger, it isn't setting a Referer HTTP >>>>>>>>> header >>>>>>>>> in >>>>>>>>> its >>>>>>>>> request. That is now required by IPA. >>>>>>>>> >>>>>>>>> >>>>>>>>> rob >>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Thu, Mar 15, 2012 at 1:33 PM, Rob >>>>>>>>>> Crittenden >>>>>>>>>> ?wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Jimmy wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Restarted IPA and now the interface loads, but resubmitting the >>>>>>>>>>>> cert >>>>>>>>>>>> has this result - >>>>>>>>>>>> >>>>>>>>>>>> ipa-getcert resubmit -i 20110913154233 >>>>>>>>>>>> 192.168.201.102 - - [10/Mar/2012:20:53:13 +0000] "POST /ipa/xml >>>>>>>>>>>> HTTP/1.1" 401 1775 >>>>>>>>>>>> 192.168.201.102 - host/abc-ipa.abc.xyz at ABC.XYZ >>>>>>>>>>>> [10/Mar/2012:20:53:13 >>>>>>>>>>>> +0000] "POST /ipa/xml HTTP/1.1" 200 314 >>>>>>>>>>>> >>>>>>>>>>>> but the cert still shows these dates- >>>>>>>>>>>> >>>>>>>>>>>> ?Not Before: Tue Sep 13 15:43:37 2011 >>>>>>>>>>>> ? ? ? ? ? ? Not After : Sun Mar 11 15:43:37 2012 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The error log will contain more interesting information. >>>>>>>>>>> >>>>>>>>>>> What does the status show in the output of ipa-getcert list? >>>>>>>>>>> >>>>>>>>>>> rob >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Mar 15, 2012 at 1:06 PM, Jimmy >>>>>>>>>>>> ?wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> I can now start the upgraded IPA, but now going to the IPA >>>>>>>>>>>>> admin >>>>>>>>>>>>> page >>>>>>>>>>>>> I get this: >>>>>>>>>>>>> >>>>>>>>>>>>> ==== >>>>>>>>>>>>> >>>>>>>>>>>>> Not Found >>>>>>>>>>>>> >>>>>>>>>>>>> The requested URL /ipa was not found on this server. >>>>>>>>>>>>> >>>>>>>>>>>>> ==== >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Freeipa-users mailing list >>>>>>>>>>>> Freeipa-users at redhat.com >>>>>>>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>> > From g17jimmy at gmail.com Fri Mar 16 16:15:29 2012 From: g17jimmy at gmail.com (Jimmy) Date: Fri, 16 Mar 2012 12:15:29 -0400 Subject: [Freeipa-users] (no subject) In-Reply-To: <4F63575B.6090805@redhat.com> References: <4F6114A5.3090507@redhat.com> <4F612BBB.3070404@redhat.com> <4F622801.10600@redhat.com> <4F622FC9.8040003@redhat.com> <4F624162.7020806@redhat.com> <4F62554F.1030804@redhat.com> <4F626135.3030402@redhat.com> <4F63575B.6090805@redhat.com> Message-ID: Here are the latest logs and info. Thanks. Jimmy ipagetcert list output- http://fpaste.org/OAra/ pki-ca system log -- http://fpaste.org/Uomy/ catalina.out -- http://fpaste.org/5MR1/ selftests -- http://fpaste.org/CwDF/ debug -- http://fpaste.org/Wy0o/ On Fri, Mar 16, 2012 at 11:08 AM, Rob Crittenden wrote: > Jimmy wrote: >> >> I didn't see a catalina.log on my system, but there is a catalina.out: >> >> http://fpaste.org/KgJn/ > > > That's the one. Looks like the CA isn't starting. > > Does /var/lib/pki-ca/logs/signedAudit/ca_audit exist? If so, what is the > SELinux context (ls -lZ)? > > rob > >> >> -J >> >> On Thu, Mar 15, 2012 at 5:37 PM, Rob Crittenden >> ?wrote: >>> >>> Jimmy wrote: >>>> >>>> >>>> error log: http://fpaste.org/efyf/ >>>> >>>> CA debug: http://fpaste.org/LemM/ >>>> >>>> CA localhost log: http://fpaste.org/q4MU/ >>>> >>>> That's all I can find the correspond to the time I ran the getcert. >>> >>> >>> >>> I'd look at the catalina.log, is dogtag coming up ok? >>> >>> rob >>> >>> >>>> >>>> Jimmy >>>> On Thu, Mar 15, 2012 at 4:47 PM, Rob Crittenden >>>> ?wrote: >>>>> >>>>> >>>>> Jimmy wrote: >>>>>> >>>>>> >>>>>> >>>>>> Still shows status: CA_UNREACHABLE >>>>>> >>>>>> http://fpaste.org/UrTJ/ >>>>> >>>>> >>>>> >>>>> >>>>> If there was an Internal Server Error there should be an error in the >>>>> Apache >>>>> error log or something in the CA debug/transaction log (or both). Can >>>>> you >>>>> check those? >>>>> >>>>> rob >>>>> >>>>>> >>>>>> On Thu, Mar 15, 2012 at 3:22 PM, Rob Crittenden >>>>>> ?wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> Jimmy wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I used yum to upgrade cert monger now the access_log has nothing new >>>>>>>> when I run the ipa-getcert, but error_log shows this: >>>>>>>> >>>>>>>> [Sat Mar 10 21:47:21 2012] [error] ipa: INFO: sslget >>>>>>>> 'https://xyz-ipa.abc.xyz:443/ca/agent/ca/displayBySerial' >>>>>>>> [Sat Mar 10 21:47:21 2012] [error] ipa: INFO: >>>>>>>> host/xyz-ipa.abc.xyz at ABC.XYZ: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> cert_request(u'MIIDQzCCAisCAQAwLDEQMA4GA1UEChMHUERILkNTUDEYMBYGA1UEAxMPY3NwLWlkbS5wZGguY3NwMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr0EHCdyTuteryFZ2bdEl+V4OATR/xk8ELthmvlwT/5qubZKwlCWS6yLawgdyCg9Yw737A7qGe0BPxHv6E+as10NxppEPsn9BOi+TPRIMYNMNNYmO2sce2pvkMkVBqsF7Gn7mF7e5+Bpc7ApnDGP7WLsAjbso8EvLUrqVMTNyiziCSHiNk+/Fi1Om6K5GKzKkqfEDex0RK+kpMswgcaZHhmW3i+y3UxFZsJjOg3R4fJAfC0+My2d1Vx4052+EgWAbSNpSj7zmLGM2+dkmgMo5Li7jjgJe8VsrqOV4L5IgqtGVJ0EOb7EP7gynbVoa74m4XrVwEP8rd/M5RxAnD1JPuwIDAQABoIHRMBoGCSqGSIb3DQEJFDENEwtTZXJ2ZXItQ2VydDCBsgYJKoZIhvcNAQkOMYGkMIGhMA4GA1UdDwEBAAQEAwIE8DB3BgNVHREBAQAEbTBroCwGCisGAQQBgjcUAgOgHgwcbGRhcC9jc3AtaWRtLnBkaC5jc3BAUERILkNTUKA7BgYrBgEFAgKgMTAvoAkbB1BESC5DU1ChIjAgoAMCAQGhGTAXGwRsZGFwGw9jc3AtaWRtLnBkaC5jc3AwFgYDVR0lAQEABAwwCgYIKwYBBQUHAwEwDQYJKoZIhvcNAQELBQADggEBABD/Hwbgf5NJNUYt0+ntMDHiilMFkSaO6ryQ36/pCH1oR+vI+PCeClHewPo0v99h4Z8W8L7CQtDdNBUMl/JVHH5Lz7cBF8A/jXZQ+naV17EEuXncacM8AvYh5dL2yih+8RpPalEmSgz5rijtbSigfNGrZn0Mh3qOW1kbsz+GDaaT9wLFxvdJyqgdKds2tsp > > 0K >>> >>> >>> zH >>>>> >>>>> >>>>> >>>>> IM >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> cJuw3cwOfH8zrBRV28XYhMLm0OOhj92uxgax5UPY2VyHP5UOtOnfuduU1ZXa+o8QIXqX7/HyDSCLGwiPJscAsp9cRzjn4KvqzZDOcdGEjXmCGfrmUiMcuzVyTDR2SdAWrHdbRmXeyVxmiBPzdk=', >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> principal=u'ldap/xyz-ipa.abc.xyz at ABC.XYZ', add=True): >>>>>>>> CertificateOperationError >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> What does ipa-getcert list show? >>>>>>> >>>>>>> You may now have something in the CA logs too. >>>>>>> >>>>>>> >>>>>>> rob >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Mar 15, 2012 at 2:07 PM, Rob Crittenden >>>>>>>> ?wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Jimmy wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Which error log? the pki-ca error log has nothing and the httpd >>>>>>>>>> error >>>>>>>>>> log has nothing, and the httpd access log has this: (yes, the >>>>>>>>>> dates >>>>>>>>>> are set back a few days, bc the current cert expires on 3/11) >>>>>>>>>> >>>>>>>>>> 192.168.201.102 - - [10/Mar/2012:21:27:24 +0000] "POST /ipa/xml >>>>>>>>>> HTTP/1.1" 401 1775 >>>>>>>>>> 192.168.201.102 - host/abc-ipa.abc.xyz at ABC.XYZ >>>>>>>>>> [10/Mar/2012:21:27:25 >>>>>>>>>> +0000] "POST /ipa/xml HTTP/1.1" 200 314 >>>>>>>>>> >>>>>>>>>> here is the ipa-getcert list: >>>>>>>>>> >>>>>>>>>> http://fpaste.org/Dzr3/ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> You need to update certmonger, it isn't setting a Referer HTTP >>>>>>>>> header >>>>>>>>> in >>>>>>>>> its >>>>>>>>> request. That is now required by IPA. >>>>>>>>> >>>>>>>>> >>>>>>>>> rob >>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Thu, Mar 15, 2012 at 1:33 PM, Rob >>>>>>>>>> Crittenden >>>>>>>>>> ?wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Jimmy wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Restarted IPA and now the interface loads, but resubmitting the >>>>>>>>>>>> cert >>>>>>>>>>>> has this result - >>>>>>>>>>>> >>>>>>>>>>>> ipa-getcert resubmit -i 20110913154233 >>>>>>>>>>>> 192.168.201.102 - - [10/Mar/2012:20:53:13 +0000] "POST /ipa/xml >>>>>>>>>>>> HTTP/1.1" 401 1775 >>>>>>>>>>>> 192.168.201.102 - host/abc-ipa.abc.xyz at ABC.XYZ >>>>>>>>>>>> [10/Mar/2012:20:53:13 >>>>>>>>>>>> +0000] "POST /ipa/xml HTTP/1.1" 200 314 >>>>>>>>>>>> >>>>>>>>>>>> but the cert still shows these dates- >>>>>>>>>>>> >>>>>>>>>>>> ?Not Before: Tue Sep 13 15:43:37 2011 >>>>>>>>>>>> ? ? ? ? ? ? Not After : Sun Mar 11 15:43:37 2012 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The error log will contain more interesting information. >>>>>>>>>>> >>>>>>>>>>> What does the status show in the output of ipa-getcert list? >>>>>>>>>>> >>>>>>>>>>> rob >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Mar 15, 2012 at 1:06 PM, Jimmy >>>>>>>>>>>> ?wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> I can now start the upgraded IPA, but now going to the IPA >>>>>>>>>>>>> admin >>>>>>>>>>>>> page >>>>>>>>>>>>> I get this: >>>>>>>>>>>>> >>>>>>>>>>>>> ==== >>>>>>>>>>>>> >>>>>>>>>>>>> Not Found >>>>>>>>>>>>> >>>>>>>>>>>>> The requested URL /ipa was not found on this server. >>>>>>>>>>>>> >>>>>>>>>>>>> ==== >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Freeipa-users mailing list >>>>>>>>>>>> Freeipa-users at redhat.com >>>>>>>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>> > From rcritten at redhat.com Fri Mar 16 16:51:06 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 16 Mar 2012 12:51:06 -0400 Subject: [Freeipa-users] (no subject) In-Reply-To: References: <4F622801.10600@redhat.com> <4F622FC9.8040003@redhat.com> <4F624162.7020806@redhat.com> <4F62554F.1030804@redhat.com> <4F626135.3030402@redhat.com> <4F63575B.6090805@redhat.com> Message-ID: <4F636F7A.4060109@redhat.com> Jimmy wrote: > Here are the latest logs and info. Thanks. Jimmy What did you change to fix the ca_audit problem? There are two problems that I can see: 1. certmonger is failing because of SSL trust issues. Have you changed the NSS database(s) recently for Apache or 389-ds, or /etc/pki/nssdb? 2. Looks like there is some corruption in the dogtag LDAP instance based on all the entries not found. rob > > ipagetcert list output- http://fpaste.org/OAra/ > > pki-ca system log -- http://fpaste.org/Uomy/ > catalina.out -- http://fpaste.org/5MR1/ > selftests -- http://fpaste.org/CwDF/ > debug -- http://fpaste.org/Wy0o/ > > On Fri, Mar 16, 2012 at 11:08 AM, Rob Crittenden wrote: >> Jimmy wrote: >>> >>> I didn't see a catalina.log on my system, but there is a catalina.out: >>> >>> http://fpaste.org/KgJn/ >> >> >> That's the one. Looks like the CA isn't starting. >> >> Does /var/lib/pki-ca/logs/signedAudit/ca_audit exist? If so, what is the >> SELinux context (ls -lZ)? >> >> rob >> >>> >>> -J >>> >>> On Thu, Mar 15, 2012 at 5:37 PM, Rob Crittenden >>> wrote: >>>> >>>> Jimmy wrote: >>>>> >>>>> >>>>> error log: http://fpaste.org/efyf/ >>>>> >>>>> CA debug: http://fpaste.org/LemM/ >>>>> >>>>> CA localhost log: http://fpaste.org/q4MU/ >>>>> >>>>> That's all I can find the correspond to the time I ran the getcert. >>>> >>>> >>>> >>>> I'd look at the catalina.log, is dogtag coming up ok? >>>> >>>> rob >>>> >>>> >>>>> >>>>> Jimmy >>>>> On Thu, Mar 15, 2012 at 4:47 PM, Rob Crittenden >>>>> wrote: >>>>>> >>>>>> >>>>>> Jimmy wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> Still shows status: CA_UNREACHABLE >>>>>>> >>>>>>> http://fpaste.org/UrTJ/ >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> If there was an Internal Server Error there should be an error in the >>>>>> Apache >>>>>> error log or something in the CA debug/transaction log (or both). Can >>>>>> you >>>>>> check those? >>>>>> >>>>>> rob >>>>>> >>>>>>> >>>>>>> On Thu, Mar 15, 2012 at 3:22 PM, Rob Crittenden >>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Jimmy wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I used yum to upgrade cert monger now the access_log has nothing new >>>>>>>>> when I run the ipa-getcert, but error_log shows this: >>>>>>>>> >>>>>>>>> [Sat Mar 10 21:47:21 2012] [error] ipa: INFO: sslget >>>>>>>>> 'https://xyz-ipa.abc.xyz:443/ca/agent/ca/displayBySerial' >>>>>>>>> [Sat Mar 10 21:47:21 2012] [error] ipa: INFO: >>>>>>>>> host/xyz-ipa.abc.xyz at ABC.XYZ: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> cert_request(u'MIIDQzCCAisCAQAwLDEQMA4GA1UEChMHUERILkNTUDEYMBYGA1UEAxMPY3NwLWlkbS5wZGguY3NwMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr0EHCdyTuteryFZ2bdEl+V4OATR/xk8ELthmvlwT/5qubZKwlCWS6yLawgdyCg9Yw737A7qGe0BPxHv6E+as10NxppEPsn9BOi+TPRIMYNMNNYmO2sce2pvkMkVBqsF7Gn7mF7e5+Bpc7ApnDGP7WLsAjbso8EvLUrqVMTNyiziCSHiNk+/Fi1Om6K5GKzKkqfEDex0RK+kpMswgcaZHhmW3i+y3UxFZsJjOg3R4fJAfC0+My2d1Vx4052+EgWAbSNpSj7zmLGM2+dkmgMo5Li7jjgJe8VsrqOV4L5IgqtGVJ0EOb7EP7gynbVoa74m4XrVwEP8rd/M5RxAnD1JPuwIDAQABoIHRMBoGCSqGSIb3DQEJFDENEwtTZXJ2ZXItQ2VydDCBsgYJKoZIhvcNAQkOMYGkMIGhMA4GA1UdDwEBAAQEAwIE8DB3BgNVHREBAQAEbTBroCwGCisGAQQBgjcUAgOgHgwcbGRhcC9jc3AtaWRtLnBkaC5jc3BAUERILkNTUKA7BgYrBgEFAgKgMTAvoAkbB1BESC5DU1ChIjAgoAMCAQGhGTAXGwRsZGFwGw9jc3AtaWRtLnBkaC5jc3AwFgYDVR0lAQEABAwwCgYIKwYBBQUHAwEwDQYJKoZIhvcNAQELBQADggEBABD/Hwbgf5NJNUYt0+ntMDHiilMFkSaO6ryQ36/pCH1oR+vI+PCeClHewPo0v99h4Z8W8L7CQtDdNBUMl/JVHH5Lz7cBF8A/jXZQ+naV17EEuXncacM8AvYh5dL2yih+8RpPalEmSgz5rijtbSigfNGrZn0Mh3qOW1kbsz+GDaaT9wLFxvdJyqgdKds2t sp >> >> 0K >>>> >>>> >>>> zH >>>>>> >>>>>> >>>>>> >>>>>> IM >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> cJuw3cwOfH8zrBRV28XYhMLm0OOhj92uxgax5UPY2VyHP5UOtOnfuduU1ZXa+o8QIXqX7/HyDSCLGwiPJscAsp9cRzjn4KvqzZDOcdGEjXmCGfrmUiMcuzVyTDR2SdAWrHdbRmXeyVxmiBPzdk=', >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> principal=u'ldap/xyz-ipa.abc.xyz at ABC.XYZ', add=True): >>>>>>>>> CertificateOperationError >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> What does ipa-getcert list show? >>>>>>>> >>>>>>>> You may now have something in the CA logs too. >>>>>>>> >>>>>>>> >>>>>>>> rob >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Mar 15, 2012 at 2:07 PM, Rob Crittenden >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Jimmy wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Which error log? the pki-ca error log has nothing and the httpd >>>>>>>>>>> error >>>>>>>>>>> log has nothing, and the httpd access log has this: (yes, the >>>>>>>>>>> dates >>>>>>>>>>> are set back a few days, bc the current cert expires on 3/11) >>>>>>>>>>> >>>>>>>>>>> 192.168.201.102 - - [10/Mar/2012:21:27:24 +0000] "POST /ipa/xml >>>>>>>>>>> HTTP/1.1" 401 1775 >>>>>>>>>>> 192.168.201.102 - host/abc-ipa.abc.xyz at ABC.XYZ >>>>>>>>>>> [10/Mar/2012:21:27:25 >>>>>>>>>>> +0000] "POST /ipa/xml HTTP/1.1" 200 314 >>>>>>>>>>> >>>>>>>>>>> here is the ipa-getcert list: >>>>>>>>>>> >>>>>>>>>>> http://fpaste.org/Dzr3/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> You need to update certmonger, it isn't setting a Referer HTTP >>>>>>>>>> header >>>>>>>>>> in >>>>>>>>>> its >>>>>>>>>> request. That is now required by IPA. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> rob >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Thu, Mar 15, 2012 at 1:33 PM, Rob >>>>>>>>>>> Crittenden >>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Jimmy wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Restarted IPA and now the interface loads, but resubmitting the >>>>>>>>>>>>> cert >>>>>>>>>>>>> has this result - >>>>>>>>>>>>> >>>>>>>>>>>>> ipa-getcert resubmit -i 20110913154233 >>>>>>>>>>>>> 192.168.201.102 - - [10/Mar/2012:20:53:13 +0000] "POST /ipa/xml >>>>>>>>>>>>> HTTP/1.1" 401 1775 >>>>>>>>>>>>> 192.168.201.102 - host/abc-ipa.abc.xyz at ABC.XYZ >>>>>>>>>>>>> [10/Mar/2012:20:53:13 >>>>>>>>>>>>> +0000] "POST /ipa/xml HTTP/1.1" 200 314 >>>>>>>>>>>>> >>>>>>>>>>>>> but the cert still shows these dates- >>>>>>>>>>>>> >>>>>>>>>>>>> Not Before: Tue Sep 13 15:43:37 2011 >>>>>>>>>>>>> Not After : Sun Mar 11 15:43:37 2012 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> The error log will contain more interesting information. >>>>>>>>>>>> >>>>>>>>>>>> What does the status show in the output of ipa-getcert list? >>>>>>>>>>>> >>>>>>>>>>>> rob >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Thu, Mar 15, 2012 at 1:06 PM, Jimmy >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> I can now start the upgraded IPA, but now going to the IPA >>>>>>>>>>>>>> admin >>>>>>>>>>>>>> page >>>>>>>>>>>>>> I get this: >>>>>>>>>>>>>> >>>>>>>>>>>>>> ==== >>>>>>>>>>>>>> >>>>>>>>>>>>>> Not Found >>>>>>>>>>>>>> >>>>>>>>>>>>>> The requested URL /ipa was not found on this server. >>>>>>>>>>>>>> >>>>>>>>>>>>>> ==== >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> Freeipa-users mailing list >>>>>>>>>>>>> Freeipa-users at redhat.com >>>>>>>>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>>> >> From g17jimmy at gmail.com Fri Mar 16 17:07:28 2012 From: g17jimmy at gmail.com (Jimmy) Date: Fri, 16 Mar 2012 13:07:28 -0400 Subject: [Freeipa-users] (no subject) In-Reply-To: References: <4F6114A5.3090507@redhat.com> <4F612BBB.3070404@redhat.com> <4F622801.10600@redhat.com> <4F622FC9.8040003@redhat.com> <4F624162.7020806@redhat.com> <4F62554F.1030804@redhat.com> <4F626135.3030402@redhat.com> <4F63575B.6090805@redhat.com> Message-ID: When I try `ipa-getcert resubmit -i 20110913154233` I see this in the CA logs: localhost.2012-03-08.log--- Mar 8, 2012 1:54:34 AM org.apache.catalina.core.ApplicationContext log INFO: caDisplayBySerial-agent: Invalid Credential. debug--- [08/Mar/2012:01:54:34][TP-Processor3]: In LdapBoundConnFactory::getConn() [08/Mar/2012:01:54:34][TP-Processor3]: masterConn is connected: true [08/Mar/2012:01:54:34][TP-Processor3]: getConn: conn is connected true [08/Mar/2012:01:54:34][TP-Processor3]: getConn: mNumConns now 2 [08/Mar/2012:01:54:34][TP-Processor3]: returnConn: mNumConns now 3 [08/Mar/2012:01:54:34][TP-Processor3]: Authentication: cannot map certificate to user [08/Mar/2012:01:54:34][TP-Processor3]: SignedAuditEventFactory: create() message=[AuditEvent=AUTH_FAIL][SubjectID=$Unidentified$][Outcome=Failure][AuthMgr=certUserDBAuthMgr][AttemptedCred=CN=IPA RA,O=ABC.XYZ] authentication failure On Fri, Mar 16, 2012 at 12:15 PM, Jimmy wrote: > Here are the latest logs and info. Thanks. Jimmy > > ipagetcert list output- http://fpaste.org/OAra/ > > pki-ca system log -- http://fpaste.org/Uomy/ > catalina.out -- http://fpaste.org/5MR1/ > selftests -- http://fpaste.org/CwDF/ > debug -- http://fpaste.org/Wy0o/ > > On Fri, Mar 16, 2012 at 11:08 AM, Rob Crittenden wrote: >> Jimmy wrote: >>> >>> I didn't see a catalina.log on my system, but there is a catalina.out: >>> >>> http://fpaste.org/KgJn/ >> >> >> That's the one. Looks like the CA isn't starting. >> >> Does /var/lib/pki-ca/logs/signedAudit/ca_audit exist? If so, what is the >> SELinux context (ls -lZ)? >> >> rob >> >>> >>> -J >>> >>> On Thu, Mar 15, 2012 at 5:37 PM, Rob Crittenden >>> ?wrote: >>>> >>>> Jimmy wrote: >>>>> >>>>> >>>>> error log: http://fpaste.org/efyf/ >>>>> >>>>> CA debug: http://fpaste.org/LemM/ >>>>> >>>>> CA localhost log: http://fpaste.org/q4MU/ >>>>> >>>>> That's all I can find the correspond to the time I ran the getcert. >>>> >>>> >>>> >>>> I'd look at the catalina.log, is dogtag coming up ok? >>>> >>>> rob >>>> >>>> >>>>> >>>>> Jimmy >>>>> On Thu, Mar 15, 2012 at 4:47 PM, Rob Crittenden >>>>> ?wrote: >>>>>> >>>>>> >>>>>> Jimmy wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> Still shows status: CA_UNREACHABLE >>>>>>> >>>>>>> http://fpaste.org/UrTJ/ >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> If there was an Internal Server Error there should be an error in the >>>>>> Apache >>>>>> error log or something in the CA debug/transaction log (or both). Can >>>>>> you >>>>>> check those? >>>>>> >>>>>> rob >>>>>> >>>>>>> >>>>>>> On Thu, Mar 15, 2012 at 3:22 PM, Rob Crittenden >>>>>>> ?wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Jimmy wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I used yum to upgrade cert monger now the access_log has nothing new >>>>>>>>> when I run the ipa-getcert, but error_log shows this: >>>>>>>>> >>>>>>>>> [Sat Mar 10 21:47:21 2012] [error] ipa: INFO: sslget >>>>>>>>> 'https://xyz-ipa.abc.xyz:443/ca/agent/ca/displayBySerial' >>>>>>>>> [Sat Mar 10 21:47:21 2012] [error] ipa: INFO: >>>>>>>>> host/xyz-ipa.abc.xyz at ABC.XYZ: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> cert_request(u'MIIDQzCCAisCAQAwLDEQMA4GA1UEChMHUERILkNTUDEYMBYGA1UEAxMPY3NwLWlkbS5wZGguY3NwMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr0EHCdyTuteryFZ2bdEl+V4OATR/xk8ELthmvlwT/5qubZKwlCWS6yLawgdyCg9Yw737A7qGe0BPxHv6E+as10NxppEPsn9BOi+TPRIMYNMNNYmO2sce2pvkMkVBqsF7Gn7mF7e5+Bpc7ApnDGP7WLsAjbso8EvLUrqVMTNyiziCSHiNk+/Fi1Om6K5GKzKkqfEDex0RK+kpMswgcaZHhmW3i+y3UxFZsJjOg3R4fJAfC0+My2d1Vx4052+EgWAbSNpSj7zmLGM2+dkmgMo5Li7jjgJe8VsrqOV4L5IgqtGVJ0EOb7EP7gynbVoa74m4XrVwEP8rd/M5RxAnD1JPuwIDAQABoIHRMBoGCSqGSIb3DQEJFDENEwtTZXJ2ZXItQ2VydDCBsgYJKoZIhvcNAQkOMYGkMIGhMA4GA1UdDwEBAAQEAwIE8DB3BgNVHREBAQAEbTBroCwGCisGAQQBgjcUAgOgHgwcbGRhcC9jc3AtaWRtLnBkaC5jc3BAUERILkNTUKA7BgYrBgEFAgKgMTAvoAkbB1BESC5DU1ChIjAgoAMCAQGhGTAXGwRsZGFwGw9jc3AtaWRtLnBkaC5jc3AwFgYDVR0lAQEABAwwCgYIKwYBBQUHAwEwDQYJKoZIhvcNAQELBQADggEBABD/Hwbgf5NJNUYt0+ntMDHiilMFkSaO6ryQ36/pCH1oR+vI+PCeClHewPo0v99h4Z8W8L7CQtDdNBUMl/JVHH5Lz7cBF8A/jXZQ+naV17EEuXncacM8AvYh5dL2yih+8RpPalEmSgz5rijtbSigfNGrZn0Mh3qOW1kbsz+GDaaT9wLFxvdJyqgdKds2tsp >> >> 0K >>>> >>>> >>>> zH >>>>>> >>>>>> >>>>>> >>>>>> IM >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> cJuw3cwOfH8zrBRV28XYhMLm0OOhj92uxgax5UPY2VyHP5UOtOnfuduU1ZXa+o8QIXqX7/HyDSCLGwiPJscAsp9cRzjn4KvqzZDOcdGEjXmCGfrmUiMcuzVyTDR2SdAWrHdbRmXeyVxmiBPzdk=', >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> principal=u'ldap/xyz-ipa.abc.xyz at ABC.XYZ', add=True): >>>>>>>>> CertificateOperationError >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> What does ipa-getcert list show? >>>>>>>> >>>>>>>> You may now have something in the CA logs too. >>>>>>>> >>>>>>>> >>>>>>>> rob >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Mar 15, 2012 at 2:07 PM, Rob Crittenden >>>>>>>>> ?wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Jimmy wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Which error log? the pki-ca error log has nothing and the httpd >>>>>>>>>>> error >>>>>>>>>>> log has nothing, and the httpd access log has this: (yes, the >>>>>>>>>>> dates >>>>>>>>>>> are set back a few days, bc the current cert expires on 3/11) >>>>>>>>>>> >>>>>>>>>>> 192.168.201.102 - - [10/Mar/2012:21:27:24 +0000] "POST /ipa/xml >>>>>>>>>>> HTTP/1.1" 401 1775 >>>>>>>>>>> 192.168.201.102 - host/abc-ipa.abc.xyz at ABC.XYZ >>>>>>>>>>> [10/Mar/2012:21:27:25 >>>>>>>>>>> +0000] "POST /ipa/xml HTTP/1.1" 200 314 >>>>>>>>>>> >>>>>>>>>>> here is the ipa-getcert list: >>>>>>>>>>> >>>>>>>>>>> http://fpaste.org/Dzr3/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> You need to update certmonger, it isn't setting a Referer HTTP >>>>>>>>>> header >>>>>>>>>> in >>>>>>>>>> its >>>>>>>>>> request. That is now required by IPA. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> rob >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Thu, Mar 15, 2012 at 1:33 PM, Rob >>>>>>>>>>> Crittenden >>>>>>>>>>> ?wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Jimmy wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Restarted IPA and now the interface loads, but resubmitting the >>>>>>>>>>>>> cert >>>>>>>>>>>>> has this result - >>>>>>>>>>>>> >>>>>>>>>>>>> ipa-getcert resubmit -i 20110913154233 >>>>>>>>>>>>> 192.168.201.102 - - [10/Mar/2012:20:53:13 +0000] "POST /ipa/xml >>>>>>>>>>>>> HTTP/1.1" 401 1775 >>>>>>>>>>>>> 192.168.201.102 - host/abc-ipa.abc.xyz at ABC.XYZ >>>>>>>>>>>>> [10/Mar/2012:20:53:13 >>>>>>>>>>>>> +0000] "POST /ipa/xml HTTP/1.1" 200 314 >>>>>>>>>>>>> >>>>>>>>>>>>> but the cert still shows these dates- >>>>>>>>>>>>> >>>>>>>>>>>>> ?Not Before: Tue Sep 13 15:43:37 2011 >>>>>>>>>>>>> ? ? ? ? ? ? Not After : Sun Mar 11 15:43:37 2012 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> The error log will contain more interesting information. >>>>>>>>>>>> >>>>>>>>>>>> What does the status show in the output of ipa-getcert list? >>>>>>>>>>>> >>>>>>>>>>>> rob >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Thu, Mar 15, 2012 at 1:06 PM, Jimmy >>>>>>>>>>>>> ?wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> I can now start the upgraded IPA, but now going to the IPA >>>>>>>>>>>>>> admin >>>>>>>>>>>>>> page >>>>>>>>>>>>>> I get this: >>>>>>>>>>>>>> >>>>>>>>>>>>>> ==== >>>>>>>>>>>>>> >>>>>>>>>>>>>> Not Found >>>>>>>>>>>>>> >>>>>>>>>>>>>> The requested URL /ipa was not found on this server. >>>>>>>>>>>>>> >>>>>>>>>>>>>> ==== >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> Freeipa-users mailing list >>>>>>>>>>>>> Freeipa-users at redhat.com >>>>>>>>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>>> >> From rcritten at redhat.com Fri Mar 16 17:29:51 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 16 Mar 2012 13:29:51 -0400 Subject: [Freeipa-users] (no subject) In-Reply-To: References: <4F622801.10600@redhat.com> <4F622FC9.8040003@redhat.com> <4F624162.7020806@redhat.com> <4F62554F.1030804@redhat.com> <4F626135.3030402@redhat.com> <4F63575B.6090805@redhat.com> Message-ID: <4F63788F.2070803@redhat.com> Jimmy wrote: > When I try `ipa-getcert resubmit -i 20110913154233` I see this in the CA logs: > > localhost.2012-03-08.log--- > Mar 8, 2012 1:54:34 AM org.apache.catalina.core.ApplicationContext log > INFO: caDisplayBySerial-agent: Invalid Credential. > > debug--- > [08/Mar/2012:01:54:34][TP-Processor3]: In LdapBoundConnFactory::getConn() > [08/Mar/2012:01:54:34][TP-Processor3]: masterConn is connected: true > [08/Mar/2012:01:54:34][TP-Processor3]: getConn: conn is connected true > [08/Mar/2012:01:54:34][TP-Processor3]: getConn: mNumConns now 2 > [08/Mar/2012:01:54:34][TP-Processor3]: returnConn: mNumConns now 3 > [08/Mar/2012:01:54:34][TP-Processor3]: Authentication: cannot map > certificate to user > [08/Mar/2012:01:54:34][TP-Processor3]: SignedAuditEventFactory: > create() message=[AuditEvent=AUTH_FAIL][SubjectID=$Unidentified$][Outcome=Failure][AuthMgr=certUserDBAuthMgr][AttemptedCred=CN=IPA > RA,O=ABC.XYZ] authentication failure Right, I think your dogtag 389-ds instance is similarly corrupted to your IPA instance so it can't find any entries. rob > > > > On Fri, Mar 16, 2012 at 12:15 PM, Jimmy wrote: >> Here are the latest logs and info. Thanks. Jimmy >> >> ipagetcert list output- http://fpaste.org/OAra/ >> >> pki-ca system log -- http://fpaste.org/Uomy/ >> catalina.out -- http://fpaste.org/5MR1/ >> selftests -- http://fpaste.org/CwDF/ >> debug -- http://fpaste.org/Wy0o/ >> >> On Fri, Mar 16, 2012 at 11:08 AM, Rob Crittenden wrote: >>> Jimmy wrote: >>>> >>>> I didn't see a catalina.log on my system, but there is a catalina.out: >>>> >>>> http://fpaste.org/KgJn/ >>> >>> >>> That's the one. Looks like the CA isn't starting. >>> >>> Does /var/lib/pki-ca/logs/signedAudit/ca_audit exist? If so, what is the >>> SELinux context (ls -lZ)? >>> >>> rob >>> >>>> >>>> -J >>>> >>>> On Thu, Mar 15, 2012 at 5:37 PM, Rob Crittenden >>>> wrote: >>>>> >>>>> Jimmy wrote: >>>>>> >>>>>> >>>>>> error log: http://fpaste.org/efyf/ >>>>>> >>>>>> CA debug: http://fpaste.org/LemM/ >>>>>> >>>>>> CA localhost log: http://fpaste.org/q4MU/ >>>>>> >>>>>> That's all I can find the correspond to the time I ran the getcert. >>>>> >>>>> >>>>> >>>>> I'd look at the catalina.log, is dogtag coming up ok? >>>>> >>>>> rob >>>>> >>>>> >>>>>> >>>>>> Jimmy >>>>>> On Thu, Mar 15, 2012 at 4:47 PM, Rob Crittenden >>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> Jimmy wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Still shows status: CA_UNREACHABLE >>>>>>>> >>>>>>>> http://fpaste.org/UrTJ/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> If there was an Internal Server Error there should be an error in the >>>>>>> Apache >>>>>>> error log or something in the CA debug/transaction log (or both). Can >>>>>>> you >>>>>>> check those? >>>>>>> >>>>>>> rob >>>>>>> >>>>>>>> >>>>>>>> On Thu, Mar 15, 2012 at 3:22 PM, Rob Crittenden >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Jimmy wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I used yum to upgrade cert monger now the access_log has nothing new >>>>>>>>>> when I run the ipa-getcert, but error_log shows this: >>>>>>>>>> >>>>>>>>>> [Sat Mar 10 21:47:21 2012] [error] ipa: INFO: sslget >>>>>>>>>> 'https://xyz-ipa.abc.xyz:443/ca/agent/ca/displayBySerial' >>>>>>>>>> [Sat Mar 10 21:47:21 2012] [error] ipa: INFO: >>>>>>>>>> host/xyz-ipa.abc.xyz at ABC.XYZ: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> cert_request(u'MIIDQzCCAisCAQAwLDEQMA4GA1UEChMHUERILkNTUDEYMBYGA1UEAxMPY3NwLWlkbS5wZGguY3NwMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr0EHCdyTuteryFZ2bdEl+V4OATR/xk8ELthmvlwT/5qubZKwlCWS6yLawgdyCg9Yw737A7qGe0BPxHv6E+as10NxppEPsn9BOi+TPRIMYNMNNYmO2sce2pvkMkVBqsF7Gn7mF7e5+Bpc7ApnDGP7WLsAjbso8EvLUrqVMTNyiziCSHiNk+/Fi1Om6K5GKzKkqfEDex0RK+kpMswgcaZHhmW3i+y3UxFZsJjOg3R4fJAfC0+My2d1Vx4052+EgWAbSNpSj7zmLGM2+dkmgMo5Li7jjgJe8VsrqOV4L5IgqtGVJ0EOb7EP7gynbVoa74m4XrVwEP8rd/M5RxAnD1JPuwIDAQABoIHRMBoGCSqGSIb3DQEJFDENEwtTZXJ2ZXItQ2VydDCBsgYJKoZIhvcNAQkOMYGkMIGhMA4GA1UdDwEBAAQEAwIE8DB3BgNVHREBAQAEbTBroCwGCisGAQQBgjcUAgOgHgwcbGRhcC9jc3AtaWRtLnBkaC5jc3BAUERILkNTUKA7BgYrBgEFAgKgMTAvoAkbB1BESC5DU1ChIjAgoAMCAQGhGTAXGwRsZGFwGw9jc3AtaWRtLnBkaC5jc3AwFgYDVR0lAQEABAwwCgYIKwYBBQUHAwEwDQYJKoZIhvcNAQELBQADggEBABD/Hwbgf5NJNUYt0+ntMDHiilMFkSaO6ryQ36/pCH1oR+vI+PCeClHewPo0v99h4Z8W8L7CQtDdNBUMl/JVHH5Lz7cBF8A/jXZQ+naV17EEuXncacM8AvYh5dL2yih+8RpPalEmSgz5rijtbSigfNGrZn0Mh3qOW1kbsz+GDaaT9wLFxvdJyqgdKds2 tsp >>> >>> 0K >>>>> >>>>> >>>>> zH >>>>>>> >>>>>>> >>>>>>> >>>>>>> IM >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> cJuw3cwOfH8zrBRV28XYhMLm0OOhj92uxgax5UPY2VyHP5UOtOnfuduU1ZXa+o8QIXqX7/HyDSCLGwiPJscAsp9cRzjn4KvqzZDOcdGEjXmCGfrmUiMcuzVyTDR2SdAWrHdbRmXeyVxmiBPzdk=', >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> principal=u'ldap/xyz-ipa.abc.xyz at ABC.XYZ', add=True): >>>>>>>>>> CertificateOperationError >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> What does ipa-getcert list show? >>>>>>>>> >>>>>>>>> You may now have something in the CA logs too. >>>>>>>>> >>>>>>>>> >>>>>>>>> rob >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Thu, Mar 15, 2012 at 2:07 PM, Rob Crittenden >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Jimmy wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Which error log? the pki-ca error log has nothing and the httpd >>>>>>>>>>>> error >>>>>>>>>>>> log has nothing, and the httpd access log has this: (yes, the >>>>>>>>>>>> dates >>>>>>>>>>>> are set back a few days, bc the current cert expires on 3/11) >>>>>>>>>>>> >>>>>>>>>>>> 192.168.201.102 - - [10/Mar/2012:21:27:24 +0000] "POST /ipa/xml >>>>>>>>>>>> HTTP/1.1" 401 1775 >>>>>>>>>>>> 192.168.201.102 - host/abc-ipa.abc.xyz at ABC.XYZ >>>>>>>>>>>> [10/Mar/2012:21:27:25 >>>>>>>>>>>> +0000] "POST /ipa/xml HTTP/1.1" 200 314 >>>>>>>>>>>> >>>>>>>>>>>> here is the ipa-getcert list: >>>>>>>>>>>> >>>>>>>>>>>> http://fpaste.org/Dzr3/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> You need to update certmonger, it isn't setting a Referer HTTP >>>>>>>>>>> header >>>>>>>>>>> in >>>>>>>>>>> its >>>>>>>>>>> request. That is now required by IPA. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> rob >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Mar 15, 2012 at 1:33 PM, Rob >>>>>>>>>>>> Crittenden >>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Jimmy wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Restarted IPA and now the interface loads, but resubmitting the >>>>>>>>>>>>>> cert >>>>>>>>>>>>>> has this result - >>>>>>>>>>>>>> >>>>>>>>>>>>>> ipa-getcert resubmit -i 20110913154233 >>>>>>>>>>>>>> 192.168.201.102 - - [10/Mar/2012:20:53:13 +0000] "POST /ipa/xml >>>>>>>>>>>>>> HTTP/1.1" 401 1775 >>>>>>>>>>>>>> 192.168.201.102 - host/abc-ipa.abc.xyz at ABC.XYZ >>>>>>>>>>>>>> [10/Mar/2012:20:53:13 >>>>>>>>>>>>>> +0000] "POST /ipa/xml HTTP/1.1" 200 314 >>>>>>>>>>>>>> >>>>>>>>>>>>>> but the cert still shows these dates- >>>>>>>>>>>>>> >>>>>>>>>>>>>> Not Before: Tue Sep 13 15:43:37 2011 >>>>>>>>>>>>>> Not After : Sun Mar 11 15:43:37 2012 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> The error log will contain more interesting information. >>>>>>>>>>>>> >>>>>>>>>>>>> What does the status show in the output of ipa-getcert list? >>>>>>>>>>>>> >>>>>>>>>>>>> rob >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Thu, Mar 15, 2012 at 1:06 PM, Jimmy >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I can now start the upgraded IPA, but now going to the IPA >>>>>>>>>>>>>>> admin >>>>>>>>>>>>>>> page >>>>>>>>>>>>>>> I get this: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ==== >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Not Found >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The requested URL /ipa was not found on this server. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ==== >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> Freeipa-users mailing list >>>>>>>>>>>>>> Freeipa-users at redhat.com >>>>>>>>>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>> From simo at redhat.com Fri Mar 16 17:38:18 2012 From: simo at redhat.com (Simo Sorce) Date: Fri, 16 Mar 2012 13:38:18 -0400 Subject: [Freeipa-users] (no subject) In-Reply-To: <4F636F7A.4060109@redhat.com> References: <4F622801.10600@redhat.com> <4F622FC9.8040003@redhat.com> <4F624162.7020806@redhat.com> <4F62554F.1030804@redhat.com> <4F626135.3030402@redhat.com> <4F63575B.6090805@redhat.com> <4F636F7A.4060109@redhat.com> Message-ID: <1331919498.9238.279.camel@willson.li.ssimo.org> On Fri, 2012-03-16 at 12:51 -0400, Rob Crittenden wrote: > Jimmy wrote: > > Here are the latest logs and info. Thanks. Jimmy > > What did you change to fix the ca_audit problem? > > There are two problems that I can see: > > 1. certmonger is failing because of SSL trust issues. Have you > changed > the NSS database(s) recently for Apache or 389-ds, or /etc/pki/nssdb? > > 2. Looks like there is some corruption in the dogtag LDAP instance > based > on all the entries not found. > > Maybe the dogtag instance also got problems during the 389ds upgrade ? Jimmy, maybe you can do the same dump to ldif restore procedure for the dogtag instance ? Simo. -- Simo Sorce * Red Hat, Inc * New York From g17jimmy at gmail.com Fri Mar 16 18:22:39 2012 From: g17jimmy at gmail.com (Jimmy) Date: Fri, 16 Mar 2012 14:22:39 -0400 Subject: [Freeipa-users] (no subject) In-Reply-To: <1331919498.9238.279.camel@willson.li.ssimo.org> References: <4F622801.10600@redhat.com> <4F622FC9.8040003@redhat.com> <4F624162.7020806@redhat.com> <4F62554F.1030804@redhat.com> <4F626135.3030402@redhat.com> <4F63575B.6090805@redhat.com> <4F636F7A.4060109@redhat.com> <1331919498.9238.279.camel@willson.li.ssimo.org> Message-ID: I'm up for that. I'm assuming the DogTag db is in /var/lib/dirsrv/slapd-PKI-IPA/db/userRoot. Correct? On Fri, Mar 16, 2012 at 1:38 PM, Simo Sorce wrote: > On Fri, 2012-03-16 at 12:51 -0400, Rob Crittenden wrote: >> Jimmy wrote: >> > Here are the latest logs and info. Thanks. Jimmy >> >> What did you change to fix the ca_audit problem? >> >> There are two problems that I can see: >> >> 1. certmonger is failing because of SSL trust issues. Have you >> changed >> the NSS database(s) recently for Apache or 389-ds, or /etc/pki/nssdb? >> >> 2. Looks like there is some corruption in the dogtag LDAP instance >> based >> on all the entries not found. >> >> > Maybe the dogtag instance also got problems during the 389ds upgrade ? > > Jimmy, maybe you can do the same dump to ldif restore procedure for the > dogtag instance ? > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > From g17jimmy at gmail.com Fri Mar 16 17:32:12 2012 From: g17jimmy at gmail.com (Jimmy) Date: Fri, 16 Mar 2012 13:32:12 -0400 Subject: [Freeipa-users] (no subject) In-Reply-To: <4F63788F.2070803@redhat.com> References: <4F622801.10600@redhat.com> <4F622FC9.8040003@redhat.com> <4F624162.7020806@redhat.com> <4F62554F.1030804@redhat.com> <4F626135.3030402@redhat.com> <4F63575B.6090805@redhat.com> <4F63788F.2070803@redhat.com> Message-ID: What is the proper way to recover from this? I've been digging and searching but don't see anything about this in relation to IPA. On Fri, Mar 16, 2012 at 1:29 PM, Rob Crittenden wrote: > Jimmy wrote: >> >> When I try `ipa-getcert resubmit -i 20110913154233` I see this in the CA >> logs: >> >> localhost.2012-03-08.log--- >> Mar 8, 2012 1:54:34 AM org.apache.catalina.core.ApplicationContext log >> INFO: caDisplayBySerial-agent: Invalid Credential. >> >> debug--- >> [08/Mar/2012:01:54:34][TP-Processor3]: In LdapBoundConnFactory::getConn() >> [08/Mar/2012:01:54:34][TP-Processor3]: masterConn is connected: true >> [08/Mar/2012:01:54:34][TP-Processor3]: getConn: conn is connected true >> [08/Mar/2012:01:54:34][TP-Processor3]: getConn: mNumConns now 2 >> [08/Mar/2012:01:54:34][TP-Processor3]: returnConn: mNumConns now 3 >> [08/Mar/2012:01:54:34][TP-Processor3]: Authentication: cannot map >> certificate to user >> [08/Mar/2012:01:54:34][TP-Processor3]: SignedAuditEventFactory: >> create() >> message=[AuditEvent=AUTH_FAIL][SubjectID=$Unidentified$][Outcome=Failure][AuthMgr=certUserDBAuthMgr][AttemptedCred=CN=IPA >> RA,O=ABC.XYZ] authentication failure > > > Right, I think your dogtag 389-ds instance is similarly corrupted to your > IPA instance so it can't find any entries. > > rob > > >> >> >> >> On Fri, Mar 16, 2012 at 12:15 PM, Jimmy ?wrote: >>> >>> Here are the latest logs and info. Thanks. Jimmy >>> >>> ipagetcert list output- http://fpaste.org/OAra/ >>> >>> pki-ca system log -- http://fpaste.org/Uomy/ >>> catalina.out -- http://fpaste.org/5MR1/ >>> selftests -- http://fpaste.org/CwDF/ >>> debug -- http://fpaste.org/Wy0o/ >>> >>> On Fri, Mar 16, 2012 at 11:08 AM, Rob Crittenden >>> ?wrote: >>>> >>>> Jimmy wrote: >>>>> >>>>> >>>>> I didn't see a catalina.log on my system, but there is a catalina.out: >>>>> >>>>> http://fpaste.org/KgJn/ >>>> >>>> >>>> >>>> That's the one. Looks like the CA isn't starting. >>>> >>>> Does /var/lib/pki-ca/logs/signedAudit/ca_audit exist? If so, what is the >>>> SELinux context (ls -lZ)? >>>> >>>> rob >>>> >>>>> >>>>> -J >>>>> >>>>> On Thu, Mar 15, 2012 at 5:37 PM, Rob Crittenden >>>>> ?wrote: >>>>>> >>>>>> >>>>>> Jimmy wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> error log: http://fpaste.org/efyf/ >>>>>>> >>>>>>> CA debug: http://fpaste.org/LemM/ >>>>>>> >>>>>>> CA localhost log: http://fpaste.org/q4MU/ >>>>>>> >>>>>>> That's all I can find the correspond to the time I ran the getcert. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> I'd look at the catalina.log, is dogtag coming up ok? >>>>>> >>>>>> rob >>>>>> >>>>>> >>>>>>> >>>>>>> Jimmy >>>>>>> On Thu, Mar 15, 2012 at 4:47 PM, Rob Crittenden >>>>>>> ?wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Jimmy wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Still shows status: CA_UNREACHABLE >>>>>>>>> >>>>>>>>> http://fpaste.org/UrTJ/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> If there was an Internal Server Error there should be an error in >>>>>>>> the >>>>>>>> Apache >>>>>>>> error log or something in the CA debug/transaction log (or both). >>>>>>>> Can >>>>>>>> you >>>>>>>> check those? >>>>>>>> >>>>>>>> rob >>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Mar 15, 2012 at 3:22 PM, Rob >>>>>>>>> Crittenden >>>>>>>>> ?wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Jimmy wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I used yum to upgrade cert monger now the access_log has nothing >>>>>>>>>>> new >>>>>>>>>>> when I run the ipa-getcert, but error_log shows this: >>>>>>>>>>> >>>>>>>>>>> [Sat Mar 10 21:47:21 2012] [error] ipa: INFO: sslget >>>>>>>>>>> 'https://xyz-ipa.abc.xyz:443/ca/agent/ca/displayBySerial' >>>>>>>>>>> [Sat Mar 10 21:47:21 2012] [error] ipa: INFO: >>>>>>>>>>> host/xyz-ipa.abc.xyz at ABC.XYZ: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> cert_request(u'MIIDQzCCAisCAQAwLDEQMA4GA1UEChMHUERILkNTUDEYMBYGA1UEAxMPY3NwLWlkbS5wZGguY3NwMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr0EHCdyTuteryFZ2bdEl+V4OATR/xk8ELthmvlwT/5qubZKwlCWS6yLawgdyCg9Yw737A7qGe0BPxHv6E+as10NxppEPsn9BOi+TPRIMYNMNNYmO2sce2pvkMkVBqsF7Gn7mF7e5+Bpc7ApnDGP7WLsAjbso8EvLUrqVMTNyiziCSHiNk+/Fi1Om6K5GKzKkqfEDex0RK+kpMswgcaZHhmW3i+y3UxFZsJjOg3R4fJAfC0+My2d1Vx4052+EgWAbSNpSj7zmLGM2+dkmgMo5Li7jjgJe8VsrqOV4L5IgqtGVJ0EOb7EP7gynbVoa74m4XrVwEP8rd/M5RxAnD1JPuwIDAQABoIHRMBoGCSqGSIb3DQEJFDENEwtTZXJ2ZXItQ2VydDCBsgYJKoZIhvcNAQkOMYGkMIGhMA4GA1UdDwEBAAQEAwIE8DB3BgNVHREBAQAEbTBroCwGCisGAQQBgjcUAgOgHgwcbGRhcC9jc3AtaWRtLnBkaC5jc3BAUERILkNTUKA7BgYrBgEFAgKgMTAvoAkbB1BESC5DU1ChIjAgoAMCAQGhGTAXGwRsZGFwGw9jc3AtaWRtLnBkaC5jc3AwFgYDVR0lAQEABAwwCgYIKwYBBQUHAwEwDQYJKoZIhvcNAQELBQADggEBABD/Hwbgf5NJNUYt0+ntMDHiilMFkSaO6ryQ36/pCH1oR+vI+PCeClHewPo0v99h4Z8W8L7CQtDdNBUMl/JVHH5Lz7cBF8A/jXZQ+naV17EEuXncacM8AvYh5dL2yih+8RpPalEmSgz5rijtbSigfNGrZn0Mh3qOW1kbsz+GDaaT9wLFxvdJyqgdKds2 > > tsp >>>> >>>> >>>> 0K >>>>>> >>>>>> >>>>>> >>>>>> zH >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> IM >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> cJuw3cwOfH8zrBRV28XYhMLm0OOhj92uxgax5UPY2VyHP5UOtOnfuduU1ZXa+o8QIXqX7/HyDSCLGwiPJscAsp9cRzjn4KvqzZDOcdGEjXmCGfrmUiMcuzVyTDR2SdAWrHdbRmXeyVxmiBPzdk=', >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> principal=u'ldap/xyz-ipa.abc.xyz at ABC.XYZ', add=True): >>>>>>>>>>> CertificateOperationError >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> What does ipa-getcert list show? >>>>>>>>>> >>>>>>>>>> You may now have something in the CA logs too. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> rob >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Thu, Mar 15, 2012 at 2:07 PM, Rob >>>>>>>>>>> Crittenden >>>>>>>>>>> ?wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Jimmy wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Which error log? the pki-ca error log has nothing and the httpd >>>>>>>>>>>>> error >>>>>>>>>>>>> log has nothing, and the httpd access log has this: (yes, the >>>>>>>>>>>>> dates >>>>>>>>>>>>> are set back a few days, bc the current cert expires on 3/11) >>>>>>>>>>>>> >>>>>>>>>>>>> 192.168.201.102 - - [10/Mar/2012:21:27:24 +0000] "POST /ipa/xml >>>>>>>>>>>>> HTTP/1.1" 401 1775 >>>>>>>>>>>>> 192.168.201.102 - host/abc-ipa.abc.xyz at ABC.XYZ >>>>>>>>>>>>> [10/Mar/2012:21:27:25 >>>>>>>>>>>>> +0000] "POST /ipa/xml HTTP/1.1" 200 314 >>>>>>>>>>>>> >>>>>>>>>>>>> here is the ipa-getcert list: >>>>>>>>>>>>> >>>>>>>>>>>>> http://fpaste.org/Dzr3/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> You need to update certmonger, it isn't setting a Referer HTTP >>>>>>>>>>>> header >>>>>>>>>>>> in >>>>>>>>>>>> its >>>>>>>>>>>> request. That is now required by IPA. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> rob >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Thu, Mar 15, 2012 at 1:33 PM, Rob >>>>>>>>>>>>> Crittenden >>>>>>>>>>>>> ?wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Jimmy wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Restarted IPA and now the interface loads, but resubmitting >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> cert >>>>>>>>>>>>>>> has this result - >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ipa-getcert resubmit -i 20110913154233 >>>>>>>>>>>>>>> 192.168.201.102 - - [10/Mar/2012:20:53:13 +0000] "POST >>>>>>>>>>>>>>> /ipa/xml >>>>>>>>>>>>>>> HTTP/1.1" 401 1775 >>>>>>>>>>>>>>> 192.168.201.102 - host/abc-ipa.abc.xyz at ABC.XYZ >>>>>>>>>>>>>>> [10/Mar/2012:20:53:13 >>>>>>>>>>>>>>> +0000] "POST /ipa/xml HTTP/1.1" 200 314 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> but the cert still shows these dates- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ?Not Before: Tue Sep 13 15:43:37 2011 >>>>>>>>>>>>>>> ? ? ? ? ? ? Not After : Sun Mar 11 15:43:37 2012 >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> The error log will contain more interesting information. >>>>>>>>>>>>>> >>>>>>>>>>>>>> What does the status show in the output of ipa-getcert list? >>>>>>>>>>>>>> >>>>>>>>>>>>>> rob >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Thu, Mar 15, 2012 at 1:06 PM, Jimmy >>>>>>>>>>>>>>> ?wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I can now start the upgraded IPA, but now going to the IPA >>>>>>>>>>>>>>>> admin >>>>>>>>>>>>>>>> page >>>>>>>>>>>>>>>> I get this: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ==== >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Not Found >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The requested URL /ipa was not found on this server. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ==== >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>> Freeipa-users mailing list >>>>>>>>>>>>>>> Freeipa-users at redhat.com >>>>>>>>>>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>>> > From g17jimmy at gmail.com Fri Mar 16 18:31:20 2012 From: g17jimmy at gmail.com (Jimmy) Date: Fri, 16 Mar 2012 14:31:20 -0400 Subject: [Freeipa-users] (no subject) In-Reply-To: <4F636F7A.4060109@redhat.com> References: <4F622801.10600@redhat.com> <4F622FC9.8040003@redhat.com> <4F624162.7020806@redhat.com> <4F62554F.1030804@redhat.com> <4F626135.3030402@redhat.com> <4F63575B.6090805@redhat.com> <4F636F7A.4060109@redhat.com> Message-ID: The ca_audit problem was caused by me accidentally moving the directory to a backup location. I was cleaning up the logs to make reading easier. When I moved the directory back that issue went away. No changes were made in the NSS database(s) or any other internal workings of IPA. This system is used for very basic user authentication, DNS, etc. I can do the ldif export/import for dogtag. Just from comparing everything, it looks like the dogtag db is in /var/lib/dirsrv/slapd-PKI-IPA/db/userRoot, is that correct? -J On Fri, Mar 16, 2012 at 12:51 PM, Rob Crittenden wrote: > Jimmy wrote: >> >> Here are the latest logs and info. Thanks. Jimmy > > > What did you change to fix the ca_audit problem? > > There are two problems that I can see: > > 1. certmonger is failing because of SSL trust issues. Have you changed the > NSS database(s) recently for Apache or 389-ds, or /etc/pki/nssdb? > > 2. Looks like there is some corruption in the dogtag LDAP instance based on > all the entries not found. > > rob > > >> >> ipagetcert list output- http://fpaste.org/OAra/ >> >> pki-ca system log -- http://fpaste.org/Uomy/ >> catalina.out -- http://fpaste.org/5MR1/ >> selftests -- http://fpaste.org/CwDF/ >> debug -- http://fpaste.org/Wy0o/ >> >> On Fri, Mar 16, 2012 at 11:08 AM, Rob Crittenden >> ?wrote: >>> >>> Jimmy wrote: >>>> >>>> >>>> I didn't see a catalina.log on my system, but there is a catalina.out: >>>> >>>> http://fpaste.org/KgJn/ >>> >>> >>> >>> That's the one. Looks like the CA isn't starting. >>> >>> Does /var/lib/pki-ca/logs/signedAudit/ca_audit exist? If so, what is the >>> SELinux context (ls -lZ)? >>> >>> rob >>> >>>> >>>> -J >>>> >>>> On Thu, Mar 15, 2012 at 5:37 PM, Rob Crittenden >>>> ?wrote: >>>>> >>>>> >>>>> Jimmy wrote: >>>>>> >>>>>> >>>>>> >>>>>> error log: http://fpaste.org/efyf/ >>>>>> >>>>>> CA debug: http://fpaste.org/LemM/ >>>>>> >>>>>> CA localhost log: http://fpaste.org/q4MU/ >>>>>> >>>>>> That's all I can find the correspond to the time I ran the getcert. >>>>> >>>>> >>>>> >>>>> >>>>> I'd look at the catalina.log, is dogtag coming up ok? >>>>> >>>>> rob >>>>> >>>>> >>>>>> >>>>>> Jimmy >>>>>> On Thu, Mar 15, 2012 at 4:47 PM, Rob Crittenden >>>>>> ?wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> Jimmy wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Still shows status: CA_UNREACHABLE >>>>>>>> >>>>>>>> http://fpaste.org/UrTJ/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> If there was an Internal Server Error there should be an error in the >>>>>>> Apache >>>>>>> error log or something in the CA debug/transaction log (or both). Can >>>>>>> you >>>>>>> check those? >>>>>>> >>>>>>> rob >>>>>>> >>>>>>>> >>>>>>>> On Thu, Mar 15, 2012 at 3:22 PM, Rob Crittenden >>>>>>>> ?wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Jimmy wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I used yum to upgrade cert monger now the access_log has nothing >>>>>>>>>> new >>>>>>>>>> when I run the ipa-getcert, but error_log shows this: >>>>>>>>>> >>>>>>>>>> [Sat Mar 10 21:47:21 2012] [error] ipa: INFO: sslget >>>>>>>>>> 'https://xyz-ipa.abc.xyz:443/ca/agent/ca/displayBySerial' >>>>>>>>>> [Sat Mar 10 21:47:21 2012] [error] ipa: INFO: >>>>>>>>>> host/xyz-ipa.abc.xyz at ABC.XYZ: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> cert_request(u'MIIDQzCCAisCAQAwLDEQMA4GA1UEChMHUERILkNTUDEYMBYGA1UEAxMPY3NwLWlkbS5wZGguY3NwMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr0EHCdyTuteryFZ2bdEl+V4OATR/xk8ELthmvlwT/5qubZKwlCWS6yLawgdyCg9Yw737A7qGe0BPxHv6E+as10NxppEPsn9BOi+TPRIMYNMNNYmO2sce2pvkMkVBqsF7Gn7mF7e5+Bpc7ApnDGP7WLsAjbso8EvLUrqVMTNyiziCSHiNk+/Fi1Om6K5GKzKkqfEDex0RK+kpMswgcaZHhmW3i+y3UxFZsJjOg3R4fJAfC0+My2d1Vx4052+EgWAbSNpSj7zmLGM2+dkmgMo5Li7jjgJe8VsrqOV4L5IgqtGVJ0EOb7EP7gynbVoa74m4XrVwEP8rd/M5RxAnD1JPuwIDAQABoIHRMBoGCSqGSIb3DQEJFDENEwtTZXJ2ZXItQ2VydDCBsgYJKoZIhvcNAQkOMYGkMIGhMA4GA1UdDwEBAAQEAwIE8DB3BgNVHREBAQAEbTBroCwGCisGAQQBgjcUAgOgHgwcbGRhcC9jc3AtaWRtLnBkaC5jc3BAUERILkNTUKA7BgYrBgEFAgKgMTAvoAkbB1BESC5DU1ChIjAgoAMCAQGhGTAXGwRsZGFwGw9jc3AtaWRtLnBkaC5jc3AwFgYDVR0lAQEABAwwCgYIKwYBBQUHAwEwDQYJKoZIhvcNAQELBQADggEBABD/Hwbgf5NJNUYt0+ntMDHiilMFkSaO6ryQ36/pCH1oR+vI+PCeClHewPo0v99h4Z8W8L7CQtDdNBUMl/JVHH5Lz7cBF8A/jXZQ+naV17EEuXncacM8AvYh5dL2yih+8RpPalEmSgz5rijtbSigfNGrZn0Mh3qOW1kbsz+GDaaT9wLFxvdJyqgdKds2t > > sp >>> >>> >>> 0K >>>>> >>>>> >>>>> >>>>> zH >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> IM >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> cJuw3cwOfH8zrBRV28XYhMLm0OOhj92uxgax5UPY2VyHP5UOtOnfuduU1ZXa+o8QIXqX7/HyDSCLGwiPJscAsp9cRzjn4KvqzZDOcdGEjXmCGfrmUiMcuzVyTDR2SdAWrHdbRmXeyVxmiBPzdk=', >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> principal=u'ldap/xyz-ipa.abc.xyz at ABC.XYZ', add=True): >>>>>>>>>> CertificateOperationError >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> What does ipa-getcert list show? >>>>>>>>> >>>>>>>>> You may now have something in the CA logs too. >>>>>>>>> >>>>>>>>> >>>>>>>>> rob >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Thu, Mar 15, 2012 at 2:07 PM, Rob >>>>>>>>>> Crittenden >>>>>>>>>> ?wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Jimmy wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Which error log? the pki-ca error log has nothing and the httpd >>>>>>>>>>>> error >>>>>>>>>>>> log has nothing, and the httpd access log has this: (yes, the >>>>>>>>>>>> dates >>>>>>>>>>>> are set back a few days, bc the current cert expires on 3/11) >>>>>>>>>>>> >>>>>>>>>>>> 192.168.201.102 - - [10/Mar/2012:21:27:24 +0000] "POST /ipa/xml >>>>>>>>>>>> HTTP/1.1" 401 1775 >>>>>>>>>>>> 192.168.201.102 - host/abc-ipa.abc.xyz at ABC.XYZ >>>>>>>>>>>> [10/Mar/2012:21:27:25 >>>>>>>>>>>> +0000] "POST /ipa/xml HTTP/1.1" 200 314 >>>>>>>>>>>> >>>>>>>>>>>> here is the ipa-getcert list: >>>>>>>>>>>> >>>>>>>>>>>> http://fpaste.org/Dzr3/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> You need to update certmonger, it isn't setting a Referer HTTP >>>>>>>>>>> header >>>>>>>>>>> in >>>>>>>>>>> its >>>>>>>>>>> request. That is now required by IPA. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> rob >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Mar 15, 2012 at 1:33 PM, Rob >>>>>>>>>>>> Crittenden >>>>>>>>>>>> ?wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Jimmy wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Restarted IPA and now the interface loads, but resubmitting >>>>>>>>>>>>>> the >>>>>>>>>>>>>> cert >>>>>>>>>>>>>> has this result - >>>>>>>>>>>>>> >>>>>>>>>>>>>> ipa-getcert resubmit -i 20110913154233 >>>>>>>>>>>>>> 192.168.201.102 - - [10/Mar/2012:20:53:13 +0000] "POST >>>>>>>>>>>>>> /ipa/xml >>>>>>>>>>>>>> HTTP/1.1" 401 1775 >>>>>>>>>>>>>> 192.168.201.102 - host/abc-ipa.abc.xyz at ABC.XYZ >>>>>>>>>>>>>> [10/Mar/2012:20:53:13 >>>>>>>>>>>>>> +0000] "POST /ipa/xml HTTP/1.1" 200 314 >>>>>>>>>>>>>> >>>>>>>>>>>>>> but the cert still shows these dates- >>>>>>>>>>>>>> >>>>>>>>>>>>>> ?Not Before: Tue Sep 13 15:43:37 2011 >>>>>>>>>>>>>> ? ? ? ? ? ? Not After : Sun Mar 11 15:43:37 2012 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> The error log will contain more interesting information. >>>>>>>>>>>>> >>>>>>>>>>>>> What does the status show in the output of ipa-getcert list? >>>>>>>>>>>>> >>>>>>>>>>>>> rob >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Thu, Mar 15, 2012 at 1:06 PM, Jimmy >>>>>>>>>>>>>> ?wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I can now start the upgraded IPA, but now going to the IPA >>>>>>>>>>>>>>> admin >>>>>>>>>>>>>>> page >>>>>>>>>>>>>>> I get this: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ==== >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Not Found >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The requested URL /ipa was not found on this server. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ==== >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> Freeipa-users mailing list >>>>>>>>>>>>>> Freeipa-users at redhat.com >>>>>>>>>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>> > From simo at redhat.com Fri Mar 16 18:39:25 2012 From: simo at redhat.com (Simo Sorce) Date: Fri, 16 Mar 2012 14:39:25 -0400 Subject: [Freeipa-users] (no subject) In-Reply-To: References: <4F622801.10600@redhat.com> <4F622FC9.8040003@redhat.com> <4F624162.7020806@redhat.com> <4F62554F.1030804@redhat.com> <4F626135.3030402@redhat.com> <4F63575B.6090805@redhat.com> <4F636F7A.4060109@redhat.com> <1331919498.9238.279.camel@willson.li.ssimo.org> Message-ID: <1331923165.9238.296.camel@willson.li.ssimo.org> On Fri, 2012-03-16 at 14:22 -0400, Jimmy wrote: > I'm up for that. I'm assuming the DogTag db is in > /var/lib/dirsrv/slapd-PKI-IPA/db/userRoot. Correct? Yes. Simo. > On Fri, Mar 16, 2012 at 1:38 PM, Simo Sorce wrote: > > On Fri, 2012-03-16 at 12:51 -0400, Rob Crittenden wrote: > >> Jimmy wrote: > >> > Here are the latest logs and info. Thanks. Jimmy > >> > >> What did you change to fix the ca_audit problem? > >> > >> There are two problems that I can see: > >> > >> 1. certmonger is failing because of SSL trust issues. Have you > >> changed > >> the NSS database(s) recently for Apache or 389-ds, or /etc/pki/nssdb? > >> > >> 2. Looks like there is some corruption in the dogtag LDAP instance > >> based > >> on all the entries not found. > >> > >> > > Maybe the dogtag instance also got problems during the 389ds upgrade ? > > > > Jimmy, maybe you can do the same dump to ldif restore procedure for the > > dogtag instance ? > > > > Simo. > > > > -- > > Simo Sorce * Red Hat, Inc * New York > > -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Fri Mar 16 18:39:35 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 16 Mar 2012 14:39:35 -0400 Subject: [Freeipa-users] (no subject) In-Reply-To: References: <4F622801.10600@redhat.com> <4F622FC9.8040003@redhat.com> <4F624162.7020806@redhat.com> <4F62554F.1030804@redhat.com> <4F626135.3030402@redhat.com> <4F63575B.6090805@redhat.com> <4F636F7A.4060109@redhat.com> Message-ID: <4F6388E7.9000409@redhat.com> Jimmy wrote: > The ca_audit problem was caused by me accidentally moving the > directory to a backup location. I was cleaning up the logs to make > reading easier. When I moved the directory back that issue went away. > No changes were made in the NSS database(s) or any other internal > workings of IPA. This system is used for very basic user > authentication, DNS, etc. > > I can do the ldif export/import for dogtag. Just from comparing > everything, it looks like the dogtag db is in > /var/lib/dirsrv/slapd-PKI-IPA/db/userRoot, is that correct? > The ipaca db rob From sbingram at gmail.com Fri Mar 16 18:54:20 2012 From: sbingram at gmail.com (Stephen Ingram) Date: Fri, 16 Mar 2012 11:54:20 -0700 Subject: [Freeipa-users] compat plug-in and replication Message-ID: I've seen mention about the compat plug-in causing issues with replication. In my 2.1.4 installation I notice that the plug-in is turned on by default. Is compat only required for those supporting NIS or does it serve another purpose. As I don't use NIS, I'm just wondering if it's safe to turn off. I'm also wondering about replication support in Redhat versions vs Fedora. Earlier I saw mention that the replication feature in the Redhat version was going to be made available through a separate channel. Then later conversation led me to believe that this had been changed. Is this still the case? Steve From rcritten at redhat.com Fri Mar 16 19:12:03 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 16 Mar 2012 15:12:03 -0400 Subject: [Freeipa-users] compat plug-in and replication In-Reply-To: References: Message-ID: <4F639083.4030707@redhat.com> Stephen Ingram wrote: > I've seen mention about the compat plug-in causing issues with > replication. In my 2.1.4 installation I notice that the plug-in is > turned on by default. Is compat only required for those supporting NIS > or does it serve another purpose. As I don't use NIS, I'm just > wondering if it's safe to turn off. The compat plugin wasn't causing problems with replication but we did see increasing memory and CPU usage during migration. We now recommend that compat be disabled when migrating entries (who needs the overhead anyway). Yes, safe to turn it off depending on what your needs are. There are two capabilities provided by the slapi-nis plugin: 1. Compatibility for older clients such as Solaris which doesn't fully grok 2307bis and netgroup triples (ipa-compat-manage enable/disable) 2. An NIS listener (ipa-nis-manage enable/disable) which requires compat to be enabled. But like I said, shouldn't impact replication at all. It just reformats data. > I'm also wondering about replication support in Redhat versions vs > Fedora. Earlier I saw mention that the replication feature in the > Redhat version was going to be made available through a separate > channel. Then later conversation led me to believe that this had been > changed. Is this still the case? Replication is included with 389-ds-base on both platforms. rob From JR.Aquino at citrix.com Fri Mar 16 19:33:16 2012 From: JR.Aquino at citrix.com (JR Aquino) Date: Fri, 16 Mar 2012 19:33:16 +0000 Subject: [Freeipa-users] compat plug-in and replication In-Reply-To: References: Message-ID: On Mar 16, 2012, at 11:54 AM, Stephen Ingram wrote: I've seen mention about the compat plug-in causing issues with replication. In my 2.1.4 installation I notice that the plug-in is turned on by default. Is compat only required for those supporting NIS or does it serve another purpose. As I don't use NIS, I'm just wondering if it's safe to turn off. To compliment what Rob mentioned... Compat is also generally necessary for any user who wishes to utilize Sudo with FreeIPA. Sudo does not natively understand what a 'hostgroup' is, so it can only utilize NIS netgroups for this. Care was taken when designing the FreeIPA hostgroup and nis compatibility system such that any hostgroup that is created has a mirrored (and semi hidden) NIS netgroup created. This way when you build Sudo rules and reference 'hostgroups', transparently, it is really referencing NIS netgroups stored inside of ldap and provided by the compat / nis plugins. Hope this helps clear some stuff up about why one would want compat and nis turned on in FreeIPA. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jr Aquino | Sr. Information Security Specialist GIAC Certified Incident Handler | GIAC WebApp Penetration Tester Citrix Online | 7408 Hollister Avenue | Goleta, CA 93117 T: +1 805.690.3478 C: +1 805.717.0365 jr.aquino at citrixonline.com http://www.citrixonline.com From g17jimmy at gmail.com Fri Mar 16 19:45:14 2012 From: g17jimmy at gmail.com (Jimmy) Date: Fri, 16 Mar 2012 15:45:14 -0400 Subject: [Freeipa-users] (no subject) In-Reply-To: <4F6388E7.9000409@redhat.com> References: <4F622801.10600@redhat.com> <4F622FC9.8040003@redhat.com> <4F624162.7020806@redhat.com> <4F62554F.1030804@redhat.com> <4F626135.3030402@redhat.com> <4F63575B.6090805@redhat.com> <4F636F7A.4060109@redhat.com> <4F6388E7.9000409@redhat.com> Message-ID: I tried it on ipca but this is what it returns: /var/lib/dirsrv/scripts-ABC-XYZ/db2ldif -n ipaca -a /dbexport/ipca-output.ldif Exported ldif file: /dbexport/ipca-output.ldif [08/Mar/2012:04:19:39 +0000] - ERROR: Could not find backend 'ipaca'. userRoot seems to export as expected. On Fri, Mar 16, 2012 at 2:39 PM, Rob Crittenden wrote: > Jimmy wrote: >> >> The ca_audit problem was caused by me accidentally moving the >> directory to a backup location. I was cleaning up the logs to make >> reading easier. When I moved the directory back that issue went away. >> No changes were made in the NSS database(s) or any other internal >> workings of IPA. This system is used for very basic user >> authentication, DNS, etc. >> >> I can do the ldif export/import for dogtag. Just from comparing >> everything, it looks like the dogtag db is in >> /var/lib/dirsrv/slapd-PKI-IPA/db/userRoot, is that correct? >> > > The ipaca db > > rob > From nalin at redhat.com Fri Mar 16 19:50:56 2012 From: nalin at redhat.com (Nalin Dahyabhai) Date: Fri, 16 Mar 2012 15:50:56 -0400 Subject: [Freeipa-users] compat plug-in and replication In-Reply-To: <4F639083.4030707@redhat.com> References: <4F639083.4030707@redhat.com> Message-ID: <20120316195056.GB4325@redhat.com> On Fri, Mar 16, 2012 at 03:12:03PM -0400, Rob Crittenden wrote: > 2. An NIS listener (ipa-nis-manage enable/disable) which requires > compat to be enabled. The NIS server plugin shouldn't depend on the compat plugin being enabled. The NIS server depends on being notified of changes to its source data by the server, and because the compat plugin isn't a full-fleged backend database, it doesn't trigger those notifications for the compat entries. HTH, Nalin From sbingram at gmail.com Fri Mar 16 19:55:30 2012 From: sbingram at gmail.com (Stephen Ingram) Date: Fri, 16 Mar 2012 12:55:30 -0700 Subject: [Freeipa-users] compat plug-in and replication In-Reply-To: <4F639083.4030707@redhat.com> References: <4F639083.4030707@redhat.com> Message-ID: On Fri, Mar 16, 2012 at 12:12 PM, Rob Crittenden wrote: > Stephen Ingram wrote: >> >> I've seen mention about the compat plug-in causing issues with >> replication. In my 2.1.4 installation I notice that the plug-in is >> turned on by default. Is compat only required for those supporting NIS >> or does it serve another purpose. As I don't use NIS, I'm just >> wondering if it's safe to turn off. > > > The compat plugin wasn't causing problems with replication but we did see > increasing memory and CPU usage during migration. We now recommend that > compat be disabled when migrating entries (who needs the overhead anyway). What do you mean exactly by migrating entries or migration in general? I'm getting the impression that this is something different than replication? If you disable compat, then those entries would not appear in the replica, no? > Yes, safe to turn it off depending on what your needs are. There are two > capabilities provided by the slapi-nis plugin: > > 1. Compatibility for older clients such as Solaris which doesn't fully grok > 2307bis and netgroup triples (ipa-compat-manage enable/disable) > > 2. An NIS listener (ipa-nis-manage enable/disable) which requires compat to > be enabled. > > But like I said, shouldn't impact replication at all. It just reformats > data. Could you please explain what you mean by reformatting the data? Are you talking about changing something in the directory? Steve From g17jimmy at gmail.com Fri Mar 16 20:05:18 2012 From: g17jimmy at gmail.com (Jimmy) Date: Fri, 16 Mar 2012 16:05:18 -0400 Subject: [Freeipa-users] (no subject) In-Reply-To: <4F6388E7.9000409@redhat.com> References: <4F622801.10600@redhat.com> <4F622FC9.8040003@redhat.com> <4F624162.7020806@redhat.com> <4F62554F.1030804@redhat.com> <4F626135.3030402@redhat.com> <4F63575B.6090805@redhat.com> <4F636F7A.4060109@redhat.com> <4F6388E7.9000409@redhat.com> Message-ID: I exported/imported the /var/lib/dirsrv/slapd-PKI-IPA/db/userRoot and that went smoothly but now I see this in /var/log/pki-ca/system: 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] Operation Error - netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] Null response control 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] Operation Error - netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] Null response control 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] Operation Error - netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] Null response control 10358.CRLIssuingPoint-MasterCRL - [08/Mar/2012:04:36:29 UTC] [3] [3] CRLIssuingPoint MasterCRL - Cannot create or store the first CRL in the internaldb. The internaldb could be down. Error LDAP operation failure - cn=MasterCRL,ou=crlIssuingPoints, ou=ca, o=ipaca netscape.ldap.LDAPE xception: error result (32); matchedDN = o=ipaca catalina.out -- http://fpaste.org/oRQd/ ca-debug -- http://fpaste.org/zzFL/ Any ideas? On Fri, Mar 16, 2012 at 2:39 PM, Rob Crittenden wrote: > Jimmy wrote: >> >> The ca_audit problem was caused by me accidentally moving the >> directory to a backup location. I was cleaning up the logs to make >> reading easier. When I moved the directory back that issue went away. >> No changes were made in the NSS database(s) or any other internal >> workings of IPA. This system is used for very basic user >> authentication, DNS, etc. >> >> I can do the ldif export/import for dogtag. Just from comparing >> everything, it looks like the dogtag db is in >> /var/lib/dirsrv/slapd-PKI-IPA/db/userRoot, is that correct? >> > > The ipaca db > > rob > From sbingram at gmail.com Fri Mar 16 20:06:36 2012 From: sbingram at gmail.com (Stephen Ingram) Date: Fri, 16 Mar 2012 13:06:36 -0700 Subject: [Freeipa-users] compat plug-in and replication In-Reply-To: References: Message-ID: On Fri, Mar 16, 2012 at 12:33 PM, JR Aquino wrote: > On Mar 16, 2012, at 11:54 AM, Stephen Ingram wrote: > > I've seen mention about the compat plug-in causing issues with > replication. In my 2.1.4 installation I notice that the plug-in is > turned on by default. Is compat only required for those supporting NIS > or does it serve another purpose. As I don't use NIS, I'm just > wondering if it's safe to turn off. > > To compliment what Rob mentioned... > > Compat is also generally necessary for any user who wishes to utilize Sudo with FreeIPA. > > Sudo does not natively understand what a 'hostgroup' is, so it can only utilize NIS netgroups for this. ?Care was taken when designing the FreeIPA hostgroup and nis compatibility system such that any hostgroup that is created has a mirrored (and semi hidden) NIS netgroup created. > > This way when you build Sudo rules and reference 'hostgroups', transparently, it is really referencing NIS netgroups stored inside of ldap and provided by the compat / nis plugins. > > Hope this helps clear some stuff up about why one would want compat and nis turned on in FreeIPA. Glad you mentioned this. I would have turned it off just to save space, but I do need sudo. This makes more sense as to why its enabled by default. Very clever design too to hide the complexity from the user. Steve From dpal at redhat.com Fri Mar 16 20:07:18 2012 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 16 Mar 2012 16:07:18 -0400 Subject: [Freeipa-users] compat plug-in and replication In-Reply-To: References: <4F639083.4030707@redhat.com> Message-ID: <4F639D76.2010400@redhat.com> On 03/16/2012 03:55 PM, Stephen Ingram wrote: > On Fri, Mar 16, 2012 at 12:12 PM, Rob Crittenden wrote: >> Stephen Ingram wrote: >>> I've seen mention about the compat plug-in causing issues with >>> replication. In my 2.1.4 installation I notice that the plug-in is >>> turned on by default. Is compat only required for those supporting NIS >>> or does it serve another purpose. As I don't use NIS, I'm just >>> wondering if it's safe to turn off. >> >> The compat plugin wasn't causing problems with replication but we did see >> increasing memory and CPU usage during migration. We now recommend that >> compat be disabled when migrating entries (who needs the overhead anyway). > What do you mean exactly by migrating entries or migration in general? > I'm getting the impression that this is something different than > replication? If you disable compat, then those entries would not > appear in the replica, no? When you migrate from a DS you have to IPA you load data into IPA using ipa migrate-ds command. Some time it takes a while to process the whole DS data you might have. During this time we recommend turning compat and NIS plugins off and then when the migration is complete turning them on if you need them. >> Yes, safe to turn it off depending on what your needs are. There are two >> capabilities provided by the slapi-nis plugin: >> >> 1. Compatibility for older clients such as Solaris which doesn't fully grok >> 2307bis and netgroup triples (ipa-compat-manage enable/disable) >> >> 2. An NIS listener (ipa-nis-manage enable/disable) which requires compat to >> be enabled. >> >> But like I said, shouldn't impact replication at all. It just reformats >> data. > Could you please explain what you mean by reformatting the data? Are > you talking about changing something in the directory? NIS plugin is a flavor of compat plugin. Compat plugin looks at the actual data in the LDAP and creates a view of this data in another format in memory. Via this capability you can create 2307 objects out of 2307bis object or expected SUDO entries from the entries in the internal representation. HTH > Steve > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From JR.Aquino at citrix.com Fri Mar 16 20:11:26 2012 From: JR.Aquino at citrix.com (JR Aquino) Date: Fri, 16 Mar 2012 20:11:26 +0000 Subject: [Freeipa-users] compat plug-in and replication In-Reply-To: References: Message-ID: <88348F23-22BE-47B2-B034-79E75C9C2E3C@citrixonline.com> On Mar 16, 2012, at 1:06 PM, Stephen Ingram wrote: > On Fri, Mar 16, 2012 at 12:33 PM, JR Aquino wrote: >> On Mar 16, 2012, at 11:54 AM, Stephen Ingram wrote: >> >> I've seen mention about the compat plug-in causing issues with >> replication. In my 2.1.4 installation I notice that the plug-in is >> turned on by default. Is compat only required for those supporting NIS >> or does it serve another purpose. As I don't use NIS, I'm just >> wondering if it's safe to turn off. >> >> To compliment what Rob mentioned... >> >> Compat is also generally necessary for any user who wishes to utilize Sudo with FreeIPA. >> >> Sudo does not natively understand what a 'hostgroup' is, so it can only utilize NIS netgroups for this. Care was taken when designing the FreeIPA hostgroup and nis compatibility system such that any hostgroup that is created has a mirrored (and semi hidden) NIS netgroup created. >> >> This way when you build Sudo rules and reference 'hostgroups', transparently, it is really referencing NIS netgroups stored inside of ldap and provided by the compat / nis plugins. >> >> Hope this helps clear some stuff up about why one would want compat and nis turned on in FreeIPA. > > Glad you mentioned this. I would have turned it off just to save > space, but I do need sudo. This makes more sense as to why its enabled > by default. Very clever design too to hide the complexity from the > user. Glad to know the info helps! We did such a good job at keeping that stuff in the background that it sometimes gets overlooked :) To be completely fair... The SSSD team is actively working toward the goal of eventually supporting FreeIPA natively via the Sudo plugin system. In the future it will not be necessary to use compat or nis for Sudo. -JR From dpal at redhat.com Fri Mar 16 20:12:05 2012 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 16 Mar 2012 16:12:05 -0400 Subject: [Freeipa-users] compat plug-in and replication In-Reply-To: References: Message-ID: <4F639E95.4080904@redhat.com> On 03/16/2012 04:06 PM, Stephen Ingram wrote: > On Fri, Mar 16, 2012 at 12:33 PM, JR Aquino wrote: >> On Mar 16, 2012, at 11:54 AM, Stephen Ingram wrote: >> >> I've seen mention about the compat plug-in causing issues with >> replication. In my 2.1.4 installation I notice that the plug-in is >> turned on by default. Is compat only required for those supporting NIS >> or does it serve another purpose. As I don't use NIS, I'm just >> wondering if it's safe to turn off. >> >> To compliment what Rob mentioned... >> >> Compat is also generally necessary for any user who wishes to utilize Sudo with FreeIPA. >> >> Sudo does not natively understand what a 'hostgroup' is, so it can only utilize NIS netgroups for this. Care was taken when designing the FreeIPA hostgroup and nis compatibility system such that any hostgroup that is created has a mirrored (and semi hidden) NIS netgroup created. >> >> This way when you build Sudo rules and reference 'hostgroups', transparently, it is really referencing NIS netgroups stored inside of ldap and provided by the compat / nis plugins. >> >> Hope this helps clear some stuff up about why one would want compat and nis turned on in FreeIPA. > Glad you mentioned this. I would have turned it off just to save > space, but I do need sudo. This makes more sense as to why its enabled > by default. Very clever design too to hide the complexity from the > user. In future we will support native IPA SUDO schema in SSSD. https://fedorahosted.org/sssd/ticket/1108 > Steve > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From g17jimmy at gmail.com Fri Mar 16 20:23:50 2012 From: g17jimmy at gmail.com (Jimmy) Date: Fri, 16 Mar 2012 16:23:50 -0400 Subject: [Freeipa-users] (no subject) In-Reply-To: References: <4F622801.10600@redhat.com> <4F622FC9.8040003@redhat.com> <4F624162.7020806@redhat.com> <4F62554F.1030804@redhat.com> <4F626135.3030402@redhat.com> <4F63575B.6090805@redhat.com> <4F636F7A.4060109@redhat.com> <4F6388E7.9000409@redhat.com> Message-ID: ipa-getcert list shows some ugly output - http://fpaste.org/bV2v/ On Fri, Mar 16, 2012 at 4:05 PM, Jimmy wrote: > I exported/imported the /var/lib/dirsrv/slapd-PKI-IPA/db/userRoot and > that went smoothly but now I see this in /var/log/pki-ca/system: > > 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] > Operation Error - netscape.ldap.LDAPException: error result (32); > matchedDN > ?= o=ipaca > 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] Null > response control > 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] > Operation Error - netscape.ldap.LDAPException: error result (32); > matchedDN > ?= o=ipaca > 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] Null > response control > 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] > Operation Error - netscape.ldap.LDAPException: error result (32); > matchedDN > ?= o=ipaca > 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] Null > response control > 10358.CRLIssuingPoint-MasterCRL - [08/Mar/2012:04:36:29 UTC] [3] [3] > CRLIssuingPoint MasterCRL - Cannot create or store the first CRL in > the > internaldb. The internaldb could be down. Error LDAP operation failure > - cn=MasterCRL,ou=crlIssuingPoints, ou=ca, o=ipaca netscape.ldap.LDAPE > xception: error result (32); matchedDN = o=ipaca > > > catalina.out -- http://fpaste.org/oRQd/ > > ca-debug -- http://fpaste.org/zzFL/ > > Any ideas? > On Fri, Mar 16, 2012 at 2:39 PM, Rob Crittenden wrote: >> Jimmy wrote: >>> >>> The ca_audit problem was caused by me accidentally moving the >>> directory to a backup location. I was cleaning up the logs to make >>> reading easier. When I moved the directory back that issue went away. >>> No changes were made in the NSS database(s) or any other internal >>> workings of IPA. This system is used for very basic user >>> authentication, DNS, etc. >>> >>> I can do the ldif export/import for dogtag. Just from comparing >>> everything, it looks like the dogtag db is in >>> /var/lib/dirsrv/slapd-PKI-IPA/db/userRoot, is that correct? >>> >> >> The ipaca db >> >> rob >> From rcritten at redhat.com Fri Mar 16 20:34:52 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 16 Mar 2012 16:34:52 -0400 Subject: [Freeipa-users] (no subject) In-Reply-To: References: <4F622801.10600@redhat.com> <4F622FC9.8040003@redhat.com> <4F624162.7020806@redhat.com> <4F62554F.1030804@redhat.com> <4F626135.3030402@redhat.com> <4F63575B.6090805@redhat.com> <4F636F7A.4060109@redhat.com> <4F6388E7.9000409@redhat.com> Message-ID: <4F63A3EC.6010205@redhat.com> Jimmy wrote: > ipa-getcert list shows some ugly output - http://fpaste.org/bV2v/ Looks pretty similar to what we've been seeing. The invalid credentials means that dogtag can't validate RA agent cert. This was due to the corrupted database. You'll need to restart the pki-cad process once the LDAP backend is fixed. The trust issues are stranger. To show the certs in those databases: # certutil -L -d /etc/httpd/alias To verify that the cert in there now has all the CA certs it needs: # certutil -V -u V -n Server-Cert -d /etc/httpd/alias -e -f /etc/httpd/alias/pwdfile.txt rob > > On Fri, Mar 16, 2012 at 4:05 PM, Jimmy wrote: >> I exported/imported the /var/lib/dirsrv/slapd-PKI-IPA/db/userRoot and >> that went smoothly but now I see this in /var/log/pki-ca/system: >> >> 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] >> Operation Error - netscape.ldap.LDAPException: error result (32); >> matchedDN >> = o=ipaca >> 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] Null >> response control >> 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] >> Operation Error - netscape.ldap.LDAPException: error result (32); >> matchedDN >> = o=ipaca >> 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] Null >> response control >> 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] >> Operation Error - netscape.ldap.LDAPException: error result (32); >> matchedDN >> = o=ipaca >> 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] Null >> response control >> 10358.CRLIssuingPoint-MasterCRL - [08/Mar/2012:04:36:29 UTC] [3] [3] >> CRLIssuingPoint MasterCRL - Cannot create or store the first CRL in >> the >> internaldb. The internaldb could be down. Error LDAP operation failure >> - cn=MasterCRL,ou=crlIssuingPoints, ou=ca, o=ipaca netscape.ldap.LDAPE >> xception: error result (32); matchedDN = o=ipaca >> >> >> catalina.out -- http://fpaste.org/oRQd/ >> >> ca-debug -- http://fpaste.org/zzFL/ >> >> Any ideas? >> On Fri, Mar 16, 2012 at 2:39 PM, Rob Crittenden wrote: >>> Jimmy wrote: >>>> >>>> The ca_audit problem was caused by me accidentally moving the >>>> directory to a backup location. I was cleaning up the logs to make >>>> reading easier. When I moved the directory back that issue went away. >>>> No changes were made in the NSS database(s) or any other internal >>>> workings of IPA. This system is used for very basic user >>>> authentication, DNS, etc. >>>> >>>> I can do the ldif export/import for dogtag. Just from comparing >>>> everything, it looks like the dogtag db is in >>>> /var/lib/dirsrv/slapd-PKI-IPA/db/userRoot, is that correct? >>>> >>> >>> The ipaca db >>> >>> rob >>> From sbingram at gmail.com Fri Mar 16 20:35:29 2012 From: sbingram at gmail.com (Stephen Ingram) Date: Fri, 16 Mar 2012 13:35:29 -0700 Subject: [Freeipa-users] compat plug-in and replication In-Reply-To: <4F639D76.2010400@redhat.com> References: <4F639083.4030707@redhat.com> <4F639D76.2010400@redhat.com> Message-ID: On Fri, Mar 16, 2012 at 1:07 PM, Dmitri Pal wrote: > On 03/16/2012 03:55 PM, Stephen Ingram wrote: >> On Fri, Mar 16, 2012 at 12:12 PM, Rob Crittenden wrote: >>> Stephen Ingram wrote: >>>> I've seen mention about the compat plug-in causing issues with >>>> replication. In my 2.1.4 installation I notice that the plug-in is >>>> turned on by default. Is compat only required for those supporting NIS >>>> or does it serve another purpose. As I don't use NIS, I'm just >>>> wondering if it's safe to turn off. >>> >>> The compat plugin wasn't causing problems with replication but we did see >>> increasing memory and CPU usage during migration. We now recommend that >>> compat be disabled when migrating entries (who needs the overhead anyway). >> What do you mean exactly by migrating entries or migration in general? >> I'm getting the impression that this is something different than >> replication? If you disable compat, then those entries would not >> appear in the replica, no? > > When you migrate from a DS you have to IPA you load data into IPA using > ipa migrate-ds command. > Some time it takes a while to process the whole DS data you might have. > During this time we recommend turning compat and NIS plugins off and > then when the migration is complete turning them on if you need them. > >>> Yes, safe to turn it off depending on what your needs are. There are two >>> capabilities provided by the slapi-nis plugin: >>> >>> 1. Compatibility for older clients such as Solaris which doesn't fully grok >>> 2307bis and netgroup triples (ipa-compat-manage enable/disable) >>> >>> 2. An NIS listener (ipa-nis-manage enable/disable) which requires compat to >>> be enabled. >>> >>> But like I said, shouldn't impact replication at all. It just reformats >>> data. >> Could you please explain what you mean by reformatting the data? Are >> you talking about changing something in the directory? > > NIS plugin is a flavor of compat plugin. > Compat plugin looks at the actual data in the LDAP and creates a view of > this data in another format in memory. > Via this capability you can create 2307 objects out of 2307bis object or > expected SUDO entries from the entries in the internal representation. > > HTH Much better. Thank you. From sbingram at gmail.com Fri Mar 16 20:44:46 2012 From: sbingram at gmail.com (Stephen Ingram) Date: Fri, 16 Mar 2012 13:44:46 -0700 Subject: [Freeipa-users] compat plug-in and replication In-Reply-To: <88348F23-22BE-47B2-B034-79E75C9C2E3C@citrixonline.com> References: <88348F23-22BE-47B2-B034-79E75C9C2E3C@citrixonline.com> Message-ID: On Fri, Mar 16, 2012 at 1:11 PM, JR Aquino wrote: > On Mar 16, 2012, at 1:06 PM, Stephen Ingram wrote: > >> On Fri, Mar 16, 2012 at 12:33 PM, JR Aquino wrote: >>> On Mar 16, 2012, at 11:54 AM, Stephen Ingram wrote: >>> >>> I've seen mention about the compat plug-in causing issues with >>> replication. In my 2.1.4 installation I notice that the plug-in is >>> turned on by default. Is compat only required for those supporting NIS >>> or does it serve another purpose. As I don't use NIS, I'm just >>> wondering if it's safe to turn off. >>> >>> To compliment what Rob mentioned... >>> >>> Compat is also generally necessary for any user who wishes to utilize Sudo with FreeIPA. >>> >>> Sudo does not natively understand what a 'hostgroup' is, so it can only utilize NIS netgroups for this. ?Care was taken when designing the FreeIPA hostgroup and nis compatibility system such that any hostgroup that is created has a mirrored (and semi hidden) NIS netgroup created. >>> >>> This way when you build Sudo rules and reference 'hostgroups', transparently, it is really referencing NIS netgroups stored inside of ldap and provided by the compat / nis plugins. >>> >>> Hope this helps clear some stuff up about why one would want compat and nis turned on in FreeIPA. >> >> Glad you mentioned this. I would have turned it off just to save >> space, but I do need sudo. This makes more sense as to why its enabled >> by default. Very clever design too to hide the complexity from the >> user. > > Glad to know the info helps! > > We did such a good job at keeping that stuff in the background that it sometimes gets overlooked :) > > To be completely fair... The SSSD team is actively working toward the goal of eventually supporting FreeIPA natively via the Sudo plugin system. > > In the future it will not be necessary to use compat or nis for Sudo. That was going to be my next question. It is great that as this project moves forward many of these tools that have been around for a long time are being reworked for the better. I continue to be amazed at the *reach* of FreeIPA and the amount I learn from just watching this list. Steve From g17jimmy at gmail.com Fri Mar 16 20:56:21 2012 From: g17jimmy at gmail.com (Jimmy) Date: Fri, 16 Mar 2012 16:56:21 -0400 Subject: [Freeipa-users] (no subject) In-Reply-To: <4F63A3EC.6010205@redhat.com> References: <4F622801.10600@redhat.com> <4F622FC9.8040003@redhat.com> <4F624162.7020806@redhat.com> <4F62554F.1030804@redhat.com> <4F626135.3030402@redhat.com> <4F63575B.6090805@redhat.com> <4F636F7A.4060109@redhat.com> <4F6388E7.9000409@redhat.com> <4F63A3EC.6010205@redhat.com> Message-ID: I actually shut down IPA to do the export and restarted after I imported. certutil -L -d /etc/httpd/alias Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI Server-Cert u,u,u ABC.XYZIPA CA CT,C,C ipaCert u,u,u Signing-Cert u,u,u certutil -V -u V -n Server-Cert -d /etc/httpd/alias -e -f /etc/httpd/alias/pwdfile.txt certutil: certificate is valid How's that look? On Fri, Mar 16, 2012 at 4:34 PM, Rob Crittenden wrote: > Jimmy wrote: >> >> ipa-getcert list shows some ugly output - http://fpaste.org/bV2v/ > > > Looks pretty similar to what we've been seeing. The invalid credentials > means that dogtag can't validate RA agent cert. This was due to the > corrupted database. You'll need to restart the pki-cad process once the LDAP > backend is fixed. > > The trust issues are stranger. To show the certs in those databases: > > # certutil -L -d /etc/httpd/alias > > To verify that the cert in there now has all the CA certs it needs: > # certutil -V -u V -n Server-Cert -d /etc/httpd/alias -e -f > /etc/httpd/alias/pwdfile.txt > > rob > > >> >> On Fri, Mar 16, 2012 at 4:05 PM, Jimmy ?wrote: >>> >>> I exported/imported the /var/lib/dirsrv/slapd-PKI-IPA/db/userRoot and >>> that went smoothly but now I see this in /var/log/pki-ca/system: >>> >>> 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] >>> Operation Error - netscape.ldap.LDAPException: error result (32); >>> matchedDN >>> ?= o=ipaca >>> 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] Null >>> response control >>> 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] >>> Operation Error - netscape.ldap.LDAPException: error result (32); >>> matchedDN >>> ?= o=ipaca >>> 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] Null >>> response control >>> 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] >>> Operation Error - netscape.ldap.LDAPException: error result (32); >>> matchedDN >>> ?= o=ipaca >>> 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] Null >>> response control >>> 10358.CRLIssuingPoint-MasterCRL - [08/Mar/2012:04:36:29 UTC] [3] [3] >>> CRLIssuingPoint MasterCRL - Cannot create or store the first CRL in >>> the >>> internaldb. The internaldb could be down. Error LDAP operation failure >>> - cn=MasterCRL,ou=crlIssuingPoints, ou=ca, o=ipaca netscape.ldap.LDAPE >>> xception: error result (32); matchedDN = o=ipaca >>> >>> >>> catalina.out -- http://fpaste.org/oRQd/ >>> >>> ca-debug -- http://fpaste.org/zzFL/ >>> >>> Any ideas? >>> On Fri, Mar 16, 2012 at 2:39 PM, Rob Crittenden >>> ?wrote: >>>> >>>> Jimmy wrote: >>>>> >>>>> >>>>> The ca_audit problem was caused by me accidentally moving the >>>>> directory to a backup location. I was cleaning up the logs to make >>>>> reading easier. When I moved the directory back that issue went away. >>>>> No changes were made in the NSS database(s) or any other internal >>>>> workings of IPA. This system is used for very basic user >>>>> authentication, DNS, etc. >>>>> >>>>> I can do the ldif export/import for dogtag. Just from comparing >>>>> everything, it looks like the dogtag db is in >>>>> /var/lib/dirsrv/slapd-PKI-IPA/db/userRoot, is that correct? >>>>> >>>> >>>> The ipaca db >>>> >>>> rob >>>> > From rcritten at redhat.com Fri Mar 16 21:30:13 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 16 Mar 2012 17:30:13 -0400 Subject: [Freeipa-users] (no subject) In-Reply-To: References: <4F622FC9.8040003@redhat.com> <4F624162.7020806@redhat.com> <4F62554F.1030804@redhat.com> <4F626135.3030402@redhat.com> <4F63575B.6090805@redhat.com> <4F636F7A.4060109@redhat.com> <4F6388E7.9000409@redhat.com> <4F63A3EC.6010205@redhat.com> Message-ID: <4F63B0E5.7030104@redhat.com> Jimmy wrote: > I actually shut down IPA to do the export and restarted after I imported. > > certutil -L -d /etc/httpd/alias > Certificate Nickname Trust Attributes > SSL,S/MIME,JAR/XPI > Server-Cert u,u,u > ABC.XYZIPA CA CT,C,C > ipaCert u,u,u > Signing-Cert u,u,u > > certutil -V -u V -n Server-Cert -d /etc/httpd/alias -e -f > /etc/httpd/alias/pwdfile.txt > certutil: certificate is valid > > How's that look? That's what it's supposed to look like. Is Apache logging a failure or maybe that is coming from dogtag through Apache... rob > > > On Fri, Mar 16, 2012 at 4:34 PM, Rob Crittenden wrote: >> Jimmy wrote: >>> >>> ipa-getcert list shows some ugly output - http://fpaste.org/bV2v/ >> >> >> Looks pretty similar to what we've been seeing. The invalid credentials >> means that dogtag can't validate RA agent cert. This was due to the >> corrupted database. You'll need to restart the pki-cad process once the LDAP >> backend is fixed. >> >> The trust issues are stranger. To show the certs in those databases: >> >> # certutil -L -d /etc/httpd/alias >> >> To verify that the cert in there now has all the CA certs it needs: >> # certutil -V -u V -n Server-Cert -d /etc/httpd/alias -e -f >> /etc/httpd/alias/pwdfile.txt >> >> rob >> >> >>> >>> On Fri, Mar 16, 2012 at 4:05 PM, Jimmy wrote: >>>> >>>> I exported/imported the /var/lib/dirsrv/slapd-PKI-IPA/db/userRoot and >>>> that went smoothly but now I see this in /var/log/pki-ca/system: >>>> >>>> 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] >>>> Operation Error - netscape.ldap.LDAPException: error result (32); >>>> matchedDN >>>> = o=ipaca >>>> 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] Null >>>> response control >>>> 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] >>>> Operation Error - netscape.ldap.LDAPException: error result (32); >>>> matchedDN >>>> = o=ipaca >>>> 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] Null >>>> response control >>>> 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] >>>> Operation Error - netscape.ldap.LDAPException: error result (32); >>>> matchedDN >>>> = o=ipaca >>>> 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] Null >>>> response control >>>> 10358.CRLIssuingPoint-MasterCRL - [08/Mar/2012:04:36:29 UTC] [3] [3] >>>> CRLIssuingPoint MasterCRL - Cannot create or store the first CRL in >>>> the >>>> internaldb. The internaldb could be down. Error LDAP operation failure >>>> - cn=MasterCRL,ou=crlIssuingPoints, ou=ca, o=ipaca netscape.ldap.LDAPE >>>> xception: error result (32); matchedDN = o=ipaca >>>> >>>> >>>> catalina.out -- http://fpaste.org/oRQd/ >>>> >>>> ca-debug -- http://fpaste.org/zzFL/ >>>> >>>> Any ideas? >>>> On Fri, Mar 16, 2012 at 2:39 PM, Rob Crittenden >>>> wrote: >>>>> >>>>> Jimmy wrote: >>>>>> >>>>>> >>>>>> The ca_audit problem was caused by me accidentally moving the >>>>>> directory to a backup location. I was cleaning up the logs to make >>>>>> reading easier. When I moved the directory back that issue went away. >>>>>> No changes were made in the NSS database(s) or any other internal >>>>>> workings of IPA. This system is used for very basic user >>>>>> authentication, DNS, etc. >>>>>> >>>>>> I can do the ldif export/import for dogtag. Just from comparing >>>>>> everything, it looks like the dogtag db is in >>>>>> /var/lib/dirsrv/slapd-PKI-IPA/db/userRoot, is that correct? >>>>>> >>>>> >>>>> The ipaca db >>>>> >>>>> rob >>>>> >> From marco.pizzoli at gmail.com Sat Mar 17 10:12:36 2012 From: marco.pizzoli at gmail.com (Marco Pizzoli) Date: Sat, 17 Mar 2012 11:12:36 +0100 Subject: [Freeipa-users] Doubt on FreeIPA LDAP extensibility Message-ID: Hi guys, I extended my set of LDAP objectClasses associated to users by adding my new objectClass to my cn=ipaConfig LDAP entry, the ipaUserObjectClasses attribute. Then, I created a new user with the web ui and I see the new objectClass associated with that user, but as structural instead of auxiliary. I don't know why, could you help me? Same thing happened for my groups. I added 3 objectClasses and now I see all of them as structural. I would understand an answer: all objectClasses eventually result as structural, but so why, for example, the ipaObject is still an auxiliary objectClass? Thanks a lot as usual Marco -------------- next part -------------- An HTML attachment was scrubbed... URL: From marco.pizzoli at gmail.com Sat Mar 17 10:24:26 2012 From: marco.pizzoli at gmail.com (Marco Pizzoli) Date: Sat, 17 Mar 2012 11:24:26 +0100 Subject: [Freeipa-users] Migration from LDAP to IPA Message-ID: Hi, by looking at the RHEL6 IPA documentation I can find instructions on how migrate from an existing LDAP server to IPA. It's cited the step: ipa config-mod --enable-migration=TRUE Please, could you explain to me what is the internal scope of this command? Also, is it normal that (always in the doc) after executing "ipa migrate-ds" I don't have to revert to ipa config-mod --enable-migration=FALSE Thanks again Marco -------------- next part -------------- An HTML attachment was scrubbed... URL: From marco.pizzoli at gmail.com Sat Mar 17 11:36:45 2012 From: marco.pizzoli at gmail.com (Marco Pizzoli) Date: Sat, 17 Mar 2012 12:36:45 +0100 Subject: [Freeipa-users] Problem in "ipa migrate-ds" procedure Message-ID: Hi guys, I'm trying to migrate my ldap user base to freeipa. I'm using the last Release Candidate. I already changed "ipa config-mod --enable-migration=TRUE" This is what I have: ipa -v migrate-ds --bind-dn="cn=manager,dc=mydc1,dc=mydc2.it" --user-container="ou=people,dc=mydc1,dc=mydc2.it" --user-objectclass=inetOrgPerson --group-container="ou=groups,dc=mydc1,dc= mydc2.it" --group-objectclass=posixGroup --base-dn="dc=mydc1,dc=mydc2.it" --with-compat ldap://ldap01 ipa: INFO: trying https://freeipa01.unix.mydomain.it/ipa/xml Password: ipa: INFO: Forwarding 'migrate_ds' to server u' http://freeipa01.unix.mydomain.it/ipa/xml' ipa: ERROR: Container for group not found at ou=groups,dc=mydc1,dc=mydc2.it I looked at my ldap server logs and I found out that the search executed has scope=1. Actually both for users and groups. This is a problem for me, in having a lot of subtrees (ou) in which my users and groups are. Is there a way to manage this? Thanks in advance Marco P.s. As a side note, I suppose there's a typo in the verbose message I obtain in my output: ipa: INFO: Forwarding 'migrate_ds' to server *u*' http://freeipa01.unix.mydomain.it/ipa/xml' -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Sat Mar 17 18:16:49 2012 From: simo at redhat.com (Simo Sorce) Date: Sat, 17 Mar 2012 14:16:49 -0400 Subject: [Freeipa-users] Doubt on FreeIPA LDAP extensibility In-Reply-To: References: Message-ID: <1332008209.9238.328.camel@willson.li.ssimo.org> On Sat, 2012-03-17 at 11:12 +0100, Marco Pizzoli wrote: > Hi guys, > > I extended my set of LDAP objectClasses associated to users by adding > my new objectClass to my cn=ipaConfig LDAP entry, the > ipaUserObjectClasses attribute. > Then, I created a new user with the web ui and I see the new > objectClass associated with that user, but as structural instead of > auxiliary. I don't know why, could you help me? > > Same thing happened for my groups. I added 3 objectClasses and now I > see all of them as structural. I would understand an answer: all > objectClasses eventually result as structural, but so why, for > example, the ipaObject is still an auxiliary objectClass? The objectClass type depends on the schema. It is not something that changes after you assign it to an object. Simo. -- Simo Sorce * Red Hat, Inc * New York From marco.pizzoli at gmail.com Sun Mar 18 12:59:08 2012 From: marco.pizzoli at gmail.com (Marco Pizzoli) Date: Sun, 18 Mar 2012 13:59:08 +0100 Subject: [Freeipa-users] Doubt on FreeIPA LDAP extensibility In-Reply-To: <1332008209.9238.328.camel@willson.li.ssimo.org> References: <1332008209.9238.328.camel@willson.li.ssimo.org> Message-ID: Hi Simo, On Sat, Mar 17, 2012 at 7:16 PM, Simo Sorce wrote: > On Sat, 2012-03-17 at 11:12 +0100, Marco Pizzoli wrote: > > Hi guys, > > > > I extended my set of LDAP objectClasses associated to users by adding > > my new objectClass to my cn=ipaConfig LDAP entry, the > > ipaUserObjectClasses attribute. > > Then, I created a new user with the web ui and I see the new > > objectClass associated with that user, but as structural instead of > > auxiliary. I don't know why, could you help me? > > > > Same thing happened for my groups. I added 3 objectClasses and now I > > see all of them as structural. I would understand an answer: all > > objectClasses eventually result as structural, but so why, for > > example, the ipaObject is still an auxiliary objectClass? > > The objectClass type depends on the schema. It is not something that > changes after you assign it to an object. > Yes, your answer surely does make sense. My question was triggered by the fact that, AFAICS, not all objectClasses are structural as well. In fact I can see that, for my group object, the objectClass "ipaobject" has been defined as auxiliary, while others structural. For users, I see that *only my objectClass* is defined as structural. All others as auxiliary. In attachment you can see 2 images that immediately represent what I'm trying to explain. If this was the intended behaviour, I would be really interested in knowing what is the rationale behind this. Only curiousity, as usual :-) Thanks again for your patience! Marco > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: User_objectClasses.PNG Type: image/png Size: 22071 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Group_objectClasses.PNG Type: image/png Size: 15950 bytes Desc: not available URL: From dpal at redhat.com Sun Mar 18 16:41:12 2012 From: dpal at redhat.com (Dmitri Pal) Date: Sun, 18 Mar 2012 12:41:12 -0400 Subject: [Freeipa-users] Doubt on FreeIPA LDAP extensibility In-Reply-To: References: <1332008209.9238.328.camel@willson.li.ssimo.org> Message-ID: <4F661028.9030708@redhat.com> On 03/18/2012 08:59 AM, Marco Pizzoli wrote: > Hi Simo, > > On Sat, Mar 17, 2012 at 7:16 PM, Simo Sorce > wrote: > > On Sat, 2012-03-17 at 11:12 +0100, Marco Pizzoli wrote: > > Hi guys, > > > > I extended my set of LDAP objectClasses associated to users by > adding > > my new objectClass to my cn=ipaConfig LDAP entry, the > > ipaUserObjectClasses attribute. > > Then, I created a new user with the web ui and I see the new > > objectClass associated with that user, but as structural instead of > > auxiliary. I don't know why, could you help me? > > > > Same thing happened for my groups. I added 3 objectClasses and now I > > see all of them as structural. I would understand an answer: all > > objectClasses eventually result as structural, but so why, for > > example, the ipaObject is still an auxiliary objectClass? > > The objectClass type depends on the schema. It is not something that > changes after you assign it to an object. > > > Yes, your answer surely does make sense. > > My question was triggered by the fact that, AFAICS, not all > objectClasses are structural as well. > In fact I can see that, for my group object, the objectClass > "ipaobject" has been defined as auxiliary, while others structural. > For users, I see that *only my objectClass* is defined as structural. > All others as auxiliary. > > In attachment you can see 2 images that immediately represent what I'm > trying to explain. > > If this was the intended behaviour, I would be really interested in > knowing what is the rationale behind this. > Only curiousity, as usual :-) > > Thanks again for your patience! AFAIU the object classes that are added to users and groups need to be first defined in the schema. I assume you have done so otherwise all sorts of errors would have shown up. Am I correct? I do not recognize the object classes as standard object classes. But might knowledge might be limited. Can you put show how you defined these new object classes in schema? You might have not specified the type and it defaulted to structural. > Marco > > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, 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 Sun Mar 18 16:47:51 2012 From: dpal at redhat.com (Dmitri Pal) Date: Sun, 18 Mar 2012 12:47:51 -0400 Subject: [Freeipa-users] Migration from LDAP to IPA In-Reply-To: References: Message-ID: <4F6611B7.9060703@redhat.com> On 03/17/2012 06:24 AM, Marco Pizzoli wrote: > Hi, > by looking at the RHEL6 IPA documentation I can find instructions on > how migrate from an existing LDAP server to IPA. > > It's cited the step: > ipa config-mod --enable-migration=TRUE > > Please, could you explain to me what is the internal scope of this > command? > > Also, is it normal that (always in the doc) after executing "ipa > migrate-ds" I don't have to revert to > ipa config-mod --enable-migration=FALSE > This enables password migration using SSSD or a special web page. It turns on migration mode. The issue is when you load the LDIF form the external DS you still need to to generate kerberos hashes for every user's password. But to do this you need to have password in clear. So you options are: to force users to change their password (which is not pleasant), give users a page to authenticate (it gets enabled when you enable migration), allow SSSD to perform a seeming-less migration by realizing that the user does not have a kerberos hash, authenticating via ldap causing to create a hash and then authenticating using Kerberos (turned on by this migration flag). So the last two migration methods are enabled when you execute the command. You need to turn it off when all users have kerberos passwords. Deon, if this is not clear in the documentation, I think we should add this clarification. > > Thanks again > Marco > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, 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 Sun Mar 18 16:49:35 2012 From: dpal at redhat.com (Dmitri Pal) Date: Sun, 18 Mar 2012 12:49:35 -0400 Subject: [Freeipa-users] Problem in "ipa migrate-ds" procedure In-Reply-To: References: Message-ID: <4F66121F.3090200@redhat.com> On 03/17/2012 07:36 AM, Marco Pizzoli wrote: > Hi guys, > I'm trying to migrate my ldap user base to freeipa. I'm using the last > Release Candidate. > > I already changed "ipa config-mod --enable-migration=TRUE" > This is what I have: > > ipa -v migrate-ds --bind-dn="cn=manager,dc=mydc1,dc=mydc2.it > " --user-container="ou=people,dc=mydc1,dc=mydc2.it > " --user-objectclass=inetOrgPerson > --group-container="ou=groups,dc=mydc1,dc=mydc2.it " > --group-objectclass=posixGroup --base-dn="dc=mydc1,dc=mydc2.it > " --with-compat ldap://ldap01 > ipa: INFO: trying https://freeipa01.unix.mydomain.it/ipa/xml > Password: > ipa: INFO: Forwarding 'migrate_ds' to server > u'http://freeipa01.unix.mydomain.it/ipa/xml' > ipa: ERROR: Container for group not found at > ou=groups,dc=mydc1,dc=mydc2.it > > I looked at my ldap server logs and I found out that the search > executed has scope=1. Actually both for users and groups. This is a > problem for me, in having a lot of subtrees (ou) in which my users and > groups are. Is there a way to manage this? > > Thanks in advance > Marco > > P.s. As a side note, I suppose there's a typo in the verbose message I > obtain in my output: > ipa: INFO: Forwarding 'migrate_ds' to server > *u*'http://freeipa01.unix.mydomain.it/ipa/xml' Please open tickets for both issues. > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From marco.pizzoli at gmail.com Sun Mar 18 17:00:01 2012 From: marco.pizzoli at gmail.com (Marco Pizzoli) Date: Sun, 18 Mar 2012 18:00:01 +0100 Subject: [Freeipa-users] Doubt on FreeIPA LDAP extensibility In-Reply-To: <4F661028.9030708@redhat.com> References: <1332008209.9238.328.camel@willson.li.ssimo.org> <4F661028.9030708@redhat.com> Message-ID: Hi Dmitri, On Sun, Mar 18, 2012 at 5:41 PM, Dmitri Pal wrote: > ** > On 03/18/2012 08:59 AM, Marco Pizzoli wrote: > > Hi Simo, > > On Sat, Mar 17, 2012 at 7:16 PM, Simo Sorce wrote: > >> On Sat, 2012-03-17 at 11:12 +0100, Marco Pizzoli wrote: >> > Hi guys, >> > >> > I extended my set of LDAP objectClasses associated to users by adding >> > my new objectClass to my cn=ipaConfig LDAP entry, the >> > ipaUserObjectClasses attribute. >> > Then, I created a new user with the web ui and I see the new >> > objectClass associated with that user, but as structural instead of >> > auxiliary. I don't know why, could you help me? >> > >> > Same thing happened for my groups. I added 3 objectClasses and now I >> > see all of them as structural. I would understand an answer: all >> > objectClasses eventually result as structural, but so why, for >> > example, the ipaObject is still an auxiliary objectClass? >> >> The objectClass type depends on the schema. It is not something that >> changes after you assign it to an object. >> > > Yes, your answer surely does make sense. > > My question was triggered by the fact that, AFAICS, not all objectClasses > are structural as well. > In fact I can see that, for my group object, the objectClass "ipaobject" > has been defined as auxiliary, while others structural. > For users, I see that *only my objectClass* is defined as structural. All > others as auxiliary. > > In attachment you can see 2 images that immediately represent what I'm > trying to explain. > > If this was the intended behaviour, I would be really interested in > knowing what is the rationale behind this. > Only curiousity, as usual :-) > > Thanks again for your patience! > > > AFAIU the object classes that are added to users and groups need to be > first defined in the schema. > I assume you have done so otherwise all sorts of errors would have shown > up. Am I correct? > Exact. I followed the instructions on extending the schema on 389-ds, by inserting a file in my /etc/dirsrv//schema dir. Everything went ok, and I can see from phpldapadmin that the DSA correctly present my objectClasses as available to use for extending objects. > I do not recognize the object classes as standard object classes. But > might knowledge might be limited. > Exact, they are "mine" objects, under a reserved OID number. > Can you put show how you defined these new object classes in schema? You > might have not specified the type and it defaulted to structural. > This was a schema file created for OpenLDAP and which is currently in production. I used the script posted on the 389-ds HowTo for the migration from OpenLDAP schema files to 389-ds format. Here you can find it. A little camouflated, of course. [root at freeipa01 ~]# cat /etc/dirsrv/slapd-UNIX-MYDOMAIN-IT/schema/98myfile.ldif dn: cn=schema attributetypes: ( 1.3.6.1.4.1.36005.0.2.4.4 NAME 'xxxUfficio' DESC 'Ufficio di appartenenza degli utenti XXX' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 USAGE userApplications ) objectclasses: ( 1.3.6.1.4.1.36005.0.2.6.2 NAME 'xxxPeopleAttributes' SUP top AUXILIARY DESC 'Definizione di attributi specifici per gli utenti XXX' MAY ( xxxUfficio )) attributetypes: ( 1.3.6.1.4.1.36005.0.2.4.1 NAME 'xxxProgetto' DESC 'Nome del macro-progetto associato a questo gruppo LDAP' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 USAGE userApplications ) attributetypes: ( 1.3.6.1.4.1.36005.0.2.4.2 NAME 'xxxAmbiente' DESC 'Nome di ambiente SVIL-TEST-VALID-PROD associato al progetto' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 USAGE userApplications ) attributetypes: ( 1.3.6.1.4.1.36005.0.2.4.5 NAME 'xxxTipoGruppo' DESC 'Tipologia di gruppo' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 USAGE userApplications ) objectclasses: ( 1.3.6.1.4.1.36005.0.2.6.3 NAME 'xxxGroupsAttributes' SUP top AUXILIARY DESC 'Definizione di attributi specifici per i gruppi XXX' MAY ( xxxProgetto $ xxxAmbiente $ xxxTipoGruppo )) attributetypes: ( 1.3.6.1.4.1.36005.0.2.4.6 NAME 'xxxWebminAmbiente' DESC 'Ufficio di appartenenza degli utenti XXX' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 USAGE userApplications ) objectclasses: ( 1.3.6.1.4.1.36005.0.2.6.4 NAME 'xxxWebminAttributes' SUP top AUXILIARY DESC 'Definizione di attributi specifici per gli oggetti Webmin' MAY ( xxxWebminAmbiente )) attributetypes: ( 1.3.6.1.4.1.36005.0.2.4.3 NAME 'xxxDB2GruppiPrivilegi' DESC 'Tipologia di gruppo creato per accesso al DB2' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 USAGE userApplications ) objectclasses: ( 1.3.6.1.4.1.36005.0.2.6.5 NAME 'xxxDB2GroupsAttributes' SUP top AUXILIARY DESC 'Definizione di attributi specifici per i gruppi DB2' MAY ( xxxDB2GruppiPrivilegi )) objectclasses: ( 1.3.6.1.4.1.36005.0.2.6.1 NAME 'xxxAttributes' SUP top AUXILIARY DESC 'Definizione di attributi specifici per utilizzo interno' MAY ( xxxProgetto $ xxxAmbiente $ xxxTipoGruppo $ xxxDB2GruppiPrivilegi )) As you can see, they are explicitly declared as AUXILIARY. Thanks again Marco -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Sun Mar 18 17:04:45 2012 From: dpal at redhat.com (Dmitri Pal) Date: Sun, 18 Mar 2012 13:04:45 -0400 Subject: [Freeipa-users] Doubt on FreeIPA LDAP extensibility In-Reply-To: References: <1332008209.9238.328.camel@willson.li.ssimo.org> <4F661028.9030708@redhat.com> Message-ID: <4F6615AD.7070306@redhat.com> On 03/18/2012 01:00 PM, Marco Pizzoli wrote: > Hi Dmitri, > > On Sun, Mar 18, 2012 at 5:41 PM, Dmitri Pal > wrote: > > On 03/18/2012 08:59 AM, Marco Pizzoli wrote: >> Hi Simo, >> >> On Sat, Mar 17, 2012 at 7:16 PM, Simo Sorce > > wrote: >> >> On Sat, 2012-03-17 at 11:12 +0100, Marco Pizzoli wrote: >> > Hi guys, >> > >> > I extended my set of LDAP objectClasses associated to users >> by adding >> > my new objectClass to my cn=ipaConfig LDAP entry, the >> > ipaUserObjectClasses attribute. >> > Then, I created a new user with the web ui and I see the new >> > objectClass associated with that user, but as structural >> instead of >> > auxiliary. I don't know why, could you help me? >> > >> > Same thing happened for my groups. I added 3 objectClasses >> and now I >> > see all of them as structural. I would understand an >> answer: all >> > objectClasses eventually result as structural, but so why, for >> > example, the ipaObject is still an auxiliary objectClass? >> >> The objectClass type depends on the schema. It is not >> something that >> changes after you assign it to an object. >> >> >> Yes, your answer surely does make sense. >> >> My question was triggered by the fact that, AFAICS, not all >> objectClasses are structural as well. >> In fact I can see that, for my group object, the objectClass >> "ipaobject" has been defined as auxiliary, while others structural. >> For users, I see that *only my objectClass* is defined as >> structural. All others as auxiliary. >> >> In attachment you can see 2 images that immediately represent >> what I'm trying to explain. >> >> If this was the intended behaviour, I would be really interested >> in knowing what is the rationale behind this. >> Only curiousity, as usual :-) >> >> Thanks again for your patience! > > AFAIU the object classes that are added to users and groups need > to be first defined in the schema. > I assume you have done so otherwise all sorts of errors would have > shown up. Am I correct? > > > Exact. I followed the instructions on extending the schema on 389-ds, > by inserting a file in my /etc/dirsrv//schema dir. > Everything went ok, and I can see from phpldapadmin that the DSA > correctly present my objectClasses as available to use for extending > objects. > > > I do not recognize the object classes as standard object classes. > But might knowledge might be limited. > > > Exact, they are "mine" objects, under a reserved OID number. > > > Can you put show how you defined these new object classes in > schema? You might have not specified the type and it defaulted to > structural. > > > This was a schema file created for OpenLDAP and which is currently in > production. > I used the script posted on the 389-ds HowTo for the migration from > OpenLDAP schema files to 389-ds format. > Here you can find it. A little camouflated, of course. > > [root at freeipa01 ~]# cat > /etc/dirsrv/slapd-UNIX-MYDOMAIN-IT/schema/98myfile.ldif > dn: cn=schema > attributetypes: ( 1.3.6.1.4.1.36005.0.2.4.4 NAME 'xxxUfficio' DESC > 'Ufficio di appartenenza degli utenti XXX' EQUALITY caseIgnoreMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 USAGE userApplications ) > objectclasses: ( 1.3.6.1.4.1.36005.0.2.6.2 NAME 'xxxPeopleAttributes' > SUP top AUXILIARY DESC 'Definizione di attributi specifici per gli > utenti XXX' MAY ( xxxUfficio )) > attributetypes: ( 1.3.6.1.4.1.36005.0.2.4.1 NAME 'xxxProgetto' DESC > 'Nome del macro-progetto associato a questo gruppo LDAP' EQUALITY > caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 USAGE > userApplications ) > attributetypes: ( 1.3.6.1.4.1.36005.0.2.4.2 NAME 'xxxAmbiente' DESC > 'Nome di ambiente SVIL-TEST-VALID-PROD associato al progetto' EQUALITY > caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 USAGE > userApplications ) > attributetypes: ( 1.3.6.1.4.1.36005.0.2.4.5 NAME 'xxxTipoGruppo' DESC > 'Tipologia di gruppo' EQUALITY caseIgnoreMatch SYNTAX > 1.3.6.1.4.1.1466.115.121.1.15 USAGE userApplications ) > objectclasses: ( 1.3.6.1.4.1.36005.0.2.6.3 NAME 'xxxGroupsAttributes' > SUP top AUXILIARY DESC 'Definizione di attributi specifici per i > gruppi XXX' MAY ( xxxProgetto $ xxxAmbiente $ xxxTipoGruppo )) > attributetypes: ( 1.3.6.1.4.1.36005.0.2.4.6 NAME 'xxxWebminAmbiente' > DESC 'Ufficio di appartenenza degli utenti XXX' EQUALITY > caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 USAGE > userApplications ) > objectclasses: ( 1.3.6.1.4.1.36005.0.2.6.4 NAME 'xxxWebminAttributes' > SUP top AUXILIARY DESC 'Definizione di attributi specifici per gli > oggetti Webmin' MAY ( xxxWebminAmbiente )) > attributetypes: ( 1.3.6.1.4.1.36005.0.2.4.3 NAME > 'xxxDB2GruppiPrivilegi' DESC 'Tipologia di gruppo creato per accesso > al DB2' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 > USAGE userApplications ) > objectclasses: ( 1.3.6.1.4.1.36005.0.2.6.5 NAME > 'xxxDB2GroupsAttributes' SUP top AUXILIARY DESC 'Definizione di > attributi specifici per i gruppi DB2' MAY ( xxxDB2GruppiPrivilegi )) > objectclasses: ( 1.3.6.1.4.1.36005.0.2.6.1 NAME 'xxxAttributes' SUP > top AUXILIARY DESC 'Definizione di attributi specifici per utilizzo > interno' MAY ( xxxProgetto $ xxxAmbiente $ xxxTipoGruppo $ > xxxDB2GruppiPrivilegi )) > > As you can see, they are explicitly declared as AUXILIARY. > OK. Then it seems like a bug on our side ;-) Please file a ticket and attached the info provided here. Thanks for your efforts. They really help us to make the project better. > Thanks again > Marco > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From marco.pizzoli at gmail.com Sun Mar 18 17:16:42 2012 From: marco.pizzoli at gmail.com (Marco Pizzoli) Date: Sun, 18 Mar 2012 18:16:42 +0100 Subject: [Freeipa-users] Doubt on FreeIPA LDAP extensibility In-Reply-To: <4F6615AD.7070306@redhat.com> References: <1332008209.9238.328.camel@willson.li.ssimo.org> <4F661028.9030708@redhat.com> <4F6615AD.7070306@redhat.com> Message-ID: On Sun, Mar 18, 2012 at 6:04 PM, Dmitri Pal wrote: > ** > On 03/18/2012 01:00 PM, Marco Pizzoli wrote: > > Hi Dmitri, > > On Sun, Mar 18, 2012 at 5:41 PM, Dmitri Pal wrote: > >> On 03/18/2012 08:59 AM, Marco Pizzoli wrote: >> >> Hi Simo, >> >> On Sat, Mar 17, 2012 at 7:16 PM, Simo Sorce wrote: >> >>> On Sat, 2012-03-17 at 11:12 +0100, Marco Pizzoli wrote: >>> > Hi guys, >>> > >>> > I extended my set of LDAP objectClasses associated to users by adding >>> > my new objectClass to my cn=ipaConfig LDAP entry, the >>> > ipaUserObjectClasses attribute. >>> > Then, I created a new user with the web ui and I see the new >>> > objectClass associated with that user, but as structural instead of >>> > auxiliary. I don't know why, could you help me? >>> > >>> > Same thing happened for my groups. I added 3 objectClasses and now I >>> > see all of them as structural. I would understand an answer: all >>> > objectClasses eventually result as structural, but so why, for >>> > example, the ipaObject is still an auxiliary objectClass? >>> >>> The objectClass type depends on the schema. It is not something that >>> changes after you assign it to an object. >>> >> >> Yes, your answer surely does make sense. >> >> My question was triggered by the fact that, AFAICS, not all objectClasses >> are structural as well. >> In fact I can see that, for my group object, the objectClass "ipaobject" >> has been defined as auxiliary, while others structural. >> For users, I see that *only my objectClass* is defined as structural. All >> others as auxiliary. >> >> In attachment you can see 2 images that immediately represent what I'm >> trying to explain. >> >> If this was the intended behaviour, I would be really interested in >> knowing what is the rationale behind this. >> Only curiousity, as usual :-) >> >> Thanks again for your patience! >> >> >> AFAIU the object classes that are added to users and groups need to be >> first defined in the schema. >> I assume you have done so otherwise all sorts of errors would have shown >> up. Am I correct? >> > > Exact. I followed the instructions on extending the schema on 389-ds, by > inserting a file in my /etc/dirsrv//schema dir. > Everything went ok, and I can see from phpldapadmin that the DSA correctly > present my objectClasses as available to use for extending objects. > > >> I do not recognize the object classes as standard object classes. But >> might knowledge might be limited. >> > > Exact, they are "mine" objects, under a reserved OID number. > > >> Can you put show how you defined these new object classes in schema? You >> might have not specified the type and it defaulted to structural. >> > > This was a schema file created for OpenLDAP and which is currently in > production. > I used the script posted on the 389-ds HowTo for the migration from > OpenLDAP schema files to 389-ds format. > Here you can find it. A little camouflated, of course. > > [root at freeipa01 ~]# cat > /etc/dirsrv/slapd-UNIX-MYDOMAIN-IT/schema/98myfile.ldif > dn: cn=schema > attributetypes: ( 1.3.6.1.4.1.36005.0.2.4.4 NAME 'xxxUfficio' DESC > 'Ufficio di appartenenza degli utenti XXX' EQUALITY caseIgnoreMatch SYNTAX > 1.3.6.1.4.1.1466.115.121.1.15 USAGE userApplications ) > objectclasses: ( 1.3.6.1.4.1.36005.0.2.6.2 NAME 'xxxPeopleAttributes' SUP > top AUXILIARY DESC 'Definizione di attributi specifici per gli utenti XXX' > MAY ( xxxUfficio )) > attributetypes: ( 1.3.6.1.4.1.36005.0.2.4.1 NAME 'xxxProgetto' DESC 'Nome > del macro-progetto associato a questo gruppo LDAP' EQUALITY caseIgnoreMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 USAGE userApplications ) > attributetypes: ( 1.3.6.1.4.1.36005.0.2.4.2 NAME 'xxxAmbiente' DESC 'Nome > di ambiente SVIL-TEST-VALID-PROD associato al progetto' EQUALITY > caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 USAGE userApplications > ) > attributetypes: ( 1.3.6.1.4.1.36005.0.2.4.5 NAME 'xxxTipoGruppo' DESC > 'Tipologia di gruppo' EQUALITY caseIgnoreMatch SYNTAX > 1.3.6.1.4.1.1466.115.121.1.15 USAGE userApplications ) > objectclasses: ( 1.3.6.1.4.1.36005.0.2.6.3 NAME 'xxxGroupsAttributes' SUP > top AUXILIARY DESC 'Definizione di attributi specifici per i gruppi XXX' > MAY ( xxxProgetto $ xxxAmbiente $ xxxTipoGruppo )) > attributetypes: ( 1.3.6.1.4.1.36005.0.2.4.6 NAME 'xxxWebminAmbiente' DESC > 'Ufficio di appartenenza degli utenti XXX' EQUALITY caseIgnoreMatch SYNTAX > 1.3.6.1.4.1.1466.115.121.1.15 USAGE userApplications ) > objectclasses: ( 1.3.6.1.4.1.36005.0.2.6.4 NAME 'xxxWebminAttributes' SUP > top AUXILIARY DESC 'Definizione di attributi specifici per gli oggetti > Webmin' MAY ( xxxWebminAmbiente )) > attributetypes: ( 1.3.6.1.4.1.36005.0.2.4.3 NAME 'xxxDB2GruppiPrivilegi' > DESC 'Tipologia di gruppo creato per accesso al DB2' EQUALITY > caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 USAGE userApplications > ) > objectclasses: ( 1.3.6.1.4.1.36005.0.2.6.5 NAME 'xxxDB2GroupsAttributes' > SUP top AUXILIARY DESC 'Definizione di attributi specifici per i gruppi > DB2' MAY ( xxxDB2GruppiPrivilegi )) > objectclasses: ( 1.3.6.1.4.1.36005.0.2.6.1 NAME 'xxxAttributes' SUP top > AUXILIARY DESC 'Definizione di attributi specifici per utilizzo interno' > MAY ( xxxProgetto $ xxxAmbiente $ xxxTipoGruppo $ xxxDB2GruppiPrivilegi )) > > As you can see, they are explicitly declared as AUXILIARY. > > > OK. Then it seems like a bug on our side ;-) > Please file a ticket and attached the info provided here. > Done. https://fedorahosted.org/freeipa/ticket/2545 > Thanks for your efforts. They really help us to make the project better. > I'm happy to help :-) > > Thanks again > Marco > > > _______________________________________________ > Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IPA project, > 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 marco.pizzoli at gmail.com Sun Mar 18 17:33:24 2012 From: marco.pizzoli at gmail.com (Marco Pizzoli) Date: Sun, 18 Mar 2012 18:33:24 +0100 Subject: [Freeipa-users] Problem in "ipa migrate-ds" procedure In-Reply-To: <4F66121F.3090200@redhat.com> References: <4F66121F.3090200@redhat.com> Message-ID: On Sun, Mar 18, 2012 at 5:49 PM, Dmitri Pal wrote: > ** > On 03/17/2012 07:36 AM, Marco Pizzoli wrote: > > Hi guys, > I'm trying to migrate my ldap user base to freeipa. I'm using the last > Release Candidate. > > I already changed "ipa config-mod --enable-migration=TRUE" > This is what I have: > > ipa -v migrate-ds --bind-dn="cn=manager,dc=mydc1,dc=mydc2.it" > --user-container="ou=people,dc=mydc1,dc=mydc2.it" > --user-objectclass=inetOrgPerson --group-container="ou=groups,dc=mydc1,dc= > mydc2.it" --group-objectclass=posixGroup --base-dn="dc=mydc1,dc=mydc2.it" > --with-compat ldap://ldap01 > ipa: INFO: trying https://freeipa01.unix.mydomain.it/ipa/xml > Password: > ipa: INFO: Forwarding 'migrate_ds' to server u' > http://freeipa01.unix.mydomain.it/ipa/xml' > ipa: ERROR: Container for group not found at ou=groups,dc=mydc1,dc= > mydc2.it > > I looked at my ldap server logs and I found out that the search executed > has scope=1. Actually both for users and groups. This is a problem for me, > in having a lot of subtrees (ou) in which my users and groups are. Is there > a way to manage this? > > Thanks in advance > Marco > > P.s. As a side note, I suppose there's a typo in the verbose message I > obtain in my output: > ipa: INFO: Forwarding 'migrate_ds' to server *u*' > http://freeipa01.unix.mydomain.it/ipa/xml' > > > Please open tickets for both issues. > Done: https://fedorahosted.org/freeipa/ticket/2547 https://fedorahosted.org/freeipa/ticket/2546 Do you have a hint on how to manage to do this import in the meantime? Every manual step is ok for me. Thanks again Marco -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Sun Mar 18 17:38:35 2012 From: dpal at redhat.com (Dmitri Pal) Date: Sun, 18 Mar 2012 13:38:35 -0400 Subject: [Freeipa-users] Problem in "ipa migrate-ds" procedure In-Reply-To: References: <4F66121F.3090200@redhat.com> Message-ID: <4F661D9B.3000000@redhat.com> On 03/18/2012 01:33 PM, Marco Pizzoli wrote: > > > On Sun, Mar 18, 2012 at 5:49 PM, Dmitri Pal > wrote: > > On 03/17/2012 07:36 AM, Marco Pizzoli wrote: >> Hi guys, >> I'm trying to migrate my ldap user base to freeipa. I'm using the >> last Release Candidate. >> >> I already changed "ipa config-mod --enable-migration=TRUE" >> This is what I have: >> >> ipa -v migrate-ds --bind-dn="cn=manager,dc=mydc1,dc=mydc2.it >> " >> --user-container="ou=people,dc=mydc1,dc=mydc2.it >> " --user-objectclass=inetOrgPerson >> --group-container="ou=groups,dc=mydc1,dc=mydc2.it >> " --group-objectclass=posixGroup >> --base-dn="dc=mydc1,dc=mydc2.it " --with-compat >> ldap://ldap01 >> ipa: INFO: trying https://freeipa01.unix.mydomain.it/ipa/xml >> Password: >> ipa: INFO: Forwarding 'migrate_ds' to server >> u'http://freeipa01.unix.mydomain.it/ipa/xml' >> ipa: ERROR: Container for group not found at >> ou=groups,dc=mydc1,dc=mydc2.it >> >> I looked at my ldap server logs and I found out that the search >> executed has scope=1. Actually both for users and groups. This is >> a problem for me, in having a lot of subtrees (ou) in which my >> users and groups are. Is there a way to manage this? >> >> Thanks in advance >> Marco >> >> P.s. As a side note, I suppose there's a typo in the verbose >> message I obtain in my output: >> ipa: INFO: Forwarding 'migrate_ds' to server >> *u*'http://freeipa01.unix.mydomain.it/ipa/xml' > > Please open tickets for both issues. > > > Done: > https://fedorahosted.org/freeipa/ticket/2547 > https://fedorahosted.org/freeipa/ticket/2546 > > Do you have a hint on how to manage to do this import in the meantime? > Every manual step is ok for me. I do not think you would like it as it would be a fair amount of work. :-) Export schema into LDIF, make a script to reformat LDIF, create flattened LDIF, load it into an empty instance of the 389 DS, migrate from there. Describe all the procedure and share the script for others to use :-) > > Thanks again > Marco > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steven.Jones at vuw.ac.nz Mon Mar 19 00:55:34 2012 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Mon, 19 Mar 2012 00:55:34 +0000 Subject: [Freeipa-users] Extending IPA schema for Federation services. Message-ID: <833D8E48405E064EBC54C84EC6B36E404CC0FA66@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, Is it possible to expand IPA's schema to do this? =================== Your Identity Management System (IdMS) will very likely have most of the attributes asked for by the federation - or will have enough information to synthesize the specific attribute values on the fly inside the IdP. But for some attributes, the IdMS might not have enough information. The following information should be considered for adding into your IdMS: * eduPersonEntitlement: The eduPersonEntitlement attribute is a storage container for values representing privileges to access resources within the federation. It is a multi-valued string attribute. The values will have the form of a URI - with specific values that are yet to be defined. The attribute definition details are (source: Attribute Recommendation 2.1 (PDF), page 14): Origin/ObjectClass: eduPerson [eduPerson] OID: 1.3.6.1.4.1.5923.1.1.1.7 SAML attribute name: urn:mace:dir:attribute-def:eduPersonEntitlement LDAP syntax: directoryString [1.3.6.1.4.1.1466.115.121.1.15] Number of values: Multiple Example values: eduPersonEntitlement: urn:mace:washington.edu:confocalMicroscope eduPersonEntitlement: http://publisher.example.com/contract/GL123 * auEduPersonSharedToken: The auEduPersonSharedToken uniquely identifies users when accessing certain resources - particularly within the computational grid and data grid. The values should be opaque, non-reassignable and persistent - and transferrable when a user moves between institutions. Even though the values are typically created as hash-values on first use, they MUST be stored and each institution must be ready to accept values users already have when coming from another institution. The attribute can be stored in either the IdMS directly (preferred) or in a database. The attribute definition details are (source: Attribute Recommendation 2.1 (PDF), pages 9-10, with OID updated to correct value): Origin/ObjectClass: auEduPerson OID: 1.3.6.1.4.1.27856.1.2.5 SAML attribute name urn:mace:federation.org.au:attribute:auEduPersonSharedToken LDAP syntax: directoryString [1.3.6.1.4.1.27856.1.2.5] Number of values: Single Example values: ZsiAvfxa0BXULgcz7QXknbGtfxk * See also the auEduPerson LDAP Schema Definition for exact LDAP definition snippets. * eduPersonAssurance: This attribute represents the Levels of Assurance. Either add the attribute into the IdMS directly, or start collecting enough information to synthesize the values later in a scripted attribute definition (like done for Affiliation below). The attribute definition details are (source: Attribute Recommendation 2.1 (PDF), page 13): Origin/ObjectClass: eduPerson OID: 1.3.6.1.4.1.5923.1.1.1.11 SAML attribute name: urn:oid:1.3.6.1.4.1.5923.1.1.1.11 LDAP syntax: directoryString [1.3.6.1.4.1.1466.115.121.1.15] Number of values: multiple Example values: See AAF IdentityLoA Vocabulary ===================== regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 From dpal at redhat.com Mon Mar 19 02:21:49 2012 From: dpal at redhat.com (Dmitri Pal) Date: Sun, 18 Mar 2012 22:21:49 -0400 Subject: [Freeipa-users] Extending IPA schema for Federation services. In-Reply-To: <833D8E48405E064EBC54C84EC6B36E404CC0FA66@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E404CC0FA66@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <4F66983D.7020301@redhat.com> On 03/18/2012 08:55 PM, Steven Jones wrote: > Hi, > > > Is it possible to expand IPA's schema to do this? > > Yes. Steps: 1) Convert schema to the correct schema format 2) Add it to the DS schema by placing the file onto the right place. Now you have it available for use by IPA via LDAP tools. 3) Use ipa config to tell IPA to add this schema to user object. 4) You can use --setaddr and --addaddr switches to populate these attributes via CLI I do not think it is exposed in UI. To make it available via UI and CLI natively the plugins should be developed following the extensibility guide. > =================== > > Your Identity Management System (IdMS) will very likely have most of the attributes asked for by the federation - or will have enough information to synthesize the specific attribute values on the fly inside the IdP. But for some attributes, the IdMS might not have enough information. The following information should be considered for adding into your IdMS: > > * eduPersonEntitlement: The eduPersonEntitlement attribute is a storage container for values representing privileges to access resources within the federation. It is a multi-valued string attribute. The values will have the form of a URI - with specific values that are yet to be defined. The attribute definition details are (source: Attribute Recommendation 2.1 (PDF), page 14): > > Origin/ObjectClass: eduPerson [eduPerson] > OID: 1.3.6.1.4.1.5923.1.1.1.7 > SAML attribute name: urn:mace:dir:attribute-def:eduPersonEntitlement > LDAP syntax: directoryString [1.3.6.1.4.1.1466.115.121.1.15] > Number of values: Multiple > Example values: eduPersonEntitlement: urn:mace:washington.edu:confocalMicroscope > eduPersonEntitlement: http://publisher.example.com/contract/GL123 > > * auEduPersonSharedToken: The auEduPersonSharedToken uniquely identifies users when accessing certain resources - particularly within the computational grid and data grid. The values should be opaque, non-reassignable and persistent - and transferrable when a user moves between institutions. Even though the values are typically created as hash-values on first use, they MUST be stored and each institution must be ready to accept values users already have when coming from another institution. The attribute can be stored in either the IdMS directly (preferred) or in a database. The attribute definition details are (source: Attribute Recommendation 2.1 (PDF), pages 9-10, with OID updated to correct value): > > Origin/ObjectClass: auEduPerson > OID: 1.3.6.1.4.1.27856.1.2.5 > SAML attribute name urn:mace:federation.org.au:attribute:auEduPersonSharedToken > LDAP syntax: directoryString [1.3.6.1.4.1.27856.1.2.5] > Number of values: Single > Example values: ZsiAvfxa0BXULgcz7QXknbGtfxk > > * See also the auEduPerson LDAP Schema Definition for exact LDAP definition snippets. > > * eduPersonAssurance: This attribute represents the Levels of Assurance. Either add the attribute into the IdMS directly, or start collecting enough information to synthesize the values later in a scripted attribute definition (like done for Affiliation below). The attribute definition details are (source: Attribute Recommendation 2.1 (PDF), page 13): > > Origin/ObjectClass: eduPerson > OID: 1.3.6.1.4.1.5923.1.1.1.11 > SAML attribute name: urn:oid:1.3.6.1.4.1.5923.1.1.1.11 > LDAP syntax: directoryString [1.3.6.1.4.1.1466.115.121.1.15] > Number of values: multiple > Example values: See AAF IdentityLoA Vocabulary > > ===================== > > > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From simo at redhat.com Mon Mar 19 12:15:57 2012 From: simo at redhat.com (Simo Sorce) Date: Mon, 19 Mar 2012 08:15:57 -0400 Subject: [Freeipa-users] Doubt on FreeIPA LDAP extensibility In-Reply-To: References: <1332008209.9238.328.camel@willson.li.ssimo.org> Message-ID: <1332159357.9238.331.camel@willson.li.ssimo.org> On Sun, 2012-03-18 at 13:59 +0100, Marco Pizzoli wrote: > Hi Simo, > > On Sat, Mar 17, 2012 at 7:16 PM, Simo Sorce wrote: > On Sat, 2012-03-17 at 11:12 +0100, Marco Pizzoli wrote: > > Hi guys, > > > > I extended my set of LDAP objectClasses associated to users > by adding > > my new objectClass to my cn=ipaConfig LDAP entry, the > > ipaUserObjectClasses attribute. > > Then, I created a new user with the web ui and I see the new > > objectClass associated with that user, but as structural > instead of > > auxiliary. I don't know why, could you help me? > > > > Same thing happened for my groups. I added 3 objectClasses > and now I > > see all of them as structural. I would understand an answer: > all > > objectClasses eventually result as structural, but so why, > for > > example, the ipaObject is still an auxiliary objectClass? > > > The objectClass type depends on the schema. It is not > something that > changes after you assign it to an object. > > Yes, your answer surely does make sense. > > My question was triggered by the fact that, AFAICS, not all > objectClasses are structural as well. > In fact I can see that, for my group object, the objectClass > "ipaobject" has been defined as auxiliary, while others structural. > For users, I see that *only my objectClass* is defined as structural. > All others as auxiliary. > > In attachment you can see 2 images that immediately represent what I'm > trying to explain. > > If this was the intended behaviour, I would be really interested in > knowing what is the rationale behind this. > Only curiousity, as usual :-) Objectclasses have no structureal/auxiliary "attribute" in an object, it's your ldap browser that is returning the labeling by (I guess ) searching the schema. I guess your object is getting it wrong, or the schema you defined in 389ds has these classes marked structural. > search the schema with your browser and see how it identify these classes ? I see you also opened a bug, but it makes little sense to me. I will close it as invalid for now, unless there is evidence 389ds returns the wrong type from the schema tree. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Mon Mar 19 12:43:53 2012 From: simo at redhat.com (Simo Sorce) Date: Mon, 19 Mar 2012 08:43:53 -0400 Subject: [Freeipa-users] Problem in "ipa migrate-ds" procedure In-Reply-To: References: <4F66121F.3090200@redhat.com> Message-ID: <1332161033.9238.335.camel@willson.li.ssimo.org> On Sun, 2012-03-18 at 18:33 +0100, Marco Pizzoli wrote: > > > On Sun, Mar 18, 2012 at 5:49 PM, Dmitri Pal wrote: > On 03/17/2012 07:36 AM, Marco Pizzoli wrote: > > Hi guys, > > I'm trying to migrate my ldap user base to freeipa. I'm > > using the last Release Candidate. > > > > I already changed "ipa config-mod --enable-migration=TRUE" > > This is what I have: > > > > ipa -v migrate-ds > > --bind-dn="cn=manager,dc=mydc1,dc=mydc2.it" > > --user-container="ou=people,dc=mydc1,dc=mydc2.it" > > --user-objectclass=inetOrgPerson > > --group-container="ou=groups,dc=mydc1,dc=mydc2.it" > > --group-objectclass=posixGroup > > --base-dn="dc=mydc1,dc=mydc2.it" --with-compat ldap://ldap01 > > ipa: INFO: trying https://freeipa01.unix.mydomain.it/ipa/xml > > Password: > > ipa: INFO: Forwarding 'migrate_ds' to server > > u'http://freeipa01.unix.mydomain.it/ipa/xml' > > ipa: ERROR: Container for group not found at > > ou=groups,dc=mydc1,dc=mydc2.it > > > > I looked at my ldap server logs and I found out that the > > search executed has scope=1. Actually both for users and > > groups. This is a problem for me, in having a lot of > > subtrees (ou) in which my users and groups are. Is there a > > way to manage this? > > > > Thanks in advance > > Marco > > > > P.s. As a side note, I suppose there's a typo in the verbose > > message I obtain in my output: > > ipa: INFO: Forwarding 'migrate_ds' to server > > u'http://freeipa01.unix.mydomain.it/ipa/xml' > > > Please open tickets for both issues. > > > Done: > https://fedorahosted.org/freeipa/ticket/2547 > https://fedorahosted.org/freeipa/ticket/2546 > > Do you have a hint on how to manage to do this import in the meantime? > Every manual step is ok for me. Maybe you can try performing a new migration for each of the subtrees you have in your source tree, assuming it is a reasonable number, by reconfiguring the migrate-ds bases between each run. Simo. -- Simo Sorce * Red Hat, Inc * New York From marco.pizzoli at gmail.com Mon Mar 19 12:51:39 2012 From: marco.pizzoli at gmail.com (Marco Pizzoli) Date: Mon, 19 Mar 2012 13:51:39 +0100 Subject: [Freeipa-users] Doubt on FreeIPA LDAP extensibility In-Reply-To: <1332159357.9238.331.camel@willson.li.ssimo.org> References: <1332008209.9238.328.camel@willson.li.ssimo.org> <1332159357.9238.331.camel@willson.li.ssimo.org> Message-ID: On Mon, Mar 19, 2012 at 1:15 PM, Simo Sorce wrote: > On Sun, 2012-03-18 at 13:59 +0100, Marco Pizzoli wrote: > > Hi Simo, > > > > On Sat, Mar 17, 2012 at 7:16 PM, Simo Sorce wrote: > > On Sat, 2012-03-17 at 11:12 +0100, Marco Pizzoli wrote: > > > Hi guys, > > > > > > I extended my set of LDAP objectClasses associated to users > > by adding > > > my new objectClass to my cn=ipaConfig LDAP entry, the > > > ipaUserObjectClasses attribute. > > > Then, I created a new user with the web ui and I see the new > > > objectClass associated with that user, but as structural > > instead of > > > auxiliary. I don't know why, could you help me? > > > > > > Same thing happened for my groups. I added 3 objectClasses > > and now I > > > see all of them as structural. I would understand an answer: > > all > > > objectClasses eventually result as structural, but so why, > > for > > > example, the ipaObject is still an auxiliary objectClass? > > > > > > The objectClass type depends on the schema. It is not > > something that > > changes after you assign it to an object. > > > > Yes, your answer surely does make sense. > > > > My question was triggered by the fact that, AFAICS, not all > > objectClasses are structural as well. > > In fact I can see that, for my group object, the objectClass > > "ipaobject" has been defined as auxiliary, while others structural. > > For users, I see that *only my objectClass* is defined as structural. > > All others as auxiliary. > > > > In attachment you can see 2 images that immediately represent what I'm > > trying to explain. > > > > If this was the intended behaviour, I would be really interested in > > knowing what is the rationale behind this. > > Only curiousity, as usual :-) > > Objectclasses have no structureal/auxiliary "attribute" in an object, > it's your ldap browser that is returning the labeling by (I guess ) > searching the schema. > Exact. I admit I have not been so clear in my explanation. > I guess your object is getting it wrong, or the schema you defined in > 389ds has these classes marked structural. > > > search the schema with your browser and see how it identify these > classes ? > In attachment. You can find only one, but all of them are equivalent from this point. They are indeed seen as structural, even if my added schema file declare them as auxiliary. > I see you also opened a bug, but it makes little sense to me. I will > close it as invalid for now, unless there is evidence 389ds returns the > wrong type from the schema tree. > Ok, I agree. Thanks as usual Marco > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: GroupsAttribute_ObjectClass.PNG Type: image/png Size: 14844 bytes Desc: not available URL: From marco.pizzoli at gmail.com Mon Mar 19 12:56:46 2012 From: marco.pizzoli at gmail.com (Marco Pizzoli) Date: Mon, 19 Mar 2012 13:56:46 +0100 Subject: [Freeipa-users] Problem in "ipa migrate-ds" procedure In-Reply-To: <1332161033.9238.335.camel@willson.li.ssimo.org> References: <4F66121F.3090200@redhat.com> <1332161033.9238.335.camel@willson.li.ssimo.org> Message-ID: On Mon, Mar 19, 2012 at 1:43 PM, Simo Sorce wrote: > On Sun, 2012-03-18 at 18:33 +0100, Marco Pizzoli wrote: > > > > > > On Sun, Mar 18, 2012 at 5:49 PM, Dmitri Pal wrote: > > On 03/17/2012 07:36 AM, Marco Pizzoli wrote: > > > Hi guys, > > > I'm trying to migrate my ldap user base to freeipa. I'm > > > using the last Release Candidate. > > > > > > I already changed "ipa config-mod --enable-migration=TRUE" > > > This is what I have: > > > > > > ipa -v migrate-ds > > > --bind-dn="cn=manager,dc=mydc1,dc=mydc2.it" > > > --user-container="ou=people,dc=mydc1,dc=mydc2.it" > > > --user-objectclass=inetOrgPerson > > > --group-container="ou=groups,dc=mydc1,dc=mydc2.it" > > > --group-objectclass=posixGroup > > > --base-dn="dc=mydc1,dc=mydc2.it" --with-compat ldap://ldap01 > > > ipa: INFO: trying https://freeipa01.unix.mydomain.it/ipa/xml > > > Password: > > > ipa: INFO: Forwarding 'migrate_ds' to server > > > u'http://freeipa01.unix.mydomain.it/ipa/xml' > > > ipa: ERROR: Container for group not found at > > > ou=groups,dc=mydc1,dc=mydc2.it > > > > > > I looked at my ldap server logs and I found out that the > > > search executed has scope=1. Actually both for users and > > > groups. This is a problem for me, in having a lot of > > > subtrees (ou) in which my users and groups are. Is there a > > > way to manage this? > > > > > > Thanks in advance > > > Marco > > > > > > P.s. As a side note, I suppose there's a typo in the verbose > > > message I obtain in my output: > > > ipa: INFO: Forwarding 'migrate_ds' to server > > > u'http://freeipa01.unix.mydomain.it/ipa/xml' > > > > > > Please open tickets for both issues. > > > > > > Done: > > https://fedorahosted.org/freeipa/ticket/2547 > > https://fedorahosted.org/freeipa/ticket/2546 > > > > Do you have a hint on how to manage to do this import in the meantime? > > Every manual step is ok for me. > > Maybe you can try performing a new migration for each of the subtrees > you have in your source tree, assuming it is a reasonable number, by > reconfiguring the migrate-ds bases between each run. > Yes, I was thinking the same... :-) To be able to script "ipa migrate-ds", I would need a parameter for setting the password on the CLI. I suppose it isn't there by design, right? Thanks again Marco -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Mon Mar 19 13:32:05 2012 From: simo at redhat.com (Simo Sorce) Date: Mon, 19 Mar 2012 09:32:05 -0400 Subject: [Freeipa-users] Doubt on FreeIPA LDAP extensibility In-Reply-To: References: <1332008209.9238.328.camel@willson.li.ssimo.org> <1332159357.9238.331.camel@willson.li.ssimo.org> Message-ID: <1332163925.9238.344.camel@willson.li.ssimo.org> On Mon, 2012-03-19 at 13:51 +0100, Marco Pizzoli wrote: > > In attachment. You can find only one, but all of them are equivalent > from this point. > They are indeed seen as structural, even if my added schema file > declare them as auxiliary. Can you attach the (sanitized) schema file you added to 389ds ? Also can you run a ldapsearch command and search in the 'cn=schema' base ? This will give you back what 389ds sends to a client. This command searches for everything but uses an attribute filter to show only the objectclasses: ldapsearch -x -h server -b 'cn=schema' 'objectClasses' No need to attach everything return, just edit the result and attach only the results for your calsses. Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Mon Mar 19 13:40:41 2012 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 19 Mar 2012 09:40:41 -0400 Subject: [Freeipa-users] Problem in "ipa migrate-ds" procedure In-Reply-To: References: <4F66121F.3090200@redhat.com> <1332161033.9238.335.camel@willson.li.ssimo.org> Message-ID: <4F673759.6010000@redhat.com> On 03/19/2012 08:56 AM, Marco Pizzoli wrote: > > > On Mon, Mar 19, 2012 at 1:43 PM, Simo Sorce > wrote: > > On Sun, 2012-03-18 at 18:33 +0100, Marco Pizzoli wrote: > > > > > > On Sun, Mar 18, 2012 at 5:49 PM, Dmitri Pal > wrote: > > On 03/17/2012 07:36 AM, Marco Pizzoli wrote: > > > Hi guys, > > > I'm trying to migrate my ldap user base to freeipa. I'm > > > using the last Release Candidate. > > > > > > I already changed "ipa config-mod --enable-migration=TRUE" > > > This is what I have: > > > > > > ipa -v migrate-ds > > > --bind-dn="cn=manager,dc=mydc1,dc=mydc2.it > " > > > --user-container="ou=people,dc=mydc1,dc=mydc2.it > " > > > --user-objectclass=inetOrgPerson > > > --group-container="ou=groups,dc=mydc1,dc=mydc2.it > " > > > --group-objectclass=posixGroup > > > --base-dn="dc=mydc1,dc=mydc2.it " > --with-compat ldap://ldap01 > > > ipa: INFO: trying > https://freeipa01.unix.mydomain.it/ipa/xml > > > Password: > > > ipa: INFO: Forwarding 'migrate_ds' to server > > > u'http://freeipa01.unix.mydomain.it/ipa/xml' > > > ipa: ERROR: Container for group not found at > > > ou=groups,dc=mydc1,dc=mydc2.it > > > > > > I looked at my ldap server logs and I found out that the > > > search executed has scope=1. Actually both for users and > > > groups. This is a problem for me, in having a lot of > > > subtrees (ou) in which my users and groups are. Is there a > > > way to manage this? > > > > > > Thanks in advance > > > Marco > > > > > > P.s. As a side note, I suppose there's a typo in the > verbose > > > message I obtain in my output: > > > ipa: INFO: Forwarding 'migrate_ds' to server > > > u'http://freeipa01.unix.mydomain.it/ipa/xml' > > > > > > Please open tickets for both issues. > > > > > > Done: > > https://fedorahosted.org/freeipa/ticket/2547 > > https://fedorahosted.org/freeipa/ticket/2546 > > > > Do you have a hint on how to manage to do this import in the > meantime? > > Every manual step is ok for me. > > Maybe you can try performing a new migration for each of the subtrees > you have in your source tree, assuming it is a reasonable number, by > reconfiguring the migrate-ds bases between each run. > > > Yes, I was thinking the same... :-) > To be able to script "ipa migrate-ds", I would need a parameter for > setting the password on the CLI. I suppose it isn't there by design, > right? > Will it handle the case when the group has members from different levels and some of the users are not picked by the search? In this case I suspect the user group membership might be lost. I am not sure that this is the case. Just something to pay attention. > Thanks again > Marco > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, 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 Mon Mar 19 13:42:12 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 19 Mar 2012 09:42:12 -0400 Subject: [Freeipa-users] Problem in "ipa migrate-ds" procedure In-Reply-To: <4F66121F.3090200@redhat.com> References: <4F66121F.3090200@redhat.com> Message-ID: <4F6737B4.5040502@redhat.com> Dmitri Pal wrote: > On 03/17/2012 07:36 AM, Marco Pizzoli wrote: >> Hi guys, >> I'm trying to migrate my ldap user base to freeipa. I'm using the last >> Release Candidate. >> >> I already changed "ipa config-mod --enable-migration=TRUE" >> This is what I have: >> >> ipa -v migrate-ds --bind-dn="cn=manager,dc=mydc1,dc=mydc2.it >> " --user-container="ou=people,dc=mydc1,dc=mydc2.it >> " --user-objectclass=inetOrgPerson >> --group-container="ou=groups,dc=mydc1,dc=mydc2.it " >> --group-objectclass=posixGroup --base-dn="dc=mydc1,dc=mydc2.it >> " --with-compat ldap://ldap01 >> ipa: INFO: trying https://freeipa01.unix.mydomain.it/ipa/xml >> Password: >> ipa: INFO: Forwarding 'migrate_ds' to server >> u'http://freeipa01.unix.mydomain.it/ipa/xml' >> ipa: ERROR: Container for group not found at >> ou=groups,dc=mydc1,dc=mydc2.it >> >> I looked at my ldap server logs and I found out that the search >> executed has scope=1. Actually both for users and groups. This is a >> problem for me, in having a lot of subtrees (ou) in which my users and >> groups are. Is there a way to manage this? >> >> Thanks in advance >> Marco >> >> P.s. As a side note, I suppose there's a typo in the verbose message I >> obtain in my output: >> ipa: INFO: Forwarding 'migrate_ds' to server >> *u*'http://freeipa01.unix.mydomain.it/ipa/xml' > > Please open tickets for both issues. Well, I don't think either is a bug. If you have users/groups in multiple places you'll need to migrate them individually for now. It is safe to run migrate-ds multiple times, existing users are not migrated. The u is a python-ism for unicode. This is not a bug. rob From marco.pizzoli at gmail.com Mon Mar 19 13:46:47 2012 From: marco.pizzoli at gmail.com (Marco Pizzoli) Date: Mon, 19 Mar 2012 14:46:47 +0100 Subject: [Freeipa-users] Doubt on FreeIPA LDAP extensibility In-Reply-To: <1332163925.9238.344.camel@willson.li.ssimo.org> References: <1332008209.9238.328.camel@willson.li.ssimo.org> <1332159357.9238.331.camel@willson.li.ssimo.org> <1332163925.9238.344.camel@willson.li.ssimo.org> Message-ID: On Mon, Mar 19, 2012 at 2:32 PM, Simo Sorce wrote: > On Mon, 2012-03-19 at 13:51 +0100, Marco Pizzoli wrote: > > > > In attachment. You can find only one, but all of them are equivalent > > from this point. > > They are indeed seen as structural, even if my added schema file > > declare them as auxiliary. > > Can you attach the (sanitized) schema file you added to 389ds ? > Already done on this thread. See my previous mail to Dmitri. Also can you run a ldapsearch command and search in the 'cn=schema' > base ? This will give you back what 389ds sends to a client. > This command searches for everything but uses an attribute filter to > show only the objectclasses: > ldapsearch -x -h server -b 'cn=schema' 'objectClasses' > > No need to attach everything return, just edit the result and attach > only the results for your calsses. > Ok, here it is: [root at freeipa01 ~]# ldapsearch -h 127.0.0.1 -x -D"cn=Directory Manager" -s base -W -b "cn=schema" "objectClasses"|perl -0pe 's/\n //g' objectClasses: ( 1.3.6.1.4.1.36005.0.2.6.2 NAME 'xxxPeopleAttributes' DESC 'Definizione di attributi specifici per gli utenti XXX' STRUCTURAL MAY xxxUfficio ) objectClasses: ( 1.3.6.1.4.1.36005.0.2.6.3 NAME 'xxxGroupsAttributes' DESC 'Definizione di attributi specifici per i gruppi XXX' STRUCTURAL MAY ( xxxProgetto $ xxxAmbiente $ xxxTipoGruppo ) ) objectClasses: ( 1.3.6.1.4.1.36005.0.2.6.4 NAME 'xxxWebminAttributes' DESC 'Definizione di attributi specifici per gli oggetti Webmin' STRUCTURAL MAY xxxWebminAmbiente ) objectClasses: ( 1.3.6.1.4.1.36005.0.2.6.5 NAME 'xxxDB2GroupsAttributes' DESC 'Definizione di attributi specifici per i gruppi DB2' STRUCTURAL MAY xxxDB2GruppiPrivilegi ) objectClasses: ( 1.3.6.1.4.1.36005.0.2.6.1 NAME 'xxxAttributes' DESC 'Definizione di attributi specifici per utilizzo interno' STRUCTURAL MAY ( xxxProgetto $ xxxAmbiente $ xxxTipoGruppo $ xxxDB2GruppiPrivilegi ) ) By seeing this output, I just checked again and I confirm that in my file /etc/dirsrv/slapd-UNIX-MYDOMAIN-IT/schema/98myfile.ldif they are still AUXILIARY. Marco -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Mon Mar 19 13:53:44 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 19 Mar 2012 09:53:44 -0400 Subject: [Freeipa-users] Problem in "ipa migrate-ds" procedure In-Reply-To: <4F673759.6010000@redhat.com> References: <4F66121F.3090200@redhat.com> <1332161033.9238.335.camel@willson.li.ssimo.org> <4F673759.6010000@redhat.com> Message-ID: <4F673A68.6000702@redhat.com> Dmitri Pal wrote: > On 03/19/2012 08:56 AM, Marco Pizzoli wrote: >> >> >> On Mon, Mar 19, 2012 at 1:43 PM, Simo Sorce > > wrote: >> >> On Sun, 2012-03-18 at 18:33 +0100, Marco Pizzoli wrote: >> > >> > >> > On Sun, Mar 18, 2012 at 5:49 PM, Dmitri Pal > > wrote: >> > On 03/17/2012 07:36 AM, Marco Pizzoli wrote: >> > > Hi guys, >> > > I'm trying to migrate my ldap user base to freeipa. I'm >> > > using the last Release Candidate. >> > > >> > > I already changed "ipa config-mod --enable-migration=TRUE" >> > > This is what I have: >> > > >> > > ipa -v migrate-ds >> > > --bind-dn="cn=manager,dc=mydc1,dc=mydc2.it " >> > > --user-container="ou=people,dc=mydc1,dc=mydc2.it >> " >> > > --user-objectclass=inetOrgPerson >> > > --group-container="ou=groups,dc=mydc1,dc=mydc2.it >> " >> > > --group-objectclass=posixGroup >> > > --base-dn="dc=mydc1,dc=mydc2.it " >> --with-compat ldap://ldap01 >> > > ipa: INFO: trying https://freeipa01.unix.mydomain.it/ipa/xml >> > > Password: >> > > ipa: INFO: Forwarding 'migrate_ds' to server >> > > u'http://freeipa01.unix.mydomain.it/ipa/xml' >> > > ipa: ERROR: Container for group not found at >> > > ou=groups,dc=mydc1,dc=mydc2.it >> > > >> > > I looked at my ldap server logs and I found out that the >> > > search executed has scope=1. Actually both for users and >> > > groups. This is a problem for me, in having a lot of >> > > subtrees (ou) in which my users and groups are. Is there a >> > > way to manage this? >> > > >> > > Thanks in advance >> > > Marco >> > > >> > > P.s. As a side note, I suppose there's a typo in the verbose >> > > message I obtain in my output: >> > > ipa: INFO: Forwarding 'migrate_ds' to server >> > > u'http://freeipa01.unix.mydomain.it/ipa/xml' >> > >> > >> > Please open tickets for both issues. >> > >> > >> > Done: >> > https://fedorahosted.org/freeipa/ticket/2547 >> > https://fedorahosted.org/freeipa/ticket/2546 >> > >> > Do you have a hint on how to manage to do this import in the >> meantime? >> > Every manual step is ok for me. >> >> Maybe you can try performing a new migration for each of the subtrees >> you have in your source tree, assuming it is a reasonable number, by >> reconfiguring the migrate-ds bases between each run. >> >> >> Yes, I was thinking the same... :-) >> To be able to script "ipa migrate-ds", I would need a parameter for >> setting the password on the CLI. I suppose it isn't there by design, >> right? >> > > Will it handle the case when the group has members from different levels > and some of the users are not picked by the search? In this case I > suspect the user group membership might be lost. I am not sure that this > is the case. Just something to pay attention. It doesn't look like we verify the membership so I think it will work just fine. It is not invalid in LDAP to have a group with a member that doesn't exist, so this shouldn't cause any errors. You can do something like echo password | ipa migrate-ds ldap://myserver.example.com:389 --user-container=... rob From rcritten at redhat.com Mon Mar 19 13:55:57 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 19 Mar 2012 09:55:57 -0400 Subject: [Freeipa-users] Extending IPA schema for Federation services. In-Reply-To: <833D8E48405E064EBC54C84EC6B36E404CC0FA66@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E404CC0FA66@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <4F673AED.9000704@redhat.com> Steven Jones wrote: > Hi, > > > Is it possible to expand IPA's schema to do this? Adding the schema is easy, doing something with it is where things get interesting. What do you want to do with these attributes/objectclasses? rob From marco.pizzoli at gmail.com Mon Mar 19 14:33:17 2012 From: marco.pizzoli at gmail.com (Marco Pizzoli) Date: Mon, 19 Mar 2012 15:33:17 +0100 Subject: [Freeipa-users] Problem in "ipa migrate-ds" procedure In-Reply-To: <4F6737B4.5040502@redhat.com> References: <4F66121F.3090200@redhat.com> <4F6737B4.5040502@redhat.com> Message-ID: On Mon, Mar 19, 2012 at 2:42 PM, Rob Crittenden wrote: > Dmitri Pal wrote: > >> On 03/17/2012 07:36 AM, Marco Pizzoli wrote: >> >>> Hi guys, >>> I'm trying to migrate my ldap user base to freeipa. I'm using the last >>> Release Candidate. >>> >>> I already changed "ipa config-mod --enable-migration=TRUE" >>> This is what I have: >>> >>> ipa -v migrate-ds --bind-dn="cn=manager,dc=**mydc1,dc=mydc2.it >>> " --user-container="ou=people,**dc=mydc1,dc=mydc2.it >>> " --user-objectclass=**inetOrgPerson >>> --group-container="ou=groups,**dc=mydc1,dc=mydc2.it " >>> --group-objectclass=posixGroup --base-dn="dc=mydc1,dc=mydc2.**it >>> " --with-compat ldap://ldap01 >>> >>> ipa: INFO: trying https://freeipa01.unix.**mydomain.it/ipa/xml >>> Password: >>> ipa: INFO: Forwarding 'migrate_ds' to server >>> u'http://freeipa01.unix.**mydomain.it/ipa/xml >>> ' >>> ipa: ERROR: Container for group not found at >>> ou=groups,dc=mydc1,dc=mydc2.it >>> >>> >>> I looked at my ldap server logs and I found out that the search >>> executed has scope=1. Actually both for users and groups. This is a >>> problem for me, in having a lot of subtrees (ou) in which my users and >>> groups are. Is there a way to manage this? >>> >>> Thanks in advance >>> Marco >>> >>> P.s. As a side note, I suppose there's a typo in the verbose message I >>> obtain in my output: >>> ipa: INFO: Forwarding 'migrate_ds' to server >>> *u*'http://freeipa01.unix.**mydomain.it/ipa/xml >>> ' >>> >> >> Please open tickets for both issues. >> > > Well, I don't think either is a bug. > > If you have users/groups in multiple places you'll need to migrate them > individually for now. It is safe to run migrate-ds multiple times, existing > users are not migrated. > I just re-executed by specifing a nested ou for my groups. This is what I got: ipa: INFO: trying https://freeipa01.unix.csebo.it/ipa/xml ipa: INFO: Forwarding 'migrate_ds' to server u' http://freeipa01.unix.csebo.it/ipa/xml' ----------- migrate-ds: ----------- Migrated: Failed user: fw03075_no: Type or value exists: [other users listed] Failed group: pdbac32: Type or value exists: [other groups listed] ---------- Passwords have been migrated in pre-hashed format. IPA is unable to generate Kerberos keys unless provided with clear text passwords. All migrated users need to login at https://your.domain/ipa/migration/ before they can use their Kerberos accounts. I don't understand what it's trying to telling me. On my FreeIPA ldap server I don't see any imported user. What's my fault here? > > The u is a python-ism for unicode. This is not a bug. > Please, could you give a little more detail on this? It's only a hint on what that data represents in a Python variable? Thanks again Marco > > rob > > > ______________________________**_________________ > 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 maciej.sawicki at polidea.pl Mon Mar 19 16:31:37 2012 From: maciej.sawicki at polidea.pl (Maciej Sawicki) Date: Mon, 19 Mar 2012 17:31:37 +0100 Subject: [Freeipa-users] Firefox on OS X 10.6 problem Message-ID: Hi, Today I setup free ipa on CentOS release 6.2. I configured my client machine, that is: 1. I edited my "/Library/Preferences/edu.mit.Kerberos" file so it has following content: [domain_realm] polidea.pl = POLIDEA.PL .polidea.pl = .POLIDEA.PL [libdefaults] default_realm = POLIDEA.PL dns_lookup_realm = true dns_lookup_kdc = true ticket_lifetime = 24h forwardable = yes [realms] POLIDEA.PL = { admin_server = free-ipa.polidea.pl:749 default_domain = polidea.pl kdc = free-ipa.polidea.pl:88 } [logging] kdc = FILE:/var/log/krb5kdc/kdc.log admin_server = FILE:/var/log/krb5kdc/kadmin.log I I run open /System/Library/Coreservices/Ticket\ Viewer.app and added admin at POLIDEA.PL identity (i get ticket so password is valid) also i configured my firefox like in this link: http://freeipa.org/page/InstallAndDeploy#Configuring_your_Browser Unfortunately when I try to login I get following error: "Your kerberos ticket is no longer valid. Please run kinit and then click 'Retry'. If this is your first time running the IPA Web UI follow these directions to configure your browser." my /var/log/krb5kdc/kadmin.log has only few old entries (0 today's entries from today). I will appreciate any help. regards, Maciek From simo at redhat.com Mon Mar 19 16:36:24 2012 From: simo at redhat.com (Simo Sorce) Date: Mon, 19 Mar 2012 12:36:24 -0400 Subject: [Freeipa-users] Doubt on FreeIPA LDAP extensibility In-Reply-To: References: <1332008209.9238.328.camel@willson.li.ssimo.org> <1332159357.9238.331.camel@willson.li.ssimo.org> <1332163925.9238.344.camel@willson.li.ssimo.org> Message-ID: <1332174984.9238.403.camel@willson.li.ssimo.org> On Mon, 2012-03-19 at 14:46 +0100, Marco Pizzoli wrote: > > > On Mon, Mar 19, 2012 at 2:32 PM, Simo Sorce wrote: > On Mon, 2012-03-19 at 13:51 +0100, Marco Pizzoli wrote: > > > > In attachment. You can find only one, but all of them are > equivalent > > from this point. > > They are indeed seen as structural, even if my added schema > file > > declare them as auxiliary. > > > Can you attach the (sanitized) schema file you added to > 389ds ? > > Already done on this thread. See my previous mail to Dmitri. > > > Also can you run a ldapsearch command and search in the > 'cn=schema' > base ? This will give you back what 389ds sends to a client. > > > This command searches for everything but uses an attribute > filter to > show only the objectclasses: > ldapsearch -x -h server -b 'cn=schema' 'objectClasses' > > No need to attach everything return, just edit the result and > attach > only the results for your calsses. > > Ok, here it is: > [root at freeipa01 ~]# ldapsearch -h 127.0.0.1 -x -D"cn=Directory > Manager" -s base -W -b "cn=schema" "objectClasses"|perl -0pe > 's/\n //g' > > objectClasses: ( 1.3.6.1.4.1.36005.0.2.6.2 NAME 'xxxPeopleAttributes' > DESC 'Definizione di attributi specifici per gli utenti XXX' > STRUCTURAL MAY xxxUfficio ) > objectClasses: ( 1.3.6.1.4.1.36005.0.2.6.3 NAME 'xxxGroupsAttributes' > DESC 'Definizione di attributi specifici per i gruppi XXX' STRUCTURAL > MAY ( xxxProgetto $ xxxAmbiente $ xxxTipoGruppo ) ) > objectClasses: ( 1.3.6.1.4.1.36005.0.2.6.4 NAME 'xxxWebminAttributes' > DESC 'Definizione di attributi specifici per gli oggetti Webmin' > STRUCTURAL MAY xxxWebminAmbiente ) > objectClasses: ( 1.3.6.1.4.1.36005.0.2.6.5 NAME > 'xxxDB2GroupsAttributes' DESC 'Definizione di attributi specifici per > i gruppi DB2' STRUCTURAL MAY xxxDB2GruppiPrivilegi ) > objectClasses: ( 1.3.6.1.4.1.36005.0.2.6.1 NAME 'xxxAttributes' DESC > 'Definizione di attributi specifici per utilizzo interno' STRUCTURAL > MAY ( xxxProgetto $ xxxAmbiente $ xxxTipoGruppo $ > xxxDB2GruppiPrivilegi ) ) > > > By seeing this output, I just checked again and I confirm that in my > file /etc/dirsrv/slapd-UNIX-MYDOMAIN-IT/schema/98myfile.ldif they are > still AUXILIARY. This is odd, indeed, I will resurrect the bug you opened with a better description, thanks. Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Mon Mar 19 16:38:29 2012 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 19 Mar 2012 12:38:29 -0400 Subject: [Freeipa-users] Firefox on OS X 10.6 problem In-Reply-To: References: Message-ID: <4F676105.2030602@redhat.com> On 03/19/2012 12:31 PM, Maciej Sawicki wrote: > Hi, > Today I setup free ipa on CentOS release 6.2. I configured my client > machine, that is: > 1. I edited my "/Library/Preferences/edu.mit.Kerberos" file so it has > following content: > [domain_realm] > polidea.pl = POLIDEA.PL > .polidea.pl = .POLIDEA.PL > [libdefaults] > default_realm = POLIDEA.PL > dns_lookup_realm = true > dns_lookup_kdc = true > ticket_lifetime = 24h > forwardable = yes > [realms] > POLIDEA.PL = { > admin_server = free-ipa.polidea.pl:749 > default_domain = polidea.pl > kdc = free-ipa.polidea.pl:88 > } > > [logging] > kdc = FILE:/var/log/krb5kdc/kdc.log > admin_server = FILE:/var/log/krb5kdc/kadmin.log > I > > I run open /System/Library/Coreservices/Ticket\ Viewer.app and added > admin at POLIDEA.PL identity (i get ticket so password is valid) > > also i configured my firefox like in this link: > http://freeipa.org/page/InstallAndDeploy#Configuring_your_Browser > > Unfortunately when I try to login I get following error: > "Your kerberos ticket is no longer valid. Please run kinit and then > click 'Retry'. If this is your first time running the IPA Web UI > follow these directions to configure your browser." > > my /var/log/krb5kdc/kadmin.log has only few old entries (0 today's > entries from today). > > I will appreciate any help. > > regards, > Maciek > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users Have you done everything covered in the section 4.3.3 of the document? http://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/using-the-ui.html#Using_a_Browser_on_Another_System -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From david at adurotec.com Mon Mar 19 16:47:06 2012 From: david at adurotec.com (David) Date: Mon, 19 Mar 2012 11:47:06 -0500 Subject: [Freeipa-users] Fedora 15 IPA Server Upgrade Broke LDAP In-Reply-To: References: Message-ID: <4F67630A.90807@adurotec.com> After upgrading the IPA server on a Fedora 15 host to freeipa-server-2.1.4-3.fc15.x86_64 along with the LDAP dependency of 389-ds-base-1.2.10.2-1.fc15.x86_64, the IPA server fails to start due to the following error: Failed to read data from Directory Service: Failed to get list of services to probe status! Configured hostname 'ipa01.ourdomain.net' does not match any master server in LDAP: No master found because of error: {'matched': 'dc=ourdomain,dc=net', 'desc': 'No such object'} and IPA shuts down. Using dbscan to view /var/lib/dirsrv/slapd-OURDOMAIN-NET/db/userRoot/id2entry.db4 I can see the data is still "there". Has anyone run into this issue and if so what needs to be done to correct it? From maciej.sawicki at polidea.pl Mon Mar 19 16:58:53 2012 From: maciej.sawicki at polidea.pl (Maciej Sawicki) Date: Mon, 19 Mar 2012 17:58:53 +0100 Subject: [Freeipa-users] Firefox on OS X 10.6 problem In-Reply-To: <4F676105.2030602@redhat.com> References: <4F676105.2030602@redhat.com> Message-ID: On Mon, Mar 19, 2012 at 5:38 PM, Dmitri Pal wrote: > Have you done everything covered in the section 4.3.3 of the document? > http://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/using-the-ui.html#Using_a_Browser_on_Another_System > Hi Dmitri, Thanks for quick answer. I did this, but still have the same problem :(. regards, Maciek Sawicki From maciej.sawicki at polidea.pl Mon Mar 19 17:02:59 2012 From: maciej.sawicki at polidea.pl (Maciej Sawicki) Date: Mon, 19 Mar 2012 18:02:59 +0100 Subject: [Freeipa-users] Firefox on OS X 10.6 problem In-Reply-To: References: <4F676105.2030602@redhat.com> Message-ID: Sorry for double post, but I would like to provide firefox log: 1886907584[10031d220]: using REQ_DELEGATE 1886907584[10031d220]: service = free-ipa.polidea.pl 1886907584[10031d220]: using negotiate-gss 1886907584[10031d220]: entering nsAuthGSSAPI::nsAuthGSSAPI() 1886907584[10031d220]: Attempting to load gss functions 1886907584[10031d220]: entering nsAuthGSSAPI::Init() 1886907584[10031d220]: nsHttpNegotiateAuth::GenerateCredentials() [challenge=Negotiate] 1886907584[10031d220]: entering nsAuthGSSAPI::GetNextToken() 1886907584[10031d220]: gss_init_sec_context() failed: Unspecified GSS failure. Minor code may provide more information 1886907584[10031d220]: leaving nsAuthGSSAPI::GetNextToken [rv=80004005] 1886907584[10031d220]: using REQ_DELEGATE 1886907584[10031d220]: service = free-ipa.polidea.pl 1886907584[10031d220]: using negotiate-gss 1886907584[10031d220]: entering nsAuthGSSAPI::nsAuthGSSAPI() 1886907584[10031d220]: entering nsAuthGSSAPI::Init() 1886907584[10031d220]: nsHttpNegotiateAuth::GenerateCredentials() [challenge=Negotiate] 1886907584[10031d220]: entering nsAuthGSSAPI::GetNextToken() 1886907584[10031d220]: gss_init_sec_context() failed: Unspecified GSS failure. Minor code may provide more information 1886907584[10031d220]: leaving nsAuthGSSAPI::GetNextToken [rv=80004005] best regards, Maciek Sawicki On Mon, Mar 19, 2012 at 5:58 PM, Maciej Sawicki wrote: > On Mon, Mar 19, 2012 at 5:38 PM, Dmitri Pal wrote: >> Have you done everything covered in the section 4.3.3 of the document? >> http://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/using-the-ui.html#Using_a_Browser_on_Another_System >> > Hi Dmitri, > Thanks for quick answer. I did this, but still have the same problem :(. > > regards, > Maciek Sawicki From sbingram at gmail.com Mon Mar 19 17:10:07 2012 From: sbingram at gmail.com (Stephen Ingram) Date: Mon, 19 Mar 2012 10:10:07 -0700 Subject: [Freeipa-users] Firefox on OS X 10.6 problem In-Reply-To: References: Message-ID: On Mon, Mar 19, 2012 at 9:31 AM, Maciej Sawicki wrote: > Hi, > Today I setup free ipa on CentOS release 6.2. I configured my client > machine, that is: > 1. I edited my "/Library/Preferences/edu.mit.Kerberos" file so it has > following content: > [domain_realm] > ? ?polidea.pl = POLIDEA.PL > ? ?.polidea.pl = .POLIDEA.PL > [libdefaults] > ? ?default_realm = POLIDEA.PL > ? ?dns_lookup_realm = true > ? ?dns_lookup_kdc = true > ? ?ticket_lifetime = 24h > ? ?forwardable = yes > [realms] > ? ?POLIDEA.PL = { > ? ?admin_server = free-ipa.polidea.pl:749 > ? ?default_domain = polidea.pl > ? ?kdc = free-ipa.polidea.pl:88 > ? ?} > > [logging] > ? ?kdc = FILE:/var/log/krb5kdc/kdc.log > ? ?admin_server = FILE:/var/log/krb5kdc/kadmin.log > I > > I run open /System/Library/Coreservices/Ticket\ Viewer.app and added > admin at POLIDEA.PL identity (i get ticket so password is valid) > > also i configured my firefox like in this link: > http://freeipa.org/page/InstallAndDeploy#Configuring_your_Browser > > Unfortunately when I try to login I get following error: > "Your kerberos ticket is no longer valid. Please run kinit and then > click 'Retry'. If this is your first time running the IPA Web UI > follow these directions to configure your browser." > > my /var/log/krb5kdc/kadmin.log has only few old entries (0 today's > entries from today). > > I will appreciate any help. I just edited /etc/krb5.conf on my mac and then kinit from command line and you should see ticket in the Ticket Viewer app. From there, you should be able to renew the ticket inside the app or from command line. I did not touch the /Library/Preferences/edu.mit.Kerberos file at all. Steve From maciej.sawicki at polidea.pl Mon Mar 19 17:22:09 2012 From: maciej.sawicki at polidea.pl (Maciej Sawicki) Date: Mon, 19 Mar 2012 18:22:09 +0100 Subject: [Freeipa-users] Firefox on OS X 10.6 problem In-Reply-To: References: Message-ID: On Mon, Mar 19, 2012 at 6:10 PM, Stephen Ingram wrote: > I just edited /etc/krb5.conf on my mac and then kinit from command > line and you should see ticket in the Ticket Viewer app. From there, > you should be able to renew the ticket inside the app or from command > line. I did not touch the /Library/Preferences/edu.mit.Kerberos file > at all. > > Steve Thanks from answer. I manage to solve this issue (I'm not sure if it best way but it works). In link from Dmitri I saw that I have to copy /etc/krb5.conf file from free-ipa server so I copied it to /Library/Preferences/edu.mit.Kerberos It's a little different then in http://freeipa.com/page/ConfiguringMacintoshClients. best regards, Maciek Sawicki From simo at redhat.com Mon Mar 19 17:27:23 2012 From: simo at redhat.com (Simo Sorce) Date: Mon, 19 Mar 2012 13:27:23 -0400 Subject: [Freeipa-users] Fedora 15 IPA Server Upgrade Broke LDAP In-Reply-To: <4F67630A.90807@adurotec.com> References: <4F67630A.90807@adurotec.com> Message-ID: <1332178043.9238.488.camel@willson.li.ssimo.org> On Mon, 2012-03-19 at 11:47 -0500, David wrote: > After upgrading the IPA server on a Fedora 15 host to > freeipa-server-2.1.4-3.fc15.x86_64 along with the LDAP dependency of > 389-ds-base-1.2.10.2-1.fc15.x86_64, the IPA server fails to start due to > the following error: > > Failed to read data from Directory Service: Failed to get list of > services to probe status! > Configured hostname 'ipa01.ourdomain.net' does not match any master > server in LDAP: > No master found because of error: {'matched': 'dc=ourdomain,dc=net', > 'desc': 'No such object'} > > and IPA shuts down. > > Using dbscan to view > /var/lib/dirsrv/slapd-OURDOMAIN-NET/db/userRoot/id2entry.db4 I can see > the data is still "there". > > Has anyone run into this issue and if so what needs to be done to > correct it? What 389ds version did you upgrad from (yum history can tell you). We have just had another thread with a user that upgraded from a alpha release of 389ds that should have not been used in production. Se the thread named: [Freeipa-users] (no subject) (yeah not a great subject :-) Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Mon Mar 19 17:44:43 2012 From: simo at redhat.com (Simo Sorce) Date: Mon, 19 Mar 2012 13:44:43 -0400 Subject: [Freeipa-users] Doubt on FreeIPA LDAP extensibility In-Reply-To: <1332174984.9238.403.camel@willson.li.ssimo.org> References: <1332008209.9238.328.camel@willson.li.ssimo.org> <1332159357.9238.331.camel@willson.li.ssimo.org> <1332163925.9238.344.camel@willson.li.ssimo.org> <1332174984.9238.403.camel@willson.li.ssimo.org> Message-ID: <1332179083.9238.511.camel@willson.li.ssimo.org> On Mon, 2012-03-19 at 12:36 -0400, Simo Sorce wrote: > On Mon, 2012-03-19 at 14:46 +0100, Marco Pizzoli wrote: > > > > > > On Mon, Mar 19, 2012 at 2:32 PM, Simo Sorce wrote: > > On Mon, 2012-03-19 at 13:51 +0100, Marco Pizzoli wrote: > > > > > > In attachment. You can find only one, but all of them are > > equivalent > > > from this point. > > > They are indeed seen as structural, even if my added schema > > file > > > declare them as auxiliary. > > > > > > Can you attach the (sanitized) schema file you added to > > 389ds ? > > > > Already done on this thread. See my previous mail to Dmitri. > > > > > > Also can you run a ldapsearch command and search in the > > 'cn=schema' > > base ? This will give you back what 389ds sends to a client. > > > > > > This command searches for everything but uses an attribute > > filter to > > show only the objectclasses: > > ldapsearch -x -h server -b 'cn=schema' 'objectClasses' > > > > No need to attach everything return, just edit the result and > > attach > > only the results for your calsses. > > > > Ok, here it is: > > [root at freeipa01 ~]# ldapsearch -h 127.0.0.1 -x -D"cn=Directory > > Manager" -s base -W -b "cn=schema" "objectClasses"|perl -0pe > > 's/\n //g' > > > > objectClasses: ( 1.3.6.1.4.1.36005.0.2.6.2 NAME 'xxxPeopleAttributes' > > DESC 'Definizione di attributi specifici per gli utenti XXX' > > STRUCTURAL MAY xxxUfficio ) > > objectClasses: ( 1.3.6.1.4.1.36005.0.2.6.3 NAME 'xxxGroupsAttributes' > > DESC 'Definizione di attributi specifici per i gruppi XXX' STRUCTURAL > > MAY ( xxxProgetto $ xxxAmbiente $ xxxTipoGruppo ) ) > > objectClasses: ( 1.3.6.1.4.1.36005.0.2.6.4 NAME 'xxxWebminAttributes' > > DESC 'Definizione di attributi specifici per gli oggetti Webmin' > > STRUCTURAL MAY xxxWebminAmbiente ) > > objectClasses: ( 1.3.6.1.4.1.36005.0.2.6.5 NAME > > 'xxxDB2GroupsAttributes' DESC 'Definizione di attributi specifici per > > i gruppi DB2' STRUCTURAL MAY xxxDB2GruppiPrivilegi ) > > objectClasses: ( 1.3.6.1.4.1.36005.0.2.6.1 NAME 'xxxAttributes' DESC > > 'Definizione di attributi specifici per utilizzo interno' STRUCTURAL > > MAY ( xxxProgetto $ xxxAmbiente $ xxxTipoGruppo $ > > xxxDB2GruppiPrivilegi ) ) > > > > > > By seeing this output, I just checked again and I confirm that in my > > file /etc/dirsrv/slapd-UNIX-MYDOMAIN-IT/schema/98myfile.ldif they are > > still AUXILIARY. > > This is odd, indeed, I will resurrect the bug you opened with a better > description, > thanks. Marco, I discussed this briefly with Nathan and it seem that it may be a parser error. 389DS parser is quite strict and wants the various definitions in the precise order they are defined in the RFCs. I guess that means that if you reorder where you define the type (AUXILIARY/STRUCTURAL) in the string you'll get the right behavior. As Is I think AUXILIARY is simply ignored because it is int eh wrong position and the default STRUCTURAL is used. If you can change your schema file to define AUS/STR in the right order (see other IPA ldif file for hints) and can confirm it is ano ordering problem we can open a documentation bug to explain this behavior until the underlying parser is improved to better handle random ordered definitions. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Mon Mar 19 18:57:26 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 19 Mar 2012 14:57:26 -0400 Subject: [Freeipa-users] Fedora 15 IPA Server Upgrade Broke LDAP In-Reply-To: <1332178043.9238.488.camel@willson.li.ssimo.org> References: <4F67630A.90807@adurotec.com> <1332178043.9238.488.camel@willson.li.ssimo.org> Message-ID: <4F678196.10705@redhat.com> Simo Sorce wrote: > On Mon, 2012-03-19 at 11:47 -0500, David wrote: >> After upgrading the IPA server on a Fedora 15 host to >> freeipa-server-2.1.4-3.fc15.x86_64 along with the LDAP dependency of >> 389-ds-base-1.2.10.2-1.fc15.x86_64, the IPA server fails to start due to >> the following error: >> >> Failed to read data from Directory Service: Failed to get list of >> services to probe status! >> Configured hostname 'ipa01.ourdomain.net' does not match any master >> server in LDAP: >> No master found because of error: {'matched': 'dc=ourdomain,dc=net', >> 'desc': 'No such object'} >> >> and IPA shuts down. >> >> Using dbscan to view >> /var/lib/dirsrv/slapd-OURDOMAIN-NET/db/userRoot/id2entry.db4 I can see >> the data is still "there". >> >> Has anyone run into this issue and if so what needs to be done to >> correct it? > > > What 389ds version did you upgrad from (yum history can tell you). > > We have just had another thread with a user that upgraded from a alpha > release of 389ds that should have not been used in production. > > Se the thread named: [Freeipa-users] (no subject) > > (yeah not a great subject :-) > > Simo. > Someone reported this in IRC as well today. The fix was to change DBVERSION to rdn-format-1 and run setup-ds.pl -u -s General.UpdateMode=offline rob From simo at redhat.com Mon Mar 19 19:12:08 2012 From: simo at redhat.com (Simo Sorce) Date: Mon, 19 Mar 2012 15:12:08 -0400 Subject: [Freeipa-users] Fedora 15 IPA Server Upgrade Broke LDAP In-Reply-To: <4F678196.10705@redhat.com> References: <4F67630A.90807@adurotec.com> <1332178043.9238.488.camel@willson.li.ssimo.org> <4F678196.10705@redhat.com> Message-ID: <1332184328.9238.571.camel@willson.li.ssimo.org> On Mon, 2012-03-19 at 14:57 -0400, Rob Crittenden wrote: > Simo Sorce wrote: > > On Mon, 2012-03-19 at 11:47 -0500, David wrote: > >> After upgrading the IPA server on a Fedora 15 host to > >> freeipa-server-2.1.4-3.fc15.x86_64 along with the LDAP dependency of > >> 389-ds-base-1.2.10.2-1.fc15.x86_64, the IPA server fails to start due to > >> the following error: > >> > >> Failed to read data from Directory Service: Failed to get list of > >> services to probe status! > >> Configured hostname 'ipa01.ourdomain.net' does not match any master > >> server in LDAP: > >> No master found because of error: {'matched': 'dc=ourdomain,dc=net', > >> 'desc': 'No such object'} > >> > >> and IPA shuts down. > >> > >> Using dbscan to view > >> /var/lib/dirsrv/slapd-OURDOMAIN-NET/db/userRoot/id2entry.db4 I can see > >> the data is still "there". > >> > >> Has anyone run into this issue and if so what needs to be done to > >> correct it? > > > > > > What 389ds version did you upgrad from (yum history can tell you). > > > > We have just had another thread with a user that upgraded from a alpha > > release of 389ds that should have not been used in production. > > > > Se the thread named: [Freeipa-users] (no subject) > > > > (yeah not a great subject :-) > > > > Simo. > > > > Someone reported this in IRC as well today. The fix was to change > DBVERSION to rdn-format-1 and run setup-ds.pl -u -s > General.UpdateMode=offline Rob is this a general issue we need to address, or is it a one off from some non-released versions of 389ds to 1.2.10.2 ? Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Mon Mar 19 19:31:28 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 19 Mar 2012 15:31:28 -0400 Subject: [Freeipa-users] Problem in "ipa migrate-ds" procedure In-Reply-To: References: <4F66121F.3090200@redhat.com> <4F6737B4.5040502@redhat.com> Message-ID: <4F678990.7020400@redhat.com> Marco Pizzoli wrote: > > > On Mon, Mar 19, 2012 at 2:42 PM, Rob Crittenden > wrote: > > Dmitri Pal wrote: > > On 03/17/2012 07:36 AM, Marco Pizzoli wrote: > > Hi guys, > I'm trying to migrate my ldap user base to freeipa. I'm > using the last > Release Candidate. > > I already changed "ipa config-mod --enable-migration=TRUE" > This is what I have: > > ipa -v migrate-ds > --bind-dn="cn=manager,dc=__mydc1,dc=mydc2.it > " > --user-container="ou=people,__dc=mydc1,dc=mydc2.it > > " --user-objectclass=__inetOrgPerson > --group-container="ou=groups,__dc=mydc1,dc=mydc2.it > " > --group-objectclass=posixGroup > --base-dn="dc=mydc1,dc=mydc2.__it > " --with-compat ldap://ldap01 > > ipa: INFO: trying > https://freeipa01.unix.__mydomain.it/ipa/xml > > Password: > ipa: INFO: Forwarding 'migrate_ds' to server > u'http://freeipa01.unix.__mydomain.it/ipa/xml > ' > ipa: ERROR: Container for group not found at > ou=groups,dc=mydc1,dc=mydc2.it > > > > I looked at my ldap server logs and I found out that the search > executed has scope=1. Actually both for users and groups. > This is a > problem for me, in having a lot of subtrees (ou) in which my > users and > groups are. Is there a way to manage this? > > Thanks in advance > Marco > > P.s. As a side note, I suppose there's a typo in the verbose > message I > obtain in my output: > ipa: INFO: Forwarding 'migrate_ds' to server > *u*'http://freeipa01.unix.__mydomain.it/ipa/xml > ' > > > Please open tickets for both issues. > > > Well, I don't think either is a bug. > > If you have users/groups in multiple places you'll need to migrate > them individually for now. It is safe to run migrate-ds multiple > times, existing users are not migrated. > > > I just re-executed by specifing a nested ou for my groups. > This is what I got: > > ipa: INFO: trying https://freeipa01.unix.csebo.it/ipa/xml > ipa: INFO: Forwarding 'migrate_ds' to server > u'http://freeipa01.unix.csebo.it/ipa/xml' > ----------- > migrate-ds: > ----------- > Migrated: > Failed user: > fw03075_no: Type or value exists: > [other users listed] > Failed group: > pdbac32: Type or value exists: > [other groups listed] > ---------- > Passwords have been migrated in pre-hashed format. > IPA is unable to generate Kerberos keys unless provided > with clear text passwords. All migrated users need to > login at https://your.domain/ipa/migration/ before they > can use their Kerberos accounts. > > I don't understand what it's trying to telling me. > On my FreeIPA ldap server I don't see any imported user. > > What's my fault here? > > > The u is a python-ism for unicode. This is not a bug. > > > Please, could you give a little more detail on this? It's only a hint on > what that data represents in a Python variable? > > Thanks again > Marco Type or value exists occurs when one tries to add an attribute value to an entry that already exists. I suspect that the underlying problem is different between users and groups. For groups it is likely adding a duplicate member. For users I'm not really sure. It could be one of the POSIX attributes. What does a failed entry look like? rob From Steven.Jones at vuw.ac.nz Mon Mar 19 19:58:58 2012 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Mon, 19 Mar 2012 19:58:58 +0000 Subject: [Freeipa-users] Extending IPA schema for Federation services. In-Reply-To: <4F673AED.9000704@redhat.com> References: <833D8E48405E064EBC54C84EC6B36E404CC0FA66@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4F673AED.9000704@redhat.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E404CC0FEE3@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, Im starting from scratch here so bear with me......ie I dont know a lot of this....which should be obvious.... Extending Easy? oh because it doesnt strike me as easy...... :/ Initially I am about to build our production IPA servers. These attributes are a requirement of the Federation system New Zealand wants to use and is probably the same for Australia. So I think the schema has to be done/extended for IPA to be viable in tertiary institutions in NZ, without it not many if anyone will use IPA they will stay with openldap. So each person should have these I think.....they may not be used initially but once extended initially then I dont have to extend the schema later. What connects to these is an apache/tomcat front end. There are two aspects/functions to this, the IdP and the SdP. The Idp allows remote tertiary organisations to query us and say our user is we legit....they then use their LDAP to provide resources via the SdP. So the Idp provides an identity to remote ppl and the SdP provides access to a resource at our end. later I expect we will have to to the SdP bit got our high performance cluster and storage... It maybe a year or more before we actually use this, but it strikes me as sensible that these are done on initial build.....I will put ina RH support case for this. We will probably also pull the actual fields/contents out of AD.....not sure yet. regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: Rob Crittenden [rcritten at redhat.com] Sent: Tuesday, 20 March 2012 2:55 a.m. To: Steven Jones Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Extending IPA schema for Federation services. Steven Jones wrote: > Hi, > > > Is it possible to expand IPA's schema to do this? Adding the schema is easy, doing something with it is where things get interesting. What do you want to do with these attributes/objectclasses? rob From dpal at redhat.com Mon Mar 19 20:19:49 2012 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 19 Mar 2012 16:19:49 -0400 Subject: [Freeipa-users] Extending IPA schema for Federation services. In-Reply-To: <833D8E48405E064EBC54C84EC6B36E404CC0FEE3@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E404CC0FA66@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4F673AED.9000704@redhat.com> <833D8E48405E064EBC54C84EC6B36E404CC0FEE3@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <4F6794E5.6060805@redhat.com> On 03/19/2012 03:58 PM, Steven Jones wrote: > Hi, > > Im starting from scratch here so bear with me......ie I dont know a lot of this....which should be obvious.... > > Extending Easy? oh because it doesnt strike me as easy...... > > :/ > > Initially I am about to build our production IPA servers. These attributes are a requirement of the Federation system New Zealand wants to use and is probably the same for Australia. So I think the schema has to be done/extended for IPA to be viable in tertiary institutions in NZ, without it not many if anyone will use IPA they will stay with openldap. So each person should have these I think.....they may not be used initially but once extended initially then I dont have to extend the schema later. > > What connects to these is an apache/tomcat front end. There are two aspects/functions to this, the IdP and the SdP. The Idp allows remote tertiary organisations to query us and say our user is we legit....they then use their LDAP to provide resources via the SdP. So the Idp provides an identity to remote ppl and the SdP provides access to a resource at our end. later I expect we will have to to the SdP bit got our high performance cluster and storage... > > It maybe a year or more before we actually use this, but it strikes me as sensible that these are done on initial build.....I will put ina RH support case for this. We will probably also pull the actual fields/contents out of AD.....not sure yet. The question is simple: how you plan to manage these attributes in IPA? Do you expect them to be a part of the UI/CLI or they should be hidden there and be managed via ldapmodify and other data sync tools? This make the whole difference especially the UI part. Depending upon these expectations the scope would be different. > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > ________________________________________ > From: Rob Crittenden [rcritten at redhat.com] > Sent: Tuesday, 20 March 2012 2:55 a.m. > To: Steven Jones > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Extending IPA schema for Federation services. > > Steven Jones wrote: >> Hi, >> >> >> Is it possible to expand IPA's schema to do this? > Adding the schema is easy, doing something with it is where things get > interesting. What do you want to do with these attributes/objectclasses? > > rob > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From g17jimmy at gmail.com Mon Mar 19 20:35:47 2012 From: g17jimmy at gmail.com (Jimmy) Date: Mon, 19 Mar 2012 16:35:47 -0400 Subject: [Freeipa-users] (no subject) In-Reply-To: <4F63B0E5.7030104@redhat.com> References: <4F622FC9.8040003@redhat.com> <4F624162.7020806@redhat.com> <4F62554F.1030804@redhat.com> <4F626135.3030402@redhat.com> <4F63575B.6090805@redhat.com> <4F636F7A.4060109@redhat.com> <4F6388E7.9000409@redhat.com> <4F63A3EC.6010205@redhat.com> <4F63B0E5.7030104@redhat.com> Message-ID: This is all I see in the /var/log/httpd/error_log file. This issue has become critical. The server has been down a week and I have no idea why certmonger broke and don't seem to have any indication of how to fix it. What would be the best route besides chasing down this certmonger issue? Could I export all of my configuration/users/etc, install a completely new IPA and import my config? [Sat Mar 03 00:05:27 2012] [error] ipa: INFO: sslget 'https://csp-idm.pdh.csp:443/ca/agent/ca/displayBySerial' [Sat Mar 03 00:05:28 2012] [error] ipa: INFO: host/csp-idm.pdh.csp at PDH.CSP: cert_request(u'MIIDQzCCAisCAQAwLDEQMA4GA1UEChMHUERILkNTUDEYMBYGA1 UEAxMPY3NwLWlkbS5wZGguY3NwMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr0EHCdyTuteryFZ2bdEl+V4OATR/xk8ELthmvlwT/5qubZKwlCWS6yLawgdyCg9Yw737A7q Ge0BPxHv6E+as10NxppEPsn9BOi+TPRIMYNMNNYmO2sce2pvkMkVBqsF7Gn7mF7e5+Bpc7ApnDGP7WLsAjbso8EvLUrqVMTNyiziCSHiNk+/Fi1Om6K5GKzKkqfEDex0RK+kpMswgcaZH hmW3i+y3UxFZsJjOg3R4fJAfC0+My2d1Vx4052+EgWAbSNpSj7zmLGM2+dkmgMo5Li7jjgJe8VsrqOV4L5IgqtGVJ0EOb7EP7gynbVoa74m4XrVwEP8rd/M5RxAnD1JPuwIDAQABoIHRM BoGCSqGSIb3DQEJFDENEwtTZXJ2ZXItQ2VydDCBsgYJKoZIhvcNAQkOMYGkMIGhMA4GA1UdDwEBAAQEAwIE8DB3BgNVHREBAQAEbTBroCwGCisGAQQBgjcUAgOgHgwcbGRhcC9jc3AtaW RtLnBkaC5jc3BAUERILkNTUKA7BgYrBgEFAgKgMTAvoAkbB1BESC5DU1ChIjAgoAMCAQGhGTAXGwRsZGFwGw9jc3AtaWRtLnBkaC5jc3AwFgYDVR0lAQEABAwwCgYIKwYBBQUHAwEwDQY JKoZIhvcNAQELBQADggEBABD/Hwbgf5NJNUYt0+ntMDHiilMFkSaO6ryQ36/pCH1oR+vI+PCeClHewPo0v99h4Z8W8L7CQtDdNBUMl/JVHH5Lz7cBF8A/jXZQ+naV17EEuXncacM8AvYh 5dL2yih+8RpPalEmSgz5rijtbSigfNGrZn0Mh3qOW1kbsz+GDaaT9wLFxvdJyqgdKds2tsp0KzHIMcJuw3cwOfH8zrBRV28XYhMLm0OOhj92uxgax5UPY2VyHP5UOtOnfuduU1ZXa+o8Q IXqX7/HyDSCLGwiPJscAsp9cRzjn4KvqzZDOcdGEjXmCGfrmUiMcuzVyTDR2SdAWrHdbRmXeyVxmiBPzdk=', principal=u'ldap/csp-idm.pdh.csp at PDH.CSP', add=True): C ertificateOperationError On Fri, Mar 16, 2012 at 5:30 PM, Rob Crittenden wrote: > Jimmy wrote: >> >> I actually shut down IPA to do the export and restarted after I imported. >> >> certutil -L -d /etc/httpd/alias >> Certificate Nickname ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Trust >> Attributes >> >> ?SSL,S/MIME,JAR/XPI >> Server-Cert ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?u,u,u >> ABC.XYZIPA CA ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? CT,C,C >> ipaCert ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?u,u,u >> Signing-Cert ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? u,u,u >> >> certutil -V -u V -n Server-Cert -d /etc/httpd/alias -e -f >> /etc/httpd/alias/pwdfile.txt >> certutil: certificate is valid >> >> How's that look? > > > That's what it's supposed to look like. Is Apache logging a failure or maybe > that is coming from dogtag through Apache... > > > rob > >> >> >> On Fri, Mar 16, 2012 at 4:34 PM, Rob Crittenden >> ?wrote: >>> >>> Jimmy wrote: >>>> >>>> >>>> ipa-getcert list shows some ugly output - http://fpaste.org/bV2v/ >>> >>> >>> >>> Looks pretty similar to what we've been seeing. The invalid credentials >>> means that dogtag can't validate RA agent cert. This was due to the >>> corrupted database. You'll need to restart the pki-cad process once the >>> LDAP >>> backend is fixed. >>> >>> The trust issues are stranger. To show the certs in those databases: >>> >>> # certutil -L -d /etc/httpd/alias >>> >>> To verify that the cert in there now has all the CA certs it needs: >>> # certutil -V -u V -n Server-Cert -d /etc/httpd/alias -e -f >>> /etc/httpd/alias/pwdfile.txt >>> >>> rob >>> >>> >>>> >>>> On Fri, Mar 16, 2012 at 4:05 PM, Jimmy ? ?wrote: >>>>> >>>>> >>>>> I exported/imported the /var/lib/dirsrv/slapd-PKI-IPA/db/userRoot and >>>>> that went smoothly but now I see this in /var/log/pki-ca/system: >>>>> >>>>> 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] >>>>> Operation Error - netscape.ldap.LDAPException: error result (32); >>>>> matchedDN >>>>> ?= o=ipaca >>>>> 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] Null >>>>> response control >>>>> 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] >>>>> Operation Error - netscape.ldap.LDAPException: error result (32); >>>>> matchedDN >>>>> ?= o=ipaca >>>>> 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] Null >>>>> response control >>>>> 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] >>>>> Operation Error - netscape.ldap.LDAPException: error result (32); >>>>> matchedDN >>>>> ?= o=ipaca >>>>> 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] Null >>>>> response control >>>>> 10358.CRLIssuingPoint-MasterCRL - [08/Mar/2012:04:36:29 UTC] [3] [3] >>>>> CRLIssuingPoint MasterCRL - Cannot create or store the first CRL in >>>>> the >>>>> internaldb. The internaldb could be down. Error LDAP operation failure >>>>> - cn=MasterCRL,ou=crlIssuingPoints, ou=ca, o=ipaca netscape.ldap.LDAPE >>>>> xception: error result (32); matchedDN = o=ipaca >>>>> >>>>> >>>>> catalina.out -- http://fpaste.org/oRQd/ >>>>> >>>>> ca-debug -- http://fpaste.org/zzFL/ >>>>> >>>>> Any ideas? >>>>> On Fri, Mar 16, 2012 at 2:39 PM, Rob Crittenden >>>>> ?wrote: >>>>>> >>>>>> >>>>>> Jimmy wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> The ca_audit problem was caused by me accidentally moving the >>>>>>> directory to a backup location. I was cleaning up the logs to make >>>>>>> reading easier. When I moved the directory back that issue went away. >>>>>>> No changes were made in the NSS database(s) or any other internal >>>>>>> workings of IPA. This system is used for very basic user >>>>>>> authentication, DNS, etc. >>>>>>> >>>>>>> I can do the ldif export/import for dogtag. Just from comparing >>>>>>> everything, it looks like the dogtag db is in >>>>>>> /var/lib/dirsrv/slapd-PKI-IPA/db/userRoot, is that correct? >>>>>>> >>>>>> >>>>>> The ipaca db >>>>>> >>>>>> rob >>>>>> >>> > From Steven.Jones at vuw.ac.nz Mon Mar 19 20:53:01 2012 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Mon, 19 Mar 2012 20:53:01 +0000 Subject: [Freeipa-users] Extending IPA schema for Federation services. In-Reply-To: <4F6794E5.6060805@redhat.com> References: <833D8E48405E064EBC54C84EC6B36E404CC0FA66@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4F673AED.9000704@redhat.com> <833D8E48405E064EBC54C84EC6B36E404CC0FEE3@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4F6794E5.6060805@redhat.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E404CC110B7@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, Is it sensible/better to extend the scheme before I start adding users? or doesnt it matter? From my perspective extending a system in use carries risk and impact to users, so its seems safer to extend it before I have any users, even if its un-used for now/? Apart from that I dont know....for now I would live with the extended schema for the user....populating the fields would be something I would look at when its decided what we will be doing....no one yet knows or at least have not told me what they will be doing. I suspect in the end we will draw the contents from AD with winsync? or populate/inject it directly via our Oracle identity system......so I'm not sure we will need the ui / gui....I dont expect to add content via it, I suspect I might need to fault find to make sure the data is there but I assume ldap search tools will return this anyway? However for other sites they may well not have an AD or user provisioning system....... regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Dmitri Pal [dpal at redhat.com] Sent: Tuesday, 20 March 2012 9:19 a.m. To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Extending IPA schema for Federation services. On 03/19/2012 03:58 PM, Steven Jones wrote: > Hi, > > Im starting from scratch here so bear with me......ie I dont know a lot of this....which should be obvious.... > > Extending Easy? oh because it doesnt strike me as easy...... > > :/ > > Initially I am about to build our production IPA servers. These attributes are a requirement of the Federation system New Zealand wants to use and is probably the same for Australia. So I think the schema has to be done/extended for IPA to be viable in tertiary institutions in NZ, without it not many if anyone will use IPA they will stay with openldap. So each person should have these I think.....they may not be used initially but once extended initially then I dont have to extend the schema later. > > What connects to these is an apache/tomcat front end. There are two aspects/functions to this, the IdP and the SdP. The Idp allows remote tertiary organisations to query us and say our user is we legit....they then use their LDAP to provide resources via the SdP. So the Idp provides an identity to remote ppl and the SdP provides access to a resource at our end. later I expect we will have to to the SdP bit got our high performance cluster and storage... > > It maybe a year or more before we actually use this, but it strikes me as sensible that these are done on initial build.....I will put ina RH support case for this. We will probably also pull the actual fields/contents out of AD.....not sure yet. The question is simple: how you plan to manage these attributes in IPA? Do you expect them to be a part of the UI/CLI or they should be hidden there and be managed via ldapmodify and other data sync tools? This make the whole difference especially the UI part. Depending upon these expectations the scope would be different. > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > ________________________________________ > From: Rob Crittenden [rcritten at redhat.com] > Sent: Tuesday, 20 March 2012 2:55 a.m. > To: Steven Jones > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Extending IPA schema for Federation services. > > Steven Jones wrote: >> Hi, >> >> >> Is it possible to expand IPA's schema to do this? > Adding the schema is easy, doing something with it is where things get > interesting. What do you want to do with these attributes/objectclasses? > > rob > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, 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 rcritten at redhat.com Mon Mar 19 20:58:01 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 19 Mar 2012 16:58:01 -0400 Subject: [Freeipa-users] (no subject) In-Reply-To: References: <4F624162.7020806@redhat.com> <4F62554F.1030804@redhat.com> <4F626135.3030402@redhat.com> <4F63575B.6090805@redhat.com> <4F636F7A.4060109@redhat.com> <4F6388E7.9000409@redhat.com> <4F63A3EC.6010205@redhat.com> <4F63B0E5.7030104@redhat.com> Message-ID: <4F679DD9.7090106@redhat.com> Jimmy wrote: > This is all I see in the /var/log/httpd/error_log file. This issue has > become critical. The server has been down a week and I have no idea > why certmonger broke and don't seem to have any indication of how to > fix it. What would be the best route besides chasing down this > certmonger issue? Could I export all of my configuration/users/etc, > install a completely new IPA and import my config? > > [Sat Mar 03 00:05:27 2012] [error] ipa: INFO: sslget > 'https://csp-idm.pdh.csp:443/ca/agent/ca/displayBySerial' > [Sat Mar 03 00:05:28 2012] [error] ipa: INFO: > host/csp-idm.pdh.csp at PDH.CSP: > cert_request(u'MIIDQzCCAisCAQAwLDEQMA4GA1UEChMHUERILkNTUDEYMBYGA1 > UEAxMPY3NwLWlkbS5wZGguY3NwMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr0EHCdyTuteryFZ2bdEl+V4OATR/xk8ELthmvlwT/5qubZKwlCWS6yLawgdyCg9Yw737A7q > Ge0BPxHv6E+as10NxppEPsn9BOi+TPRIMYNMNNYmO2sce2pvkMkVBqsF7Gn7mF7e5+Bpc7ApnDGP7WLsAjbso8EvLUrqVMTNyiziCSHiNk+/Fi1Om6K5GKzKkqfEDex0RK+kpMswgcaZH > hmW3i+y3UxFZsJjOg3R4fJAfC0+My2d1Vx4052+EgWAbSNpSj7zmLGM2+dkmgMo5Li7jjgJe8VsrqOV4L5IgqtGVJ0EOb7EP7gynbVoa74m4XrVwEP8rd/M5RxAnD1JPuwIDAQABoIHRM > BoGCSqGSIb3DQEJFDENEwtTZXJ2ZXItQ2VydDCBsgYJKoZIhvcNAQkOMYGkMIGhMA4GA1UdDwEBAAQEAwIE8DB3BgNVHREBAQAEbTBroCwGCisGAQQBgjcUAgOgHgwcbGRhcC9jc3AtaW > RtLnBkaC5jc3BAUERILkNTUKA7BgYrBgEFAgKgMTAvoAkbB1BESC5DU1ChIjAgoAMCAQGhGTAXGwRsZGFwGw9jc3AtaWRtLnBkaC5jc3AwFgYDVR0lAQEABAwwCgYIKwYBBQUHAwEwDQY > JKoZIhvcNAQELBQADggEBABD/Hwbgf5NJNUYt0+ntMDHiilMFkSaO6ryQ36/pCH1oR+vI+PCeClHewPo0v99h4Z8W8L7CQtDdNBUMl/JVHH5Lz7cBF8A/jXZQ+naV17EEuXncacM8AvYh > 5dL2yih+8RpPalEmSgz5rijtbSigfNGrZn0Mh3qOW1kbsz+GDaaT9wLFxvdJyqgdKds2tsp0KzHIMcJuw3cwOfH8zrBRV28XYhMLm0OOhj92uxgax5UPY2VyHP5UOtOnfuduU1ZXa+o8Q > IXqX7/HyDSCLGwiPJscAsp9cRzjn4KvqzZDOcdGEjXmCGfrmUiMcuzVyTDR2SdAWrHdbRmXeyVxmiBPzdk=', > principal=u'ldap/csp-idm.pdh.csp at PDH.CSP', add=True): C > ertificateOperationError I think your CA is still not up and running. Things to check: /var/log/pki-ca/catalina.out to be see if there are start up errors. The debug log in the same directory may contain information as well. If you are seeing a bunch of error 32's it means your db is still corrupted. The output of ipa-getcert list. This will tell you what certmonger thinks is wrong. Did you repair the ipaca backend in PKI-IPA? It is different than userRoot. rob > > > On Fri, Mar 16, 2012 at 5:30 PM, Rob Crittenden wrote: >> Jimmy wrote: >>> >>> I actually shut down IPA to do the export and restarted after I imported. >>> >>> certutil -L -d /etc/httpd/alias >>> Certificate Nickname Trust >>> Attributes >>> >>> SSL,S/MIME,JAR/XPI >>> Server-Cert u,u,u >>> ABC.XYZIPA CA CT,C,C >>> ipaCert u,u,u >>> Signing-Cert u,u,u >>> >>> certutil -V -u V -n Server-Cert -d /etc/httpd/alias -e -f >>> /etc/httpd/alias/pwdfile.txt >>> certutil: certificate is valid >>> >>> How's that look? >> >> >> That's what it's supposed to look like. Is Apache logging a failure or maybe >> that is coming from dogtag through Apache... >> >> >> rob >> >>> >>> >>> On Fri, Mar 16, 2012 at 4:34 PM, Rob Crittenden >>> wrote: >>>> >>>> Jimmy wrote: >>>>> >>>>> >>>>> ipa-getcert list shows some ugly output - http://fpaste.org/bV2v/ >>>> >>>> >>>> >>>> Looks pretty similar to what we've been seeing. The invalid credentials >>>> means that dogtag can't validate RA agent cert. This was due to the >>>> corrupted database. You'll need to restart the pki-cad process once the >>>> LDAP >>>> backend is fixed. >>>> >>>> The trust issues are stranger. To show the certs in those databases: >>>> >>>> # certutil -L -d /etc/httpd/alias >>>> >>>> To verify that the cert in there now has all the CA certs it needs: >>>> # certutil -V -u V -n Server-Cert -d /etc/httpd/alias -e -f >>>> /etc/httpd/alias/pwdfile.txt >>>> >>>> rob >>>> >>>> >>>>> >>>>> On Fri, Mar 16, 2012 at 4:05 PM, Jimmy wrote: >>>>>> >>>>>> >>>>>> I exported/imported the /var/lib/dirsrv/slapd-PKI-IPA/db/userRoot and >>>>>> that went smoothly but now I see this in /var/log/pki-ca/system: >>>>>> >>>>>> 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] >>>>>> Operation Error - netscape.ldap.LDAPException: error result (32); >>>>>> matchedDN >>>>>> = o=ipaca >>>>>> 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] Null >>>>>> response control >>>>>> 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] >>>>>> Operation Error - netscape.ldap.LDAPException: error result (32); >>>>>> matchedDN >>>>>> = o=ipaca >>>>>> 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] Null >>>>>> response control >>>>>> 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] >>>>>> Operation Error - netscape.ldap.LDAPException: error result (32); >>>>>> matchedDN >>>>>> = o=ipaca >>>>>> 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] Null >>>>>> response control >>>>>> 10358.CRLIssuingPoint-MasterCRL - [08/Mar/2012:04:36:29 UTC] [3] [3] >>>>>> CRLIssuingPoint MasterCRL - Cannot create or store the first CRL in >>>>>> the >>>>>> internaldb. The internaldb could be down. Error LDAP operation failure >>>>>> - cn=MasterCRL,ou=crlIssuingPoints, ou=ca, o=ipaca netscape.ldap.LDAPE >>>>>> xception: error result (32); matchedDN = o=ipaca >>>>>> >>>>>> >>>>>> catalina.out -- http://fpaste.org/oRQd/ >>>>>> >>>>>> ca-debug -- http://fpaste.org/zzFL/ >>>>>> >>>>>> Any ideas? >>>>>> On Fri, Mar 16, 2012 at 2:39 PM, Rob Crittenden >>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> Jimmy wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> The ca_audit problem was caused by me accidentally moving the >>>>>>>> directory to a backup location. I was cleaning up the logs to make >>>>>>>> reading easier. When I moved the directory back that issue went away. >>>>>>>> No changes were made in the NSS database(s) or any other internal >>>>>>>> workings of IPA. This system is used for very basic user >>>>>>>> authentication, DNS, etc. >>>>>>>> >>>>>>>> I can do the ldif export/import for dogtag. Just from comparing >>>>>>>> everything, it looks like the dogtag db is in >>>>>>>> /var/lib/dirsrv/slapd-PKI-IPA/db/userRoot, is that correct? >>>>>>>> >>>>>>> >>>>>>> The ipaca db >>>>>>> >>>>>>> rob >>>>>>> >>>> >> From rcritten at redhat.com Mon Mar 19 21:14:30 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 19 Mar 2012 17:14:30 -0400 Subject: [Freeipa-users] Fedora 15 IPA Server Upgrade Broke LDAP In-Reply-To: <1332184328.9238.571.camel@willson.li.ssimo.org> References: <4F67630A.90807@adurotec.com> <1332178043.9238.488.camel@willson.li.ssimo.org> <4F678196.10705@redhat.com> <1332184328.9238.571.camel@willson.li.ssimo.org> Message-ID: <4F67A1B6.3050909@redhat.com> Simo Sorce wrote: > On Mon, 2012-03-19 at 14:57 -0400, Rob Crittenden wrote: >> Simo Sorce wrote: >>> On Mon, 2012-03-19 at 11:47 -0500, David wrote: >>>> After upgrading the IPA server on a Fedora 15 host to >>>> freeipa-server-2.1.4-3.fc15.x86_64 along with the LDAP dependency of >>>> 389-ds-base-1.2.10.2-1.fc15.x86_64, the IPA server fails to start due to >>>> the following error: >>>> >>>> Failed to read data from Directory Service: Failed to get list of >>>> services to probe status! >>>> Configured hostname 'ipa01.ourdomain.net' does not match any master >>>> server in LDAP: >>>> No master found because of error: {'matched': 'dc=ourdomain,dc=net', >>>> 'desc': 'No such object'} >>>> >>>> and IPA shuts down. >>>> >>>> Using dbscan to view >>>> /var/lib/dirsrv/slapd-OURDOMAIN-NET/db/userRoot/id2entry.db4 I can see >>>> the data is still "there". >>>> >>>> Has anyone run into this issue and if so what needs to be done to >>>> correct it? >>> >>> >>> What 389ds version did you upgrad from (yum history can tell you). >>> >>> We have just had another thread with a user that upgraded from a alpha >>> release of 389ds that should have not been used in production. >>> >>> Se the thread named: [Freeipa-users] (no subject) >>> >>> (yeah not a great subject :-) >>> >>> Simo. >>> >> >> Someone reported this in IRC as well today. The fix was to change >> DBVERSION to rdn-format-1 and run setup-ds.pl -u -s >> General.UpdateMode=offline > > Rob is this a general issue we need to address, or is it a one off from > some non-released versions of 389ds to 1.2.10.2 ? > > Simo. > It is unclear. At least one user that reported this was running an alpha release of 389-ds. rob From rcritten at redhat.com Mon Mar 19 21:34:56 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 19 Mar 2012 17:34:56 -0400 Subject: [Freeipa-users] Extending IPA schema for Federation services. In-Reply-To: <833D8E48405E064EBC54C84EC6B36E404CC110B7@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E404CC0FA66@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4F673AED.9000704@redhat.com> <833D8E48405E064EBC54C84EC6B36E404CC0FEE3@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4F6794E5.6060805@redhat.com> <833D8E48405E064EBC54C84EC6B36E404CC110B7@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <4F67A680.1040201@redhat.com> Steven Jones wrote: > Hi, > > Is it sensible/better to extend the scheme before I start adding users? or doesnt it matter? From my perspective extending a system in use carries risk and impact to users, so its seems safer to extend it before I have any users, even if its un-used for now/? If you do it later you may need to write a script to update all existing users with the missing objectclasses. > Apart from that I dont know....for now I would live with the extended schema for the user....populating the fields would be something I would look at when its decided what we will be doing....no one yet knows or at least have not told me what they will be doing. It matters depending on whether the attributes in those objectclasses are required or not. > I suspect in the end we will draw the contents from AD with winsync? The list of attributes for winsync is currently hardcoded. > > or populate/inject it directly via our Oracle identity system......so I'm not sure we will need the ui / gui....I dont expect to add content via it, I suspect I might need to fault find to make sure the data is there but I assume ldap search tools will return this anyway? Right, it is possible to use the IPA LDAP server as a data store, the framework need not know about these extra attributes. > > However for other sites they may well not have an AD or user provisioning system....... > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > ________________________________________ > From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Dmitri Pal [dpal at redhat.com] > Sent: Tuesday, 20 March 2012 9:19 a.m. > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Extending IPA schema for Federation services. > > On 03/19/2012 03:58 PM, Steven Jones wrote: >> Hi, >> >> Im starting from scratch here so bear with me......ie I dont know a lot of this....which should be obvious.... >> >> Extending Easy? oh because it doesnt strike me as easy...... >> >> :/ >> >> Initially I am about to build our production IPA servers. These attributes are a requirement of the Federation system New Zealand wants to use and is probably the same for Australia. So I think the schema has to be done/extended for IPA to be viable in tertiary institutions in NZ, without it not many if anyone will use IPA they will stay with openldap. So each person should have these I think.....they may not be used initially but once extended initially then I dont have to extend the schema later. >> >> What connects to these is an apache/tomcat front end. There are two aspects/functions to this, the IdP and the SdP. The Idp allows remote tertiary organisations to query us and say our user is we legit....they then use their LDAP to provide resources via the SdP. So the Idp provides an identity to remote ppl and the SdP provides access to a resource at our end. later I expect we will have to to the SdP bit got our high performance cluster and storage... >> >> It maybe a year or more before we actually use this, but it strikes me as sensible that these are done on initial build.....I will put ina RH support case for this. We will probably also pull the actual fields/contents out of AD.....not sure yet. > > > The question is simple: how you plan to manage these attributes in IPA? > Do you expect them to be a part of the UI/CLI or they should be hidden > there and be managed via ldapmodify and other data sync tools? > > This make the whole difference especially the UI part. Depending upon > these expectations the scope would be different. > > >> regards >> >> Steven Jones >> >> Technical Specialist - Linux RHCE >> >> Victoria University, Wellington, NZ >> >> 0064 4 463 6272 >> >> ________________________________________ >> From: Rob Crittenden [rcritten at redhat.com] >> Sent: Tuesday, 20 March 2012 2:55 a.m. >> To: Steven Jones >> Cc: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] Extending IPA schema for Federation services. >> >> Steven Jones wrote: >>> Hi, >>> >>> >>> Is it possible to expand IPA's schema to do this? >> Adding the schema is easy, doing something with it is where things get >> interesting. What do you want to do with these attributes/objectclasses? >> >> rob >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IPA project, > 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 > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From marco.pizzoli at gmail.com Mon Mar 19 22:44:18 2012 From: marco.pizzoli at gmail.com (Marco Pizzoli) Date: Mon, 19 Mar 2012 23:44:18 +0100 Subject: [Freeipa-users] Doubt on FreeIPA LDAP extensibility In-Reply-To: <1332179083.9238.511.camel@willson.li.ssimo.org> References: <1332008209.9238.328.camel@willson.li.ssimo.org> <1332159357.9238.331.camel@willson.li.ssimo.org> <1332163925.9238.344.camel@willson.li.ssimo.org> <1332174984.9238.403.camel@willson.li.ssimo.org> <1332179083.9238.511.camel@willson.li.ssimo.org> Message-ID: Hi On Mon, Mar 19, 2012 at 6:44 PM, Simo Sorce wrote: > On Mon, 2012-03-19 at 12:36 -0400, Simo Sorce wrote: > > On Mon, 2012-03-19 at 14:46 +0100, Marco Pizzoli wrote: > > > > > > > > > On Mon, Mar 19, 2012 at 2:32 PM, Simo Sorce wrote: > > > On Mon, 2012-03-19 at 13:51 +0100, Marco Pizzoli wrote: > > > > > > > > In attachment. You can find only one, but all of them are > > > equivalent > > > > from this point. > > > > They are indeed seen as structural, even if my added schema > > > file > > > > declare them as auxiliary. > > > > > > > > > Can you attach the (sanitized) schema file you added to > > > 389ds ? > > > > > > Already done on this thread. See my previous mail to Dmitri. > > > > > > > > > Also can you run a ldapsearch command and search in the > > > 'cn=schema' > > > base ? This will give you back what 389ds sends to a client. > > > > > > > > > This command searches for everything but uses an attribute > > > filter to > > > show only the objectclasses: > > > ldapsearch -x -h server -b 'cn=schema' 'objectClasses' > > > > > > No need to attach everything return, just edit the result and > > > attach > > > only the results for your calsses. > > > > > > Ok, here it is: > > > [root at freeipa01 ~]# ldapsearch -h 127.0.0.1 -x -D"cn=Directory > > > Manager" -s base -W -b "cn=schema" "objectClasses"|perl -0pe > > > 's/\n //g' > > > > > > objectClasses: ( 1.3.6.1.4.1.36005.0.2.6.2 NAME 'xxxPeopleAttributes' > > > DESC 'Definizione di attributi specifici per gli utenti XXX' > > > STRUCTURAL MAY xxxUfficio ) > > > objectClasses: ( 1.3.6.1.4.1.36005.0.2.6.3 NAME 'xxxGroupsAttributes' > > > DESC 'Definizione di attributi specifici per i gruppi XXX' STRUCTURAL > > > MAY ( xxxProgetto $ xxxAmbiente $ xxxTipoGruppo ) ) > > > objectClasses: ( 1.3.6.1.4.1.36005.0.2.6.4 NAME 'xxxWebminAttributes' > > > DESC 'Definizione di attributi specifici per gli oggetti Webmin' > > > STRUCTURAL MAY xxxWebminAmbiente ) > > > objectClasses: ( 1.3.6.1.4.1.36005.0.2.6.5 NAME > > > 'xxxDB2GroupsAttributes' DESC 'Definizione di attributi specifici per > > > i gruppi DB2' STRUCTURAL MAY xxxDB2GruppiPrivilegi ) > > > objectClasses: ( 1.3.6.1.4.1.36005.0.2.6.1 NAME 'xxxAttributes' DESC > > > 'Definizione di attributi specifici per utilizzo interno' STRUCTURAL > > > MAY ( xxxProgetto $ xxxAmbiente $ xxxTipoGruppo $ > > > xxxDB2GruppiPrivilegi ) ) > > > > > > > > > By seeing this output, I just checked again and I confirm that in my > > > file /etc/dirsrv/slapd-UNIX-MYDOMAIN-IT/schema/98myfile.ldif they are > > > still AUXILIARY. > > > > This is odd, indeed, I will resurrect the bug you opened with a better > > description, > > thanks. > > Marco, > I discussed this briefly with Nathan and it seem that it may be a parser > error. 389DS parser is quite strict and wants the various definitions in > the precise order they are defined in the RFCs. I guess that means that > if you reorder where you define the type (AUXILIARY/STRUCTURAL) in the > string you'll get the right behavior. As Is I think AUXILIARY is simply > ignored because it is int eh wrong position and the default STRUCTURAL > is used. > If you can change your schema file to define AUS/STR in the right order > (see other IPA ldif file for hints) and can confirm it is ano ordering > problem we can open a documentation bug to explain this behavior until > the underlying parser is improved to better handle random ordered > definitions. > Yes, I modified the position of the "SUP top AUXILIARY" part and now it's ok!! My use case was in converting a working OpenLDAP schema file with the script published on the 389-ds wiki[1]. I would ask/suggest/like/appreciate it being improved for dealing with this thing too... I'm not a programmer, in that case I would offer to do it... :-/ [1] http://directory.fedoraproject.org/download/ol-macro-expand.pl > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marco.pizzoli at gmail.com Mon Mar 19 22:54:42 2012 From: marco.pizzoli at gmail.com (Marco Pizzoli) Date: Mon, 19 Mar 2012 23:54:42 +0100 Subject: [Freeipa-users] Problem in "ipa migrate-ds" procedure In-Reply-To: <4F678990.7020400@redhat.com> References: <4F66121F.3090200@redhat.com> <4F6737B4.5040502@redhat.com> <4F678990.7020400@redhat.com> Message-ID: On Mon, Mar 19, 2012 at 8:31 PM, Rob Crittenden wrote: > Marco Pizzoli wrote: > >> >> >> On Mon, Mar 19, 2012 at 2:42 PM, Rob Crittenden > > wrote: >> >> Dmitri Pal wrote: >> >> On 03/17/2012 07:36 AM, Marco Pizzoli wrote: >> >> Hi guys, >> I'm trying to migrate my ldap user base to freeipa. I'm >> using the last >> Release Candidate. >> >> I already changed "ipa config-mod --enable-migration=TRUE" >> This is what I have: >> >> ipa -v migrate-ds >> --bind-dn="cn=manager,dc=__**mydc1,dc=mydc2.it < >> http://mydc2.it> >> " >> --user-container="ou=people,__**dc=mydc1,dc=mydc2.it >> >> " --user-objectclass=__**inetOrgPerson >> --group-container="ou=groups,_**_dc=mydc1,dc=mydc2.it >> " >> --group-objectclass=posixGroup >> --base-dn="dc=mydc1,dc=mydc2._**_it >> >> " --with-compat ldap://ldap01 >> >> ipa: INFO: trying >> https://freeipa01.unix.__mydom**ain.it/ipa/xml >> >> >> > >> Password: >> ipa: INFO: Forwarding 'migrate_ds' to server >> u'http://freeipa01.unix.__mydo**main.it/ipa/xml >> >> >> >' >> ipa: ERROR: Container for group not found at >> ou=groups,dc=mydc1,dc=mydc2.it >> >> >> >> I looked at my ldap server logs and I found out that the search >> executed has scope=1. Actually both for users and groups. >> This is a >> problem for me, in having a lot of subtrees (ou) in which my >> users and >> groups are. Is there a way to manage this? >> >> Thanks in advance >> Marco >> >> P.s. As a side note, I suppose there's a typo in the verbose >> message I >> obtain in my output: >> ipa: INFO: Forwarding 'migrate_ds' to server >> *u*'http://freeipa01.unix.__my**domain.it/ipa/xml >> >> >> >' >> >> >> Please open tickets for both issues. >> >> >> Well, I don't think either is a bug. >> >> If you have users/groups in multiple places you'll need to migrate >> them individually for now. It is safe to run migrate-ds multiple >> times, existing users are not migrated. >> >> >> I just re-executed by specifing a nested ou for my groups. >> This is what I got: >> >> ipa: INFO: trying https://freeipa01.unix.csebo.**it/ipa/xml >> ipa: INFO: Forwarding 'migrate_ds' to server >> u'http://freeipa01.unix.csebo.**it/ipa/xml >> ' >> ----------- >> migrate-ds: >> ----------- >> Migrated: >> Failed user: >> fw03075_no: Type or value exists: >> [other users listed] >> Failed group: >> pdbac32: Type or value exists: >> [other groups listed] >> ---------- >> Passwords have been migrated in pre-hashed format. >> IPA is unable to generate Kerberos keys unless provided >> with clear text passwords. All migrated users need to >> login at https://your.domain/ipa/**migration/before they >> can use their Kerberos accounts. >> >> I don't understand what it's trying to telling me. >> On my FreeIPA ldap server I don't see any imported user. >> >> What's my fault here? >> >> >> The u is a python-ism for unicode. This is not a bug. >> >> >> Please, could you give a little more detail on this? It's only a hint on >> what that data represents in a Python variable? >> >> Thanks again >> Marco >> > > Type or value exists occurs when one tries to add an attribute value to an > entry that already exists. > > I suspect that the underlying problem is different between users and > groups. > > For groups it is likely adding a duplicate member. > > For users I'm not really sure. It could be one of the POSIX attributes. > What does a failed entry look like? > > rob > The user entry: ------------------------ dn: uid=fw03075_NO,ou=People,dc=mydc1,dc=mydc2.it description: fw03075 cn: fw03075 uidNumber: 11013 gidNumber: 503 homeDirectory: /home/fw03075 loginShell: /bin/sh gecos: fw03075 shadowLastChange: 13059 shadowMax: 99999 shadowWarning: 7 objectClass: inetOrgPerson objectClass: posixAccount objectClass: shadowAccount objectClass: top objectClass: xxxPeopleAttributes sn: SN_NON_IMPOSTATO givenName: GIVENNAME_NON_IMPOSTATO xxxUfficio: UFFICIO_NON_IMPOSTATO xxxTipoUtente: tecnico uid: fw03075_NO userPassword: secret group entry: ------------------- dn: cn=pdbac32,ou=pdbac32,ou=prod,ou=db2,ou=databases,ou=Groups,dc=mydc1,dc= mydc2.it gidNumber: 10015 member: uid=NESSUNO,ou=People,dc=mydc1,dc=mydc2.it member: uid=aaa415,ou=People,dc=mydc1,dc=mydc2.it member: uid=bbb446,ou=People,dc=mydc1,dc=mydc2.it memberUid: NESSUNO memberUid: aaa415 memberUid: bbb446 xxxAmbiente: prod xxxDB2GruppiPrivilegi: instance_owner description: Mydescription xxxTipoGruppo: db objectClass: top objectClass: posixGroup objectClass: groupOfNames objectClass: xxxGroupsAttributes objectClass: xxxDB2GroupsAttributes cn: pdbac32 Thanks again Marco -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Mon Mar 19 23:08:48 2012 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 19 Mar 2012 19:08:48 -0400 Subject: [Freeipa-users] Extending IPA schema for Federation services. In-Reply-To: <4F67A680.1040201@redhat.com> References: <833D8E48405E064EBC54C84EC6B36E404CC0FA66@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4F673AED.9000704@redhat.com> <833D8E48405E064EBC54C84EC6B36E404CC0FEE3@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4F6794E5.6060805@redhat.com> <833D8E48405E064EBC54C84EC6B36E404CC110B7@STAWINCOX10MBX1.staff.vuw.ac.nz> <4F67A680.1040201@redhat.com> Message-ID: <4F67BC80.7010709@redhat.com> On 03/19/2012 05:34 PM, Rob Crittenden wrote: > Steven Jones wrote: >> Hi, >> >> Is it sensible/better to extend the scheme before I start adding >> users? or doesnt it matter? From my perspective extending a system >> in use carries risk and impact to users, so its seems safer to extend >> it before I have any users, even if its un-used for now/? > > If you do it later you may need to write a script to update all > existing users with the missing objectclasses. > So yes it is better to do now. >> Apart from that I dont know....for now I would live with the extended >> schema for the user....populating the fields would be something I >> would look at when its decided what we will be doing....no one yet >> knows or at least have not told me what they will be doing. > > It matters depending on whether the attributes in those objectclasses > are required or not. > >> I suspect in the end we will draw the contents from AD with winsync? > > The list of attributes for winsync is currently hardcoded. Probably some custom ldapmodify or CLI with setatttr/addattr based solution. It can be done just not something generic so probably will be left to you to script against the data source. > >> >> or populate/inject it directly via our Oracle identity system......so >> I'm not sure we will need the ui / gui....I dont expect to add >> content via it, I suspect I might need to fault find to make sure the >> data is there but I assume ldap search tools will return this anyway? > > Right, it is possible to use the IPA LDAP server as a data store, the > framework need not know about these extra attributes. "Framework" meaning the management interfaces i.e. UI/CLI. But CLI is smart and can access LDAP attributes if they are available in the object via --setattr/--addattr > >> >> However for other sites they may well not have an AD or user >> provisioning system....... >> >> regards >> >> Steven Jones >> >> Technical Specialist - Linux RHCE >> >> Victoria University, Wellington, NZ >> >> 0064 4 463 6272 >> >> ________________________________________ >> From: freeipa-users-bounces at redhat.com >> [freeipa-users-bounces at redhat.com] on behalf of Dmitri Pal >> [dpal at redhat.com] >> Sent: Tuesday, 20 March 2012 9:19 a.m. >> To: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] Extending IPA schema for Federation >> services. >> >> On 03/19/2012 03:58 PM, Steven Jones wrote: >>> Hi, >>> >>> Im starting from scratch here so bear with me......ie I dont know a >>> lot of this....which should be obvious.... >>> >>> Extending Easy? oh because it doesnt strike me as easy...... >>> >>> :/ >>> >>> Initially I am about to build our production IPA servers. These >>> attributes are a requirement of the Federation system New Zealand >>> wants to use and is probably the same for Australia. So I think the >>> schema has to be done/extended for IPA to be viable in tertiary >>> institutions in NZ, without it not many if anyone will use IPA they >>> will stay with openldap. So each person should have these I >>> think.....they may not be used initially but once extended initially >>> then I dont have to extend the schema later. >>> >>> What connects to these is an apache/tomcat front end. There are two >>> aspects/functions to this, the IdP and the SdP. The Idp allows >>> remote tertiary organisations to query us and say our user is we >>> legit....they then use their LDAP to provide resources via the SdP. >>> So the Idp provides an identity to remote ppl and the SdP provides >>> access to a resource at our end. later I expect we will have to to >>> the SdP bit got our high performance cluster and storage... >>> >>> It maybe a year or more before we actually use this, but it strikes >>> me as sensible that these are done on initial build.....I will put >>> ina RH support case for this. We will probably also pull the >>> actual fields/contents out of AD.....not sure yet. >> >> >> The question is simple: how you plan to manage these attributes in IPA? >> Do you expect them to be a part of the UI/CLI or they should be hidden >> there and be managed via ldapmodify and other data sync tools? >> >> This make the whole difference especially the UI part. Depending upon >> these expectations the scope would be different. >> >> >>> regards >>> >>> Steven Jones >>> >>> Technical Specialist - Linux RHCE >>> >>> Victoria University, Wellington, NZ >>> >>> 0064 4 463 6272 >>> >>> ________________________________________ >>> From: Rob Crittenden [rcritten at redhat.com] >>> Sent: Tuesday, 20 March 2012 2:55 a.m. >>> To: Steven Jones >>> Cc: freeipa-users at redhat.com >>> Subject: Re: [Freeipa-users] Extending IPA schema for Federation >>> services. >>> >>> Steven Jones wrote: >>>> Hi, >>>> >>>> >>>> Is it possible to expand IPA's schema to do this? >>> Adding the schema is easy, doing something with it is where things get >>> interesting. What do you want to do with these >>> attributes/objectclasses? >>> >>> rob >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager IPA project, >> 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 >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Mon Mar 19 23:14:06 2012 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 19 Mar 2012 19:14:06 -0400 Subject: [Freeipa-users] Problem in "ipa migrate-ds" procedure In-Reply-To: References: <4F66121F.3090200@redhat.com> <4F6737B4.5040502@redhat.com> <4F678990.7020400@redhat.com> Message-ID: <4F67BDBE.3010204@redhat.com> On 03/19/2012 06:54 PM, Marco Pizzoli wrote: > > > On Mon, Mar 19, 2012 at 8:31 PM, Rob Crittenden > wrote: > > Marco Pizzoli wrote: > > > > On Mon, Mar 19, 2012 at 2:42 PM, Rob Crittenden > > >> wrote: > > Dmitri Pal wrote: > > On 03/17/2012 07:36 AM, Marco Pizzoli wrote: > > Hi guys, > I'm trying to migrate my ldap user base to freeipa. I'm > using the last > Release Candidate. > > I already changed "ipa config-mod > --enable-migration=TRUE" > This is what I have: > > ipa -v migrate-ds > --bind-dn="cn=manager,dc=__mydc1,dc=mydc2.it > > " > --user-container="ou=people,__dc=mydc1,dc=mydc2.it > > > " --user-objectclass=__inetOrgPerson > --group-container="ou=groups,__dc=mydc1,dc=mydc2.it > > " > --group-objectclass=posixGroup > --base-dn="dc=mydc1,dc=mydc2.__it > > " --with-compat ldap://ldap01 > > ipa: INFO: trying > https://freeipa01.unix.__mydomain.it/ipa/xml > > > > Password: > ipa: INFO: Forwarding 'migrate_ds' to server > u'http://freeipa01.unix.__mydomain.it/ipa/xml > > > ' > ipa: ERROR: Container for group not found at > ou=groups,dc=mydc1,dc=mydc2.it > > > > > I looked at my ldap server logs and I found out > that the search > executed has scope=1. Actually both for users and > groups. > This is a > problem for me, in having a lot of subtrees (ou) in > which my > users and > groups are. Is there a way to manage this? > > Thanks in advance > Marco > > P.s. As a side note, I suppose there's a typo in > the verbose > message I > obtain in my output: > ipa: INFO: Forwarding 'migrate_ds' to server > *u*'http://freeipa01.unix.__mydomain.it/ipa/xml > > > ' > > > Please open tickets for both issues. > > > Well, I don't think either is a bug. > > If you have users/groups in multiple places you'll need to > migrate > them individually for now. It is safe to run migrate-ds > multiple > times, existing users are not migrated. > > > I just re-executed by specifing a nested ou for my groups. > This is what I got: > > ipa: INFO: trying https://freeipa01.unix.csebo.it/ipa/xml > ipa: INFO: Forwarding 'migrate_ds' to server > u'http://freeipa01.unix.csebo.it/ipa/xml' > ----------- > migrate-ds: > ----------- > Migrated: > Failed user: > fw03075_no: Type or value exists: > [other users listed] > Failed group: > pdbac32: Type or value exists: > [other groups listed] > ---------- > Passwords have been migrated in pre-hashed format. > IPA is unable to generate Kerberos keys unless provided > with clear text passwords. All migrated users need to > login at https://your.domain/ipa/migration/ before they > can use their Kerberos accounts. > > I don't understand what it's trying to telling me. > On my FreeIPA ldap server I don't see any imported user. > > What's my fault here? > > > The u is a python-ism for unicode. This is not a bug. > > > Please, could you give a little more detail on this? It's only > a hint on > what that data represents in a Python variable? > > Thanks again > Marco > > > Type or value exists occurs when one tries to add an attribute > value to an entry that already exists. > > I suspect that the underlying problem is different between users > and groups. > > For groups it is likely adding a duplicate member. > > For users I'm not really sure. It could be one of the POSIX > attributes. What does a failed entry look like? > > rob > > > The user entry: > ------------------------ > dn: uid=fw03075_NO,ou=People,dc=mydc1,dc=mydc2.it > description: fw03075 > cn: fw03075 > uidNumber: 11013 > gidNumber: 503 > homeDirectory: /home/fw03075 > loginShell: /bin/sh > gecos: fw03075 > shadowLastChange: 13059 > shadowMax: 99999 > shadowWarning: 7 > objectClass: inetOrgPerson > objectClass: posixAccount > objectClass: shadowAccount > objectClass: top > objectClass: xxxPeopleAttributes > sn: SN_NON_IMPOSTATO > givenName: GIVENNAME_NON_IMPOSTATO > xxxUfficio: UFFICIO_NON_IMPOSTATO > xxxTipoUtente: tecnico > uid: fw03075_NO > userPassword: secret > > > group entry: > ------------------- > dn: > cn=pdbac32,ou=pdbac32,ou=prod,ou=db2,ou=databases,ou=Groups,dc=mydc1,dc=mydc2.it > > gidNumber: 10015 > member: uid=NESSUNO,ou=People,dc=mydc1,dc=mydc2.it > member: uid=aaa415,ou=People,dc=mydc1,dc=mydc2.it > member: uid=bbb446,ou=People,dc=mydc1,dc=mydc2.it > memberUid: NESSUNO > memberUid: aaa415 > memberUid: bbb446 > xxxAmbiente: prod > xxxDB2GruppiPrivilegi: instance_owner > description: Mydescription > xxxTipoGruppo: db > objectClass: top > objectClass: posixGroup > objectClass: groupOfNames > objectClass: xxxGroupsAttributes > objectClass: xxxDB2GroupsAttributes > cn: pdbac32 > > Thanks again > Marco > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users Do you by any chance have a _group_ with name "fw03075_NO" and _user_ with name "pdbac32"? May be you are hitting a collision on manged group managed? -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From marco.pizzoli at gmail.com Tue Mar 20 09:19:53 2012 From: marco.pizzoli at gmail.com (Marco Pizzoli) Date: Tue, 20 Mar 2012 10:19:53 +0100 Subject: [Freeipa-users] Problem in "ipa migrate-ds" procedure In-Reply-To: <4F67BDBE.3010204@redhat.com> References: <4F66121F.3090200@redhat.com> <4F6737B4.5040502@redhat.com> <4F678990.7020400@redhat.com> <4F67BDBE.3010204@redhat.com> Message-ID: On Tue, Mar 20, 2012 at 12:14 AM, Dmitri Pal wrote: > ** > On 03/19/2012 06:54 PM, Marco Pizzoli wrote: > > > > On Mon, Mar 19, 2012 at 8:31 PM, Rob Crittenden wrote: > >> Marco Pizzoli wrote: >> >>> >>> >>> On Mon, Mar 19, 2012 at 2:42 PM, Rob Crittenden >> > wrote: >>> >>> Dmitri Pal wrote: >>> >>> On 03/17/2012 07:36 AM, Marco Pizzoli wrote: >>> >>> Hi guys, >>> I'm trying to migrate my ldap user base to freeipa. I'm >>> using the last >>> Release Candidate. >>> >>> I already changed "ipa config-mod --enable-migration=TRUE" >>> This is what I have: >>> >>> ipa -v migrate-ds >>> --bind-dn="cn=manager,dc=__mydc1,dc=mydc2.it < >>> http://mydc2.it> >>> " >>> --user-container="ou=people,__dc=mydc1,dc=mydc2.it >>> >>> " --user-objectclass=__inetOrgPerson >>> --group-container="ou=groups,__dc=mydc1,dc=mydc2.it >>> " >>> --group-objectclass=posixGroup >>> --base-dn="dc=mydc1,dc=mydc2.__it >>> >>> " --with-compat ldap://ldap01 >>> >>> ipa: INFO: trying >>> https://freeipa01.unix.__mydomain.it/ipa/xml >>> >>> >>> Password: >>> ipa: INFO: Forwarding 'migrate_ds' to server >>> u'http://freeipa01.unix.__mydomain.it/ipa/xml >>> >>> ' >>> ipa: ERROR: Container for group not found at >>> ou=groups,dc=mydc1,dc=mydc2.it >>> >>> >>> >>> I looked at my ldap server logs and I found out that the >>> search >>> executed has scope=1. Actually both for users and groups. >>> This is a >>> problem for me, in having a lot of subtrees (ou) in which my >>> users and >>> groups are. Is there a way to manage this? >>> >>> Thanks in advance >>> Marco >>> >>> P.s. As a side note, I suppose there's a typo in the verbose >>> message I >>> obtain in my output: >>> ipa: INFO: Forwarding 'migrate_ds' to server >>> *u*'http://freeipa01.unix.__mydomain.it/ipa/xml >>> >>> ' >>> >>> >>> Please open tickets for both issues. >>> >>> >>> Well, I don't think either is a bug. >>> >>> If you have users/groups in multiple places you'll need to migrate >>> them individually for now. It is safe to run migrate-ds multiple >>> times, existing users are not migrated. >>> >>> >>> I just re-executed by specifing a nested ou for my groups. >>> This is what I got: >>> >>> ipa: INFO: trying https://freeipa01.unix.csebo.it/ipa/xml >>> ipa: INFO: Forwarding 'migrate_ds' to server >>> u'http://freeipa01.unix.csebo.it/ipa/xml' >>> ----------- >>> migrate-ds: >>> ----------- >>> Migrated: >>> Failed user: >>> fw03075_no: Type or value exists: >>> [other users listed] >>> Failed group: >>> pdbac32: Type or value exists: >>> [other groups listed] >>> ---------- >>> Passwords have been migrated in pre-hashed format. >>> IPA is unable to generate Kerberos keys unless provided >>> with clear text passwords. All migrated users need to >>> login at https://your.domain/ipa/migration/ before they >>> can use their Kerberos accounts. >>> >>> I don't understand what it's trying to telling me. >>> On my FreeIPA ldap server I don't see any imported user. >>> >>> What's my fault here? >>> >>> >>> The u is a python-ism for unicode. This is not a bug. >>> >>> >>> Please, could you give a little more detail on this? It's only a hint on >>> what that data represents in a Python variable? >>> >>> Thanks again >>> Marco >>> >> >> Type or value exists occurs when one tries to add an attribute value to >> an entry that already exists. >> >> I suspect that the underlying problem is different between users and >> groups. >> >> For groups it is likely adding a duplicate member. >> >> For users I'm not really sure. It could be one of the POSIX attributes. >> What does a failed entry look like? >> >> rob >> > > The user entry: > ------------------------ > dn: uid=fw03075_NO,ou=People,dc=mydc1,dc=mydc2.it > description: fw03075 > cn: fw03075 > uidNumber: 11013 > gidNumber: 503 > homeDirectory: /home/fw03075 > loginShell: /bin/sh > gecos: fw03075 > shadowLastChange: 13059 > shadowMax: 99999 > shadowWarning: 7 > objectClass: inetOrgPerson > objectClass: posixAccount > objectClass: shadowAccount > objectClass: top > objectClass: xxxPeopleAttributes > sn: SN_NON_IMPOSTATO > givenName: GIVENNAME_NON_IMPOSTATO > xxxUfficio: UFFICIO_NON_IMPOSTATO > xxxTipoUtente: tecnico > uid: fw03075_NO > userPassword: secret > > > group entry: > ------------------- > dn: > cn=pdbac32,ou=pdbac32,ou=prod,ou=db2,ou=databases,ou=Groups,dc=mydc1,dc= > mydc2.it > gidNumber: 10015 > member: uid=NESSUNO,ou=People,dc=mydc1,dc=mydc2.it > member: uid=aaa415,ou=People,dc=mydc1,dc=mydc2.it > member: uid=bbb446,ou=People,dc=mydc1,dc=mydc2.it > memberUid: NESSUNO > memberUid: aaa415 > memberUid: bbb446 > xxxAmbiente: prod > xxxDB2GruppiPrivilegi: instance_owner > description: Mydescription > xxxTipoGruppo: db > objectClass: top > objectClass: posixGroup > objectClass: groupOfNames > objectClass: xxxGroupsAttributes > objectClass: xxxDB2GroupsAttributes > cn: pdbac32 > > Thanks again > Marco > > > _______________________________________________ > Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users > > > Do you by any chance have a *group* with name "fw03075_NO" and *user*with name "pdbac32"? > May be you are hitting a collision on manged group managed? > Well, yes and no. No, I don't have a group called "fw03075_NO" and No, I don't have a user called "pdbac32". Yes, I have some users uid=samename and groups cn=samename, but they are not found in the group subtree (ou) from where I launched "ipa migrate-ds". If this is the problem, where can I have any evidence of the actual problem? Thanks again Marco > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IPA project, > 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 mkosek at redhat.com Tue Mar 20 12:02:50 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 20 Mar 2012 13:02:50 +0100 Subject: [Freeipa-users] [Freeipa-devel] FreeIPA beta1: SELinux prohibits memcached In-Reply-To: References: Message-ID: <1332244970.20122.11.camel@balmora.brq.redhat.com> On Tue, 2012-03-20 at 12:44 +0100, Marco Pizzoli wrote: > Hi guys, > I don't know if you already know this, but in my logs I can find this: > > > Mar 20 12:14:47 freeipa01 setroubleshoot: SELinux is > preventing /usr/bin/memcached from create access on the sock_file > ipa_memcached. For complete SELinux messages. run sealert -l > 85b51f4e-3f2e-4e7d-819f-1efb04836de3 > > > I'm running: > > > [root at freeipa01 ipa]# rpm -qa|grep freeipa > freeipa-server-selinux-2.1.90.rc1-0.fc16.x86_64 > freeipa-client-2.1.90.rc1-0.fc16.x86_64 > freeipa-server-2.1.90.rc1-0.fc16.x86_64 > freeipa-admintools-2.1.90.rc1-0.fc16.x86_64 > freeipa-python-2.1.90.rc1-0.fc16.x86_64 > > > HTH > Marco Hello Marco, there is a SELinux policy where this issue is fixed: https://admin.fedoraproject.org/updates/FEDORA-2012-2733/selinux-policy-3.10.0-80.fc16 Its still in updates-testing though. This is an appropriate BZ: https://bugzilla.redhat.com/show_bug.cgi?id=783592 It requires "httpd_manage_ipa" SELinux boolean to be set, upstream FreeIPA bits already sets it automatically during installation. Martin From marco.pizzoli at gmail.com Tue Mar 20 12:14:39 2012 From: marco.pizzoli at gmail.com (Marco Pizzoli) Date: Tue, 20 Mar 2012 13:14:39 +0100 Subject: [Freeipa-users] [Freeipa-devel] FreeIPA beta1: SELinux prohibits memcached In-Reply-To: <1332244970.20122.11.camel@balmora.brq.redhat.com> References: <1332244970.20122.11.camel@balmora.brq.redhat.com> Message-ID: Hi Martin, On Tue, Mar 20, 2012 at 1:02 PM, Martin Kosek wrote: > On Tue, 2012-03-20 at 12:44 +0100, Marco Pizzoli wrote: > > Hi guys, > > I don't know if you already know this, but in my logs I can find this: > > > > > > Mar 20 12:14:47 freeipa01 setroubleshoot: SELinux is > > preventing /usr/bin/memcached from create access on the sock_file > > ipa_memcached. For complete SELinux messages. run sealert -l > > 85b51f4e-3f2e-4e7d-819f-1efb04836de3 > > > > > > I'm running: > > > > > > [root at freeipa01 ipa]# rpm -qa|grep freeipa > > freeipa-server-selinux-2.1.90.rc1-0.fc16.x86_64 > > freeipa-client-2.1.90.rc1-0.fc16.x86_64 > > freeipa-server-2.1.90.rc1-0.fc16.x86_64 > > freeipa-admintools-2.1.90.rc1-0.fc16.x86_64 > > freeipa-python-2.1.90.rc1-0.fc16.x86_64 > > > > > > HTH > > Marco > > Hello Marco, > > there is a SELinux policy where this issue is fixed: > > https://admin.fedoraproject.org/updates/FEDORA-2012-2733/selinux-policy-3.10.0-80.fc16 > > Its still in updates-testing though. This is an appropriate BZ: > https://bugzilla.redhat.com/show_bug.cgi?id=783592 Thanks for your answer. Just to be aligned, actually it's not still available on the updates-testing channel too. I see on the cli that I cannot update to that release and by looking at the link you posted I see it has still to be pushed -> current state: pending. Thanks again Marco > > > It requires "httpd_manage_ipa" SELinux boolean to be set, upstream > FreeIPA bits already sets it automatically during installation. > > Martin > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Tue Mar 20 12:28:49 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 20 Mar 2012 13:28:49 +0100 Subject: [Freeipa-users] [Freeipa-devel] FreeIPA beta1: SELinux prohibits memcached In-Reply-To: References: <1332244970.20122.11.camel@balmora.brq.redhat.com> Message-ID: <1332246529.20122.14.camel@balmora.brq.redhat.com> On Tue, 2012-03-20 at 13:14 +0100, Marco Pizzoli wrote: > Hi Martin, > > On Tue, Mar 20, 2012 at 1:02 PM, Martin Kosek > wrote: > On Tue, 2012-03-20 at 12:44 +0100, Marco Pizzoli wrote: > > Hi guys, > > I don't know if you already know this, but in my logs I can > find this: > > > > > > Mar 20 12:14:47 freeipa01 setroubleshoot: SELinux is > > preventing /usr/bin/memcached from create access on the > sock_file > > ipa_memcached. For complete SELinux messages. run sealert -l > > 85b51f4e-3f2e-4e7d-819f-1efb04836de3 > > > > > > I'm running: > > > > > > [root at freeipa01 ipa]# rpm -qa|grep freeipa > > freeipa-server-selinux-2.1.90.rc1-0.fc16.x86_64 > > freeipa-client-2.1.90.rc1-0.fc16.x86_64 > > freeipa-server-2.1.90.rc1-0.fc16.x86_64 > > freeipa-admintools-2.1.90.rc1-0.fc16.x86_64 > > freeipa-python-2.1.90.rc1-0.fc16.x86_64 > > > > > > HTH > > Marco > > > Hello Marco, > > there is a SELinux policy where this issue is fixed: > https://admin.fedoraproject.org/updates/FEDORA-2012-2733/selinux-policy-3.10.0-80.fc16 > > Its still in updates-testing though. This is an appropriate > BZ: > https://bugzilla.redhat.com/show_bug.cgi?id=783592 > > > Thanks for your answer. > Just to be aligned, actually it's not still available on the > updates-testing channel too. > I see on the cli that I cannot update to that release and by looking > at the link you posted I see it has still to be pushed -> current > state: pending. > > > Thanks again > Marco You are right, its not there yet. You can just download and install fixed RPM from koji (there is a link on Fedora update file), but it is of course a SElinux policy version without proper community testing. I tried it and it worked for me, no AVC raised. Martin From dpal at redhat.com Tue Mar 20 12:32:06 2012 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 20 Mar 2012 08:32:06 -0400 Subject: [Freeipa-users] Problem in "ipa migrate-ds" procedure In-Reply-To: References: <4F66121F.3090200@redhat.com> <4F6737B4.5040502@redhat.com> <4F678990.7020400@redhat.com> <4F67BDBE.3010204@redhat.com> Message-ID: <4F6878C6.4040608@redhat.com> On 03/20/2012 05:19 AM, Marco Pizzoli wrote: > > > On Tue, Mar 20, 2012 at 12:14 AM, Dmitri Pal > wrote: > > On 03/19/2012 06:54 PM, Marco Pizzoli wrote: >> >> >> On Mon, Mar 19, 2012 at 8:31 PM, Rob Crittenden >> > wrote: >> >> Marco Pizzoli wrote: >> >> >> >> On Mon, Mar 19, 2012 at 2:42 PM, Rob Crittenden >> >> > >> wrote: >> >> Dmitri Pal wrote: >> >> On 03/17/2012 07:36 AM, Marco Pizzoli wrote: >> >> Hi guys, >> I'm trying to migrate my ldap user base to >> freeipa. I'm >> using the last >> Release Candidate. >> >> I already changed "ipa config-mod >> --enable-migration=TRUE" >> This is what I have: >> >> ipa -v migrate-ds >> --bind-dn="cn=manager,dc=__mydc1,dc=mydc2.it >> >> " >> >> --user-container="ou=people,__dc=mydc1,dc=mydc2.it >> >> >> " >> --user-objectclass=__inetOrgPerson >> >> --group-container="ou=groups,__dc=mydc1,dc=mydc2.it >> >> " >> --group-objectclass=posixGroup >> --base-dn="dc=mydc1,dc=mydc2.__it >> >> >> " --with-compat ldap://ldap01 >> >> ipa: INFO: trying >> https://freeipa01.unix.__mydomain.it/ipa/xml >> >> >> >> Password: >> ipa: INFO: Forwarding 'migrate_ds' to server >> u'http://freeipa01.unix.__mydomain.it/ipa/xml >> >> >> ' >> ipa: ERROR: Container for group not found at >> ou=groups,dc=mydc1,dc=mydc2.it >> >> >> >> >> I looked at my ldap server logs and I found >> out that the search >> executed has scope=1. Actually both for users >> and groups. >> This is a >> problem for me, in having a lot of subtrees >> (ou) in which my >> users and >> groups are. Is there a way to manage this? >> >> Thanks in advance >> Marco >> >> P.s. As a side note, I suppose there's a typo >> in the verbose >> message I >> obtain in my output: >> ipa: INFO: Forwarding 'migrate_ds' to server >> >> *u*'http://freeipa01.unix.__mydomain.it/ipa/xml >> >> >> ' >> >> >> Please open tickets for both issues. >> >> >> Well, I don't think either is a bug. >> >> If you have users/groups in multiple places you'll >> need to migrate >> them individually for now. It is safe to run >> migrate-ds multiple >> times, existing users are not migrated. >> >> >> I just re-executed by specifing a nested ou for my groups. >> This is what I got: >> >> ipa: INFO: trying https://freeipa01.unix.csebo.it/ipa/xml >> ipa: INFO: Forwarding 'migrate_ds' to server >> u'http://freeipa01.unix.csebo.it/ipa/xml' >> ----------- >> migrate-ds: >> ----------- >> Migrated: >> Failed user: >> fw03075_no: Type or value exists: >> [other users listed] >> Failed group: >> pdbac32: Type or value exists: >> [other groups listed] >> ---------- >> Passwords have been migrated in pre-hashed format. >> IPA is unable to generate Kerberos keys unless provided >> with clear text passwords. All migrated users need to >> login at https://your.domain/ipa/migration/ before they >> can use their Kerberos accounts. >> >> I don't understand what it's trying to telling me. >> On my FreeIPA ldap server I don't see any imported user. >> >> What's my fault here? >> >> >> The u is a python-ism for unicode. This is not a bug. >> >> >> Please, could you give a little more detail on this? It's >> only a hint on >> what that data represents in a Python variable? >> >> Thanks again >> Marco >> >> >> Type or value exists occurs when one tries to add an >> attribute value to an entry that already exists. >> >> I suspect that the underlying problem is different between >> users and groups. >> >> For groups it is likely adding a duplicate member. >> >> For users I'm not really sure. It could be one of the POSIX >> attributes. What does a failed entry look like? >> >> rob >> >> >> The user entry: >> ------------------------ >> dn: uid=fw03075_NO,ou=People,dc=mydc1,dc=mydc2.it >> description: fw03075 >> cn: fw03075 >> uidNumber: 11013 >> gidNumber: 503 >> homeDirectory: /home/fw03075 >> loginShell: /bin/sh >> gecos: fw03075 >> shadowLastChange: 13059 >> shadowMax: 99999 >> shadowWarning: 7 >> objectClass: inetOrgPerson >> objectClass: posixAccount >> objectClass: shadowAccount >> objectClass: top >> objectClass: xxxPeopleAttributes >> sn: SN_NON_IMPOSTATO >> givenName: GIVENNAME_NON_IMPOSTATO >> xxxUfficio: UFFICIO_NON_IMPOSTATO >> xxxTipoUtente: tecnico >> uid: fw03075_NO >> userPassword: secret >> >> >> group entry: >> ------------------- >> dn: >> cn=pdbac32,ou=pdbac32,ou=prod,ou=db2,ou=databases,ou=Groups,dc=mydc1,dc=mydc2.it >> >> gidNumber: 10015 >> member: uid=NESSUNO,ou=People,dc=mydc1,dc=mydc2.it >> member: uid=aaa415,ou=People,dc=mydc1,dc=mydc2.it >> member: uid=bbb446,ou=People,dc=mydc1,dc=mydc2.it >> memberUid: NESSUNO >> memberUid: aaa415 >> memberUid: bbb446 >> xxxAmbiente: prod >> xxxDB2GruppiPrivilegi: instance_owner >> description: Mydescription >> xxxTipoGruppo: db >> objectClass: top >> objectClass: posixGroup >> objectClass: groupOfNames >> objectClass: xxxGroupsAttributes >> objectClass: xxxDB2GroupsAttributes >> cn: pdbac32 >> >> Thanks again >> Marco >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > Do you by any chance have a _group_ with name "fw03075_NO" and > _user_ with name "pdbac32"? > May be you are hitting a collision on manged group managed? > > > Well, yes and no. > > No, I don't have a group called "fw03075_NO" and No, I don't have a > user called "pdbac32". > > Yes, I have some users uid=samename and groups cn=samename, but they > are not found in the group subtree (ou) from where I launched "ipa > migrate-ds". > > If this is the problem, where can I have any evidence of the actual > problem? > Can you search those names in the IPA LDAP tree after the migration? May be there is some object already there with the same cn that collides. This way we would be able to determine what the colliding object is and take it from there. It might collide on some other attribute in the entry and just be reported by uid and cn. > Thanks again > Marco > > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IPA project, > 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 IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From marco.pizzoli at gmail.com Tue Mar 20 13:09:49 2012 From: marco.pizzoli at gmail.com (Marco Pizzoli) Date: Tue, 20 Mar 2012 14:09:49 +0100 Subject: [Freeipa-users] Problem in "ipa migrate-ds" procedure In-Reply-To: <4F6878C6.4040608@redhat.com> References: <4F66121F.3090200@redhat.com> <4F6737B4.5040502@redhat.com> <4F678990.7020400@redhat.com> <4F67BDBE.3010204@redhat.com> <4F6878C6.4040608@redhat.com> Message-ID: On Tue, Mar 20, 2012 at 1:32 PM, Dmitri Pal wrote: > ** > On 03/20/2012 05:19 AM, Marco Pizzoli wrote: > > > > On Tue, Mar 20, 2012 at 12:14 AM, Dmitri Pal wrote: > >> On 03/19/2012 06:54 PM, Marco Pizzoli wrote: >> >> >> >> On Mon, Mar 19, 2012 at 8:31 PM, Rob Crittenden wrote: >> >>> Marco Pizzoli wrote: >>> >>>> >>>> >>>> On Mon, Mar 19, 2012 at 2:42 PM, Rob Crittenden >>> > wrote: >>>> >>>> Dmitri Pal wrote: >>>> >>>> On 03/17/2012 07:36 AM, Marco Pizzoli wrote: >>>> >>>> Hi guys, >>>> I'm trying to migrate my ldap user base to freeipa. I'm >>>> using the last >>>> Release Candidate. >>>> >>>> I already changed "ipa config-mod --enable-migration=TRUE" >>>> This is what I have: >>>> >>>> ipa -v migrate-ds >>>> --bind-dn="cn=manager,dc=__mydc1,dc=mydc2.it < >>>> http://mydc2.it> >>>> " >>>> --user-container="ou=people,__dc=mydc1,dc=mydc2.it >>>> >>>> " --user-objectclass=__inetOrgPerson >>>> --group-container="ou=groups,__dc=mydc1,dc=mydc2.it >>>> " >>>> --group-objectclass=posixGroup >>>> --base-dn="dc=mydc1,dc=mydc2.__it >>>> >>>> " --with-compat ldap://ldap01 >>>> >>>> ipa: INFO: trying >>>> https://freeipa01.unix.__mydomain.it/ipa/xml >>>> >>>> >>>> Password: >>>> ipa: INFO: Forwarding 'migrate_ds' to server >>>> u'http://freeipa01.unix.__mydomain.it/ipa/xml >>>> >>>> ' >>>> ipa: ERROR: Container for group not found at >>>> ou=groups,dc=mydc1,dc=mydc2.it >>>> >>>> >>>> >>>> I looked at my ldap server logs and I found out that the >>>> search >>>> executed has scope=1. Actually both for users and groups. >>>> This is a >>>> problem for me, in having a lot of subtrees (ou) in which my >>>> users and >>>> groups are. Is there a way to manage this? >>>> >>>> Thanks in advance >>>> Marco >>>> >>>> P.s. As a side note, I suppose there's a typo in the verbose >>>> message I >>>> obtain in my output: >>>> ipa: INFO: Forwarding 'migrate_ds' to server >>>> *u*'http://freeipa01.unix.__mydomain.it/ipa/xml >>>> >>>> ' >>>> >>>> >>>> Please open tickets for both issues. >>>> >>>> >>>> Well, I don't think either is a bug. >>>> >>>> If you have users/groups in multiple places you'll need to migrate >>>> them individually for now. It is safe to run migrate-ds multiple >>>> times, existing users are not migrated. >>>> >>>> >>>> I just re-executed by specifing a nested ou for my groups. >>>> This is what I got: >>>> >>>> ipa: INFO: trying https://freeipa01.unix.csebo.it/ipa/xml >>>> ipa: INFO: Forwarding 'migrate_ds' to server >>>> u'http://freeipa01.unix.csebo.it/ipa/xml' >>>> ----------- >>>> migrate-ds: >>>> ----------- >>>> Migrated: >>>> Failed user: >>>> fw03075_no: Type or value exists: >>>> [other users listed] >>>> Failed group: >>>> pdbac32: Type or value exists: >>>> [other groups listed] >>>> ---------- >>>> Passwords have been migrated in pre-hashed format. >>>> IPA is unable to generate Kerberos keys unless provided >>>> with clear text passwords. All migrated users need to >>>> login at https://your.domain/ipa/migration/ before they >>>> can use their Kerberos accounts. >>>> >>>> I don't understand what it's trying to telling me. >>>> On my FreeIPA ldap server I don't see any imported user. >>>> >>>> What's my fault here? >>>> >>>> >>>> The u is a python-ism for unicode. This is not a bug. >>>> >>>> >>>> Please, could you give a little more detail on this? It's only a hint on >>>> what that data represents in a Python variable? >>>> >>>> Thanks again >>>> Marco >>>> >>> >>> Type or value exists occurs when one tries to add an attribute value to >>> an entry that already exists. >>> >>> I suspect that the underlying problem is different between users and >>> groups. >>> >>> For groups it is likely adding a duplicate member. >>> >>> For users I'm not really sure. It could be one of the POSIX attributes. >>> What does a failed entry look like? >>> >>> rob >>> >> >> The user entry: >> ------------------------ >> dn: uid=fw03075_NO,ou=People,dc=mydc1,dc=mydc2.it >> description: fw03075 >> cn: fw03075 >> uidNumber: 11013 >> gidNumber: 503 >> homeDirectory: /home/fw03075 >> loginShell: /bin/sh >> gecos: fw03075 >> shadowLastChange: 13059 >> shadowMax: 99999 >> shadowWarning: 7 >> objectClass: inetOrgPerson >> objectClass: posixAccount >> objectClass: shadowAccount >> objectClass: top >> objectClass: xxxPeopleAttributes >> sn: SN_NON_IMPOSTATO >> givenName: GIVENNAME_NON_IMPOSTATO >> xxxUfficio: UFFICIO_NON_IMPOSTATO >> xxxTipoUtente: tecnico >> uid: fw03075_NO >> userPassword: secret >> >> >> group entry: >> ------------------- >> dn: >> cn=pdbac32,ou=pdbac32,ou=prod,ou=db2,ou=databases,ou=Groups,dc=mydc1,dc= >> mydc2.it >> gidNumber: 10015 >> member: uid=NESSUNO,ou=People,dc=mydc1,dc=mydc2.it >> member: uid=aaa415,ou=People,dc=mydc1,dc=mydc2.it >> member: uid=bbb446,ou=People,dc=mydc1,dc=mydc2.it >> memberUid: NESSUNO >> memberUid: aaa415 >> memberUid: bbb446 >> xxxAmbiente: prod >> xxxDB2GruppiPrivilegi: instance_owner >> description: Mydescription >> xxxTipoGruppo: db >> objectClass: top >> objectClass: posixGroup >> objectClass: groupOfNames >> objectClass: xxxGroupsAttributes >> objectClass: xxxDB2GroupsAttributes >> cn: pdbac32 >> >> Thanks again >> Marco >> >> >> _______________________________________________ >> Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users >> >> >> Do you by any chance have a *group* with name "fw03075_NO" and *user*with name "pdbac32"? >> May be you are hitting a collision on manged group managed? >> > > Well, yes and no. > > No, I don't have a group called "fw03075_NO" and No, I don't have a user > called "pdbac32". > > Yes, I have some users uid=samename and groups cn=samename, but they are > not found in the group subtree (ou) from where I launched "ipa migrate-ds". > > If this is the problem, where can I have any evidence of the actual > problem? > > > Can you search those names in the IPA LDAP tree after the migration? May > be there is some object already there with the same cn that collides. This > way we would be able to determine what the colliding object is and take it > from there. It might collide on some other attribute in the entry and just > be reported by uid and cn. > Here it is: [root at freeipa01 ipa]# ldapsearch -h 127.0.0.1 -x -D "cn=Directory Manager" -W -b "dc=unix,dc=mydomain,dc=it" -s sub "(uid=fw03075_NO)" Enter LDAP Password: # extended LDIF # # LDAPv3 # base with scope subtree # filter: (uid=fw03075_NO) # requesting: ALL # # search result search: 2 result: 0 Success # numResponses: 1 [root at freeipa01 ipa]# ldapsearch -h 127.0.0.1 -x -D "cn=Directory Manager" -W -b "dc=unix,dc= mydomain ,dc=it" -s sub "(cn=fw03075_NO)" Enter LDAP Password: # extended LDIF # # LDAPv3 # base with scope subtree # filter: (cn=fw03075_NO) # requesting: ALL # # search result search: 2 result: 0 Success # numResponses: 1 Same thing for "pdbac32". Or were you asking me something more complicated? My group and user tree is almost empty. There are only default groups and 5/6 user created by hand. Yes, some of them have the same uid as the one manually created, but they represent only a minority of the total. Marco > > > Thanks again > Marco > > >> >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager IPA project, >> 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 IPA project, > 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 Mar 20 13:53:12 2012 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 20 Mar 2012 09:53:12 -0400 Subject: [Freeipa-users] Problem in "ipa migrate-ds" procedure In-Reply-To: References: <4F66121F.3090200@redhat.com> <4F6737B4.5040502@redhat.com> <4F678990.7020400@redhat.com> <4F67BDBE.3010204@redhat.com> <4F6878C6.4040608@redhat.com> Message-ID: <4F688BC8.30608@redhat.com> On 03/20/2012 09:09 AM, Marco Pizzoli wrote: > > > On Tue, Mar 20, 2012 at 1:32 PM, Dmitri Pal > wrote: > > On 03/20/2012 05:19 AM, Marco Pizzoli wrote: >> >> >> On Tue, Mar 20, 2012 at 12:14 AM, Dmitri Pal > > wrote: >> >> On 03/19/2012 06:54 PM, Marco Pizzoli wrote: >>> >>> >>> On Mon, Mar 19, 2012 at 8:31 PM, Rob Crittenden >>> > wrote: >>> >>> Marco Pizzoli wrote: >>> >>> >>> >>> On Mon, Mar 19, 2012 at 2:42 PM, Rob Crittenden >>> >>> >> >> wrote: >>> >>> Dmitri Pal wrote: >>> >>> On 03/17/2012 07:36 AM, Marco Pizzoli wrote: >>> >>> Hi guys, >>> I'm trying to migrate my ldap user base >>> to freeipa. I'm >>> using the last >>> Release Candidate. >>> >>> I already changed "ipa config-mod >>> --enable-migration=TRUE" >>> This is what I have: >>> >>> ipa -v migrate-ds >>> >>> --bind-dn="cn=manager,dc=__mydc1,dc=mydc2.it >>> >>> " >>> >>> --user-container="ou=people,__dc=mydc1,dc=mydc2.it >>> >>> >>> " >>> --user-objectclass=__inetOrgPerson >>> >>> --group-container="ou=groups,__dc=mydc1,dc=mydc2.it >>> >>> " >>> --group-objectclass=posixGroup >>> --base-dn="dc=mydc1,dc=mydc2.__it >>> >>> >>> " --with-compat >>> ldap://ldap01 >>> >>> ipa: INFO: trying >>> >>> https://freeipa01.unix.__mydomain.it/ipa/xml >>> >>> >>> >>> Password: >>> ipa: INFO: Forwarding 'migrate_ds' to server >>> >>> u'http://freeipa01.unix.__mydomain.it/ipa/xml >>> >>> >>> ' >>> ipa: ERROR: Container for group not found at >>> ou=groups,dc=mydc1,dc=mydc2.it >>> >>> >>> >>> >>> I looked at my ldap server logs and I >>> found out that the search >>> executed has scope=1. Actually both for >>> users and groups. >>> This is a >>> problem for me, in having a lot of >>> subtrees (ou) in which my >>> users and >>> groups are. Is there a way to manage this? >>> >>> Thanks in advance >>> Marco >>> >>> P.s. As a side note, I suppose there's a >>> typo in the verbose >>> message I >>> obtain in my output: >>> ipa: INFO: Forwarding 'migrate_ds' to server >>> >>> *u*'http://freeipa01.unix.__mydomain.it/ipa/xml >>> >>> >>> ' >>> >>> >>> Please open tickets for both issues. >>> >>> >>> Well, I don't think either is a bug. >>> >>> If you have users/groups in multiple places >>> you'll need to migrate >>> them individually for now. It is safe to run >>> migrate-ds multiple >>> times, existing users are not migrated. >>> >>> >>> I just re-executed by specifing a nested ou for my >>> groups. >>> This is what I got: >>> >>> ipa: INFO: trying >>> https://freeipa01.unix.csebo.it/ipa/xml >>> ipa: INFO: Forwarding 'migrate_ds' to server >>> u'http://freeipa01.unix.csebo.it/ipa/xml' >>> ----------- >>> migrate-ds: >>> ----------- >>> Migrated: >>> Failed user: >>> fw03075_no: Type or value exists: >>> [other users listed] >>> Failed group: >>> pdbac32: Type or value exists: >>> [other groups listed] >>> ---------- >>> Passwords have been migrated in pre-hashed format. >>> IPA is unable to generate Kerberos keys unless provided >>> with clear text passwords. All migrated users need to >>> login at https://your.domain/ipa/migration/ before they >>> can use their Kerberos accounts. >>> >>> I don't understand what it's trying to telling me. >>> On my FreeIPA ldap server I don't see any imported user. >>> >>> What's my fault here? >>> >>> >>> The u is a python-ism for unicode. This is not a bug. >>> >>> >>> Please, could you give a little more detail on this? >>> It's only a hint on >>> what that data represents in a Python variable? >>> >>> Thanks again >>> Marco >>> >>> >>> Type or value exists occurs when one tries to add an >>> attribute value to an entry that already exists. >>> >>> I suspect that the underlying problem is different >>> between users and groups. >>> >>> For groups it is likely adding a duplicate member. >>> >>> For users I'm not really sure. It could be one of the >>> POSIX attributes. What does a failed entry look like? >>> >>> rob >>> >>> >>> The user entry: >>> ------------------------ >>> dn: uid=fw03075_NO,ou=People,dc=mydc1,dc=mydc2.it >>> >>> description: fw03075 >>> cn: fw03075 >>> uidNumber: 11013 >>> gidNumber: 503 >>> homeDirectory: /home/fw03075 >>> loginShell: /bin/sh >>> gecos: fw03075 >>> shadowLastChange: 13059 >>> shadowMax: 99999 >>> shadowWarning: 7 >>> objectClass: inetOrgPerson >>> objectClass: posixAccount >>> objectClass: shadowAccount >>> objectClass: top >>> objectClass: xxxPeopleAttributes >>> sn: SN_NON_IMPOSTATO >>> givenName: GIVENNAME_NON_IMPOSTATO >>> xxxUfficio: UFFICIO_NON_IMPOSTATO >>> xxxTipoUtente: tecnico >>> uid: fw03075_NO >>> userPassword: secret >>> >>> >>> group entry: >>> ------------------- >>> dn: >>> cn=pdbac32,ou=pdbac32,ou=prod,ou=db2,ou=databases,ou=Groups,dc=mydc1,dc=mydc2.it >>> >>> gidNumber: 10015 >>> member: uid=NESSUNO,ou=People,dc=mydc1,dc=mydc2.it >>> >>> member: uid=aaa415,ou=People,dc=mydc1,dc=mydc2.it >>> >>> member: uid=bbb446,ou=People,dc=mydc1,dc=mydc2.it >>> >>> memberUid: NESSUNO >>> memberUid: aaa415 >>> memberUid: bbb446 >>> xxxAmbiente: prod >>> xxxDB2GruppiPrivilegi: instance_owner >>> description: Mydescription >>> xxxTipoGruppo: db >>> objectClass: top >>> objectClass: posixGroup >>> objectClass: groupOfNames >>> objectClass: xxxGroupsAttributes >>> objectClass: xxxDB2GroupsAttributes >>> cn: pdbac32 >>> >>> Thanks again >>> Marco >>> >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> Do you by any chance have a _group_ with name "fw03075_NO" >> and _user_ with name "pdbac32"? >> May be you are hitting a collision on manged group managed? >> >> >> Well, yes and no. >> >> No, I don't have a group called "fw03075_NO" and No, I don't have >> a user called "pdbac32". >> >> Yes, I have some users uid=samename and groups cn=samename, but >> they are not found in the group subtree (ou) from where I >> launched "ipa migrate-ds". >> >> If this is the problem, where can I have any evidence of the >> actual problem? >> > > Can you search those names in the IPA LDAP tree after the > migration? May be there is some object already there with the same > cn that collides. This way we would be able to determine what the > colliding object is and take it from there. It might collide on > some other attribute in the entry and just be reported by uid and cn. > > > Here it is: > > [root at freeipa01 ipa]# ldapsearch -h 127.0.0.1 -x -D "cn=Directory > Manager" -W -b "dc=unix,dc=mydomain,dc=it" -s sub "(uid=fw03075_NO)" > Enter LDAP Password: > # extended LDIF > # > # LDAPv3 > # base with scope subtree > # filter: (uid=fw03075_NO) > # requesting: ALL > # > > # search result > search: 2 > result: 0 Success > > # numResponses: 1 > [root at freeipa01 ipa]# ldapsearch -h 127.0.0.1 -x -D "cn=Directory > Manager" -W -b "dc=unix,dc= mydomain ,dc=it" -s sub "(cn=fw03075_NO)" > Enter LDAP Password: > # extended LDIF > # > # LDAPv3 > # base with scope subtree > # filter: (cn=fw03075_NO) > # requesting: ALL > # > > # search result > search: 2 > result: 0 Success > > # numResponses: 1 > > Same thing for "pdbac32". > > Or were you asking me something more complicated? > > My group and user tree is almost empty. There are only default groups > and 5/6 user created by hand. > Yes, some of them have the same uid as the one manually created, but > they represent only a minority of the total. > > Marco > I am running out of ideas. Rob, any clues? > > > > >> Thanks again >> Marco >> >> >> >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager IPA project, >> 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 IPA project, > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From g17jimmy at gmail.com Tue Mar 20 14:30:15 2012 From: g17jimmy at gmail.com (Jimmy) Date: Tue, 20 Mar 2012 10:30:15 -0400 Subject: [Freeipa-users] (no subject) In-Reply-To: <4F679DD9.7090106@redhat.com> References: <4F624162.7020806@redhat.com> <4F62554F.1030804@redhat.com> <4F626135.3030402@redhat.com> <4F63575B.6090805@redhat.com> <4F636F7A.4060109@redhat.com> <4F6388E7.9000409@redhat.com> <4F63A3EC.6010205@redhat.com> <4F63B0E5.7030104@redhat.com> <4F679DD9.7090106@redhat.com> Message-ID: When I try to export the db I get this: /var/lib/dirsrv/scripts-ABC-XYZ/db2ldif -n ipaca -a /dbexport/ipaca-output.ldif Exported ldif file: /dbexport/ipaca-output.ldif [03/Mar/2012:17:27:25 +0000] - ERROR: Could not find backend 'ipaca' When I start IPA as it is now these are the logs I get: debug- http://fpaste.org/ItuZ/ catalina.out- http://fpaste.org/tSyQ/ -Jimmy On Mon, Mar 19, 2012 at 4:58 PM, Rob Crittenden wrote: > Jimmy wrote: >> >> This is all I see in the /var/log/httpd/error_log file. This issue has >> become critical. The server has been down a week and I have no idea >> why certmonger broke and don't seem to have any indication of how to >> fix it. What would be the best route besides chasing down this >> certmonger issue? Could I export all of my configuration/users/etc, >> install a completely new IPA and import my config? >> >> [Sat Mar 03 00:05:27 2012] [error] ipa: INFO: sslget >> 'https://csp-idm.pdh.csp:443/ca/agent/ca/displayBySerial' >> [Sat Mar 03 00:05:28 2012] [error] ipa: INFO: >> host/csp-idm.pdh.csp at PDH.CSP: >> cert_request(u'MIIDQzCCAisCAQAwLDEQMA4GA1UEChMHUERILkNTUDEYMBYGA1 >> >> UEAxMPY3NwLWlkbS5wZGguY3NwMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr0EHCdyTuteryFZ2bdEl+V4OATR/xk8ELthmvlwT/5qubZKwlCWS6yLawgdyCg9Yw737A7q >> >> Ge0BPxHv6E+as10NxppEPsn9BOi+TPRIMYNMNNYmO2sce2pvkMkVBqsF7Gn7mF7e5+Bpc7ApnDGP7WLsAjbso8EvLUrqVMTNyiziCSHiNk+/Fi1Om6K5GKzKkqfEDex0RK+kpMswgcaZH >> >> hmW3i+y3UxFZsJjOg3R4fJAfC0+My2d1Vx4052+EgWAbSNpSj7zmLGM2+dkmgMo5Li7jjgJe8VsrqOV4L5IgqtGVJ0EOb7EP7gynbVoa74m4XrVwEP8rd/M5RxAnD1JPuwIDAQABoIHRM >> >> BoGCSqGSIb3DQEJFDENEwtTZXJ2ZXItQ2VydDCBsgYJKoZIhvcNAQkOMYGkMIGhMA4GA1UdDwEBAAQEAwIE8DB3BgNVHREBAQAEbTBroCwGCisGAQQBgjcUAgOgHgwcbGRhcC9jc3AtaW >> >> RtLnBkaC5jc3BAUERILkNTUKA7BgYrBgEFAgKgMTAvoAkbB1BESC5DU1ChIjAgoAMCAQGhGTAXGwRsZGFwGw9jc3AtaWRtLnBkaC5jc3AwFgYDVR0lAQEABAwwCgYIKwYBBQUHAwEwDQY >> >> JKoZIhvcNAQELBQADggEBABD/Hwbgf5NJNUYt0+ntMDHiilMFkSaO6ryQ36/pCH1oR+vI+PCeClHewPo0v99h4Z8W8L7CQtDdNBUMl/JVHH5Lz7cBF8A/jXZQ+naV17EEuXncacM8AvYh >> >> 5dL2yih+8RpPalEmSgz5rijtbSigfNGrZn0Mh3qOW1kbsz+GDaaT9wLFxvdJyqgdKds2tsp0KzHIMcJuw3cwOfH8zrBRV28XYhMLm0OOhj92uxgax5UPY2VyHP5UOtOnfuduU1ZXa+o8Q >> >> IXqX7/HyDSCLGwiPJscAsp9cRzjn4KvqzZDOcdGEjXmCGfrmUiMcuzVyTDR2SdAWrHdbRmXeyVxmiBPzdk=', >> principal=u'ldap/csp-idm.pdh.csp at PDH.CSP', add=True): C >> ertificateOperationError > > > I think your CA is still not up and running. > > Things to check: > > /var/log/pki-ca/catalina.out to be see if there are start up errors. The > debug log in the same directory may contain information as well. If you are > seeing a bunch of error 32's it means your db is still corrupted. > > The output of ipa-getcert list. This will tell you what certmonger thinks is > wrong. > > Did you repair the ipaca backend in PKI-IPA? It is different than userRoot. > > > rob > >> >> >> On Fri, Mar 16, 2012 at 5:30 PM, Rob Crittenden >> ?wrote: >>> >>> Jimmy wrote: >>>> >>>> >>>> I actually shut down IPA to do the export and restarted after I >>>> imported. >>>> >>>> certutil -L -d /etc/httpd/alias >>>> Certificate Nickname ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Trust >>>> Attributes >>>> >>>> ?SSL,S/MIME,JAR/XPI >>>> Server-Cert ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?u,u,u >>>> ABC.XYZIPA CA ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? CT,C,C >>>> ipaCert ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?u,u,u >>>> Signing-Cert ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? u,u,u >>>> >>>> certutil -V -u V -n Server-Cert -d /etc/httpd/alias -e -f >>>> /etc/httpd/alias/pwdfile.txt >>>> certutil: certificate is valid >>>> >>>> How's that look? >>> >>> >>> >>> That's what it's supposed to look like. Is Apache logging a failure or >>> maybe >>> that is coming from dogtag through Apache... >>> >>> >>> rob >>> >>>> >>>> >>>> On Fri, Mar 16, 2012 at 4:34 PM, Rob Crittenden >>>> ?wrote: >>>>> >>>>> >>>>> Jimmy wrote: >>>>>> >>>>>> >>>>>> >>>>>> ipa-getcert list shows some ugly output - http://fpaste.org/bV2v/ >>>>> >>>>> >>>>> >>>>> >>>>> Looks pretty similar to what we've been seeing. The invalid credentials >>>>> means that dogtag can't validate RA agent cert. This was due to the >>>>> corrupted database. You'll need to restart the pki-cad process once the >>>>> LDAP >>>>> backend is fixed. >>>>> >>>>> The trust issues are stranger. To show the certs in those databases: >>>>> >>>>> # certutil -L -d /etc/httpd/alias >>>>> >>>>> To verify that the cert in there now has all the CA certs it needs: >>>>> # certutil -V -u V -n Server-Cert -d /etc/httpd/alias -e -f >>>>> /etc/httpd/alias/pwdfile.txt >>>>> >>>>> rob >>>>> >>>>> >>>>>> >>>>>> On Fri, Mar 16, 2012 at 4:05 PM, Jimmy ? ? ?wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> I exported/imported the /var/lib/dirsrv/slapd-PKI-IPA/db/userRoot and >>>>>>> that went smoothly but now I see this in /var/log/pki-ca/system: >>>>>>> >>>>>>> 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] >>>>>>> Operation Error - netscape.ldap.LDAPException: error result (32); >>>>>>> matchedDN >>>>>>> ?= o=ipaca >>>>>>> 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] >>>>>>> Null >>>>>>> response control >>>>>>> 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] >>>>>>> Operation Error - netscape.ldap.LDAPException: error result (32); >>>>>>> matchedDN >>>>>>> ?= o=ipaca >>>>>>> 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] >>>>>>> Null >>>>>>> response control >>>>>>> 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] >>>>>>> Operation Error - netscape.ldap.LDAPException: error result (32); >>>>>>> matchedDN >>>>>>> ?= o=ipaca >>>>>>> 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] >>>>>>> Null >>>>>>> response control >>>>>>> 10358.CRLIssuingPoint-MasterCRL - [08/Mar/2012:04:36:29 UTC] [3] [3] >>>>>>> CRLIssuingPoint MasterCRL - Cannot create or store the first CRL in >>>>>>> the >>>>>>> internaldb. The internaldb could be down. Error LDAP operation >>>>>>> failure >>>>>>> - cn=MasterCRL,ou=crlIssuingPoints, ou=ca, o=ipaca >>>>>>> netscape.ldap.LDAPE >>>>>>> xception: error result (32); matchedDN = o=ipaca >>>>>>> >>>>>>> >>>>>>> catalina.out -- http://fpaste.org/oRQd/ >>>>>>> >>>>>>> ca-debug -- http://fpaste.org/zzFL/ >>>>>>> >>>>>>> Any ideas? >>>>>>> On Fri, Mar 16, 2012 at 2:39 PM, Rob Crittenden >>>>>>> ?wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Jimmy wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> The ca_audit problem was caused by me accidentally moving the >>>>>>>>> directory to a backup location. I was cleaning up the logs to make >>>>>>>>> reading easier. When I moved the directory back that issue went >>>>>>>>> away. >>>>>>>>> No changes were made in the NSS database(s) or any other internal >>>>>>>>> workings of IPA. This system is used for very basic user >>>>>>>>> authentication, DNS, etc. >>>>>>>>> >>>>>>>>> I can do the ldif export/import for dogtag. Just from comparing >>>>>>>>> everything, it looks like the dogtag db is in >>>>>>>>> /var/lib/dirsrv/slapd-PKI-IPA/db/userRoot, is that correct? >>>>>>>>> >>>>>>>> >>>>>>>> The ipaca db >>>>>>>> >>>>>>>> rob >>>>>>>> >>>>> >>> > From marco.pizzoli at gmail.com Tue Mar 20 11:58:12 2012 From: marco.pizzoli at gmail.com (Marco Pizzoli) Date: Tue, 20 Mar 2012 12:58:12 +0100 Subject: [Freeipa-users] Error during ipa-replica-install Message-ID: Hi guys, I'm running this version of FreeIPA: [root at freeipa03 ~]# rpm -qa|grep freeipa freeipa-server-selinux-2.1.90.rc1-0.fc16.x86_64 freeipa-server-2.1.90.rc1-0.fc16.x86_64 freeipa-admintools-2.1.90.rc1-0.fc16.x86_64 freeipa-client-2.1.90.rc1-0.fc16.x86_64 freeipa-python-2.1.90.rc1-0.fc16.x86_64 I'm having this problem: [root at freeipa03 ~]# ipa-replica-install --setup-dns --no-forwarders /var/lib/ipa/replica-info-freeipa03.unix.mydomain.it.gpg Directory Manager (existing master) password: Run connection check to master Check connection from replica to remote master 'freeipa01.unix.mydomain.it': Directory Service: Unsecure port (389): OK Directory Service: Secure port (636): OK Kerberos KDC: TCP (88): OK Kerberos Kpasswd: TCP (464): OK HTTP Server: Unsecure port (80): OK HTTP Server: Secure port (443): OK The following list of ports use UDP protocol and would need to be checked manually: Kerberos KDC: UDP (88): SKIPPED Kerberos Kpasswd: UDP (464): SKIPPED Connection from replica to master is OK. Start listening on required ports for remote master check Get credentials to log in to remote master admin at UNIX.MYDOMAIN.IT password: Cannot acquire Kerberos ticket: kinit: Invalid message type while getting initial credentials Connection check failed! Please fix your network settings according to error messages above. If the check results are not valid it can be skipped with --skip-conncheck parameter. ------------------- I don't have any firewall between freeipa03 and freeipa01. This is what I have in my /var/log/messages file: Mar 20 12:03:51 freeipa03 sssd: Starting up Mar 20 12:03:51 freeipa03 sssd[be[unix.mydomain.it]]: Starting up Mar 20 12:03:52 freeipa03 ntpd_intres[773]: host name not found: 0.fedora.pool.ntp.org Mar 20 12:03:52 freeipa03 ntpd_intres[773]: host name not found: 1.fedora.pool.ntp.org Mar 20 12:03:52 freeipa03 ntpd_intres[773]: host name not found: 2.fedora.pool.ntp.org Mar 20 12:03:52 freeipa03 avahi-daemon[734]: Successfully called chroot(). Mar 20 12:03:52 freeipa03 avahi-daemon[734]: Successfully dropped remaining capabilities. Mar 20 12:03:52 freeipa03 avahi-daemon[734]: Loading service file /services/ssh.service. Mar 20 12:03:52 freeipa03 avahi-daemon[734]: Loading service file /services/udisks.service. Mar 20 12:03:52 freeipa03 avahi-daemon[734]: Network interface enumeration completed. Mar 20 12:03:52 freeipa03 avahi-daemon[734]: Registering HINFO record with values 'X86_64'/'LINUX'. Mar 20 12:03:52 freeipa03 avahi-daemon[734]: Server startup complete. Host name is freeipa03.local. Local service cookie is 3668475942. Mar 20 12:03:52 freeipa03 avahi-daemon[734]: Service "freeipa03" (/services/udisks.service) successfully established. Mar 20 12:03:52 freeipa03 avahi-daemon[734]: Service "freeipa03" (/services/ssh.service) successfully established. Mar 20 12:03:52 freeipa03 systemd-logind[764]: New seat seat0. Mar 20 12:03:53 freeipa03 sssd[pam]: Starting up Mar 20 12:03:53 freeipa03 sssd[nss]: Starting up Mar 20 12:03:53 freeipa03 network[765]: Bringing up loopback interface: [ OK ] Mar 20 12:03:54 freeipa03 kernel: [ 25.724015] e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None Mar 20 12:03:55 freeipa03 avahi-daemon[734]: Registering new address record for fe80::20c:29ff:fedc:9788 on eth0.*. Mar 20 12:03:56 freeipa03 avahi-daemon[734]: Joining mDNS multicast group on interface eth0.IPv4 with address 192.168.146.134. Mar 20 12:03:56 freeipa03 avahi-daemon[734]: New relevant interface eth0.IPv4 for mDNS. Mar 20 12:03:56 freeipa03 avahi-daemon[734]: Registering new address record for 192.168.146.134 on eth0.IPv4. Mar 20 12:03:56 freeipa03 network[765]: Bringing up interface eth0: [ OK ] Mar 20 12:03:57 freeipa03 kernel: [ 28.697268] 8021q: 802.1Q VLAN Support v1.8 Mar 20 12:03:57 freeipa03 kernel: [ 28.697283] 8021q: adding VLAN 0 to HW filter on device eth0 Mar 20 12:03:57 freeipa03 rpc.statd[994]: Version 1.2.5 starting Mar 20 12:03:57 freeipa03 ntpd[741]: Listen normally on 4 eth0 192.168.146.134 UDP 123 Mar 20 12:03:57 freeipa03 ntpd[741]: Listen normally on 5 eth0 fe80::20c:29ff:fedc:9788 UDP 123 Mar 20 12:03:57 freeipa03 ntpd[741]: peers refreshed Mar 20 12:03:57 freeipa03 sm-notify[995]: Version 1.2.5 starting Mar 20 12:03:58 freeipa03 systemd[1]: PID file /run/sendmail.pid not readable (yet?) after start. Mar 20 12:04:04 freeipa03 ntpd_intres[773]: host name not found: 0.fedora.pool.ntp.org Mar 20 12:04:07 freeipa03 systemd[1]: PID file /var/run/krb5kdc.pid not readable (yet?) after start. Mar 20 12:04:09 freeipa03 ntpd_intres[773]: host name not found: 1.fedora.pool.ntp.org Mar 20 12:04:10 freeipa03 named[1113]: starting BIND 9.8.2rc2-RedHat-9.8.2-0.4.rc2.fc16 -u named Mar 20 12:04:10 freeipa03 named[1113]: built with '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--program-prefix=' '--disable-dependency-tracking' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-libtool' '--localstatedir=/var' '--enable-threads' '--enable-ipv6' '--with-pic' '--disable-static' '--disable-openssl-version-check' '--enable-exportlib' '--with-export-libdir=/usr/lib64' '--with-export-includedir=/usr/include' '--includedir=/usr/include/bind9' '--with-pkcs11=/usr/lib64/pkcs11/PKCS11_API.so' '--with-dlz-ldap=yes' '--with-dlz-postgres=yes' '--with-dlz-mysql=yes' '--with-dlz-filesystem=yes' '--with-gssapi=yes' '--disable-isc-spnego' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'CFLAGS= -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' 'LDFLAGS=-Wl,-z,relro ' 'CPPFLAGS= -DDIG_SIGCHASE' Mar 20 12:04:10 freeipa03 named[1113]: ---------------------------------------------------- Mar 20 12:04:10 freeipa03 named[1113]: BIND 9 is maintained by Internet Systems Consortium, Mar 20 12:04:10 freeipa03 named[1113]: Inc. (ISC), a non-profit 501(c)(3) public-benefit Mar 20 12:04:10 freeipa03 named[1113]: corporation. Support and training for BIND 9 are Mar 20 12:04:10 freeipa03 named[1113]: available at https://www.isc.org/support Mar 20 12:04:10 freeipa03 named[1113]: ---------------------------------------------------- Mar 20 12:04:10 freeipa03 named[1113]: adjusted limit on open files from 4096 to 1048576 Mar 20 12:04:10 freeipa03 named[1113]: found 1 CPU, using 1 worker thread Mar 20 12:04:10 freeipa03 named[1113]: using up to 4096 sockets Mar 20 12:04:10 freeipa03 named[1113]: loading configuration from '/etc/named.conf' Mar 20 12:04:10 freeipa03 named[1113]: using default UDP/IPv4 port range: [1024, 65535] Mar 20 12:04:10 freeipa03 named[1113]: using default UDP/IPv6 port range: [1024, 65535] Mar 20 12:04:10 freeipa03 named[1113]: listening on IPv6 interfaces, port 53 Mar 20 12:04:10 freeipa03 named[1113]: listening on IPv4 interface lo, 127.0.0.1#53 Mar 20 12:04:10 freeipa03 named[1113]: listening on IPv4 interface eth0, 192.168.146.134#53 Mar 20 12:04:10 freeipa03 named[1113]: generating session key for dynamic DNS Mar 20 12:04:10 freeipa03 named[1113]: sizing zone task pool based on 6 zones Mar 20 12:04:10 freeipa03 named[1113]: set up managed keys zone for view _default, file 'managed-keys.bind' Mar 20 12:04:10 freeipa03 named[1113]: Warning: 'empty-zones-enable/disable-empty-zone' not set: disabling RFC 1918 empty zones Mar 20 12:04:10 freeipa03 named[1113]: automatic empty zone: 127.IN-ADDR.ARPA Mar 20 12:04:10 freeipa03 named[1113]: automatic empty zone: 254.169.IN-ADDR.ARPA Mar 20 12:04:10 freeipa03 named[1113]: automatic empty zone: 2.0.192.IN-ADDR.ARPA Mar 20 12:04:10 freeipa03 named[1113]: automatic empty zone: 100.51.198.IN-ADDR.ARPA Mar 20 12:04:10 freeipa03 named[1113]: automatic empty zone: 113.0.203.IN-ADDR.ARPA Mar 20 12:04:10 freeipa03 named[1113]: automatic empty zone: 255.255.255.255.IN-ADDR.ARPA Mar 20 12:04:10 freeipa03 named[1113]: automatic empty zone: 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA Mar 20 12:04:10 freeipa03 named[1113]: automatic empty zone: D.F.IP6.ARPA Mar 20 12:04:10 freeipa03 named[1113]: automatic empty zone: 8.E.F.IP6.ARPA Mar 20 12:04:10 freeipa03 named[1113]: automatic empty zone: 9.E.F.IP6.ARPA Mar 20 12:04:10 freeipa03 named[1113]: automatic empty zone: A.E.F.IP6.ARPA Mar 20 12:04:10 freeipa03 named[1113]: automatic empty zone: B.E.F.IP6.ARPA Mar 20 12:04:10 freeipa03 named[1113]: automatic empty zone: 8.B.D.0.1.0.0.2.IP6.ARPA Mar 20 12:04:11 freeipa03 named[1113]: command channel listening on 127.0.0.1#953 Mar 20 12:04:11 freeipa03 named[1113]: command channel listening on ::1#953 Mar 20 12:04:11 freeipa03 named[1113]: zone 0.in-addr.arpa/IN: loaded serial 0 Mar 20 12:04:11 freeipa03 named[1113]: zone 1.0.0.127.in-addr.arpa/IN: loaded serial 0 Mar 20 12:04:11 freeipa03 named[1113]: zone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN: loaded serial 0 Mar 20 12:04:11 freeipa03 named[1113]: zone localhost.localdomain/IN: loaded serial 0 Mar 20 12:04:11 freeipa03 named[1113]: zone localhost/IN: loaded serial 0 Mar 20 12:04:11 freeipa03 named[1113]: managed-keys-zone ./IN: loaded serial 0 Mar 20 12:04:11 freeipa03 named[1113]: running Mar 20 12:04:11 freeipa03 named[1107]: Starting named: [ OK ] Mar 20 12:04:12 freeipa03 systemd[1]: PID file /var/run/httpd/httpd.pid not readable (yet?) after start. Mar 20 12:04:13 freeipa03 ipactl[974]: Starting Directory Service Mar 20 12:04:13 freeipa03 ipactl[974]: Starting KDC Service Mar 20 12:04:13 freeipa03 ipactl[974]: Starting KPASSWD Service Mar 20 12:04:13 freeipa03 ipactl[974]: Starting DNS Service Mar 20 12:04:13 freeipa03 ipactl[974]: Starting HTTP Service Mar 20 12:04:13 freeipa03 ipactl[974]: Starting CA Service Mar 20 12:04:14 freeipa03 ntpd_intres[773]: host name not found: 2.fedora.pool.ntp.org Mar 20 12:04:17 freeipa03 kernel: [ 49.099554] hrtimer: interrupt took 17369081 ns Mar 20 12:05:15 freeipa03 systemd[1]: Startup finished in 2s 98ms 878us (kernel) + 5s 40ms 620us (initrd) + 1min 40s 13ms 749us (userspace) = 1min 47s 153ms 247us. Mar 20 12:06:18 freeipa03 ntpd_intres[773]: host name not found: 0.fedora.pool.ntp.org Mar 20 12:06:23 freeipa03 ntpd_intres[773]: host name not found: 1.fedora.pool.ntp.org Mar 20 12:06:28 freeipa03 ntpd_intres[773]: host name not found: 2.fedora.pool.ntp.org Mar 20 12:09:59 freeipa03 systemd-logind[764]: New session 1 of user root. Mar 20 12:10:35 freeipa03 ntpd_intres[773]: host name not found: 0.fedora.pool.ntp.org Mar 20 12:10:40 freeipa03 ntpd_intres[773]: host name not found: 1.fedora.pool.ntp.org Mar 20 12:10:45 freeipa03 ntpd_intres[773]: host name not found: 2.fedora.pool.ntp.org Mar 20 12:16:31 freeipa03 python: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credentials cache file '/tmp/krb5cc_0' not found) Mar 20 12:18:28 freeipa03 systemd-tmpfiles[1438]: Successfully loaded SELinux database in 232ms 225us, size on heap is 485K. Mar 20 12:18:29 freeipa03 systemd-tmpfiles[1438]: Two or more conflicting lines for /var/run/dirsrv configured, ignoring. Mar 20 12:18:29 freeipa03 systemd-tmpfiles[1438]: Two or more conflicting lines for /var/lock/dirsrv configured, ignoring. Mar 20 12:18:48 freeipa03 ntpd_intres[773]: DNS 0.fedora.pool.ntp.org -> 212.45.144.206 Mar 20 12:18:49 freeipa03 ntpd_intres[773]: DNS 1.fedora.pool.ntp.org -> 212.45.144.88 Mar 20 12:18:49 freeipa03 ntpd_intres[773]: DNS 2.fedora.pool.ntp.org -> 77.242.176.254 Mar 20 12:19:49 freeipa03 ntpd[741]: frequency error 531 PPM exceeds tolerance 500 PPM Mar 20 12:24:45 freeipa03 systemd-logind[764]: New session 2 of user root. Mar 20 12:24:46 freeipa03 systemd-logind[764]: Removed session 2. Mar 20 12:27:46 freeipa03 ntpd[741]: frequency error 558 PPM exceeds tolerance 500 PPM Mar 20 12:29:56 freeipa03 ntpd[741]: frequency error 516 PPM exceeds tolerance 500 PPM Mar 20 12:32:08 freeipa03 systemd[1]: pki-cad at pki-ca.service: main process exited, code=exited, status=143 Mar 20 12:32:08 freeipa03 systemd[1]: Unit pki-cad at pki-ca.service entered failed state. Mar 20 12:32:21 freeipa03 named[1113]: received control channel command 'stop' Mar 20 12:32:21 freeipa03 named[1113]: shutting down: flushing changes Mar 20 12:32:21 freeipa03 named[1113]: stopping command channel on 127.0.0.1#953 Mar 20 12:32:21 freeipa03 named[1113]: stopping command channel on ::1#953 Mar 20 12:32:21 freeipa03 named[1113]: no longer listening on ::#53 Mar 20 12:32:21 freeipa03 named[1113]: no longer listening on 127.0.0.1#53 Mar 20 12:32:21 freeipa03 named[1113]: no longer listening on 192.168.146.134#53 Mar 20 12:32:22 freeipa03 named[1113]: exiting Mar 20 12:32:23 freeipa03 named[1538]: Stopping named: .[ OK ] Mar 20 12:32:24 freeipa03 systemd[1]: kadmin.service: main process exited, code=exited, status=2 Mar 20 12:32:24 freeipa03 systemd[1]: Unit kadmin.service entered failed state. Mar 20 12:32:28 freeipa03 ipactl[1458]: Stopping CA Service Mar 20 12:32:28 freeipa03 ipactl[1458]: Stopping HTTP Service Mar 20 12:32:28 freeipa03 ipactl[1458]: Stopping DNS Service Mar 20 12:32:28 freeipa03 ipactl[1458]: Stopping KPASSWD Service Mar 20 12:32:28 freeipa03 ipactl[1458]: Stopping KDC Service Mar 20 12:32:28 freeipa03 ipactl[1458]: Stopping Directory Service Mar 20 12:36:43 freeipa03 ntpd[741]: frequency error 546 PPM exceeds tolerance 500 PPM Mar 20 12:48:50 freeipa03 ntpd[741]: frequency error 579 PPM exceeds tolerance 500 PPM I can add this info: [root at freeipa03 ~]# kinit admin kinit: Cannot contact any KDC for realm 'UNIX.MYDOMAIN.IT' while getting initial credentials [root at freeipa03 ~]# cat /etc/krb5.conf [logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] default_realm = UNIX.MYDOMAIN.IT dns_lookup_realm = false dns_lookup_kdc = false rdns = false ticket_lifetime = 24h forwardable = yes [realms] UNIX.MYDOMAIN.IT = { kdc = freeipa03.unix.mydomain.it:88 admin_server = freeipa03.unix.mydomain.it:749 default_domain = unix.mydomain.it pkinit_anchors = FILE:/etc/ipa/ca.crt } [domain_realm] .unix.mydomain.it = UNIX.MYDOMAIN.IT unix.mydomain.it = UNIX.MYDOMAIN.IT [dbmodules] # UNIX.MYDOMAIN.IT = { # db_library = kldap # ldap_servers = ldapi://%2fvar%2frun%2fslapd-UNIX-MYDOMAIN-IT.socket # ldap_kerberos_container_dn = cn=kerberos,dc=unix,dc=mydomain,dc=it # ldap_kdc_dn = uid=kdc,cn=sysaccounts,cn=etc,dc=unix,dc=mydomain,dc=it # ldap_kadmind_dn = uid=kdc,cn=sysaccounts,cn=etc,dc=unix,dc=mydomain,dc=it # ldap_service_password_file = /var/kerberos/krb5kdc/ldappwd # } UNIX.MYDOMAIN.IT = { db_library = ipadb.so } Thanks as usual Marco -------------- next part -------------- An HTML attachment was scrubbed... URL: From maciej.sawicki at polidea.pl Tue Mar 20 15:54:55 2012 From: maciej.sawicki at polidea.pl (Maciej Sawicki) Date: Tue, 20 Mar 2012 16:54:55 +0100 Subject: [Freeipa-users] groups migration problem Message-ID: Hi, I haven't manage to migrate ldap groups (in free ipa panel I see that users are migrated) #ipa migrate-ds ldap://192.168.1.125:389 --bind-dn="cn=admin,dc=polidea,dc=pl" --group-container='ou=groups,dc=polidea,dc=pl' #ipa: ERROR: Container for group not found My old ldap setup: https://skitch.com/viroos/8miq5/ldap-ou-groups-dc-polidea-dc-pl-lem-apache-directory-studio. Best regards, Maciej Sawicki From rcritten at redhat.com Tue Mar 20 17:41:00 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 20 Mar 2012 13:41:00 -0400 Subject: [Freeipa-users] (no subject) In-Reply-To: References: <4F62554F.1030804@redhat.com> <4F626135.3030402@redhat.com> <4F63575B.6090805@redhat.com> <4F636F7A.4060109@redhat.com> <4F6388E7.9000409@redhat.com> <4F63A3EC.6010205@redhat.com> <4F63B0E5.7030104@redhat.com> <4F679DD9.7090106@redhat.com> Message-ID: <4F68C12C.80103@redhat.com> Jimmy wrote: > When I try to export the db I get this: > > /var/lib/dirsrv/scripts-ABC-XYZ/db2ldif -n ipaca -a /dbexport/ipaca-output.ldif > Exported ldif file: /dbexport/ipaca-output.ldif > [03/Mar/2012:17:27:25 +0000] - ERROR: Could not find backend 'ipaca'] The CA uses a different instance of 389-ds. You need to run the scripts specific to that instance. dogtag sets things up slightly differently, you want something like: /usr/lib/dirsrv/slapd-PKI-IPA/db2ldif -n ipaca -a /dbexport/ipaca-output.ldif > When I start IPA as it is now these are the logs I get: > > debug- http://fpaste.org/ItuZ/ > catalina.out- http://fpaste.org/tSyQ/ Yes, as I suspected it isn't finding any of its data which is why the certificate renewal is failing. rob > > -Jimmy > > On Mon, Mar 19, 2012 at 4:58 PM, Rob Crittenden wrote: >> Jimmy wrote: >>> >>> This is all I see in the /var/log/httpd/error_log file. This issue has >>> become critical. The server has been down a week and I have no idea >>> why certmonger broke and don't seem to have any indication of how to >>> fix it. What would be the best route besides chasing down this >>> certmonger issue? Could I export all of my configuration/users/etc, >>> install a completely new IPA and import my config? >>> >>> [Sat Mar 03 00:05:27 2012] [error] ipa: INFO: sslget >>> 'https://csp-idm.pdh.csp:443/ca/agent/ca/displayBySerial' >>> [Sat Mar 03 00:05:28 2012] [error] ipa: INFO: >>> host/csp-idm.pdh.csp at PDH.CSP: >>> cert_request(u'MIIDQzCCAisCAQAwLDEQMA4GA1UEChMHUERILkNTUDEYMBYGA1 >>> >>> UEAxMPY3NwLWlkbS5wZGguY3NwMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr0EHCdyTuteryFZ2bdEl+V4OATR/xk8ELthmvlwT/5qubZKwlCWS6yLawgdyCg9Yw737A7q >>> >>> Ge0BPxHv6E+as10NxppEPsn9BOi+TPRIMYNMNNYmO2sce2pvkMkVBqsF7Gn7mF7e5+Bpc7ApnDGP7WLsAjbso8EvLUrqVMTNyiziCSHiNk+/Fi1Om6K5GKzKkqfEDex0RK+kpMswgcaZH >>> >>> hmW3i+y3UxFZsJjOg3R4fJAfC0+My2d1Vx4052+EgWAbSNpSj7zmLGM2+dkmgMo5Li7jjgJe8VsrqOV4L5IgqtGVJ0EOb7EP7gynbVoa74m4XrVwEP8rd/M5RxAnD1JPuwIDAQABoIHRM >>> >>> BoGCSqGSIb3DQEJFDENEwtTZXJ2ZXItQ2VydDCBsgYJKoZIhvcNAQkOMYGkMIGhMA4GA1UdDwEBAAQEAwIE8DB3BgNVHREBAQAEbTBroCwGCisGAQQBgjcUAgOgHgwcbGRhcC9jc3AtaW >>> >>> RtLnBkaC5jc3BAUERILkNTUKA7BgYrBgEFAgKgMTAvoAkbB1BESC5DU1ChIjAgoAMCAQGhGTAXGwRsZGFwGw9jc3AtaWRtLnBkaC5jc3AwFgYDVR0lAQEABAwwCgYIKwYBBQUHAwEwDQY >>> >>> JKoZIhvcNAQELBQADggEBABD/Hwbgf5NJNUYt0+ntMDHiilMFkSaO6ryQ36/pCH1oR+vI+PCeClHewPo0v99h4Z8W8L7CQtDdNBUMl/JVHH5Lz7cBF8A/jXZQ+naV17EEuXncacM8AvYh >>> >>> 5dL2yih+8RpPalEmSgz5rijtbSigfNGrZn0Mh3qOW1kbsz+GDaaT9wLFxvdJyqgdKds2tsp0KzHIMcJuw3cwOfH8zrBRV28XYhMLm0OOhj92uxgax5UPY2VyHP5UOtOnfuduU1ZXa+o8Q >>> >>> IXqX7/HyDSCLGwiPJscAsp9cRzjn4KvqzZDOcdGEjXmCGfrmUiMcuzVyTDR2SdAWrHdbRmXeyVxmiBPzdk=', >>> principal=u'ldap/csp-idm.pdh.csp at PDH.CSP', add=True): C >>> ertificateOperationError >> >> >> I think your CA is still not up and running. >> >> Things to check: >> >> /var/log/pki-ca/catalina.out to be see if there are start up errors. The >> debug log in the same directory may contain information as well. If you are >> seeing a bunch of error 32's it means your db is still corrupted. >> >> The output of ipa-getcert list. This will tell you what certmonger thinks is >> wrong. >> >> Did you repair the ipaca backend in PKI-IPA? It is different than userRoot. >> >> >> rob >> >>> >>> >>> On Fri, Mar 16, 2012 at 5:30 PM, Rob Crittenden >>> wrote: >>>> >>>> Jimmy wrote: >>>>> >>>>> >>>>> I actually shut down IPA to do the export and restarted after I >>>>> imported. >>>>> >>>>> certutil -L -d /etc/httpd/alias >>>>> Certificate Nickname Trust >>>>> Attributes >>>>> >>>>> SSL,S/MIME,JAR/XPI >>>>> Server-Cert u,u,u >>>>> ABC.XYZIPA CA CT,C,C >>>>> ipaCert u,u,u >>>>> Signing-Cert u,u,u >>>>> >>>>> certutil -V -u V -n Server-Cert -d /etc/httpd/alias -e -f >>>>> /etc/httpd/alias/pwdfile.txt >>>>> certutil: certificate is valid >>>>> >>>>> How's that look? >>>> >>>> >>>> >>>> That's what it's supposed to look like. Is Apache logging a failure or >>>> maybe >>>> that is coming from dogtag through Apache... >>>> >>>> >>>> rob >>>> >>>>> >>>>> >>>>> On Fri, Mar 16, 2012 at 4:34 PM, Rob Crittenden >>>>> wrote: >>>>>> >>>>>> >>>>>> Jimmy wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> ipa-getcert list shows some ugly output - http://fpaste.org/bV2v/ >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Looks pretty similar to what we've been seeing. The invalid credentials >>>>>> means that dogtag can't validate RA agent cert. This was due to the >>>>>> corrupted database. You'll need to restart the pki-cad process once the >>>>>> LDAP >>>>>> backend is fixed. >>>>>> >>>>>> The trust issues are stranger. To show the certs in those databases: >>>>>> >>>>>> # certutil -L -d /etc/httpd/alias >>>>>> >>>>>> To verify that the cert in there now has all the CA certs it needs: >>>>>> # certutil -V -u V -n Server-Cert -d /etc/httpd/alias -e -f >>>>>> /etc/httpd/alias/pwdfile.txt >>>>>> >>>>>> rob >>>>>> >>>>>> >>>>>>> >>>>>>> On Fri, Mar 16, 2012 at 4:05 PM, Jimmy wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I exported/imported the /var/lib/dirsrv/slapd-PKI-IPA/db/userRoot and >>>>>>>> that went smoothly but now I see this in /var/log/pki-ca/system: >>>>>>>> >>>>>>>> 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] >>>>>>>> Operation Error - netscape.ldap.LDAPException: error result (32); >>>>>>>> matchedDN >>>>>>>> = o=ipaca >>>>>>>> 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] >>>>>>>> Null >>>>>>>> response control >>>>>>>> 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] >>>>>>>> Operation Error - netscape.ldap.LDAPException: error result (32); >>>>>>>> matchedDN >>>>>>>> = o=ipaca >>>>>>>> 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] >>>>>>>> Null >>>>>>>> response control >>>>>>>> 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] >>>>>>>> Operation Error - netscape.ldap.LDAPException: error result (32); >>>>>>>> matchedDN >>>>>>>> = o=ipaca >>>>>>>> 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] >>>>>>>> Null >>>>>>>> response control >>>>>>>> 10358.CRLIssuingPoint-MasterCRL - [08/Mar/2012:04:36:29 UTC] [3] [3] >>>>>>>> CRLIssuingPoint MasterCRL - Cannot create or store the first CRL in >>>>>>>> the >>>>>>>> internaldb. The internaldb could be down. Error LDAP operation >>>>>>>> failure >>>>>>>> - cn=MasterCRL,ou=crlIssuingPoints, ou=ca, o=ipaca >>>>>>>> netscape.ldap.LDAPE >>>>>>>> xception: error result (32); matchedDN = o=ipaca >>>>>>>> >>>>>>>> >>>>>>>> catalina.out -- http://fpaste.org/oRQd/ >>>>>>>> >>>>>>>> ca-debug -- http://fpaste.org/zzFL/ >>>>>>>> >>>>>>>> Any ideas? >>>>>>>> On Fri, Mar 16, 2012 at 2:39 PM, Rob Crittenden >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Jimmy wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The ca_audit problem was caused by me accidentally moving the >>>>>>>>>> directory to a backup location. I was cleaning up the logs to make >>>>>>>>>> reading easier. When I moved the directory back that issue went >>>>>>>>>> away. >>>>>>>>>> No changes were made in the NSS database(s) or any other internal >>>>>>>>>> workings of IPA. This system is used for very basic user >>>>>>>>>> authentication, DNS, etc. >>>>>>>>>> >>>>>>>>>> I can do the ldif export/import for dogtag. Just from comparing >>>>>>>>>> everything, it looks like the dogtag db is in >>>>>>>>>> /var/lib/dirsrv/slapd-PKI-IPA/db/userRoot, is that correct? >>>>>>>>>> >>>>>>>>> >>>>>>>>> The ipaca db >>>>>>>>> >>>>>>>>> rob >>>>>>>>> >>>>>> >>>> >> From rcritten at redhat.com Tue Mar 20 18:14:30 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 20 Mar 2012 14:14:30 -0400 Subject: [Freeipa-users] Problem in "ipa migrate-ds" procedure In-Reply-To: <4F688BC8.30608@redhat.com> References: <4F66121F.3090200@redhat.com> <4F6737B4.5040502@redhat.com> <4F678990.7020400@redhat.com> <4F67BDBE.3010204@redhat.com> <4F6878C6.4040608@redhat.com> <4F688BC8.30608@redhat.com> Message-ID: <4F68C906.1020903@redhat.com> Dmitri Pal wrote: > On 03/20/2012 09:09 AM, Marco Pizzoli wrote: >> >> >> On Tue, Mar 20, 2012 at 1:32 PM, Dmitri Pal > > wrote: >> >> On 03/20/2012 05:19 AM, Marco Pizzoli wrote: >>> >>> >>> On Tue, Mar 20, 2012 at 12:14 AM, Dmitri Pal >> > wrote: >>> >>> On 03/19/2012 06:54 PM, Marco Pizzoli wrote: >>>> >>>> >>>> On Mon, Mar 19, 2012 at 8:31 PM, Rob Crittenden >>>> > wrote: >>>> >>>> Marco Pizzoli wrote: >>>> >>>> >>>> >>>> On Mon, Mar 19, 2012 at 2:42 PM, Rob Crittenden >>>> >>>> >>> >> wrote: >>>> >>>> Dmitri Pal wrote: >>>> >>>> On 03/17/2012 07:36 AM, Marco Pizzoli wrote: >>>> >>>> Hi guys, >>>> I'm trying to migrate my ldap user base to freeipa. I'm >>>> using the last >>>> Release Candidate. >>>> >>>> I already changed "ipa config-mod >>>> --enable-migration=TRUE" >>>> This is what I have: >>>> >>>> ipa -v migrate-ds >>>> --bind-dn="cn=manager,dc=__mydc1,dc=mydc2.it >>>> >>>> " >>>> --user-container="ou=people,__dc=mydc1,dc=mydc2.it >>>> >>>> >>>> " --user-objectclass=__inetOrgPerson >>>> --group-container="ou=groups,__dc=mydc1,dc=mydc2.it >>>> >>>> " >>>> --group-objectclass=posixGroup >>>> --base-dn="dc=mydc1,dc=mydc2.__it >>>> >>>> " --with-compat ldap://ldap01 >>>> >>>> ipa: INFO: trying >>>> https://freeipa01.unix.__mydomain.it/ipa/xml >>>> >>>> >>>> >>>> Password: >>>> ipa: INFO: Forwarding 'migrate_ds' to server >>>> u'http://freeipa01.unix.__mydomain.it/ipa/xml >>>> >>>> >>>> ' >>>> ipa: ERROR: Container for group not found at >>>> ou=groups,dc=mydc1,dc=mydc2.it >>>> >>>> >>>> >>>> >>>> I looked at my ldap server logs and I found out that >>>> the search >>>> executed has scope=1. Actually both for users and >>>> groups. >>>> This is a >>>> problem for me, in having a lot of subtrees (ou) in >>>> which my >>>> users and >>>> groups are. Is there a way to manage this? >>>> >>>> Thanks in advance >>>> Marco >>>> >>>> P.s. As a side note, I suppose there's a typo in the >>>> verbose >>>> message I >>>> obtain in my output: >>>> ipa: INFO: Forwarding 'migrate_ds' to server >>>> *u*'http://freeipa01.unix.__mydomain.it/ipa/xml >>>> >>>> >>>> ' >>>> >>>> >>>> Please open tickets for both issues. >>>> >>>> >>>> Well, I don't think either is a bug. >>>> >>>> If you have users/groups in multiple places you'll >>>> need to migrate >>>> them individually for now. It is safe to run >>>> migrate-ds multiple >>>> times, existing users are not migrated. >>>> >>>> >>>> I just re-executed by specifing a nested ou for my >>>> groups. >>>> This is what I got: >>>> >>>> ipa: INFO: trying >>>> https://freeipa01.unix.csebo.it/ipa/xml >>>> ipa: INFO: Forwarding 'migrate_ds' to server >>>> u'http://freeipa01.unix.csebo.it/ipa/xml' >>>> ----------- >>>> migrate-ds: >>>> ----------- >>>> Migrated: >>>> Failed user: >>>> fw03075_no: Type or value exists: >>>> [other users listed] >>>> Failed group: >>>> pdbac32: Type or value exists: >>>> [other groups listed] >>>> ---------- >>>> Passwords have been migrated in pre-hashed format. >>>> IPA is unable to generate Kerberos keys unless provided >>>> with clear text passwords. All migrated users need to >>>> login at https://your.domain/ipa/migration/ before they >>>> can use their Kerberos accounts. >>>> >>>> I don't understand what it's trying to telling me. >>>> On my FreeIPA ldap server I don't see any imported user. >>>> >>>> What's my fault here? >>>> >>>> >>>> The u is a python-ism for unicode. This is not a bug. >>>> >>>> >>>> Please, could you give a little more detail on this? >>>> It's only a hint on >>>> what that data represents in a Python variable? >>>> >>>> Thanks again >>>> Marco >>>> >>>> >>>> Type or value exists occurs when one tries to add an >>>> attribute value to an entry that already exists. >>>> >>>> I suspect that the underlying problem is different >>>> between users and groups. >>>> >>>> For groups it is likely adding a duplicate member. >>>> >>>> For users I'm not really sure. It could be one of the >>>> POSIX attributes. What does a failed entry look like? >>>> >>>> rob >>>> >>>> >>>> The user entry: >>>> ------------------------ >>>> dn: uid=fw03075_NO,ou=People,dc=mydc1,dc=mydc2.it >>>> >>>> description: fw03075 >>>> cn: fw03075 >>>> uidNumber: 11013 >>>> gidNumber: 503 >>>> homeDirectory: /home/fw03075 >>>> loginShell: /bin/sh >>>> gecos: fw03075 >>>> shadowLastChange: 13059 >>>> shadowMax: 99999 >>>> shadowWarning: 7 >>>> objectClass: inetOrgPerson >>>> objectClass: posixAccount >>>> objectClass: shadowAccount >>>> objectClass: top >>>> objectClass: xxxPeopleAttributes >>>> sn: SN_NON_IMPOSTATO >>>> givenName: GIVENNAME_NON_IMPOSTATO >>>> xxxUfficio: UFFICIO_NON_IMPOSTATO >>>> xxxTipoUtente: tecnico >>>> uid: fw03075_NO >>>> userPassword: secret >>>> >>>> >>>> group entry: >>>> ------------------- >>>> dn: >>>> cn=pdbac32,ou=pdbac32,ou=prod,ou=db2,ou=databases,ou=Groups,dc=mydc1,dc=mydc2.it >>>> >>>> gidNumber: 10015 >>>> member: uid=NESSUNO,ou=People,dc=mydc1,dc=mydc2.it >>>> >>>> member: uid=aaa415,ou=People,dc=mydc1,dc=mydc2.it >>>> >>>> member: uid=bbb446,ou=People,dc=mydc1,dc=mydc2.it >>>> >>>> memberUid: NESSUNO >>>> memberUid: aaa415 >>>> memberUid: bbb446 >>>> xxxAmbiente: prod >>>> xxxDB2GruppiPrivilegi: instance_owner >>>> description: Mydescription >>>> xxxTipoGruppo: db >>>> objectClass: top >>>> objectClass: posixGroup >>>> objectClass: groupOfNames >>>> objectClass: xxxGroupsAttributes >>>> objectClass: xxxDB2GroupsAttributes >>>> cn: pdbac32 >>>> >>>> Thanks again >>>> Marco >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-users mailing list >>>> Freeipa-users at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> >>> Do you by any chance have a _group_ with name "fw03075_NO" >>> and _user_ with name "pdbac32"? >>> May be you are hitting a collision on manged group managed? >>> >>> >>> Well, yes and no. >>> >>> No, I don't have a group called "fw03075_NO" and No, I don't have >>> a user called "pdbac32". >>> >>> Yes, I have some users uid=samename and groups cn=samename, but >>> they are not found in the group subtree (ou) from where I >>> launched "ipa migrate-ds". >>> >>> If this is the problem, where can I have any evidence of the >>> actual problem? >>> >> >> Can you search those names in the IPA LDAP tree after the >> migration? May be there is some object already there with the same >> cn that collides. This way we would be able to determine what the >> colliding object is and take it from there. It might collide on >> some other attribute in the entry and just be reported by uid and cn. >> >> >> Here it is: >> >> [root at freeipa01 ipa]# ldapsearch -h 127.0.0.1 -x -D "cn=Directory >> Manager" -W -b "dc=unix,dc=mydomain,dc=it" -s sub "(uid=fw03075_NO)" >> Enter LDAP Password: >> # extended LDIF >> # >> # LDAPv3 >> # base with scope subtree >> # filter: (uid=fw03075_NO) >> # requesting: ALL >> # >> >> # search result >> search: 2 >> result: 0 Success >> >> # numResponses: 1 >> [root at freeipa01 ipa]# ldapsearch -h 127.0.0.1 -x -D "cn=Directory >> Manager" -W -b "dc=unix,dc= mydomain ,dc=it" -s sub "(cn=fw03075_NO)" >> Enter LDAP Password: >> # extended LDIF >> # >> # LDAPv3 >> # base with scope subtree >> # filter: (cn=fw03075_NO) >> # requesting: ALL >> # >> >> # search result >> search: 2 >> result: 0 Success >> >> # numResponses: 1 >> >> Same thing for "pdbac32". >> >> Or were you asking me something more complicated? >> >> My group and user tree is almost empty. There are only default groups >> and 5/6 user created by hand. >> Yes, some of them have the same uid as the one manually created, but >> they represent only a minority of the total. >> >> Marco >> > > I am running out of ideas. Rob, any clues? Not yet. This isn't a duplicate entry problem, it must have something to do with the way we create the new users in IPA. I think this is going to require setting up a similar machine and trying to reproduce it. rob From rcritten at redhat.com Tue Mar 20 18:22:37 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 20 Mar 2012 14:22:37 -0400 Subject: [Freeipa-users] groups migration problem In-Reply-To: References: Message-ID: <4F68CAED.5010509@redhat.com> Maciej Sawicki wrote: > Hi, > I haven't manage to migrate ldap groups (in free ipa panel I see that > users are migrated) > #ipa migrate-ds ldap://192.168.1.125:389 > --bind-dn="cn=admin,dc=polidea,dc=pl" > --group-container='ou=groups,dc=polidea,dc=pl' > #ipa: ERROR: Container for group not found > > My old ldap setup: > https://skitch.com/viroos/8miq5/ldap-ou-groups-dc-polidea-dc-pl-lem-apache-directory-studio. The basedn is automatically appended. Try --group-container=ou=groups regards rob From g17jimmy at gmail.com Tue Mar 20 19:16:48 2012 From: g17jimmy at gmail.com (Jimmy) Date: Tue, 20 Mar 2012 15:16:48 -0400 Subject: [Freeipa-users] (no subject) In-Reply-To: References: <4F62554F.1030804@redhat.com> <4F626135.3030402@redhat.com> <4F63575B.6090805@redhat.com> <4F636F7A.4060109@redhat.com> <4F6388E7.9000409@redhat.com> <4F63A3EC.6010205@redhat.com> <4F63B0E5.7030104@redhat.com> <4F679DD9.7090106@redhat.com> <4F68C12C.80103@redhat.com> Message-ID: I was able to do this: /usr/lib64/dirsrv/slapd-PKI-IPA/db2ldif -n ipaca -a /dbexport/ipaca-output.ldif /usr/lib64/dirsrv/slapd-PKI-IPA/ldif2db -n ipaca -i /dbexport/ipaca-output.ldif The cert still doesn't seem to be renewing, though. Here is the debug and catalina.out. http://fpaste.org/k0Lz/ http://fpaste.org/UUnE/ ?ipa-getcert list shows this for a couple certs in question: Request ID '20110913154314': ? ? ? ?status: MONITORING ? ? ? ?ca-error: Error setting up ccache for local "host" service using default keytab. ? ? ? ?stuck: no ? ? ? ?key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA//pwdfile.txt' ? ? ? ?certificate: type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS Certificate DB' ? ? ? ?CA: IPA ? ? ? ?issuer: CN=Certificate Authority,O=ABC.XYZ ? ? ? ?subject: CN=xyz-ipa.abc.xyz,O=ABC.XYZ ? ? ? ?expires: 2012-03-11 15:43:13 UTC ? ? ? ?eku: id-kp-serverAuth ? ? ? ?command: ? ? ? ?track: yes ? ? ? ?auto-renew: yes Request ID '20110913154337': ? ? ? ?status: MONITORING ? ? ? ?ca-error: Error setting up ccache for local "host" service using default keytab. ? ? ? ?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=ABC.XYZ ? ? ? ?subject: CN=xyz-ipa.abc.xyz,O=ABC.XYZ ? ? ? ?expires: 2012-03-11 15:43:37 UTC ? ? ? ?eku: id-kp-serverAuth ? ? ? ?command: ? ? ? ?track: yes ? ? ? ?auto-renew: yes On Tue, Mar 20, 2012 at 1:41 PM, Rob Crittenden wrote: > Jimmy wrote: >> >> When I try to export the db I get this: >> >> ?/var/lib/dirsrv/scripts-ABC-XYZ/db2ldif -n ipaca -a >> /dbexport/ipaca-output.ldif >> Exported ldif file: /dbexport/ipaca-output.ldif >> [03/Mar/2012:17:27:25 +0000] - ERROR: Could not find backend 'ipaca'] > > > The CA uses a different instance of 389-ds. You need to run the scripts > specific to that instance. dogtag sets things up slightly differently, you > want something like: > > /usr/lib/dirsrv/slapd-PKI-IPA/db2ldif -n ipaca -a > /dbexport/ipaca-output.ldif > > >> When I start IPA as it is now these are the logs I get: >> >> debug- http://fpaste.org/ItuZ/ >> catalina.out- http://fpaste.org/tSyQ/ > > > Yes, as I suspected it isn't finding any of its data which is why the > certificate renewal is failing. > > rob > > >> >> -Jimmy >> >> On Mon, Mar 19, 2012 at 4:58 PM, Rob Crittenden >> ?wrote: >>> >>> Jimmy wrote: >>>> >>>> >>>> This is all I see in the /var/log/httpd/error_log file. This issue has >>>> become critical. The server has been down a week and I have no idea >>>> why certmonger broke and don't seem to have any indication of how to >>>> fix it. What would be the best route besides chasing down this >>>> certmonger issue? Could I export all of my configuration/users/etc, >>>> install a completely new IPA and import my config? >>>> >>>> [Sat Mar 03 00:05:27 2012] [error] ipa: INFO: sslget >>>> 'https://csp-idm.pdh.csp:443/ca/agent/ca/displayBySerial' >>>> [Sat Mar 03 00:05:28 2012] [error] ipa: INFO: >>>> host/csp-idm.pdh.csp at PDH.CSP: >>>> cert_request(u'MIIDQzCCAisCAQAwLDEQMA4GA1UEChMHUERILkNTUDEYMBYGA1 >>>> >>>> >>>> UEAxMPY3NwLWlkbS5wZGguY3NwMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr0EHCdyTuteryFZ2bdEl+V4OATR/xk8ELthmvlwT/5qubZKwlCWS6yLawgdyCg9Yw737A7q >>>> >>>> >>>> Ge0BPxHv6E+as10NxppEPsn9BOi+TPRIMYNMNNYmO2sce2pvkMkVBqsF7Gn7mF7e5+Bpc7ApnDGP7WLsAjbso8EvLUrqVMTNyiziCSHiNk+/Fi1Om6K5GKzKkqfEDex0RK+kpMswgcaZH >>>> >>>> >>>> hmW3i+y3UxFZsJjOg3R4fJAfC0+My2d1Vx4052+EgWAbSNpSj7zmLGM2+dkmgMo5Li7jjgJe8VsrqOV4L5IgqtGVJ0EOb7EP7gynbVoa74m4XrVwEP8rd/M5RxAnD1JPuwIDAQABoIHRM >>>> >>>> >>>> BoGCSqGSIb3DQEJFDENEwtTZXJ2ZXItQ2VydDCBsgYJKoZIhvcNAQkOMYGkMIGhMA4GA1UdDwEBAAQEAwIE8DB3BgNVHREBAQAEbTBroCwGCisGAQQBgjcUAgOgHgwcbGRhcC9jc3AtaW >>>> >>>> >>>> RtLnBkaC5jc3BAUERILkNTUKA7BgYrBgEFAgKgMTAvoAkbB1BESC5DU1ChIjAgoAMCAQGhGTAXGwRsZGFwGw9jc3AtaWRtLnBkaC5jc3AwFgYDVR0lAQEABAwwCgYIKwYBBQUHAwEwDQY >>>> >>>> >>>> JKoZIhvcNAQELBQADggEBABD/Hwbgf5NJNUYt0+ntMDHiilMFkSaO6ryQ36/pCH1oR+vI+PCeClHewPo0v99h4Z8W8L7CQtDdNBUMl/JVHH5Lz7cBF8A/jXZQ+naV17EEuXncacM8AvYh >>>> >>>> >>>> 5dL2yih+8RpPalEmSgz5rijtbSigfNGrZn0Mh3qOW1kbsz+GDaaT9wLFxvdJyqgdKds2tsp0KzHIMcJuw3cwOfH8zrBRV28XYhMLm0OOhj92uxgax5UPY2VyHP5UOtOnfuduU1ZXa+o8Q >>>> >>>> >>>> IXqX7/HyDSCLGwiPJscAsp9cRzjn4KvqzZDOcdGEjXmCGfrmUiMcuzVyTDR2SdAWrHdbRmXeyVxmiBPzdk=', >>>> principal=u'ldap/csp-idm.pdh.csp at PDH.CSP', add=True): C >>>> ertificateOperationError >>> >>> >>> >>> I think your CA is still not up and running. >>> >>> Things to check: >>> >>> /var/log/pki-ca/catalina.out to be see if there are start up errors. The >>> debug log in the same directory may contain information as well. If you >>> are >>> seeing a bunch of error 32's it means your db is still corrupted. >>> >>> The output of ipa-getcert list. This will tell you what certmonger thinks >>> is >>> wrong. >>> >>> Did you repair the ipaca backend in PKI-IPA? It is different than >>> userRoot. >>> >>> >>> rob >>> >>>> >>>> >>>> On Fri, Mar 16, 2012 at 5:30 PM, Rob Crittenden >>>> ?wrote: >>>>> >>>>> >>>>> Jimmy wrote: >>>>>> >>>>>> >>>>>> >>>>>> I actually shut down IPA to do the export and restarted after I >>>>>> imported. >>>>>> >>>>>> certutil -L -d /etc/httpd/alias >>>>>> Certificate Nickname ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Trust >>>>>> Attributes >>>>>> >>>>>> ?SSL,S/MIME,JAR/XPI >>>>>> Server-Cert ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?u,u,u >>>>>> ABC.XYZIPA CA ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? CT,C,C >>>>>> ipaCert ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?u,u,u >>>>>> Signing-Cert ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? u,u,u >>>>>> >>>>>> certutil -V -u V -n Server-Cert -d /etc/httpd/alias -e -f >>>>>> /etc/httpd/alias/pwdfile.txt >>>>>> certutil: certificate is valid >>>>>> >>>>>> How's that look? >>>>> >>>>> >>>>> >>>>> >>>>> That's what it's supposed to look like. Is Apache logging a failure or >>>>> maybe >>>>> that is coming from dogtag through Apache... >>>>> >>>>> >>>>> rob >>>>> >>>>>> >>>>>> >>>>>> On Fri, Mar 16, 2012 at 4:34 PM, Rob Crittenden >>>>>> ?wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> Jimmy wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ipa-getcert list shows some ugly output - http://fpaste.org/bV2v/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Looks pretty similar to what we've been seeing. The invalid >>>>>>> credentials >>>>>>> means that dogtag can't validate RA agent cert. This was due to the >>>>>>> corrupted database. You'll need to restart the pki-cad process once >>>>>>> the >>>>>>> LDAP >>>>>>> backend is fixed. >>>>>>> >>>>>>> The trust issues are stranger. To show the certs in those databases: >>>>>>> >>>>>>> # certutil -L -d /etc/httpd/alias >>>>>>> >>>>>>> To verify that the cert in there now has all the CA certs it needs: >>>>>>> # certutil -V -u V -n Server-Cert -d /etc/httpd/alias -e -f >>>>>>> /etc/httpd/alias/pwdfile.txt >>>>>>> >>>>>>> rob >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> On Fri, Mar 16, 2012 at 4:05 PM, Jimmy >>>>>>>> ?wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I exported/imported the /var/lib/dirsrv/slapd-PKI-IPA/db/userRoot >>>>>>>>> and >>>>>>>>> that went smoothly but now I see this in /var/log/pki-ca/system: >>>>>>>>> >>>>>>>>> 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] >>>>>>>>> Operation Error - netscape.ldap.LDAPException: error result (32); >>>>>>>>> matchedDN >>>>>>>>> ?= o=ipaca >>>>>>>>> 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] >>>>>>>>> Null >>>>>>>>> response control >>>>>>>>> 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] >>>>>>>>> Operation Error - netscape.ldap.LDAPException: error result (32); >>>>>>>>> matchedDN >>>>>>>>> ?= o=ipaca >>>>>>>>> 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] >>>>>>>>> Null >>>>>>>>> response control >>>>>>>>> 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] >>>>>>>>> Operation Error - netscape.ldap.LDAPException: error result (32); >>>>>>>>> matchedDN >>>>>>>>> ?= o=ipaca >>>>>>>>> 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] >>>>>>>>> Null >>>>>>>>> response control >>>>>>>>> 10358.CRLIssuingPoint-MasterCRL - [08/Mar/2012:04:36:29 UTC] [3] >>>>>>>>> [3] >>>>>>>>> CRLIssuingPoint MasterCRL - Cannot create or store the first CRL in >>>>>>>>> the >>>>>>>>> internaldb. The internaldb could be down. Error LDAP operation >>>>>>>>> failure >>>>>>>>> - cn=MasterCRL,ou=crlIssuingPoints, ou=ca, o=ipaca >>>>>>>>> netscape.ldap.LDAPE >>>>>>>>> xception: error result (32); matchedDN = o=ipaca >>>>>>>>> >>>>>>>>> >>>>>>>>> catalina.out -- http://fpaste.org/oRQd/ >>>>>>>>> >>>>>>>>> ca-debug -- http://fpaste.org/zzFL/ >>>>>>>>> >>>>>>>>> Any ideas? >>>>>>>>> On Fri, Mar 16, 2012 at 2:39 PM, Rob >>>>>>>>> Crittenden >>>>>>>>> ?wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Jimmy wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The ca_audit problem was caused by me accidentally moving the >>>>>>>>>>> directory to a backup location. I was cleaning up the logs to >>>>>>>>>>> make >>>>>>>>>>> reading easier. When I moved the directory back that issue went >>>>>>>>>>> away. >>>>>>>>>>> No changes were made in the NSS database(s) or any other internal >>>>>>>>>>> workings of IPA. This system is used for very basic user >>>>>>>>>>> authentication, DNS, etc. >>>>>>>>>>> >>>>>>>>>>> I can do the ldif export/import for dogtag. Just from comparing >>>>>>>>>>> everything, it looks like the dogtag db is in >>>>>>>>>>> /var/lib/dirsrv/slapd-PKI-IPA/db/userRoot, is that correct? >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The ipaca db >>>>>>>>>> >>>>>>>>>> rob >>>>>>>>>> >>>>>>> >>>>> >>> > From g17jimmy at gmail.com Tue Mar 20 19:18:01 2012 From: g17jimmy at gmail.com (Jimmy) Date: Tue, 20 Mar 2012 15:18:01 -0400 Subject: [Freeipa-users] (no subject) In-Reply-To: References: <4F62554F.1030804@redhat.com> <4F626135.3030402@redhat.com> <4F63575B.6090805@redhat.com> <4F636F7A.4060109@redhat.com> <4F6388E7.9000409@redhat.com> <4F63A3EC.6010205@redhat.com> <4F63B0E5.7030104@redhat.com> <4F679DD9.7090106@redhat.com> <4F68C12C.80103@redhat.com> Message-ID: Here are the http logs: http://fpaste.org/j7kN/ On Tue, Mar 20, 2012 at 3:16 PM, Jimmy wrote: > I was able to do this: > /usr/lib64/dirsrv/slapd-PKI-IPA/db2ldif -n ipaca -a /dbexport/ipaca-output.ldif > /usr/lib64/dirsrv/slapd-PKI-IPA/ldif2db -n ipaca -i /dbexport/ipaca-output.ldif > > The cert still doesn't seem to be renewing, though. Here is the debug > and catalina.out. > > http://fpaste.org/k0Lz/ > http://fpaste.org/UUnE/ > > ?ipa-getcert list shows this for a couple certs in question: > > Request ID '20110913154314': > ? ? ? ?status: MONITORING > ? ? ? ?ca-error: Error setting up ccache for local "host" service > using default keytab. > ? ? ? ?stuck: no > ? ? ? ?key pair storage: > type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS > Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA//pwdfile.txt' > ? ? ? ?certificate: > type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS > Certificate DB' > ? ? ? ?CA: IPA > ? ? ? ?issuer: CN=Certificate Authority,O=ABC.XYZ > ? ? ? ?subject: CN=xyz-ipa.abc.xyz,O=ABC.XYZ > ? ? ? ?expires: 2012-03-11 15:43:13 UTC > ? ? ? ?eku: id-kp-serverAuth > ? ? ? ?command: > ? ? ? ?track: yes > ? ? ? ?auto-renew: yes > Request ID '20110913154337': > ? ? ? ?status: MONITORING > ? ? ? ?ca-error: Error setting up ccache for local "host" service > using default keytab. > ? ? ? ?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=ABC.XYZ > ? ? ? ?subject: CN=xyz-ipa.abc.xyz,O=ABC.XYZ > ? ? ? ?expires: 2012-03-11 15:43:37 UTC > ? ? ? ?eku: id-kp-serverAuth > ? ? ? ?command: > ? ? ? ?track: yes > ? ? ? ?auto-renew: yes > > > > > On Tue, Mar 20, 2012 at 1:41 PM, Rob Crittenden wrote: >> Jimmy wrote: >>> >>> When I try to export the db I get this: >>> >>> ?/var/lib/dirsrv/scripts-ABC-XYZ/db2ldif -n ipaca -a >>> /dbexport/ipaca-output.ldif >>> Exported ldif file: /dbexport/ipaca-output.ldif >>> [03/Mar/2012:17:27:25 +0000] - ERROR: Could not find backend 'ipaca'] >> >> >> The CA uses a different instance of 389-ds. You need to run the scripts >> specific to that instance. dogtag sets things up slightly differently, you >> want something like: >> >> /usr/lib/dirsrv/slapd-PKI-IPA/db2ldif -n ipaca -a >> /dbexport/ipaca-output.ldif >> >> >>> When I start IPA as it is now these are the logs I get: >>> >>> debug- http://fpaste.org/ItuZ/ >>> catalina.out- http://fpaste.org/tSyQ/ >> >> >> Yes, as I suspected it isn't finding any of its data which is why the >> certificate renewal is failing. >> >> rob >> >> >>> >>> -Jimmy >>> >>> On Mon, Mar 19, 2012 at 4:58 PM, Rob Crittenden >>> ?wrote: >>>> >>>> Jimmy wrote: >>>>> >>>>> >>>>> This is all I see in the /var/log/httpd/error_log file. This issue has >>>>> become critical. The server has been down a week and I have no idea >>>>> why certmonger broke and don't seem to have any indication of how to >>>>> fix it. What would be the best route besides chasing down this >>>>> certmonger issue? Could I export all of my configuration/users/etc, >>>>> install a completely new IPA and import my config? >>>>> >>>>> [Sat Mar 03 00:05:27 2012] [error] ipa: INFO: sslget >>>>> 'https://csp-idm.pdh.csp:443/ca/agent/ca/displayBySerial' >>>>> [Sat Mar 03 00:05:28 2012] [error] ipa: INFO: >>>>> host/csp-idm.pdh.csp at PDH.CSP: >>>>> cert_request(u'MIIDQzCCAisCAQAwLDEQMA4GA1UEChMHUERILkNTUDEYMBYGA1 >>>>> >>>>> >>>>> UEAxMPY3NwLWlkbS5wZGguY3NwMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr0EHCdyTuteryFZ2bdEl+V4OATR/xk8ELthmvlwT/5qubZKwlCWS6yLawgdyCg9Yw737A7q >>>>> >>>>> >>>>> Ge0BPxHv6E+as10NxppEPsn9BOi+TPRIMYNMNNYmO2sce2pvkMkVBqsF7Gn7mF7e5+Bpc7ApnDGP7WLsAjbso8EvLUrqVMTNyiziCSHiNk+/Fi1Om6K5GKzKkqfEDex0RK+kpMswgcaZH >>>>> >>>>> >>>>> hmW3i+y3UxFZsJjOg3R4fJAfC0+My2d1Vx4052+EgWAbSNpSj7zmLGM2+dkmgMo5Li7jjgJe8VsrqOV4L5IgqtGVJ0EOb7EP7gynbVoa74m4XrVwEP8rd/M5RxAnD1JPuwIDAQABoIHRM >>>>> >>>>> >>>>> BoGCSqGSIb3DQEJFDENEwtTZXJ2ZXItQ2VydDCBsgYJKoZIhvcNAQkOMYGkMIGhMA4GA1UdDwEBAAQEAwIE8DB3BgNVHREBAQAEbTBroCwGCisGAQQBgjcUAgOgHgwcbGRhcC9jc3AtaW >>>>> >>>>> >>>>> RtLnBkaC5jc3BAUERILkNTUKA7BgYrBgEFAgKgMTAvoAkbB1BESC5DU1ChIjAgoAMCAQGhGTAXGwRsZGFwGw9jc3AtaWRtLnBkaC5jc3AwFgYDVR0lAQEABAwwCgYIKwYBBQUHAwEwDQY >>>>> >>>>> >>>>> JKoZIhvcNAQELBQADggEBABD/Hwbgf5NJNUYt0+ntMDHiilMFkSaO6ryQ36/pCH1oR+vI+PCeClHewPo0v99h4Z8W8L7CQtDdNBUMl/JVHH5Lz7cBF8A/jXZQ+naV17EEuXncacM8AvYh >>>>> >>>>> >>>>> 5dL2yih+8RpPalEmSgz5rijtbSigfNGrZn0Mh3qOW1kbsz+GDaaT9wLFxvdJyqgdKds2tsp0KzHIMcJuw3cwOfH8zrBRV28XYhMLm0OOhj92uxgax5UPY2VyHP5UOtOnfuduU1ZXa+o8Q >>>>> >>>>> >>>>> IXqX7/HyDSCLGwiPJscAsp9cRzjn4KvqzZDOcdGEjXmCGfrmUiMcuzVyTDR2SdAWrHdbRmXeyVxmiBPzdk=', >>>>> principal=u'ldap/csp-idm.pdh.csp at PDH.CSP', add=True): C >>>>> ertificateOperationError >>>> >>>> >>>> >>>> I think your CA is still not up and running. >>>> >>>> Things to check: >>>> >>>> /var/log/pki-ca/catalina.out to be see if there are start up errors. The >>>> debug log in the same directory may contain information as well. If you >>>> are >>>> seeing a bunch of error 32's it means your db is still corrupted. >>>> >>>> The output of ipa-getcert list. This will tell you what certmonger thinks >>>> is >>>> wrong. >>>> >>>> Did you repair the ipaca backend in PKI-IPA? It is different than >>>> userRoot. >>>> >>>> >>>> rob >>>> >>>>> >>>>> >>>>> On Fri, Mar 16, 2012 at 5:30 PM, Rob Crittenden >>>>> ?wrote: >>>>>> >>>>>> >>>>>> Jimmy wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> I actually shut down IPA to do the export and restarted after I >>>>>>> imported. >>>>>>> >>>>>>> certutil -L -d /etc/httpd/alias >>>>>>> Certificate Nickname ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Trust >>>>>>> Attributes >>>>>>> >>>>>>> ?SSL,S/MIME,JAR/XPI >>>>>>> Server-Cert ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?u,u,u >>>>>>> ABC.XYZIPA CA ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? CT,C,C >>>>>>> ipaCert ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?u,u,u >>>>>>> Signing-Cert ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? u,u,u >>>>>>> >>>>>>> certutil -V -u V -n Server-Cert -d /etc/httpd/alias -e -f >>>>>>> /etc/httpd/alias/pwdfile.txt >>>>>>> certutil: certificate is valid >>>>>>> >>>>>>> How's that look? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> That's what it's supposed to look like. Is Apache logging a failure or >>>>>> maybe >>>>>> that is coming from dogtag through Apache... >>>>>> >>>>>> >>>>>> rob >>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, Mar 16, 2012 at 4:34 PM, Rob Crittenden >>>>>>> ?wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Jimmy wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> ipa-getcert list shows some ugly output - http://fpaste.org/bV2v/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Looks pretty similar to what we've been seeing. The invalid >>>>>>>> credentials >>>>>>>> means that dogtag can't validate RA agent cert. This was due to the >>>>>>>> corrupted database. You'll need to restart the pki-cad process once >>>>>>>> the >>>>>>>> LDAP >>>>>>>> backend is fixed. >>>>>>>> >>>>>>>> The trust issues are stranger. To show the certs in those databases: >>>>>>>> >>>>>>>> # certutil -L -d /etc/httpd/alias >>>>>>>> >>>>>>>> To verify that the cert in there now has all the CA certs it needs: >>>>>>>> # certutil -V -u V -n Server-Cert -d /etc/httpd/alias -e -f >>>>>>>> /etc/httpd/alias/pwdfile.txt >>>>>>>> >>>>>>>> rob >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> On Fri, Mar 16, 2012 at 4:05 PM, Jimmy >>>>>>>>> ?wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I exported/imported the /var/lib/dirsrv/slapd-PKI-IPA/db/userRoot >>>>>>>>>> and >>>>>>>>>> that went smoothly but now I see this in /var/log/pki-ca/system: >>>>>>>>>> >>>>>>>>>> 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] >>>>>>>>>> Operation Error - netscape.ldap.LDAPException: error result (32); >>>>>>>>>> matchedDN >>>>>>>>>> ?= o=ipaca >>>>>>>>>> 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] >>>>>>>>>> Null >>>>>>>>>> response control >>>>>>>>>> 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] >>>>>>>>>> Operation Error - netscape.ldap.LDAPException: error result (32); >>>>>>>>>> matchedDN >>>>>>>>>> ?= o=ipaca >>>>>>>>>> 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] >>>>>>>>>> Null >>>>>>>>>> response control >>>>>>>>>> 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] >>>>>>>>>> Operation Error - netscape.ldap.LDAPException: error result (32); >>>>>>>>>> matchedDN >>>>>>>>>> ?= o=ipaca >>>>>>>>>> 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] >>>>>>>>>> Null >>>>>>>>>> response control >>>>>>>>>> 10358.CRLIssuingPoint-MasterCRL - [08/Mar/2012:04:36:29 UTC] [3] >>>>>>>>>> [3] >>>>>>>>>> CRLIssuingPoint MasterCRL - Cannot create or store the first CRL in >>>>>>>>>> the >>>>>>>>>> internaldb. The internaldb could be down. Error LDAP operation >>>>>>>>>> failure >>>>>>>>>> - cn=MasterCRL,ou=crlIssuingPoints, ou=ca, o=ipaca >>>>>>>>>> netscape.ldap.LDAPE >>>>>>>>>> xception: error result (32); matchedDN = o=ipaca >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> catalina.out -- http://fpaste.org/oRQd/ >>>>>>>>>> >>>>>>>>>> ca-debug -- http://fpaste.org/zzFL/ >>>>>>>>>> >>>>>>>>>> Any ideas? >>>>>>>>>> On Fri, Mar 16, 2012 at 2:39 PM, Rob >>>>>>>>>> Crittenden >>>>>>>>>> ?wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Jimmy wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> The ca_audit problem was caused by me accidentally moving the >>>>>>>>>>>> directory to a backup location. I was cleaning up the logs to >>>>>>>>>>>> make >>>>>>>>>>>> reading easier. When I moved the directory back that issue went >>>>>>>>>>>> away. >>>>>>>>>>>> No changes were made in the NSS database(s) or any other internal >>>>>>>>>>>> workings of IPA. This system is used for very basic user >>>>>>>>>>>> authentication, DNS, etc. >>>>>>>>>>>> >>>>>>>>>>>> I can do the ldif export/import for dogtag. Just from comparing >>>>>>>>>>>> everything, it looks like the dogtag db is in >>>>>>>>>>>> /var/lib/dirsrv/slapd-PKI-IPA/db/userRoot, is that correct? >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The ipaca db >>>>>>>>>>> >>>>>>>>>>> rob >>>>>>>>>>> >>>>>>>> >>>>>> >>>> >> From g17jimmy at gmail.com Tue Mar 20 19:35:09 2012 From: g17jimmy at gmail.com (Jimmy) Date: Tue, 20 Mar 2012 15:35:09 -0400 Subject: [Freeipa-users] (no subject) In-Reply-To: <4F68D941.6070307@redhat.com> References: <4F626135.3030402@redhat.com> <4F63575B.6090805@redhat.com> <4F636F7A.4060109@redhat.com> <4F6388E7.9000409@redhat.com> <4F63A3EC.6010205@redhat.com> <4F63B0E5.7030104@redhat.com> <4F679DD9.7090106@redhat.com> <4F68C12C.80103@redhat.com> <4F68D941.6070307@redhat.com> Message-ID: ipa cert-show 1== Certificate: MIIDhTCCAm2gAwIBAgIBATANBgkqhkiG9w0BAQsFADAyMRAwDgYDVQQKEwdQREgu Q1NQMR4wHAYDVQQDExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMTEwOTEzMTU0 MTE4WhcNMTkwOTEzMTU0MTE4WjAyMRAwDgYDVQQKEwdQREguQ1NQMR4wHAYDVQQD ExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDRPzyFQbAIgnNLGZQRoMVuHGLIBqANVpJOXiE28PlwVczQ5F14FE5e d2QZ6CYtY/1RpWph/SaUHqRKW2C2NTlx3Rw6q+aaLzFqqSp4cC9vNwfURT32xn64 wSuHsVPakBp6xDF5QfJTgxXEcO/eJt9KiyIDtOEmk3TBzmalNtVejNe33OfwBx6s LmVKjH49wUuUGQBvk6/di5vhQ8soquWMRKdZFsTBfepp4BSvscweY0nNk7+iMOEE ESt0JOhvrQOzEeopqVf7GcDKLEhCC4BRwuGZ6GzWl3w9OiiriH8aLdEGeLuBjYq1 wa/z6pCah4dNmAmV/nf5xocH84DdxRJJAgMBAAGjgaUwgaIwHwYDVR0jBBgwFoAU PiI4ye3VbGZeR6iy37xgdCLgUNcwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8E BAMCAcYwHQYDVR0OBBYEFD4iOMnt1WxmXkeost+8YHQi4FDXMD8GCCsGAQUFBwEB BDMwMTAvBggrBgEFBQcwAYYjaHR0cDovL2NzcC1pZG0ucGRoLmNzcDo5MTgwL2Nh L29jc3AwDQYJKoZIhvcNAQELBQADggEBALsg/ivFOv4VmydSZ2q93TwQUtV49Gp+ AJcrCu8aVpd2q9LX2yNxq2EXSZq4+/Afml6zGCSMZ6w/EV2dpwHo4BrVg5HAIWe9 k6zekjDhVGVYRtO09B8PTWoRvt5lgQf4zMoiaVwS8+uE8CWF3Y24CqnAeW4z9vFr EmCkVEp69xaLfbTBLt1bzyIxIlq4mgb8oE8NDVr2Qo3cdwT4qGNPLEHvb9vCwySN R3BNarw+LB0GB5g5XkEIXPmgKmxoJuQ3nW578bPxXRvUJ19Yg2/WObAyrfoVL/sc iEJDnJKWtV/kcN68LhOIkC77w41RII43YxJFQva9NQVY4uT1CApNcPk= Subject: CN=Certificate Authority,O=ABC.XYZ Issuer: CN=Certificate Authority,O=ABC.XYZ Not Before: Tue Sep 13 15:41:18 2011 UTC Not After: Fri Sep 13 15:41:18 2019 UTC Fingerprint (MD5): 05:d4:89:49:6b:03:0e:9b:06:14:a0:0a:e2:32:dc:e1 Fingerprint (SHA1): c4:b7:9f:07:df:5a:9e:36:a6:c3:f4:18:c7:77:1a:29:86:30:41:4f Serial number: 1 kvno host/xyz-ipa.abc.xyz -k /etc/krb5.keytab host/xyz-ipa.abc.xyz at ABC.XYZ: kvno = 2, keytab entry valid I can do a kinit as the host principal with the keytab /etc/krb5.keytab From rmeggins at redhat.com Tue Mar 20 19:36:39 2012 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 20 Mar 2012 13:36:39 -0600 Subject: [Freeipa-users] (no subject) In-Reply-To: References: <4F63575B.6090805@redhat.com> <4F636F7A.4060109@redhat.com> <4F6388E7.9000409@redhat.com> <4F63A3EC.6010205@redhat.com> <4F63B0E5.7030104@redhat.com> <4F679DD9.7090106@redhat.com> <4F68C12C.80103@redhat.com> Message-ID: <4F68DC47.5000600@redhat.com> On 03/20/2012 01:16 PM, Jimmy wrote: > I was able to do this: > /usr/lib64/dirsrv/slapd-PKI-IPA/db2ldif -n ipaca -a /dbexport/ipaca-output.ldif > /usr/lib64/dirsrv/slapd-PKI-IPA/ldif2db -n ipaca -i /dbexport/ipaca-output.ldif ok - let's make sure this step worked - any errors in /var/log/dirsrv/slapd-PKI-IPA/errors? > > The cert still doesn't seem to be renewing, though. Here is the debug > and catalina.out. What about /var/log/dirsrv/slapd-PKI-IPA/access? > > http://fpaste.org/k0Lz/ > http://fpaste.org/UUnE/ > > ipa-getcert list shows this for a couple certs in question: > > Request ID '20110913154314': > status: MONITORING > ca-error: Error setting up ccache for local "host" service > using default keytab. > stuck: no > key pair storage: > type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS > Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA//pwdfile.txt' > certificate: > type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS > Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=ABC.XYZ > subject: CN=xyz-ipa.abc.xyz,O=ABC.XYZ > expires: 2012-03-11 15:43:13 UTC > eku: id-kp-serverAuth > command: > track: yes > auto-renew: yes > Request ID '20110913154337': > status: MONITORING > ca-error: Error setting up ccache for local "host" service > using default keytab. > 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=ABC.XYZ > subject: CN=xyz-ipa.abc.xyz,O=ABC.XYZ > expires: 2012-03-11 15:43:37 UTC > eku: id-kp-serverAuth > command: > track: yes > auto-renew: yes > > > > > On Tue, Mar 20, 2012 at 1:41 PM, Rob Crittenden wrote: >> Jimmy wrote: >>> When I try to export the db I get this: >>> >>> /var/lib/dirsrv/scripts-ABC-XYZ/db2ldif -n ipaca -a >>> /dbexport/ipaca-output.ldif >>> Exported ldif file: /dbexport/ipaca-output.ldif >>> [03/Mar/2012:17:27:25 +0000] - ERROR: Could not find backend 'ipaca'] >> >> The CA uses a different instance of 389-ds. You need to run the scripts >> specific to that instance. dogtag sets things up slightly differently, you >> want something like: >> >> /usr/lib/dirsrv/slapd-PKI-IPA/db2ldif -n ipaca -a >> /dbexport/ipaca-output.ldif >> >> >>> When I start IPA as it is now these are the logs I get: >>> >>> debug- http://fpaste.org/ItuZ/ >>> catalina.out- http://fpaste.org/tSyQ/ >> >> Yes, as I suspected it isn't finding any of its data which is why the >> certificate renewal is failing. >> >> rob >> >> >>> -Jimmy >>> >>> On Mon, Mar 19, 2012 at 4:58 PM, Rob Crittenden >>> wrote: >>>> Jimmy wrote: >>>>> >>>>> This is all I see in the /var/log/httpd/error_log file. This issue has >>>>> become critical. The server has been down a week and I have no idea >>>>> why certmonger broke and don't seem to have any indication of how to >>>>> fix it. What would be the best route besides chasing down this >>>>> certmonger issue? Could I export all of my configuration/users/etc, >>>>> install a completely new IPA and import my config? >>>>> >>>>> [Sat Mar 03 00:05:27 2012] [error] ipa: INFO: sslget >>>>> 'https://csp-idm.pdh.csp:443/ca/agent/ca/displayBySerial' >>>>> [Sat Mar 03 00:05:28 2012] [error] ipa: INFO: >>>>> host/csp-idm.pdh.csp at PDH.CSP: >>>>> cert_request(u'MIIDQzCCAisCAQAwLDEQMA4GA1UEChMHUERILkNTUDEYMBYGA1 >>>>> >>>>> >>>>> UEAxMPY3NwLWlkbS5wZGguY3NwMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr0EHCdyTuteryFZ2bdEl+V4OATR/xk8ELthmvlwT/5qubZKwlCWS6yLawgdyCg9Yw737A7q >>>>> >>>>> >>>>> Ge0BPxHv6E+as10NxppEPsn9BOi+TPRIMYNMNNYmO2sce2pvkMkVBqsF7Gn7mF7e5+Bpc7ApnDGP7WLsAjbso8EvLUrqVMTNyiziCSHiNk+/Fi1Om6K5GKzKkqfEDex0RK+kpMswgcaZH >>>>> >>>>> >>>>> hmW3i+y3UxFZsJjOg3R4fJAfC0+My2d1Vx4052+EgWAbSNpSj7zmLGM2+dkmgMo5Li7jjgJe8VsrqOV4L5IgqtGVJ0EOb7EP7gynbVoa74m4XrVwEP8rd/M5RxAnD1JPuwIDAQABoIHRM >>>>> >>>>> >>>>> BoGCSqGSIb3DQEJFDENEwtTZXJ2ZXItQ2VydDCBsgYJKoZIhvcNAQkOMYGkMIGhMA4GA1UdDwEBAAQEAwIE8DB3BgNVHREBAQAEbTBroCwGCisGAQQBgjcUAgOgHgwcbGRhcC9jc3AtaW >>>>> >>>>> >>>>> RtLnBkaC5jc3BAUERILkNTUKA7BgYrBgEFAgKgMTAvoAkbB1BESC5DU1ChIjAgoAMCAQGhGTAXGwRsZGFwGw9jc3AtaWRtLnBkaC5jc3AwFgYDVR0lAQEABAwwCgYIKwYBBQUHAwEwDQY >>>>> >>>>> >>>>> JKoZIhvcNAQELBQADggEBABD/Hwbgf5NJNUYt0+ntMDHiilMFkSaO6ryQ36/pCH1oR+vI+PCeClHewPo0v99h4Z8W8L7CQtDdNBUMl/JVHH5Lz7cBF8A/jXZQ+naV17EEuXncacM8AvYh >>>>> >>>>> >>>>> 5dL2yih+8RpPalEmSgz5rijtbSigfNGrZn0Mh3qOW1kbsz+GDaaT9wLFxvdJyqgdKds2tsp0KzHIMcJuw3cwOfH8zrBRV28XYhMLm0OOhj92uxgax5UPY2VyHP5UOtOnfuduU1ZXa+o8Q >>>>> >>>>> >>>>> IXqX7/HyDSCLGwiPJscAsp9cRzjn4KvqzZDOcdGEjXmCGfrmUiMcuzVyTDR2SdAWrHdbRmXeyVxmiBPzdk=', >>>>> principal=u'ldap/csp-idm.pdh.csp at PDH.CSP', add=True): C >>>>> ertificateOperationError >>>> >>>> >>>> I think your CA is still not up and running. >>>> >>>> Things to check: >>>> >>>> /var/log/pki-ca/catalina.out to be see if there are start up errors. The >>>> debug log in the same directory may contain information as well. If you >>>> are >>>> seeing a bunch of error 32's it means your db is still corrupted. >>>> >>>> The output of ipa-getcert list. This will tell you what certmonger thinks >>>> is >>>> wrong. >>>> >>>> Did you repair the ipaca backend in PKI-IPA? It is different than >>>> userRoot. >>>> >>>> >>>> rob >>>> >>>>> >>>>> On Fri, Mar 16, 2012 at 5:30 PM, Rob Crittenden >>>>> wrote: >>>>>> >>>>>> Jimmy wrote: >>>>>>> >>>>>>> >>>>>>> I actually shut down IPA to do the export and restarted after I >>>>>>> imported. >>>>>>> >>>>>>> certutil -L -d /etc/httpd/alias >>>>>>> Certificate Nickname Trust >>>>>>> Attributes >>>>>>> >>>>>>> SSL,S/MIME,JAR/XPI >>>>>>> Server-Cert u,u,u >>>>>>> ABC.XYZIPA CA CT,C,C >>>>>>> ipaCert u,u,u >>>>>>> Signing-Cert u,u,u >>>>>>> >>>>>>> certutil -V -u V -n Server-Cert -d /etc/httpd/alias -e -f >>>>>>> /etc/httpd/alias/pwdfile.txt >>>>>>> certutil: certificate is valid >>>>>>> >>>>>>> How's that look? >>>>>> >>>>>> >>>>>> >>>>>> That's what it's supposed to look like. Is Apache logging a failure or >>>>>> maybe >>>>>> that is coming from dogtag through Apache... >>>>>> >>>>>> >>>>>> rob >>>>>> >>>>>>> >>>>>>> On Fri, Mar 16, 2012 at 4:34 PM, Rob Crittenden >>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> Jimmy wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> ipa-getcert list shows some ugly output - http://fpaste.org/bV2v/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Looks pretty similar to what we've been seeing. The invalid >>>>>>>> credentials >>>>>>>> means that dogtag can't validate RA agent cert. This was due to the >>>>>>>> corrupted database. You'll need to restart the pki-cad process once >>>>>>>> the >>>>>>>> LDAP >>>>>>>> backend is fixed. >>>>>>>> >>>>>>>> The trust issues are stranger. To show the certs in those databases: >>>>>>>> >>>>>>>> # certutil -L -d /etc/httpd/alias >>>>>>>> >>>>>>>> To verify that the cert in there now has all the CA certs it needs: >>>>>>>> # certutil -V -u V -n Server-Cert -d /etc/httpd/alias -e -f >>>>>>>> /etc/httpd/alias/pwdfile.txt >>>>>>>> >>>>>>>> rob >>>>>>>> >>>>>>>> >>>>>>>>> On Fri, Mar 16, 2012 at 4:05 PM, Jimmy >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I exported/imported the /var/lib/dirsrv/slapd-PKI-IPA/db/userRoot >>>>>>>>>> and >>>>>>>>>> that went smoothly but now I see this in /var/log/pki-ca/system: >>>>>>>>>> >>>>>>>>>> 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] >>>>>>>>>> Operation Error - netscape.ldap.LDAPException: error result (32); >>>>>>>>>> matchedDN >>>>>>>>>> = o=ipaca >>>>>>>>>> 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] >>>>>>>>>> Null >>>>>>>>>> response control >>>>>>>>>> 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] >>>>>>>>>> Operation Error - netscape.ldap.LDAPException: error result (32); >>>>>>>>>> matchedDN >>>>>>>>>> = o=ipaca >>>>>>>>>> 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] >>>>>>>>>> Null >>>>>>>>>> response control >>>>>>>>>> 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] >>>>>>>>>> Operation Error - netscape.ldap.LDAPException: error result (32); >>>>>>>>>> matchedDN >>>>>>>>>> = o=ipaca >>>>>>>>>> 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] >>>>>>>>>> Null >>>>>>>>>> response control >>>>>>>>>> 10358.CRLIssuingPoint-MasterCRL - [08/Mar/2012:04:36:29 UTC] [3] >>>>>>>>>> [3] >>>>>>>>>> CRLIssuingPoint MasterCRL - Cannot create or store the first CRL in >>>>>>>>>> the >>>>>>>>>> internaldb. The internaldb could be down. Error LDAP operation >>>>>>>>>> failure >>>>>>>>>> - cn=MasterCRL,ou=crlIssuingPoints, ou=ca, o=ipaca >>>>>>>>>> netscape.ldap.LDAPE >>>>>>>>>> xception: error result (32); matchedDN = o=ipaca >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> catalina.out -- http://fpaste.org/oRQd/ >>>>>>>>>> >>>>>>>>>> ca-debug -- http://fpaste.org/zzFL/ >>>>>>>>>> >>>>>>>>>> Any ideas? >>>>>>>>>> On Fri, Mar 16, 2012 at 2:39 PM, Rob >>>>>>>>>> Crittenden >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Jimmy wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> The ca_audit problem was caused by me accidentally moving the >>>>>>>>>>>> directory to a backup location. I was cleaning up the logs to >>>>>>>>>>>> make >>>>>>>>>>>> reading easier. When I moved the directory back that issue went >>>>>>>>>>>> away. >>>>>>>>>>>> No changes were made in the NSS database(s) or any other internal >>>>>>>>>>>> workings of IPA. This system is used for very basic user >>>>>>>>>>>> authentication, DNS, etc. >>>>>>>>>>>> >>>>>>>>>>>> I can do the ldif export/import for dogtag. Just from comparing >>>>>>>>>>>> everything, it looks like the dogtag db is in >>>>>>>>>>>> /var/lib/dirsrv/slapd-PKI-IPA/db/userRoot, is that correct? >>>>>>>>>>>> >>>>>>>>>>> The ipaca db >>>>>>>>>>> >>>>>>>>>>> rob >>>>>>>>>>> > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From rcritten at redhat.com Tue Mar 20 19:40:13 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 20 Mar 2012 15:40:13 -0400 Subject: [Freeipa-users] (no subject) In-Reply-To: References: <4F63575B.6090805@redhat.com> <4F636F7A.4060109@redhat.com> <4F6388E7.9000409@redhat.com> <4F63A3EC.6010205@redhat.com> <4F63B0E5.7030104@redhat.com> <4F679DD9.7090106@redhat.com> <4F68C12C.80103@redhat.com> <4F68D941.6070307@redhat.com> Message-ID: <4F68DD1D.7010407@redhat.com> Jimmy wrote: > ipa cert-show 1== > > Certificate: MIIDhTCCAm2gAwIBAgIBATANBgkqhkiG9w0BAQsFADAyMRAwDgYDVQQKEwdQREgu > Q1NQMR4wHAYDVQQDExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMTEwOTEzMTU0 > MTE4WhcNMTkwOTEzMTU0MTE4WjAyMRAwDgYDVQQKEwdQREguQ1NQMR4wHAYDVQQD > ExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw > ggEKAoIBAQDRPzyFQbAIgnNLGZQRoMVuHGLIBqANVpJOXiE28PlwVczQ5F14FE5e > d2QZ6CYtY/1RpWph/SaUHqRKW2C2NTlx3Rw6q+aaLzFqqSp4cC9vNwfURT32xn64 > wSuHsVPakBp6xDF5QfJTgxXEcO/eJt9KiyIDtOEmk3TBzmalNtVejNe33OfwBx6s > LmVKjH49wUuUGQBvk6/di5vhQ8soquWMRKdZFsTBfepp4BSvscweY0nNk7+iMOEE > ESt0JOhvrQOzEeopqVf7GcDKLEhCC4BRwuGZ6GzWl3w9OiiriH8aLdEGeLuBjYq1 > wa/z6pCah4dNmAmV/nf5xocH84DdxRJJAgMBAAGjgaUwgaIwHwYDVR0jBBgwFoAU > PiI4ye3VbGZeR6iy37xgdCLgUNcwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8E > BAMCAcYwHQYDVR0OBBYEFD4iOMnt1WxmXkeost+8YHQi4FDXMD8GCCsGAQUFBwEB > BDMwMTAvBggrBgEFBQcwAYYjaHR0cDovL2NzcC1pZG0ucGRoLmNzcDo5MTgwL2Nh > L29jc3AwDQYJKoZIhvcNAQELBQADggEBALsg/ivFOv4VmydSZ2q93TwQUtV49Gp+ > AJcrCu8aVpd2q9LX2yNxq2EXSZq4+/Afml6zGCSMZ6w/EV2dpwHo4BrVg5HAIWe9 > k6zekjDhVGVYRtO09B8PTWoRvt5lgQf4zMoiaVwS8+uE8CWF3Y24CqnAeW4z9vFr > EmCkVEp69xaLfbTBLt1bzyIxIlq4mgb8oE8NDVr2Qo3cdwT4qGNPLEHvb9vCwySN > R3BNarw+LB0GB5g5XkEIXPmgKmxoJuQ3nW578bPxXRvUJ19Yg2/WObAyrfoVL/sc > iEJDnJKWtV/kcN68LhOIkC77w41RII43YxJFQva9NQVY4uT1CApNcPk= > Subject: CN=Certificate Authority,O=ABC.XYZ > Issuer: CN=Certificate Authority,O=ABC.XYZ > Not Before: Tue Sep 13 15:41:18 2011 UTC > Not After: Fri Sep 13 15:41:18 2019 UTC > Fingerprint (MD5): 05:d4:89:49:6b:03:0e:9b:06:14:a0:0a:e2:32:dc:e1 > Fingerprint (SHA1): > c4:b7:9f:07:df:5a:9e:36:a6:c3:f4:18:c7:77:1a:29:86:30:41:4f > Serial number: 1 > > kvno host/xyz-ipa.abc.xyz -k /etc/krb5.keytab > host/xyz-ipa.abc.xyz at ABC.XYZ: kvno = 2, keytab entry valid > > I can do a kinit as the host principal with the keytab /etc/krb5.keytab Can you make sure the system hostname is right? Check the output of /bin/hostname, /etc/hosts and DNS. You might try restarting the certmonger service. rob From g17jimmy at gmail.com Tue Mar 20 20:10:19 2012 From: g17jimmy at gmail.com (Jimmy) Date: Tue, 20 Mar 2012 16:10:19 -0400 Subject: [Freeipa-users] (no subject) In-Reply-To: <4F68DD1D.7010407@redhat.com> References: <4F63575B.6090805@redhat.com> <4F636F7A.4060109@redhat.com> <4F6388E7.9000409@redhat.com> <4F63A3EC.6010205@redhat.com> <4F63B0E5.7030104@redhat.com> <4F679DD9.7090106@redhat.com> <4F68C12C.80103@redhat.com> <4F68D941.6070307@redhat.com> <4F68DD1D.7010407@redhat.com> Message-ID: I restarted certmonger and it seems to be working. Is there some way to change the renewal interval so we can simulate this in the lab? I'd like to see it go through a number of renewals to make sure we don't keep having this problem. From nalin at redhat.com Tue Mar 20 20:52:42 2012 From: nalin at redhat.com (Nalin Dahyabhai) Date: Tue, 20 Mar 2012 16:52:42 -0400 Subject: [Freeipa-users] (no subject) In-Reply-To: References: <4F63B0E5.7030104@redhat.com> <4F679DD9.7090106@redhat.com> <4F68C12C.80103@redhat.com> <4F68D941.6070307@redhat.com> <4F68DD1D.7010407@redhat.com> Message-ID: <20120320205242.GC2124@redhat.com> On Tue, Mar 20, 2012 at 04:10:19PM -0400, Jimmy wrote: > I restarted certmonger and it seems to be working. Is there some way > to change the renewal interval so we can simulate this in the lab? I'd > like to see it go through a number of renewals to make sure we don't > keep having this problem. Attempts to re-enroll are triggered as the not-valid-after date approaches and you cross a threshold time-left value. The default ("2419200, 604800, 259200, 172800, 86400", which works out to 28, 7, 3, 2, and 1 day, when you convert from seconds to days) can be modified by setting the "ttls" value in the [defaults] section of /etc/certmonger/certmonger.conf. To avoid going nuts, the daemon will actually hold off on certificates with a not-before value that's not at least an hour in the past, so adding a really high "ttls" value (say, longer than the certificate's entire validity period) should force frequent re-enrollments, though I haven't done this myself. HTH, Nalin From rcritten at redhat.com Tue Mar 20 21:20:39 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 20 Mar 2012 17:20:39 -0400 Subject: [Freeipa-users] (no subject) In-Reply-To: References: <4F636F7A.4060109@redhat.com> <4F6388E7.9000409@redhat.com> <4F63A3EC.6010205@redhat.com> <4F63B0E5.7030104@redhat.com> <4F679DD9.7090106@redhat.com> <4F68C12C.80103@redhat.com> <4F68D941.6070307@redhat.com> <4F68DD1D.7010407@redhat.com> Message-ID: <4F68F4A7.7030305@redhat.com> Jimmy wrote: > I restarted certmonger and it seems to be working. Is there some way > to change the renewal interval so we can simulate this in the lab? I'd > like to see it go through a number of renewals to make sure we don't > keep having this problem. Glad you are up and running again. You can control the interval by tuning knobs in certmonger.conf(5). You want to modify ttls. rob From g17jimmy at gmail.com Tue Mar 20 21:22:57 2012 From: g17jimmy at gmail.com (Jimmy) Date: Tue, 20 Mar 2012 17:22:57 -0400 Subject: [Freeipa-users] (no subject) In-Reply-To: <4F68F4A7.7030305@redhat.com> References: <4F636F7A.4060109@redhat.com> <4F6388E7.9000409@redhat.com> <4F63A3EC.6010205@redhat.com> <4F63B0E5.7030104@redhat.com> <4F679DD9.7090106@redhat.com> <4F68C12C.80103@redhat.com> <4F68D941.6070307@redhat.com> <4F68DD1D.7010407@redhat.com> <4F68F4A7.7030305@redhat.com> Message-ID: Cool thanks for the awesome help, y'all. On Tue, Mar 20, 2012 at 5:20 PM, Rob Crittenden wrote: > Jimmy wrote: >> >> I restarted certmonger and it seems to be working. Is there some way >> to change the renewal interval so we can simulate this in the lab? I'd >> like to see it go through a number of renewals to make sure we don't >> keep having this problem. > > > Glad you are up and running again. You can control the interval by tuning > knobs in certmonger.conf(5). You want to modify ttls. > > rob From pspacek at redhat.com Wed Mar 21 08:43:59 2012 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 21 Mar 2012 09:43:59 +0100 Subject: [Freeipa-users] groups migration problem In-Reply-To: <4F68CAED.5010509@redhat.com> References: <4F68CAED.5010509@redhat.com> Message-ID: <4F6994CF.4020705@redhat.com> On 03/20/2012 07:22 PM, Rob Crittenden wrote: > Maciej Sawicki wrote: >> Hi, >> I haven't manage to migrate ldap groups (in free ipa panel I see that >> users are migrated) >> #ipa migrate-ds ldap://192.168.1.125:389 >> --bind-dn="cn=admin,dc=polidea,dc=pl" >> --group-container='ou=groups,dc=polidea,dc=pl' >> #ipa: ERROR: Container for group not found >> >> My old ldap setup: >> https://skitch.com/viroos/8miq5/ldap-ou-groups-dc-polidea-dc-pl-lem-apache-directory-studio. >> > > The basedn is automatically appended. Try --group-container=ou=groups > > regards > > rob It would be nice to include something like "The basedn was automatically appended." to this kind of error messages. Another option is to print whole DN as part of error message. Petr^2 Spacek From g17jimmy at gmail.com Wed Mar 21 20:33:34 2012 From: g17jimmy at gmail.com (Jimmy) Date: Wed, 21 Mar 2012 16:33:34 -0400 Subject: [Freeipa-users] (no subject) In-Reply-To: References: <4F636F7A.4060109@redhat.com> <4F6388E7.9000409@redhat.com> <4F63A3EC.6010205@redhat.com> <4F63B0E5.7030104@redhat.com> <4F679DD9.7090106@redhat.com> <4F68C12C.80103@redhat.com> <4F68D941.6070307@redhat.com> <4F68DD1D.7010407@redhat.com> <4F68F4A7.7030305@redhat.com> Message-ID: Since I needed to make sure I could recover from this if it ever happened again I went back to an old copy of the VM I'm going through everything I did on the original. To begin with, it does have the same issue, the cert won't renew. So I attempted to db2ldif and ldif2db all of the db's ***WITHOUT*** upgrading FreeIPA, and that didn't work. Different error than before when running , but I don't have it in front of me now, so I can't report it. One thing I did notice is that the exported ldif did not have the extra entries that prevented the ldif from importing right away last time. So I rolled back to the original database again, ran the freeipa upgrade from yum, and then exported the db's and now these entries show in the db that weren't there before: http://fpaste.org/jims/ Any idea why the upgrade did this? The ldif2db fails with this error as long as those 2 entries are in the ldif: [21/Mar/2012:00:59:14 +0000] entryrdn-index - _entryrdn_insert_key: Same DN (dn: ou=profile,dc=abc,dc=xyz) is already in the entryrdn file with different ID 146. Expected ID is 311. [21/Mar/2012:00:59:14 +0000] - import userRoot: Duplicated DN detected: "ou=profile,dc=abc,dc=xyz": Entry ID: (311) Sorry for bringing this back up, but it seems odd that the upgrade duplicates this entry. Jimmy On Tue, Mar 20, 2012 at 5:22 PM, Jimmy wrote: > Cool thanks for the awesome help, y'all. > > On Tue, Mar 20, 2012 at 5:20 PM, Rob Crittenden wrote: >> Jimmy wrote: >>> >>> I restarted certmonger and it seems to be working. Is there some way >>> to change the renewal interval so we can simulate this in the lab? I'd >>> like to see it go through a number of renewals to make sure we don't >>> keep having this problem. >> >> >> Glad you are up and running again. You can control the interval by tuning >> knobs in certmonger.conf(5). You want to modify ttls. >> >> rob From rcritten at redhat.com Wed Mar 21 21:20:10 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 21 Mar 2012 17:20:10 -0400 Subject: [Freeipa-users] (no subject) In-Reply-To: References: <4F63A3EC.6010205@redhat.com> <4F63B0E5.7030104@redhat.com> <4F679DD9.7090106@redhat.com> <4F68C12C.80103@redhat.com> <4F68D941.6070307@redhat.com> <4F68DD1D.7010407@redhat.com> <4F68F4A7.7030305@redhat.com> Message-ID: <4F6A460A.7000805@redhat.com> Jimmy wrote: > Since I needed to make sure I could recover from this if it ever > happened again I went back to an old copy of the VM I'm going through > everything I did on the original. To begin with, it does have the same > issue, the cert won't renew. So I attempted to db2ldif and ldif2db all > of the db's ***WITHOUT*** upgrading FreeIPA, and that didn't work. > Different error than before when running , but I don't have it in > front of me now, so I can't report it. One thing I did notice is that > the exported ldif did not have the extra entries that prevented the > ldif from importing right away last time. > > So I rolled back to the original database again, ran the freeipa > upgrade from yum, and then exported the db's and now these entries > show in the db that weren't there before: > > http://fpaste.org/jims/ > > Any idea why the upgrade did this? The ldif2db fails with this error > as long as those 2 entries are in the ldif: > > [21/Mar/2012:00:59:14 +0000] entryrdn-index - _entryrdn_insert_key: > Same DN (dn: ou=profile,dc=abc,dc=xyz) is already in the entryrdn file > with different ID 146. Expected ID is 311. > [21/Mar/2012:00:59:14 +0000] - import userRoot: Duplicated DN > detected: "ou=profile,dc=abc,dc=xyz": Entry ID: (311) > > Sorry for bringing this back up, but it seems odd that the upgrade > duplicates this entry. > Perhaps the database is already corrupted? The entries are added by the upgrade process only if they can't already be found in the database. It does an ldapsearch against the dn and adds if it isn't already there. The fact that 389-ds allows the add indicates that it doesn't think the entry is there. rob > Jimmy > > On Tue, Mar 20, 2012 at 5:22 PM, Jimmy wrote: >> Cool thanks for the awesome help, y'all. >> >> On Tue, Mar 20, 2012 at 5:20 PM, Rob Crittenden wrote: >>> Jimmy wrote: >>>> >>>> I restarted certmonger and it seems to be working. Is there some way >>>> to change the renewal interval so we can simulate this in the lab? I'd >>>> like to see it go through a number of renewals to make sure we don't >>>> keep having this problem. >>> >>> >>> Glad you are up and running again. You can control the interval by tuning >>> knobs in certmonger.conf(5). You want to modify ttls. >>> >>> rob From mkosek at redhat.com Thu Mar 22 10:50:35 2012 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 22 Mar 2012 11:50:35 +0100 Subject: [Freeipa-users] Error during ipa-replica-install In-Reply-To: References: Message-ID: <1332413435.10439.18.camel@balmora.brq.redhat.com> Hello Marco, judging from the output you sent, it looks like you had an installed replica on freeipa03, then stopped it with "ipactl" stop and after that tried to run ipa-replica-install again - krb5.conf and /var/log/messages you sent would support this theory. IPA replica agreement should be first removed with "ipa-replica-manage del " on freeipa01 and then uninstalled with "ipa-server-install --uninstall" before you try to install it again. Martin On Tue, 2012-03-20 at 12:58 +0100, Marco Pizzoli wrote: > Hi guys, > I'm running this version of FreeIPA: > > > [root at freeipa03 ~]# rpm -qa|grep freeipa > freeipa-server-selinux-2.1.90.rc1-0.fc16.x86_64 > freeipa-server-2.1.90.rc1-0.fc16.x86_64 > freeipa-admintools-2.1.90.rc1-0.fc16.x86_64 > freeipa-client-2.1.90.rc1-0.fc16.x86_64 > freeipa-python-2.1.90.rc1-0.fc16.x86_64 > > > > > I'm having this problem: > > > [root at freeipa03 ~]# ipa-replica-install --setup-dns > --no-forwarders /var/lib/ipa/replica-info-freeipa03.unix.mydomain.it.gpg > Directory Manager (existing master) password: > > > Run connection check to master > Check connection from replica to remote master > 'freeipa01.unix.mydomain.it': > Directory Service: Unsecure port (389): OK > Directory Service: Secure port (636): OK > Kerberos KDC: TCP (88): OK > Kerberos Kpasswd: TCP (464): OK > HTTP Server: Unsecure port (80): OK > HTTP Server: Secure port (443): OK > > > The following list of ports use UDP protocol and would need to be > checked manually: > Kerberos KDC: UDP (88): SKIPPED > Kerberos Kpasswd: UDP (464): SKIPPED > > > Connection from replica to master is OK. > Start listening on required ports for remote master check > Get credentials to log in to remote master > admin at UNIX.MYDOMAIN.IT password: > > > Cannot acquire Kerberos ticket: kinit: Invalid message type while > getting initial credentials > > > Connection check failed! > Please fix your network settings according to error messages above. > If the check results are not valid it can be skipped with > --skip-conncheck parameter. > > > ------------------- > I don't have any firewall between freeipa03 and freeipa01. > > > This is what I have in my /var/log/messages file: > > > > > Mar 20 12:03:51 freeipa03 sssd: Starting up > Mar 20 12:03:51 freeipa03 sssd[be[unix.mydomain.it]]: Starting up > Mar 20 12:03:52 freeipa03 ntpd_intres[773]: host name not found: > 0.fedora.pool.ntp.org > Mar 20 12:03:52 freeipa03 ntpd_intres[773]: host name not found: > 1.fedora.pool.ntp.org > Mar 20 12:03:52 freeipa03 ntpd_intres[773]: host name not found: > 2.fedora.pool.ntp.org > Mar 20 12:03:52 freeipa03 avahi-daemon[734]: Successfully called > chroot(). > Mar 20 12:03:52 freeipa03 avahi-daemon[734]: Successfully dropped > remaining capabilities. > Mar 20 12:03:52 freeipa03 avahi-daemon[734]: Loading service > file /services/ssh.service. > Mar 20 12:03:52 freeipa03 avahi-daemon[734]: Loading service > file /services/udisks.service. > Mar 20 12:03:52 freeipa03 avahi-daemon[734]: Network interface > enumeration completed. > Mar 20 12:03:52 freeipa03 avahi-daemon[734]: Registering HINFO record > with values 'X86_64'/'LINUX'. > Mar 20 12:03:52 freeipa03 avahi-daemon[734]: Server startup complete. > Host name is freeipa03.local. Local service cookie is 3668475942. > Mar 20 12:03:52 freeipa03 avahi-daemon[734]: Service > "freeipa03" (/services/udisks.service) successfully established. > Mar 20 12:03:52 freeipa03 avahi-daemon[734]: Service > "freeipa03" (/services/ssh.service) successfully established. > Mar 20 12:03:52 freeipa03 systemd-logind[764]: New seat seat0. > Mar 20 12:03:53 freeipa03 sssd[pam]: Starting up > Mar 20 12:03:53 freeipa03 sssd[nss]: Starting up > Mar 20 12:03:53 freeipa03 network[765]: Bringing up loopback > interface: [ OK ] > Mar 20 12:03:54 freeipa03 kernel: [ 25.724015] e1000: eth0 NIC Link > is Up 1000 Mbps Full Duplex, Flow Control: None > Mar 20 12:03:55 freeipa03 avahi-daemon[734]: Registering new address > record for fe80::20c:29ff:fedc:9788 on eth0.*. > Mar 20 12:03:56 freeipa03 avahi-daemon[734]: Joining mDNS multicast > group on interface eth0.IPv4 with address 192.168.146.134. > Mar 20 12:03:56 freeipa03 avahi-daemon[734]: New relevant interface > eth0.IPv4 for mDNS. > Mar 20 12:03:56 freeipa03 avahi-daemon[734]: Registering new address > record for 192.168.146.134 on eth0.IPv4. > Mar 20 12:03:56 freeipa03 network[765]: Bringing up interface eth0: > [ OK ] > Mar 20 12:03:57 freeipa03 kernel: [ 28.697268] 8021q: 802.1Q VLAN > Support v1.8 > Mar 20 12:03:57 freeipa03 kernel: [ 28.697283] 8021q: adding VLAN 0 > to HW filter on device eth0 > Mar 20 12:03:57 freeipa03 rpc.statd[994]: Version 1.2.5 starting > Mar 20 12:03:57 freeipa03 ntpd[741]: Listen normally on 4 eth0 > 192.168.146.134 UDP 123 > Mar 20 12:03:57 freeipa03 ntpd[741]: Listen normally on 5 eth0 > fe80::20c:29ff:fedc:9788 UDP 123 > Mar 20 12:03:57 freeipa03 ntpd[741]: peers refreshed > Mar 20 12:03:57 freeipa03 sm-notify[995]: Version 1.2.5 starting > Mar 20 12:03:58 freeipa03 systemd[1]: PID file /run/sendmail.pid not > readable (yet?) after start. > Mar 20 12:04:04 freeipa03 ntpd_intres[773]: host name not found: > 0.fedora.pool.ntp.org > Mar 20 12:04:07 freeipa03 systemd[1]: PID file /var/run/krb5kdc.pid > not readable (yet?) after start. > Mar 20 12:04:09 freeipa03 ntpd_intres[773]: host name not found: > 1.fedora.pool.ntp.org > Mar 20 12:04:10 freeipa03 named[1113]: starting BIND > 9.8.2rc2-RedHat-9.8.2-0.4.rc2.fc16 -u named > Mar 20 12:04:10 freeipa03 named[1113]: built with > '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' > '--program-prefix=' '--disable-dependency-tracking' '--prefix=/usr' > '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' > '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' > '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' > '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' > '--infodir=/usr/share/info' '--with-libtool' '--localstatedir=/var' > '--enable-threads' '--enable-ipv6' '--with-pic' '--disable-static' > '--disable-openssl-version-check' '--enable-exportlib' > '--with-export-libdir=/usr/lib64' > '--with-export-includedir=/usr/include' > '--includedir=/usr/include/bind9' > '--with-pkcs11=/usr/lib64/pkcs11/PKCS11_API.so' '--with-dlz-ldap=yes' > '--with-dlz-postgres=yes' '--with-dlz-mysql=yes' > '--with-dlz-filesystem=yes' '--with-gssapi=yes' '--disable-isc-spnego' > 'build_alias=x86_64-redhat-linux-gnu' > 'host_alias=x86_64-redhat-linux-gnu' 'CFLAGS= -O2 -g -pipe -Wall > -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector > --param=ssp-buffer-size=4 -m64 -mtune=generic' 'LDFLAGS=-Wl,-z,relro ' > 'CPPFLAGS= -DDIG_SIGCHASE' > Mar 20 12:04:10 freeipa03 named[1113]: > ---------------------------------------------------- > Mar 20 12:04:10 freeipa03 named[1113]: BIND 9 is maintained by > Internet Systems Consortium, > Mar 20 12:04:10 freeipa03 named[1113]: Inc. (ISC), a non-profit > 501(c)(3) public-benefit > Mar 20 12:04:10 freeipa03 named[1113]: corporation. Support and > training for BIND 9 are > Mar 20 12:04:10 freeipa03 named[1113]: available at > https://www.isc.org/support > Mar 20 12:04:10 freeipa03 named[1113]: > ---------------------------------------------------- > Mar 20 12:04:10 freeipa03 named[1113]: adjusted limit on open files > from 4096 to 1048576 > Mar 20 12:04:10 freeipa03 named[1113]: found 1 CPU, using 1 worker > thread > Mar 20 12:04:10 freeipa03 named[1113]: using up to 4096 sockets > Mar 20 12:04:10 freeipa03 named[1113]: loading configuration from > '/etc/named.conf' > Mar 20 12:04:10 freeipa03 named[1113]: using default UDP/IPv4 port > range: [1024, 65535] > Mar 20 12:04:10 freeipa03 named[1113]: using default UDP/IPv6 port > range: [1024, 65535] > Mar 20 12:04:10 freeipa03 named[1113]: listening on IPv6 interfaces, > port 53 > Mar 20 12:04:10 freeipa03 named[1113]: listening on IPv4 interface lo, > 127.0.0.1#53 > Mar 20 12:04:10 freeipa03 named[1113]: listening on IPv4 interface > eth0, 192.168.146.134#53 > Mar 20 12:04:10 freeipa03 named[1113]: generating session key for > dynamic DNS > Mar 20 12:04:10 freeipa03 named[1113]: sizing zone task pool based on > 6 zones > Mar 20 12:04:10 freeipa03 named[1113]: set up managed keys zone for > view _default, file 'managed-keys.bind' > Mar 20 12:04:10 freeipa03 named[1113]: Warning: > 'empty-zones-enable/disable-empty-zone' not set: disabling RFC 1918 > empty zones > Mar 20 12:04:10 freeipa03 named[1113]: automatic empty zone: > 127.IN-ADDR.ARPA > Mar 20 12:04:10 freeipa03 named[1113]: automatic empty zone: > 254.169.IN-ADDR.ARPA > Mar 20 12:04:10 freeipa03 named[1113]: automatic empty zone: > 2.0.192.IN-ADDR.ARPA > Mar 20 12:04:10 freeipa03 named[1113]: automatic empty zone: > 100.51.198.IN-ADDR.ARPA > Mar 20 12:04:10 freeipa03 named[1113]: automatic empty zone: > 113.0.203.IN-ADDR.ARPA > Mar 20 12:04:10 freeipa03 named[1113]: automatic empty zone: > 255.255.255.255.IN-ADDR.ARPA > Mar 20 12:04:10 freeipa03 named[1113]: automatic empty zone: > 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA > Mar 20 12:04:10 freeipa03 named[1113]: automatic empty zone: > D.F.IP6.ARPA > Mar 20 12:04:10 freeipa03 named[1113]: automatic empty zone: > 8.E.F.IP6.ARPA > Mar 20 12:04:10 freeipa03 named[1113]: automatic empty zone: > 9.E.F.IP6.ARPA > Mar 20 12:04:10 freeipa03 named[1113]: automatic empty zone: > A.E.F.IP6.ARPA > Mar 20 12:04:10 freeipa03 named[1113]: automatic empty zone: > B.E.F.IP6.ARPA > Mar 20 12:04:10 freeipa03 named[1113]: automatic empty zone: > 8.B.D.0.1.0.0.2.IP6.ARPA > Mar 20 12:04:11 freeipa03 named[1113]: command channel listening on > 127.0.0.1#953 > Mar 20 12:04:11 freeipa03 named[1113]: command channel listening > on ::1#953 > Mar 20 12:04:11 freeipa03 named[1113]: zone 0.in-addr.arpa/IN: loaded > serial 0 > Mar 20 12:04:11 freeipa03 named[1113]: zone 1.0.0.127.in-addr.arpa/IN: > loaded serial 0 > Mar 20 12:04:11 freeipa03 named[1113]: zone > 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN: loaded serial 0 > Mar 20 12:04:11 freeipa03 named[1113]: zone localhost.localdomain/IN: > loaded serial 0 > Mar 20 12:04:11 freeipa03 named[1113]: zone localhost/IN: loaded > serial 0 > Mar 20 12:04:11 freeipa03 named[1113]: managed-keys-zone ./IN: loaded > serial 0 > Mar 20 12:04:11 freeipa03 named[1113]: running > Mar 20 12:04:11 freeipa03 named[1107]: Starting named: [ OK ] > Mar 20 12:04:12 freeipa03 systemd[1]: PID > file /var/run/httpd/httpd.pid not readable (yet?) after start. > Mar 20 12:04:13 freeipa03 ipactl[974]: Starting Directory Service > Mar 20 12:04:13 freeipa03 ipactl[974]: Starting KDC Service > Mar 20 12:04:13 freeipa03 ipactl[974]: Starting KPASSWD Service > Mar 20 12:04:13 freeipa03 ipactl[974]: Starting DNS Service > Mar 20 12:04:13 freeipa03 ipactl[974]: Starting HTTP Service > Mar 20 12:04:13 freeipa03 ipactl[974]: Starting CA Service > Mar 20 12:04:14 freeipa03 ntpd_intres[773]: host name not found: > 2.fedora.pool.ntp.org > Mar 20 12:04:17 freeipa03 kernel: [ 49.099554] hrtimer: interrupt > took 17369081 ns > Mar 20 12:05:15 freeipa03 systemd[1]: Startup finished in 2s 98ms > 878us (kernel) + 5s 40ms 620us (initrd) + 1min 40s 13ms 749us > (userspace) = 1min 47s 153ms 247us. > Mar 20 12:06:18 freeipa03 ntpd_intres[773]: host name not found: > 0.fedora.pool.ntp.org > Mar 20 12:06:23 freeipa03 ntpd_intres[773]: host name not found: > 1.fedora.pool.ntp.org > Mar 20 12:06:28 freeipa03 ntpd_intres[773]: host name not found: > 2.fedora.pool.ntp.org > Mar 20 12:09:59 freeipa03 systemd-logind[764]: New session 1 of user > root. > Mar 20 12:10:35 freeipa03 ntpd_intres[773]: host name not found: > 0.fedora.pool.ntp.org > Mar 20 12:10:40 freeipa03 ntpd_intres[773]: host name not found: > 1.fedora.pool.ntp.org > Mar 20 12:10:45 freeipa03 ntpd_intres[773]: host name not found: > 2.fedora.pool.ntp.org > Mar 20 12:16:31 freeipa03 python: GSSAPI Error: Unspecified GSS > failure. Minor code may provide more information (Credentials cache > file '/tmp/krb5cc_0' not found) > Mar 20 12:18:28 freeipa03 systemd-tmpfiles[1438]: Successfully loaded > SELinux database in 232ms 225us, size on heap is 485K. > Mar 20 12:18:29 freeipa03 systemd-tmpfiles[1438]: Two or more > conflicting lines for /var/run/dirsrv configured, ignoring. > Mar 20 12:18:29 freeipa03 systemd-tmpfiles[1438]: Two or more > conflicting lines for /var/lock/dirsrv configured, ignoring. > Mar 20 12:18:48 freeipa03 ntpd_intres[773]: DNS 0.fedora.pool.ntp.org > -> 212.45.144.206 > Mar 20 12:18:49 freeipa03 ntpd_intres[773]: DNS 1.fedora.pool.ntp.org > -> 212.45.144.88 > Mar 20 12:18:49 freeipa03 ntpd_intres[773]: DNS 2.fedora.pool.ntp.org > -> 77.242.176.254 > Mar 20 12:19:49 freeipa03 ntpd[741]: frequency error 531 PPM exceeds > tolerance 500 PPM > Mar 20 12:24:45 freeipa03 systemd-logind[764]: New session 2 of user > root. > Mar 20 12:24:46 freeipa03 systemd-logind[764]: Removed session 2. > Mar 20 12:27:46 freeipa03 ntpd[741]: frequency error 558 PPM exceeds > tolerance 500 PPM > Mar 20 12:29:56 freeipa03 ntpd[741]: frequency error 516 PPM exceeds > tolerance 500 PPM > Mar 20 12:32:08 freeipa03 systemd[1]: pki-cad at pki-ca.service: main > process exited, code=exited, status=143 > Mar 20 12:32:08 freeipa03 systemd[1]: Unit pki-cad at pki-ca.service > entered failed state. > Mar 20 12:32:21 freeipa03 named[1113]: received control channel > command 'stop' > Mar 20 12:32:21 freeipa03 named[1113]: shutting down: flushing changes > Mar 20 12:32:21 freeipa03 named[1113]: stopping command channel on > 127.0.0.1#953 > Mar 20 12:32:21 freeipa03 named[1113]: stopping command channel > on ::1#953 > Mar 20 12:32:21 freeipa03 named[1113]: no longer listening on ::#53 > Mar 20 12:32:21 freeipa03 named[1113]: no longer listening on > 127.0.0.1#53 > Mar 20 12:32:21 freeipa03 named[1113]: no longer listening on > 192.168.146.134#53 > Mar 20 12:32:22 freeipa03 named[1113]: exiting > Mar 20 12:32:23 freeipa03 named[1538]: Stopping named: .[ OK ] > Mar 20 12:32:24 freeipa03 systemd[1]: kadmin.service: main process > exited, code=exited, status=2 > Mar 20 12:32:24 freeipa03 systemd[1]: Unit kadmin.service entered > failed state. > Mar 20 12:32:28 freeipa03 ipactl[1458]: Stopping CA Service > Mar 20 12:32:28 freeipa03 ipactl[1458]: Stopping HTTP Service > Mar 20 12:32:28 freeipa03 ipactl[1458]: Stopping DNS Service > Mar 20 12:32:28 freeipa03 ipactl[1458]: Stopping KPASSWD Service > Mar 20 12:32:28 freeipa03 ipactl[1458]: Stopping KDC Service > Mar 20 12:32:28 freeipa03 ipactl[1458]: Stopping Directory Service > Mar 20 12:36:43 freeipa03 ntpd[741]: frequency error 546 PPM exceeds > tolerance 500 PPM > Mar 20 12:48:50 freeipa03 ntpd[741]: frequency error 579 PPM exceeds > tolerance 500 PPM > > > > > > > I can add this info: > > > [root at freeipa03 ~]# kinit admin > kinit: Cannot contact any KDC for realm 'UNIX.MYDOMAIN.IT' while > getting initial credentials > > > [root at freeipa03 ~]# cat /etc/krb5.conf > [logging] > default = FILE:/var/log/krb5libs.log > kdc = FILE:/var/log/krb5kdc.log > admin_server = FILE:/var/log/kadmind.log > > > [libdefaults] > default_realm = UNIX.MYDOMAIN.IT > dns_lookup_realm = false > dns_lookup_kdc = false > rdns = false > ticket_lifetime = 24h > forwardable = yes > > > [realms] > UNIX.MYDOMAIN.IT = { > kdc = freeipa03.unix.mydomain.it:88 > admin_server = freeipa03.unix.mydomain.it:749 > default_domain = unix.mydomain.it > pkinit_anchors = FILE:/etc/ipa/ca.crt > } > > > [domain_realm] > .unix.mydomain.it = UNIX.MYDOMAIN.IT > unix.mydomain.it = UNIX.MYDOMAIN.IT > > > [dbmodules] > # UNIX.MYDOMAIN.IT = { > # db_library = kldap > # ldap_servers = ldapi://%2fvar%2frun% > 2fslapd-UNIX-MYDOMAIN-IT.socket > # ldap_kerberos_container_dn = > cn=kerberos,dc=unix,dc=mydomain,dc=it > # ldap_kdc_dn = > uid=kdc,cn=sysaccounts,cn=etc,dc=unix,dc=mydomain,dc=it > # ldap_kadmind_dn = > uid=kdc,cn=sysaccounts,cn=etc,dc=unix,dc=mydomain,dc=it > # ldap_service_password_file = /var/kerberos/krb5kdc/ldappwd > # } > > > UNIX.MYDOMAIN.IT = { > db_library = ipadb.so > } > > > > > Thanks as usual > Marco > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From maciej.sawicki at polidea.pl Fri Mar 23 10:16:01 2012 From: maciej.sawicki at polidea.pl (Maciej Sawicki) Date: Fri, 23 Mar 2012 11:16:01 +0100 Subject: [Freeipa-users] groups migration problem In-Reply-To: <4F68CAED.5010509@redhat.com> References: <4F68CAED.5010509@redhat.com> Message-ID: On Tue, Mar 20, 2012 at 7:22 PM, Rob Crittenden wrote: > The basedn is automatically appended. Try --group-container=ou=groups > Hi Rob, Thanks for quick answer. I tried it today. Didn't helped. "[root at free-ipa ~]# ipa migrate-ds ldap://192.168.1.125:389 --bind-dn="cn=admin,dc=polidea,dc=pl" --group-container='ou=groups' Password: ipa: ERROR: Container for group not found " regards, Maciej Sawicki From maciej.sawicki at polidea.pl Fri Mar 23 13:15:53 2012 From: maciej.sawicki at polidea.pl (Maciej Sawicki) Date: Fri, 23 Mar 2012 14:15:53 +0100 Subject: [Freeipa-users] groups migration problem In-Reply-To: References: <4F68CAED.5010509@redhat.com> Message-ID: Hi, I Solved my problem :D. I had to add --group-objectclas argument: ipa migrate-ds ldap://192.168.1.125:389 --bind-dn="cn=admin,dc=polidea,dc=pl" --group-container='ou=groups' --group-objectclas='posixGroup' Anyway I think " ipa: ERROR: Container for group not found" error is confusing. best regards, Maciej Sawicki On Fri, Mar 23, 2012 at 11:16 AM, Maciej Sawicki wrote: > On Tue, Mar 20, 2012 at 7:22 PM, Rob Crittenden wrote: >> The basedn is automatically appended. Try --group-container=ou=groups >> > > Hi Rob, > Thanks for quick answer. I tried it today. Didn't helped. > > "[root at free-ipa ~]# ipa migrate-ds ldap://192.168.1.125:389 > --bind-dn="cn=admin,dc=polidea,dc=pl" --group-container='ou=groups' > Password: > ipa: ERROR: Container for group not found > " > > regards, > Maciej Sawicki From dpal at redhat.com Fri Mar 23 13:32:01 2012 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 23 Mar 2012 09:32:01 -0400 Subject: [Freeipa-users] groups migration problem In-Reply-To: References: <4F68CAED.5010509@redhat.com> Message-ID: <4F6C7B51.8080808@redhat.com> On 03/23/2012 09:15 AM, Maciej Sawicki wrote: > Hi, > I Solved my problem :D. I had to add --group-objectclas argument: > > ipa migrate-ds ldap://192.168.1.125:389 > --bind-dn="cn=admin,dc=polidea,dc=pl" --group-container='ou=groups' > --group-objectclas='posixGroup' > > Anyway I think " ipa: ERROR: Container for group not found" error is confusing. Please open a ticket. https://fedorahosted.org/freeipa/ > best regards, > Maciej Sawicki > > > > On Fri, Mar 23, 2012 at 11:16 AM, Maciej Sawicki > wrote: >> On Tue, Mar 20, 2012 at 7:22 PM, Rob Crittenden wrote: >>> The basedn is automatically appended. Try --group-container=ou=groups >>> >> Hi Rob, >> Thanks for quick answer. I tried it today. Didn't helped. >> >> "[root at free-ipa ~]# ipa migrate-ds ldap://192.168.1.125:389 >> --bind-dn="cn=admin,dc=polidea,dc=pl" --group-container='ou=groups' >> Password: >> ipa: ERROR: Container for group not found >> " >> >> regards, >> Maciej Sawicki > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From marco.pizzoli at gmail.com Sat Mar 24 17:11:28 2012 From: marco.pizzoli at gmail.com (Marco Pizzoli) Date: Sat, 24 Mar 2012 18:11:28 +0100 Subject: [Freeipa-users] Constantly failing ipa-client-install Message-ID: Hi guys, I'm wirking with 2.1.90-rc1 and I'm getting always this error during a client enrollment: [root at myhostname ~]# ipa-client-install --enable-dns-updates --principal=admin --password=mypassword --ssh-trust-dns --mkhomedir Discovery was successful! Hostname: myhostname.server.unix.mydomain.it Realm: UNIX.MYDOMAIN.IT DNS Domain: unix.mydomain.it IPA Server: freeipa01.unix.mydomain.it BaseDN: dc=unix,dc=mydomain,dc=it Continue to configure the system with these values? [no]: yes Synchronizing time with KDC... Enrolled in IPA realm UNIX.MYDOMAIN.IT Created /etc/ipa/default.conf Traceback (most recent call last): File "/usr/sbin/ipa-client-install", line 1527, in sys.exit(main()) File "/usr/sbin/ipa-client-install", line 1514, in main rval = install(options, env, fstore, statestore) File "/usr/sbin/ipa-client-install", line 1327, in install api.finalize() File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 659, in finalize self.__do_if_not_done('load_plugins') File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 452, in __do_if_not_done getattr(self, name)() File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 598, in load_plugins self.import_plugins('ipalib') File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 649, in import_plugins raise e ImportError: No module named krbV Could you help me? Thanks as usual Marco -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdennis at redhat.com Sat Mar 24 20:35:40 2012 From: jdennis at redhat.com (John Dennis) Date: Sat, 24 Mar 2012 16:35:40 -0400 Subject: [Freeipa-users] Constantly failing ipa-client-install In-Reply-To: References: Message-ID: <4F6E301C.4070701@redhat.com> On 03/24/2012 01:11 PM, Marco Pizzoli wrote: > Hi guys, > I'm wirking with 2.1.90-rc1 and I'm getting always this error during a > client enrollment: > > [root at myhostname ~]# ipa-client-install --enable-dns-updates > --principal=admin --password=mypassword --ssh-trust-dns --mkhomedir > Discovery was successful! > Hostname: myhostname.server.unix.mydomain.it > > Realm: UNIX.MYDOMAIN.IT > DNS Domain: unix.mydomain.it > IPA Server: freeipa01.unix.mydomain.it > BaseDN: dc=unix,dc=mydomain,dc=it > > > Continue to configure the system with these values? [no]: yes > Synchronizing time with KDC... > > Enrolled in IPA realm UNIX.MYDOMAIN.IT > Created /etc/ipa/default.conf > Traceback (most recent call last): > File "/usr/sbin/ipa-client-install", line 1527, in > sys.exit(main()) > File "/usr/sbin/ipa-client-install", line 1514, in main > rval = install(options, env, fstore, statestore) > File "/usr/sbin/ipa-client-install", line 1327, in install > api.finalize() > File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 659, > in finalize > self.__do_if_not_done('load_plugins') > File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 452, > in __do_if_not_done > getattr(self, name)() > File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 598, > in load_plugins > self.import_plugins('ipalib') > File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 649, > in import_plugins > raise e > ImportError: No module named krbV > > Could you help me? > > Thanks as usual > Marco Sounds like you don't have the python-krbV RPM installed. $ sudo yum install python-krbV should fix it. What version of freeipa-client do you have? $ rpm -q freeipa-client Does it require python-krbV? rpm -q --requires freeipa-client I think we might have introduced a dependency on python-krbV in the client code we weren't aware of and need to fix this. If that's true would you please file a bug here: https://fedorahosted.org/freeipa/ -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From marco.pizzoli at gmail.com Sun Mar 25 09:50:30 2012 From: marco.pizzoli at gmail.com (Marco Pizzoli) Date: Sun, 25 Mar 2012 11:50:30 +0200 Subject: [Freeipa-users] Constantly failing ipa-client-install In-Reply-To: <4F6E301C.4070701@redhat.com> References: <4F6E301C.4070701@redhat.com> Message-ID: Hi John, On Sat, Mar 24, 2012 at 9:35 PM, John Dennis wrote: > On 03/24/2012 01:11 PM, Marco Pizzoli wrote: > >> Hi guys, >> I'm wirking with 2.1.90-rc1 and I'm getting always this error during a >> client enrollment: >> >> [root at myhostname ~]# ipa-client-install --enable-dns-updates >> --principal=admin --password=mypassword --ssh-trust-dns --mkhomedir >> Discovery was successful! >> Hostname: myhostname.server.unix.**mydomain.it >> >> > >> Realm: UNIX.MYDOMAIN.IT >> DNS Domain: unix.mydomain.it >> IPA Server: freeipa01.unix.mydomain.it > mydomain.it > >> >> BaseDN: dc=unix,dc=mydomain,dc=it >> >> >> Continue to configure the system with these values? [no]: yes >> Synchronizing time with KDC... >> >> Enrolled in IPA realm UNIX.MYDOMAIN.IT >> >> Created /etc/ipa/default.conf >> Traceback (most recent call last): >> File "/usr/sbin/ipa-client-install"**, line 1527, in >> sys.exit(main()) >> File "/usr/sbin/ipa-client-install"**, line 1514, in main >> rval = install(options, env, fstore, statestore) >> File "/usr/sbin/ipa-client-install"**, line 1327, in install >> api.finalize() >> File "/usr/lib/python2.7/site-**packages/ipalib/plugable.py", line 659, >> in finalize >> self.__do_if_not_done('load_**plugins') >> File "/usr/lib/python2.7/site-**packages/ipalib/plugable.py", line 452, >> in __do_if_not_done >> getattr(self, name)() >> File "/usr/lib/python2.7/site-**packages/ipalib/plugable.py", line 598, >> in load_plugins >> self.import_plugins('ipalib') >> File "/usr/lib/python2.7/site-**packages/ipalib/plugable.py", line 649, >> in import_plugins >> raise e >> ImportError: No module named krbV >> >> Could you help me? >> >> Thanks as usual >> Marco >> > > Sounds like you don't have the python-krbV RPM installed. > > $ sudo yum install python-krbV > > should fix it. > > What version of freeipa-client do you have? > > $ rpm -q freeipa-client > > Does it require python-krbV? > > rpm -q --requires freeipa-client > [root@ myhostname ~]# rpm -q freeipa-client freeipa-client-2.1.90.rc1-0.fc16.x86_64 [root at myhostname ~]# rpm -q --requires freeipa-client /usr/bin/python authconfig bind-utils certmonger >= 0.26 cyrus-sasl-gssapi(x86-64) freeipa-python = 2.1.90.rc1-0.fc16 krb5-workstation libc.so.6()(64bit) libc.so.6(GLIBC_2.14)(64bit) libc.so.6(GLIBC_2.2.5)(64bit) libc.so.6(GLIBC_2.3)(64bit) libc.so.6(GLIBC_2.3.4)(64bit) libc.so.6(GLIBC_2.8)(64bit) libcom_err.so.2()(64bit) libcurl >= 7.21.7-2 libcurl.so.4()(64bit) libk5crypto.so.3()(64bit) libk5crypto.so.3(k5crypto_3_MIT)(64bit) libkrb5.so.3()(64bit) libkrb5.so.3(krb5_3_MIT)(64bit) liblber-2.4.so.2()(64bit) libldap-2.4.so.2()(64bit) libpopt.so.0()(64bit) libpopt.so.0(LIBPOPT_0)(64bit) libsasl2.so.2()(64bit) libxmlrpc.so.3()(64bit) libxmlrpc_client.so.3()(64bit) libxmlrpc_util.so.3()(64bit) nss-tools ntp oddjob-mkhomedir pam_krb5 python(abi) = 2.7 python-ldap rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PartialHardlinkSets) <= 4.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rtld(GNU_HASH) sssd >= 1.8.0 wget xmlrpc-c >= 1.27.4 rpmlib(PayloadIsXz) <= 5.2-1 I installed the package python-krbV as you suggested and it did the trick! Thanks > > I think we might have introduced a dependency on python-krbV in the client > code we weren't aware of and need to fix this. If that's true would you > please file a bug here: > > https://fedorahosted.org/**freeipa/ > > Done. https://fedorahosted.org/freeipa/ticket/2577 > > > -- > John Dennis > > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marco.pizzoli at gmail.com Sun Mar 25 13:55:51 2012 From: marco.pizzoli at gmail.com (Marco Pizzoli) Date: Sun, 25 Mar 2012 15:55:51 +0200 Subject: [Freeipa-users] Error during ipa-replica-install In-Reply-To: <1332413435.10439.18.camel@balmora.brq.redhat.com> References: <1332413435.10439.18.camel@balmora.brq.redhat.com> Message-ID: Hi Martin, On Thu, Mar 22, 2012 at 11:50 AM, Martin Kosek wrote: > Hello Marco, > > judging from the output you sent, it looks like you had an installed > replica on freeipa03, then stopped it with "ipactl" stop and after that > tried to run ipa-replica-install again - krb5.conf and /var/log/messages > you sent would support this theory. > > IPA replica agreement should be first removed with "ipa-replica-manage > del " on freeipa01 and then uninstalled with > "ipa-server-install --uninstall" before you try to install it again. > Thanks for your answer. I tried what you suggested, but this is what I'm getting now: [root at freeipa01 ~]# ipa-replica-manage -v list freeipa01.unix.mydomain.it: master freeipa03.unix.mydomain.it: master [root at freeipa01 ~]# ipa-replica-manage -v del freeipa03.unix.mydomain.it Unable to delete replica freeipa03.unix.mydomain.it: {'desc': "Can't contact LDAP server"} [root at freeipa01 ~]# ps -ef|grep slap dirsrv 1149 1 0 15:30 ? 00:00:01 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-UNIX-MYDOMAIN-IT -i /var/run/dirsrv/slapd-UNIX-MYDOMAIN-IT.pid -w /var/run/dirsrv/slapd-UNIX-MYDOMAIN-IT.startpid pkisrv 1150 1 0 15:30 ? 00:00:00 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-PKI-IPA -i /var/run/dirsrv/slapd-PKI-IPA.pid -w /var/run/dirsrv/slapd-PKI-IPA.startpid After little investigation (should worth a more descriptive output? ^_^) I found the LDAP server being asked was the freeipa03 one. Yes, it was not running at the moment I executed the command. I went to freeipa03 and tried to "systemctl start dirsrv.target". This is what I have in my /var/log/messages log: Mar 25 15:48:50 freeipa03 systemd[1]: Failed to load environment files: No such file or directory Mar 25 15:48:50 freeipa03 systemd[1]: dirsrv at UNIX-MYDOMAIN-IT.servicefailed to run 'start' task: No such file or directory Mar 25 15:48:50 freeipa03 systemd[1]: Unit dirsrv at UNIX-MYDOMAIN-IT.serviceentered failed state. My dirsrv access and error log files are currently not populated. How can I exit from the tunnel? :-) Thanks in advance again Marco > > Martin > > On Tue, 2012-03-20 at 12:58 +0100, Marco Pizzoli wrote: > > Hi guys, > > I'm running this version of FreeIPA: > > > > > > [root at freeipa03 ~]# rpm -qa|grep freeipa > > freeipa-server-selinux-2.1.90.rc1-0.fc16.x86_64 > > freeipa-server-2.1.90.rc1-0.fc16.x86_64 > > freeipa-admintools-2.1.90.rc1-0.fc16.x86_64 > > freeipa-client-2.1.90.rc1-0.fc16.x86_64 > > freeipa-python-2.1.90.rc1-0.fc16.x86_64 > > > > > > > > > > I'm having this problem: > > > > > > [root at freeipa03 ~]# ipa-replica-install --setup-dns > > --no-forwarders /var/lib/ipa/replica-info-freeipa03.unix.mydomain.it.gpg > > Directory Manager (existing master) password: > > > > > > Run connection check to master > > Check connection from replica to remote master > > 'freeipa01.unix.mydomain.it': > > Directory Service: Unsecure port (389): OK > > Directory Service: Secure port (636): OK > > Kerberos KDC: TCP (88): OK > > Kerberos Kpasswd: TCP (464): OK > > HTTP Server: Unsecure port (80): OK > > HTTP Server: Secure port (443): OK > > > > > > The following list of ports use UDP protocol and would need to be > > checked manually: > > Kerberos KDC: UDP (88): SKIPPED > > Kerberos Kpasswd: UDP (464): SKIPPED > > > > > > Connection from replica to master is OK. > > Start listening on required ports for remote master check > > Get credentials to log in to remote master > > admin at UNIX.MYDOMAIN.IT password: > > > > > > Cannot acquire Kerberos ticket: kinit: Invalid message type while > > getting initial credentials > > > > > > Connection check failed! > > Please fix your network settings according to error messages above. > > If the check results are not valid it can be skipped with > > --skip-conncheck parameter. > > > > > > ------------------- > > I don't have any firewall between freeipa03 and freeipa01. > > > > > > This is what I have in my /var/log/messages file: > > > > > > > > > > Mar 20 12:03:51 freeipa03 sssd: Starting up > > Mar 20 12:03:51 freeipa03 sssd[be[unix.mydomain.it]]: Starting up > > Mar 20 12:03:52 freeipa03 ntpd_intres[773]: host name not found: > > 0.fedora.pool.ntp.org > > Mar 20 12:03:52 freeipa03 ntpd_intres[773]: host name not found: > > 1.fedora.pool.ntp.org > > Mar 20 12:03:52 freeipa03 ntpd_intres[773]: host name not found: > > 2.fedora.pool.ntp.org > > Mar 20 12:03:52 freeipa03 avahi-daemon[734]: Successfully called > > chroot(). > > Mar 20 12:03:52 freeipa03 avahi-daemon[734]: Successfully dropped > > remaining capabilities. > > Mar 20 12:03:52 freeipa03 avahi-daemon[734]: Loading service > > file /services/ssh.service. > > Mar 20 12:03:52 freeipa03 avahi-daemon[734]: Loading service > > file /services/udisks.service. > > Mar 20 12:03:52 freeipa03 avahi-daemon[734]: Network interface > > enumeration completed. > > Mar 20 12:03:52 freeipa03 avahi-daemon[734]: Registering HINFO record > > with values 'X86_64'/'LINUX'. > > Mar 20 12:03:52 freeipa03 avahi-daemon[734]: Server startup complete. > > Host name is freeipa03.local. Local service cookie is 3668475942. > > Mar 20 12:03:52 freeipa03 avahi-daemon[734]: Service > > "freeipa03" (/services/udisks.service) successfully established. > > Mar 20 12:03:52 freeipa03 avahi-daemon[734]: Service > > "freeipa03" (/services/ssh.service) successfully established. > > Mar 20 12:03:52 freeipa03 systemd-logind[764]: New seat seat0. > > Mar 20 12:03:53 freeipa03 sssd[pam]: Starting up > > Mar 20 12:03:53 freeipa03 sssd[nss]: Starting up > > Mar 20 12:03:53 freeipa03 network[765]: Bringing up loopback > > interface: [ OK ] > > Mar 20 12:03:54 freeipa03 kernel: [ 25.724015] e1000: eth0 NIC Link > > is Up 1000 Mbps Full Duplex, Flow Control: None > > Mar 20 12:03:55 freeipa03 avahi-daemon[734]: Registering new address > > record for fe80::20c:29ff:fedc:9788 on eth0.*. > > Mar 20 12:03:56 freeipa03 avahi-daemon[734]: Joining mDNS multicast > > group on interface eth0.IPv4 with address 192.168.146.134. > > Mar 20 12:03:56 freeipa03 avahi-daemon[734]: New relevant interface > > eth0.IPv4 for mDNS. > > Mar 20 12:03:56 freeipa03 avahi-daemon[734]: Registering new address > > record for 192.168.146.134 on eth0.IPv4. > > Mar 20 12:03:56 freeipa03 network[765]: Bringing up interface eth0: > > [ OK ] > > Mar 20 12:03:57 freeipa03 kernel: [ 28.697268] 8021q: 802.1Q VLAN > > Support v1.8 > > Mar 20 12:03:57 freeipa03 kernel: [ 28.697283] 8021q: adding VLAN 0 > > to HW filter on device eth0 > > Mar 20 12:03:57 freeipa03 rpc.statd[994]: Version 1.2.5 starting > > Mar 20 12:03:57 freeipa03 ntpd[741]: Listen normally on 4 eth0 > > 192.168.146.134 UDP 123 > > Mar 20 12:03:57 freeipa03 ntpd[741]: Listen normally on 5 eth0 > > fe80::20c:29ff:fedc:9788 UDP 123 > > Mar 20 12:03:57 freeipa03 ntpd[741]: peers refreshed > > Mar 20 12:03:57 freeipa03 sm-notify[995]: Version 1.2.5 starting > > Mar 20 12:03:58 freeipa03 systemd[1]: PID file /run/sendmail.pid not > > readable (yet?) after start. > > Mar 20 12:04:04 freeipa03 ntpd_intres[773]: host name not found: > > 0.fedora.pool.ntp.org > > Mar 20 12:04:07 freeipa03 systemd[1]: PID file /var/run/krb5kdc.pid > > not readable (yet?) after start. > > Mar 20 12:04:09 freeipa03 ntpd_intres[773]: host name not found: > > 1.fedora.pool.ntp.org > > Mar 20 12:04:10 freeipa03 named[1113]: starting BIND > > 9.8.2rc2-RedHat-9.8.2-0.4.rc2.fc16 -u named > > Mar 20 12:04:10 freeipa03 named[1113]: built with > > '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' > > '--program-prefix=' '--disable-dependency-tracking' '--prefix=/usr' > > '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' > > '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' > > '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' > > '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' > > '--infodir=/usr/share/info' '--with-libtool' '--localstatedir=/var' > > '--enable-threads' '--enable-ipv6' '--with-pic' '--disable-static' > > '--disable-openssl-version-check' '--enable-exportlib' > > '--with-export-libdir=/usr/lib64' > > '--with-export-includedir=/usr/include' > > '--includedir=/usr/include/bind9' > > '--with-pkcs11=/usr/lib64/pkcs11/PKCS11_API.so' '--with-dlz-ldap=yes' > > '--with-dlz-postgres=yes' '--with-dlz-mysql=yes' > > '--with-dlz-filesystem=yes' '--with-gssapi=yes' '--disable-isc-spnego' > > 'build_alias=x86_64-redhat-linux-gnu' > > 'host_alias=x86_64-redhat-linux-gnu' 'CFLAGS= -O2 -g -pipe -Wall > > -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector > > --param=ssp-buffer-size=4 -m64 -mtune=generic' 'LDFLAGS=-Wl,-z,relro ' > > 'CPPFLAGS= -DDIG_SIGCHASE' > > Mar 20 12:04:10 freeipa03 named[1113]: > > ---------------------------------------------------- > > Mar 20 12:04:10 freeipa03 named[1113]: BIND 9 is maintained by > > Internet Systems Consortium, > > Mar 20 12:04:10 freeipa03 named[1113]: Inc. (ISC), a non-profit > > 501(c)(3) public-benefit > > Mar 20 12:04:10 freeipa03 named[1113]: corporation. Support and > > training for BIND 9 are > > Mar 20 12:04:10 freeipa03 named[1113]: available at > > https://www.isc.org/support > > Mar 20 12:04:10 freeipa03 named[1113]: > > ---------------------------------------------------- > > Mar 20 12:04:10 freeipa03 named[1113]: adjusted limit on open files > > from 4096 to 1048576 > > Mar 20 12:04:10 freeipa03 named[1113]: found 1 CPU, using 1 worker > > thread > > Mar 20 12:04:10 freeipa03 named[1113]: using up to 4096 sockets > > Mar 20 12:04:10 freeipa03 named[1113]: loading configuration from > > '/etc/named.conf' > > Mar 20 12:04:10 freeipa03 named[1113]: using default UDP/IPv4 port > > range: [1024, 65535] > > Mar 20 12:04:10 freeipa03 named[1113]: using default UDP/IPv6 port > > range: [1024, 65535] > > Mar 20 12:04:10 freeipa03 named[1113]: listening on IPv6 interfaces, > > port 53 > > Mar 20 12:04:10 freeipa03 named[1113]: listening on IPv4 interface lo, > > 127.0.0.1#53 > > Mar 20 12:04:10 freeipa03 named[1113]: listening on IPv4 interface > > eth0, 192.168.146.134#53 > > Mar 20 12:04:10 freeipa03 named[1113]: generating session key for > > dynamic DNS > > Mar 20 12:04:10 freeipa03 named[1113]: sizing zone task pool based on > > 6 zones > > Mar 20 12:04:10 freeipa03 named[1113]: set up managed keys zone for > > view _default, file 'managed-keys.bind' > > Mar 20 12:04:10 freeipa03 named[1113]: Warning: > > 'empty-zones-enable/disable-empty-zone' not set: disabling RFC 1918 > > empty zones > > Mar 20 12:04:10 freeipa03 named[1113]: automatic empty zone: > > 127.IN-ADDR.ARPA > > Mar 20 12:04:10 freeipa03 named[1113]: automatic empty zone: > > 254.169.IN-ADDR.ARPA > > Mar 20 12:04:10 freeipa03 named[1113]: automatic empty zone: > > 2.0.192.IN-ADDR.ARPA > > Mar 20 12:04:10 freeipa03 named[1113]: automatic empty zone: > > 100.51.198.IN-ADDR.ARPA > > Mar 20 12:04:10 freeipa03 named[1113]: automatic empty zone: > > 113.0.203.IN-ADDR.ARPA > > Mar 20 12:04:10 freeipa03 named[1113]: automatic empty zone: > > 255.255.255.255.IN-ADDR.ARPA > > Mar 20 12:04:10 freeipa03 named[1113]: automatic empty zone: > > 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA > > Mar 20 12:04:10 freeipa03 named[1113]: automatic empty zone: > > D.F.IP6.ARPA > > Mar 20 12:04:10 freeipa03 named[1113]: automatic empty zone: > > 8.E.F.IP6.ARPA > > Mar 20 12:04:10 freeipa03 named[1113]: automatic empty zone: > > 9.E.F.IP6.ARPA > > Mar 20 12:04:10 freeipa03 named[1113]: automatic empty zone: > > A.E.F.IP6.ARPA > > Mar 20 12:04:10 freeipa03 named[1113]: automatic empty zone: > > B.E.F.IP6.ARPA > > Mar 20 12:04:10 freeipa03 named[1113]: automatic empty zone: > > 8.B.D.0.1.0.0.2.IP6.ARPA > > Mar 20 12:04:11 freeipa03 named[1113]: command channel listening on > > 127.0.0.1#953 > > Mar 20 12:04:11 freeipa03 named[1113]: command channel listening > > on ::1#953 > > Mar 20 12:04:11 freeipa03 named[1113]: zone 0.in-addr.arpa/IN: loaded > > serial 0 > > Mar 20 12:04:11 freeipa03 named[1113]: zone 1.0.0.127.in-addr.arpa/IN: > > loaded serial 0 > > Mar 20 12:04:11 freeipa03 named[1113]: zone > > > 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN: > loaded serial 0 > > Mar 20 12:04:11 freeipa03 named[1113]: zone localhost.localdomain/IN: > > loaded serial 0 > > Mar 20 12:04:11 freeipa03 named[1113]: zone localhost/IN: loaded > > serial 0 > > Mar 20 12:04:11 freeipa03 named[1113]: managed-keys-zone ./IN: loaded > > serial 0 > > Mar 20 12:04:11 freeipa03 named[1113]: running > > Mar 20 12:04:11 freeipa03 named[1107]: Starting named: [ OK ] > > Mar 20 12:04:12 freeipa03 systemd[1]: PID > > file /var/run/httpd/httpd.pid not readable (yet?) after start. > > Mar 20 12:04:13 freeipa03 ipactl[974]: Starting Directory Service > > Mar 20 12:04:13 freeipa03 ipactl[974]: Starting KDC Service > > Mar 20 12:04:13 freeipa03 ipactl[974]: Starting KPASSWD Service > > Mar 20 12:04:13 freeipa03 ipactl[974]: Starting DNS Service > > Mar 20 12:04:13 freeipa03 ipactl[974]: Starting HTTP Service > > Mar 20 12:04:13 freeipa03 ipactl[974]: Starting CA Service > > Mar 20 12:04:14 freeipa03 ntpd_intres[773]: host name not found: > > 2.fedora.pool.ntp.org > > Mar 20 12:04:17 freeipa03 kernel: [ 49.099554] hrtimer: interrupt > > took 17369081 ns > > Mar 20 12:05:15 freeipa03 systemd[1]: Startup finished in 2s 98ms > > 878us (kernel) + 5s 40ms 620us (initrd) + 1min 40s 13ms 749us > > (userspace) = 1min 47s 153ms 247us. > > Mar 20 12:06:18 freeipa03 ntpd_intres[773]: host name not found: > > 0.fedora.pool.ntp.org > > Mar 20 12:06:23 freeipa03 ntpd_intres[773]: host name not found: > > 1.fedora.pool.ntp.org > > Mar 20 12:06:28 freeipa03 ntpd_intres[773]: host name not found: > > 2.fedora.pool.ntp.org > > Mar 20 12:09:59 freeipa03 systemd-logind[764]: New session 1 of user > > root. > > Mar 20 12:10:35 freeipa03 ntpd_intres[773]: host name not found: > > 0.fedora.pool.ntp.org > > Mar 20 12:10:40 freeipa03 ntpd_intres[773]: host name not found: > > 1.fedora.pool.ntp.org > > Mar 20 12:10:45 freeipa03 ntpd_intres[773]: host name not found: > > 2.fedora.pool.ntp.org > > Mar 20 12:16:31 freeipa03 python: GSSAPI Error: Unspecified GSS > > failure. Minor code may provide more information (Credentials cache > > file '/tmp/krb5cc_0' not found) > > Mar 20 12:18:28 freeipa03 systemd-tmpfiles[1438]: Successfully loaded > > SELinux database in 232ms 225us, size on heap is 485K. > > Mar 20 12:18:29 freeipa03 systemd-tmpfiles[1438]: Two or more > > conflicting lines for /var/run/dirsrv configured, ignoring. > > Mar 20 12:18:29 freeipa03 systemd-tmpfiles[1438]: Two or more > > conflicting lines for /var/lock/dirsrv configured, ignoring. > > Mar 20 12:18:48 freeipa03 ntpd_intres[773]: DNS 0.fedora.pool.ntp.org > > -> 212.45.144.206 > > Mar 20 12:18:49 freeipa03 ntpd_intres[773]: DNS 1.fedora.pool.ntp.org > > -> 212.45.144.88 > > Mar 20 12:18:49 freeipa03 ntpd_intres[773]: DNS 2.fedora.pool.ntp.org > > -> 77.242.176.254 > > Mar 20 12:19:49 freeipa03 ntpd[741]: frequency error 531 PPM exceeds > > tolerance 500 PPM > > Mar 20 12:24:45 freeipa03 systemd-logind[764]: New session 2 of user > > root. > > Mar 20 12:24:46 freeipa03 systemd-logind[764]: Removed session 2. > > Mar 20 12:27:46 freeipa03 ntpd[741]: frequency error 558 PPM exceeds > > tolerance 500 PPM > > Mar 20 12:29:56 freeipa03 ntpd[741]: frequency error 516 PPM exceeds > > tolerance 500 PPM > > Mar 20 12:32:08 freeipa03 systemd[1]: pki-cad at pki-ca.service: main > > process exited, code=exited, status=143 > > Mar 20 12:32:08 freeipa03 systemd[1]: Unit pki-cad at pki-ca.service > > entered failed state. > > Mar 20 12:32:21 freeipa03 named[1113]: received control channel > > command 'stop' > > Mar 20 12:32:21 freeipa03 named[1113]: shutting down: flushing changes > > Mar 20 12:32:21 freeipa03 named[1113]: stopping command channel on > > 127.0.0.1#953 > > Mar 20 12:32:21 freeipa03 named[1113]: stopping command channel > > on ::1#953 > > Mar 20 12:32:21 freeipa03 named[1113]: no longer listening on ::#53 > > Mar 20 12:32:21 freeipa03 named[1113]: no longer listening on > > 127.0.0.1#53 > > Mar 20 12:32:21 freeipa03 named[1113]: no longer listening on > > 192.168.146.134#53 > > Mar 20 12:32:22 freeipa03 named[1113]: exiting > > Mar 20 12:32:23 freeipa03 named[1538]: Stopping named: .[ OK ] > > Mar 20 12:32:24 freeipa03 systemd[1]: kadmin.service: main process > > exited, code=exited, status=2 > > Mar 20 12:32:24 freeipa03 systemd[1]: Unit kadmin.service entered > > failed state. > > Mar 20 12:32:28 freeipa03 ipactl[1458]: Stopping CA Service > > Mar 20 12:32:28 freeipa03 ipactl[1458]: Stopping HTTP Service > > Mar 20 12:32:28 freeipa03 ipactl[1458]: Stopping DNS Service > > Mar 20 12:32:28 freeipa03 ipactl[1458]: Stopping KPASSWD Service > > Mar 20 12:32:28 freeipa03 ipactl[1458]: Stopping KDC Service > > Mar 20 12:32:28 freeipa03 ipactl[1458]: Stopping Directory Service > > Mar 20 12:36:43 freeipa03 ntpd[741]: frequency error 546 PPM exceeds > > tolerance 500 PPM > > Mar 20 12:48:50 freeipa03 ntpd[741]: frequency error 579 PPM exceeds > > tolerance 500 PPM > > > > > > > > > > > > > > I can add this info: > > > > > > [root at freeipa03 ~]# kinit admin > > kinit: Cannot contact any KDC for realm 'UNIX.MYDOMAIN.IT' while > > getting initial credentials > > > > > > [root at freeipa03 ~]# cat /etc/krb5.conf > > [logging] > > default = FILE:/var/log/krb5libs.log > > kdc = FILE:/var/log/krb5kdc.log > > admin_server = FILE:/var/log/kadmind.log > > > > > > [libdefaults] > > default_realm = UNIX.MYDOMAIN.IT > > dns_lookup_realm = false > > dns_lookup_kdc = false > > rdns = false > > ticket_lifetime = 24h > > forwardable = yes > > > > > > [realms] > > UNIX.MYDOMAIN.IT = { > > kdc = freeipa03.unix.mydomain.it:88 > > admin_server = freeipa03.unix.mydomain.it:749 > > default_domain = unix.mydomain.it > > pkinit_anchors = FILE:/etc/ipa/ca.crt > > } > > > > > > [domain_realm] > > .unix.mydomain.it = UNIX.MYDOMAIN.IT > > unix.mydomain.it = UNIX.MYDOMAIN.IT > > > > > > [dbmodules] > > # UNIX.MYDOMAIN.IT = { > > # db_library = kldap > > # ldap_servers = ldapi://%2fvar%2frun% > > 2fslapd-UNIX-MYDOMAIN-IT.socket > > # ldap_kerberos_container_dn = > > cn=kerberos,dc=unix,dc=mydomain,dc=it > > # ldap_kdc_dn = > > uid=kdc,cn=sysaccounts,cn=etc,dc=unix,dc=mydomain,dc=it > > # ldap_kadmind_dn = > > uid=kdc,cn=sysaccounts,cn=etc,dc=unix,dc=mydomain,dc=it > > # ldap_service_password_file = /var/kerberos/krb5kdc/ldappwd > > # } > > > > > > UNIX.MYDOMAIN.IT = { > > db_library = ipadb.so > > } > > > > > > > > > > Thanks as usual > > Marco > > _______________________________________________ > > 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 marco.pizzoli at gmail.com Sun Mar 25 15:35:27 2012 From: marco.pizzoli at gmail.com (Marco Pizzoli) Date: Sun, 25 Mar 2012 17:35:27 +0200 Subject: [Freeipa-users] ipa-client-install error during ipa-replica-install Message-ID: Hi guys, I'm still working with the beta version. I tried the setup of another replica and this is what I'm getting: [root at freeipa04 ~]# ipa-replica-install --setup-dns --no-forwarders /var/lib/ipa/replica-info-freeipa04.unix.mydomain.it.gpg Directory Manager (existing master) password: Warning: Hostname (freeipa04.unix.mydomain.it) not found in DNS Run connection check to master Check connection from replica to remote master 'freeipa01.unix.mydomain.it': Directory Service: Unsecure port (389): OK Directory Service: Secure port (636): OK Kerberos KDC: TCP (88): OK Kerberos Kpasswd: TCP (464): OK HTTP Server: Unsecure port (80): OK HTTP Server: Secure port (443): OK The following list of ports use UDP protocol and would need to be checked manually: Kerberos KDC: UDP (88): SKIPPED Kerberos Kpasswd: UDP (464): SKIPPED Connection from replica to master is OK. Start listening on required ports for remote master check Get credentials to log in to remote master admin at UNIX.MYDOMAIN.IT password: Execute check on remote master admin at freeipa01.unix.mydomain.it's password: Check connection from master to remote replica 'freeipa04.unix.mydomain.it': Directory Service: Unsecure port (389): OK Directory Service: Secure port (636): OK Kerberos KDC: TCP (88): OK Kerberos KDC: UDP (88): OK Kerberos Kpasswd: TCP (464): OK Kerberos Kpasswd: UDP (464): OK HTTP Server: Unsecure port (80): OK HTTP Server: Secure port (443): OK Connection from master to replica is OK. Connection check OK Configuring ntpd [1/4]: stopping ntpd [2/4]: writing configuration [3/4]: configuring ntpd to start on boot [4/4]: starting ntpd done configuring ntpd. Configuring directory server: Estimated time 1 minute [1/30]: creating directory server user [2/30]: creating directory server instance [3/30]: adding default schema [4/30]: enabling memberof plugin [5/30]: enabling referential integrity plugin [6/30]: enabling winsync plugin [7/30]: configuring replication version plugin [8/30]: enabling IPA enrollment plugin [9/30]: enabling ldapi [10/30]: configuring uniqueness plugin [11/30]: configuring uuid plugin [12/30]: configuring modrdn plugin [13/30]: enabling entryUSN plugin [14/30]: configuring lockout plugin [15/30]: creating indices [16/30]: configuring ssl for ds instance [17/30]: configuring certmap.conf [18/30]: configure autobind for root [19/30]: configure new location for managed entries [20/30]: restarting directory server [21/30]: setting up initial replication Starting replication, please wait until this has completed. Update in progress Update in progress Update in progress Update in progress Update in progress Update succeeded [22/30]: adding replication acis [23/30]: setting Auto Member configuration [24/30]: enabling S4U2Proxy delegation [25/30]: initializing group membership [26/30]: adding master entry [27/30]: configuring Posix uid/gid generation [28/30]: enabling compatibility plugin [29/30]: tuning directory server [30/30]: configuring directory to start on boot done configuring dirsrv. Configuring Kerberos KDC: Estimated time 30 seconds [1/9]: adding sasl mappings to the directory [2/9]: writing stash file from DS [3/9]: configuring KDC [4/9]: creating a keytab for the directory [5/9]: creating a keytab for the machine [6/9]: adding the password extension to the directory [7/9]: enable GSSAPI for replication [8/9]: starting the KDC [9/9]: configuring KDC to start on boot done configuring krb5kdc. Configuring kadmin [1/2]: starting kadmin [2/2]: configuring kadmin to start on boot done configuring kadmin. Configuring ipa_memcached [1/2]: starting ipa_memcached [2/2]: configuring ipa_memcached to start on boot done configuring ipa_memcached. Configuring the web interface: Estimated time 1 minute [1/13]: disabling mod_ssl in httpd [2/13]: setting mod_nss port to 443 [3/13]: setting mod_nss password file [4/13]: enabling mod_nss renegotiate [5/13]: adding URL rewriting rules [6/13]: configuring httpd [7/13]: setting up ssl [8/13]: publish CA cert [9/13]: creating a keytab for httpd [10/13]: clean up any existing httpd ccache [11/13]: configuring SELinux for httpd [12/13]: restarting httpd [13/13]: configuring httpd to start on boot done configuring httpd. Applying LDAP updates Restarting the directory server Restarting the KDC Restarting the web server Using reverse zone 146.168.192.in-addr.arpa. Configuring named: [1/8]: adding NS record to the zone [2/8]: setting up reverse zone [3/8]: setting up our own record [4/8]: setting up kerberos principal [5/8]: setting up named.conf [6/8]: restarting named [7/8]: configuring named to start on boot [8/8]: changing resolv.conf to point to ourselves done configuring named. Configuration of client side components failed! ipa-client-install returned: Command '/usr/sbin/ipa-client-install --on-master --unattended --domain unix.mydomain.it --server freeipa04.unix.mydomain.it --realm UNIX.MYDOMAIN.IT' returned non-zero exit status 1 creation of replica failed: Failed to configure the client Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. [root at freeipa04 ~]# And these are my last lines of the file /var/log/ipaclient-install.log [cut] 2012-03-25T15:13:40Z DEBUG stdout=Kerberos 5 version 1.9.3 2012-03-25T15:13:40Z DEBUG stderr= 2012-03-25T15:13:40Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/role.py' 2012-03-25T15:13:40Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/selfservice.py' 2012-03-25T15:13:40Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/selinuxusermap.py' 2012-03-25T15:13:40Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/service.py' 2012-03-25T15:13:40Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/sudocmd.py' 2012-03-25T15:13:40Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/sudocmdgroup.py' 2012-03-25T15:13:40Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/sudorule.py' 2012-03-25T15:13:40Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/user.py' 2012-03-25T15:13:40Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/virtual.py' 2012-03-25T15:13:40Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/xmlclient.py' 2012-03-25T15:13:42Z DEBUG Backing up system configuration file '/etc/sssd/sssd.conf' 2012-03-25T15:13:42Z DEBUG Saving Index File to '/var/lib/ipa-client/sysrestore/sysrestore.index' 2012-03-25T15:13:42Z DEBUG Unable to activate the SSH service in SSSD config. 2012-03-25T15:13:42Z DEBUG args=/usr/bin/certutil -A -d /etc/pki/nssdb -n IPA CA -t CT,C,C -a -i /etc/ipa/ca.crt 2012-03-25T15:13:42Z DEBUG stdout= 2012-03-25T15:13:42Z DEBUG stderr=certutil: could not add certificate to token or database: Error adding certificate to database. I tried to manually execute the command "/usr/bin/certutil -A -d /etc/pki/nssdb -n IPA CA -t CT,C,C -a -i /etc/ipa/ca.crt" [root at freeipa04 ~]# /usr/bin/certutil -A -d /etc/pki/nssdb -n IPA CA -t CT,C,C -a -i /etc/ipa/ca.crt [root at freeipa04 ~]# echo $? 0 Any help? Thanks in advance as usual Marco -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Mon Mar 26 06:43:23 2012 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 26 Mar 2012 08:43:23 +0200 Subject: [Freeipa-users] Error during ipa-replica-install In-Reply-To: References: <1332413435.10439.18.camel@balmora.brq.redhat.com> Message-ID: <1332744203.6363.6.camel@balmora.brq.redhat.com> On Sun, 2012-03-25 at 15:55 +0200, Marco Pizzoli wrote: > Hi Martin, > > On Thu, Mar 22, 2012 at 11:50 AM, Martin Kosek > wrote: > Hello Marco, > > judging from the output you sent, it looks like you had an > installed > replica on freeipa03, then stopped it with "ipactl" stop and > after that > tried to run ipa-replica-install again - krb5.conf > and /var/log/messages > you sent would support this theory. > > IPA replica agreement should be first removed with > "ipa-replica-manage > del " on freeipa01 and then uninstalled with > "ipa-server-install --uninstall" before you try to install it > again. > > > Thanks for your answer. > I tried what you suggested, but this is what I'm getting now: > > > [root at freeipa01 ~]# ipa-replica-manage -v list > freeipa01.unix.mydomain.it: master > freeipa03.unix.mydomain.it: master > [root at freeipa01 ~]# ipa-replica-manage -v del > freeipa03.unix.mydomain.it > Unable to delete replica freeipa03.unix.mydomain.it: {'desc': "Can't > contact LDAP server"} > [root at freeipa01 ~]# ps -ef|grep slap > dirsrv 1149 1 0 15:30 ? 00:00:01 /usr/sbin/ns-slapd > -D /etc/dirsrv/slapd-UNIX-MYDOMAIN-IT > -i /var/run/dirsrv/slapd-UNIX-MYDOMAIN-IT.pid > -w /var/run/dirsrv/slapd-UNIX-MYDOMAIN-IT.startpid > pkisrv 1150 1 0 15:30 ? 00:00:00 /usr/sbin/ns-slapd > -D /etc/dirsrv/slapd-PKI-IPA -i /var/run/dirsrv/slapd-PKI-IPA.pid > -w /var/run/dirsrv/slapd-PKI-IPA.startpid > > > After little investigation (should worth a more descriptive output? > ^_^) I found the LDAP server being asked was the freeipa03 one. > Yes, it was not running at the moment I executed the command. > > > I went to freeipa03 and tried to "systemctl start dirsrv.target". > This is what I have in my /var/log/messages log: > > > Mar 25 15:48:50 freeipa03 systemd[1]: Failed to load environment > files: No such file or directory > Mar 25 15:48:50 freeipa03 systemd[1]: dirsrv at UNIX-MYDOMAIN-IT.service > failed to run 'start' task: No such file or directory > Mar 25 15:48:50 freeipa03 systemd[1]: Unit > dirsrv at UNIX-MYDOMAIN-IT.service entered failed state. > > > My dirsrv access and error log files are currently not populated. > > > How can I exit from the tunnel? :-) > > > Thanks in advance again > Marco > Hello Marco, if you want to correctly set up a 2-master configuration, you need to at first properly remove replica agreements between freeipa01 and freeipa03 (which are visible in your "ipa-replica-manage list") and then install the replica on freeipa03: # force is needed as freeipa03 is not running [root at freeipa01 ~]# ipa-replica-manage -v del freeipa03.unix.mydomain.it --force # to get a new fresh replica info file: [root at freeipa01 ~]# ipa-replica-prepare freeipa03.unix.mydomain.it # on freeipa03: [root at freeipa03 ~]# ipa-replica-install Does this help? Martin From marco.pizzoli at gmail.com Mon Mar 26 09:02:41 2012 From: marco.pizzoli at gmail.com (Marco Pizzoli) Date: Mon, 26 Mar 2012 11:02:41 +0200 Subject: [Freeipa-users] Error during ipa-replica-install In-Reply-To: <1332744203.6363.6.camel@balmora.brq.redhat.com> References: <1332413435.10439.18.camel@balmora.brq.redhat.com> <1332744203.6363.6.camel@balmora.brq.redhat.com> Message-ID: On Mon, Mar 26, 2012 at 8:43 AM, Martin Kosek wrote: > On Sun, 2012-03-25 at 15:55 +0200, Marco Pizzoli wrote: > > Hi Martin, > > > > On Thu, Mar 22, 2012 at 11:50 AM, Martin Kosek > > wrote: > > Hello Marco, > > > > judging from the output you sent, it looks like you had an > > installed > > replica on freeipa03, then stopped it with "ipactl" stop and > > after that > > tried to run ipa-replica-install again - krb5.conf > > and /var/log/messages > > you sent would support this theory. > > > > IPA replica agreement should be first removed with > > "ipa-replica-manage > > del " on freeipa01 and then uninstalled with > > "ipa-server-install --uninstall" before you try to install it > > again. > > > > > > Thanks for your answer. > > I tried what you suggested, but this is what I'm getting now: > > > > > > [root at freeipa01 ~]# ipa-replica-manage -v list > > freeipa01.unix.mydomain.it: master > > freeipa03.unix.mydomain.it: master > > [root at freeipa01 ~]# ipa-replica-manage -v del > > freeipa03.unix.mydomain.it > > Unable to delete replica freeipa03.unix.mydomain.it: {'desc': "Can't > > contact LDAP server"} > > [root at freeipa01 ~]# ps -ef|grep slap > > dirsrv 1149 1 0 15:30 ? 00:00:01 /usr/sbin/ns-slapd > > -D /etc/dirsrv/slapd-UNIX-MYDOMAIN-IT > > -i /var/run/dirsrv/slapd-UNIX-MYDOMAIN-IT.pid > > -w /var/run/dirsrv/slapd-UNIX-MYDOMAIN-IT.startpid > > pkisrv 1150 1 0 15:30 ? 00:00:00 /usr/sbin/ns-slapd > > -D /etc/dirsrv/slapd-PKI-IPA -i /var/run/dirsrv/slapd-PKI-IPA.pid > > -w /var/run/dirsrv/slapd-PKI-IPA.startpid > > > > > > After little investigation (should worth a more descriptive output? > > ^_^) I found the LDAP server being asked was the freeipa03 one. > > Yes, it was not running at the moment I executed the command. > > > > > > I went to freeipa03 and tried to "systemctl start dirsrv.target". > > This is what I have in my /var/log/messages log: > > > > > > Mar 25 15:48:50 freeipa03 systemd[1]: Failed to load environment > > files: No such file or directory > > Mar 25 15:48:50 freeipa03 systemd[1]: dirsrv at UNIX-MYDOMAIN-IT.service > > failed to run 'start' task: No such file or directory > > Mar 25 15:48:50 freeipa03 systemd[1]: Unit > > dirsrv at UNIX-MYDOMAIN-IT.service entered failed state. > > > > > > My dirsrv access and error log files are currently not populated. > > > > > > How can I exit from the tunnel? :-) > > > > > > Thanks in advance again > > Marco > > > > Hello Marco, > > if you want to correctly set up a 2-master configuration, you need to at > first properly remove replica agreements between freeipa01 and freeipa03 > (which are visible in your "ipa-replica-manage list") and then install > the replica on freeipa03: > > # force is needed as freeipa03 is not running > [root at freeipa01 ~]# ipa-replica-manage -v del freeipa03.unix.mydomain.it > --force > # to get a new fresh replica info file: > [root at freeipa01 ~]# ipa-replica-prepare freeipa03.unix.mydomain.it > > # on freeipa03: > [root at freeipa03 ~]# ipa-replica-install > > Does this help? > Yes, it helped a lot! replica deleted. Thanks! Marco > Martin > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danieljamesscott at gmail.com Mon Mar 26 19:01:07 2012 From: danieljamesscott at gmail.com (Dan Scott) Date: Mon, 26 Mar 2012 15:01:07 -0400 Subject: [Freeipa-users] Another CA replica install issue Message-ID: Hi, I'm having another replica CA install issue. Fedora 16 with latest updates applied this morning: ipa-ca-install replica-info-fileserver4.example.com.gpg [snip] Configuring certificate server: Estimated time 3 minutes 30 seconds [1/11]: creating certificate server user [2/11]: creating pki-ca instance [3/11]: configuring certificate server instance root : CRITICAL failed to configure ca instance Command '/usr/bin/perl /usr/bin/pkisilent 'ConfigureCA' '-cs_hostname' 'fileserver4.example.com' '-cs_port' '9445' '-client_certdb_dir' '/tmp/tmp-w8FRe5' '-client_certdb_pwd' XXXXXXXX '-preop_pin' 'zIK3zLWJhhdzciy3HiE3' '-domain_name' 'IPA' '-admin_user' 'admin' '-admin_email' 'root at localhost' '-admin_password' XXXXXXXX '-agent_name' 'ipa-ca-agent' '-agent_key_size' '2048' '-agent_key_type' 'rsa' '-agent_cert_subject' 'CN=ipa-ca-agent,O=EXAMPLE.COM' '-ldap_host' 'fileserver4.example.com' '-ldap_port' '7389' '-bind_dn' 'cn=Directory Manager' '-bind_password' XXXXXXXX '-base_dn' 'o=ipaca' '-db_name' 'ipaca' '-key_size' '2048' '-key_type' 'rsa' '-key_algorithm' 'SHA256withRSA' '-save_p12' 'true' '-backup_pwd' XXXXXXXX '-subsystem_name' 'pki-cad' '-token_name' 'internal' '-ca_subsystem_cert_subject_name' 'CN=CA Subsystem,O=EXAMPLE.COM' '-ca_ocsp_cert_subject_name' 'CN=OCSP Subsystem,O=EXAMPLE.COM' '-ca_server_cert_subject_name' 'CN=fileserver4.example.com,O=EXAMPLE.COM' '-ca_audit_signing_cert_subject_name' 'CN=CA Audit,O=EXAMPLE.COM' '-ca_sign_cert_subject_name' 'CN=Certificate Authority,O=EXAMPLE.COM' '-external' 'false' '-clone' 'true' '-clone_p12_file' 'ca.p12' '-clone_p12_password' XXXXXXXX '-sd_hostname' 'fileserver1.example.com' '-sd_admin_port' '443' '-sd_admin_name' 'admin' '-sd_admin_password' XXXXXXXX '-clone_start_tls' 'true' '-clone_uri' 'https://fileserver1.example.com:443'' returned non-zero exit status 255 creation of replica failed: Configuration of CA failed /var/log/ipareplica-ca-install.log contains: org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 50; White spaces are required between publicId and systemId. 2012-03-26 14:22:36,714 DEBUG Configuration of CA failed File "/usr/sbin/ipa-ca-install", line 157, in main() File "/usr/sbin/ipa-ca-install", line 142, in main (CA, cs) = cainstance.install_replica_ca(config, postinstall=True) File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 1136, in install_replica_ca subject_base=config.subject_base) File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 537, in configure_instance self.start_creation("Configuring certificate server", 210) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 248, in start_creation method() File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 680, in __configure_instance raise RuntimeError('Configuration of CA failed') /var/log/pki-ca/debug contains: [26/Mar/2012:14:22:36][http-9445-2]: SecurityDomainPanel: validating SSL Admin HTTPS . . . [26/Mar/2012:14:22:36][http-9445-2]: WizardPanelBase pingCS: started [26/Mar/2012:14:22:36][http-9445-2]: WizardPanelBase: pingCS: parser failedorg.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 50; White spaces are required between publicId and systemId. [26/Mar/2012:14:22:36][http-9445-2]: SecurityDomainPanel: pingAdminCS no successful response for SSL Admin HTTPS [26/Mar/2012:14:22:36][http-9445-2]: WizardPanelBase getCertChainUsingSecureAdminPort start [26/Mar/2012:14:22:36][http-9445-2]: WizardPanelBase::getCertChainUsingSecureAdminPort() - Exception=org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 50; White spaces are required between publicId and systemId. [26/Mar/2012:14:22:36][http-9445-2]: WizardPanelBase: getCertChainUsingSecureAdminPort: java.io.IOException: org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 50; White spaces are required between publicId and systemId. [26/Mar/2012:14:22:36][http-9445-2]: WizardPanelBase pingCS: started [26/Mar/2012:14:22:36][http-9445-1]: CMSServlet:service() uri = /ca/admin/ca/getStatus [26/Mar/2012:14:22:36][http-9445-1]: CMSServlet: caGetStatus start to service. [26/Mar/2012:14:22:36][http-9445-2]: WizardPanelBase pingCS: got XML parsed [26/Mar/2012:14:22:36][http-9445-2]: WizardPanelBase pingCS: state=0 [26/Mar/2012:14:22:36][http-9445-2]: panel no=3 [26/Mar/2012:14:22:36][http-9445-2]: panel name=securitydomain [26/Mar/2012:14:22:36][http-9445-2]: total number of panels=19 [26/Mar/2012:14:22:36][http-9445-2]: WizardServlet: found xml [26/Mar/2012:14:22:36][http-9445-2]: Error: unknown type org.apache.catalina.connector.ResponseFacade [26/Mar/2012:14:22:36][http-9445-2]: Error: unknown type org.apache.catalina.connector.RequestFacade [26/Mar/2012:14:22:36][http-9445-1]: CMSServlet: curDate=Mon Mar 26 14:22:36 EDT 2012 id=caGetStatus time=13 I found a SELinux error: type=AVC msg=audit(1332788252.062:222): avc: denied { name_connect } for pid=3042 comm="java" dest=43323 scontext=system_u:system_r:pki_ca_t:s0 tcontext=system_u:object_r:ephemeral_port_t:s0 tclass=tcp_socket But the install still failed in the same way after I put SELinux into enforcing mode. Thanks, Dan Scott From rcritten at redhat.com Mon Mar 26 19:53:42 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 26 Mar 2012 15:53:42 -0400 Subject: [Freeipa-users] Another CA replica install issue In-Reply-To: References: Message-ID: <4F70C946.3060801@redhat.com> Dan Scott wrote: > Hi, > > I'm having another replica CA install issue. Fedora 16 with latest > updates applied this morning: > > ipa-ca-install replica-info-fileserver4.example.com.gpg > > [snip] > > Configuring certificate server: Estimated time 3 minutes 30 seconds > [1/11]: creating certificate server user > [2/11]: creating pki-ca instance > [3/11]: configuring certificate server instance > root : CRITICAL failed to configure ca instance Command > '/usr/bin/perl /usr/bin/pkisilent 'ConfigureCA' '-cs_hostname' > 'fileserver4.example.com' '-cs_port' '9445' '-client_certdb_dir' > '/tmp/tmp-w8FRe5' '-client_certdb_pwd' XXXXXXXX '-preop_pin' > 'zIK3zLWJhhdzciy3HiE3' '-domain_name' 'IPA' '-admin_user' 'admin' > '-admin_email' 'root at localhost' '-admin_password' XXXXXXXX > '-agent_name' 'ipa-ca-agent' '-agent_key_size' '2048' > '-agent_key_type' 'rsa' '-agent_cert_subject' > 'CN=ipa-ca-agent,O=EXAMPLE.COM' '-ldap_host' 'fileserver4.example.com' > '-ldap_port' '7389' '-bind_dn' 'cn=Directory Manager' '-bind_password' > XXXXXXXX '-base_dn' 'o=ipaca' '-db_name' 'ipaca' '-key_size' '2048' > '-key_type' 'rsa' '-key_algorithm' 'SHA256withRSA' '-save_p12' 'true' > '-backup_pwd' XXXXXXXX '-subsystem_name' 'pki-cad' '-token_name' > 'internal' '-ca_subsystem_cert_subject_name' 'CN=CA > Subsystem,O=EXAMPLE.COM' '-ca_ocsp_cert_subject_name' 'CN=OCSP > Subsystem,O=EXAMPLE.COM' '-ca_server_cert_subject_name' > 'CN=fileserver4.example.com,O=EXAMPLE.COM' > '-ca_audit_signing_cert_subject_name' 'CN=CA Audit,O=EXAMPLE.COM' > '-ca_sign_cert_subject_name' 'CN=Certificate Authority,O=EXAMPLE.COM' > '-external' 'false' '-clone' 'true' '-clone_p12_file' 'ca.p12' > '-clone_p12_password' XXXXXXXX '-sd_hostname' > 'fileserver1.example.com' '-sd_admin_port' '443' '-sd_admin_name' > 'admin' '-sd_admin_password' XXXXXXXX '-clone_start_tls' 'true' > '-clone_uri' 'https://fileserver1.example.com:443'' returned non-zero > exit status 255 > creation of replica failed: Configuration of CA failed > > /var/log/ipareplica-ca-install.log contains: > > org.xml.sax.SAXParseException; lineNumber: 1; > columnNumber: 50; White spaces are required between publicId and > systemId. > > 2012-03-26 14:22:36,714 DEBUG Configuration of CA failed > File "/usr/sbin/ipa-ca-install", line 157, in > main() > > File "/usr/sbin/ipa-ca-install", line 142, in main > (CA, cs) = cainstance.install_replica_ca(config, postinstall=True) > > File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", > line 1136, in install_replica_ca > subject_base=config.subject_base) > > File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", > line 537, in configure_instance > self.start_creation("Configuring certificate server", 210) > > File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", > line 248, in start_creation > method() > > File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", > line 680, in __configure_instance > raise RuntimeError('Configuration of CA failed') > > /var/log/pki-ca/debug contains: > > [26/Mar/2012:14:22:36][http-9445-2]: SecurityDomainPanel: validating > SSL Admin HTTPS . . . > [26/Mar/2012:14:22:36][http-9445-2]: WizardPanelBase pingCS: started > [26/Mar/2012:14:22:36][http-9445-2]: WizardPanelBase: pingCS: parser > failedorg.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 50; > White spaces are required between publicId and systemId. > [26/Mar/2012:14:22:36][http-9445-2]: SecurityDomainPanel: pingAdminCS > no successful response for SSL Admin HTTPS > [26/Mar/2012:14:22:36][http-9445-2]: WizardPanelBase > getCertChainUsingSecureAdminPort start > [26/Mar/2012:14:22:36][http-9445-2]: > WizardPanelBase::getCertChainUsingSecureAdminPort() - > Exception=org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: > 50; White spaces are required between publicId and systemId. > [26/Mar/2012:14:22:36][http-9445-2]: WizardPanelBase: > getCertChainUsingSecureAdminPort: java.io.IOException: > org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 50; White > spaces are required between publicId and systemId. > [26/Mar/2012:14:22:36][http-9445-2]: WizardPanelBase pingCS: started > [26/Mar/2012:14:22:36][http-9445-1]: CMSServlet:service() uri = > /ca/admin/ca/getStatus > [26/Mar/2012:14:22:36][http-9445-1]: CMSServlet: caGetStatus start to service. > [26/Mar/2012:14:22:36][http-9445-2]: WizardPanelBase pingCS: got XML parsed > [26/Mar/2012:14:22:36][http-9445-2]: WizardPanelBase pingCS: state=0 > [26/Mar/2012:14:22:36][http-9445-2]: panel no=3 > [26/Mar/2012:14:22:36][http-9445-2]: panel name=securitydomain > [26/Mar/2012:14:22:36][http-9445-2]: total number of panels=19 > [26/Mar/2012:14:22:36][http-9445-2]: WizardServlet: found xml > [26/Mar/2012:14:22:36][http-9445-2]: Error: unknown type > org.apache.catalina.connector.ResponseFacade > [26/Mar/2012:14:22:36][http-9445-2]: Error: unknown type > org.apache.catalina.connector.RequestFacade > [26/Mar/2012:14:22:36][http-9445-1]: CMSServlet: curDate=Mon Mar 26 > 14:22:36 EDT 2012 id=caGetStatus time=13 > > I found a SELinux error: > > type=AVC msg=audit(1332788252.062:222): avc: denied { name_connect } > for pid=3042 comm="java" dest=43323 > scontext=system_u:system_r:pki_ca_t:s0 > tcontext=system_u:object_r:ephemeral_port_t:s0 tclass=tcp_socket > > But the install still failed in the same way after I put SELinux into > enforcing mode. I assume you mean you set it to permissive mode? What about /var/log/ipareplica-ca-install.log, what is at the end of that? rob From danieljamesscott at gmail.com Mon Mar 26 20:17:30 2012 From: danieljamesscott at gmail.com (Dan Scott) Date: Mon, 26 Mar 2012 16:17:30 -0400 Subject: [Freeipa-users] Another CA replica install issue In-Reply-To: <4F70C946.3060801@redhat.com> References: <4F70C946.3060801@redhat.com> Message-ID: On Mon, Mar 26, 2012 at 15:53, Rob Crittenden wrote: > Dan Scott wrote: >> >> Hi, >> >> I'm having another replica CA install issue. Fedora 16 with latest >> updates applied this morning: >> >> ipa-ca-install replica-info-fileserver4.example.com.gpg >> >> [snip] >> >> Configuring certificate server: Estimated time 3 minutes 30 seconds >> ? [1/11]: creating certificate server user >> ? [2/11]: creating pki-ca instance >> ? [3/11]: configuring certificate server instance >> root ? ? ? ?: CRITICAL failed to configure ca instance Command >> '/usr/bin/perl /usr/bin/pkisilent 'ConfigureCA' '-cs_hostname' >> 'fileserver4.example.com' '-cs_port' '9445' '-client_certdb_dir' >> '/tmp/tmp-w8FRe5' '-client_certdb_pwd' XXXXXXXX '-preop_pin' >> 'zIK3zLWJhhdzciy3HiE3' '-domain_name' 'IPA' '-admin_user' 'admin' >> '-admin_email' 'root at localhost' '-admin_password' XXXXXXXX >> '-agent_name' 'ipa-ca-agent' '-agent_key_size' '2048' >> '-agent_key_type' 'rsa' '-agent_cert_subject' >> 'CN=ipa-ca-agent,O=EXAMPLE.COM' '-ldap_host' 'fileserver4.example.com' >> '-ldap_port' '7389' '-bind_dn' 'cn=Directory Manager' '-bind_password' >> XXXXXXXX '-base_dn' 'o=ipaca' '-db_name' 'ipaca' '-key_size' '2048' >> '-key_type' 'rsa' '-key_algorithm' 'SHA256withRSA' '-save_p12' 'true' >> '-backup_pwd' XXXXXXXX '-subsystem_name' 'pki-cad' '-token_name' >> 'internal' '-ca_subsystem_cert_subject_name' 'CN=CA >> Subsystem,O=EXAMPLE.COM' '-ca_ocsp_cert_subject_name' 'CN=OCSP >> Subsystem,O=EXAMPLE.COM' '-ca_server_cert_subject_name' >> 'CN=fileserver4.example.com,O=EXAMPLE.COM' >> '-ca_audit_signing_cert_subject_name' 'CN=CA Audit,O=EXAMPLE.COM' >> '-ca_sign_cert_subject_name' 'CN=Certificate Authority,O=EXAMPLE.COM' >> '-external' 'false' '-clone' 'true' '-clone_p12_file' 'ca.p12' >> '-clone_p12_password' XXXXXXXX '-sd_hostname' >> 'fileserver1.example.com' '-sd_admin_port' '443' '-sd_admin_name' >> 'admin' '-sd_admin_password' XXXXXXXX '-clone_start_tls' 'true' >> '-clone_uri' 'https://fileserver1.example.com:443'' returned non-zero >> exit status 255 >> creation of replica failed: Configuration of CA failed >> >> /var/log/ipareplica-ca-install.log contains: >> >> org.xml.sax.SAXParseException; lineNumber: 1; >> columnNumber: 50; White spaces are required between publicId and >> systemId. >> >> 2012-03-26 14:22:36,714 DEBUG Configuration of CA failed >> ? File "/usr/sbin/ipa-ca-install", line 157, in >> ? ? main() >> >> ? File "/usr/sbin/ipa-ca-install", line 142, in main >> ? ? (CA, cs) = cainstance.install_replica_ca(config, postinstall=True) >> >> ? File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", >> line 1136, in install_replica_ca >> ? ? subject_base=config.subject_base) >> >> ? File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", >> line 537, in configure_instance >> ? ? self.start_creation("Configuring certificate server", 210) >> >> ? File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >> line 248, in start_creation >> ? ? method() >> >> ? File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", >> line 680, in __configure_instance >> ? ? raise RuntimeError('Configuration of CA failed') >> >> /var/log/pki-ca/debug contains: >> >> [26/Mar/2012:14:22:36][http-9445-2]: SecurityDomainPanel: validating >> SSL Admin HTTPS . . . >> [26/Mar/2012:14:22:36][http-9445-2]: WizardPanelBase pingCS: started >> [26/Mar/2012:14:22:36][http-9445-2]: WizardPanelBase: pingCS: parser >> failedorg.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 50; >> White spaces are required between publicId and systemId. >> [26/Mar/2012:14:22:36][http-9445-2]: SecurityDomainPanel: pingAdminCS >> no successful response for SSL Admin HTTPS >> [26/Mar/2012:14:22:36][http-9445-2]: WizardPanelBase >> getCertChainUsingSecureAdminPort start >> [26/Mar/2012:14:22:36][http-9445-2]: >> WizardPanelBase::getCertChainUsingSecureAdminPort() - >> Exception=org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: >> 50; White spaces are required between publicId and systemId. >> [26/Mar/2012:14:22:36][http-9445-2]: WizardPanelBase: >> getCertChainUsingSecureAdminPort: java.io.IOException: >> org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 50; White >> spaces are required between publicId and systemId. >> [26/Mar/2012:14:22:36][http-9445-2]: WizardPanelBase pingCS: started >> [26/Mar/2012:14:22:36][http-9445-1]: CMSServlet:service() uri = >> /ca/admin/ca/getStatus >> [26/Mar/2012:14:22:36][http-9445-1]: CMSServlet: caGetStatus start to >> service. >> [26/Mar/2012:14:22:36][http-9445-2]: WizardPanelBase pingCS: got XML >> parsed >> [26/Mar/2012:14:22:36][http-9445-2]: WizardPanelBase pingCS: state=0 >> [26/Mar/2012:14:22:36][http-9445-2]: panel no=3 >> [26/Mar/2012:14:22:36][http-9445-2]: panel name=securitydomain >> [26/Mar/2012:14:22:36][http-9445-2]: total number of panels=19 >> [26/Mar/2012:14:22:36][http-9445-2]: WizardServlet: found xml >> [26/Mar/2012:14:22:36][http-9445-2]: Error: unknown type >> org.apache.catalina.connector.ResponseFacade >> [26/Mar/2012:14:22:36][http-9445-2]: Error: unknown type >> org.apache.catalina.connector.RequestFacade >> [26/Mar/2012:14:22:36][http-9445-1]: CMSServlet: curDate=Mon Mar 26 >> 14:22:36 EDT 2012 id=caGetStatus time=13 >> >> I found a SELinux error: >> >> type=AVC msg=audit(1332788252.062:222): avc: ?denied ?{ name_connect } >> for ?pid=3042 comm="java" dest=43323 >> scontext=system_u:system_r:pki_ca_t:s0 >> tcontext=system_u:object_r:ephemeral_port_t:s0 tclass=tcp_socket >> >> But the install still failed in the same way after I put SELinux into >> enforcing mode. > > > I assume you mean you set it to permissive mode? Yes, sorry. > What about /var/log/ipareplica-ca-install.log, what is at the end of that? The errors from that are in the second part of the message above. Right after the console output and before /var/log/pki-ca/debug Thanks, Dan From Steven.Jones at vuw.ac.nz Mon Mar 26 21:28:39 2012 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Mon, 26 Mar 2012 21:28:39 +0000 Subject: [Freeipa-users] Setting a new directory manager password Message-ID: <833D8E48405E064EBC54C84EC6B36E404CC36B4C@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, Our policy is to have the security manager hold the top most password of AD. There is a requirement that we do the same thing for IPA if possible/practical. So, is there any reason apart from resetting the admin password or replication that I would ever need this password in a day to day context? If not, how would I re-write/change the password? regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 From dpal at redhat.com Mon Mar 26 21:34:20 2012 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 26 Mar 2012 17:34:20 -0400 Subject: [Freeipa-users] Setting a new directory manager password In-Reply-To: <833D8E48405E064EBC54C84EC6B36E404CC36B4C@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E404CC36B4C@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <4F70E0DC.2050105@redhat.com> On 03/26/2012 05:28 PM, Steven Jones wrote: > Hi, > > Our policy is to have the security manager hold the top most password of AD. There is a requirement that we do the same thing for IPA if possible/practical. > > So, is there any reason apart from resetting the admin password or replication that I would ever need this password in a day to day context? As long as you create other administrative accounts and define their permissions as more confined you do not need to use this admin account other than to perform operations on itself. All other functions can be delegated except the DM password of the underlying DS that should be used only if you need to do some low level DS operations in case something went wrong. > If not, how would I re-write/change the password? > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rmeggins at redhat.com Mon Mar 26 21:31:38 2012 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 26 Mar 2012 15:31:38 -0600 Subject: [Freeipa-users] Setting a new directory manager password In-Reply-To: <833D8E48405E064EBC54C84EC6B36E404CC36B4C@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E404CC36B4C@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <4F70E03A.6080405@redhat.com> On 03/26/2012 03:28 PM, Steven Jones wrote: > Hi, > > Our policy is to have the security manager hold the top most password of AD. There is a requirement that we do the same thing for IPA if possible/practical. > > So, is there any reason apart from resetting the admin password or replication that I would ever need this password in a day to day context? > > If not, how would I re-write/change the password? http://port389.org/wiki/Howto:ResetDirMgrPassword > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From Steven.Jones at vuw.ac.nz Mon Mar 26 21:36:51 2012 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Mon, 26 Mar 2012 21:36:51 +0000 Subject: [Freeipa-users] Setting a new directory manager password In-Reply-To: <4F70E0DC.2050105@redhat.com> References: <833D8E48405E064EBC54C84EC6B36E404CC36B4C@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4F70E0DC.2050105@redhat.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E404CC37B7A@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, What needs to be delegated? regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Dmitri Pal [dpal at redhat.com] Sent: Tuesday, 27 March 2012 10:34 a.m. To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Setting a new directory manager password On 03/26/2012 05:28 PM, Steven Jones wrote: > Hi, > > Our policy is to have the security manager hold the top most password of AD. There is a requirement that we do the same thing for IPA if possible/practical. > > So, is there any reason apart from resetting the admin password or replication that I would ever need this password in a day to day context? As long as you create other administrative accounts and define their permissions as more confined you do not need to use this admin account other than to perform operations on itself. All other functions can be delegated except the DM password of the underlying DS that should be used only if you need to do some low level DS operations in case something went wrong. > If not, how would I re-write/change the password? > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, 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 dpal at redhat.com Mon Mar 26 22:52:45 2012 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 26 Mar 2012 18:52:45 -0400 Subject: [Freeipa-users] Setting a new directory manager password In-Reply-To: <833D8E48405E064EBC54C84EC6B36E404CC37B7A@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E404CC36B4C@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4F70E0DC.2050105@redhat.com> <833D8E48405E064EBC54C84EC6B36E404CC37B7A@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <4F70F33D.1040401@redhat.com> On 03/26/2012 05:36 PM, Steven Jones wrote: > Hi, > > What needs to be delegated? May be I misread what you trying to accomplish. Are you talking about DM password or admin account password? DM password is needed for low level DS operations for example if something goes wrong. admin password is need for admin account and since admin account is the only IPA admin created out of box it is need to do all the IPA administration. However you can split the administrative capabilities (delegate) to different low level admins and make admin account not used or owned by the same person who owns the DM password. How you split the responsibilities is up to you. How you do it? Via permission, privilege and role related commands or UI. > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > ________________________________________ > From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Dmitri Pal [dpal at redhat.com] > Sent: Tuesday, 27 March 2012 10:34 a.m. > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Setting a new directory manager password > > On 03/26/2012 05:28 PM, Steven Jones wrote: >> Hi, >> >> Our policy is to have the security manager hold the top most password of AD. There is a requirement that we do the same thing for IPA if possible/practical. >> >> So, is there any reason apart from resetting the admin password or replication that I would ever need this password in a day to day context? > As long as you create other administrative accounts and define their > permissions as more confined you do not need to use this admin account > other than to perform operations on itself. All other functions can be > delegated except the DM password of the underlying DS that should be > used only if you need to do some low level DS operations in case > something went wrong. > >> If not, how would I re-write/change the password? >> >> regards >> >> Steven Jones >> >> Technical Specialist - Linux RHCE >> >> Victoria University, Wellington, NZ >> >> 0064 4 463 6272 >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IPA project, > 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 IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From Steven.Jones at vuw.ac.nz Mon Mar 26 23:03:08 2012 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Mon, 26 Mar 2012 23:03:08 +0000 Subject: [Freeipa-users] Setting a new directory manager password In-Reply-To: <4F70F33D.1040401@redhat.com> References: <833D8E48405E064EBC54C84EC6B36E404CC36B4C@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4F70E0DC.2050105@redhat.com> <833D8E48405E064EBC54C84EC6B36E404CC37B7A@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4F70F33D.1040401@redhat.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E404CC38E18@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, No I was confused, I thought you meant there were some function that the DM held that could be delegated. I expect that the admin user will be deleted as that's an attack vector (however obscure/indirect). I'm really looking at what is considered good AD security practice and looking to see what is appropriate or equivalent in IPA. regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: Dmitri Pal [dpal at redhat.com] Sent: Tuesday, 27 March 2012 11:52 a.m. To: Steven Jones Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Setting a new directory manager password On 03/26/2012 05:36 PM, Steven Jones wrote: > Hi, > > What needs to be delegated? May be I misread what you trying to accomplish. Are you talking about DM password or admin account password? DM password is needed for low level DS operations for example if something goes wrong. admin password is need for admin account and since admin account is the only IPA admin created out of box it is need to do all the IPA administration. However you can split the administrative capabilities (delegate) to different low level admins and make admin account not used or owned by the same person who owns the DM password. How you split the responsibilities is up to you. How you do it? Via permission, privilege and role related commands or UI. > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > ________________________________________ > From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Dmitri Pal [dpal at redhat.com] > Sent: Tuesday, 27 March 2012 10:34 a.m. > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Setting a new directory manager password > > On 03/26/2012 05:28 PM, Steven Jones wrote: >> Hi, >> >> Our policy is to have the security manager hold the top most password of AD. There is a requirement that we do the same thing for IPA if possible/practical. >> >> So, is there any reason apart from resetting the admin password or replication that I would ever need this password in a day to day context? > As long as you create other administrative accounts and define their > permissions as more confined you do not need to use this admin account > other than to perform operations on itself. All other functions can be > delegated except the DM password of the underlying DS that should be > used only if you need to do some low level DS operations in case > something went wrong. > >> If not, how would I re-write/change the password? >> >> regards >> >> Steven Jones >> >> Technical Specialist - Linux RHCE >> >> Victoria University, Wellington, NZ >> >> 0064 4 463 6272 >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IPA project, > 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 IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From Steven.Jones at vuw.ac.nz Tue Mar 27 01:15:33 2012 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Tue, 27 Mar 2012 01:15:33 +0000 Subject: [Freeipa-users] hosts/clients joining IPA but dns updating not working Message-ID: <833D8E48405E064EBC54C84EC6B36E404CC38EA5@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, I just started adding hosts/clients but DNS isnt being updated for the client(s). Screenshot of error is attached.... regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 -------------- next part -------------- A non-text attachment was scrubbed... Name: ipa-add-error-01.jpeg Type: image/jpeg Size: 43189 bytes Desc: ipa-add-error-01.jpeg URL: From oguzyilmazlist at gmail.com Tue Mar 27 08:32:53 2012 From: oguzyilmazlist at gmail.com (Oguz Yilmaz) Date: Tue, 27 Mar 2012 11:32:53 +0300 Subject: [Freeipa-users] Assessment of FreeIPA for local central authentication and user management service for a single server with multiple services in need for AA Message-ID: Hello, I plan to implement a common authentication and authorization system for several Linux applications. My research has redirected me to FreeIPA, and I am happy to know about such a good project. However, I dont have any purpose of managing non-windows computers and users. This is a one gateway box, single machine system. My planned system has several services, Some examples to use that AA system is: xl2tpd, pptpd, openvpn, squid and some custom made web applications. I need the following functions for those services and applications: - User authentication - User roles and authorization (vpnuser, manager, webuser...) - User, role and credentials management (creating users by admin, passsword changes by users,...) - AD and radius sync or proxying AA. The services can be connected to the AA system through an authenticator system binary. Binary is called with user credentials and service requesting AA; and results in grant or reject. System services may use this binary for checking authentication and authorization. Do you think FreeIPA is a good choice? What would you suggest, otherwise? Best Regards, -- Oguz YILMAZ From mkosek at redhat.com Tue Mar 27 09:04:27 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 27 Mar 2012 11:04:27 +0200 Subject: [Freeipa-users] hosts/clients joining IPA but dns updating not working In-Reply-To: <833D8E48405E064EBC54C84EC6B36E404CC38EA5@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E404CC38EA5@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <1332839067.9937.28.camel@balmora.brq.redhat.com> On Tue, 2012-03-27 at 01:15 +0000, Steven Jones wrote: > Hi, > > I just started adding hosts/clients but DNS isnt being updated for the client(s). > > Screenshot of error is attached.... > Hello Steven, there is something wrong with your host keytab. As written in the output, ipa-client-install could not get a TGT for host/vuwunicorh6ws04 at ODS.VUW.AC.NZ and thus nsupdate which performs the DNS update failed. Can you please attach a relevant portion of ipaclient-install.log so that we can get more information about why it failed? Alternatively, you can list credentials in the keytab with this command yourself: # klist -kt /etc/krb5.keytab To test obtaining the TGT from the host keytab and thus reproducing this issue, you can run this command: # kinit -k -t /etc/krb5.keytab host/vuwunicorh6ws04 at ODS.VUW.AC.NZ The command output itself, or KRB5KDC logs in IPA server should provide a hint why the kinit fails. Martin From dpal at redhat.com Tue Mar 27 13:19:11 2012 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 27 Mar 2012 09:19:11 -0400 Subject: [Freeipa-users] Assessment of FreeIPA for local central authentication and user management service for a single server with multiple services in need for AA In-Reply-To: References: Message-ID: <4F71BE4F.8080202@redhat.com> On 03/27/2012 04:32 AM, Oguz Yilmaz wrote: > Hello, > > I plan to implement a common authentication and authorization system > for several Linux applications. My research has redirected me to > FreeIPA, and I am happy to know about such a good project. > > However, I dont have any purpose of managing non-windows computers and > users. This is a one gateway box, single machine system. > > My planned system has several services, Some examples to use that AA > system is: xl2tpd, pptpd, openvpn, squid and some custom made web > applications. > > I need the following functions for those services and applications: > > - User authentication > - User roles and authorization (vpnuser, manager, webuser...) > - User, role and credentials management (creating users by admin, > passsword changes by users,...) > - AD and radius sync or proxying AA. > > The services can be connected to the AA system through an > authenticator system binary. Binary is called with user credentials > and service requesting AA; and results in grant or reject. System > services may use this binary for checking authentication and > authorization. > > Do you think FreeIPA is a good choice? What would you suggest, otherwise? > >From the high level yes it seems like a good choice but devil is in details. IPA does everything you listed but it might do it in a different way from how you envision it. You might find that a pure DS server would be more flexible for you. But it would not be clear up until you give it a try. I suggest you give it a try and make your mind based on the experience and quick evaluation. Looking at your requirements I would bet that IPA would work for you just fine. This authenticator system binary that you mention is it a custom code or something off the shelf? Is it ldap based or uses PAM? Is it something like kinit? > Best Regards, > > > -- > Oguz YILMAZ > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From simo at redhat.com Tue Mar 27 14:03:24 2012 From: simo at redhat.com (Simo Sorce) Date: Tue, 27 Mar 2012 10:03:24 -0400 Subject: [Freeipa-users] Setting a new directory manager password In-Reply-To: <833D8E48405E064EBC54C84EC6B36E404CC38E18@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E404CC36B4C@STAWINCOX10MBX1.staff.vuw.ac.nz> , <4F70E0DC.2050105@redhat.com> <833D8E48405E064EBC54C84EC6B36E404CC37B7A@STAWINCOX10MBX1.staff.vuw.ac.nz> , <4F70F33D.1040401@redhat.com> <833D8E48405E064EBC54C84EC6B36E404CC38E18@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <1332857004.22628.46.camel@willson.li.ssimo.org> On Mon, 2012-03-26 at 23:03 +0000, Steven Jones wrote: > Hi, > > No I was confused, I thought you meant there were some function that > the DM held that could be delegated. I expect that the admin user > will be deleted as that's an attack vector (however obscure/indirect). If you delete the admin user you will completely break your FreeIPA server. Just FYI. Simo. -- Simo Sorce * Red Hat, Inc * New York From Steven.Jones at vuw.ac.nz Tue Mar 27 19:47:17 2012 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Tue, 27 Mar 2012 19:47:17 +0000 Subject: [Freeipa-users] hosts/clients joining IPA but dns updating not working In-Reply-To: <1332839067.9937.28.camel@balmora.brq.redhat.com> References: <833D8E48405E064EBC54C84EC6B36E404CC38EA5@STAWINCOX10MBX1.staff.vuw.ac.nz>, <1332839067.9937.28.camel@balmora.brq.redhat.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E404CC3A51C@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi Its possible the uninstall from one IPA realm didnt work properly before I joined it to another? Anyway I have incl both logs just in case. There is a suggestion that the kerberos ticket isnt right? regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: Martin Kosek [mkosek at redhat.com] Sent: Tuesday, 27 March 2012 10:04 p.m. To: Steven Jones Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] hosts/clients joining IPA but dns updating not working On Tue, 2012-03-27 at 01:15 +0000, Steven Jones wrote: > Hi, > > I just started adding hosts/clients but DNS isnt being updated for the client(s). > > Screenshot of error is attached.... > Hello Steven, there is something wrong with your host keytab. As written in the output, ipa-client-install could not get a TGT for host/vuwunicorh6ws04 at ODS.VUW.AC.NZ and thus nsupdate which performs the DNS update failed. Can you please attach a relevant portion of ipaclient-install.log so that we can get more information about why it failed? Alternatively, you can list credentials in the keytab with this command yourself: # klist -kt /etc/krb5.keytab To test obtaining the TGT from the host keytab and thus reproducing this issue, you can run this command: # kinit -k -t /etc/krb5.keytab host/vuwunicorh6ws04 at ODS.VUW.AC.NZ The command output itself, or KRB5KDC logs in IPA server should provide a hint why the kinit fails. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: ipaclient-install.log Type: application/octet-stream Size: 11069 bytes Desc: ipaclient-install.log URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ipaclient-uninstall.log Type: application/octet-stream Size: 7987 bytes Desc: ipaclient-uninstall.log URL: From Steven.Jones at vuw.ac.nz Tue Mar 27 20:37:20 2012 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Tue, 27 Mar 2012 20:37:20 +0000 Subject: [Freeipa-users] Trying to get my head around Delegating admin permissions and groups Message-ID: <833D8E48405E064EBC54C84EC6B36E404CC3A6A0@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, I want to have 2 trees of user (and, or? host?) groups, one server branch and one desktop as the desktop admins differ from the server admins and have to be kept separate......so that seems to be a high level thing.... So reading the delegation section its unclear if I am in the right place or what permission to give....so for a top level admin I give the manager attribute? to the top group or simply all? or what? looking down the attributes I see things like "cn" so I see nothing that helps me understand.....yep Im lost..... What I need to do is give the desktop admins control over desktops and desktop users but not any over servers and server users and the the server admins the opposite. There are also going to be at least two password policies, one for staff and one for students. After a bit I will have passync from AD for staff so that policy needs to be disabled...also the requirement to reset their password on first login as that's done via AD So is the best way to make a top level group for each of the two trees, delegate this to each admin branch (manager?) to that? and then under that have two groups where I attach each of the password policies? seems logical, but who knows.... Say a group labeled 1 is the top for the server tree with 2 under it for staff server passwords and 3 for student server passwords. Say a group labeled A is the top for the desktop tree with B under it for staff server passwords and C for student server passwords... hope my asci art works.... 2 1< 3 b a< c So a staff password policy is attached to 2 and B and a student password policy is attached to 3 and C? :/ Is this clear? The next Q is doing the nesting, I get confused on which way it goes........1 goes into group 2 and 3 while a goes into b and c? That way 1 has "control over" 2 and 3? which is what I want.... or do 2 and 3 go into 1? cant see taht as 2 and 3 would have the same level as 1? I then have to repeat something similar for the hosts/clients? regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 From dpal at redhat.com Tue Mar 27 21:36:42 2012 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 27 Mar 2012 17:36:42 -0400 Subject: [Freeipa-users] hosts/clients joining IPA but dns updating not working In-Reply-To: <833D8E48405E064EBC54C84EC6B36E404CC3A51C@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E404CC38EA5@STAWINCOX10MBX1.staff.vuw.ac.nz>, <1332839067.9937.28.camel@balmora.brq.redhat.com> <833D8E48405E064EBC54C84EC6B36E404CC3A51C@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <4F7232EA.7090604@redhat.com> On 03/27/2012 03:47 PM, Steven Jones wrote: > Hi > > Its possible the uninstall from one IPA realm didnt work properly before I joined it to another? > > Anyway I have incl both logs just in case. There is a suggestion that the kerberos ticket isnt right? > Seems like the client fails to get its name properly. Something related to the host name resolution is likely not correct. > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > ________________________________________ > From: Martin Kosek [mkosek at redhat.com] > Sent: Tuesday, 27 March 2012 10:04 p.m. > To: Steven Jones > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] hosts/clients joining IPA but dns updating not working > > On Tue, 2012-03-27 at 01:15 +0000, Steven Jones wrote: >> Hi, >> >> I just started adding hosts/clients but DNS isnt being updated for the client(s). >> >> Screenshot of error is attached.... >> > Hello Steven, > > there is something wrong with your host keytab. As written in the > output, ipa-client-install could not get a TGT for > host/vuwunicorh6ws04 at ODS.VUW.AC.NZ and thus nsupdate which performs the > DNS update failed. > > Can you please attach a relevant portion of ipaclient-install.log so > that we can get more information about why it failed? > > Alternatively, you can list credentials in the keytab with this command > yourself: > # klist -kt /etc/krb5.keytab > > To test obtaining the TGT from the host keytab and thus reproducing this > issue, you can run this command: > # kinit -k -t /etc/krb5.keytab host/vuwunicorh6ws04 at ODS.VUW.AC.NZ > > The command output itself, or KRB5KDC logs in IPA server should provide > a hint why the kinit fails. > > Martin > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steven.Jones at vuw.ac.nz Tue Mar 27 21:44:46 2012 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Tue, 27 Mar 2012 21:44:46 +0000 Subject: [Freeipa-users] passwd sync Message-ID: <833D8E48405E064EBC54C84EC6B36E404CC3A6ED@STAWINCOX10MBX1.staff.vuw.ac.nz> Section 7.4.2 on password sync calls for a download of a PassSync.msi...I cannot locate this....so your doc needs updating I think. For the 7.4.2 number 4 point 2 I see uid=passync cn=systemaccounts cn=etc, then the dc= usual bits I assume the two cn='s are "standard"? number 4 point 4 ou=People,dc=example,dc=com is a "standard"? So in my case it would simply be ou=People,dc=ods,dc=vuw,dc=ac,dc=nz ? regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Dmitri Pal [dpal at redhat.com] Sent: Wednesday, 28 March 2012 10:36 a.m. To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] hosts/clients joining IPA but dns updating not working On 03/27/2012 03:47 PM, Steven Jones wrote: Hi Its possible the uninstall from one IPA realm didnt work properly before I joined it to another? Anyway I have incl both logs just in case. There is a suggestion that the kerberos ticket isnt right? Seems like the client fails to get its name properly. Something related to the host name resolution is likely not correct. regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: Martin Kosek [mkosek at redhat.com] Sent: Tuesday, 27 March 2012 10:04 p.m. To: Steven Jones Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] hosts/clients joining IPA but dns updating not working On Tue, 2012-03-27 at 01:15 +0000, Steven Jones wrote: Hi, I just started adding hosts/clients but DNS isnt being updated for the client(s). Screenshot of error is attached.... Hello Steven, there is something wrong with your host keytab. As written in the output, ipa-client-install could not get a TGT for host/vuwunicorh6ws04 at ODS.VUW.AC.NZ and thus nsupdate which performs the DNS update failed. Can you please attach a relevant portion of ipaclient-install.log so that we can get more information about why it failed? Alternatively, you can list credentials in the keytab with this command yourself: # klist -kt /etc/krb5.keytab To test obtaining the TGT from the host keytab and thus reproducing this issue, you can run this command: # kinit -k -t /etc/krb5.keytab host/vuwunicorh6ws04 at ODS.VUW.AC.NZ The command output itself, or KRB5KDC logs in IPA server should provide a hint why the kinit fails. Martin _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steven.Jones at vuw.ac.nz Tue Mar 27 21:49:18 2012 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Tue, 27 Mar 2012 21:49:18 +0000 Subject: [Freeipa-users] passwd sync In-Reply-To: <833D8E48405E064EBC54C84EC6B36E404CC3A6ED@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E404CC3A6ED@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <833D8E48405E064EBC54C84EC6B36E404CC3A70E@STAWINCOX10MBX1.staff.vuw.ac.nz> Or maybe its on the AD so its, ou=People,dc=vuw,dc=ac,dc=nz ? regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Steven Jones [Steven.Jones at vuw.ac.nz] Sent: Wednesday, 28 March 2012 10:44 a.m. To: freeipa-users at redhat.com Subject: [Freeipa-users] passwd sync Section 7.4.2 on password sync calls for a download of a PassSync.msi...I cannot locate this....so your doc needs updating I think. For the 7.4.2 number 4 point 2 I see uid=passync cn=systemaccounts cn=etc, then the dc= usual bits I assume the two cn='s are "standard"? number 4 point 4 ou=People,dc=example,dc=com is a "standard"? So in my case it would simply be ou=People,dc=ods,dc=vuw,dc=ac,dc=nz ? regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Dmitri Pal [dpal at redhat.com] Sent: Wednesday, 28 March 2012 10:36 a.m. To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] hosts/clients joining IPA but dns updating not working On 03/27/2012 03:47 PM, Steven Jones wrote: Hi Its possible the uninstall from one IPA realm didnt work properly before I joined it to another? Anyway I have incl both logs just in case. There is a suggestion that the kerberos ticket isnt right? Seems like the client fails to get its name properly. Something related to the host name resolution is likely not correct. regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: Martin Kosek [mkosek at redhat.com] Sent: Tuesday, 27 March 2012 10:04 p.m. To: Steven Jones Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] hosts/clients joining IPA but dns updating not working On Tue, 2012-03-27 at 01:15 +0000, Steven Jones wrote: Hi, I just started adding hosts/clients but DNS isnt being updated for the client(s). Screenshot of error is attached.... Hello Steven, there is something wrong with your host keytab. As written in the output, ipa-client-install could not get a TGT for host/vuwunicorh6ws04 at ODS.VUW.AC.NZ and thus nsupdate which performs the DNS update failed. Can you please attach a relevant portion of ipaclient-install.log so that we can get more information about why it failed? Alternatively, you can list credentials in the keytab with this command yourself: # klist -kt /etc/krb5.keytab To test obtaining the TGT from the host keytab and thus reproducing this issue, you can run this command: # kinit -k -t /etc/krb5.keytab host/vuwunicorh6ws04 at ODS.VUW.AC.NZ The command output itself, or KRB5KDC logs in IPA server should provide a hint why the kinit fails. Martin _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Tue Mar 27 21:57:26 2012 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 27 Mar 2012 15:57:26 -0600 Subject: [Freeipa-users] passwd sync In-Reply-To: <833D8E48405E064EBC54C84EC6B36E404CC3A6ED@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E404CC3A6ED@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <4F7237C6.5010009@redhat.com> On 03/27/2012 03:44 PM, Steven Jones wrote: > Section 7.4.2 on password sync calls for a download of a > PassSync.msi...I cannot locate this....so your doc needs updating I think. There is a version here http://port389.org/wiki/Download -Windows Password Synchronization > > For the 7.4.2 number 4 point 2 I see uid=passync cn=systemaccounts > cn=etc, then the dc= usual bits > > I assume the two cn='s are "standard"? > > number 4 point 4 ou=People,dc=example,dc=com is a "standard"? > > So in my case it would simply be ou=People,dc=ods,dc=vuw,dc=ac,dc=nz > > ? > > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > ------------------------------------------------------------------------ > *From:* freeipa-users-bounces at redhat.com > [freeipa-users-bounces at redhat.com] on behalf of Dmitri Pal > [dpal at redhat.com] > *Sent:* Wednesday, 28 March 2012 10:36 a.m. > *To:* freeipa-users at redhat.com > *Subject:* Re: [Freeipa-users] hosts/clients joining IPA but dns > updating not working > > On 03/27/2012 03:47 PM, Steven Jones wrote: >> Hi >> >> Its possible the uninstall from one IPA realm didnt work properly before I joined it to another? >> >> Anyway I have incl both logs just in case. There is a suggestion that the kerberos ticket isnt right? >> > > Seems like the client fails to get its name properly. Something > related to the host name resolution is likely not correct. > >> regards >> >> Steven Jones >> >> Technical Specialist - Linux RHCE >> >> Victoria University, Wellington, NZ >> >> 0064 4 463 6272 >> >> ________________________________________ >> From: Martin Kosek [mkosek at redhat.com] >> Sent: Tuesday, 27 March 2012 10:04 p.m. >> To: Steven Jones >> Cc:freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] hosts/clients joining IPA but dns updating not working >> >> On Tue, 2012-03-27 at 01:15 +0000, Steven Jones wrote: >>> Hi, >>> >>> I just started adding hosts/clients but DNS isnt being updated for the client(s). >>> >>> Screenshot of error is attached.... >>> >> Hello Steven, >> >> there is something wrong with your host keytab. As written in the >> output, ipa-client-install could not get a TGT for >> host/vuwunicorh6ws04 at ODS.VUW.AC.NZ and thus nsupdate which performs the >> DNS update failed. >> >> Can you please attach a relevant portion of ipaclient-install.log so >> that we can get more information about why it failed? >> >> Alternatively, you can list credentials in the keytab with this command >> yourself: >> # klist -kt /etc/krb5.keytab >> >> To test obtaining the TGT from the host keytab and thus reproducing this >> issue, you can run this command: >> # kinit -k -t /etc/krb5.keytabhost/vuwunicorh6ws04 at ODS.VUW.AC.NZ >> >> The command output itself, or KRB5KDC logs in IPA server should provide >> a hint why the kinit fails. >> >> Martin >> >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IPA project, > 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 dpal at redhat.com Tue Mar 27 22:07:22 2012 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 27 Mar 2012 18:07:22 -0400 Subject: [Freeipa-users] passwd sync In-Reply-To: <833D8E48405E064EBC54C84EC6B36E404CC3A6ED@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E404CC3A6ED@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <4F723A1A.5060600@redhat.com> On 03/27/2012 05:44 PM, Steven Jones wrote: > Section 7.4.2 on password sync calls for a download of a > PassSync.msi...I cannot locate this....so your doc needs updating I think. > > For the 7.4.2 number 4 point 2 I see uid=passync cn=systemaccounts > cn=etc, then the dc= usual bits > > I assume the two cn='s are "standard"? > > number 4 point 4 ou=People,dc=example,dc=com is a "standard"? > > So in my case it would simply be ou=People,dc=ods,dc=vuw,dc=ac,dc=nz > > ? Isn't it in a separate channel that needs to be added? > > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > ------------------------------------------------------------------------ > *From:* freeipa-users-bounces at redhat.com > [freeipa-users-bounces at redhat.com] on behalf of Dmitri Pal > [dpal at redhat.com] > *Sent:* Wednesday, 28 March 2012 10:36 a.m. > *To:* freeipa-users at redhat.com > *Subject:* Re: [Freeipa-users] hosts/clients joining IPA but dns > updating not working > > On 03/27/2012 03:47 PM, Steven Jones wrote: >> Hi >> >> Its possible the uninstall from one IPA realm didnt work properly before I joined it to another? >> >> Anyway I have incl both logs just in case. There is a suggestion that the kerberos ticket isnt right? >> > > Seems like the client fails to get its name properly. Something > related to the host name resolution is likely not correct. > >> regards >> >> Steven Jones >> >> Technical Specialist - Linux RHCE >> >> Victoria University, Wellington, NZ >> >> 0064 4 463 6272 >> >> ________________________________________ >> From: Martin Kosek [mkosek at redhat.com] >> Sent: Tuesday, 27 March 2012 10:04 p.m. >> To: Steven Jones >> Cc: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] hosts/clients joining IPA but dns updating not working >> >> On Tue, 2012-03-27 at 01:15 +0000, Steven Jones wrote: >>> Hi, >>> >>> I just started adding hosts/clients but DNS isnt being updated for the client(s). >>> >>> Screenshot of error is attached.... >>> >> Hello Steven, >> >> there is something wrong with your host keytab. As written in the >> output, ipa-client-install could not get a TGT for >> host/vuwunicorh6ws04 at ODS.VUW.AC.NZ and thus nsupdate which performs the >> DNS update failed. >> >> Can you please attach a relevant portion of ipaclient-install.log so >> that we can get more information about why it failed? >> >> Alternatively, you can list credentials in the keytab with this command >> yourself: >> # klist -kt /etc/krb5.keytab >> >> To test obtaining the TGT from the host keytab and thus reproducing this >> issue, you can run this command: >> # kinit -k -t /etc/krb5.keytab host/vuwunicorh6ws04 at ODS.VUW.AC.NZ >> >> The command output itself, or KRB5KDC logs in IPA server should provide >> a hint why the kinit fails. >> >> Martin >> >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IPA project, > 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 IPA project, 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 Mar 27 22:09:19 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 27 Mar 2012 18:09:19 -0400 Subject: [Freeipa-users] Trying to get my head around Delegating admin permissions and groups In-Reply-To: <833D8E48405E064EBC54C84EC6B36E404CC3A6A0@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E404CC3A6A0@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <4F723A8F.9000805@redhat.com> Steven Jones wrote: > Hi, > > I want to have 2 trees of user (and, or? host?) groups, one server branch and one desktop as the desktop admins differ from the server admins and have to be kept separate......so that seems to be a high level thing.... > > So reading the delegation section its unclear if I am in the right place or what permission to give....so for a top level admin I give the manager attribute? to the top group or simply all? or what? looking down the attributes I see things like "cn" so I see nothing that helps me understand.....yep Im lost..... > > What I need to do is give the desktop admins control over desktops and desktop users but not any over servers and server users and the the server admins the opposite. > > There are also going to be at least two password policies, one for staff and one for students. After a bit I will have passync from AD for staff so that policy needs to be disabled...also the requirement to reset their password on first login as that's done via AD > > So is the best way to make a top level group for each of the two trees, delegate this to each admin branch (manager?) to that? and then under that have two groups where I attach each of the password policies? seems logical, but who knows.... > > Say a group labeled 1 is the top for the server tree with 2 under it for staff server passwords and 3 for student server passwords. > > Say a group labeled A is the top for the desktop tree with B under it for staff server passwords and C for student server passwords... > > hope my asci art works.... > > 2 > 1< > 3 > > b > a< > c > > So a staff password policy is attached to 2 and B and a student password policy is attached to 3 and C? > > :/ > > Is this clear? > > The next Q is doing the nesting, I get confused on which way it goes........1 goes into group 2 and 3 while a goes into b and c? > > That way 1 has "control over" 2 and 3? which is what I want.... > > or do 2 and 3 go into 1? cant see taht as 2 and 3 would have the same level as 1? > > I then have to repeat something similar for the hosts/clients? IPA has a flat DIT, so all users are stored together, all groups, etc. You cannot use the IPA tools to manage users stored elsewhere in the tree. You can grant permissions via groups and hostgroups, I think that will do what you need. You'll need to craft a series of permissions granting access to modify attributes of members of a group. Then create privileges and roles and assign membership as necessary. So for example you create a couple of groups: DesktopAdmins and DesktopUsers. Assign users as appropriate. It is ok for users to be members of both. Here is how it might look. I'm just creating a permission to modify a few attributes of a class of users but it should point you in the right direction. Create our groups $ ipa group-add desktopusers --desc='Desktop users' $ ipa group-add desktopadmins --desc='Desktop admins' Create a permission to write some user attributes $ ipa permission-add 'Manage desktop users' --memberof=desktopusers --attrs='givenname,sn,telephonenumber' --type=user --permissions=write Create some sample users (yes, one extra user) $ echo password | ipa user-add --first=tim --last=user duser1 --password $ echo password | ipa user-add --first=tim --last=user dadmin1 --password $ echo password | ipa user-add --first=tim --last=user tuser1 --password Assign members to groups $ ipa group-add-member --users=duser1 desktopusers $ ipa group-add-member --users=dadmin1 desktopadmins Create privilege and role $ ipa privilege-add 'Desktop admins' --desc='Desktop admins' $ ipa role-add 'Desktop admins' --desc='Desktop admins' $ ipa privilege-add-permission --permissions='Manage desktop users' 'Desktop admins' $ ipa role-add-privilege --privileges='Desktop admins' 'Desktop admins' Now become a desktop admin and test $ kinit dadmin1 $ ipa user-mod --first=Gary duser1 ---------------------- Modified user "duser1" ---------------------- User login: duser1 First name: Gary Last name: user Home directory: /home/duser1 Login shell: /bin/sh UID: 643800004 GID: 643800004 Account disabled: False Password: True Member of groups: ipausers, desktopusers Kerberos keys available: True $ ipa user-mod --first=Gary tuser1 ipa: ERROR: Insufficient access: Insufficient 'write' privilege to the 'givenName' attribute of entry 'uid=tuser1,cn=users,cn=accounts,dc=example,dc=com'. You can see that it can manage the user we added to desktopusers but not the other user. Things you can't easily do are things like "Create a desktop user". You can't easily do this because the group membership is assigned later. regards rob From rcritten at redhat.com Tue Mar 27 22:16:09 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 27 Mar 2012 18:16:09 -0400 Subject: [Freeipa-users] passwd sync In-Reply-To: <833D8E48405E064EBC54C84EC6B36E404CC3A6ED@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E404CC3A6ED@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <4F723C29.7010507@redhat.com> Steven Jones wrote: > Section 7.4.2 on password sync calls for a download of a > PassSync.msi...I cannot locate this....so your doc needs updating I think. > > For the 7.4.2 number 4 point 2 I see uid=passync cn=systemaccounts > cn=etc, then the dc= usual bits > > I assume the two cn='s are "standard"? It isn't incorrect, if that is what you are asking. cn is a multi-valued attribute. > number 4 point 4 ou=People,dc=example,dc=com is a "standard"? It is merely an example. I think the default location for AD users is ou=Users. > So in my case it would simply be ou=People,dc=ods,dc=vuw,dc=ac,dc=nz You'd want to check with your AD administrator(s). rob From Steven.Jones at vuw.ac.nz Tue Mar 27 22:15:55 2012 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Tue, 27 Mar 2012 22:15:55 +0000 Subject: [Freeipa-users] passwd sync In-Reply-To: <4F723A1A.5060600@redhat.com> References: <833D8E48405E064EBC54C84EC6B36E404CC3A6ED@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4F723A1A.5060600@redhat.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E404CC3A746@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, Dunno, I have raised a ticket with support to clarify where it is, I am unable to find it, the document doesn't say which channel. regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Dmitri Pal [dpal at redhat.com] Sent: Wednesday, 28 March 2012 11:07 a.m. To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] passwd sync On 03/27/2012 05:44 PM, Steven Jones wrote: Section 7.4.2 on password sync calls for a download of a PassSync.msi...I cannot locate this....so your doc needs updating I think. For the 7.4.2 number 4 point 2 I see uid=passync cn=systemaccounts cn=etc, then the dc= usual bits I assume the two cn='s are "standard"? number 4 point 4 ou=People,dc=example,dc=com is a "standard"? So in my case it would simply be ou=People,dc=ods,dc=vuw,dc=ac,dc=nz ? Isn't it in a separate channel that needs to be added? regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Dmitri Pal [dpal at redhat.com] Sent: Wednesday, 28 March 2012 10:36 a.m. To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] hosts/clients joining IPA but dns updating not working On 03/27/2012 03:47 PM, Steven Jones wrote: Hi Its possible the uninstall from one IPA realm didnt work properly before I joined it to another? Anyway I have incl both logs just in case. There is a suggestion that the kerberos ticket isnt right? Seems like the client fails to get its name properly. Something related to the host name resolution is likely not correct. regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: Martin Kosek [mkosek at redhat.com] Sent: Tuesday, 27 March 2012 10:04 p.m. To: Steven Jones Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] hosts/clients joining IPA but dns updating not working On Tue, 2012-03-27 at 01:15 +0000, Steven Jones wrote: Hi, I just started adding hosts/clients but DNS isnt being updated for the client(s). Screenshot of error is attached.... Hello Steven, there is something wrong with your host keytab. As written in the output, ipa-client-install could not get a TGT for host/vuwunicorh6ws04 at ODS.VUW.AC.NZ and thus nsupdate which performs the DNS update failed. Can you please attach a relevant portion of ipaclient-install.log so that we can get more information about why it failed? Alternatively, you can list credentials in the keytab with this command yourself: # klist -kt /etc/krb5.keytab To test obtaining the TGT from the host keytab and thus reproducing this issue, you can run this command: # kinit -k -t /etc/krb5.keytab host/vuwunicorh6ws04 at ODS.VUW.AC.NZ The command output itself, or KRB5KDC logs in IPA server should provide a hint why the kinit fails. Martin _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, 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 IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steven.Jones at vuw.ac.nz Tue Mar 27 22:24:31 2012 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Tue, 27 Mar 2012 22:24:31 +0000 Subject: [Freeipa-users] passwd sync In-Reply-To: <4F723C29.7010507@redhat.com> References: <833D8E48405E064EBC54C84EC6B36E404CC3A6ED@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4F723C29.7010507@redhat.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E404CC3A754@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, We want to do a one way password sync from AD to IPA for staff but not students as they are a different AD domain, can we do a one way sync? Oh wait, also while I can only do one winsync to one AD domain, can I do a password sync from 2 ADs to one IPA domain? 7.4.3 talks about every password change wanting a reset..... So it there a way to disable this for all or some groups of users? I assume passSyncManagersDNs: uid=admin,cn=users,cn=accounts,dc=etc could be, uid=*,cn=staff,cn=accounts,dc=etc...... ? Since Im setting the password complexity in AD and Psync I assume that I simply do not want any policy for most users....but I still will need a global for users who are not in AD. regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: Rob Crittenden [rcritten at redhat.com] Sent: Wednesday, 28 March 2012 11:16 a.m. To: Steven Jones Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] passwd sync Steven Jones wrote: > Section 7.4.2 on password sync calls for a download of a > PassSync.msi...I cannot locate this....so your doc needs updating I think. > > For the 7.4.2 number 4 point 2 I see uid=passync cn=systemaccounts > cn=etc, then the dc= usual bits > > I assume the two cn='s are "standard"? It isn't incorrect, if that is what you are asking. cn is a multi-valued attribute. > number 4 point 4 ou=People,dc=example,dc=com is a "standard"? It is merely an example. I think the default location for AD users is ou=Users. > So in my case it would simply be ou=People,dc=ods,dc=vuw,dc=ac,dc=nz You'd want to check with your AD administrator(s). rob From dpal at redhat.com Tue Mar 27 23:01:21 2012 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 27 Mar 2012 19:01:21 -0400 Subject: [Freeipa-users] passwd sync In-Reply-To: <833D8E48405E064EBC54C84EC6B36E404CC3A754@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E404CC3A6ED@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4F723C29.7010507@redhat.com> <833D8E48405E064EBC54C84EC6B36E404CC3A754@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <4F7246C1.2010003@redhat.com> On 03/27/2012 06:24 PM, Steven Jones wrote: > Hi, > > We want to do a one way password sync from AD to IPA for staff but not students as they are a different AD domain, > > can we do a one way sync? Yes > Oh wait, also while I can only do one winsync to one AD domain, can I do a password sync from 2 ADs to one IPA domain? No. One Domain. IPA can sync only from one AD domain. And it can't sync users back (DS can). > 7.4.3 talks about every password change wanting a reset..... Yes because you need to capture passwords and create hashes in LDAP for that passwords need to be reset and passsync needs to be put on the AD to capture the changes. This is ugly this is why we spending so much time and effort on building trusts so that IPA can just accept AD tickets without any sync. > So it there a way to disable this for all or some groups of users? > > I assume passSyncManagersDNs: uid=admin,cn=users,cn=accounts,dc=etc > > could be, > > uid=*,cn=staff,cn=accounts,dc=etc...... I will leave to Rich to explain this > ? > > Since Im setting the password complexity in AD and Psync I assume that I simply do not want any policy for most users....but I still will need a global for users who are not in AD. Correct > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > ________________________________________ > From: Rob Crittenden [rcritten at redhat.com] > Sent: Wednesday, 28 March 2012 11:16 a.m. > To: Steven Jones > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] passwd sync > > Steven Jones wrote: >> Section 7.4.2 on password sync calls for a download of a >> PassSync.msi...I cannot locate this....so your doc needs updating I think. >> >> For the 7.4.2 number 4 point 2 I see uid=passync cn=systemaccounts >> cn=etc, then the dc= usual bits >> >> I assume the two cn='s are "standard"? > It isn't incorrect, if that is what you are asking. cn is a multi-valued > attribute. > >> number 4 point 4 ou=People,dc=example,dc=com is a "standard"? > It is merely an example. I think the default location for AD users is > ou=Users. > >> So in my case it would simply be ou=People,dc=ods,dc=vuw,dc=ac,dc=nz > You'd want to check with your AD administrator(s). > > rob > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From Steven.Jones at vuw.ac.nz Tue Mar 27 23:19:35 2012 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Tue, 27 Mar 2012 23:19:35 +0000 Subject: [Freeipa-users] Trying to get my head around Delegating admin permissions and groups In-Reply-To: <4F723A8F.9000805@redhat.com> References: <833D8E48405E064EBC54C84EC6B36E404CC3A6A0@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4F723A8F.9000805@redhat.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E404CC3A79B@STAWINCOX10MBX1.staff.vuw.ac.nz> 8><---- Things you can't easily do are things like "Create a desktop user". You can't easily do this because the group membership is assigned later. 8><---- yep, tahst OK I think......Users will be created by our useradmins initially, in AD and then IPA if there is a need for a UID/linux login. Later after I have a one way passsync working I will do a one way winsync agreement such that when the useradmin crates the user in the provisioning system which in turn injects it inot AD that is automatically transmitted to IPA. At that point I would want the desktop admin or useradmin to assign that user to group(s). At least this is how I think we will be working, hopefully that makes sense. regards From rmeggins at redhat.com Wed Mar 28 00:54:22 2012 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 27 Mar 2012 18:54:22 -0600 Subject: [Freeipa-users] passwd sync In-Reply-To: <4F7246C1.2010003@redhat.com> References: <833D8E48405E064EBC54C84EC6B36E404CC3A6ED@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4F723C29.7010507@redhat.com> <833D8E48405E064EBC54C84EC6B36E404CC3A754@STAWINCOX10MBX1.staff.vuw.ac.nz> <4F7246C1.2010003@redhat.com> Message-ID: <4F72613E.10609@redhat.com> On 03/27/2012 05:01 PM, Dmitri Pal wrote: > On 03/27/2012 06:24 PM, Steven Jones wrote: >> Hi, >> >> We want to do a one way password sync from AD to IPA for staff but not students as they are a different AD domain, >> >> can we do a one way sync? > Yes one way sync for everything or one way sync for everything except student passwords? the former is easy, the latter is not possible afaik > >> Oh wait, also while I can only do one winsync to one AD domain, can I do a password sync from 2 ADs to one IPA domain? > No. One Domain. > IPA can sync only from one AD domain. And it can't sync users back (DS can). ipa winsync cannot add users added to IPA to AD - you'll have to add those manually to AD, then they will be in sync for modify operations. > >> 7.4.3 talks about every password change wanting a reset..... > Yes because you need to capture passwords and create hashes in LDAP for > that passwords need to be reset and passsync needs to be put on the AD > to capture the changes. > This is ugly this is why we spending so much time and effort on building > trusts so that IPA can just accept AD tickets without any sync. +1 > >> So it there a way to disable this for all or some groups of users? >> >> I assume passSyncManagersDNs: uid=admin,cn=users,cn=accounts,dc=etc >> >> could be, >> >> uid=*,cn=staff,cn=accounts,dc=etc...... > I will leave to Rich to explain this It cannot be a wildcard: if (strcasecmp(krbcfg->passsync_mgrs[i], bindDN) == 0) { pwdata.changetype = IPA_CHANGETYPE_DSMGR; break; } but it is multivalued. What exactly are you trying to do? Defeat password sync for uid=*,cn=staff,cn=accounts,dc=etc ? Because I don't think passSyncManagersDNs is what you want for that, unless I'm mistaken. > >> ? >> >> Since Im setting the password complexity in AD and Psync I assume that I simply do not want any policy for most users....but I still will need a global for users who are not in AD. > Correct >> regards >> >> Steven Jones >> >> Technical Specialist - Linux RHCE >> >> Victoria University, Wellington, NZ >> >> 0064 4 463 6272 >> >> ________________________________________ >> From: Rob Crittenden [rcritten at redhat.com] >> Sent: Wednesday, 28 March 2012 11:16 a.m. >> To: Steven Jones >> Cc: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] passwd sync >> >> Steven Jones wrote: >>> Section 7.4.2 on password sync calls for a download of a >>> PassSync.msi...I cannot locate this....so your doc needs updating I think. >>> >>> For the 7.4.2 number 4 point 2 I see uid=passync cn=systemaccounts >>> cn=etc, then the dc= usual bits >>> >>> I assume the two cn='s are "standard"? >> It isn't incorrect, if that is what you are asking. cn is a multi-valued >> attribute. >> >>> number 4 point 4 ou=People,dc=example,dc=com is a "standard"? >> It is merely an example. I think the default location for AD users is >> ou=Users. >> >>> So in my case it would simply be ou=People,dc=ods,dc=vuw,dc=ac,dc=nz >> You'd want to check with your AD administrator(s). >> >> rob >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > From Steven.Jones at vuw.ac.nz Wed Mar 28 01:36:08 2012 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Wed, 28 Mar 2012 01:36:08 +0000 Subject: [Freeipa-users] passwd sync In-Reply-To: <4F72613E.10609@redhat.com> References: <833D8E48405E064EBC54C84EC6B36E404CC3A6ED@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4F723C29.7010507@redhat.com> <833D8E48405E064EBC54C84EC6B36E404CC3A754@STAWINCOX10MBX1.staff.vuw.ac.nz> <4F7246C1.2010003@redhat.com>,<4F72613E.10609@redhat.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E404CC3B932@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi Until we collapse the domains into one we will have a one way sync for staff only... I assume because a student does not exist if staff then there will be no sync....they will simply have a linux/IPA password. I dont need anything to go from IPA to AD, its all AD to IPA or manually created in IPA which stays there. "What exactly are you trying to do? Defeat password sync for" - Turn off password policy for everyone. Policy will be controlled by AD or Psync..so the password should come through from AD via passsync with the complexity we want...... regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Rich Megginson [rmeggins at redhat.com] Sent: Wednesday, 28 March 2012 1:54 p.m. To: dpal at redhat.com Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] passwd sync On 03/27/2012 05:01 PM, Dmitri Pal wrote: > On 03/27/2012 06:24 PM, Steven Jones wrote: >> Hi, >> >> We want to do a one way password sync from AD to IPA for staff but not students as they are a different AD domain, >> >> can we do a one way sync? > Yes one way sync for everything or one way sync for everything except student passwords? the former is easy, the latter is not possible afaik > >> Oh wait, also while I can only do one winsync to one AD domain, can I do a password sync from 2 ADs to one IPA domain? > No. One Domain. > IPA can sync only from one AD domain. And it can't sync users back (DS can). ipa winsync cannot add users added to IPA to AD - you'll have to add those manually to AD, then they will be in sync for modify operations. > >> 7.4.3 talks about every password change wanting a reset..... > Yes because you need to capture passwords and create hashes in LDAP for > that passwords need to be reset and passsync needs to be put on the AD > to capture the changes. > This is ugly this is why we spending so much time and effort on building > trusts so that IPA can just accept AD tickets without any sync. +1 > >> So it there a way to disable this for all or some groups of users? >> >> I assume passSyncManagersDNs: uid=admin,cn=users,cn=accounts,dc=etc >> >> could be, >> >> uid=*,cn=staff,cn=accounts,dc=etc...... > I will leave to Rich to explain this It cannot be a wildcard: if (strcasecmp(krbcfg->passsync_mgrs[i], bindDN) == 0) { pwdata.changetype = IPA_CHANGETYPE_DSMGR; break; } but it is multivalued. What exactly are you trying to do? Defeat password sync for uid=*,cn=staff,cn=accounts,dc=etc ? Because I don't think passSyncManagersDNs is what you want for that, unless I'm mistaken. > >> ? >> >> Since Im setting the password complexity in AD and Psync I assume that I simply do not want any policy for most users....but I still will need a global for users who are not in AD. > Correct >> regards >> >> Steven Jones >> >> Technical Specialist - Linux RHCE >> >> Victoria University, Wellington, NZ >> >> 0064 4 463 6272 >> >> ________________________________________ >> From: Rob Crittenden [rcritten at redhat.com] >> Sent: Wednesday, 28 March 2012 11:16 a.m. >> To: Steven Jones >> Cc: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] passwd sync >> >> Steven Jones wrote: >>> Section 7.4.2 on password sync calls for a download of a >>> PassSync.msi...I cannot locate this....so your doc needs updating I think. >>> >>> For the 7.4.2 number 4 point 2 I see uid=passync cn=systemaccounts >>> cn=etc, then the dc= usual bits >>> >>> I assume the two cn='s are "standard"? >> It isn't incorrect, if that is what you are asking. cn is a multi-valued >> attribute. >> >>> number 4 point 4 ou=People,dc=example,dc=com is a "standard"? >> It is merely an example. I think the default location for AD users is >> ou=Users. >> >>> So in my case it would simply be ou=People,dc=ods,dc=vuw,dc=ac,dc=nz >> You'd want to check with your AD administrator(s). >> >> 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 rmeggins at redhat.com Wed Mar 28 01:40:31 2012 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 27 Mar 2012 19:40:31 -0600 Subject: [Freeipa-users] passwd sync In-Reply-To: <833D8E48405E064EBC54C84EC6B36E404CC3B932@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E404CC3A6ED@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4F723C29.7010507@redhat.com> <833D8E48405E064EBC54C84EC6B36E404CC3A754@STAWINCOX10MBX1.staff.vuw.ac.nz> <4F7246C1.2010003@redhat.com>, <4F72613E.10609@redhat.com> <833D8E48405E064EBC54C84EC6B36E404CC3B932@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <4F726C0F.8090602@redhat.com> On 03/27/2012 07:36 PM, Steven Jones wrote: > Hi > > Until we collapse the domains into one we will have a one way sync for staff only... I assume because a student does not exist if staff then there will be no sync....they will simply have a linux/IPA password. > > I dont need anything to go from IPA to AD, its all AD to IPA or manually created in IPA which stays there. ok - then you can just use the oneWaySync feature of 389. > > "What exactly are you trying to do? Defeat password sync for" - Turn off password policy for everyone. Policy will be controlled by AD or Psync..so the password should come through from AD via passsync with the complexity we want...... Not sure how you do that with IPA > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > ________________________________________ > From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Rich Megginson [rmeggins at redhat.com] > Sent: Wednesday, 28 March 2012 1:54 p.m. > To: dpal at redhat.com > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] passwd sync > > On 03/27/2012 05:01 PM, Dmitri Pal wrote: >> On 03/27/2012 06:24 PM, Steven Jones wrote: >>> Hi, >>> >>> We want to do a one way password sync from AD to IPA for staff but not students as they are a different AD domain, >>> >>> can we do a one way sync? >> Yes > one way sync for everything or one way sync for everything except > student passwords? the former is easy, the latter is not possible afaik >>> Oh wait, also while I can only do one winsync to one AD domain, can I do a password sync from 2 ADs to one IPA domain? >> No. One Domain. >> IPA can sync only from one AD domain. And it can't sync users back (DS can). > ipa winsync cannot add users added to IPA to AD - you'll have to add > those manually to AD, then they will be in sync for modify operations. >>> 7.4.3 talks about every password change wanting a reset..... >> Yes because you need to capture passwords and create hashes in LDAP for >> that passwords need to be reset and passsync needs to be put on the AD >> to capture the changes. >> This is ugly this is why we spending so much time and effort on building >> trusts so that IPA can just accept AD tickets without any sync. > +1 >>> So it there a way to disable this for all or some groups of users? >>> >>> I assume passSyncManagersDNs: uid=admin,cn=users,cn=accounts,dc=etc >>> >>> could be, >>> >>> uid=*,cn=staff,cn=accounts,dc=etc...... >> I will leave to Rich to explain this > It cannot be a wildcard: > if (strcasecmp(krbcfg->passsync_mgrs[i], bindDN) == 0) { > pwdata.changetype = IPA_CHANGETYPE_DSMGR; > break; > } > but it is multivalued. > > > What exactly are you trying to do? Defeat password sync for > > uid=*,cn=staff,cn=accounts,dc=etc ? Because I don't think passSyncManagersDNs is what you want for that, unless I'm mistaken. > >>> ? >>> >>> Since Im setting the password complexity in AD and Psync I assume that I simply do not want any policy for most users....but I still will need a global for users who are not in AD. >> Correct >>> regards >>> >>> Steven Jones >>> >>> Technical Specialist - Linux RHCE >>> >>> Victoria University, Wellington, NZ >>> >>> 0064 4 463 6272 >>> >>> ________________________________________ >>> From: Rob Crittenden [rcritten at redhat.com] >>> Sent: Wednesday, 28 March 2012 11:16 a.m. >>> To: Steven Jones >>> Cc: freeipa-users at redhat.com >>> Subject: Re: [Freeipa-users] passwd sync >>> >>> Steven Jones wrote: >>>> Section 7.4.2 on password sync calls for a download of a >>>> PassSync.msi...I cannot locate this....so your doc needs updating I think. >>>> >>>> For the 7.4.2 number 4 point 2 I see uid=passync cn=systemaccounts >>>> cn=etc, then the dc= usual bits >>>> >>>> I assume the two cn='s are "standard"? >>> It isn't incorrect, if that is what you are asking. cn is a multi-valued >>> attribute. >>> >>>> number 4 point 4 ou=People,dc=example,dc=com is a "standard"? >>> It is merely an example. I think the default location for AD users is >>> ou=Users. >>> >>>> So in my case it would simply be ou=People,dc=ods,dc=vuw,dc=ac,dc=nz >>> You'd want to check with your AD administrator(s). >>> >>> 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 simo at redhat.com Wed Mar 28 02:40:54 2012 From: simo at redhat.com (Simo Sorce) Date: Tue, 27 Mar 2012 22:40:54 -0400 Subject: [Freeipa-users] passwd sync In-Reply-To: <4F726C0F.8090602@redhat.com> References: <833D8E48405E064EBC54C84EC6B36E404CC3A6ED@STAWINCOX10MBX1.staff.vuw.ac.nz> , <4F723C29.7010507@redhat.com> <833D8E48405E064EBC54C84EC6B36E404CC3A754@STAWINCOX10MBX1.staff.vuw.ac.nz> <4F7246C1.2010003@redhat.com>, <4F72613E.10609@redhat.com> <833D8E48405E064EBC54C84EC6B36E404CC3B932@STAWINCOX10MBX1.staff.vuw.ac.nz> <4F726C0F.8090602@redhat.com> Message-ID: <1332902454.22628.83.camel@willson.li.ssimo.org> On Tue, 2012-03-27 at 19:40 -0600, Rich Megginson wrote: > On 03/27/2012 07:36 PM, Steven Jones wrote: > > Hi > > > > Until we collapse the domains into one we will have a one way sync for staff only... I assume because a student does not exist if staff then there will be no sync....they will simply have a linux/IPA password. > > > > I dont need anything to go from IPA to AD, its all AD to IPA or manually created in IPA which stays there. > ok - then you can just use the oneWaySync feature of 389. > > > > "What exactly are you trying to do? Defeat password sync for" - Turn off password policy for everyone. Policy will be controlled by AD or Psync..so the password should come through from AD via passsync with the complexity we want...... > Not sure how you do that with IPA passsync uses a user to save passwords in IPA, all you need to do is to make sure that user is one of the passsync managers. When you do that password policy is not enforced at all and the password is taken in as is w/o any check. Simo. -- Simo Sorce * Red Hat, Inc * New York From danieljamesscott at gmail.com Wed Mar 28 17:32:14 2012 From: danieljamesscott at gmail.com (Dan Scott) Date: Wed, 28 Mar 2012 13:32:14 -0400 Subject: [Freeipa-users] Another CA replica install issue In-Reply-To: References: <4F70C946.3060801@redhat.com> Message-ID: Can anyone help with this? Thanks, Dan On Mon, Mar 26, 2012 at 16:17, Dan Scott wrote: > On Mon, Mar 26, 2012 at 15:53, Rob Crittenden wrote: >> Dan Scott wrote: >>> >>> Hi, >>> >>> I'm having another replica CA install issue. Fedora 16 with latest >>> updates applied this morning: >>> >>> ipa-ca-install replica-info-fileserver4.example.com.gpg >>> >>> [snip] >>> >>> Configuring certificate server: Estimated time 3 minutes 30 seconds >>> ? [1/11]: creating certificate server user >>> ? [2/11]: creating pki-ca instance >>> ? [3/11]: configuring certificate server instance >>> root ? ? ? ?: CRITICAL failed to configure ca instance Command >>> '/usr/bin/perl /usr/bin/pkisilent 'ConfigureCA' '-cs_hostname' >>> 'fileserver4.example.com' '-cs_port' '9445' '-client_certdb_dir' >>> '/tmp/tmp-w8FRe5' '-client_certdb_pwd' XXXXXXXX '-preop_pin' >>> 'zIK3zLWJhhdzciy3HiE3' '-domain_name' 'IPA' '-admin_user' 'admin' >>> '-admin_email' 'root at localhost' '-admin_password' XXXXXXXX >>> '-agent_name' 'ipa-ca-agent' '-agent_key_size' '2048' >>> '-agent_key_type' 'rsa' '-agent_cert_subject' >>> 'CN=ipa-ca-agent,O=EXAMPLE.COM' '-ldap_host' 'fileserver4.example.com' >>> '-ldap_port' '7389' '-bind_dn' 'cn=Directory Manager' '-bind_password' >>> XXXXXXXX '-base_dn' 'o=ipaca' '-db_name' 'ipaca' '-key_size' '2048' >>> '-key_type' 'rsa' '-key_algorithm' 'SHA256withRSA' '-save_p12' 'true' >>> '-backup_pwd' XXXXXXXX '-subsystem_name' 'pki-cad' '-token_name' >>> 'internal' '-ca_subsystem_cert_subject_name' 'CN=CA >>> Subsystem,O=EXAMPLE.COM' '-ca_ocsp_cert_subject_name' 'CN=OCSP >>> Subsystem,O=EXAMPLE.COM' '-ca_server_cert_subject_name' >>> 'CN=fileserver4.example.com,O=EXAMPLE.COM' >>> '-ca_audit_signing_cert_subject_name' 'CN=CA Audit,O=EXAMPLE.COM' >>> '-ca_sign_cert_subject_name' 'CN=Certificate Authority,O=EXAMPLE.COM' >>> '-external' 'false' '-clone' 'true' '-clone_p12_file' 'ca.p12' >>> '-clone_p12_password' XXXXXXXX '-sd_hostname' >>> 'fileserver1.example.com' '-sd_admin_port' '443' '-sd_admin_name' >>> 'admin' '-sd_admin_password' XXXXXXXX '-clone_start_tls' 'true' >>> '-clone_uri' 'https://fileserver1.example.com:443'' returned non-zero >>> exit status 255 >>> creation of replica failed: Configuration of CA failed >>> >>> /var/log/ipareplica-ca-install.log contains: >>> >>> org.xml.sax.SAXParseException; lineNumber: 1; >>> columnNumber: 50; White spaces are required between publicId and >>> systemId. >>> >>> 2012-03-26 14:22:36,714 DEBUG Configuration of CA failed >>> ? File "/usr/sbin/ipa-ca-install", line 157, in >>> ? ? main() >>> >>> ? File "/usr/sbin/ipa-ca-install", line 142, in main >>> ? ? (CA, cs) = cainstance.install_replica_ca(config, postinstall=True) >>> >>> ? File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", >>> line 1136, in install_replica_ca >>> ? ? subject_base=config.subject_base) >>> >>> ? File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", >>> line 537, in configure_instance >>> ? ? self.start_creation("Configuring certificate server", 210) >>> >>> ? File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >>> line 248, in start_creation >>> ? ? method() >>> >>> ? File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", >>> line 680, in __configure_instance >>> ? ? raise RuntimeError('Configuration of CA failed') >>> >>> /var/log/pki-ca/debug contains: >>> >>> [26/Mar/2012:14:22:36][http-9445-2]: SecurityDomainPanel: validating >>> SSL Admin HTTPS . . . >>> [26/Mar/2012:14:22:36][http-9445-2]: WizardPanelBase pingCS: started >>> [26/Mar/2012:14:22:36][http-9445-2]: WizardPanelBase: pingCS: parser >>> failedorg.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 50; >>> White spaces are required between publicId and systemId. >>> [26/Mar/2012:14:22:36][http-9445-2]: SecurityDomainPanel: pingAdminCS >>> no successful response for SSL Admin HTTPS >>> [26/Mar/2012:14:22:36][http-9445-2]: WizardPanelBase >>> getCertChainUsingSecureAdminPort start >>> [26/Mar/2012:14:22:36][http-9445-2]: >>> WizardPanelBase::getCertChainUsingSecureAdminPort() - >>> Exception=org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: >>> 50; White spaces are required between publicId and systemId. >>> [26/Mar/2012:14:22:36][http-9445-2]: WizardPanelBase: >>> getCertChainUsingSecureAdminPort: java.io.IOException: >>> org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 50; White >>> spaces are required between publicId and systemId. >>> [26/Mar/2012:14:22:36][http-9445-2]: WizardPanelBase pingCS: started >>> [26/Mar/2012:14:22:36][http-9445-1]: CMSServlet:service() uri = >>> /ca/admin/ca/getStatus >>> [26/Mar/2012:14:22:36][http-9445-1]: CMSServlet: caGetStatus start to >>> service. >>> [26/Mar/2012:14:22:36][http-9445-2]: WizardPanelBase pingCS: got XML >>> parsed >>> [26/Mar/2012:14:22:36][http-9445-2]: WizardPanelBase pingCS: state=0 >>> [26/Mar/2012:14:22:36][http-9445-2]: panel no=3 >>> [26/Mar/2012:14:22:36][http-9445-2]: panel name=securitydomain >>> [26/Mar/2012:14:22:36][http-9445-2]: total number of panels=19 >>> [26/Mar/2012:14:22:36][http-9445-2]: WizardServlet: found xml >>> [26/Mar/2012:14:22:36][http-9445-2]: Error: unknown type >>> org.apache.catalina.connector.ResponseFacade >>> [26/Mar/2012:14:22:36][http-9445-2]: Error: unknown type >>> org.apache.catalina.connector.RequestFacade >>> [26/Mar/2012:14:22:36][http-9445-1]: CMSServlet: curDate=Mon Mar 26 >>> 14:22:36 EDT 2012 id=caGetStatus time=13 >>> >>> I found a SELinux error: >>> >>> type=AVC msg=audit(1332788252.062:222): avc: ?denied ?{ name_connect } >>> for ?pid=3042 comm="java" dest=43323 >>> scontext=system_u:system_r:pki_ca_t:s0 >>> tcontext=system_u:object_r:ephemeral_port_t:s0 tclass=tcp_socket >>> >>> But the install still failed in the same way after I put SELinux into >>> enforcing mode. >> >> >> I assume you mean you set it to permissive mode? > > Yes, sorry. > >> What about /var/log/ipareplica-ca-install.log, what is at the end of that? > > The errors from that are in the second part of the message above. > Right after the console output and before /var/log/pki-ca/debug > > Thanks, > > Dan From rcritten at redhat.com Wed Mar 28 18:50:12 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 28 Mar 2012 14:50:12 -0400 Subject: [Freeipa-users] Another CA replica install issue In-Reply-To: References: <4F70C946.3060801@redhat.com> Message-ID: <4F735D64.1040001@redhat.com> Dan Scott wrote: > Can anyone help with this? > > Thanks, > > Dan > > On Mon, Mar 26, 2012 at 16:17, Dan Scott wrote: >> On Mon, Mar 26, 2012 at 15:53, Rob Crittenden wrote: >>> Dan Scott wrote: >>>> >>>> Hi, >>>> >>>> I'm having another replica CA install issue. Fedora 16 with latest >>>> updates applied this morning: >>>> >>>> ipa-ca-install replica-info-fileserver4.example.com.gpg >>>> >>>> [snip] >>>> >>>> Configuring certificate server: Estimated time 3 minutes 30 seconds >>>> [1/11]: creating certificate server user >>>> [2/11]: creating pki-ca instance >>>> [3/11]: configuring certificate server instance >>>> root : CRITICAL failed to configure ca instance Command >>>> '/usr/bin/perl /usr/bin/pkisilent 'ConfigureCA' '-cs_hostname' >>>> 'fileserver4.example.com' '-cs_port' '9445' '-client_certdb_dir' >>>> '/tmp/tmp-w8FRe5' '-client_certdb_pwd' XXXXXXXX '-preop_pin' >>>> 'zIK3zLWJhhdzciy3HiE3' '-domain_name' 'IPA' '-admin_user' 'admin' >>>> '-admin_email' 'root at localhost' '-admin_password' XXXXXXXX >>>> '-agent_name' 'ipa-ca-agent' '-agent_key_size' '2048' >>>> '-agent_key_type' 'rsa' '-agent_cert_subject' >>>> 'CN=ipa-ca-agent,O=EXAMPLE.COM' '-ldap_host' 'fileserver4.example.com' >>>> '-ldap_port' '7389' '-bind_dn' 'cn=Directory Manager' '-bind_password' >>>> XXXXXXXX '-base_dn' 'o=ipaca' '-db_name' 'ipaca' '-key_size' '2048' >>>> '-key_type' 'rsa' '-key_algorithm' 'SHA256withRSA' '-save_p12' 'true' >>>> '-backup_pwd' XXXXXXXX '-subsystem_name' 'pki-cad' '-token_name' >>>> 'internal' '-ca_subsystem_cert_subject_name' 'CN=CA >>>> Subsystem,O=EXAMPLE.COM' '-ca_ocsp_cert_subject_name' 'CN=OCSP >>>> Subsystem,O=EXAMPLE.COM' '-ca_server_cert_subject_name' >>>> 'CN=fileserver4.example.com,O=EXAMPLE.COM' >>>> '-ca_audit_signing_cert_subject_name' 'CN=CA Audit,O=EXAMPLE.COM' >>>> '-ca_sign_cert_subject_name' 'CN=Certificate Authority,O=EXAMPLE.COM' >>>> '-external' 'false' '-clone' 'true' '-clone_p12_file' 'ca.p12' >>>> '-clone_p12_password' XXXXXXXX '-sd_hostname' >>>> 'fileserver1.example.com' '-sd_admin_port' '443' '-sd_admin_name' >>>> 'admin' '-sd_admin_password' XXXXXXXX '-clone_start_tls' 'true' >>>> '-clone_uri' 'https://fileserver1.example.com:443'' returned non-zero >>>> exit status 255 >>>> creation of replica failed: Configuration of CA failed >>>> >>>> /var/log/ipareplica-ca-install.log contains: >>>> >>>> org.xml.sax.SAXParseException; lineNumber: 1; >>>> columnNumber: 50; White spaces are required between publicId and >>>> systemId. >>>> >>>> 2012-03-26 14:22:36,714 DEBUG Configuration of CA failed >>>> File "/usr/sbin/ipa-ca-install", line 157, in >>>> main() >>>> >>>> File "/usr/sbin/ipa-ca-install", line 142, in main >>>> (CA, cs) = cainstance.install_replica_ca(config, postinstall=True) >>>> >>>> File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", >>>> line 1136, in install_replica_ca >>>> subject_base=config.subject_base) >>>> >>>> File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", >>>> line 537, in configure_instance >>>> self.start_creation("Configuring certificate server", 210) >>>> >>>> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >>>> line 248, in start_creation >>>> method() >>>> >>>> File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", >>>> line 680, in __configure_instance >>>> raise RuntimeError('Configuration of CA failed') >>>> >>>> /var/log/pki-ca/debug contains: >>>> >>>> [26/Mar/2012:14:22:36][http-9445-2]: SecurityDomainPanel: validating >>>> SSL Admin HTTPS . . . >>>> [26/Mar/2012:14:22:36][http-9445-2]: WizardPanelBase pingCS: started >>>> [26/Mar/2012:14:22:36][http-9445-2]: WizardPanelBase: pingCS: parser >>>> failedorg.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 50; >>>> White spaces are required between publicId and systemId. >>>> [26/Mar/2012:14:22:36][http-9445-2]: SecurityDomainPanel: pingAdminCS >>>> no successful response for SSL Admin HTTPS >>>> [26/Mar/2012:14:22:36][http-9445-2]: WizardPanelBase >>>> getCertChainUsingSecureAdminPort start >>>> [26/Mar/2012:14:22:36][http-9445-2]: >>>> WizardPanelBase::getCertChainUsingSecureAdminPort() - >>>> Exception=org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: >>>> 50; White spaces are required between publicId and systemId. >>>> [26/Mar/2012:14:22:36][http-9445-2]: WizardPanelBase: >>>> getCertChainUsingSecureAdminPort: java.io.IOException: >>>> org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 50; White >>>> spaces are required between publicId and systemId. >>>> [26/Mar/2012:14:22:36][http-9445-2]: WizardPanelBase pingCS: started >>>> [26/Mar/2012:14:22:36][http-9445-1]: CMSServlet:service() uri = >>>> /ca/admin/ca/getStatus >>>> [26/Mar/2012:14:22:36][http-9445-1]: CMSServlet: caGetStatus start to >>>> service. >>>> [26/Mar/2012:14:22:36][http-9445-2]: WizardPanelBase pingCS: got XML >>>> parsed >>>> [26/Mar/2012:14:22:36][http-9445-2]: WizardPanelBase pingCS: state=0 >>>> [26/Mar/2012:14:22:36][http-9445-2]: panel no=3 >>>> [26/Mar/2012:14:22:36][http-9445-2]: panel name=securitydomain >>>> [26/Mar/2012:14:22:36][http-9445-2]: total number of panels=19 >>>> [26/Mar/2012:14:22:36][http-9445-2]: WizardServlet: found xml >>>> [26/Mar/2012:14:22:36][http-9445-2]: Error: unknown type >>>> org.apache.catalina.connector.ResponseFacade >>>> [26/Mar/2012:14:22:36][http-9445-2]: Error: unknown type >>>> org.apache.catalina.connector.RequestFacade >>>> [26/Mar/2012:14:22:36][http-9445-1]: CMSServlet: curDate=Mon Mar 26 >>>> 14:22:36 EDT 2012 id=caGetStatus time=13 >>>> >>>> I found a SELinux error: >>>> >>>> type=AVC msg=audit(1332788252.062:222): avc: denied { name_connect } >>>> for pid=3042 comm="java" dest=43323 >>>> scontext=system_u:system_r:pki_ca_t:s0 >>>> tcontext=system_u:object_r:ephemeral_port_t:s0 tclass=tcp_socket >>>> >>>> But the install still failed in the same way after I put SELinux into >>>> enforcing mode. >>> >>> >>> I assume you mean you set it to permissive mode? >> >> Yes, sorry. >> >>> What about /var/log/ipareplica-ca-install.log, what is at the end of that? >> >> The errors from that are in the second part of the message above. >> Right after the console output and before /var/log/pki-ca/debug >> >> Thanks, >> >> Dan Sorry, I meant to respond yesterday. We need more context. This type of error sometimes occurs well before the actual exception. Can we see the full ipareplica-install.log and CA debug log? You can send them to me privately if you wish. rob From Steven.Jones at vuw.ac.nz Wed Mar 28 19:39:23 2012 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Wed, 28 Mar 2012 19:39:23 +0000 Subject: [Freeipa-users] passwd sync Message-ID: <833D8E48405E064EBC54C84EC6B36E404CC3BCE1@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, I have a support call into RH as the passync msi is in the RDS channel so I have no access to it as I have no RDS subscription......so if its "free" as it comes with IPA it needs to be moved. regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 From Steven.Jones at vuw.ac.nz Wed Mar 28 19:50:30 2012 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Wed, 28 Mar 2012 19:50:30 +0000 Subject: [Freeipa-users] passwd sync In-Reply-To: <4F72613E.10609@redhat.com> References: <833D8E48405E064EBC54C84EC6B36E404CC3A6ED@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4F723C29.7010507@redhat.com> <833D8E48405E064EBC54C84EC6B36E404CC3A754@STAWINCOX10MBX1.staff.vuw.ac.nz> <4F7246C1.2010003@redhat.com>,<4F72613E.10609@redhat.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E404CC3BEC2@STAWINCOX10MBX1.staff.vuw.ac.nz> 8><------ It cannot be a wildcard: if (strcasecmp(krbcfg->passsync_mgrs[i], bindDN) == 0) { pwdata.changetype = IPA_CHANGETYPE_DSMGR; break; } but it is multivalued. 8><---------- This is over my head 8><---------- What exactly are you trying to do? Defeat password sync for uid=*,cn=staff,cn=accounts,dc=etc ? Because I don't think passSyncManagersDNs is what you want for that, unless I'm mistaken. 8><-------- Ok, so at present when I setup a new user with a temp password in IPA and give it to the user they have to set a new one on first login to a client. Once password(s) flow through from AD I don't want the reset password feature in IPA to be functional when a user "first" logs in. regards From dpal at redhat.com Wed Mar 28 19:53:32 2012 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 28 Mar 2012 15:53:32 -0400 Subject: [Freeipa-users] passwd sync In-Reply-To: <833D8E48405E064EBC54C84EC6B36E404CC3BEC2@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E404CC3A6ED@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4F723C29.7010507@redhat.com> <833D8E48405E064EBC54C84EC6B36E404CC3A754@STAWINCOX10MBX1.staff.vuw.ac.nz> <4F7246C1.2010003@redhat.com>, <4F72613E.10609@redhat.com> <833D8E48405E064EBC54C84EC6B36E404CC3BEC2@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <4F736C3C.5040205@redhat.com> On 03/28/2012 03:50 PM, Steven Jones wrote: > 8><------ > > It cannot be a wildcard: > if (strcasecmp(krbcfg->passsync_mgrs[i], bindDN) == 0) { > pwdata.changetype = IPA_CHANGETYPE_DSMGR; > break; > } > but it is multivalued. > > 8><---------- > > This is over my head > > 8><---------- > > What exactly are you trying to do? Defeat password sync for > > uid=*,cn=staff,cn=accounts,dc=etc ? Because I don't think passSyncManagersDNs is what you want for that, unless I'm mistaken. > > 8><-------- > > Ok, so at present when I setup a new user with a temp password in IPA and give it to the user they have to set a new one on first login to a client. > > Once password(s) flow through from AD I don't want the reset password feature in IPA to be functional when a user "first" logs in. > > regards > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users I do not think the password reset is required when you sync the users from an external source. Only when you added a new user via CLI or UI or migrated him. -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From Steven.Jones at vuw.ac.nz Wed Mar 28 20:12:30 2012 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Wed, 28 Mar 2012 20:12:30 +0000 Subject: [Freeipa-users] passwd sync In-Reply-To: <4F736C3C.5040205@redhat.com> References: <833D8E48405E064EBC54C84EC6B36E404CC3A6ED@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4F723C29.7010507@redhat.com> <833D8E48405E064EBC54C84EC6B36E404CC3A754@STAWINCOX10MBX1.staff.vuw.ac.nz> <4F7246C1.2010003@redhat.com>, <4F72613E.10609@redhat.com> <833D8E48405E064EBC54C84EC6B36E404CC3BEC2@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4F736C3C.5040205@redhat.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E404CC3BEE3@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, That is cool, but I have not read that anywhere, can we get that bit written into the passsync section? or have I missed it? regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Dmitri Pal [dpal at redhat.com] Sent: Thursday, 29 March 2012 8:53 a.m. To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] passwd sync On 03/28/2012 03:50 PM, Steven Jones wrote: > 8><------ > > It cannot be a wildcard: > if (strcasecmp(krbcfg->passsync_mgrs[i], bindDN) == 0) { > pwdata.changetype = IPA_CHANGETYPE_DSMGR; > break; > } > but it is multivalued. > > 8><---------- > > This is over my head > > 8><---------- > > What exactly are you trying to do? Defeat password sync for > > uid=*,cn=staff,cn=accounts,dc=etc ? Because I don't think passSyncManagersDNs is what you want for that, unless I'm mistaken. > > 8><-------- > > Ok, so at present when I setup a new user with a temp password in IPA and give it to the user they have to set a new one on first login to a client. > > Once password(s) flow through from AD I don't want the reset password feature in IPA to be functional when a user "first" logs in. > > regards > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users I do not think the password reset is required when you sync the users from an external source. Only when you added a new user via CLI or UI or migrated him. -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, 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 natxo.asenjo at gmail.com Wed Mar 28 20:49:14 2012 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Wed, 28 Mar 2012 22:49:14 +0200 Subject: [Freeipa-users] http service keytab for cname virtual host Message-ID: hi, enable a kerberized site with the fqdn is very easy with freeipa but we would like to use virtual hosting and kerberized sites. I have joined a host webserver01.ipa.domain.tld to a ipa realm. I then created a spn HTTP/webserver01.ipa.domain.tld, generated the keytab, configured the apache webserver and it works. Then I created a cname record (vhost) pointing to webserver01.ipa.domain.tld. I enabled virtual hosting in the apache webserver, configured the vhosts without kerberizing anything. Virtual hosts work as expected. But when I enable a kerberized directory in the vhost, then I see this in the log file: [Wed Mar 28 22:02:14 2012] [error] [client 192.168.0.21] gss_acquire_cred() failed: Unspecified GSS failure. Minor code may provide more information (, Permission denied) [Wed Mar 28 22:02:14 2012] [debug] src/mod_auth_kerb.c(1578): [client 192.168.0.21] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos [Wed Mar 28 22:02:14 2012] [debug] src/mod_auth_kerb.c(1578): [client 192.168.0.21] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos [Wed Mar 28 22:02:14 2012] [debug] src/mod_auth_kerb.c(1213): [client 192.168.0.21] Acquiring creds for HTTP at vhost.ipa.domain.tld. When not using vhosts, it works although I see similar debugging info (but instead of HTTP at vhost.ipa.domain.tld, HTTP at webserver01.ipa.domain.tld). So I was wondering if it is possible to do this vhost thing. With the ipa tools I can only add service principals to joined hosts, not to cnames. It would be nice to have. Otherwise we need to have one server per kerberized site, a bit of an overkill really. -- Groeten, natxo -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Wed Mar 28 20:55:53 2012 From: simo at redhat.com (Simo Sorce) Date: Wed, 28 Mar 2012 16:55:53 -0400 Subject: [Freeipa-users] passwd sync In-Reply-To: <833D8E48405E064EBC54C84EC6B36E404CC3BEE3@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E404CC3A6ED@STAWINCOX10MBX1.staff.vuw.ac.nz> , <4F723C29.7010507@redhat.com> <833D8E48405E064EBC54C84EC6B36E404CC3A754@STAWINCOX10MBX1.staff.vuw.ac.nz> <4F7246C1.2010003@redhat.com>, <4F72613E.10609@redhat.com> <833D8E48405E064EBC54C84EC6B36E404CC3BEC2@STAWINCOX10MBX1.staff.vuw.ac.nz> , <4F736C3C.5040205@redhat.com> <833D8E48405E064EBC54C84EC6B36E404CC3BEE3@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <1332968153.22628.125.camel@willson.li.ssimo.org> On Wed, 2012-03-28 at 20:12 +0000, Steven Jones wrote: > Hi, > > That is cool, but I have not read that anywhere, can we get that bit written into the passsync section? or have I missed it? This may shed some light: http://freeipa.org/page/PasswordSynchronization Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Wed Mar 28 21:30:40 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 28 Mar 2012 17:30:40 -0400 Subject: [Freeipa-users] http service keytab for cname virtual host In-Reply-To: References: Message-ID: <4F738300.3010305@redhat.com> Natxo Asenjo wrote: > hi, > > enable a kerberized site with the fqdn is very easy with freeipa but we > would like to use virtual hosting and kerberized sites. > > I have joined a host webserver01.ipa.domain.tld to a ipa realm. I then > created a spn HTTP/webserver01.ipa.domain.tld, generated the keytab, > configured the apache webserver and it works. > > Then I created a cname record (vhost) pointing to > webserver01.ipa.domain.tld. I enabled virtual hosting in the apache > webserver, configured the vhosts without kerberizing anything. Virtual > hosts work as expected. > > But when I enable a kerberized directory in the vhost, then I see this > in the log file: > > [Wed Mar 28 22:02:14 2012] [error] [client 192.168.0.21] > gss_acquire_cred() failed: Unspecified GSS failure. Minor code may > provide more information (, Permission denied) > [Wed Mar 28 22:02:14 2012] [debug] src/mod_auth_kerb.c(1578): [client > 192.168.0.21] kerb_authenticate_user entered with user (NULL) and > auth_type Kerberos > [Wed Mar 28 22:02:14 2012] [debug] src/mod_auth_kerb.c(1578): [client > 192.168.0.21] kerb_authenticate_user entered with user (NULL) and > auth_type Kerberos > [Wed Mar 28 22:02:14 2012] [debug] src/mod_auth_kerb.c(1213): [client > 192.168.0.21] Acquiring creds for HTTP at vhost.ipa.domain.tld. > > When not using vhosts, it works although I see similar debugging info > (but instead of HTTP at vhost.ipa.domain.tld, > HTTP at webserver01.ipa.domain.tld). So I was wondering if it is possible > to do this vhost thing. With the ipa tools I can only add service > principals to joined hosts, not to cnames. > > It would be nice to have. Otherwise we need to have one server per > kerberized site, a bit of an overkill really. You should be able to add a host entry for the vhost, perhaps with the --force flag to let it add w/o a DNS A record. Then you should be able to create the service. rob From simo at redhat.com Wed Mar 28 21:36:17 2012 From: simo at redhat.com (Simo Sorce) Date: Wed, 28 Mar 2012 17:36:17 -0400 Subject: [Freeipa-users] http service keytab for cname virtual host In-Reply-To: References: Message-ID: <1332970577.22628.131.camel@willson.li.ssimo.org> On Wed, 2012-03-28 at 22:49 +0200, Natxo Asenjo wrote: > hi, > > enable a kerberized site with the fqdn is very easy with freeipa but > we would like to use virtual hosting and kerberized sites. > > I have joined a host webserver01.ipa.domain.tld to a ipa realm. I then > created a spn HTTP/webserver01.ipa.domain.tld, generated the keytab, > configured the apache webserver and it works. > > Then I created a cname record (vhost) pointing to > webserver01.ipa.domain.tld. I enabled virtual hosting in the apache > webserver, configured the vhosts without kerberizing anything. Virtual > hosts work as expected. > > But when I enable a kerberized directory in the vhost, then I see this > in the log file: > > [Wed Mar 28 22:02:14 2012] [error] [client 192.168.0.21] > gss_acquire_cred() failed: Unspecified GSS failure. Minor code may > provide more information (, Permission denied) > [Wed Mar 28 22:02:14 2012] [debug] src/mod_auth_kerb.c(1578): [client > 192.168.0.21] kerb_authenticate_user entered with user (NULL) and > auth_type Kerberos > [Wed Mar 28 22:02:14 2012] [debug] src/mod_auth_kerb.c(1578): [client > 192.168.0.21] kerb_authenticate_user entered with user (NULL) and > auth_type Kerberos > [Wed Mar 28 22:02:14 2012] [debug] src/mod_auth_kerb.c(1213): [client > 192.168.0.21] Acquiring creds for HTTP at vhost.ipa.domain.tld. > > When not using vhosts, it works although I see similar debugging info > (but instead of HTTP at vhost.ipa.domain.tld, > HTTP at webserver01.ipa.domain.tld). So I was wondering if it is possible > to do this vhost thing. With the ipa tools I can only add service > principals to joined hosts, not to cnames. > > It would be nice to have. Otherwise we need to have one server per > kerberized site, a bit of an overkill really. CNAMEs should work just fine with the host's HTTP/A-name at REALM key. In fact I just tested a virtual host on my ipa server using a cname and it worked. Can you post your (sanitized) mod_auth_kerb configuration ? Also what browser are you testing with ? If you kdestroy and then kinit clean, and then try to access the server *only* using the CNAME you should see the browser has acquired a ticket for HTTP/A-name, You can use klist to verify. If this works you know it is a server side issue only. If you do not have the ticket, there may be a DNS/browser issue. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Wed Mar 28 23:07:25 2012 From: simo at redhat.com (Simo Sorce) Date: Wed, 28 Mar 2012 19:07:25 -0400 Subject: [Freeipa-users] http service keytab for cname virtual host In-Reply-To: <4F738300.3010305@redhat.com> References: <4F738300.3010305@redhat.com> Message-ID: <1332976045.22628.133.camel@willson.li.ssimo.org> On Wed, 2012-03-28 at 17:30 -0400, Rob Crittenden wrote: > Natxo Asenjo wrote: > > hi, > > > > enable a kerberized site with the fqdn is very easy with freeipa but we > > would like to use virtual hosting and kerberized sites. > > > > I have joined a host webserver01.ipa.domain.tld to a ipa realm. I then > > created a spn HTTP/webserver01.ipa.domain.tld, generated the keytab, > > configured the apache webserver and it works. > > > > Then I created a cname record (vhost) pointing to > > webserver01.ipa.domain.tld. I enabled virtual hosting in the apache > > webserver, configured the vhosts without kerberizing anything. Virtual > > hosts work as expected. > > > > But when I enable a kerberized directory in the vhost, then I see this > > in the log file: > > > > [Wed Mar 28 22:02:14 2012] [error] [client 192.168.0.21] > > gss_acquire_cred() failed: Unspecified GSS failure. Minor code may > > provide more information (, Permission denied) > > [Wed Mar 28 22:02:14 2012] [debug] src/mod_auth_kerb.c(1578): [client > > 192.168.0.21] kerb_authenticate_user entered with user (NULL) and > > auth_type Kerberos > > [Wed Mar 28 22:02:14 2012] [debug] src/mod_auth_kerb.c(1578): [client > > 192.168.0.21] kerb_authenticate_user entered with user (NULL) and > > auth_type Kerberos > > [Wed Mar 28 22:02:14 2012] [debug] src/mod_auth_kerb.c(1213): [client > > 192.168.0.21] Acquiring creds for HTTP at vhost.ipa.domain.tld. > > > > When not using vhosts, it works although I see similar debugging info > > (but instead of HTTP at vhost.ipa.domain.tld, > > HTTP at webserver01.ipa.domain.tld). So I was wondering if it is possible > > to do this vhost thing. With the ipa tools I can only add service > > principals to joined hosts, not to cnames. > > > > It would be nice to have. Otherwise we need to have one server per > > kerberized site, a bit of an overkill really. > > You should be able to add a host entry for the vhost, perhaps with the > --force flag to let it add w/o a DNS A record. Then you should be able > to create the service. This shouldn't be necessary unless the vhost uses an A name, but then you need a key for each vhost, which is burdensome. I would keep this as a last resort after any other avenue failed. Simo. -- Simo Sorce * Red Hat, Inc * New York From natxo.asenjo at gmail.com Thu Mar 29 06:58:37 2012 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Thu, 29 Mar 2012 08:58:37 +0200 Subject: [Freeipa-users] http service keytab for cname virtual host In-Reply-To: <1332970577.22628.131.camel@willson.li.ssimo.org> References: <1332970577.22628.131.camel@willson.li.ssimo.org> Message-ID: On Wed, Mar 28, 2012 at 11:36 PM, Simo Sorce wrote: > > CNAMEs should work just fine with the host's HTTP/A-name at REALM key. > In fact I just tested a virtual host on my ipa server using a cname and > it worked. > great! > Can you post your (sanitized) mod_auth_kerb configuration ? > Also what browser are you testing with ? > sure: ServerName vhost.ipa.domain.tld ServerAdmin webmaster at domain.tld DocumentRoot /var/www/html/vhost1 LogLevel debug CustomLog /var/log/httpd/vhost1.access.log combined ErrorLog /var/log/httpd/vhost1.error.log AuthType Kerberos AuthName "Kerberos Login" KrbMethodNegotiate on KrbMethodK5Passwd off KrbServiceName HTTP KrbAuthRealms IPA.DOMAIN.TLD Krb5KeyTab /etc/httpd/conf/webserver01_http.keytab KrbSaveCredentials on Require valid-user > If you kdestroy and then kinit clean, and then try to access the server > *only* using the CNAME you should see the browser has acquired a ticket > for HTTP/A-name, You can use klist to verify. If this works you know it > is a server side issue only. If you do not have the ticket, there may be > a DNS/browser issue. > yes, I get a HTTP/A-name ticket and a 500 internal server error on the browser. So you are right, we have an apache issue only. If you can shed some light on the the mod_kerb config that will be great. TIA. -- Groeten, Natxo -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Thu Mar 29 11:11:43 2012 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 29 Mar 2012 13:11:43 +0200 Subject: [Freeipa-users] hosts/clients joining IPA but dns updating not working In-Reply-To: <833D8E48405E064EBC54C84EC6B36E404CC3A51C@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E404CC38EA5@STAWINCOX10MBX1.staff.vuw.ac.nz>, <1332839067.9937.28.camel@balmora.brq.redhat.com> <833D8E48405E064EBC54C84EC6B36E404CC3A51C@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <4F74436F.3010707@redhat.com> Hello, please post output from: # klist -kt /etc/krb5.keytab We still need this to better understand logs. I'm not sure if keytab contains right keys. -- Petr Spacek On 03/27/2012 09:47 PM, Steven Jones wrote: > Hi > > Its possible the uninstall from one IPA realm didnt work properly before I joined it to another? > > Anyway I have incl both logs just in case. There is a suggestion that the kerberos ticket isnt right? > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > ________________________________________ > From: Martin Kosek [mkosek at redhat.com] > Sent: Tuesday, 27 March 2012 10:04 p.m. > To: Steven Jones > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] hosts/clients joining IPA but dns updating not working > > On Tue, 2012-03-27 at 01:15 +0000, Steven Jones wrote: >> Hi, >> >> I just started adding hosts/clients but DNS isnt being updated for the client(s). >> >> Screenshot of error is attached.... >> > > Hello Steven, > > there is something wrong with your host keytab. As written in the > output, ipa-client-install could not get a TGT for > host/vuwunicorh6ws04 at ODS.VUW.AC.NZ and thus nsupdate which performs the > DNS update failed. > > Can you please attach a relevant portion of ipaclient-install.log so > that we can get more information about why it failed? > > Alternatively, you can list credentials in the keytab with this command > yourself: > # klist -kt /etc/krb5.keytab > > To test obtaining the TGT from the host keytab and thus reproducing this > issue, you can run this command: > # kinit -k -t /etc/krb5.keytab host/vuwunicorh6ws04 at ODS.VUW.AC.NZ > > The command output itself, or KRB5KDC logs in IPA server should provide > a hint why the kinit fails. > > Martin > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From rcritten at redhat.com Thu Mar 29 12:57:53 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 29 Mar 2012 08:57:53 -0400 Subject: [Freeipa-users] passwd sync In-Reply-To: <833D8E48405E064EBC54C84EC6B36E404CC3BEC2@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E404CC3A6ED@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4F723C29.7010507@redhat.com> <833D8E48405E064EBC54C84EC6B36E404CC3A754@STAWINCOX10MBX1.staff.vuw.ac.nz> <4F7246C1.2010003@redhat.com>, <4F72613E.10609@redhat.com> <833D8E48405E064EBC54C84EC6B36E404CC3BEC2@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <4F745C51.3060103@redhat.com> Steven Jones wrote: > 8><------ > > It cannot be a wildcard: > if (strcasecmp(krbcfg->passsync_mgrs[i], bindDN) == 0) { > pwdata.changetype = IPA_CHANGETYPE_DSMGR; > break; > } > but it is multivalued. > > 8><---------- > > This is over my head > > 8><---------- > > What exactly are you trying to do? Defeat password sync for > > uid=*,cn=staff,cn=accounts,dc=etc ? Because I don't think passSyncManagersDNs is what you want for that, unless I'm mistaken. > > 8><-------- > > Ok, so at present when I setup a new user with a temp password in IPA and give it to the user they have to set a new one on first login to a client. > > Once password(s) flow through from AD I don't want the reset password feature in IPA to be functional when a user "first" logs in. That is what the passsyncmanagersdn does, bypasses policy checks. It doesn't look at the individual entry being replicated, it looks at the user who is bound and doing the replication. rob From simo at redhat.com Thu Mar 29 18:25:56 2012 From: simo at redhat.com (Simo Sorce) Date: Thu, 29 Mar 2012 14:25:56 -0400 Subject: [Freeipa-users] http service keytab for cname virtual host In-Reply-To: References: <1332970577.22628.131.camel@willson.li.ssimo.org> Message-ID: <1333045556.22628.155.camel@willson.li.ssimo.org> On Thu, 2012-03-29 at 08:58 +0200, Natxo Asenjo wrote: > On Wed, Mar 28, 2012 at 11:36 PM, Simo Sorce wrote: > > > CNAMEs should work just fine with the host's HTTP/A-name at REALM > key. > In fact I just tested a virtual host on my ipa server using a > cname and > it worked. > > great! > > > Can you post your (sanitized) mod_auth_kerb configuration ? > Also what browser are you testing with ? > > sure: > > > ServerName vhost.ipa.domain.tld > ServerAdmin webmaster at domain.tld > DocumentRoot /var/www/html/vhost1 > LogLevel debug > CustomLog /var/log/httpd/vhost1.access.log combined > ErrorLog /var/log/httpd/vhost1.error.log > > > AuthType Kerberos > AuthName "Kerberos Login" > KrbMethodNegotiate on > KrbMethodK5Passwd off > KrbServiceName HTTP > KrbAuthRealms IPA.DOMAIN.TLD > Krb5KeyTab /etc/httpd/conf/webserver01_http.keytab > KrbSaveCredentials on > Require valid-user > > > > > If you kdestroy and then kinit clean, and then try to access > the server > *only* using the CNAME you should see the browser has acquired > a ticket > for HTTP/A-name, You can use klist to verify. If this works > you know it > is a server side issue only. If you do not have the ticket, > there may be > a DNS/browser issue. > > yes, I get a HTTP/A-name ticket and a 500 internal server error on the > browser. So you are right, we have an apache issue only. If you can > shed some light on the the mod_kerb config that will be great. > Your configuration looks right, but I went back and looked at your logs and I saw a permission denied error. I would check that the apache user can access the keytab file: /etc/httpd/conf/webserver01_http.keytab If you are using RHEL/Fedora, also check the audit.log file in case the file is mislabeled and SELinux is preventing access to it. Simo. -- Simo Sorce * Red Hat, Inc * New York From natxo.asenjo at gmail.com Thu Mar 29 18:43:13 2012 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Thu, 29 Mar 2012 20:43:13 +0200 Subject: [Freeipa-users] http service keytab for cname virtual host In-Reply-To: <1333045556.22628.155.camel@willson.li.ssimo.org> References: <1332970577.22628.131.camel@willson.li.ssimo.org> <1333045556.22628.155.camel@willson.li.ssimo.org> Message-ID: On Thu, Mar 29, 2012 at 8:25 PM, Simo Sorce wrote: > Your configuration looks right, but I went back and looked at your logs > and I saw a permission denied error. > > I would check that the apache user can access the keytab > file: /etc/httpd/conf/webserver01_http.keytab > If you are using RHEL/Fedora, also check the audit.log file in case the > file is mislabeled and SELinux is preventing access to it. > Bingo! selinux was indeed blocking it. :-) A few years ago I would have inmediately looked at selinux (or even disabled it right away during the installation), but since fedora 12 you guys have actually made it just work (TM), so I never thought of that. This is really awesome, I am thoroughly enjoying ipa. Thanks! -- natxo -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Thu Mar 29 19:09:01 2012 From: simo at redhat.com (Simo Sorce) Date: Thu, 29 Mar 2012 15:09:01 -0400 Subject: [Freeipa-users] http service keytab for cname virtual host In-Reply-To: References: <1332970577.22628.131.camel@willson.li.ssimo.org> <1333045556.22628.155.camel@willson.li.ssimo.org> Message-ID: <1333048141.22628.162.camel@willson.li.ssimo.org> On Thu, 2012-03-29 at 20:43 +0200, Natxo Asenjo wrote: > > On Thu, Mar 29, 2012 at 8:25 PM, Simo Sorce wrote: > Your configuration looks right, but I went back and looked at > your logs > and I saw a permission denied error. > > I would check that the apache user can access the keytab > file: /etc/httpd/conf/webserver01_http.keytab > If you are using RHEL/Fedora, also check the audit.log file in > case the > file is mislabeled and SELinux is preventing access to it. > > Bingo! selinux was indeed blocking it. > > :-) > > A few years ago I would have inmediately looked at selinux (or even > disabled it right away during the installation), but since fedora 12 > you guys have actually made it just work (TM), so I never thought of > that. > > This is really awesome, I am thoroughly enjoying ipa. > Yes SeLinux works well, use audit2allow to make a custom policy or apply the right label and don't disable SELinux please :-) If you have problems we can help, documenting on this list how to properly configure SELinux with IPA related deployments is considered on topic and will make up useful documentation for others. Simo. -- Simo Sorce * Red Hat, Inc * New York From sakodak at gmail.com Fri Mar 30 23:35:32 2012 From: sakodak at gmail.com (KodaK) Date: Fri, 30 Mar 2012 18:35:32 -0500 Subject: [Freeipa-users] AIX client headaches Message-ID: Hello, I'm attempting to configure an AIX 5.3 client, I've followed the instructions (and then some) that are found here: http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/Configuring_an_IPA_Client_on_AIX.html I keep overcoming hurdles (like the documentation asking you in step 3 to authenticate with a user you create in step 11) but now I'm really stuck. I have a user, creatively named "testuser" and the password is of sufficient complexity. I can authenticate with this user to a Linux box that's been configured with the ipa-client, so I'm pretty sure my server configuration is OK. When I connect to an AIX client, though, it tells me: Received disconnect from 10.200.2.68: 2: Too many authentication failures for testuser Here's the output of ssh -v testuser at slnldca01.unix.magellanhealth.com: [jebalicki at mo0031472 ~]$ kinit testuser Password for testuser at UNIX.MAGELLANHEALTH.COM: [jebalicki at mo0031472 ~]$ ssh -v testuser at slnldca01.unix.magellanhealth.com OpenSSH_5.6p1, OpenSSL 1.0.0g-fips 18 Jan 2012 debug1: Reading configuration data /home/jebalicki/.ssh/config debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Connecting to slnldca01.unix.magellanhealth.com [10.200.2.68] port 22. debug1: Connection established. debug1: identity file /home/jebalicki/.ssh/id_rsa type 1 debug1: identity file /home/jebalicki/.ssh/id_rsa-cert type -1 debug1: identity file /home/jebalicki/.ssh/id_dsa type -1 debug1: identity file /home/jebalicki/.ssh/id_dsa-cert type -1 debug1: Remote protocol version 1.99, remote software version OpenSSH_4.1 debug1: match: OpenSSH_4.1 pat OpenSSH_4* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.6 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-ctr hmac-md5 none debug1: kex: client->server aes128-ctr hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host 'slnldca01.unix.magellanhealth.com' is known and matches the RSA host key. debug1: Found key in /home/jebalicki/.ssh/known_hosts:10 debug1: ssh_rsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,gssapi-with-mic,password,keyboard-interactive debug1: Next authentication method: gssapi-with-mic debug1: Authentications that can continue: publickey,gssapi-with-mic,password,keyboard-interactive debug1: Authentications that can continue: publickey,gssapi-with-mic,password,keyboard-interactive debug1: Authentications that can continue: publickey,gssapi-with-mic,password,keyboard-interactive debug1: Authentications that can continue: publickey,gssapi-with-mic,password,keyboard-interactive debug1: Next authentication method: publickey debug1: Offering RSA public key: /home/jebalicki/.ssh/id_rsa debug1: Authentications that can continue: publickey,gssapi-with-mic,password,keyboard-interactive debug1: Trying private key: /home/jebalicki/.ssh/id_dsa debug1: Next authentication method: keyboard-interactive debug1: Authentications that can continue: publickey,gssapi-with-mic,password,keyboard-interactive debug1: Next authentication method: password testuser at slnldca01.unix.magellanhealth.com's password: Received disconnect from 10.200.2.68: 2: Too many authentication failures for testuser Here's the output of sshd -ddd on the AIX client: bash-3.00# /usr/sbin/sshd -dddd debug2: load_server_config: filename /etc/ssh/sshd_config debug2: load_server_config: done config len = 248 debug2: parse_server_config: config /etc/ssh/sshd_config len 248 debug1: sshd version OpenSSH_4.1p1 debug1: private host key: #0 type 0 RSA1 debug3: Not a RSA1 key file /etc/ssh/ssh_host_rsa_key. debug1: read PEM private key done: type RSA debug1: private host key: #1 type 1 RSA debug3: Not a RSA1 key file /etc/ssh/ssh_host_dsa_key. debug1: read PEM private key done: type DSA debug1: private host key: #2 type 2 DSA debug1: rexec_argv[0]='/usr/sbin/sshd' debug1: rexec_argv[1]='-dddd' debug2: fd 3 setting O_NONBLOCK debug1: Bind to port 22 on 0.0.0.0. Server listening on 0.0.0.0 port 22. debug2: fd 4 setting O_NONBLOCK debug1: Bind to port 22 on ::. Bind to port 22 on :: failed: Address already in use. Generating 768 bit RSA key. RSA key generation complete. debug1: fd 4 clearing O_NONBLOCK debug1: Server will not fork when running in debugging mode. debug3: send_rexec_state: entering fd = 7 config len 248 debug3: ssh_msg_send: type 0 debug3: send_rexec_state: done debug1: rexec start in 4 out 4 newsock 4 pipe -1 sock 7 debug1: inetd sockets after dupping: 3, 3 Connection from 10.200.10.117 port 49075 debug1: Client protocol version 2.0; client software version OpenSSH_5.6 debug1: match: OpenSSH_5.6 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-1.99-OpenSSH_4.1 debug1: init_func_ptrs passed debug2: fd 3 setting O_NONBLOCK debug3: privsep user:group 202:201 debug1: permanently_set_uid: 202/201 debug1: list_hostkey_types: ssh-rsa,ssh-dss debug1: SSH2_MSG_KEXINIT sent debug2: Network child is on pid 348394 debug3: preauth child monitor started debug3: mm_request_receive entering debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa-cert-v01 at openssh.com,ssh-dss-cert-v01 at openssh.com,ssh-rsa-cert-v00 at openssh.com,ssh-dss-cert-v00 at openssh.com,ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_init: found hmac-md5 debug1: kex: client->server aes128-ctr hmac-md5 none debug2: mac_init: found hmac-md5 debug1: kex: server->client aes128-ctr hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received debug3: mm_request_send entering: type 0 debug3: mm_choose_dh: waiting for MONITOR_ANS_MODULI debug3: mm_request_receive_expect entering: type 1 debug3: mm_request_receive entering debug3: monitor_read: checking request 0 debug3: mm_answer_moduli: got parameters: 1024 1024 8192 debug3: mm_request_send entering: type 1 debug3: mm_choose_dh: remaining 0 debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent debug2: monitor_read: 0 used once, disabling now debug3: mm_request_receive entering debug2: dh_gen_key: priv key bits set: 130/256 debug2: bits set: 481/1024 debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT debug2: bits set: 505/1024 debug3: mm_key_sign entering debug3: mm_request_send entering: type 4 debug3: mm_key_sign: waiting for MONITOR_ANS_SIGN debug3: monitor_read: checking request 4 debug3: mm_request_receive_expect entering: type 5 debug3: mm_answer_sign debug3: mm_request_receive entering debug3: mm_answer_sign: signature 20042f88(143) debug3: mm_request_send entering: type 5 debug2: monitor_read: 4 used once, disabling now debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent debug3: mm_request_receive entering debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: KEX done debug1: userauth-request for user testuser service ssh-connection method none debug1: attempt 0 failures 0 debug3: mm_getpwnamallow entering debug3: mm_request_send entering: type 6 debug3: mm_getpwnamallow: waiting for MONITOR_ANS_PWNAM debug3: monitor_read: checking request 6 debug3: mm_request_receive_expect entering: type 7 debug3: mm_answer_pwnamallow debug3: mm_request_receive entering debug3: AIX/loginrestrictions returned 0 msg (none) debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 1 debug3: mm_request_send entering: type 7 debug2: monitor_read: 6 used once, disabling now debug2: input_userauth_request: setting up authctxt for testuser debug3: mm_request_receive entering debug3: mm_inform_authserv entering debug3: mm_request_send entering: type 3 debug2: input_userauth_request: try method none debug3: monitor_read: checking request 3 debug3: mm_auth_password entering debug3: mm_answer_authserv: service=ssh-connection, style= debug3: mm_request_send entering: type 10 debug2: monitor_read: 3 used once, disabling now debug3: mm_auth_password: waiting for MONITOR_ANS_AUTHPASSWORD debug3: mm_request_receive entering debug3: mm_request_receive_expect entering: type 11 debug3: monitor_read: checking request 10 debug3: mm_request_receive entering debug3: mm_answer_authpassword: sending result 0 debug3: mm_request_send entering: type 11 debug3: mm_auth_password: user not authenticated Failed none for testuser from 10.200.10.117 port 49075 ssh2 Failed none for testuser from 10.200.10.117 port 49075 ssh2 debug3: mm_request_receive entering debug1: userauth-request for user testuser service ssh-connection method gssapi-with-mic debug1: attempt 1 failures 1 debug2: input_userauth_request: try method gssapi-with-mic debug3: mm_request_send entering: type 37 debug3: mm_request_receive_expect entering: type 38 debug3: monitor_read: checking request 37 debug3: mm_request_receive entering debug1: Miscellaneous failure No principal in keytab matches desired name debug3: mm_request_send entering: type 38 Failed gssapi-with-mic for testuser from 10.200.10.117 port 49075 ssh2 debug3: mm_request_receive entering debug1: userauth-request for user testuser service ssh-connection method gssapi-with-mic debug1: attempt 2 failures 2 debug2: input_userauth_request: try method gssapi-with-mic Failed gssapi-with-mic for testuser from 10.200.10.117 port 49075 ssh2 debug1: userauth-request for user testuser service ssh-connection method gssapi-with-mic debug1: attempt 3 failures 3 debug2: input_userauth_request: try method gssapi-with-mic Failed gssapi-with-mic for testuser from 10.200.10.117 port 49075 ssh2 debug1: userauth-request for user testuser service ssh-connection method gssapi-with-mic debug1: attempt 4 failures 4 debug2: input_userauth_request: try method gssapi-with-mic Failed gssapi-with-mic for testuser from 10.200.10.117 port 49075 ssh2 debug1: userauth-request for user testuser service ssh-connection method publickey debug1: attempt 5 failures 5 debug2: input_userauth_request: try method publickey debug1: test whether pkalg/pkblob are acceptable debug3: mm_key_allowed entering debug3: mm_request_send entering: type 20 debug3: mm_key_allowed: waiting for MONITOR_ANS_KEYALLOWED debug3: mm_request_receive_expect entering: type 21 debug3: mm_request_receive entering debug3: monitor_read: checking request 20 debug3: mm_answer_keyallowed entering debug3: mm_answer_keyallowed: key_from_blob: 20042fd8 debug1: temporarily_use_uid: 1115600008/1115600008 (e=0/0) debug1: trying public key file /home/testuser/.ssh/authorized_keys debug1: restore_uid: 0/0 debug1: temporarily_use_uid: 1115600008/1115600008 (e=0/0) debug1: trying public key file /home/testuser/.ssh/authorized_keys2 debug1: restore_uid: 0/0 debug3: mm_answer_keyallowed: key 20042fd8 is disallowed debug3: mm_request_send entering: type 21 debug3: mm_request_receive entering debug2: userauth_pubkey: authenticated 0 pkalg ssh-rsa Failed publickey for testuser from 10.200.10.117 port 49075 ssh2 debug1: userauth-request for user testuser service ssh-connection method keyboard-interactive debug1: attempt 6 failures 6 debug2: input_userauth_request: try method keyboard-interactive debug1: keyboard-interactive devs debug1: auth2_challenge: user=testuser devs= debug1: kbdint_alloc: devices '' debug2: auth2_challenge_start: devices Failed keyboard-interactive for testuser from 10.200.10.117 port 49075 ssh2 debug1: userauth-request for user testuser service ssh-connection method password debug1: attempt 7 failures 7 debug2: input_userauth_request: try method password debug3: mm_auth_password entering debug3: mm_request_send entering: type 10 debug3: mm_auth_password: waiting for MONITOR_ANS_AUTHPASSWORD debug3: mm_request_receive_expect entering: type 11 debug3: mm_request_receive entering debug3: monitor_read: checking request 10 debug3: inside auth_password debug3: AIX/authenticate result 1, msg debug3: AIX SYSTEM attribute KRB5ALXAP or compat debug3: mm_answer_authpassword: sending result 0 debug3: mm_request_send entering: type 11 Failed password for testuser from 10.200.10.117 port 49075 ssh2 debug3: mm_auth_password: user not authenticated Failed password for testuser from 10.200.10.117 port 49075 ssh2 Disconnecting: Too many authentication failures for testuser debug1: do_cleanup debug3: AIX/setauthdb set registry 'LDAP' debug3: aix_restoreauthdb: restoring old registry '' debug3: mm_request_receive entering debug1: do_cleanup bash-3.00# here's klist -k -e on the AIX box: bash-3.00# /usr/krb5/bin/klist -k -e Keytab name: FILE:/etc/krb5/krb5.keytab KVNO Principal ---- --------- 1 sshd/slnldca01.unix.magellanhealth.com at UNIX.MAGELLANHEALTH.COM (DES cbc mode with CRC-32) 3 host/slpidml01.unix.magellanhealth.com at UNIX.MAGELLANHEALTH.COM (Triple DES cbc mode with HMAC/sha1) 3 host/slpidml01.unix.magellanhealth.com at UNIX.MAGELLANHEALTH.COM (ArcFour with HMAC/md5) 4 host/slpidml01.unix.magellanhealth.com at UNIX.MAGELLANHEALTH.COM (Triple DES cbc mode with HMAC/sha1) 4 host/slpidml01.unix.magellanhealth.com at UNIX.MAGELLANHEALTH.COM (ArcFour with HMAC/md5) 5 host/slpidml01.unix.magellanhealth.com at UNIX.MAGELLANHEALTH.COM (Triple DES cbc mode with HMAC/sha1) 5 host/slpidml01.unix.magellanhealth.com at UNIX.MAGELLANHEALTH.COM (ArcFour with HMAC/md5) 6 host/slpidml01.unix.magellanhealth.com at UNIX.MAGELLANHEALTH.COM (DES cbc mode with CRC-32) 6 host/slpidml01.unix.magellanhealth.com at UNIX.MAGELLANHEALTH.COM (Triple DES cbc mode with HMAC/sha1) 6 host/slpidml01.unix.magellanhealth.com at UNIX.MAGELLANHEALTH.COM (ArcFour with HMAC/md5) 2 sshd/slnldca01.unix.magellanhealth.com at UNIX.MAGELLANHEALTH.COM (DES cbc mode with CRC-32) 2 sshd/slnldca01.unix.magellanhealth.com at UNIX.MAGELLANHEALTH.COM (Triple DES cbc mode with HMAC/sha1) 2 sshd/slnldca01.unix.magellanhealth.com at UNIX.MAGELLANHEALTH.COM (ArcFour with HMAC/md5) 1 host/slnldca01.unix.magellanhealth.com at UNIX.MAGELLANHEALTH.COM (Triple DES cbc mode with HMAC/sha1) 1 host/slnldca01.unix.magellanhealth.com at UNIX.MAGELLANHEALTH.COM (ArcFour with HMAC/md5) here's the relevent portion in krb5kdc.log: ar 30 18:13:10 slpidml01.unix.magellanhealth.com krb5kdc[13765](info): TGS_REQ (7 etypes {18 17 16 23 1 3 2}) 10.200.10.117: ISSUE: authtime 1333149153, etypes {rep=18 tkt=16 ses=16}, testuser at UNIX.MAGELLANHEALTH.COM for host/slnldca01.unix.magellanhealth.com at UNIX.MAGELLANHEALTH.COM Mar 30 18:13:15 slpidml01.unix.magellanhealth.com krb5kdc[13765](info): AS_REQ (5 etypes {16 23 18 3 1}) 10.200.2.68: NEEDED_PREAUTH: testuser at UNIX.MAGELLANHEALTH.COM for krbtgt/UNIX.MAGELLANHEALTH.COM at UNIX.MAGELLANHEALTH.COM, Additional pre-authentication required Mar 30 18:13:16 slpidml01.unix.magellanhealth.com krb5kdc[13765](info): AS_REQ (5 etypes {16 23 18 3 1}) 10.200.2.68: ISSUE: authtime 1333149196, etypes {rep=16 tkt=18 ses=16}, testuser at UNIX.MAGELLANHEALTH.COM for krbtgt/UNIX.MAGELLANHEALTH.COM at UNIX.MAGELLANHEALTH.COM Any help? If it's not obvious, I have no clue what I'm doing -- but I've been banging my head on this for three days straight, I have a ticket open with Red Hat and I've been reading everything I can find. Oh, I get similar entries in the kdc log if I telnet instead of ssh: Mar 30 18:33:42 slpidml01.unix.magellanhealth.com krb5kdc[13765](info): AS_REQ (5 etypes {16 23 18 3 1}) 10.200.2.68: NEEDED_PREAUTH: testuser at UNIX.MAGELLANHEALTH.COM for krbtgt/UNIX.MAGELLANHEALTH.COM at UNIX.MAGELLANHEALTH.COM, Additional pre-authentication required Mar 30 18:33:43 slpidml01.unix.magellanhealth.com krb5kdc[13765](info): AS_REQ (5 etypes {16 23 18 3 1}) 10.200.2.68: ISSUE: authtime 1333150423, etypes {rep=16 tkt=18 ses=16}, testuser at UNIX.MAGELLANHEALTH.COM for krbtgt/UNIX.MAGELLANHEALTH.COM at UNIX.MAGELLANHEALTH.COM Thanks, --Jason