From rajnesh.siwal at gmail.com Fri Feb 1 11:26:16 2013 From: rajnesh.siwal at gmail.com (Rajnesh Kumar Siwal) Date: Fri, 1 Feb 2013 16:56:16 +0530 Subject: [Freeipa-users] Bug: FreeIPA 2.2.0 on CentOS 6.3 Any User can see the details of all the Users through GUI Message-ID: Any User throug IPA GUI can see the details of all the other users. He should be able to see his own details. Additionally the , Change Passwords link is enabled corresponding to all Users (appears to any regular user). I am in Migration Mode. -- Regards, Rajnesh Kumar Siwal From pviktori at redhat.com Fri Feb 1 11:56:15 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 01 Feb 2013 12:56:15 +0100 Subject: [Freeipa-users] Bug: FreeIPA 2.2.0 on CentOS 6.3 Any User can see the details of all the Users through GUI In-Reply-To: References: Message-ID: <510BAD5F.3020205@redhat.com> On 02/01/2013 12:26 PM, Rajnesh Kumar Siwal wrote: > Any User throug IPA GUI can see the details of all the other users. > He should be able to see his own details. This is by design, see for example the note at https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html-single/Identity_Management_Guide/index.html#defining-roles > Additionally the , Change Passwords link is enabled corresponding to > all Users (appears to any regular user). > I am in Migration Mode. Do you mean that any user can change another users' password? The change password link should be grayed out on other users' pages. -- Petr? From william.muriithi at gmail.com Fri Feb 1 14:42:11 2013 From: william.muriithi at gmail.com (William Muriithi) Date: Fri, 1 Feb 2013 09:42:11 -0500 Subject: [Freeipa-users] Failed to obtain host TGT bug Message-ID: Hello pal, I have a centos 6.3 that fails to enroll to the IPA server however much I try. I believe its because of the bug below. I have updated the IPA client but it seem it is only fixed on ipa-3.0 which ships on RHEL 6.4 Is there a way of enrolling the client manually without necessary updating the system to Centos 6.4 (Which I don't know is it exist actually)? https://bugzilla.redhat.com/show_bug.cgi?id=845691 This is the most current IPA client on 6.3 ipa-client-2.2.0-17.el6_3.1.x86_64.rpm Thanks William -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Fri Feb 1 15:03:48 2013 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 01 Feb 2013 16:03:48 +0100 Subject: [Freeipa-users] Failed to obtain host TGT bug In-Reply-To: References: Message-ID: <510BD954.9080107@redhat.com> On 1.2.2013 15:42, William Muriithi wrote: > > Hello pal, > > I have a centos 6.3 that fails to enroll to the IPA server however much > I try. I believe its because of the bug below. I have updated the IPA > client but it seem it is only fixed on ipa-3.0 which ships on RHEL 6.4 How many replicas do you have? Could you share /var/log/ipa-client-install.log ? > Is there a way of enrolling the client manually without necessary > updating the system to Centos 6.4 (Which I don't know is it exist > actually)? You can try dirty hack: On client create iptables rule in OUTPUT chain which rejects all traffic to all IPA servers except one. Installer should theoretically fail over to the only accessible server. I would recommend "-j REJECT". DROP would create huge intervals of waiting for packets which will never arrive. > https://bugzilla.redhat.com/show_bug.cgi?id=845691 > > This is the most current IPA client on 6.3 > > ipa-client-2.2.0-17.el6_3.1.x86_64.rpm -- Petr^2 Spacek From rajnesh.siwal at gmail.com Fri Feb 1 17:26:42 2013 From: rajnesh.siwal at gmail.com (Rajnesh Kumar Siwal) Date: Fri, 1 Feb 2013 22:56:42 +0530 Subject: [Freeipa-users] Bug: FreeIPA 2.2.0 on CentOS 6.3 Any User can see the details of all the Users through GUI Message-ID: Change Password Link is not greyed (It is enabled). However, when I tried to change password, it failed because of insufficient Privileges (Looks Good). Thanks for the Quick reply. -- Regards, Rajnesh Kumar Siwal From christianh at 4over.com Fri Feb 1 20:42:26 2013 From: christianh at 4over.com (Christian Hernandez) Date: Fri, 1 Feb 2013 12:42:26 -0800 Subject: [Freeipa-users] Errors with Configuring GitHub Message-ID: We are trying to configure our internal GitHub server to use Our IPA server's LDAP for user logins. We successfully configured it; but users can't seem to login. So, before you ask, yes we do have an active support case with githubenterprise about this; but wanted to see if anyone else ran into the same issue. Attached is the screenshot of the config. This is the errors I'm seeing in the DirSrv logs [25/Jan/2013:15:41:35 -0800] conn=29453 fd=241 slot=241 connection from 192.168.114.95 to 192.168.114.114 [25/Jan/2013:15:41:35 -0800] conn=29453 op=0 BIND dn="uid=admin,cn=users,cn=accounts,dc=4over,dc=com" method=128 version=3 [25/Jan/2013:15:41:35 -0800] conn=29453 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=admin,cn=users,cn=accounts,dc=4over,dc=com" [25/Jan/2013:15:41:35 -0800] conn=29453 op=1 SRCH base="" scope=2 filter="(uid=chrish)", failed to decode LDAP controls [25/Jan/2013:15:41:35 -0800] conn=29453 op=1 RESULT err=2 tag=101 nentries=0 etime=0 [25/Jan/2013:15:41:35 -0800] conn=29453 op=-1 fd=241 closed - B1 Anyone has run into this? Also, I haven't tried connecting with TLS because I don't know where to find the cert! So if someone can point me in the right direction there I would appreciate it :) Thank you, Christian Hernandez -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen shot 2013-01-25 at 3.49.37 PM.png Type: image/png Size: 81200 bytes Desc: not available URL: From rmeggins at redhat.com Fri Feb 1 20:57:03 2013 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 01 Feb 2013 13:57:03 -0700 Subject: [Freeipa-users] Errors with Configuring GitHub In-Reply-To: References: Message-ID: <510C2C1F.7010206@redhat.com> On 02/01/2013 01:42 PM, Christian Hernandez wrote: > We are trying to configure our internal GitHub server to use Our IPA > server's LDAP for user logins. > > We successfully configured it; but users can't seem to login. > > So, before you ask, yes we do have an active support case with > githubenterprise about this; but wanted to see if anyone else ran into > the same issue. > > Attached is the screenshot of the config. > > This is the errors I'm seeing in the DirSrv logs > > > [25/Jan/2013:15:41:35 -0800] conn=29453 fd=241 slot=241 connection > from 192.168.114.95 to 192.168.114.114 > [25/Jan/2013:15:41:35 -0800] conn=29453 op=0 BIND > dn="uid=admin,cn=users,cn=accounts,dc=4over,dc=com" method=128 version=3 > [25/Jan/2013:15:41:35 -0800] conn=29453 op=0 RESULT err=0 tag=97 > nentries=0 etime=0 dn="uid=admin,cn=users,cn=accounts,dc=4over,dc=com" > [25/Jan/2013:15:41:35 -0800] conn=29453 op=1 SRCH base="" scope=2 > filter="(uid=chrish)", failed to decode LDAP controls > [25/Jan/2013:15:41:35 -0800] conn=29453 op=1 RESULT err=2 tag=101 > nentries=0 etime=0 > [25/Jan/2013:15:41:35 -0800] conn=29453 op=-1 fd=241 closed - B1 > > Anyone has run into this? Looks like DS is receiving some LDAP controls that it doesn't know how to process. Does this work with any other LDAP server? Can you run wireshark/tshark and capture the network traffic? I'd like to see what the BER looks like. > > Also, I haven't tried connecting with TLS because I don't know where > to find the cert! So if someone can point me in the right direction > there I would appreciate it :) > > Thank you, > > Christian Hernandez > > > _______________________________________________ > 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 it.meme01 at gmail.com Sat Feb 2 00:00:32 2013 From: it.meme01 at gmail.com (It Meme) Date: Fri, 1 Feb 2013 16:00:32 -0800 Subject: [Freeipa-users] IPA Create User Message-ID: Hi: We would like to trigger creation of user accounts from another application - is this possible completely by LDAP calls? Or using the APIs, the best way to proceed? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From christianh at 4over.com Sat Feb 2 00:25:22 2013 From: christianh at 4over.com (Christian Hernandez) Date: Fri, 1 Feb 2013 16:25:22 -0800 Subject: [Freeipa-users] Errors with Configuring GitHub In-Reply-To: <510C2C1F.7010206@redhat.com> References: <510C2C1F.7010206@redhat.com> Message-ID: Hello Attached is a TCPDUMP. Communication is happening between 192.168.114.95 and 192.168.114.114 Thank you, Christian Hernandez On Fri, Feb 1, 2013 at 12:57 PM, Rich Megginson wrote: > On 02/01/2013 01:42 PM, Christian Hernandez wrote: > > We are trying to configure our internal GitHub server to use Our IPA > server's LDAP for user logins. > > We successfully configured it; but users can't seem to login. > > So, before you ask, yes we do have an active support case with > githubenterprise about this; but wanted to see if anyone else ran into the > same issue. > > Attached is the screenshot of the config. > > This is the errors I'm seeing in the DirSrv logs > > > [25/Jan/2013:15:41:35 -0800] conn=29453 fd=241 slot=241 connection from > 192.168.114.95 to 192.168.114.114 > [25/Jan/2013:15:41:35 -0800] conn=29453 op=0 BIND > dn="uid=admin,cn=users,cn=accounts,dc=4over,dc=com" method=128 version=3 > [25/Jan/2013:15:41:35 -0800] conn=29453 op=0 RESULT err=0 tag=97 > nentries=0 etime=0 dn="uid=admin,cn=users,cn=accounts,dc=4over,dc=com" > [25/Jan/2013:15:41:35 -0800] conn=29453 op=1 SRCH base="" scope=2 > filter="(uid=chrish)", failed to decode LDAP controls > [25/Jan/2013:15:41:35 -0800] conn=29453 op=1 RESULT err=2 tag=101 > nentries=0 etime=0 > [25/Jan/2013:15:41:35 -0800] conn=29453 op=-1 fd=241 closed - B1 > > Anyone has run into this? > > > Looks like DS is receiving some LDAP controls that it doesn't know how to > process. Does this work with any other LDAP server? Can you run > wireshark/tshark and capture the network traffic? I'd like to see what the > BER looks like. > > > Also, I haven't tried connecting with TLS because I don't know where to > find the cert! So if someone can point me in the right direction there I > would appreciate it :) > > Thank you, > > Christian Hernandez > > > _______________________________________________ > Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users > > > Thank you, Christian Hernandez 1225 Los Angeles Street Glendale, CA 91204 Phone: 877-782-2737 ext. 4566 Fax: 818-265-3152 christianh at 4over.com www.4over.com On Fri, Feb 1, 2013 at 12:57 PM, Rich Megginson wrote: > On 02/01/2013 01:42 PM, Christian Hernandez wrote: > > We are trying to configure our internal GitHub server to use Our IPA > server's LDAP for user logins. > > We successfully configured it; but users can't seem to login. > > So, before you ask, yes we do have an active support case with > githubenterprise about this; but wanted to see if anyone else ran into the > same issue. > > Attached is the screenshot of the config. > > This is the errors I'm seeing in the DirSrv logs > > > [25/Jan/2013:15:41:35 -0800] conn=29453 fd=241 slot=241 connection from > 192.168.114.95 to 192.168.114.114 > [25/Jan/2013:15:41:35 -0800] conn=29453 op=0 BIND > dn="uid=admin,cn=users,cn=accounts,dc=4over,dc=com" method=128 version=3 > [25/Jan/2013:15:41:35 -0800] conn=29453 op=0 RESULT err=0 tag=97 > nentries=0 etime=0 dn="uid=admin,cn=users,cn=accounts,dc=4over,dc=com" > [25/Jan/2013:15:41:35 -0800] conn=29453 op=1 SRCH base="" scope=2 > filter="(uid=chrish)", failed to decode LDAP controls > [25/Jan/2013:15:41:35 -0800] conn=29453 op=1 RESULT err=2 tag=101 > nentries=0 etime=0 > [25/Jan/2013:15:41:35 -0800] conn=29453 op=-1 fd=241 closed - B1 > > Anyone has run into this? > > > Looks like DS is receiving some LDAP controls that it doesn't know how to > process. Does this work with any other LDAP server? Can you run > wireshark/tshark and capture the network traffic? I'd like to see what the > BER looks like. > > > Also, I haven't tried connecting with TLS because I don't know where to > find the cert! So if someone can point me in the right direction there I > would appreciate it :) > > Thank you, > > Christian Hernandez > > > _______________________________________________ > Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ipa.dump Type: application/octet-stream Size: 66704 bytes Desc: not available URL: From christianh at 4over.com Sat Feb 2 00:29:58 2013 From: christianh at 4over.com (Christian Hernandez) Date: Fri, 1 Feb 2013 16:29:58 -0800 Subject: [Freeipa-users] Errors with Configuring GitHub In-Reply-To: References: <510C2C1F.7010206@redhat.com> Message-ID: And to answer your questions Rich. GitHub was working with CDS 8.1.0 It looks like IPA is using 389 ns-slapd --version 389 Project 389-Directory/1.2.10.2 B2012.194.51 Thank you, Christian Hernandez 1225 Los Angeles Street Glendale, CA 91204 Phone: 877-782-2737 ext. 4566 Fax: 818-265-3152 christianh at 4over.com www.4over.com On Fri, Feb 1, 2013 at 4:25 PM, Christian Hernandez wrote: > Hello > > Attached is a TCPDUMP. > > Communication is happening between 192.168.114.95 and 192.168.114.114 > > Thank you, > > Christian Hernandez > > > On Fri, Feb 1, 2013 at 12:57 PM, Rich Megginson wrote: > >> On 02/01/2013 01:42 PM, Christian Hernandez wrote: >> >> We are trying to configure our internal GitHub server to use Our IPA >> server's LDAP for user logins. >> >> We successfully configured it; but users can't seem to login. >> >> So, before you ask, yes we do have an active support case with >> githubenterprise about this; but wanted to see if anyone else ran into the >> same issue. >> >> Attached is the screenshot of the config. >> >> This is the errors I'm seeing in the DirSrv logs >> >> >> [25/Jan/2013:15:41:35 -0800] conn=29453 fd=241 slot=241 connection from >> 192.168.114.95 to 192.168.114.114 >> [25/Jan/2013:15:41:35 -0800] conn=29453 op=0 BIND >> dn="uid=admin,cn=users,cn=accounts,dc=4over,dc=com" method=128 version=3 >> [25/Jan/2013:15:41:35 -0800] conn=29453 op=0 RESULT err=0 tag=97 >> nentries=0 etime=0 dn="uid=admin,cn=users,cn=accounts,dc=4over,dc=com" >> [25/Jan/2013:15:41:35 -0800] conn=29453 op=1 SRCH base="" scope=2 >> filter="(uid=chrish)", failed to decode LDAP controls >> [25/Jan/2013:15:41:35 -0800] conn=29453 op=1 RESULT err=2 tag=101 >> nentries=0 etime=0 >> [25/Jan/2013:15:41:35 -0800] conn=29453 op=-1 fd=241 closed - B1 >> >> Anyone has run into this? >> >> >> Looks like DS is receiving some LDAP controls that it doesn't know how to >> process. Does this work with any other LDAP server? Can you run >> wireshark/tshark and capture the network traffic? I'd like to see what the >> BER looks like. >> >> >> Also, I haven't tried connecting with TLS because I don't know where to >> find the cert! So if someone can point me in the right direction there I >> would appreciate it :) >> >> Thank you, >> >> Christian Hernandez >> >> >> _______________________________________________ >> Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users >> >> >> > > > Thank you, > > Christian Hernandez > 1225 Los Angeles Street > Glendale, CA 91204 > Phone: 877-782-2737 ext. 4566 > Fax: 818-265-3152 > christianh at 4over.com > www.4over.com > > > On Fri, Feb 1, 2013 at 12:57 PM, Rich Megginson wrote: > >> On 02/01/2013 01:42 PM, Christian Hernandez wrote: >> >> We are trying to configure our internal GitHub server to use Our IPA >> server's LDAP for user logins. >> >> We successfully configured it; but users can't seem to login. >> >> So, before you ask, yes we do have an active support case with >> githubenterprise about this; but wanted to see if anyone else ran into the >> same issue. >> >> Attached is the screenshot of the config. >> >> This is the errors I'm seeing in the DirSrv logs >> >> >> [25/Jan/2013:15:41:35 -0800] conn=29453 fd=241 slot=241 connection from >> 192.168.114.95 to 192.168.114.114 >> [25/Jan/2013:15:41:35 -0800] conn=29453 op=0 BIND >> dn="uid=admin,cn=users,cn=accounts,dc=4over,dc=com" method=128 version=3 >> [25/Jan/2013:15:41:35 -0800] conn=29453 op=0 RESULT err=0 tag=97 >> nentries=0 etime=0 dn="uid=admin,cn=users,cn=accounts,dc=4over,dc=com" >> [25/Jan/2013:15:41:35 -0800] conn=29453 op=1 SRCH base="" scope=2 >> filter="(uid=chrish)", failed to decode LDAP controls >> [25/Jan/2013:15:41:35 -0800] conn=29453 op=1 RESULT err=2 tag=101 >> nentries=0 etime=0 >> [25/Jan/2013:15:41:35 -0800] conn=29453 op=-1 fd=241 closed - B1 >> >> Anyone has run into this? >> >> >> Looks like DS is receiving some LDAP controls that it doesn't know how to >> process. Does this work with any other LDAP server? Can you run >> wireshark/tshark and capture the network traffic? I'd like to see what the >> BER looks like. >> >> >> Also, I haven't tried connecting with TLS because I don't know where to >> find the cert! So if someone can point me in the right direction there I >> would appreciate it :) >> >> Thank you, >> >> Christian Hernandez >> >> >> _______________________________________________ >> Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Sat Feb 2 00:35:48 2013 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 01 Feb 2013 17:35:48 -0700 Subject: [Freeipa-users] Errors with Configuring GitHub In-Reply-To: References: <510C2C1F.7010206@redhat.com> Message-ID: <510C5F64.6090306@redhat.com> On 02/01/2013 05:29 PM, Christian Hernandez wrote: > And to answer your questions Rich. > > GitHub was working with CDS 8.1.0 What is CDS? Is that centos-ds? > > It looks like IPA is using 389 > > ns-slapd --version > 389 Project > 389-Directory/1.2.10.2 B2012.194.51 > > > Thank you, > > Christian Hernandez > 1225 Los Angeles Street > Glendale, CA 91204 > Phone: 877-782-2737 ext. 4566 > Fax: 818-265-3152 > christianh at 4over.com > > > www.4over.com > > > > On Fri, Feb 1, 2013 at 4:25 PM, Christian Hernandez > > wrote: > > Hello > > Attached is a TCPDUMP. > > Communication is happening between 192.168.114.95 and 192.168.114.114 > > Thank you, > > Christian Hernandez > > > On Fri, Feb 1, 2013 at 12:57 PM, Rich Megginson > > wrote: > > On 02/01/2013 01:42 PM, Christian Hernandez wrote: >> We are trying to configure our internal GitHub server to use >> Our IPA server's LDAP for user logins. >> >> We successfully configured it; but users can't seem to login. >> >> So, before you ask, yes we do have an active support case >> with githubenterprise about this; but wanted to see if anyone >> else ran into the same issue. >> >> Attached is the screenshot of the config. >> >> This is the errors I'm seeing in the DirSrv logs >> >> >> [25/Jan/2013:15:41:35 -0800] conn=29453 fd=241 slot=241 >> connection from 192.168.114.95 to 192.168.114.114 >> [25/Jan/2013:15:41:35 -0800] conn=29453 op=0 BIND >> dn="uid=admin,cn=users,cn=accounts,dc=4over,dc=com" >> method=128 version=3 >> [25/Jan/2013:15:41:35 -0800] conn=29453 op=0 RESULT err=0 >> tag=97 nentries=0 etime=0 >> dn="uid=admin,cn=users,cn=accounts,dc=4over,dc=com" >> [25/Jan/2013:15:41:35 -0800] conn=29453 op=1 SRCH base="" >> scope=2 filter="(uid=chrish)", failed to decode LDAP controls >> [25/Jan/2013:15:41:35 -0800] conn=29453 op=1 RESULT err=2 >> tag=101 nentries=0 etime=0 >> [25/Jan/2013:15:41:35 -0800] conn=29453 op=-1 fd=241 closed - B1 >> >> Anyone has run into this? > > Looks like DS is receiving some LDAP controls that it doesn't > know how to process. Does this work with any other LDAP > server? Can you run wireshark/tshark and capture the network > traffic? I'd like to see what the BER looks like. > >> >> Also, I haven't tried connecting with TLS because I don't >> know where to find the cert! So if someone can point me in >> the right direction there I would appreciate it :) >> >> Thank you, >> >> Christian Hernandez >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > Thank you, > > Christian Hernandez > 1225 Los Angeles Street > Glendale, CA 91204 > Phone: 877-782-2737 ext. 4566 > Fax: 818-265-3152 > christianh at 4over.com > > > www.4over.com > > > > On Fri, Feb 1, 2013 at 12:57 PM, Rich Megginson > > wrote: > > On 02/01/2013 01:42 PM, Christian Hernandez wrote: >> We are trying to configure our internal GitHub server to use >> Our IPA server's LDAP for user logins. >> >> We successfully configured it; but users can't seem to login. >> >> So, before you ask, yes we do have an active support case >> with githubenterprise about this; but wanted to see if anyone >> else ran into the same issue. >> >> Attached is the screenshot of the config. >> >> This is the errors I'm seeing in the DirSrv logs >> >> >> [25/Jan/2013:15:41:35 -0800] conn=29453 fd=241 slot=241 >> connection from 192.168.114.95 to 192.168.114.114 >> [25/Jan/2013:15:41:35 -0800] conn=29453 op=0 BIND >> dn="uid=admin,cn=users,cn=accounts,dc=4over,dc=com" >> method=128 version=3 >> [25/Jan/2013:15:41:35 -0800] conn=29453 op=0 RESULT err=0 >> tag=97 nentries=0 etime=0 >> dn="uid=admin,cn=users,cn=accounts,dc=4over,dc=com" >> [25/Jan/2013:15:41:35 -0800] conn=29453 op=1 SRCH base="" >> scope=2 filter="(uid=chrish)", failed to decode LDAP controls >> [25/Jan/2013:15:41:35 -0800] conn=29453 op=1 RESULT err=2 >> tag=101 nentries=0 etime=0 >> [25/Jan/2013:15:41:35 -0800] conn=29453 op=-1 fd=241 closed - B1 >> >> Anyone has run into this? > > Looks like DS is receiving some LDAP controls that it doesn't > know how to process. Does this work with any other LDAP > server? Can you run wireshark/tshark and capture the network > traffic? I'd like to see what the BER looks like. > >> >> Also, I haven't tried connecting with TLS because I don't >> know where to find the cert! So if someone can point me in >> the right direction there I would appreciate it :) >> >> Thank you, >> >> Christian Hernandez >> >> >> _______________________________________________ >> 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 hari.mailvaganam at ubc.ca Sat Feb 2 00:43:19 2013 From: hari.mailvaganam at ubc.ca (Mailvaganam, Hari) Date: Sat, 2 Feb 2013 00:43:19 +0000 Subject: [Freeipa-users] List of APIs Message-ID: Hi: Is there an online list/docs of the available IPA APIs? Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Sat Feb 2 00:42:10 2013 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 01 Feb 2013 17:42:10 -0700 Subject: [Freeipa-users] Errors with Configuring GitHub In-Reply-To: References: <510C2C1F.7010206@redhat.com> Message-ID: <510C60E2.10600@redhat.com> On 02/01/2013 05:25 PM, Christian Hernandez wrote: > Hello > > Attached is a TCPDUMP. > > Communication is happening between 192.168.114.95 and 192.168.114.114 Thanks. The problem is that 389 doesn't like the fact that the search request includes the control tag but the length is 0. You said you were using CDS 8.1 - if that was centos-ds running on EL5, that used mozldap for the ldap sdk. 389 now uses openldap for the ldap sdk. Looks like there is a slight difference between how mozldap and openldap handle this situation. Please file a ticket at https://fedorahosted.org/389/newticket In the meantime, is there some option in github server to either completely disable LDAP controls in the LDAP search request? Or, alternately, is there a way to add some control to the search request? The goal is to figure out some way to tell github not to pass in a 0 length LDAP control sequence. > > Thank you, > > Christian Hernandez > > > On Fri, Feb 1, 2013 at 12:57 PM, Rich Megginson > wrote: > > On 02/01/2013 01:42 PM, Christian Hernandez wrote: >> We are trying to configure our internal GitHub server to use Our >> IPA server's LDAP for user logins. >> >> We successfully configured it; but users can't seem to login. >> >> So, before you ask, yes we do have an active support case with >> githubenterprise about this; but wanted to see if anyone else ran >> into the same issue. >> >> Attached is the screenshot of the config. >> >> This is the errors I'm seeing in the DirSrv logs >> >> >> [25/Jan/2013:15:41:35 -0800] conn=29453 fd=241 slot=241 >> connection from 192.168.114.95 to 192.168.114.114 >> [25/Jan/2013:15:41:35 -0800] conn=29453 op=0 BIND >> dn="uid=admin,cn=users,cn=accounts,dc=4over,dc=com" method=128 >> version=3 >> [25/Jan/2013:15:41:35 -0800] conn=29453 op=0 RESULT err=0 tag=97 >> nentries=0 etime=0 >> dn="uid=admin,cn=users,cn=accounts,dc=4over,dc=com" >> [25/Jan/2013:15:41:35 -0800] conn=29453 op=1 SRCH base="" scope=2 >> filter="(uid=chrish)", failed to decode LDAP controls >> [25/Jan/2013:15:41:35 -0800] conn=29453 op=1 RESULT err=2 tag=101 >> nentries=0 etime=0 >> [25/Jan/2013:15:41:35 -0800] conn=29453 op=-1 fd=241 closed - B1 >> >> Anyone has run into this? > > Looks like DS is receiving some LDAP controls that it doesn't know > how to process. Does this work with any other LDAP server? Can > you run wireshark/tshark and capture the network traffic? I'd > like to see what the BER looks like. > >> >> Also, I haven't tried connecting with TLS because I don't know >> where to find the cert! So if someone can point me in the right >> direction there I would appreciate it :) >> >> Thank you, >> >> Christian Hernandez >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > Thank you, > > Christian Hernandez > 1225 Los Angeles Street > Glendale, CA 91204 > Phone: 877-782-2737 ext. 4566 > Fax: 818-265-3152 > christianh at 4over.com > > > www.4over.com > > > > On Fri, Feb 1, 2013 at 12:57 PM, Rich Megginson > wrote: > > On 02/01/2013 01:42 PM, Christian Hernandez wrote: >> We are trying to configure our internal GitHub server to use Our >> IPA server's LDAP for user logins. >> >> We successfully configured it; but users can't seem to login. >> >> So, before you ask, yes we do have an active support case with >> githubenterprise about this; but wanted to see if anyone else ran >> into the same issue. >> >> Attached is the screenshot of the config. >> >> This is the errors I'm seeing in the DirSrv logs >> >> >> [25/Jan/2013:15:41:35 -0800] conn=29453 fd=241 slot=241 >> connection from 192.168.114.95 to 192.168.114.114 >> [25/Jan/2013:15:41:35 -0800] conn=29453 op=0 BIND >> dn="uid=admin,cn=users,cn=accounts,dc=4over,dc=com" method=128 >> version=3 >> [25/Jan/2013:15:41:35 -0800] conn=29453 op=0 RESULT err=0 tag=97 >> nentries=0 etime=0 >> dn="uid=admin,cn=users,cn=accounts,dc=4over,dc=com" >> [25/Jan/2013:15:41:35 -0800] conn=29453 op=1 SRCH base="" scope=2 >> filter="(uid=chrish)", failed to decode LDAP controls >> [25/Jan/2013:15:41:35 -0800] conn=29453 op=1 RESULT err=2 tag=101 >> nentries=0 etime=0 >> [25/Jan/2013:15:41:35 -0800] conn=29453 op=-1 fd=241 closed - B1 >> >> Anyone has run into this? > > Looks like DS is receiving some LDAP controls that it doesn't know > how to process. Does this work with any other LDAP server? Can > you run wireshark/tshark and capture the network traffic? I'd > like to see what the BER looks like. > >> >> Also, I haven't tried connecting with TLS because I don't know >> where to find the cert! So if someone can point me in the right >> direction there I would appreciate it :) >> >> Thank you, >> >> Christian Hernandez >> >> >> _______________________________________________ >> 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 christianh at 4over.com Sat Feb 2 00:52:29 2013 From: christianh at 4over.com (Christian Hernandez) Date: Fri, 1 Feb 2013 16:52:29 -0800 Subject: [Freeipa-users] Errors with Configuring GitHub In-Reply-To: <510C60E2.10600@redhat.com> References: <510C2C1F.7010206@redhat.com> <510C60E2.10600@redhat.com> Message-ID: Will Do. I've also put an inquiry into GitHub enterprise to see if there is a way for GitHub not to pass a 0 length sequence. I will take a look at the CPannel to see if I can find something as well. I will update when I have a chance. I couldn't fill a ticket because I do not have a login...and I do not have a login because "We are not ready to accept contributions at this time" Thank you, Christian Hernandez 1225 Los Angeles Street Glendale, CA 91204 Phone: 877-782-2737 ext. 4566 Fax: 818-265-3152 christianh at 4over.com www.4over.com On Fri, Feb 1, 2013 at 4:42 PM, Rich Megginson wrote: > On 02/01/2013 05:25 PM, Christian Hernandez wrote: > > Hello > > Attached is a TCPDUMP. > > Communication is happening between 192.168.114.95 and 192.168.114.114 > > > Thanks. The problem is that 389 doesn't like the fact that the search > request includes the control tag but the length is 0. You said you were > using CDS 8.1 - if that was centos-ds running on EL5, that used mozldap for > the ldap sdk. 389 now uses openldap for the ldap sdk. Looks like there is > a slight difference between how mozldap and openldap handle this > situation. Please file a ticket at https://fedorahosted.org/389/newticket > > In the meantime, is there some option in github server to either > completely disable LDAP controls in the LDAP search request? Or, > alternately, is there a way to add some control to the search request? The > goal is to figure out some way to tell github not to pass in a 0 length > LDAP control sequence. > > > > Thank you, > > Christian Hernandez > > > On Fri, Feb 1, 2013 at 12:57 PM, Rich Megginson wrote: > >> On 02/01/2013 01:42 PM, Christian Hernandez wrote: >> >> We are trying to configure our internal GitHub server to use Our IPA >> server's LDAP for user logins. >> >> We successfully configured it; but users can't seem to login. >> >> So, before you ask, yes we do have an active support case with >> githubenterprise about this; but wanted to see if anyone else ran into the >> same issue. >> >> Attached is the screenshot of the config. >> >> This is the errors I'm seeing in the DirSrv logs >> >> >> [25/Jan/2013:15:41:35 -0800] conn=29453 fd=241 slot=241 connection from >> 192.168.114.95 to 192.168.114.114 >> [25/Jan/2013:15:41:35 -0800] conn=29453 op=0 BIND >> dn="uid=admin,cn=users,cn=accounts,dc=4over,dc=com" method=128 version=3 >> [25/Jan/2013:15:41:35 -0800] conn=29453 op=0 RESULT err=0 tag=97 >> nentries=0 etime=0 dn="uid=admin,cn=users,cn=accounts,dc=4over,dc=com" >> [25/Jan/2013:15:41:35 -0800] conn=29453 op=1 SRCH base="" scope=2 >> filter="(uid=chrish)", failed to decode LDAP controls >> [25/Jan/2013:15:41:35 -0800] conn=29453 op=1 RESULT err=2 tag=101 >> nentries=0 etime=0 >> [25/Jan/2013:15:41:35 -0800] conn=29453 op=-1 fd=241 closed - B1 >> >> Anyone has run into this? >> >> >> Looks like DS is receiving some LDAP controls that it doesn't know how >> to process. Does this work with any other LDAP server? Can you run >> wireshark/tshark and capture the network traffic? I'd like to see what the >> BER looks like. >> >> >> Also, I haven't tried connecting with TLS because I don't know where to >> find the cert! So if someone can point me in the right direction there I >> would appreciate it :) >> >> Thank you, >> >> Christian Hernandez >> >> >> _______________________________________________ >> Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users >> >> >> > > > Thank you, > > Christian Hernandez > 1225 Los Angeles Street > Glendale, CA 91204 > Phone: 877-782-2737 ext. 4566 > Fax: 818-265-3152 > christianh at 4over.com > www.4over.com > > > On Fri, Feb 1, 2013 at 12:57 PM, Rich Megginson wrote: > >> On 02/01/2013 01:42 PM, Christian Hernandez wrote: >> >> We are trying to configure our internal GitHub server to use Our IPA >> server's LDAP for user logins. >> >> We successfully configured it; but users can't seem to login. >> >> So, before you ask, yes we do have an active support case with >> githubenterprise about this; but wanted to see if anyone else ran into the >> same issue. >> >> Attached is the screenshot of the config. >> >> This is the errors I'm seeing in the DirSrv logs >> >> >> [25/Jan/2013:15:41:35 -0800] conn=29453 fd=241 slot=241 connection from >> 192.168.114.95 to 192.168.114.114 >> [25/Jan/2013:15:41:35 -0800] conn=29453 op=0 BIND >> dn="uid=admin,cn=users,cn=accounts,dc=4over,dc=com" method=128 version=3 >> [25/Jan/2013:15:41:35 -0800] conn=29453 op=0 RESULT err=0 tag=97 >> nentries=0 etime=0 dn="uid=admin,cn=users,cn=accounts,dc=4over,dc=com" >> [25/Jan/2013:15:41:35 -0800] conn=29453 op=1 SRCH base="" scope=2 >> filter="(uid=chrish)", failed to decode LDAP controls >> [25/Jan/2013:15:41:35 -0800] conn=29453 op=1 RESULT err=2 tag=101 >> nentries=0 etime=0 >> [25/Jan/2013:15:41:35 -0800] conn=29453 op=-1 fd=241 closed - B1 >> >> Anyone has run into this? >> >> >> Looks like DS is receiving some LDAP controls that it doesn't know how >> to process. Does this work with any other LDAP server? Can you run >> wireshark/tshark and capture the network traffic? I'd like to see what the >> BER looks like. >> >> >> Also, I haven't tried connecting with TLS because I don't know where to >> find the cert! So if someone can point me in the right direction there I >> would appreciate it :) >> >> Thank you, >> >> Christian Hernandez >> >> >> _______________________________________________ >> Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christianh at 4over.com Sat Feb 2 00:39:18 2013 From: christianh at 4over.com (Christian Hernandez) Date: Fri, 1 Feb 2013 16:39:18 -0800 Subject: [Freeipa-users] Errors with Configuring GitHub In-Reply-To: <510C5F64.6090306@redhat.com> References: <510C2C1F.7010206@redhat.com> <510C5F64.6090306@redhat.com> Message-ID: Oh yes, sorry; we all live in Acronyms :-) Yes centos-ds Thank you, Christian Hernandez 1225 Los Angeles Street Glendale, CA 91204 Phone: 877-782-2737 ext. 4566 Fax: 818-265-3152 christianh at 4over.com www.4over.com On Fri, Feb 1, 2013 at 4:35 PM, Rich Megginson wrote: > On 02/01/2013 05:29 PM, Christian Hernandez wrote: > > And to answer your questions Rich. > > GitHub was working with CDS 8.1.0 > > > What is CDS? Is that centos-ds? > > > > It looks like IPA is using 389 > > ns-slapd --version > 389 Project > 389-Directory/1.2.10.2 B2012.194.51 > > > Thank you, > > Christian Hernandez > 1225 Los Angeles Street > Glendale, CA 91204 > Phone: 877-782-2737 ext. 4566 > Fax: 818-265-3152 > christianh at 4over.com > www.4over.com > > > On Fri, Feb 1, 2013 at 4:25 PM, Christian Hernandez wrote: > >> Hello >> >> Attached is a TCPDUMP. >> >> Communication is happening between 192.168.114.95 and 192.168.114.114 >> >> Thank you, >> >> Christian Hernandez >> >> >> On Fri, Feb 1, 2013 at 12:57 PM, Rich Megginson wrote: >> >>> On 02/01/2013 01:42 PM, Christian Hernandez wrote: >>> >>> We are trying to configure our internal GitHub server to use Our IPA >>> server's LDAP for user logins. >>> >>> We successfully configured it; but users can't seem to login. >>> >>> So, before you ask, yes we do have an active support case with >>> githubenterprise about this; but wanted to see if anyone else ran into the >>> same issue. >>> >>> Attached is the screenshot of the config. >>> >>> This is the errors I'm seeing in the DirSrv logs >>> >>> >>> [25/Jan/2013:15:41:35 -0800] conn=29453 fd=241 slot=241 connection from >>> 192.168.114.95 to 192.168.114.114 >>> [25/Jan/2013:15:41:35 -0800] conn=29453 op=0 BIND >>> dn="uid=admin,cn=users,cn=accounts,dc=4over,dc=com" method=128 version=3 >>> [25/Jan/2013:15:41:35 -0800] conn=29453 op=0 RESULT err=0 tag=97 >>> nentries=0 etime=0 dn="uid=admin,cn=users,cn=accounts,dc=4over,dc=com" >>> [25/Jan/2013:15:41:35 -0800] conn=29453 op=1 SRCH base="" scope=2 >>> filter="(uid=chrish)", failed to decode LDAP controls >>> [25/Jan/2013:15:41:35 -0800] conn=29453 op=1 RESULT err=2 tag=101 >>> nentries=0 etime=0 >>> [25/Jan/2013:15:41:35 -0800] conn=29453 op=-1 fd=241 closed - B1 >>> >>> Anyone has run into this? >>> >>> >>> Looks like DS is receiving some LDAP controls that it doesn't know how >>> to process. Does this work with any other LDAP server? Can you run >>> wireshark/tshark and capture the network traffic? I'd like to see what the >>> BER looks like. >>> >>> >>> Also, I haven't tried connecting with TLS because I don't know where to >>> find the cert! So if someone can point me in the right direction there I >>> would appreciate it :) >>> >>> Thank you, >>> >>> Christian Hernandez >>> >>> >>> _______________________________________________ >>> Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users >>> >>> >>> >> >> >> Thank you, >> >> Christian Hernandez >> 1225 Los Angeles Street >> Glendale, CA 91204 >> Phone: 877-782-2737 ext. 4566 >> Fax: 818-265-3152 >> christianh at 4over.com >> www.4over.com >> >> >> On Fri, Feb 1, 2013 at 12:57 PM, Rich Megginson wrote: >> >>> On 02/01/2013 01:42 PM, Christian Hernandez wrote: >>> >>> We are trying to configure our internal GitHub server to use Our IPA >>> server's LDAP for user logins. >>> >>> We successfully configured it; but users can't seem to login. >>> >>> So, before you ask, yes we do have an active support case with >>> githubenterprise about this; but wanted to see if anyone else ran into the >>> same issue. >>> >>> Attached is the screenshot of the config. >>> >>> This is the errors I'm seeing in the DirSrv logs >>> >>> >>> [25/Jan/2013:15:41:35 -0800] conn=29453 fd=241 slot=241 connection from >>> 192.168.114.95 to 192.168.114.114 >>> [25/Jan/2013:15:41:35 -0800] conn=29453 op=0 BIND >>> dn="uid=admin,cn=users,cn=accounts,dc=4over,dc=com" method=128 version=3 >>> [25/Jan/2013:15:41:35 -0800] conn=29453 op=0 RESULT err=0 tag=97 >>> nentries=0 etime=0 dn="uid=admin,cn=users,cn=accounts,dc=4over,dc=com" >>> [25/Jan/2013:15:41:35 -0800] conn=29453 op=1 SRCH base="" scope=2 >>> filter="(uid=chrish)", failed to decode LDAP controls >>> [25/Jan/2013:15:41:35 -0800] conn=29453 op=1 RESULT err=2 tag=101 >>> nentries=0 etime=0 >>> [25/Jan/2013:15:41:35 -0800] conn=29453 op=-1 fd=241 closed - B1 >>> >>> Anyone has run into this? >>> >>> >>> Looks like DS is receiving some LDAP controls that it doesn't know how >>> to process. Does this work with any other LDAP server? Can you run >>> wireshark/tshark and capture the network traffic? I'd like to see what the >>> BER looks like. >>> >>> >>> Also, I haven't tried connecting with TLS because I don't know where to >>> find the cert! So if someone can point me in the right direction there I >>> would appreciate it :) >>> >>> Thank you, >>> >>> Christian Hernandez >>> >>> >>> _______________________________________________ >>> Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users >>> >>> >>> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Sat Feb 2 00:42:44 2013 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 01 Feb 2013 19:42:44 -0500 Subject: [Freeipa-users] IPA Create User In-Reply-To: References: Message-ID: <510C6104.4050208@redhat.com> On 02/01/2013 07:00 PM, It Meme wrote: > Hi: > > We would like to trigger creation of user accounts from another > application - is this possible completely by LDAP calls? > > Or using the APIs, the best way to proceed? Actually using CLIs would be a preferred and supported way for the time being. APIs would be the second. They are stable but not public. We have not published them because so far no one seriously considered calling IPA from another application. May be you are going to be the first. You can look at the extnsibility guide. Also we would be able to provide additional guidance but we are not ready to call it an API we not going to break so if you are fine with modifying your app if we change things it might be a good option for both of us to move to a more production ready API. LDAP is not a preferred method for creation of the entries because we do more in the code than just calling LDAP modify. We can help you to craft something but effectively you would have to duplicate our ipa user-add logic within your code. I suspect you do not want to go this path. Thanks Dmitri > > Thanks. > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Sat Feb 2 03:23:17 2013 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 01 Feb 2013 20:23:17 -0700 Subject: [Freeipa-users] Errors with Configuring GitHub In-Reply-To: References: <510C2C1F.7010206@redhat.com> <510C60E2.10600@redhat.com> Message-ID: <510C86A5.90809@redhat.com> On 02/01/2013 05:52 PM, Christian Hernandez wrote: > Will Do. > > I've also put an inquiry into GitHub enterprise to see if there is a > way for GitHub not to pass a 0 length sequence. I will take a look at > the CPannel to see if I can find something as well. > > I will update when I have a chance. > > I couldn't fill a ticket because I do not have a login...and I do not > have a login because "We are not ready to accept contributions at this > time" Ok. https://fedorahosted.org/389/ticket/571 When you are able, please add yourself to the CC list of this ticket. > > > Thank you, > > Christian Hernandez > 1225 Los Angeles Street > Glendale, CA 91204 > Phone: 877-782-2737 ext. 4566 > Fax: 818-265-3152 > christianh at 4over.com > > > www.4over.com > > > > On Fri, Feb 1, 2013 at 4:42 PM, Rich Megginson > wrote: > > On 02/01/2013 05:25 PM, Christian Hernandez wrote: >> Hello >> >> Attached is a TCPDUMP. >> >> Communication is happening between 192.168.114.95 and 192.168.114.114 > > Thanks. The problem is that 389 doesn't like the fact that the > search request includes the control tag but the length is 0. You > said you were using CDS 8.1 - if that was centos-ds running on > EL5, that used mozldap for the ldap sdk. 389 now uses openldap > for the ldap sdk. Looks like there is a slight difference between > how mozldap and openldap handle this situation. Please file a > ticket at https://fedorahosted.org/389/newticket > > In the meantime, is there some option in github server to either > completely disable LDAP controls in the LDAP search request? Or, > alternately, is there a way to add some control to the search > request? The goal is to figure out some way to tell github not to > pass in a 0 length LDAP control sequence. > > >> >> Thank you, >> >> Christian Hernandez >> >> >> On Fri, Feb 1, 2013 at 12:57 PM, Rich Megginson >> > wrote: >> >> On 02/01/2013 01:42 PM, Christian Hernandez wrote: >>> We are trying to configure our internal GitHub server to use >>> Our IPA server's LDAP for user logins. >>> >>> We successfully configured it; but users can't seem to login. >>> >>> So, before you ask, yes we do have an active support case >>> with githubenterprise about this; but wanted to see if >>> anyone else ran into the same issue. >>> >>> Attached is the screenshot of the config. >>> >>> This is the errors I'm seeing in the DirSrv logs >>> >>> >>> [25/Jan/2013:15:41:35 -0800] conn=29453 fd=241 slot=241 >>> connection from 192.168.114.95 to 192.168.114.114 >>> [25/Jan/2013:15:41:35 -0800] conn=29453 op=0 BIND >>> dn="uid=admin,cn=users,cn=accounts,dc=4over,dc=com" >>> method=128 version=3 >>> [25/Jan/2013:15:41:35 -0800] conn=29453 op=0 RESULT err=0 >>> tag=97 nentries=0 etime=0 >>> dn="uid=admin,cn=users,cn=accounts,dc=4over,dc=com" >>> [25/Jan/2013:15:41:35 -0800] conn=29453 op=1 SRCH base="" >>> scope=2 filter="(uid=chrish)", failed to decode LDAP controls >>> [25/Jan/2013:15:41:35 -0800] conn=29453 op=1 RESULT err=2 >>> tag=101 nentries=0 etime=0 >>> [25/Jan/2013:15:41:35 -0800] conn=29453 op=-1 fd=241 closed - B1 >>> >>> Anyone has run into this? >> >> Looks like DS is receiving some LDAP controls that it doesn't >> know how to process. Does this work with any other LDAP >> server? Can you run wireshark/tshark and capture the network >> traffic? I'd like to see what the BER looks like. >> >>> >>> Also, I haven't tried connecting with TLS because I don't >>> know where to find the cert! So if someone can point me in >>> the right direction there I would appreciate it :) >>> >>> Thank you, >>> >>> Christian Hernandez >>> >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> >> >> >> Thank you, >> >> Christian Hernandez >> 1225 Los Angeles Street >> Glendale, CA 91204 >> Phone: 877-782-2737 ext. 4566 >> Fax: 818-265-3152 >> christianh at 4over.com >> > >> www.4over.com > > >> >> >> On Fri, Feb 1, 2013 at 12:57 PM, Rich Megginson >> > wrote: >> >> On 02/01/2013 01:42 PM, Christian Hernandez wrote: >>> We are trying to configure our internal GitHub server to use >>> Our IPA server's LDAP for user logins. >>> >>> We successfully configured it; but users can't seem to login. >>> >>> So, before you ask, yes we do have an active support case >>> with githubenterprise about this; but wanted to see if >>> anyone else ran into the same issue. >>> >>> Attached is the screenshot of the config. >>> >>> This is the errors I'm seeing in the DirSrv logs >>> >>> >>> [25/Jan/2013:15:41:35 -0800] conn=29453 fd=241 slot=241 >>> connection from 192.168.114.95 to 192.168.114.114 >>> [25/Jan/2013:15:41:35 -0800] conn=29453 op=0 BIND >>> dn="uid=admin,cn=users,cn=accounts,dc=4over,dc=com" >>> method=128 version=3 >>> [25/Jan/2013:15:41:35 -0800] conn=29453 op=0 RESULT err=0 >>> tag=97 nentries=0 etime=0 >>> dn="uid=admin,cn=users,cn=accounts,dc=4over,dc=com" >>> [25/Jan/2013:15:41:35 -0800] conn=29453 op=1 SRCH base="" >>> scope=2 filter="(uid=chrish)", failed to decode LDAP controls >>> [25/Jan/2013:15:41:35 -0800] conn=29453 op=1 RESULT err=2 >>> tag=101 nentries=0 etime=0 >>> [25/Jan/2013:15:41:35 -0800] conn=29453 op=-1 fd=241 closed - B1 >>> >>> Anyone has run into this? >> >> Looks like DS is receiving some LDAP controls that it doesn't >> know how to process. Does this work with any other LDAP >> server? Can you run wireshark/tshark and capture the network >> traffic? I'd like to see what the BER looks like. >> >>> >>> Also, I haven't tried connecting with TLS because I don't >>> know where to find the cert! So if someone can point me in >>> the right direction there I would appreciate it :) >>> >>> Thank you, >>> >>> Christian Hernandez >>> >>> >>> _______________________________________________ >>> 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 it.meme01 at gmail.com Sat Feb 2 03:26:35 2013 From: it.meme01 at gmail.com (It Meme) Date: Fri, 1 Feb 2013 19:26:35 -0800 Subject: [Freeipa-users] IPA Create User In-Reply-To: <510C6104.4050208@redhat.com> References: <510C6104.4050208@redhat.com> Message-ID: Hi Dimitri: Thank you for your helpful posts. Do you know of any organization that provisions accounts and groups in real-time, from an external IdM system, to IPA, via CLI? We have an IdM system which will be reading data from HR, and making 'joiner, mover, leaver, decisions' - accounts are provisioned, deleted, groups changed etc based on the HR data. Is it feasible to consider the IdM system calling the CLI, via scripts, to create/delete accounts, manage groups, in near real-time? I am gathering the details on options and present it to management. Thanks. On Fri, Feb 1, 2013 at 4:42 PM, Dmitri Pal wrote: > On 02/01/2013 07:00 PM, It Meme wrote: > > Hi: > > We would like to trigger creation of user accounts from another > application - is this possible completely by LDAP calls? > > Or using the APIs, the best way to proceed? > > > Actually using CLIs would be a preferred and supported way for the time > being. > APIs would be the second. They are stable but not public. We have not > published them because so far no one seriously considered calling IPA from > another application. May be you are going to be the first. You can look at > the extnsibility guide. Also we would be able to provide additional > guidance but we are not ready to call it an API we not going to break so if > you are fine with modifying your app if we change things it might be a good > option for both of us to move to a more production ready API. > LDAP is not a preferred method for creation of the entries because we do > more in the code than just calling LDAP modify. > We can help you to craft something but effectively you would have to > duplicate our ipa user-add logic within your code. I suspect you do not > want to go this path. > > Thanks > Dmitri > > > Thanks. > > > > > _______________________________________________ > Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs?www.redhat.com/carveoutcosts/ > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdennis at redhat.com Sat Feb 2 04:59:54 2013 From: jdennis at redhat.com (John Dennis) Date: Fri, 01 Feb 2013 23:59:54 -0500 Subject: [Freeipa-users] IPA Create User In-Reply-To: References: <510C6104.4050208@redhat.com> Message-ID: <510C9D4A.5080100@redhat.com> On 02/01/2013 10:26 PM, It Meme wrote: > Hi Dimitri: > > Thank you for your helpful posts. > > Do you know of any organization that provisions accounts and groups in > real-time, from an external IdM system, to IPA, via CLI? > > We have an IdM system which will be reading data from HR, and making > 'joiner, mover, leaver, decisions' - accounts are provisioned, deleted, > groups changed etc based on the HR data. > > Is it feasible to consider the IdM system calling the CLI, via scripts, > to create/delete accounts, manage groups, in near real-time? Calling a script does not take much time (especially compared to the elapsed time it takes for the command to complete), it would only be an issue if you were trying to do a number of transactions per second, but it doesn't sound like your HR dept is going to need that kind of throughput. It's also possible to call our API from Python, others have done this. Whether your IdM forks out to a shell script or to a Python script would be negligible compared to the total elapsed time to complete the operation. I suppose the answer to your question begs another, what's your definition of "real time"? If your IdM triggers a transaction and it completes within a few seconds is that real time? John -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Sat Feb 2 19:33:38 2013 From: dpal at redhat.com (Dmitri Pal) Date: Sat, 02 Feb 2013 14:33:38 -0500 Subject: [Freeipa-users] List of APIs In-Reply-To: References: Message-ID: <510D6A12.4070504@redhat.com> On 02/01/2013 07:43 PM, Mailvaganam, Hari wrote: > Hi: > > Is there an online list/docs of the available IPA APIs? There is no API documentation because we are not ready so claim that API is stable to document it and support it. However de facto the API pretty stable so it is more a question of demand than anything else at the moment. The CLI has has a good help system. Just run 'ipa --help' and take it from there. > > Thank you. > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rajnesh.siwal at gmail.com Sat Feb 2 20:24:15 2013 From: rajnesh.siwal at gmail.com (Rajnesh Kumar Siwal) Date: Sun, 3 Feb 2013 01:54:15 +0530 Subject: [Freeipa-users] Unable to change the password from IPA Client Message-ID: I am unable to change the password through my IPA client (RHEL 5.6). IPA Server (CentOS 6.3) , IPA 2.2. [rsiwal at gw1-test ~]$ kinit rsiwal Password for rsiwal at XYZ.COM Password expired. You must change it now. Enter new password: Enter it again: Password mismatch. Please try again. Enter new password: Enter it again: Password change rejected. Please try again. It is matching the password complexidt. It is in Migration Mode so that the Users can change the passwords through WebUI. From dpal at redhat.com Sun Feb 3 00:32:10 2013 From: dpal at redhat.com (Dmitri Pal) Date: Sat, 02 Feb 2013 19:32:10 -0500 Subject: [Freeipa-users] Unable to change the password from IPA Client In-Reply-To: References: Message-ID: <510DB00A.3050706@redhat.com> On 02/02/2013 03:24 PM, Rajnesh Kumar Siwal wrote: > I am unable to change the password through my IPA client (RHEL 5.6). > IPA Server (CentOS 6.3) , IPA 2.2. > > [rsiwal at gw1-test ~]$ kinit rsiwal > Password for rsiwal at XYZ.COM > Password expired. You must change it now. > Enter new password: > Enter it again: > Password mismatch. Please try again. > Enter new password: > Enter it again: > Password change rejected. Please try again. > > It is matching the password complexidt. > It is in Migration Mode so that the Users can change the passwords > through WebUI. > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users The first time you probably fat fingered it. The second time your password most likely did not meet the password policy and was rejected. Check you pwd policy on the server and look into the KDC logs. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rajnesh.siwal at gmail.com Sun Feb 3 17:10:05 2013 From: rajnesh.siwal at gmail.com (Rajnesh Kumar Siwal) Date: Sun, 3 Feb 2013 22:40:05 +0530 Subject: [Freeipa-users] Backup and Restoration of IPA Server Message-ID: As the IPA server has been the backbone of any Company, is there any recommended approach for Backup/Restore. Please suggest the best approach how to backup and rebuilt the server from scratch and restore the IPA Server. -- Regards, Rajnesh Kumar Siwal From dpal at redhat.com Sun Feb 3 18:01:45 2013 From: dpal at redhat.com (Dmitri Pal) Date: Sun, 03 Feb 2013 13:01:45 -0500 Subject: [Freeipa-users] Backup and Restoration of IPA Server In-Reply-To: References: Message-ID: <510EA609.1060206@redhat.com> On 02/03/2013 12:10 PM, Rajnesh Kumar Siwal wrote: > As the IPA server has been the backbone of any Company, is there any > recommended approach for Backup/Restore. > Please suggest the best approach how to backup and rebuilt the server > from scratch and restore the IPA Server. > For redundancy we recommend running several replicas so that if you loose one you can easily redeploy. It you want, you can run one of the replicas in a VM and take snapshots of the whole system. A more fine grained Backup/Restore procedure is on the roadmap for the next release. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From Steven.Jones at vuw.ac.nz Sun Feb 3 20:17:18 2013 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Sun, 3 Feb 2013 20:17:18 +0000 Subject: [Freeipa-users] Backup and Restoration of IPA Server In-Reply-To: <510EA609.1060206@redhat.com> References: , <510EA609.1060206@redhat.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E407107893F@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, The problem I had with snapshots is I found if snapshoting hot they got confused and the users all doubled on some replicas, on others replication broke...very weird... So snapshot cold. 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: Monday, 4 February 2013 7:01 a.m. To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Backup and Restoration of IPA Server On 02/03/2013 12:10 PM, Rajnesh Kumar Siwal wrote: > As the IPA server has been the backbone of any Company, is there any > recommended approach for Backup/Restore. > Please suggest the best approach how to backup and rebuilt the server > from scratch and restore the IPA Server. > For redundancy we recommend running several replicas so that if you loose one you can easily redeploy. It you want, you can run one of the replicas in a VM and take snapshots of the whole system. A more fine grained Backup/Restore procedure is on the roadmap for the next release. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users From christianh at 4over.com Sun Feb 3 21:07:23 2013 From: christianh at 4over.com (Christian Hernandez) Date: Sun, 3 Feb 2013 13:07:23 -0800 Subject: [Freeipa-users] Backup and Restoration of IPA Server In-Reply-To: <833D8E48405E064EBC54C84EC6B36E407107893F@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <510EA609.1060206@redhat.com> <833D8E48405E064EBC54C84EC6B36E407107893F@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: I also Snapshot Cold. Since I have many replicas; it's really no big deal in shutting down an IPA server for a few seconds to get a quiescent snapshot Thank you, Christian Hernandez 1225 Los Angeles Street Glendale, CA 91204 Phone: 877-782-2737 ext. 4566 Fax: 818-265-3152 christianh at 4over.com www.4over.com On Sun, Feb 3, 2013 at 12:17 PM, Steven Jones wrote: > Hi, > > The problem I had with snapshots is I found if snapshoting hot they got > confused and the users all doubled on some replicas, on others replication > broke...very weird... > > So snapshot cold. > > 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: Monday, 4 February 2013 7:01 a.m. > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Backup and Restoration of IPA Server > > On 02/03/2013 12:10 PM, Rajnesh Kumar Siwal wrote: > > As the IPA server has been the backbone of any Company, is there any > > recommended approach for Backup/Restore. > > Please suggest the best approach how to backup and rebuilt the server > > from scratch and restore the IPA Server. > > > > For redundancy we recommend running several replicas so that if you > loose one you can easily redeploy. > It you want, you can run one of the replicas in a VM and take snapshots > of the whole system. > > A more fine grained Backup/Restore procedure is on the roadmap for the > next release. > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > _______________________________________________ > 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 ssorce at redhat.com Sun Feb 3 23:25:25 2013 From: ssorce at redhat.com (Simo Sorce) Date: Sun, 3 Feb 2013 18:25:25 -0500 (EST) Subject: [Freeipa-users] Errors with Configuring GitHub In-Reply-To: Message-ID: <1684414839.8435946.1359933925841.JavaMail.root@redhat.com> (sorry for top posting, travelling) Christian, I think I have seen this once before from a user trying to use a (IIRC) ruby ldap library to connect to 389ds, he also reported at the time the same thing was working on older 389ds. If I recall correctly it is an actual bug in the client code, but went undetected for long because the older 389 ds was less strict. I am sorry I do not have more details right now. Simo. ----- Original Message ----- > Oh yes, sorry; we all live in Acronyms :-) > Yes centos-ds > Thank you, > Christian Hernandez > 1225 Los Angeles Street > Glendale, CA 91204 > Phone: 877-782-2737 ext. 4566 > Fax: 818-265-3152 > christianh at 4over.com > www.4over.com < http://www.4over.com > > On Fri, Feb 1, 2013 at 4:35 PM, Rich Megginson < rmeggins at redhat.com > > wrote: > > On 02/01/2013 05:29 PM, Christian Hernandez wrote: > > > > And to answer your questions Rich. > > > > > > GitHub was working with CDS 8.1.0 > > > > > What is CDS? Is that centos-ds? > > > > It looks like IPA is using 389 > > > > > > ns-slapd --version > > > > > > 389 Project > > > > > > 389-Directory/ 1.2.10.2 B2012.194.51 > > > > > > Thank you, > > > > > > Christian Hernandez > > > > > > 1225 Los Angeles Street > > > > > > Glendale, CA 91204 > > > > > > Phone: 877-782-2737 ext. 4566 > > > > > > Fax: 818-265-3152 > > > > > > christianh at 4over.com > > > > > > www.4over.com < http://www.4over.com > > > > > > > On Fri, Feb 1, 2013 at 4:25 PM, Christian Hernandez < > > > christianh at 4over.com > wrote: > > > > > > > Hello > > > > > > > > > > Attached is a TCPDUMP. > > > > > > > > > > Communication is happening between 192.168.114.95 and > > > > 192.168.114.114 > > > > > > > > > > Thank you, > > > > > > > > > > Christian Hernandez > > > > > > > > > > On Fri, Feb 1, 2013 at 12:57 PM, Rich Megginson < > > > > rmeggins at redhat.com > > > > > wrote: > > > > > > > > > > > On 02/01/2013 01:42 PM, Christian Hernandez wrote: > > > > > > > > > > > > > > > > We are trying to configure our internal GitHub server to > > > > > > use > > > > > > Our > > > > > > IPA > > > > > > server's LDAP for user logins. > > > > > > > > > > > > > > > > > > > > > We successfully configured it; but users can't seem to > > > > > > login. > > > > > > > > > > > > > > > > > > > > > So, before you ask, yes we do have an active support case > > > > > > with > > > > > > githubenterprise about this; but wanted to see if anyone > > > > > > else > > > > > > ran > > > > > > into the same issue. > > > > > > > > > > > > > > > > > > > > > Attached is the screenshot of the config. > > > > > > > > > > > > > > > > > > > > > This is the errors I'm seeing in the DirSrv logs > > > > > > > > > > > > > > > > > > > > > [25/Jan/2013:15:41:35 -0800] conn=29453 fd=241 slot=241 > > > > > > connection > > > > > > from 192.168.114.95 to 192.168.114.114 > > > > > > > > > > > > > > > > > > > > > [25/Jan/2013:15:41:35 -0800] conn=29453 op=0 BIND > > > > > > dn="uid=admin,cn=users,cn=accounts,dc=4over,dc=com" > > > > > > method=128 > > > > > > version=3 > > > > > > > > > > > > > > > > > > > > > [25/Jan/2013:15:41:35 -0800] conn=29453 op=0 RESULT err=0 > > > > > > tag=97 > > > > > > nentries=0 etime=0 > > > > > > dn="uid=admin,cn=users,cn=accounts,dc=4over,dc=com" > > > > > > > > > > > > > > > > > > > > > [25/Jan/2013:15:41:35 -0800] conn=29453 op=1 SRCH base="" > > > > > > scope=2 > > > > > > filter="(uid=chrish)", failed to decode LDAP controls > > > > > > > > > > > > > > > > > > > > > [25/Jan/2013:15:41:35 -0800] conn=29453 op=1 RESULT err=2 > > > > > > tag=101 > > > > > > nentries=0 etime=0 > > > > > > > > > > > > > > > > > > > > > [25/Jan/2013:15:41:35 -0800] conn=29453 op=-1 fd=241 closed > > > > > > - > > > > > > B1 > > > > > > > > > > > > > > > > > > > > > Anyone has run into this? > > > > > > > > > > > > > > > > > > > > Looks like DS is receiving some LDAP controls that it doesn't > > > > > know > > > > > how to process. Does this work with any other LDAP server? > > > > > Can > > > > > you > > > > > run wireshark/tshark and capture the network traffic? I'd > > > > > like > > > > > to > > > > > see what the BER looks like. > > > > > > > > > > > > > > > > Also, I haven't tried connecting with TLS because I don't > > > > > > know > > > > > > where > > > > > > to find the cert! So if someone can point me in the right > > > > > > direction > > > > > > there I would appreciate it :) > > > > > > > > > > > > > > > > > > > > > Thank you, > > > > > > > > > > > > > > > > > > > > > Christian Hernandez > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > > > > > > > > > Freeipa-users mailing list Freeipa-users at redhat.com > > > > > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > > > > > > > > > > > > > > > Thank you, > > > > > > > > > > Christian Hernandez > > > > > > > > > > 1225 Los Angeles Street > > > > > > > > > > Glendale, CA 91204 > > > > > > > > > > Phone: 877-782-2737 ext. 4566 > > > > > > > > > > Fax: 818-265-3152 > > > > > > > > > > christianh at 4over.com > > > > > > > > > > www.4over.com < http://www.4over.com > > > > > > > > > > > On Fri, Feb 1, 2013 at 12:57 PM, Rich Megginson < > > > > rmeggins at redhat.com > > > > > wrote: > > > > > > > > > > > On 02/01/2013 01:42 PM, Christian Hernandez wrote: > > > > > > > > > > > > > > > > We are trying to configure our internal GitHub server to > > > > > > use > > > > > > Our > > > > > > IPA > > > > > > server's LDAP for user logins. > > > > > > > > > > > > > > > > > > > > > We successfully configured it; but users can't seem to > > > > > > login. > > > > > > > > > > > > > > > > > > > > > So, before you ask, yes we do have an active support case > > > > > > with > > > > > > githubenterprise about this; but wanted to see if anyone > > > > > > else > > > > > > ran > > > > > > into the same issue. > > > > > > > > > > > > > > > > > > > > > Attached is the screenshot of the config. > > > > > > > > > > > > > > > > > > > > > This is the errors I'm seeing in the DirSrv logs > > > > > > > > > > > > > > > > > > > > > [25/Jan/2013:15:41:35 -0800] conn=29453 fd=241 slot=241 > > > > > > connection > > > > > > from 192.168.114.95 to 192.168.114.114 > > > > > > > > > > > > > > > > > > > > > [25/Jan/2013:15:41:35 -0800] conn=29453 op=0 BIND > > > > > > dn="uid=admin,cn=users,cn=accounts,dc=4over,dc=com" > > > > > > method=128 > > > > > > version=3 > > > > > > > > > > > > > > > > > > > > > [25/Jan/2013:15:41:35 -0800] conn=29453 op=0 RESULT err=0 > > > > > > tag=97 > > > > > > nentries=0 etime=0 > > > > > > dn="uid=admin,cn=users,cn=accounts,dc=4over,dc=com" > > > > > > > > > > > > > > > > > > > > > [25/Jan/2013:15:41:35 -0800] conn=29453 op=1 SRCH base="" > > > > > > scope=2 > > > > > > filter="(uid=chrish)", failed to decode LDAP controls > > > > > > > > > > > > > > > > > > > > > [25/Jan/2013:15:41:35 -0800] conn=29453 op=1 RESULT err=2 > > > > > > tag=101 > > > > > > nentries=0 etime=0 > > > > > > > > > > > > > > > > > > > > > [25/Jan/2013:15:41:35 -0800] conn=29453 op=-1 fd=241 closed > > > > > > - > > > > > > B1 > > > > > > > > > > > > > > > > > > > > > Anyone has run into this? > > > > > > > > > > > > > > > > > > > > Looks like DS is receiving some LDAP controls that it doesn't > > > > > know > > > > > how to process. Does this work with any other LDAP server? > > > > > Can > > > > > you > > > > > run wireshark/tshark and capture the network traffic? I'd > > > > > like > > > > > to > > > > > see what the BER looks like. > > > > > > > > > > > > > > > > Also, I haven't tried connecting with TLS because I don't > > > > > > know > > > > > > where > > > > > > to find the cert! So if someone can point me in the right > > > > > > direction > > > > > > there I would appreciate it :) > > > > > > > > > > > > > > > > > > > > > Thank you, > > > > > > > > > > > > > > > > > > > > > Christian Hernandez > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > > > > > > > > > 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 -- Simo Sorce * Red Hat, Inc. * New York -------------- next part -------------- An HTML attachment was scrubbed... URL: From christianh at 4over.com Mon Feb 4 02:26:30 2013 From: christianh at 4over.com (Christian Hernandez) Date: Sun, 3 Feb 2013 18:26:30 -0800 Subject: [Freeipa-users] Errors with Configuring GitHub In-Reply-To: <1684414839.8435946.1359933925841.JavaMail.root@redhat.com> References: <1684414839.8435946.1359933925841.JavaMail.root@redhat.com> Message-ID: I have provided some feedback to GitHub enterprise. Hopefully they provide something meaningful - or if there is an update in Ruby; that they'll support some sort of patch. Thank you, Christian Hernandez On Sun, Feb 3, 2013 at 3:25 PM, Simo Sorce wrote: > (sorry for top posting, travelling) > > Christian, I think I have seen this once before from a user trying to use > a (IIRC) ruby ldap library to connect to 389ds, he also reported at the > time the same thing was working on older 389ds. If I recall correctly it is > an actual bug in the client code, but went undetected for long because the > older 389 ds was less strict. > > I am sorry I do not have more details right now. > > Simo. > > ------------------------------ > > Oh yes, sorry; we all live in Acronyms :-) > > Yes centos-ds > > > Thank you, > > Christian Hernandez > 1225 Los Angeles Street > Glendale, CA 91204 > Phone: 877-782-2737 ext. 4566 > Fax: 818-265-3152 > christianh at 4over.com > www.4over.com > > > On Fri, Feb 1, 2013 at 4:35 PM, Rich Megginson wrote: > >> On 02/01/2013 05:29 PM, Christian Hernandez wrote: >> >> And to answer your questions Rich. >> >> GitHub was working with CDS 8.1.0 >> >> >> What is CDS? Is that centos-ds? >> >> >> >> It looks like IPA is using 389 >> >> ns-slapd --version >> 389 Project >> 389-Directory/1.2.10.2 B2012.194.51 >> >> >> Thank you, >> >> Christian Hernandez >> 1225 Los Angeles Street >> Glendale, CA 91204 >> Phone: 877-782-2737 ext. 4566 >> Fax: 818-265-3152 >> christianh at 4over.com >> www.4over.com >> >> >> On Fri, Feb 1, 2013 at 4:25 PM, Christian Hernandez > > wrote: >> >>> Hello >>> >>> Attached is a TCPDUMP. >>> >>> Communication is happening between 192.168.114.95 and 192.168.114.114 >>> >>> Thank you, >>> >>> Christian Hernandez >>> >>> >>> On Fri, Feb 1, 2013 at 12:57 PM, Rich Megginson wrote: >>> >>>> On 02/01/2013 01:42 PM, Christian Hernandez wrote: >>>> >>>> We are trying to configure our internal GitHub server to use Our >>>> IPA server's LDAP for user logins. >>>> >>>> We successfully configured it; but users can't seem to login. >>>> >>>> So, before you ask, yes we do have an active support case with >>>> githubenterprise about this; but wanted to see if anyone else ran into the >>>> same issue. >>>> >>>> Attached is the screenshot of the config. >>>> >>>> This is the errors I'm seeing in the DirSrv logs >>>> >>>> >>>> [25/Jan/2013:15:41:35 -0800] conn=29453 fd=241 slot=241 connection >>>> from 192.168.114.95 to 192.168.114.114 >>>> [25/Jan/2013:15:41:35 -0800] conn=29453 op=0 BIND >>>> dn="uid=admin,cn=users,cn=accounts,dc=4over,dc=com" method=128 version=3 >>>> [25/Jan/2013:15:41:35 -0800] conn=29453 op=0 RESULT err=0 tag=97 >>>> nentries=0 etime=0 dn="uid=admin,cn=users,cn=accounts,dc=4over,dc=com" >>>> [25/Jan/2013:15:41:35 -0800] conn=29453 op=1 SRCH base="" scope=2 >>>> filter="(uid=chrish)", failed to decode LDAP controls >>>> [25/Jan/2013:15:41:35 -0800] conn=29453 op=1 RESULT err=2 tag=101 >>>> nentries=0 etime=0 >>>> [25/Jan/2013:15:41:35 -0800] conn=29453 op=-1 fd=241 closed - B1 >>>> >>>> Anyone has run into this? >>>> >>>> >>>> Looks like DS is receiving some LDAP controls that it doesn't know how >>>> to process. Does this work with any other LDAP server? Can you run >>>> wireshark/tshark and capture the network traffic? I'd like to see what the >>>> BER looks like. >>>> >>>> >>>> Also, I haven't tried connecting with TLS because I don't know where to >>>> find the cert! So if someone can point me in the right direction there I >>>> would appreciate it :) >>>> >>>> Thank you, >>>> >>>> Christian Hernandez >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users >>>> >>>> >>>> >>> >>> >>> Thank you, >>> >>> Christian Hernandez >>> 1225 Los Angeles Street >>> Glendale, CA 91204 >>> Phone: 877-782-2737 ext. 4566 >>> Fax: 818-265-3152 >>> christianh at 4over.com >>> www.4over.com >>> >>> >>> On Fri, Feb 1, 2013 at 12:57 PM, Rich Megginson wrote: >>> >>>> On 02/01/2013 01:42 PM, Christian Hernandez wrote: >>>> >>>> We are trying to configure our internal GitHub server to use Our >>>> IPA server's LDAP for user logins. >>>> >>>> We successfully configured it; but users can't seem to login. >>>> >>>> So, before you ask, yes we do have an active support case with >>>> githubenterprise about this; but wanted to see if anyone else ran into the >>>> same issue. >>>> >>>> Attached is the screenshot of the config. >>>> >>>> This is the errors I'm seeing in the DirSrv logs >>>> >>>> >>>> [25/Jan/2013:15:41:35 -0800] conn=29453 fd=241 slot=241 connection >>>> from 192.168.114.95 to 192.168.114.114 >>>> [25/Jan/2013:15:41:35 -0800] conn=29453 op=0 BIND >>>> dn="uid=admin,cn=users,cn=accounts,dc=4over,dc=com" method=128 version=3 >>>> [25/Jan/2013:15:41:35 -0800] conn=29453 op=0 RESULT err=0 tag=97 >>>> nentries=0 etime=0 dn="uid=admin,cn=users,cn=accounts,dc=4over,dc=com" >>>> [25/Jan/2013:15:41:35 -0800] conn=29453 op=1 SRCH base="" scope=2 >>>> filter="(uid=chrish)", failed to decode LDAP controls >>>> [25/Jan/2013:15:41:35 -0800] conn=29453 op=1 RESULT err=2 tag=101 >>>> nentries=0 etime=0 >>>> [25/Jan/2013:15:41:35 -0800] conn=29453 op=-1 fd=241 closed - B1 >>>> >>>> Anyone has run into this? >>>> >>>> >>>> Looks like DS is receiving some LDAP controls that it doesn't know how >>>> to process. Does this work with any other LDAP server? Can you run >>>> wireshark/tshark and capture the network traffic? I'd like to see what the >>>> BER looks like. >>>> >>>> >>>> Also, I haven't tried connecting with TLS because I don't know where to >>>> find the cert! So if someone can point me in the right direction there I >>>> would appreciate it :) >>>> >>>> Thank you, >>>> >>>> Christian Hernandez >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users >>>> >>>> >>>> >>> >> >> > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > -- > Simo Sorce * Red Hat, Inc. * New York > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rajnesh.siwal at gmail.com Mon Feb 4 06:29:46 2013 From: rajnesh.siwal at gmail.com (Rajnesh Kumar Siwal) Date: Mon, 4 Feb 2013 11:59:46 +0530 Subject: [Freeipa-users] RHEL 6.3 identity manual - IPA Message-ID: I am planning to use the sudo feature on IPA 2.2. By default the IPA client that I configured does not seems to use fetch the sudo user details. It looks that we need to modify nsswitch.conf and ldap.conf to support it. Can sssd take care of fetching the sudo user details ? Secondly, I am not able to find the password for uid=sudo,cn=sysaccounts,cn=etc,dc=example,dc=com . How do I find it ? Will it be safe to change password of this sudo user or it may impact the IPA Server ? Please suggest. -- Regards, Rajnesh Kumar Siwal From rajnesh.siwal at gmail.com Mon Feb 4 07:52:37 2013 From: rajnesh.siwal at gmail.com (Rajnesh Kumar Siwal) Date: Mon, 4 Feb 2013 13:22:37 +0530 Subject: [Freeipa-users] sudo rule working even after the user has been removed from the sudo rule Message-ID: Hi all, I have just created a setup for sudo on the IPA Server 2.2. I modified nsswitch.conf to use ldap. ldap.conf has been modified to fetch sudo users from the IPA Server. Now, th euser in group "admin" can do sudo. 1. rsiwal being a user of group sudo can run all commands as sudo (FINE) 2. If I disable the rule "Admins" (that I admin group access to sudo), the sudo still works for the user rsiwal (Which should not work logically). 3. Removed the group "Admins" (including rsiwal) from the Sudo rule. The rule is still allowing user rsiwal to run "sudo su -". (It should Fail) Is there some kind of caching being at the Server / client end ? -- Regards, Rajnesh Kumar Siwal From fvzwieten at vxcompany.com Mon Feb 4 08:24:18 2013 From: fvzwieten at vxcompany.com (Fred van Zwieten) Date: Mon, 4 Feb 2013 09:24:18 +0100 Subject: [Freeipa-users] RHEL 6.3 identity manual - IPA In-Reply-To: References: Message-ID: Hi, ipa-client-install should take care of setting up sudo on the client to use IPA, afaik. Essential line in nsswitch.conf: sudoers: files ldap Please read here As for the second question. dc=example,dc=com is, well, an example. example.com is used throughout the documentation for documentation purposes where a domain name is needed. Please replace is with you're domain, e.g. dc=yourcompanyname,dc=com Met vriendelijke groeten, * Fred* On Mon, Feb 4, 2013 at 7:29 AM, Rajnesh Kumar Siwal wrote: > I am planning to use the sudo feature on IPA 2.2. By default the IPA > client that I configured does not seems to use fetch the sudo user > details. > > It looks that we need to modify nsswitch.conf and ldap.conf to support it. > > Can sssd take care of fetching the sudo user details ? > > Secondly, I am not able to find the password for > uid=sudo,cn=sysaccounts,cn=etc,dc=example,dc=com . How do I find it ? > Will it be safe to change password of this sudo user or it may impact > the IPA Server ? > > Please suggest. > > > -- > Regards, > Rajnesh Kumar Siwal > > _______________________________________________ > 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 rajnesh.siwal at gmail.com Mon Feb 4 08:32:18 2013 From: rajnesh.siwal at gmail.com (Rajnesh Kumar Siwal) Date: Mon, 4 Feb 2013 14:02:18 +0530 Subject: [Freeipa-users] sudo rule working even after the user has been removed from the sudo rule In-Reply-To: References: Message-ID: Here is the outuput of ldapsearch :- dn: cn=Admins,ou=sudoers,dc=example,dc=com objectClass: sudoRole sudoUser: %ctsadmin sudoHost: ALL sudoCommand: ALL sudoRunAsUser: ALL cn: Admins The rule still says that the group ctsadmin is allowed (Which should not happen after I remove the ctsadmin group from sudo access) On the IPA Web Interface there is not sudo role attached to the User "rsiwal" (Neither Direct nor Indirect). May be there is some bug. On Mon, Feb 4, 2013 at 1:22 PM, Rajnesh Kumar Siwal wrote: > Hi all, > > I have just created a setup for sudo on the IPA Server 2.2. > I modified nsswitch.conf to use ldap. > ldap.conf has been modified to fetch sudo users from the IPA Server. > > Now, th euser in group "admin" can do sudo. > 1. rsiwal being a user of group sudo can run all commands as sudo (FINE) > 2. If I disable the rule "Admins" (that I admin group access to > sudo), the sudo still works for the user rsiwal (Which should not work > logically). > 3. Removed the group "Admins" (including rsiwal) from the Sudo > rule. The rule is still allowing user rsiwal to run "sudo su -". (It > should Fail) > > Is there some kind of caching being at the Server / client end ? > > -- > Regards, > Rajnesh Kumar Siwal -- Regards, Rajnesh Kumar Siwal From rajnesh.siwal at gmail.com Mon Feb 4 08:33:47 2013 From: rajnesh.siwal at gmail.com (Rajnesh Kumar Siwal) Date: Mon, 4 Feb 2013 14:03:47 +0530 Subject: [Freeipa-users] RHEL 6.3 identity manual - IPA In-Reply-To: References: Message-ID: IPA client on CentOS 5.6 was not able to take care of it.) On Mon, Feb 4, 2013 at 1:54 PM, Fred van Zwieten wrote: > Hi, > > ipa-client-install should take care of setting up sudo on the client to use > IPA, afaik. > > Essential line in nsswitch.conf: > sudoers: files ldap > > Please read here > > As for the second question. dc=example,dc=com is, well, an example. > example.com is used throughout the documentation for documentation purposes > where a domain name is needed. Please replace is with you're domain, e.g. > dc=yourcompanyname,dc=com > > Met vriendelijke groeten, > > Fred > > > On Mon, Feb 4, 2013 at 7:29 AM, Rajnesh Kumar Siwal > wrote: >> >> I am planning to use the sudo feature on IPA 2.2. By default the IPA >> client that I configured does not seems to use fetch the sudo user >> details. >> >> It looks that we need to modify nsswitch.conf and ldap.conf to support it. >> >> Can sssd take care of fetching the sudo user details ? >> >> Secondly, I am not able to find the password for >> uid=sudo,cn=sysaccounts,cn=etc,dc=example,dc=com . How do I find it ? >> Will it be safe to change password of this sudo user or it may impact >> the IPA Server ? >> >> Please suggest. >> >> >> -- >> Regards, >> Rajnesh Kumar Siwal >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > -- Regards, Rajnesh Kumar Siwal From rajnesh.siwal at gmail.com Mon Feb 4 08:48:12 2013 From: rajnesh.siwal at gmail.com (Rajnesh Kumar Siwal) Date: Mon, 4 Feb 2013 14:18:12 +0530 Subject: [Freeipa-users] SOLVED: Re: sudo rule working even after the user has been removed from the sudo rule Message-ID: Looking into the sssd logs, I came to know there there was one more rule allowing access:- (Mon Feb 4 14:13:01 2013) [sssd[be[chargepoint.dmz]]] [hbac_get_category] (5): Category is set to 'all'. (Mon Feb 4 14:13:01 2013) [sssd[be[chargepoint.dmz]]] [ipa_hbac_evaluate_rules] (3): Access granted by HBAC rule [allow_all] (Mon Feb 4 14:13:01 2013) [sssd[be[chargepoint.dmz]]] [be_pam_handler_callback] (4): Backend returned: (0, 0, ) [Success] I disabled that allow_all rule, now it is fine. On Mon, Feb 4, 2013 at 2:02 PM, Rajnesh Kumar Siwal wrote: > Here is the outuput of ldapsearch :- > dn: cn=Admins,ou=sudoers,dc=example,dc=com > objectClass: sudoRole > sudoUser: %ctsadmin > sudoHost: ALL > sudoCommand: ALL > sudoRunAsUser: ALL > cn: Admins > > The rule still says that the group ctsadmin is allowed (Which should > not happen after I remove the ctsadmin group from sudo access) > On the IPA Web Interface there is not sudo role attached to the User > "rsiwal" (Neither Direct nor Indirect). > May be there is some bug. > > > On Mon, Feb 4, 2013 at 1:22 PM, Rajnesh Kumar Siwal > wrote: >> Hi all, >> >> I have just created a setup for sudo on the IPA Server 2.2. >> I modified nsswitch.conf to use ldap. >> ldap.conf has been modified to fetch sudo users from the IPA Server. >> >> Now, th euser in group "admin" can do sudo. >> 1. rsiwal being a user of group sudo can run all commands as sudo (FINE) >> 2. If I disable the rule "Admins" (that I admin group access to >> sudo), the sudo still works for the user rsiwal (Which should not work >> logically). >> 3. Removed the group "Admins" (including rsiwal) from the Sudo >> rule. The rule is still allowing user rsiwal to run "sudo su -". (It >> should Fail) >> >> Is there some kind of caching being at the Server / client end ? >> >> -- >> Regards, >> Rajnesh Kumar Siwal > > > > -- > Regards, > Rajnesh Kumar Siwal -- Regards, Rajnesh Kumar Siwal From rajnesh.siwal at gmail.com Mon Feb 4 10:24:31 2013 From: rajnesh.siwal at gmail.com (Rajnesh Kumar Siwal) Date: Mon, 4 Feb 2013 15:54:31 +0530 Subject: [Freeipa-users] sudo rule working even after the user has been removed from the sudo rule Message-ID: I deleted the following entry from the IPA WebUI "All Except Shell" (Sudo Role) but ldapsearch still fetches it (Effectively sudo works after the deletion of the rule) :- dn: cn=All Except Shell,ou=sudoers,dc=example,dc=com objectClass: sudoRole sudoUser: %ctsadmin sudoHost: ALL sudoCommand: ALL sudoRunAsUser: ALL sudoOption: !authenticate cn: All Except Shell Is it present in cache somewhere ? On Mon, Feb 4, 2013 at 2:18 PM, Rajnesh Kumar Siwal wrote: > Looking into the sssd logs, I came to know there there was one more > rule allowing access:- > (Mon Feb 4 14:13:01 2013) [sssd[be[chargepoint.dmz]]] > [hbac_get_category] (5): Category is set to 'all'. > (Mon Feb 4 14:13:01 2013) [sssd[be[chargepoint.dmz]]] > [ipa_hbac_evaluate_rules] (3): Access granted by HBAC rule [allow_all] > (Mon Feb 4 14:13:01 2013) [sssd[be[chargepoint.dmz]]] > [be_pam_handler_callback] (4): Backend returned: (0, 0, ) > [Success] > > I disabled that allow_all rule, now it is fine. > > On Mon, Feb 4, 2013 at 2:02 PM, Rajnesh Kumar Siwal > wrote: >> Here is the outuput of ldapsearch :- >> dn: cn=Admins,ou=sudoers,dc=example,dc=com >> objectClass: sudoRole >> sudoUser: %ctsadmin >> sudoHost: ALL >> sudoCommand: ALL >> sudoRunAsUser: ALL >> cn: Admins >> >> The rule still says that the group ctsadmin is allowed (Which should >> not happen after I remove the ctsadmin group from sudo access) >> On the IPA Web Interface there is not sudo role attached to the User >> "rsiwal" (Neither Direct nor Indirect). >> May be there is some bug. >> >> >> On Mon, Feb 4, 2013 at 1:22 PM, Rajnesh Kumar Siwal >> wrote: >>> Hi all, >>> >>> I have just created a setup for sudo on the IPA Server 2.2. >>> I modified nsswitch.conf to use ldap. >>> ldap.conf has been modified to fetch sudo users from the IPA Server. >>> >>> Now, th euser in group "admin" can do sudo. >>> 1. rsiwal being a user of group sudo can run all commands as sudo (FINE) >>> 2. If I disable the rule "Admins" (that I admin group access to >>> sudo), the sudo still works for the user rsiwal (Which should not work >>> logically). >>> 3. Removed the group "Admins" (including rsiwal) from the Sudo >>> rule. The rule is still allowing user rsiwal to run "sudo su -". (It >>> should Fail) >>> >>> Is there some kind of caching being at the Server / client end ? >>> >>> -- >>> Regards, >>> Rajnesh Kumar Siwal >> >> >> >> -- >> Regards, >> Rajnesh Kumar Siwal > > > > -- > Regards, > Rajnesh Kumar Siwal -- Regards, Rajnesh Kumar Siwal From jorick at netbulae.eu Mon Feb 4 10:31:09 2013 From: jorick at netbulae.eu (Jorick Astrego) Date: Mon, 04 Feb 2013 11:31:09 +0100 Subject: [Freeipa-users] CRITICAL Failed to load upload-cacert.ldif In-Reply-To: References: Message-ID: <510F8DED.5010909@netbulae.eu> Hi, Running the installer of the latest stable on a fresh Fedora 18, I get the following error during install: > [30/36]: Upload CA cert to the directory > ipa : CRITICAL Failed to load upload-cacert.ldif: Command > '/usr/bin/ldapmodify -v -f /tmp/tmpLFZEuz -H ldap://xxxx.xxxx.xxxx:389 > -x -D cn=Directory Manager -y /tmp/tmpYzjl4P' returned non-zero exit > status 247 > [31/36]: initializing group membership -- Kind regards, Jorick Astrego Netbulae B.V. From rajnesh.siwal at gmail.com Mon Feb 4 10:47:33 2013 From: rajnesh.siwal at gmail.com (Rajnesh Kumar Siwal) Date: Mon, 4 Feb 2013 16:17:33 +0530 Subject: [Freeipa-users] sudo rule working even after the user has been removed from the sudo rule In-Reply-To: References: Message-ID: Restarting IPA removed the rule that was deleted manually through GUI . It looks like a bug the IPA Webui was not able to delete the sudo rule "cn: All Except Shell" On Mon, Feb 4, 2013 at 3:54 PM, Rajnesh Kumar Siwal wrote: > I deleted the following entry from the IPA WebUI "All Except Shell" > (Sudo Role) but ldapsearch still fetches it (Effectively sudo works > after the deletion of the rule) :- > > dn: cn=All Except Shell,ou=sudoers,dc=example,dc=com > objectClass: sudoRole > sudoUser: %ctsadmin > sudoHost: ALL > sudoCommand: ALL > sudoRunAsUser: ALL > sudoOption: !authenticate > cn: All Except Shell > > Is it present in cache somewhere ? > > On Mon, Feb 4, 2013 at 2:18 PM, Rajnesh Kumar Siwal > wrote: >> Looking into the sssd logs, I came to know there there was one more >> rule allowing access:- >> (Mon Feb 4 14:13:01 2013) [sssd[be[chargepoint.dmz]]] >> [hbac_get_category] (5): Category is set to 'all'. >> (Mon Feb 4 14:13:01 2013) [sssd[be[chargepoint.dmz]]] >> [ipa_hbac_evaluate_rules] (3): Access granted by HBAC rule [allow_all] >> (Mon Feb 4 14:13:01 2013) [sssd[be[chargepoint.dmz]]] >> [be_pam_handler_callback] (4): Backend returned: (0, 0, ) >> [Success] >> >> I disabled that allow_all rule, now it is fine. >> >> On Mon, Feb 4, 2013 at 2:02 PM, Rajnesh Kumar Siwal >> wrote: >>> Here is the outuput of ldapsearch :- >>> dn: cn=Admins,ou=sudoers,dc=example,dc=com >>> objectClass: sudoRole >>> sudoUser: %ctsadmin >>> sudoHost: ALL >>> sudoCommand: ALL >>> sudoRunAsUser: ALL >>> cn: Admins >>> >>> The rule still says that the group ctsadmin is allowed (Which should >>> not happen after I remove the ctsadmin group from sudo access) >>> On the IPA Web Interface there is not sudo role attached to the User >>> "rsiwal" (Neither Direct nor Indirect). >>> May be there is some bug. >>> >>> >>> On Mon, Feb 4, 2013 at 1:22 PM, Rajnesh Kumar Siwal >>> wrote: >>>> Hi all, >>>> >>>> I have just created a setup for sudo on the IPA Server 2.2. >>>> I modified nsswitch.conf to use ldap. >>>> ldap.conf has been modified to fetch sudo users from the IPA Server. >>>> >>>> Now, th euser in group "admin" can do sudo. >>>> 1. rsiwal being a user of group sudo can run all commands as sudo (FINE) >>>> 2. If I disable the rule "Admins" (that I admin group access to >>>> sudo), the sudo still works for the user rsiwal (Which should not work >>>> logically). >>>> 3. Removed the group "Admins" (including rsiwal) from the Sudo >>>> rule. The rule is still allowing user rsiwal to run "sudo su -". (It >>>> should Fail) >>>> >>>> Is there some kind of caching being at the Server / client end ? >>>> >>>> -- >>>> Regards, >>>> Rajnesh Kumar Siwal >>> >>> >>> >>> -- >>> Regards, >>> Rajnesh Kumar Siwal >> >> >> >> -- >> Regards, >> Rajnesh Kumar Siwal > > > > -- > Regards, > Rajnesh Kumar Siwal -- Regards, Rajnesh Kumar Siwal From mkosek at redhat.com Mon Feb 4 10:52:26 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 04 Feb 2013 11:52:26 +0100 Subject: [Freeipa-users] CRITICAL Failed to load upload-cacert.ldif In-Reply-To: <510F8DED.5010909@netbulae.eu> References: <510F8DED.5010909@netbulae.eu> Message-ID: <510F92EA.5070407@redhat.com> On 02/04/2013 11:31 AM, Jorick Astrego wrote: > Hi, > > Running the installer of the latest stable on a fresh Fedora 18, I get the > following error during install: > >> [30/36]: Upload CA cert to the directory >> ipa : CRITICAL Failed to load upload-cacert.ldif: Command >> '/usr/bin/ldapmodify -v -f /tmp/tmpLFZEuz -H ldap://xxxx.xxxx.xxxx:389 -x -D >> cn=Directory Manager -y /tmp/tmpYzjl4P' returned non-zero exit status 247 >> [31/36]: initializing group membership > > Hello Jorick, this is a benign error message as per https://fedorahosted.org/freeipa/ticket/3375 You can safely ignore it. The error message will be fixed in next release... Martin From rajnesh.siwal at gmail.com Mon Feb 4 10:54:22 2013 From: rajnesh.siwal at gmail.com (Rajnesh Kumar Siwal) Date: Mon, 4 Feb 2013 16:24:22 +0530 Subject: [Freeipa-users] Backup and Restoration of IPA Server Message-ID: Does it means that we don't have any backup / restoration process as of now for IPA 2.2 ? I am really concerned about such a critical application. It would be greate if you could please specify the set of manual commands in case they can be used for Backup / Restoration purpose. -- Regards, Rajnesh Kumar Siwal From fvzwieten at vxcompany.com Mon Feb 4 11:12:52 2013 From: fvzwieten at vxcompany.com (Fred van Zwieten) Date: Mon, 4 Feb 2013 12:12:52 +0100 Subject: [Freeipa-users] Backup and Restoration of IPA Server In-Reply-To: References: Message-ID: This triggers me on something related. We do use snapshots on VM's. However, we want to separate data and system disks within the guests. We have /var on a seperate disk and only that disk is getting snapshots. So, is IPA data living in /var? Fred On Mon, Feb 4, 2013 at 11:54 AM, Rajnesh Kumar Siwal < rajnesh.siwal at gmail.com> wrote: > Does it means that we don't have any backup / restoration process as > of now for IPA 2.2 ? > I am really concerned about such a critical application. > > It would be greate if you could please specify the set of manual > commands in case they can be used for Backup / Restoration purpose. > > -- > Regards, > Rajnesh Kumar Siwal > > _______________________________________________ > 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 natxo.asenjo at gmail.com Mon Feb 4 11:13:51 2013 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Mon, 4 Feb 2013 12:13:51 +0100 Subject: [Freeipa-users] RHEL 6.3 identity manual - IPA In-Reply-To: References: Message-ID: On Mon, Feb 4, 2013 at 9:33 AM, Rajnesh Kumar Siwal wrote: > IPA client on CentOS 5.6 was not able to take care of it.) that's why you should be using a config management tool like cfengine, puppet, chef, ansible, ....., (choose your poison). Organizations usually have multiple admins and people make mistakes. Config tools ensure configs are consistent (they can also wreak havoc if not used properly haha), but that's where test/dev systems are for ;-) -- groet, natxo From rcritten at redhat.com Mon Feb 4 14:20:11 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 04 Feb 2013 09:20:11 -0500 Subject: [Freeipa-users] RHEL 6.3 identity manual - IPA In-Reply-To: References: Message-ID: <510FC39B.8030505@redhat.com> Fred van Zwieten wrote: > Hi, > > ipa-client-install should take care of setting up sudo on the client to > use IPA, afaik. > Not yet, https://fedorahosted.org/freeipa/ticket/3358 > Essential line in nsswitch.conf: > sudoers: files ldap > > Please read here > Note that the configuration file name is wrong for RHEL 6. You need to use /etc/sudo-ldap.conf. rob > > As for the second question. dc=example,dc=com is, well, an example. > example.com is used throughout the documentation > for documentation purposes where a domain name is needed. Please replace > is with you're domain, e.g. dc=yourcompanyname,dc=com > > Met vriendelijke groeten, > * > Fred* > > > On Mon, Feb 4, 2013 at 7:29 AM, Rajnesh Kumar Siwal > > wrote: > > I am planning to use the sudo feature on IPA 2.2. By default the IPA > client that I configured does not seems to use fetch the sudo user > details. > > It looks that we need to modify nsswitch.conf and ldap.conf to > support it. > > Can sssd take care of fetching the sudo user details ? > > Secondly, I am not able to find the password for > uid=sudo,cn=sysaccounts,cn=etc,dc=example,dc=com . How do I find it ? > Will it be safe to change password of this sudo user or it may impact > the IPA Server ? > > Please suggest. > > > -- > Regards, > Rajnesh Kumar Siwal > > _______________________________________________ > 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 Mon Feb 4 14:21:32 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 04 Feb 2013 09:21:32 -0500 Subject: [Freeipa-users] SOLVED: Re: sudo rule working even after the user has been removed from the sudo rule In-Reply-To: References: Message-ID: <510FC3EC.7090200@redhat.com> Rajnesh Kumar Siwal wrote: > Looking into the sssd logs, I came to know there there was one more > rule allowing access:- > (Mon Feb 4 14:13:01 2013) [sssd[be[chargepoint.dmz]]] > [hbac_get_category] (5): Category is set to 'all'. > (Mon Feb 4 14:13:01 2013) [sssd[be[chargepoint.dmz]]] > [ipa_hbac_evaluate_rules] (3): Access granted by HBAC rule [allow_all] > (Mon Feb 4 14:13:01 2013) [sssd[be[chargepoint.dmz]]] > [be_pam_handler_callback] (4): Backend returned: (0, 0, ) > [Success] > > I disabled that allow_all rule, now it is fine. I don't know why that would make any difference. HBAC != sudo. rob > > On Mon, Feb 4, 2013 at 2:02 PM, Rajnesh Kumar Siwal > wrote: >> Here is the outuput of ldapsearch :- >> dn: cn=Admins,ou=sudoers,dc=example,dc=com >> objectClass: sudoRole >> sudoUser: %ctsadmin >> sudoHost: ALL >> sudoCommand: ALL >> sudoRunAsUser: ALL >> cn: Admins >> >> The rule still says that the group ctsadmin is allowed (Which should >> not happen after I remove the ctsadmin group from sudo access) >> On the IPA Web Interface there is not sudo role attached to the User >> "rsiwal" (Neither Direct nor Indirect). >> May be there is some bug. >> >> >> On Mon, Feb 4, 2013 at 1:22 PM, Rajnesh Kumar Siwal >> wrote: >>> Hi all, >>> >>> I have just created a setup for sudo on the IPA Server 2.2. >>> I modified nsswitch.conf to use ldap. >>> ldap.conf has been modified to fetch sudo users from the IPA Server. >>> >>> Now, th euser in group "admin" can do sudo. >>> 1. rsiwal being a user of group sudo can run all commands as sudo (FINE) >>> 2. If I disable the rule "Admins" (that I admin group access to >>> sudo), the sudo still works for the user rsiwal (Which should not work >>> logically). >>> 3. Removed the group "Admins" (including rsiwal) from the Sudo >>> rule. The rule is still allowing user rsiwal to run "sudo su -". (It >>> should Fail) >>> >>> Is there some kind of caching being at the Server / client end ? >>> >>> -- >>> Regards, >>> Rajnesh Kumar Siwal >> >> >> >> -- >> Regards, >> Rajnesh Kumar Siwal > > > From rcritten at redhat.com Mon Feb 4 14:29:56 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 04 Feb 2013 09:29:56 -0500 Subject: [Freeipa-users] sudo rule working even after the user has been removed from the sudo rule In-Reply-To: References: Message-ID: <510FC5E4.7090406@redhat.com> Rajnesh Kumar Siwal wrote: > I deleted the following entry from the IPA WebUI "All Except Shell" > (Sudo Role) but ldapsearch still fetches it (Effectively sudo works > after the deletion of the rule) :- > > dn: cn=All Except Shell,ou=sudoers,dc=example,dc=com > objectClass: sudoRole > sudoUser: %ctsadmin > sudoHost: ALL > sudoCommand: ALL > sudoRunAsUser: ALL > sudoOption: !authenticate > cn: All Except Shell > > Is it present in cache somewhere ? I think we need more information on your configuration, distribution, exact package version(s) and what you've done. rob > > On Mon, Feb 4, 2013 at 2:18 PM, Rajnesh Kumar Siwal > wrote: >> Looking into the sssd logs, I came to know there there was one more >> rule allowing access:- >> (Mon Feb 4 14:13:01 2013) [sssd[be[chargepoint.dmz]]] >> [hbac_get_category] (5): Category is set to 'all'. >> (Mon Feb 4 14:13:01 2013) [sssd[be[chargepoint.dmz]]] >> [ipa_hbac_evaluate_rules] (3): Access granted by HBAC rule [allow_all] >> (Mon Feb 4 14:13:01 2013) [sssd[be[chargepoint.dmz]]] >> [be_pam_handler_callback] (4): Backend returned: (0, 0, ) >> [Success] >> >> I disabled that allow_all rule, now it is fine. >> >> On Mon, Feb 4, 2013 at 2:02 PM, Rajnesh Kumar Siwal >> wrote: >>> Here is the outuput of ldapsearch :- >>> dn: cn=Admins,ou=sudoers,dc=example,dc=com >>> objectClass: sudoRole >>> sudoUser: %ctsadmin >>> sudoHost: ALL >>> sudoCommand: ALL >>> sudoRunAsUser: ALL >>> cn: Admins >>> >>> The rule still says that the group ctsadmin is allowed (Which should >>> not happen after I remove the ctsadmin group from sudo access) >>> On the IPA Web Interface there is not sudo role attached to the User >>> "rsiwal" (Neither Direct nor Indirect). >>> May be there is some bug. >>> >>> >>> On Mon, Feb 4, 2013 at 1:22 PM, Rajnesh Kumar Siwal >>> wrote: >>>> Hi all, >>>> >>>> I have just created a setup for sudo on the IPA Server 2.2. >>>> I modified nsswitch.conf to use ldap. >>>> ldap.conf has been modified to fetch sudo users from the IPA Server. >>>> >>>> Now, th euser in group "admin" can do sudo. >>>> 1. rsiwal being a user of group sudo can run all commands as sudo (FINE) >>>> 2. If I disable the rule "Admins" (that I admin group access to >>>> sudo), the sudo still works for the user rsiwal (Which should not work >>>> logically). >>>> 3. Removed the group "Admins" (including rsiwal) from the Sudo >>>> rule. The rule is still allowing user rsiwal to run "sudo su -". (It >>>> should Fail) >>>> >>>> Is there some kind of caching being at the Server / client end ? >>>> >>>> -- >>>> Regards, >>>> Rajnesh Kumar Siwal >>> >>> >>> >>> -- >>> Regards, >>> Rajnesh Kumar Siwal >> >> >> >> -- >> Regards, >> Rajnesh Kumar Siwal > > > From rajnesh.siwal at gmail.com Mon Feb 4 15:17:40 2013 From: rajnesh.siwal at gmail.com (Rajnesh Kumar Siwal) Date: Mon, 4 Feb 2013 20:47:40 +0530 Subject: [Freeipa-users] sudo rule working even after the user has been removed from the sudo rule In-Reply-To: <510FC5E4.7090406@redhat.com> References: <510FC5E4.7090406@redhat.com> Message-ID: The details are as follows :- [root at ipa1 ~]# cat /etc/redhat-release CentOS release 6.3 (Final) [root at ipa1 ~]# rpm -qa|grep -i ipa ipa-server-2.2.0-17.el6_3.1.x86_64 libipa_hbac-python-1.8.0-32.el6.x86_64 ipa-pki-ca-theme-9.0.3-7.el6.noarch ipa-python-2.2.0-17.el6_3.1.x86_64 device-mapper-multipath-libs-0.4.9-56.el6_3.1.x86_64 libipa_hbac-1.8.0-32.el6.x86_64 python-iniparse-0.3.1-2.1.el6.noarch ipa-client-2.2.0-17.el6_3.1.x86_64 ipa-server-selinux-2.2.0-17.el6_3.1.x86_64 ipa-pki-common-theme-9.0.3-7.el6.noarch ipa-admintools-2.2.0-17.el6_3.1.x86_64 device-mapper-multipath-0.4.9-56.el6_3.1.x86_64 [root at ipa1 ~]# uname -a Linux ipa1.chargepoint.dmz 2.6.32-279.19.1.el6.x86_64 #1 SMP Wed Dec 19 07:05:20 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux As of now this is a standalone server being run (No replication till now) We have been interacting with the Web Interface only. One thing, the Server is in "Migration Mode" . The users have yet to login into the Migration Page and get their credentials created. [root at ipa1 ~]# ipa config-show Maximum username length: 32 Home directory base: /home Default shell: /bin/bash Default users group: ipausers Default e-mail domain: chargepoint.com Search time limit: 2 Search size limit: 100 User search fields: uid,givenname,sn,telephonenumber,ou,title Group search fields: cn,description Enable migration mode: TRUE Certificate Subject base: O=MYCOMPANY.DMZ Password Expiration Notification (days): 15 Password plugin features: AllowNThash SELinux user map order: guest_u:s0$xguest_u:s0$user_u:s0-s0:c0.c1023$staff_u:s0-s0:c0.c1023$unconfined_u:s0-s0:c0.c1023 Default SELinux user: guest_u:s0 We have migrated the Users/Groups from the OpenLDAP Server (after disabling compat-mode) using schema RFC 2307. I am not yet aable to migrate sudo roles so will be creating them manually. On Mon, Feb 4, 2013 at 7:59 PM, Rob Crittenden wrote: > Rajnesh Kumar Siwal wrote: >> >> I deleted the following entry from the IPA WebUI "All Except Shell" >> (Sudo Role) but ldapsearch still fetches it (Effectively sudo works >> after the deletion of the rule) :- >> >> dn: cn=All Except Shell,ou=sudoers,dc=example,dc=com >> objectClass: sudoRole >> sudoUser: %ctsadmin >> sudoHost: ALL >> sudoCommand: ALL >> sudoRunAsUser: ALL >> sudoOption: !authenticate >> cn: All Except Shell >> >> Is it present in cache somewhere ? > > > I think we need more information on your configuration, distribution, exact > package version(s) and what you've done. > > rob > > >> >> On Mon, Feb 4, 2013 at 2:18 PM, Rajnesh Kumar Siwal >> wrote: >>> >>> Looking into the sssd logs, I came to know there there was one more >>> rule allowing access:- >>> (Mon Feb 4 14:13:01 2013) [sssd[be[chargepoint.dmz]]] >>> [hbac_get_category] (5): Category is set to 'all'. >>> (Mon Feb 4 14:13:01 2013) [sssd[be[chargepoint.dmz]]] >>> [ipa_hbac_evaluate_rules] (3): Access granted by HBAC rule [allow_all] >>> (Mon Feb 4 14:13:01 2013) [sssd[be[chargepoint.dmz]]] >>> [be_pam_handler_callback] (4): Backend returned: (0, 0, ) >>> [Success] >>> >>> I disabled that allow_all rule, now it is fine. >>> >>> On Mon, Feb 4, 2013 at 2:02 PM, Rajnesh Kumar Siwal >>> wrote: >>>> >>>> Here is the outuput of ldapsearch :- >>>> dn: cn=Admins,ou=sudoers,dc=example,dc=com >>>> objectClass: sudoRole >>>> sudoUser: %ctsadmin >>>> sudoHost: ALL >>>> sudoCommand: ALL >>>> sudoRunAsUser: ALL >>>> cn: Admins >>>> >>>> The rule still says that the group ctsadmin is allowed (Which should >>>> not happen after I remove the ctsadmin group from sudo access) >>>> On the IPA Web Interface there is not sudo role attached to the User >>>> "rsiwal" (Neither Direct nor Indirect). >>>> May be there is some bug. >>>> >>>> >>>> On Mon, Feb 4, 2013 at 1:22 PM, Rajnesh Kumar Siwal >>>> wrote: >>>>> >>>>> Hi all, >>>>> >>>>> I have just created a setup for sudo on the IPA Server 2.2. >>>>> I modified nsswitch.conf to use ldap. >>>>> ldap.conf has been modified to fetch sudo users from the IPA Server. >>>>> >>>>> Now, th euser in group "admin" can do sudo. >>>>> 1. rsiwal being a user of group sudo can run all commands as >>>>> sudo (FINE) >>>>> 2. If I disable the rule "Admins" (that I admin group access to >>>>> sudo), the sudo still works for the user rsiwal (Which should not work >>>>> logically). >>>>> 3. Removed the group "Admins" (including rsiwal) from the Sudo >>>>> rule. The rule is still allowing user rsiwal to run "sudo su -". (It >>>>> should Fail) >>>>> >>>>> Is there some kind of caching being at the Server / client end ? >>>>> >>>>> -- >>>>> Regards, >>>>> Rajnesh Kumar Siwal >>>> >>>> >>>> >>>> >>>> -- >>>> Regards, >>>> Rajnesh Kumar Siwal >>> >>> >>> >>> >>> -- >>> Regards, >>> Rajnesh Kumar Siwal >> >> >> >> > -- Regards, Rajnesh Kumar Siwal From rajnesh.siwal at gmail.com Mon Feb 4 15:21:11 2013 From: rajnesh.siwal at gmail.com (Rajnesh Kumar Siwal) Date: Mon, 4 Feb 2013 20:51:11 +0530 Subject: [Freeipa-users] SOLVED: Re: sudo rule working even after the user has been removed from the sudo rule In-Reply-To: <510FC3EC.7090200@redhat.com> References: <510FC3EC.7090200@redhat.com> Message-ID: Not sure but this is what resolved it. On Mon, Feb 4, 2013 at 7:51 PM, Rob Crittenden wrote: > Rajnesh Kumar Siwal wrote: >> >> Looking into the sssd logs, I came to know there there was one more >> rule allowing access:- >> (Mon Feb 4 14:13:01 2013) [sssd[be[chargepoint.dmz]]] >> [hbac_get_category] (5): Category is set to 'all'. >> (Mon Feb 4 14:13:01 2013) [sssd[be[chargepoint.dmz]]] >> [ipa_hbac_evaluate_rules] (3): Access granted by HBAC rule [allow_all] >> (Mon Feb 4 14:13:01 2013) [sssd[be[chargepoint.dmz]]] >> [be_pam_handler_callback] (4): Backend returned: (0, 0, ) >> [Success] >> >> I disabled that allow_all rule, now it is fine. > > > I don't know why that would make any difference. HBAC != sudo. > > rob > > >> >> On Mon, Feb 4, 2013 at 2:02 PM, Rajnesh Kumar Siwal >> wrote: >>> >>> Here is the outuput of ldapsearch :- >>> dn: cn=Admins,ou=sudoers,dc=example,dc=com >>> objectClass: sudoRole >>> sudoUser: %ctsadmin >>> sudoHost: ALL >>> sudoCommand: ALL >>> sudoRunAsUser: ALL >>> cn: Admins >>> >>> The rule still says that the group ctsadmin is allowed (Which should >>> not happen after I remove the ctsadmin group from sudo access) >>> On the IPA Web Interface there is not sudo role attached to the User >>> "rsiwal" (Neither Direct nor Indirect). >>> May be there is some bug. >>> >>> >>> On Mon, Feb 4, 2013 at 1:22 PM, Rajnesh Kumar Siwal >>> wrote: >>>> >>>> Hi all, >>>> >>>> I have just created a setup for sudo on the IPA Server 2.2. >>>> I modified nsswitch.conf to use ldap. >>>> ldap.conf has been modified to fetch sudo users from the IPA Server. >>>> >>>> Now, th euser in group "admin" can do sudo. >>>> 1. rsiwal being a user of group sudo can run all commands as sudo >>>> (FINE) >>>> 2. If I disable the rule "Admins" (that I admin group access to >>>> sudo), the sudo still works for the user rsiwal (Which should not work >>>> logically). >>>> 3. Removed the group "Admins" (including rsiwal) from the Sudo >>>> rule. The rule is still allowing user rsiwal to run "sudo su -". (It >>>> should Fail) >>>> >>>> Is there some kind of caching being at the Server / client end ? >>>> >>>> -- >>>> Regards, >>>> Rajnesh Kumar Siwal >>> >>> >>> >>> >>> -- >>> Regards, >>> Rajnesh Kumar Siwal >> >> >> >> > -- Regards, Rajnesh Kumar Siwal From rajnesh.siwal at gmail.com Mon Feb 4 15:57:20 2013 From: rajnesh.siwal at gmail.com (Rajnesh Kumar Siwal) Date: Mon, 4 Feb 2013 21:27:20 +0530 Subject: [Freeipa-users] RHEL 6.3 identity manual - IPA In-Reply-To: <510FC39B.8030505@redhat.com> References: <510FC39B.8030505@redhat.com> Message-ID: Hi Rob, This is the way I configured it:- 1. Added the details in /etc/ldap.conf :- binddn uid=sudo,cn=sysaccounts,cn=etc,dc=chargepoint,dc=dmz bindpw xxxxxxxxxxxxxxxx ssl start_tls tls_cacertfile /etc/ipa/ca.crt tls_checkpeer yes bind_timelimit 5 timelimit 15 uri ldap://ipa1.chargepoint.dmz sudoers_base ou=SUDOers,dc=chargepoint,dc=dmz sudoers_debug 1 2. Modified /etc/nsswitch.conf to fetch sudo details from ldap:- sudoers: files ldap 3. So what I can understand from the above steps is that I am interacting directly with the LDAP (389-ds) Server directly (because I am not using sss (instead ldap is being used)). On Mon, Feb 4, 2013 at 7:50 PM, Rob Crittenden wrote: > Fred van Zwieten wrote: >> >> Hi, >> >> ipa-client-install should take care of setting up sudo on the client to >> use IPA, afaik. >> > > Not yet, https://fedorahosted.org/freeipa/ticket/3358 > >> Essential line in nsswitch.conf: >> sudoers: files ldap >> >> Please read here >> >> > > > Note that the configuration file name is wrong for RHEL 6. You need to use > /etc/sudo-ldap.conf. > > rob > >> >> As for the second question. dc=example,dc=com is, well, an example. >> example.com is used throughout the documentation >> >> for documentation purposes where a domain name is needed. Please replace >> is with you're domain, e.g. dc=yourcompanyname,dc=com >> >> Met vriendelijke groeten, >> * >> Fred* >> >> >> >> On Mon, Feb 4, 2013 at 7:29 AM, Rajnesh Kumar Siwal >> > wrote: >> >> I am planning to use the sudo feature on IPA 2.2. By default the IPA >> client that I configured does not seems to use fetch the sudo user >> details. >> >> It looks that we need to modify nsswitch.conf and ldap.conf to >> support it. >> >> Can sssd take care of fetching the sudo user details ? >> >> Secondly, I am not able to find the password for >> uid=sudo,cn=sysaccounts,cn=etc,dc=example,dc=com . How do I find it ? >> Will it be safe to change password of this sudo user or it may impact >> the IPA Server ? >> >> Please suggest. >> >> >> -- >> Regards, >> Rajnesh Kumar Siwal >> >> _______________________________________________ >> 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 >> > -- Regards, Rajnesh Kumar Siwal From rcritten at redhat.com Mon Feb 4 15:58:31 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 04 Feb 2013 10:58:31 -0500 Subject: [Freeipa-users] Roadmap Message-ID: <510FDAA7.4010502@redhat.com> In order to keep you informed of the current and future plans for FreeIPA we've updated our Roadmap with some more details: http://www.freeipa.org/page/Roadmap rob From rcritten at redhat.com Mon Feb 4 16:07:38 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 04 Feb 2013 11:07:38 -0500 Subject: [Freeipa-users] RHEL 6.3 identity manual - IPA In-Reply-To: References: <510FC39B.8030505@redhat.com> Message-ID: <510FDCCA.5070303@redhat.com> Rajnesh Kumar Siwal wrote: > Hi Rob, > > This is the way I configured it:- > 1. Added the details in /etc/ldap.conf :- > binddn uid=sudo,cn=sysaccounts,cn=etc,dc=chargepoint,dc=dmz > bindpw xxxxxxxxxxxxxxxx > > ssl start_tls > tls_cacertfile /etc/ipa/ca.crt > tls_checkpeer yes > > bind_timelimit 5 > timelimit 15 > > uri ldap://ipa1.chargepoint.dmz > sudoers_base ou=SUDOers,dc=chargepoint,dc=dmz > sudoers_debug 1 > > 2. Modified /etc/nsswitch.conf to fetch sudo details from ldap:- > sudoers: files ldap > > 3. So what I can understand from the above steps is that I am > interacting directly with the LDAP (389-ds) Server directly (because I > am not using sss (instead ldap is being used)). What distribution and release number is the client? Can you include what you see when you execute a sudo? rob > > > On Mon, Feb 4, 2013 at 7:50 PM, Rob Crittenden wrote: >> Fred van Zwieten wrote: >>> >>> Hi, >>> >>> ipa-client-install should take care of setting up sudo on the client to >>> use IPA, afaik. >>> >> >> Not yet, https://fedorahosted.org/freeipa/ticket/3358 >> >>> Essential line in nsswitch.conf: >>> sudoers: files ldap >>> >>> Please read here >>> >>> >> >> >> Note that the configuration file name is wrong for RHEL 6. You need to use >> /etc/sudo-ldap.conf. >> >> rob >> >>> >>> As for the second question. dc=example,dc=com is, well, an example. >>> example.com is used throughout the documentation >>> >>> for documentation purposes where a domain name is needed. Please replace >>> is with you're domain, e.g. dc=yourcompanyname,dc=com >>> >>> Met vriendelijke groeten, >>> * >>> Fred* >>> >>> >>> >>> On Mon, Feb 4, 2013 at 7:29 AM, Rajnesh Kumar Siwal >>> > wrote: >>> >>> I am planning to use the sudo feature on IPA 2.2. By default the IPA >>> client that I configured does not seems to use fetch the sudo user >>> details. >>> >>> It looks that we need to modify nsswitch.conf and ldap.conf to >>> support it. >>> >>> Can sssd take care of fetching the sudo user details ? >>> >>> Secondly, I am not able to find the password for >>> uid=sudo,cn=sysaccounts,cn=etc,dc=example,dc=com . How do I find it ? >>> Will it be safe to change password of this sudo user or it may impact >>> the IPA Server ? >>> >>> Please suggest. >>> >>> >>> -- >>> Regards, >>> Rajnesh Kumar Siwal >>> >>> _______________________________________________ >>> 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 rajnesh.siwal at gmail.com Mon Feb 4 16:10:02 2013 From: rajnesh.siwal at gmail.com (Rajnesh Kumar Siwal) Date: Mon, 4 Feb 2013 21:40:02 +0530 Subject: [Freeipa-users] RHEL 6.3 identity manual - IPA In-Reply-To: <510FDCCA.5070303@redhat.com> References: <510FC39B.8030505@redhat.com> <510FDCCA.5070303@redhat.com> Message-ID: IPA client details are :- [rsiwal at gw1-test ~]$ rpm -qa|grep -i -w ipa ipa-client-2.1.3-5.el5_9.2 [rsiwal at gw1-test ~]$ cat /etc/redhat-release CentOS release 5.6 (Final) [rsiwal at gw1-test ~]$ uname -a Linux gw1-test 2.6.18-238.el5 #1 SMP Thu Jan 13 15:51:15 EST 2011 x86_64 x86_64 x86_64 GNU/Linux On Mon, Feb 4, 2013 at 9:37 PM, Rob Crittenden wrote: > Rajnesh Kumar Siwal wrote: >> >> Hi Rob, >> >> This is the way I configured it:- >> 1. Added the details in /etc/ldap.conf :- >> binddn uid=sudo,cn=sysaccounts,cn=etc,dc=chargepoint,dc=dmz >> bindpw xxxxxxxxxxxxxxxx >> >> ssl start_tls >> tls_cacertfile /etc/ipa/ca.crt >> tls_checkpeer yes >> >> bind_timelimit 5 >> timelimit 15 >> >> uri ldap://ipa1.chargepoint.dmz >> sudoers_base ou=SUDOers,dc=chargepoint,dc=dmz >> sudoers_debug 1 >> >> 2. Modified /etc/nsswitch.conf to fetch sudo details from ldap:- >> sudoers: files ldap >> >> 3. So what I can understand from the above steps is that I am >> interacting directly with the LDAP (389-ds) Server directly (because I >> am not using sss (instead ldap is being used)). > > > What distribution and release number is the client? > > Can you include what you see when you execute a sudo? > > rob > > >> >> >> On Mon, Feb 4, 2013 at 7:50 PM, Rob Crittenden >> wrote: >>> >>> Fred van Zwieten wrote: >>>> >>>> >>>> Hi, >>>> >>>> ipa-client-install should take care of setting up sudo on the client to >>>> use IPA, afaik. >>>> >>> >>> Not yet, https://fedorahosted.org/freeipa/ticket/3358 >>> >>>> Essential line in nsswitch.conf: >>>> sudoers: files ldap >>>> >>>> Please read here >>>> >>>> >>>> >>> >>> >>> >>> Note that the configuration file name is wrong for RHEL 6. You need to >>> use >>> /etc/sudo-ldap.conf. >>> >>> rob >>> >>>> >>>> As for the second question. dc=example,dc=com is, well, an example. >>>> example.com is used throughout the documentation >>>> >>>> for documentation purposes where a domain name is needed. Please replace >>>> is with you're domain, e.g. dc=yourcompanyname,dc=com >>>> >>>> Met vriendelijke groeten, >>>> * >>>> Fred* >>>> >>>> >>>> >>>> On Mon, Feb 4, 2013 at 7:29 AM, Rajnesh Kumar Siwal >>>> > wrote: >>>> >>>> I am planning to use the sudo feature on IPA 2.2. By default the >>>> IPA >>>> client that I configured does not seems to use fetch the sudo user >>>> details. >>>> >>>> It looks that we need to modify nsswitch.conf and ldap.conf to >>>> support it. >>>> >>>> Can sssd take care of fetching the sudo user details ? >>>> >>>> Secondly, I am not able to find the password for >>>> uid=sudo,cn=sysaccounts,cn=etc,dc=example,dc=com . How do I find it >>>> ? >>>> Will it be safe to change password of this sudo user or it may >>>> impact >>>> the IPA Server ? >>>> >>>> Please suggest. >>>> >>>> >>>> -- >>>> Regards, >>>> Rajnesh Kumar Siwal >>>> >>>> _______________________________________________ >>>> 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 >>>> >>> >> >> >> > -- Regards, Rajnesh Kumar Siwal From christianh at 4over.com Mon Feb 4 16:46:27 2013 From: christianh at 4over.com (Christian Hernandez) Date: Mon, 4 Feb 2013 08:46:27 -0800 Subject: [Freeipa-users] Backup and Restoration of IPA Server In-Reply-To: References: Message-ID: Looks like a "backup/restore" procedure is in the roadmap http://www.freeipa.org/page/Roadmap Thank you, Christian Hernandez 1225 Los Angeles Street Glendale, CA 91204 Phone: 877-782-2737 ext. 4566 Fax: 818-265-3152 christianh at 4over.com www.4over.com On Mon, Feb 4, 2013 at 2:54 AM, Rajnesh Kumar Siwal wrote: > Does it means that we don't have any backup / restoration process as > of now for IPA 2.2 ? > I am really concerned about such a critical application. > > It would be greate if you could please specify the set of manual > commands in case they can be used for Backup / Restoration purpose. > > -- > Regards, > Rajnesh Kumar Siwal > > _______________________________________________ > 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 rajnesh.siwal at gmail.com Mon Feb 4 16:51:17 2013 From: rajnesh.siwal at gmail.com (Rajnesh Kumar Siwal) Date: Mon, 4 Feb 2013 22:21:17 +0530 Subject: [Freeipa-users] Backup and Restoration of IPA Server In-Reply-To: References: Message-ID: Thanks Christian. I am still looking for some workaround till then. On Mon, Feb 4, 2013 at 10:16 PM, Christian Hernandez wrote: > Looks like a "backup/restore" procedure is in the roadmap > > http://www.freeipa.org/page/Roadmap > > > Thank you, > > Christian Hernandez > 1225 Los Angeles Street > Glendale, CA 91204 > Phone: 877-782-2737 ext. 4566 > Fax: 818-265-3152 > christianh at 4over.com > www.4over.com > > > On Mon, Feb 4, 2013 at 2:54 AM, Rajnesh Kumar Siwal > wrote: >> >> Does it means that we don't have any backup / restoration process as >> of now for IPA 2.2 ? >> I am really concerned about such a critical application. >> >> It would be greate if you could please specify the set of manual >> commands in case they can be used for Backup / Restoration purpose. >> >> -- >> Regards, >> Rajnesh Kumar Siwal >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > -- Regards, Rajnesh Kumar Siwal From rcritten at redhat.com Mon Feb 4 19:17:39 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 04 Feb 2013 14:17:39 -0500 Subject: [Freeipa-users] sudo rule working even after the user has been removed from the sudo rule In-Reply-To: References: <510FC5E4.7090406@redhat.com> Message-ID: <51100953.9080902@redhat.com> Rajnesh Kumar Siwal wrote: > The details are as follows :- > [root at ipa1 ~]# cat /etc/redhat-release > CentOS release 6.3 (Final) > > [root at ipa1 ~]# rpm -qa|grep -i ipa > ipa-server-2.2.0-17.el6_3.1.x86_64 > libipa_hbac-python-1.8.0-32.el6.x86_64 > ipa-pki-ca-theme-9.0.3-7.el6.noarch > ipa-python-2.2.0-17.el6_3.1.x86_64 > device-mapper-multipath-libs-0.4.9-56.el6_3.1.x86_64 > libipa_hbac-1.8.0-32.el6.x86_64 > python-iniparse-0.3.1-2.1.el6.noarch > ipa-client-2.2.0-17.el6_3.1.x86_64 > ipa-server-selinux-2.2.0-17.el6_3.1.x86_64 > ipa-pki-common-theme-9.0.3-7.el6.noarch > ipa-admintools-2.2.0-17.el6_3.1.x86_64 > device-mapper-multipath-0.4.9-56.el6_3.1.x86_64 > > [root at ipa1 ~]# uname -a > Linux ipa1.chargepoint.dmz 2.6.32-279.19.1.el6.x86_64 #1 SMP Wed Dec > 19 07:05:20 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux > > As of now this is a standalone server being run (No replication till now) > We have been interacting with the Web Interface only. The ou=sudoers entry in LDAP is a virtual entry managed by the compat plugin. It should detect deletes and remove them from its view. If you restart the dirsrv service does the entry go away? > > One thing, the Server is in "Migration Mode" . > The users have yet to login into the Migration Page and get their > credentials created. Migration mode has no impact on sudo. > I am not yet aable to migrate sudo roles so will be creating them manually. There currently no way to import existing sudo rules. rob > > > On Mon, Feb 4, 2013 at 7:59 PM, Rob Crittenden wrote: >> Rajnesh Kumar Siwal wrote: >>> >>> I deleted the following entry from the IPA WebUI "All Except Shell" >>> (Sudo Role) but ldapsearch still fetches it (Effectively sudo works >>> after the deletion of the rule) :- >>> >>> dn: cn=All Except Shell,ou=sudoers,dc=example,dc=com >>> objectClass: sudoRole >>> sudoUser: %ctsadmin >>> sudoHost: ALL >>> sudoCommand: ALL >>> sudoRunAsUser: ALL >>> sudoOption: !authenticate >>> cn: All Except Shell >>> >>> Is it present in cache somewhere ? >> >> >> I think we need more information on your configuration, distribution, exact >> package version(s) and what you've done. >> >> rob >> >> >>> >>> On Mon, Feb 4, 2013 at 2:18 PM, Rajnesh Kumar Siwal >>> wrote: >>>> >>>> Looking into the sssd logs, I came to know there there was one more >>>> rule allowing access:- >>>> (Mon Feb 4 14:13:01 2013) [sssd[be[chargepoint.dmz]]] >>>> [hbac_get_category] (5): Category is set to 'all'. >>>> (Mon Feb 4 14:13:01 2013) [sssd[be[chargepoint.dmz]]] >>>> [ipa_hbac_evaluate_rules] (3): Access granted by HBAC rule [allow_all] >>>> (Mon Feb 4 14:13:01 2013) [sssd[be[chargepoint.dmz]]] >>>> [be_pam_handler_callback] (4): Backend returned: (0, 0, ) >>>> [Success] >>>> >>>> I disabled that allow_all rule, now it is fine. >>>> >>>> On Mon, Feb 4, 2013 at 2:02 PM, Rajnesh Kumar Siwal >>>> wrote: >>>>> >>>>> Here is the outuput of ldapsearch :- >>>>> dn: cn=Admins,ou=sudoers,dc=example,dc=com >>>>> objectClass: sudoRole >>>>> sudoUser: %ctsadmin >>>>> sudoHost: ALL >>>>> sudoCommand: ALL >>>>> sudoRunAsUser: ALL >>>>> cn: Admins >>>>> >>>>> The rule still says that the group ctsadmin is allowed (Which should >>>>> not happen after I remove the ctsadmin group from sudo access) >>>>> On the IPA Web Interface there is not sudo role attached to the User >>>>> "rsiwal" (Neither Direct nor Indirect). >>>>> May be there is some bug. >>>>> >>>>> >>>>> On Mon, Feb 4, 2013 at 1:22 PM, Rajnesh Kumar Siwal >>>>> wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> I have just created a setup for sudo on the IPA Server 2.2. >>>>>> I modified nsswitch.conf to use ldap. >>>>>> ldap.conf has been modified to fetch sudo users from the IPA Server. >>>>>> >>>>>> Now, th euser in group "admin" can do sudo. >>>>>> 1. rsiwal being a user of group sudo can run all commands as >>>>>> sudo (FINE) >>>>>> 2. If I disable the rule "Admins" (that I admin group access to >>>>>> sudo), the sudo still works for the user rsiwal (Which should not work >>>>>> logically). >>>>>> 3. Removed the group "Admins" (including rsiwal) from the Sudo >>>>>> rule. The rule is still allowing user rsiwal to run "sudo su -". (It >>>>>> should Fail) >>>>>> >>>>>> Is there some kind of caching being at the Server / client end ? >>>>>> >>>>>> -- >>>>>> Regards, >>>>>> Rajnesh Kumar Siwal >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Regards, >>>>> Rajnesh Kumar Siwal >>>> >>>> >>>> >>>> >>>> -- >>>> Regards, >>>> Rajnesh Kumar Siwal >>> >>> >>> >>> >> > > > From loris at lgs.com.ve Mon Feb 4 19:23:20 2013 From: loris at lgs.com.ve (Loris Santamaria) Date: Mon, 04 Feb 2013 14:53:20 -0430 Subject: [Freeipa-users] Replication flood caused by ipa_lockout plugin Message-ID: <1360005800.10939.37.camel@toron.pzo.lgs.com.ve> Hi on a production IPA realm with 3 servers and about 2000 users we were experimenting a very high load on the servers. Further investigation showed that the high load was caused by a lot of writes done by the IPA dirsrv instance. Activating the audit logging showed a lot of MOD operation to the directory, like these: time: 20130204140217 dn: uid=XXXX,cn=users,cn=accounts,dc=XXX,dc=XXX,dc=XX changetype: modify replace: modifiersName modifiersName: cn=IPA Lockout,cn=plugins,cn=config - replace: modifyTimestamp modifyTimestamp: 20130204183216Z - replace: entryusn entryusn: 3472506 - time: 20130204140217 dn: uid=XXXX,cn=users,cn=accounts,dc=XXX,dc=XXX,dc=XX changetype: modify replace: modifiersName modifiersName: cn=IPA Lockout,cn=plugins,cn=config - replace: modifyTimestamp modifyTimestamp: 20130204183217Z - replace: entryusn entryusn: 3472507 There is an HTTP proxy server which connects to IPA to perform user authorization and it seems that it does a BIND on behalf of the user for every page the user visits... and for every successful BIND the IPA Lockout plugin does the MODs indicated above. It is to note that currently we are not locking accounts on failed authentication to the directory, so the above MODs seem completely unnecessary. For the time being we disabled the ipa lockout plugin, but we would like to know if the behavior highlighted above is expected or if we should file a bug. Thanks -- Loris Santamaria linux user #70506 xmpp:loris at lgs.com.ve Links Global Services, C.A. http://www.lgs.com.ve Tel: 0286 952.06.87 Cel: 0414 095.00.10 sip:103 at lgs.com.ve ------------------------------------------------------------ "If I'd asked my customers what they wanted, they'd have said a faster horse" - Henry Ford -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6173 bytes Desc: not available URL: From rcritten at redhat.com Mon Feb 4 19:45:16 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 04 Feb 2013 14:45:16 -0500 Subject: [Freeipa-users] Replication flood caused by ipa_lockout plugin In-Reply-To: <1360005800.10939.37.camel@toron.pzo.lgs.com.ve> References: <1360005800.10939.37.camel@toron.pzo.lgs.com.ve> Message-ID: <51100FCC.4040508@redhat.com> Loris Santamaria wrote: > Hi > > on a production IPA realm with 3 servers and about 2000 users we were > experimenting a very high load on the servers. Further investigation > showed that the high load was caused by a lot of writes done by the IPA > dirsrv instance. Activating the audit logging showed a lot of MOD > operation to the directory, like these: > > time: 20130204140217 > dn: uid=XXXX,cn=users,cn=accounts,dc=XXX,dc=XXX,dc=XX > changetype: modify > replace: modifiersName > modifiersName: cn=IPA Lockout,cn=plugins,cn=config > - > replace: modifyTimestamp > modifyTimestamp: 20130204183216Z > - > replace: entryusn > entryusn: 3472506 > - > > time: 20130204140217 > dn: uid=XXXX,cn=users,cn=accounts,dc=XXX,dc=XXX,dc=XX > changetype: modify > replace: modifiersName > modifiersName: cn=IPA Lockout,cn=plugins,cn=config > - > replace: modifyTimestamp > modifyTimestamp: 20130204183217Z > - > replace: entryusn > entryusn: 3472507 > > There is an HTTP proxy server which connects to IPA to perform user > authorization and it seems that it does a BIND on behalf of the user for > every page the user visits... and for every successful BIND the IPA > Lockout plugin does the MODs indicated above. > > It is to note that currently we are not locking accounts on failed > authentication to the directory, so the above MODs seem completely > unnecessary. > > For the time being we disabled the ipa lockout plugin, but we would like > to know if the behavior highlighted above is expected or if we should > file a bug. Fixed in 389-ds-base 1.2.11. See bug https://bugzilla.redhat.com/show_bug.cgi?id=782975 The commit is: https://lists.fedoraproject.org/pipermail/389-commits/2012-May/005209.html rob From sakodak at gmail.com Mon Feb 4 21:01:09 2013 From: sakodak at gmail.com (KodaK) Date: Mon, 4 Feb 2013 15:01:09 -0600 Subject: [Freeipa-users] Backup and Restoration of IPA Server In-Reply-To: References: Message-ID: I use the following to dump my LDAP databases: #!/bin/sh /usr/lib64/dirsrv/slapd-PKI-IPA/db2ldif.pl -D "cn=directory manager" -j /var/lib/dirsrv/scripts-YOUR-KERB-REALM/dmanager.credentials -n ipaca -a /var/lib/dirsrv/slapd-PKI-IPA/bak/ipaca.`/bin/date +%Y%m%d%H%M%S`.ldif /var/lib/dirsrv/scripts-YOUR-KERB-REALM/db2ldif.pl -D "cn=directory manager" -j /var/lib/dirsrv/scripts-YOUR-KERB-REALM/dmanager.credentials -n userroot -a /var/lib/dirsrv/slapd-YOUR-KERB-REALM/bak/userroot.`/bin/date +%Y%m%d%H%M%S`.ldif I have that in a script that's run by cron, followed up by a script to delete old backups. Netbackup takes care of backing up the systems. dmanager.credentials just has the Directory Manager password in it in plain test. Not optimal, but it works. --Jason On Mon, Feb 4, 2013 at 10:51 AM, Rajnesh Kumar Siwal wrote: > Thanks Christian. > I am still looking for some workaround till then. > > On Mon, Feb 4, 2013 at 10:16 PM, Christian Hernandez > wrote: >> Looks like a "backup/restore" procedure is in the roadmap >> >> http://www.freeipa.org/page/Roadmap >> >> >> Thank you, >> >> Christian Hernandez >> 1225 Los Angeles Street >> Glendale, CA 91204 >> Phone: 877-782-2737 ext. 4566 >> Fax: 818-265-3152 >> christianh at 4over.com >> www.4over.com >> >> >> On Mon, Feb 4, 2013 at 2:54 AM, Rajnesh Kumar Siwal >> wrote: >>> >>> Does it means that we don't have any backup / restoration process as >>> of now for IPA 2.2 ? >>> I am really concerned about such a critical application. >>> >>> It would be greate if you could please specify the set of manual >>> commands in case they can be used for Backup / Restoration purpose. >>> >>> -- >>> Regards, >>> Rajnesh Kumar Siwal >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> > > > > -- > Regards, > Rajnesh Kumar Siwal > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- The government is going to read our mail anyway, might as well make it tough for them. GPG Public key ID: B6A1A7C6 From it.meme01 at gmail.com Tue Feb 5 00:07:50 2013 From: it.meme01 at gmail.com (It Meme) Date: Mon, 4 Feb 2013 16:07:50 -0800 Subject: [Freeipa-users] IPA Create User In-Reply-To: <510C9D4A.5080100@redhat.com> References: <510C6104.4050208@redhat.com> <510C9D4A.5080100@redhat.com> Message-ID: Thank you John for your helpful reply. Near real time will be sufficient - within the 5 min range. Will it be practical when managing a user's groups - these can happen when a user moves within the organization or is terminated. On Fri, Feb 1, 2013 at 8:59 PM, John Dennis wrote: > On 02/01/2013 10:26 PM, It Meme wrote: > >> Hi Dimitri: >> >> Thank you for your helpful posts. >> >> Do you know of any organization that provisions accounts and groups in >> real-time, from an external IdM system, to IPA, via CLI? >> >> We have an IdM system which will be reading data from HR, and making >> 'joiner, mover, leaver, decisions' - accounts are provisioned, deleted, >> groups changed etc based on the HR data. >> >> Is it feasible to consider the IdM system calling the CLI, via scripts, >> to create/delete accounts, manage groups, in near real-time? >> > > Calling a script does not take much time (especially compared to the > elapsed time it takes for the command to complete), it would only be an > issue if you were trying to do a number of transactions per second, but it > doesn't sound like your HR dept is going to need that kind of throughput. > It's also possible to call our API from Python, others have done this. > Whether your IdM forks out to a shell script or to a Python script would be > negligible compared to the total elapsed time to complete the operation. > > I suppose the answer to your question begs another, what's your definition > of "real time"? If your IdM triggers a transaction and it completes within > a few seconds is that real time? > > John > > -- > John Dennis > > > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdennis at redhat.com Tue Feb 5 00:35:42 2013 From: jdennis at redhat.com (John Dennis) Date: Mon, 04 Feb 2013 19:35:42 -0500 Subject: [Freeipa-users] IPA Create User In-Reply-To: References: <510C6104.4050208@redhat.com> <510C9D4A.5080100@redhat.com> Message-ID: <511053DE.1080202@redhat.com> On 02/04/2013 07:07 PM, It Meme wrote: > Thank you John for your helpful reply. > > Near real time will be sufficient - within the 5 min range. > > Will it be practical when managing a user's groups - these can happen > when a user moves within the organization or is terminated. I'm not sure we've done timing measurements on various operations, but in general most IPA commands are fast executing in sub-second elapsed time on the server. Latency on the client side can be introduced by such things as authentication (mitigated by the use of client sessions), network latencies between the client and the server, DNS resolution, etc. Those types of network induced latencies can be very hard to predict because it depends on a number of external factors having nothing to do with IPA per se. Elapsed time on the server is also influenced by LDAP tuning (e.g. indexes), memory, available CPU, etc. Things like adding a user, or adding a user to a group are not compute intensive and should execute quickly. For your intended use I don't see any issues with the elapsed time for command execution. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From it.meme01 at gmail.com Tue Feb 5 05:05:30 2013 From: it.meme01 at gmail.com (It Meme) Date: Mon, 4 Feb 2013 21:05:30 -0800 Subject: [Freeipa-users] IPA Create User In-Reply-To: <511053DE.1080202@redhat.com> References: <510C6104.4050208@redhat.com> <510C9D4A.5080100@redhat.com> <511053DE.1080202@redhat.com> Message-ID: <75A0B4F9-7319-40DB-B0C9-121ED06FC0A3@gmail.com> Thank you John - much appreciated. Sent from my iPhone On 2013-02-04, at 16:35, John Dennis wrote: > On 02/04/2013 07:07 PM, It Meme wrote: >> Thank you John for your helpful reply. >> >> Near real time will be sufficient - within the 5 min range. >> >> Will it be practical when managing a user's groups - these can happen >> when a user moves within the organization or is terminated. > > I'm not sure we've done timing measurements on various operations, but in general most IPA commands are fast executing in sub-second elapsed time on the server. Latency on the client side can be introduced by such things as authentication (mitigated by the use of client sessions), network latencies between the client and the server, DNS resolution, etc. Those types of network induced latencies can be very hard to predict because it depends on a number of external factors having nothing to do with IPA per se. Elapsed time on the server is also influenced by LDAP tuning (e.g. indexes), memory, available CPU, etc. > > Things like adding a user, or adding a user to a group are not compute intensive and should execute quickly. For your intended use I don't see any issues with the elapsed time for command execution. > > -- > John Dennis > > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ From it.meme01 at gmail.com Tue Feb 5 05:08:02 2013 From: it.meme01 at gmail.com (It Meme) Date: Mon, 4 Feb 2013 21:08:02 -0800 Subject: [Freeipa-users] Java JSON Example -> IPA API Message-ID: Hi. Would be any online examples for calling the IPA JSON APIs from a java application? Thanks. Sent from my iPhone From rajnesh.siwal at gmail.com Tue Feb 5 13:18:50 2013 From: rajnesh.siwal at gmail.com (Rajnesh Kumar Siwal) Date: Tue, 5 Feb 2013 18:48:50 +0530 Subject: [Freeipa-users] ipa replica install fails Message-ID: We are trying to setup the IPA replication but it says "Connection check failed!". We disabled the firewall and found the same result. ----------------------------------------------------------------------------------------------------------------------- [root at ipa2 /]# ipa-replica-install -d --setup-ca --setup-dns --forwarder 64.71.0.60 /var/lib/ipa/replica-info-ipa2.xyz.dmz.gpg ipa : DEBUG /usr/sbin/ipa-replica-install was invoked with argument "/var/lib/ipa/replica-info-ipa2.xyz.dmz.gpg" and options: {'no_forwarders': False, 'conf_ssh': False, 'conf_sshd': False, 'ui_redirect': True, 'reverse_zone': None, 'trust_sshfp': False, 'unattended': False, 'no_host_dns': False, 'ip_address': None, 'no_reverse': False, 'setup_dns': True, 'create_sshfp': True, 'setup_ca': True, 'forwarders': [CheckedIPAddress('64.71.0.60')], 'debug': True, 'conf_ntp': True, 'skip_conncheck': False} ipa : DEBUG Loading Index file from '/var/lib/ipa-client/sysrestore/sysrestore.index' ipa : DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' ipa : DEBUG Loading Index file from '/var/lib/ipa/sysrestore/sysrestore.index' Directory Manager (existing master) password: ipa : DEBUG args=/usr/bin/gpg --batch --homedir /tmp/tmpRGaqDpipa/ipa-A3XOq7/.gnupg --passphrase-fd 0 --yes --no-tty -o /tmp/tmpRGaqDpipa/files.tar -d /var/lib/ipa/replica-info-ipa2.xyz.dmz.gpg ipa : DEBUG stdout= ipa : DEBUG stderr=gpg: WARNING: unsafe permissions on homedir `/tmp/tmpRGaqDpipa/ipa-A3XOq7/.gnupg' gpg: keyring `/tmp/tmpRGaqDpipa/ipa-A3XOq7/.gnupg/secring.gpg' created gpg: keyring `/tmp/tmpRGaqDpipa/ipa-A3XOq7/.gnupg/pubring.gpg' created gpg: 3DES encrypted data gpg: encrypted with 1 passphrase gpg: WARNING: message was not integrity protected ipa : DEBUG args=tar xf /tmp/tmpRGaqDpipa/files.tar -C /tmp/tmpRGaqDpipa ipa : DEBUG stdout= ipa : DEBUG stderr= Run connection check to master Check connection from replica to remote master 'ipa1.xyz.dmz': 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 PKI-CA: Directory Service port (7389): 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 XYZ.DMZ password: Execute check on remote master admin at ipa1.xyz.dmz's password: Remote master check failed with following error message(s): ipa : DEBUG args=/usr/sbin/ipa-replica-conncheck --master ipa1.xyz.dmz --auto-master-check --realm XYZ.DMZ --principal admin --hostname ipa2.xyz.dmz --check-ca 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. -------------------------------------------------------------------------------------------------------------------------------------------------------------- Please suggest From rcritten at redhat.com Tue Feb 5 14:05:03 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 05 Feb 2013 09:05:03 -0500 Subject: [Freeipa-users] ipa replica install fails In-Reply-To: References: Message-ID: <5111118F.8010606@redhat.com> Rajnesh Kumar Siwal wrote: > We are trying to setup the IPA replication but it says "Connection > check failed!". > We disabled the firewall and found the same result. > > ----------------------------------------------------------------------------------------------------------------------- > [root at ipa2 /]# ipa-replica-install -d --setup-ca --setup-dns > --forwarder 64.71.0.60 /var/lib/ipa/replica-info-ipa2.xyz.dmz.gpg > ipa : DEBUG /usr/sbin/ipa-replica-install was invoked with > argument "/var/lib/ipa/replica-info-ipa2.xyz.dmz.gpg" and options: > {'no_forwarders': False, 'conf_ssh': False, 'conf_sshd': False, > 'ui_redirect': True, 'reverse_zone': None, 'trust_sshfp': False, > 'unattended': False, 'no_host_dns': False, 'ip_address': None, > 'no_reverse': False, 'setup_dns': True, 'create_sshfp': True, > 'setup_ca': True, 'forwarders': [CheckedIPAddress('64.71.0.60')], > 'debug': True, 'conf_ntp': True, 'skip_conncheck': False} > ipa : DEBUG Loading Index file from > '/var/lib/ipa-client/sysrestore/sysrestore.index' > ipa : DEBUG Loading StateFile from > '/var/lib/ipa/sysrestore/sysrestore.state' > ipa : DEBUG Loading Index file from > '/var/lib/ipa/sysrestore/sysrestore.index' > Directory Manager (existing master) password: > > ipa : DEBUG args=/usr/bin/gpg --batch --homedir > /tmp/tmpRGaqDpipa/ipa-A3XOq7/.gnupg --passphrase-fd 0 --yes --no-tty > -o /tmp/tmpRGaqDpipa/files.tar -d > /var/lib/ipa/replica-info-ipa2.xyz.dmz.gpg > ipa : DEBUG stdout= > ipa : DEBUG stderr=gpg: WARNING: unsafe permissions on > homedir `/tmp/tmpRGaqDpipa/ipa-A3XOq7/.gnupg' > gpg: keyring `/tmp/tmpRGaqDpipa/ipa-A3XOq7/.gnupg/secring.gpg' created > gpg: keyring `/tmp/tmpRGaqDpipa/ipa-A3XOq7/.gnupg/pubring.gpg' created > gpg: 3DES encrypted data > gpg: encrypted with 1 passphrase > gpg: WARNING: message was not integrity protected > > ipa : DEBUG args=tar xf /tmp/tmpRGaqDpipa/files.tar -C > /tmp/tmpRGaqDpipa > ipa : DEBUG stdout= > ipa : DEBUG stderr= > Run connection check to master > Check connection from replica to remote master 'ipa1.xyz.dmz': > 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 > PKI-CA: Directory Service port (7389): 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 XYZ.DMZ password: > > Execute check on remote master > admin at ipa1.xyz.dmz's password: > > Remote master check failed with following error message(s): > > ipa : DEBUG args=/usr/sbin/ipa-replica-conncheck --master > ipa1.xyz.dmz --auto-master-check --realm XYZ.DMZ --principal admin > --hostname ipa2.xyz.dmz --check-ca > 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. > -------------------------------------------------------------------------------------------------------------------------------------------------------------- > Please suggest Each server has its own iptables configuration. The test from the replica to the master succeeded. What failed is the connection test from the master to the replica, so I'd look at the iptables configuration on the replica machine. If that turns out ok it could be a false positive. You can add the --skip-conncheck to the ipa-replica-install command to skip this test. rob From rajnesh.siwal at gmail.com Tue Feb 5 14:15:27 2013 From: rajnesh.siwal at gmail.com (Rajnesh Kumar Siwal) Date: Tue, 5 Feb 2013 19:45:27 +0530 Subject: [Freeipa-users] ipa replica install fails In-Reply-To: <5111118F.8010606@redhat.com> References: <5111118F.8010606@redhat.com> Message-ID: Hi Rob, Thanks for the quick reply. I tried logging iptables in the replica also, but no log for dropped packet :- I would appreciate if you could please let me know what these login actually do. 1. Looks to me as getting tgt for admin 2. Is it trying to login though ssh to ipa1 server ? ---------------------------------------------------------------------- Get credentials to log in to remote master admin at XYZ.DMZ password: Execute check on remote master admin at ipa1.xyz.dmz's password: ---------------------------------------------------------------------- SELINUX is disabled at both the ends. Is there any other log file that may suggest something. It would be great if we could figure out whats the cause of the error. ----------------------------------------------------------------------------------------------------------------------- On Tue, Feb 5, 2013 at 7:35 PM, Rob Crittenden wrote: > Rajnesh Kumar Siwal wrote: >> >> We are trying to setup the IPA replication but it says "Connection >> check failed!". >> We disabled the firewall and found the same result. >> >> >> ----------------------------------------------------------------------------------------------------------------------- >> [root at ipa2 /]# ipa-replica-install -d --setup-ca --setup-dns >> --forwarder 64.71.0.60 /var/lib/ipa/replica-info-ipa2.xyz.dmz.gpg >> ipa : DEBUG /usr/sbin/ipa-replica-install was invoked with >> argument "/var/lib/ipa/replica-info-ipa2.xyz.dmz.gpg" and options: >> {'no_forwarders': False, 'conf_ssh': False, 'conf_sshd': False, >> 'ui_redirect': True, 'reverse_zone': None, 'trust_sshfp': False, >> 'unattended': False, 'no_host_dns': False, 'ip_address': None, >> 'no_reverse': False, 'setup_dns': True, 'create_sshfp': True, >> 'setup_ca': True, 'forwarders': [CheckedIPAddress('64.71.0.60')], >> 'debug': True, 'conf_ntp': True, 'skip_conncheck': False} >> ipa : DEBUG Loading Index file from >> '/var/lib/ipa-client/sysrestore/sysrestore.index' >> ipa : DEBUG Loading StateFile from >> '/var/lib/ipa/sysrestore/sysrestore.state' >> ipa : DEBUG Loading Index file from >> '/var/lib/ipa/sysrestore/sysrestore.index' >> Directory Manager (existing master) password: >> >> ipa : DEBUG args=/usr/bin/gpg --batch --homedir >> /tmp/tmpRGaqDpipa/ipa-A3XOq7/.gnupg --passphrase-fd 0 --yes --no-tty >> -o /tmp/tmpRGaqDpipa/files.tar -d >> /var/lib/ipa/replica-info-ipa2.xyz.dmz.gpg >> ipa : DEBUG stdout= >> ipa : DEBUG stderr=gpg: WARNING: unsafe permissions on >> homedir `/tmp/tmpRGaqDpipa/ipa-A3XOq7/.gnupg' >> gpg: keyring `/tmp/tmpRGaqDpipa/ipa-A3XOq7/.gnupg/secring.gpg' created >> gpg: keyring `/tmp/tmpRGaqDpipa/ipa-A3XOq7/.gnupg/pubring.gpg' created >> gpg: 3DES encrypted data >> gpg: encrypted with 1 passphrase >> gpg: WARNING: message was not integrity protected >> >> ipa : DEBUG args=tar xf /tmp/tmpRGaqDpipa/files.tar -C >> /tmp/tmpRGaqDpipa >> ipa : DEBUG stdout= >> ipa : DEBUG stderr= >> Run connection check to master >> Check connection from replica to remote master 'ipa1.xyz.dmz': >> 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 >> PKI-CA: Directory Service port (7389): 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 XYZ.DMZ password: >> >> Execute check on remote master >> admin at ipa1.xyz.dmz's password: >> >> Remote master check failed with following error message(s): >> >> ipa : DEBUG args=/usr/sbin/ipa-replica-conncheck --master >> ipa1.xyz.dmz --auto-master-check --realm XYZ.DMZ --principal admin >> --hostname ipa2.xyz.dmz --check-ca >> 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. >> >> -------------------------------------------------------------------------------------------------------------------------------------------------------------- >> Please suggest > > > Each server has its own iptables configuration. > > The test from the replica to the master succeeded. What failed is the > connection test from the master to the replica, so I'd look at the iptables > configuration on the replica machine. > > If that turns out ok it could be a false positive. You can add the > --skip-conncheck to the ipa-replica-install command to skip this test. > > rob -- Regards, Rajnesh Kumar Siwal From pspacek at redhat.com Tue Feb 5 14:19:16 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 05 Feb 2013 15:19:16 +0100 Subject: [Freeipa-users] ipa replica install fails In-Reply-To: References: <5111118F.8010606@redhat.com> Message-ID: <511114E4.5030003@redhat.com> On 5.2.2013 15:15, Rajnesh Kumar Siwal wrote: > Is there any other log file that may suggest something. > It would be great if we could figure out whats the cause of the error. I would recommend to run tcpdump on one of the servers and look to what is sent over the wire. It is most effective way. -- Petr^2 Spacek From rajnesh.siwal at gmail.com Tue Feb 5 14:45:56 2013 From: rajnesh.siwal at gmail.com (Rajnesh Kumar Siwal) Date: Tue, 5 Feb 2013 20:15:56 +0530 Subject: [Freeipa-users] ipa replica install fails In-Reply-To: References: <5111118F.8010606@redhat.com> Message-ID: Finally , I installed it with "--skip-conncheck":- Now DNS fails to start. I tried ipa-dns-install too:- [root at ipa2 log]# ipa-dns-install The log file for this installation can be found in /var/log/ipaserver-install.log ============================================================================== This program will setup DNS for the IPA Server. This includes: * Configure DNS (bind) To accept the default shown in brackets, press the Enter key. Existing BIND configuration detected, overwrite? [no]: yes DNS is already configured in this IPA server. [root at ipa2 log]# /etc/init.d/ipa status Directory Service: RUNNING KDC Service: RUNNING KPASSWD Service: RUNNING DNS Service: STOPPED MEMCACHE Service: RUNNING HTTP Service: RUNNING CA Service: RUNNING [root at ipa2 log]# /etc/init.d/named restart Stopping named: [ OK ] Starting named: [FAILED] --------------------------------------------------------------------------------------------- DNS logs :- Feb 5 09:40:19 ipa2 named[19873]: ---------------------------------------------------- Feb 5 09:40:19 ipa2 named[19873]: BIND 9 is maintained by Internet Systems Consortium, Feb 5 09:40:19 ipa2 named[19873]: Inc. (ISC), a non-profit 501(c)(3) public-benefit Feb 5 09:40:19 ipa2 named[19873]: corporation. Support and training for BIND 9 are Feb 5 09:40:19 ipa2 named[19873]: available at https://www.isc.org/support Feb 5 09:40:19 ipa2 named[19873]: ---------------------------------------------------- Feb 5 09:40:19 ipa2 named[19873]: adjusted limit on open files from 102400 to 1048576 Feb 5 09:40:19 ipa2 named[19873]: found 2 CPUs, using 2 worker threads Feb 5 09:40:19 ipa2 named[19873]: using up to 4096 sockets Feb 5 09:40:19 ipa2 named[19873]: loading configuration from '/etc/named.conf' Feb 5 09:40:19 ipa2 named[19873]: using default UDP/IPv4 port range: [1024, 65535] Feb 5 09:40:19 ipa2 named[19873]: using default UDP/IPv6 port range: [1024, 65535] Feb 5 09:40:19 ipa2 named[19873]: listening on IPv6 interfaces, port 53 Feb 5 09:40:19 ipa2 named[19873]: listening on IPv4 interface lo, 127.0.0.1#53 Feb 5 09:40:19 ipa2 named[19873]: listening on IPv4 interface eth0, 172.31.254.205#53 Feb 5 09:40:19 ipa2 named[19873]: generating session key for dynamic DNS Feb 5 09:40:19 ipa2 named[19873]: sizing zone task pool based on 6 zones Feb 5 09:40:19 ipa2 named[19873]: set up managed keys zone for view _default, file 'dynamic/managed-keys.bind' Feb 5 09:40:19 ipa2 named[19873]: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Mutual authentication failed) Feb 5 09:40:19 ipa2 named[19873]: bind to LDAP server failed: Local error Feb 5 09:40:19 ipa2 named[19873]: loading configuration: failure Feb 5 09:40:19 ipa2 named[19873]: exiting (due to fatal error) Feb 5 09:40:28 ipa2 kernel: IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:22:6b:12:99:bc:08:00 SRC=0.0.0.0 DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=60 ID=0 PROTO=UDP SPT=68 DPT=67 LEN=308 [root at ipa2 log]# klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: admin at XYZ.DMZ Valid starting Expires Service principal 02/05/13 14:32:56 02/06/13 14:32:24 krbtgt/XYZ.DMZ at XYZ.DMZ 02/05/13 14:33:16 02/06/13 14:31:34 ldap/ipa2.xyz.dmz at XYZ.DMZ On Tue, Feb 5, 2013 at 7:45 PM, Rajnesh Kumar Siwal wrote: > Hi Rob, > > Thanks for the quick reply. > I tried logging iptables in the replica also, but no log for dropped packet :- > I would appreciate if you could please let me know what these login actually do. > 1. Looks to me as getting tgt for admin > 2. Is it trying to login though ssh to ipa1 server ? > ---------------------------------------------------------------------- > Get credentials to log in to remote master > admin at XYZ.DMZ password: > > Execute check on remote master > admin at ipa1.xyz.dmz's password: > ---------------------------------------------------------------------- > > SELINUX is disabled at both the ends. > > Is there any other log file that may suggest something. > It would be great if we could figure out whats the cause of the error. > ----------------------------------------------------------------------------------------------------------------------- > > On Tue, Feb 5, 2013 at 7:35 PM, Rob Crittenden wrote: >> Rajnesh Kumar Siwal wrote: >>> >>> We are trying to setup the IPA replication but it says "Connection >>> check failed!". >>> We disabled the firewall and found the same result. >>> >>> >>> ----------------------------------------------------------------------------------------------------------------------- >>> [root at ipa2 /]# ipa-replica-install -d --setup-ca --setup-dns >>> --forwarder 64.71.0.60 /var/lib/ipa/replica-info-ipa2.xyz.dmz.gpg >>> ipa : DEBUG /usr/sbin/ipa-replica-install was invoked with >>> argument "/var/lib/ipa/replica-info-ipa2.xyz.dmz.gpg" and options: >>> {'no_forwarders': False, 'conf_ssh': False, 'conf_sshd': False, >>> 'ui_redirect': True, 'reverse_zone': None, 'trust_sshfp': False, >>> 'unattended': False, 'no_host_dns': False, 'ip_address': None, >>> 'no_reverse': False, 'setup_dns': True, 'create_sshfp': True, >>> 'setup_ca': True, 'forwarders': [CheckedIPAddress('64.71.0.60')], >>> 'debug': True, 'conf_ntp': True, 'skip_conncheck': False} >>> ipa : DEBUG Loading Index file from >>> '/var/lib/ipa-client/sysrestore/sysrestore.index' >>> ipa : DEBUG Loading StateFile from >>> '/var/lib/ipa/sysrestore/sysrestore.state' >>> ipa : DEBUG Loading Index file from >>> '/var/lib/ipa/sysrestore/sysrestore.index' >>> Directory Manager (existing master) password: >>> >>> ipa : DEBUG args=/usr/bin/gpg --batch --homedir >>> /tmp/tmpRGaqDpipa/ipa-A3XOq7/.gnupg --passphrase-fd 0 --yes --no-tty >>> -o /tmp/tmpRGaqDpipa/files.tar -d >>> /var/lib/ipa/replica-info-ipa2.xyz.dmz.gpg >>> ipa : DEBUG stdout= >>> ipa : DEBUG stderr=gpg: WARNING: unsafe permissions on >>> homedir `/tmp/tmpRGaqDpipa/ipa-A3XOq7/.gnupg' >>> gpg: keyring `/tmp/tmpRGaqDpipa/ipa-A3XOq7/.gnupg/secring.gpg' created >>> gpg: keyring `/tmp/tmpRGaqDpipa/ipa-A3XOq7/.gnupg/pubring.gpg' created >>> gpg: 3DES encrypted data >>> gpg: encrypted with 1 passphrase >>> gpg: WARNING: message was not integrity protected >>> >>> ipa : DEBUG args=tar xf /tmp/tmpRGaqDpipa/files.tar -C >>> /tmp/tmpRGaqDpipa >>> ipa : DEBUG stdout= >>> ipa : DEBUG stderr= >>> Run connection check to master >>> Check connection from replica to remote master 'ipa1.xyz.dmz': >>> 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 >>> PKI-CA: Directory Service port (7389): 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 XYZ.DMZ password: >>> >>> Execute check on remote master >>> admin at ipa1.xyz.dmz's password: >>> >>> Remote master check failed with following error message(s): >>> >>> ipa : DEBUG args=/usr/sbin/ipa-replica-conncheck --master >>> ipa1.xyz.dmz --auto-master-check --realm XYZ.DMZ --principal admin >>> --hostname ipa2.xyz.dmz --check-ca >>> 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. >>> >>> -------------------------------------------------------------------------------------------------------------------------------------------------------------- >>> Please suggest >> >> >> Each server has its own iptables configuration. >> >> The test from the replica to the master succeeded. What failed is the >> connection test from the master to the replica, so I'd look at the iptables >> configuration on the replica machine. >> >> If that turns out ok it could be a false positive. You can add the >> --skip-conncheck to the ipa-replica-install command to skip this test. >> >> rob > > > > -- > Regards, > Rajnesh Kumar Siwal -- Regards, Rajnesh Kumar Siwal From simo at redhat.com Tue Feb 5 14:48:31 2013 From: simo at redhat.com (Simo Sorce) Date: Tue, 05 Feb 2013 09:48:31 -0500 Subject: [Freeipa-users] SOLVED: Re: sudo rule working even after the user has been removed from the sudo rule In-Reply-To: <510FC3EC.7090200@redhat.com> References: <510FC3EC.7090200@redhat.com> Message-ID: <1360075711.2689.6.camel@willson.li.ssimo.org> On Mon, 2013-02-04 at 09:21 -0500, Rob Crittenden wrote: > Rajnesh Kumar Siwal wrote: > > Looking into the sssd logs, I came to know there there was one more > > rule allowing access:- > > (Mon Feb 4 14:13:01 2013) [sssd[be[chargepoint.dmz]]] > > [hbac_get_category] (5): Category is set to 'all'. > > (Mon Feb 4 14:13:01 2013) [sssd[be[chargepoint.dmz]]] > > [ipa_hbac_evaluate_rules] (3): Access granted by HBAC rule [allow_all] > > (Mon Feb 4 14:13:01 2013) [sssd[be[chargepoint.dmz]]] > > [be_pam_handler_callback] (4): Backend returned: (0, 0, ) > > [Success] > > > > I disabled that allow_all rule, now it is fine. > > I don't know why that would make any difference. HBAC != sudo. sudo uses pam so HBAC may be involved during auth Simo. -- Simo Sorce * Red Hat, Inc * New York From sailer at sailer.dynip.lugs.ch Tue Feb 5 14:52:56 2013 From: sailer at sailer.dynip.lugs.ch (Thomas Sailer) Date: Tue, 05 Feb 2013 15:52:56 +0100 Subject: [Freeipa-users] Upgrade to 3.1.2: web UI no longer works Message-ID: <51111CC8.7010502@sailer.dynip.lugs.ch> Hi, I've just upgraded from F16 to F18 and thus freeipa v3.1.2. It basically works, on the command line. ipa user-show xxx works. The Web UI however no longer works. I get the login window with "Your session has expired. Please re-login.", no matter whether I use kerberos or password login. The httpd logs don't seem to be very informative. /var/cache/ipa/sessions/ is empty. Could someone point me to where I could find more information to debug this problem? Thanks, Tom From rcritten at redhat.com Tue Feb 5 14:54:58 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 05 Feb 2013 09:54:58 -0500 Subject: [Freeipa-users] SOLVED: Re: sudo rule working even after the user has been removed from the sudo rule In-Reply-To: <1360075711.2689.6.camel@willson.li.ssimo.org> References: <510FC3EC.7090200@redhat.com> <1360075711.2689.6.camel@willson.li.ssimo.org> Message-ID: <51111D42.4030308@redhat.com> Simo Sorce wrote: > On Mon, 2013-02-04 at 09:21 -0500, Rob Crittenden wrote: >> Rajnesh Kumar Siwal wrote: >>> Looking into the sssd logs, I came to know there there was one more >>> rule allowing access:- >>> (Mon Feb 4 14:13:01 2013) [sssd[be[chargepoint.dmz]]] >>> [hbac_get_category] (5): Category is set to 'all'. >>> (Mon Feb 4 14:13:01 2013) [sssd[be[chargepoint.dmz]]] >>> [ipa_hbac_evaluate_rules] (3): Access granted by HBAC rule [allow_all] >>> (Mon Feb 4 14:13:01 2013) [sssd[be[chargepoint.dmz]]] >>> [be_pam_handler_callback] (4): Backend returned: (0, 0, ) >>> [Success] >>> >>> I disabled that allow_all rule, now it is fine. >> >> I don't know why that would make any difference. HBAC != sudo. > > sudo uses pam so HBAC may be involved during auth > > Simo. > That's true but it isn't going to grant sudo access to users that aren't in the rule. rob From rajnesh.siwal at gmail.com Tue Feb 5 15:01:13 2013 From: rajnesh.siwal at gmail.com (Rajnesh Kumar Siwal) Date: Tue, 5 Feb 2013 20:31:13 +0530 Subject: [Freeipa-users] SOLVED: Re: sudo rule working even after the user has been removed from the sudo rule In-Reply-To: <51111D42.4030308@redhat.com> References: <510FC3EC.7090200@redhat.com> <1360075711.2689.6.camel@willson.li.ssimo.org> <51111D42.4030308@redhat.com> Message-ID: Thanks, Bob/Simo. On Tue, Feb 5, 2013 at 8:24 PM, Rob Crittenden wrote: > Simo Sorce wrote: >> >> On Mon, 2013-02-04 at 09:21 -0500, Rob Crittenden wrote: >>> >>> Rajnesh Kumar Siwal wrote: >>>> >>>> Looking into the sssd logs, I came to know there there was one more >>>> rule allowing access:- >>>> (Mon Feb 4 14:13:01 2013) [sssd[be[chargepoint.dmz]]] >>>> [hbac_get_category] (5): Category is set to 'all'. >>>> (Mon Feb 4 14:13:01 2013) [sssd[be[chargepoint.dmz]]] >>>> [ipa_hbac_evaluate_rules] (3): Access granted by HBAC rule [allow_all] >>>> (Mon Feb 4 14:13:01 2013) [sssd[be[chargepoint.dmz]]] >>>> [be_pam_handler_callback] (4): Backend returned: (0, 0, ) >>>> [Success] >>>> >>>> I disabled that allow_all rule, now it is fine. >>> >>> >>> I don't know why that would make any difference. HBAC != sudo. >> >> >> sudo uses pam so HBAC may be involved during auth >> >> Simo. >> > > That's true but it isn't going to grant sudo access to users that aren't in > the rule. > > rob -- Regards, Rajnesh Kumar Siwal From jdennis at redhat.com Tue Feb 5 15:10:06 2013 From: jdennis at redhat.com (John Dennis) Date: Tue, 05 Feb 2013 10:10:06 -0500 Subject: [Freeipa-users] Upgrade to 3.1.2: web UI no longer works In-Reply-To: <51111CC8.7010502@sailer.dynip.lugs.ch> References: <51111CC8.7010502@sailer.dynip.lugs.ch> Message-ID: <511120CE.3010007@redhat.com> On 02/05/2013 09:52 AM, Thomas Sailer wrote: > Hi, > > I've just upgraded from F16 to F18 and thus freeipa v3.1.2. > > It basically works, on the command line. ipa user-show xxx works. > > The Web UI however no longer works. I get the login window with "Your > session has expired. Please re-login.", no matter whether I use kerberos > or password login. > > The httpd logs don't seem to be very informative. > /var/cache/ipa/sessions/ is empty. > > Could someone point me to where I could find more information to debug > this problem? In /etc/ipa/default.conf on the server add this line: debug=True Then restart the server (actually you only need to restart httpd, e.g. systemctl restart httpd.service) Then you should see a lot of debug messages in /var/log/httpd/error_log /var/cache/ipa/sessions is historical cruft, you won't find anything there. Once you get the debug trace one of us can help diagnose it. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From pspacek at redhat.com Tue Feb 5 15:59:05 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 05 Feb 2013 16:59:05 +0100 Subject: [Freeipa-users] ipa replica install fails In-Reply-To: References: <5111118F.8010606@redhat.com> Message-ID: <51112C49.7050008@redhat.com> On 5.2.2013 15:45, Rajnesh Kumar Siwal wrote: > Finally , I installed it with "--skip-conncheck":- > Now DNS fails to start. > I tried ipa-dns-install too:- > > [root at ipa2 log]# ipa-dns-install > The log file for this installation can be found in > /var/log/ipaserver-install.log > ============================================================================== > This program will setup DNS for the IPA Server. > > This includes: > * Configure DNS (bind) > > To accept the default shown in brackets, press the Enter key. > Existing BIND configuration detected, overwrite? [no]: yes > DNS is already configured in this IPA server. > [root at ipa2 log]# /etc/init.d/ipa status > Directory Service: RUNNING > KDC Service: RUNNING > KPASSWD Service: RUNNING > DNS Service: STOPPED > MEMCACHE Service: RUNNING > HTTP Service: RUNNING > CA Service: RUNNING > [root at ipa2 log]# /etc/init.d/named restart > Stopping named: [ OK ] > Starting named: [FAILED] > > --------------------------------------------------------------------------------------------- > DNS logs :- > Feb 5 09:40:19 ipa2 named[19873]: > ---------------------------------------------------- > Feb 5 09:40:19 ipa2 named[19873]: BIND 9 is maintained by Internet > Systems Consortium, > Feb 5 09:40:19 ipa2 named[19873]: Inc. (ISC), a non-profit 501(c)(3) > public-benefit > Feb 5 09:40:19 ipa2 named[19873]: corporation. Support and training > for BIND 9 are > Feb 5 09:40:19 ipa2 named[19873]: available at https://www.isc.org/support > Feb 5 09:40:19 ipa2 named[19873]: > ---------------------------------------------------- > Feb 5 09:40:19 ipa2 named[19873]: adjusted limit on open files from > 102400 to 1048576 > Feb 5 09:40:19 ipa2 named[19873]: found 2 CPUs, using 2 worker threads > Feb 5 09:40:19 ipa2 named[19873]: using up to 4096 sockets > Feb 5 09:40:19 ipa2 named[19873]: loading configuration from '/etc/named.conf' > Feb 5 09:40:19 ipa2 named[19873]: using default UDP/IPv4 port range: > [1024, 65535] > Feb 5 09:40:19 ipa2 named[19873]: using default UDP/IPv6 port range: > [1024, 65535] > Feb 5 09:40:19 ipa2 named[19873]: listening on IPv6 interfaces, port 53 > Feb 5 09:40:19 ipa2 named[19873]: listening on IPv4 interface lo, 127.0.0.1#53 > Feb 5 09:40:19 ipa2 named[19873]: listening on IPv4 interface eth0, > 172.31.254.205#53 > Feb 5 09:40:19 ipa2 named[19873]: generating session key for dynamic DNS > Feb 5 09:40:19 ipa2 named[19873]: sizing zone task pool based on 6 zones > Feb 5 09:40:19 ipa2 named[19873]: set up managed keys zone for view > _default, file 'dynamic/managed-keys.bind' > Feb 5 09:40:19 ipa2 named[19873]: GSSAPI Error: Unspecified GSS > failure. Minor code may provide more information (Mutual > authentication failed) > Feb 5 09:40:19 ipa2 named[19873]: bind to LDAP server failed: Local error > Feb 5 09:40:19 ipa2 named[19873]: loading configuration: failure > Feb 5 09:40:19 ipa2 named[19873]: exiting (due to fatal error) > Feb 5 09:40:28 ipa2 kernel: IN=eth0 OUT= > MAC=ff:ff:ff:ff:ff:ff:00:22:6b:12:99:bc:08:00 SRC=0.0.0.0 > DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=60 ID=0 PROTO=UDP > SPT=68 DPT=67 LEN=308 > [root at ipa2 log]# klist > Ticket cache: FILE:/tmp/krb5cc_0 > Default principal: admin at XYZ.DMZ > Valid starting Expires Service principal > 02/05/13 14:32:56 02/06/13 14:32:24 krbtgt/XYZ.DMZ at XYZ.DMZ > 02/05/13 14:33:16 02/06/13 14:31:34 ldap/ipa2.xyz.dmz at XYZ.DMZ The important line is: > Feb 5 09:40:19 ipa2 named[19873]: GSSAPI Error: Unspecified GSS > failure. Minor code may provide more information (Mutual > authentication failed) Did you poke to /etc/named.keytab in any way? Is this server the first installation with this host name? (I.e. was there a host with the same DNS name in the past?) I don't understand what went wrong. Please provide output from following commands (in this order): $ klist -ket /etc/named.keytab $ kinit -kt DNS/ipa2.xyz.dmz at XYZ.DMZ $ klist Simo, is it possible to do something like "kadmin -p admin" and "getprinc DNS/ipa2.xyz.dmz at XYZ.DMZ"? It fails: kadmin: getprinc DNS/host.redhat.com at E.TEST get_principal: Operation requires ``get'' privilege while retrieving "DNS/host.redhat.com at E.TEST". How it is possible to retrieve kvno and other details for IPA principals? Petr^2 Spacek > On Tue, Feb 5, 2013 at 7:45 PM, Rajnesh Kumar Siwal > wrote: >> Hi Rob, >> >> Thanks for the quick reply. >> I tried logging iptables in the replica also, but no log for dropped packet :- >> I would appreciate if you could please let me know what these login actually do. >> 1. Looks to me as getting tgt for admin >> 2. Is it trying to login though ssh to ipa1 server ? >> ---------------------------------------------------------------------- >> Get credentials to log in to remote master >> admin at XYZ.DMZ password: >> >> Execute check on remote master >> admin at ipa1.xyz.dmz's password: >> ---------------------------------------------------------------------- >> >> SELINUX is disabled at both the ends. >> >> Is there any other log file that may suggest something. >> It would be great if we could figure out whats the cause of the error. >> ----------------------------------------------------------------------------------------------------------------------- >> >> On Tue, Feb 5, 2013 at 7:35 PM, Rob Crittenden wrote: >>> Rajnesh Kumar Siwal wrote: >>>> >>>> We are trying to setup the IPA replication but it says "Connection >>>> check failed!". >>>> We disabled the firewall and found the same result. >>>> >>>> >>>> ----------------------------------------------------------------------------------------------------------------------- >>>> [root at ipa2 /]# ipa-replica-install -d --setup-ca --setup-dns >>>> --forwarder 64.71.0.60 /var/lib/ipa/replica-info-ipa2.xyz.dmz.gpg >>>> ipa : DEBUG /usr/sbin/ipa-replica-install was invoked with >>>> argument "/var/lib/ipa/replica-info-ipa2.xyz.dmz.gpg" and options: >>>> {'no_forwarders': False, 'conf_ssh': False, 'conf_sshd': False, >>>> 'ui_redirect': True, 'reverse_zone': None, 'trust_sshfp': False, >>>> 'unattended': False, 'no_host_dns': False, 'ip_address': None, >>>> 'no_reverse': False, 'setup_dns': True, 'create_sshfp': True, >>>> 'setup_ca': True, 'forwarders': [CheckedIPAddress('64.71.0.60')], >>>> 'debug': True, 'conf_ntp': True, 'skip_conncheck': False} >>>> ipa : DEBUG Loading Index file from >>>> '/var/lib/ipa-client/sysrestore/sysrestore.index' >>>> ipa : DEBUG Loading StateFile from >>>> '/var/lib/ipa/sysrestore/sysrestore.state' >>>> ipa : DEBUG Loading Index file from >>>> '/var/lib/ipa/sysrestore/sysrestore.index' >>>> Directory Manager (existing master) password: >>>> >>>> ipa : DEBUG args=/usr/bin/gpg --batch --homedir >>>> /tmp/tmpRGaqDpipa/ipa-A3XOq7/.gnupg --passphrase-fd 0 --yes --no-tty >>>> -o /tmp/tmpRGaqDpipa/files.tar -d >>>> /var/lib/ipa/replica-info-ipa2.xyz.dmz.gpg >>>> ipa : DEBUG stdout= >>>> ipa : DEBUG stderr=gpg: WARNING: unsafe permissions on >>>> homedir `/tmp/tmpRGaqDpipa/ipa-A3XOq7/.gnupg' >>>> gpg: keyring `/tmp/tmpRGaqDpipa/ipa-A3XOq7/.gnupg/secring.gpg' created >>>> gpg: keyring `/tmp/tmpRGaqDpipa/ipa-A3XOq7/.gnupg/pubring.gpg' created >>>> gpg: 3DES encrypted data >>>> gpg: encrypted with 1 passphrase >>>> gpg: WARNING: message was not integrity protected >>>> >>>> ipa : DEBUG args=tar xf /tmp/tmpRGaqDpipa/files.tar -C >>>> /tmp/tmpRGaqDpipa >>>> ipa : DEBUG stdout= >>>> ipa : DEBUG stderr= >>>> Run connection check to master >>>> Check connection from replica to remote master 'ipa1.xyz.dmz': >>>> 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 >>>> PKI-CA: Directory Service port (7389): 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 XYZ.DMZ password: >>>> >>>> Execute check on remote master >>>> admin at ipa1.xyz.dmz's password: >>>> >>>> Remote master check failed with following error message(s): >>>> >>>> ipa : DEBUG args=/usr/sbin/ipa-replica-conncheck --master >>>> ipa1.xyz.dmz --auto-master-check --realm XYZ.DMZ --principal admin >>>> --hostname ipa2.xyz.dmz --check-ca >>>> 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. >>>> >>>> -------------------------------------------------------------------------------------------------------------------------------------------------------------- >>>> Please suggest >>> >>> >>> Each server has its own iptables configuration. >>> >>> The test from the replica to the master succeeded. What failed is the >>> connection test from the master to the replica, so I'd look at the iptables >>> configuration on the replica machine. >>> >>> If that turns out ok it could be a false positive. You can add the >>> --skip-conncheck to the ipa-replica-install command to skip this test. From simo at redhat.com Tue Feb 5 16:01:36 2013 From: simo at redhat.com (Simo Sorce) Date: Tue, 05 Feb 2013 11:01:36 -0500 Subject: [Freeipa-users] ipa replica install fails In-Reply-To: <51112C49.7050008@redhat.com> References: <5111118F.8010606@redhat.com> <51112C49.7050008@redhat.com> Message-ID: <1360080096.2689.16.camel@willson.li.ssimo.org> On Tue, 2013-02-05 at 16:59 +0100, Petr Spacek wrote: > On 5.2.2013 15:45, Rajnesh Kumar Siwal wrote: > > Finally , I installed it with "--skip-conncheck":- > > Now DNS fails to start. > > I tried ipa-dns-install too:- > > > > [root at ipa2 log]# ipa-dns-install > > The log file for this installation can be found in > > /var/log/ipaserver-install.log > > ============================================================================== > > This program will setup DNS for the IPA Server. > > > > This includes: > > * Configure DNS (bind) > > > > To accept the default shown in brackets, press the Enter key. > > Existing BIND configuration detected, overwrite? [no]: yes > > DNS is already configured in this IPA server. > > [root at ipa2 log]# /etc/init.d/ipa status > > Directory Service: RUNNING > > KDC Service: RUNNING > > KPASSWD Service: RUNNING > > DNS Service: STOPPED > > MEMCACHE Service: RUNNING > > HTTP Service: RUNNING > > CA Service: RUNNING > > [root at ipa2 log]# /etc/init.d/named restart > > Stopping named: [ OK ] > > Starting named: [FAILED] > > > > --------------------------------------------------------------------------------------------- > > DNS logs :- > > Feb 5 09:40:19 ipa2 named[19873]: > > ---------------------------------------------------- > > Feb 5 09:40:19 ipa2 named[19873]: BIND 9 is maintained by Internet > > Systems Consortium, > > Feb 5 09:40:19 ipa2 named[19873]: Inc. (ISC), a non-profit 501(c)(3) > > public-benefit > > Feb 5 09:40:19 ipa2 named[19873]: corporation. Support and training > > for BIND 9 are > > Feb 5 09:40:19 ipa2 named[19873]: available at https://www.isc.org/support > > Feb 5 09:40:19 ipa2 named[19873]: > > ---------------------------------------------------- > > Feb 5 09:40:19 ipa2 named[19873]: adjusted limit on open files from > > 102400 to 1048576 > > Feb 5 09:40:19 ipa2 named[19873]: found 2 CPUs, using 2 worker threads > > Feb 5 09:40:19 ipa2 named[19873]: using up to 4096 sockets > > Feb 5 09:40:19 ipa2 named[19873]: loading configuration from '/etc/named.conf' > > Feb 5 09:40:19 ipa2 named[19873]: using default UDP/IPv4 port range: > > [1024, 65535] > > Feb 5 09:40:19 ipa2 named[19873]: using default UDP/IPv6 port range: > > [1024, 65535] > > Feb 5 09:40:19 ipa2 named[19873]: listening on IPv6 interfaces, port 53 > > Feb 5 09:40:19 ipa2 named[19873]: listening on IPv4 interface lo, 127.0.0.1#53 > > Feb 5 09:40:19 ipa2 named[19873]: listening on IPv4 interface eth0, > > 172.31.254.205#53 > > Feb 5 09:40:19 ipa2 named[19873]: generating session key for dynamic DNS > > Feb 5 09:40:19 ipa2 named[19873]: sizing zone task pool based on 6 zones > > Feb 5 09:40:19 ipa2 named[19873]: set up managed keys zone for view > > _default, file 'dynamic/managed-keys.bind' > > Feb 5 09:40:19 ipa2 named[19873]: GSSAPI Error: Unspecified GSS > > failure. Minor code may provide more information (Mutual > > authentication failed) > > Feb 5 09:40:19 ipa2 named[19873]: bind to LDAP server failed: Local error > > Feb 5 09:40:19 ipa2 named[19873]: loading configuration: failure > > Feb 5 09:40:19 ipa2 named[19873]: exiting (due to fatal error) > > Feb 5 09:40:28 ipa2 kernel: IN=eth0 OUT= > > MAC=ff:ff:ff:ff:ff:ff:00:22:6b:12:99:bc:08:00 SRC=0.0.0.0 > > DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=60 ID=0 PROTO=UDP > > SPT=68 DPT=67 LEN=308 > > [root at ipa2 log]# klist > > Ticket cache: FILE:/tmp/krb5cc_0 > > Default principal: admin at XYZ.DMZ > > Valid starting Expires Service principal > > 02/05/13 14:32:56 02/06/13 14:32:24 krbtgt/XYZ.DMZ at XYZ.DMZ > > 02/05/13 14:33:16 02/06/13 14:31:34 ldap/ipa2.xyz.dmz at XYZ.DMZ > > The important line is: > > Feb 5 09:40:19 ipa2 named[19873]: GSSAPI Error: Unspecified GSS > > failure. Minor code may provide more information (Mutual > > authentication failed) > > Did you poke to /etc/named.keytab in any way? Is this server the first > installation with this host name? (I.e. was there a host with the same DNS > name in the past?) > > I don't understand what went wrong. > > Please provide output from following commands (in this order): > $ klist -ket /etc/named.keytab > $ kinit -kt DNS/ipa2.xyz.dmz at XYZ.DMZ > $ klist > > Simo, is it possible to do something like "kadmin -p admin" and "getprinc > DNS/ipa2.xyz.dmz at XYZ.DMZ"? you could use kadmin.local on the KDC > It fails: > > kadmin: getprinc DNS/host.redhat.com at E.TEST > get_principal: Operation requires ``get'' privilege while retrieving > "DNS/host.redhat.com at E.TEST". Interesting, this shouldn't happen, can you open a bug ? (only if on 3.x) > How it is possible to retrieve kvno and other details for IPA principals? Use kvno command for now. Simo. -- Simo Sorce * Red Hat, Inc * New York From rajnesh.siwal at gmail.com Tue Feb 5 16:15:36 2013 From: rajnesh.siwal at gmail.com (Rajnesh Kumar Siwal) Date: Tue, 5 Feb 2013 21:45:36 +0530 Subject: [Freeipa-users] ipa replica install fails In-Reply-To: References: <5111118F.8010606@redhat.com> Message-ID: Last time the installation of replica failed. So this is second time I did it (The logs in the mail are from the second time after I uninstalled the ipa2). After installing the replica, I restarted IPA and failed to start the KDC too. So, kinit admin is now failing. --------------------------------------------------------------------- [root at ipa2 log]# klist -ket /etc/named.keytab Keytab name: WRFILE:/etc/named.keytab KVNO Timestamp Principal ---- ----------------- -------------------------------------------------------- 2 02/05/13 14:30:26 DNS/ipa2.xyz.dmz at XYZ.DMZ (aes256-cts-hmac-sha1-96) 2 02/05/13 14:30:26 DNS/ipa2.xyz.dmz at XYZ.DMZ (aes128-cts-hmac-sha1-96) 2 02/05/13 14:30:26 DNS/ipa2.xyz.dmz at XYZ.DMZ (des3-cbc-sha1) 2 02/05/13 14:30:26 DNS/ipa2.xyz.dmz at XYZ.DMZ (arcfour-hmac) [root at ipa2 log]# kinit -kt DNS/ipa2.xyz.dmz at XYZ.DMZ kinit: Cannot contact any KDC for realm 'XYZ.DMZ' while getting initial credentials --------------------------------------------------------------------------------------------------------------- On Tue, Feb 5, 2013 at 8:15 PM, Rajnesh Kumar Siwal wrote: > Finally , I installed it with "--skip-conncheck":- > Now DNS fails to start. > I tried ipa-dns-install too:- > > [root at ipa2 log]# ipa-dns-install > The log file for this installation can be found in > /var/log/ipaserver-install.log > ============================================================================== > This program will setup DNS for the IPA Server. > > This includes: > * Configure DNS (bind) > > To accept the default shown in brackets, press the Enter key. > Existing BIND configuration detected, overwrite? [no]: yes > DNS is already configured in this IPA server. > [root at ipa2 log]# /etc/init.d/ipa status > Directory Service: RUNNING > KDC Service: RUNNING > KPASSWD Service: RUNNING > DNS Service: STOPPED > MEMCACHE Service: RUNNING > HTTP Service: RUNNING > CA Service: RUNNING > [root at ipa2 log]# /etc/init.d/named restart > Stopping named: [ OK ] > Starting named: [FAILED] > > --------------------------------------------------------------------------------------------- > DNS logs :- > Feb 5 09:40:19 ipa2 named[19873]: > ---------------------------------------------------- > Feb 5 09:40:19 ipa2 named[19873]: BIND 9 is maintained by Internet > Systems Consortium, > Feb 5 09:40:19 ipa2 named[19873]: Inc. (ISC), a non-profit 501(c)(3) > public-benefit > Feb 5 09:40:19 ipa2 named[19873]: corporation. Support and training > for BIND 9 are > Feb 5 09:40:19 ipa2 named[19873]: available at https://www.isc.org/support > Feb 5 09:40:19 ipa2 named[19873]: > ---------------------------------------------------- > Feb 5 09:40:19 ipa2 named[19873]: adjusted limit on open files from > 102400 to 1048576 > Feb 5 09:40:19 ipa2 named[19873]: found 2 CPUs, using 2 worker threads > Feb 5 09:40:19 ipa2 named[19873]: using up to 4096 sockets > Feb 5 09:40:19 ipa2 named[19873]: loading configuration from '/etc/named.conf' > Feb 5 09:40:19 ipa2 named[19873]: using default UDP/IPv4 port range: > [1024, 65535] > Feb 5 09:40:19 ipa2 named[19873]: using default UDP/IPv6 port range: > [1024, 65535] > Feb 5 09:40:19 ipa2 named[19873]: listening on IPv6 interfaces, port 53 > Feb 5 09:40:19 ipa2 named[19873]: listening on IPv4 interface lo, 127.0.0.1#53 > Feb 5 09:40:19 ipa2 named[19873]: listening on IPv4 interface eth0, > 172.31.254.205#53 > Feb 5 09:40:19 ipa2 named[19873]: generating session key for dynamic DNS > Feb 5 09:40:19 ipa2 named[19873]: sizing zone task pool based on 6 zones > Feb 5 09:40:19 ipa2 named[19873]: set up managed keys zone for view > _default, file 'dynamic/managed-keys.bind' > Feb 5 09:40:19 ipa2 named[19873]: GSSAPI Error: Unspecified GSS > failure. Minor code may provide more information (Mutual > authentication failed) > Feb 5 09:40:19 ipa2 named[19873]: bind to LDAP server failed: Local error > Feb 5 09:40:19 ipa2 named[19873]: loading configuration: failure > Feb 5 09:40:19 ipa2 named[19873]: exiting (due to fatal error) > Feb 5 09:40:28 ipa2 kernel: IN=eth0 OUT= > MAC=ff:ff:ff:ff:ff:ff:00:22:6b:12:99:bc:08:00 SRC=0.0.0.0 > DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=60 ID=0 PROTO=UDP > SPT=68 DPT=67 LEN=308 > [root at ipa2 log]# klist > Ticket cache: FILE:/tmp/krb5cc_0 > Default principal: admin at XYZ.DMZ > Valid starting Expires Service principal > 02/05/13 14:32:56 02/06/13 14:32:24 krbtgt/XYZ.DMZ at XYZ.DMZ > 02/05/13 14:33:16 02/06/13 14:31:34 ldap/ipa2.xyz.dmz at XYZ.DMZ > > > > On Tue, Feb 5, 2013 at 7:45 PM, Rajnesh Kumar Siwal > wrote: >> Hi Rob, >> >> Thanks for the quick reply. >> I tried logging iptables in the replica also, but no log for dropped packet :- >> I would appreciate if you could please let me know what these login actually do. >> 1. Looks to me as getting tgt for admin >> 2. Is it trying to login though ssh to ipa1 server ? >> ---------------------------------------------------------------------- >> Get credentials to log in to remote master >> admin at XYZ.DMZ password: >> >> Execute check on remote master >> admin at ipa1.xyz.dmz's password: >> ---------------------------------------------------------------------- >> >> SELINUX is disabled at both the ends. >> >> Is there any other log file that may suggest something. >> It would be great if we could figure out whats the cause of the error. >> ----------------------------------------------------------------------------------------------------------------------- >> >> On Tue, Feb 5, 2013 at 7:35 PM, Rob Crittenden wrote: >>> Rajnesh Kumar Siwal wrote: >>>> >>>> We are trying to setup the IPA replication but it says "Connection >>>> check failed!". >>>> We disabled the firewall and found the same result. >>>> >>>> >>>> ----------------------------------------------------------------------------------------------------------------------- >>>> [root at ipa2 /]# ipa-replica-install -d --setup-ca --setup-dns >>>> --forwarder 64.71.0.60 /var/lib/ipa/replica-info-ipa2.xyz.dmz.gpg >>>> ipa : DEBUG /usr/sbin/ipa-replica-install was invoked with >>>> argument "/var/lib/ipa/replica-info-ipa2.xyz.dmz.gpg" and options: >>>> {'no_forwarders': False, 'conf_ssh': False, 'conf_sshd': False, >>>> 'ui_redirect': True, 'reverse_zone': None, 'trust_sshfp': False, >>>> 'unattended': False, 'no_host_dns': False, 'ip_address': None, >>>> 'no_reverse': False, 'setup_dns': True, 'create_sshfp': True, >>>> 'setup_ca': True, 'forwarders': [CheckedIPAddress('64.71.0.60')], >>>> 'debug': True, 'conf_ntp': True, 'skip_conncheck': False} >>>> ipa : DEBUG Loading Index file from >>>> '/var/lib/ipa-client/sysrestore/sysrestore.index' >>>> ipa : DEBUG Loading StateFile from >>>> '/var/lib/ipa/sysrestore/sysrestore.state' >>>> ipa : DEBUG Loading Index file from >>>> '/var/lib/ipa/sysrestore/sysrestore.index' >>>> Directory Manager (existing master) password: >>>> >>>> ipa : DEBUG args=/usr/bin/gpg --batch --homedir >>>> /tmp/tmpRGaqDpipa/ipa-A3XOq7/.gnupg --passphrase-fd 0 --yes --no-tty >>>> -o /tmp/tmpRGaqDpipa/files.tar -d >>>> /var/lib/ipa/replica-info-ipa2.xyz.dmz.gpg >>>> ipa : DEBUG stdout= >>>> ipa : DEBUG stderr=gpg: WARNING: unsafe permissions on >>>> homedir `/tmp/tmpRGaqDpipa/ipa-A3XOq7/.gnupg' >>>> gpg: keyring `/tmp/tmpRGaqDpipa/ipa-A3XOq7/.gnupg/secring.gpg' created >>>> gpg: keyring `/tmp/tmpRGaqDpipa/ipa-A3XOq7/.gnupg/pubring.gpg' created >>>> gpg: 3DES encrypted data >>>> gpg: encrypted with 1 passphrase >>>> gpg: WARNING: message was not integrity protected >>>> >>>> ipa : DEBUG args=tar xf /tmp/tmpRGaqDpipa/files.tar -C >>>> /tmp/tmpRGaqDpipa >>>> ipa : DEBUG stdout= >>>> ipa : DEBUG stderr= >>>> Run connection check to master >>>> Check connection from replica to remote master 'ipa1.xyz.dmz': >>>> 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 >>>> PKI-CA: Directory Service port (7389): 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 XYZ.DMZ password: >>>> >>>> Execute check on remote master >>>> admin at ipa1.xyz.dmz's password: >>>> >>>> Remote master check failed with following error message(s): >>>> >>>> ipa : DEBUG args=/usr/sbin/ipa-replica-conncheck --master >>>> ipa1.xyz.dmz --auto-master-check --realm XYZ.DMZ --principal admin >>>> --hostname ipa2.xyz.dmz --check-ca >>>> 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. >>>> >>>> -------------------------------------------------------------------------------------------------------------------------------------------------------------- >>>> Please suggest >>> >>> >>> Each server has its own iptables configuration. >>> >>> The test from the replica to the master succeeded. What failed is the >>> connection test from the master to the replica, so I'd look at the iptables >>> configuration on the replica machine. >>> >>> If that turns out ok it could be a false positive. You can add the >>> --skip-conncheck to the ipa-replica-install command to skip this test. >>> >>> rob >> >> >> >> -- >> Regards, >> Rajnesh Kumar Siwal > > > > -- > Regards, > Rajnesh Kumar Siwal -- Regards, Rajnesh Kumar Siwal From pspacek at redhat.com Tue Feb 5 16:33:39 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 05 Feb 2013 17:33:39 +0100 Subject: [Freeipa-users] ipa replica install fails In-Reply-To: References: <5111118F.8010606@redhat.com> Message-ID: <51113463.4030904@redhat.com> On 5.2.2013 17:15, Rajnesh Kumar Siwal wrote: > Last time the installation of replica failed. So this is second time I > did it (The logs in the mail are from the second time after I > uninstalled the ipa2). > > After installing the replica, I restarted IPA and failed to start the KDC too. > So, kinit admin is now failing. Correct me if I'm wrong, please: Now you have 2 replicas, one of them is not starting and you can't kinit? In that case you really have some network/firewall problems, because kinit should failover to the functional replica. I would recommend to really debug network/firewall and then continue with something else. Petr^2 Spacek > --------------------------------------------------------------------- > > [root at ipa2 log]# klist -ket /etc/named.keytab > Keytab name: WRFILE:/etc/named.keytab > KVNO Timestamp Principal > ---- ----------------- -------------------------------------------------------- > 2 02/05/13 14:30:26 DNS/ipa2.xyz.dmz at XYZ.DMZ (aes256-cts-hmac-sha1-96) > 2 02/05/13 14:30:26 DNS/ipa2.xyz.dmz at XYZ.DMZ (aes128-cts-hmac-sha1-96) > 2 02/05/13 14:30:26 DNS/ipa2.xyz.dmz at XYZ.DMZ (des3-cbc-sha1) > 2 02/05/13 14:30:26 DNS/ipa2.xyz.dmz at XYZ.DMZ (arcfour-hmac) > [root at ipa2 log]# kinit -kt DNS/ipa2.xyz.dmz at XYZ.DMZ > kinit: Cannot contact any KDC for realm 'XYZ.DMZ' while getting > initial credentials > --------------------------------------------------------------------------------------------------------------- > > On Tue, Feb 5, 2013 at 8:15 PM, Rajnesh Kumar Siwal > wrote: >> Finally , I installed it with "--skip-conncheck":- >> Now DNS fails to start. >> I tried ipa-dns-install too:- >> >> [root at ipa2 log]# ipa-dns-install >> The log file for this installation can be found in >> /var/log/ipaserver-install.log >> ============================================================================== >> This program will setup DNS for the IPA Server. >> >> This includes: >> * Configure DNS (bind) >> >> To accept the default shown in brackets, press the Enter key. >> Existing BIND configuration detected, overwrite? [no]: yes >> DNS is already configured in this IPA server. >> [root at ipa2 log]# /etc/init.d/ipa status >> Directory Service: RUNNING >> KDC Service: RUNNING >> KPASSWD Service: RUNNING >> DNS Service: STOPPED >> MEMCACHE Service: RUNNING >> HTTP Service: RUNNING >> CA Service: RUNNING >> [root at ipa2 log]# /etc/init.d/named restart >> Stopping named: [ OK ] >> Starting named: [FAILED] >> >> --------------------------------------------------------------------------------------------- >> DNS logs :- >> Feb 5 09:40:19 ipa2 named[19873]: >> ---------------------------------------------------- >> Feb 5 09:40:19 ipa2 named[19873]: BIND 9 is maintained by Internet >> Systems Consortium, >> Feb 5 09:40:19 ipa2 named[19873]: Inc. (ISC), a non-profit 501(c)(3) >> public-benefit >> Feb 5 09:40:19 ipa2 named[19873]: corporation. Support and training >> for BIND 9 are >> Feb 5 09:40:19 ipa2 named[19873]: available at https://www.isc.org/support >> Feb 5 09:40:19 ipa2 named[19873]: >> ---------------------------------------------------- >> Feb 5 09:40:19 ipa2 named[19873]: adjusted limit on open files from >> 102400 to 1048576 >> Feb 5 09:40:19 ipa2 named[19873]: found 2 CPUs, using 2 worker threads >> Feb 5 09:40:19 ipa2 named[19873]: using up to 4096 sockets >> Feb 5 09:40:19 ipa2 named[19873]: loading configuration from '/etc/named.conf' >> Feb 5 09:40:19 ipa2 named[19873]: using default UDP/IPv4 port range: >> [1024, 65535] >> Feb 5 09:40:19 ipa2 named[19873]: using default UDP/IPv6 port range: >> [1024, 65535] >> Feb 5 09:40:19 ipa2 named[19873]: listening on IPv6 interfaces, port 53 >> Feb 5 09:40:19 ipa2 named[19873]: listening on IPv4 interface lo, 127.0.0.1#53 >> Feb 5 09:40:19 ipa2 named[19873]: listening on IPv4 interface eth0, >> 172.31.254.205#53 >> Feb 5 09:40:19 ipa2 named[19873]: generating session key for dynamic DNS >> Feb 5 09:40:19 ipa2 named[19873]: sizing zone task pool based on 6 zones >> Feb 5 09:40:19 ipa2 named[19873]: set up managed keys zone for view >> _default, file 'dynamic/managed-keys.bind' >> Feb 5 09:40:19 ipa2 named[19873]: GSSAPI Error: Unspecified GSS >> failure. Minor code may provide more information (Mutual >> authentication failed) >> Feb 5 09:40:19 ipa2 named[19873]: bind to LDAP server failed: Local error >> Feb 5 09:40:19 ipa2 named[19873]: loading configuration: failure >> Feb 5 09:40:19 ipa2 named[19873]: exiting (due to fatal error) >> Feb 5 09:40:28 ipa2 kernel: IN=eth0 OUT= >> MAC=ff:ff:ff:ff:ff:ff:00:22:6b:12:99:bc:08:00 SRC=0.0.0.0 >> DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=60 ID=0 PROTO=UDP >> SPT=68 DPT=67 LEN=308 >> [root at ipa2 log]# klist >> Ticket cache: FILE:/tmp/krb5cc_0 >> Default principal: admin at XYZ.DMZ >> Valid starting Expires Service principal >> 02/05/13 14:32:56 02/06/13 14:32:24 krbtgt/XYZ.DMZ at XYZ.DMZ >> 02/05/13 14:33:16 02/06/13 14:31:34 ldap/ipa2.xyz.dmz at XYZ.DMZ >> >> >> >> On Tue, Feb 5, 2013 at 7:45 PM, Rajnesh Kumar Siwal >> wrote: >>> Hi Rob, >>> >>> Thanks for the quick reply. >>> I tried logging iptables in the replica also, but no log for dropped packet :- >>> I would appreciate if you could please let me know what these login actually do. >>> 1. Looks to me as getting tgt for admin >>> 2. Is it trying to login though ssh to ipa1 server ? >>> ---------------------------------------------------------------------- >>> Get credentials to log in to remote master >>> admin at XYZ.DMZ password: >>> >>> Execute check on remote master >>> admin at ipa1.xyz.dmz's password: >>> ---------------------------------------------------------------------- >>> >>> SELINUX is disabled at both the ends. >>> >>> Is there any other log file that may suggest something. >>> It would be great if we could figure out whats the cause of the error. >>> ----------------------------------------------------------------------------------------------------------------------- >>> >>> On Tue, Feb 5, 2013 at 7:35 PM, Rob Crittenden wrote: >>>> Rajnesh Kumar Siwal wrote: >>>>> >>>>> We are trying to setup the IPA replication but it says "Connection >>>>> check failed!". >>>>> We disabled the firewall and found the same result. >>>>> >>>>> >>>>> ----------------------------------------------------------------------------------------------------------------------- >>>>> [root at ipa2 /]# ipa-replica-install -d --setup-ca --setup-dns >>>>> --forwarder 64.71.0.60 /var/lib/ipa/replica-info-ipa2.xyz.dmz.gpg >>>>> ipa : DEBUG /usr/sbin/ipa-replica-install was invoked with >>>>> argument "/var/lib/ipa/replica-info-ipa2.xyz.dmz.gpg" and options: >>>>> {'no_forwarders': False, 'conf_ssh': False, 'conf_sshd': False, >>>>> 'ui_redirect': True, 'reverse_zone': None, 'trust_sshfp': False, >>>>> 'unattended': False, 'no_host_dns': False, 'ip_address': None, >>>>> 'no_reverse': False, 'setup_dns': True, 'create_sshfp': True, >>>>> 'setup_ca': True, 'forwarders': [CheckedIPAddress('64.71.0.60')], >>>>> 'debug': True, 'conf_ntp': True, 'skip_conncheck': False} >>>>> ipa : DEBUG Loading Index file from >>>>> '/var/lib/ipa-client/sysrestore/sysrestore.index' >>>>> ipa : DEBUG Loading StateFile from >>>>> '/var/lib/ipa/sysrestore/sysrestore.state' >>>>> ipa : DEBUG Loading Index file from >>>>> '/var/lib/ipa/sysrestore/sysrestore.index' >>>>> Directory Manager (existing master) password: >>>>> >>>>> ipa : DEBUG args=/usr/bin/gpg --batch --homedir >>>>> /tmp/tmpRGaqDpipa/ipa-A3XOq7/.gnupg --passphrase-fd 0 --yes --no-tty >>>>> -o /tmp/tmpRGaqDpipa/files.tar -d >>>>> /var/lib/ipa/replica-info-ipa2.xyz.dmz.gpg >>>>> ipa : DEBUG stdout= >>>>> ipa : DEBUG stderr=gpg: WARNING: unsafe permissions on >>>>> homedir `/tmp/tmpRGaqDpipa/ipa-A3XOq7/.gnupg' >>>>> gpg: keyring `/tmp/tmpRGaqDpipa/ipa-A3XOq7/.gnupg/secring.gpg' created >>>>> gpg: keyring `/tmp/tmpRGaqDpipa/ipa-A3XOq7/.gnupg/pubring.gpg' created >>>>> gpg: 3DES encrypted data >>>>> gpg: encrypted with 1 passphrase >>>>> gpg: WARNING: message was not integrity protected >>>>> >>>>> ipa : DEBUG args=tar xf /tmp/tmpRGaqDpipa/files.tar -C >>>>> /tmp/tmpRGaqDpipa >>>>> ipa : DEBUG stdout= >>>>> ipa : DEBUG stderr= >>>>> Run connection check to master >>>>> Check connection from replica to remote master 'ipa1.xyz.dmz': >>>>> 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 >>>>> PKI-CA: Directory Service port (7389): 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 XYZ.DMZ password: >>>>> >>>>> Execute check on remote master >>>>> admin at ipa1.xyz.dmz's password: >>>>> >>>>> Remote master check failed with following error message(s): >>>>> >>>>> ipa : DEBUG args=/usr/sbin/ipa-replica-conncheck --master >>>>> ipa1.xyz.dmz --auto-master-check --realm XYZ.DMZ --principal admin >>>>> --hostname ipa2.xyz.dmz --check-ca >>>>> 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. >>>>> >>>>> -------------------------------------------------------------------------------------------------------------------------------------------------------------- >>>>> Please suggest >>>> >>>> >>>> Each server has its own iptables configuration. >>>> >>>> The test from the replica to the master succeeded. What failed is the >>>> connection test from the master to the replica, so I'd look at the iptables >>>> configuration on the replica machine. >>>> >>>> If that turns out ok it could be a false positive. You can add the >>>> --skip-conncheck to the ipa-replica-install command to skip this test. From rajnesh.siwal at gmail.com Tue Feb 5 16:48:29 2013 From: rajnesh.siwal at gmail.com (Rajnesh Kumar Siwal) Date: Tue, 5 Feb 2013 22:18:29 +0530 Subject: [Freeipa-users] ipa replica install fails In-Reply-To: References: <5111118F.8010606@redhat.com> Message-ID: Both of these replica are in the same network. I have disabled the iptables on both Selinux disable. still the output of kinit admin is the same kinit: Cannot contact any KDC for realm strace output attached. On Tue, Feb 5, 2013 at 9:45 PM, Rajnesh Kumar Siwal wrote: > Last time the installation of replica failed. So this is second time I > did it (The logs in the mail are from the second time after I > uninstalled the ipa2). > > After installing the replica, I restarted IPA and failed to start the KDC too. > So, kinit admin is now failing. > --------------------------------------------------------------------- > > [root at ipa2 log]# klist -ket /etc/named.keytab > Keytab name: WRFILE:/etc/named.keytab > KVNO Timestamp Principal > ---- ----------------- -------------------------------------------------------- > 2 02/05/13 14:30:26 DNS/ipa2.xyz.dmz at XYZ.DMZ (aes256-cts-hmac-sha1-96) > 2 02/05/13 14:30:26 DNS/ipa2.xyz.dmz at XYZ.DMZ (aes128-cts-hmac-sha1-96) > 2 02/05/13 14:30:26 DNS/ipa2.xyz.dmz at XYZ.DMZ (des3-cbc-sha1) > 2 02/05/13 14:30:26 DNS/ipa2.xyz.dmz at XYZ.DMZ (arcfour-hmac) > [root at ipa2 log]# kinit -kt DNS/ipa2.xyz.dmz at XYZ.DMZ > kinit: Cannot contact any KDC for realm 'XYZ.DMZ' while getting > initial credentials > --------------------------------------------------------------------------------------------------------------- > > On Tue, Feb 5, 2013 at 8:15 PM, Rajnesh Kumar Siwal > wrote: >> Finally , I installed it with "--skip-conncheck":- >> Now DNS fails to start. >> I tried ipa-dns-install too:- >> >> [root at ipa2 log]# ipa-dns-install >> The log file for this installation can be found in >> /var/log/ipaserver-install.log >> ============================================================================== >> This program will setup DNS for the IPA Server. >> >> This includes: >> * Configure DNS (bind) >> >> To accept the default shown in brackets, press the Enter key. >> Existing BIND configuration detected, overwrite? [no]: yes >> DNS is already configured in this IPA server. >> [root at ipa2 log]# /etc/init.d/ipa status >> Directory Service: RUNNING >> KDC Service: RUNNING >> KPASSWD Service: RUNNING >> DNS Service: STOPPED >> MEMCACHE Service: RUNNING >> HTTP Service: RUNNING >> CA Service: RUNNING >> [root at ipa2 log]# /etc/init.d/named restart >> Stopping named: [ OK ] >> Starting named: [FAILED] >> >> --------------------------------------------------------------------------------------------- >> DNS logs :- >> Feb 5 09:40:19 ipa2 named[19873]: >> ---------------------------------------------------- >> Feb 5 09:40:19 ipa2 named[19873]: BIND 9 is maintained by Internet >> Systems Consortium, >> Feb 5 09:40:19 ipa2 named[19873]: Inc. (ISC), a non-profit 501(c)(3) >> public-benefit >> Feb 5 09:40:19 ipa2 named[19873]: corporation. Support and training >> for BIND 9 are >> Feb 5 09:40:19 ipa2 named[19873]: available at https://www.isc.org/support >> Feb 5 09:40:19 ipa2 named[19873]: >> ---------------------------------------------------- >> Feb 5 09:40:19 ipa2 named[19873]: adjusted limit on open files from >> 102400 to 1048576 >> Feb 5 09:40:19 ipa2 named[19873]: found 2 CPUs, using 2 worker threads >> Feb 5 09:40:19 ipa2 named[19873]: using up to 4096 sockets >> Feb 5 09:40:19 ipa2 named[19873]: loading configuration from '/etc/named.conf' >> Feb 5 09:40:19 ipa2 named[19873]: using default UDP/IPv4 port range: >> [1024, 65535] >> Feb 5 09:40:19 ipa2 named[19873]: using default UDP/IPv6 port range: >> [1024, 65535] >> Feb 5 09:40:19 ipa2 named[19873]: listening on IPv6 interfaces, port 53 >> Feb 5 09:40:19 ipa2 named[19873]: listening on IPv4 interface lo, 127.0.0.1#53 >> Feb 5 09:40:19 ipa2 named[19873]: listening on IPv4 interface eth0, >> 172.31.254.205#53 >> Feb 5 09:40:19 ipa2 named[19873]: generating session key for dynamic DNS >> Feb 5 09:40:19 ipa2 named[19873]: sizing zone task pool based on 6 zones >> Feb 5 09:40:19 ipa2 named[19873]: set up managed keys zone for view >> _default, file 'dynamic/managed-keys.bind' >> Feb 5 09:40:19 ipa2 named[19873]: GSSAPI Error: Unspecified GSS >> failure. Minor code may provide more information (Mutual >> authentication failed) >> Feb 5 09:40:19 ipa2 named[19873]: bind to LDAP server failed: Local error >> Feb 5 09:40:19 ipa2 named[19873]: loading configuration: failure >> Feb 5 09:40:19 ipa2 named[19873]: exiting (due to fatal error) >> Feb 5 09:40:28 ipa2 kernel: IN=eth0 OUT= >> MAC=ff:ff:ff:ff:ff:ff:00:22:6b:12:99:bc:08:00 SRC=0.0.0.0 >> DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=60 ID=0 PROTO=UDP >> SPT=68 DPT=67 LEN=308 >> [root at ipa2 log]# klist >> Ticket cache: FILE:/tmp/krb5cc_0 >> Default principal: admin at XYZ.DMZ >> Valid starting Expires Service principal >> 02/05/13 14:32:56 02/06/13 14:32:24 krbtgt/XYZ.DMZ at XYZ.DMZ >> 02/05/13 14:33:16 02/06/13 14:31:34 ldap/ipa2.xyz.dmz at XYZ.DMZ >> >> >> >> On Tue, Feb 5, 2013 at 7:45 PM, Rajnesh Kumar Siwal >> wrote: >>> Hi Rob, >>> >>> Thanks for the quick reply. >>> I tried logging iptables in the replica also, but no log for dropped packet :- >>> I would appreciate if you could please let me know what these login actually do. >>> 1. Looks to me as getting tgt for admin >>> 2. Is it trying to login though ssh to ipa1 server ? >>> ---------------------------------------------------------------------- >>> Get credentials to log in to remote master >>> admin at XYZ.DMZ password: >>> >>> Execute check on remote master >>> admin at ipa1.xyz.dmz's password: >>> ---------------------------------------------------------------------- >>> >>> SELINUX is disabled at both the ends. >>> >>> Is there any other log file that may suggest something. >>> It would be great if we could figure out whats the cause of the error. >>> ----------------------------------------------------------------------------------------------------------------------- >>> >>> On Tue, Feb 5, 2013 at 7:35 PM, Rob Crittenden wrote: >>>> Rajnesh Kumar Siwal wrote: >>>>> >>>>> We are trying to setup the IPA replication but it says "Connection >>>>> check failed!". >>>>> We disabled the firewall and found the same result. >>>>> >>>>> >>>>> ----------------------------------------------------------------------------------------------------------------------- >>>>> [root at ipa2 /]# ipa-replica-install -d --setup-ca --setup-dns >>>>> --forwarder 64.71.0.60 /var/lib/ipa/replica-info-ipa2.xyz.dmz.gpg >>>>> ipa : DEBUG /usr/sbin/ipa-replica-install was invoked with >>>>> argument "/var/lib/ipa/replica-info-ipa2.xyz.dmz.gpg" and options: >>>>> {'no_forwarders': False, 'conf_ssh': False, 'conf_sshd': False, >>>>> 'ui_redirect': True, 'reverse_zone': None, 'trust_sshfp': False, >>>>> 'unattended': False, 'no_host_dns': False, 'ip_address': None, >>>>> 'no_reverse': False, 'setup_dns': True, 'create_sshfp': True, >>>>> 'setup_ca': True, 'forwarders': [CheckedIPAddress('64.71.0.60')], >>>>> 'debug': True, 'conf_ntp': True, 'skip_conncheck': False} >>>>> ipa : DEBUG Loading Index file from >>>>> '/var/lib/ipa-client/sysrestore/sysrestore.index' >>>>> ipa : DEBUG Loading StateFile from >>>>> '/var/lib/ipa/sysrestore/sysrestore.state' >>>>> ipa : DEBUG Loading Index file from >>>>> '/var/lib/ipa/sysrestore/sysrestore.index' >>>>> Directory Manager (existing master) password: >>>>> >>>>> ipa : DEBUG args=/usr/bin/gpg --batch --homedir >>>>> /tmp/tmpRGaqDpipa/ipa-A3XOq7/.gnupg --passphrase-fd 0 --yes --no-tty >>>>> -o /tmp/tmpRGaqDpipa/files.tar -d >>>>> /var/lib/ipa/replica-info-ipa2.xyz.dmz.gpg >>>>> ipa : DEBUG stdout= >>>>> ipa : DEBUG stderr=gpg: WARNING: unsafe permissions on >>>>> homedir `/tmp/tmpRGaqDpipa/ipa-A3XOq7/.gnupg' >>>>> gpg: keyring `/tmp/tmpRGaqDpipa/ipa-A3XOq7/.gnupg/secring.gpg' created >>>>> gpg: keyring `/tmp/tmpRGaqDpipa/ipa-A3XOq7/.gnupg/pubring.gpg' created >>>>> gpg: 3DES encrypted data >>>>> gpg: encrypted with 1 passphrase >>>>> gpg: WARNING: message was not integrity protected >>>>> >>>>> ipa : DEBUG args=tar xf /tmp/tmpRGaqDpipa/files.tar -C >>>>> /tmp/tmpRGaqDpipa >>>>> ipa : DEBUG stdout= >>>>> ipa : DEBUG stderr= >>>>> Run connection check to master >>>>> Check connection from replica to remote master 'ipa1.xyz.dmz': >>>>> 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 >>>>> PKI-CA: Directory Service port (7389): 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 XYZ.DMZ password: >>>>> >>>>> Execute check on remote master >>>>> admin at ipa1.xyz.dmz's password: >>>>> >>>>> Remote master check failed with following error message(s): >>>>> >>>>> ipa : DEBUG args=/usr/sbin/ipa-replica-conncheck --master >>>>> ipa1.xyz.dmz --auto-master-check --realm XYZ.DMZ --principal admin >>>>> --hostname ipa2.xyz.dmz --check-ca >>>>> 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. >>>>> >>>>> -------------------------------------------------------------------------------------------------------------------------------------------------------------- >>>>> Please suggest >>>> >>>> >>>> Each server has its own iptables configuration. >>>> >>>> The test from the replica to the master succeeded. What failed is the >>>> connection test from the master to the replica, so I'd look at the iptables >>>> configuration on the replica machine. >>>> >>>> If that turns out ok it could be a false positive. You can add the >>>> --skip-conncheck to the ipa-replica-install command to skip this test. >>>> >>>> rob >>> >>> >>> >>> -- >>> Regards, >>> Rajnesh Kumar Siwal >> >> >> >> -- >> Regards, >> Rajnesh Kumar Siwal > > > > -- > Regards, > Rajnesh Kumar Siwal -- Regards, Rajnesh Kumar Siwal -------------- next part -------------- [root at ipa2 log]# /etc/init.d/iptables stop iptables: Flushing firewall rules: [ OK ] iptables: Setting chains to policy ACCEPT: filter [ OK ] iptables: Unloading modules: [ OK ] [root at ipa2 log]# setenforce 0 [root at ipa2 log]# kinit admin kinit: Cannot contact any KDC for realm 'XYZ.DMZ' while getting initial credentials [root at ipa2 log]# statce kinit admin -bash: statce: command not found [root at ipa2 log]# strace kinit admin execve("/usr/bin/kinit", ["kinit", "admin"], [/* 22 vars */]) = 0 brk(0) = 0x7fa389df2000 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa3881ad000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=32166, ...}) = 0 mmap(NULL, 32166, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fa3881a5000 close(3) = 0 open("/usr/lib64/libkadm5srv_mit.so.8", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340n\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=118512, ...}) = 0 mmap(NULL, 2255256, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fa387d68000 mprotect(0x7fa387d84000, 2093056, PROT_NONE) = 0 mmap(0x7fa387f83000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1b000) = 0x7fa387f83000 mmap(0x7fa387f85000, 39320, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fa387f85000 close(3) = 0 open("/usr/lib64/libkdb5.so.5", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340?\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=72888, ...}) = 0 mmap(NULL, 2168096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fa387b56000 mprotect(0x7fa387b67000, 2093056, PROT_NONE) = 0 mmap(0x7fa387d66000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x10000) = 0x7fa387d66000 close(3) = 0 open("/lib64/libgssrpc.so.4", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20X\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=131384, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa3881a4000 mmap(NULL, 2226952, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fa387936000 mprotect(0x7fa387954000, 2097152, PROT_NONE) = 0 mmap(0x7fa387b54000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1e000) = 0x7fa387b54000 close(3) = 0 open("/lib64/libgssapi_krb5.so.2", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0 \236\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=269472, ...}) = 0 mmap(NULL, 2365152, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fa3876f4000 mprotect(0x7fa387733000, 2097152, PROT_NONE) = 0 mmap(0x7fa387933000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3f000) = 0x7fa387933000 close(3) = 0 open("/lib64/libkrb5.so.3", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20\246\1\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=912944, ...}) = 0 mmap(NULL, 3008864, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fa387415000 mprotect(0x7fa3874e9000, 2097152, PROT_NONE) = 0 mmap(0x7fa3876e9000, 45056, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xd4000) = 0x7fa3876e9000 close(3) = 0 open("/lib64/libk5crypto.so.3", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\300G\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=178952, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa3881a3000 mmap(NULL, 2275296, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fa3871e9000 mprotect(0x7fa387213000, 2093056, PROT_NONE) = 0 mmap(0x7fa387412000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x29000) = 0x7fa387412000 close(3) = 0 open("/lib64/libcom_err.so.2", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360\23\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=14664, ...}) = 0 mmap(NULL, 2109872, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fa386fe5000 mprotect(0x7fa386fe8000, 2093056, PROT_NONE) = 0 mmap(0x7fa3871e7000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7fa3871e7000 close(3) = 0 open("/lib64/libkrb5support.so.0", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360(\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=43712, ...}) = 0 mmap(NULL, 2139184, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fa386dda000 mprotect(0x7fa386de4000, 2093056, PROT_NONE) = 0 mmap(0x7fa386fe3000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x9000) = 0x7fa386fe3000 close(3) = 0 open("/lib64/libkeyutils.so.1", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360\v\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=10192, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa3881a2000 mmap(NULL, 2105424, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fa386bd7000 mprotect(0x7fa386bd9000, 2093056, PROT_NONE) = 0 mmap(0x7fa386dd8000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1000) = 0x7fa386dd8000 close(3) = 0 open("/lib64/libresolv.so.2", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\00009\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=110960, ...}) = 0 mmap(NULL, 2202248, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fa3869bd000 mprotect(0x7fa3869d3000, 2097152, PROT_NONE) = 0 mmap(0x7fa386bd3000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x16000) = 0x7fa386bd3000 mmap(0x7fa386bd5000, 6792, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fa386bd5000 close(3) = 0 open("/lib64/libselinux.so.1", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0PX\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=122040, ...}) = 0 mmap(NULL, 2221912, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fa38679e000 mprotect(0x7fa3867bb000, 2093056, PROT_NONE) = 0 mmap(0x7fa3869ba000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1c000) = 0x7fa3869ba000 mmap(0x7fa3869bc000, 1880, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fa3869bc000 close(3) = 0 open("/lib64/libdl.so.2", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340\r\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=19536, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa3881a1000 mmap(NULL, 2109696, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fa38659a000 mprotect(0x7fa38659c000, 2097152, PROT_NONE) = 0 mmap(0x7fa38679c000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7fa38679c000 close(3) = 0 open("/lib64/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360\355\1\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=1916528, ...}) = 0 mmap(NULL, 3745960, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fa386207000 mprotect(0x7fa386390000, 2097152, PROT_NONE) = 0 mmap(0x7fa386590000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x189000) = 0x7fa386590000 mmap(0x7fa386595000, 18600, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fa386595000 close(3) = 0 open("/lib64/libpthread.so.0", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`\\\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=142464, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa3881a0000 mmap(NULL, 2212768, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fa385fea000 mprotect(0x7fa386001000, 2097152, PROT_NONE) = 0 mmap(0x7fa386201000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x17000) = 0x7fa386201000 mmap(0x7fa386203000, 13216, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fa386203000 close(3) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa38819f000 mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa38819d000 arch_prctl(ARCH_SET_FS, 0x7fa38819d7c0) = 0 mprotect(0x7fa386201000, 4096, PROT_READ) = 0 mprotect(0x7fa386590000, 16384, PROT_READ) = 0 mprotect(0x7fa38679c000, 4096, PROT_READ) = 0 mprotect(0x7fa3869ba000, 4096, PROT_READ) = 0 mprotect(0x7fa386bd3000, 4096, PROT_READ) = 0 mprotect(0x7fa386dd8000, 4096, PROT_READ) = 0 mprotect(0x7fa386fe3000, 4096, PROT_READ) = 0 mprotect(0x7fa3871e7000, 4096, PROT_READ) = 0 mprotect(0x7fa387412000, 8192, PROT_READ) = 0 mprotect(0x7fa3876e9000, 36864, PROT_READ) = 0 mprotect(0x7fa387933000, 4096, PROT_READ) = 0 mprotect(0x7fa387b54000, 4096, PROT_READ) = 0 mprotect(0x7fa387d66000, 4096, PROT_READ) = 0 mprotect(0x7fa387f83000, 4096, PROT_READ) = 0 mprotect(0x7fa3883b5000, 4096, PROT_READ) = 0 mprotect(0x7fa3881ae000, 4096, PROT_READ) = 0 munmap(0x7fa3881a5000, 32166) = 0 set_tid_address(0x7fa38819da90) = 21248 set_robust_list(0x7fa38819daa0, 0x18) = 0 futex(0x7fffa0ede8fc, FUTEX_WAKE_PRIVATE, 1) = 0 futex(0x7fffa0ede8fc, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 1, NULL, 7fa38819d7c0) = -1 EAGAIN (Resource temporarily unavailable) rt_sigaction(SIGRTMIN, {0x7fa385fefae0, [], SA_RESTORER|SA_SIGINFO, 0x7fa385ff9500}, NULL, 8) = 0 rt_sigaction(SIGRT_1, {0x7fa385fefb70, [], SA_RESTORER|SA_RESTART|SA_SIGINFO, 0x7fa385ff9500}, NULL, 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0 getrlimit(RLIMIT_STACK, {rlim_cur=10240*1024, rlim_max=RLIM_INFINITY}) = 0 statfs("/selinux", {f_type=0xf97cff8c, f_bsize=4096, f_blocks=0, f_bfree=0, f_bavail=0, f_files=0, f_ffree=0, f_fsid={0, 0}, f_namelen=255, f_frsize=4096}) = 0 brk(0) = 0x7fa389df2000 brk(0x7fa389e13000) = 0x7fa389e13000 ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0 ioctl(2, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0 futex(0x7fa386fe42e8, FUTEX_WAKE_PRIVATE, 2147483647) = 0 futex(0x7fa386fe4280, FUTEX_WAKE_PRIVATE, 2147483647) = 0 futex(0x7fa3876f3200, FUTEX_WAKE_PRIVATE, 2147483647) = 0 futex(0x7fa3876f3600, FUTEX_WAKE_PRIVATE, 2147483647) = 0 stat("/etc/krb5.conf", {st_mode=S_IFREG|0644, st_size=612, ...}) = 0 open("/etc/krb5.conf", O_RDONLY) = 3 fcntl(3, F_SETFD, FD_CLOEXEC) = 0 fstat(3, {st_mode=S_IFREG|0644, st_size=612, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa3881ac000 read(3, "[logging]\n default = FILE:/var/l"..., 4096) = 612 read(3, "", 4096) = 0 close(3) = 0 munmap(0x7fa3881ac000, 4096) = 0 open("/dev/urandom", O_RDONLY) = 3 fcntl(3, F_SETFD, FD_CLOEXEC) = 0 fstat(3, {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 9), ...}) = 0 read(3, "q3e\364\177\241_\34\357\343\325%\33\3072\203:\212\346\372", 20) = 20 close(3) = 0 futex(0x7fa3874142d0, FUTEX_WAKE_PRIVATE, 2147483647) = 0 getuid() = 0 open("/usr/lib64/krb5/plugins/preauth", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3 fcntl(3, F_GETFD) = 0x1 (flags FD_CLOEXEC) getdents(3, /* 4 entries */, 32768) = 128 stat("/usr/lib64/krb5/plugins/preauth/pkinit.so", {st_mode=S_IFREG|0755, st_size=116144, ...}) = 0 futex(0x7fa38679d0ec, FUTEX_WAKE_PRIVATE, 2147483647) = 0 open("/usr/lib64/krb5/plugins/preauth/pkinit.so", O_RDONLY) = 4 read(4, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240d\0\0\0\0\0\0"..., 832) = 832 fstat(4, {st_mode=S_IFREG|0755, st_size=116144, ...}) = 0 mmap(NULL, 2211544, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 4, 0) = 0x7fa385dce000 mprotect(0x7fa385de8000, 2097152, PROT_NONE) = 0 mmap(0x7fa385fe8000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 4, 0x1a000) = 0x7fa385fe8000 close(4) = 0 open("/etc/ld.so.cache", O_RDONLY) = 4 fstat(4, {st_mode=S_IFREG|0644, st_size=32166, ...}) = 0 mmap(NULL, 32166, PROT_READ, MAP_PRIVATE, 4, 0) = 0x7fa3881a5000 close(4) = 0 open("/usr/lib64/libcrypto.so.10", O_RDONLY) = 4 read(4, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\312\5\0\0\0\0\0"..., 832) = 832 fstat(4, {st_mode=S_IFREG|0755, st_size=1662832, ...}) = 0 mmap(NULL, 3773576, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 4, 0) = 0x7fa385a34000 mprotect(0x7fa385ba8000, 2093056, PROT_NONE) = 0 mmap(0x7fa385da7000, 143360, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 4, 0x173000) = 0x7fa385da7000 mmap(0x7fa385dca000, 13448, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fa385dca000 close(4) = 0 open("/lib64/libz.so.1", O_RDONLY) = 4 read(4, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0000\37\0\0\0\0\0\0"..., 832) = 832 fstat(4, {st_mode=S_IFREG|0755, st_size=88520, ...}) = 0 mmap(NULL, 2183696, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 4, 0) = 0x7fa38581e000 mprotect(0x7fa385833000, 2093056, PROT_NONE) = 0 mmap(0x7fa385a32000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 4, 0x14000) = 0x7fa385a32000 close(4) = 0 mprotect(0x7fa385a32000, 4096, PROT_READ) = 0 mprotect(0x7fa385da7000, 102400, PROT_READ) = 0 mprotect(0x7fa385fe8000, 4096, PROT_READ) = 0 munmap(0x7fa3881a5000, 32166) = 0 stat("/usr/lib64/krb5/plugins/preauth/encrypted_challenge.so", {st_mode=S_IFREG|0755, st_size=10616, ...}) = 0 open("/usr/lib64/krb5/plugins/preauth/encrypted_challenge.so", O_RDONLY) = 4 read(4, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0@\v\0\0\0\0\0\0"..., 832) = 832 fstat(4, {st_mode=S_IFREG|0755, st_size=10616, ...}) = 0 mmap(NULL, 2105704, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 4, 0) = 0x7fa38561b000 mprotect(0x7fa38561d000, 2093056, PROT_NONE) = 0 mmap(0x7fa38581c000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 4, 0x1000) = 0x7fa38581c000 close(4) = 0 mprotect(0x7fa38581c000, 4096, PROT_READ) = 0 getdents(3, /* 0 entries */, 32768) = 0 close(3) = 0 open("/proc/sys/crypto/fips_enabled", O_RDONLY) = 3 read(3, "0\n", 2) = 2 close(3) = 0 open("/etc/localtime", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=618, ...}) = 0 fstat(3, {st_mode=S_IFREG|0644, st_size=618, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa3881ac000 read(3, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1\0\0\0\1\0\0\0\31"..., 4096) = 618 lseek(3, -362, SEEK_CUR) = 256 read(3, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1\0\0\0\1\0\0\0\31"..., 4096) = 362 close(3) = 0 munmap(0x7fa3881ac000, 4096) = 0 open("/usr/lib64/krb5/plugins/libkrb5", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3 brk(0x7fa389e35000) = 0x7fa389e35000 getdents(3, /* 3 entries */, 32768) = 96 stat("/usr/lib64/krb5/plugins/libkrb5/sssd_krb5_locator_plugin.so", {st_mode=S_IFREG|0755, st_size=10888, ...}) = 0 open("/usr/lib64/krb5/plugins/libkrb5/sssd_krb5_locator_plugin.so", O_RDONLY) = 4 read(4, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0@\f\0\0\0\0\0\0"..., 832) = 832 fstat(4, {st_mode=S_IFREG|0755, st_size=10888, ...}) = 0 mmap(NULL, 2106120, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 4, 0) = 0x7fa385418000 mprotect(0x7fa38541a000, 2097152, PROT_NONE) = 0 mmap(0x7fa38561a000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 4, 0x2000) = 0x7fa38561a000 close(4) = 0 getdents(3, /* 0 entries */, 32768) = 0 close(3) = 0 open("/var/lib/sss/pubconf/kdcinfo.XYZ.DMZ", O_RDONLY) = -1 ENOENT (No such file or directory) socket(PF_NETLINK, SOCK_RAW, 0) = 3 bind(3, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 0 getsockname(3, {sa_family=AF_NETLINK, pid=21248, groups=00000000}, [12]) = 0 sendto(3, "\24\0\0\0\26\0\1\3\3776\21Q\0\0\0\0\0\0\0\0", 20, 0, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 20 recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"0\0\0\0\24\0\2\0\3776\21Q\0S\0\0\2\10\200\376\1\0\0\0\10\0\1\0\177\0\0\1"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 108 recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"@\0\0\0\24\0\2\0\3776\21Q\0S\0\0\n\200\200\376\1\0\0\0\24\0\1\0\0\0\0\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 128 recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"\24\0\0\0\3\0\2\0\3776\21Q\0S\0\0\0\0\0\0\1\0\0\0\24\0\1\0\0\0\0\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 20 close(3) = 0 socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3 connect(3, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory) close(3) = 0 socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3 connect(3, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory) close(3) = 0 open("/etc/nsswitch.conf", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=1698, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa3881ac000 read(3, "#\n# /etc/nsswitch.conf\n#\n# An ex"..., 4096) = 1698 read(3, "", 4096) = 0 close(3) = 0 munmap(0x7fa3881ac000, 4096) = 0 open("/etc/host.conf", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=9, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa3881ac000 read(3, "multi on\n", 4096) = 9 read(3, "", 4096) = 0 close(3) = 0 munmap(0x7fa3881ac000, 4096) = 0 futex(0x7fa386598384, FUTEX_WAKE_PRIVATE, 2147483647) = 0 open("/etc/resolv.conf", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=76, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa3881ac000 read(3, "search xyz.dmz\n#nameserv"..., 4096) = 76 read(3, "", 4096) = 0 close(3) = 0 munmap(0x7fa3881ac000, 4096) = 0 open("/etc/ld.so.cache", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=32166, ...}) = 0 mmap(NULL, 32166, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fa3881a5000 close(3) = 0 open("/lib64/libnss_files.so.2", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360!\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=65928, ...}) = 0 mmap(NULL, 2151824, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fa38520a000 mprotect(0x7fa385216000, 2097152, PROT_NONE) = 0 mmap(0x7fa385416000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xc000) = 0x7fa385416000 close(3) = 0 mprotect(0x7fa385416000, 4096, PROT_READ) = 0 munmap(0x7fa3881a5000, 32166) = 0 open("/etc/hosts", O_RDONLY|O_CLOEXEC) = 3 fcntl(3, F_GETFD) = 0x1 (flags FD_CLOEXEC) fstat(3, {st_mode=S_IFREG|0644, st_size=240, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa3881ac000 read(3, "127.0.0.1 localhost localhost."..., 4096) = 240 read(3, "", 4096) = 0 close(3) = 0 munmap(0x7fa3881ac000, 4096) = 0 open("/var/lib/sss/pubconf/kdcinfo.XYZ.DMZ", O_RDONLY) = -1 ENOENT (No such file or directory) socket(PF_NETLINK, SOCK_RAW, 0) = 3 bind(3, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 0 getsockname(3, {sa_family=AF_NETLINK, pid=21248, groups=00000000}, [12]) = 0 sendto(3, "\24\0\0\0\26\0\1\3\3776\21Q\0\0\0\0\0\0\0\0", 20, 0, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 20 recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"0\0\0\0\24\0\2\0\3776\21Q\0S\0\0\2\10\200\376\1\0\0\0\10\0\1\0\177\0\0\1"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 108 recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"@\0\0\0\24\0\2\0\3776\21Q\0S\0\0\n\200\200\376\1\0\0\0\24\0\1\0\0\0\0\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 128 recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"\24\0\0\0\3\0\2\0\3776\21Q\0S\0\0\0\0\0\0\1\0\0\0\24\0\1\0\0\0\0\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 20 close(3) = 0 open("/etc/hosts", O_RDONLY|O_CLOEXEC) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=240, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa3881ac000 read(3, "127.0.0.1 localhost localhost."..., 4096) = 240 read(3, "", 4096) = 0 close(3) = 0 munmap(0x7fa3881ac000, 4096) = 0 socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3 fcntl(3, F_SETFD, FD_CLOEXEC) = 0 connect(3, {sa_family=AF_INET, sin_port=htons(88), sin_addr=inet_addr("172.31.254.205")}, 16) = 0 sendto(3, "j\201\2670\201\264\241\3\2\1\5\242\3\2\1\n\243\0160\f0\n\241\4\2\2\0\225\242\2\4\0"..., 186, 0, NULL, 0) = 186 poll([{fd=3, events=POLLIN}], 1, 1000) = 1 ([{fd=3, revents=POLLERR}]) recvfrom(3, 0x7fa389e119b0, 4096, 0, 0, 0) = -1 ECONNREFUSED (Connection refused) close(3) = 0 socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3 fcntl(3, F_SETFD, FD_CLOEXEC) = 0 ioctl(3, FIONBIO, [1]) = 0 setsockopt(3, SOL_SOCKET, SO_LINGER, {onoff=0, linger=0}, 8) = 0 connect(3, {sa_family=AF_INET, sin_port=htons(88), sin_addr=inet_addr("172.31.254.205")}, 16) = -1 EINPROGRESS (Operation now in progress) poll([{fd=3, events=POLLIN|POLLOUT}], 1, 1000) = 1 ([{fd=3, revents=POLLIN|POLLERR|POLLHUP}]) close(3) = 0 close(4294967295) = -1 EBADF (Bad file descriptor) write(2, "kinit: Cannot contact any KDC fo"..., 58kinit: Cannot contact any KDC for realm 'XYZ.DMZ' ) = 58 write(2, "while getting initial credential"..., 33while getting initial credentials) = 33 write(2, "\n", 1 ) = 1 munmap(0x7fa385dce000, 2211544) = 0 munmap(0x7fa385a34000, 3773576) = 0 munmap(0x7fa38581e000, 2183696) = 0 munmap(0x7fa38561b000, 2105704) = 0 munmap(0x7fa385418000, 2106120) = 0 exit_group(1) = ? From rcritten at redhat.com Tue Feb 5 16:59:21 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 05 Feb 2013 11:59:21 -0500 Subject: [Freeipa-users] ipa replica install fails In-Reply-To: References: <5111118F.8010606@redhat.com> Message-ID: <51113A69.9040407@redhat.com> Rajnesh Kumar Siwal wrote: > Both of these replica are in the same network. > I have disabled the iptables on both > Selinux disable. > still the output of kinit admin is the same > kinit: Cannot contact any KDC for realm > > strace output attached. strace isn't really helpful in this case. Is the KDC running? You might want to check /var/log/krb5kdc.log to see what it says. rob > > > On Tue, Feb 5, 2013 at 9:45 PM, Rajnesh Kumar Siwal > wrote: >> Last time the installation of replica failed. So this is second time I >> did it (The logs in the mail are from the second time after I >> uninstalled the ipa2). >> >> After installing the replica, I restarted IPA and failed to start the KDC too. >> So, kinit admin is now failing. >> --------------------------------------------------------------------- >> >> [root at ipa2 log]# klist -ket /etc/named.keytab >> Keytab name: WRFILE:/etc/named.keytab >> KVNO Timestamp Principal >> ---- ----------------- -------------------------------------------------------- >> 2 02/05/13 14:30:26 DNS/ipa2.xyz.dmz at XYZ.DMZ (aes256-cts-hmac-sha1-96) >> 2 02/05/13 14:30:26 DNS/ipa2.xyz.dmz at XYZ.DMZ (aes128-cts-hmac-sha1-96) >> 2 02/05/13 14:30:26 DNS/ipa2.xyz.dmz at XYZ.DMZ (des3-cbc-sha1) >> 2 02/05/13 14:30:26 DNS/ipa2.xyz.dmz at XYZ.DMZ (arcfour-hmac) >> [root at ipa2 log]# kinit -kt DNS/ipa2.xyz.dmz at XYZ.DMZ >> kinit: Cannot contact any KDC for realm 'XYZ.DMZ' while getting >> initial credentials >> --------------------------------------------------------------------------------------------------------------- >> >> On Tue, Feb 5, 2013 at 8:15 PM, Rajnesh Kumar Siwal >> wrote: >>> Finally , I installed it with "--skip-conncheck":- >>> Now DNS fails to start. >>> I tried ipa-dns-install too:- >>> >>> [root at ipa2 log]# ipa-dns-install >>> The log file for this installation can be found in >>> /var/log/ipaserver-install.log >>> ============================================================================== >>> This program will setup DNS for the IPA Server. >>> >>> This includes: >>> * Configure DNS (bind) >>> >>> To accept the default shown in brackets, press the Enter key. >>> Existing BIND configuration detected, overwrite? [no]: yes >>> DNS is already configured in this IPA server. >>> [root at ipa2 log]# /etc/init.d/ipa status >>> Directory Service: RUNNING >>> KDC Service: RUNNING >>> KPASSWD Service: RUNNING >>> DNS Service: STOPPED >>> MEMCACHE Service: RUNNING >>> HTTP Service: RUNNING >>> CA Service: RUNNING >>> [root at ipa2 log]# /etc/init.d/named restart >>> Stopping named: [ OK ] >>> Starting named: [FAILED] >>> >>> --------------------------------------------------------------------------------------------- >>> DNS logs :- >>> Feb 5 09:40:19 ipa2 named[19873]: >>> ---------------------------------------------------- >>> Feb 5 09:40:19 ipa2 named[19873]: BIND 9 is maintained by Internet >>> Systems Consortium, >>> Feb 5 09:40:19 ipa2 named[19873]: Inc. (ISC), a non-profit 501(c)(3) >>> public-benefit >>> Feb 5 09:40:19 ipa2 named[19873]: corporation. Support and training >>> for BIND 9 are >>> Feb 5 09:40:19 ipa2 named[19873]: available at https://www.isc.org/support >>> Feb 5 09:40:19 ipa2 named[19873]: >>> ---------------------------------------------------- >>> Feb 5 09:40:19 ipa2 named[19873]: adjusted limit on open files from >>> 102400 to 1048576 >>> Feb 5 09:40:19 ipa2 named[19873]: found 2 CPUs, using 2 worker threads >>> Feb 5 09:40:19 ipa2 named[19873]: using up to 4096 sockets >>> Feb 5 09:40:19 ipa2 named[19873]: loading configuration from '/etc/named.conf' >>> Feb 5 09:40:19 ipa2 named[19873]: using default UDP/IPv4 port range: >>> [1024, 65535] >>> Feb 5 09:40:19 ipa2 named[19873]: using default UDP/IPv6 port range: >>> [1024, 65535] >>> Feb 5 09:40:19 ipa2 named[19873]: listening on IPv6 interfaces, port 53 >>> Feb 5 09:40:19 ipa2 named[19873]: listening on IPv4 interface lo, 127.0.0.1#53 >>> Feb 5 09:40:19 ipa2 named[19873]: listening on IPv4 interface eth0, >>> 172.31.254.205#53 >>> Feb 5 09:40:19 ipa2 named[19873]: generating session key for dynamic DNS >>> Feb 5 09:40:19 ipa2 named[19873]: sizing zone task pool based on 6 zones >>> Feb 5 09:40:19 ipa2 named[19873]: set up managed keys zone for view >>> _default, file 'dynamic/managed-keys.bind' >>> Feb 5 09:40:19 ipa2 named[19873]: GSSAPI Error: Unspecified GSS >>> failure. Minor code may provide more information (Mutual >>> authentication failed) >>> Feb 5 09:40:19 ipa2 named[19873]: bind to LDAP server failed: Local error >>> Feb 5 09:40:19 ipa2 named[19873]: loading configuration: failure >>> Feb 5 09:40:19 ipa2 named[19873]: exiting (due to fatal error) >>> Feb 5 09:40:28 ipa2 kernel: IN=eth0 OUT= >>> MAC=ff:ff:ff:ff:ff:ff:00:22:6b:12:99:bc:08:00 SRC=0.0.0.0 >>> DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=60 ID=0 PROTO=UDP >>> SPT=68 DPT=67 LEN=308 >>> [root at ipa2 log]# klist >>> Ticket cache: FILE:/tmp/krb5cc_0 >>> Default principal: admin at XYZ.DMZ >>> Valid starting Expires Service principal >>> 02/05/13 14:32:56 02/06/13 14:32:24 krbtgt/XYZ.DMZ at XYZ.DMZ >>> 02/05/13 14:33:16 02/06/13 14:31:34 ldap/ipa2.xyz.dmz at XYZ.DMZ >>> >>> >>> >>> On Tue, Feb 5, 2013 at 7:45 PM, Rajnesh Kumar Siwal >>> wrote: >>>> Hi Rob, >>>> >>>> Thanks for the quick reply. >>>> I tried logging iptables in the replica also, but no log for dropped packet :- >>>> I would appreciate if you could please let me know what these login actually do. >>>> 1. Looks to me as getting tgt for admin >>>> 2. Is it trying to login though ssh to ipa1 server ? >>>> ---------------------------------------------------------------------- >>>> Get credentials to log in to remote master >>>> admin at XYZ.DMZ password: >>>> >>>> Execute check on remote master >>>> admin at ipa1.xyz.dmz's password: >>>> ---------------------------------------------------------------------- >>>> >>>> SELINUX is disabled at both the ends. >>>> >>>> Is there any other log file that may suggest something. >>>> It would be great if we could figure out whats the cause of the error. >>>> ----------------------------------------------------------------------------------------------------------------------- >>>> >>>> On Tue, Feb 5, 2013 at 7:35 PM, Rob Crittenden wrote: >>>>> Rajnesh Kumar Siwal wrote: >>>>>> >>>>>> We are trying to setup the IPA replication but it says "Connection >>>>>> check failed!". >>>>>> We disabled the firewall and found the same result. >>>>>> >>>>>> >>>>>> ----------------------------------------------------------------------------------------------------------------------- >>>>>> [root at ipa2 /]# ipa-replica-install -d --setup-ca --setup-dns >>>>>> --forwarder 64.71.0.60 /var/lib/ipa/replica-info-ipa2.xyz.dmz.gpg >>>>>> ipa : DEBUG /usr/sbin/ipa-replica-install was invoked with >>>>>> argument "/var/lib/ipa/replica-info-ipa2.xyz.dmz.gpg" and options: >>>>>> {'no_forwarders': False, 'conf_ssh': False, 'conf_sshd': False, >>>>>> 'ui_redirect': True, 'reverse_zone': None, 'trust_sshfp': False, >>>>>> 'unattended': False, 'no_host_dns': False, 'ip_address': None, >>>>>> 'no_reverse': False, 'setup_dns': True, 'create_sshfp': True, >>>>>> 'setup_ca': True, 'forwarders': [CheckedIPAddress('64.71.0.60')], >>>>>> 'debug': True, 'conf_ntp': True, 'skip_conncheck': False} >>>>>> ipa : DEBUG Loading Index file from >>>>>> '/var/lib/ipa-client/sysrestore/sysrestore.index' >>>>>> ipa : DEBUG Loading StateFile from >>>>>> '/var/lib/ipa/sysrestore/sysrestore.state' >>>>>> ipa : DEBUG Loading Index file from >>>>>> '/var/lib/ipa/sysrestore/sysrestore.index' >>>>>> Directory Manager (existing master) password: >>>>>> >>>>>> ipa : DEBUG args=/usr/bin/gpg --batch --homedir >>>>>> /tmp/tmpRGaqDpipa/ipa-A3XOq7/.gnupg --passphrase-fd 0 --yes --no-tty >>>>>> -o /tmp/tmpRGaqDpipa/files.tar -d >>>>>> /var/lib/ipa/replica-info-ipa2.xyz.dmz.gpg >>>>>> ipa : DEBUG stdout= >>>>>> ipa : DEBUG stderr=gpg: WARNING: unsafe permissions on >>>>>> homedir `/tmp/tmpRGaqDpipa/ipa-A3XOq7/.gnupg' >>>>>> gpg: keyring `/tmp/tmpRGaqDpipa/ipa-A3XOq7/.gnupg/secring.gpg' created >>>>>> gpg: keyring `/tmp/tmpRGaqDpipa/ipa-A3XOq7/.gnupg/pubring.gpg' created >>>>>> gpg: 3DES encrypted data >>>>>> gpg: encrypted with 1 passphrase >>>>>> gpg: WARNING: message was not integrity protected >>>>>> >>>>>> ipa : DEBUG args=tar xf /tmp/tmpRGaqDpipa/files.tar -C >>>>>> /tmp/tmpRGaqDpipa >>>>>> ipa : DEBUG stdout= >>>>>> ipa : DEBUG stderr= >>>>>> Run connection check to master >>>>>> Check connection from replica to remote master 'ipa1.xyz.dmz': >>>>>> 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 >>>>>> PKI-CA: Directory Service port (7389): 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 XYZ.DMZ password: >>>>>> >>>>>> Execute check on remote master >>>>>> admin at ipa1.xyz.dmz's password: >>>>>> >>>>>> Remote master check failed with following error message(s): >>>>>> >>>>>> ipa : DEBUG args=/usr/sbin/ipa-replica-conncheck --master >>>>>> ipa1.xyz.dmz --auto-master-check --realm XYZ.DMZ --principal admin >>>>>> --hostname ipa2.xyz.dmz --check-ca >>>>>> 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. >>>>>> >>>>>> -------------------------------------------------------------------------------------------------------------------------------------------------------------- >>>>>> Please suggest >>>>> >>>>> >>>>> Each server has its own iptables configuration. >>>>> >>>>> The test from the replica to the master succeeded. What failed is the >>>>> connection test from the master to the replica, so I'd look at the iptables >>>>> configuration on the replica machine. >>>>> >>>>> If that turns out ok it could be a false positive. You can add the >>>>> --skip-conncheck to the ipa-replica-install command to skip this test. >>>>> >>>>> rob >>>> >>>> >>>> >>>> -- >>>> Regards, >>>> Rajnesh Kumar Siwal >>> >>> >>> >>> -- >>> Regards, >>> Rajnesh Kumar Siwal >> >> >> >> -- >> Regards, >> Rajnesh Kumar Siwal > > > From sailer at sailer.dynip.lugs.ch Tue Feb 5 17:11:32 2013 From: sailer at sailer.dynip.lugs.ch (Thomas Sailer) Date: Tue, 05 Feb 2013 18:11:32 +0100 Subject: [Freeipa-users] Upgrade to 3.1.2: web UI no longer works In-Reply-To: <511120CE.3010007@redhat.com> References: <51111CC8.7010502@sailer.dynip.lugs.ch> <511120CE.3010007@redhat.com> Message-ID: <51113D44.1040304@sailer.dynip.lugs.ch> Thanks, John! See the log below. The only thing that looks strange to me is expiration_timestamp=1970-01-01T01:00:00. Where does this time come from? Tom [Tue Feb 05 16:16:53.798117 2013] [:error] [pid 6843] ipa: INFO: *** PROCESS START *** [Tue Feb 05 16:16:53.914486 2013] [:error] [pid 6844] ipa: INFO: *** PROCESS START *** [Tue Feb 05 18:09:25.829937 2013] [:error] [pid 6843] ipa: DEBUG: WSGI wsgi_dispatch.__call__: [Tue Feb 05 18:09:25.830261 2013] [:error] [pid 6843] ipa: DEBUG: WSGI jsonserver_session.__call__: [Tue Feb 05 18:09:25.830910 2013] [:error] [pid 6843] ipa: DEBUG: found session cookie_id = bcc81ee57dd1b0dc068a6b049618dfa8 [Tue Feb 05 18:09:25.831823 2013] [:error] [pid 6843] ipa: DEBUG: no session data in cache with id=bcc81ee57dd1b0dc068a6b049618dfa8, generating empty session data [Tue Feb 05 18:09:25.832551 2013] [:error] [pid 6843] ipa: DEBUG: store session: session_id=bcc81ee57dd1b0dc068a6b049618dfa8 start_timestamp=2013-02-05T18:09:25 access_timestamp=2013-02-05T18:09:25 expiration_timestamp=1970-01-01T01:00:00 [Tue Feb 05 18:09:25.833104 2013] [:error] [pid 6843] ipa: DEBUG: jsonserver_session.__call__: session_id=bcc81ee57dd1b0dc068a6b049618dfa8 start_timestamp=2013-02-05T18:09:25 access_timestamp=2013-02-05T18:09:25 expiration_timestamp=1970-01-01T01:00:00 [Tue Feb 05 18:09:25.833325 2013] [:error] [pid 6843] ipa: DEBUG: no ccache, need login [Tue Feb 05 18:09:25.833472 2013] [:error] [pid 6843] ipa: DEBUG: jsonserver_session: 401 Unauthorized need login [Tue Feb 05 18:09:26.265310 2013] [:error] [pid 6844] ipa: DEBUG: WSGI wsgi_dispatch.__call__: [Tue Feb 05 18:09:26.265601 2013] [:error] [pid 6844] ipa: DEBUG: WSGI login_kerberos.__call__: [Tue Feb 05 18:09:26.266719 2013] [:error] [pid 6844] ipa: DEBUG: found session cookie_id = bcc81ee57dd1b0dc068a6b049618dfa8 [Tue Feb 05 18:09:26.268036 2013] [:error] [pid 6844] ipa: DEBUG: no session data in cache with id=bcc81ee57dd1b0dc068a6b049618dfa8, generating empty session data [Tue Feb 05 18:09:26.268517 2013] [:error] [pid 6844] ipa: DEBUG: store session: session_id=bcc81ee57dd1b0dc068a6b049618dfa8 start_timestamp=2013-02-05T18:09:26 access_timestamp=2013-02-05T18:09:26 expiration_timestamp=1970-01-01T01:00:00 [Tue Feb 05 18:09:26.269176 2013] [:error] [pid 6844] ipa: DEBUG: finalize_kerberos_acquisition: login_kerberos ccache_name="FILE:/run/httpd/krbcache/krb5cc_apache_MxFRBf" session_id="bcc81ee57dd1b0dc068a6b049618dfa8" [Tue Feb 05 18:09:26.269420 2013] [:error] [pid 6844] ipa: DEBUG: reading ccache data from file "/run/httpd/krbcache/krb5cc_apache_MxFRBf" [Tue Feb 05 18:09:26.271728 2013] [:error] [pid 6844] ipa: DEBUG: get_credential_times: principal=krbtgt/XXXX.COM at XXXX.COM, authtime=02/05/13 14:28:55, starttime=02/05/13 18:09:26, endtime=02/06/13 14:25:28, renew_till=01/01/70 01:00:00 [Tue Feb 05 18:09:26.272044 2013] [:error] [pid 6844] ipa: DEBUG: KRB5_CCache FILE:/run/httpd/krbcache/krb5cc_apache_MxFRBf endtime=1360157128 (02/06/13 14:25:28) [Tue Feb 05 18:09:26.272554 2013] [:error] [pid 6844] ipa: DEBUG: set_session_expiration_time: duration_type=inactivity_timeout duration=1200 max_age=1360156828 expiration=1360085366.27 (2013-02-05T18:29:26) [Tue Feb 05 18:09:26.272877 2013] [:error] [pid 6844] ipa: DEBUG: store session: session_id=bcc81ee57dd1b0dc068a6b049618dfa8 start_timestamp=2013-02-05T18:09:26 access_timestamp=2013-02-05T18:09:26 expiration_timestamp=2013-02-05T18:29:26 [Tue Feb 05 18:09:26.273477 2013] [:error] [pid 6844] ipa: DEBUG: release_ipa_ccache: KRB5CCNAME environment variable not set [Tue Feb 05 18:09:26.296615 2013] [:error] [pid 6843] ipa: DEBUG: WSGI wsgi_dispatch.__call__: [Tue Feb 05 18:09:26.297201 2013] [:error] [pid 6843] ipa: DEBUG: WSGI jsonserver_session.__call__: [Tue Feb 05 18:09:26.298296 2013] [:error] [pid 6843] ipa: DEBUG: found session cookie_id = bcc81ee57dd1b0dc068a6b049618dfa8 [Tue Feb 05 18:09:26.298995 2013] [:error] [pid 6843] ipa: DEBUG: no session data in cache with id=bcc81ee57dd1b0dc068a6b049618dfa8, generating empty session data [Tue Feb 05 18:09:26.299561 2013] [:error] [pid 6843] ipa: DEBUG: store session: session_id=bcc81ee57dd1b0dc068a6b049618dfa8 start_timestamp=2013-02-05T18:09:26 access_timestamp=2013-02-05T18:09:26 expiration_timestamp=1970-01-01T01:00:00 [Tue Feb 05 18:09:26.300515 2013] [:error] [pid 6843] ipa: DEBUG: jsonserver_session.__call__: session_id=bcc81ee57dd1b0dc068a6b049618dfa8 start_timestamp=2013-02-05T18:09:26 access_timestamp=2013-02-05T18:09:26 expiration_timestamp=1970-01-01T01:00:00 [Tue Feb 05 18:09:26.300903 2013] [:error] [pid 6843] ipa: DEBUG: no ccache, need login [Tue Feb 05 18:09:26.301258 2013] [:error] [pid 6843] ipa: DEBUG: jsonserver_session: 401 Unauthorized need login From jdennis at redhat.com Tue Feb 5 17:32:36 2013 From: jdennis at redhat.com (John Dennis) Date: Tue, 05 Feb 2013 12:32:36 -0500 Subject: [Freeipa-users] Upgrade to 3.1.2: web UI no longer works In-Reply-To: <51113D44.1040304@sailer.dynip.lugs.ch> References: <51111CC8.7010502@sailer.dynip.lugs.ch> <511120CE.3010007@redhat.com> <51113D44.1040304@sailer.dynip.lugs.ch> Message-ID: <51114234.9060606@redhat.com> On 02/05/2013 12:11 PM, Thomas Sailer wrote: > Thanks, John! > > See the log below. The only thing that looks strange to me is > expiration_timestamp=1970-01-01T01:00:00. Where does this time come from? That's the initial value of zero on the expiration timestamp, the beginning of the UNIX epoch, it's reset later, nothing to worry about here. Could you please check if ipa-memcached is running? The easiest way is with % ipactl status Also when you send log snippets could you either send them as a text attachment or via a pastebin, your mailer is wrapping the lines which makes it hard to read. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From pvoborni at redhat.com Tue Feb 5 17:47:27 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 05 Feb 2013 18:47:27 +0100 Subject: [Freeipa-users] Upgrade to 3.1.2: web UI no longer works In-Reply-To: <51111CC8.7010502@sailer.dynip.lugs.ch> References: <51111CC8.7010502@sailer.dynip.lugs.ch> Message-ID: <511145AF.6040200@redhat.com> On 02/05/2013 03:52 PM, Thomas Sailer wrote: > Hi, > > I've just upgraded from F16 to F18 and thus freeipa v3.1.2. > > It basically works, on the command line. ipa user-show xxx works. > > The Web UI however no longer works. I get the login window with "Your > session has expired. Please re-login.", no matter whether I use kerberos > or password login. > > The httpd logs don't seem to be very informative. > /var/cache/ipa/sessions/ is empty. > > Could someone point me to where I could find more information to debug > this problem? > > Thanks, > Tom > You can also look for unusual stuff on Web UI side. Open Web Console in browser (in FF: 'Tools/Web Developer/Web Console', in Chrome hit F12). First check if there are some JavaScript errors. Then check communication of authentication process - requests to 'ipa/session/login_password' and 'ipa/session/login_kerberos'). When password login fails, there should be filled http header named X-IPA-Rejection-Reason. If you manage to get session, check expiration of ipa_session cookie. -- Petr Vobornik From rajnesh.siwal at gmail.com Tue Feb 5 18:03:05 2013 From: rajnesh.siwal at gmail.com (Rajnesh Kumar Siwal) Date: Tue, 5 Feb 2013 23:33:05 +0530 Subject: [Freeipa-users] ipa replica install fails In-Reply-To: <51113A69.9040407@redhat.com> References: <5111118F.8010606@redhat.com> <51113A69.9040407@redhat.com> Message-ID: When I am trying to restart ipa, it fails to start the services to I manually started LDAP and krb5kdc, now kinit admin is fine :- How shall I proceed now ? ----------------------------------------------------------------------------- [root at ipa2 ~]# /etc/init.d/ipa status Directory Service: STOPPED Unknown error when retrieving list of services from LDAP: [Errno 111] Connection refused [root at ipa2 ~]# ipactl status Directory Service: STOPPED Unknown error when retrieving list of services from LDAP: [Errno 111] Connection refused [root at ipa2 ~]# /etc/init.d/dirsrv status dirsrv XYZ-DMZ is stopped dirsrv PKI-IPA is stopped [root at ipa2 ~]# /etc/init.d/dirsrv start Starting dirsrv: XYZ-DMZ... [ OK ] PKI-IPA... [ OK ] [root at ipa2 ~]# /etc/init.d/krb5kdc start Starting Kerberos 5 KDC: [ OK ] [root at ipa2 ~]# kinit admin Password for admin at XYX.DMZ: On Tue, Feb 5, 2013 at 10:29 PM, Rob Crittenden wrote: > Rajnesh Kumar Siwal wrote: >> >> Both of these replica are in the same network. >> I have disabled the iptables on both >> Selinux disable. >> still the output of kinit admin is the same >> kinit: Cannot contact any KDC for realm >> >> strace output attached. > > > strace isn't really helpful in this case. > > Is the KDC running? You might want to check /var/log/krb5kdc.log to see what > it says. > > rob > > >> >> >> On Tue, Feb 5, 2013 at 9:45 PM, Rajnesh Kumar Siwal >> wrote: >>> >>> Last time the installation of replica failed. So this is second time I >>> did it (The logs in the mail are from the second time after I >>> uninstalled the ipa2). >>> >>> After installing the replica, I restarted IPA and failed to start the KDC >>> too. >>> So, kinit admin is now failing. >>> --------------------------------------------------------------------- >>> >>> [root at ipa2 log]# klist -ket /etc/named.keytab >>> Keytab name: WRFILE:/etc/named.keytab >>> KVNO Timestamp Principal >>> ---- ----------------- >>> -------------------------------------------------------- >>> 2 02/05/13 14:30:26 DNS/ipa2.xyz.dmz at XYZ.DMZ >>> (aes256-cts-hmac-sha1-96) >>> 2 02/05/13 14:30:26 DNS/ipa2.xyz.dmz at XYZ.DMZ >>> (aes128-cts-hmac-sha1-96) >>> 2 02/05/13 14:30:26 DNS/ipa2.xyz.dmz at XYZ.DMZ (des3-cbc-sha1) >>> 2 02/05/13 14:30:26 DNS/ipa2.xyz.dmz at XYZ.DMZ (arcfour-hmac) >>> [root at ipa2 log]# kinit -kt DNS/ipa2.xyz.dmz at XYZ.DMZ >>> kinit: Cannot contact any KDC for realm 'XYZ.DMZ' while getting >>> initial credentials >>> >>> --------------------------------------------------------------------------------------------------------------- >>> >>> On Tue, Feb 5, 2013 at 8:15 PM, Rajnesh Kumar Siwal >>> wrote: >>>> >>>> Finally , I installed it with "--skip-conncheck":- >>>> Now DNS fails to start. >>>> I tried ipa-dns-install too:- >>>> >>>> [root at ipa2 log]# ipa-dns-install >>>> The log file for this installation can be found in >>>> /var/log/ipaserver-install.log >>>> >>>> ============================================================================== >>>> This program will setup DNS for the IPA Server. >>>> >>>> This includes: >>>> * Configure DNS (bind) >>>> >>>> To accept the default shown in brackets, press the Enter key. >>>> Existing BIND configuration detected, overwrite? [no]: yes >>>> DNS is already configured in this IPA server. >>>> [root at ipa2 log]# /etc/init.d/ipa status >>>> Directory Service: RUNNING >>>> KDC Service: RUNNING >>>> KPASSWD Service: RUNNING >>>> DNS Service: STOPPED >>>> MEMCACHE Service: RUNNING >>>> HTTP Service: RUNNING >>>> CA Service: RUNNING >>>> [root at ipa2 log]# /etc/init.d/named restart >>>> Stopping named: [ OK ] >>>> Starting named: [FAILED] >>>> >>>> >>>> --------------------------------------------------------------------------------------------- >>>> DNS logs :- >>>> Feb 5 09:40:19 ipa2 named[19873]: >>>> ---------------------------------------------------- >>>> Feb 5 09:40:19 ipa2 named[19873]: BIND 9 is maintained by Internet >>>> Systems Consortium, >>>> Feb 5 09:40:19 ipa2 named[19873]: Inc. (ISC), a non-profit 501(c)(3) >>>> public-benefit >>>> Feb 5 09:40:19 ipa2 named[19873]: corporation. Support and training >>>> for BIND 9 are >>>> Feb 5 09:40:19 ipa2 named[19873]: available at >>>> https://www.isc.org/support >>>> Feb 5 09:40:19 ipa2 named[19873]: >>>> ---------------------------------------------------- >>>> Feb 5 09:40:19 ipa2 named[19873]: adjusted limit on open files from >>>> 102400 to 1048576 >>>> Feb 5 09:40:19 ipa2 named[19873]: found 2 CPUs, using 2 worker threads >>>> Feb 5 09:40:19 ipa2 named[19873]: using up to 4096 sockets >>>> Feb 5 09:40:19 ipa2 named[19873]: loading configuration from >>>> '/etc/named.conf' >>>> Feb 5 09:40:19 ipa2 named[19873]: using default UDP/IPv4 port range: >>>> [1024, 65535] >>>> Feb 5 09:40:19 ipa2 named[19873]: using default UDP/IPv6 port range: >>>> [1024, 65535] >>>> Feb 5 09:40:19 ipa2 named[19873]: listening on IPv6 interfaces, port 53 >>>> Feb 5 09:40:19 ipa2 named[19873]: listening on IPv4 interface lo, >>>> 127.0.0.1#53 >>>> Feb 5 09:40:19 ipa2 named[19873]: listening on IPv4 interface eth0, >>>> 172.31.254.205#53 >>>> Feb 5 09:40:19 ipa2 named[19873]: generating session key for dynamic >>>> DNS >>>> Feb 5 09:40:19 ipa2 named[19873]: sizing zone task pool based on 6 >>>> zones >>>> Feb 5 09:40:19 ipa2 named[19873]: set up managed keys zone for view >>>> _default, file 'dynamic/managed-keys.bind' >>>> Feb 5 09:40:19 ipa2 named[19873]: GSSAPI Error: Unspecified GSS >>>> failure. Minor code may provide more information (Mutual >>>> authentication failed) >>>> Feb 5 09:40:19 ipa2 named[19873]: bind to LDAP server failed: Local >>>> error >>>> Feb 5 09:40:19 ipa2 named[19873]: loading configuration: failure >>>> Feb 5 09:40:19 ipa2 named[19873]: exiting (due to fatal error) >>>> Feb 5 09:40:28 ipa2 kernel: IN=eth0 OUT= >>>> MAC=ff:ff:ff:ff:ff:ff:00:22:6b:12:99:bc:08:00 SRC=0.0.0.0 >>>> DST=255.255.255.255 LEN=328 TOS=0x00 PREC=0x00 TTL=60 ID=0 PROTO=UDP >>>> SPT=68 DPT=67 LEN=308 >>>> [root at ipa2 log]# klist >>>> Ticket cache: FILE:/tmp/krb5cc_0 >>>> Default principal: admin at XYZ.DMZ >>>> Valid starting Expires Service principal >>>> 02/05/13 14:32:56 02/06/13 14:32:24 krbtgt/XYZ.DMZ at XYZ.DMZ >>>> 02/05/13 14:33:16 02/06/13 14:31:34 ldap/ipa2.xyz.dmz at XYZ.DMZ >>>> >>>> >>>> >>>> On Tue, Feb 5, 2013 at 7:45 PM, Rajnesh Kumar Siwal >>>> wrote: >>>>> >>>>> Hi Rob, >>>>> >>>>> Thanks for the quick reply. >>>>> I tried logging iptables in the replica also, but no log for dropped >>>>> packet :- >>>>> I would appreciate if you could please let me know what these login >>>>> actually do. >>>>> 1. Looks to me as getting tgt for admin >>>>> 2. Is it trying to login though ssh to ipa1 server ? >>>>> ---------------------------------------------------------------------- >>>>> Get credentials to log in to remote master >>>>> admin at XYZ.DMZ password: >>>>> >>>>> Execute check on remote master >>>>> admin at ipa1.xyz.dmz's password: >>>>> ---------------------------------------------------------------------- >>>>> >>>>> SELINUX is disabled at both the ends. >>>>> >>>>> Is there any other log file that may suggest something. >>>>> It would be great if we could figure out whats the cause of the error. >>>>> >>>>> ----------------------------------------------------------------------------------------------------------------------- >>>>> >>>>> On Tue, Feb 5, 2013 at 7:35 PM, Rob Crittenden >>>>> wrote: >>>>>> >>>>>> Rajnesh Kumar Siwal wrote: >>>>>>> >>>>>>> >>>>>>> We are trying to setup the IPA replication but it says "Connection >>>>>>> check failed!". >>>>>>> We disabled the firewall and found the same result. >>>>>>> >>>>>>> >>>>>>> >>>>>>> ----------------------------------------------------------------------------------------------------------------------- >>>>>>> [root at ipa2 /]# ipa-replica-install -d --setup-ca --setup-dns >>>>>>> --forwarder 64.71.0.60 /var/lib/ipa/replica-info-ipa2.xyz.dmz.gpg >>>>>>> ipa : DEBUG /usr/sbin/ipa-replica-install was invoked with >>>>>>> argument "/var/lib/ipa/replica-info-ipa2.xyz.dmz.gpg" and options: >>>>>>> {'no_forwarders': False, 'conf_ssh': False, 'conf_sshd': False, >>>>>>> 'ui_redirect': True, 'reverse_zone': None, 'trust_sshfp': False, >>>>>>> 'unattended': False, 'no_host_dns': False, 'ip_address': None, >>>>>>> 'no_reverse': False, 'setup_dns': True, 'create_sshfp': True, >>>>>>> 'setup_ca': True, 'forwarders': [CheckedIPAddress('64.71.0.60')], >>>>>>> 'debug': True, 'conf_ntp': True, 'skip_conncheck': False} >>>>>>> ipa : DEBUG Loading Index file from >>>>>>> '/var/lib/ipa-client/sysrestore/sysrestore.index' >>>>>>> ipa : DEBUG Loading StateFile from >>>>>>> '/var/lib/ipa/sysrestore/sysrestore.state' >>>>>>> ipa : DEBUG Loading Index file from >>>>>>> '/var/lib/ipa/sysrestore/sysrestore.index' >>>>>>> Directory Manager (existing master) password: >>>>>>> >>>>>>> ipa : DEBUG args=/usr/bin/gpg --batch --homedir >>>>>>> /tmp/tmpRGaqDpipa/ipa-A3XOq7/.gnupg --passphrase-fd 0 --yes --no-tty >>>>>>> -o /tmp/tmpRGaqDpipa/files.tar -d >>>>>>> /var/lib/ipa/replica-info-ipa2.xyz.dmz.gpg >>>>>>> ipa : DEBUG stdout= >>>>>>> ipa : DEBUG stderr=gpg: WARNING: unsafe permissions on >>>>>>> homedir `/tmp/tmpRGaqDpipa/ipa-A3XOq7/.gnupg' >>>>>>> gpg: keyring `/tmp/tmpRGaqDpipa/ipa-A3XOq7/.gnupg/secring.gpg' >>>>>>> created >>>>>>> gpg: keyring `/tmp/tmpRGaqDpipa/ipa-A3XOq7/.gnupg/pubring.gpg' >>>>>>> created >>>>>>> gpg: 3DES encrypted data >>>>>>> gpg: encrypted with 1 passphrase >>>>>>> gpg: WARNING: message was not integrity protected >>>>>>> >>>>>>> ipa : DEBUG args=tar xf /tmp/tmpRGaqDpipa/files.tar -C >>>>>>> /tmp/tmpRGaqDpipa >>>>>>> ipa : DEBUG stdout= >>>>>>> ipa : DEBUG stderr= >>>>>>> Run connection check to master >>>>>>> Check connection from replica to remote master 'ipa1.xyz.dmz': >>>>>>> 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 >>>>>>> PKI-CA: Directory Service port (7389): 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 XYZ.DMZ password: >>>>>>> >>>>>>> Execute check on remote master >>>>>>> admin at ipa1.xyz.dmz's password: >>>>>>> >>>>>>> Remote master check failed with following error message(s): >>>>>>> >>>>>>> ipa : DEBUG args=/usr/sbin/ipa-replica-conncheck --master >>>>>>> ipa1.xyz.dmz --auto-master-check --realm XYZ.DMZ --principal admin >>>>>>> --hostname ipa2.xyz.dmz --check-ca >>>>>>> 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. >>>>>>> >>>>>>> >>>>>>> -------------------------------------------------------------------------------------------------------------------------------------------------------------- >>>>>>> Please suggest >>>>>> >>>>>> >>>>>> >>>>>> Each server has its own iptables configuration. >>>>>> >>>>>> The test from the replica to the master succeeded. What failed is the >>>>>> connection test from the master to the replica, so I'd look at the >>>>>> iptables >>>>>> configuration on the replica machine. >>>>>> >>>>>> If that turns out ok it could be a false positive. You can add the >>>>>> --skip-conncheck to the ipa-replica-install command to skip this test. >>>>>> >>>>>> rob >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Regards, >>>>> Rajnesh Kumar Siwal >>>> >>>> >>>> >>>> >>>> -- >>>> Regards, >>>> Rajnesh Kumar Siwal >>> >>> >>> >>> >>> -- >>> Regards, >>> Rajnesh Kumar Siwal >> >> >> >> > -- Regards, Rajnesh Kumar Siwal From sailer at sailer.dynip.lugs.ch Tue Feb 5 18:40:48 2013 From: sailer at sailer.dynip.lugs.ch (Thomas Sailer) Date: Tue, 05 Feb 2013 19:40:48 +0100 Subject: [Freeipa-users] Upgrade to 3.1.2: web UI no longer works In-Reply-To: <51114234.9060606@redhat.com> References: <51111CC8.7010502@sailer.dynip.lugs.ch> <511120CE.3010007@redhat.com> <51113D44.1040304@sailer.dynip.lugs.ch> <51114234.9060606@redhat.com> Message-ID: <51115230.8010309@sailer.dynip.lugs.ch> On 02/05/2013 06:32 PM, John Dennis wrote: > % ipactl status # ipactl status Directory Service: RUNNING krb5kdc Service: RUNNING kadmin Service: RUNNING named Service: RUNNING httpd Service: RUNNING pki-cad Service: RUNNING ipa: INFO: The ipactl command was successful Apparently, it isn't... I've started it using: # systemctl restart ipa_memcached.service # systemctl enable ipa_memcached.service But still, it's not listed with ipactl status (systemctl says it started successfully) Now I'm getting "IPA Error 903". Thanks, Tom -------------- next part -------------- [Tue Feb 05 19:38:27.394919 2013] [:error] [pid 7520] ipa: INFO: *** PROCESS START *** [Tue Feb 05 19:38:27.410930 2013] [:error] [pid 7519] ipa: INFO: *** PROCESS START *** [Tue Feb 05 19:38:55.828540 2013] [:error] [pid 7520] ipa: DEBUG: WSGI wsgi_dispatch.__call__: [Tue Feb 05 19:38:55.829826 2013] [:error] [pid 7520] ipa: DEBUG: WSGI jsonserver_session.__call__: [Tue Feb 05 19:38:55.831338 2013] [:error] [pid 7520] ipa: DEBUG: found session cookie_id = bcc81ee57dd1b0dc068a6b049618dfa8 [Tue Feb 05 19:38:55.832468 2013] [:error] [pid 7520] ipa: DEBUG: found session data in cache with id=bcc81ee57dd1b0dc068a6b049618dfa8 [Tue Feb 05 19:38:55.852098 2013] [:error] [pid 7520] ipa: DEBUG: jsonserver_session.__call__: session_id=bcc81ee57dd1b0dc068a6b049618dfa8 start_timestamp=2013-02-05T19:34:48 access_timestamp=2013-02-05T19:38:55 expiration_timestamp=2013-02-05T19:57:31 [Tue Feb 05 19:38:55.853918 2013] [:error] [pid 7520] ipa: DEBUG: storing ccache data into file "/var/run/ipa_memcached/krbcc_7520" [Tue Feb 05 19:38:55.857797 2013] [:error] [pid 7520] ipa: DEBUG: get_credential_times: principal=krbtgt/XXXX.COM at XXXX.COM, authtime=02/05/13 14:28:55, starttime=02/05/13 19:34:48, endtime=02/06/13 14:25:28, renew_till=01/01/70 01:00:00 [Tue Feb 05 19:38:55.858643 2013] [:error] [pid 7520] ipa: DEBUG: get_credential_times: principal=krbtgt/XXXX.COM at XXXX.COM, authtime=02/05/13 14:28:55, starttime=02/05/13 19:34:48, endtime=02/06/13 14:25:28, renew_till=01/01/70 01:00:00 [Tue Feb 05 19:38:55.863192 2013] [:error] [pid 7520] ipa: DEBUG: KRB5_CCache FILE:/var/run/ipa_memcached/krbcc_7520 endtime=1360157128 (02/06/13 14:25:28) [Tue Feb 05 19:38:55.864570 2013] [:error] [pid 7520] ipa: DEBUG: set_session_expiration_time: duration_type=inactivity_timeout duration=1200 max_age=1360156828 expiration=1360090735.86 (2013-02-05T19:58:55) [Tue Feb 05 19:38:56.000067 2013] [:error] [pid 7520] ipa: DEBUG: Created connection context.ldap2 [Tue Feb 05 19:38:56.000523 2013] [:error] [pid 7520] ipa: DEBUG: WSGI jsonserver.__call__: [Tue Feb 05 19:38:56.000831 2013] [:error] [pid 7520] ipa: DEBUG: WSGI WSGIExecutioner.__call__: [Tue Feb 05 19:38:56.001809 2013] [:error] [pid 7520] ipa: DEBUG: raw: batch(({u'params': [[], {}], u'method': u'i18n_messages'}, {u'params': [[], {}], u'method': u'config_show'}, {u'params': [[], {u'all': True, u'whoami': True}], u'method': u'user_find'}, {u'params': [[], {}], u'method': u'env'}, {u'params': [[], {}], u'method': u'dns_is_enabled'})) [Tue Feb 05 19:38:56.002558 2013] [:error] [pid 7520] ipa: DEBUG: batch(({u'params': [[], {}], u'method': u'i18n_messages'}, {u'params': [[], {}], u'method': u'config_show'}, {u'params': [[], {u'all': True, u'whoami': True}], u'method': u'user_find'}, {u'params': [[], {}], u'method': u'env'}, {u'params': [[], {}], u'method': u'dns_is_enabled'})) [Tue Feb 05 19:38:56.003219 2013] [:error] [pid 7520] ipa: DEBUG: raw: i18n_messages() [Tue Feb 05 19:38:56.003633 2013] [:error] [pid 7520] ipa: DEBUG: i18n_messages() [Tue Feb 05 19:38:56.011433 2013] [:error] [pid 7520] ipa: INFO: user at XXXX.COM: batch: i18n_messages(): SUCCESS [Tue Feb 05 19:38:56.011971 2013] [:error] [pid 7520] ipa: DEBUG: raw: config_show() [Tue Feb 05 19:38:56.012526 2013] [:error] [pid 7520] ipa: DEBUG: config_show(rights=False, all=False, raw=False) [Tue Feb 05 19:38:56.016416 2013] [:error] [pid 7520] ipa: DEBUG: retrieving schema for SchemaCache url=ldapi://%2fvar%2frun%2fslapd-XXXX-COM.socket conn= [Tue Feb 05 19:38:56.322078 2013] [:error] [pid 7520] ipa: INFO: user at XXXX.COM: batch: config_show(): SUCCESS [Tue Feb 05 19:38:56.322640 2013] [:error] [pid 7520] ipa: DEBUG: raw: user_find(None, whoami=True, all=True) [Tue Feb 05 19:38:56.323390 2013] [:error] [pid 7520] ipa: DEBUG: user_find(None, whoami=True, all=True, raw=False, pkey_only=False) [Tue Feb 05 19:38:56.335920 2013] [:error] [pid 7520] ipa: DEBUG: get_memberof: entry_dn=uid=user,cn=users,cn=accounts,dc=xxxx,dc=com memberof=[ipapython.dn.DN('cn=admins,cn=groups,cn=accounts,dc=xxxx,dc=com'), ipapython.dn.DN('cn=Replication Administrators,cn=privileges,cn=pbac,dc=xxxx,dc=com'), ipapython.dn.DN('cn=Add Replication Agreements,cn=permissions,cn=pbac,dc=xxxx,dc=com'), ipapython.dn.DN('cn=Modify Replication Agreements,cn=permissions,cn=pbac,dc=xxxx,dc=com'), ipapython.dn.DN('cn=Remove Replication Agreements,cn=permissions,cn=pbac,dc=xxxx,dc=com'), ipapython.dn.DN('cn=Host Enrollment,cn=privileges,cn=pbac,dc=xxxx,dc=com'), ipapython.dn.DN('cn=Manage host keytab,cn=permissions,cn=pbac,dc=xxxx,dc=com'), ipapython.dn.DN('cn=Enroll a host,cn=permissions,cn=pbac,dc=xxxx,dc=com'), ipapython.dn.DN('cn=Add krbPrincipalName to a host,cn=permissions,cn=pbac,dc=xxxx,dc=com'), ipapython.dn.DN('cn=Unlock user accounts,cn=permissions,cn=pbac,dc=xxxx,dc=com'), ipapython.dn.DN('cn=Manage service keytab,cn=permissions,cn=pbac,dc=xxxx,dc=com'), ipapython.dn.DN('cn=ipausers,cn=groups,cn=accounts,dc=xxxx,dc=com'), ipapython.dn.DN('cn=domain admins,cn=groups,cn=accounts,dc=xxxx,dc=com'), ipapython.dn.DN('cn=domain users,cn=groups,cn=accounts,dc=xxxx,dc=com'), ipapython.dn.DN('cn=administrators,cn=groups,cn=accounts,dc=xxxx,dc=com')] [Tue Feb 05 19:38:56.357334 2013] [:error] [pid 7520] ipa: DEBUG: get_memberof: result direct=[ipapython.dn.DN('cn=admins,cn=groups,cn=accounts,dc=xxxx,dc=com'), ipapython.dn.DN('cn=ipausers,cn=groups,cn=accounts,dc=xxxx,dc=com'), ipapython.dn.DN('cn=domain admins,cn=groups,cn=accounts,dc=xxxx,dc=com'), ipapython.dn.DN('cn=domain users,cn=groups,cn=accounts,dc=xxxx,dc=com'), ipapython.dn.DN('cn=administrators,cn=groups,cn=accounts,dc=xxxx,dc=com')] indirect=[ipapython.dn.DN('cn=Replication Administrators,cn=privileges,cn=pbac,dc=xxxx,dc=com'), ipapython.dn.DN('cn=Add Replication Agreements,cn=permissions,cn=pbac,dc=xxxx,dc=com'), ipapython.dn.DN('cn=Modify Replication Agreements,cn=permissions,cn=pbac,dc=xxxx,dc=com'), ipapython.dn.DN('cn=Remove Replication Agreements,cn=permissions,cn=pbac,dc=xxxx,dc=com'), ipapython.dn.DN('cn=Host Enrollment,cn=privileges,cn=pbac,dc=xxxx,dc=com'), ipapython.dn.DN('cn=Manage host keytab,cn=permissions,cn=pbac,dc=xxxx,dc=com'), ipapython.dn.DN('cn=Enroll a host,cn=permissions,cn=pbac,dc=xxxx,dc=com'), ipapython.dn.DN('cn=Add krbPrincipalName to a host,cn=permissions,cn=pbac,dc=xxxx,dc=com'), ipapython.dn.DN('cn=Unlock user accounts,cn=permissions,cn=pbac,dc=xxxx,dc=com'), ipapython.dn.DN('cn=Manage service keytab,cn=permissions,cn=pbac,dc=xxxx,dc=com')] [Tue Feb 05 19:38:56.369686 2013] [:error] [pid 7520] ipa: INFO: user at XXXX.COM: batch: user_find(None, whoami=True, all=True): SUCCESS [Tue Feb 05 19:38:56.370010 2013] [:error] [pid 7520] ipa: DEBUG: raw: env(None) [Tue Feb 05 19:38:56.370285 2013] [:error] [pid 7520] ipa: DEBUG: env(None, server=False, all=True) [Tue Feb 05 19:38:56.370822 2013] [:error] [pid 7520] ipa: INFO: user at XXXX.COM: batch: env(None): SUCCESS [Tue Feb 05 19:38:56.371065 2013] [:error] [pid 7520] ipa: DEBUG: raw: dns_is_enabled() [Tue Feb 05 19:38:56.371253 2013] [:error] [pid 7520] ipa: DEBUG: dns_is_enabled() [Tue Feb 05 19:38:56.374367 2013] [:error] [pid 7520] ipa: INFO: user at XXXX.COM: batch: dns_is_enabled(): SUCCESS [Tue Feb 05 19:38:56.374978 2013] [:error] [pid 7520] ipa: INFO: user at XXXX.COM: batch(({u'params': [[], {}], u'method': u'i18n_messages'}, {u'params': [[], {}], u'method': u'config_show'}, {u'params': [[], {u'all': True, u'whoami': True}], u'method': u'user_find'}, {u'params': [[], {}], u'method': u'env'}, {u'params': [[], {}], u'method': u'dns_is_enabled'})): SUCCESS [Tue Feb 05 19:38:56.386777 2013] [:error] [pid 7520] ipa: DEBUG: reading ccache data from file "/var/run/ipa_memcached/krbcc_7520" [Tue Feb 05 19:38:56.387450 2013] [:error] [pid 7520] ipa: DEBUG: store session: session_id=bcc81ee57dd1b0dc068a6b049618dfa8 start_timestamp=2013-02-05T19:34:48 access_timestamp=2013-02-05T19:38:56 expiration_timestamp=2013-02-05T19:58:55 [Tue Feb 05 19:38:56.388829 2013] [:error] [pid 7520] ipa: DEBUG: Destroyed connection context.ldap2 [Tue Feb 05 19:38:56.435801 2013] [:error] [pid 7519] ipa: DEBUG: WSGI wsgi_dispatch.__call__: [Tue Feb 05 19:38:56.436182 2013] [:error] [pid 7519] ipa: DEBUG: WSGI jsonserver_session.__call__: [Tue Feb 05 19:38:56.436897 2013] [:error] [pid 7519] ipa: DEBUG: found session cookie_id = bcc81ee57dd1b0dc068a6b049618dfa8 [Tue Feb 05 19:38:56.437951 2013] [:error] [pid 7519] ipa: DEBUG: found session data in cache with id=bcc81ee57dd1b0dc068a6b049618dfa8 [Tue Feb 05 19:38:56.438451 2013] [:error] [pid 7519] ipa: DEBUG: jsonserver_session.__call__: session_id=bcc81ee57dd1b0dc068a6b049618dfa8 start_timestamp=2013-02-05T19:34:48 access_timestamp=2013-02-05T19:38:56 expiration_timestamp=2013-02-05T19:58:55 [Tue Feb 05 19:38:56.438673 2013] [:error] [pid 7519] ipa: DEBUG: storing ccache data into file "/var/run/ipa_memcached/krbcc_7519" [Tue Feb 05 19:38:56.440594 2013] [:error] [pid 7519] ipa: DEBUG: get_credential_times: principal=krbtgt/XXXX.COM at XXXX.COM, authtime=02/05/13 14:28:55, starttime=02/05/13 19:34:48, endtime=02/06/13 14:25:28, renew_till=01/01/70 01:00:00 [Tue Feb 05 19:38:56.441541 2013] [:error] [pid 7519] ipa: DEBUG: get_credential_times: principal=krbtgt/XXXX.COM at XXXX.COM, authtime=02/05/13 14:28:55, starttime=02/05/13 19:34:48, endtime=02/06/13 14:25:28, renew_till=01/01/70 01:00:00 [Tue Feb 05 19:38:56.441955 2013] [:error] [pid 7519] ipa: DEBUG: KRB5_CCache FILE:/var/run/ipa_memcached/krbcc_7519 endtime=1360157128 (02/06/13 14:25:28) [Tue Feb 05 19:38:56.442392 2013] [:error] [pid 7519] ipa: DEBUG: set_session_expiration_time: duration_type=inactivity_timeout duration=1200 max_age=1360156828 expiration=1360090736.44 (2013-02-05T19:58:56) [Tue Feb 05 19:38:56.466157 2013] [:error] [pid 7520] ipa: DEBUG: WSGI wsgi_dispatch.__call__: [Tue Feb 05 19:38:56.466577 2013] [:error] [pid 7520] ipa: DEBUG: WSGI jsonserver_session.__call__: [Tue Feb 05 19:38:56.467221 2013] [:error] [pid 7520] ipa: DEBUG: found session cookie_id = bcc81ee57dd1b0dc068a6b049618dfa8 [Tue Feb 05 19:38:56.467841 2013] [:error] [pid 7520] ipa: DEBUG: found session data in cache with id=bcc81ee57dd1b0dc068a6b049618dfa8 [Tue Feb 05 19:38:56.468299 2013] [:error] [pid 7520] ipa: DEBUG: jsonserver_session.__call__: session_id=bcc81ee57dd1b0dc068a6b049618dfa8 start_timestamp=2013-02-05T19:34:48 access_timestamp=2013-02-05T19:38:56 expiration_timestamp=2013-02-05T19:58:55 [Tue Feb 05 19:38:56.468595 2013] [:error] [pid 7520] ipa: DEBUG: storing ccache data into file "/var/run/ipa_memcached/krbcc_7520" [Tue Feb 05 19:38:56.469656 2013] [:error] [pid 7520] ipa: DEBUG: get_credential_times: principal=krbtgt/XXXX.COM at XXXX.COM, authtime=02/05/13 14:28:55, starttime=02/05/13 19:34:48, endtime=02/06/13 14:25:28, renew_till=01/01/70 01:00:00 [Tue Feb 05 19:38:56.470506 2013] [:error] [pid 7520] ipa: DEBUG: get_credential_times: principal=krbtgt/XXXX.COM at XXXX.COM, authtime=02/05/13 14:28:55, starttime=02/05/13 19:34:48, endtime=02/06/13 14:25:28, renew_till=01/01/70 01:00:00 [Tue Feb 05 19:38:56.470926 2013] [:error] [pid 7520] ipa: DEBUG: KRB5_CCache FILE:/var/run/ipa_memcached/krbcc_7520 endtime=1360157128 (02/06/13 14:25:28) [Tue Feb 05 19:38:56.471342 2013] [:error] [pid 7520] ipa: DEBUG: set_session_expiration_time: duration_type=inactivity_timeout duration=1200 max_age=1360156828 expiration=1360090736.47 (2013-02-05T19:58:56) [Tue Feb 05 19:38:56.591917 2013] [:error] [pid 7519] ipa: DEBUG: Created connection context.ldap2 [Tue Feb 05 19:38:56.592432 2013] [:error] [pid 7520] ipa: DEBUG: Created connection context.ldap2 [Tue Feb 05 19:38:56.592946 2013] [:error] [pid 7519] ipa: DEBUG: WSGI jsonserver.__call__: [Tue Feb 05 19:38:56.592995 2013] [:error] [pid 7520] ipa: DEBUG: WSGI jsonserver.__call__: [Tue Feb 05 19:38:56.593399 2013] [:error] [pid 7519] ipa: DEBUG: WSGI WSGIExecutioner.__call__: [Tue Feb 05 19:38:56.594329 2013] [:error] [pid 7520] ipa: DEBUG: WSGI WSGIExecutioner.__call__: [Tue Feb 05 19:38:56.595505 2013] [:error] [pid 7520] ipa: DEBUG: raw: json_metadata(None, None, command=u'all') [Tue Feb 05 19:38:56.595568 2013] [:error] [pid 7519] ipa: DEBUG: raw: json_metadata(None, None, object=u'all') [Tue Feb 05 19:38:56.596156 2013] [:error] [pid 7520] ipa: DEBUG: json_metadata(None, None, command=u'all') [Tue Feb 05 19:38:56.597081 2013] [:error] [pid 7519] ipa: DEBUG: json_metadata(None, None, object=u'all') [Tue Feb 05 19:38:56.602179 2013] [:error] [pid 7519] ipa: DEBUG: retrieving schema for SchemaCache url=ldapi://%2fvar%2frun%2fslapd-XXXX-COM.socket conn= [Tue Feb 05 19:38:57.108457 2013] [:error] [pid 7519] ipa: ERROR: non-public: KeyError: 'ipaExternalGroup' [Tue Feb 05 19:38:57.108702 2013] [:error] [pid 7519] Traceback (most recent call last): [Tue Feb 05 19:38:57.108791 2013] [:error] [pid 7519] File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 334, in wsgi_execute [Tue Feb 05 19:38:57.108881 2013] [:error] [pid 7519] result = self.Command[name](*args, **options) [Tue Feb 05 19:38:57.108973 2013] [:error] [pid 7519] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 435, in __call__ [Tue Feb 05 19:38:57.109191 2013] [:error] [pid 7519] ret = self.run(*args, **options) [Tue Feb 05 19:38:57.109454 2013] [:error] [pid 7519] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 747, in run [Tue Feb 05 19:38:57.109605 2013] [:error] [pid 7519] return self.execute(*args, **options) [Tue Feb 05 19:38:57.109696 2013] [:error] [pid 7519] File "/usr/lib/python2.7/site-packages/ipalib/plugins/internal.py", line 119, in execute [Tue Feb 05 19:38:57.109825 2013] [:error] [pid 7519] (o.name, json_serialize(o)) for o in self.api.Object() [Tue Feb 05 19:38:57.109914 2013] [:error] [pid 7519] File "/usr/lib/python2.7/site-packages/ipalib/plugins/internal.py", line 119, in [Tue Feb 05 19:38:57.110043 2013] [:error] [pid 7519] (o.name, json_serialize(o)) for o in self.api.Object() [Tue Feb 05 19:38:57.110178 2013] [:error] [pid 7519] File "/usr/lib/python2.7/site-packages/ipalib/util.py", line 56, in json_serialize [Tue Feb 05 19:38:57.110281 2013] [:error] [pid 7519] return json_serialize(obj.__json__()) [Tue Feb 05 19:38:57.110382 2013] [:error] [pid 7519] File "/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py", line 600, in __json__ [Tue Feb 05 19:38:57.110504 2013] [:error] [pid 7519] attrs = self.api.Backend.ldap2.schema.attribute_types(objectclasses) [Tue Feb 05 19:38:57.110604 2013] [:error] [pid 7519] File "/usr/lib64/python2.7/site-packages/ldap/schema/subentry.py", line 377, in attribute_types [Tue Feb 05 19:38:57.110713 2013] [:error] [pid 7519] object_class = self.sed[ObjectClass][object_class_oid] [Tue Feb 05 19:38:57.110801 2013] [:error] [pid 7519] KeyError: 'ipaExternalGroup' [Tue Feb 05 19:38:57.111401 2013] [:error] [pid 7519] ipa: INFO: user at XXXX.COM: json_metadata(None, None, object=u'all'): KeyError [Tue Feb 05 19:38:57.112574 2013] [:error] [pid 7519] ipa: DEBUG: reading ccache data from file "/var/run/ipa_memcached/krbcc_7519" [Tue Feb 05 19:38:57.113382 2013] [:error] [pid 7519] ipa: DEBUG: store session: session_id=bcc81ee57dd1b0dc068a6b049618dfa8 start_timestamp=2013-02-05T19:34:48 access_timestamp=2013-02-05T19:38:57 expiration_timestamp=2013-02-05T19:58:56 [Tue Feb 05 19:38:57.115977 2013] [:error] [pid 7519] ipa: DEBUG: Destroyed connection context.ldap2 [Tue Feb 05 19:38:57.504186 2013] [:error] [pid 7520] ipa: INFO: user at XXXX.COM: json_metadata(None, None, command=u'all'): SUCCESS [Tue Feb 05 19:38:57.700424 2013] [:error] [pid 7520] ipa: DEBUG: reading ccache data from file "/var/run/ipa_memcached/krbcc_7520" [Tue Feb 05 19:38:57.701086 2013] [:error] [pid 7520] ipa: DEBUG: store session: session_id=bcc81ee57dd1b0dc068a6b049618dfa8 start_timestamp=2013-02-05T19:34:48 access_timestamp=2013-02-05T19:38:57 expiration_timestamp=2013-02-05T19:58:56 [Tue Feb 05 19:38:57.702346 2013] [:error] [pid 7520] ipa: DEBUG: Destroyed connection context.ldap2 From sailer at sailer.dynip.lugs.ch Tue Feb 5 18:46:53 2013 From: sailer at sailer.dynip.lugs.ch (Thomas Sailer) Date: Tue, 05 Feb 2013 19:46:53 +0100 Subject: [Freeipa-users] Upgrade to 3.1.2: web UI no longer works In-Reply-To: <511145AF.6040200@redhat.com> References: <51111CC8.7010502@sailer.dynip.lugs.ch> <511145AF.6040200@redhat.com> Message-ID: <5111539D.6030602@sailer.dynip.lugs.ch> On 02/05/2013 06:47 PM, Petr Vobornik wrote: > Open Web Console in browser (in FF: 'Tools/Web Developer/Web Console', > in Chrome hit F12). I'm using firefox. I'm getting a javascript warning about getAttributeNode being deprecated, and some css complaints. The first post just gets one's own principal (which is correct), and i18 messages, the second post returns the Error 903... Tom From rcritten at redhat.com Tue Feb 5 19:02:57 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 05 Feb 2013 14:02:57 -0500 Subject: [Freeipa-users] Upgrade to 3.1.2: web UI no longer works In-Reply-To: <51115230.8010309@sailer.dynip.lugs.ch> References: <51111CC8.7010502@sailer.dynip.lugs.ch> <511120CE.3010007@redhat.com> <51113D44.1040304@sailer.dynip.lugs.ch> <51114234.9060606@redhat.com> <51115230.8010309@sailer.dynip.lugs.ch> Message-ID: <51115761.3050306@redhat.com> Thomas Sailer wrote: > On 02/05/2013 06:32 PM, John Dennis wrote: >> % ipactl status > # ipactl status > Directory Service: RUNNING > krb5kdc Service: RUNNING > kadmin Service: RUNNING > named Service: RUNNING > httpd Service: RUNNING > pki-cad Service: RUNNING > ipa: INFO: The ipactl command was successful > > Apparently, it isn't... > > I've started it using: > # systemctl restart ipa_memcached.service > # systemctl enable ipa_memcached.service > > But still, it's not listed with ipactl status (systemctl says it started > successfully) > > Now I'm getting "IPA Error 903". > > Thanks, > Tom 903 is a non-public error caused by the backtrace. Apparently something went awry with the upgrade which is why memcached isn't a configured service too. Can you see if you have 60basev3.ldif in /etc/dirsrv/slapd-YOUR-REALM/schema ? If not, stop dirsrv and copy it there from /usr/share/ipa/60basev3.ldif Restart dirsrv, try ipa user-show admin or something simple. You'll want to look at /var/log/ipaupgrade.log as well (it may be huge). rob From jdennis at redhat.com Tue Feb 5 19:09:37 2013 From: jdennis at redhat.com (John Dennis) Date: Tue, 05 Feb 2013 14:09:37 -0500 Subject: [Freeipa-users] Upgrade to 3.1.2: web UI no longer works In-Reply-To: <51115230.8010309@sailer.dynip.lugs.ch> References: <51111CC8.7010502@sailer.dynip.lugs.ch> <511120CE.3010007@redhat.com> <51113D44.1040304@sailer.dynip.lugs.ch> <51114234.9060606@redhat.com> <51115230.8010309@sailer.dynip.lugs.ch> Message-ID: <511158F1.6010508@redhat.com> On 02/05/2013 01:40 PM, Thomas Sailer wrote: > On 02/05/2013 06:32 PM, John Dennis wrote: >> % ipactl status > # ipactl status > Directory Service: RUNNING > krb5kdc Service: RUNNING > kadmin Service: RUNNING > named Service: RUNNING > httpd Service: RUNNING > pki-cad Service: RUNNING > ipa: INFO: The ipactl command was successful > > Apparently, it isn't... > > I've started it using: > # systemctl restart ipa_memcached.service > # systemctl enable ipa_memcached.service > > But still, it's not listed with ipactl status (systemctl says it started > successfully) > > Now I'm getting "IPA Error 903". > > Thanks, > Tom > The fact ipactl does not know about ipa-memcache indicates something went wrong with your upgrade, most likely related to ldap. We probably want to look in /var/log/ipaupgrade.log to see if there were problems. After manually starting ipa-memcached your log shows sessions are working correctly, that's good. That also means the ipa code was installed correctly, once again this points to an LDAP upgrade error, not an RPM install error. (FWIW ipactl reads LDAP to learn what services it has to run). Also, thank you very much for attaching the log, it's *much* easier to read :-) -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From sailer at sailer.dynip.lugs.ch Tue Feb 5 19:22:39 2013 From: sailer at sailer.dynip.lugs.ch (Thomas Sailer) Date: Tue, 05 Feb 2013 20:22:39 +0100 Subject: [Freeipa-users] Upgrade to 3.1.2: web UI no longer works In-Reply-To: <51115761.3050306@redhat.com> References: <51111CC8.7010502@sailer.dynip.lugs.ch> <511120CE.3010007@redhat.com> <51113D44.1040304@sailer.dynip.lugs.ch> <51114234.9060606@redhat.com> <51115230.8010309@sailer.dynip.lugs.ch> <51115761.3050306@redhat.com> Message-ID: <51115BFF.7080507@sailer.dynip.lugs.ch> On 02/05/2013 08:02 PM, Rob Crittenden wrote: > Can you see if you have 60basev3.ldif in > /etc/dirsrv/slapd-YOUR-REALM/schema ? That was indeed not there (only 60basev2.ldif). I've copied it, restarted dirsrv. ipa user-show admin works (it did work before though). > You'll want to look at /var/log/ipaupgrade.log as well (it may be huge). I reran ipa-upgradeconfig, there are a few errors; see the attachment. Seems to be mostly ldap errors; I don't know why named and pki-cad didn't restart, when I do that manually, they start fine. Thanks, Tom -------------- next part -------------- 2012-02-24 14:48:01,062 ERROR Update failed: Type or value exists: 2012-02-24 14:48:01,240 ERROR Add failure Object class violation: missing required attribute "objectclass" 2012-02-24 14:48:01,382 ERROR Add failure cn=anonymous-limits,cn=etc,dc=xxxx,dc=com 2012-02-24 14:48:01,392 ERROR Add failure cn=Managed Entries,cn=etc,dc=xxxx,dc=com 2012-02-24 14:48:01,447 ERROR Add failure Object class violation: missing required attribute "objectclass" 2012-02-24 14:48:01,510 ERROR Add failure cn=replication,cn=etc,dc=xxxx,dc=com 2012-02-24 14:48:01,515 ERROR Add failure cn=automember,cn=etc,dc=xxxx,dc=com 2012-02-24 14:48:01,544 ERROR Add failure cn=Templates,cn=Managed Entries,cn=etc,dc=xxxx,dc=com 2012-02-24 14:48:01,550 ERROR Add failure cn=Definitions,cn=Managed Entries,cn=etc,dc=xxxx,dc=com 2012-02-24 14:48:01,555 ERROR Add failure cn=replicas,cn=ipa,cn=etc,dc=xxxx,dc=com 2012-02-24 14:48:01,561 ERROR Add failure cn=Hostgroup,cn=automember,cn=etc,dc=xxxx,dc=com 2012-02-24 14:48:01,566 ERROR Add failure cn=Group,cn=automember,cn=etc,dc=xxxx,dc=com 2012-02-24 14:48:01,571 ERROR Add failure cn=Write IPA Configuration,cn=privileges,cn=pbac,dc=xxxx,dc=com 2012-02-24 14:48:01,577 ERROR Add failure cn=Write IPA Configuration,cn=permissions,cn=pbac,dc=xxxx,dc=com 2012-02-24 14:48:01,582 ERROR Add failure cn=Add HBAC rule,cn=permissions,cn=pbac,dc=xxxx,dc=com 2012-02-24 14:48:01,586 ERROR Add failure cn=Delete HBAC rule,cn=permissions,cn=pbac,dc=xxxx,dc=com 2012-02-24 14:48:01,592 ERROR Add failure cn=Modify HBAC rule,cn=permissions,cn=pbac,dc=xxxx,dc=com 2012-02-24 14:48:01,597 ERROR Add failure cn=Manage HBAC rule membership,cn=permissions,cn=pbac,dc=xxxx,dc=com 2012-02-24 14:48:01,602 ERROR Add failure cn=Add HBAC services,cn=permissions,cn=pbac,dc=xxxx,dc=com 2012-02-24 14:48:01,607 ERROR Add failure cn=Delete HBAC services,cn=permissions,cn=pbac,dc=xxxx,dc=com 2012-02-24 14:48:01,613 ERROR Add failure cn=Add HBAC service groups,cn=permissions,cn=pbac,dc=xxxx,dc=com 2012-02-24 14:48:01,618 ERROR Add failure cn=Delete HBAC service groups,cn=permissions,cn=pbac,dc=xxxx,dc=com 2012-02-24 14:48:01,623 ERROR Add failure cn=Manage HBAC service group membership,cn=permissions,cn=pbac,dc=xxxx,dc=com 2012-02-24 14:48:01,628 ERROR Add failure cn=HBAC Administrator,cn=privileges,cn=pbac,dc=xxxx,dc=com 2012-02-24 14:48:01,634 ERROR Add failure cn=Add Sudo rule,cn=permissions,cn=pbac,dc=xxxx,dc=com 2012-02-24 14:48:01,638 ERROR Add failure cn=Delete Sudo rule,cn=permissions,cn=pbac,dc=xxxx,dc=com 2012-02-24 14:48:01,643 ERROR Add failure cn=Modify Sudo rule,cn=permissions,cn=pbac,dc=xxxx,dc=com 2012-02-24 14:48:01,648 ERROR Add failure cn=Add Sudo command,cn=permissions,cn=pbac,dc=xxxx,dc=com 2012-02-24 14:48:01,654 ERROR Add failure cn=Delete Sudo command,cn=permissions,cn=pbac,dc=xxxx,dc=com 2012-02-24 14:48:01,659 ERROR Add failure cn=Modify Sudo command,cn=permissions,cn=pbac,dc=xxxx,dc=com 2012-02-24 14:48:01,664 ERROR Add failure cn=Add Sudo command group,cn=permissions,cn=pbac,dc=xxxx,dc=com 2012-02-24 14:48:01,669 ERROR Add failure cn=Delete Sudo command group,cn=permissions,cn=pbac,dc=xxxx,dc=com 2012-02-24 14:48:01,674 ERROR Add failure cn=Manage Sudo command group membership,cn=permissions,cn=pbac,dc=xxxx,dc=com 2012-02-24 14:48:01,679 ERROR Add failure cn=Sudo Administrator,cn=privileges,cn=pbac,dc=xxxx,dc=com 2012-02-24 14:48:01,684 ERROR Add failure cn=Add Group Password Policy costemplate,cn=permissions,cn=pbac,dc=xxxx,dc=com 2012-02-24 14:48:01,689 ERROR Add failure cn=Delete Group Password Policy costemplate,cn=permissions,cn=pbac,dc=xxxx,dc=com 2012-02-24 14:48:01,694 ERROR Add failure cn=Modify Group Password Policy costemplate,cn=permissions,cn=pbac,dc=xxxx,dc=com 2012-02-24 14:48:01,699 ERROR Add failure cn=Add Group Password Policy,cn=permissions,cn=pbac,dc=xxxx,dc=com 2012-02-24 14:48:01,704 ERROR Add failure cn=Delete Group Password Policy,cn=permissions,cn=pbac,dc=xxxx,dc=com 2012-02-24 14:48:01,710 ERROR Add failure cn=Modify Group Password Policy,cn=permissions,cn=pbac,dc=xxxx,dc=com 2012-02-24 14:48:01,715 ERROR Add failure cn=Password Policy Administrator,cn=privileges,cn=pbac,dc=xxxx,dc=com 2012-02-24 14:48:01,721 ERROR Add failure cn=Add krbPrincipalName to a host,cn=permissions,cn=pbac,dc=xxxx,dc=com 2012-02-24 14:48:01,813 ERROR Add failure Object class violation: missing required attribute "objectclass" 2012-02-24 14:48:01,825 ERROR Add failure cn=Modify Users and Reset passwords,cn=privileges,cn=pbac,dc=xxxx,dc=com 2012-02-24 14:48:01,874 ERROR Add failure Object class violation: missing required attribute "objectclass" 2012-02-24 14:48:01,919 ERROR Add failure Object class violation: missing required attribute "objectclass" 2012-02-24 14:48:01,925 ERROR Add failure cn=Modify Group membership,cn=privileges,cn=pbac,dc=xxxx,dc=com 2012-02-24 14:48:01,930 ERROR Add failure cn=User Administrator,cn=roles,cn=accounts,dc=xxxx,dc=com 2012-02-24 14:48:01,978 ERROR Add failure Object class violation: missing required attribute "objectclass" 2012-02-24 14:48:02,016 ERROR Add failure Object class violation: missing required attribute "objectclass" 2012-02-24 14:48:02,021 ERROR Add failure cn=IT Specialist,cn=roles,cn=accounts,dc=xxxx,dc=com 2012-02-24 14:48:02,066 ERROR Add failure Object class violation: missing required attribute "objectclass" 2012-02-24 14:48:02,111 ERROR Add failure Object class violation: missing required attribute "objectclass" 2012-02-24 14:48:02,144 ERROR Add failure Object class violation: missing required attribute "objectclass" 2012-02-24 14:48:02,178 ERROR Add failure Object class violation: missing required attribute "objectclass" 2012-02-24 14:48:02,183 ERROR Add failure cn=IT Security Specialist,cn=roles,cn=accounts,dc=xxxx,dc=com 2012-02-24 14:48:02,219 ERROR Add failure Object class violation: missing required attribute "objectclass" 2012-02-24 14:48:02,255 ERROR Add failure Object class violation: missing required attribute "objectclass" 2012-02-24 14:48:02,260 ERROR Add failure cn=Security Architect,cn=roles,cn=accounts,dc=xxxx,dc=com 2012-02-24 14:48:02,292 ERROR Add failure Object class violation: missing required attribute "objectclass" 2012-02-24 14:48:02,330 ERROR Add failure Object class violation: missing required attribute "objectclass" 2012-02-24 14:48:02,475 ERROR Add failure Object class violation: attribute "cn" not allowed 2012-02-24 14:48:02,517 ERROR Add failure Object class violation: attribute "cn" not allowed 2012-02-24 14:48:02,558 ERROR Add failure Object class violation: attribute "cn" not allowed 2012-02-24 14:48:02,569 ERROR Add failure cn=vsftpd,cn=hbacservices,cn=hbac,dc=xxxx,dc=com 2012-02-24 14:48:02,580 ERROR Add failure cn=proftpd,cn=hbacservices,cn=hbac,dc=xxxx,dc=com 2012-02-24 14:48:02,590 ERROR Add failure cn=pure-ftpd,cn=hbacservices,cn=hbac,dc=xxxx,dc=com 2012-02-24 14:48:02,601 ERROR Add failure cn=gssftp,cn=hbacservices,cn=hbac,dc=xxxx,dc=com 2012-02-24 14:48:02,612 ERROR Add failure cn=ftp,cn=hbacservicegroups,cn=hbac,dc=xxxx,dc=com 2012-02-24 14:48:02,620 ERROR Add failure cn=NGP HGP Template,cn=Templates,cn=Managed Entries,cn=etc,dc=xxxx,dc=com 2012-02-24 14:48:02,657 ERROR Add failure Server is unwilling to perform: Not a valid managed entries configuration entry. 2012-02-24 14:48:34,830 ERROR Add failure cn=UPG Template,cn=Templates,cn=Managed Entries,cn=etc,dc=xxxx,dc=com 2012-02-24 14:48:34,916 ERROR Add failure Server is unwilling to perform: Not a valid managed entries configuration entry. 2012-05-30 13:53:32,873 ERROR Update failed: Type or value exists: 2013-02-04T14:51:29Z ERROR Upgrade failed with Unable to connect to LDAP server ldapi://%2fvar%2frun%2fslapd-XXXX-COM.socket 2013-02-04T22:21:18Z ERROR Cannot connect to LDAP to add DNS records: cannot connect to u'ldapi://%2fvar%2frun%2fslapd-XXXX-COM.socket': LDAP Server Down 2013-02-04T22:21:18Z ERROR Failed to restart named: Command '/bin/systemctl restart named.service' returned non-zero exit status 1 2013-02-04T22:21:19Z ERROR Failed to restart pki-cad: Command '/bin/systemctl restart pki-cad at pki-ca.service' returned non-zero exit status 1 From rcritten at redhat.com Tue Feb 5 19:25:26 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 05 Feb 2013 14:25:26 -0500 Subject: [Freeipa-users] Upgrade to 3.1.2: web UI no longer works In-Reply-To: <51115BFF.7080507@sailer.dynip.lugs.ch> References: <51111CC8.7010502@sailer.dynip.lugs.ch> <511120CE.3010007@redhat.com> <51113D44.1040304@sailer.dynip.lugs.ch> <51114234.9060606@redhat.com> <51115230.8010309@sailer.dynip.lugs.ch> <51115761.3050306@redhat.com> <51115BFF.7080507@sailer.dynip.lugs.ch> Message-ID: <51115CA6.2010600@redhat.com> Thomas Sailer wrote: > On 02/05/2013 08:02 PM, Rob Crittenden wrote: >> Can you see if you have 60basev3.ldif in >> /etc/dirsrv/slapd-YOUR-REALM/schema ? > > That was indeed not there (only 60basev2.ldif). > > I've copied it, restarted dirsrv. > > ipa user-show admin works (it did work before though). > >> You'll want to look at /var/log/ipaupgrade.log as well (it may be huge). > > I reran ipa-upgradeconfig, there are a few errors; see the attachment. > > Seems to be mostly ldap errors; I don't know why named and pki-cad > didn't restart, when I do that manually, they start fine. > > Thanks, > Tom > > What version did you upgrade from in F-16? Can you send me the full ipupgrade.log privately? rob From rajnesh.siwal at gmail.com Wed Feb 6 04:57:10 2013 From: rajnesh.siwal at gmail.com (Rajnesh Kumar Siwal) Date: Wed, 6 Feb 2013 10:27:10 +0530 Subject: [Freeipa-users] ipa replica install fails In-Reply-To: References: <5111118F.8010606@redhat.com> <51113A69.9040407@redhat.com> Message-ID: Still unable to start bind :- [root at ipa2 ~]# ipa-replica-conncheck --replica ipa1.xyz.dmz Check connection from master to remote replica 'ipa1.xyz.dmz': Directory Service: Unsecure port (389): OK Directory Service: Secure port (636): OK Kerberos KDC: TCP (88): OK Kerberos KDC: UDP (88): WARNING Kerberos Kpasswd: TCP (464): OK Kerberos Kpasswd: UDP (464): WARNING HTTP Server: Unsecure port (80): OK HTTP Server: Secure port (443): OK The following UDP ports could not be verified as open: 88, 464 This can happen if they are already bound to an application and ipa-replica-conncheck cannot attach own UDP responder. Connection from master to replica is OK. [root at ipa2 ~]# ipactl status Directory Service: RUNNING KDC Service: RUNNING KPASSWD Service: RUNNING DNS Service: STOPPED MEMCACHE Service: STOPPED HTTP Service: RUNNING CA Service: STOPPED [root at ipa2 ~]# /etc/init.d/named restart Stopping named: [ OK ] Starting named: [FAILED] LOG:== Feb 5 23:53:34 ipa2 named[22084]: sizing zone task pool based on 6 zones Feb 5 23:53:34 ipa2 named[22084]: set up managed keys zone for view _default, file 'dynamic/managed-keys.bind' Feb 5 23:53:34 ipa2 named[22084]: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Mutual authentication failed) Feb 5 23:53:34 ipa2 named[22084]: bind to LDAP server failed: Local error Feb 5 23:53:34 ipa2 named[22084]: loading configuration: failure Feb 5 23:53:34 ipa2 named[22084]: exiting (due to fatal error) Feb 5 23:53:35 ipa2 sssd_be: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Mutual authentication failed) --------------------------------------------------------------------------------------------------------- [root at ipa1 ~]# ipa-replica-conncheck --replica ipa2.xyz.dmz Check connection from master to remote replica 'ipa2.xyz.dmz': Directory Service: Unsecure port (389): OK Directory Service: Secure port (636): OK Kerberos KDC: TCP (88): OK Kerberos KDC: UDP (88): WARNING Kerberos Kpasswd: TCP (464): OK Kerberos Kpasswd: UDP (464): WARNING HTTP Server: Unsecure port (80): OK HTTP Server: Secure port (443): OK The following UDP ports could not be verified as open: 88, 464 This can happen if they are already bound to an application and ipa-replica-conncheck cannot attach own UDP responder. Connection from master to replica is OK. [root at ipa1 ~]# From rajnesh.siwal at gmail.com Wed Feb 6 05:19:42 2013 From: rajnesh.siwal at gmail.com (Rajnesh Kumar Siwal) Date: Wed, 6 Feb 2013 10:49:42 +0530 Subject: [Freeipa-users] ipa replica install fails In-Reply-To: References: <5111118F.8010606@redhat.com> <51113A69.9040407@redhat.com> Message-ID: As a workaround I modified named.conf to use simple authentication and was able to start bind However I am looking for a better resolution. -------------------------------------------------------------------------------------------------------------- dynamic-db "ipa" { library "ldap.so"; arg "uri ldapi://%2fvar%2frun%2fslapd-XYZ-DMZ.socket"; arg "base cn=dns, dc=xyz,dc=dmz"; arg "fake_mname ipa2.xyz.dmz."; arg "auth_method simple"; arg "bind_dn cn=Directory Manager"; arg "password xxxxxxx"; #arg "auth_method sasl"; #arg "sasl_mech GSSAPI"; #arg "sasl_user DNS/ipa2.xyz.dmz"; arg "zone_refresh 30"; }; [root at ipa2 ~]# ipactl status Directory Service: RUNNING KDC Service: RUNNING KPASSWD Service: RUNNING DNS Service: RUNNING MEMCACHE Service: RUNNING HTTP Service: RUNNING CA Service: RUNNING --------------------------------------------------------------------- From rajnesh.siwal at gmail.com Wed Feb 6 05:29:25 2013 From: rajnesh.siwal at gmail.com (Rajnesh Kumar Siwal) Date: Wed, 6 Feb 2013 10:59:25 +0530 Subject: [Freeipa-users] ipa replica install fails In-Reply-To: References: <5111118F.8010606@redhat.com> <51113A69.9040407@redhat.com> Message-ID: Two more issues:- 1. I am still not able to login into the WebUI of ipa2 (Replica Server). It displays "Internal Server Error" 2. Are there any logs to make sure that the Replication is working fine ? From rajnesh.siwal at gmail.com Wed Feb 6 06:17:08 2013 From: rajnesh.siwal at gmail.com (Rajnesh Kumar Siwal) Date: Wed, 6 Feb 2013 11:47:08 +0530 Subject: [Freeipa-users] ipa replica install fails In-Reply-To: References: <5111118F.8010606@redhat.com> <51113A69.9040407@redhat.com> Message-ID: I am missing these two entries in ipa1 (The Master that was installed first):- HTTP/ipa2.xyz.dmz at XYZ.DMZ DNS/ipa2.xyz.dmz at XYZ.DMZ The above entries are present only in ipa2. From pspacek at redhat.com Wed Feb 6 08:30:18 2013 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 06 Feb 2013 09:30:18 +0100 Subject: [Freeipa-users] ipa replica install fails In-Reply-To: References: <5111118F.8010606@redhat.com> <51113A69.9040407@redhat.com> Message-ID: <5112149A.4060604@redhat.com> On 6.2.2013 07:17, Rajnesh Kumar Siwal wrote: > I am missing these two entries in ipa1 (The Master that was installed first):- > HTTP/ipa2.xyz.dmz at XYZ.DMZ > DNS/ipa2.xyz.dmz at XYZ.DMZ > > The above entries are present only in ipa2. It seems like replication problems to me. Did you already solved problems causing connection check failure? IPA will definitely not work if you do not solve these problems. Did you try to check what went wrong (with tcpdump)? Feel free to send the capture file to me privately. -- Petr^2 Spacek From rcritten at redhat.com Wed Feb 6 19:39:26 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 06 Feb 2013 14:39:26 -0500 Subject: [Freeipa-users] Java JSON Example -> IPA API In-Reply-To: References: Message-ID: <5112B16E.7010201@redhat.com> It Meme wrote: > Hi. > > Would be any online examples for calling the IPA JSON APIs from a java application? I gather from the lack of response that there aren't a lot of java users. Here is a sample of what a batch command would look like in json: {"method":"batch","params":[[ {"method":"user_show","params":[["admin"],{"all":true}]} ],{}],"id":1} You can see it in action with: $ curl -H "Content-Type:application/json" -H "Accept:application/json" -H "Referer: https://ipa.example.com/ipa/json" -H "Accept-Language:en" --negotiate -u : --cacert /etc/ipa/ca.crt -d @req.json https://ipa.example.com/ipa/json A simple user-show admin looks like: {"method":"user_show","params":[["admin"],{"all":true}]} How you do this in Java I have no idea. rob From fvzwieten at vxcompany.com Wed Feb 6 08:57:45 2013 From: fvzwieten at vxcompany.com (Fred van Zwieten) Date: Wed, 6 Feb 2013 09:57:45 +0100 Subject: [Freeipa-users] Howto use IPA for internal websites Message-ID: Hi, We have installed IPA in our internal network (let's call it example.com). We have all kinds of internal websites running for various administrative tasks. These websites are in all kind of subdomains of example.com. We would like to have them using a certificate signed by our CA. Some internal websites run on IPA-clients, some not. So, what is the exact workflow to make this happen? Also, our internal users must trust the IPA server as a Certificate Signing Authority. Users use both linux and windows clients and use various browsers on them. What is the procedure to have them trusting the IPA server as the CSA? Fred -------------- next part -------------- An HTML attachment was scrubbed... URL: From taaj.shawn at gmail.com Wed Feb 6 20:13:54 2013 From: taaj.shawn at gmail.com (Shawn) Date: Wed, 6 Feb 2013 15:13:54 -0500 Subject: [Freeipa-users] Testing out FreeIPA Message-ID: Is their any centos5/centos6 packages available? -- *- Shawn Taaj* -------------- next part -------------- An HTML attachment was scrubbed... URL: From christianh at 4over.com Wed Feb 6 20:40:21 2013 From: christianh at 4over.com (Christian Hernandez) Date: Wed, 6 Feb 2013 12:40:21 -0800 Subject: [Freeipa-users] Testing out FreeIPA In-Reply-To: References: Message-ID: IPA is in the default CentOS repos last I recall Thank you, Christian Hernandez 1225 Los Angeles Street Glendale, CA 91204 Phone: 877-782-2737 ext. 4566 Fax: 818-265-3152 christianh at 4over.com www.4over.com On Wed, Feb 6, 2013 at 12:13 PM, Shawn wrote: > Is their any centos5/centos6 packages available? > > -- > *- Shawn Taaj* > > _______________________________________________ > 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 sakodak at gmail.com Wed Feb 6 20:47:36 2013 From: sakodak at gmail.com (KodaK) Date: Wed, 6 Feb 2013 14:47:36 -0600 Subject: [Freeipa-users] Testing out FreeIPA In-Reply-To: References: Message-ID: On Wed, Feb 6, 2013 at 2:13 PM, Shawn wrote: > Is their any centos5/centos6 packages available? Yup. yum search ipa should show you them. I don't run Centos here, so I don't know if the packages are called ipa or freeipa. --Jason From sigbjorn at nixtra.com Wed Feb 6 20:56:54 2013 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Wed, 06 Feb 2013 21:56:54 +0100 Subject: [Freeipa-users] Testing out FreeIPA In-Reply-To: References: Message-ID: <5112C396.1080304@nixtra.com> On 02/06/2013 09:47 PM, KodaK wrote: > On Wed, Feb 6, 2013 at 2:13 PM, Shawn wrote: >> Is their any centos5/centos6 packages available? > > Yup. yum search ipa should show you them. I don't run Centos here, > so I don't know if the packages are called ipa or freeipa. > They are called ipa-* Just do "yum install ipa-server" and you'll get all the required packages. ipa-admintools-2.2.0-17.el6_3.1.x86_64 ipa-client-2.2.0-17.el6_3.1.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.2.0-17.el6_3.1.x86_64 ipa-server-2.2.0-17.el6_3.1.x86_64 ipa-server-selinux-2.2.0-17.el6_3.1.x86_64 Regards, Siggi From rcritten at redhat.com Wed Feb 6 20:26:44 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 06 Feb 2013 15:26:44 -0500 Subject: [Freeipa-users] Testing out FreeIPA In-Reply-To: References: Message-ID: <5112BC84.4030204@redhat.com> Shawn wrote: > Is their any centos5/centos6 packages available? Should be in the CentOS repositories. rob From rcritten at redhat.com Wed Feb 6 22:32:20 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 06 Feb 2013 17:32:20 -0500 Subject: [Freeipa-users] Howto use IPA for internal websites In-Reply-To: References: Message-ID: <5112D9F4.5080405@redhat.com> Fred van Zwieten wrote: > Hi, > > We have installed IPA in our internal network (let's call it example.com > ). > > We have all kinds of internal websites running for various > administrative tasks. These websites are in all kind of subdomains of > example.com . We would like to have them using a > certificate signed by our CA. > > Some internal websites run on IPA-clients, some not. > > So, what is the exact workflow to make this happen? A host doesn't need to be enrolled to get a certificate. You can just use host-add (or the UI) to create the host and potentiall whatever services you want certificates for (HTTP, ldap, whatever). Then generate a CSR on the host you want the cert for using your favorite crypto tools and pass that to ipa cert-request. The output of that is a signed public cert. You'll need the CA cert chain as well. It can be retrieved via the web from http://ipa.example.com/ipa/config/ca.crt. In 3.1 you can also get it over LDAP in cn=CAcert,cn=ipa,cn=etc,$SUFFIX in the cACertificate attribute. > Also, our internal users must trust the IPA server as a Certificate > Signing Authority. Users use both linux and windows clients and use > various browsers on them. What is the procedure to have them trusting > the IPA server as the CSA? You can visit the URI for the CA cert directly and you should be prompted to import and trust it in most browsers. rob From jreg2k at gmail.com Thu Feb 7 00:20:02 2013 From: jreg2k at gmail.com (James James) Date: Thu, 7 Feb 2013 01:20:02 +0100 Subject: [Freeipa-users] Account Expiration In-Reply-To: References: <5106A043.1070103@redhat.com> Message-ID: Can somebody gives me some help to set krbPrincipalExpiration from the freeipa ui ? Many thanks 2013/1/28 James James > Hi Martin, > thanks a lot for your answer. The krbPrincipalExpiration should do the job. > > Regards. > > > 2013/1/28 Martin Kosek > >> On 01/28/2013 12:14 PM, James James wrote: >> > Hi, in 389-ds there is a nice plugin I love, it's account policy. You >> can set >> > account expiration date and the account will be inactive at this day. >> > >> > >> http://directory.fedoraproject.org/wiki/Account_Policy_Design#Detailed_Design_of_Account_Expiration >> > >> > Is there a way to have this feature with freeipa ? >> > >> > Regards. >> > >> > >> > James >> > >> >> Hello James, >> >> FreeIPA user plugin does not support this feature, you would need to hack >> it in >> the plugin yourselves (patches welcome :-). >> >> Generally, you should be able to set account expiration to >> krbPrincipalExpiration attribute of the user account and it should just >> work. >> You can also check few tickets we have already few tickets filed for >> better >> handling of this attribute: >> >> https://fedorahosted.org/freeipa/ticket/3062 >> [RFE] Allow admins to change expiration attribute for the accounts >> >> https://fedorahosted.org/freeipa/ticket/3305 >> KrbPrincipalExpiration should be checked in pre-bind op >> >> https://fedorahosted.org/freeipa/ticket/3306 >> [RFE] Expose the krbPrincipalExpiration attribute for editing in the IPA >> CLI / >> WEBUI >> >> >> Anyway, if you want a support for this particular plugin, you can file an >> RFE >> to Trac/Bugzilla which we will further process. >> >> HTH, >> Martin >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Thu Feb 7 03:24:28 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 06 Feb 2013 22:24:28 -0500 Subject: [Freeipa-users] Account Expiration In-Reply-To: References: <5106A043.1070103@redhat.com> Message-ID: <51131E6C.7030103@redhat.com> James James wrote: > Can somebody gives me some help to set krbPrincipalExpiration from the > freeipa ui ? You can't set this in the web UI. You can do it from the command line using ldapmodify with: $ ldapmodify -x -D 'cn=Directory Manager' -W Enter LDAP Password: dn: uid=tuser1,cn=users,cn=accounts,dc=example,dc=com changetype: modify replace: krbPasswordExpiration krbPasswordExpiration: 20200508032114Z ^D rob > > Many thanks > > > 2013/1/28 James James > > > Hi Martin, > thanks a lot for your answer. The krbPrincipalExpiration should do > the job. > > Regards. > > > 2013/1/28 Martin Kosek > > > On 01/28/2013 12:14 PM, James James wrote: > > Hi, in 389-ds there is a nice plugin I love, it's account > policy. You can set > > account expiration date and the account will be inactive at > this day. > > > > > http://directory.fedoraproject.org/wiki/Account_Policy_Design#Detailed_Design_of_Account_Expiration > > > > Is there a way to have this feature with freeipa ? > > > > Regards. > > > > > > James > > > > Hello James, > > FreeIPA user plugin does not support this feature, you would > need to hack it in > the plugin yourselves (patches welcome :-). > > Generally, you should be able to set account expiration to > krbPrincipalExpiration attribute of the user account and it > should just work. > You can also check few tickets we have already few tickets filed > for better > handling of this attribute: > > https://fedorahosted.org/freeipa/ticket/3062 > [RFE] Allow admins to change expiration attribute for the accounts > > https://fedorahosted.org/freeipa/ticket/3305 > KrbPrincipalExpiration should be checked in pre-bind op > > https://fedorahosted.org/freeipa/ticket/3306 > [RFE] Expose the krbPrincipalExpiration attribute for editing in > the IPA CLI / > WEBUI > > > Anyway, if you want a support for this particular plugin, you > can file an RFE > to Trac/Bugzilla which we will further process. > > HTH, > Martin > > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > From jreg2k at gmail.com Thu Feb 7 07:31:52 2013 From: jreg2k at gmail.com (James James) Date: Thu, 7 Feb 2013 08:31:52 +0100 Subject: [Freeipa-users] Account Expiration In-Reply-To: <51131E6C.7030103@redhat.com> References: <5106A043.1070103@redhat.com> <51131E6C.7030103@redhat.com> Message-ID: Thanks Rob. I have one more question. Is it possible to add a field in the ui, and get the field's value in a custom add user hook script ? James 2013/2/7 Rob Crittenden > James James wrote: > >> Can somebody gives me some help to set krbPrincipalExpiration from the >> freeipa ui ? >> > > You can't set this in the web UI. > > You can do it from the command line using ldapmodify with: > > $ ldapmodify -x -D 'cn=Directory Manager' -W > Enter LDAP Password: > dn: uid=tuser1,cn=users,cn=**accounts,dc=example,dc=com > changetype: modify > replace: krbPasswordExpiration > krbPasswordExpiration: 20200508032114Z > > ^D > > rob > >> >> Many thanks >> >> >> 2013/1/28 James James > >> >> >> Hi Martin, >> thanks a lot for your answer. The krbPrincipalExpiration should do >> the job. >> >> Regards. >> >> >> 2013/1/28 Martin Kosek > >> >> >> On 01/28/2013 12:14 PM, James James wrote: >> > Hi, in 389-ds there is a nice plugin I love, it's account >> policy. You can set >> > account expiration date and the account will be inactive at >> this day. >> > >> > >> http://directory.**fedoraproject.org/wiki/** >> Account_Policy_Design#**Detailed_Design_of_Account_**Expiration >> > >> > Is there a way to have this feature with freeipa ? >> > >> > Regards. >> > >> > >> > James >> > >> >> Hello James, >> >> FreeIPA user plugin does not support this feature, you would >> need to hack it in >> the plugin yourselves (patches welcome :-). >> >> Generally, you should be able to set account expiration to >> krbPrincipalExpiration attribute of the user account and it >> should just work. >> You can also check few tickets we have already few tickets filed >> for better >> handling of this attribute: >> >> https://fedorahosted.org/**freeipa/ticket/3062 >> [RFE] Allow admins to change expiration attribute for the accounts >> >> https://fedorahosted.org/**freeipa/ticket/3305 >> KrbPrincipalExpiration should be checked in pre-bind op >> >> https://fedorahosted.org/**freeipa/ticket/3306 >> [RFE] Expose the krbPrincipalExpiration attribute for editing in >> the IPA CLI / >> WEBUI >> >> >> Anyway, if you want a support for this particular plugin, you >> can file an RFE >> to Trac/Bugzilla which we will further process. >> >> HTH, >> Martin >> >> >> >> >> >> ______________________________**_________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/**mailman/listinfo/freeipa-users >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Thu Feb 7 07:45:16 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 07 Feb 2013 08:45:16 +0100 Subject: [Freeipa-users] Account Expiration In-Reply-To: References: <5106A043.1070103@redhat.com> <51131E6C.7030103@redhat.com> Message-ID: <51135B8C.5070001@redhat.com> On 02/07/2013 08:31 AM, James James wrote: > Thanks Rob. I have one more question. Is it possible to add a field in the ui, > and get the field's value in a custom add user hook script ? > > James I know that Petr Vobornik is already working in better extensibility of the UI, but that would be available in future releases. Petr, do you have any advice for James for current release? > > > 2013/2/7 Rob Crittenden > > > James James wrote: > > Can somebody gives me some help to set krbPrincipalExpiration from the > freeipa ui ? > > > You can't set this in the web UI. Note: You will be able to set it in the CLI/UI when ticket https://fedorahosted.org/freeipa/ticket/3306 is fixed. > > You can do it from the command line using ldapmodify with: > > $ ldapmodify -x -D 'cn=Directory Manager' -W > Enter LDAP Password: > dn: uid=tuser1,cn=users,cn=__accounts,dc=example,dc=com > changetype: modify > replace: krbPasswordExpiration > krbPasswordExpiration: 20200508032114Z > > ^D This would change password expiration attribute. So for account expiration, you would just need to replace krbPasswordExpiration modification above with krbPrincipalExpiration. Martin From simo at redhat.com Thu Feb 7 13:48:59 2013 From: simo at redhat.com (Simo Sorce) Date: Thu, 07 Feb 2013 08:48:59 -0500 Subject: [Freeipa-users] Account Expiration In-Reply-To: References: <5106A043.1070103@redhat.com> <51131E6C.7030103@redhat.com> Message-ID: <1360244939.2299.3.camel@willson.li.ssimo.org> On Thu, 2013-02-07 at 08:31 +0100, James James wrote: > Thanks Rob. I have one more question. Is it possible to add a field in > the ui, and get the field's value in a custom add user hook script ? > It wouldn't be useful as you would not have permission to change it anyways. If you want to consistently have a different expiration time you should change the password policy. Simo. -- Simo Sorce * Red Hat, Inc * New York From pvoborni at redhat.com Thu Feb 7 14:16:25 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 07 Feb 2013 15:16:25 +0100 Subject: [Freeipa-users] Account Expiration In-Reply-To: <51135B8C.5070001@redhat.com> References: <5106A043.1070103@redhat.com> <51131E6C.7030103@redhat.com> <51135B8C.5070001@redhat.com> Message-ID: <5113B739.6090008@redhat.com> On 02/07/2013 08:45 AM, Martin Kosek wrote: > On 02/07/2013 08:31 AM, James James wrote: >> Thanks Rob. I have one more question. Is it possible to add a field in the ui, >> and get the field's value in a custom add user hook script ? >> >> James Theoretically it's possible but it requires quite good knowledge of Web UI code. It's easier to modify user page source codes. For simple edit (just textbox, no calendar widget) it may be just one line of code (in WebUI, server plugin will require more work). > > I know that Petr Vobornik is already working in better extensibility of the UI, > but that would be available in future releases. Petr, do you have any advice > for James for current release? > >> >> >> 2013/2/7 Rob Crittenden > >> >> James James wrote: >> >> Can somebody gives me some help to set krbPrincipalExpiration from the >> freeipa ui ? >> >> >> You can't set this in the web UI. > > Note: You will be able to set it in the CLI/UI when ticket > https://fedorahosted.org/freeipa/ticket/3306 > is fixed. > >> >> You can do it from the command line using ldapmodify with: >> >> $ ldapmodify -x -D 'cn=Directory Manager' -W >> Enter LDAP Password: >> dn: uid=tuser1,cn=users,cn=__accounts,dc=example,dc=com >> changetype: modify >> replace: krbPasswordExpiration >> krbPasswordExpiration: 20200508032114Z >> >> ^D > > This would change password expiration attribute. So for account expiration, you > would just need to replace krbPasswordExpiration modification above with > krbPrincipalExpiration. > > Martin > -- Petr Vobornik From jreg2k at gmail.com Thu Feb 7 18:02:56 2013 From: jreg2k at gmail.com (James James) Date: Thu, 7 Feb 2013 19:02:56 +0100 Subject: [Freeipa-users] Account Expiration In-Reply-To: <5113B739.6090008@redhat.com> References: <5106A043.1070103@redhat.com> <51131E6C.7030103@redhat.com> <51135B8C.5070001@redhat.com> <5113B739.6090008@redhat.com> Message-ID: ok thanks. 2013/2/7 Petr Vobornik > On 02/07/2013 08:45 AM, Martin Kosek wrote: > >> On 02/07/2013 08:31 AM, James James wrote: >> >>> Thanks Rob. I have one more question. Is it possible to add a field in >>> the ui, >>> and get the field's value in a custom add user hook script ? >>> >>> James >>> >> > Theoretically it's possible but it requires quite good knowledge of Web UI > code. It's easier to modify user page source codes. For simple edit (just > textbox, no calendar widget) it may be just one line of code (in WebUI, > server plugin will require more work). > > > >> I know that Petr Vobornik is already working in better extensibility of >> the UI, >> but that would be available in future releases. Petr, do you have any >> advice >> for James for current release? >> >> >>> >>> 2013/2/7 Rob Crittenden >> >> >>> >>> James James wrote: >>> >>> Can somebody gives me some help to set krbPrincipalExpiration >>> from the >>> freeipa ui ? >>> >>> >>> You can't set this in the web UI. >>> >> >> Note: You will be able to set it in the CLI/UI when ticket >> https://fedorahosted.org/**freeipa/ticket/3306 >> is fixed. >> >> >>> You can do it from the command line using ldapmodify with: >>> >>> $ ldapmodify -x -D 'cn=Directory Manager' -W >>> Enter LDAP Password: >>> dn: uid=tuser1,cn=users,cn=__**accounts,dc=example,dc=com >>> changetype: modify >>> replace: krbPasswordExpiration >>> krbPasswordExpiration: 20200508032114Z >>> >>> ^D >>> >> >> This would change password expiration attribute. So for account >> expiration, you >> would just need to replace krbPasswordExpiration modification above with >> krbPrincipalExpiration. >> >> Martin >> >> > -- > Petr Vobornik > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rajnesh.siwal at gmail.com Thu Feb 7 19:27:54 2013 From: rajnesh.siwal at gmail.com (Rajnesh Kumar Siwal) Date: Fri, 8 Feb 2013 00:57:54 +0530 Subject: [Freeipa-users] Adding an ipa-client behind NAT Message-ID: Does IPA server 2.2 supports the ipa clients authentication behind the NAT ? -- Regards, Rajnesh Kumar Siwal From Steven.Jones at vuw.ac.nz Thu Feb 7 19:46:40 2013 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Thu, 7 Feb 2013 19:46:40 +0000 Subject: [Freeipa-users] Service accounts and groups Message-ID: <833D8E48405E064EBC54C84EC6B36E4071081B5A@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, I have had little to do with permissions until now so bear with me if the Qs are obviously stupid, probably not really IPA but a linux blind spot I have....anyway, So I have a service account with its group this runs a database. So oracle with uid 2000 and gid 2000. I have some other users that need to be in the oracle user's group but I cant do that in IPA? So how do I get around that? Or am I approaching it totally wrong? I created a user group called oragrp gid 2001 but the user oracle is creating files with a uid of 2000 and gid of 2000 and not a gid of 2001 which I assume would fix it? regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 From simo at redhat.com Thu Feb 7 20:00:28 2013 From: simo at redhat.com (Simo Sorce) Date: Thu, 07 Feb 2013 15:00:28 -0500 Subject: [Freeipa-users] Adding an ipa-client behind NAT In-Reply-To: References: Message-ID: <1360267228.2299.12.camel@willson.li.ssimo.org> On Fri, 2013-02-08 at 00:57 +0530, Rajnesh Kumar Siwal wrote: > Does IPA server 2.2 supports the ipa clients authentication behind the NAT ? Authentication works, password changes using kpasswd protocol do not. Simo. -- Simo Sorce * Red Hat, Inc * New York From bcook at redhat.com Thu Feb 7 21:12:03 2013 From: bcook at redhat.com (Brian Cook) Date: Thu, 7 Feb 2013 13:12:03 -0800 Subject: [Freeipa-users] sync / trusts with multiple AD domains Message-ID: <27DE1DC0-BD8A-4397-BBFE-F35B0464091A@redhat.com> I know that syncing w/ AD has a limitation to one domain, or multiple but only if there are no overlapping accounts in the AD domains. Does the current AD trust implementation allow multiple domains, and does it have the same overlapping account issues? Thanks, Brian From sakodak at gmail.com Thu Feb 7 22:22:25 2013 From: sakodak at gmail.com (KodaK) Date: Thu, 7 Feb 2013 16:22:25 -0600 Subject: [Freeipa-users] Service accounts and groups In-Reply-To: <833D8E48405E064EBC54C84EC6B36E4071081B5A@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E4071081B5A@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: On Thu, Feb 7, 2013 at 1:46 PM, Steven Jones wrote: > Hi, > > I have had little to do with permissions until now so bear with me if the Qs are obviously stupid, probably not really IPA but a linux blind spot I have....anyway, > > So I have a service account with its group this runs a database. > > So oracle with uid 2000 and gid 2000. I have some other users that need to be in the oracle user's group but I cant do that in IPA? > Is oracle an IPA user and group or a local user and group? Assuming a Linux host and a local oracle user and group: you can add the IPA users to a local group and it will work. I have no idea if that's the "right" way to do it, though. > I created a user group called oragrp gid 2001 but the user oracle is creating files with a uid of 2000 and gid of 2000 and not a gid of 2001 which I assume would fix it? Again, if oracle is a local user, you can change his primary group using "usermod -G 2001 oracle" -- but you might as well just add the IPA users to the local oracle group. --Jason From jreg2k at gmail.com Thu Feb 7 23:35:30 2013 From: jreg2k at gmail.com (James James) Date: Fri, 8 Feb 2013 00:35:30 +0100 Subject: [Freeipa-users] ipa-replica-prepare failed Message-ID: Hi, today I wanted to install a ipa replica. When I used the ipa-replica-prepare command, I've got this error : [root at ipa ~]# ipa-replica-prepare ipa2-example.com Directory Manager (existing master) password: Preparing replica for ipa-EXAMPLE.COM from ipa.EXAMPLE.COM Creating SSL certificate for the Directory Server certutil: could not find certificate named "CN=EXAMPLE.COM Certificate Authority": security library: bad database. certutil: unable to create cert (security library: bad database.) preparation of replica failed: Command '/usr/bin/certutil -d /tmp/tmpoUpN72ipa/realm_info -A -n Server-Cert -t u,u,u -i /var/lib/ipa/ipa-6qKbha/tmpcert.der -f /tmp/tmpoUpN72ipa/realm_info/pwdfile.txt' returned non-zero exit status 255 Command '/usr/bin/certutil -d /tmp/tmpoUpN72ipa/realm_info -A -n Server-Cert -t u,u,u -i /var/lib/ipa/ipa-6qKbha/tmpcert.der -f /tmp/tmpoUpN72ipa/realm_info/pwdfile.txt' returned non-zero exit status 255 File "/usr/sbin/ipa-replica-prepare", line 459, in main() File "/usr/sbin/ipa-replica-prepare", line 345, in main export_certdb(api.env.realm, ds_dir, dir, passwd_fname, "dscert", replica_fqdn, subject_base) File "/usr/sbin/ipa-replica-prepare", line 143, in export_certdb raise e I have a certificate generated by a custom certificate authority in the ipa server. Regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steven.Jones at vuw.ac.nz Fri Feb 8 00:21:32 2013 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Fri, 8 Feb 2013 00:21:32 +0000 Subject: [Freeipa-users] Service accounts and groups In-Reply-To: References: <833D8E48405E064EBC54C84EC6B36E4071081B5A@STAWINCOX10MBX1.staff.vuw.ac.nz>, Message-ID: <833D8E48405E064EBC54C84EC6B36E4071081E4C@STAWINCOX10MBX1.staff.vuw.ac.nz> All users are IPA only 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 KodaK [sakodak at gmail.com] Sent: Friday, 8 February 2013 11:22 a.m. To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Service accounts and groups On Thu, Feb 7, 2013 at 1:46 PM, Steven Jones wrote: > Hi, > > I have had little to do with permissions until now so bear with me if the Qs are obviously stupid, probably not really IPA but a linux blind spot I have....anyway, > > So I have a service account with its group this runs a database. > > So oracle with uid 2000 and gid 2000. I have some other users that need to be in the oracle user's group but I cant do that in IPA? > Is oracle an IPA user and group or a local user and group? Assuming a Linux host and a local oracle user and group: you can add the IPA users to a local group and it will work. I have no idea if that's the "right" way to do it, though. > I created a user group called oragrp gid 2001 but the user oracle is creating files with a uid of 2000 and gid of 2000 and not a gid of 2001 which I assume would fix it? Again, if oracle is a local user, you can change his primary group using "usermod -G 2001 oracle" -- but you might as well just add the IPA users to the local oracle group. --Jason _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users From umarzuki at gmail.com Fri Feb 8 01:42:49 2013 From: umarzuki at gmail.com (Umarzuki Mochlis) Date: Fri, 8 Feb 2013 09:42:49 +0800 Subject: [Freeipa-users] creating group via CLI Message-ID: Hi, Is it possible to create groups and add users to that group via CLI? So far, I could not find any sample command on doing that. I'm using FreeIPA 3.1.0-2 on fc18 -- Regards, Umarzuki Mochlis http://debmal.my From jdennis at redhat.com Fri Feb 8 02:00:14 2013 From: jdennis at redhat.com (John Dennis) Date: Thu, 07 Feb 2013 21:00:14 -0500 Subject: [Freeipa-users] creating group via CLI In-Reply-To: References: Message-ID: <51145C2E.6020208@redhat.com> On 02/07/2013 08:42 PM, Umarzuki Mochlis wrote: > Hi, > > Is it possible to create groups and add users to that group via CLI? > So far, I could not find any sample command on doing that. The ipa CLI has help % ipa help user % ipa help group % ipa help user-add etc. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rajnesh.siwal at gmail.com Fri Feb 8 03:32:31 2013 From: rajnesh.siwal at gmail.com (Rajnesh Kumar Siwal) Date: Fri, 8 Feb 2013 09:02:31 +0530 Subject: [Freeipa-users] SOLVED: Re: Adding an ipa-client behind NAT Message-ID: Thanks, Simo. On Fri, Feb 8, 2013 at 1:30 AM, Simo Sorce wrote: > On Fri, 2013-02-08 at 00:57 +0530, Rajnesh Kumar Siwal wrote: >> Does IPA server 2.2 supports the ipa clients authentication behind the NAT ? > > Authentication works, password changes using kpasswd protocol do not. > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > -- Regards, Rajnesh Kumar Siwal From rajnesh.siwal at gmail.com Fri Feb 8 03:40:51 2013 From: rajnesh.siwal at gmail.com (Rajnesh Kumar Siwal) Date: Fri, 8 Feb 2013 09:10:51 +0530 Subject: [Freeipa-users] Does disabling IPA User disables his LDAP Account Also Message-ID: We are planning to use the IPA Server in the application that may not support Kerberos. So, we may have to interact with the LDAP Server (389-ds) directly for some applications. I would like to confirm whether disabling the IPA User (I believe it locks Kerberos Account) also disables his LDAP Account / Password. -- Regards, Rajnesh Kumar Siwal From rcritten at redhat.com Fri Feb 8 04:01:45 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 07 Feb 2013 23:01:45 -0500 Subject: [Freeipa-users] Does disabling IPA User disables his LDAP Account Also In-Reply-To: References: Message-ID: <511478A9.7050204@redhat.com> Rajnesh Kumar Siwal wrote: > We are planning to use the IPA Server in the application that may not > support Kerberos. > So, we may have to interact with the LDAP Server (389-ds) directly for > some applications. > I would like to confirm whether disabling the IPA User (I believe it > locks Kerberos Account) also disables his LDAP Account / Password. > It does. rob From rcritten at redhat.com Fri Feb 8 04:08:45 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 07 Feb 2013 23:08:45 -0500 Subject: [Freeipa-users] ipa-replica-prepare failed In-Reply-To: References: Message-ID: <51147A4D.8020508@redhat.com> James James wrote: > Hi, > today I wanted to install a ipa replica. When I used the > ipa-replica-prepare command, I've got this error : > > [root at ipa ~]# ipa-replica-prepare ipa2-example.com > Directory Manager (existing master) password: > > Preparing replica for ipa-EXAMPLE.COM from ipa.EXAMPLE.COM > > Creating SSL certificate for the Directory Server > certutil: could not find certificate named "CN=EXAMPLE.COM > Certificate Authority": security library: bad database. > certutil: unable to create cert (security library: bad database.) > preparation of replica failed: Command '/usr/bin/certutil -d > /tmp/tmpoUpN72ipa/realm_info -A -n Server-Cert -t u,u,u -i > /var/lib/ipa/ipa-6qKbha/tmpcert.der -f > /tmp/tmpoUpN72ipa/realm_info/pwdfile.txt' returned non-zero exit status 255 > Command '/usr/bin/certutil -d /tmp/tmpoUpN72ipa/realm_info -A -n > Server-Cert -t u,u,u -i /var/lib/ipa/ipa-6qKbha/tmpcert.der -f > /tmp/tmpoUpN72ipa/realm_info/pwdfile.txt' returned non-zero exit status 255 > File "/usr/sbin/ipa-replica-prepare", line 459, in > main() > > File "/usr/sbin/ipa-replica-prepare", line 345, in main > export_certdb(api.env.realm, ds_dir, dir, passwd_fname, "dscert", > replica_fqdn, subject_base) > > File "/usr/sbin/ipa-replica-prepare", line 143, in export_certdb > raise e > > > I have a certificate generated by a custom certificate authority in the > ipa server. Need more information on your installation. What version of IPA, what distro? Did you use ipa-server-certinstall to replace the default IPA certs? rob From rajnesh.siwal at gmail.com Fri Feb 8 04:12:53 2013 From: rajnesh.siwal at gmail.com (Rajnesh Kumar Siwal) Date: Fri, 8 Feb 2013 09:42:53 +0530 Subject: [Freeipa-users] SOLVED: Re: Does disabling IPA User disables his LDAP Account Also Message-ID: Thanks for the Quick update. On Fri, Feb 8, 2013 at 9:31 AM, Rob Crittenden wrote: > Rajnesh Kumar Siwal wrote: >> >> We are planning to use the IPA Server in the application that may not >> support Kerberos. >> So, we may have to interact with the LDAP Server (389-ds) directly for >> some applications. >> I would like to confirm whether disabling the IPA User (I believe it >> locks Kerberos Account) also disables his LDAP Account / Password. >> > > It does. > > rob -- Regards, Rajnesh Kumar Siwal From rajnesh.siwal at gmail.com Fri Feb 8 06:43:13 2013 From: rajnesh.siwal at gmail.com (Rajnesh Kumar Siwal) Date: Fri, 8 Feb 2013 12:13:13 +0530 Subject: [Freeipa-users] User Migrated from LDAP not able to change the password Message-ID: We migrated the users from openldap to IPA. We are getting the following error after the User has been migrated (after he changes the password through https://ipa1/ipa/migration/) and he tries to change passwd :- Account is not locked and Kerberos credentials seems to be present (created by ipa/migration) $ ssh siwal at 1.1.1.1 siwal at 172.31.254.204's password: Warning: Your password will expire in less than one hour. Password expired. Change your password now. Last login: Fri Feb 8 09:28:41 2013 from 1.1.1.2 WARNING: Your password has expired. You must change your password now and login again! Changing password for user siwal Current Password: passwd: Authentication token manipulation error Connection to 1.1.1.1 closed. -------------------------------------------------------------------------------- # ipa user-status siwal ----------------------- Account disabled: False ----------------------- Server: ipa1.xyz.dmz Failed logins: 0 Last successful authentication: 2013-02-08T03:59:29Z Last failed authentication: N/A Time now: 2013-02-08T06:40:18Z Server: ipa2.xyz.dmz Failed logins: 1 Last successful authentication: 2013-02-08T03:59:20Z Last failed authentication: 2013-02-08T03:59:33Z Time now: 2013-02-08T06:40:18Z ---------------------------- Number of entries returned 2 ---------------------------- # ipa user-show vinay User login: siwal Home directory: /home/siwal Login shell: /bin/bash UID: 522 GID: 522 Account disabled: False Password: True Kerberos keys available: True -- Regards, Rajnesh Kumar Siwal From jreg2k at gmail.com Fri Feb 8 07:11:41 2013 From: jreg2k at gmail.com (James James) Date: Fri, 8 Feb 2013 08:11:41 +0100 Subject: [Freeipa-users] ipa-replica-prepare failed In-Reply-To: <51147A4D.8020508@redhat.com> References: <51147A4D.8020508@redhat.com> Message-ID: My ipa version is ipa-server-2.2.0-17.el6_3.1.x86_64 and the distro is Scientific Linux 6.3. I have used ipa-server-certinstall to replace the default IPA certs. 2013/2/8 Rob Crittenden > James James wrote: > >> Hi, >> today I wanted to install a ipa replica. When I used the >> ipa-replica-prepare command, I've got this error : >> >> [root at ipa ~]# ipa-replica-prepare ipa2-example.com < >> http://ipa2-example.com> >> >> Directory Manager (existing master) password: >> >> Preparing replica for ipa-EXAMPLE.COM from ipa.EXAMPLE.COM >> >> >> Creating SSL certificate for the Directory Server >> certutil: could not find certificate named "CN=EXAMPLE.COM >> Certificate Authority": security library: bad >> database. >> >> certutil: unable to create cert (security library: bad database.) >> preparation of replica failed: Command '/usr/bin/certutil -d >> /tmp/tmpoUpN72ipa/realm_info -A -n Server-Cert -t u,u,u -i >> /var/lib/ipa/ipa-6qKbha/**tmpcert.der -f >> /tmp/tmpoUpN72ipa/realm_info/**pwdfile.txt' returned non-zero exit >> status 255 >> Command '/usr/bin/certutil -d /tmp/tmpoUpN72ipa/realm_info -A -n >> Server-Cert -t u,u,u -i /var/lib/ipa/ipa-6qKbha/**tmpcert.der -f >> /tmp/tmpoUpN72ipa/realm_info/**pwdfile.txt' returned non-zero exit >> status 255 >> File "/usr/sbin/ipa-replica-**prepare", line 459, in >> main() >> >> File "/usr/sbin/ipa-replica-**prepare", line 345, in main >> export_certdb(api.env.realm, ds_dir, dir, passwd_fname, "dscert", >> replica_fqdn, subject_base) >> >> File "/usr/sbin/ipa-replica-**prepare", line 143, in export_certdb >> raise e >> >> >> I have a certificate generated by a custom certificate authority in the >> ipa server. >> > > Need more information on your installation. What version of IPA, what > distro? > > Did you use ipa-server-certinstall to replace the default IPA certs? > > rob > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Fri Feb 8 07:44:12 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 08 Feb 2013 08:44:12 +0100 Subject: [Freeipa-users] User Migrated from LDAP not able to change the password In-Reply-To: References: Message-ID: <5114ACCC.6050604@redhat.com> On 02/08/2013 07:43 AM, Rajnesh Kumar Siwal wrote: > We migrated the users from openldap to IPA. > We are getting the following error after the User has been migrated > (after he changes the password through https://ipa1/ipa/migration/) > and he tries to change passwd :- > Account is not locked and Kerberos credentials seems to be present > (created by ipa/migration) > > $ ssh siwal at 1.1.1.1 > siwal at 172.31.254.204's password: > Warning: Your password will expire in less than one hour. > Password expired. Change your password now. > Last login: Fri Feb 8 09:28:41 2013 from 1.1.1.2 > WARNING: Your password has expired. > You must change your password now and login again! > Changing password for user siwal > Current Password: > passwd: Authentication token manipulation error > Connection to 1.1.1.1 closed. > -------------------------------------------------------------------------------- > # ipa user-status siwal > ----------------------- > Account disabled: False > ----------------------- > Server: ipa1.xyz.dmz > Failed logins: 0 > Last successful authentication: 2013-02-08T03:59:29Z > Last failed authentication: N/A > Time now: 2013-02-08T06:40:18Z > > Server: ipa2.xyz.dmz > Failed logins: 1 > Last successful authentication: 2013-02-08T03:59:20Z > Last failed authentication: 2013-02-08T03:59:33Z > Time now: 2013-02-08T06:40:18Z > ---------------------------- > Number of entries returned 2 > ---------------------------- > # ipa user-show vinay > User login: siwal > Home directory: /home/siwal > Login shell: /bin/bash > UID: 522 > GID: 522 > Account disabled: False > Password: True > Kerberos keys available: True > Hello Rajnesh, can you show your user password policy? # ipa pwpolicy-show I would be also interested to see full user record after the authentication failure: # ipa user-show siwal --all --raw krb* attributes and others may give us some hint what's wrong. Martin From mkosek at redhat.com Fri Feb 8 07:57:12 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 08 Feb 2013 08:57:12 +0100 Subject: [Freeipa-users] Service accounts and groups In-Reply-To: <833D8E48405E064EBC54C84EC6B36E4071081B5A@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E4071081B5A@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <5114AFD8.2050506@redhat.com> On 02/07/2013 08:46 PM, Steven Jones wrote: > Hi, > > I have had little to do with permissions until now so bear with me if the Qs are obviously stupid, probably not really IPA but a linux blind spot I have....anyway, > > So I have a service account with its group this runs a database. > > So oracle with uid 2000 and gid 2000. I have some other users that need to be in the oracle user's group but I cant do that in IPA? > > So how do I get around that? > > Or am I approaching it totally wrong? > > I created a user group called oragrp gid 2001 but the user oracle is creating files with a uid of 2000 and gid of 2000 and not a gid of 2001 which I assume would fix it? > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > Hello Steven, I assume you want to change oracle user primary GID, i.e. something like that: # ipa group-add oragrp --desc "Oracle Group" --gid 2001 -------------------- Added group "oragrp" -------------------- Group name: oragrp Description: Oracle Group GID: 2001 # ipa user-add --first Oracle --last User oracle --noprivate --uid 2000 --gidnumber 2001 ------------------- Added user "oracle" ------------------- User login: oracle First name: Oracle Last name: User Full name: Oracle User Display name: Oracle User Initials: OU Home directory: /home/oracle GECOS field: Oracle User Login shell: /bin/sh Kerberos principal: oracle at EXAMPLE.COM Email address: oracle at example.com UID: 2000 GID: 2001 Password: False Member of groups: ipausers Kerberos keys available: False # su oracle sh-4.2$ id uid=2000(oracle) gid=2001(oragrp) groups=2001(oragrp) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 $ touch /tmp/foo $ ls -la /tmp/foo -rw-r--r--. 1 oracle oragrp 0 Feb 8 02:28 /tmp/foo Martin From sbose at redhat.com Fri Feb 8 08:18:53 2013 From: sbose at redhat.com (Sumit Bose) Date: Fri, 8 Feb 2013 09:18:53 +0100 Subject: [Freeipa-users] sync / trusts with multiple AD domains In-Reply-To: <27DE1DC0-BD8A-4397-BBFE-F35B0464091A@redhat.com> References: <27DE1DC0-BD8A-4397-BBFE-F35B0464091A@redhat.com> Message-ID: <20130208081853.GA24753@localhost.localdomain> On Thu, Feb 07, 2013 at 01:12:03PM -0800, Brian Cook wrote: > I know that syncing w/ AD has a limitation to one domain, or multiple but only if there are no overlapping accounts in the AD domains. > > Does the current AD trust implementation allow multiple domains, and does it have the same overlapping account issues? Currently only one domain is supported but we are working on multiple domain support. What do you mean by 'overlapping accounts'? Accounts with the same name? Since we use fully qualified names, e.g. DOM\username or username at domain.name, there shouldn't be an overlap anymore. HTH bye, Sumit > > Thanks, > Brian > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From jreg2k at gmail.com Fri Feb 8 10:30:19 2013 From: jreg2k at gmail.com (James James) Date: Fri, 8 Feb 2013 11:30:19 +0100 Subject: [Freeipa-users] SOLVED Re: ipa-replica-prepare failed Message-ID: I had to set the --dirsrv_pkcs12, --dirsrv_pin, --http_pkcs12, --http_pin and the ipa-replica-prepare command runs without failure. Thanks for your help. 2013/2/8 James James > My ipa version is ipa-server-2.2.0-17.el6_3.1.x86_64 and the distro is > Scientific Linux 6.3. I have used ipa-server-certinstall to replace the > default IPA certs. > > > > > 2013/2/8 Rob Crittenden > >> James James wrote: >> >>> Hi, >>> today I wanted to install a ipa replica. When I used the >>> ipa-replica-prepare command, I've got this error : >>> >>> [root at ipa ~]# ipa-replica-prepare ipa2-example.com < >>> http://ipa2-example.com> >>> >>> Directory Manager (existing master) password: >>> >>> Preparing replica for ipa-EXAMPLE.COM from ipa.EXAMPLE.COM >>> >>> >>> Creating SSL certificate for the Directory Server >>> certutil: could not find certificate named "CN=EXAMPLE.COM >>> Certificate Authority": security library: bad >>> database. >>> >>> certutil: unable to create cert (security library: bad database.) >>> preparation of replica failed: Command '/usr/bin/certutil -d >>> /tmp/tmpoUpN72ipa/realm_info -A -n Server-Cert -t u,u,u -i >>> /var/lib/ipa/ipa-6qKbha/**tmpcert.der -f >>> /tmp/tmpoUpN72ipa/realm_info/**pwdfile.txt' returned non-zero exit >>> status 255 >>> Command '/usr/bin/certutil -d /tmp/tmpoUpN72ipa/realm_info -A -n >>> Server-Cert -t u,u,u -i /var/lib/ipa/ipa-6qKbha/**tmpcert.der -f >>> /tmp/tmpoUpN72ipa/realm_info/**pwdfile.txt' returned non-zero exit >>> status 255 >>> File "/usr/sbin/ipa-replica-**prepare", line 459, in >>> main() >>> >>> File "/usr/sbin/ipa-replica-**prepare", line 345, in main >>> export_certdb(api.env.realm, ds_dir, dir, passwd_fname, "dscert", >>> replica_fqdn, subject_base) >>> >>> File "/usr/sbin/ipa-replica-**prepare", line 143, in export_certdb >>> raise e >>> >>> >>> I have a certificate generated by a custom certificate authority in the >>> ipa server. >>> >> >> Need more information on your installation. What version of IPA, what >> distro? >> >> Did you use ipa-server-certinstall to replace the default IPA certs? >> >> rob >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jreg2k at gmail.com Fri Feb 8 10:58:29 2013 From: jreg2k at gmail.com (James James) Date: Fri, 8 Feb 2013 11:58:29 +0100 Subject: [Freeipa-users] ipa-replica-prepare failed In-Reply-To: References: <51147A4D.8020508@redhat.com> Message-ID: I had to set the --dirsrv_pkcs12, --dirsrv_pin, --http_pkcs12, --http_pin and the ipa-replica-prepare command runs without failure. Thanks for your help. 2013/2/8 James James > My ipa version is ipa-server-2.2.0-17.el6_3.1.x86_64 and the distro is > Scientific Linux 6.3. I have used ipa-server-certinstall to replace the > default IPA certs. > > > > > 2013/2/8 Rob Crittenden > >> James James wrote: >> >>> Hi, >>> today I wanted to install a ipa replica. When I used the >>> ipa-replica-prepare command, I've got this error : >>> >>> [root at ipa ~]# ipa-replica-prepare ipa2-example.com < >>> http://ipa2-example.com> >>> >>> Directory Manager (existing master) password: >>> >>> Preparing replica for ipa-EXAMPLE.COM from ipa.EXAMPLE.COM >>> >>> >>> Creating SSL certificate for the Directory Server >>> certutil: could not find certificate named "CN=EXAMPLE.COM >>> Certificate Authority": security library: bad >>> database. >>> >>> certutil: unable to create cert (security library: bad database.) >>> preparation of replica failed: Command '/usr/bin/certutil -d >>> /tmp/tmpoUpN72ipa/realm_info -A -n Server-Cert -t u,u,u -i >>> /var/lib/ipa/ipa-6qKbha/**tmpcert.der -f >>> /tmp/tmpoUpN72ipa/realm_info/**pwdfile.txt' returned non-zero exit >>> status 255 >>> Command '/usr/bin/certutil -d /tmp/tmpoUpN72ipa/realm_info -A -n >>> Server-Cert -t u,u,u -i /var/lib/ipa/ipa-6qKbha/**tmpcert.der -f >>> /tmp/tmpoUpN72ipa/realm_info/**pwdfile.txt' returned non-zero exit >>> status 255 >>> File "/usr/sbin/ipa-replica-**prepare", line 459, in >>> main() >>> >>> File "/usr/sbin/ipa-replica-**prepare", line 345, in main >>> export_certdb(api.env.realm, ds_dir, dir, passwd_fname, "dscert", >>> replica_fqdn, subject_base) >>> >>> File "/usr/sbin/ipa-replica-**prepare", line 143, in export_certdb >>> raise e >>> >>> >>> I have a certificate generated by a custom certificate authority in the >>> ipa server. >>> >> >> Need more information on your installation. What version of IPA, what >> distro? >> >> Did you use ipa-server-certinstall to replace the default IPA certs? >> >> rob >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Fri Feb 8 13:44:02 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 08 Feb 2013 08:44:02 -0500 Subject: [Freeipa-users] ipa-replica-prepare failed In-Reply-To: References: <51147A4D.8020508@redhat.com> Message-ID: <51150122.9010208@redhat.com> James James wrote: > I had to set the --dirsrv_pkcs12, --dirsrv_pin, --http_pkcs12, > --http_pin and the ipa-replica-prepare command runs without failure. > > Thanks for your help. Yes, this is what I was going to suggest. Using ipa-server-certinstall replace the IPA CA with an external one. I should note that we're deprecating this tool and do not recommend that it be used. We instead suggest that if you need certificates from an external CA you get the IPA CA signed as a subordinate. rob > > > 2013/2/8 James James > > > My ipa version is ipa-server-2.2.0-17.el6_3.1.x86_64 and the distro > is Scientific Linux 6.3. I have used ipa-server-certinstall to > replace the default IPA certs. > > > > > 2013/2/8 Rob Crittenden > > > James James wrote: > > Hi, > today I wanted to install a ipa replica. When I used the > ipa-replica-prepare command, I've got this error : > > [root at ipa ~]# ipa-replica-prepare ipa2-example.com > > > Directory Manager (existing master) password: > > Preparing replica for ipa-EXAMPLE.COM from ipa.EXAMPLE.COM > > > > Creating SSL certificate for the Directory Server > certutil: could not find certificate named "CN=EXAMPLE.COM > > Certificate Authority": security > library: bad database. > > certutil: unable to create cert (security library: bad > database.) > preparation of replica failed: Command '/usr/bin/certutil -d > /tmp/tmpoUpN72ipa/realm_info -A -n Server-Cert -t u,u,u -i > /var/lib/ipa/ipa-6qKbha/__tmpcert.der -f > /tmp/tmpoUpN72ipa/realm_info/__pwdfile.txt' returned > non-zero exit status 255 > Command '/usr/bin/certutil -d /tmp/tmpoUpN72ipa/realm_info -A -n > Server-Cert -t u,u,u -i /var/lib/ipa/ipa-6qKbha/__tmpcert.der -f > /tmp/tmpoUpN72ipa/realm_info/__pwdfile.txt' returned > non-zero exit status 255 > File "/usr/sbin/ipa-replica-__prepare", line 459, in > > main() > > File "/usr/sbin/ipa-replica-__prepare", line 345, in main > export_certdb(api.env.realm, ds_dir, dir, > passwd_fname, "dscert", > replica_fqdn, subject_base) > > File "/usr/sbin/ipa-replica-__prepare", line 143, in > export_certdb > raise e > > > I have a certificate generated by a custom certificate > authority in the > ipa server. > > > Need more information on your installation. What version of IPA, > what distro? > > Did you use ipa-server-certinstall to replace the default IPA certs? > > rob > > > From rajnesh.siwal at gmail.com Fri Feb 8 14:42:34 2013 From: rajnesh.siwal at gmail.com (Rajnesh Kumar Siwal) Date: Fri, 8 Feb 2013 20:12:34 +0530 Subject: [Freeipa-users] Testing out FreeIPA Message-ID: #yum install ipa-server -- Regards, Rajnesh Kumar Siwal From orion at cora.nwra.com Fri Feb 8 17:46:06 2013 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 08 Feb 2013 10:46:06 -0700 Subject: [Freeipa-users] ipa-replica-prepare failed In-Reply-To: <51150122.9010208@redhat.com> References: <51147A4D.8020508@redhat.com> <51150122.9010208@redhat.com> Message-ID: <511539DE.1090600@cora.nwra.com> On 02/08/2013 06:44 AM, Rob Crittenden wrote: > James James wrote: >> I had to set the --dirsrv_pkcs12, --dirsrv_pin, --http_pkcs12, >> --http_pin and the ipa-replica-prepare command runs without failure. >> >> Thanks for your help. > > Yes, this is what I was going to suggest. Using ipa-server-certinstall replace > the IPA CA with an external one. > > I should note that we're deprecating this tool and do not recommend that it be > used. We instead suggest that if you need certificates from an external CA you > get the IPA CA signed as a subordinate. > > rob Is that possible to do from a commercial SSL certificate provider? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com From rcritten at redhat.com Fri Feb 8 18:25:39 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 08 Feb 2013 13:25:39 -0500 Subject: [Freeipa-users] ipa-replica-prepare failed In-Reply-To: <511539DE.1090600@cora.nwra.com> References: <51147A4D.8020508@redhat.com> <51150122.9010208@redhat.com> <511539DE.1090600@cora.nwra.com> Message-ID: <51154323.5070503@redhat.com> Orion Poplawski wrote: > On 02/08/2013 06:44 AM, Rob Crittenden wrote: >> James James wrote: >>> I had to set the --dirsrv_pkcs12, --dirsrv_pin, --http_pkcs12, >>> --http_pin and the ipa-replica-prepare command runs without failure. >>> >>> Thanks for your help. >> >> Yes, this is what I was going to suggest. Using ipa-server-certinstall >> replace >> the IPA CA with an external one. >> >> I should note that we're deprecating this tool and do not recommend >> that it be >> used. We instead suggest that if you need certificates from an >> external CA you >> get the IPA CA signed as a subordinate. >> >> rob > > Is that possible to do from a commercial SSL certificate provider? > > GeoTrust does, I don't know about any others. http://www.prnewswire.com/news-releases/geotrust-launches-georoot-allows-organizations-with-their-own-certificate-authority-ca-to-chain-to-geotrusts-ubiquitous-public-root-54048807.html rob From jreg2k at gmail.com Fri Feb 8 20:21:54 2013 From: jreg2k at gmail.com (James James) Date: Fri, 8 Feb 2013 21:21:54 +0100 Subject: [Freeipa-users] ipa-replica-prepare failed In-Reply-To: <51150122.9010208@redhat.com> References: <51147A4D.8020508@redhat.com> <51150122.9010208@redhat.com> Message-ID: Now on the replica server I've got this error : Run connection check to master 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 creation of replica failed: Could not find a CA cert in /tmp/tmp21VpT8ipa/realm_info/dscert.p12 Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. Where I have to put the CA certficate ? Regards (again) 2013/2/8 Rob Crittenden > James James wrote: > >> I had to set the --dirsrv_pkcs12, --dirsrv_pin, --http_pkcs12, >> --http_pin and the ipa-replica-prepare command runs without failure. >> >> Thanks for your help. >> > > Yes, this is what I was going to suggest. Using ipa-server-certinstall > replace the IPA CA with an external one. > > I should note that we're deprecating this tool and do not recommend that > it be used. We instead suggest that if you need certificates from an > external CA you get the IPA CA signed as a subordinate. > > rob > > >> >> 2013/2/8 James James > >> >> >> My ipa version is ipa-server-2.2.0-17.el6_3.1.**x86_64 and the distro >> is Scientific Linux 6.3. I have used ipa-server-certinstall to >> replace the default IPA certs. >> >> >> >> >> 2013/2/8 Rob Crittenden > > >> >> >> James James wrote: >> >> Hi, >> today I wanted to install a ipa replica. When I used the >> ipa-replica-prepare command, I've got this error : >> >> [root at ipa ~]# ipa-replica-prepare ipa2-example.com >> >> >> >> Directory Manager (existing master) password: >> >> Preparing replica for ipa-EXAMPLE.COM from ipa.EXAMPLE.COM >> >> >> >> Creating SSL certificate for the Directory Server >> certutil: could not find certificate named "CN=EXAMPLE.COM >> >> Certificate Authority": security >> library: bad database. >> >> certutil: unable to create cert (security library: bad >> database.) >> preparation of replica failed: Command '/usr/bin/certutil -d >> /tmp/tmpoUpN72ipa/realm_info -A -n Server-Cert -t u,u,u -i >> /var/lib/ipa/ipa-6qKbha/__**tmpcert.der -f >> /tmp/tmpoUpN72ipa/realm_info/_**_pwdfile.txt' returned >> >> non-zero exit status 255 >> Command '/usr/bin/certutil -d /tmp/tmpoUpN72ipa/realm_info -A >> -n >> Server-Cert -t u,u,u -i /var/lib/ipa/ipa-6qKbha/__**tmpcert.der >> -f >> /tmp/tmpoUpN72ipa/realm_info/_**_pwdfile.txt' returned >> non-zero exit status 255 >> File "/usr/sbin/ipa-replica-__**prepare", line 459, in >> >> main() >> >> File "/usr/sbin/ipa-replica-__**prepare", line 345, in >> main >> >> export_certdb(api.env.realm, ds_dir, dir, >> passwd_fname, "dscert", >> replica_fqdn, subject_base) >> >> File "/usr/sbin/ipa-replica-__**prepare", line 143, in >> >> export_certdb >> raise e >> >> >> I have a certificate generated by a custom certificate >> authority in the >> ipa server. >> >> >> Need more information on your installation. What version of IPA, >> what distro? >> >> Did you use ipa-server-certinstall to replace the default IPA >> certs? >> >> rob >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Fri Feb 8 20:46:42 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 08 Feb 2013 15:46:42 -0500 Subject: [Freeipa-users] ipa-replica-prepare failed In-Reply-To: References: <51147A4D.8020508@redhat.com> <51150122.9010208@redhat.com> Message-ID: <51156432.3000707@redhat.com> James James wrote: > Now on the replica server I've got this error : > Run connection check to master > 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 > creation of replica failed: Could not find a CA cert in > /tmp/tmp21VpT8ipa/realm_info/dscert.p12 > > Your system may be partly configured. > Run /usr/sbin/ipa-server-install --uninstall to clean up. > > > Where I have to put the CA certficate ? It needs to be in the PKCS#12 file. rob From jreg2k at gmail.com Fri Feb 8 20:54:16 2013 From: jreg2k at gmail.com (James James) Date: Fri, 8 Feb 2013 21:54:16 +0100 Subject: [Freeipa-users] ipa-replica-prepare failed In-Reply-To: <51156432.3000707@redhat.com> References: <51147A4D.8020508@redhat.com> <51150122.9010208@redhat.com> <51156432.3000707@redhat.com> Message-ID: OK .. but I have to put the pkc12 file in /etc/pki/nssdb ? 2013/2/8 Rob Crittenden > James James wrote: > >> Now on the replica server I've got this error : >> Run connection check to master >> 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 >> creation of replica failed: Could not find a CA cert in >> /tmp/tmp21VpT8ipa/realm_info/**dscert.p12 >> >> Your system may be partly configured. >> Run /usr/sbin/ipa-server-install --uninstall to clean up. >> >> >> Where I have to put the CA certficate ? >> > > It needs to be in the PKCS#12 file. > > rob > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Fri Feb 8 22:19:35 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 08 Feb 2013 17:19:35 -0500 Subject: [Freeipa-users] ipa-replica-prepare failed In-Reply-To: References: <51147A4D.8020508@redhat.com> <51150122.9010208@redhat.com> <51156432.3000707@redhat.com> Message-ID: <511579F7.7000105@redhat.com> James James wrote: > OK .. but I have to put the pkc12 file in /etc/pki/nssdb ? No. The PKCS#12 file that contains your server private key and cert needs to also contain the CA that signed it. rob > > > 2013/2/8 Rob Crittenden > > > James James wrote: > > Now on the replica server I've got this error : > Run connection check to master > 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 > creation of replica failed: Could not find a CA cert in > /tmp/tmp21VpT8ipa/realm_info/__dscert.p12 > > Your system may be partly configured. > Run /usr/sbin/ipa-server-install --uninstall to clean up. > > > Where I have to put the CA certficate ? > > > It needs to be in the PKCS#12 file. > > rob > > From it.meme01 at gmail.com Fri Feb 8 22:29:45 2013 From: it.meme01 at gmail.com (It Meme) Date: Fri, 8 Feb 2013 14:29:45 -0800 Subject: [Freeipa-users] Python Client Message-ID: Hi: Scenario: 1) User is created via LDAP call to IPA (i.e.the 389 Directory Server) The above user will not have IPA-specific attributes. Can we use the Python Library, or CLI, to modify the account to IPA-ize it? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Fri Feb 8 22:39:29 2013 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 08 Feb 2013 17:39:29 -0500 Subject: [Freeipa-users] Python Client In-Reply-To: References: Message-ID: <51157EA1.7090000@redhat.com> On 02/08/2013 05:29 PM, It Meme wrote: > Hi: > > Scenario: > > 1) User is created via LDAP call to IPA (i.e.the 389 Directory Server) > > The above user will not have IPA-specific attributes. > > Can we use the Python Library, or CLI, to modify the account to > IPA-ize it? Is this an integration with the external provisioning system? Do you need to do it in real time or in batches? A simple solution that comes to mind is: to create users in a different sub tree in ipa temporarily run a cron job to inspect this area and translate the data in this temp entry into the arguments of the CLI add user command and then clean this temp area. ldap search > parse > ipa user-add delete processed temp entries The job can run at the cadence you think is reasonable - 30 min may be? > > Thanks. > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From it.meme01 at gmail.com Fri Feb 8 23:33:00 2013 From: it.meme01 at gmail.com (It Meme) Date: Fri, 8 Feb 2013 15:33:00 -0800 Subject: [Freeipa-users] Python Client In-Reply-To: <51157EA1.7090000@redhat.com> References: <51157EA1.7090000@redhat.com> Message-ID: Hi Dmitri: Yes, we are evaluating ways of provisioning users and their group memberships for Joiner, Mover, Leaver (JML) events. We were thinking of your suggestion as an option and your reply was very helpful. Our expected real-time scenarios is probably 5 mins latency. Is it viable to explore provisioning accounts/group to the destination tree via LDAP calls and a subsequent cron job runs, identifies the newly provisioned accounts, and applies modifications to create the IPA-specific attributes? Or is the temp folder the only option? Thank you for all your great help. On Fri, Feb 8, 2013 at 2:39 PM, Dmitri Pal wrote: > On 02/08/2013 05:29 PM, It Meme wrote: > > Hi: > > Scenario: > > 1) User is created via LDAP call to IPA (i.e.the 389 Directory Server) > > The above user will not have IPA-specific attributes. > > Can we use the Python Library, or CLI, to modify the account to IPA-ize > it? > > > Is this an integration with the external provisioning system? > Do you need to do it in real time or in batches? > > A simple solution that comes to mind is: > to create users in a different sub tree in ipa temporarily > run a cron job to inspect this area and translate the data in this temp > entry into the arguments of the CLI add user command and then clean this > temp area. > ldap search > parse > ipa user-add > delete processed temp entries > > The job can run at the cadence you think is reasonable - 30 min may be? > > > Thanks. > > > _______________________________________________ > Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs?www.redhat.com/carveoutcosts/ > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Fri Feb 8 23:57:26 2013 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 08 Feb 2013 18:57:26 -0500 Subject: [Freeipa-users] Python Client In-Reply-To: References: <51157EA1.7090000@redhat.com> Message-ID: <511590E6.6080803@redhat.com> On 02/08/2013 06:33 PM, It Meme wrote: > Hi Dmitri: > > Yes, we are evaluating ways of provisioning users and their group > memberships for Joiner, Mover, Leaver (JML) events. > > We were thinking of your suggestion as an option and your reply was > very helpful. > > Our expected real-time scenarios is probably 5 mins latency. > > Is it viable to explore provisioning accounts/group to the destination > tree via LDAP calls and a subsequent cron job runs, identifies the > newly provisioned accounts, and applies modifications to create the > IPA-specific attributes? Or is the temp folder the only option? You can do either, I think it is more error prone for you to try to convert the user that is already inserted. You would to make sure that all the attributes are in place. You would have to decompose the logic of the IPA user add and effectively re-implement it. Another approach would be to build a "simple" bridge that would take LDAP request and translate it into IPA JSON request. Such tool would be quite useful for us too. I am not sure how simple such thing would be in reality though. > > > Thank you for all your great help. > > > > On Fri, Feb 8, 2013 at 2:39 PM, Dmitri Pal > wrote: > > On 02/08/2013 05:29 PM, It Meme wrote: >> Hi: >> >> Scenario: >> >> 1) User is created via LDAP call to IPA (i.e.the 389 Directory >> Server) >> >> The above user will not have IPA-specific attributes. >> >> Can we use the Python Library, or CLI, to modify the account to >> IPA-ize it? > > Is this an integration with the external provisioning system? > Do you need to do it in real time or in batches? > > A simple solution that comes to mind is: > to create users in a different sub tree in ipa temporarily > run a cron job to inspect this area and translate the data in this > temp entry into the arguments of the CLI add user command and then > clean this temp area. > ldap search > parse > ipa user-add > delete processed temp entries > > The job can run at the cadence you think is reasonable - 30 min > may be? > >> >> Thanks. >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From shelltoesuperstar at gmail.com Sat Feb 9 00:47:16 2013 From: shelltoesuperstar at gmail.com (Charlie Derwent) Date: Sat, 9 Feb 2013 00:47:16 +0000 Subject: [Freeipa-users] Unable to enrol servers with principal Message-ID: Hi Whenever I attempt an unattended installation with a principal and password. The installation fails. I'm using the following syntax for my command ipa-client-install --domain=example.com --server=ipa.example.com --realm= EXAMPLE.COM --principal=user --password=pass -U --ntp-server=123.123.123.123 --mkhomedir --hostname=server1.example.com The error I get varies between (in order of frequency) Joining realm failed: /usr/sbin/ipa-join: symbol lookup error: /usr/sbin/ipa-join: undefined symbol: xmlrpc_server_info_set_user and kinit(v5): Password incorrect while getting initial credentials and Password expired. you must change it now. kinit(v5): Cannot read password while getting initial credentials The password is 100% right as I can kinit on other servers and access the webgui with the same details. OTP's work flawlessly. ipa-client = tried with 2.1.3-1.el5 and 2.1.3-5.el5_9.2 (RHEL 5.8) ipa-server = 2.2.0-16.el6 (RHEL 6.3) Thanks, Charlie -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Sat Feb 9 01:07:14 2013 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 08 Feb 2013 20:07:14 -0500 Subject: [Freeipa-users] Unable to enrol servers with principal In-Reply-To: References: Message-ID: <5115A142.6090509@redhat.com> On 02/08/2013 07:47 PM, Charlie Derwent wrote: > Hi > > Whenever I attempt an unattended installation with a principal and > password. The installation fails. > > I'm using the following syntax for my command > > ipa-client-install --domain=example.com > --server=ipa.example.com --realm=EXAMPLE.COM > --principal=user --password=pass -U > --ntp-server=123.123.123.123 --mkhomedir > --hostname=server1.example.com > > The error I get varies between (in order of frequency) > > Joining realm failed: /usr/sbin/ipa-join: symbol lookup error: > /usr/sbin/ipa-join: undefined symbol: xmlrpc_server_info_set_user > > and > > kinit(v5): Password incorrect while getting initial credentials > > and > > Password expired. you must change it now. > kinit(v5): Cannot read password while getting initial credentials > > The password is 100% right as I can kinit on other servers and access > the webgui with the same details. > > OTP's work flawlessly. > > ipa-client = tried with 2.1.3-1.el5 and 2.1.3-5.el5_9.2 (RHEL 5.8) > > ipa-server = 2.2.0-16.el6 (RHEL 6.3) I assume this happens on the newly installed system... Is the time on the system correct? > > Thanks, > Charlie > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From shelltoesuperstar at gmail.com Sat Feb 9 02:24:43 2013 From: shelltoesuperstar at gmail.com (Charlie Derwent) Date: Sat, 9 Feb 2013 02:24:43 +0000 Subject: [Freeipa-users] Unable to enrol servers with principal In-Reply-To: <5115A142.6090509@redhat.com> References: <5115A142.6090509@redhat.com> Message-ID: Yes the times on the ipa server and ipa client are in sync with our NTP source Thanks Charlie On Sat, Feb 9, 2013 at 1:07 AM, Dmitri Pal wrote: > On 02/08/2013 07:47 PM, Charlie Derwent wrote: > > Hi > > Whenever I attempt an unattended installation with a principal and > password. The installation fails. > > I'm using the following syntax for my command > > ipa-client-install --domain=example.com --server=ipa.example.com --realm= > EXAMPLE.COM --principal=user --password=pass -U > --ntp-server=123.123.123.123 --mkhomedir --hostname=server1.example.com > > The error I get varies between (in order of frequency) > > Joining realm failed: /usr/sbin/ipa-join: symbol lookup error: > /usr/sbin/ipa-join: undefined symbol: xmlrpc_server_info_set_user > > and > > kinit(v5): Password incorrect while getting initial credentials > > and > > Password expired. you must change it now. > kinit(v5): Cannot read password while getting initial credentials > > The password is 100% right as I can kinit on other servers and access the > webgui with the same details. > > OTP's work flawlessly. > > ipa-client = tried with 2.1.3-1.el5 and 2.1.3-5.el5_9.2 (RHEL 5.8) > > ipa-server = 2.2.0-16.el6 (RHEL 6.3) > > > I assume this happens on the newly installed system... > Is the time on the system correct? > > > Thanks, > Charlie > > > _______________________________________________ > Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs?www.redhat.com/carveoutcosts/ > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From umarzuki at gmail.com Sat Feb 9 05:32:14 2013 From: umarzuki at gmail.com (Umarzuki Mochlis) Date: Sat, 9 Feb 2013 13:32:14 +0800 Subject: [Freeipa-users] creating group via CLI In-Reply-To: <51145C2E.6020208@redhat.com> References: <51145C2E.6020208@redhat.com> Message-ID: 2013/2/8 John Dennis : > On 02/07/2013 08:42 PM, Umarzuki Mochlis wrote: >> >> Hi, >> >> Is it possible to create groups and add users to that group via CLI? >> So far, I could not find any sample command on doing that. > > > The ipa CLI has help > > % ipa help user > % ipa help group > % ipa help user-add > > etc. thanks, i'll check it out -- Regards, Umarzuki Mochlis http://debmal.my From natxo.asenjo at gmail.com Sat Feb 9 10:43:08 2013 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Sat, 9 Feb 2013 11:43:08 +0100 Subject: [Freeipa-users] error adding replica In-Reply-To: References: <50BCCA3D.6070807@redhat.com> <50C20B07.3040805@redhat.com> <50C92552.3080908@redhat.com> <50CA7472.5000706@redhat.com> <50F0270F.6010701@redhat.com> Message-ID: On Fri, Jan 11, 2013 at 4:19 PM, Natxo Asenjo wrote: > On Fri, Jan 11, 2013 at 3:51 PM, Rob Crittenden wrote: >> Natxo Asenjo wrote: >>> I just tried again to create a replica and had exactly the same error >>> as on the thread's first post. >>> >>> in ipareplica-install.log I get "The pkcs12 file is not correct." error. >>> >> >> Can you send me the log file /var/log/pki-ca/debug out-of-band? I'll pass >> that long to the dogtag guys who can hopefully tell us what is going on. I'd >> need the log from both the IPA Master that you are installing and the one >> that generated the replica file. >> >> The files can be big, gzipping is appreciate :-) hi, do you have any updates on this case? It is not really important, but if you do not have the time to look into it I will just wipe the vm because my homelab is going to be rebuilt ;-) -- groet, natxo From rajnesh.siwal at gmail.com Sat Feb 9 16:04:58 2013 From: rajnesh.siwal at gmail.com (Rajnesh Kumar Siwal) Date: Sat, 9 Feb 2013 21:34:58 +0530 Subject: [Freeipa-users] How to failover to IPA replica server Message-ID: We have setup an IPA replica server on the environment using the following command:- #ipa-replica-install --setup-dns --setup-ca --forwarder=192.168.1.204 /var/lib/ipa/replica-info-ipa2.labs.local.gpg There is a client authenticating against it. If I shutdown the ipa1 (Master server), the client does not falls back and authenticate against ipa2 (the replica) Logs that can be seen at IPA2 :- [09/Feb/2013:15:52:50 +0000] slapi_ldap_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error -1 (Can't contact LDAP server) [09/Feb/2013:15:56:02 +0000] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not connected) [09/Feb/2013:15:56:02 +0000] slapi_ldap_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error -1 (Can't contact LDAP server) nslookup from the IPA client :- [root at testvm ~]# nslookup -type=srv _kerberos._tcp.labs.local Server: 192.168.1.207 Address: 192.168.1.207#53 _kerberos._tcp.labs.local service = 0 100 88 ipa2.labs.local. _kerberos._tcp.labs.local service = 0 100 88 ipa.labs.local. --------------------------------------------------------------------------------------------------------------------------------------- Please suggest how to use ipa2 for authentication purpose. -- Regards, Rajnesh Kumar Siwal From jreg2k at gmail.com Sat Feb 9 16:14:05 2013 From: jreg2k at gmail.com (James James) Date: Sat, 9 Feb 2013 17:14:05 +0100 Subject: [Freeipa-users] ipa-replica-prepare failed In-Reply-To: <511579F7.7000105@redhat.com> References: <51147A4D.8020508@redhat.com> <51150122.9010208@redhat.com> <51156432.3000707@redhat.com> <511579F7.7000105@redhat.com> Message-ID: Maybe I am stupid or tired (or both ..) but I have tried many thing to include the ca cert, the ipa key and pem file in a single pkcs12 file but I am still stucked. Can you give me a more detailled help ? 2013/2/8 Rob Crittenden > James James wrote: > >> OK .. but I have to put the pkc12 file in /etc/pki/nssdb ? >> > > No. The PKCS#12 file that contains your server private key and cert needs > to also contain the CA that signed it. > > rob > > >> >> 2013/2/8 Rob Crittenden > >> >> >> >> James James wrote: >> >> Now on the replica server I've got this error : >> Run connection check to master >> 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 >> creation of replica failed: Could not find a CA cert in >> /tmp/tmp21VpT8ipa/realm_info/_**_dscert.p12 >> >> >> Your system may be partly configured. >> Run /usr/sbin/ipa-server-install --uninstall to clean up. >> >> >> Where I have to put the CA certficate ? >> >> >> It needs to be in the PKCS#12 file. >> >> rob >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rajnesh.siwal at gmail.com Sat Feb 9 16:45:42 2013 From: rajnesh.siwal at gmail.com (Rajnesh Kumar Siwal) Date: Sat, 9 Feb 2013 22:15:42 +0530 Subject: [Freeipa-users] SOLVED: Re: How to failover to IPA replica server Message-ID: It started working after a few minutes. On Sat, Feb 9, 2013 at 9:34 PM, Rajnesh Kumar Siwal wrote: > We have setup an IPA replica server on the environment using the > following command:- > #ipa-replica-install --setup-dns --setup-ca --forwarder=192.168.1.204 > /var/lib/ipa/replica-info-ipa2.labs.local.gpg > > There is a client authenticating against it. > If I shutdown the ipa1 (Master server), the client does not falls back > and authenticate against ipa2 (the replica) > > Logs that can be seen at IPA2 :- > [09/Feb/2013:15:52:50 +0000] slapi_ldap_bind - Error: could not > perform interactive bind for id [] mech [GSSAPI]: error -1 (Can't > contact LDAP server) > [09/Feb/2013:15:56:02 +0000] slapd_ldap_sasl_interactive_bind - Error: > could not perform interactive bind for id [] mech [GSSAPI]: LDAP error > -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint > is not connected) > [09/Feb/2013:15:56:02 +0000] slapi_ldap_bind - Error: could not > perform interactive bind for id [] mech [GSSAPI]: error -1 (Can't > contact LDAP server) > > > nslookup from the IPA client :- > [root at testvm ~]# nslookup -type=srv _kerberos._tcp.labs.local > Server: 192.168.1.207 > Address: 192.168.1.207#53 > > _kerberos._tcp.labs.local service = 0 100 88 ipa2.labs.local. > _kerberos._tcp.labs.local service = 0 100 88 ipa.labs.local. > --------------------------------------------------------------------------------------------------------------------------------------- > > Please suggest how to use ipa2 for authentication purpose. > > -- > Regards, > Rajnesh Kumar Siwal -- Regards, Rajnesh Kumar Siwal From jdennis at redhat.com Sat Feb 9 16:53:56 2013 From: jdennis at redhat.com (John Dennis) Date: Sat, 09 Feb 2013 11:53:56 -0500 Subject: [Freeipa-users] Python Client In-Reply-To: References: Message-ID: <51167F24.30904@redhat.com> On 02/08/2013 05:29 PM, It Meme wrote: > Hi: > > Scenario: > > 1) User is created via LDAP call to IPA (i.e.the 389 Directory Server) > > The above user will not have IPA-specific attributes. > > Can we use the Python Library, or CLI, to modify the account to IPA-ize it? You're really better off using the IPA API directly rather than trying to bypass it. Why? Because we implement additional logic inside the commands. If you could achieve everything IPA does by just modifying an LDAP server there wouldn't be a need for IPA. A good example of this is group membership, some of that logic is handled directly by a plugin to the 389 DS, but a large part of it is implemented in the IPA commands that manage users and groups. You really don't want to bypass it. You have a number of options on how to call the IPA commands: 1) the ipa command line client 2) sending the command formatted in JSON to the server 3) sending the command formatted in XML-RPC to the server 4) calling the command from your own python code 5) using the web GUI It's really not hard to call the IPA command line client from a program, typically this is done via a "system" command of which there are a number of variants. The following thread has a discussion of how to invoke one of our commands from Python code, this particular email response from Martin shows how it can be done in in about half a dozen lines of code. https://www.redhat.com/archives/freeipa-users/2012-June/msg00334.html What I'm not understanding why you're avoiding using the commands we provide. If you're not familiar with how to call another program/process we can help you or just google it. Or is the problem your existing management system does not provide you with any "hooks" to execute code when an action occurs. But from everything you've said so far you imply it does provide such hooks. Perhaps if you could be more specific we could be more helpful. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Sun Feb 10 01:48:37 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Sat, 09 Feb 2013 20:48:37 -0500 Subject: [Freeipa-users] Unable to enrol servers with principal In-Reply-To: References: Message-ID: <5116FC75.1000105@redhat.com> Charlie Derwent wrote: > Hi > Whenever I attempt an unattended installation with a principal and > password. The installation fails. > I'm using the following syntax for my command > ipa-client-install --domain=example.com > --server=ipa.example.com --realm=EXAMPLE.COM > --principal=user --password=pass -U > --ntp-server=123.123.123.123 --mkhomedir --hostname=server1.example.com > > The error I get varies between (in order of frequency) > Joining realm failed: /usr/sbin/ipa-join: symbol lookup error: > /usr/sbin/ipa-join: undefined symbol: xmlrpc_server_info_set_user > and This is the sort of thing that if you saw once, you should see every time. What version of xmlrpc-c-client is installed? > kinit(v5): Password incorrect while getting initial credentials > and > Password expired. you must change it now. > kinit(v5): Cannot read password while getting initial credentials > The password is 100% right as I can kinit on other servers and access > the webgui with the same details. > OTP's work flawlessly. The KDC log might have more information. > ipa-client = tried with 2.1.3-1.el5 and 2.1.3-5.el5_9.2 (RHEL 5.8) > ipa-server = 2.2.0-16.el6 (RHEL 6.3) rob From rcritten at redhat.com Sun Feb 10 01:53:13 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Sat, 09 Feb 2013 20:53:13 -0500 Subject: [Freeipa-users] How to failover to IPA replica server In-Reply-To: References: Message-ID: <5116FD89.9010908@redhat.com> Rajnesh Kumar Siwal wrote: > We have setup an IPA replica server on the environment using the > following command:- > #ipa-replica-install --setup-dns --setup-ca --forwarder=192.168.1.204 > /var/lib/ipa/replica-info-ipa2.labs.local.gpg > > There is a client authenticating against it. > If I shutdown the ipa1 (Master server), the client does not falls back > and authenticate against ipa2 (the replica) We are working on fixing this now. Once a client is enrolled then sssd will handle the fallback but during installation things can fail if it tries to contact a downed server. > Logs that can be seen at IPA2 :- > [09/Feb/2013:15:52:50 +0000] slapi_ldap_bind - Error: could not > perform interactive bind for id [] mech [GSSAPI]: error -1 (Can't > contact LDAP server) > [09/Feb/2013:15:56:02 +0000] slapd_ldap_sasl_interactive_bind - Error: > could not perform interactive bind for id [] mech [GSSAPI]: LDAP error > -1 (Can't contact LDAP server) ((null)) errno 107 (Transport endpoint > is not connected) > [09/Feb/2013:15:56:02 +0000] slapi_ldap_bind - Error: could not > perform interactive bind for id [] mech [GSSAPI]: error -1 (Can't > contact LDAP server) Seems like this should be expected, it can't connect to do replication. > > > nslookup from the IPA client :- > [root at testvm ~]# nslookup -type=srv _kerberos._tcp.labs.local > Server: 192.168.1.207 > Address: 192.168.1.207#53 > > _kerberos._tcp.labs.local service = 0 100 88 ipa2.labs.local. > _kerberos._tcp.labs.local service = 0 100 88 ipa.labs.local. > --------------------------------------------------------------------------------------------------------------------------------------- > > Please suggest how to use ipa2 for authentication purpose. > enrollment != authentication. Once enrolled sssd takes over and it handles failover very well. rob From rcritten at redhat.com Sun Feb 10 01:59:47 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Sat, 09 Feb 2013 20:59:47 -0500 Subject: [Freeipa-users] ipa-replica-prepare failed In-Reply-To: References: <51147A4D.8020508@redhat.com> <51150122.9010208@redhat.com> <51156432.3000707@redhat.com> <511579F7.7000105@redhat.com> Message-ID: <5116FF13.20403@redhat.com> James James wrote: > Maybe I am stupid or tired (or both ..) but I have tried many thing to > include the ca cert, the ipa key and pem file in a single pkcs12 file > but I am still stucked. > > Can you give me a more detailled help ? Well, this is one of the reasons we're deprecating this feature, because it hasn't been well-tested since v1 and is ridden with corner cases. I think the only solution is going to be to in direct code changes to the IPA python scripts to match what your PKCS#12 files contain. If it is signed by a root CA then chances are if you simply skip the step where the CA is loaded and trusted then things may just work. It is failing in ipaserver/install/certs.p12 in the call to find_root_cert_from_pkcs12(). Either it is simply an issue of our identifying the CA or one isn't being loaded at all. You can do: certutil -L -d /etc/dirsrv/slapd-YOUR_REALM to list the certificates that were loaded. It may be that the CA was loaded but we aren't detecting the nickname, in which case you could simply hardcode it into the python file for a workaround, something like: ca_names = ['CA nickname'] rob > > > 2013/2/8 Rob Crittenden > > > James James wrote: > > OK .. but I have to put the pkc12 file in /etc/pki/nssdb ? > > > No. The PKCS#12 file that contains your server private key and cert > needs to also contain the CA that signed it. > > rob > > > > 2013/2/8 Rob Crittenden >> > > > James James wrote: > > Now on the replica server I've got this error : > Run connection check to master > 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 > creation of replica failed: Could not find a CA cert in > /tmp/tmp21VpT8ipa/realm_info/____dscert.p12 > > > Your system may be partly configured. > Run /usr/sbin/ipa-server-install --uninstall to clean up. > > > Where I have to put the CA certficate ? > > > It needs to be in the PKCS#12 file. > > rob > > > > From bin.echo at gmail.com Sun Feb 10 07:15:07 2013 From: bin.echo at gmail.com (bin.echo at gmail.com) Date: Sun, 10 Feb 2013 00:15:07 -0700 Subject: [Freeipa-users] Fedora 17 ipa.service fails to load with "ipa.service failed to load. No such file or directory." Message-ID: Here is what I did: Install Fedora 17 XFCE spin. yum upgrade yum install freeipa-client enroll machine (it enrolls just fine) However, when I reboot the machine, I find the ipa.service isn't running. So I manually try to start it: systemcrl start ipa.service Then I get this error Failed to issue method call: Unit ipa.service failed to load: No such file or directory. See system logs and 'systemctrl status ipa.service' for details. systemctrl status ipa.service proveide no additional useful information. It simply tells me there is a directory missing also. Grepping all of /var/log turns up nothing useful. I have no idea what directory ipa.service feels it is missing. I'm stumped. Any pointers? thanks, -Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: From dale at themacartneyclan.com Sun Feb 10 12:15:00 2013 From: dale at themacartneyclan.com (Dale Macartney) Date: Sun, 10 Feb 2013 12:15:00 +0000 Subject: [Freeipa-users] User info lookup via LDAP with Jabber +FreeIPA Message-ID: <51178F44.2060209@themacartneyclan.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all So I have started testing more of the end user experience of FreeIPA with my integration docs of different services over the weekend and when I logged in as an IPA test user to Jabber, I noticed that the user details are not being populated. Article is here: https://www.dalemacartney.com/2012/07/05/configuring-ejabberd-to-authenticate-freeipa-users-using-ldap-group-memberships As an admin, these details probably seem pretty trivial and unneeded, but as an end user, this could be useful. Otherwise those fields wouldn't be in the client at all really. I used Empathy on Fedora 18 as the connecting client as it is an authenticated IPA workstation. Does anyone have any ideas/suggestions/experience on pulling those user attributes from IPA into the jabber client? Screenshot attached. Thanks all Dale -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRF48/AAoJEAJsWS61tB+q/88QAJ65I8U2nsInKBW8G8Mn241E M54fUYrhUdJm9o5PW0mgQePDsaOWYPlww8ccB7Z7k00guG3WQ0nmNuaUsSTSfd63 LBCBYTBECs9fJhU9TbQkdUlXFjGtnJmhWazuXUHOwDUAK5yFsIZxgFtLQQd9F38j TNZd87sGbrJZ4/+O4ocXWBQlzE9PcrplkXMk0pCsnbeQpzhdLUMfgnhwpK0Pfnyp dabSDdQE0HYFYFqOq7rn8W2OC9IgUk1pknapSHyqyAjIkDeh/dQem6p6CgZyrqx/ GNcf1P75UnYT6PvxQXfxQeGzLBxunQClKS+7KsxwhhsQGIMCVX0cH/1/3xzZuPjS x1PAgBSPXg7CKchoW7tmdY7S9CZ8qAuwXEzDI+++XzzPl39OXuWWL6PQk8kWVnq+ M0IGQyk2Xzrvkgr6BEOsUeQHNbfOPDQGjjjvJnUu2VLXqSeS0d2JluaFQmf7mm/P 40HvJxL7R0wkdqjOgkd+I4GbbEOtiTJyH3gPf6EKSyu423jHTpbed8GOLRX6Cq6j knhUvLXgOJQEntR1iNcs7o7e1XCpOP06J1mEknLTcnApMszPcHjDDX+3/Z6CDalP LXHe9OZglgD28xmBm4pBaLQN1q5DoXGxRExOO+BylVIn3ZkTn7A1RCkKHNIJgTxF NWk492cJ/Y99HPAd5vAi =Eiki -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: Jabber+IPA.png Type: image/png Size: 37544 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Jabber+IPA.png.sig Type: application/pgp-signature Size: 543 bytes Desc: not available URL: From dpal at redhat.com Sun Feb 10 15:32:51 2013 From: dpal at redhat.com (Dmitri Pal) Date: Sun, 10 Feb 2013 10:32:51 -0500 Subject: [Freeipa-users] Python Client In-Reply-To: <51167F24.30904@redhat.com> References: <51167F24.30904@redhat.com> Message-ID: <5117BDA3.4070800@redhat.com> On 02/09/2013 11:53 AM, John Dennis wrote: > On 02/08/2013 05:29 PM, It Meme wrote: >> Hi: >> >> Scenario: >> >> 1) User is created via LDAP call to IPA (i.e.the 389 Directory Server) >> >> The above user will not have IPA-specific attributes. >> >> Can we use the Python Library, or CLI, to modify the account to >> IPA-ize it? > > You're really better off using the IPA API directly rather than trying > to bypass it. Why? Because we implement additional logic inside the > commands. If you could achieve everything IPA does by just modifying > an LDAP server there wouldn't be a need for IPA. A good example of > this is group membership, some of that logic is handled directly by a > plugin to the 389 DS, but a large part of it is implemented in the IPA > commands that manage users and groups. You really don't want to bypass > it. > > You have a number of options on how to call the IPA commands: > > 1) the ipa command line client > > 2) sending the command formatted in JSON to the server > > 3) sending the command formatted in XML-RPC to the server > > 4) calling the command from your own python code > > 5) using the web GUI > > It's really not hard to call the IPA command line client from a > program, typically this is done via a "system" command of which there > are a number of variants. > > The following thread has a discussion of how to invoke one of our > commands from Python code, this particular email response from Martin > shows how it can be done in in about half a dozen lines of code. > > https://www.redhat.com/archives/freeipa-users/2012-June/msg00334.html > > What I'm not understanding why you're avoiding using the commands we > provide. If you're not familiar with how to call another > program/process we can help you or just google it. Or is the problem > your existing management system does not provide you with any "hooks" > to execute code when an action occurs. But from everything you've said > so far you imply it does provide such hooks. Perhaps if you could be > more specific we could be more helpful. > It seems that the management system in question can insert an entry into LDAP but can't do the "generic" hook. I bet this is the issue here. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Sun Feb 10 16:39:44 2013 From: dpal at redhat.com (Dmitri Pal) Date: Sun, 10 Feb 2013 11:39:44 -0500 Subject: [Freeipa-users] User info lookup via LDAP with Jabber +FreeIPA In-Reply-To: <51178F44.2060209@themacartneyclan.com> References: <51178F44.2060209@themacartneyclan.com> Message-ID: <5117CD50.6040207@redhat.com> On 02/10/2013 07:15 AM, Dale Macartney wrote: > > Hi all > > So I have started testing more of the end user experience of FreeIPA > with my integration docs of different services over the weekend and when > I logged in as an IPA test user to Jabber, I noticed that the user > details are not being populated. > > Article is here: > https://www.dalemacartney.com/2012/07/05/configuring-ejabberd-to-authenticate-freeipa-users-using-ldap-group-memberships > > As an admin, these details probably seem pretty trivial and unneeded, > but as an end user, this could be useful. Otherwise those fields > wouldn't be in the client at all really. > > I used Empathy on Fedora 18 as the connecting client as it is an > authenticated IPA workstation. > > Does anyone have any ideas/suggestions/experience on pulling those user > attributes from IPA into the jabber client? > > Screenshot attached. > > Thanks all > > Dale > > Would be nice to understand which attributes are expected for those. I do not think we keep a birthday in IPA. > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dale at themacartneyclan.com Sun Feb 10 16:47:33 2013 From: dale at themacartneyclan.com (Dale Macartney) Date: Sun, 10 Feb 2013 16:47:33 +0000 Subject: [Freeipa-users] User info lookup via LDAP with Jabber +FreeIPA In-Reply-To: <5117CD50.6040207@redhat.com> References: <51178F44.2060209@themacartneyclan.com> <5117CD50.6040207@redhat.com> Message-ID: <5117CF25.8030103@themacartneyclan.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/10/2013 04:39 PM, Dmitri Pal wrote: > On 02/10/2013 07:15 AM, Dale Macartney wrote: > > >> Hi all >> >> So I have started testing more of the end user experience of FreeIPA >> with my integration docs of different services over the weekend and when >> I logged in as an IPA test user to Jabber, I noticed that the user >> details are not being populated. >> >> Article is here: >> https://www.dalemacartney.com/2012/07/05/configuring-ejabberd-to-authenticate-freeipa-users-using-ldap-group-memberships >> >> As an admin, these details probably seem pretty trivial and unneeded, >> but as an end user, this could be useful. Otherwise those fields >> wouldn't be in the client at all really. >> >> I used Empathy on Fedora 18 as the connecting client as it is an >> authenticated IPA workstation. >> >> Does anyone have any ideas/suggestions/experience on pulling those user >> attributes from IPA into the jabber client? >> >> Screenshot attached. >> >> Thanks all >> >> Dale >> >> > Would be nice to understand which attributes are expected for those. > I do not think we keep a birthday in IPA. I did have a chuckle when I noticed that one. - From what i've been reading its just an additional section I need in the ejabberd config.. There seems support for display photos as well. Might have to pick that one up as well when I have a free moment. I'll keep the list informed on progress. > > > > > > > > > _______________________________________________ > > Freeipa-users mailing list > > Freeipa-users at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-users > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRF88kAAoJEAJsWS61tB+qWxgQALhwUOEjZS2cN0NPpdh4WXEJ Ouo41EAgAsQt4HYM6m74g/sp0hYpMwexwIDGFHydfoKtUSokHzKwOknOMubAqvOr QGbtuBfg3u95kb7bMkE7mhAhCC1U67g6fsYwYIQZ5/Dm+RfQxP2QxRdggPAG63cD ECIxLJVydf0PiI+pWp5lEHGYtxc4mLpgnJeEbd+UKUcBss+lY0ftyvMmvMeuxPip NMW62xHws0iGbldHcQPYCztfcyPoxaZXNjFknPcASf7H3gAUE9kjb8XVcVf8QN+Y HHDywahqWxFvT0+LxB8EKWLdcOsCcj0Inb9TWJuBhh+n7GKwlNI73JUlrbNThkys LysMiRoID32huHV5WDbvRJW+wOzCW8LoFQHvSao5GV1WMMPquayblNRgTIr0Vuwz HezzSFghG4r/pXl2Q9jawcOvVky3M/D03EdknrgIPSsQCKsSnb9/aQER2Q4v2Olq PMpH4hiCIH1tUH16KG6HOfcDCksxhZTd4OXn3GGc55A+u0tcM0ev9amvFkmUfHV/ up4TtSphQH3IZq4JKrs14u2QaGBm6+jT8pKU4+tVYD80nlCAd0YAjEu7RejKQPH9 3P6rbWqXkYrSA03f3VU7/DgE/f2RXhuSKBAOOQtmC+KJOdv0gpSN/xMYaQxfIV8s rygkO+Cmw0AyKNPRilvL =Ya55 -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From rajnesh.siwal at gmail.com Sun Feb 10 17:30:21 2013 From: rajnesh.siwal at gmail.com (Rajnesh Kumar Siwal) Date: Sun, 10 Feb 2013 17:30:21 +0000 Subject: [Freeipa-users] The htaccess login pop-up window appears but login never succeeds Message-ID: Hi All, As I try to login into the IPA through https, it displays me a popup window to login. But login fails through it every time. I don't understand why this popup window is for. Screenshot of pop-up window attached. In the next screen, I login through Form-Based authentication and that works fine. Why does this POP-up window appears and why my login fails everytime (I try to login through admin user) Please suggest Thanks in advance. -- Regards, Rajnesh Kumar Siwal -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot from 2013-02-10 22:55:03.png Type: image/png Size: 75359 bytes Desc: not available URL: From dpal at redhat.com Mon Feb 11 02:59:31 2013 From: dpal at redhat.com (Dmitri Pal) Date: Sun, 10 Feb 2013 21:59:31 -0500 Subject: [Freeipa-users] The htaccess login pop-up window appears but login never succeeds In-Reply-To: References: Message-ID: <51185E93.5080903@redhat.com> On 02/10/2013 12:30 PM, Rajnesh Kumar Siwal wrote: > Hi All, > > As I try to login into the IPA through https, it displays me a popup > window to login. > But login fails through it every time. I don't understand why this > popup window is for. > Screenshot of pop-up window attached. > > In the next screen, I login through Form-Based authentication and that > works fine. > > Why does this POP-up window appears and why my login fails everytime > (I try to login through admin user) > Please suggest > > Thanks in advance. Which version of IPA do you use? Did you follow the instructions on how to import IPA cert into your browser? > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rajnesh.siwal at gmail.com Mon Feb 11 04:10:13 2013 From: rajnesh.siwal at gmail.com (Rajnesh Kumar Siwal) Date: Mon, 11 Feb 2013 04:10:13 +0000 Subject: [Freeipa-users] The htaccess login pop-up window appears but login never succeeds In-Reply-To: References: Message-ID: Versions: OS: CentOS 6.3 IPA: 2.2 On Sun, Feb 10, 2013 at 5:30 PM, Rajnesh Kumar Siwal wrote: > Hi All, > > As I try to login into the IPA through https, it displays me a popup > window to login. > But login fails through it every time. I don't understand why this > popup window is for. > Screenshot of pop-up window attached. > > In the next screen, I login through Form-Based authentication and that > works fine. > > Why does this POP-up window appears and why my login fails everytime > (I try to login through admin user) > Please suggest > > Thanks in advance. > -- > Regards, > Rajnesh Kumar Siwal -- Regards, Rajnesh Kumar Siwal From rajnesh.siwal at gmail.com Mon Feb 11 04:12:49 2013 From: rajnesh.siwal at gmail.com (Rajnesh Kumar Siwal) Date: Mon, 11 Feb 2013 04:12:49 +0000 Subject: [Freeipa-users] The htaccess login pop-up window appears but login never succeeds In-Reply-To: References: Message-ID: Did you follow the instructions on how to import IPA cert into your browser ? Not yet. Will following the instructions test that part also and will let you know. But I need to understand what this htaccess page is trying to do. On Mon, Feb 11, 2013 at 4:10 AM, Rajnesh Kumar Siwal wrote: > Versions: > OS: CentOS 6.3 > IPA: 2.2 > > On Sun, Feb 10, 2013 at 5:30 PM, Rajnesh Kumar Siwal > wrote: >> Hi All, >> >> As I try to login into the IPA through https, it displays me a popup >> window to login. >> But login fails through it every time. I don't understand why this >> popup window is for. >> Screenshot of pop-up window attached. >> >> In the next screen, I login through Form-Based authentication and that >> works fine. >> >> Why does this POP-up window appears and why my login fails everytime >> (I try to login through admin user) >> Please suggest >> >> Thanks in advance. >> -- >> Regards, >> Rajnesh Kumar Siwal > > > > -- > Regards, > Rajnesh Kumar Siwal -- Regards, Rajnesh Kumar Siwal From rajnesh.siwal at gmail.com Mon Feb 11 04:22:01 2013 From: rajnesh.siwal at gmail.com (Rajnesh Kumar Siwal) Date: Mon, 11 Feb 2013 04:22:01 +0000 Subject: [Freeipa-users] User Migrated from LDAP not able to change the password Message-ID: The details are as follows:- [root at ipa1 ~]# ipa pwpolicy-show Group: global_policy Max lifetime (days): 90 Min lifetime (hours): 1 History size: 0 Character classes: 0 Min length: 12 Max failures: 6 Failure reset interval: 60 Lockout duration: 600 [root at ipa1 ~]# ipa user-show siwal --all --raw dn: uid=siwal,cn=users,cn=accounts,dc=xyz,dc=dmz uid: siwal sn: Kumar cn: siwal homedirectory: /home/siwal loginshell: /bin/bash krbprincipalname: siwal at XYZ.DMZ uidnumber: 522 gidnumber: 522 nsaccountlock: False has_password: True has_keytab: True ipauniqueid: 65775332-712f-11e2-b3cc-000c298a58a4 krblastpwdchange: 20130208035343Z krblastsuccessfulauth: 20130208035929Z krbpasswordexpiration: 20130208035343Z memberof: cn=ipausers,cn=groups,cn=accounts,dc=xyz,dc=dmz memberofindirect: cn=software,cn=groups,cn=accounts,dc=xyz,dc=dmz objectclass: krbticketpolicyaux objectclass: ipaobject objectclass: organizationalperson objectclass: top objectclass: ipasshuser objectclass: inetorgperson objectclass: person objectclass: inetuser objectclass: krbprincipalaux objectclass: shadowaccount objectclass: posixaccount objectclass: ipaSshGroupOfPubKeys shadowlastchange: 14879 shadowmax: 99999 shadowmin: 0 shadowwarning: 7 -- Regards, Rajnesh Kumar Siwal From rajnesh.siwal at gmail.com Mon Feb 11 06:38:24 2013 From: rajnesh.siwal at gmail.com (Rajnesh Kumar Siwal) Date: Mon, 11 Feb 2013 06:38:24 +0000 Subject: [Freeipa-users] Failed to obtain host TGT bug Message-ID: Please show us the output when you are trying to register the client in debug mode :- $ipa-client-install -d -- Regards, Rajnesh Kumar Siwal From pvoborni at redhat.com Mon Feb 11 09:23:01 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 11 Feb 2013 10:23:01 +0100 Subject: [Freeipa-users] The htaccess login pop-up window appears but login never succeeds In-Reply-To: References: Message-ID: <5118B875.2090707@redhat.com> On 02/10/2013 06:30 PM, Rajnesh Kumar Siwal wrote: > Hi All, > > As I try to login into the IPA through https, it displays me a popup > window to login. > But login fails through it every time. I don't understand why this > popup window is for. > Screenshot of pop-up window attached. > > In the next screen, I login through Form-Based authentication and that > works fine. > > Why does this POP-up window appears and why my login fails everytime > (I try to login through admin user) > Please suggest > > Thanks in advance. > Hi, it looks like a HTTP basic authentication dialog. FreeIPA doesn't use this method. Is it possible, that you, or some other application on the machine modified apache configuration and enabled it? HTH -- Petr Vobornik From rajnesh.siwal at gmail.com Mon Feb 11 09:25:01 2013 From: rajnesh.siwal at gmail.com (Rajnesh Kumar Siwal) Date: Mon, 11 Feb 2013 09:25:01 +0000 Subject: [Freeipa-users] The htaccess login pop-up window appears but login never succeeds In-Reply-To: <5118B875.2090707@redhat.com> References: <5118B875.2090707@redhat.com> Message-ID: Thanks, Petr, I would like to confirm that I did not manually install any other application on it. I will dig further on it , if I could fetch out the reason. On Mon, Feb 11, 2013 at 9:23 AM, Petr Vobornik wrote: > On 02/10/2013 06:30 PM, Rajnesh Kumar Siwal wrote: >> >> Hi All, >> >> As I try to login into the IPA through https, it displays me a popup >> window to login. >> But login fails through it every time. I don't understand why this >> popup window is for. >> Screenshot of pop-up window attached. >> >> In the next screen, I login through Form-Based authentication and that >> works fine. >> >> Why does this POP-up window appears and why my login fails everytime >> (I try to login through admin user) >> Please suggest >> >> Thanks in advance. >> > > Hi, > > it looks like a HTTP basic authentication dialog. FreeIPA doesn't use this > method. Is it possible, that you, or some other application on the machine > modified apache configuration and enabled it? > > HTH > -- > Petr Vobornik -- Regards, Rajnesh Kumar Siwal From mkosek at redhat.com Mon Feb 11 09:48:48 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 11 Feb 2013 10:48:48 +0100 Subject: [Freeipa-users] Fedora 17 ipa.service fails to load with "ipa.service failed to load. No such file or directory." In-Reply-To: References: Message-ID: <5118BE80.3030308@redhat.com> On 02/10/2013 08:15 AM, bin.echo at gmail.com wrote: > Here is what I did: > > Install Fedora 17 XFCE spin. > > yum upgrade > > yum install freeipa-client > > enroll machine (it enrolls just fine) > > However, when I reboot the machine, I find the ipa.service isn't running. So I > manually try to start it: > > systemcrl start ipa.service > > Then I get this error > Failed to issue method call: Unit ipa.service failed to load: No such file or > directory. See system logs and 'systemctrl status ipa.service' for details. > > systemctrl status ipa.service proveide no additional useful information. It > simply tells me there is a directory missing also. > > Grepping all of /var/log turns up nothing useful. > > I have no idea what directory ipa.service feels it is missing. > > I'm stumped. Any pointers? > > thanks, > -Aaron Hello Aaron, ipa.service is packaged in freeipa-server package. It is a service controlling IPA _server_ services (configured by ipa-server-install), i.e. Directory Server, Kerberos KDC, PKI CA, ... It is not needed to be run on pure client machine. The client machine does not have a unified ipa service, but only services you configured during ipa-client-install, for example sssd service. HTH, Martin From Rashard.Kelly at SITA.aero Mon Feb 11 17:00:22 2013 From: Rashard.Kelly at SITA.aero (Rashard.Kelly at SITA.aero) Date: Mon, 11 Feb 2013 12:00:22 -0500 Subject: [Freeipa-users] Postponing IPA 3 upgrade Message-ID: I was wondering if I need to be concerned about IPA 2 being updated automatically to IPA 3? We have a working IPA 2 environment in place now and wanted to know if IPA needed to be added to an exclude list. We are afraid of breaking our current setup. When IPA 3 is released will yum automatically upgrade it to 3 or will that be something that we have to manually issue? Thanks, Rashard This document is strictly confidential and intended only for use by the addressee unless otherwise stated. If you are not the intended recipient, please notify the sender immediately and delete it from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: From erinn.looneytriggs at gmail.com Mon Feb 11 18:11:47 2013 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Mon, 11 Feb 2013 11:11:47 -0700 Subject: [Freeipa-users] Postponing IPA 3 upgrade In-Reply-To: References: Message-ID: <51193463.4070603@gmail.com> On 02/11/2013 10:00 AM, Rashard.Kelly at SITA.aero wrote: > I was wondering if I need to be concerned about IPA 2 being updated > automatically to IPA 3? We have a working IPA 2 environment in place now > and wanted to know if IPA needed to be added to an exclude list. We are > afraid of breaking our current setup. When IPA 3 is released will yum > automatically upgrade it to 3 or will that be something that we have to > manually issue? > > > Thanks, > Rashard > > > This document is strictly confidential and intended only for use by the > addressee unless otherwise stated. If you are not the intended > recipient, please notify the sender immediately and delete it from your > system. > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > That is going to depend a lot on how you manage your environment. If you are set up to simply download and install any updates then yes you should give it some thought. If you are set up with a management entitlement through RHN, you can choose when to deploy an update. Or if you are simply running yum update by hand then it is not just going to happen. It is possible to do excludes in yum, just search for yum excludes. That might give you all the 6.4 updates minus the IPA updates. However, I would be wary of this as that may cause some issues as well. It is also possible to just stay with 6.3, I don't know much about how this works, but I do know that for some point releases Red Hat continues to offer support in the form of patches and updates after the next point release is put out. -Erinn -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 555 bytes Desc: OpenPGP digital signature URL: From chorn at fluxcoil.net Mon Feb 11 18:14:15 2013 From: chorn at fluxcoil.net (Christian Horn) Date: Mon, 11 Feb 2013 19:14:15 +0100 Subject: [Freeipa-users] Postponing IPA 3 upgrade In-Reply-To: References: Message-ID: <20130211181415.GA13989@fluxcoil.net> On Mon, Feb 11, 2013 at 12:00:22PM -0500, Rashard.Kelly at SITA.aero wrote: > I was wondering if I need to be concerned about IPA 2 being updated > automatically to IPA 3? We have a working IPA 2 environment in place now > and wanted to know if IPA needed to be added to an exclude list. We are > afraid of breaking our current setup. When IPA 3 is released will yum > automatically upgrade it to 3 or will that be something that we have to > manually issue? If you have the old system only receiving z-stream updates, so i.e. 6.3.z for a RHEL6.3 then you will stay on ipa2. I just tested the upgrade of a populated ipa2/rhel6.3 to rhel6.4 . Without a 'exclude=ipa*' in yum.conf the ipa is upgraded like all other packages when the system gets a RHEL6.4 repo configured and 'yum update' is executed. The release notes do not note any special upgrade procedure, also for my testsetup the upgrade went without any issues. Thus all points at that upgrade path is ok, as for all other packages. cheers, Christian From rcritten at redhat.com Mon Feb 11 18:25:56 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 11 Feb 2013 13:25:56 -0500 Subject: [Freeipa-users] Postponing IPA 3 upgrade In-Reply-To: <20130211181415.GA13989@fluxcoil.net> References: <20130211181415.GA13989@fluxcoil.net> Message-ID: <511937B4.4020709@redhat.com> Christian Horn wrote: > On Mon, Feb 11, 2013 at 12:00:22PM -0500, Rashard.Kelly at SITA.aero wrote: >> I was wondering if I need to be concerned about IPA 2 being updated >> automatically to IPA 3? We have a working IPA 2 environment in place now >> and wanted to know if IPA needed to be added to an exclude list. We are >> afraid of breaking our current setup. When IPA 3 is released will yum >> automatically upgrade it to 3 or will that be something that we have to >> manually issue? > > If you have the old system only receiving z-stream updates, so i.e. > 6.3.z for a RHEL6.3 then you will stay on ipa2. > > I just tested the upgrade of a populated ipa2/rhel6.3 to rhel6.4 . > Without a 'exclude=ipa*' in yum.conf the ipa is upgraded like all > other packages when the system gets a RHEL6.4 repo configured and > 'yum update' is executed. > The release notes do not note any special upgrade procedure, also > for my testsetup the upgrade went without any issues. > > Thus all points at that upgrade path is ok, as for all other packages. I would add that I would be careful about only excluding the IPA packages. We rely on a lot of other subsystemsand mixing versions may not work as expected. In particular 389-ds-base, pki-core and krb5-*. We are experimenting with a strict subpackage in Fedora to address this, to prevent a set of other packages from being upgraded, but it isn't quite ready for prime-time. rob From chorn at fluxcoil.net Mon Feb 11 19:06:26 2013 From: chorn at fluxcoil.net (Christian Horn) Date: Mon, 11 Feb 2013 20:06:26 +0100 Subject: [Freeipa-users] Postponing IPA 3 upgrade In-Reply-To: <511937B4.4020709@redhat.com> References: <20130211181415.GA13989@fluxcoil.net> <511937B4.4020709@redhat.com> Message-ID: <20130211190626.GA14158@fluxcoil.net> On Mon, Feb 11, 2013 at 01:25:56PM -0500, Rob Crittenden wrote: > Christian Horn wrote: > > > >If you have the old system only receiving z-stream updates, so i.e. > >6.3.z for a RHEL6.3 then you will stay on ipa2. > > > >I just tested the upgrade of a populated ipa2/rhel6.3 to rhel6.4 . > >Without a 'exclude=ipa*' in yum.conf the ipa is upgraded like all > >other packages when the system gets a RHEL6.4 repo configured and > >'yum update' is executed. > >The release notes do not note any special upgrade procedure, also > >for my testsetup the upgrade went without any issues. > > > >Thus all points at that upgrade path is ok, as for all other packages. > > I would add that I would be careful about only excluding the IPA > packages. We rely on a lot of other subsystemsand mixing versions > may not work as expected. In particular 389-ds-base, pki-core and > krb5-*. Cant we then just tie the ipa packages to the older 389-ds-base etc. package versions? Christian From eivind at aminor.no Mon Feb 11 19:12:05 2013 From: eivind at aminor.no (Eivind Olsen) Date: Mon, 11 Feb 2013 20:12:05 +0100 Subject: [Freeipa-users] The htaccess login pop-up window appears but login never succeeds In-Reply-To: References: <5118B875.2090707@redhat.com> Message-ID: Rajnesh Kumar Siwal wrote: > Thanks, Petr, > > I would like to confirm that I did not manually install any other > application on it. > I will dig further on it , if I could fetch out the reason. Did you get any closer to finding out what's causing this? I get the same kind of pop-up window here, but only in some web browsers: I get the pop-up in MS Internet Explorer and Google Chrome, but not in Firefox. Opera gives me a "Unknown Error" instead. (this is on RHEL 6.3 w/IPA 2.2.0-17, btw) Regards Eivind Olsen From eivind at aminor.no Mon Feb 11 19:16:29 2013 From: eivind at aminor.no (Eivind Olsen) Date: Mon, 11 Feb 2013 20:16:29 +0100 Subject: [Freeipa-users] The htaccess login pop-up window appears but login never succeeds In-Reply-To: References: <5118B875.2090707@redhat.com> Message-ID: <27ea6fc2aa55ff42c7d897d47c61a3ce.squirrel@webmail.aminor.no> Eivind Olsen wrote: > Did you get any closer to finding out what's causing this? I get the same > kind of pop-up window here, but only in some web browsers: I get the > pop-up in MS Internet Explorer and Google Chrome, but not in Firefox. > Opera gives me a "Unknown Error" instead. > (this is on RHEL 6.3 w/IPA 2.2.0-17, btw) Hm, I normally try to not reply to myself, but thought I'd add that after upgrading Opera from 11.x to 12.14 I no longer get the "Unknown Error", but instead I get a login pop-up just like I did with MSIE and Chrome. Regards Eivind Olsen From rcritten at redhat.com Mon Feb 11 19:26:06 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 11 Feb 2013 14:26:06 -0500 Subject: [Freeipa-users] Postponing IPA 3 upgrade In-Reply-To: <20130211190626.GA14158@fluxcoil.net> References: <20130211181415.GA13989@fluxcoil.net> <511937B4.4020709@redhat.com> <20130211190626.GA14158@fluxcoil.net> Message-ID: <511945CE.10302@redhat.com> Christian Horn wrote: > On Mon, Feb 11, 2013 at 01:25:56PM -0500, Rob Crittenden wrote: >> Christian Horn wrote: >>> >>> If you have the old system only receiving z-stream updates, so i.e. >>> 6.3.z for a RHEL6.3 then you will stay on ipa2. >>> >>> I just tested the upgrade of a populated ipa2/rhel6.3 to rhel6.4 . >>> Without a 'exclude=ipa*' in yum.conf the ipa is upgraded like all >>> other packages when the system gets a RHEL6.4 repo configured and >>> 'yum update' is executed. >>> The release notes do not note any special upgrade procedure, also >>> for my testsetup the upgrade went without any issues. >>> >>> Thus all points at that upgrade path is ok, as for all other packages. >> >> I would add that I would be careful about only excluding the IPA >> packages. We rely on a lot of other subsystemsand mixing versions >> may not work as expected. In particular 389-ds-base, pki-core and >> krb5-*. > > Cant we then just tie the ipa packages to the older 389-ds-base etc. > package versions? > > Christian > That's what we're looking into, to have, for example, specific Requires: 389-ds-base = x.y.z rather than >= x.y.z. This introduces other challenges too because we need to allow some amount of flexibility. We just need to find the right balance. rob From chorn at fluxcoil.net Mon Feb 11 19:31:22 2013 From: chorn at fluxcoil.net (Christian Horn) Date: Mon, 11 Feb 2013 20:31:22 +0100 Subject: [Freeipa-users] Postponing IPA 3 upgrade In-Reply-To: <511945CE.10302@redhat.com> References: <20130211181415.GA13989@fluxcoil.net> <511937B4.4020709@redhat.com> <20130211190626.GA14158@fluxcoil.net> <511945CE.10302@redhat.com> Message-ID: <20130211193122.GB14158@fluxcoil.net> On Mon, Feb 11, 2013 at 02:26:06PM -0500, Rob Crittenden wrote: > Christian Horn wrote: > >On Mon, Feb 11, 2013 at 01:25:56PM -0500, Rob Crittenden wrote: > >>Christian Horn wrote: > >>> > >>>If you have the old system only receiving z-stream updates, so i.e. > >>>6.3.z for a RHEL6.3 then you will stay on ipa2. > >>> > >>>I just tested the upgrade of a populated ipa2/rhel6.3 to rhel6.4 . > >>>Without a 'exclude=ipa*' in yum.conf the ipa is upgraded like all > >>>other packages when the system gets a RHEL6.4 repo configured and > >>>'yum update' is executed. > >>>The release notes do not note any special upgrade procedure, also > >>>for my testsetup the upgrade went without any issues. > >>> > >>>Thus all points at that upgrade path is ok, as for all other packages. > >> > >>I would add that I would be careful about only excluding the IPA > >>packages. We rely on a lot of other subsystemsand mixing versions > >>may not work as expected. In particular 389-ds-base, pki-core and > >>krb5-*. > > > >Cant we then just tie the ipa packages to the older 389-ds-base etc. > >package versions? > > > >Christian > > > > That's what we're looking into, to have, for example, specific > Requires: 389-ds-base = x.y.z rather than >= x.y.z. This introduces > other challenges too because we need to allow some amount of > flexibility. We just need to find the right balance. Ah, thanks for the background. I think somewhere in the RHEL support docs we also have a place which reads like 'all previously released errata should be applied'. This also hints that this strict tieing is not done in other places, and using 'exclude' for RHEL packages should not be done often. Seen it mostly to hold back kernel and glibc updates, to have them applied at a convenient time with a reboot. Christian From Steven.Jones at vuw.ac.nz Mon Feb 11 21:05:40 2013 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Mon, 11 Feb 2013 21:05:40 +0000 Subject: [Freeipa-users] Postponing IPA 3 upgrade In-Reply-To: References: Message-ID: <833D8E48405E064EBC54C84EC6B36E4071089661@STAWINCOX10MBX1.staff.vuw.ac.nz> Personally Im very worried, 6.2 to 6.3 went badly and this looks like a bigger upgrade :( 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 Rashard.Kelly at sita.aero [Rashard.Kelly at sita.aero] Sent: Tuesday, 12 February 2013 6:00 a.m. To: freeipa-users at redhat.com Subject: [Freeipa-users] Postponing IPA 3 upgrade I was wondering if I need to be concerned about IPA 2 being updated automatically to IPA 3? We have a working IPA 2 environment in place now and wanted to know if IPA needed to be added to an exclude list. We are afraid of breaking our current setup. When IPA 3 is released will yum automatically upgrade it to 3 or will that be something that we have to manually issue? Thanks, Rashard This document is strictly confidential and intended only for use by the addressee unless otherwise stated. If you are not the intended recipient, please notify the sender immediately and delete it from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jreg2k at gmail.com Mon Feb 11 22:36:32 2013 From: jreg2k at gmail.com (James James) Date: Mon, 11 Feb 2013 23:36:32 +0100 Subject: [Freeipa-users] ipa-replica-prepare failed In-Reply-To: <5116FF13.20403@redhat.com> References: <51147A4D.8020508@redhat.com> <51150122.9010208@redhat.com> <51156432.3000707@redhat.com> <511579F7.7000105@redhat.com> <5116FF13.20403@redhat.com> Message-ID: Thanks you Rob. My replica is workin now. :) 2013/2/10 Rob Crittenden > James James wrote: > >> Maybe I am stupid or tired (or both ..) but I have tried many thing to >> include the ca cert, the ipa key and pem file in a single pkcs12 file >> but I am still stucked. >> >> Can you give me a more detailled help ? >> > > Well, this is one of the reasons we're deprecating this feature, because > it hasn't been well-tested since v1 and is ridden with corner cases. > > I think the only solution is going to be to in direct code changes to the > IPA python scripts to match what your PKCS#12 files contain. If it is > signed by a root CA then chances are if you simply skip the step where the > CA is loaded and trusted then things may just work. > > It is failing in ipaserver/install/certs.p12 in the call to > find_root_cert_from_pkcs12(). Either it is simply an issue of our > identifying the CA or one isn't being loaded at all. > > You can do: certutil -L -d /etc/dirsrv/slapd-YOUR_REALM to list the > certificates that were loaded. It may be that the CA was loaded but we > aren't detecting the nickname, in which case you could simply hardcode it > into the python file for a workaround, something like: > > ca_names = ['CA nickname'] > > rob > >> >> >> 2013/2/8 Rob Crittenden > >> >> >> James James wrote: >> >> OK .. but I have to put the pkc12 file in /etc/pki/nssdb ? >> >> >> No. The PKCS#12 file that contains your server private key and cert >> needs to also contain the CA that signed it. >> >> rob >> >> >> >> 2013/2/8 Rob Crittenden > > >> >> >> >> >> James James wrote: >> >> Now on the replica server I've got this error : >> Run connection check to master >> 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 >> creation of replica failed: Could not find a CA cert in >> /tmp/tmp21VpT8ipa/realm_info/_**___dscert.p12 >> >> >> >> Your system may be partly configured. >> Run /usr/sbin/ipa-server-install --uninstall to clean up. >> >> >> Where I have to put the CA certficate ? >> >> >> It needs to be in the PKCS#12 file. >> >> rob >> >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bin.echo at gmail.com Tue Feb 12 00:30:42 2013 From: bin.echo at gmail.com (bin.echo at gmail.com) Date: Mon, 11 Feb 2013 17:30:42 -0700 Subject: [Freeipa-users] Fedora 17 ipa.service fails to load with "ipa.service failed to load. No such file or directory." In-Reply-To: <5118BE80.3030308@redhat.com> References: <5118BE80.3030308@redhat.com> Message-ID: RESOLVED Thanks Martin. After a good nights sleep and your input I was able to focus on the correct details. sssd was failing to start at boot due to too much time skew. I just had to know where to focus my search. This reveals the inadequacy of the poor-mans time sync we are doing right now. In this setup, the FreeIPA server is the master time server but it's only running on it's own system clock. Due to the nature of the setup of our current project, we are not allowed access to the Internet so we can't use Internet based timeservers inside the secure portion of our network. I may need to ask permission to create a small hole allowing a route out to the some time servers, or I might need to get one of those GPS time servers for inside the walled garden because I can see this issue really dogging us. -Aaron On Mon, Feb 11, 2013 at 2:48 AM, Martin Kosek wrote: > On 02/10/2013 08:15 AM, bin.echo at gmail.com wrote: > > Here is what I did: > > > > Install Fedora 17 XFCE spin. > > > > yum upgrade > > > > yum install freeipa-client > > > > enroll machine (it enrolls just fine) > > > > However, when I reboot the machine, I find the ipa.service isn't > running. So I > > manually try to start it: > > > > systemcrl start ipa.service > > > > Then I get this error > > Failed to issue method call: Unit ipa.service failed to load: No such > file or > > directory. See system logs and 'systemctrl status ipa.service' for > details. > > > > systemctrl status ipa.service proveide no additional useful information. > It > > simply tells me there is a directory missing also. > > > > Grepping all of /var/log turns up nothing useful. > > > > I have no idea what directory ipa.service feels it is missing. > > > > I'm stumped. Any pointers? > > > > thanks, > > -Aaron > > Hello Aaron, > > ipa.service is packaged in freeipa-server package. It is a service > controlling > IPA _server_ services (configured by ipa-server-install), i.e. Directory > Server, Kerberos KDC, PKI CA, ... It is not needed to be run on pure client > machine. > > The client machine does not have a unified ipa service, but only services > you > configured during ipa-client-install, for example sssd service. > > HTH, > Martin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Tue Feb 12 01:19:46 2013 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 11 Feb 2013 20:19:46 -0500 Subject: [Freeipa-users] The htaccess login pop-up window appears but login never succeeds In-Reply-To: <27ea6fc2aa55ff42c7d897d47c61a3ce.squirrel@webmail.aminor.no> References: <5118B875.2090707@redhat.com> <27ea6fc2aa55ff42c7d897d47c61a3ce.squirrel@webmail.aminor.no> Message-ID: <511998B2.60902@redhat.com> On 02/11/2013 02:16 PM, Eivind Olsen wrote: > Eivind Olsen wrote: > >> Did you get any closer to finding out what's causing this? I get the same >> kind of pop-up window here, but only in some web browsers: I get the >> pop-up in MS Internet Explorer and Google Chrome, but not in Firefox. >> Opera gives me a "Unknown Error" instead. >> (this is on RHEL 6.3 w/IPA 2.2.0-17, btw) > Hm, I normally try to not reply to myself, but thought I'd add that after > upgrading Opera from 11.x to 12.14 I no longer get the "Unknown Error", > but instead I get a login pop-up just like I did with MSIE and Chrome. > > Regards > Eivind Olsen So which versions of the browsers we are talking about? I wonder if you hitting the case when the method we used on configuring the browser does not work any more on the newer browsers. We saw some problems with latest versions of FF so we had add a fix for 3.0. If your initial configuration did not happen properly you might need to configure you browser manually. There is a procedure in the manual regarding configuring the browser. > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Tue Feb 12 01:22:11 2013 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 11 Feb 2013 20:22:11 -0500 Subject: [Freeipa-users] User Migrated from LDAP not able to change the password In-Reply-To: References: Message-ID: <51199943.4040202@redhat.com> On 02/10/2013 11:22 PM, Rajnesh Kumar Siwal wrote: > The details are as follows:- > > [root at ipa1 ~]# ipa pwpolicy-show > Group: global_policy > Max lifetime (days): 90 > Min lifetime (hours): 1 > History size: 0 > Character classes: 0 > Min length: 12 > Max failures: 6 > Failure reset interval: 60 > Lockout duration: 600 > [root at ipa1 ~]# ipa user-show siwal --all --raw > dn: uid=siwal,cn=users,cn=accounts,dc=xyz,dc=dmz > uid: siwal > sn: Kumar > cn: siwal > homedirectory: /home/siwal > loginshell: /bin/bash > krbprincipalname: siwal at XYZ.DMZ > uidnumber: 522 > gidnumber: 522 > nsaccountlock: False > has_password: True > has_keytab: True > ipauniqueid: 65775332-712f-11e2-b3cc-000c298a58a4 > krblastpwdchange: 20130208035343Z > krblastsuccessfulauth: 20130208035929Z > krbpasswordexpiration: 20130208035343Z > memberof: cn=ipausers,cn=groups,cn=accounts,dc=xyz,dc=dmz > memberofindirect: cn=software,cn=groups,cn=accounts,dc=xyz,dc=dmz > objectclass: krbticketpolicyaux > objectclass: ipaobject > objectclass: organizationalperson > objectclass: top > objectclass: ipasshuser > objectclass: inetorgperson > objectclass: person > objectclass: inetuser > objectclass: krbprincipalaux > objectclass: shadowaccount > objectclass: posixaccount > objectclass: ipaSshGroupOfPubKeys > shadowlastchange: 14879 > shadowmax: 99999 > shadowmin: 0 > shadowwarning: 7 > > Shadow? Is this normal for IPA accounts? I do not remember seeing it before. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Tue Feb 12 03:19:47 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 11 Feb 2013 22:19:47 -0500 Subject: [Freeipa-users] The htaccess login pop-up window appears but login never succeeds In-Reply-To: <511998B2.60902@redhat.com> References: <5118B875.2090707@redhat.com> <27ea6fc2aa55ff42c7d897d47c61a3ce.squirrel@webmail.aminor.no> <511998B2.60902@redhat.com> Message-ID: <5119B4D3.8010904@redhat.com> Dmitri Pal wrote: > On 02/11/2013 02:16 PM, Eivind Olsen wrote: >> Eivind Olsen wrote: >> >>> Did you get any closer to finding out what's causing this? I get the same >>> kind of pop-up window here, but only in some web browsers: I get the >>> pop-up in MS Internet Explorer and Google Chrome, but not in Firefox. >>> Opera gives me a "Unknown Error" instead. >>> (this is on RHEL 6.3 w/IPA 2.2.0-17, btw) >> Hm, I normally try to not reply to myself, but thought I'd add that after >> upgrading Opera from 11.x to 12.14 I no longer get the "Unknown Error", >> but instead I get a login pop-up just like I did with MSIE and Chrome. >> >> Regards >> Eivind Olsen > > So which versions of the browsers we are talking about? > I wonder if you hitting the case when the method we used on configuring > the browser does not work any more on the newer browsers. > We saw some problems with latest versions of FF so we had add a fix for > 3.0. > If your initial configuration did not happen properly you might need to > configure you browser manually. > There is a procedure in the manual regarding configuring the browser. I just don't know why an authentication dialog would pop up unless KrbMethodK5Passwd was set to on in /etc/httpd/conf.d/ipa.conf. It might be handy to use something like the Live HTTP Headers plugin to capture the dialog to see what is actually being exchanged. rob From rcritten at redhat.com Tue Feb 12 03:21:50 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 11 Feb 2013 22:21:50 -0500 Subject: [Freeipa-users] User Migrated from LDAP not able to change the password In-Reply-To: <51199943.4040202@redhat.com> References: <51199943.4040202@redhat.com> Message-ID: <5119B54E.4010900@redhat.com> Dmitri Pal wrote: > On 02/10/2013 11:22 PM, Rajnesh Kumar Siwal wrote: >> The details are as follows:- >> >> [root at ipa1 ~]# ipa pwpolicy-show >> Group: global_policy >> Max lifetime (days): 90 >> Min lifetime (hours): 1 >> History size: 0 >> Character classes: 0 >> Min length: 12 >> Max failures: 6 >> Failure reset interval: 60 >> Lockout duration: 600 >> [root at ipa1 ~]# ipa user-show siwal --all --raw >> dn: uid=siwal,cn=users,cn=accounts,dc=xyz,dc=dmz >> uid: siwal >> sn: Kumar >> cn: siwal >> homedirectory: /home/siwal >> loginshell: /bin/bash >> krbprincipalname: siwal at XYZ.DMZ >> uidnumber: 522 >> gidnumber: 522 >> nsaccountlock: False >> has_password: True >> has_keytab: True >> ipauniqueid: 65775332-712f-11e2-b3cc-000c298a58a4 >> krblastpwdchange: 20130208035343Z >> krblastsuccessfulauth: 20130208035929Z >> krbpasswordexpiration: 20130208035343Z >> memberof: cn=ipausers,cn=groups,cn=accounts,dc=xyz,dc=dmz >> memberofindirect: cn=software,cn=groups,cn=accounts,dc=xyz,dc=dmz >> objectclass: krbticketpolicyaux >> objectclass: ipaobject >> objectclass: organizationalperson >> objectclass: top >> objectclass: ipasshuser >> objectclass: inetorgperson >> objectclass: person >> objectclass: inetuser >> objectclass: krbprincipalaux >> objectclass: shadowaccount >> objectclass: posixaccount >> objectclass: ipaSshGroupOfPubKeys >> shadowlastchange: 14879 >> shadowmax: 99999 >> shadowmin: 0 >> shadowwarning: 7 >> >> > Shadow? Is this normal for IPA accounts? I do not remember seeing it before. > They have added the shadowAccount objectclass. I also don't see a password policy reference in this user. Does ipa pwpolicy-show --user=siwal return anything? You might check /var/lig/dirsrv/slapd-YOUR_REALM/errors for any issues. And note that there is a minimum lifetime on passwords so they can't be changed too quickly. rob From rajnesh.siwal at gmail.com Tue Feb 12 04:41:52 2013 From: rajnesh.siwal at gmail.com (Rajnesh Kumar Siwal) Date: Tue, 12 Feb 2013 10:11:52 +0530 Subject: [Freeipa-users] User Migrated from LDAP not able to change the password Message-ID: We migrated the Users from OpenLDAP where we were using the objectClass 'ShadowAccount' for the Password Expiration and Warning, So, it has been added by the IPA migration part. [root at ipa1 ~]# ipa pwpolicy-show --user=siwal Group: global_policy Max lifetime (days): 90 Min lifetime (hours): 1 History size: 0 Character classes: 0 Min length: 12 Max failures: 6 Failure reset interval: 60 Lockout duration: 600 -- Regards, Rajnesh Kumar Siwal From chorn at fluxcoil.net Tue Feb 12 07:30:14 2013 From: chorn at fluxcoil.net (Christian Horn) Date: Tue, 12 Feb 2013 08:30:14 +0100 Subject: [Freeipa-users] Postponing IPA 3 upgrade In-Reply-To: <833D8E48405E064EBC54C84EC6B36E4071089661@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E4071089661@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <20130212073014.GB15541@fluxcoil.net> On Mon, Feb 11, 2013 at 09:05:40PM +0000, Steven Jones wrote: > Personally Im very worried, 6.2 to 6.3 went badly and this looks like a bigger upgrade I might miss something.. but cant one create a "throw away replica" of the old environment, use that then separatedly and try out the upgrade with it? Christian From it.meme01 at gmail.com Tue Feb 12 17:42:06 2013 From: it.meme01 at gmail.com (It Meme) Date: Tue, 12 Feb 2013 09:42:06 -0800 Subject: [Freeipa-users] Python Client In-Reply-To: <5117BDA3.4070800@redhat.com> References: <51167F24.30904@redhat.com> <5117BDA3.4070800@redhat.com> Message-ID: <31827C39-36BA-4510-8718-29318A0A9746@gmail.com> Yes - Dmitri is correct. Our purchased IAM product has LDAP connectors. It is possible to customize to develop other connector protocols but it requires tweaking the core product code - this adds risk and, if not careful, could break our support with vendor or increase operational risk to a critical production system. The most practical option is to continue to use the LDAP connectors to provision accounts to directory server. If we use IPA, that would mean provisioning accounts, from our IAM product to IPA, via LDAP (Step 1) - and subsequently running a script that will call the python libraries to IPA-ize the provisioned accounts (Step 2). It will assist our help desk staff if 'Step 1' provisioned accounts were created in main accounts tree in IPA - then subsequent script will IPA-ize the accounts for 'Step 2' and accounts will be updated in same tree. Any gotchas foreseen with above? We have larger user base with ~40K new accounts per year and 600K ongoing - automating the tasks in stable systems, and having help desk insight to account statuses are critical items for management. Thank you for your help, insights, input - they are very helpful and greatly appreciated. On 2013-02-10, at 7:32, Dmitri Pal wrote: > On 02/09/2013 11:53 AM, John Dennis wrote: >> On 02/08/2013 05:29 PM, It Meme wrote: >>> Hi: >>> >>> Scenario: >>> >>> 1) User is created via LDAP call to IPA (i.e.the 389 Directory Server) >>> >>> The above user will not have IPA-specific attributes. >>> >>> Can we use the Python Library, or CLI, to modify the account to >>> IPA-ize it? >> >> You're really better off using the IPA API directly rather than trying >> to bypass it. Why? Because we implement additional logic inside the >> commands. If you could achieve everything IPA does by just modifying >> an LDAP server there wouldn't be a need for IPA. A good example of >> this is group membership, some of that logic is handled directly by a >> plugin to the 389 DS, but a large part of it is implemented in the IPA >> commands that manage users and groups. You really don't want to bypass >> it. >> >> You have a number of options on how to call the IPA commands: >> >> 1) the ipa command line client >> >> 2) sending the command formatted in JSON to the server >> >> 3) sending the command formatted in XML-RPC to the server >> >> 4) calling the command from your own python code >> >> 5) using the web GUI >> >> It's really not hard to call the IPA command line client from a >> program, typically this is done via a "system" command of which there >> are a number of variants. >> >> The following thread has a discussion of how to invoke one of our >> commands from Python code, this particular email response from Martin >> shows how it can be done in in about half a dozen lines of code. >> >> https://www.redhat.com/archives/freeipa-users/2012-June/msg00334.html >> >> What I'm not understanding why you're avoiding using the commands we >> provide. If you're not familiar with how to call another >> program/process we can help you or just google it. Or is the problem >> your existing management system does not provide you with any "hooks" >> to execute code when an action occurs. But from everything you've said >> so far you imply it does provide such hooks. Perhaps if you could be >> more specific we could be more helpful. > It seems that the management system in question can insert an entry into > LDAP but can't do the "generic" hook. > I bet this is the issue here. > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From jorick at netbulae.eu Tue Feb 12 17:57:58 2013 From: jorick at netbulae.eu (Jorick Astrego) Date: Tue, 12 Feb 2013 18:57:58 +0100 Subject: [Freeipa-users] Postponing IPA 3 upgrade In-Reply-To: <20130212073014.GB15541@fluxcoil.net> References: <833D8E48405E064EBC54C84EC6B36E4071089661@STAWINCOX10MBX1.staff.vuw.ac.nz> <20130212073014.GB15541@fluxcoil.net> Message-ID: <511A82A6.1050201@netbulae.eu> On 02/12/2013 08:30 AM, Christian Horn wrote: > On Mon, Feb 11, 2013 at 09:05:40PM +0000, Steven Jones wrote: >> Personally Im very worried, 6.2 to 6.3 went badly and this looks like a bigger upgrade > I might miss something.. but cant one create a "throw away replica" > of the old environment, use that then separatedly and try out the > upgrade with it? > > Christian > He could if he has spare hardware laying around. Or if he is running it virtulized you could clone the vm easily and test it on a virtual network not connected to the rest. But if you read Rashard's post correctly, he is afraid of yum automatically updating freeIPA and breaking it. @ Rashard You should not be letting yum update automatically but use Katello, Red Hat Network Satellite or Spacewalk to install updates. Still I would like to know the same. Some other projects use version dependant repo's so you can choose to switch by changing repo, others put the version number in the package name. -- Kind Regards, Jorick Astrego Netbulae B.V. Site: http://www.netbulae.eu From Rashard.Kelly at sita.aero Tue Feb 12 18:21:26 2013 From: Rashard.Kelly at sita.aero (Rashard.Kelly at sita.aero) Date: Tue, 12 Feb 2013 13:21:26 -0500 Subject: [Freeipa-users] Postponing IPA 3 upgrade In-Reply-To: <511A82A6.1050201@netbulae.eu> References: <833D8E48405E064EBC54C84EC6B36E4071089661@STAWINCOX10MBX1.staff.vuw.ac.nz> <20130212073014.GB15541@fluxcoil.net> <511A82A6.1050201@netbulae.eu> Message-ID: Thanks for all the replies, We are using Red Hat Satellite Server to handle Yum updates but I am still getting a grasp on how it works. After talking to one of our admins, I was told that it should not do a major version upgrade without being explicitly told to. The servers are virtual so I will clone them off before the next patch cycles. Is there an official go-live date for IPA3 in RHEL? Thanks, Rashard From: Jorick Astrego To: Christian Horn Cc: freeipa-users at redhat.com Date: 02/12/2013 01:04 PM Subject: Re: [Freeipa-users] Postponing IPA 3 upgrade Sent by: freeipa-users-bounces at redhat.com On 02/12/2013 08:30 AM, Christian Horn wrote: > On Mon, Feb 11, 2013 at 09:05:40PM +0000, Steven Jones wrote: >> Personally Im very worried, 6.2 to 6.3 went badly and this looks like a bigger upgrade > I might miss something.. but cant one create a "throw away replica" > of the old environment, use that then separatedly and try out the > upgrade with it? > > Christian > He could if he has spare hardware laying around. Or if he is running it virtulized you could clone the vm easily and test it on a virtual network not connected to the rest. But if you read Rashard's post correctly, he is afraid of yum automatically updating freeIPA and breaking it. @ Rashard You should not be letting yum update automatically but use Katello, Red Hat Network Satellite or Spacewalk to install updates. Still I would like to know the same. Some other projects use version dependant repo's so you can choose to switch by changing repo, others put the version number in the package name. -- Kind Regards, Jorick Astrego Netbulae B.V. Site: http://www.netbulae.eu _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users This document is strictly confidential and intended only for use by the addressee unless otherwise stated. If you are not the intended recipient, please notify the sender immediately and delete it from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jreg2k at gmail.com Tue Feb 12 18:34:22 2013 From: jreg2k at gmail.com (James James) Date: Tue, 12 Feb 2013 19:34:22 +0100 Subject: [Freeipa-users] Account Expiration In-Reply-To: <51135B8C.5070001@redhat.com> References: <5106A043.1070103@redhat.com> <51131E6C.7030103@redhat.com> <51135B8C.5070001@redhat.com> Message-ID: Can you tell me how update my ipa's files once when ticket https://fedorahosted.org/freeipa/ticket/3306 will be fixed ? Should I have to do 'yum update ipa*' ? Is it possible to ipa to send a email to user when his account is about to expire (the current date is near krbprincipalexpiration date) ? 2013/2/7 Martin Kosek > On 02/07/2013 08:31 AM, James James wrote: > > Thanks Rob. I have one more question. Is it possible to add a field in > the ui, > > and get the field's value in a custom add user hook script ? > > > > James > > I know that Petr Vobornik is already working in better extensibility of > the UI, > but that would be available in future releases. Petr, do you have any > advice > for James for current release? > > > > > > > 2013/2/7 Rob Crittenden >> > > > > James James wrote: > > > > Can somebody gives me some help to set krbPrincipalExpiration > from the > > freeipa ui ? > > > > > > You can't set this in the web UI. > > Note: You will be able to set it in the CLI/UI when ticket > https://fedorahosted.org/freeipa/ticket/3306 > is fixed. > > > > > You can do it from the command line using ldapmodify with: > > > > $ ldapmodify -x -D 'cn=Directory Manager' -W > > Enter LDAP Password: > > dn: uid=tuser1,cn=users,cn=__accounts,dc=example,dc=com > > changetype: modify > > replace: krbPasswordExpiration > > krbPasswordExpiration: 20200508032114Z > > > > ^D > > This would change password expiration attribute. So for account > expiration, you > would just need to replace krbPasswordExpiration modification above with > krbPrincipalExpiration. > > Martin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Tue Feb 12 18:40:08 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 12 Feb 2013 13:40:08 -0500 Subject: [Freeipa-users] Account Expiration In-Reply-To: References: <5106A043.1070103@redhat.com> <51131E6C.7030103@redhat.com> <51135B8C.5070001@redhat.com> Message-ID: <511A8C88.7000001@redhat.com> James James wrote: > Can you tell me how update my ipa's files once when ticket > https://fedorahosted.org/freeipa/ticket/3306 will be fixed ? > > Should I have to do 'yum update ipa*' ? Once it gets fixed upstream and packaged into a release, yes, that is what you would do. > Is it possible to ipa to send a email to user when his account is about > to expire (the current date is near krbprincipalexpiration date) ? Not currently. In 3.0+ we will provide a notice when one logs into the WebUI but that's it. We can't be sure that an MTA is properly configured on the IPA server at install time so we have punted on this for a while. We don't want to get into the business of picking and configuring one. This is one of those things that seems really easy but gets complicated the deeper you dig into it. We're open to suggestions/patches. regards rob > > > 2013/2/7 Martin Kosek > > > On 02/07/2013 08:31 AM, James James wrote: > > Thanks Rob. I have one more question. Is it possible to add a > field in the ui, > > and get the field's value in a custom add user hook script ? > > > > James > > I know that Petr Vobornik is already working in better extensibility > of the UI, > but that would be available in future releases. Petr, do you have > any advice > for James for current release? > > > > > > > 2013/2/7 Rob Crittenden >> > > > > James James wrote: > > > > Can somebody gives me some help to set > krbPrincipalExpiration from the > > freeipa ui ? > > > > > > You can't set this in the web UI. > > Note: You will be able to set it in the CLI/UI when ticket > https://fedorahosted.org/freeipa/ticket/3306 > is fixed. > > > > > You can do it from the command line using ldapmodify with: > > > > $ ldapmodify -x -D 'cn=Directory Manager' -W > > Enter LDAP Password: > > dn: uid=tuser1,cn=users,cn=__accounts,dc=example,dc=com > > changetype: modify > > replace: krbPasswordExpiration > > krbPasswordExpiration: 20200508032114Z > > > > ^D > > This would change password expiration attribute. So for account > expiration, you > would just need to replace krbPasswordExpiration modification above with > krbPrincipalExpiration. > > Martin > > From jdennis at redhat.com Tue Feb 12 19:21:52 2013 From: jdennis at redhat.com (John Dennis) Date: Tue, 12 Feb 2013 14:21:52 -0500 Subject: [Freeipa-users] Account Expiration In-Reply-To: <511A8C88.7000001@redhat.com> References: <5106A043.1070103@redhat.com> <51131E6C.7030103@redhat.com> <51135B8C.5070001@redhat.com> <511A8C88.7000001@redhat.com> Message-ID: <511A9650.7030302@redhat.com> On 02/12/2013 01:40 PM, Rob Crittenden wrote: >> Is it possible to ipa to send a email to user when his account is about >> to expire (the current date is near krbprincipalexpiration date) ? > > Not currently. In 3.0+ we will provide a notice when one logs into the > WebUI but that's it. > > We can't be sure that an MTA is properly configured on the IPA server at > install time so we have punted on this for a while. We don't want to get > into the business of picking and configuring one. This is one of those > things that seems really easy but gets complicated the deeper you dig > into it. We're open to suggestions/patches. Yeah, I don't think we want to be in the business of installing and configuring an MTA. However, we should be able to detect if one is available and use it if it is. I think it would be reasonable to restrict it to LMTP with a Unix domain socket (most MTA's support this). Then our config would have a LMTP domain socket pathname, if that pathname exists and we can connect to it we use, if not we fallback to not generating any mail. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From Steven.Jones at vuw.ac.nz Tue Feb 12 20:03:09 2013 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Tue, 12 Feb 2013 20:03:09 +0000 Subject: [Freeipa-users] Postponing IPA 3 upgrade In-Reply-To: <20130212073014.GB15541@fluxcoil.net> References: <833D8E48405E064EBC54C84EC6B36E4071089661@STAWINCOX10MBX1.staff.vuw.ac.nz>, <20130212073014.GB15541@fluxcoil.net> Message-ID: <833D8E48405E064EBC54C84EC6B36E407108BAFC@STAWINCOX10MBX1.staff.vuw.ac.nz> Trouble is getting the rpms to upgrade... 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 Christian Horn [chorn at fluxcoil.net] Sent: Tuesday, 12 February 2013 8:30 p.m. To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Postponing IPA 3 upgrade On Mon, Feb 11, 2013 at 09:05:40PM +0000, Steven Jones wrote: > Personally Im very worried, 6.2 to 6.3 went badly and this looks like a bigger upgrade I might miss something.. but cant one create a "throw away replica" of the old environment, use that then separatedly and try out the upgrade with it? Christian _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users From Steven.Jones at vuw.ac.nz Tue Feb 12 20:09:03 2013 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Tue, 12 Feb 2013 20:09:03 +0000 Subject: [Freeipa-users] Postponing IPA 3 upgrade In-Reply-To: References: <833D8E48405E064EBC54C84EC6B36E4071089661@STAWINCOX10MBX1.staff.vuw.ac.nz> <20130212073014.GB15541@fluxcoil.net> <511A82A6.1050201@netbulae.eu>, Message-ID: <833D8E48405E064EBC54C84EC6B36E407108BB1F@STAWINCOX10MBX1.staff.vuw.ac.nz> We have Sat..... Create a clone channel of RHEL6.3 say today. You then have a known patch set channel that wont change, point the IPA servers at it. So we have a raw/std RHEL channel in Sat, a testing channel that is 2~4 weeks old and a prod channel we clone off the testing channel(s) once we are happy so thats 4~8 weeks old. So I build using the std/raw channel and move the server to one or other depending on its end use. 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 Rashard.Kelly at sita.aero [Rashard.Kelly at sita.aero] Sent: Wednesday, 13 February 2013 7:21 a.m. To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Postponing IPA 3 upgrade Thanks for all the replies, We are using Red Hat Satellite Server to handle Yum updates but I am still getting a grasp on how it works. After talking to one of our admins, I was told that it should not do a major version upgrade without being explicitly told to. The servers are virtual so I will clone them off before the next patch cycles. Is there an official go-live date for IPA3 in RHEL? Thanks, Rashard From: Jorick Astrego To: Christian Horn Cc: freeipa-users at redhat.com Date: 02/12/2013 01:04 PM Subject: Re: [Freeipa-users] Postponing IPA 3 upgrade Sent by: freeipa-users-bounces at redhat.com ________________________________ On 02/12/2013 08:30 AM, Christian Horn wrote: > On Mon, Feb 11, 2013 at 09:05:40PM +0000, Steven Jones wrote: >> Personally Im very worried, 6.2 to 6.3 went badly and this looks like a bigger upgrade > I might miss something.. but cant one create a "throw away replica" > of the old environment, use that then separatedly and try out the > upgrade with it? > > Christian > He could if he has spare hardware laying around. Or if he is running it virtulized you could clone the vm easily and test it on a virtual network not connected to the rest. But if you read Rashard's post correctly, he is afraid of yum automatically updating freeIPA and breaking it. @ Rashard You should not be letting yum update automatically but use Katello, Red Hat Network Satellite or Spacewalk to install updates. Still I would like to know the same. Some other projects use version dependant repo's so you can choose to switch by changing repo, others put the version number in the package name. -- Kind Regards, Jorick Astrego Netbulae B.V. Site: http://www.netbulae.eu _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users This document is strictly confidential and intended only for use by the addressee unless otherwise stated. If you are not the intended recipient, please notify the sender immediately and delete it from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: From it.meme01 at gmail.com Tue Feb 12 20:15:49 2013 From: it.meme01 at gmail.com (It Meme) Date: Tue, 12 Feb 2013 12:15:49 -0800 Subject: [Freeipa-users] IPA Account - Managed by LDAP Calls Message-ID: Hi: Assumption: Accounts have been provisioned in IPA. Can the IPA provisioned accounts be subsequently managed by LDAP calls from an external system? Examples: password update, group membership. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Tue Feb 12 20:24:41 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 12 Feb 2013 15:24:41 -0500 Subject: [Freeipa-users] IPA Account - Managed by LDAP Calls In-Reply-To: References: Message-ID: <511AA509.3020101@redhat.com> It Meme wrote: > Hi: > > Assumption: Accounts have been provisioned in IPA. > > Can the IPA provisioned accounts be subsequently managed by LDAP calls > from an external system? Examples: password update, group membership. Password update via LDAP: yes Group membership is just properly adding a member attribute with the DN of the member into the right location, so yeah. This may depend on the access rights of the user doing the change. Note that this is potentially dangerous. For example, our management framework prevents the last user from being removed from the admins group. If you do this via LDAP you lose that protection. rob From rcritten at redhat.com Tue Feb 12 20:39:19 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 12 Feb 2013 15:39:19 -0500 Subject: [Freeipa-users] Postponing IPA 3 upgrade In-Reply-To: <833D8E48405E064EBC54C84EC6B36E407108BAFC@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E4071089661@STAWINCOX10MBX1.staff.vuw.ac.nz>, <20130212073014.GB15541@fluxcoil.net> <833D8E48405E064EBC54C84EC6B36E407108BAFC@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <511AA877.7090502@redhat.com> Steven Jones wrote: > Trouble is getting the rpms to upgrade... Not sure what you mean. There were some bumps in upgrading IPA v2.1 to 2.2 but they were unrelated to the rpms. The problem was in the LDAP updater and they were generally fairly easily resolved. The resulting upgraded server was missing schema which caused a variety of issues. rob > > > 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 Christian Horn [chorn at fluxcoil.net] > Sent: Tuesday, 12 February 2013 8:30 p.m. > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Postponing IPA 3 upgrade > > On Mon, Feb 11, 2013 at 09:05:40PM +0000, Steven Jones wrote: >> Personally Im very worried, 6.2 to 6.3 went badly and this looks like a bigger upgrade > > I might miss something.. but cant one create a "throw away replica" > of the old environment, use that then separatedly and try out the > upgrade with it? > > Christian > > _______________________________________________ > 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 Steven.Jones at vuw.ac.nz Tue Feb 12 20:57:41 2013 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Tue, 12 Feb 2013 20:57:41 +0000 Subject: [Freeipa-users] Postponing IPA 3 upgrade In-Reply-To: <511AA877.7090502@redhat.com> References: <833D8E48405E064EBC54C84EC6B36E4071089661@STAWINCOX10MBX1.staff.vuw.ac.nz>, <20130212073014.GB15541@fluxcoil.net> <833D8E48405E064EBC54C84EC6B36E407108BAFC@STAWINCOX10MBX1.staff.vuw.ac.nz>, <511AA877.7090502@redhat.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E407108BC3A@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, My cloned copy of IPA is in an isolated network so it has no access to our Sat server or the Internet. So in production we'd just do a yum update, but in the isolated environment I cant do that so the test isnt real world. regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: Rob Crittenden [rcritten at redhat.com] Sent: Wednesday, 13 February 2013 9:39 a.m. To: Steven Jones Cc: Christian Horn; freeipa-users at redhat.com Subject: Re: [Freeipa-users] Postponing IPA 3 upgrade Steven Jones wrote: > Trouble is getting the rpms to upgrade... Not sure what you mean. There were some bumps in upgrading IPA v2.1 to 2.2 but they were unrelated to the rpms. The problem was in the LDAP updater and they were generally fairly easily resolved. The resulting upgraded server was missing schema which caused a variety of issues. rob > > > 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 Christian Horn [chorn at fluxcoil.net] > Sent: Tuesday, 12 February 2013 8:30 p.m. > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Postponing IPA 3 upgrade > > On Mon, Feb 11, 2013 at 09:05:40PM +0000, Steven Jones wrote: >> Personally Im very worried, 6.2 to 6.3 went badly and this looks like a bigger upgrade > > I might miss something.. but cant one create a "throw away replica" > of the old environment, use that then separatedly and try out the > upgrade with it? > > Christian > > _______________________________________________ > 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 chucklever at gmail.com Tue Feb 12 21:20:45 2013 From: chucklever at gmail.com (Chuck Lever) Date: Tue, 12 Feb 2013 16:20:45 -0500 Subject: [Freeipa-users] ipa-server-install IndexError: list index out of range Message-ID: Hi- I'm new to FreeIPA. I'm installing on an up-to-date Fedora 18 system from the freeipa packages available with Fedora 18. When running ipa-server-install, the install process fails here: Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds [1/20]: creating certificate server user ... [15/20]: requesting RA certificate from CA Unexpected error - see /var/log/ipaserver-install.log for details: IndexError: list index out of range The tail of the installer log looks like this: Generating key. This may take a few moments... 2013-02-12T21:04:46Z INFO File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 617, in run_script return_value = main_function() File "/sbin/ipa-server-install", line 986, in main dm_password, subject_base=options.subject) File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 621, in configure_instance self.start_creation(runtime=210) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 358, in start_creation method() File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 1219, in __request_ra_certificate self.requestId = item_node[0].childNodes[0].data 2013-02-12T21:04:46Z INFO The ipa-server-install command failed, exception: IndexError: list index out of range Is there a workaround or fix available? I haven't found any relevant information via a web search, and a few searches on bugzilla.redhat.com have come up empty. -- Chuck Lever chucklever[at]gmail[dot]com From rcritten at redhat.com Tue Feb 12 21:24:07 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 12 Feb 2013 16:24:07 -0500 Subject: [Freeipa-users] ipa-server-install IndexError: list index out of range In-Reply-To: References: Message-ID: <511AB2F7.8030509@redhat.com> Chuck Lever wrote: > Hi- > > I'm new to FreeIPA. I'm installing on an up-to-date Fedora 18 system from the freeipa packages available with Fedora 18. When running ipa-server-install, the install process fails here: > > Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds > [1/20]: creating certificate server user > ... > [15/20]: requesting RA certificate from CA > Unexpected error - see /var/log/ipaserver-install.log for details: > IndexError: list index out of range > > The tail of the installer log looks like this: > > Generating key. This may take a few moments... > > > 2013-02-12T21:04:46Z INFO File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 617, in run_script > return_value = main_function() > > File "/sbin/ipa-server-install", line 986, in main > dm_password, subject_base=options.subject) > > File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 621, in configure_instance > self.start_creation(runtime=210) > > File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 358, in start_creation > method() > > File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 1219, in __request_ra_certificate > self.requestId = item_node[0].childNodes[0].data > > 2013-02-12T21:04:46Z INFO The ipa-server-install command failed, exception: IndexError: list index out of range > > > Is there a workaround or fix available? I haven't found any relevant information via a web search, and a few searches on bugzilla.redhat.com have come up empty. > We've seen just one other report of this and unfortunately the VM was removed before we could do a lot of diagnosis. What we saw was that certutil output garbage when requesting the RA admin certificate. Can you look in /var/log/ipaserver-install.log for the last certutil command? Does stdout contain a lot of garbage characters in it? It should consist of a base64-encoded CSR. If so, what version of nss and nss-tools do you have installed? rob From chucklever at gmail.com Tue Feb 12 21:26:54 2013 From: chucklever at gmail.com (Chuck Lever) Date: Tue, 12 Feb 2013 16:26:54 -0500 Subject: [Freeipa-users] ipa-server-install IndexError: list index out of range In-Reply-To: <511AB2F7.8030509@redhat.com> References: <511AB2F7.8030509@redhat.com> Message-ID: On Feb 12, 2013, at 4:24 PM, Rob Crittenden wrote: > Chuck Lever wrote: >> Hi- >> >> I'm new to FreeIPA. I'm installing on an up-to-date Fedora 18 system from the freeipa packages available with Fedora 18. When running ipa-server-install, the install process fails here: >> >> Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds >> [1/20]: creating certificate server user >> ... >> [15/20]: requesting RA certificate from CA >> Unexpected error - see /var/log/ipaserver-install.log for details: >> IndexError: list index out of range >> >> The tail of the installer log looks like this: >> >> Generating key. This may take a few moments... >> >> >> 2013-02-12T21:04:46Z INFO File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 617, in run_script >> return_value = main_function() >> >> File "/sbin/ipa-server-install", line 986, in main >> dm_password, subject_base=options.subject) >> >> File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 621, in configure_instance >> self.start_creation(runtime=210) >> >> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 358, in start_creation >> method() >> >> File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 1219, in __request_ra_certificate >> self.requestId = item_node[0].childNodes[0].data >> >> 2013-02-12T21:04:46Z INFO The ipa-server-install command failed, exception: IndexError: list index out of range >> >> >> Is there a workaround or fix available? I haven't found any relevant information via a web search, and a few searches on bugzilla.redhat.com have come up empty. >> > > We've seen just one other report of this and unfortunately the VM was removed before we could do a lot of diagnosis. What we saw was that certutil output garbage when requesting the RA admin certificate. Can you look in /var/log/ipaserver-install.log for the last certutil command? Does stdout contain a lot of garbage characters in it? It should consist of a base64-encoded CSR. 2013-02-12T21:04:29Z DEBUG [15/20]: requesting RA certificate from CA 2013-02-12T21:04:29Z DEBUG Starting external process 2013-02-12T21:04:29Z DEBUG args=/usr/bin/certutil -d /etc/httpd/alias -f XXXXXXXX -R -k rsa -g 2048 -s CN=IPA RA,O=1015GRANGER.NET -z /tmp/tmptIYFZ5 -a 2013-02-12T21:04:33Z DEBUG Process finished, return code=0 2013-02-12T21:04:33Z DEBUG stdout=^X^\^<^@^@^@^X^\^<^@^@^@^P-<85>^B^@^@^@^@^P- <85>^B^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@@^G 8^?^@^@^E^@^@^@^@^@^@<98>^W^<^@^@^@<98>^W^<^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@?<87>^U^^6?^L^R|=^^W^D^N ^\=<9F>^@^@^@^@^@^@^@^@q^E^@^@^@^@^@^@<98>^W^<^@^@^@^P^B^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^Y<85>^B^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^A_<^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@+_<^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^A ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^D^@^@^@^@^@^@<98>^W^<^@^@^@* <85>^B^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@<80><84>^B^@^@^@^@^@^@^@^@^@^@^@^@^@^A^@^@^@^@^@^@P^@^@^@^@^@^@^@^P^B^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@`^B^@^@^@^@^@^@^P^B^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ 2013-02-12T21:04:33Z DEBUG stderr= > If so, what version of nss and nss-tools do you have installed? [root at forain ~]# yum info nss nss-tools Loaded plugins: langpacks, presto, refresh-packagekit Installed Packages Name : nss Arch : x86_64 Version : 3.14.2 Release : 2.fc18 Size : 2.5 M Repo : installed >From repo : updates Summary : Network Security Services URL : http://www.mozilla.org/projects/security/pki/nss/ License : MPLv2.0 Description : Network Security Services (NSS) is a set of libraries designed to : support cross-platform development of security-enabled client and : server applications. Applications built with NSS can support SSL v2 : and v3, TLS, PKCS #5, PKCS #7, PKCS #11, PKCS #12, S/MIME, X.509 : v3 certificates, and other security standards. Name : nss-tools Arch : x86_64 Version : 3.14.2 Release : 2.fc18 Size : 1.7 M Repo : installed >From repo : updates Summary : Tools for the Network Security Services URL : http://www.mozilla.org/projects/security/pki/nss/ License : MPLv2.0 Description : Network Security Services (NSS) is a set of libraries designed to : support cross-platform development of security-enabled client and : server applications. Applications built with NSS can support SSL v2 : and v3, TLS, PKCS #5, PKCS #7, PKCS #11, PKCS #12, S/MIME, X.509 : v3 certificates, and other security standards. : : Install the nss-tools package if you need command-line tools to : manipulate the NSS certificate and key database. Available Packages Name : nss Arch : i686 Version : 3.14.2 Release : 2.fc18 Size : 833 k Repo : updates/18/x86_64 Summary : Network Security Services URL : http://www.mozilla.org/projects/security/pki/nss/ License : MPLv2.0 Description : Network Security Services (NSS) is a set of libraries designed to : support cross-platform development of security-enabled client and : server applications. Applications built with NSS can support SSL v2 : and v3, TLS, PKCS #5, PKCS #7, PKCS #11, PKCS #12, S/MIME, X.509 : v3 certificates, and other security standards. [root at forain ~]# Hope this helps. -- Chuck Lever chucklever[at]gmail[dot]com From jreg2k at gmail.com Tue Feb 12 21:50:17 2013 From: jreg2k at gmail.com (James James) Date: Tue, 12 Feb 2013 22:50:17 +0100 Subject: [Freeipa-users] Account Expiration In-Reply-To: <511A9650.7030302@redhat.com> References: <5106A043.1070103@redhat.com> <51131E6C.7030103@redhat.com> <51135B8C.5070001@redhat.com> <511A8C88.7000001@redhat.com> <511A9650.7030302@redhat.com> Message-ID: Thanks guys for your answers. 2013/2/12 John Dennis > On 02/12/2013 01:40 PM, Rob Crittenden wrote: > >> Is it possible to ipa to send a email to user when his account is about >>> to expire (the current date is near krbprincipalexpiration date) ? >>> >> >> Not currently. In 3.0+ we will provide a notice when one logs into the >> WebUI but that's it. >> >> We can't be sure that an MTA is properly configured on the IPA server at >> install time so we have punted on this for a while. We don't want to get >> into the business of picking and configuring one. This is one of those >> things that seems really easy but gets complicated the deeper you dig >> into it. We're open to suggestions/patches. >> > > Yeah, I don't think we want to be in the business of installing and > configuring an MTA. However, we should be able to detect if one is > available and use it if it is. I think it would be reasonable to restrict > it to LMTP with a Unix domain socket (most MTA's support this). Then our > config would have a LMTP domain socket pathname, if that pathname exists > and we can connect to it we use, if not we fallback to not generating any > mail. > > -- > John Dennis > > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Tue Feb 12 22:08:43 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 12 Feb 2013 17:08:43 -0500 Subject: [Freeipa-users] ipa-server-install IndexError: list index out of range In-Reply-To: References: <511AB2F7.8030509@redhat.com> Message-ID: <511ABD6B.9000505@redhat.com> Chuck Lever wrote: > > On Feb 12, 2013, at 4:24 PM, Rob Crittenden wrote: > >> Chuck Lever wrote: >>> Hi- >>> >>> I'm new to FreeIPA. I'm installing on an up-to-date Fedora 18 system from the freeipa packages available with Fedora 18. When running ipa-server-install, the install process fails here: >>> >>> Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds >>> [1/20]: creating certificate server user >>> ... >>> [15/20]: requesting RA certificate from CA >>> Unexpected error - see /var/log/ipaserver-install.log for details: >>> IndexError: list index out of range >>> >>> The tail of the installer log looks like this: >>> >>> Generating key. This may take a few moments... >>> >>> >>> 2013-02-12T21:04:46Z INFO File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 617, in run_script >>> return_value = main_function() >>> >>> File "/sbin/ipa-server-install", line 986, in main >>> dm_password, subject_base=options.subject) >>> >>> File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 621, in configure_instance >>> self.start_creation(runtime=210) >>> >>> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 358, in start_creation >>> method() >>> >>> File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 1219, in __request_ra_certificate >>> self.requestId = item_node[0].childNodes[0].data >>> >>> 2013-02-12T21:04:46Z INFO The ipa-server-install command failed, exception: IndexError: list index out of range >>> >>> >>> Is there a workaround or fix available? I haven't found any relevant information via a web search, and a few searches on bugzilla.redhat.com have come up empty. >>> >> >> We've seen just one other report of this and unfortunately the VM was removed before we could do a lot of diagnosis. What we saw was that certutil output garbage when requesting the RA admin certificate. Can you look in /var/log/ipaserver-install.log for the last certutil command? Does stdout contain a lot of garbage characters in it? It should consist of a base64-encoded CSR. > > 2013-02-12T21:04:29Z DEBUG [15/20]: requesting RA certificate from CA > 2013-02-12T21:04:29Z DEBUG Starting external process > 2013-02-12T21:04:29Z DEBUG args=/usr/bin/certutil -d /etc/httpd/alias -f XXXXXXXX -R -k > rsa -g 2048 -s CN=IPA RA,O=1015GRANGER.NET -z /tmp/tmptIYFZ5 -a > 2013-02-12T21:04:33Z DEBUG Process finished, return code=0 > 2013-02-12T21:04:33Z DEBUG stdout=^X^\^<^@^@^@^X^\^<^@^@^@^P-<85>^B^@^@^@^@^P- > <85>^B^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ > ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ > ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ > ^@^@^@@^G 8^?^@^@^E^@^@^@^@^@^@<98>^W^<^@^@^@<98>^W^<^@^@^@^@^@^@^@^@^@ > ^@^@^@^@^@^@^@^@^@^@?<87>^U^^6?^L^R|=^^W^D^N > ^\=<9F>^@^@^@^@^@^@^@^@q^E^@^@^@^@^@^@<98>^W^<^@^@^@^P^B^@^@^@^@^@^@ > ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^Y<85>^B^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^A_<^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@+_<^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^A > ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^D^@^@^@^@^@^@<98>^W^<^@^@^@* > <85>^B^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@<80><84>^B^@^@^@^@^@^@^@^@^@^@^@^@^@^A^@^@^@^@^@^@P^@^@^@^@^@^@^@^P^B^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ > ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^! @^@^@^@^@` ^B^@^@^@^@^@^@^P^B^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ > ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ > 2013-02-12T21:04:33Z DEBUG stderr= > > >> If so, what version of nss and nss-tools do you have installed? > > > [root at forain ~]# yum info nss nss-tools > Loaded plugins: langpacks, presto, refresh-packagekit > Installed Packages > Name : nss > Arch : x86_64 > Version : 3.14.2 > Release : 2.fc18 > Size : 2.5 M > Repo : installed > From repo : updates > Summary : Network Security Services > URL : http://www.mozilla.org/projects/security/pki/nss/ > License : MPLv2.0 > Description : Network Security Services (NSS) is a set of libraries designed to > : support cross-platform development of security-enabled client and > : server applications. Applications built with NSS can support SSL v2 > : and v3, TLS, PKCS #5, PKCS #7, PKCS #11, PKCS #12, S/MIME, X.509 > : v3 certificates, and other security standards. > > Name : nss-tools > Arch : x86_64 > Version : 3.14.2 > Release : 2.fc18 > Size : 1.7 M > Repo : installed > From repo : updates > Summary : Tools for the Network Security Services > URL : http://www.mozilla.org/projects/security/pki/nss/ > License : MPLv2.0 > Description : Network Security Services (NSS) is a set of libraries designed to > : support cross-platform development of security-enabled client and > : server applications. Applications built with NSS can support SSL v2 > : and v3, TLS, PKCS #5, PKCS #7, PKCS #11, PKCS #12, S/MIME, X.509 > : v3 certificates, and other security standards. > : > : Install the nss-tools package if you need command-line tools to > : manipulate the NSS certificate and key database. > > Available Packages > Name : nss > Arch : i686 > Version : 3.14.2 > Release : 2.fc18 > Size : 833 k > Repo : updates/18/x86_64 > Summary : Network Security Services > URL : http://www.mozilla.org/projects/security/pki/nss/ > License : MPLv2.0 > Description : Network Security Services (NSS) is a set of libraries designed to > : support cross-platform development of security-enabled client and > : server applications. Applications built with NSS can support SSL v2 > : and v3, TLS, PKCS #5, PKCS #7, PKCS #11, PKCS #12, S/MIME, X.509 > : v3 certificates, and other security standards. > > [root at forain ~]# > > Hope this helps. > > -- > Chuck Lever > chucklever[at]gmail[dot]com > > > Ok, easily reproduced with this version of nss. I filed https://bugzilla.redhat.com/show_bug.cgi?id=910584 For a workaround you might try to yum downgrade nss. You may need to downgrade several other subpackages as well like nss-tools and nss-sysinit depending on your install. I think you can safely upgrade again once the install is complete. rob From rcritten at redhat.com Tue Feb 12 23:57:53 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 12 Feb 2013 18:57:53 -0500 Subject: [Freeipa-users] ipa-server-install IndexError: list index out of range In-Reply-To: <511ABD6B.9000505@redhat.com> References: <511AB2F7.8030509@redhat.com> <511ABD6B.9000505@redhat.com> Message-ID: <511AD701.70907@redhat.com> Rob Crittenden wrote: > Chuck Lever wrote: >> >> On Feb 12, 2013, at 4:24 PM, Rob Crittenden wrote: >> >>> Chuck Lever wrote: >>>> Hi- >>>> >>>> I'm new to FreeIPA. I'm installing on an up-to-date Fedora 18 >>>> system from the freeipa packages available with Fedora 18. When >>>> running ipa-server-install, the install process fails here: >>>> >>>> Configuring certificate server (pki-tomcatd): Estimated time 3 >>>> minutes 30 seconds >>>> [1/20]: creating certificate server user >>>> ... >>>> [15/20]: requesting RA certificate from CA >>>> Unexpected error - see /var/log/ipaserver-install.log for details: >>>> IndexError: list index out of range >>>> >>>> The tail of the installer log looks like this: >>>> >>>> Generating key. This may take a few moments... >>>> >>>> >>>> 2013-02-12T21:04:46Z INFO File >>>> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line >>>> 617, in run_script >>>> return_value = main_function() >>>> >>>> File "/sbin/ipa-server-install", line 986, in main >>>> dm_password, subject_base=options.subject) >>>> >>>> File >>>> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", >>>> line 621, in configure_instance >>>> self.start_creation(runtime=210) >>>> >>>> File >>>> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >>>> line 358, in start_creation >>>> method() >>>> >>>> File >>>> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", >>>> line 1219, in __request_ra_certificate >>>> self.requestId = item_node[0].childNodes[0].data >>>> >>>> 2013-02-12T21:04:46Z INFO The ipa-server-install command failed, >>>> exception: IndexError: list index out of range >>>> >>>> >>>> Is there a workaround or fix available? I haven't found any >>>> relevant information via a web search, and a few searches on >>>> bugzilla.redhat.com have come up empty. >>>> >>> >>> We've seen just one other report of this and unfortunately the VM was >>> removed before we could do a lot of diagnosis. What we saw was that >>> certutil output garbage when requesting the RA admin certificate. Can >>> you look in /var/log/ipaserver-install.log for the last certutil >>> command? Does stdout contain a lot of garbage characters in it? It >>> should consist of a base64-encoded CSR. >> >> 2013-02-12T21:04:29Z DEBUG [15/20]: requesting RA certificate from CA >> 2013-02-12T21:04:29Z DEBUG Starting external process >> 2013-02-12T21:04:29Z DEBUG args=/usr/bin/certutil -d /etc/httpd/alias >> -f XXXXXXXX -R -k >> rsa -g 2048 -s CN=IPA RA,O=1015GRANGER.NET -z /tmp/tmptIYFZ5 -a >> 2013-02-12T21:04:33Z DEBUG Process finished, return code=0 >> 2013-02-12T21:04:33Z DEBUG >> stdout=^X^\^<^@^@^@^X^\^<^@^@^@^P-<85>^B^@^@^@^@^P- >> <85>^B^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ >> >> ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ >> >> ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ >> >> ^@^@^@@^G >> 8^?^@^@^E^@^@^@^@^@^@<98>^W^<^@^@^@<98>^W^<^@^@^@^@^@^@^@^@^@ >> >> ^@^@^@^@^@^@^@^@^@^@?<87>^U^^6?^L^R|=^^W^D^N >> >> ^\=<9F>^@^@^@^@^@^@^@^@q^E^@^@^@^@^@^@<98>^W^<^@^@^@^P^B^@^@^@^@^@^@ >> >> ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^Y<85>^B^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^A_<^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@+_<^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^A >> >> ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^D^@^@^@^@^@^@<98>^W^<^@^@^@* >> >> <85>^B^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@<80><84>^B^@^@^@^@^@^@^@^@^@^@^@^@^@^A^@^@^@^@^@^@P^@^@^@^@^@^@^@^P^B^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ >> >> ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@! ^! >> > @^@^@^@^@` > ^B^@^@^@^@^@^@^P^B^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ >> ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ >> >> 2013-02-12T21:04:33Z DEBUG stderr= >> >> >>> If so, what version of nss and nss-tools do you have installed? >> >> >> [root at forain ~]# yum info nss nss-tools >> Loaded plugins: langpacks, presto, refresh-packagekit >> Installed Packages >> Name : nss >> Arch : x86_64 >> Version : 3.14.2 >> Release : 2.fc18 >> Size : 2.5 M >> Repo : installed >> From repo : updates >> Summary : Network Security Services >> URL : http://www.mozilla.org/projects/security/pki/nss/ >> License : MPLv2.0 >> Description : Network Security Services (NSS) is a set of libraries >> designed to >> : support cross-platform development of security-enabled >> client and >> : server applications. Applications built with NSS can >> support SSL v2 >> : and v3, TLS, PKCS #5, PKCS #7, PKCS #11, PKCS #12, >> S/MIME, X.509 >> : v3 certificates, and other security standards. >> >> Name : nss-tools >> Arch : x86_64 >> Version : 3.14.2 >> Release : 2.fc18 >> Size : 1.7 M >> Repo : installed >> From repo : updates >> Summary : Tools for the Network Security Services >> URL : http://www.mozilla.org/projects/security/pki/nss/ >> License : MPLv2.0 >> Description : Network Security Services (NSS) is a set of libraries >> designed to >> : support cross-platform development of security-enabled >> client and >> : server applications. Applications built with NSS can >> support SSL v2 >> : and v3, TLS, PKCS #5, PKCS #7, PKCS #11, PKCS #12, >> S/MIME, X.509 >> : v3 certificates, and other security standards. >> : >> : Install the nss-tools package if you need command-line >> tools to >> : manipulate the NSS certificate and key database. >> >> Available Packages >> Name : nss >> Arch : i686 >> Version : 3.14.2 >> Release : 2.fc18 >> Size : 833 k >> Repo : updates/18/x86_64 >> Summary : Network Security Services >> URL : http://www.mozilla.org/projects/security/pki/nss/ >> License : MPLv2.0 >> Description : Network Security Services (NSS) is a set of libraries >> designed to >> : support cross-platform development of security-enabled >> client and >> : server applications. Applications built with NSS can >> support SSL v2 >> : and v3, TLS, PKCS #5, PKCS #7, PKCS #11, PKCS #12, >> S/MIME, X.509 >> : v3 certificates, and other security standards. >> >> [root at forain ~]# >> >> Hope this helps. >> >> -- >> Chuck Lever >> chucklever[at]gmail[dot]com >> >> >> > > Ok, easily reproduced with this version of nss. I filed > https://bugzilla.redhat.com/show_bug.cgi?id=910584 > > For a workaround you might try to yum downgrade nss. You may need to > downgrade several other subpackages as well like nss-tools and > nss-sysinit depending on your install. > > I think you can safely upgrade again once the install is complete. I did some real quick smoke testing and this seems to work. I did: # yum downgrade nss nss-* # ipa-server-install ... # yum update nss This is with a dogtag CA. I didn't test a selfsign CA. This was a single install. Preparing a replica will fail with the error "Certificate issuance failed" because of the certutil problem. rob From dpal at redhat.com Tue Feb 12 23:58:56 2013 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 12 Feb 2013 18:58:56 -0500 Subject: [Freeipa-users] Postponing IPA 3 upgrade In-Reply-To: References: <833D8E48405E064EBC54C84EC6B36E4071089661@STAWINCOX10MBX1.staff.vuw.ac.nz> <20130212073014.GB15541@fluxcoil.net> <511A82A6.1050201@netbulae.eu> Message-ID: <511AD740.2040202@redhat.com> On 02/12/2013 01:21 PM, Rashard.Kelly at sita.aero wrote: > Thanks for all the replies, We are using Red Hat Satellite Server to > handle Yum updates but I am still getting a grasp on how it works. > After talking to one of our admins, I was told that it should not do a > major version upgrade without being explicitly told to. > > The servers are virtual so I will clone them off before the next patch > cycles. > Is there an official go-live date for IPA3 in RHEL? > Watch for RHEL 6.4 announcements. > Thanks, > Rashard > > > > From: Jorick Astrego > To: Christian Horn > Cc: freeipa-users at redhat.com > Date: 02/12/2013 01:04 PM > Subject: Re: [Freeipa-users] Postponing IPA 3 upgrade > Sent by: freeipa-users-bounces at redhat.com > ------------------------------------------------------------------------ > > > > On 02/12/2013 08:30 AM, Christian Horn wrote: > > On Mon, Feb 11, 2013 at 09:05:40PM +0000, Steven Jones wrote: > >> Personally Im very worried, 6.2 to 6.3 went badly and this looks > like a bigger upgrade > > I might miss something.. but cant one create a "throw away replica" > > of the old environment, use that then separatedly and try out the > > upgrade with it? > > > > Christian > > > He could if he has spare hardware laying around. Or if he is running it > virtulized you could clone the vm easily and test it on a virtual > network not connected to the rest. > > But if you read Rashard's post correctly, he is afraid of yum > automatically updating freeIPA and breaking it. > > @ Rashard > > You should not be letting yum update automatically but use Katello, Red > Hat Network Satellite or Spacewalk to install updates. > > Still I would like to know the same. Some other projects use version > dependant repo's so you can choose to switch by changing repo, others > put the version number in the package name. > > > -- > Kind Regards, > > Jorick Astrego > > Netbulae B.V. > Site: http://www.netbulae.eu > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > > > > > > > > > > > > > > This document is strictly confidential and intended only for use by > the addressee unless otherwise stated. If you are not the intended > recipient, please notify the sender immediately and delete it from > your system. > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Wed Feb 13 00:18:11 2013 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 12 Feb 2013 19:18:11 -0500 Subject: [Freeipa-users] Python Client In-Reply-To: <31827C39-36BA-4510-8718-29318A0A9746@gmail.com> References: <51167F24.30904@redhat.com> <5117BDA3.4070800@redhat.com> <31827C39-36BA-4510-8718-29318A0A9746@gmail.com> Message-ID: <511ADBC3.6060406@redhat.com> On 02/12/2013 12:42 PM, It Meme wrote: > Yes - Dmitri is correct. > > Our purchased IAM product has LDAP connectors. It is possible to customize to develop other connector protocols but it requires tweaking the core product code - this adds risk and, if not careful, could break our support with vendor or increase operational risk to a critical production system. > > The most practical option is to continue to use the LDAP connectors to provision accounts to directory server. > > If we use IPA, that would mean provisioning accounts, from our IAM product to IPA, via LDAP (Step 1) - and subsequently running a script that will call the python libraries to IPA-ize the provisioned accounts (Step 2). > > It will assist our help desk staff if 'Step 1' provisioned accounts were created in main accounts tree in IPA - then subsequent script will IPA-ize the accounts for 'Step 2' and accounts will be updated in same tree. > > Any gotchas foreseen with above? Yes. You need to be very careful. You are bypassing all the checks that framework creates around user and group management. It is also unclear how the system would react to the half baked user. It is all doable but you shift the risk from the tweaking core product code to creating a custom IPA code. IMO the level of risk is nearly the same. > We have larger user base with ~40K new accounts per year and 600K ongoing - automating the tasks in stable systems, and having help desk insight to account statuses are critical items for management. > > Thank you for your help, insights, input - they are very helpful and greatly appreciated. > > On 2013-02-10, at 7:32, Dmitri Pal wrote: > >> On 02/09/2013 11:53 AM, John Dennis wrote: >>> On 02/08/2013 05:29 PM, It Meme wrote: >>>> Hi: >>>> >>>> Scenario: >>>> >>>> 1) User is created via LDAP call to IPA (i.e.the 389 Directory Server) >>>> >>>> The above user will not have IPA-specific attributes. >>>> >>>> Can we use the Python Library, or CLI, to modify the account to >>>> IPA-ize it? >>> You're really better off using the IPA API directly rather than trying >>> to bypass it. Why? Because we implement additional logic inside the >>> commands. If you could achieve everything IPA does by just modifying >>> an LDAP server there wouldn't be a need for IPA. A good example of >>> this is group membership, some of that logic is handled directly by a >>> plugin to the 389 DS, but a large part of it is implemented in the IPA >>> commands that manage users and groups. You really don't want to bypass >>> it. >>> >>> You have a number of options on how to call the IPA commands: >>> >>> 1) the ipa command line client >>> >>> 2) sending the command formatted in JSON to the server >>> >>> 3) sending the command formatted in XML-RPC to the server >>> >>> 4) calling the command from your own python code >>> >>> 5) using the web GUI >>> >>> It's really not hard to call the IPA command line client from a >>> program, typically this is done via a "system" command of which there >>> are a number of variants. >>> >>> The following thread has a discussion of how to invoke one of our >>> commands from Python code, this particular email response from Martin >>> shows how it can be done in in about half a dozen lines of code. >>> >>> https://www.redhat.com/archives/freeipa-users/2012-June/msg00334.html >>> >>> What I'm not understanding why you're avoiding using the commands we >>> provide. If you're not familiar with how to call another >>> program/process we can help you or just google it. Or is the problem >>> your existing management system does not provide you with any "hooks" >>> to execute code when an action occurs. But from everything you've said >>> so far you imply it does provide such hooks. Perhaps if you could be >>> more specific we could be more helpful. >> It seems that the management system in question can insert an entry into >> LDAP but can't do the "generic" hook. >> I bet this is the issue here. >> >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager for IdM portfolio >> Red Hat Inc. >> >> >> ------------------------------- >> Looking to carve out IT costs? >> www.redhat.com/carveoutcosts/ >> >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From it.meme01 at gmail.com Wed Feb 13 05:47:29 2013 From: it.meme01 at gmail.com (It Meme) Date: Tue, 12 Feb 2013 21:47:29 -0800 Subject: [Freeipa-users] Python Client In-Reply-To: <511ADBC3.6060406@redhat.com> References: <51167F24.30904@redhat.com> <5117BDA3.4070800@redhat.com> <31827C39-36BA-4510-8718-29318A0A9746@gmail.com> <511ADBC3.6060406@redhat.com> Message-ID: Thank you for your reply. Could there be anyway that accounts can be provisioned to IPA, via LDAP, from existing IAM system? The newly provisioned accounts can be temporarily stored in IPA's 389 Directory Server, and subsequently an automated task can IPA-ize the accounts (i.e. via the Python libraries). The accounts that have not been IPA-ized will be provisioned in a disabled state (i.e. users will be not using them). After accounts have been IPA-ize, account attributes, such as 'givenName', 'password', 'membershipOf', can be managed by LDAP from the central IAM system. Thank you. On Tue, Feb 12, 2013 at 4:18 PM, Dmitri Pal wrote: > On 02/12/2013 12:42 PM, It Meme wrote: > > Yes - Dmitri is correct. > > > > Our purchased IAM product has LDAP connectors. It is possible to > customize to develop other connector protocols but it requires tweaking the > core product code - this adds risk and, if not careful, could break our > support with vendor or increase operational risk to a critical production > system. > > > > The most practical option is to continue to use the LDAP connectors to > provision accounts to directory server. > > > > If we use IPA, that would mean provisioning accounts, from our IAM > product to IPA, via LDAP (Step 1) - and subsequently running a script that > will call the python libraries to IPA-ize the provisioned accounts (Step 2). > > > > It will assist our help desk staff if 'Step 1' provisioned accounts were > created in main accounts tree in IPA - then subsequent script will IPA-ize > the accounts for 'Step 2' and accounts will be updated in same tree. > > > > Any gotchas foreseen with above? > Yes. You need to be very careful. You are bypassing all the checks that > framework creates around user and group management. It is also unclear > how the system would react to the half baked user. It is all doable but > you shift the risk from the tweaking core product code to creating a > custom IPA code. IMO the level of risk is nearly the same. > > > We have larger user base with ~40K new accounts per year and 600K > ongoing - automating the tasks in stable systems, and having help desk > insight to account statuses are critical items for management. > > > > Thank you for your help, insights, input - they are very helpful and > greatly appreciated. > > > > On 2013-02-10, at 7:32, Dmitri Pal wrote: > > > >> On 02/09/2013 11:53 AM, John Dennis wrote: > >>> On 02/08/2013 05:29 PM, It Meme wrote: > >>>> Hi: > >>>> > >>>> Scenario: > >>>> > >>>> 1) User is created via LDAP call to IPA (i.e.the 389 Directory Server) > >>>> > >>>> The above user will not have IPA-specific attributes. > >>>> > >>>> Can we use the Python Library, or CLI, to modify the account to > >>>> IPA-ize it? > >>> You're really better off using the IPA API directly rather than trying > >>> to bypass it. Why? Because we implement additional logic inside the > >>> commands. If you could achieve everything IPA does by just modifying > >>> an LDAP server there wouldn't be a need for IPA. A good example of > >>> this is group membership, some of that logic is handled directly by a > >>> plugin to the 389 DS, but a large part of it is implemented in the IPA > >>> commands that manage users and groups. You really don't want to bypass > >>> it. > >>> > >>> You have a number of options on how to call the IPA commands: > >>> > >>> 1) the ipa command line client > >>> > >>> 2) sending the command formatted in JSON to the server > >>> > >>> 3) sending the command formatted in XML-RPC to the server > >>> > >>> 4) calling the command from your own python code > >>> > >>> 5) using the web GUI > >>> > >>> It's really not hard to call the IPA command line client from a > >>> program, typically this is done via a "system" command of which there > >>> are a number of variants. > >>> > >>> The following thread has a discussion of how to invoke one of our > >>> commands from Python code, this particular email response from Martin > >>> shows how it can be done in in about half a dozen lines of code. > >>> > >>> https://www.redhat.com/archives/freeipa-users/2012-June/msg00334.html > >>> > >>> What I'm not understanding why you're avoiding using the commands we > >>> provide. If you're not familiar with how to call another > >>> program/process we can help you or just google it. Or is the problem > >>> your existing management system does not provide you with any "hooks" > >>> to execute code when an action occurs. But from everything you've said > >>> so far you imply it does provide such hooks. Perhaps if you could be > >>> more specific we could be more helpful. > >> It seems that the management system in question can insert an entry into > >> LDAP but can't do the "generic" hook. > >> I bet this is the issue here. > >> > >> > >> -- > >> Thank you, > >> Dmitri Pal > >> > >> Sr. Engineering Manager for IdM portfolio > >> Red Hat Inc. > >> > >> > >> ------------------------------- > >> Looking to carve out IT costs? > >> www.redhat.com/carveoutcosts/ > >> > >> > >> > >> _______________________________________________ > >> Freeipa-users mailing list > >> Freeipa-users at redhat.com > >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Wed Feb 13 08:29:42 2013 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 13 Feb 2013 09:29:42 +0100 Subject: [Freeipa-users] Account Expiration In-Reply-To: <511A9650.7030302@redhat.com> References: <5106A043.1070103@redhat.com> <51131E6C.7030103@redhat.com> <51135B8C.5070001@redhat.com> <511A8C88.7000001@redhat.com> <511A9650.7030302@redhat.com> Message-ID: <511B4EF6.1040702@redhat.com> On 12.2.2013 20:21, John Dennis wrote: > On 02/12/2013 01:40 PM, Rob Crittenden wrote: >>> Is it possible to ipa to send a email to user when his account is about >>> to expire (the current date is near krbprincipalexpiration date) ? >> >> Not currently. In 3.0+ we will provide a notice when one logs into the >> WebUI but that's it. >> >> We can't be sure that an MTA is properly configured on the IPA server at >> install time so we have punted on this for a while. We don't want to get >> into the business of picking and configuring one. This is one of those >> things that seems really easy but gets complicated the deeper you dig >> into it. We're open to suggestions/patches. > > Yeah, I don't think we want to be in the business of installing and > configuring an MTA. However, we should be able to detect if one is available > and use it if it is. I think it would be reasonable to restrict it to LMTP > with a Unix domain socket (most MTA's support this). Then our config would > have a LMTP domain socket pathname, if that pathname exists and we can connect > to it we use, if not we fallback to not generating any mail. In meanwhile, it should be relatively simple to code script which does ldapsearch from time to time and sends some e-mails. This script doesn't have to run on the same server as IPA, only access to LDAP and some MTA is required. -- Petr^2 Spacek From mkosek at redhat.com Wed Feb 13 09:48:42 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 13 Feb 2013 10:48:42 +0100 Subject: [Freeipa-users] Announcing FreeIPA 2.2.2 Message-ID: <511B617A.4010602@redhat.com> The FreeIPA team is proud to announce version FreeIPA v2.2.2 This release contains Security Updates. It can be downloaded from http://www.freeipa.org/page/Downloads. A build is currently on the way to updates-testing for Fedora 17. == Highlights == This release contains a Security Advisory: * CVE-2012-5484: MITM Attack during Join process The FreeIPA Team would like to thank the Red Hat Security Response Team and in particular Vincent Danen for the invaluable assistance provided for the assessment and resolution of these issues. For CVE-2012-5484 we would like to thank Petr Men??k for reporting the issue. == Upgrading == Please consult each CVE announcement for related Upgrading instructions. An IPA server can be upgraded simply by installing updated rpms. The server does not need to be shut down in advance. If you have multiple servers you may upgrade them one at a time. It is expected that all servers will be upgraded in a relatively short period (days or weeks not months). They should be able to co-exist peacefully but new features will not be available on old servers and enrolling a new client against an old server will result in the SSH keys not being uploaded. Downgrading a server once upgraded is not supported. == 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.2.1 == Alexander Bokovoy (1): * Update plugin to upload CA certificate to LDAP Jan Cholasta (1): * Pylint cleanup John Dennis (1): * Use secure method to acquire IPA CA certificate Martin Kosek (3): * Run index task for new indexes * Filter suffix in replication management tools * Become IPA 2.2.2 Rob Crittenden (1): * Do SSL CA verification and hostname validation. Simo Sorce (1): * Upload CA cert in the directory on install ################################################################################ == CVE-2012-5484: MITM Attack during Join process == A weakness was found in the way an IPA client communicates with an IPA server when attempting to join an IPA domain. When an IPA client attempts to join an IPA domain an attacker could run a Man in The Middle Attack to try to intercept and hijack initial communication. A join initiated by an administrative user would grant the attacker administrative rights to the IPA server, whereas a join initiated by an unprivileged user would only grant the attacker limited privilege (typically just the ability to join the domain). The weakness is caused by the way the CA certificate is retrieved from the server. The following SSL communication may then be intercepted and subverted. Note that no credentials are exposed through this attack and it is effective only if performed during the join procedure and network traffic can be redirected or intercepted. Mere observation of the network traffic is not sufficient to grant an attacker any privilege. == Affected Versions == All 2.x and 3.x versions == Impact == Low == Acknowledgements == The FreeIPA team would like to thank Petr Men??k for reporting this issue. == Upgrade instructions == The resolution for this issue consist in allowing clients to download the CA certificate exclusively via a mutually authenticated LDAP connection or by providing the CA cert via an external method to the client. At least one IPA server in a domain need to be updated using the provided patches, so that the CA certificate is made available via LDAP. All client should be upgraded to use the updated ipa-client-install script that downloads the CA cert via an authenticated LDAP connection. From rajnesh.siwal at gmail.com Wed Feb 13 10:38:51 2013 From: rajnesh.siwal at gmail.com (Rajnesh Kumar Siwal) Date: Wed, 13 Feb 2013 16:08:51 +0530 Subject: [Freeipa-users] Restricting other User's Details to be visible to a user Message-ID: It has been found that any user can see the details of other users through the IPA Web Interface (even ldapsearch with anonymous user). It would be great if we could hide the details of the other users from the current user (including emai, phone number, Licence Number). Additionally, anonymous access to the information should not be available. -- Regards, Rajnesh Kumar Siwal From pspacek at redhat.com Wed Feb 13 10:56:11 2013 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 13 Feb 2013 11:56:11 +0100 Subject: [Freeipa-users] Restricting other User's Details to be visible to a user In-Reply-To: References: Message-ID: <511B714B.80903@redhat.com> On 13.2.2013 11:38, Rajnesh Kumar Siwal wrote: > It has been found that any user can see the details of other users > through the IPA Web Interface (even ldapsearch with anonymous user). > It would be great if we could hide the details of the other users from > the current user (including emai, phone number, Licence Number). > Additionally, anonymous access to the information should not be available. Please look to archives, Dmitri summarized current state of things nicely: https://www.redhat.com/archives/freeipa-users/2012-November/msg00052.html We can recommend some way if you still want to do that. -- Petr^2 Spacek From rajnesh.siwal at gmail.com Wed Feb 13 11:22:39 2013 From: rajnesh.siwal at gmail.com (Rajnesh Kumar Siwal) Date: Wed, 13 Feb 2013 16:52:39 +0530 Subject: [Freeipa-users] Restricting other User's Details to be visible to a user Message-ID: Yes. We would still like to restrict the Visibility of the users. We could implement the ACL's in 389-ds. However, I was concerned whether it breaks the IPA. -- Regards, Rajnesh Kumar Siwal From jreg2k at gmail.com Wed Feb 13 12:03:36 2013 From: jreg2k at gmail.com (James James) Date: Wed, 13 Feb 2013 13:03:36 +0100 Subject: [Freeipa-users] Account Expiration In-Reply-To: <511B4EF6.1040702@redhat.com> References: <5106A043.1070103@redhat.com> <51131E6C.7030103@redhat.com> <51135B8C.5070001@redhat.com> <511A8C88.7000001@redhat.com> <511A9650.7030302@redhat.com> <511B4EF6.1040702@redhat.com> Message-ID: It's a good idea. I will try that. 2013/2/13 Petr Spacek > On 12.2.2013 20:21, John Dennis wrote: > >> On 02/12/2013 01:40 PM, Rob Crittenden wrote: >> >>> Is it possible to ipa to send a email to user when his account is about >>>> to expire (the current date is near krbprincipalexpiration date) ? >>>> >>> >>> Not currently. In 3.0+ we will provide a notice when one logs into the >>> WebUI but that's it. >>> >>> We can't be sure that an MTA is properly configured on the IPA server at >>> install time so we have punted on this for a while. We don't want to get >>> into the business of picking and configuring one. This is one of those >>> things that seems really easy but gets complicated the deeper you dig >>> into it. We're open to suggestions/patches. >>> >> >> Yeah, I don't think we want to be in the business of installing and >> configuring an MTA. However, we should be able to detect if one is >> available >> and use it if it is. I think it would be reasonable to restrict it to LMTP >> with a Unix domain socket (most MTA's support this). Then our config would >> have a LMTP domain socket pathname, if that pathname exists and we can >> connect >> to it we use, if not we fallback to not generating any mail. >> > > In meanwhile, it should be relatively simple to code script which does > ldapsearch from time to time and sends some e-mails. This script doesn't > have to run on the same server as IPA, only access to LDAP and some MTA is > required. > > -- > Petr^2 Spacek > > > ______________________________**_________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/**mailman/listinfo/freeipa-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed Feb 13 13:56:39 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 13 Feb 2013 08:56:39 -0500 Subject: [Freeipa-users] Account Expiration In-Reply-To: <511B4EF6.1040702@redhat.com> References: <5106A043.1070103@redhat.com> <51131E6C.7030103@redhat.com> <51135B8C.5070001@redhat.com> <511A8C88.7000001@redhat.com> <511A9650.7030302@redhat.com> <511B4EF6.1040702@redhat.com> Message-ID: <511B9B97.5060309@redhat.com> Petr Spacek wrote: > On 12.2.2013 20:21, John Dennis wrote: >> On 02/12/2013 01:40 PM, Rob Crittenden wrote: >>>> Is it possible to ipa to send a email to user when his account is about >>>> to expire (the current date is near krbprincipalexpiration date) ? >>> >>> Not currently. In 3.0+ we will provide a notice when one logs into the >>> WebUI but that's it. >>> >>> We can't be sure that an MTA is properly configured on the IPA server at >>> install time so we have punted on this for a while. We don't want to get >>> into the business of picking and configuring one. This is one of those >>> things that seems really easy but gets complicated the deeper you dig >>> into it. We're open to suggestions/patches. >> >> Yeah, I don't think we want to be in the business of installing and >> configuring an MTA. However, we should be able to detect if one is >> available >> and use it if it is. I think it would be reasonable to restrict it to >> LMTP >> with a Unix domain socket (most MTA's support this). Then our config >> would >> have a LMTP domain socket pathname, if that pathname exists and we can >> connect >> to it we use, if not we fallback to not generating any mail. > > In meanwhile, it should be relatively simple to code script which does > ldapsearch from time to time and sends some e-mails. This script doesn't > have to run on the same server as IPA, only access to LDAP and some MTA > is required. > Yes, that is our current recommendation. There is a sample query in the docs IIRC. rob From dpal at redhat.com Wed Feb 13 14:35:48 2013 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 13 Feb 2013 09:35:48 -0500 Subject: [Freeipa-users] Python Client In-Reply-To: References: <51167F24.30904@redhat.com> <5117BDA3.4070800@redhat.com> <31827C39-36BA-4510-8718-29318A0A9746@gmail.com> <511ADBC3.6060406@redhat.com> Message-ID: <511BA4C4.4010009@redhat.com> On 02/13/2013 12:47 AM, It Meme wrote: > Thank you for your reply. > > Could there be anyway that accounts can be provisioned to IPA, via > LDAP, from existing IAM system? > > The newly provisioned accounts can be temporarily stored in IPA's 389 > Directory Server, and subsequently an automated task can IPA-ize the > accounts (i.e. via the Python libraries). The accounts that have not > been IPA-ized will be provisioned in a disabled state (i.e. users will > be not using them). > > After accounts have been IPA-ize, account attributes, such as > 'givenName', 'password', 'membershipOf', can be managed by LDAP from > the central IAM system. > IMO a solution might be to do something like this: https://fedorahosted.org/freeipa/ticket/1593 You create a plugin for DS to intercept the changes and send them over DBUS or socket So the whole thing would work like this: You create a different tree for accounts managed by the external system for example under cn=ext, ... You create a plugin that would intercept add, delete and modify commands and would also send these over the DBUS/Socket to a python service that would translate the changes into ipa user-add, ipa user-mod and ipa-user-del commands. The value of this approach is that would take advantage of the standard interfaces of both systems and have full control over the code you develop. Would that work for you? > Thank you. > > > On Tue, Feb 12, 2013 at 4:18 PM, Dmitri Pal > wrote: > > On 02/12/2013 12:42 PM, It Meme wrote: > > Yes - Dmitri is correct. > > > > Our purchased IAM product has LDAP connectors. It is possible to > customize to develop other connector protocols but it requires > tweaking the core product code - this adds risk and, if not > careful, could break our support with vendor or increase > operational risk to a critical production system. > > > > The most practical option is to continue to use the LDAP > connectors to provision accounts to directory server. > > > > If we use IPA, that would mean provisioning accounts, from our > IAM product to IPA, via LDAP (Step 1) - and subsequently running a > script that will call the python libraries to IPA-ize the > provisioned accounts (Step 2). > > > > It will assist our help desk staff if 'Step 1' provisioned > accounts were created in main accounts tree in IPA - then > subsequent script will IPA-ize the accounts for 'Step 2' and > accounts will be updated in same tree. > > > > Any gotchas foreseen with above? > Yes. You need to be very careful. You are bypassing all the checks > that > framework creates around user and group management. It is also unclear > how the system would react to the half baked user. It is all > doable but > you shift the risk from the tweaking core product code to creating a > custom IPA code. IMO the level of risk is nearly the same. > > > We have larger user base with ~40K new accounts per year and > 600K ongoing - automating the tasks in stable systems, and having > help desk insight to account statuses are critical items for > management. > > > > Thank you for your help, insights, input - they are very helpful > and greatly appreciated. > > > > On 2013-02-10, at 7:32, Dmitri Pal > wrote: > > > >> On 02/09/2013 11:53 AM, John Dennis wrote: > >>> On 02/08/2013 05:29 PM, It Meme wrote: > >>>> Hi: > >>>> > >>>> Scenario: > >>>> > >>>> 1) User is created via LDAP call to IPA (i.e.the 389 > Directory Server) > >>>> > >>>> The above user will not have IPA-specific attributes. > >>>> > >>>> Can we use the Python Library, or CLI, to modify the account to > >>>> IPA-ize it? > >>> You're really better off using the IPA API directly rather > than trying > >>> to bypass it. Why? Because we implement additional logic > inside the > >>> commands. If you could achieve everything IPA does by just > modifying > >>> an LDAP server there wouldn't be a need for IPA. A good example of > >>> this is group membership, some of that logic is handled > directly by a > >>> plugin to the 389 DS, but a large part of it is implemented in > the IPA > >>> commands that manage users and groups. You really don't want > to bypass > >>> it. > >>> > >>> You have a number of options on how to call the IPA commands: > >>> > >>> 1) the ipa command line client > >>> > >>> 2) sending the command formatted in JSON to the server > >>> > >>> 3) sending the command formatted in XML-RPC to the server > >>> > >>> 4) calling the command from your own python code > >>> > >>> 5) using the web GUI > >>> > >>> It's really not hard to call the IPA command line client from a > >>> program, typically this is done via a "system" command of > which there > >>> are a number of variants. > >>> > >>> The following thread has a discussion of how to invoke one of our > >>> commands from Python code, this particular email response from > Martin > >>> shows how it can be done in in about half a dozen lines of code. > >>> > >>> > https://www.redhat.com/archives/freeipa-users/2012-June/msg00334.html > >>> > >>> What I'm not understanding why you're avoiding using the > commands we > >>> provide. If you're not familiar with how to call another > >>> program/process we can help you or just google it. Or is the > problem > >>> your existing management system does not provide you with any > "hooks" > >>> to execute code when an action occurs. But from everything > you've said > >>> so far you imply it does provide such hooks. Perhaps if you > could be > >>> more specific we could be more helpful. > >> It seems that the management system in question can insert an > entry into > >> LDAP but can't do the "generic" hook. > >> I bet this is the issue here. > >> > >> > >> -- > >> Thank you, > >> Dmitri Pal > >> > >> Sr. Engineering Manager for IdM portfolio > >> Red Hat Inc. > >> > >> > >> ------------------------------- > >> Looking to carve out IT costs? > >> www.redhat.com/carveoutcosts/ > > >> > >> > >> > >> _______________________________________________ > >> Freeipa-users mailing list > >> Freeipa-users at redhat.com > >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed Feb 13 14:38:11 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 13 Feb 2013 09:38:11 -0500 Subject: [Freeipa-users] Restricting other User's Details to be visible to a user In-Reply-To: References: Message-ID: <511BA553.6060402@redhat.com> Rajnesh Kumar Siwal wrote: > Yes. We would still like to restrict the Visibility of the users. > We could implement the ACL's in 389-ds. However, I was concerned > whether it breaks the IPA. > To disable anonymous you need to set nsslapd-allow-anonymous-access to off in cn=config (bind as Directory Manager). Note that this needs to be done on every IPA master (and you need to remember to do this if you add any more). To disallow restrict read access to a set of attributes you'd need to write a custom ACI, something that is beyond the ability of our permission commands. If you're considering just some attributes in the user object then it should be fine. Those fields will just appear as blank to users that cannot read them. Hard to say if it would break anything without seeing the ACI. rob From rcritten at redhat.com Wed Feb 13 14:41:15 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 13 Feb 2013 09:41:15 -0500 Subject: [Freeipa-users] Python Client In-Reply-To: References: <51167F24.30904@redhat.com> <5117BDA3.4070800@redhat.com> <31827C39-36BA-4510-8718-29318A0A9746@gmail.com> <511ADBC3.6060406@redhat.com> Message-ID: <511BA60B.2070602@redhat.com> It Meme wrote: > Thank you for your reply. > > Could there be anyway that accounts can be provisioned to IPA, via LDAP, > from existing IAM system? > > The newly provisioned accounts can be temporarily stored in IPA's 389 > Directory Server, and subsequently an automated task can IPA-ize the > accounts (i.e. via the Python libraries). The accounts that have not > been IPA-ized will be provisioned in a disabled state (i.e. users will > be not using them). > > After accounts have been IPA-ize, account attributes, such as > 'givenName', 'password', 'membershipOf', can be managed by LDAP from the > central IAM system. I think as has been suggested your best bet is to write the users to a location outside of the IPA DIT and run a periodic query or write a service that uses LDAP persistent search to retrieve the user then pass it to the IPA framework via user-add. I think persistent search and a user principal in a keytab would be a pretty decent way to go. rob > > Thank you. > > > On Tue, Feb 12, 2013 at 4:18 PM, Dmitri Pal > wrote: > > On 02/12/2013 12:42 PM, It Meme wrote: > > Yes - Dmitri is correct. > > > > Our purchased IAM product has LDAP connectors. It is possible to > customize to develop other connector protocols but it requires > tweaking the core product code - this adds risk and, if not careful, > could break our support with vendor or increase operational risk to > a critical production system. > > > > The most practical option is to continue to use the LDAP > connectors to provision accounts to directory server. > > > > If we use IPA, that would mean provisioning accounts, from our > IAM product to IPA, via LDAP (Step 1) - and subsequently running a > script that will call the python libraries to IPA-ize the > provisioned accounts (Step 2). > > > > It will assist our help desk staff if 'Step 1' provisioned > accounts were created in main accounts tree in IPA - then subsequent > script will IPA-ize the accounts for 'Step 2' and accounts will be > updated in same tree. > > > > Any gotchas foreseen with above? > Yes. You need to be very careful. You are bypassing all the checks that > framework creates around user and group management. It is also unclear > how the system would react to the half baked user. It is all doable but > you shift the risk from the tweaking core product code to creating a > custom IPA code. IMO the level of risk is nearly the same. > > > We have larger user base with ~40K new accounts per year and 600K > ongoing - automating the tasks in stable systems, and having help > desk insight to account statuses are critical items for management. > > > > Thank you for your help, insights, input - they are very helpful > and greatly appreciated. > > > > On 2013-02-10, at 7:32, Dmitri Pal > wrote: > > > >> On 02/09/2013 11:53 AM, John Dennis wrote: > >>> On 02/08/2013 05:29 PM, It Meme wrote: > >>>> Hi: > >>>> > >>>> Scenario: > >>>> > >>>> 1) User is created via LDAP call to IPA (i.e.the 389 Directory > Server) > >>>> > >>>> The above user will not have IPA-specific attributes. > >>>> > >>>> Can we use the Python Library, or CLI, to modify the account to > >>>> IPA-ize it? > >>> You're really better off using the IPA API directly rather than > trying > >>> to bypass it. Why? Because we implement additional logic inside the > >>> commands. If you could achieve everything IPA does by just > modifying > >>> an LDAP server there wouldn't be a need for IPA. A good example of > >>> this is group membership, some of that logic is handled > directly by a > >>> plugin to the 389 DS, but a large part of it is implemented in > the IPA > >>> commands that manage users and groups. You really don't want to > bypass > >>> it. > >>> > >>> You have a number of options on how to call the IPA commands: > >>> > >>> 1) the ipa command line client > >>> > >>> 2) sending the command formatted in JSON to the server > >>> > >>> 3) sending the command formatted in XML-RPC to the server > >>> > >>> 4) calling the command from your own python code > >>> > >>> 5) using the web GUI > >>> > >>> It's really not hard to call the IPA command line client from a > >>> program, typically this is done via a "system" command of which > there > >>> are a number of variants. > >>> > >>> The following thread has a discussion of how to invoke one of our > >>> commands from Python code, this particular email response from > Martin > >>> shows how it can be done in in about half a dozen lines of code. > >>> > >>> > https://www.redhat.com/archives/freeipa-users/2012-June/msg00334.html > >>> > >>> What I'm not understanding why you're avoiding using the > commands we > >>> provide. If you're not familiar with how to call another > >>> program/process we can help you or just google it. Or is the > problem > >>> your existing management system does not provide you with any > "hooks" > >>> to execute code when an action occurs. But from everything > you've said > >>> so far you imply it does provide such hooks. Perhaps if you > could be > >>> more specific we could be more helpful. > >> It seems that the management system in question can insert an > entry into > >> LDAP but can't do the "generic" hook. > >> I bet this is the issue here. > >> > >> > >> -- > >> Thank you, > >> Dmitri Pal > >> > >> Sr. Engineering Manager for IdM portfolio > >> Red Hat Inc. > >> > >> > >> ------------------------------- > >> Looking to carve out IT costs? > >> www.redhat.com/carveoutcosts/ > >> > >> > >> > >> _______________________________________________ > >> Freeipa-users mailing list > >> Freeipa-users at redhat.com > >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > From lists at romal.de Wed Feb 13 14:44:12 2013 From: lists at romal.de (Robert M. Albrecht) Date: Wed, 13 Feb 2013 15:44:12 +0100 Subject: [Freeipa-users] FreeIPA installation bug on F18 while "requesting RA certificate from CA" In-Reply-To: <511BA66B.1070302@romal.de> References: <511BA66B.1070302@romal.de> Message-ID: <511BA6BC.2080700@romal.de> Hi, Configuring NTP daemon (ntpd) [1/4]: stopping ntpd [2/4]: writing configuration [3/4]: configuring ntpd to start on boot [4/4]: starting ntpd Done configuring NTP daemon (ntpd). Configuring directory server (dirsrv): Estimated time 1 minute [1/36]: creating directory server user [2/36]: creating directory server instance [3/36]: adding default schema [4/36]: enabling memberof plugin [5/36]: enabling winsync plugin [6/36]: configuring replication version plugin [7/36]: enabling IPA enrollment plugin [8/36]: enabling ldapi [9/36]: configuring uniqueness plugin [10/36]: configuring uuid plugin [11/36]: configuring modrdn plugin [12/36]: enabling entryUSN plugin [13/36]: configuring lockout plugin [14/36]: creating indices [15/36]: enabling referential integrity plugin [16/36]: configuring certmap.conf [17/36]: configure autobind for root [18/36]: configure new location for managed entries [19/36]: restarting directory server [20/36]: adding default layout [21/36]: adding delegation layout [22/36]: adding replication acis [23/36]: creating container for managed entries [24/36]: configuring user private groups [25/36]: configuring netgroups from hostgroups [26/36]: creating default Sudo bind user [27/36]: creating default Auto Member layout [28/36]: adding range check plugin [29/36]: creating default HBAC rule allow_all [30/36]: Upload CA cert to the directory ipa : CRITICAL Failed to load upload-cacert.ldif: Command '/usr/bin/ldapmodify -v -f /tmp/tmpSkzd0p -H ldap://gutenberg.vorlon.lan:389 -x -D cn=Directory Manager -y /tmp/tmpVB45G5' returned non-zero exit status 247 [31/36]: initializing group membership [32/36]: adding master entry [33/36]: configuring Posix uid/gid generation [34/36]: enabling compatibility plugin [35/36]: tuning directory server [36/36]: configuring directory to start on boot Done configuring directory server (dirsrv). Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds [1/20]: creating certificate server user [2/20]: configuring certificate server instance [3/20]: disabling nonces [4/20]: creating RA agent certificate database [5/20]: importing CA chain to RA certificate database [6/20]: fixing RA database permissions [7/20]: setting up signing cert profile [8/20]: set up CRL publishing [9/20]: set certificate subject base [10/20]: enabling Subject Key Identifier [11/20]: enabling CRL and OCSP extensions for certificates [12/20]: setting audit signing renewal to 2 years [13/20]: configuring certificate server to start on boot [14/20]: restarting certificate server [15/20]: requesting RA certificate from CA Unexpected error - see /var/log/ipaserver-install.log for details: IndexError: list index out of range [root at gutenberg ~]# from /var/log/ipaserver-install.log 2013-02-13T14:38:15Z DEBUG stderr= 2013-02-13T14:38:15Z DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state' 2013-02-13T14:38:15Z DEBUG duration: 0 seconds 2013-02-13T14:38:15Z DEBUG [14/20]: restarting certificate server 2013-02-13T14:38:15Z DEBUG Starting external process 2013-02-13T14:38:15Z DEBUG args=/bin/systemctl restart pki-tomcatd at pki-tomcat.service 2013-02-13T14:38:19Z DEBUG Process finished, return code=0 2013-02-13T14:38:19Z DEBUG stdout= 2013-02-13T14:38:19Z DEBUG stderr= 2013-02-13T14:38:19Z DEBUG Starting external process 2013-02-13T14:38:19Z DEBUG args=/bin/systemctl is-active pki-tomcatd at pki-tomcat.service 2013-02-13T14:38:19Z DEBUG Process finished, return code=0 2013-02-13T14:38:19Z DEBUG stdout=active 2013-02-13T14:38:19Z DEBUG stderr= 2013-02-13T14:38:19Z DEBUG wait_for_open_ports: localhost [8080, 8443] timeout 120 2013-02-13T14:38:25Z DEBUG The httpd proxy is not installed, skipping wait for CA 2013-02-13T14:38:25Z DEBUG duration: 9 seconds 2013-02-13T14:38:25Z DEBUG [15/20]: requesting RA certificate from CA 2013-02-13T14:38:25Z DEBUG Starting external process 2013-02-13T14:38:25Z DEBUG args=/usr/bin/certutil -d /etc/httpd/alias -f XXXXXXXX -R -k rsa -g 2048 -s CN=IPA RA,O=VORLON.LAN -z /tmp/tmpQoA4BN -a 2013-02-13T14:38:31Z DEBUG Process finished, return code=0 2013-02-13T14:38:31Z DEBUG stdout=^X^\5^@^@^@^X^\5^@^@^@^P<81>^A^@^@^@^@^P<81>^A^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^A^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@!^F^@^@^@^@^@^@<98>^W5^@^@^@<81>^A^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@<80><8D><81>^A^@^@^@^@^@^@^@^@^@^@^@^@^@^A^@^@^@^@^@^@P^@^@^@^@^@^@^@^P^B^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@`^B^@^@^@^@^@^@^P^B^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ 2013-02-13T14:38:31Z DEBUG stderr= Generating key. This may take a few moments... 2013-02-13T14:38:47Z INFO File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 617, in run_script return_value = main_function() File "/sbin/ipa-server-install", line 986, in main dm_password, subject_base=options.subject) File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 621, in configure_instance self.start_creation(runtime=210) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 358, in start_creation method() File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 1219, in __request_ra_certificate self.requestId = item_node[0].childNodes[0].data 2013-02-13T14:38:47Z INFO The ipa-server-install command failed, exception: IndexError: list index out of range (END) There are no special charters in any password. Any ideas ? cu romal From rcritten at redhat.com Wed Feb 13 14:48:58 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 13 Feb 2013 09:48:58 -0500 Subject: [Freeipa-users] FreeIPA installation bug on F18 while "requesting RA certificate from CA" In-Reply-To: <511BA6BC.2080700@romal.de> References: <511BA66B.1070302@romal.de> <511BA6BC.2080700@romal.de> Message-ID: <511BA7DA.6080500@redhat.com> Robert M. Albrecht wrote: > Hi, > > > Configuring NTP daemon (ntpd) > [1/4]: stopping ntpd > [2/4]: writing configuration > [3/4]: configuring ntpd to start on boot > [4/4]: starting ntpd > Done configuring NTP daemon (ntpd). > Configuring directory server (dirsrv): Estimated time 1 minute > [1/36]: creating directory server user > [2/36]: creating directory server instance > [3/36]: adding default schema > [4/36]: enabling memberof plugin > [5/36]: enabling winsync plugin > [6/36]: configuring replication version plugin > [7/36]: enabling IPA enrollment plugin > [8/36]: enabling ldapi > [9/36]: configuring uniqueness plugin > [10/36]: configuring uuid plugin > [11/36]: configuring modrdn plugin > [12/36]: enabling entryUSN plugin > [13/36]: configuring lockout plugin > [14/36]: creating indices > [15/36]: enabling referential integrity plugin > [16/36]: configuring certmap.conf > [17/36]: configure autobind for root > [18/36]: configure new location for managed entries > [19/36]: restarting directory server > [20/36]: adding default layout > [21/36]: adding delegation layout > [22/36]: adding replication acis > [23/36]: creating container for managed entries > [24/36]: configuring user private groups > [25/36]: configuring netgroups from hostgroups > [26/36]: creating default Sudo bind user > [27/36]: creating default Auto Member layout > [28/36]: adding range check plugin > [29/36]: creating default HBAC rule allow_all > [30/36]: Upload CA cert to the directory > ipa : CRITICAL Failed to load upload-cacert.ldif: Command > '/usr/bin/ldapmodify -v -f /tmp/tmpSkzd0p -H > ldap://gutenberg.vorlon.lan:389 -x -D cn=Directory Manager -y > /tmp/tmpVB45G5' returned non-zero exit status 247 > [31/36]: initializing group membership > [32/36]: adding master entry > [33/36]: configuring Posix uid/gid generation > [34/36]: enabling compatibility plugin > [35/36]: tuning directory server > [36/36]: configuring directory to start on boot > Done configuring directory server (dirsrv). > Configuring certificate server (pki-tomcatd): Estimated time 3 minutes > 30 seconds > [1/20]: creating certificate server user > [2/20]: configuring certificate server instance > [3/20]: disabling nonces > [4/20]: creating RA agent certificate database > [5/20]: importing CA chain to RA certificate database > [6/20]: fixing RA database permissions > [7/20]: setting up signing cert profile > [8/20]: set up CRL publishing > [9/20]: set certificate subject base > [10/20]: enabling Subject Key Identifier > [11/20]: enabling CRL and OCSP extensions for certificates > [12/20]: setting audit signing renewal to 2 years > [13/20]: configuring certificate server to start on boot > [14/20]: restarting certificate server > [15/20]: requesting RA certificate from CA > Unexpected error - see /var/log/ipaserver-install.log for details: > IndexError: list index out of range > [root at gutenberg ~]# > > from /var/log/ipaserver-install.log > > 2013-02-13T14:38:15Z DEBUG stderr= > 2013-02-13T14:38:15Z DEBUG Saving StateFile to > '/var/lib/ipa/sysrestore/sysrestore.state' > 2013-02-13T14:38:15Z DEBUG duration: 0 seconds > 2013-02-13T14:38:15Z DEBUG [14/20]: restarting certificate server > 2013-02-13T14:38:15Z DEBUG Starting external process > 2013-02-13T14:38:15Z DEBUG args=/bin/systemctl restart > pki-tomcatd at pki-tomcat.service > 2013-02-13T14:38:19Z DEBUG Process finished, return code=0 > 2013-02-13T14:38:19Z DEBUG stdout= > 2013-02-13T14:38:19Z DEBUG stderr= > 2013-02-13T14:38:19Z DEBUG Starting external process > 2013-02-13T14:38:19Z DEBUG args=/bin/systemctl is-active > pki-tomcatd at pki-tomcat.service > 2013-02-13T14:38:19Z DEBUG Process finished, return code=0 > 2013-02-13T14:38:19Z DEBUG stdout=active > > 2013-02-13T14:38:19Z DEBUG stderr= > 2013-02-13T14:38:19Z DEBUG wait_for_open_ports: localhost [8080, 8443] > timeout 120 > 2013-02-13T14:38:25Z DEBUG The httpd proxy is not installed, skipping > wait for CA > 2013-02-13T14:38:25Z DEBUG duration: 9 seconds > 2013-02-13T14:38:25Z DEBUG [15/20]: requesting RA certificate from CA > 2013-02-13T14:38:25Z DEBUG Starting external process > 2013-02-13T14:38:25Z DEBUG args=/usr/bin/certutil -d /etc/httpd/alias -f > XXXXXXXX -R -k rsa -g 2048 -s CN=IPA RA,O=VORLON.LAN -z /tmp/tmpQoA4BN -a > 2013-02-13T14:38:31Z DEBUG Process finished, return code=0 > 2013-02-13T14:38:31Z DEBUG > stdout=^X^\5^@^@^@^X^\5^@^@^@^P<81>^A^@^@^@^@^P<81>^A^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^A^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@!^F^@^@^@^@^@^@<98>^W5^@^@^@<81>^A^@ > > ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@<80><8D><81>^A^@^@^@^@^@^@^@^@^@^@^@^@^@^A^@^@^@^@^@^@P^@^@^@^@^@^@^@^P^B^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ > > ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ > > ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ > > ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@`^B^@^@^@^@^@^@^P^B^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ > > ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ > > ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ > > ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ > > 2013-02-13T14:38:31Z DEBUG stderr= > > Generating key. This may take a few moments... > > > 2013-02-13T14:38:47Z INFO File > "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", > line 617, in run_script > return_value = main_function() > > File "/sbin/ipa-server-install", line 986, in main > dm_password, subject_base=options.subject) > > File > "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line > 621, in configure_instance > self.start_creation(runtime=210) > > File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", > line 358, in start_creation > method() > > File > "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line > 1219, in __request_ra_certificate > self.requestId = item_node[0].childNodes[0].data > > 2013-02-13T14:38:47Z INFO The ipa-server-install command failed, > exception: IndexError: list index out of range > (END) > > > There are no special charters in any password. > > Any ideas ? Caused by a bug in the nss package, see this thread https://www.redhat.com/archives/freeipa-users/2013-February/msg00195.html rob From dag at wieers.com Wed Feb 13 14:58:42 2013 From: dag at wieers.com (Dag Wieers) Date: Wed, 13 Feb 2013 15:58:42 +0100 (CET) Subject: [Freeipa-users] RHEL6 IPA and Active Directory synchronisation and Solaris RBAC Message-ID: Hi, We are investigating whether IPA is an acceptable solution for our environment. One of the aspects that is not clear (from reading the documentation and testing it without AD) is whether the synchronization with AD can be limited to a subset. Since we would like to only synchronize certain user-accounts (conforming to a specific format) from AD unidirectionally, and we also want to manage functional/technical accounts on IPA, we need to make sure that we: - can filter the stuff we pull from AD - can avoid the synchronisation to remove other accounts managed in IPA Can someone confirm that this is possible ? Is there any indepth information on how this AD sycnhronization works (preferably about RHEL6 IPA) ? Also since we also require compatibility with Solaris, and roles (RBAC) is currently used on Solaris, does IPA support RBAC on Solaris ? (We noticed that RBAC mentioned in the IPA web interface only relates to IPA management). Thanks in advance, -- -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- dagit linux solutions, info at dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors] From simo at redhat.com Wed Feb 13 15:05:09 2013 From: simo at redhat.com (Simo Sorce) Date: Wed, 13 Feb 2013 10:05:09 -0500 Subject: [Freeipa-users] Python Client In-Reply-To: <511BA4C4.4010009@redhat.com> References: <51167F24.30904@redhat.com> <5117BDA3.4070800@redhat.com> <31827C39-36BA-4510-8718-29318A0A9746@gmail.com> <511ADBC3.6060406@redhat.com> <511BA4C4.4010009@redhat.com> Message-ID: <1360767909.12328.45.camel@willson.li.ssimo.org> On Wed, 2013-02-13 at 09:35 -0500, Dmitri Pal wrote: > On 02/13/2013 12:47 AM, It Meme wrote: > > Could there be anyway that accounts can be provisioned to IPA, via > > LDAP, from existing IAM system? > > > > > > The newly provisioned accounts can be temporarily stored in IPA's > > 389 Directory Server, and subsequently an automated task can IPA-ize > > the accounts (i.e. via the Python libraries). The accounts that have > > not been IPA-ized will be provisioned in a disabled state (i.e. > > users will be not using them). > > > > > > After accounts have been IPA-ize, account attributes, such as > > 'givenName', 'password', 'membershipOf', can be managed by LDAP from > > the central IAM system. > IMO a solution might be to do something like this: > https://fedorahosted.org/freeipa/ticket/1593 > You create a plugin for DS to intercept the changes and send them over > DBUS or socket > > So the whole thing would work like this: > You create a different tree for accounts managed by the external > system for example under cn=ext, ... > You create a plugin that would intercept add, delete and modify > commands and would also send these over the DBUS/Socket to a python > service that would translate the changes into ipa user-add, ipa > user-mod and ipa-user-del commands. > > The value of this approach is that would take advantage of the > standard interfaces of both systems and have full control over the > code you develop. > > Would that work for you? > I hadn't seen this reply yet, but I just proposed something similar on freeipa-devel. However my proposal would avoid strange back and forth with temporary objects and so on. It Meme, if you are interested in helping in this direction please subscribe to freeipa-devel and follow this thread: https://www.redhat.com/archives/freeipa-devel/2013-February/msg00149.html Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Wed Feb 13 15:10:38 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 13 Feb 2013 10:10:38 -0500 Subject: [Freeipa-users] RHEL6 IPA and Active Directory synchronisation and Solaris RBAC In-Reply-To: References: Message-ID: <511BACEE.8050900@redhat.com> Dag Wieers wrote: > Hi, > > We are investigating whether IPA is an acceptable solution for our > environment. One of the aspects that is not clear (from reading the > documentation and testing it without AD) is whether the synchronization > with AD can be limited to a subset. > > > Since we would like to only synchronize certain user-accounts > (conforming to a specific format) from AD unidirectionally, and we also > want to manage functional/technical accounts on IPA, we need to make > sure that we: > > - can filter the stuff we pull from AD You can set the subtree to use, I'm not sure if you can supply a filter to the winsync agreement. Rich? > - can avoid the synchronisation to remove other accounts managed in IPA I don't understand the question. You don't want the winsync agreement to affect IPA-specific users? That works. > > Can someone confirm that this is possible ? Is there any indepth > information on how this AD sycnhronization works (preferably about RHEL6 > IPA) ? Not beyond what is in the 389-ds-base and IPA documentation. There might be some additional information on the 389-ds wiki. > > Also since we also require compatibility with Solaris, and roles (RBAC) > is currently used on Solaris, does IPA support RBAC on Solaris ? (We > noticed that RBAC mentioned in the IPA web interface only relates to IPA > management). No, IPA doesn't support RBAC on Solaris. rob From rmeggins at redhat.com Wed Feb 13 15:24:04 2013 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 13 Feb 2013 08:24:04 -0700 Subject: [Freeipa-users] RHEL6 IPA and Active Directory synchronisation and Solaris RBAC In-Reply-To: <511BACEE.8050900@redhat.com> References: <511BACEE.8050900@redhat.com> Message-ID: <511BB014.3070802@redhat.com> On 02/13/2013 08:10 AM, Rob Crittenden wrote: > Dag Wieers wrote: >> Hi, >> >> We are investigating whether IPA is an acceptable solution for our >> environment. One of the aspects that is not clear (from reading the >> documentation and testing it without AD) is whether the synchronization >> with AD can be limited to a subset. >> >> >> Since we would like to only synchronize certain user-accounts >> (conforming to a specific format) from AD unidirectionally, and we also >> want to manage functional/technical accounts on IPA, we need to make >> sure that we: >> >> - can filter the stuff we pull from AD > > You can set the subtree to use, I'm not sure if you can supply a > filter to the winsync agreement. Rich? No, this is an RFE This trac report gives a pretty good idea of the limitations of 389 winsync: https://fedorahosted.org/389/query?component=Sync+Service&status=accepted&status=assigned&status=new&status=reopened&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component&order=priority&report=16 see especially https://fedorahosted.org/389/ticket/178 https://fedorahosted.org/389/ticket/460 > >> - can avoid the synchronisation to remove other accounts managed in >> IPA > > I don't understand the question. You don't want the winsync agreement > to affect IPA-specific users? That works. > >> >> Can someone confirm that this is possible ? Is there any indepth >> information on how this AD sycnhronization works (preferably about RHEL6 >> IPA) ? > > Not beyond what is in the 389-ds-base and IPA documentation. There > might be some additional information on the 389-ds wiki. What would you like to know? > >> >> Also since we also require compatibility with Solaris, and roles (RBAC) >> is currently used on Solaris, does IPA support RBAC on Solaris ? (We >> noticed that RBAC mentioned in the IPA web interface only relates to IPA >> management). > > No, IPA doesn't support RBAC on Solaris. > > rob > From Steven.Jones at vuw.ac.nz Wed Feb 13 19:50:50 2013 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Wed, 13 Feb 2013 19:50:50 +0000 Subject: [Freeipa-users] RHEL6 IPA and Active Directory synchronisation and Solaris RBAC In-Reply-To: References: Message-ID: <833D8E48405E064EBC54C84EC6B36E407108D01E@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, You can specify a --winsubtree, provided all the users you want are in that, I think that will work. For filters, Ive suggested that, we have so much garbage in our AD that its cluttering IPA badly. eg we have hundred templates, so I'd like to block those from being transferred. 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 Dag Wieers [dag at wieers.com] Sent: Thursday, 14 February 2013 3:58 a.m. To: freeipa-users at redhat.com Subject: [Freeipa-users] RHEL6 IPA and Active Directory synchronisation and Solaris RBAC Hi, We are investigating whether IPA is an acceptable solution for our environment. One of the aspects that is not clear (from reading the documentation and testing it without AD) is whether the synchronization with AD can be limited to a subset. Since we would like to only synchronize certain user-accounts (conforming to a specific format) from AD unidirectionally, and we also want to manage functional/technical accounts on IPA, we need to make sure that we: - can filter the stuff we pull from AD - can avoid the synchronisation to remove other accounts managed in IPA Can someone confirm that this is possible ? Is there any indepth information on how this AD sycnhronization works (preferably about RHEL6 IPA) ? Also since we also require compatibility with Solaris, and roles (RBAC) is currently used on Solaris, does IPA support RBAC on Solaris ? (We noticed that RBAC mentioned in the IPA web interface only relates to IPA management). Thanks in advance, -- -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- dagit linux solutions, info at dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors] _______________________________________________ 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 Feb 13 19:54:39 2013 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Wed, 13 Feb 2013 19:54:39 +0000 Subject: [Freeipa-users] Account Expiration In-Reply-To: <511B9B97.5060309@redhat.com> References: <5106A043.1070103@redhat.com> <51131E6C.7030103@redhat.com> <51135B8C.5070001@redhat.com> <511A8C88.7000001@redhat.com> <511A9650.7030302@redhat.com> <511B4EF6.1040702@redhat.com>,<511B9B97.5060309@redhat.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E407108D0D6@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, Isnt Postfix the RHEL default now? So is it that hard to do a Postfix-ipa-config.rpm? Its something we want as well, so I'll do a RFE, RH support will love me more I'm sure.... ;] 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 Rob Crittenden [rcritten at redhat.com] Sent: Thursday, 14 February 2013 2:56 a.m. To: Petr Spacek Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Account Expiration Petr Spacek wrote: > On 12.2.2013 20:21, John Dennis wrote: >> On 02/12/2013 01:40 PM, Rob Crittenden wrote: >>>> Is it possible to ipa to send a email to user when his account is about >>>> to expire (the current date is near krbprincipalexpiration date) ? >>> >>> Not currently. In 3.0+ we will provide a notice when one logs into the >>> WebUI but that's it. >>> >>> We can't be sure that an MTA is properly configured on the IPA server at >>> install time so we have punted on this for a while. We don't want to get >>> into the business of picking and configuring one. This is one of those >>> things that seems really easy but gets complicated the deeper you dig >>> into it. We're open to suggestions/patches. >> >> Yeah, I don't think we want to be in the business of installing and >> configuring an MTA. However, we should be able to detect if one is >> available >> and use it if it is. I think it would be reasonable to restrict it to >> LMTP >> with a Unix domain socket (most MTA's support this). Then our config >> would >> have a LMTP domain socket pathname, if that pathname exists and we can >> connect >> to it we use, if not we fallback to not generating any mail. > > In meanwhile, it should be relatively simple to code script which does > ldapsearch from time to time and sends some e-mails. This script doesn't > have to run on the same server as IPA, only access to LDAP and some MTA > is required. > Yes, that is our current recommendation. There is a sample query in the docs IIRC. rob _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users From lists at romal.de Wed Feb 13 20:03:16 2013 From: lists at romal.de (Robert M. Albrecht) Date: Wed, 13 Feb 2013 21:03:16 +0100 Subject: [Freeipa-users] FreeIPA installation bug on F18 while "requesting RA certificate from CA" In-Reply-To: <511BA7DA.6080500@redhat.com> References: <511BA66B.1070302@romal.de> <511BA6BC.2080700@romal.de> <511BA7DA.6080500@redhat.com> Message-ID: <511BF184.106@romal.de> Hi Rob, yes, worked after downgrading nss* and xulrunner & firefox because of deps. Thanks. cu romal Am 13.02.13 15:48, schrieb Rob Crittenden: > Robert M. Albrecht wrote: >> Hi, >> >> >> Configuring NTP daemon (ntpd) >> [1/4]: stopping ntpd >> [2/4]: writing configuration >> [3/4]: configuring ntpd to start on boot >> [4/4]: starting ntpd >> Done configuring NTP daemon (ntpd). >> Configuring directory server (dirsrv): Estimated time 1 minute >> [1/36]: creating directory server user >> [2/36]: creating directory server instance >> [3/36]: adding default schema >> [4/36]: enabling memberof plugin >> [5/36]: enabling winsync plugin >> [6/36]: configuring replication version plugin >> [7/36]: enabling IPA enrollment plugin >> [8/36]: enabling ldapi >> [9/36]: configuring uniqueness plugin >> [10/36]: configuring uuid plugin >> [11/36]: configuring modrdn plugin >> [12/36]: enabling entryUSN plugin >> [13/36]: configuring lockout plugin >> [14/36]: creating indices >> [15/36]: enabling referential integrity plugin >> [16/36]: configuring certmap.conf >> [17/36]: configure autobind for root >> [18/36]: configure new location for managed entries >> [19/36]: restarting directory server >> [20/36]: adding default layout >> [21/36]: adding delegation layout >> [22/36]: adding replication acis >> [23/36]: creating container for managed entries >> [24/36]: configuring user private groups >> [25/36]: configuring netgroups from hostgroups >> [26/36]: creating default Sudo bind user >> [27/36]: creating default Auto Member layout >> [28/36]: adding range check plugin >> [29/36]: creating default HBAC rule allow_all >> [30/36]: Upload CA cert to the directory >> ipa : CRITICAL Failed to load upload-cacert.ldif: Command >> '/usr/bin/ldapmodify -v -f /tmp/tmpSkzd0p -H >> ldap://gutenberg.vorlon.lan:389 -x -D cn=Directory Manager -y >> /tmp/tmpVB45G5' returned non-zero exit status 247 >> [31/36]: initializing group membership >> [32/36]: adding master entry >> [33/36]: configuring Posix uid/gid generation >> [34/36]: enabling compatibility plugin >> [35/36]: tuning directory server >> [36/36]: configuring directory to start on boot >> Done configuring directory server (dirsrv). >> Configuring certificate server (pki-tomcatd): Estimated time 3 minutes >> 30 seconds >> [1/20]: creating certificate server user >> [2/20]: configuring certificate server instance >> [3/20]: disabling nonces >> [4/20]: creating RA agent certificate database >> [5/20]: importing CA chain to RA certificate database >> [6/20]: fixing RA database permissions >> [7/20]: setting up signing cert profile >> [8/20]: set up CRL publishing >> [9/20]: set certificate subject base >> [10/20]: enabling Subject Key Identifier >> [11/20]: enabling CRL and OCSP extensions for certificates >> [12/20]: setting audit signing renewal to 2 years >> [13/20]: configuring certificate server to start on boot >> [14/20]: restarting certificate server >> [15/20]: requesting RA certificate from CA >> Unexpected error - see /var/log/ipaserver-install.log for details: >> IndexError: list index out of range >> [root at gutenberg ~]# >> >> from /var/log/ipaserver-install.log >> >> 2013-02-13T14:38:15Z DEBUG stderr= >> 2013-02-13T14:38:15Z DEBUG Saving StateFile to >> '/var/lib/ipa/sysrestore/sysrestore.state' >> 2013-02-13T14:38:15Z DEBUG duration: 0 seconds >> 2013-02-13T14:38:15Z DEBUG [14/20]: restarting certificate server >> 2013-02-13T14:38:15Z DEBUG Starting external process >> 2013-02-13T14:38:15Z DEBUG args=/bin/systemctl restart >> pki-tomcatd at pki-tomcat.service >> 2013-02-13T14:38:19Z DEBUG Process finished, return code=0 >> 2013-02-13T14:38:19Z DEBUG stdout= >> 2013-02-13T14:38:19Z DEBUG stderr= >> 2013-02-13T14:38:19Z DEBUG Starting external process >> 2013-02-13T14:38:19Z DEBUG args=/bin/systemctl is-active >> pki-tomcatd at pki-tomcat.service >> 2013-02-13T14:38:19Z DEBUG Process finished, return code=0 >> 2013-02-13T14:38:19Z DEBUG stdout=active >> >> 2013-02-13T14:38:19Z DEBUG stderr= >> 2013-02-13T14:38:19Z DEBUG wait_for_open_ports: localhost [8080, 8443] >> timeout 120 >> 2013-02-13T14:38:25Z DEBUG The httpd proxy is not installed, skipping >> wait for CA >> 2013-02-13T14:38:25Z DEBUG duration: 9 seconds >> 2013-02-13T14:38:25Z DEBUG [15/20]: requesting RA certificate from CA >> 2013-02-13T14:38:25Z DEBUG Starting external process >> 2013-02-13T14:38:25Z DEBUG args=/usr/bin/certutil -d /etc/httpd/alias -f >> XXXXXXXX -R -k rsa -g 2048 -s CN=IPA RA,O=VORLON.LAN -z /tmp/tmpQoA4BN -a >> 2013-02-13T14:38:31Z DEBUG Process finished, return code=0 >> 2013-02-13T14:38:31Z DEBUG >> stdout=^X^\5^@^@^@^X^\5^@^@^@^P<81>^A^@^@^@^@^P<81>^A^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^A^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@!^F^@^@^@^@^@^@<98>^W5^@^@^@<81>^A^@ >> >> >> ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@<80><8D><81>^A^@^@^@^@^@^@^@^@^@^@^@^@^@^A^@^@^@^@^@^@P^@^@^@^@^@^@^@^P^B^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ >> >> >> ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ >> >> >> ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ >> >> >> ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@`^B^@^@^@^@^@^@^P^B^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ >> >> >> ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ >> >> >> ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ >> >> >> ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ >> >> >> 2013-02-13T14:38:31Z DEBUG stderr= >> >> Generating key. This may take a few moments... >> >> >> 2013-02-13T14:38:47Z INFO File >> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", >> line 617, in run_script >> return_value = main_function() >> >> File "/sbin/ipa-server-install", line 986, in main >> dm_password, subject_base=options.subject) >> >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line >> 621, in configure_instance >> self.start_creation(runtime=210) >> >> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >> line 358, in start_creation >> method() >> >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line >> 1219, in __request_ra_certificate >> self.requestId = item_node[0].childNodes[0].data >> >> 2013-02-13T14:38:47Z INFO The ipa-server-install command failed, >> exception: IndexError: list index out of range >> (END) >> >> >> There are no special charters in any password. >> >> Any ideas ? > > Caused by a bug in the nss package, see this thread > https://www.redhat.com/archives/freeipa-users/2013-February/msg00195.html > > rob > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > From janfrode at tanso.net Wed Feb 13 20:16:08 2013 From: janfrode at tanso.net (Jan-Frode Myklebust) Date: Wed, 13 Feb 2013 21:16:08 +0100 Subject: [Freeipa-users] Account Expiration In-Reply-To: <511B4EF6.1040702@redhat.com> References: <5106A043.1070103@redhat.com> <51131E6C.7030103@redhat.com> <51135B8C.5070001@redhat.com> <511A8C88.7000001@redhat.com> <511A9650.7030302@redhat.com> <511B4EF6.1040702@redhat.com> Message-ID: <20130213201608.GA28233@dibs.tanso.net> On Wed, Feb 13, 2013 at 09:29:42AM +0100, Petr Spacek wrote: > > > >Yeah, I don't think we want to be in the business of installing and > >configuring an MTA. However, we should be able to detect if one is available > >and use it if it is. I think it would be reasonable to restrict it to LMTP > >with a Unix domain socket (most MTA's support this). Then our config would > >have a LMTP domain socket pathname, if that pathname exists and we can connect > >to it we use, if not we fallback to not generating any mail. > > In meanwhile, it should be relatively simple to code script which > does ldapsearch from time to time and sends some e-mails. This > script doesn't have to run on the same server as IPA, only access to > LDAP and some MTA is required. Crude, but a start: ---------------------------------------------------------------- #! /bin/bash ldapsearch -z 500 -x -h ipa1.example.net -b cn=users,cn=accounts,dc=example,dc=net "(krbPasswordExpiration<=$(date +%Y%m%d --date='+1 week')000000Z)" mail |grep ^mail|cut -d: -f2 |while read mail do echo password expires in less than a week | mail -s "Password expires" $mail done ---------------------------------------------------------------- -jf From jreg2k at gmail.com Wed Feb 13 20:26:42 2013 From: jreg2k at gmail.com (James James) Date: Wed, 13 Feb 2013 21:26:42 +0100 Subject: [Freeipa-users] Account Expiration In-Reply-To: <511B9B97.5060309@redhat.com> References: <5106A043.1070103@redhat.com> <51131E6C.7030103@redhat.com> <51135B8C.5070001@redhat.com> <511A8C88.7000001@redhat.com> <511A9650.7030302@redhat.com> <511B4EF6.1040702@redhat.com> <511B9B97.5060309@redhat.com> Message-ID: What is the IIRC docs ? 2013/2/13 Rob Crittenden > Petr Spacek wrote: > >> On 12.2.2013 20:21, John Dennis wrote: >> >>> On 02/12/2013 01:40 PM, Rob Crittenden wrote: >>> >>>> Is it possible to ipa to send a email to user when his account is about >>>>> to expire (the current date is near krbprincipalexpiration date) ? >>>>> >>>> >>>> Not currently. In 3.0+ we will provide a notice when one logs into the >>>> WebUI but that's it. >>>> >>>> We can't be sure that an MTA is properly configured on the IPA server at >>>> install time so we have punted on this for a while. We don't want to get >>>> into the business of picking and configuring one. This is one of those >>>> things that seems really easy but gets complicated the deeper you dig >>>> into it. We're open to suggestions/patches. >>>> >>> >>> Yeah, I don't think we want to be in the business of installing and >>> configuring an MTA. However, we should be able to detect if one is >>> available >>> and use it if it is. I think it would be reasonable to restrict it to >>> LMTP >>> with a Unix domain socket (most MTA's support this). Then our config >>> would >>> have a LMTP domain socket pathname, if that pathname exists and we can >>> connect >>> to it we use, if not we fallback to not generating any mail. >>> >> >> In meanwhile, it should be relatively simple to code script which does >> ldapsearch from time to time and sends some e-mails. This script doesn't >> have to run on the same server as IPA, only access to LDAP and some MTA >> is required. >> >> > Yes, that is our current recommendation. There is a sample query in the > docs IIRC. > > 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 jreg2k at gmail.com Wed Feb 13 20:31:50 2013 From: jreg2k at gmail.com (James James) Date: Wed, 13 Feb 2013 21:31:50 +0100 Subject: [Freeipa-users] Account Expiration In-Reply-To: <20130213201608.GA28233@dibs.tanso.net> References: <5106A043.1070103@redhat.com> <51131E6C.7030103@redhat.com> <51135B8C.5070001@redhat.com> <511A8C88.7000001@redhat.com> <511A9650.7030302@redhat.com> <511B4EF6.1040702@redhat.com> <20130213201608.GA28233@dibs.tanso.net> Message-ID: thanks for your code. :) 2013/2/13 Jan-Frode Myklebust > On Wed, Feb 13, 2013 at 09:29:42AM +0100, Petr Spacek wrote: > > > > > >Yeah, I don't think we want to be in the business of installing and > > >configuring an MTA. However, we should be able to detect if one is > available > > >and use it if it is. I think it would be reasonable to restrict it to > LMTP > > >with a Unix domain socket (most MTA's support this). Then our config > would > > >have a LMTP domain socket pathname, if that pathname exists and we can > connect > > >to it we use, if not we fallback to not generating any mail. > > > > In meanwhile, it should be relatively simple to code script which > > does ldapsearch from time to time and sends some e-mails. This > > script doesn't have to run on the same server as IPA, only access to > > LDAP and some MTA is required. > > Crude, but a start: > > ---------------------------------------------------------------- > #! /bin/bash > ldapsearch -z 500 -x -h ipa1.example.net -b > cn=users,cn=accounts,dc=example,dc=net "(krbPasswordExpiration<=$(date > +%Y%m%d --date='+1 week')000000Z)" mail |grep ^mail|cut -d: -f2 |while read > mail > do > echo password expires in less than a week | mail -s "Password > expires" $mail > done > ---------------------------------------------------------------- > > > > -jf > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed Feb 13 20:34:51 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 13 Feb 2013 15:34:51 -0500 Subject: [Freeipa-users] Account Expiration In-Reply-To: References: <5106A043.1070103@redhat.com> <51131E6C.7030103@redhat.com> <51135B8C.5070001@redhat.com> <511A8C88.7000001@redhat.com> <511A9650.7030302@redhat.com> <511B4EF6.1040702@redhat.com> <511B9B97.5060309@redhat.com> Message-ID: <511BF8EB.1060504@redhat.com> James James wrote: > What is the IIRC docs ? IIRC == If I Recall Correctly. https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6-Beta/html-single/Identity_Management_Guide/index.html#pwd-expiration rob > > > 2013/2/13 Rob Crittenden > > > Petr Spacek wrote: > > On 12.2.2013 20:21, John Dennis wrote: > > On 02/12/2013 01:40 PM, Rob Crittenden wrote: > > Is it possible to ipa to send a email to user when > his account is about > to expire (the current date is near > krbprincipalexpiration date) ? > > > Not currently. In 3.0+ we will provide a notice when one > logs into the > WebUI but that's it. > > We can't be sure that an MTA is properly configured on > the IPA server at > install time so we have punted on this for a while. We > don't want to get > into the business of picking and configuring one. This > is one of those > things that seems really easy but gets complicated the > deeper you dig > into it. We're open to suggestions/patches. > > > Yeah, I don't think we want to be in the business of > installing and > configuring an MTA. However, we should be able to detect if > one is > available > and use it if it is. I think it would be reasonable to > restrict it to > LMTP > with a Unix domain socket (most MTA's support this). Then > our config > would > have a LMTP domain socket pathname, if that pathname exists > and we can > connect > to it we use, if not we fallback to not generating any mail. > > > In meanwhile, it should be relatively simple to code script > which does > ldapsearch from time to time and sends some e-mails. This script > doesn't > have to run on the same server as IPA, only access to LDAP and > some MTA > is required. > > > Yes, that is our current recommendation. There is a sample query in > the docs IIRC. > > rob > > > _________________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/__mailman/listinfo/freeipa-users > > > From shelltoesuperstar at gmail.com Wed Feb 13 21:57:22 2013 From: shelltoesuperstar at gmail.com (Charlie Derwent) Date: Wed, 13 Feb 2013 21:57:22 +0000 Subject: [Freeipa-users] Unable to enrol servers with principal In-Reply-To: <5116FC75.1000105@redhat.com> References: <5116FC75.1000105@redhat.com> Message-ID: On Sun, Feb 10, 2013 at 1:48 AM, Rob Crittenden wrote: > Charlie Derwent wrote: > >> Hi >> Whenever I attempt an unattended installation with a principal and >> password. The installation fails. >> I'm using the following syntax for my command >> ipa-client-install --domain=example.com >> --server=ipa.example.com --realm=EXAMPLE.COM >> --principal=user --password=pass -U >> --ntp-server=123.123.123.123 --mkhomedir --hostname=server1.example.com >> >> >> The error I get varies between (in order of frequency) >> Joining realm failed: /usr/sbin/ipa-join: symbol lookup error: >> /usr/sbin/ipa-join: undefined symbol: xmlrpc_server_info_set_user >> and >> > > This is the sort of thing that if you saw once, you should see every time. > What version of xmlrpc-c-client is installed? > > > I agree I should be seeing it all the time it's very odd that I'm not, the package is xmlrpc-c-client-1.16.24-1206.1840.4.el5.x86_64.rpm > > kinit(v5): Password incorrect while getting initial credentials >> and >> Password expired. you must change it now. >> kinit(v5): Cannot read password while getting initial credentials >> The password is 100% right as I can kinit on other servers and access >> the webgui with the same details. >> OTP's work flawlessly. >> > > The KDC log might have more information. > I'm not in the office right now so I can't check the logs but I assume the KDC log is actually on the IPA server? Thanks Charlie > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Wed Feb 13 22:24:07 2013 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 13 Feb 2013 17:24:07 -0500 Subject: [Freeipa-users] RHEL6 IPA and Active Directory synchronisation and Solaris RBAC In-Reply-To: References: Message-ID: <511C1287.4090703@redhat.com> On 02/13/2013 09:58 AM, Dag Wieers wrote: > Hi, > > We are investigating whether IPA is an acceptable solution for our > environment. One of the aspects that is not clear (from reading the > documentation and testing it without AD) is whether the > synchronization with AD can be limited to a subset. > > > Since we would like to only synchronize certain user-accounts > (conforming to a specific format) from AD unidirectionally, and we > also want to manage functional/technical accounts on IPA, we need to > make sure that we: > > - can filter the stuff we pull from AD > - can avoid the synchronisation to remove other accounts managed in IPA > > Can someone confirm that this is possible ? Is there any indepth > information on how this AD sycnhronization works (preferably about > RHEL6 IPA) ? > > > Also since we also require compatibility with Solaris, and roles > (RBAC) is currently used on Solaris, does IPA support RBAC on Solaris > ? (We noticed that RBAC mentioned in the IPA web interface only > relates to IPA management). > > > Thanks in advance, If you are planning to use latest bits from upstream you also can consider using trusts and PAM passthough instead of password synchronization. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Wed Feb 13 22:27:04 2013 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 13 Feb 2013 17:27:04 -0500 Subject: [Freeipa-users] Unable to enrol servers with principal In-Reply-To: References: <5116FC75.1000105@redhat.com> Message-ID: <511C1338.3010101@redhat.com> On 02/13/2013 04:57 PM, Charlie Derwent wrote: > > > On Sun, Feb 10, 2013 at 1:48 AM, Rob Crittenden > wrote: > > Charlie Derwent wrote: > > Hi > Whenever I attempt an unattended installation with a principal and > password. The installation fails. > I'm using the following syntax for my command > ipa-client-install --domain=example.com > > --server=ipa.example.com > --realm=EXAMPLE.COM > --principal=user --password=pass -U > --ntp-server=123.123.123.123 --mkhomedir > --hostname=server1.example.com > > > The error I get varies between (in order of frequency) > Joining realm failed: /usr/sbin/ipa-join: symbol lookup error: > /usr/sbin/ipa-join: undefined symbol: xmlrpc_server_info_set_user > and > > > This is the sort of thing that if you saw once, you should see > every time. What version of xmlrpc-c-client is installed? > > > > I agree I should be seeing it all the time it's very odd that I'm not, > the package is xmlrpc-c-client-1.16.24-1206.1840.4.el5.x86_64.rpm > > > kinit(v5): Password incorrect while getting initial credentials > and > Password expired. you must change it now. > kinit(v5): Cannot read password while getting initial credentials > The password is 100% right as I can kinit on other servers and > access > the webgui with the same details. > OTP's work flawlessly. > > > The KDC log might have more information. > > I'm not in the office right now so I can't check the logs but I assume > the KDC log is actually on the IPA server? yes and the DS access logs too > > Thanks > Charlie > > > > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steven.Jones at vuw.ac.nz Wed Feb 13 23:16:08 2013 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Wed, 13 Feb 2013 23:16:08 +0000 Subject: [Freeipa-users] RHEL6 IPA and Active Directory synchronisation and Solaris RBAC In-Reply-To: <511C1287.4090703@redhat.com> References: , <511C1287.4090703@redhat.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E407108D1F7@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, However trusts open a whole nest of vipers... The advantage of using winsync is you can control what happens in IPA, so if AD say gets hacked anything in IPA probably will survive. The reverse is of course also true.... ;] 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, 14 February 2013 11:24 a.m. To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] RHEL6 IPA and Active Directory synchronisation and Solaris RBAC On 02/13/2013 09:58 AM, Dag Wieers wrote: > Hi, > > We are investigating whether IPA is an acceptable solution for our > environment. One of the aspects that is not clear (from reading the > documentation and testing it without AD) is whether the > synchronization with AD can be limited to a subset. > > > Since we would like to only synchronize certain user-accounts > (conforming to a specific format) from AD unidirectionally, and we > also want to manage functional/technical accounts on IPA, we need to > make sure that we: > > - can filter the stuff we pull from AD > - can avoid the synchronisation to remove other accounts managed in IPA > > Can someone confirm that this is possible ? Is there any indepth > information on how this AD sycnhronization works (preferably about > RHEL6 IPA) ? > > > Also since we also require compatibility with Solaris, and roles > (RBAC) is currently used on Solaris, does IPA support RBAC on Solaris > ? (We noticed that RBAC mentioned in the IPA web interface only > relates to IPA management). > > > Thanks in advance, If you are planning to use latest bits from upstream you also can consider using trusts and PAM passthough instead of password synchronization. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users From rajnesh.siwal at gmail.com Thu Feb 14 07:20:02 2013 From: rajnesh.siwal at gmail.com (Rajnesh Kumar Siwal) Date: Thu, 14 Feb 2013 12:50:02 +0530 Subject: [Freeipa-users] Logging of Who does What on IPA Server Message-ID: IPA is going to be very critical Server for any environment. Do we have proper logging of who as locked whom, Who has created a sudo policy, who has allowed access to whom etc ? -- Regards, Rajnesh Kumar Siwal From mkosek at redhat.com Thu Feb 14 08:49:42 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 14 Feb 2013 09:49:42 +0100 Subject: [Freeipa-users] Logging of Who does What on IPA Server In-Reply-To: References: Message-ID: <511CA526.1010702@redhat.com> On 02/14/2013 08:20 AM, Rajnesh Kumar Siwal wrote: > IPA is going to be very critical Server for any environment. > Do we have proper logging of who as locked whom, Who has created a > sudo policy, who has allowed access to whom etc ? > Hello Rajnesh, the audit component of IPA collecting and processing audit information is not there yet. There is some information about our future direction in our wiki: http://freeipa.org/page/Roadmap As for logging who did what, you can check existing logs on your IPA server(s) which may have information you need for audit: LDAP access log (LDAP calls): /var/log/dirsrv/slapd-$INST/access http error log (IPA framework calls): /var/log/httpd/error_log Martin From dag at wieers.com Thu Feb 14 09:02:56 2013 From: dag at wieers.com (Dag Wieers) Date: Thu, 14 Feb 2013 10:02:56 +0100 (CET) Subject: [Freeipa-users] Granting rights temporarily Message-ID: Hi, Another interesting recommendation from security is that all granted access (that is exceptional, rather than permanent) should be limited in time from the onset. If this is not possible all granted access needs to be documented and revised regularly. However a system that would automatically revoke access after a certain period is preferred from a security/administrative perspective. (Period to be defined when granting access) This would mean that e.g. sudo-rules, group memberships, etc. could have due dates and that IPA ensures that these rights are revoked in due time. So I was wondering whether this is something that was already discussed as a feature for IPA ? -- -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- dagit linux solutions, info at dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors] From natxo.asenjo at gmail.com Thu Feb 14 09:22:35 2013 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Thu, 14 Feb 2013 10:22:35 +0100 Subject: [Freeipa-users] Granting rights temporarily In-Reply-To: References: Message-ID: On Thu, Feb 14, 2013 at 10:02 AM, Dag Wieers wrote: > Hi, > > Another interesting recommendation from security is that all granted access > (that is exceptional, rather than permanent) should be limited in time from > the onset. > > If this is not possible all granted access needs to be documented and > revised regularly. However a system that would automatically revoke access > after a certain period is preferred from a security/administrative > perspective. (Period to be defined when granting access) > > This would mean that e.g. sudo-rules, group memberships, etc. could have due > dates and that IPA ensures that these rights are revoked in due time. > > So I was wondering whether this is something that was already discussed as a > feature for IPA ? +1 -- groet, natxo From pspacek at redhat.com Thu Feb 14 09:37:32 2013 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 14 Feb 2013 10:37:32 +0100 Subject: [Freeipa-users] Logging of Who does What on IPA Server In-Reply-To: <511CA526.1010702@redhat.com> References: <511CA526.1010702@redhat.com> Message-ID: <511CB05C.5020509@redhat.com> On 14.2.2013 09:49, Martin Kosek wrote: > On 02/14/2013 08:20 AM, Rajnesh Kumar Siwal wrote: >> IPA is going to be very critical Server for any environment. >> Do we have proper logging of who as locked whom, Who has created a >> sudo policy, who has allowed access to whom etc ? >> > > Hello Rajnesh, > > the audit component of IPA collecting and processing audit information is not > there yet. There is some information about our future direction in our wiki: > http://freeipa.org/page/Roadmap > > As for logging who did what, you can check existing logs on your IPA server(s) > which may have information you need for audit: > > LDAP access log (LDAP calls): /var/log/dirsrv/slapd-$INST/access Also note 389 audit capabilities! > http error log (IPA framework calls): /var/log/httpd/error_log -- Petr^2 Spacek From abokovoy at redhat.com Thu Feb 14 12:17:17 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 14 Feb 2013 14:17:17 +0200 Subject: [Freeipa-users] Granting rights temporarily In-Reply-To: References: Message-ID: <20130214121717.GF476@redhat.com> On Thu, 14 Feb 2013, Dag Wieers wrote: >Hi, > >Another interesting recommendation from security is that all granted >access (that is exceptional, rather than permanent) should be limited >in time from the onset. > >If this is not possible all granted access needs to be documented and >revised regularly. However a system that would automatically revoke >access after a certain period is preferred from a >security/administrative perspective. (Period to be defined when >granting access) > >This would mean that e.g. sudo-rules, group memberships, etc. could >have due dates and that IPA ensures that these rights are revoked in >due time. > >So I was wondering whether this is something that was already >discussed as a feature for IPA ? Yes, something along these lines was discussed in past. We have three tickets so far in deferred state: https://fedorahosted.org/freeipa/ticket/547 https://fedorahosted.org/freeipa/ticket/548 https://fedorahosted.org/freeipa/ticket/3127 A problem with time-based access management is to consider its locality. Time-limited rules all stored centrally but applied locally and timezones play important role in messing things up. We also wanted to develop solution which would be scalable and easier to integrate with visual tools to edit recurrent events, thus ideas towards use of iCalendar (RFC5545 and RFC5546) format. From FreeIPA perspective application of rules would be done by SSSD and its plugins to various applications (sudo, SELinux enforcement, etc). FreeIPA itself would provide storage and means to edit the rules, both in command line and web UI. We haven't started working on the topic yet because there were (and currently are) numerous other tasks with slightly higher priority. Any contribution in the are is welcomed, even in form of thinking out and writing down feature proposal, based on a template at http://www.freeipa.org/page/Feature_template -- / Alexander Bokovoy From simo at redhat.com Thu Feb 14 13:51:17 2013 From: simo at redhat.com (Simo Sorce) Date: Thu, 14 Feb 2013 08:51:17 -0500 Subject: [Freeipa-users] Logging of Who does What on IPA Server In-Reply-To: References: Message-ID: <1360849877.12328.168.camel@willson.li.ssimo.org> On Thu, 2013-02-14 at 12:50 +0530, Rajnesh Kumar Siwal wrote: > IPA is going to be very critical Server for any environment. > Do we have proper logging of who as locked whom, Who has created a > sudo policy, who has allowed access to whom etc ? You can see this information by querying LDAP directly. The 'creatorsName' attribute holds the identity of the user that created the object. The 'createTimestamp' attribute holds the time at which the object was created. The 'modifiersName' attribute holds the identity of the user that last modified the object. The 'modifyTimestamp' attribute holds the time at which the object was modified. All these attributes are operational, so you normally do not see them unless you explicitly ask for them during an ldap search. Some LDAP browsers allow you to add a list of attributes to ask for explicitly. To see these attributes for a user named foo for example you can run this query: "ldapsearch -Y GSSAPI uid=foo creatorsName createTimestamp modifiersName modifyTimestamp" add a '*' at the end if you also want to fetch regular attributes. This command assumes you have kerberos credentials (-Y GSSAPI tells ldapsearch to use them to auth to the server). Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Thu Feb 14 13:54:23 2013 From: simo at redhat.com (Simo Sorce) Date: Thu, 14 Feb 2013 08:54:23 -0500 Subject: [Freeipa-users] Granting rights temporarily In-Reply-To: References: Message-ID: <1360850063.12328.171.camel@willson.li.ssimo.org> On Thu, 2013-02-14 at 10:02 +0100, Dag Wieers wrote: > Hi, > > Another interesting recommendation from security is that all granted > access (that is exceptional, rather than permanent) should be limited in > time from the onset. > > If this is not possible all granted access needs to be documented and > revised regularly. However a system that would automatically revoke access > after a certain period is preferred from a security/administrative > perspective. (Period to be defined when granting access) > > This would mean that e.g. sudo-rules, group memberships, etc. could have > due dates and that IPA ensures that these rights are revoked in due time. > > So I was wondering whether this is something that was already discussed as > a feature for IPA ? sudo rules have sudoNotBefore sudoNotAfter attributes, so you can limit their validity. User accounts have an expiration time as well. There is no expiration time for groups or group membership, we have not had any previous request or need for this and I am not sure it really is possible to do this for group memberships. I guess we could add an attribute to expire a group, however no client will respect that for now, so it would be a bit pointless if not misguiding. Simo. -- Simo Sorce * Red Hat, Inc * New York From rajnesh.siwal at gmail.com Thu Feb 14 14:56:05 2013 From: rajnesh.siwal at gmail.com (Rajnesh Kumar Siwal) Date: Thu, 14 Feb 2013 20:26:05 +0530 Subject: [Freeipa-users] SOLVED: Re: Logging of Who does What on IPA Server Message-ID: Thanks, Simo. It solves my concern, On Thu, Feb 14, 2013 at 7:21 PM, Simo Sorce wrote: > On Thu, 2013-02-14 at 12:50 +0530, Rajnesh Kumar Siwal wrote: >> IPA is going to be very critical Server for any environment. >> Do we have proper logging of who as locked whom, Who has created a >> sudo policy, who has allowed access to whom etc ? > > You can see this information by querying LDAP directly. > > The 'creatorsName' attribute holds the identity of the user that created > the object. > > The 'createTimestamp' attribute holds the time at which the object was > created. > > The 'modifiersName' attribute holds the identity of the user that last > modified the object. > > The 'modifyTimestamp' attribute holds the time at which the object was > modified. > > All these attributes are operational, so you normally do not see them > unless you explicitly ask for them during an ldap search. Some LDAP > browsers allow you to add a list of attributes to ask for explicitly. > > > > To see these attributes for a user named foo for example you can run > this query: "ldapsearch -Y GSSAPI uid=foo creatorsName createTimestamp > modifiersName modifyTimestamp" > > add a '*' at the end if you also want to fetch regular attributes. > This command assumes you have kerberos credentials (-Y GSSAPI tells > ldapsearch to use them to auth to the server). > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > -- Regards, Rajnesh Kumar Siwal From rmeggins at redhat.com Thu Feb 14 15:30:44 2013 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 14 Feb 2013 08:30:44 -0700 Subject: [Freeipa-users] Granting rights temporarily In-Reply-To: <1360850063.12328.171.camel@willson.li.ssimo.org> References: <1360850063.12328.171.camel@willson.li.ssimo.org> Message-ID: <511D0324.1070303@redhat.com> On 02/14/2013 06:54 AM, Simo Sorce wrote: > On Thu, 2013-02-14 at 10:02 +0100, Dag Wieers wrote: >> Hi, >> >> Another interesting recommendation from security is that all granted >> access (that is exceptional, rather than permanent) should be limited in >> time from the onset. >> >> If this is not possible all granted access needs to be documented and >> revised regularly. However a system that would automatically revoke access >> after a certain period is preferred from a security/administrative >> perspective. (Period to be defined when granting access) >> >> This would mean that e.g. sudo-rules, group memberships, etc. could have >> due dates and that IPA ensures that these rights are revoked in due time. >> >> So I was wondering whether this is something that was already discussed as >> a feature for IPA ? > sudo rules have sudoNotBefore sudoNotAfter attributes, so you can limit > their validity. > > User accounts have an expiration time as well. > > There is no expiration time for groups or group membership, we have not > had any previous request or need for this and I am not sure it really is > possible to do this for group memberships. Someone was asking for this in one of the OpenLDAP forums. They want to be able to expire group membership after a certain time. They were going to create a new syntax which would be something like generalizedTime DELIM distinguishedName e.g. dn: cn=temporaryAdminGroup,.... timedmember: 20130215120000Z$uid=richm,...... After 20130215120000Z is hit, the value would be removed from the group. > > I guess we could add an attribute to expire a group, however no client > will respect that for now, so it would be a bit pointless if not > misguiding. > > Simo. > From dag at wieers.com Thu Feb 14 15:57:46 2013 From: dag at wieers.com (Dag Wieers) Date: Thu, 14 Feb 2013 16:57:46 +0100 (CET) Subject: [Freeipa-users] Granting rights temporarily In-Reply-To: <20130214121717.GF476@redhat.com> References: <20130214121717.GF476@redhat.com> Message-ID: On Thu, 14 Feb 2013, Alexander Bokovoy wrote: > On Thu, 14 Feb 2013, Dag Wieers wrote: > >> So I was wondering whether this is something that was already discussed as >> a feature for IPA ? > Yes, something along these lines was discussed in past. > We have three tickets so far in deferred state: > https: //fedorahosted.org/freeipa/ticket/547 > https: //fedorahosted.org/freeipa/ticket/548 > https: //fedorahosted.org/freeipa/ticket/3127 > > A problem with time-based access management is to consider its locality. > Time-limited rules all stored centrally but applied locally and > timezones play important role in messing things up. > > We also wanted to develop solution which would be scalable and easier to > integrate with visual tools to edit recurrent events, thus ideas towards > use of iCalendar (RFC5545 and RFC5546) format. > > From FreeIPA perspective application of rules would be done by SSSD and > its plugins to various applications (sudo, SELinux enforcement, etc). > FreeIPA itself would provide storage and means to edit the rules, both > in command line and web UI. Thanks for the feedback. Obviously I didn't consider all the use-cases yet, but what you describe would fulfill the security recommendation. I'd like to start a feature proposal, however I am not sure if I am best placed to do it given there has obviously been discussions about it already (and our use-case is rather limited). Let me know if you see any value. -- -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- dagit linux solutions, info at dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors] From simo at redhat.com Thu Feb 14 16:03:05 2013 From: simo at redhat.com (Simo Sorce) Date: Thu, 14 Feb 2013 11:03:05 -0500 Subject: [Freeipa-users] Granting rights temporarily In-Reply-To: <511D0324.1070303@redhat.com> References: <1360850063.12328.171.camel@willson.li.ssimo.org> <511D0324.1070303@redhat.com> Message-ID: <1360857785.12328.209.camel@willson.li.ssimo.org> On Thu, 2013-02-14 at 08:30 -0700, Rich Megginson wrote: > On 02/14/2013 06:54 AM, Simo Sorce wrote: > > On Thu, 2013-02-14 at 10:02 +0100, Dag Wieers wrote: > >> Hi, > >> > >> Another interesting recommendation from security is that all granted > >> access (that is exceptional, rather than permanent) should be limited in > >> time from the onset. > >> > >> If this is not possible all granted access needs to be documented and > >> revised regularly. However a system that would automatically revoke access > >> after a certain period is preferred from a security/administrative > >> perspective. (Period to be defined when granting access) > >> > >> This would mean that e.g. sudo-rules, group memberships, etc. could have > >> due dates and that IPA ensures that these rights are revoked in due time. > >> > >> So I was wondering whether this is something that was already discussed as > >> a feature for IPA ? > > sudo rules have sudoNotBefore sudoNotAfter attributes, so you can limit > > their validity. > > > > User accounts have an expiration time as well. > > > > There is no expiration time for groups or group membership, we have not > > had any previous request or need for this and I am not sure it really is > > possible to do this for group memberships. > > Someone was asking for this in one of the OpenLDAP forums. They want to > be able to expire group membership after a certain time. They were going > to create a new syntax which would be something like > > generalizedTime DELIM distinguishedName > > e.g. > dn: cn=temporaryAdminGroup,.... > timedmember: 20130215120000Z$uid=richm,...... > > After 20130215120000Z is hit, the value would be removed from the group. To me it looks like a bad hack and breaks all exiting clients. I do not think it is a viable interface except for purpose built software. Simo. -- Simo Sorce * Red Hat, Inc * New York From chucklever at gmail.com Thu Feb 14 16:36:25 2013 From: chucklever at gmail.com (Chuck Lever) Date: Thu, 14 Feb 2013 11:36:25 -0500 Subject: [Freeipa-users] ipa-server-install IndexError: list index out of range In-Reply-To: <511AD701.70907@redhat.com> References: <511AB2F7.8030509@redhat.com> <511ABD6B.9000505@redhat.com> <511AD701.70907@redhat.com> Message-ID: On Feb 12, 2013, at 6:57 PM, Rob Crittenden wrote: > Rob Crittenden wrote: >> Chuck Lever wrote: >>> >>> On Feb 12, 2013, at 4:24 PM, Rob Crittenden wrote: >>> >>>> Chuck Lever wrote: >>>>> Hi- >>>>> >>>>> I'm new to FreeIPA. I'm installing on an up-to-date Fedora 18 >>>>> system from the freeipa packages available with Fedora 18. When >>>>> running ipa-server-install, the install process fails here: >>>>> >>>>> Configuring certificate server (pki-tomcatd): Estimated time 3 >>>>> minutes 30 seconds >>>>> [1/20]: creating certificate server user >>>>> ... >>>>> [15/20]: requesting RA certificate from CA >>>>> Unexpected error - see /var/log/ipaserver-install.log for details: >>>>> IndexError: list index out of range >>>>> >>>>> The tail of the installer log looks like this: >>>>> >>>>> Generating key. This may take a few moments... >>>>> >>>>> >>>>> 2013-02-12T21:04:46Z INFO File >>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line >>>>> 617, in run_script >>>>> return_value = main_function() >>>>> >>>>> File "/sbin/ipa-server-install", line 986, in main >>>>> dm_password, subject_base=options.subject) >>>>> >>>>> File >>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", >>>>> line 621, in configure_instance >>>>> self.start_creation(runtime=210) >>>>> >>>>> File >>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >>>>> line 358, in start_creation >>>>> method() >>>>> >>>>> File >>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", >>>>> line 1219, in __request_ra_certificate >>>>> self.requestId = item_node[0].childNodes[0].data >>>>> >>>>> 2013-02-12T21:04:46Z INFO The ipa-server-install command failed, >>>>> exception: IndexError: list index out of range >>>>> >>>>> >>>>> Is there a workaround or fix available? I haven't found any >>>>> relevant information via a web search, and a few searches on >>>>> bugzilla.redhat.com have come up empty. >>>>> >>>> >>>> We've seen just one other report of this and unfortunately the VM was >>>> removed before we could do a lot of diagnosis. What we saw was that >>>> certutil output garbage when requesting the RA admin certificate. Can >>>> you look in /var/log/ipaserver-install.log for the last certutil >>>> command? Does stdout contain a lot of garbage characters in it? It >>>> should consist of a base64-encoded CSR. >>> >>> 2013-02-12T21:04:29Z DEBUG [15/20]: requesting RA certificate from CA >>> 2013-02-12T21:04:29Z DEBUG Starting external process >>> 2013-02-12T21:04:29Z DEBUG args=/usr/bin/certutil -d /etc/httpd/alias >>> -f XXXXXXXX -R -k >>> rsa -g 2048 -s CN=IPA RA,O=1015GRANGER.NET -z /tmp/tmptIYFZ5 -a >>> 2013-02-12T21:04:33Z DEBUG Process finished, return code=0 >>> 2013-02-12T21:04:33Z DEBUG >>> stdout=^X^\^<^@^@^@^X^\^<^@^@^@^P-<85>^B^@^@^@^@^P- >>> <85>^B^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ >>> >>> ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ >>> >>> ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ >>> >>> ^@^@^@@^G >>> 8^?^@^@^E^@^@^@^@^@^@<98>^W^<^@^@^@<98>^W^<^@^@^@^@^@^@^@^@^@ >>> >>> ^@^@^@^@^@^@^@^@^@^@?<87>^U^^6?^L^R|=^^W^D^N >>> >>> ^\=<9F>^@^@^@^@^@^@^@^@q^E^@^@^@^@^@^@<98>^W^<^@^@^@^P^B^@^@^@^@^@^@ >>> >>> ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^Y<85>^B^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^A_<^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@+_<^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^A >>> >>> ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^D^@^@^@^@^@^@<98>^W^<^@^@^@* >>> >>> <85>^B^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@<80><84>^B^@^@^@^@^@^@^@^@^@^@^@^@^@^A^@^@^@^@^@^@P^@^@^@^@^@^@^@^P^B^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ >>> >>> ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@! > ^! >>> >> @^@^@^@^@` >> ^B^@^@^@^@^@^@^P^B^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ >>> ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ >>> >>> 2013-02-12T21:04:33Z DEBUG stderr= >>> >>> >>>> If so, what version of nss and nss-tools do you have installed? >>> >>> >>> [root at forain ~]# yum info nss nss-tools >>> Loaded plugins: langpacks, presto, refresh-packagekit >>> Installed Packages >>> Name : nss >>> Arch : x86_64 >>> Version : 3.14.2 >>> Release : 2.fc18 >>> Size : 2.5 M >>> Repo : installed >>> From repo : updates >>> Summary : Network Security Services >>> URL : http://www.mozilla.org/projects/security/pki/nss/ >>> License : MPLv2.0 >>> Description : Network Security Services (NSS) is a set of libraries >>> designed to >>> : support cross-platform development of security-enabled >>> client and >>> : server applications. Applications built with NSS can >>> support SSL v2 >>> : and v3, TLS, PKCS #5, PKCS #7, PKCS #11, PKCS #12, >>> S/MIME, X.509 >>> : v3 certificates, and other security standards. >>> >>> Name : nss-tools >>> Arch : x86_64 >>> Version : 3.14.2 >>> Release : 2.fc18 >>> Size : 1.7 M >>> Repo : installed >>> From repo : updates >>> Summary : Tools for the Network Security Services >>> URL : http://www.mozilla.org/projects/security/pki/nss/ >>> License : MPLv2.0 >>> Description : Network Security Services (NSS) is a set of libraries >>> designed to >>> : support cross-platform development of security-enabled >>> client and >>> : server applications. Applications built with NSS can >>> support SSL v2 >>> : and v3, TLS, PKCS #5, PKCS #7, PKCS #11, PKCS #12, >>> S/MIME, X.509 >>> : v3 certificates, and other security standards. >>> : >>> : Install the nss-tools package if you need command-line >>> tools to >>> : manipulate the NSS certificate and key database. >>> >>> Available Packages >>> Name : nss >>> Arch : i686 >>> Version : 3.14.2 >>> Release : 2.fc18 >>> Size : 833 k >>> Repo : updates/18/x86_64 >>> Summary : Network Security Services >>> URL : http://www.mozilla.org/projects/security/pki/nss/ >>> License : MPLv2.0 >>> Description : Network Security Services (NSS) is a set of libraries >>> designed to >>> : support cross-platform development of security-enabled >>> client and >>> : server applications. Applications built with NSS can >>> support SSL v2 >>> : and v3, TLS, PKCS #5, PKCS #7, PKCS #11, PKCS #12, >>> S/MIME, X.509 >>> : v3 certificates, and other security standards. >>> >>> [root at forain ~]# >>> >>> Hope this helps. >>> >>> -- >>> Chuck Lever >>> chucklever[at]gmail[dot]com >>> >>> >>> >> >> Ok, easily reproduced with this version of nss. I filed >> https://bugzilla.redhat.com/show_bug.cgi?id=910584 >> >> For a workaround you might try to yum downgrade nss. You may need to >> downgrade several other subpackages as well like nss-tools and >> nss-sysinit depending on your install. >> >> I think you can safely upgrade again once the install is complete. > > I did some real quick smoke testing and this seems to work. I did: > > # yum downgrade nss nss-* > # ipa-server-install ... > # yum update nss > > This is with a dogtag CA. I didn't test a selfsign CA. > > This was a single install. > > Preparing a replica will fail with the error "Certificate issuance failed" because of the certutil problem. Confirmed: # yum downgrade nss nss-tools nss-sysinit # ipa-server-install worked as expected. -- Chuck Lever chucklever[at]gmail[dot]com From sigbjorn at nixtra.com Thu Feb 14 17:56:17 2013 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Thu, 14 Feb 2013 18:56:17 +0100 Subject: [Freeipa-users] RHEL6 IPA and Active Directory synchronisation and Solaris RBAC In-Reply-To: <511BACEE.8050900@redhat.com> References: <511BACEE.8050900@redhat.com> Message-ID: <511D2541.1000201@nixtra.com> On 02/13/2013 04:10 PM, Rob Crittenden wrote: >> >> Also since we also require compatibility with Solaris, and roles (RBAC) >> is currently used on Solaris, does IPA support RBAC on Solaris ? (We >> noticed that RBAC mentioned in the IPA web interface only relates to IPA >> management). > > No, IPA doesn't support RBAC on Solaris. > I've come across the same issue. This is just a matter of extending the schema. Would there be any interest for adding the Solaris RBAC schema as a part of the standard IPA distributed LDAP schemas? Regards, Siggi From rcritten at redhat.com Thu Feb 14 18:27:56 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 14 Feb 2013 13:27:56 -0500 Subject: [Freeipa-users] RHEL6 IPA and Active Directory synchronisation and Solaris RBAC In-Reply-To: <511D2541.1000201@nixtra.com> References: <511BACEE.8050900@redhat.com> <511D2541.1000201@nixtra.com> Message-ID: <511D2CAC.6050400@redhat.com> Sigbjorn Lie wrote: > On 02/13/2013 04:10 PM, Rob Crittenden wrote: > >>> >>> Also since we also require compatibility with Solaris, and roles (RBAC) >>> is currently used on Solaris, does IPA support RBAC on Solaris ? (We >>> noticed that RBAC mentioned in the IPA web interface only relates to IPA >>> management). >> >> No, IPA doesn't support RBAC on Solaris. >> > > I've come across the same issue. This is just a matter of extending the > schema. > > Would there be any interest for adding the Solaris RBAC schema as a part > of the standard IPA distributed LDAP schemas? Is the schema enough? Won't people want a way from IPA to manage the data too? rob From rmercer at harris.com Thu Feb 14 19:55:58 2013 From: rmercer at harris.com (Rodney L. Mercer) Date: Thu, 14 Feb 2013 14:55:58 -0500 Subject: [Freeipa-users] RHEL6 IPA and Active Directory synchronisation and Solaris RBAC In-Reply-To: <511D2541.1000201@nixtra.com> References: <511BACEE.8050900@redhat.com> <511D2541.1000201@nixtra.com> Message-ID: <1360871758.21935.497.camel@osc145.evn.harris.com> On Thu, 2013-02-14 at 18:56 +0100, Sigbjorn Lie wrote: > On 02/13/2013 04:10 PM, Rob Crittenden wrote: > > >> > >> Also since we also require compatibility with Solaris, and roles (RBAC) > >> is currently used on Solaris, does IPA support RBAC on Solaris ? (We > >> noticed that RBAC mentioned in the IPA web interface only relates to IPA > >> management). > > > > No, IPA doesn't support RBAC on Solaris. > > > > I've come across the same issue. This is just a matter of extending the > schema. > > Would there be any interest for adding the Solaris RBAC schema as a part > of the standard IPA distributed LDAP schemas? > > > > Regards, > Siggi > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-usersSiggi, Yes, I had asked for this back in late 2011. I am glad to see that Dag Wieers is asking for it also. https://www.redhat.com/archives/freeipa-users/2011-November/msg00053.html Regards, Rodney. -- Rodney Mercer Systems Administrator From dag at wieers.com Thu Feb 14 20:06:38 2013 From: dag at wieers.com (Dag Wieers) Date: Thu, 14 Feb 2013 21:06:38 +0100 (CET) Subject: [Freeipa-users] RHEL6 IPA and Active Directory synchronisation and Solaris RBAC In-Reply-To: <511D2CAC.6050400@redhat.com> References: <511BACEE.8050900@redhat.com> <511D2541.1000201@nixtra.com> <511D2CAC.6050400@redhat.com> Message-ID: On Thu, 14 Feb 2013, Rob Crittenden wrote: > Sigbjorn Lie wrote: >> On 02/13/2013 04:10 PM, Rob Crittenden wrote: >> >> > > Also since we also require compatibility with Solaris, and roles >> > > (RBAC) >> > > is currently used on Solaris, does IPA support RBAC on Solaris ? (We >> > > noticed that RBAC mentioned in the IPA web interface only relates to >> > > IPA >> > > management). >> > >> > No, IPA doesn't support RBAC on Solaris. >> >> I've come across the same issue. This is just a matter of extending the >> schema. >> >> Would there be any interest for adding the Solaris RBAC schema as a part >> of the standard IPA distributed LDAP schemas? > > Is the schema enough? Won't people want a way from IPA to manage the data > too? Of course, integration in IPA is better, but having the schema integrated is a good first step. Besides, integration in IPA probably won't happen without RBAC support in Fedora/RHEL, right ? -- -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- dagit linux solutions, info at dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors] From simo at redhat.com Thu Feb 14 20:17:23 2013 From: simo at redhat.com (Simo Sorce) Date: Thu, 14 Feb 2013 15:17:23 -0500 Subject: [Freeipa-users] RHEL6 IPA and Active Directory synchronisation and Solaris RBAC In-Reply-To: References: <511BACEE.8050900@redhat.com> <511D2541.1000201@nixtra.com> <511D2CAC.6050400@redhat.com> Message-ID: <1360873043.12328.225.camel@willson.li.ssimo.org> On Thu, 2013-02-14 at 21:06 +0100, Dag Wieers wrote: > On Thu, 14 Feb 2013, Rob Crittenden wrote: > > > Sigbjorn Lie wrote: > >> On 02/13/2013 04:10 PM, Rob Crittenden wrote: > >> > >> > > Also since we also require compatibility with Solaris, and roles > >> > > (RBAC) > >> > > is currently used on Solaris, does IPA support RBAC on Solaris ? (We > >> > > noticed that RBAC mentioned in the IPA web interface only relates to > >> > > IPA > >> > > management). > >> > > >> > No, IPA doesn't support RBAC on Solaris. > >> > >> I've come across the same issue. This is just a matter of extending the > >> schema. > >> > >> Would there be any interest for adding the Solaris RBAC schema as a part > >> of the standard IPA distributed LDAP schemas? > > > > Is the schema enough? Won't people want a way from IPA to manage the data > > too? > > Of course, integration in IPA is better, but having the schema integrated > is a good first step. Besides, integration in IPA probably won't happen > without RBAC support in Fedora/RHEL, right ? We can consider code contributions for this kind of features. Of course not being able to test them in our default distro would make them fragile and more subject to regressions, but I think that can also be easily fixed by an appropriate test suite. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Thu Feb 14 20:18:27 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 14 Feb 2013 15:18:27 -0500 Subject: [Freeipa-users] RHEL6 IPA and Active Directory synchronisation and Solaris RBAC In-Reply-To: References: <511BACEE.8050900@redhat.com> <511D2541.1000201@nixtra.com> <511D2CAC.6050400@redhat.com> Message-ID: <511D4693.8010502@redhat.com> Dag Wieers wrote: > On Thu, 14 Feb 2013, Rob Crittenden wrote: > >> Sigbjorn Lie wrote: >>> On 02/13/2013 04:10 PM, Rob Crittenden wrote: >>> >>> > > Also since we also require compatibility with Solaris, and roles >>> > > (RBAC) >>> > > is currently used on Solaris, does IPA support RBAC on Solaris ? >>> (We >>> > > noticed that RBAC mentioned in the IPA web interface only >>> relates to > > IPA >>> > > management). >>> > > No, IPA doesn't support RBAC on Solaris. >>> >>> I've come across the same issue. This is just a matter of extending the >>> schema. >>> >>> Would there be any interest for adding the Solaris RBAC schema as a >>> part >>> of the standard IPA distributed LDAP schemas? >> >> Is the schema enough? Won't people want a way from IPA to manage the >> data too? > > Of course, integration in IPA is better, but having the schema > integrated is a good first step. Besides, integration in IPA probably > won't happen without RBAC support in Fedora/RHEL, right ? > Right, and it is a bit beyond our scope to create a compatible RBAC solution. rob From sigbjorn at nixtra.com Thu Feb 14 20:44:02 2013 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Thu, 14 Feb 2013 21:44:02 +0100 Subject: [Freeipa-users] RHEL6 IPA and Active Directory synchronisation and Solaris RBAC In-Reply-To: <511D4693.8010502@redhat.com> References: <511BACEE.8050900@redhat.com> <511D2541.1000201@nixtra.com> <511D2CAC.6050400@redhat.com> <511D4693.8010502@redhat.com> Message-ID: I agree with schema support being enough for now. I do not expect the ipa mgmt tools to support Solaris rbac mgmt. The ipa mgmt tools are great, but I already have other data in the ipa ldap that I have to manage manually anyway. Rgds, Siggi Rob Crittenden wrote: >Dag Wieers wrote: >> On Thu, 14 Feb 2013, Rob Crittenden wrote: >> >>> Sigbjorn Lie wrote: >>>> On 02/13/2013 04:10 PM, Rob Crittenden wrote: >>>> >>>> > > Also since we also require compatibility with Solaris, and >roles >>>> > > (RBAC) >>>> > > is currently used on Solaris, does IPA support RBAC on Solaris >? >>>> (We >>>> > > noticed that RBAC mentioned in the IPA web interface only >>>> relates to > > IPA >>>> > > management). >>>> > > No, IPA doesn't support RBAC on Solaris. >>>> >>>> I've come across the same issue. This is just a matter of >extending the >>>> schema. >>>> >>>> Would there be any interest for adding the Solaris RBAC schema as >a >>>> part >>>> of the standard IPA distributed LDAP schemas? >>> >>> Is the schema enough? Won't people want a way from IPA to manage the >>> data too? >> >> Of course, integration in IPA is better, but having the schema >> integrated is a good first step. Besides, integration in IPA probably >> won't happen without RBAC support in Fedora/RHEL, right ? >> > >Right, and it is a bit beyond our scope to create a compatible RBAC >solution. > >rob -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rendhalver at gmail.com Thu Feb 14 23:36:44 2013 From: rendhalver at gmail.com (Peter Brown) Date: Fri, 15 Feb 2013 09:36:44 +1000 Subject: [Freeipa-users] Logging of Who does What on IPA Server In-Reply-To: <511CB05C.5020509@redhat.com> References: <511CA526.1010702@redhat.com> <511CB05C.5020509@redhat.com> Message-ID: On 14 February 2013 19:37, Petr Spacek wrote: > On 14.2.2013 09:49, Martin Kosek wrote: > >> On 02/14/2013 08:20 AM, Rajnesh Kumar Siwal wrote: >> >>> IPA is going to be very critical Server for any environment. >>> Do we have proper logging of who as locked whom, Who has created a >>> sudo policy, who has allowed access to whom etc ? >>> >>> >> Hello Rajnesh, >> >> the audit component of IPA collecting and processing audit information is >> not >> there yet. There is some information about our future direction in our >> wiki: >> http://freeipa.org/page/**Roadmap >> >> As for logging who did what, you can check existing logs on your IPA >> server(s) >> which may have information you need for audit: >> >> LDAP access log (LDAP calls): /var/log/dirsrv/slapd-$INST/**access >> > Also note 389 audit capabilities! If it can log to auditd I would just use that... Is that possible? > > > http error log (IPA framework calls): /var/log/httpd/error_log >> > > -- > Petr^2 Spacek > > > ______________________________**_________________ > 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 rmercer at harris.com Fri Feb 15 14:17:20 2013 From: rmercer at harris.com (Rodney L. Mercer) Date: Fri, 15 Feb 2013 09:17:20 -0500 Subject: [Freeipa-users] RHEL6 IPA and Active Directory synchronisation and Solaris RBAC In-Reply-To: References: <511BACEE.8050900@redhat.com> <511D2541.1000201@nixtra.com> <511D2CAC.6050400@redhat.com> <511D4693.8010502@redhat.com> Message-ID: <1360937840.21935.556.camel@osc145.evn.harris.com> On Thu, 2013-02-14 at 21:44 +0100, Sigbjorn Lie wrote: > I agree with schema support being enough for now. I do not expect the > ipa mgmt tools to support Solaris rbac mgmt. > > The ipa mgmt tools are great, but I already have other data in the ipa > ldap that I have to manage manually anyway. > > > > Rgds, > Siggi > > > > Rob Crittenden wrote: > Dag Wieers wrote: > On Thu, 14 Feb 2013, Rob Crittenden wrote: > > Sigbjorn Lie wrote: > On 02/13/2013 04:10 PM, Rob Crittenden wrote: > > Also since we also require compatibility with Solaris, and roles > (RBAC) > is currently used on Solaris, does IPA support RBAC on Solar > is ? > (We > noticed that RBAC mentioned in the IPA web interface only > relates to > > IPA > management). > No, IPA doesn't support RBAC on Solaris. > > I've come across the same issue. This is just a matter of extending the > schema. > > Would there be any interest for adding the Solaris RBAC schema as a > part > of the standard IPA distributed LDAP schemas? Consider the following: What else would have to be put in to support this? Once the schema is established, can SSSD be extended to use this and potentially be referenced in nsswitch.conf as it is implemented on Solaris? IE: tail -5 /etc/nsswitch.conf user_attr: sssd auth_attr: sssd prof_attr: sssd exec_attr: sssd project: sssd > > Is the schema enough? Won't > people > want a way from IPA to manage the > data too? > Of course, integration in IPA is better, but having the schema > integrated is a good first step. Besides, integration in IPA probably > won't happen without RBAC support in Fedora/RHEL, right ? > > > Right, and it is a bit beyond our scope to create a compatible RBAC > solution. > > rob > > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From orion at cora.nwra.com Fri Feb 15 16:36:41 2013 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 15 Feb 2013 09:36:41 -0700 Subject: [Freeipa-users] Non-human users Message-ID: <511E6419.4080402@cora.nwra.com> Is there a recommended way to distinguish between "real" human user accounts in IPA and non-human "system" accounts in IPA? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com From pviktori at redhat.com Fri Feb 15 16:45:30 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 15 Feb 2013 17:45:30 +0100 Subject: [Freeipa-users] Non-human users In-Reply-To: <511E6419.4080402@cora.nwra.com> References: <511E6419.4080402@cora.nwra.com> Message-ID: <511E662A.7010307@redhat.com> On 02/15/2013 05:36 PM, Orion Poplawski wrote: > Is there a recommended way to distinguish between "real" human user > accounts in IPA and non-human "system" accounts in IPA? > What kind of system accounts do you have in IPA? Consider not storing them in IPA at all. -- Petr? From lroot at redhat.com Fri Feb 15 17:25:38 2013 From: lroot at redhat.com (Lynn Root) Date: Fri, 15 Feb 2013 09:25:38 -0800 Subject: [Freeipa-users] IPA w/ Puppet? Message-ID: <511E6F92.3020000@redhat.com> Hi all - I'm curious if anyone has written Puppet manifests for managing an IPA domain. If so, I'd like to pester you to take a peek at those manifests. More curious on the overall automated management process than anything specific. I did find a post [1] on IPA managing the certs that Puppet uses - but perhaps someone else has gone a bit deeper! Thanks! Lynn Root [1] http://jcape.name/2012/01/16/using-the-freeipa-pki-with-puppet/ -- Lynn Root @roguelynn Associate Software Engineer Red Hat, Inc -------------- next part -------------- An HTML attachment was scrubbed... URL: From orion at cora.nwra.com Fri Feb 15 17:32:24 2013 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 15 Feb 2013 10:32:24 -0700 Subject: [Freeipa-users] Non-human users In-Reply-To: <511E662A.7010307@redhat.com> References: <511E6419.4080402@cora.nwra.com> <511E662A.7010307@redhat.com> Message-ID: <511E7128.1090804@cora.nwra.com> On 02/15/2013 09:45 AM, Petr Viktorin wrote: > On 02/15/2013 05:36 PM, Orion Poplawski wrote: >> Is there a recommended way to distinguish between "real" human user >> accounts in IPA and non-human "system" accounts in IPA? >> > > What kind of system accounts do you have in IPA? Consider not storing them in > IPA at all. > Yeah, that seems like the better idea, but: I think the main issue we've run into is needing the apache user to be a member of groups in ldap, and that not working unless the apache user was in ldap as well. Another example is a backup user account that backup software logs in as. Also some accounts that own files and some services run as that are needed on multiple machines. I suppose we could use puppet to manage those, but ldap seems more convenient. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com From jdennis at redhat.com Fri Feb 15 17:52:06 2013 From: jdennis at redhat.com (John Dennis) Date: Fri, 15 Feb 2013 12:52:06 -0500 Subject: [Freeipa-users] Non-human users In-Reply-To: <511E7128.1090804@cora.nwra.com> References: <511E6419.4080402@cora.nwra.com> <511E662A.7010307@redhat.com> <511E7128.1090804@cora.nwra.com> Message-ID: <511E75C6.9020708@redhat.com> On 02/15/2013 12:32 PM, Orion Poplawski wrote: > On 02/15/2013 09:45 AM, Petr Viktorin wrote: >> On 02/15/2013 05:36 PM, Orion Poplawski wrote: >>> Is there a recommended way to distinguish between "real" human user >>> accounts in IPA and non-human "system" accounts in IPA? >>> >> >> What kind of system accounts do you have in IPA? Consider not storing them in >> IPA at all. >> > > Yeah, that seems like the better idea, but: > > I think the main issue we've run into is needing the apache user to be a > member of groups in ldap, and that not working unless the apache user was in > ldap as well. > > Another example is a backup user account that backup software logs in as. > > Also some accounts that own files and some services run as that are needed on > multiple machines. I suppose we could use puppet to manage those, but ldap > seems more convenient. > Generally system users do not need accounts. Most daemons define a system user only for the purposes of having a uid they can drop privileges to after starting as root. These users typically do not have shells (technically their shell is /sbin/nologin) nor home directories. Also these system accounts typically have fixed well known uid's. Also these system users are automatically created when you install the package. Thus there is little point in trying to manage them. If you find yourself with a need to manage them step back and ask yourself why. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From bcook at redhat.com Fri Feb 15 18:03:52 2013 From: bcook at redhat.com (Brian Cook) Date: Fri, 15 Feb 2013 10:03:52 -0800 Subject: [Freeipa-users] Non-human users In-Reply-To: <511E75C6.9020708@redhat.com> References: <511E6419.4080402@cora.nwra.com> <511E662A.7010307@redhat.com> <511E7128.1090804@cora.nwra.com> <511E75C6.9020708@redhat.com> Message-ID: <42636B42-A8D7-44FE-A1B5-50EC0A8BEBB6@redhat.com> There are lots of use cases where it makes sense to have a share 'application' user: -agentless monitoring -penetration testing -code deployment -clustering The system user is not always the user an application is running as. Sometimes it is just a user that is used to gain access to a remote system. Brian --- Brian Cook Solutions Architect, Red Hat, Inc. 407-212-7079 On Feb 15, 2013, at 9:52 AM, John Dennis wrote: > On 02/15/2013 12:32 PM, Orion Poplawski wrote: >> On 02/15/2013 09:45 AM, Petr Viktorin wrote: >>> On 02/15/2013 05:36 PM, Orion Poplawski wrote: >>>> Is there a recommended way to distinguish between "real" human user >>>> accounts in IPA and non-human "system" accounts in IPA? >>>> >>> >>> What kind of system accounts do you have in IPA? Consider not storing them in >>> IPA at all. >>> >> >> Yeah, that seems like the better idea, but: >> >> I think the main issue we've run into is needing the apache user to be a >> member of groups in ldap, and that not working unless the apache user was in >> ldap as well. >> >> Another example is a backup user account that backup software logs in as. >> >> Also some accounts that own files and some services run as that are needed on >> multiple machines. I suppose we could use puppet to manage those, but ldap >> seems more convenient. >> > > Generally system users do not need accounts. Most daemons define a system user only for the purposes of having a uid they can drop privileges to after starting as root. These users typically do not have shells (technically their shell is /sbin/nologin) nor home directories. Also these system accounts typically have fixed well known uid's. Also these system users are automatically created when you install the package. Thus there is little point in trying to manage them. If you find yourself with a need to manage them step back and ask yourself why. > > -- > John Dennis > > 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 rcritten at redhat.com Fri Feb 15 18:20:22 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 15 Feb 2013 13:20:22 -0500 Subject: [Freeipa-users] Non-human users In-Reply-To: <511E75C6.9020708@redhat.com> References: <511E6419.4080402@cora.nwra.com> <511E662A.7010307@redhat.com> <511E7128.1090804@cora.nwra.com> <511E75C6.9020708@redhat.com> Message-ID: <511E7C66.907@redhat.com> John Dennis wrote: > On 02/15/2013 12:32 PM, Orion Poplawski wrote: >> On 02/15/2013 09:45 AM, Petr Viktorin wrote: >>> On 02/15/2013 05:36 PM, Orion Poplawski wrote: >>>> Is there a recommended way to distinguish between "real" human user >>>> accounts in IPA and non-human "system" accounts in IPA? >>>> >>> >>> What kind of system accounts do you have in IPA? Consider not storing >>> them in >>> IPA at all. >>> >> >> Yeah, that seems like the better idea, but: >> >> I think the main issue we've run into is needing the apache user to be a >> member of groups in ldap, and that not working unless the apache user >> was in >> ldap as well. >> >> Another example is a backup user account that backup software logs in as. >> >> Also some accounts that own files and some services run as that are >> needed on >> multiple machines. I suppose we could use puppet to manage those, but >> ldap >> seems more convenient. >> > > Generally system users do not need accounts. Most daemons define a > system user only for the purposes of having a uid they can drop > privileges to after starting as root. These users typically do not have > shells (technically their shell is /sbin/nologin) nor home directories. > Also these system accounts typically have fixed well known uid's. Also > these system users are automatically created when you install the > package. Thus there is little point in trying to manage them. If you > find yourself with a need to manage them step back and ask yourself why. > The mock user is sort of a system account but it would be definitely nice to be able to manage its group membership from IPA, for example. rob From chuck.lever at oracle.com Fri Feb 15 18:23:23 2013 From: chuck.lever at oracle.com (Chuck Lever) Date: Fri, 15 Feb 2013 13:23:23 -0500 Subject: [Freeipa-users] Use of LOCAL clock in ntpd configuration Message-ID: Hi- First-time FreeIPA user here. I've installed FreeIPA on Fedora 18 and have some Fedora 16 IPA clients. "ipa-server-install" on Fedora 18 and "ipa-client-install" on Fedora 16 both add the following stanza to /etc/ntp.conf: server 127.127.1.0 # local clock fudge 127.127.1.0 stratum 10 This sets up an additional time source based on the local system's hardware clock. According to http://www.ntp.org/ntpfaq/NTP-s-refclk.htm > The LCL is no reference clock in reality; instead it simply refers to the system time on the current machine. Therefore it should never be used, except when the system time is synchronized by some means not visible by xntpd. "synchronized by some means not visible by xntpd" means a GPS card or an atomic clock, hardware which most systems do not have available. In my experience, including a local time source on typical PC hardware is a recipe for inaccurate timekeeping. It can be especially problematic in a virtual environment. Including a local source might make sense for IPA servers, but only if the source is externally synchronized. At first I thought maybe the ntp configurator script had found some evidence of external synchronization on my server hardware, but then the same stanza appeared on my IPA clients, both of which are VMware Fusion guests. As soon as the local clock source was added on my IPA server, its ntp clock offset was skewed by a second and a half from the network servers it was tracking, and it became worse until I removed the local source. It seems to me that adding a local source automatically is a bad idea. Anyone know why the IPA installers add this source? (I also note that "ipa-client-install" does not disable chronyd, but I've only tried the client install script on Fedora 16). -- Chuck Lever chuck[dot]lever[at]oracle[dot]com From jdennis at redhat.com Fri Feb 15 18:34:52 2013 From: jdennis at redhat.com (John Dennis) Date: Fri, 15 Feb 2013 13:34:52 -0500 Subject: [Freeipa-users] Non-human users In-Reply-To: <511E7C66.907@redhat.com> References: <511E6419.4080402@cora.nwra.com> <511E662A.7010307@redhat.com> <511E7128.1090804@cora.nwra.com> <511E75C6.9020708@redhat.com> <511E7C66.907@redhat.com> Message-ID: <511E7FCC.3040605@redhat.com> The example cited was the apache user, a system daemon. For system users bound to system daemons I stand by what I said. If you want to talk about other system users not bound to a daemon than state that rather than confusing the issue. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Fri Feb 15 18:35:49 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 15 Feb 2013 13:35:49 -0500 Subject: [Freeipa-users] Non-human users In-Reply-To: <511E7FCC.3040605@redhat.com> References: <511E6419.4080402@cora.nwra.com> <511E662A.7010307@redhat.com> <511E7128.1090804@cora.nwra.com> <511E75C6.9020708@redhat.com> <511E7C66.907@redhat.com> <511E7FCC.3040605@redhat.com> Message-ID: <511E8005.5030107@redhat.com> John Dennis wrote: > The example cited was the apache user, a system daemon. For system users > bound to system daemons I stand by what I said. If you want to talk > about other system users not bound to a daemon than state that rather > than confusing the issue. > He cited a backup user. That isn't tied to a daemon. rob From jdennis at redhat.com Fri Feb 15 18:38:30 2013 From: jdennis at redhat.com (John Dennis) Date: Fri, 15 Feb 2013 13:38:30 -0500 Subject: [Freeipa-users] Non-human users In-Reply-To: <511E8005.5030107@redhat.com> References: <511E6419.4080402@cora.nwra.com> <511E662A.7010307@redhat.com> <511E7128.1090804@cora.nwra.com> <511E75C6.9020708@redhat.com> <511E7C66.907@redhat.com> <511E7FCC.3040605@redhat.com> <511E8005.5030107@redhat.com> Message-ID: <511E80A6.5000605@redhat.com> On 02/15/2013 01:35 PM, Rob Crittenden wrote: > John Dennis wrote: >> The example cited was the apache user, a system daemon. For system users >> bound to system daemons I stand by what I said. If you want to talk >> about other system users not bound to a daemon than state that rather >> than confusing the issue. >> > > He cited a backup user. That isn't tied to a daemon. The original message said this: > I think the main issue we've run into is needing the apache user ... -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From orion at cora.nwra.com Fri Feb 15 18:39:14 2013 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 15 Feb 2013 11:39:14 -0700 Subject: [Freeipa-users] Non-human users In-Reply-To: <511E80A6.5000605@redhat.com> References: <511E6419.4080402@cora.nwra.com> <511E662A.7010307@redhat.com> <511E7128.1090804@cora.nwra.com> <511E75C6.9020708@redhat.com> <511E7C66.907@redhat.com> <511E7FCC.3040605@redhat.com> <511E8005.5030107@redhat.com> <511E80A6.5000605@redhat.com> Message-ID: <511E80D2.2050801@cora.nwra.com> On 02/15/2013 11:38 AM, John Dennis wrote: > On 02/15/2013 01:35 PM, Rob Crittenden wrote: >> John Dennis wrote: >>> The example cited was the apache user, a system daemon. For system users >>> bound to system daemons I stand by what I said. If you want to talk >>> about other system users not bound to a daemon than state that rather >>> than confusing the issue. >>> >> >> He cited a backup user. That isn't tied to a daemon. > > The original message said this: > >> I think the main issue we've run into is needing the apache user ... > > > > And: Another example is a backup user account that backup software logs in as. Also some accounts that own files and some services run as that are needed on multiple machines. I suppose we could use puppet to manage those, but ldap seems more convenient. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com From rcritten at redhat.com Fri Feb 15 18:47:17 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 15 Feb 2013 13:47:17 -0500 Subject: [Freeipa-users] Use of LOCAL clock in ntpd configuration In-Reply-To: References: Message-ID: <511E82B5.8090502@redhat.com> Chuck Lever wrote: > Hi- > > First-time FreeIPA user here. > > I've installed FreeIPA on Fedora 18 and have some Fedora 16 IPA clients. "ipa-server-install" on Fedora 18 and "ipa-client-install" on Fedora 16 both add the following stanza to /etc/ntp.conf: > > server 127.127.1.0 # local clock > fudge 127.127.1.0 stratum 10 > > This sets up an additional time source based on the local system's hardware clock. > > According to http://www.ntp.org/ntpfaq/NTP-s-refclk.htm > >> The LCL is no reference clock in reality; instead it simply refers to the system time on the current machine. Therefore it should never be used, except when the system time is synchronized by some means not visible by xntpd. > > "synchronized by some means not visible by xntpd" means a GPS card or an atomic clock, hardware which most systems do not have available. In my experience, including a local time source on typical PC hardware is a recipe for inaccurate timekeeping. It can be especially problematic in a virtual environment. > > Including a local source might make sense for IPA servers, but only if the source is externally synchronized. At first I thought maybe the ntp configurator script had found some evidence of external synchronization on my server hardware, but then the same stanza appeared on my IPA clients, both of which are VMware Fusion guests. It was meant as a fallback. It may not make sense to have that anymore, on either the client or the server. It is probably worth revisiting, this was added in 2007-ish when the world was very different. > As soon as the local clock source was added on my IPA server, its ntp clock offset was skewed by a second and a half from the network servers it was tracking, and it became worse until I removed the local source. > > It seems to me that adding a local source automatically is a bad idea. Anyone know why the IPA installers add this source? Some VMs don't play very nice with ntp. Things seem to be better lately. Our documentation still recommends against configuring ntpd on VMs (though this can introduce other issues b/c we still attempt to sync the time against a non-existent time server during client enrollment). > (I also note that "ipa-client-install" does not disable chronyd, but I've only tried the client install script on Fedora 16). It will in the next release. rob From shelltoesuperstar at gmail.com Fri Feb 15 18:47:54 2013 From: shelltoesuperstar at gmail.com (Charlie Derwent) Date: Fri, 15 Feb 2013 18:47:54 +0000 Subject: [Freeipa-users] Unable to enrol servers with principal In-Reply-To: <511C1338.3010101@redhat.com> References: <5116FC75.1000105@redhat.com> <511C1338.3010101@redhat.com> Message-ID: Hi So there's nothing I can see in the access logs. However, I get the following message in the KDC log Feb 15 14:05:49 ipa.example.com krb5kdc[1749](info): AS_REQ (12 etypes {18 17 16 23 1 3 2 11 10 15 12 13}) 192.168.0.1: ISSUE: authtime 1360951549, etypes {rep=18 tkt=18 ses=18}, user at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM and when I get a "kinit(v5): Cannot read password while getting initial credentials" error I see this error Feb 15 14:39:35 ipa.example.com krb5kdc[1749](info): AS_REQ (12 etypes {18 17 16 23 1 3 2 11 10 15 12 13}) 192.168.0.1: NEEDED_PREAUTH: user at EXAMPLE.COM for kadmin/changepw at EXAMPLE.COM, Additional pre-authentication required Interestingly enough when I try a 5.6 server running ipa-client-2.0.14.el5_7.2 and xmlrpc-c-client-1.16.24-1206.1840.el5 it works but rolling ipa-client, certmonger, xmlrpc-c and xmlrpc-c-client back to their 5.6 versions on the 5.8 server makes no difference. I guess looking at times it has worked I should be getting a TGS_REQ message in logs immediately after the AS_REQ. Any ideas or anything else I can check? Thanks Charlie On Wed, Feb 13, 2013 at 10:27 PM, Dmitri Pal wrote: > On 02/13/2013 04:57 PM, Charlie Derwent wrote: > > > > On Sun, Feb 10, 2013 at 1:48 AM, Rob Crittenden wrote: > >> Charlie Derwent wrote: >> >>> Hi >>> Whenever I attempt an unattended installation with a principal and >>> password. The installation fails. >>> I'm using the following syntax for my command >>> ipa-client-install --domain=example.com >>> --server=ipa.example.com --realm=EXAMPLE.COM >>> --principal=user --password=pass -U >>> --ntp-server=123.123.123.123 --mkhomedir --hostname=server1.example.com >>> >>> >>> The error I get varies between (in order of frequency) >>> Joining realm failed: /usr/sbin/ipa-join: symbol lookup error: >>> /usr/sbin/ipa-join: undefined symbol: xmlrpc_server_info_set_user >>> and >>> >> >> This is the sort of thing that if you saw once, you should see every >> time. What version of xmlrpc-c-client is installed? >> >> >> > I agree I should be seeing it all the time it's very odd that I'm not, > the package is xmlrpc-c-client-1.16.24-1206.1840.4.el5.x86_64.rpm > >> >> kinit(v5): Password incorrect while getting initial credentials >>> and >>> Password expired. you must change it now. >>> kinit(v5): Cannot read password while getting initial credentials >>> The password is 100% right as I can kinit on other servers and access >>> the webgui with the same details. >>> OTP's work flawlessly. >>> >> >> The KDC log might have more information. >> > I'm not in the office right now so I can't check the logs but I assume the > KDC log is actually on the IPA server? > > > yes > and the DS access logs too > > > Thanks > Charlie > >> >> > > > > > _______________________________________________ > Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs?www.redhat.com/carveoutcosts/ > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Fri Feb 15 18:49:32 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 15 Feb 2013 13:49:32 -0500 Subject: [Freeipa-users] Non-human users In-Reply-To: <511E80D2.2050801@cora.nwra.com> References: <511E6419.4080402@cora.nwra.com> <511E662A.7010307@redhat.com> <511E7128.1090804@cora.nwra.com> <511E75C6.9020708@redhat.com> <511E7C66.907@redhat.com> <511E7FCC.3040605@redhat.com> <511E8005.5030107@redhat.com> <511E80A6.5000605@redhat.com> <511E80D2.2050801@cora.nwra.com> Message-ID: <511E833C.6080602@redhat.com> Orion Poplawski wrote: > On 02/15/2013 11:38 AM, John Dennis wrote: >> On 02/15/2013 01:35 PM, Rob Crittenden wrote: >>> John Dennis wrote: >>>> The example cited was the apache user, a system daemon. For system >>>> users >>>> bound to system daemons I stand by what I said. If you want to talk >>>> about other system users not bound to a daemon than state that rather >>>> than confusing the issue. >>>> >>> >>> He cited a backup user. That isn't tied to a daemon. >> >> The original message said this: >> >>> I think the main issue we've run into is needing the apache user ... >> >> >> >> > > And: > > > Another example is a backup user account that backup software logs in as. > > Also some accounts that own files and some services run as that are > needed on multiple machines. I suppose we could use puppet to manage > those, but ldap seems more convenient. In any case, it is probably reasonable to discuss these two cases separately. As John said, for pure system daemons it is probably best to leave those as local accounts. For quasi local accounts like mock or backup accounts things get a little fuzzy. I think I would avoid storing the user in /etc/passwd and the group in IPA, if possible. I imagine that sssd would be able to handle the case ok but I don't know that this is something they actively test. Why do you want/need to distinguish them from "real" people? rob From jdennis at redhat.com Fri Feb 15 18:50:59 2013 From: jdennis at redhat.com (John Dennis) Date: Fri, 15 Feb 2013 13:50:59 -0500 Subject: [Freeipa-users] Non-human users In-Reply-To: <511E80D2.2050801@cora.nwra.com> References: <511E6419.4080402@cora.nwra.com> <511E662A.7010307@redhat.com> <511E7128.1090804@cora.nwra.com> <511E75C6.9020708@redhat.com> <511E7C66.907@redhat.com> <511E7FCC.3040605@redhat.com> <511E8005.5030107@redhat.com> <511E80A6.5000605@redhat.com> <511E80D2.2050801@cora.nwra.com> Message-ID: <511E8393.8000700@redhat.com> On 02/15/2013 01:39 PM, Orion Poplawski wrote: > On 02/15/2013 11:38 AM, John Dennis wrote: >> On 02/15/2013 01:35 PM, Rob Crittenden wrote: >>> John Dennis wrote: >>>> The example cited was the apache user, a system daemon. For system users >>>> bound to system daemons I stand by what I said. If you want to talk >>>> about other system users not bound to a daemon than state that rather >>>> than confusing the issue. >>>> >>> >>> He cited a backup user. That isn't tied to a daemon. >> >> The original message said this: >> >>> I think the main issue we've run into is needing the apache user ... >> >> >> >> > > And: > > > Another example is a backup user account that backup software logs in as. > > Also some accounts that own files and some services run as that are needed on > multiple machines. I suppose we could use puppet to manage those, but ldap > seems more convenient. > > O.K. but I want to make sure you understand the difference. If you give login or other permissions to a network facing system daemon you're opening a huge security hole. Adding the apache user to the set of users managed by IPA is quite dangerous unless you are extraordinarily careful to remove privileges normally granted by IPA, it could lead to the complete compromise of your network. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From orion at cora.nwra.com Fri Feb 15 18:52:35 2013 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 15 Feb 2013 11:52:35 -0700 Subject: [Freeipa-users] Non-human users In-Reply-To: <511E8393.8000700@redhat.com> References: <511E6419.4080402@cora.nwra.com> <511E662A.7010307@redhat.com> <511E7128.1090804@cora.nwra.com> <511E75C6.9020708@redhat.com> <511E7C66.907@redhat.com> <511E7FCC.3040605@redhat.com> <511E8005.5030107@redhat.com> <511E80A6.5000605@redhat.com> <511E80D2.2050801@cora.nwra.com> <511E8393.8000700@redhat.com> Message-ID: <511E83F3.3090307@cora.nwra.com> On 02/15/2013 11:50 AM, John Dennis wrote: > > O.K. but I want to make sure you understand the difference. If you give login > or other permissions to a network facing system daemon you're opening a huge > security hole. Adding the apache user to the set of users managed by IPA is > quite dangerous unless you are extraordinarily careful to remove privileges > normally granted by IPA, it could lead to the complete compromise of your > network. > Understood. This is actually all before we have moved to IPA, but are exploring things. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com From rcritten at redhat.com Fri Feb 15 18:56:50 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 15 Feb 2013 13:56:50 -0500 Subject: [Freeipa-users] Unable to enrol servers with principal In-Reply-To: References: <5116FC75.1000105@redhat.com> <511C1338.3010101@redhat.com> Message-ID: <511E84F2.1090203@redhat.com> Charlie Derwent wrote: > Hi > So there's nothing I can see in the access logs. > However, I get the following message in the KDC log > Feb 15 14:05:49 ipa.example.com > krb5kdc[1749](info): AS_REQ (12 etypes {18 17 16 23 1 3 2 11 10 15 12 > 13}) 192.168.0.1 : ISSUE: authtime 1360951549, > etypes {rep=18 tkt=18 ses=18}, user at EXAMPLE.COM > for krbtgt/EXAMPLE.COM at EXAMPLE.COM > > and when I get a "kinit(v5): Cannot read password while getting initial > credentials" error I see this error > Feb 15 14:39:35 ipa.example.com > krb5kdc[1749](info): AS_REQ (12 etypes {18 17 16 23 1 3 2 11 10 15 12 > 13}) 192.168.0.1 : NEEDED_PREAUTH: user at EXAMPLE.COM > for kadmin/changepw at EXAMPLE.COM > , Additional pre-authentication required > Interestingly enough when I try a 5.6 server running > ipa-client-2.0.14.el5_7.2 and xmlrpc-c-client-1.16.24-1206.1840.el5 it > works but rolling ipa-client, certmonger, xmlrpc-c and xmlrpc-c-client > back to their 5.6 versions on the 5.8 server makes no difference. I > guess looking at times it has worked I should be getting a TGS_REQ > message in logs immediately after the AS_REQ. > Any ideas or anything else I can check? > Thanks > Charliez Are you seeing this failure only on this one 5.8 box or on others as well? The linker error is totally bizarre and I'm not sure why you'd get it infrequently. Does /var/log/ipaclient-install.log contain any additional information when things fail? rob From orion at cora.nwra.com Fri Feb 15 19:01:45 2013 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 15 Feb 2013 12:01:45 -0700 Subject: [Freeipa-users] Non-human users In-Reply-To: <511E833C.6080602@redhat.com> References: <511E6419.4080402@cora.nwra.com> <511E662A.7010307@redhat.com> <511E7128.1090804@cora.nwra.com> <511E75C6.9020708@redhat.com> <511E7C66.907@redhat.com> <511E7FCC.3040605@redhat.com> <511E8005.5030107@redhat.com> <511E80A6.5000605@redhat.com> <511E80D2.2050801@cora.nwra.com> <511E833C.6080602@redhat.com> Message-ID: <511E8619.2070808@cora.nwra.com> On 02/15/2013 11:49 AM, Rob Crittenden wrote: >> Another example is a backup user account that backup software logs in as. >> >> Also some accounts that own files and some services run as that are >> needed on multiple machines. I suppose we could use puppet to manage >> those, but ldap seems more convenient. > > In any case, it is probably reasonable to discuss these two cases separately. > > As John said, for pure system daemons it is probably best to leave those as > local accounts. > > For quasi local accounts like mock or backup accounts things get a little > fuzzy. I think I would avoid storing the user in /etc/passwd and the group in > IPA, if possible. I imagine that sssd would be able to handle the case ok but > I don't know that this is something they actively test. > > Why do you want/need to distinguish them from "real" people? > > rob What brought this up was the need to sync users from LDAP into another authentication system, and for that system we only wanted "real" human people to be listed. Also, we don't want these accounts listed in things like Thunderbird LDAP address books (hence no "*person" attributes: mail cn givenName sn). And just for doing periodic audits it would be helpful for distinguishing between them. I've been trying to track down any bugs I may have filed without success, but I'm pretty sure I tried at first adding a system user to LDAP groups and that not working unless the system user was in LDAP. This may have been before I started using SSSD on the servers so I'll need to retest this. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com From orion at cora.nwra.com Fri Feb 15 19:23:21 2013 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 15 Feb 2013 12:23:21 -0700 Subject: [Freeipa-users] Non-human users In-Reply-To: <511E8619.2070808@cora.nwra.com> References: <511E6419.4080402@cora.nwra.com> <511E662A.7010307@redhat.com> <511E7128.1090804@cora.nwra.com> <511E75C6.9020708@redhat.com> <511E7C66.907@redhat.com> <511E7FCC.3040605@redhat.com> <511E8005.5030107@redhat.com> <511E80A6.5000605@redhat.com> <511E80D2.2050801@cora.nwra.com> <511E833C.6080602@redhat.com> <511E8619.2070808@cora.nwra.com> Message-ID: <511E8B29.6090404@cora.nwra.com> On 02/15/2013 12:01 PM, Orion Poplawski wrote: > > I've been trying to track down any bugs I may have filed without success, but > I'm pretty sure I tried at first adding a system user to LDAP groups and that > not working unless the system user was in LDAP. This may have been before I > started using SSSD on the servers so I'll need to retest this. This still appears to be the case. As soon as I removed the system user from our current ldap database, id now longer reported any other group memberships. This is with the default using "memberUid" for group membership. With the IPA schema of recording group membership with the full dn, it seems the user would have to be in the database to have a dn. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com From sakodak at gmail.com Fri Feb 15 19:26:15 2013 From: sakodak at gmail.com (KodaK) Date: Fri, 15 Feb 2013 13:26:15 -0600 Subject: [Freeipa-users] IPA w/ Puppet? In-Reply-To: <511E6F92.3020000@redhat.com> References: <511E6F92.3020000@redhat.com> Message-ID: On Fri, Feb 15, 2013 at 11:25 AM, Lynn Root wrote: > Hi all - > > I'm curious if anyone has written Puppet manifests for managing an IPA > domain. If so, I'd like to pester you to take a peek at those manifests. > More curious on the overall automated management process than anything > specific. > > I did find a post [1] on IPA managing the certs that Puppet uses - but > perhaps someone else has gone a bit deeper! I use puppet to push various things related to IPA. For example, I have a lot of AIX hosts, so I use puppet to push ipa.crt, sshd_config, ssh_config, ldap.cfg, ntpd.conf, netsvc (AIX's nsswitch.conf,) and some other things that I'm not thinking of at the moment. I do some of this for Linux hosts too, just to keep things in sync (resolv.conf, the ssh configs, PAM configs, etc.) Pretty basic stuff, I either push the whole config file or add lines to it. Nothing fancy. Here's a listing of my custom modules directory, it should give some idea of what I'm doing: aix_dot_profile aix_etc_profile aix_hacmp_facts aix_inittab aix_ldap aix_ldap_startup aix_ldap_temp_fix aix_methods_cfg aix_ntp_conf aix_puppet_conf aix_puppet_startup aix_rc_local aix_sendmail aix_snmpdv3_conf apache cloud_provisioner dashboard dnsmasq etc_hosts firewall ipa_cert ipa_resolv_conf krb5_aix motd mysql netsvc nsswitch_sudoers ntp pam_mkhomedir_linux passenger perldbi_link resolv_conf ruby sane_env_aix sendmail ssh_config sshd sshd_config sshd_deny_oracle sudo_ldap vmwaretools From jdennis at redhat.com Fri Feb 15 20:42:19 2013 From: jdennis at redhat.com (John Dennis) Date: Fri, 15 Feb 2013 15:42:19 -0500 Subject: [Freeipa-users] Non-human users In-Reply-To: <511E8B29.6090404@cora.nwra.com> References: <511E6419.4080402@cora.nwra.com> <511E662A.7010307@redhat.com> <511E7128.1090804@cora.nwra.com> <511E75C6.9020708@redhat.com> <511E7C66.907@redhat.com> <511E7FCC.3040605@redhat.com> <511E8005.5030107@redhat.com> <511E80A6.5000605@redhat.com> <511E80D2.2050801@cora.nwra.com> <511E833C.6080602@redhat.com> <511E8619.2070808@cora.nwra.com> <511E8B29.6090404@cora.nwra.com> Message-ID: <511E9DAB.3010201@redhat.com> On 02/15/2013 02:23 PM, Orion Poplawski wrote: > On 02/15/2013 12:01 PM, Orion Poplawski wrote: >> >> I've been trying to track down any bugs I may have filed without success, but >> I'm pretty sure I tried at first adding a system user to LDAP groups and that >> not working unless the system user was in LDAP. This may have been before I >> started using SSSD on the servers so I'll need to retest this. > > This still appears to be the case. As soon as I removed the system user from > our current ldap database, id now longer reported any other group memberships. > This is with the default using "memberUid" for group membership. With the > IPA schema of recording group membership with the full dn, it seems the user > would have to be in the database to have a dn. Yes you're right, the user has to exist in LDAP in order to be a member of a group managed in LDAP. If your goal is not to have system users returned in a ldap search you'll have to filter them (e.g. adding (uid >= 1024) to the search filter because system users are usually less than some magic number, it used to be 512, now it's 1024 I believe). Adding that (or some other filter criteria) to every LDAP client in your enterprise is probably not viable. I don't think setting ACL's to prevent specific users from being returned in searches is viable either because they need to visible during the operations they're involved in. The problem as I see it is that IPA by design stores users in a "flat" namespace. That means you cannot partition users by putting them in different LDAP containers (trees). During the design of IPA the issue of whether we would use a flat namespace or permit different namespaces (via LDAP containers, conventionally called organizational units, i.e. OU's) came up. There was a sentiment that OU's had historically been problematic, hence we have a flat namespace and partitioning would be done via filtering. Thus only thing I can suggest at the moment is filtering, perhaps others have a better idea. Your other alternative is not put these system users in LDAP and instead use local users & groups managed via some other mechanism (puppet?). I'm not sure this issue has come up before, it does present some interesting issues. John -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From simo at redhat.com Fri Feb 15 20:46:12 2013 From: simo at redhat.com (Simo Sorce) Date: Fri, 15 Feb 2013 15:46:12 -0500 Subject: [Freeipa-users] Non-human users In-Reply-To: <511E8619.2070808@cora.nwra.com> References: <511E6419.4080402@cora.nwra.com> <511E662A.7010307@redhat.com> <511E7128.1090804@cora.nwra.com> <511E75C6.9020708@redhat.com> <511E7C66.907@redhat.com> <511E7FCC.3040605@redhat.com> <511E8005.5030107@redhat.com> <511E80A6.5000605@redhat.com> <511E80D2.2050801@cora.nwra.com> <511E833C.6080602@redhat.com> <511E8619.2070808@cora.nwra.com> Message-ID: <1360961172.12328.294.camel@willson.li.ssimo.org> On Fri, 2013-02-15 at 12:01 -0700, Orion Poplawski wrote: > On 02/15/2013 11:49 AM, Rob Crittenden wrote: > >> Another example is a backup user account that backup software logs in as. > >> > >> Also some accounts that own files and some services run as that are > >> needed on multiple machines. I suppose we could use puppet to manage > >> those, but ldap seems more convenient. > > > > In any case, it is probably reasonable to discuss these two cases separately. > > > > As John said, for pure system daemons it is probably best to leave those as > > local accounts. > > > > For quasi local accounts like mock or backup accounts things get a little > > fuzzy. I think I would avoid storing the user in /etc/passwd and the group in > > IPA, if possible. I imagine that sssd would be able to handle the case ok but > > I don't know that this is something they actively test. > > > > Why do you want/need to distinguish them from "real" people? > > > > rob > > What brought this up was the need to sync users from LDAP into another > authentication system, and for that system we only wanted "real" human people > to be listed. > > Also, we don't want these accounts listed in things like Thunderbird LDAP > address books (hence no "*person" attributes: mail cn givenName sn). > > And just for doing periodic audits it would be helpful for distinguishing > between them. > > I've been trying to track down any bugs I may have filed without success, but > I'm pretty sure I tried at first adding a system user to LDAP groups and that > not working unless the system user was in LDAP. This may have been before I > started using SSSD on the servers so I'll need to retest this. This is an interesting use case, it would probably be appropriate to have a RFE filed to allow to create ipa users marked as 'non-person' so that they are not assigned the person objectclass. Simo. -- Simo Sorce * Red Hat, Inc * New York From jdennis at redhat.com Fri Feb 15 20:56:33 2013 From: jdennis at redhat.com (John Dennis) Date: Fri, 15 Feb 2013 15:56:33 -0500 Subject: [Freeipa-users] Non-human users In-Reply-To: <1360961172.12328.294.camel@willson.li.ssimo.org> References: <511E6419.4080402@cora.nwra.com> <511E662A.7010307@redhat.com> <511E7128.1090804@cora.nwra.com> <511E75C6.9020708@redhat.com> <511E7C66.907@redhat.com> <511E7FCC.3040605@redhat.com> <511E8005.5030107@redhat.com> <511E80A6.5000605@redhat.com> <511E80D2.2050801@cora.nwra.com> <511E833C.6080602@redhat.com> <511E8619.2070808@cora.nwra.com> <1360961172.12328.294.camel@willson.li.ssimo.org> Message-ID: <511EA101.2060505@redhat.com> On 02/15/2013 03:46 PM, Simo Sorce wrote: > This is an interesting use case, it would probably be appropriate to > have a RFE filed to allow to create ipa users marked as 'non-person' so > that they are not assigned the person objectclass. Yes, that addresses one large component of the problem. But the part of the requirement is not to have non-humans show up in every client (e.g. mail clients) that support LDAP directory lookups. That means they have to modify the filter on every client. That's a tall order :-( -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From orion at cora.nwra.com Fri Feb 15 20:57:39 2013 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 15 Feb 2013 13:57:39 -0700 Subject: [Freeipa-users] Non-human users In-Reply-To: <511EA101.2060505@redhat.com> References: <511E6419.4080402@cora.nwra.com> <511E662A.7010307@redhat.com> <511E7128.1090804@cora.nwra.com> <511E75C6.9020708@redhat.com> <511E7C66.907@redhat.com> <511E7FCC.3040605@redhat.com> <511E8005.5030107@redhat.com> <511E80A6.5000605@redhat.com> <511E80D2.2050801@cora.nwra.com> <511E833C.6080602@redhat.com> <511E8619.2070808@cora.nwra.com> <1360961172.12328.294.camel@willson.li.ssimo.org> <511EA101.2060505@redhat.com> Message-ID: <511EA143.1000804@cora.nwra.com> On 02/15/2013 01:56 PM, John Dennis wrote: > On 02/15/2013 03:46 PM, Simo Sorce wrote: >> This is an interesting use case, it would probably be appropriate to >> have a RFE filed to allow to create ipa users marked as 'non-person' so >> that they are not assigned the person objectclass. > > Yes, that addresses one large component of the problem. But the part of the > requirement is not to have non-humans show up in every client (e.g. mail > clients) that support LDAP directory lookups. That means they have to modify > the filter on every client. That's a tall order :-( > Actually, this would cover it. The LDAP address book searches look for attributes that the *person objectclasses provide. Without them, they are excluded. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com From orion at cora.nwra.com Fri Feb 15 21:01:05 2013 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 15 Feb 2013 14:01:05 -0700 Subject: [Freeipa-users] Non-human users In-Reply-To: <511E9DAB.3010201@redhat.com> References: <511E6419.4080402@cora.nwra.com> <511E662A.7010307@redhat.com> <511E7128.1090804@cora.nwra.com> <511E75C6.9020708@redhat.com> <511E7C66.907@redhat.com> <511E7FCC.3040605@redhat.com> <511E8005.5030107@redhat.com> <511E80A6.5000605@redhat.com> <511E80D2.2050801@cora.nwra.com> <511E833C.6080602@redhat.com> <511E8619.2070808@cora.nwra.com> <511E8B29.6090404@cora.nwra.com> <511E9DAB.3010201@redhat.com> Message-ID: <511EA211.1040405@cora.nwra.com> On 02/15/2013 01:42 PM, John Dennis wrote: > On 02/15/2013 02:23 PM, Orion Poplawski wrote: >> On 02/15/2013 12:01 PM, Orion Poplawski wrote: >>> >>> I've been trying to track down any bugs I may have filed without success, but >>> I'm pretty sure I tried at first adding a system user to LDAP groups and that >>> not working unless the system user was in LDAP. This may have been before I >>> started using SSSD on the servers so I'll need to retest this. >> >> This still appears to be the case. As soon as I removed the system user from >> our current ldap database, id now longer reported any other group memberships. >> This is with the default using "memberUid" for group membership. With the >> IPA schema of recording group membership with the full dn, it seems the user >> would have to be in the database to have a dn. > > Yes you're right, the user has to exist in LDAP in order to be a member of a > group managed in LDAP. > > Your other alternative is not put these system users in LDAP and instead use > local users & groups managed via some other mechanism (puppet?). > I've been testing with puppet, but that doesn't work. It detects the groups presence in ldap, so doesn't add them to /etc/group, then when it goes to add apache to the various groups, that fails. Possibly could missing functionality in puppet, but not a solution at the moment. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com From jdennis at redhat.com Fri Feb 15 21:02:23 2013 From: jdennis at redhat.com (John Dennis) Date: Fri, 15 Feb 2013 16:02:23 -0500 Subject: [Freeipa-users] Non-human users In-Reply-To: <511EA143.1000804@cora.nwra.com> References: <511E6419.4080402@cora.nwra.com> <511E662A.7010307@redhat.com> <511E7128.1090804@cora.nwra.com> <511E75C6.9020708@redhat.com> <511E7C66.907@redhat.com> <511E7FCC.3040605@redhat.com> <511E8005.5030107@redhat.com> <511E80A6.5000605@redhat.com> <511E80D2.2050801@cora.nwra.com> <511E833C.6080602@redhat.com> <511E8619.2070808@cora.nwra.com> <1360961172.12328.294.camel@willson.li.ssimo.org> <511EA101.2060505@redhat.com> <511EA143.1000804@cora.nwra.com> Message-ID: <511EA25F.2010606@redhat.com> On 02/15/2013 03:57 PM, Orion Poplawski wrote: > On 02/15/2013 01:56 PM, John Dennis wrote: >> On 02/15/2013 03:46 PM, Simo Sorce wrote: >>> This is an interesting use case, it would probably be appropriate to >>> have a RFE filed to allow to create ipa users marked as 'non-person' so >>> that they are not assigned the person objectclass. >> >> Yes, that addresses one large component of the problem. But the part of the >> requirement is not to have non-humans show up in every client (e.g. mail >> clients) that support LDAP directory lookups. That means they have to modify >> the filter on every client. That's a tall order :-( >> > > Actually, this would cover it. The LDAP address book searches look for > attributes that the *person objectclasses provide. Without them, they are > excluded. Interesting, before I replied I checked the filter in my Thunderbird client and it's set to (objectclass=*). I don't know if I modified it as some point or if it's the default, I assumed it's the default. I suspect it's the default filter for many clients. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Fri Feb 15 21:08:37 2013 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 15 Feb 2013 16:08:37 -0500 Subject: [Freeipa-users] Logging of Who does What on IPA Server In-Reply-To: <1360849877.12328.168.camel@willson.li.ssimo.org> References: <1360849877.12328.168.camel@willson.li.ssimo.org> Message-ID: <511EA3D5.3000705@redhat.com> On 02/14/2013 08:51 AM, Simo Sorce wrote: > On Thu, 2013-02-14 at 12:50 +0530, Rajnesh Kumar Siwal wrote: >> IPA is going to be very critical Server for any environment. >> Do we have proper logging of who as locked whom, Who has created a >> sudo policy, who has allowed access to whom etc ? > You can see this information by querying LDAP directly. > > The 'creatorsName' attribute holds the identity of the user that created > the object. > > The 'createTimestamp' attribute holds the time at which the object was > created. > > The 'modifiersName' attribute holds the identity of the user that last > modified the object. > > The 'modifyTimestamp' attribute holds the time at which the object was > modified. > > All these attributes are operational, so you normally do not see them > unless you explicitly ask for them during an ldap search. Some LDAP > browsers allow you to add a list of attributes to ask for explicitly. > > > > To see these attributes for a user named foo for example you can run > this query: "ldapsearch -Y GSSAPI uid=foo creatorsName createTimestamp > modifiersName modifyTimestamp" > > add a '*' at the end if you also want to fetch regular attributes. > This command assumes you have kerberos credentials (-Y GSSAPI tells > ldapsearch to use them to auth to the server). > > Simo. > I also recommend to look at Logstash as a solution to collecting and correlating logs. http://logstash.net/docs/1.1.9/ -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From bcook at redhat.com Fri Feb 15 21:09:26 2013 From: bcook at redhat.com (Brian Cook) Date: Fri, 15 Feb 2013 13:09:26 -0800 Subject: [Freeipa-users] Non-human users In-Reply-To: <511EA25F.2010606@redhat.com> References: <511E6419.4080402@cora.nwra.com> <511E662A.7010307@redhat.com> <511E7128.1090804@cora.nwra.com> <511E75C6.9020708@redhat.com> <511E7C66.907@redhat.com> <511E7FCC.3040605@redhat.com> <511E8005.5030107@redhat.com> <511E80A6.5000605@redhat.com> <511E80D2.2050801@cora.nwra.com> <511E833C.6080602@redhat.com> <511E8619.2070808@cora.nwra.com> <1360961172.12328.294.camel@willson.li.ssimo.org> <511EA101.2060505@redhat.com> <511EA143.1000804@cora.nwra.com> <511EA25F.2010606@redhat.com> Message-ID: On Feb 15, 2013, at 1:02 PM, John Dennis wrote: > On 02/15/2013 03:57 PM, Orion Poplawski wrote: >> On 02/15/2013 01:56 PM, John Dennis wrote: >>> On 02/15/2013 03:46 PM, Simo Sorce wrote: >>>> This is an interesting use case, it would probably be appropriate to >>>> have a RFE filed to allow to create ipa users marked as 'non-person' so >>>> that they are not assigned the person objectclass. >>> >>> Yes, that addresses one large component of the problem. But the part of the >>> requirement is not to have non-humans show up in every client (e.g. mail >>> clients) that support LDAP directory lookups. That means they have to modify >>> the filter on every client. That's a tall order :-( >>> >> >> Actually, this would cover it. The LDAP address book searches look for >> attributes that the *person objectclasses provide. Without them, they are >> excluded. > > Interesting, before I replied I checked the filter in my Thunderbird client and it's set to (objectclass=*). I don't know if I modified it as some point or if it's the default, I assumed it's the default. I suspect it's the default filter for many clients. > I think maybe he means that he is putting a custom search string in the address books that filters out objects that don't have attributes that *person object classes provide, but that doesn't work unless you can keep those attributes from being assigned to non-person accounts in freeipa. -Brian > > -- > John Dennis > > 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 orion at cora.nwra.com Fri Feb 15 21:16:03 2013 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 15 Feb 2013 14:16:03 -0700 Subject: [Freeipa-users] Non-human users In-Reply-To: <511EA25F.2010606@redhat.com> References: <511E6419.4080402@cora.nwra.com> <511E662A.7010307@redhat.com> <511E7128.1090804@cora.nwra.com> <511E75C6.9020708@redhat.com> <511E7C66.907@redhat.com> <511E7FCC.3040605@redhat.com> <511E8005.5030107@redhat.com> <511E80A6.5000605@redhat.com> <511E80D2.2050801@cora.nwra.com> <511E833C.6080602@redhat.com> <511E8619.2070808@cora.nwra.com> <1360961172.12328.294.camel@willson.li.ssimo.org> <511EA101.2060505@redhat.com> <511EA143.1000804@cora.nwra.com> <511EA25F.2010606@redhat.com> Message-ID: <511EA593.1010801@cora.nwra.com> On 02/15/2013 02:02 PM, John Dennis wrote: > On 02/15/2013 03:57 PM, Orion Poplawski wrote: >> On 02/15/2013 01:56 PM, John Dennis wrote: >>> On 02/15/2013 03:46 PM, Simo Sorce wrote: >>>> This is an interesting use case, it would probably be appropriate to >>>> have a RFE filed to allow to create ipa users marked as 'non-person' so >>>> that they are not assigned the person objectclass. >>> >>> Yes, that addresses one large component of the problem. But the part of the >>> requirement is not to have non-humans show up in every client (e.g. mail >>> clients) that support LDAP directory lookups. That means they have to modify >>> the filter on every client. That's a tall order :-( >>> >> >> Actually, this would cover it. The LDAP address book searches look for >> attributes that the *person objectclasses provide. Without them, they are >> excluded. > > Interesting, before I replied I checked the filter in my Thunderbird client > and it's set to (objectclass=*). I don't know if I modified it as some point > or if it's the default, I assumed it's the default. I suspect it's the default > filter for many clients. > > Hmm, that is the filter in TB for me too, but: [15/Feb/2013:11:17:21 -0700] conn=931 op=1 SRCH base="ou=people,dc=nwra,dc=com" scope=2 filter="(|(mail=*apache*)(cn=*apache*)(givenName=*apache*)(sn=*apache*))" attrs="description notes title sn sn mozillaHomeLocalityName givenName mozillaHomeState mail mozillaWorkUrl workurl labeledURI o company mozillaNickname mozillaNickname mobile cellphone carphone modifyTimestamp nsAIMid nsAIMid telephoneNumber birthyear c c mozillaHomeStreet cn cn postalCode zip mozillaCustom1 custom1 mozillaHomeCountryName homePhone st region mozillaCustom2 custom2 mozillaSecondEmail mozillaSecondEmail facsimileTelephoneNumber facsimileTelephoneNumber mozillaCustom3 custom3 mozillaUseHtmlMail mozillaUseHtmlMail mozillaHomeStreet2 birthday street street postOfficeBox mozillaCustom4 custom4 mozillaHomeUrl homeurl l l pager pagerphone ou department departmentNumber orgunit birthmonth mozillaWorkStreet2 mozillaHomePostalCode objectClass" is what I see in the LDAP server log -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com From dpal at redhat.com Fri Feb 15 21:23:55 2013 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 15 Feb 2013 16:23:55 -0500 Subject: [Freeipa-users] Non-human users In-Reply-To: <1360961172.12328.294.camel@willson.li.ssimo.org> References: <511E6419.4080402@cora.nwra.com> <511E662A.7010307@redhat.com> <511E7128.1090804@cora.nwra.com> <511E75C6.9020708@redhat.com> <511E7C66.907@redhat.com> <511E7FCC.3040605@redhat.com> <511E8005.5030107@redhat.com> <511E80A6.5000605@redhat.com> <511E80D2.2050801@cora.nwra.com> <511E833C.6080602@redhat.com> <511E8619.2070808@cora.nwra.com> <1360961172.12328.294.camel@willson.li.ssimo.org> Message-ID: <511EA76B.5070106@redhat.com> On 02/15/2013 03:46 PM, Simo Sorce wrote: > On Fri, 2013-02-15 at 12:01 -0700, Orion Poplawski wrote: >> On 02/15/2013 11:49 AM, Rob Crittenden wrote: >>>> Another example is a backup user account that backup software logs in as. >>>> >>>> Also some accounts that own files and some services run as that are >>>> needed on multiple machines. I suppose we could use puppet to manage >>>> those, but ldap seems more convenient. >>> In any case, it is probably reasonable to discuss these two cases separately. >>> >>> As John said, for pure system daemons it is probably best to leave those as >>> local accounts. >>> >>> For quasi local accounts like mock or backup accounts things get a little >>> fuzzy. I think I would avoid storing the user in /etc/passwd and the group in >>> IPA, if possible. I imagine that sssd would be able to handle the case ok but >>> I don't know that this is something they actively test. >>> >>> Why do you want/need to distinguish them from "real" people? >>> >>> rob >> What brought this up was the need to sync users from LDAP into another >> authentication system, and for that system we only wanted "real" human people >> to be listed. >> >> Also, we don't want these accounts listed in things like Thunderbird LDAP >> address books (hence no "*person" attributes: mail cn givenName sn). >> >> And just for doing periodic audits it would be helpful for distinguishing >> between them. >> >> I've been trying to track down any bugs I may have filed without success, but >> I'm pretty sure I tried at first adding a system user to LDAP groups and that >> not working unless the system user was in LDAP. This may have been before I >> started using SSSD on the servers so I'll need to retest this. > This is an interesting use case, it would probably be appropriate to > have a RFE filed to allow to create ipa users marked as 'non-person' so > that they are not assigned the person objectclass. > > Simo. > https://fedorahosted.org/freeipa/ticket/3430 -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From lyamanishi at sesda3.com Fri Feb 15 21:26:11 2013 From: lyamanishi at sesda3.com (Lucas Yamanishi) Date: Fri, 15 Feb 2013 16:26:11 -0500 Subject: [Freeipa-users] Non-human users In-Reply-To: <511EA211.1040405@cora.nwra.com> References: <511E6419.4080402@cora.nwra.com> <511E662A.7010307@redhat.com> <511E7128.1090804@cora.nwra.com> <511E75C6.9020708@redhat.com> <511E7C66.907@redhat.com> <511E7FCC.3040605@redhat.com> <511E8005.5030107@redhat.com> <511E80A6.5000605@redhat.com> <511E80D2.2050801@cora.nwra.com> <511E833C.6080602@redhat.com> <511E8619.2070808@cora.nwra.com> <511E8B29.6090404@cora.nwra.com> <511E9DAB.3010201@redhat.com> <511EA211.1040405@cora.nwra.com> Message-ID: <511EA7F3.1050607@sesda3.com> On 02/15/2013 04:01 PM, Orion Poplawski wrote: > On 02/15/2013 01:42 PM, John Dennis wrote: >> On 02/15/2013 02:23 PM, Orion Poplawski wrote: >>> On 02/15/2013 12:01 PM, Orion Poplawski wrote: >>>> >>>> I've been trying to track down any bugs I may have filed without >>>> success, but >>>> I'm pretty sure I tried at first adding a system user to LDAP groups >>>> and that >>>> not working unless the system user was in LDAP. This may have been >>>> before I >>>> started using SSSD on the servers so I'll need to retest this. >>> >>> This still appears to be the case. As soon as I removed the system >>> user from >>> our current ldap database, id now longer reported any other group >>> memberships. >>> This is with the default using "memberUid" for group membership. >>> With the >>> IPA schema of recording group membership with the full dn, it seems >>> the user >>> would have to be in the database to have a dn. >> >> Yes you're right, the user has to exist in LDAP in order to be a >> member of a >> group managed in LDAP. >> >> Your other alternative is not put these system users in LDAP and >> instead use >> local users & groups managed via some other mechanism (puppet?). >> > > I've been testing with puppet, but that doesn't work. It detects the > groups presence in ldap, so doesn't add them to /etc/group, then when it > goes to add apache to the various groups, that fails. Possibly could > missing functionality in puppet, but not a solution at the moment. > sssd.conf has some filter directives that will prevent sssd from looking up the specified users/groups. That should prevent puppet from detecting the LDAP group. -- ----- *question everything*learn something*answer nothing* ------------ Lucas Yamanishi ------------------ Systems Administrator, ADNET Systems, Inc. 7515 Mission Drive, Suite A100 Lanham, MD 20706 * 301-352-4646 * 0xE23F3D7A From orion at cora.nwra.com Fri Feb 15 21:30:06 2013 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 15 Feb 2013 14:30:06 -0700 Subject: [Freeipa-users] Non-human users In-Reply-To: <1360961172.12328.294.camel@willson.li.ssimo.org> References: <511E6419.4080402@cora.nwra.com> <511E662A.7010307@redhat.com> <511E7128.1090804@cora.nwra.com> <511E75C6.9020708@redhat.com> <511E7C66.907@redhat.com> <511E7FCC.3040605@redhat.com> <511E8005.5030107@redhat.com> <511E80A6.5000605@redhat.com> <511E80D2.2050801@cora.nwra.com> <511E833C.6080602@redhat.com> <511E8619.2070808@cora.nwra.com> <1360961172.12328.294.camel@willson.li.ssimo.org> Message-ID: <511EA8DE.7080206@cora.nwra.com> On 02/15/2013 01:46 PM, Simo Sorce wrote: > On Fri, 2013-02-15 at 12:01 -0700, Orion Poplawski wrote: >> What brought this up was the need to sync users from LDAP into another >> authentication system, and for that system we only wanted "real" human people >> to be listed. >> >> Also, we don't want these accounts listed in things like Thunderbird LDAP >> address books (hence no "*person" attributes: mail cn givenName sn). >> >> And just for doing periodic audits it would be helpful for distinguishing >> between them. >> >> I've been trying to track down any bugs I may have filed without success, but >> I'm pretty sure I tried at first adding a system user to LDAP groups and that >> not working unless the system user was in LDAP. This may have been before I >> started using SSSD on the servers so I'll need to retest this. > > This is an interesting use case, it would probably be appropriate to > have a RFE filed to allow to create ipa users marked as 'non-person' so > that they are not assigned the person objectclass. > > Simo. > Filed https://fedorahosted.org/freeipa/ticket/3431 -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com From dpal at redhat.com Fri Feb 15 21:31:40 2013 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 15 Feb 2013 16:31:40 -0500 Subject: [Freeipa-users] RHEL6 IPA and Active Directory synchronisation and Solaris RBAC In-Reply-To: <1360937840.21935.556.camel@osc145.evn.harris.com> References: <511BACEE.8050900@redhat.com> <511D2541.1000201@nixtra.com> <511D2CAC.6050400@redhat.com> <511D4693.8010502@redhat.com> <1360937840.21935.556.camel@osc145.evn.harris.com> Message-ID: <511EA93C.8060909@redhat.com> On 02/15/2013 09:17 AM, Rodney L. Mercer wrote: > > On Thu, 2013-02-14 at 21:44 +0100, Sigbjorn Lie wrote: >> I agree with schema support being enough for now. I do not expect the >> ipa mgmt tools to support Solaris rbac mgmt. >> >> The ipa mgmt tools are great, but I already have other data in the ipa >> ldap that I have to manage manually anyway. >> >> >> >> Rgds, >> Siggi >> >> >> >> Rob Crittenden wrote: >> Dag Wieers wrote: >> On Thu, 14 Feb 2013, Rob Crittenden wrote: >> >> Sigbjorn Lie wrote: >> On 02/13/2013 04:10 PM, Rob Crittenden wrote: >> >> Also since we also require compatibility with Solaris, and roles >> (RBAC) >> is currently used on Solaris, does IPA support RBAC on Solar >> is ? >> (We >> noticed that RBAC mentioned in the IPA web interface only >> relates to > > IPA >> management). >> No, IPA doesn't support RBAC on Solaris. >> >> I've come across the same issue. This is just a matter of extending the >> schema. >> >> Would there be any interest for adding the Solaris RBAC schema as a >> part >> of the standard IPA distributed LDAP schemas? > > Consider the following: What else would have to be put in to support > this? > Once the schema is established, can SSSD be extended to use this and > potentially be referenced in nsswitch.conf as it is implemented on > Solaris? IE: > tail -5 /etc/nsswitch.conf > user_attr: sssd > auth_attr: sssd > prof_attr: sssd > exec_attr: sssd > project: sssd Before we define how it is passed/exposed it would nice to understand who on Linux will be consuming it out of SSSD? > > > >> >> Is the schema enough? Won't >> people >> want a way from IPA to manage the >> data too? >> Of course, integration in IPA is better, but having the schema >> integrated is a good first step. Besides, integration in IPA probably >> won't happen without RBAC support in Fedora/RHEL, right ? >> >> >> Right, and it is a bit beyond our scope to create a compatible RBAC >> solution. >> >> rob >> >> -- >> Sent from my Android phone with K-9 Mail. Please excuse my brevity. >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From jdennis at redhat.com Fri Feb 15 21:34:31 2013 From: jdennis at redhat.com (John Dennis) Date: Fri, 15 Feb 2013 16:34:31 -0500 Subject: [Freeipa-users] Non-human users In-Reply-To: <511EA593.1010801@cora.nwra.com> References: <511E6419.4080402@cora.nwra.com> <511E662A.7010307@redhat.com> <511E7128.1090804@cora.nwra.com> <511E75C6.9020708@redhat.com> <511E7C66.907@redhat.com> <511E7FCC.3040605@redhat.com> <511E8005.5030107@redhat.com> <511E80A6.5000605@redhat.com> <511E80D2.2050801@cora.nwra.com> <511E833C.6080602@redhat.com> <511E8619.2070808@cora.nwra.com> <1360961172.12328.294.camel@willson.li.ssimo.org> <511EA101.2060505@redhat.com> <511EA143.1000804@cora.nwra.com> <511EA25F.2010606@redhat.com> <511EA593.1010801@cora.nwra.com> Message-ID: <511EA9E7.5070606@redhat.com> On 02/15/2013 04:16 PM, Orion Poplawski wrote: > On 02/15/2013 02:02 PM, John Dennis wrote: >> On 02/15/2013 03:57 PM, Orion Poplawski wrote: >>> On 02/15/2013 01:56 PM, John Dennis wrote: >>>> On 02/15/2013 03:46 PM, Simo Sorce wrote: >>>>> This is an interesting use case, it would probably be appropriate to >>>>> have a RFE filed to allow to create ipa users marked as 'non-person' so >>>>> that they are not assigned the person objectclass. >>>> >>>> Yes, that addresses one large component of the problem. But the part of the >>>> requirement is not to have non-humans show up in every client (e.g. mail >>>> clients) that support LDAP directory lookups. That means they have to modify >>>> the filter on every client. That's a tall order :-( >>>> >>> >>> Actually, this would cover it. The LDAP address book searches look for >>> attributes that the *person objectclasses provide. Without them, they are >>> excluded. >> >> Interesting, before I replied I checked the filter in my Thunderbird client >> and it's set to (objectclass=*). I don't know if I modified it as some point >> or if it's the default, I assumed it's the default. I suspect it's the default >> filter for many clients. >> >> > > Hmm, that is the filter in TB for me too, but: > > [15/Feb/2013:11:17:21 -0700] conn=931 op=1 SRCH > base="ou=people,dc=nwra,dc=com" scope=2 > filter="(|(mail=*apache*)(cn=*apache*)(givenName=*apache*)(sn=*apache*))" > attrs="description notes title sn sn mozillaHomeLocalityName givenName > mozillaHomeState mail mozillaWorkUrl workurl labeledURI o company > mozillaNickname mozillaNickname mobile cellphone carphone modifyTimestamp > nsAIMid nsAIMid telephoneNumber birthyear c c mozillaHomeStreet cn cn > postalCode zip mozillaCustom1 custom1 mozillaHomeCountryName homePhone st > region mozillaCustom2 custom2 mozillaSecondEmail mozillaSecondEmail > facsimileTelephoneNumber facsimileTelephoneNumber mozillaCustom3 custom3 > mozillaUseHtmlMail mozillaUseHtmlMail mozillaHomeStreet2 birthday street > street postOfficeBox mozillaCustom4 custom4 mozillaHomeUrl homeurl l l pager > pagerphone ou department departmentNumber orgunit birthmonth > mozillaWorkStreet2 mozillaHomePostalCode objectClass" > > is what I see in the LDAP server log > I don't know, beats me as to why there is no objectclass filter component. Perhaps TB is smart enough to know (objectclass=*) is effectively a no-op and ignores it when it builds the final filter. What happens if you set the TB filter to (objectclass=person)? -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From orion at cora.nwra.com Fri Feb 15 21:54:55 2013 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 15 Feb 2013 14:54:55 -0700 Subject: [Freeipa-users] Non-human users In-Reply-To: <511EA9E7.5070606@redhat.com> References: <511E6419.4080402@cora.nwra.com> <511E662A.7010307@redhat.com> <511E7128.1090804@cora.nwra.com> <511E75C6.9020708@redhat.com> <511E7C66.907@redhat.com> <511E7FCC.3040605@redhat.com> <511E8005.5030107@redhat.com> <511E80A6.5000605@redhat.com> <511E80D2.2050801@cora.nwra.com> <511E833C.6080602@redhat.com> <511E8619.2070808@cora.nwra.com> <1360961172.12328.294.camel@willson.li.ssimo.org> <511EA101.2060505@redhat.com> <511EA143.1000804@cora.nwra.com> <511EA25F.2010606@redhat.com> <511EA593.1010801@cora.nwra.com> <511EA9E7.5070606@redhat.com> Message-ID: <511EAEAF.2080101@cora.nwra.com> On 02/15/2013 02:34 PM, John Dennis wrote: > On 02/15/2013 04:16 PM, Orion Poplawski wrote: >> >> Hmm, that is the filter in TB for me too, but: >> >> [15/Feb/2013:11:17:21 -0700] conn=931 op=1 SRCH >> base="ou=people,dc=nwra,dc=com" scope=2 >> filter="(|(mail=*apache*)(cn=*apache*)(givenName=*apache*)(sn=*apache*))" >> attrs="description notes title sn sn mozillaHomeLocalityName givenName >> mozillaHomeState mail mozillaWorkUrl workurl labeledURI o company >> mozillaNickname mozillaNickname mobile cellphone carphone modifyTimestamp >> nsAIMid nsAIMid telephoneNumber birthyear c c mozillaHomeStreet cn cn >> postalCode zip mozillaCustom1 custom1 mozillaHomeCountryName homePhone st >> region mozillaCustom2 custom2 mozillaSecondEmail mozillaSecondEmail >> facsimileTelephoneNumber facsimileTelephoneNumber mozillaCustom3 custom3 >> mozillaUseHtmlMail mozillaUseHtmlMail mozillaHomeStreet2 birthday street >> street postOfficeBox mozillaCustom4 custom4 mozillaHomeUrl homeurl l l pager >> pagerphone ou department departmentNumber orgunit birthmonth >> mozillaWorkStreet2 mozillaHomePostalCode objectClass" >> >> is what I see in the LDAP server log >> > > I don't know, beats me as to why there is no objectclass filter component. > Perhaps TB is smart enough to know (objectclass=*) is effectively a no-op and > ignores it when it builds the final filter. > > What happens if you set the TB filter to (objectclass=person)? > Yup, then it adds it: filter="(&(objectClass=person)(|(mail=*apac*)(cn=*apac*)(givenName=*apac*)(sn=*apac*)))" -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com From jdennis at redhat.com Fri Feb 15 22:12:49 2013 From: jdennis at redhat.com (John Dennis) Date: Fri, 15 Feb 2013 17:12:49 -0500 Subject: [Freeipa-users] Non-human users In-Reply-To: <511EAEAF.2080101@cora.nwra.com> References: <511E6419.4080402@cora.nwra.com> <511E662A.7010307@redhat.com> <511E7128.1090804@cora.nwra.com> <511E75C6.9020708@redhat.com> <511E7C66.907@redhat.com> <511E7FCC.3040605@redhat.com> <511E8005.5030107@redhat.com> <511E80A6.5000605@redhat.com> <511E80D2.2050801@cora.nwra.com> <511E833C.6080602@redhat.com> <511E8619.2070808@cora.nwra.com> <1360961172.12328.294.camel@willson.li.ssimo.org> <511EA101.2060505@redhat.com> <511EA143.1000804@cora.nwra.com> <511EA25F.2010606@redhat.com> <511EA593.1010801@cora.nwra.com> <511EA9E7.5070606@redhat.com> <511EAEAF.2080101@cora.nwra.com> Message-ID: <511EB2E1.4060506@redhat.com> On 02/15/2013 04:54 PM, Orion Poplawski wrote: > On 02/15/2013 02:34 PM, John Dennis wrote: >> On 02/15/2013 04:16 PM, Orion Poplawski wrote: >>> >>> Hmm, that is the filter in TB for me too, but: >>> >>> [15/Feb/2013:11:17:21 -0700] conn=931 op=1 SRCH >>> base="ou=people,dc=nwra,dc=com" scope=2 >>> filter="(|(mail=*apache*)(cn=*apache*)(givenName=*apache*)(sn=*apache*))" >>> attrs="description notes title sn sn mozillaHomeLocalityName givenName >>> mozillaHomeState mail mozillaWorkUrl workurl labeledURI o company >>> mozillaNickname mozillaNickname mobile cellphone carphone modifyTimestamp >>> nsAIMid nsAIMid telephoneNumber birthyear c c mozillaHomeStreet cn cn >>> postalCode zip mozillaCustom1 custom1 mozillaHomeCountryName homePhone st >>> region mozillaCustom2 custom2 mozillaSecondEmail mozillaSecondEmail >>> facsimileTelephoneNumber facsimileTelephoneNumber mozillaCustom3 custom3 >>> mozillaUseHtmlMail mozillaUseHtmlMail mozillaHomeStreet2 birthday street >>> street postOfficeBox mozillaCustom4 custom4 mozillaHomeUrl homeurl l l pager >>> pagerphone ou department departmentNumber orgunit birthmonth >>> mozillaWorkStreet2 mozillaHomePostalCode objectClass" >>> >>> is what I see in the LDAP server log >>> >> >> I don't know, beats me as to why there is no objectclass filter component. >> Perhaps TB is smart enough to know (objectclass=*) is effectively a no-op and >> ignores it when it builds the final filter. >> >> What happens if you set the TB filter to (objectclass=person)? >> > > Yup, then it adds it: > > > filter="(&(objectClass=person)(|(mail=*apac*)(cn=*apac*)(givenName=*apac*)(sn=*apac*)))" > O.K. I presume it's obvious the consequence of this little experiment is that if we do an an RFE that results in removing the person objectclass from non-human users you'll have to configure a custom LDAP search filter in every client in your enterprise if you don't want them to see non-human users in their search results. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From sakodak at gmail.com Fri Feb 15 22:15:52 2013 From: sakodak at gmail.com (KodaK) Date: Fri, 15 Feb 2013 16:15:52 -0600 Subject: [Freeipa-users] Adding other users to a user's created default group Message-ID: I suspect the answer to this is "no," but I'm asking anyway: Let's say I have an IPA user named "bob." When bob was created, IPA created a matching GID for him. Is it possible, through IPA, to add another user to that GID? If not, and I add another user to that GID by directly manipulating LDAP, will that break anything in IPA? I know the "correct" way is to make a new group. -- The government is going to read our mail anyway, might as well make it tough for them. GPG Public key ID: B6A1A7C6 From dpal at redhat.com Fri Feb 15 22:34:00 2013 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 15 Feb 2013 17:34:00 -0500 Subject: [Freeipa-users] Non-human users In-Reply-To: <511EB2E1.4060506@redhat.com> References: <511E6419.4080402@cora.nwra.com> <511E662A.7010307@redhat.com> <511E7128.1090804@cora.nwra.com> <511E75C6.9020708@redhat.com> <511E7C66.907@redhat.com> <511E7FCC.3040605@redhat.com> <511E8005.5030107@redhat.com> <511E80A6.5000605@redhat.com> <511E80D2.2050801@cora.nwra.com> <511E833C.6080602@redhat.com> <511E8619.2070808@cora.nwra.com> <1360961172.12328.294.camel@willson.li.ssimo.org> <511EA101.2060505@redhat.com> <511EA143.1000804@cora.nwra.com> <511EA25F.2010606@redhat.com> <511EA593.1010801@cora.nwra.com> <511EA9E7.5070606@redhat.com> <511EAEAF.2080101@cora.nwra.com> <511EB2E1.4060506@redhat.com> Message-ID: <511EB7D8.2060108@redhat.com> On 02/15/2013 05:12 PM, John Dennis wrote: > On 02/15/2013 04:54 PM, Orion Poplawski wrote: >> On 02/15/2013 02:34 PM, John Dennis wrote: >>> On 02/15/2013 04:16 PM, Orion Poplawski wrote: >>>> >>>> Hmm, that is the filter in TB for me too, but: >>>> >>>> [15/Feb/2013:11:17:21 -0700] conn=931 op=1 SRCH >>>> base="ou=people,dc=nwra,dc=com" scope=2 >>>> filter="(|(mail=*apache*)(cn=*apache*)(givenName=*apache*)(sn=*apache*))" >>>> >>>> attrs="description notes title sn sn mozillaHomeLocalityName givenName >>>> mozillaHomeState mail mozillaWorkUrl workurl labeledURI o company >>>> mozillaNickname mozillaNickname mobile cellphone carphone >>>> modifyTimestamp >>>> nsAIMid nsAIMid telephoneNumber birthyear c c mozillaHomeStreet cn cn >>>> postalCode zip mozillaCustom1 custom1 mozillaHomeCountryName >>>> homePhone st >>>> region mozillaCustom2 custom2 mozillaSecondEmail mozillaSecondEmail >>>> facsimileTelephoneNumber facsimileTelephoneNumber mozillaCustom3 >>>> custom3 >>>> mozillaUseHtmlMail mozillaUseHtmlMail mozillaHomeStreet2 birthday >>>> street >>>> street postOfficeBox mozillaCustom4 custom4 mozillaHomeUrl homeurl >>>> l l pager >>>> pagerphone ou department departmentNumber orgunit birthmonth >>>> mozillaWorkStreet2 mozillaHomePostalCode objectClass" >>>> >>>> is what I see in the LDAP server log >>>> >>> >>> I don't know, beats me as to why there is no objectclass filter >>> component. >>> Perhaps TB is smart enough to know (objectclass=*) is effectively a >>> no-op and >>> ignores it when it builds the final filter. >>> >>> What happens if you set the TB filter to (objectclass=person)? >>> >> >> Yup, then it adds it: >> >> >> filter="(&(objectClass=person)(|(mail=*apac*)(cn=*apac*)(givenName=*apac*)(sn=*apac*)))" >> >> > > O.K. I presume it's obvious the consequence of this little experiment > is that if we do an an RFE that results in removing the person > objectclass from non-human users you'll have to configure a custom > LDAP search filter in every client in your enterprise if you don't > want them to see non-human users in their search results. > Can it be managed via Puppet? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From orion at cora.nwra.com Fri Feb 15 22:35:29 2013 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 15 Feb 2013 15:35:29 -0700 Subject: [Freeipa-users] Non-human users In-Reply-To: <511EB2E1.4060506@redhat.com> References: <511E6419.4080402@cora.nwra.com> <511E662A.7010307@redhat.com> <511E7128.1090804@cora.nwra.com> <511E75C6.9020708@redhat.com> <511E7C66.907@redhat.com> <511E7FCC.3040605@redhat.com> <511E8005.5030107@redhat.com> <511E80A6.5000605@redhat.com> <511E80D2.2050801@cora.nwra.com> <511E833C.6080602@redhat.com> <511E8619.2070808@cora.nwra.com> <1360961172.12328.294.camel@willson.li.ssimo.org> <511EA101.2060505@redhat.com> <511EA143.1000804@cora.nwra.com> <511EA25F.2010606@redhat.com> <511EA593.1010801@cora.nwra.com> <511EA9E7.5070606@redhat.com> <511EAEAF.2080101@cora.nwra.com> <511EB2E1.4060506@redhat.com> Message-ID: <511EB831.10200@cora.nwra.com> On 02/15/2013 03:12 PM, John Dennis wrote: > On 02/15/2013 04:54 PM, Orion Poplawski wrote: >> On 02/15/2013 02:34 PM, John Dennis wrote: >>> What happens if you set the TB filter to (objectclass=person)? >>> >> >> Yup, then it adds it: >> >> >> filter="(&(objectClass=person)(|(mail=*apac*)(cn=*apac*)(givenName=*apac*)(sn=*apac*)))" >> >> > > O.K. I presume it's obvious the consequence of this little experiment is that > if we do an an RFE that results in removing the person objectclass from > non-human users you'll have to configure a custom LDAP search filter in every > client in your enterprise if you don't want them to see non-human users in > their search results. > Well, it at least doesn't present an email during auto completion (since there is none), but an empty address book entry is returned during and address book search. Hopefully can be set with Mozilla Enterprise deployment tools. And at least such a possibility would exist. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com From dpal at redhat.com Fri Feb 15 22:35:43 2013 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 15 Feb 2013 17:35:43 -0500 Subject: [Freeipa-users] Adding other users to a user's created default group In-Reply-To: References: Message-ID: <511EB83F.7080607@redhat.com> On 02/15/2013 05:15 PM, KodaK wrote: > I suspect the answer to this is "no," but I'm asking anyway: > > Let's say I have an IPA user named "bob." When bob was created, IPA > created a matching GID for him. Is it possible, through IPA, to add > another user to that GID? > > If not, and I add another user to that GID by directly manipulating > LDAP, will that break anything in IPA? > > I know the "correct" way is to make a new group. > I think you should be able to. There was/is way to display UPGs in the UI so it should be managble as yet another group with some special warnings. At least this is how it was speced. I do not know how it is actually implemented. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From simo at redhat.com Fri Feb 15 22:50:49 2013 From: simo at redhat.com (Simo Sorce) Date: Fri, 15 Feb 2013 17:50:49 -0500 Subject: [Freeipa-users] Adding other users to a user's created default group In-Reply-To: <511EB83F.7080607@redhat.com> References: <511EB83F.7080607@redhat.com> Message-ID: <1360968649.12328.301.camel@willson.li.ssimo.org> On Fri, 2013-02-15 at 17:35 -0500, Dmitri Pal wrote: > On 02/15/2013 05:15 PM, KodaK wrote: > > I suspect the answer to this is "no," but I'm asking anyway: > > > > Let's say I have an IPA user named "bob." When bob was created, IPA > > created a matching GID for him. Is it possible, through IPA, to add > > another user to that GID? > > > > If not, and I add another user to that GID by directly manipulating > > LDAP, will that break anything in IPA? > > > > I know the "correct" way is to make a new group. > > > I think you should be able to. You may be able to but you -should not-. > There was/is way to display UPGs in the > UI so it should be managble as yet another group with some special > warnings. At least this is how it was speced. I do not know how it is > actually implemented. No, the UPG are not special just because of display reasons. The UPG are private to the user because on most *nix the default mask is allows access by the primary group. This means having other users part of the primary group of a user means all this user files are readable by the other users by default. So the way we generate UPGs is that we do not add the groupOFmembers objectclass which prevents you from adding the member attribute, preventing additional users to be made part of this group. Now, you can convert a UPG group into a normal group manually via LDAP operations, or you can also simply delete the UPG and then recreate a new group with the same gid number. Just make sure you are comfortable with the security consequences for the original user when doing so. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Fri Feb 15 23:03:23 2013 From: simo at redhat.com (Simo Sorce) Date: Fri, 15 Feb 2013 18:03:23 -0500 Subject: [Freeipa-users] Non-human users In-Reply-To: <511EB2E1.4060506@redhat.com> References: <511E6419.4080402@cora.nwra.com> <511E662A.7010307@redhat.com> <511E7128.1090804@cora.nwra.com> <511E75C6.9020708@redhat.com> <511E7C66.907@redhat.com> <511E7FCC.3040605@redhat.com> <511E8005.5030107@redhat.com> <511E80A6.5000605@redhat.com> <511E80D2.2050801@cora.nwra.com> <511E833C.6080602@redhat.com> <511E8619.2070808@cora.nwra.com> <1360961172.12328.294.camel@willson.li.ssimo.org> <511EA101.2060505@redhat.com> <511EA143.1000804@cora.nwra.com> <511EA25F.2010606@redhat.com> <511EA593.1010801@cora.nwra.com> <511EA9E7.5070606@redhat.com> <511EAEAF.2080101@cora.nwra.com> <511EB2E1.4060506@redhat.com> Message-ID: <1360969403.12328.311.camel@willson.li.ssimo.org> On Fri, 2013-02-15 at 17:12 -0500, John Dennis wrote: > On 02/15/2013 04:54 PM, Orion Poplawski wrote: > > On 02/15/2013 02:34 PM, John Dennis wrote: > >> On 02/15/2013 04:16 PM, Orion Poplawski wrote: > >>> > >>> Hmm, that is the filter in TB for me too, but: > >>> > >>> [15/Feb/2013:11:17:21 -0700] conn=931 op=1 SRCH > >>> base="ou=people,dc=nwra,dc=com" scope=2 > >>> filter="(|(mail=*apache*)(cn=*apache*)(givenName=*apache*)(sn=*apache*))" > >>> attrs="description notes title sn sn mozillaHomeLocalityName givenName > >>> mozillaHomeState mail mozillaWorkUrl workurl labeledURI o company > >>> mozillaNickname mozillaNickname mobile cellphone carphone modifyTimestamp > >>> nsAIMid nsAIMid telephoneNumber birthyear c c mozillaHomeStreet cn cn > >>> postalCode zip mozillaCustom1 custom1 mozillaHomeCountryName homePhone st > >>> region mozillaCustom2 custom2 mozillaSecondEmail mozillaSecondEmail > >>> facsimileTelephoneNumber facsimileTelephoneNumber mozillaCustom3 custom3 > >>> mozillaUseHtmlMail mozillaUseHtmlMail mozillaHomeStreet2 birthday street > >>> street postOfficeBox mozillaCustom4 custom4 mozillaHomeUrl homeurl l l pager > >>> pagerphone ou department departmentNumber orgunit birthmonth > >>> mozillaWorkStreet2 mozillaHomePostalCode objectClass" > >>> > >>> is what I see in the LDAP server log > >>> > >> > >> I don't know, beats me as to why there is no objectclass filter component. > >> Perhaps TB is smart enough to know (objectclass=*) is effectively a no-op and > >> ignores it when it builds the final filter. > >> > >> What happens if you set the TB filter to (objectclass=person)? > >> > > > > Yup, then it adds it: > > > > > > filter="(&(objectClass=person)(|(mail=*apac*)(cn=*apac*)(givenName=*apac*)(sn=*apac*)))" > > > > O.K. I presume it's obvious the consequence of this little experiment is > that if we do an an RFE that results in removing the person objectclass > from non-human users you'll have to configure a custom LDAP search > filter in every client in your enterprise if you don't want them to see > non-human users in their search results. Not really, without the person objectclass none of the attributes thunderbird searches by default would be part of the user object, so the user would *not* show up. So the RFE would perfectly solve also the requirement these 'non-person' users do not show up in thunderbird. Simo. -- Simo Sorce * Red Hat, Inc * New York From orion at cora.nwra.com Fri Feb 15 23:06:04 2013 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 15 Feb 2013 16:06:04 -0700 Subject: [Freeipa-users] Non-human users In-Reply-To: <1360969403.12328.311.camel@willson.li.ssimo.org> References: <511E6419.4080402@cora.nwra.com> <511E662A.7010307@redhat.com> <511E7128.1090804@cora.nwra.com> <511E75C6.9020708@redhat.com> <511E7C66.907@redhat.com> <511E7FCC.3040605@redhat.com> <511E8005.5030107@redhat.com> <511E80A6.5000605@redhat.com> <511E80D2.2050801@cora.nwra.com> <511E833C.6080602@redhat.com> <511E8619.2070808@cora.nwra.com> <1360961172.12328.294.camel@willson.li.ssimo.org> <511EA101.2060505@redhat.com> <511EA143.1000804@cora.nwra.com> <511EA25F.2010606@redhat.com> <511EA593.1010801@cora.nwra.com> <511EA9E7.5070606@redhat.com> <511EAEAF.2080101@cora.nwra.com> <511EB2E1.4060506@redhat.com> <1360969403.12328.311.camel@willson.li.ssimo.org> Message-ID: <511EBF5C.4070302@cora.nwra.com> On 02/15/2013 04:03 PM, Simo Sorce wrote: > On Fri, 2013-02-15 at 17:12 -0500, John Dennis wrote: >> On 02/15/2013 04:54 PM, Orion Poplawski wrote: >>> On 02/15/2013 02:34 PM, John Dennis wrote: >>>> On 02/15/2013 04:16 PM, Orion Poplawski wrote: >>>>> >>>>> Hmm, that is the filter in TB for me too, but: >>>>> >>>>> [15/Feb/2013:11:17:21 -0700] conn=931 op=1 SRCH >>>>> base="ou=people,dc=nwra,dc=com" scope=2 >>>>> filter="(|(mail=*apache*)(cn=*apache*)(givenName=*apache*)(sn=*apache*))" >>>>> attrs="description notes title sn sn mozillaHomeLocalityName givenName >>>>> mozillaHomeState mail mozillaWorkUrl workurl labeledURI o company >>>>> mozillaNickname mozillaNickname mobile cellphone carphone modifyTimestamp >>>>> nsAIMid nsAIMid telephoneNumber birthyear c c mozillaHomeStreet cn cn >>>>> postalCode zip mozillaCustom1 custom1 mozillaHomeCountryName homePhone st >>>>> region mozillaCustom2 custom2 mozillaSecondEmail mozillaSecondEmail >>>>> facsimileTelephoneNumber facsimileTelephoneNumber mozillaCustom3 custom3 >>>>> mozillaUseHtmlMail mozillaUseHtmlMail mozillaHomeStreet2 birthday street >>>>> street postOfficeBox mozillaCustom4 custom4 mozillaHomeUrl homeurl l l pager >>>>> pagerphone ou department departmentNumber orgunit birthmonth >>>>> mozillaWorkStreet2 mozillaHomePostalCode objectClass" >>>>> >>>>> is what I see in the LDAP server log >>>>> >>>> >>>> I don't know, beats me as to why there is no objectclass filter component. >>>> Perhaps TB is smart enough to know (objectclass=*) is effectively a no-op and >>>> ignores it when it builds the final filter. >>>> >>>> What happens if you set the TB filter to (objectclass=person)? >>>> >>> >>> Yup, then it adds it: >>> >>> >>> filter="(&(objectClass=person)(|(mail=*apac*)(cn=*apac*)(givenName=*apac*)(sn=*apac*)))" >>> >> >> O.K. I presume it's obvious the consequence of this little experiment is >> that if we do an an RFE that results in removing the person objectclass >> from non-human users you'll have to configure a custom LDAP search >> filter in every client in your enterprise if you don't want them to see >> non-human users in their search results. > > Not really, without the person objectclass none of the attributes > thunderbird searches by default would be part of the user object, so the > user would *not* show up. > > So the RFE would perfectly solve also the requirement these 'non-person' > users do not show up in thunderbird. > > Simo. > posixAccount must have "cn". -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com From orion at cora.nwra.com Fri Feb 15 23:07:52 2013 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 15 Feb 2013 16:07:52 -0700 Subject: [Freeipa-users] Non-human users In-Reply-To: <511EBF5C.4070302@cora.nwra.com> References: <511E6419.4080402@cora.nwra.com> <511E662A.7010307@redhat.com> <511E7128.1090804@cora.nwra.com> <511E75C6.9020708@redhat.com> <511E7C66.907@redhat.com> <511E7FCC.3040605@redhat.com> <511E8005.5030107@redhat.com> <511E80A6.5000605@redhat.com> <511E80D2.2050801@cora.nwra.com> <511E833C.6080602@redhat.com> <511E8619.2070808@cora.nwra.com> <1360961172.12328.294.camel@willson.li.ssimo.org> <511EA101.2060505@redhat.com> <511EA143.1000804@cora.nwra.com> <511EA25F.2010606@redhat.com> <511EA593.1010801@cora.nwra.com> <511EA9E7.5070606@redhat.com> <511EAEAF.2080101@cora.nwra.com> <511EB2E1.4060506@redhat.com> <1360969403.12328.311.camel@willson.li.ssimo.org> <511EBF5C.4070302@cora.nwra.com> Message-ID: <511EBFC8.1000603@cora.nwra.com> On 02/15/2013 04:06 PM, Orion Poplawski wrote: > On 02/15/2013 04:03 PM, Simo Sorce wrote: >> On Fri, 2013-02-15 at 17:12 -0500, John Dennis wrote: >>> On 02/15/2013 04:54 PM, Orion Poplawski wrote: >>>> Yup, then it adds it: >>>> >>>> >>>> filter="(&(objectClass=person)(|(mail=*apac*)(cn=*apac*)(givenName=*apac*)(sn=*apac*)))" >>>> >>>> >>> >>> O.K. I presume it's obvious the consequence of this little experiment is >>> that if we do an an RFE that results in removing the person objectclass >>> from non-human users you'll have to configure a custom LDAP search >>> filter in every client in your enterprise if you don't want them to see >>> non-human users in their search results. >> >> Not really, without the person objectclass none of the attributes >> thunderbird searches by default would be part of the user object, so the >> user would *not* show up. >> >> So the RFE would perfectly solve also the requirement these 'non-person' >> users do not show up in thunderbird. >> >> Simo. >> > > posixAccount must have "cn". > > That said, there are still other (and arguably more important) reasons for this RFE. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com From simo at redhat.com Fri Feb 15 23:10:13 2013 From: simo at redhat.com (Simo Sorce) Date: Fri, 15 Feb 2013 18:10:13 -0500 Subject: [Freeipa-users] Non-human users In-Reply-To: <511EBF5C.4070302@cora.nwra.com> References: <511E6419.4080402@cora.nwra.com> <511E662A.7010307@redhat.com> <511E7128.1090804@cora.nwra.com> <511E75C6.9020708@redhat.com> <511E7C66.907@redhat.com> <511E7FCC.3040605@redhat.com> <511E8005.5030107@redhat.com> <511E80A6.5000605@redhat.com> <511E80D2.2050801@cora.nwra.com> <511E833C.6080602@redhat.com> <511E8619.2070808@cora.nwra.com> <1360961172.12328.294.camel@willson.li.ssimo.org> <511EA101.2060505@redhat.com> <511EA143.1000804@cora.nwra.com> <511EA25F.2010606@redhat.com> <511EA593.1010801@cora.nwra.com> <511EA9E7.5070606@redhat.com> <511EAEAF.2080101@cora.nwra.com> <511EB2E1.4060506@redhat.com> <1360969403.12328.311.camel@willson.li.ssimo.org> <511EBF5C.4070302@cora.nwra.com> Message-ID: <1360969813.12328.314.camel@willson.li.ssimo.org> On Fri, 2013-02-15 at 16:06 -0700, Orion Poplawski wrote: > On 02/15/2013 04:03 PM, Simo Sorce wrote: > > On Fri, 2013-02-15 at 17:12 -0500, John Dennis wrote: > >> On 02/15/2013 04:54 PM, Orion Poplawski wrote: > >>> On 02/15/2013 02:34 PM, John Dennis wrote: > >>>> On 02/15/2013 04:16 PM, Orion Poplawski wrote: > >>>>> > >>>>> Hmm, that is the filter in TB for me too, but: > >>>>> > >>>>> [15/Feb/2013:11:17:21 -0700] conn=931 op=1 SRCH > >>>>> base="ou=people,dc=nwra,dc=com" scope=2 > >>>>> filter="(|(mail=*apache*)(cn=*apache*)(givenName=*apache*)(sn=*apache*))" > >>>>> attrs="description notes title sn sn mozillaHomeLocalityName givenName > >>>>> mozillaHomeState mail mozillaWorkUrl workurl labeledURI o company > >>>>> mozillaNickname mozillaNickname mobile cellphone carphone modifyTimestamp > >>>>> nsAIMid nsAIMid telephoneNumber birthyear c c mozillaHomeStreet cn cn > >>>>> postalCode zip mozillaCustom1 custom1 mozillaHomeCountryName homePhone st > >>>>> region mozillaCustom2 custom2 mozillaSecondEmail mozillaSecondEmail > >>>>> facsimileTelephoneNumber facsimileTelephoneNumber mozillaCustom3 custom3 > >>>>> mozillaUseHtmlMail mozillaUseHtmlMail mozillaHomeStreet2 birthday street > >>>>> street postOfficeBox mozillaCustom4 custom4 mozillaHomeUrl homeurl l l pager > >>>>> pagerphone ou department departmentNumber orgunit birthmonth > >>>>> mozillaWorkStreet2 mozillaHomePostalCode objectClass" > >>>>> > >>>>> is what I see in the LDAP server log > >>>>> > >>>> > >>>> I don't know, beats me as to why there is no objectclass filter component. > >>>> Perhaps TB is smart enough to know (objectclass=*) is effectively a no-op and > >>>> ignores it when it builds the final filter. > >>>> > >>>> What happens if you set the TB filter to (objectclass=person)? > >>>> > >>> > >>> Yup, then it adds it: > >>> > >>> > >>> filter="(&(objectClass=person)(|(mail=*apac*)(cn=*apac*)(givenName=*apac*)(sn=*apac*)))" > >>> > >> > >> O.K. I presume it's obvious the consequence of this little experiment is > >> that if we do an an RFE that results in removing the person objectclass > >> from non-human users you'll have to configure a custom LDAP search > >> filter in every client in your enterprise if you don't want them to see > >> non-human users in their search results. > > > > Not really, without the person objectclass none of the attributes > > thunderbird searches by default would be part of the user object, so the > > user would *not* show up. > > > > So the RFE would perfectly solve also the requirement these 'non-person' > > users do not show up in thunderbird. > > > > Simo. > > > > posixAccount must have "cn". Argh, you are right :-/ I forgot about that silly requirement (given it already requires 'uid') Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Fri Feb 15 23:11:22 2013 From: simo at redhat.com (Simo Sorce) Date: Fri, 15 Feb 2013 18:11:22 -0500 Subject: [Freeipa-users] Non-human users In-Reply-To: <511EB7D8.2060108@redhat.com> References: <511E6419.4080402@cora.nwra.com> <511E662A.7010307@redhat.com> <511E7128.1090804@cora.nwra.com> <511E75C6.9020708@redhat.com> <511E7C66.907@redhat.com> <511E7FCC.3040605@redhat.com> <511E8005.5030107@redhat.com> <511E80A6.5000605@redhat.com> <511E80D2.2050801@cora.nwra.com> <511E833C.6080602@redhat.com> <511E8619.2070808@cora.nwra.com> <1360961172.12328.294.camel@willson.li.ssimo.org> <511EA101.2060505@redhat.com> <511EA143.1000804@cora.nwra.com> <511EA25F.2010606@redhat.com> <511EA593.1010801@cora.nwra.com> <511EA9E7.5070606@redhat.com> <511EAEAF.2080101@cora.nwra.com> <511EB2E1.4060506@redhat.com> <511EB7D8.2060108@redhat.com> Message-ID: <1360969882.12328.315.camel@willson.li.ssimo.org> On Fri, 2013-02-15 at 17:34 -0500, Dmitri Pal wrote: > On 02/15/2013 05:12 PM, John Dennis wrote: > > On 02/15/2013 04:54 PM, Orion Poplawski wrote: > >> On 02/15/2013 02:34 PM, John Dennis wrote: > >>> On 02/15/2013 04:16 PM, Orion Poplawski wrote: > >>>> > >>>> Hmm, that is the filter in TB for me too, but: > >>>> > >>>> [15/Feb/2013:11:17:21 -0700] conn=931 op=1 SRCH > >>>> base="ou=people,dc=nwra,dc=com" scope=2 > >>>> filter="(|(mail=*apache*)(cn=*apache*)(givenName=*apache*)(sn=*apache*))" > >>>> > >>>> attrs="description notes title sn sn mozillaHomeLocalityName givenName > >>>> mozillaHomeState mail mozillaWorkUrl workurl labeledURI o company > >>>> mozillaNickname mozillaNickname mobile cellphone carphone > >>>> modifyTimestamp > >>>> nsAIMid nsAIMid telephoneNumber birthyear c c mozillaHomeStreet cn cn > >>>> postalCode zip mozillaCustom1 custom1 mozillaHomeCountryName > >>>> homePhone st > >>>> region mozillaCustom2 custom2 mozillaSecondEmail mozillaSecondEmail > >>>> facsimileTelephoneNumber facsimileTelephoneNumber mozillaCustom3 > >>>> custom3 > >>>> mozillaUseHtmlMail mozillaUseHtmlMail mozillaHomeStreet2 birthday > >>>> street > >>>> street postOfficeBox mozillaCustom4 custom4 mozillaHomeUrl homeurl > >>>> l l pager > >>>> pagerphone ou department departmentNumber orgunit birthmonth > >>>> mozillaWorkStreet2 mozillaHomePostalCode objectClass" > >>>> > >>>> is what I see in the LDAP server log > >>>> > >>> > >>> I don't know, beats me as to why there is no objectclass filter > >>> component. > >>> Perhaps TB is smart enough to know (objectclass=*) is effectively a > >>> no-op and > >>> ignores it when it builds the final filter. > >>> > >>> What happens if you set the TB filter to (objectclass=person)? > >>> > >> > >> Yup, then it adds it: > >> > >> > >> filter="(&(objectClass=person)(|(mail=*apac*)(cn=*apac*)(givenName=*apac*)(sn=*apac*)))" > >> > >> > > > > O.K. I presume it's obvious the consequence of this little experiment > > is that if we do an an RFE that results in removing the person > > objectclass from non-human users you'll have to configure a custom > > LDAP search filter in every client in your enterprise if you don't > > want them to see non-human users in their search results. > > > Can it be managed via Puppet? Unlikely, thunderbird preferences are per user and stored in user preference files, which cannot be arbitrarily overridden. Simo. -- Simo Sorce * Red Hat, Inc * New York From bcook at redhat.com Fri Feb 15 23:32:30 2013 From: bcook at redhat.com (Brian Cook) Date: Fri, 15 Feb 2013 15:32:30 -0800 Subject: [Freeipa-users] Non-human users In-Reply-To: <1360969882.12328.315.camel@willson.li.ssimo.org> References: <511E6419.4080402@cora.nwra.com> <511E662A.7010307@redhat.com> <511E7128.1090804@cora.nwra.com> <511E75C6.9020708@redhat.com> <511E7C66.907@redhat.com> <511E7FCC.3040605@redhat.com> <511E8005.5030107@redhat.com> <511E80A6.5000605@redhat.com> <511E80D2.2050801@cora.nwra.com> <511E833C.6080602@redhat.com> <511E8619.2070808@cora.nwra.com> <1360961172.12328.294.camel@willson.li.ssimo.org> <511EA101.2060505@redhat.com> <511EA143.1000804@cora.nwra.com> <511EA25F.2010606@redhat.com> <511EA593.1010801@cora.nwra.com> <511EA9E7.5070606@redhat.com> <511EAEAF.2080101@cora.nwra.com> <511EB2E1.4060506@redhat.com> <511EB7D8.2060108@redhat.com> <1360969882.12328.315.camel@willson.li.ssimo.org> Message-ID: On Feb 15, 2013, at 3:11 PM, Simo Sorce wrote: > On Fri, 2013-02-15 at 17:34 -0500, Dmitri Pal wrote: >> On 02/15/2013 05:12 PM, John Dennis wrote: >>> On 02/15/2013 04:54 PM, Orion Poplawski wrote: >>>> On 02/15/2013 02:34 PM, John Dennis wrote: >>>>> On 02/15/2013 04:16 PM, Orion Poplawski wrote: >>>>>> >>>>>> Hmm, that is the filter in TB for me too, but: >>>>>> >>>>>> [15/Feb/2013:11:17:21 -0700] conn=931 op=1 SRCH >>>>>> base="ou=people,dc=nwra,dc=com" scope=2 >>>>>> filter="(|(mail=*apache*)(cn=*apache*)(givenName=*apache*)(sn=*apache*))" >>>>>> >>>>>> attrs="description notes title sn sn mozillaHomeLocalityName givenName >>>>>> mozillaHomeState mail mozillaWorkUrl workurl labeledURI o company >>>>>> mozillaNickname mozillaNickname mobile cellphone carphone >>>>>> modifyTimestamp >>>>>> nsAIMid nsAIMid telephoneNumber birthyear c c mozillaHomeStreet cn cn >>>>>> postalCode zip mozillaCustom1 custom1 mozillaHomeCountryName >>>>>> homePhone st >>>>>> region mozillaCustom2 custom2 mozillaSecondEmail mozillaSecondEmail >>>>>> facsimileTelephoneNumber facsimileTelephoneNumber mozillaCustom3 >>>>>> custom3 >>>>>> mozillaUseHtmlMail mozillaUseHtmlMail mozillaHomeStreet2 birthday >>>>>> street >>>>>> street postOfficeBox mozillaCustom4 custom4 mozillaHomeUrl homeurl >>>>>> l l pager >>>>>> pagerphone ou department departmentNumber orgunit birthmonth >>>>>> mozillaWorkStreet2 mozillaHomePostalCode objectClass" >>>>>> >>>>>> is what I see in the LDAP server log >>>>>> >>>>> >>>>> I don't know, beats me as to why there is no objectclass filter >>>>> component. >>>>> Perhaps TB is smart enough to know (objectclass=*) is effectively a >>>>> no-op and >>>>> ignores it when it builds the final filter. >>>>> >>>>> What happens if you set the TB filter to (objectclass=person)? >>>>> >>>> >>>> Yup, then it adds it: >>>> >>>> >>>> filter="(&(objectClass=person)(|(mail=*apac*)(cn=*apac*)(givenName=*apac*)(sn=*apac*)))" >>>> >>>> >>> >>> O.K. I presume it's obvious the consequence of this little experiment >>> is that if we do an an RFE that results in removing the person >>> objectclass from non-human users you'll have to configure a custom >>> LDAP search filter in every client in your enterprise if you don't >>> want them to see non-human users in their search results. >>> >> Can it be managed via Puppet? > > Unlikely, thunderbird preferences are per user and stored in user > preference files, which cannot be arbitrarily overridden. > Following URL details a deployment method that configures thunderbird for address book in AD with a custom search string. Maybe you can use it or it will inspire you as to how to accomplish your deployment. http://wpkg.org/Thunderbird#System-wide > 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 dpal at redhat.com Sat Feb 16 02:05:07 2013 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 15 Feb 2013 21:05:07 -0500 Subject: [Freeipa-users] Adding other users to a user's created default group In-Reply-To: <1360968649.12328.301.camel@willson.li.ssimo.org> References: <511EB83F.7080607@redhat.com> <1360968649.12328.301.camel@willson.li.ssimo.org> Message-ID: <511EE953.4020004@redhat.com> On 02/15/2013 05:50 PM, Simo Sorce wrote: > On Fri, 2013-02-15 at 17:35 -0500, Dmitri Pal wrote: >> On 02/15/2013 05:15 PM, KodaK wrote: >>> I suspect the answer to this is "no," but I'm asking anyway: >>> >>> Let's say I have an IPA user named "bob." When bob was created, IPA >>> created a matching GID for him. Is it possible, through IPA, to add >>> another user to that GID? >>> >>> If not, and I add another user to that GID by directly manipulating >>> LDAP, will that break anything in IPA? >>> >>> I know the "correct" way is to make a new group. >>> >> I think you should be able to. > You may be able to but you -should not-. > >> There was/is way to display UPGs in the >> UI so it should be managble as yet another group with some special >> warnings. At least this is how it was speced. I do not know how it is >> actually implemented. > No, the UPG are not special just because of display reasons. This is not what I said or meant. UPGs are not by default shown in the UI. They are filtered out. There is a way (at least how it was specd) to show them and perform operations on them. There is a supposed to be a check box on the list of the groups screen that controls it (I do not have the IPA instance to confirm). I also do not remember what operations are allowed against such group. It might very well be that the only operation allowed is to decouple UPG from the user. Now that I think of it this might be the case. This is an irreversible operation. Then you can add another user into that group but definitely Simo is correct about the security implications, however based on the way you worded the question it seems that your are aware of them. > > The UPG are private to the user because on most *nix the default mask is > allows access by the primary group. This means having other users part > of the primary group of a user means all this user files are readable by > the other users by default. > > So the way we generate UPGs is that we do not add the groupOFmembers > objectclass which prevents you from adding the member attribute, > preventing additional users to be made part of this group. > > Now, you can convert a UPG group into a normal group manually via LDAP > operations, or you can also simply delete the UPG and then recreate a > new group with the same gid number. There should be a CLI command for that AFAIR. > > Just make sure you are comfortable with the security consequences for > the original user when doing so. > > Simo. > -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From sigbjorn at nixtra.com Sat Feb 16 11:27:48 2013 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Sat, 16 Feb 2013 12:27:48 +0100 Subject: [Freeipa-users] RHEL6 IPA and Active Directory synchronisation and Solaris RBAC In-Reply-To: <1360937840.21935.556.camel@osc145.evn.harris.com> References: <511BACEE.8050900@redhat.com> <511D2541.1000201@nixtra.com> <511D2CAC.6050400@redhat.com> <511D4693.8010502@redhat.com> <1360937840.21935.556.camel@osc145.evn.harris.com> Message-ID: <511F6D34.8010907@nixtra.com> On 02/15/2013 03:17 PM, Rodney L. Mercer wrote: > > > On Thu, 2013-02-14 at 21:44 +0100, Sigbjorn Lie wrote: >> I agree with schema support being enough for now. I do not expect the >> ipa mgmt tools to support Solaris rbac mgmt. >> >> The ipa mgmt tools are great, but I already have other data in the ipa >> ldap that I have to manage manually anyway. >> >> >> >> Rgds, >> Siggi >> >> >> >> Rob Crittenden wrote: >> Dag Wieers wrote: >> On Thu, 14 Feb 2013, Rob Crittenden wrote: >> >> Sigbjorn Lie wrote: >> On 02/13/2013 04:10 PM, Rob Crittenden wrote: >> >> Also since we also require compatibility with Solaris, and roles >> (RBAC) >> is currently used on Solaris, does IPA support RBAC on Solar >> is ? >> (We >> noticed that RBAC mentioned in the IPA web interface only >> relates to > > IPA >> management). >> No, IPA doesn't support RBAC on Solaris. >> >> I've come across the same issue. This is just a matter of extending the >> schema. >> >> Would there be any interest for adding the Solaris RBAC schema as a >> part >> of the standard IPA distributed LDAP schemas? > > > Consider the following: What else would have to be put in to support > this? > Once the schema is established, can SSSD be extended to use this and > potentially be referenced in nsswitch.conf as it is implemented on > Solaris? IE: > tail -5 /etc/nsswitch.conf > user_attr: sssd > auth_attr: sssd > prof_attr: sssd > exec_attr: sssd > project: sssd > > Do you use SSSD on Solaris? From sigbjorn at nixtra.com Sat Feb 16 11:29:28 2013 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Sat, 16 Feb 2013 12:29:28 +0100 Subject: [Freeipa-users] RHEL6 IPA and Active Directory synchronisation and Solaris RBAC In-Reply-To: <511EA93C.8060909@redhat.com> References: <511BACEE.8050900@redhat.com> <511D2541.1000201@nixtra.com> <511D2CAC.6050400@redhat.com> <511D4693.8010502@redhat.com> <1360937840.21935.556.camel@osc145.evn.harris.com> <511EA93C.8060909@redhat.com> Message-ID: <511F6D98.30700@nixtra.com> On 02/15/2013 10:31 PM, Dmitri Pal wrote: > On 02/15/2013 09:17 AM, Rodney L. Mercer wrote: >> >> On Thu, 2013-02-14 at 21:44 +0100, Sigbjorn Lie wrote: >>> I agree with schema support being enough for now. I do not expect the >>> ipa mgmt tools to support Solaris rbac mgmt. >>> >>> The ipa mgmt tools are great, but I already have other data in the ipa >>> ldap that I have to manage manually anyway. >>> >>> >>> >>> Rgds, >>> Siggi >>> >>> >>> >>> Rob Crittenden wrote: >>> Dag Wieers wrote: >>> On Thu, 14 Feb 2013, Rob Crittenden wrote: >>> >>> Sigbjorn Lie wrote: >>> On 02/13/2013 04:10 PM, Rob Crittenden wrote: >>> >>> Also since we also require compatibility with Solaris, and roles >>> (RBAC) >>> is currently used on Solaris, does IPA support RBAC on Solar >>> is ? >>> (We >>> noticed that RBAC mentioned in the IPA web interface only >>> relates to > > IPA >>> management). >>> No, IPA doesn't support RBAC on Solaris. >>> >>> I've come across the same issue. This is just a matter of extending the >>> schema. >>> >>> Would there be any interest for adding the Solaris RBAC schema as a >>> part >>> of the standard IPA distributed LDAP schemas? >> >> Consider the following: What else would have to be put in to support >> this? >> Once the schema is established, can SSSD be extended to use this and >> potentially be referenced in nsswitch.conf as it is implemented on >> Solaris? IE: >> tail -5 /etc/nsswitch.conf >> user_attr: sssd >> auth_attr: sssd >> prof_attr: sssd >> exec_attr: sssd >> project: sssd > > Before we define how it is passed/exposed it would nice to understand > who on Linux will be consuming it out of SSSD? > I don't think Linux would consume these attributes. They are specific to the Role Based Access Control solution implemented in Solaris. Rgds, Siggi From shelltoesuperstar at gmail.com Sat Feb 16 13:22:19 2013 From: shelltoesuperstar at gmail.com (Charlie Derwent) Date: Sat, 16 Feb 2013 13:22:19 +0000 Subject: [Freeipa-users] Unable to enrol servers with principal In-Reply-To: <511E84F2.1090203@redhat.com> References: <5116FC75.1000105@redhat.com> <511C1338.3010101@redhat.com> <511E84F2.1090203@redhat.com> Message-ID: On Fri, Feb 15, 2013 at 6:56 PM, Rob Crittenden wrote: > Charlie Derwent wrote: > >> Hi >> So there's nothing I can see in the access logs. >> However, I get the following message in the KDC log >> Feb 15 14:05:49 ipa.example.com >> >> krb5kdc[1749](info): AS_REQ (12 etypes {18 17 16 23 1 3 2 11 10 15 12 >> 13}) 192.168.0.1 : ISSUE: authtime 1360951549, >> >> etypes {rep=18 tkt=18 ses=18}, user at EXAMPLE.COM >> for krbtgt/EXAMPLE.COM at EXAMPLE.COM >> > >> >> and when I get a "kinit(v5): Cannot read password while getting initial >> credentials" error I see this error >> Feb 15 14:39:35 ipa.example.com >> >> krb5kdc[1749](info): AS_REQ (12 etypes {18 17 16 23 1 3 2 11 10 15 12 >> 13}) 192.168.0.1 : NEEDED_PREAUTH: user at EXAMPLE.COM >> for kadmin/changepw at EXAMPLE.COM >> >, >> Additional pre-authentication required >> >> Interestingly enough when I try a 5.6 server running >> ipa-client-2.0.14.el5_7.2 and xmlrpc-c-client-1.16.24-1206.**1840.el5 it >> works but rolling ipa-client, certmonger, xmlrpc-c and xmlrpc-c-client >> back to their 5.6 versions on the 5.8 server makes no difference. I >> guess looking at times it has worked I should be getting a TGS_REQ >> message in logs immediately after the AS_REQ. >> Any ideas or anything else I can check? >> Thanks >> Charliez >> > > Are you seeing this failure only on this one 5.8 box or on others as well? > > The linker error is totally bizarre and I'm not sure why you'd get it > infrequently. > > Does /var/log/ipaclient-install.log contain any additional information > when things fail? > > rob > > On a whole host of 5.8 boxes. I'm 99.9% sure the ipaclient-install.log didn't throw up anything I hadn't seen running the installer in debug mode and then mentioned in the original e-mail but I'll double check that when I'm in the office on Monday. Dmitri, I'll triple check the date/timezone settings. I know the times match using the date command, but I haven't checked inside the localtime and clock files, all our servers should be set to UTC someone is getting fired out of a cannon if I find one that isn't. It's worth mentioning that we don't use the ntp function of the IPA server as we're running them inside VMs. All servers get there time from elsewhere. -------------- next part -------------- An HTML attachment was scrubbed... URL: From shelltoesuperstar at gmail.com Sat Feb 16 13:31:58 2013 From: shelltoesuperstar at gmail.com (Charlie Derwent) Date: Sat, 16 Feb 2013 13:31:58 +0000 Subject: [Freeipa-users] Non-human users In-Reply-To: References: <511E6419.4080402@cora.nwra.com> <511E662A.7010307@redhat.com> <511E7128.1090804@cora.nwra.com> <511E75C6.9020708@redhat.com> <511E7C66.907@redhat.com> <511E7FCC.3040605@redhat.com> <511E8005.5030107@redhat.com> <511E80A6.5000605@redhat.com> <511E80D2.2050801@cora.nwra.com> <511E833C.6080602@redhat.com> <511E8619.2070808@cora.nwra.com> <1360961172.12328.294.camel@willson.li.ssimo.org> <511EA101.2060505@redhat.com> <511EA143.1000804@cora.nwra.com> <511EA25F.2010606@redhat.com> <511EA593.1010801@cora.nwra.com> <511EA9E7.5070606@redhat.com> <511EAEAF.2080101@cora.nwra.com> <511EB2E1.4060506@redhat.com> <511EB7D8.2060108@redhat.com> <1360969882.12328.315.camel@willson.li.ssimo.org> Message-ID: Bit late to the conversation here, but if you want another example of a quasi-system account within IPA, there is the need for a user to handle automated enrollment/re-enrollment of servers. Charlie On Fri, Feb 15, 2013 at 11:32 PM, Brian Cook wrote: > > On Feb 15, 2013, at 3:11 PM, Simo Sorce wrote: > > On Fri, 2013-02-15 at 17:34 -0500, Dmitri Pal wrote: > > On 02/15/2013 05:12 PM, John Dennis wrote: > > On 02/15/2013 04:54 PM, Orion Poplawski wrote: > > On 02/15/2013 02:34 PM, John Dennis wrote: > > On 02/15/2013 04:16 PM, Orion Poplawski wrote: > > > Hmm, that is the filter in TB for me too, but: > > [15/Feb/2013:11:17:21 -0700] conn=931 op=1 SRCH > base="ou=people,dc=nwra,dc=com" scope=2 > filter="(|(mail=*apache*)(cn=*apache*)(givenName=*apache*)(sn=*apache*))" > > attrs="description notes title sn sn mozillaHomeLocalityName givenName > mozillaHomeState mail mozillaWorkUrl workurl labeledURI o company > mozillaNickname mozillaNickname mobile cellphone carphone > modifyTimestamp > nsAIMid nsAIMid telephoneNumber birthyear c c mozillaHomeStreet cn cn > postalCode zip mozillaCustom1 custom1 mozillaHomeCountryName > homePhone st > region mozillaCustom2 custom2 mozillaSecondEmail mozillaSecondEmail > facsimileTelephoneNumber facsimileTelephoneNumber mozillaCustom3 > custom3 > mozillaUseHtmlMail mozillaUseHtmlMail mozillaHomeStreet2 birthday > street > street postOfficeBox mozillaCustom4 custom4 mozillaHomeUrl homeurl > l l pager > pagerphone ou department departmentNumber orgunit birthmonth > mozillaWorkStreet2 mozillaHomePostalCode objectClass" > > is what I see in the LDAP server log > > > I don't know, beats me as to why there is no objectclass filter > component. > Perhaps TB is smart enough to know (objectclass=*) is effectively a > no-op and > ignores it when it builds the final filter. > > What happens if you set the TB filter to (objectclass=person)? > > > Yup, then it adds it: > > > > filter="(&(objectClass=person)(|(mail=*apac*)(cn=*apac*)(givenName=*apac*)(sn=*apac*)))" > > > > O.K. I presume it's obvious the consequence of this little experiment > is that if we do an an RFE that results in removing the person > objectclass from non-human users you'll have to configure a custom > LDAP search filter in every client in your enterprise if you don't > want them to see non-human users in their search results. > > Can it be managed via Puppet? > > > Unlikely, thunderbird preferences are per user and stored in user > preference files, which cannot be arbitrarily overridden. > > > Following URL details a deployment method that configures thunderbird for > address book in AD with a custom search string. Maybe you can use it or it > will inspire you as to how to accomplish your deployment. > > http://wpkg.org/Thunderbird#System-wide > > > 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 > > > > _______________________________________________ > 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 rmercer at harris.com Sat Feb 16 17:14:48 2013 From: rmercer at harris.com (Mercer, Rodney) Date: Sat, 16 Feb 2013 17:14:48 +0000 Subject: [Freeipa-users] RHEL6 IPA and Active Directory synchronisation and Solaris RBAC In-Reply-To: <511F6D98.30700@nixtra.com> References: <511BACEE.8050900@redhat.com> <511D2541.1000201@nixtra.com> <511D2CAC.6050400@redhat.com> <511D4693.8010502@redhat.com> <1360937840.21935.556.camel@osc145.evn.harris.com> <511EA93C.8060909@redhat.com>,<511F6D98.30700@nixtra.com> Message-ID: <512A3AF8DAE8454D95C05141F746ECE1512AC316@MLBMXUS21.cs.myharris.net> ________________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Sigbjorn Lie [sigbjorn at nixtra.com] Sent: Saturday, February 16, 2013 6:29 AM To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] RHEL6 IPA and Active Directory synchronisation and Solaris RBAC On 02/15/2013 10:31 PM, Dmitri Pal wrote: > On 02/15/2013 09:17 AM, Rodney L. Mercer wrote: >> >> On Thu, 2013-02-14 at 21:44 +0100, Sigbjorn Lie wrote: >>> I agree with schema support being enough for now. I do not expect the >>> ipa mgmt tools to support Solaris rbac mgmt. >>> >>> The ipa mgmt tools are great, but I already have other data in the ipa >>> ldap that I have to manage manually anyway. >>> >>> >>> >>> Rgds, >>> Siggi >>> >>> >>> >>> Rob Crittenden wrote: >>> Dag Wieers wrote: >>> On Thu, 14 Feb 2013, Rob Crittenden wrote: >>> >>> Sigbjorn Lie wrote: >>> On 02/13/2013 04:10 PM, Rob Crittenden wrote: >>> >>> Also since we also require compatibility with Solaris, and roles >>> (RBAC) >>> is currently used on Solaris, does IPA support RBAC on Solar >>> is ? >>> (We >>> noticed that RBAC mentioned in the IPA web interface only >>> relates to > > IPA >>> management). >>> No, IPA doesn't support RBAC on Solaris. >>> >>> I've come across the same issue. This is just a matter of extending the >>> schema. >>> >>> Would there be any interest for adding the Solaris RBAC schema as a >>> part >>> of the standard IPA distributed LDAP schema? >> >> Consider the following: What else would have to be put in to support >> this? >> Once the schema is established, can SSSD be extended to use this and >> potentially be referenced in nsswitch.conf as it is implemented on >> Solaris? IE: >> tail -5 /etc/nsswitch.conf >> user_attr: sssd >> auth_attr: sssd >> prof_attr: sssd >> exec_attr: sssd >> project: sssd > > Before we define how it is passed/exposed it would nice to understand > who on Linux will be consuming it out of SSSD? > I don't think Linux would consume these attributes. They are specific to the Role Based Access Control solution implemented in Solaris. Rgds, Siggi ---------------------------------- Yes, I understand that Linux has no mechanism currently built in to consume these Solaris name server switch attributes. But, If the Solaris RBAC schema is included as part of the standard IPA distributed LDAP schema, My question is how hard would it be to create an extension using SSSD/pam to do so? I agree that it is too much to ask for a full Solaris style RBAC implementation on RHEL. We have an application that currently uses the Solaris RBAC structure to authorize user/role accesses within the application. Our goal is to use existing OS calls or possibly extending SSSD to allow system calls that would give us back an answer to attrbutes placed within the LDAP tree that are composed in like fashion as how they are stored in Solaris. Defining the schema seemed to be well received and I understand that it is intended that it would be there to support Solaris clients. If SSSD could be extended to access these attributes and possibly pam modules to allow Linux clients to take advantage of this RBAC schema, then our application could perform as it does on Solaris. It would also open up the opportunity for other vendors to consider moving their Solaris RBAC applications to RHEL. I think with that as a goal, we could then create users and SELinux roles that are defined within the RBAC based schema much like our current Solaris implementation. We use Solaris nsswitch calls to get yes/no authorization answers for user/role privilege within our application. Since IdM and SSD already support a) HBAC b) SUDO c) SELinux user mapping I believe HBAC as already implemented in IdM will be an additional asset in defining and restricting access that can be used by our customers. We have decided to move away from sudo, but may reconsider some of its uses if it suits the situation. Maybe SSSD can be extended to access the RBAC schema in much the same way that it accesses SUDO or HBAC schema? We have decided to use RHEL as the primary OS platform of choice going forward and we need to create a solution to our application RBAC needs similar to that in which we have accomplished with Solaris. I have been speaking with Dmitri on the side about these possibilities and would like to know what each of your thoughts are. The feasibility of accomplishing this is a bit over my head but is certainly our goal. I believe our management is committed to creating such a solution by involving our software engineers. Helping with adding the Solaris RBAC schema and contributing the GUI to manage the RBAC Schema data would be a goal. Also, since this is not the SSSD development list, I would like to know the list info for SSSD development and see what their thoughts are. Dmitri to answer your questions directly to me: Certainly we can discuss additional security components such as centrally managed SSH keys and host fingerprints. We don't need any interaction within our application to include AD, but our customers may want to take advantage of that at some point. From dpal at redhat.com Sun Feb 17 18:31:05 2013 From: dpal at redhat.com (Dmitri Pal) Date: Sun, 17 Feb 2013 13:31:05 -0500 Subject: [Freeipa-users] RHEL6 IPA and Active Directory synchronisation and Solaris RBAC In-Reply-To: <512A3AF8DAE8454D95C05141F746ECE1512AC316@MLBMXUS21.cs.myharris.net> References: <511BACEE.8050900@redhat.com> <511D2541.1000201@nixtra.com> <511D2CAC.6050400@redhat.com> <511D4693.8010502@redhat.com> <1360937840.21935.556.camel@osc145.evn.harris.com> <511EA93C.8060909@redhat.com>, <511F6D98.30700@nixtra.com> <512A3AF8DAE8454D95C05141F746ECE1512AC316@MLBMXUS21.cs.myharris.net> Message-ID: <512121E9.2050608@redhat.com> On 02/16/2013 12:14 PM, Mercer, Rodney wrote: > ________________________________________ > From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Sigbjorn Lie [sigbjorn at nixtra.com] > Sent: Saturday, February 16, 2013 6:29 AM > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] RHEL6 IPA and Active Directory synchronisation and Solaris RBAC > > On 02/15/2013 10:31 PM, Dmitri Pal wrote: >> On 02/15/2013 09:17 AM, Rodney L. Mercer wrote: >>> On Thu, 2013-02-14 at 21:44 +0100, Sigbjorn Lie wrote: >>>> I agree with schema support being enough for now. I do not expect the >>>> ipa mgmt tools to support Solaris rbac mgmt. >>>> >>>> The ipa mgmt tools are great, but I already have other data in the ipa >>>> ldap that I have to manage manually anyway. >>>> >>>> >>>> >>>> Rgds, >>>> Siggi >>>> >>>> >>>> >>>> Rob Crittenden wrote: >>>> Dag Wieers wrote: >>>> On Thu, 14 Feb 2013, Rob Crittenden wrote: >>>> >>>> Sigbjorn Lie wrote: >>>> On 02/13/2013 04:10 PM, Rob Crittenden wrote: >>>> >>>> Also since we also require compatibility with Solaris, and roles >>>> (RBAC) >>>> is currently used on Solaris, does IPA support RBAC on Solar >>>> is ? >>>> (We >>>> noticed that RBAC mentioned in the IPA web interface only >>>> relates to > > IPA >>>> management). >>>> No, IPA doesn't support RBAC on Solaris. >>>> >>>> I've come across the same issue. This is just a matter of extending the >>>> schema. >>>> >>>> Would there be any interest for adding the Solaris RBAC schema as a >>>> part >>>> of the standard IPA distributed LDAP schema? >>> Consider the following: What else would have to be put in to support >>> this? >>> Once the schema is established, can SSSD be extended to use this and >>> potentially be referenced in nsswitch.conf as it is implemented on >>> Solaris? IE: >>> tail -5 /etc/nsswitch.conf >>> user_attr: sssd >>> auth_attr: sssd >>> prof_attr: sssd >>> exec_attr: sssd >>> project: sssd >> Before we define how it is passed/exposed it would nice to understand >> who on Linux will be consuming it out of SSSD? >> > I don't think Linux would consume these attributes. They are specific to > the Role Based Access Control solution implemented in Solaris. > > > Rgds, > Siggi > > ---------------------------------- > > Yes, I understand that Linux has no mechanism currently built in to consume these Solaris name server switch attributes. But, If the Solaris RBAC schema is included as > part of the standard IPA distributed LDAP schema, My question is how hard would it be to create an extension using SSSD/pam to do so? > > I agree that it is too much to ask for a full Solaris style RBAC implementation on RHEL. > > We have an application that currently uses the Solaris RBAC structure to authorize user/role accesses within the application. > > Our goal is to use existing OS calls or possibly extending SSSD to allow system calls that would give us back an answer to attrbutes placed within the LDAP > tree that are composed in like fashion as how they are stored in Solaris. Defining the schema seemed to be well received and I understand that it is intended that it would be there to support Solaris clients. > If SSSD could be extended to access these attributes and possibly pam modules to allow Linux clients to take advantage of this RBAC schema, then our application could perform as it does on Solaris. It would also > open up the opportunity for other vendors to consider moving their Solaris RBAC applications to RHEL. > > I think with that as a goal, we could then create users and SELinux roles that are defined within the RBAC based schema much like our current Solaris implementation. > We use Solaris nsswitch calls to get yes/no authorization answers for user/role privilege within our application. > > Since IdM and SSD already support > a) HBAC > b) SUDO > c) SELinux user mapping > > I believe HBAC as already implemented in IdM will be an additional asset in defining and restricting access that can be used by our customers. > We have decided to move away from sudo, but may reconsider some of its uses if it suits the situation. > Maybe SSSD can be extended to access the RBAC schema in much the same way that it accesses SUDO or HBAC schema? > > We have decided to use RHEL as the primary OS platform of choice going forward and we need to create a solution to our application RBAC > needs similar to that in which we have accomplished with Solaris. I have been speaking with Dmitri on the side about these possibilities and would like to know > what each of your thoughts are. The feasibility of accomplishing this is a bit over my head but is certainly our goal. > I believe our management is committed to creating such a solution by involving our software engineers. Helping with adding the Solaris RBAC schema and > contributing the GUI to manage the RBAC Schema data would be a goal. > > Also, since this is not the SSSD development list, I would like to know the list info for SSSD development and see what their thoughts are. > > Dmitri to answer your questions directly to me: > Certainly we can discuss additional security components such as centrally managed SSH keys and host fingerprints. We don't need any interaction within our application to include AD, > but our customers may want to take advantage of that at some point. The sssd user list is sssd-users at lists.fedorahosted.org The devel list is sssd-devel at lists.fedorahosted.org But I suggest we continue this conversation here because otherwise the conversation might fork and I would be hard to track. Most of the SSSD developers read this list too. Since you have a clearly defined interface your application consumes from Solaris the best thing now would be for you to provide a man page style description of the calls the application needs and we will see how to satisfy them with what we have and identify what needs to be added. IMO such interface would be a requirement list. How we deliver it to the application is an important but yes an implementation detail that we can discuss after we know what requirements are. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rajnesh.siwal at gmail.com Sun Feb 17 19:05:29 2013 From: rajnesh.siwal at gmail.com (Rajnesh Kumar Siwal) Date: Mon, 18 Feb 2013 00:35:29 +0530 Subject: [Freeipa-users] permissions of the user uid=sudo, cn=sysaccounts, cn=etc, dc=example, dc=com Message-ID: Please guide us about the LDAP user "uid=sudo,cn=sysaccounts,cn=etc,dc=example,dc=com". Does it has a read only access or read-write access to the "uid=sudo,cn=sysaccounts,cn=etc,dc=example,dc=com" ? Because the file /etc/ldap.conf is readable by all the users, so I am concerned about the security. -- Regards, Rajnesh Kumar Siwal From simo at redhat.com Sun Feb 17 19:37:57 2013 From: simo at redhat.com (Simo Sorce) Date: Sun, 17 Feb 2013 14:37:57 -0500 Subject: [Freeipa-users] Non-human users In-Reply-To: References: <511E6419.4080402@cora.nwra.com> <511E662A.7010307@redhat.com> <511E7128.1090804@cora.nwra.com> <511E75C6.9020708@redhat.com> <511E7C66.907@redhat.com> <511E7FCC.3040605@redhat.com> <511E8005.5030107@redhat.com> <511E80A6.5000605@redhat.com> <511E80D2.2050801@cora.nwra.com> <511E833C.6080602@redhat.com> <511E8619.2070808@cora.nwra.com> <1360961172.12328.294.camel@willson.li.ssimo.org> <511EA101.2060505@redhat.com> <511EA143.1000804@cora.nwra.com> <511EA25F.2010606@redhat.com> <511EA593.1010801@cora.nwra.com> <511EA9E7.5070606@redhat.com> <511EAEAF.2080101@cora.nwra.com> <511EB2E1.4060506@redhat.com> <511EB7D8.2060108@redhat.com> <1360969882.12328.315.camel@willson.li.ssimo.org> Message-ID: <1361129877.12328.325.camel@willson.li.ssimo.org> On Sat, 2013-02-16 at 13:31 +0000, Charlie Derwent wrote: > > > Bit late to the conversation here, but if you want another example of > a > quasi-system account within IPA, there is the need for a user to > handle > automated enrollment/re-enrollment of servers. > > Charlie > For this we should be able to use a service principal, not a full account. Unless for some reason you need this principal to show up as a user in the system (full posixAccount). Simo. -- Simo Sorce * Red Hat, Inc * New York From janfrode at tanso.net Sun Feb 17 20:10:42 2013 From: janfrode at tanso.net (Jan-Frode Myklebust) Date: Sun, 17 Feb 2013 21:10:42 +0100 Subject: [Freeipa-users] missing member in group Message-ID: <20130217201042.GA5121@dibs.tanso.net> I have the following sssd backend: ------------------------------------------------------------ domains = IPALDAP [domain/IPALDAP] id_provider = ldap auth_provider = ldap ldap_schema = IPA ldap_uri = ldap://ipa1.example.net, ldap://ipa2.example.net ldap_search_base = dc=example,dc=net ldap_user_search_base = cn=users,cn=accounts,dc=example,dc=net ldap_netgroup_search_base = cn=ng,cn=compat,dc=example,dc=net ldap_tls_cacert = /etc/ipa/ca.crt ldap_tls_reqcert = demand cache_credentials = false enumerate = true debug_level = 5 ------------------------------------------------------------ Why isn't "emilb" a member of the systemagic group??? # getent group|grep systema systemagic:*:10031:johanl,martinh # ldapsearch -x -h ipa1.example.net -b cn=accounts,dc=example,dc=net # cn=systemagic # extended LDIF # # LDAPv3 # base with scope subtree # filter: cn=systemagic # requesting: ALL # # systemagic, groups, accounts, example.net dn: cn=systemagic,cn=groups,cn=accounts,dc=example,dc=net objectClass: ipaobject objectClass: top objectClass: groupofuniquenames objectClass: ipausergroup objectClass: posixgroup objectClass: groupofnames objectClass: nestedgroup memberUid: susannek memberUid: martinh memberUid: johanl gidNumber: 10031 cn: systemagic ipaUniqueID: 329e0b6e-9ec5-11e1-8777-525400b94ff0 member: uid=johanl,cn=users,cn=accounts,dc=example,dc=net member: uid=martinh,cn=users,cn=accounts,dc=example,dc=net member: uid=emilb,cn=users,cn=accounts,dc=example,dc=net # search result search: 2 result: 0 Success -jf From dpal at redhat.com Sun Feb 17 20:13:38 2013 From: dpal at redhat.com (Dmitri Pal) Date: Sun, 17 Feb 2013 15:13:38 -0500 Subject: [Freeipa-users] Non-human users In-Reply-To: <1361129877.12328.325.camel@willson.li.ssimo.org> References: <511E6419.4080402@cora.nwra.com> <511E662A.7010307@redhat.com> <511E7128.1090804@cora.nwra.com> <511E75C6.9020708@redhat.com> <511E7C66.907@redhat.com> <511E7FCC.3040605@redhat.com> <511E8005.5030107@redhat.com> <511E80A6.5000605@redhat.com> <511E80D2.2050801@cora.nwra.com> <511E833C.6080602@redhat.com> <511E8619.2070808@cora.nwra.com> <1360961172.12328.294.camel@willson.li.ssimo.org> <511EA101.2060505@redhat.com> <511EA143.1000804@cora.nwra.com> <511EA25F.2010606@redhat.com> <511EA593.1010801@cora.nwra.com> <511EA9E7.5070606@redhat.com> <511EAEAF.2080101@cora.nwra.com> <511EB2E1.4060506@redhat.com> <511EB7D8.2060108@redhat.com> <1360969882.12328.315.camel@willson.li.ssimo.org> <1361129877.12328.325.camel@willson.li.ssimo.org> Message-ID: <512139F2.7080605@redhat.com> On 02/17/2013 02:37 PM, Simo Sorce wrote: > On Sat, 2013-02-16 at 13:31 +0000, Charlie Derwent wrote: >> >> Bit late to the conversation here, but if you want another example of >> a >> quasi-system account within IPA, there is the need for a user to >> handle >> automated enrollment/re-enrollment of servers. >> >> Charlie >> > For this we should be able to use a service principal, not a full > account. Unless for some reason you need this principal to show up as a > user in the system (full posixAccount). > > Simo. > I do not think we have any permission setup in IPA for a service account to perform any modification operations. It can be host account though and we have permission mechanisms built into IdM to allow a host (provisioning system or hypervisor) manage other hosts and services running on them. It should be in the docs. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Sun Feb 17 20:23:22 2013 From: dpal at redhat.com (Dmitri Pal) Date: Sun, 17 Feb 2013 15:23:22 -0500 Subject: [Freeipa-users] missing member in group In-Reply-To: <20130217201042.GA5121@dibs.tanso.net> References: <20130217201042.GA5121@dibs.tanso.net> Message-ID: <51213C3A.3020102@redhat.com> On 02/17/2013 03:10 PM, Jan-Frode Myklebust wrote: > I have the following sssd backend: > > ------------------------------------------------------------ > > domains = IPALDAP > > [domain/IPALDAP] > id_provider = ldap > auth_provider = ldap > ldap_schema = IPA > ldap_uri = ldap://ipa1.example.net, ldap://ipa2.example.net > ldap_search_base = dc=example,dc=net > ldap_user_search_base = cn=users,cn=accounts,dc=example,dc=net > ldap_netgroup_search_base = cn=ng,cn=compat,dc=example,dc=net > ldap_tls_cacert = /etc/ipa/ca.crt > ldap_tls_reqcert = demand > cache_credentials = false > enumerate = true > debug_level = 5 > ------------------------------------------------------------ > > Why isn't "emilb" a member of the systemagic group??? > > # getent group|grep systema > systemagic:*:10031:johanl,martinh > > > # ldapsearch -x -h ipa1.example.net -b cn=accounts,dc=example,dc=net > # cn=systemagic > # extended LDIF > # > # LDAPv3 > # base with scope subtree > # filter: cn=systemagic > # requesting: ALL > # > > # systemagic, groups, accounts, example.net > dn: cn=systemagic,cn=groups,cn=accounts,dc=example,dc=net > objectClass: ipaobject > objectClass: top > objectClass: groupofuniquenames > objectClass: ipausergroup > objectClass: posixgroup > objectClass: groupofnames > objectClass: nestedgroup > memberUid: susannek > memberUid: martinh > memberUid: johanl > gidNumber: 10031 > cn: systemagic > ipaUniqueID: 329e0b6e-9ec5-11e1-8777-525400b94ff0 > member: uid=johanl,cn=users,cn=accounts,dc=example,dc=net > member: uid=martinh,cn=users,cn=accounts,dc=example,dc=net > member: uid=emilb,cn=users,cn=accounts,dc=example,dc=net > > # search result > search: 2 > result: 0 Success 1) What versions you have? 2) Do you need enumeration to be turned on? We recommend it off unless very specific use cases. 3) Can you turn on debug level on SSSD to 9 and search debug logs /var/log/sssd and see what happens to this group? I suspect it is either bug that might have been fixed or the group is filtered for some reason. > > > -jf > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From janfrode at tanso.net Sun Feb 17 20:48:10 2013 From: janfrode at tanso.net (Jan-Frode Myklebust) Date: Sun, 17 Feb 2013 21:48:10 +0100 Subject: [Freeipa-users] missing member in group In-Reply-To: <51213C3A.3020102@redhat.com> References: <20130217201042.GA5121@dibs.tanso.net> <51213C3A.3020102@redhat.com> Message-ID: <20130217204810.GA5277@dibs.tanso.net> On Sun, Feb 17, 2013 at 03:23:22PM -0500, Dmitri Pal wrote: > 1) What versions you have? Running RHEL 6.3 server (ipa-server-2.2.0-17.el6_3.1.x86_64) and various RHEL4, 5, 6 clients. > 2) Do you need enumeration to be turned on? > We recommend it off unless very specific use cases. Maybe not. Am just used to having it on with the previous LDAP backend. Turned it off now, and that hides the problem, as now getent group $groupname lists no member :-) > > 3) Can you turn on debug level on SSSD to 9 and search debug logs > /var/log/sssd and see what happens to this group? > I suspect it is either bug that might have been fixed or the group is > filtered for some reason. Whoha.. loglevel=9 gave quite a bit of output. This one looks interesting: (Sun Feb 17 21:40:07 2013) [sssd[be[IPALDAP]]] [sdap_fill_memberships] (7): member #2 (uid=emilb,cn=users,cn=accounts,dc=example,dc=net): not found! But why it can't find him I don't understand: [root at ldapm1 sssd]# ldapsearch -x -h ipa1.example.net -b uid=emilb,cn=users,cn=accounts,dc=example,dc=net # extended LDIF # # LDAPv3 # base with scope subtree # filter: (objectclass=*) # requesting: ALL # # emilb, users, accounts, example.net dn: uid=emilb,cn=users,cn=accounts,dc=example,dc=net krbLoginFailedCount: 1 krbLastFailedAuth: 20130217201648Z cn: emilb objectClass: krbticketpolicyaux objectClass: ipaobject objectClass: organizationalperson objectClass: top objectClass: inetorgperson objectClass: person objectClass: inetuser objectClass: krbprincipalaux objectClass: posixgroup objectClass: posixaccount loginShell: /bin/bash uidNumber: 15567 gidNumber: 15567 gecos:: RW1pbCBCb3N0csO2bQ== sn:: Qm9zdHLDtm0= homeDirectory: /home/emilb mail: emil.bostrom at example.no krbPrincipalName: emilb at EXAMPLE.NET givenName: Emil uid: emilb ipaUniqueID: b340ce78-784a-11e2-9ee1-525400b94ff0 # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 This user was migrated saturday, using: ipa migrate-ds --user-ignore-objectclass=ldapPublic Key --user-ignore-attribute=sshPublicKey --user-container=ou=People --group-cont ou=Groups ldap://sim1.example.net:389 --with-compat I don't know what --with-compat does, but it migrate-ds seemed to require it this time. Earlier migrations hasn't needed it.. -jf From janfrode at tanso.net Sun Feb 17 20:55:46 2013 From: janfrode at tanso.net (Jan-Frode Myklebust) Date: Sun, 17 Feb 2013 21:55:46 +0100 Subject: [Freeipa-users] missing member in group In-Reply-To: <20130217204810.GA5277@dibs.tanso.net> References: <20130217201042.GA5121@dibs.tanso.net> <51213C3A.3020102@redhat.com> <20130217204810.GA5277@dibs.tanso.net> Message-ID: <20130217205546.GA5342@dibs.tanso.net> On Sun, Feb 17, 2013 at 09:48:10PM +0100, Jan-Frode Myklebust wrote: > > (Sun Feb 17 21:40:07 2013) [sssd[be[IPALDAP]]] [sdap_fill_memberships] (7): member #2 (uid=emilb,cn=users,cn=accounts,dc=example,dc=net): not found! > > > This user was migrated saturday, using: > > ipa migrate-ds --user-ignore-objectclass=ldapPublic Key --user-ignore-attribute=sshPublicKey --user-container=ou=People --group-cont ou=Groups ldap://sim1.example.net:389 --with-compat > > I don't know what --with-compat does, but it migrate-ds seemed to require it > this time. Earlier migrations hasn't needed it.. > I see now that all the users I migrated saturday are logged as "not found!". Maybe they need to log in and get fully migrated before they show up in the groups? (We're running IPA in migration mode). -jf From dpal at redhat.com Mon Feb 18 05:16:33 2013 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 18 Feb 2013 00:16:33 -0500 Subject: [Freeipa-users] missing member in group In-Reply-To: <20130217205546.GA5342@dibs.tanso.net> References: <20130217201042.GA5121@dibs.tanso.net> <51213C3A.3020102@redhat.com> <20130217204810.GA5277@dibs.tanso.net> <20130217205546.GA5342@dibs.tanso.net> Message-ID: <5121B931.6070802@redhat.com> On 02/17/2013 03:55 PM, Jan-Frode Myklebust wrote: > On Sun, Feb 17, 2013 at 09:48:10PM +0100, Jan-Frode Myklebust wrote: >> (Sun Feb 17 21:40:07 2013) [sssd[be[IPALDAP]]] [sdap_fill_memberships] (7): member #2 (uid=emilb,cn=users,cn=accounts,dc=example,dc=net): not found! >> > > >> This user was migrated saturday, using: >> >> ipa migrate-ds --user-ignore-objectclass=ldapPublic Key --user-ignore-attribute=sshPublicKey --user-container=ou=People --group-cont ou=Groups ldap://sim1.example.net:389 --with-compat >> >> I don't know what --with-compat does, but it migrate-ds seemed to require it >> this time. Earlier migrations hasn't needed it.. >> > I see now that all the users I migrated saturday are logged as "not > found!". Maybe they need to log in and get fully migrated before they > show up in the groups? (We're running IPA in migration mode). > > > -jf Please do the ldap search of the user and post it here. I bet some attribute or object class is missing. But SSSD should see users that are just migrated. Did you use migrate-ds or loaded LDIF manually? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From pspacek at redhat.com Mon Feb 18 08:41:21 2013 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 18 Feb 2013 09:41:21 +0100 Subject: [Freeipa-users] permissions of the user uid=sudo, cn=sysaccounts, cn=etc, dc=example, dc=com In-Reply-To: References: Message-ID: <5121E931.9030006@redhat.com> On 17.2.2013 20:05, Rajnesh Kumar Siwal wrote: > Please guide us about the LDAP user > "uid=sudo,cn=sysaccounts,cn=etc,dc=example,dc=com". > Does it has a read only access or read-write access to the > "uid=sudo,cn=sysaccounts,cn=etc,dc=example,dc=com" ? > Because the file /etc/ldap.conf is readable by all the users, so I am > concerned about the security. You can get effective access rights for any DN: Command example: /usr/lib64/mozldap/ldapsearch -D "cn=directory manager" -w secret -p 389 -h server.example.com -b "dc=example,dc=com" -s sub -J 1.3.6.1.4.1.42.2.27.9.5.2:true:dn:uid=sudo,cn=sysaccounts,cn=etc,dc=example,dc=com "(objectclass=*)" Example was taken from section 8.4.11: https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Examples-of-common-ldapsearches.html Effective access rights description: https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Viewing_the_ACIs_for_an_Entry-Get_Effective_Rights_Control.html -- Petr^2 Spacek From mkosek at redhat.com Mon Feb 18 08:56:53 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 18 Feb 2013 09:56:53 +0100 Subject: [Freeipa-users] Use of LOCAL clock in ntpd configuration In-Reply-To: References: Message-ID: <5121ECD5.7040303@redhat.com> On 02/15/2013 07:23 PM, Chuck Lever wrote: ... > (I also note that "ipa-client-install" does not disable chronyd, but I've only tried the client install script on Fedora 16). > Hello Chuck, I would just like to comment that we address chronyd/ntpd in FreeIPA in Fedora 18. We do check if chronyd is already installed and when you do ipa-server-install, we warn user and disable it later so that we can deploy the ntpd service. When installing IPA on client and chronyd is configured, we let it configured and do not deploy ntpd unless you use --force-ntpd flag. Martin From jhrozek at redhat.com Mon Feb 18 09:13:54 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 18 Feb 2013 10:13:54 +0100 Subject: [Freeipa-users] missing member in group In-Reply-To: <5121B931.6070802@redhat.com> References: <20130217201042.GA5121@dibs.tanso.net> <51213C3A.3020102@redhat.com> <20130217204810.GA5277@dibs.tanso.net> <20130217205546.GA5342@dibs.tanso.net> <5121B931.6070802@redhat.com> Message-ID: <20130218091354.GE13206@hendrix.brq.redhat.com> On Mon, Feb 18, 2013 at 12:16:33AM -0500, Dmitri Pal wrote: > On 02/17/2013 03:55 PM, Jan-Frode Myklebust wrote: > > On Sun, Feb 17, 2013 at 09:48:10PM +0100, Jan-Frode Myklebust wrote: > >> (Sun Feb 17 21:40:07 2013) [sssd[be[IPALDAP]]] [sdap_fill_memberships] (7): member #2 (uid=emilb,cn=users,cn=accounts,dc=example,dc=net): not found! > >> > > > > > >> This user was migrated saturday, using: > >> > >> ipa migrate-ds --user-ignore-objectclass=ldapPublic Key --user-ignore-attribute=sshPublicKey --user-container=ou=People --group-cont ou=Groups ldap://sim1.example.net:389 --with-compat > >> > >> I don't know what --with-compat does, but it migrate-ds seemed to require it > >> this time. Earlier migrations hasn't needed it.. > >> > > I see now that all the users I migrated saturday are logged as "not > > found!". Maybe they need to log in and get fully migrated before they > > show up in the groups? (We're running IPA in migration mode). > > > > > > -jf > Please do the ldap search of the user and post it here. > I bet some attribute or object class is missing. > But SSSD should see users that are just migrated. > Did you use migrate-ds or loaded LDIF manually? Are only the users you migrated not showing up? Does getent passwd emilb work? Given that you explicitly configured cache_credentials=false can you log in (to verify SSSD is able to correctly connect to the remote server) ? From rcritten at redhat.com Mon Feb 18 14:47:55 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 18 Feb 2013 09:47:55 -0500 Subject: [Freeipa-users] permissions of the user uid=sudo, cn=sysaccounts, cn=etc, dc=example, dc=com In-Reply-To: <5121E931.9030006@redhat.com> References: <5121E931.9030006@redhat.com> Message-ID: <51223F1B.9060501@redhat.com> Petr Spacek wrote: > On 17.2.2013 20:05, Rajnesh Kumar Siwal wrote: >> Please guide us about the LDAP user >> "uid=sudo,cn=sysaccounts,cn=etc,dc=example,dc=com". >> Does it has a read only access or read-write access to the >> "uid=sudo,cn=sysaccounts,cn=etc,dc=example,dc=com" ? >> Because the file /etc/ldap.conf is readable by all the users, so I am >> concerned about the security. > > You can get effective access rights for any DN: > > Command example: > /usr/lib64/mozldap/ldapsearch -D "cn=directory manager" -w secret -p 389 > -h server.example.com -b "dc=example,dc=com" -s sub -J > 1.3.6.1.4.1.42.2.27.9.5.2:true:dn:uid=sudo,cn=sysaccounts,cn=etc,dc=example,dc=com > "(objectclass=*)" > > Example was taken from section 8.4.11: > https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Examples-of-common-ldapsearches.html > > > Effective access rights description: > https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Viewing_the_ACIs_for_an_Entry-Get_Effective_Rights_Control.html > > You need the ldapsearch from mozldap-tools for this to work. The user has read-only access to the tree but it has write access to itself (via the self-service rule). rob From john.moyer at digitalreasoning.com Mon Feb 18 14:58:12 2013 From: john.moyer at digitalreasoning.com (John Moyer) Date: Mon, 18 Feb 2013 09:58:12 -0500 Subject: [Freeipa-users] Cannot obtain CA Certificate Message-ID: <80D02259-925A-4529-943F-0ACAD7B77BB3@digitalreasoning.com> Hello all, I am having an issue using IPA 2.2.0. I am trying to put together a proof of concept set of systems. I've stood up 2 servers on AWS. One is the server one is the client. I am using CentOS 6 to do all this testing on, with the default IPA packages provided from CentOS. I had a fully operational proof of concept finished fully scripted to be built without issues. I shutdown and started these as needed to show to people to get approval for the project. The other day the client stopped enrolling to the IPA server, I have no idea why I assume a patch pushed out broke something since it is a fully scripted install. It does get the most recent patches each time I stand it up so it definitely would pull any new patches that came out. After investigating I am getting this error when I try to manually enroll the client. I haven't been able to find any reference to this error anywhere on the net. Any help would be greatly appreciated! Let me know if any additional details are needed. PLEASE NOTE: Everything below has been sanitized [root at client ~]# ipa-client-install --domain=example.com --server=ipa1.example.com --realm=EXAMPLE.COM --configure-ssh --configure-sshd -p ipa-bind -w "blah" -U DNS domain 'example.com' is not configured for automatic KDC address lookup. KDC address will be set to fixed value. Discovery was successful! Hostname: client.ec2.internal Realm: EXAMPLE.COM DNS Domain: digitalreasoning.com IPA Server: ipa1.example.com BaseDN: dc=example,dc=com Synchronizing time with KDC... ipa : ERROR Cannot obtain CA certificate 'ldap://ipa1.example.com' doesn't have a certificate. Installation failed. Rolling back changes. IPA client is not configured on this system. Thanks, _____________________________________________________ John Moyer -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Mon Feb 18 15:02:15 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 18 Feb 2013 17:02:15 +0200 Subject: [Freeipa-users] permissions of the user uid=sudo, cn=sysaccounts, cn=etc, dc=example, dc=com In-Reply-To: <51223F1B.9060501@redhat.com> References: <5121E931.9030006@redhat.com> <51223F1B.9060501@redhat.com> Message-ID: <20130218150215.GJ476@redhat.com> On Mon, 18 Feb 2013, Rob Crittenden wrote: >Petr Spacek wrote: >>On 17.2.2013 20:05, Rajnesh Kumar Siwal wrote: >>>Please guide us about the LDAP user >>>"uid=sudo,cn=sysaccounts,cn=etc,dc=example,dc=com". >>>Does it has a read only access or read-write access to the >>>"uid=sudo,cn=sysaccounts,cn=etc,dc=example,dc=com" ? >>>Because the file /etc/ldap.conf is readable by all the users, so I am >>>concerned about the security. >> >>You can get effective access rights for any DN: >> >>Command example: >>/usr/lib64/mozldap/ldapsearch -D "cn=directory manager" -w secret -p 389 >>-h server.example.com -b "dc=example,dc=com" -s sub -J >>1.3.6.1.4.1.42.2.27.9.5.2:true:dn:uid=sudo,cn=sysaccounts,cn=etc,dc=example,dc=com >>"(objectclass=*)" >> >>Example was taken from section 8.4.11: >>https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Examples-of-common-ldapsearches.html >> >> >>Effective access rights description: >>https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Viewing_the_ACIs_for_an_Entry-Get_Effective_Rights_Control.html >> >> > >You need the ldapsearch from mozldap-tools for this to work. > >The user has read-only access to the tree but it has write access to >itself (via the self-service rule). You can use ldapsearch from openldap too: $ ldapsearch -D cn=directory\ manager -w XXXXX -b cn=sysaccounts,cn=etc,dc=ipa,dc=team -s sub -E 1.3.6.1.4.1.42.2.27.9.5.2 uid=sudo # extended LDIF # # LDAPv3 # base with scope subtree # filter: uid=sudo # requesting: ALL # # sudo, sysaccounts, etc, ipa.team dn: uid=sudo,cn=sysaccounts,cn=etc,dc=ipa,dc=team objectClass: account objectClass: simplesecurityobject objectClass: top uid: sudo userPassword:: XXXXXXXXXXXXXXXXXXXXXXXX entryLevelRights: 21 attributeLevelRights: *:21 -- / Alexander Bokovoy From rcritten at redhat.com Mon Feb 18 15:56:34 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 18 Feb 2013 10:56:34 -0500 Subject: [Freeipa-users] permissions of the user uid=sudo, cn=sysaccounts, cn=etc, dc=example, dc=com In-Reply-To: <20130218150215.GJ476@redhat.com> References: <5121E931.9030006@redhat.com> <51223F1B.9060501@redhat.com> <20130218150215.GJ476@redhat.com> Message-ID: <51224F32.3080607@redhat.com> Alexander Bokovoy wrote: > On Mon, 18 Feb 2013, Rob Crittenden wrote: >> Petr Spacek wrote: >>> On 17.2.2013 20:05, Rajnesh Kumar Siwal wrote: >>>> Please guide us about the LDAP user >>>> "uid=sudo,cn=sysaccounts,cn=etc,dc=example,dc=com". >>>> Does it has a read only access or read-write access to the >>>> "uid=sudo,cn=sysaccounts,cn=etc,dc=example,dc=com" ? >>>> Because the file /etc/ldap.conf is readable by all the users, so I am >>>> concerned about the security. >>> >>> You can get effective access rights for any DN: >>> >>> Command example: >>> /usr/lib64/mozldap/ldapsearch -D "cn=directory manager" -w secret -p 389 >>> -h server.example.com -b "dc=example,dc=com" -s sub -J >>> 1.3.6.1.4.1.42.2.27.9.5.2:true:dn:uid=sudo,cn=sysaccounts,cn=etc,dc=example,dc=com >>> >>> "(objectclass=*)" >>> >>> Example was taken from section 8.4.11: >>> https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Examples-of-common-ldapsearches.html >>> >>> >>> >>> Effective access rights description: >>> https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Viewing_the_ACIs_for_an_Entry-Get_Effective_Rights_Control.html >>> >>> >>> >> >> You need the ldapsearch from mozldap-tools for this to work. >> >> The user has read-only access to the tree but it has write access to >> itself (via the self-service rule). > You can use ldapsearch from openldap too: > $ ldapsearch -D cn=directory\ manager -w XXXXX -b > cn=sysaccounts,cn=etc,dc=ipa,dc=team -s sub -E 1.3.6.1.4.1.42.2.27.9.5.2 > uid=sudo > # extended LDIF > # > # LDAPv3 > # base with scope subtree > # filter: uid=sudo > # requesting: ALL > # > > # sudo, sysaccounts, etc, ipa.team > dn: uid=sudo,cn=sysaccounts,cn=etc,dc=ipa,dc=team > objectClass: account > objectClass: simplesecurityobject > objectClass: top > uid: sudo > userPassword:: XXXXXXXXXXXXXXXXXXXXXXXX > entryLevelRights: 21 > attributeLevelRights: *:21 > > The syntax for the control isn't quite right (and in the 2 seconds I looked at it I wasn't able to get it working in openldap ldapsearch). It needs to be set as critical and the DN you are checking the rights for needs to be passed as payload. The result should be a list of attributes and rights. rob From mmercier at gmail.com Mon Feb 18 16:27:21 2013 From: mmercier at gmail.com (Michael Mercier) Date: Mon, 18 Feb 2013 11:27:21 -0500 Subject: [Freeipa-users] named crash Message-ID: <9EF03C7E-A7BE-4456-BED2-337E9FAFFFB5@gmail.com> Hello, Named stopped on one of my IPA servers over the weekend, this was the last message in the log file: ldap_helper.c:627: fatal error: RUNTIME_CHECK(((pthread_mutex_destroy(((&ldap_conn->lock))) == 0) ? 0 : 34) == 0) failed exiting (due to fatal error in library) Any ideas? All other IPA services (ipactl status) were shown as running when I checked this morning, the only service stopped was named. IPA on CentOS 6.3: libipa_hbac-1.8.0-32.el6.x86_64 ipa-admintools-2.2.0-17.el6_3.1.x86_64 ipa-pki-ca-theme-9.0.3-7.el6.noarch ipa-python-2.2.0-17.el6_3.1.x86_64 ipa-client-2.2.0-17.el6_3.1.x86_64 ipa-server-2.2.0-17.el6_3.1.x86_64 libipa_hbac-python-1.8.0-32.el6.x86_64 ipa-pki-common-theme-9.0.3-7.el6.noarch python-iniparse-0.3.1-2.1.el6.noarch ipa-server-selinux-2.2.0-17.el6_3.1.x86_64 bind-libs-9.8.2-0.10.rc1.el6_3.6.x86_64 bind-utils-9.8.2-0.10.rc1.el6_3.6.x86_64 bind-dyndb-ldap-1.1.0-0.9.b1.el6_3.1.x86_64 bind-9.8.2-0.10.rc1.el6_3.6.x86_64 Thanks, Mike From janfrode at tanso.net Mon Feb 18 18:21:31 2013 From: janfrode at tanso.net (Jan-Frode Myklebust) Date: Mon, 18 Feb 2013 19:21:31 +0100 Subject: [Freeipa-users] Netgroup domain entry Message-ID: <20130218182131.GA15759@dibs.tanso.net> We have all our servers in two domains, example.com and lab.example.com. But unfortunately it seems IPA (ipa-server-2.2.0-17.el6_3.1.x86_64) populates the automatic host netgroups in the example.com domain both for hostname1.example.com and hostname2.lab.example.com. I.e.: (machinename.lab.example.com, -, example.com) Where is it picking up the domain from? This breaks all netgroup lookups for our lab-servers.. -jf From rcritten at redhat.com Mon Feb 18 18:33:08 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 18 Feb 2013 13:33:08 -0500 Subject: [Freeipa-users] Netgroup domain entry In-Reply-To: <20130218182131.GA15759@dibs.tanso.net> References: <20130218182131.GA15759@dibs.tanso.net> Message-ID: <512273E4.8030401@redhat.com> Jan-Frode Myklebust wrote: > We have all our servers in two domains, example.com and lab.example.com. > But unfortunately it seems IPA (ipa-server-2.2.0-17.el6_3.1.x86_64) > populates the automatic host netgroups in the example.com domain both for > hostname1.example.com and hostname2.lab.example.com. I.e.: > > (machinename.lab.example.com, -, example.com) > > Where is it picking up the domain from? > > This breaks all netgroup lookups for our lab-servers.. nisDomainName is defined in the dc=example,dc=com entry. Currently only one nis domain is supported. It is probably possible to support multiple but it would require hacking on the nis schema compat configuration. rob From janfrode at tanso.net Mon Feb 18 20:02:53 2013 From: janfrode at tanso.net (Jan-Frode Myklebust) Date: Mon, 18 Feb 2013 21:02:53 +0100 Subject: [Freeipa-users] Netgroup domain entry In-Reply-To: <512273E4.8030401@redhat.com> References: <20130218182131.GA15759@dibs.tanso.net> <512273E4.8030401@redhat.com> Message-ID: <20130218200253.GA16177@dibs.tanso.net> On Mon, Feb 18, 2013 at 01:33:08PM -0500, Rob Crittenden wrote: > > nisDomainName is defined in the dc=example,dc=com entry. > > Currently only one nis domain is supported. It is probably possible > to support multiple but it would require hacking on the nis schema > compat configuration. Will it be OK to use "-" for nisdomain ? Or is this used any other places than in the netgroups where "-" might be problematic? -jf From rcritten at redhat.com Mon Feb 18 20:06:39 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 18 Feb 2013 15:06:39 -0500 Subject: [Freeipa-users] Netgroup domain entry In-Reply-To: <20130218200253.GA16177@dibs.tanso.net> References: <20130218182131.GA15759@dibs.tanso.net> <512273E4.8030401@redhat.com> <20130218200253.GA16177@dibs.tanso.net> Message-ID: <512289CF.6050401@redhat.com> Jan-Frode Myklebust wrote: > On Mon, Feb 18, 2013 at 01:33:08PM -0500, Rob Crittenden wrote: >> >> nisDomainName is defined in the dc=example,dc=com entry. >> >> Currently only one nis domain is supported. It is probably possible >> to support multiple but it would require hacking on the nis schema >> compat configuration. > > Will it be OK to use "-" for nisdomain ? Or is this used any other places > than in the netgroups where "-" might be problematic? > It probably depends on how the client matches its NIS domain. It sure seems like a reasonable thing to try. rob From bcook at redhat.com Mon Feb 18 23:58:32 2013 From: bcook at redhat.com (Brian Cook) Date: Mon, 18 Feb 2013 15:58:32 -0800 Subject: [Freeipa-users] trouble with trusts and gssapi Message-ID: <7AABBEBA-0ECF-4960-837C-633B96CB5E22@redhat.com> I am trying to ssh from Windows - > IPA server using GSS-API. I've tried putty, which provides very little debug out. I then downloaded securecrt which provides more output. On the server side, I just see postponed gss-with-mic and then a failure message. I'm attaching the output from securecrt. Any help would be greatly appreciated. Thanks, Brian -------------- next part -------------- A non-text attachment was scrubbed... Name: securecrt-out.rtf Type: text/rtf Size: 5298 bytes Desc: not available URL: From bcook at redhat.com Tue Feb 19 00:06:47 2013 From: bcook at redhat.com (Brian Cook) Date: Mon, 18 Feb 2013 16:06:47 -0800 Subject: [Freeipa-users] trouble with trusts and gssapi In-Reply-To: <7AABBEBA-0ECF-4960-837C-633B96CB5E22@redhat.com> References: <7AABBEBA-0ECF-4960-837C-633B96CB5E22@redhat.com> Message-ID: <6E7BCFC0-C670-41BD-87BF-F46A152F52F6@redhat.com> More info - attached var/log/secure, and sshd_config. Password authentication works, just gssapi fails. in the securecrt provided I have disabled password auth as an option -------------- next part -------------- A non-text attachment was scrubbed... Name: sshd_config.rtf Type: text/rtf Size: 2988 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: var-log-secure.rtf Type: text/rtf Size: 15019 bytes Desc: not available URL: -------------- next part -------------- On Feb 18, 2013, at 3:58 PM, Brian Cook wrote: > I am trying to ssh from Windows - > IPA server using GSS-API. I've tried putty, which provides very little debug out. I then downloaded securecrt which provides more output. > > On the server side, I just see postponed gss-with-mic and then a failure message. I'm attaching the output from securecrt. Any help would be greatly appreciated. > > Thanks, > Brian > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From rendhalver at gmail.com Tue Feb 19 00:24:48 2013 From: rendhalver at gmail.com (Peter Brown) Date: Tue, 19 Feb 2013 10:24:48 +1000 Subject: [Freeipa-users] Cannot obtain CA Certificate In-Reply-To: <80D02259-925A-4529-943F-0ACAD7B77BB3@digitalreasoning.com> References: <80D02259-925A-4529-943F-0ACAD7B77BB3@digitalreasoning.com> Message-ID: Hi John, I ran into a similar issue with setting up a 2.2 client with a 3.1 server. It turned out to be that port 80 wasn't open on the freeipa server. I would check your ports and see if the right ones are open. I also find that setting up the SRV and TXT records in your dns zone makes setting up clients a lot simpler. On 19 February 2013 00:58, John Moyer wrote: > Hello all, > > I am having an issue using IPA 2.2.0. I am trying to put together a > proof of concept set of systems. I've stood up 2 servers on AWS. One is > the server one is the client. I am using CentOS 6 to do all this testing > on, with the default IPA packages provided from CentOS. I had a fully > operational proof of concept finished fully scripted to be built without > issues. I shutdown and started these as needed to show to people to get > approval for the project. The other day the client stopped enrolling to > the IPA server, I have no idea why I assume a patch pushed out broke > something since it is a fully scripted install. It does get the most recent > patches each time I stand it up so it definitely would pull any new patches > that came out. > > After investigating I am getting this error when I try to manually enroll > the client. I haven't been able to find any reference to this error > anywhere on the net. Any help would be greatly appreciated! Let me know > if any additional details are needed. > > > PLEASE NOTE: Everything below has been sanitized > > > [root at client ~]# ipa-client-install --domain=example.com --server= > ipa1.example.com --realm=EXAMPLE.COM --configure-ssh --configure-sshd -p > ipa-bind -w "blah" -U > DNS domain 'example.com' is not configured for automatic KDC address > lookup. > KDC address will be set to fixed value. > > Discovery was successful! > Hostname: client.ec2.internal > Realm: EXAMPLE.COM > DNS Domain: digitalreasoning.com > IPA Server: ipa1.example.com > BaseDN: dc=example,dc=com > > > Synchronizing time with KDC... > > ipa : ERROR Cannot obtain CA certificate > 'ldap://ipa1.example.com' doesn't have a certificate. > Installation failed. Rolling back changes. > IPA client is not configured on this system. > > > Thanks, > _____________________________________________________ > John Moyer > > > > _______________________________________________ > 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 john.moyer at digitalreasoning.com Tue Feb 19 01:03:41 2013 From: john.moyer at digitalreasoning.com (John Moyer) Date: Mon, 18 Feb 2013 20:03:41 -0500 Subject: [Freeipa-users] Cannot obtain CA Certificate In-Reply-To: References: <80D02259-925A-4529-943F-0ACAD7B77BB3@digitalreasoning.com> Message-ID: <717BE6A1-AA0D-44AB-9709-3AF504B37559@digitalreasoning.com> Peter, Thanks for the response, I just checked out my security group settings, I did have some ports blocked, however, allowing them did not help. I installed mmap on the client and did a port scan of the server and got the follow: PORT STATE SERVICE 22/tcp open ssh 53/tcp open domain 80/tcp open http 88/tcp open kerberos-sec 389/tcp open ldap 443/tcp open https 464/tcp open kpasswd5 636/tcp open ldapssl 749/tcp open kerberos-adm I tried to enroll again and got the same error as seen here: Synchronizing time with KDC... ipa : ERROR Cannot obtain CA certificate Thanks, _____________________________________________________ John Moyer On Feb 18, 2013, at 7:24 PM, Peter Brown wrote: > Hi John, > > I ran into a similar issue with setting up a 2.2 client with a 3.1 server. > It turned out to be that port 80 wasn't open on the freeipa server. > I would check your ports and see if the right ones are open. > I also find that setting up the SRV and TXT records in your dns zone makes setting up clients a lot simpler. > > > > On 19 February 2013 00:58, John Moyer wrote: > Hello all, > > I am having an issue using IPA 2.2.0. I am trying to put together a proof of concept set of systems. I've stood up 2 servers on AWS. One is the server one is the client. I am using CentOS 6 to do all this testing on, with the default IPA packages provided from CentOS. I had a fully operational proof of concept finished fully scripted to be built without issues. I shutdown and started these as needed to show to people to get approval for the project. The other day the client stopped enrolling to the IPA server, I have no idea why I assume a patch pushed out broke something since it is a fully scripted install. It does get the most recent patches each time I stand it up so it definitely would pull any new patches that came out. > > After investigating I am getting this error when I try to manually enroll the client. I haven't been able to find any reference to this error anywhere on the net. Any help would be greatly appreciated! Let me know if any additional details are needed. > > > PLEASE NOTE: Everything below has been sanitized > > > [root at client ~]# ipa-client-install --domain=example.com --server=ipa1.example.com --realm=EXAMPLE.COM --configure-ssh --configure-sshd -p ipa-bind -w "blah" -U > DNS domain 'example.com' is not configured for automatic KDC address lookup. > KDC address will be set to fixed value. > > Discovery was successful! > Hostname: client.ec2.internal > Realm: EXAMPLE.COM > DNS Domain: digitalreasoning.com > IPA Server: ipa1.example.com > BaseDN: dc=example,dc=com > > > Synchronizing time with KDC... > > ipa : ERROR Cannot obtain CA certificate > 'ldap://ipa1.example.com' doesn't have a certificate. > Installation failed. Rolling back changes. > IPA client is not configured on this system. > > > Thanks, > _____________________________________________________ > John Moyer > > > > _______________________________________________ > 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 Tue Feb 19 01:28:09 2013 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Tue, 19 Feb 2013 01:28:09 +0000 Subject: [Freeipa-users] Cannot obtain CA Certificate In-Reply-To: <717BE6A1-AA0D-44AB-9709-3AF504B37559@digitalreasoning.com> References: <80D02259-925A-4529-943F-0ACAD7B77BB3@digitalreasoning.com> , <717BE6A1-AA0D-44AB-9709-3AF504B37559@digitalreasoning.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E40710967F3@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, My poor 2 ideas, You could try web browsing to the IPA server to see if the cert is there (wild guess). ~/ipa and see if there is a CA cert you can import. Is the client pointing at the IPA server for its DNS? 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 John Moyer [john.moyer at digitalreasoning.com] Sent: Tuesday, 19 February 2013 2:03 p.m. To: Peter Brown Cc: freeipa-users Subject: Re: [Freeipa-users] Cannot obtain CA Certificate Peter, Thanks for the response, I just checked out my security group settings, I did have some ports blocked, however, allowing them did not help. I installed mmap on the client and did a port scan of the server and got the follow: PORT STATE SERVICE 22/tcp open ssh 53/tcp open domain 80/tcp open http 88/tcp open kerberos-sec 389/tcp open ldap 443/tcp open https 464/tcp open kpasswd5 636/tcp open ldapssl 749/tcp open kerberos-adm I tried to enroll again and got the same error as seen here: Synchronizing time with KDC... ipa : ERROR Cannot obtain CA certificate Thanks, _____________________________________________________ John Moyer On Feb 18, 2013, at 7:24 PM, Peter Brown > wrote: Hi John, I ran into a similar issue with setting up a 2.2 client with a 3.1 server. It turned out to be that port 80 wasn't open on the freeipa server. I would check your ports and see if the right ones are open. I also find that setting up the SRV and TXT records in your dns zone makes setting up clients a lot simpler. On 19 February 2013 00:58, John Moyer > wrote: Hello all, I am having an issue using IPA 2.2.0. I am trying to put together a proof of concept set of systems. I've stood up 2 servers on AWS. One is the server one is the client. I am using CentOS 6 to do all this testing on, with the default IPA packages provided from CentOS. I had a fully operational proof of concept finished fully scripted to be built without issues. I shutdown and started these as needed to show to people to get approval for the project. The other day the client stopped enrolling to the IPA server, I have no idea why I assume a patch pushed out broke something since it is a fully scripted install. It does get the most recent patches each time I stand it up so it definitely would pull any new patches that came out. After investigating I am getting this error when I try to manually enroll the client. I haven't been able to find any reference to this error anywhere on the net. Any help would be greatly appreciated! Let me know if any additional details are needed. PLEASE NOTE: Everything below has been sanitized [root at client ~]# ipa-client-install --domain=example.com --server=ipa1.example.com --realm=EXAMPLE.COM --configure-ssh --configure-sshd -p ipa-bind -w "blah" -U DNS domain 'example.com' is not configured for automatic KDC address lookup. KDC address will be set to fixed value. Discovery was successful! Hostname: client.ec2.internal Realm: EXAMPLE.COM DNS Domain: digitalreasoning.com IPA Server: ipa1.example.com BaseDN: dc=example,dc=com Synchronizing time with KDC... ipa : ERROR Cannot obtain CA certificate 'ldap://ipa1.example.com' doesn't have a certificate. Installation failed. Rolling back changes. IPA client is not configured on this system. Thanks, _____________________________________________________ John Moyer _______________________________________________ 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 rendhalver at gmail.com Tue Feb 19 01:42:45 2013 From: rendhalver at gmail.com (Peter Brown) Date: Tue, 19 Feb 2013 11:42:45 +1000 Subject: [Freeipa-users] Cannot obtain CA Certificate In-Reply-To: <717BE6A1-AA0D-44AB-9709-3AF504B37559@digitalreasoning.com> References: <80D02259-925A-4529-943F-0ACAD7B77BB3@digitalreasoning.com> <717BE6A1-AA0D-44AB-9709-3AF504B37559@digitalreasoning.com> Message-ID: On 19 February 2013 11:03, John Moyer wrote: > Peter, > > Thanks for the response, I just checked out my security group settings, I > did have some ports blocked, however, allowing them did not help. I > installed mmap on the client and did a port scan of the server and got the > follow: > > PORT STATE SERVICE > 22/tcp open ssh > 53/tcp open domain > 80/tcp open http > 88/tcp open kerberos-sec > 389/tcp open ldap > 443/tcp open https > 464/tcp open kpasswd5 > 636/tcp open ldapssl > 749/tcp open kerberos-adm > There is a couple of UDP ports that need to be open as well 464 and 88 from memory. They shouldn't affect your ability to download the ca cert. Have you checked the ipa-client log file? I can't remember where that gets saved right now but it should mention the location when you run the ipa-client command. > I tried to enroll again and got the same error as seen here: > > > Synchronizing time with KDC... > > ipa : ERROR Cannot obtain CA certificate > > > > Thanks, > _____________________________________________________ > John Moyer > > > On Feb 18, 2013, at 7:24 PM, Peter Brown wrote: > > Hi John, > > I ran into a similar issue with setting up a 2.2 client with a 3.1 server. > It turned out to be that port 80 wasn't open on the freeipa server. > I would check your ports and see if the right ones are open. > I also find that setting up the SRV and TXT records in your dns zone makes > setting up clients a lot simpler. > > > > On 19 February 2013 00:58, John Moyer wrote: > >> Hello all, >> >> I am having an issue using IPA 2.2.0. I am trying to put together a >> proof of concept set of systems. I've stood up 2 servers on AWS. One is >> the server one is the client. I am using CentOS 6 to do all this testing >> on, with the default IPA packages provided from CentOS. I had a fully >> operational proof of concept finished fully scripted to be built without >> issues. I shutdown and started these as needed to show to people to get >> approval for the project. The other day the client stopped enrolling to >> the IPA server, I have no idea why I assume a patch pushed out broke >> something since it is a fully scripted install. It does get the most recent >> patches each time I stand it up so it definitely would pull any new patches >> that came out. >> >> After investigating I am getting this error when I try to manually enroll >> the client. I haven't been able to find any reference to this error >> anywhere on the net. Any help would be greatly appreciated! Let me know >> if any additional details are needed. >> >> >> PLEASE NOTE: Everything below has been sanitized >> >> >> [root at client ~]# ipa-client-install --domain=example.com --server= >> ipa1.example.com --realm=EXAMPLE.COM --configure-ssh --configure-sshd -p ipa-bind -w "blah" -U >> DNS domain 'example.com' is not configured for automatic KDC address >> lookup. >> KDC address will be set to fixed value. >> >> Discovery was successful! >> Hostname: client.ec2.internal >> Realm: EXAMPLE.COM >> DNS Domain: digitalreasoning.com >> IPA Server: ipa1.example.com >> BaseDN: dc=example,dc=com >> >> >> Synchronizing time with KDC... >> >> ipa : ERROR Cannot obtain CA certificate >> 'ldap://ipa1.example.com' doesn't have a certificate. >> Installation failed. Rolling back changes. >> IPA client is not configured on this system. >> >> >> Thanks, >> _____________________________________________________ >> John Moyer >> >> >> >> _______________________________________________ >> 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 john.moyer at digitalreasoning.com Tue Feb 19 02:06:59 2013 From: john.moyer at digitalreasoning.com (John Moyer) Date: Mon, 18 Feb 2013 21:06:59 -0500 Subject: [Freeipa-users] Cannot obtain CA Certificate In-Reply-To: References: <80D02259-925A-4529-943F-0ACAD7B77BB3@digitalreasoning.com> <717BE6A1-AA0D-44AB-9709-3AF504B37559@digitalreasoning.com> Message-ID: <973C2234-AB82-4C7A-8DB3-F43F61A95D53@digitalreasoning.com> Peter, The client is pointing to DNS for the server. Here is the log info from the ipa-client-log (in /var/log/). I haven't tried the other stuff yet, I'll respond back when I get a chance to check out the CA cert things. 2013-02-19T02:01:37Z DEBUG args=kinit ipa-bind at EXAMPLE.COM 2013-02-19T02:01:37Z DEBUG stdout=Password for ipa-bind at EXAMPLE.COM: 2013-02-19T02:01:37Z DEBUG stderr= 2013-02-19T02:01:37Z DEBUG trying to retrieve CA cert via LDAP from ldap://ipa1.example.com 2013-02-19T02:01:37Z DEBUG get_ca_cert_from_ldap() error: Local error SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Server krbtgt/COM at EXAMPLE.COM not found in Kerberos database) 2013-02-19T02:01:37Z DEBUG {'info': 'SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Server krbtgt/COM at EXAMPLE.COM not found in Kerberos database)', 'desc': 'Local error'} 2013-02-19T02:01:37Z ERROR Cannot obtain CA certificate 'ldap://ipa1.example.com' doesn't have a certificate. 2013-02-19T02:01:37Z DEBUG args=kdestroy 2013-02-19T02:01:37Z DEBUG stdout= 2013-02-19T02:01:37Z DEBUG stderr= Thanks, _____________________________________________________ John Moyer Director, IT Operations Digital Reasoning Systems, Inc. John.Moyer at digitalreasoning.com Office: 703.678.2311 Mobile: 240.460.0023 Fax: 703.678.2312 www.digitalreasoning.com On Feb 18, 2013, at 8:42 PM, Peter Brown wrote: > On 19 February 2013 11:03, John Moyer wrote: > Peter, > > Thanks for the response, I just checked out my security group settings, I did have some ports blocked, however, allowing them did not help. I installed mmap on the client and did a port scan of the server and got the follow: > > PORT STATE SERVICE > 22/tcp open ssh > 53/tcp open domain > 80/tcp open http > 88/tcp open kerberos-sec > 389/tcp open ldap > 443/tcp open https > 464/tcp open kpasswd5 > 636/tcp open ldapssl > 749/tcp open kerberos-adm > > There is a couple of UDP ports that need to be open as well > 464 and 88 from memory. > > They shouldn't affect your ability to download the ca cert. > > Have you checked the ipa-client log file? > I can't remember where that gets saved right now but it should mention the location when you run the ipa-client command. > > > > I tried to enroll again and got the same error as seen here: > > > Synchronizing time with KDC... > > ipa : ERROR Cannot obtain CA certificate > > > > Thanks, > _____________________________________________________ > John Moyer > > > On Feb 18, 2013, at 7:24 PM, Peter Brown wrote: > >> Hi John, >> >> I ran into a similar issue with setting up a 2.2 client with a 3.1 server. >> It turned out to be that port 80 wasn't open on the freeipa server. >> I would check your ports and see if the right ones are open. >> I also find that setting up the SRV and TXT records in your dns zone makes setting up clients a lot simpler. >> >> >> >> On 19 February 2013 00:58, John Moyer wrote: >> Hello all, >> >> I am having an issue using IPA 2.2.0. I am trying to put together a proof of concept set of systems. I've stood up 2 servers on AWS. One is the server one is the client. I am using CentOS 6 to do all this testing on, with the default IPA packages provided from CentOS. I had a fully operational proof of concept finished fully scripted to be built without issues. I shutdown and started these as needed to show to people to get approval for the project. The other day the client stopped enrolling to the IPA server, I have no idea why I assume a patch pushed out broke something since it is a fully scripted install. It does get the most recent patches each time I stand it up so it definitely would pull any new patches that came out. >> >> After investigating I am getting this error when I try to manually enroll the client. I haven't been able to find any reference to this error anywhere on the net. Any help would be greatly appreciated! Let me know if any additional details are needed. >> >> >> PLEASE NOTE: Everything below has been sanitized >> >> >> [root at client ~]# ipa-client-install --domain=example.com --server=ipa1.example.com --realm=EXAMPLE.COM --configure-ssh --configure-sshd -p ipa-bind -w "blah" -U >> DNS domain 'example.com' is not configured for automatic KDC address lookup. >> KDC address will be set to fixed value. >> >> Discovery was successful! >> Hostname: client.ec2.internal >> Realm: EXAMPLE.COM >> DNS Domain: digitalreasoning.com >> IPA Server: ipa1.example.com >> BaseDN: dc=example,dc=com >> >> >> Synchronizing time with KDC... >> >> ipa : ERROR Cannot obtain CA certificate >> 'ldap://ipa1.example.com' doesn't have a certificate. >> Installation failed. Rolling back changes. >> IPA client is not configured on this system. >> >> >> Thanks, >> _____________________________________________________ >> John Moyer >> >> >> >> _______________________________________________ >> 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 Feb 19 02:35:43 2013 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 18 Feb 2013 21:35:43 -0500 Subject: [Freeipa-users] Cannot obtain CA Certificate In-Reply-To: <973C2234-AB82-4C7A-8DB3-F43F61A95D53@digitalreasoning.com> References: <80D02259-925A-4529-943F-0ACAD7B77BB3@digitalreasoning.com> <717BE6A1-AA0D-44AB-9709-3AF504B37559@digitalreasoning.com> <973C2234-AB82-4C7A-8DB3-F43F61A95D53@digitalreasoning.com> Message-ID: <5122E4FF.5060400@redhat.com> On 02/18/2013 09:06 PM, John Moyer wrote: > Peter, > > The client is pointing to DNS for the server. Here is the log info > from the ipa-client-log (in /var/log/). I haven't tried the other > stuff yet, I'll respond back when I get a chance to check out the CA > cert things. > > > 2013-02-19T02:01:37Z DEBUG args=kinit ipa-bind at EXAMPLE.COM > > 2013-02-19T02:01:37Z DEBUG stdout=Password for ipa-bind at EXAMPLE.COM > : > > 2013-02-19T02:01:37Z DEBUG stderr= > 2013-02-19T02:01:37Z DEBUG trying to retrieve CA cert via LDAP from > ldap://ipa1.example.com > 2013-02-19T02:01:37Z DEBUG get_ca_cert_from_ldap() error: Local error > SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. > Minor code may provide more information (Server > krbtgt/COM at EXAMPLE.COM not found in > Kerberos database) > 2013-02-19T02:01:37Z DEBUG {'info': 'SASL(-1): generic failure: GSSAPI > Error: Unspecified GSS failure. Minor code may provide more > information (Server krbtgt/COM at EXAMPLE.COM > not found in Kerberos database)', > 'desc': 'Local error'} > 2013-02-19T02:01:37Z ERROR Cannot obtain CA certificate > 'ldap://ipa1.example.com' doesn't have a > certificate. > 2013-02-19T02:01:37Z DEBUG args=kdestroy > 2013-02-19T02:01:37Z DEBUG stdout= > 2013-02-19T02:01:37Z DEBUG stderr= Can the server resolve the client in the same way as client resolves itself? In AWS it might be an issue because it changes system names dynamically and thus you client host when restarted might have a different name or be not resolvable by the server. The fact that AWS changes names under you makes IPA not usable in AWS environment. https://fedorahosted.org/freeipa/ticket/2715 > > > Thanks, > _____________________________________________________ > John Moyer > Director, IT Operations > *Digital Reasoning Systems, Inc.* > John.Moyer at digitalreasoning.com > Office:703.678.2311 > Mobile:240.460.0023 > Fax:703.678.2312 > www.digitalreasoning.com > > On Feb 18, 2013, at 8:42 PM, Peter Brown > wrote: > >> On 19 February 2013 11:03, John Moyer >> > > wrote: >> >> Peter, >> >> Thanks for the response, I just checked out my security group >> settings, I did have some ports blocked, however, allowing them >> did not help. I installed mmap on the client and did a port >> scan of the server and got the follow: >> >> PORT STATE SERVICE >> 22/tcp open ssh >> 53/tcp open domain >> 80/tcp open http >> 88/tcp open kerberos-sec >> 389/tcp open ldap >> 443/tcp open https >> 464/tcp open kpasswd5 >> 636/tcp open ldapssl >> 749/tcp open kerberos-adm >> >> >> There is a couple of UDP ports that need to be open as well >> 464 and 88 from memory. >> >> They shouldn't affect your ability to download the ca cert. >> >> Have you checked the ipa-client log file? >> I can't remember where that gets saved right now but it should >> mention the location when you run the ipa-client command. >> >> >> >> I tried to enroll again and got the same error as seen here: >> >> >> Synchronizing time with KDC... >> >> ipa : ERROR Cannot obtain CA certificate >> >> >> >> Thanks, >> _____________________________________________________ >> John Moyer >> >> >> On Feb 18, 2013, at 7:24 PM, Peter Brown > > wrote: >> >>> Hi John, >>> >>> I ran into a similar issue with setting up a 2.2 client with a >>> 3.1 server. >>> It turned out to be that port 80 wasn't open on the freeipa server. >>> I would check your ports and see if the right ones are open. >>> I also find that setting up the SRV and TXT records in your dns >>> zone makes setting up clients a lot simpler. >>> >>> >>> >>> On 19 February 2013 00:58, John Moyer >>> >> > wrote: >>> >>> Hello all, >>> >>> I am having an issue using IPA 2.2.0. I am trying to put >>> together a proof of concept set of systems. I've stood up 2 >>> servers on AWS. One is the server one is the client. I >>> am using CentOS 6 to do all this testing on, with the >>> default IPA packages provided from CentOS. I had a fully >>> operational proof of concept finished fully scripted to be >>> built without issues. I shutdown and started these as >>> needed to show to people to get approval for the project. >>> The other day the client stopped enrolling to the IPA >>> server, I have no idea why I assume a patch pushed out broke >>> something since it is a fully scripted install. It does get >>> the most recent patches each time I stand it up so it >>> definitely would pull any new patches that came out. >>> >>> After investigating I am getting this error when I try to >>> manually enroll the client. I haven't been able to find any >>> reference to this error anywhere on the net. Any help would >>> be greatly appreciated! Let me know if any additional >>> details are needed. >>> >>> >>> PLEASE NOTE: Everything below has been sanitized >>> >>> >>> [root at client ~]# ipa-client-install --domain=example.com >>> --server=ipa1.example.com >>> --realm=EXAMPLE.COM >>> --configure-ssh --configure-sshd -p >>> ipa-bind -w "blah" -U >>> DNS domain 'example.com ' is not >>> configured for automatic KDC address lookup. >>> KDC address will be set to fixed value. >>> >>> Discovery was successful! >>> Hostname: client.ec2.internal >>> Realm: EXAMPLE.COM >>> DNS Domain: digitalreasoning.com >>> IPA Server: ipa1.example.com >>> BaseDN: dc=example,dc=com >>> >>> >>> Synchronizing time with KDC... >>> >>> ipa : ERROR Cannot obtain CA certificate >>> 'ldap://ipa1.example.com' doesn't have a certificate. >>> Installation failed. Rolling back changes. >>> IPA client is not configured on this system. >>> >>> >>> Thanks, >>> _____________________________________________________ >>> John Moyer >>> >>> >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> >>> >> >> > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rendhalver at gmail.com Tue Feb 19 02:44:17 2013 From: rendhalver at gmail.com (Peter Brown) Date: Tue, 19 Feb 2013 12:44:17 +1000 Subject: [Freeipa-users] Cannot obtain CA Certificate In-Reply-To: <973C2234-AB82-4C7A-8DB3-F43F61A95D53@digitalreasoning.com> References: <80D02259-925A-4529-943F-0ACAD7B77BB3@digitalreasoning.com> <717BE6A1-AA0D-44AB-9709-3AF504B37559@digitalreasoning.com> <973C2234-AB82-4C7A-8DB3-F43F61A95D53@digitalreasoning.com> Message-ID: On 19 February 2013 12:06, John Moyer wrote: > Peter, > > The client is pointing to DNS for the server. Here is the log info from > the ipa-client-log (in /var/log/). I haven't tried the other stuff yet, > I'll respond back when I get a chance to check out the CA cert things. > > > 2013-02-19T02:01:37Z DEBUG args=kinit ipa-bind at EXAMPLE.COM > 2013-02-19T02:01:37Z DEBUG stdout=Password for ipa-bind at EXAMPLE.COM: > > 2013-02-19T02:01:37Z DEBUG stderr= > 2013-02-19T02:01:37Z DEBUG trying to retrieve CA cert via LDAP from > ldap://ipa1.example.com > 2013-02-19T02:01:37Z DEBUG get_ca_cert_from_ldap() error: Local error > SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor > code may provide more information (Server krbtgt/COM at EXAMPLE.COM not > found in Kerberos database) > 2013-02-19T02:01:37Z DEBUG {'info': 'SASL(-1): generic failure: GSSAPI > Error: Unspecified GSS failure. Minor code may provide more information > (Server krbtgt/COM at EXAMPLE.COM not found in Kerberos database)', 'desc': > 'Local error'} > 2013-02-19T02:01:37Z ERROR Cannot obtain CA certificate > 'ldap://ipa1.example.com' doesn't have a certificate. > 2013-02-19T02:01:37Z DEBUG args=kdestroy > 2013-02-19T02:01:37Z DEBUG stdout= > 2013-02-19T02:01:37Z DEBUG stderr= > I would hazard a guess you need those udp ports open on the firewall for your freeipa server. the two I mentioned are kerberos ports. you will likely need udp port 389 open as well for talking to the directory server where it is attempting to get the cert from. > > Thanks, > _____________________________________________________ > John Moyer > Director, IT Operations > *Digital Reasoning Systems, Inc.* > John.Moyer at digitalreasoning.com > Office: 703.678.2311 > Mobile: 240.460.0023 > Fax: 703.678.2312 > www.digitalreasoning.com > > On Feb 18, 2013, at 8:42 PM, Peter Brown wrote: > > On 19 February 2013 11:03, John Moyer wrote: > >> Peter, >> >> Thanks for the response, I just checked out my security group settings, I >> did have some ports blocked, however, allowing them did not help. I >> installed mmap on the client and did a port scan of the server and got the >> follow: >> >> PORT STATE SERVICE >> 22/tcp open ssh >> 53/tcp open domain >> 80/tcp open http >> 88/tcp open kerberos-sec >> 389/tcp open ldap >> 443/tcp open https >> 464/tcp open kpasswd5 >> 636/tcp open ldapssl >> 749/tcp open kerberos-adm >> > > There is a couple of UDP ports that need to be open as well > 464 and 88 from memory. > > They shouldn't affect your ability to download the ca cert. > > Have you checked the ipa-client log file? > I can't remember where that gets saved right now but it should mention the > location when you run the ipa-client command. > > > >> I tried to enroll again and got the same error as seen here: >> >> >> Synchronizing time with KDC... >> >> ipa : ERROR Cannot obtain CA certificate >> >> >> >> Thanks, >> _____________________________________________________ >> John Moyer >> >> >> On Feb 18, 2013, at 7:24 PM, Peter Brown wrote: >> >> Hi John, >> >> I ran into a similar issue with setting up a 2.2 client with a 3.1 server. >> It turned out to be that port 80 wasn't open on the freeipa server. >> I would check your ports and see if the right ones are open. >> I also find that setting up the SRV and TXT records in your dns zone >> makes setting up clients a lot simpler. >> >> >> >> On 19 February 2013 00:58, John Moyer wrote: >> >>> Hello all, >>> >>> I am having an issue using IPA 2.2.0. I am trying to put together a >>> proof of concept set of systems. I've stood up 2 servers on AWS. One is >>> the server one is the client. I am using CentOS 6 to do all this testing >>> on, with the default IPA packages provided from CentOS. I had a fully >>> operational proof of concept finished fully scripted to be built without >>> issues. I shutdown and started these as needed to show to people to get >>> approval for the project. The other day the client stopped enrolling to >>> the IPA server, I have no idea why I assume a patch pushed out broke >>> something since it is a fully scripted install. It does get the most recent >>> patches each time I stand it up so it definitely would pull any new patches >>> that came out. >>> >>> After investigating I am getting this error when I try to manually >>> enroll the client. I haven't been able to find any reference to this error >>> anywhere on the net. Any help would be greatly appreciated! Let me know >>> if any additional details are needed. >>> >>> >>> PLEASE NOTE: Everything below has been sanitized >>> >>> >>> [root at client ~]# ipa-client-install --domain=example.com --server= >>> ipa1.example.com --realm=EXAMPLE.COM --configure-ssh --configure-sshd -p ipa-bind -w "blah" -U >>> DNS domain 'example.com' is not configured for automatic KDC address >>> lookup. >>> KDC address will be set to fixed value. >>> >>> Discovery was successful! >>> Hostname: client.ec2.internal >>> Realm: EXAMPLE.COM >>> DNS Domain: digitalreasoning.com >>> IPA Server: ipa1.example.com >>> BaseDN: dc=example,dc=com >>> >>> >>> Synchronizing time with KDC... >>> >>> ipa : ERROR Cannot obtain CA certificate >>> 'ldap://ipa1.example.com' doesn't have a certificate. >>> Installation failed. Rolling back changes. >>> IPA client is not configured on this system. >>> >>> >>> Thanks, >>> _____________________________________________________ >>> John Moyer >>> >>> >>> >>> _______________________________________________ >>> 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 rendhalver at gmail.com Tue Feb 19 02:46:59 2013 From: rendhalver at gmail.com (Peter Brown) Date: Tue, 19 Feb 2013 12:46:59 +1000 Subject: [Freeipa-users] Cannot obtain CA Certificate In-Reply-To: References: <80D02259-925A-4529-943F-0ACAD7B77BB3@digitalreasoning.com> <717BE6A1-AA0D-44AB-9709-3AF504B37559@digitalreasoning.com> <973C2234-AB82-4C7A-8DB3-F43F61A95D53@digitalreasoning.com> Message-ID: On 19 February 2013 12:44, Peter Brown wrote: > > > > On 19 February 2013 12:06, John Moyer wrote: > >> Peter, >> >> The client is pointing to DNS for the server. Here is the log info >> from the ipa-client-log (in /var/log/). I haven't tried the other stuff >> yet, I'll respond back when I get a chance to check out the CA cert things. >> >> >> 2013-02-19T02:01:37Z DEBUG args=kinit ipa-bind at EXAMPLE.COM >> 2013-02-19T02:01:37Z DEBUG stdout=Password for ipa-bind at EXAMPLE.COM: >> >> 2013-02-19T02:01:37Z DEBUG stderr= >> 2013-02-19T02:01:37Z DEBUG trying to retrieve CA cert via LDAP from >> ldap://ipa1.example.com >> 2013-02-19T02:01:37Z DEBUG get_ca_cert_from_ldap() error: Local error >> SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor >> code may provide more information (Server krbtgt/COM at EXAMPLE.COM not >> found in Kerberos database) >> 2013-02-19T02:01:37Z DEBUG {'info': 'SASL(-1): generic failure: GSSAPI >> Error: Unspecified GSS failure. Minor code may provide more information >> (Server krbtgt/COM at EXAMPLE.COM not found in Kerberos database)', 'desc': >> 'Local error'} >> 2013-02-19T02:01:37Z ERROR Cannot obtain CA certificate >> 'ldap://ipa1.example.com' doesn't have a certificate. >> 2013-02-19T02:01:37Z DEBUG args=kdestroy >> 2013-02-19T02:01:37Z DEBUG stdout= >> 2013-02-19T02:01:37Z DEBUG stderr= >> > > I would hazard a guess you need those udp ports open on the firewall for > your freeipa server. > the two I mentioned are kerberos ports. > you will likely need udp port 389 open as well for talking to the > directory server where it is attempting to get the cert from. > I just had another thought. If you have outgoing port restrictions on your AWS instances you will need to allow them to connect to all the ports freeipa needs. > >> >> Thanks, >> _____________________________________________________ >> John Moyer >> Director, IT Operations >> *Digital Reasoning Systems, Inc.* >> John.Moyer at digitalreasoning.com >> Office: 703.678.2311 >> Mobile: 240.460.0023 >> Fax: 703.678.2312 >> www.digitalreasoning.com >> >> On Feb 18, 2013, at 8:42 PM, Peter Brown wrote: >> >> On 19 February 2013 11:03, John Moyer wrote: >> >>> Peter, >>> >>> Thanks for the response, I just checked out my security group >>> settings, I did have some ports blocked, however, allowing them did not >>> help. I installed mmap on the client and did a port scan of the server >>> and got the follow: >>> >>> PORT STATE SERVICE >>> 22/tcp open ssh >>> 53/tcp open domain >>> 80/tcp open http >>> 88/tcp open kerberos-sec >>> 389/tcp open ldap >>> 443/tcp open https >>> 464/tcp open kpasswd5 >>> 636/tcp open ldapssl >>> 749/tcp open kerberos-adm >>> >> >> There is a couple of UDP ports that need to be open as well >> 464 and 88 from memory. >> >> They shouldn't affect your ability to download the ca cert. >> >> Have you checked the ipa-client log file? >> I can't remember where that gets saved right now but it should mention >> the location when you run the ipa-client command. >> >> >> >>> I tried to enroll again and got the same error as seen here: >>> >>> >>> Synchronizing time with KDC... >>> >>> ipa : ERROR Cannot obtain CA certificate >>> >>> >>> >>> Thanks, >>> _____________________________________________________ >>> John Moyer >>> >>> >>> On Feb 18, 2013, at 7:24 PM, Peter Brown wrote: >>> >>> Hi John, >>> >>> I ran into a similar issue with setting up a 2.2 client with a 3.1 >>> server. >>> It turned out to be that port 80 wasn't open on the freeipa server. >>> I would check your ports and see if the right ones are open. >>> I also find that setting up the SRV and TXT records in your dns zone >>> makes setting up clients a lot simpler. >>> >>> >>> >>> On 19 February 2013 00:58, John Moyer wrote: >>> >>>> Hello all, >>>> >>>> I am having an issue using IPA 2.2.0. I am trying to put together a >>>> proof of concept set of systems. I've stood up 2 servers on AWS. One is >>>> the server one is the client. I am using CentOS 6 to do all this testing >>>> on, with the default IPA packages provided from CentOS. I had a fully >>>> operational proof of concept finished fully scripted to be built without >>>> issues. I shutdown and started these as needed to show to people to get >>>> approval for the project. The other day the client stopped enrolling to >>>> the IPA server, I have no idea why I assume a patch pushed out broke >>>> something since it is a fully scripted install. It does get the most recent >>>> patches each time I stand it up so it definitely would pull any new patches >>>> that came out. >>>> >>>> After investigating I am getting this error when I try to manually >>>> enroll the client. I haven't been able to find any reference to this error >>>> anywhere on the net. Any help would be greatly appreciated! Let me know >>>> if any additional details are needed. >>>> >>>> >>>> PLEASE NOTE: Everything below has been sanitized >>>> >>>> >>>> [root at client ~]# ipa-client-install --domain=example.com --server= >>>> ipa1.example.com --realm=EXAMPLE.COM --configure-ssh --configure-sshd -p ipa-bind -w "blah" -U >>>> DNS domain 'example.com' is not configured for automatic KDC address >>>> lookup. >>>> KDC address will be set to fixed value. >>>> >>>> Discovery was successful! >>>> Hostname: client.ec2.internal >>>> Realm: EXAMPLE.COM >>>> DNS Domain: digitalreasoning.com >>>> IPA Server: ipa1.example.com >>>> BaseDN: dc=example,dc=com >>>> >>>> >>>> Synchronizing time with KDC... >>>> >>>> ipa : ERROR Cannot obtain CA certificate >>>> 'ldap://ipa1.example.com' doesn't have a certificate. >>>> Installation failed. Rolling back changes. >>>> IPA client is not configured on this system. >>>> >>>> >>>> Thanks, >>>> _____________________________________________________ >>>> John Moyer >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 Tue Feb 19 02:52:12 2013 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Tue, 19 Feb 2013 02:52:12 +0000 Subject: [Freeipa-users] Cannot obtain CA Certificate In-Reply-To: <5122E4FF.5060400@redhat.com> References: <80D02259-925A-4529-943F-0ACAD7B77BB3@digitalreasoning.com> <717BE6A1-AA0D-44AB-9709-3AF504B37559@digitalreasoning.com> <973C2234-AB82-4C7A-8DB3-F43F61A95D53@digitalreasoning.com>, <5122E4FF.5060400@redhat.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E4071096860@STAWINCOX10MBX1.staff.vuw.ac.nz> whats AWS? 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, 19 February 2013 3:35 p.m. To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Cannot obtain CA Certificate On 02/18/2013 09:06 PM, John Moyer wrote: Peter, The client is pointing to DNS for the server. Here is the log info from the ipa-client-log (in /var/log/). I haven't tried the other stuff yet, I'll respond back when I get a chance to check out the CA cert things. 2013-02-19T02:01:37Z DEBUG args=kinit ipa-bind at EXAMPLE.COM 2013-02-19T02:01:37Z DEBUG stdout=Password for ipa-bind at EXAMPLE.COM: 2013-02-19T02:01:37Z DEBUG stderr= 2013-02-19T02:01:37Z DEBUG trying to retrieve CA cert via LDAP from ldap://ipa1.example.com 2013-02-19T02:01:37Z DEBUG get_ca_cert_from_ldap() error: Local error SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Server krbtgt/COM at EXAMPLE.COM not found in Kerberos database) 2013-02-19T02:01:37Z DEBUG {'info': 'SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Server krbtgt/COM at EXAMPLE.COM not found in Kerberos database)', 'desc': 'Local error'} 2013-02-19T02:01:37Z ERROR Cannot obtain CA certificate 'ldap://ipa1.example.com' doesn't have a certificate. 2013-02-19T02:01:37Z DEBUG args=kdestroy 2013-02-19T02:01:37Z DEBUG stdout= 2013-02-19T02:01:37Z DEBUG stderr= Can the server resolve the client in the same way as client resolves itself? In AWS it might be an issue because it changes system names dynamically and thus you client host when restarted might have a different name or be not resolvable by the server. The fact that AWS changes names under you makes IPA not usable in AWS environment. https://fedorahosted.org/freeipa/ticket/2715 Thanks, _____________________________________________________ John Moyer Director, IT Operations Digital Reasoning Systems, Inc. John.Moyer at digitalreasoning.com Office: 703.678.2311 Mobile: 240.460.0023 Fax: 703.678.2312 www.digitalreasoning.com On Feb 18, 2013, at 8:42 PM, Peter Brown > wrote: On 19 February 2013 11:03, John Moyer > wrote: Peter, Thanks for the response, I just checked out my security group settings, I did have some ports blocked, however, allowing them did not help. I installed mmap on the client and did a port scan of the server and got the follow: PORT STATE SERVICE 22/tcp open ssh 53/tcp open domain 80/tcp open http 88/tcp open kerberos-sec 389/tcp open ldap 443/tcp open https 464/tcp open kpasswd5 636/tcp open ldapssl 749/tcp open kerberos-adm There is a couple of UDP ports that need to be open as well 464 and 88 from memory. They shouldn't affect your ability to download the ca cert. Have you checked the ipa-client log file? I can't remember where that gets saved right now but it should mention the location when you run the ipa-client command. I tried to enroll again and got the same error as seen here: Synchronizing time with KDC... ipa : ERROR Cannot obtain CA certificate Thanks, _____________________________________________________ John Moyer On Feb 18, 2013, at 7:24 PM, Peter Brown > wrote: Hi John, I ran into a similar issue with setting up a 2.2 client with a 3.1 server. It turned out to be that port 80 wasn't open on the freeipa server. I would check your ports and see if the right ones are open. I also find that setting up the SRV and TXT records in your dns zone makes setting up clients a lot simpler. On 19 February 2013 00:58, John Moyer > wrote: Hello all, I am having an issue using IPA 2.2.0. I am trying to put together a proof of concept set of systems. I've stood up 2 servers on AWS. One is the server one is the client. I am using CentOS 6 to do all this testing on, with the default IPA packages provided from CentOS. I had a fully operational proof of concept finished fully scripted to be built without issues. I shutdown and started these as needed to show to people to get approval for the project. The other day the client stopped enrolling to the IPA server, I have no idea why I assume a patch pushed out broke something since it is a fully scripted install. It does get the most recent patches each time I stand it up so it definitely would pull any new patches that came out. After investigating I am getting this error when I try to manually enroll the client. I haven't been able to find any reference to this error anywhere on the net. Any help would be greatly appreciated! Let me know if any additional details are needed. PLEASE NOTE: Everything below has been sanitized [root at client ~]# ipa-client-install --domain=example.com --server=ipa1.example.com --realm=EXAMPLE.COM --configure-ssh --configure-sshd -p ipa-bind -w "blah" -U DNS domain 'example.com' is not configured for automatic KDC address lookup. KDC address will be set to fixed value. Discovery was successful! Hostname: client.ec2.internal Realm: EXAMPLE.COM DNS Domain: digitalreasoning.com IPA Server: ipa1.example.com BaseDN: dc=example,dc=com Synchronizing time with KDC... ipa : ERROR Cannot obtain CA certificate 'ldap://ipa1.example.com' doesn't have a certificate. Installation failed. Rolling back changes. IPA client is not configured on this system. Thanks, _____________________________________________________ John Moyer _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Tue Feb 19 02:53:48 2013 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 18 Feb 2013 21:53:48 -0500 Subject: [Freeipa-users] Cannot obtain CA Certificate In-Reply-To: <833D8E48405E064EBC54C84EC6B36E4071096860@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <80D02259-925A-4529-943F-0ACAD7B77BB3@digitalreasoning.com> <717BE6A1-AA0D-44AB-9709-3AF504B37559@digitalreasoning.com> <973C2234-AB82-4C7A-8DB3-F43F61A95D53@digitalreasoning.com>, <5122E4FF.5060400@redhat.com> <833D8E48405E064EBC54C84EC6B36E4071096860@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <5122E93C.8020806@redhat.com> On 02/18/2013 09:52 PM, Steven Jones wrote: > whats AWS? Amazon EC2 cloud. > > 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, 19 February 2013 3:35 p.m. > *To:* freeipa-users at redhat.com > *Subject:* Re: [Freeipa-users] Cannot obtain CA Certificate > > On 02/18/2013 09:06 PM, John Moyer wrote: >> Peter, >> >> The client is pointing to DNS for the server. Here is the log info >> from the ipa-client-log (in /var/log/). I haven't tried the other >> stuff yet, I'll respond back when I get a chance to check out the CA >> cert things. >> >> >> 2013-02-19T02:01:37Z DEBUG args=kinit ipa-bind at EXAMPLE.COM >> >> 2013-02-19T02:01:37Z DEBUG stdout=Password for ipa-bind at EXAMPLE.COM >> : >> >> 2013-02-19T02:01:37Z DEBUG stderr= >> 2013-02-19T02:01:37Z DEBUG trying to retrieve CA cert via LDAP from >> ldap://ipa1.example.com >> 2013-02-19T02:01:37Z DEBUG get_ca_cert_from_ldap() error: Local error >> SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. >> Minor code may provide more information (Server >> krbtgt/COM at EXAMPLE.COM not found in >> Kerberos database) >> 2013-02-19T02:01:37Z DEBUG {'info': 'SASL(-1): generic failure: >> GSSAPI Error: Unspecified GSS failure. Minor code may provide more >> information (Server krbtgt/COM at EXAMPLE.COM >> not found in Kerberos database)', >> 'desc': 'Local error'} >> 2013-02-19T02:01:37Z ERROR Cannot obtain CA certificate >> 'ldap://ipa1.example.com' doesn't have a >> certificate. >> 2013-02-19T02:01:37Z DEBUG args=kdestroy >> 2013-02-19T02:01:37Z DEBUG stdout= >> 2013-02-19T02:01:37Z DEBUG stderr= > > > Can the server resolve the client in the same way as client resolves > itself? > In AWS it might be an issue because it changes system names > dynamically and thus you client host when restarted might have a > different name or be not resolvable by the server. > The fact that AWS changes names under you makes IPA not usable in AWS > environment. > https://fedorahosted.org/freeipa/ticket/2715 > >> >> >> Thanks, >> _____________________________________________________ >> John Moyer >> Director, IT Operations >> *Digital Reasoning Systems, Inc.* >> John.Moyer at digitalreasoning.com >> Office:703.678.2311 >> Mobile:240.460.0023 >> Fax:703.678.2312 >> www.digitalreasoning.com >> >> On Feb 18, 2013, at 8:42 PM, Peter Brown > > wrote: >> >>> On 19 February 2013 11:03, John Moyer >>> >> > wrote: >>> >>> Peter, >>> >>> Thanks for the response, I just checked out my security group >>> settings, I did have some ports blocked, however, allowing them >>> did not help. I installed mmap on the client and did a port >>> scan of the server and got the follow: >>> >>> PORT STATE SERVICE >>> 22/tcp open ssh >>> 53/tcp open domain >>> 80/tcp open http >>> 88/tcp open kerberos-sec >>> 389/tcp open ldap >>> 443/tcp open https >>> 464/tcp open kpasswd5 >>> 636/tcp open ldapssl >>> 749/tcp open kerberos-adm >>> >>> >>> There is a couple of UDP ports that need to be open as well >>> 464 and 88 from memory. >>> >>> They shouldn't affect your ability to download the ca cert. >>> >>> Have you checked the ipa-client log file? >>> I can't remember where that gets saved right now but it should >>> mention the location when you run the ipa-client command. >>> >>> >>> >>> I tried to enroll again and got the same error as seen here: >>> >>> >>> Synchronizing time with KDC... >>> >>> ipa : ERROR Cannot obtain CA certificate >>> >>> >>> >>> Thanks, >>> _____________________________________________________ >>> John Moyer >>> >>> >>> On Feb 18, 2013, at 7:24 PM, Peter Brown >> > wrote: >>> >>>> Hi John, >>>> >>>> I ran into a similar issue with setting up a 2.2 client with a >>>> 3.1 server. >>>> It turned out to be that port 80 wasn't open on the freeipa server. >>>> I would check your ports and see if the right ones are open. >>>> I also find that setting up the SRV and TXT records in your dns >>>> zone makes setting up clients a lot simpler. >>>> >>>> >>>> >>>> On 19 February 2013 00:58, John Moyer >>>> >>> > wrote: >>>> >>>> Hello all, >>>> >>>> I am having an issue using IPA 2.2.0. I am trying to put >>>> together a proof of concept set of systems. I've stood up >>>> 2 servers on AWS. One is the server one is the client. >>>> I am using CentOS 6 to do all this testing on, with the >>>> default IPA packages provided from CentOS. I had a fully >>>> operational proof of concept finished fully scripted to be >>>> built without issues. I shutdown and started these as >>>> needed to show to people to get approval for the project. >>>> The other day the client stopped enrolling to the IPA >>>> server, I have no idea why I assume a patch pushed out >>>> broke something since it is a fully scripted install. It >>>> does get the most recent patches each time I stand it up so >>>> it definitely would pull any new patches that came out. >>>> >>>> After investigating I am getting this error when I try to >>>> manually enroll the client. I haven't been able to find >>>> any reference to this error anywhere on the net. Any help >>>> would be greatly appreciated! Let me know if any >>>> additional details are needed. >>>> >>>> >>>> PLEASE NOTE: Everything below has been sanitized >>>> >>>> >>>> [root at client ~]# ipa-client-install --domain=example.com >>>> --server=ipa1.example.com >>>> --realm=EXAMPLE.COM >>>> --configure-ssh --configure-sshd -p >>>> ipa-bind -w "blah" -U >>>> DNS domain 'example.com ' is not >>>> configured for automatic KDC address lookup. >>>> KDC address will be set to fixed value. >>>> >>>> Discovery was successful! >>>> Hostname: client.ec2.internal >>>> Realm: EXAMPLE.COM >>>> DNS Domain: digitalreasoning.com >>>> IPA Server: ipa1.example.com >>>> BaseDN: dc=example,dc=com >>>> >>>> >>>> Synchronizing time with KDC... >>>> >>>> ipa : ERROR Cannot obtain CA certificate >>>> 'ldap://ipa1.example.com' doesn't have a certificate. >>>> Installation failed. Rolling back changes. >>>> IPA client is not configured on this system. >>>> >>>> >>>> Thanks, >>>> _____________________________________________________ >>>> John Moyer >>>> >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-users mailing list >>>> Freeipa-users at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>> >>>> >>> >>> >> >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdennis at redhat.com Tue Feb 19 03:04:13 2013 From: jdennis at redhat.com (John Dennis) Date: Mon, 18 Feb 2013 22:04:13 -0500 Subject: [Freeipa-users] Cannot obtain CA Certificate In-Reply-To: <973C2234-AB82-4C7A-8DB3-F43F61A95D53@digitalreasoning.com> References: <80D02259-925A-4529-943F-0ACAD7B77BB3@digitalreasoning.com> <717BE6A1-AA0D-44AB-9709-3AF504B37559@digitalreasoning.com> <973C2234-AB82-4C7A-8DB3-F43F61A95D53@digitalreasoning.com> Message-ID: <5122EBAD.1030102@redhat.com> On 02/18/2013 09:06 PM, John Moyer wrote: > Peter, > > The client is pointing to DNS for the server. Here is the log info > from the ipa-client-log (in /var/log/). I haven't tried the other stuff > yet, I'll respond back when I get a chance to check out the CA cert things. > > > 2013-02-19T02:01:37Z DEBUG args=kinit ipa-bind at EXAMPLE.COM When the client installer tries to retrieve the CA cert from LDAP it uses a GSSAPI bind and they error you're getting is that it cannot perform a bind with the credentials from above. Did you provide the password for ipa-bind? Are you running the client install interactively? Is the realm EXAMPLE.COM really correct? Are you able to do a kinit for ipa-bind at EXAMPLE.COM on the client successfully? Are your kerberos ports open? -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Tue Feb 19 03:35:57 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 18 Feb 2013 22:35:57 -0500 Subject: [Freeipa-users] trouble with trusts and gssapi In-Reply-To: <6E7BCFC0-C670-41BD-87BF-F46A152F52F6@redhat.com> References: <7AABBEBA-0ECF-4960-837C-633B96CB5E22@redhat.com> <6E7BCFC0-C670-41BD-87BF-F46A152F52F6@redhat.com> Message-ID: <5122F31D.3090504@redhat.com> Brian Cook wrote: > More info - attached var/log/secure, and sshd_config. > > Password authentication works, just gssapi fails. in the securecrt provided I have disabled password auth as an option Create a .k5login in the home directory of your user. What I did was log in as Administratory at AD.EXAMPLE.COM using the password, create .k5login containing that principal, log out, then I was able to log back in using SSO. You should be able to add something like this to /etc/krb5.conf if you have a lot of users you want to do SSO: auth_to_local = RULE:[1:$1@$0](^.*@TRUSTED.DOMAIN$)s/@TRUSTED.DOMAIN/@trusted.domain/ auth_to_local = DEFAULT See 'info krb5-admin "Configuration Files" "krb5.conf" "realms (krb5.conf)"' for more details and examples for auth_to_local. rob > > > > > > > > On Feb 18, 2013, at 3:58 PM, Brian Cook wrote: > >> I am trying to ssh from Windows - > IPA server using GSS-API. I've tried putty, which provides very little debug out. I then downloaded securecrt which provides more output. >> >> On the server side, I just see postponed gss-with-mic and then a failure message. I'm attaching the output from securecrt. Any help would be greatly appreciated. >> >> Thanks, >> Brian >> >> _______________________________________________ >> 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 bcook at redhat.com Tue Feb 19 05:02:13 2013 From: bcook at redhat.com (Brian Cook) Date: Mon, 18 Feb 2013 21:02:13 -0800 Subject: [Freeipa-users] trouble with trusts and gssapi In-Reply-To: <5122F31D.3090504@redhat.com> References: <7AABBEBA-0ECF-4960-837C-633B96CB5E22@redhat.com> <6E7BCFC0-C670-41BD-87BF-F46A152F52F6@redhat.com> <5122F31D.3090504@redhat.com> Message-ID: <806F5FF7-01C5-4629-9F4B-F1B7895BE1DF@redhat.com> This fixed in. That makes perfect sense, but nothing in the log made me think that this was the problem. There was an auth_to_local rule setup, which I saved, which did not work. Is this a bug that we need to open a ticket for? Seems like installer is putting an inadequate regular expression in the rule. Thanks! Brian On Feb 18, 2013, at 7:35 PM, Rob Crittenden wrote: > Brian Cook wrote: >> More info - attached var/log/secure, and sshd_config. >> >> Password authentication works, just gssapi fails. in the securecrt provided I have disabled password auth as an option > > Create a .k5login in the home directory of your user. What I did was log in as Administratory at AD.EXAMPLE.COM using the password, create .k5login containing that principal, log out, then I was able to log back in using SSO. > > You should be able to add something like this to /etc/krb5.conf if you have a lot of users you want to do SSO: > > auth_to_local = RULE:[1:$1@$0](^.*@TRUSTED.DOMAIN$)s/@TRUSTED.DOMAIN/@trusted.domain/ > auth_to_local = DEFAULT > > See 'info krb5-admin "Configuration Files" "krb5.conf" "realms (krb5.conf)"' for more details and examples for auth_to_local. > > rob > >> >> >> >> >> >> >> >> On Feb 18, 2013, at 3:58 PM, Brian Cook wrote: >> >>> I am trying to ssh from Windows - > IPA server using GSS-API. I've tried putty, which provides very little debug out. I then downloaded securecrt which provides more output. >>> >>> On the server side, I just see postponed gss-with-mic and then a failure message. I'm attaching the output from securecrt. Any help would be greatly appreciated. >>> >>> Thanks, >>> Brian >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Tue Feb 19 06:48:44 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 19 Feb 2013 08:48:44 +0200 Subject: [Freeipa-users] trouble with trusts and gssapi In-Reply-To: <806F5FF7-01C5-4629-9F4B-F1B7895BE1DF@redhat.com> References: <7AABBEBA-0ECF-4960-837C-633B96CB5E22@redhat.com> <6E7BCFC0-C670-41BD-87BF-F46A152F52F6@redhat.com> <5122F31D.3090504@redhat.com> <806F5FF7-01C5-4629-9F4B-F1B7895BE1DF@redhat.com> Message-ID: <20130219064844.GK476@redhat.com> On Mon, 18 Feb 2013, Brian Cook wrote: >This fixed in. That makes perfect sense, but nothing in the log made >me think that this was the problem. > >There was an auth_to_local rule setup, which I saved, which did not >work. Is this a bug that we need to open a ticket for? Seems like >installer is putting an inadequate regular expression in the rule. Installer does not put auth_to_local rules into /etc/krb5.conf. Since we don't know what will be your trusted domains until you would really establish the trust, we cannot fill in proper auth_to_local rule. That rule has to be written manually, as described in http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#Edit_.2Fetc.2Fkrb5.conf Log actually hints about it: Feb 18 16:02:54 ipa1 sshd[21048]: debug3: mm_ssh_gssapi_userok: user not authenticated this is a stage where openssh calls for gss_userok -- is this user which credentials were already authenticated would be authorized by the local system? Failure of this call means it was not possible to relate principal to local account. The way MIT Kerberos does this action is currently limited to use of manual mapping rules, either in krb5.conf (auth_to_local) or .k5login. We hope to get a pluggable interface in future versions of MIT Kerberos which would allow us to dynamically hook into it on SSSD side and verify against currently configured list of trusted domains. -- / Alexander Bokovoy From sbose at redhat.com Tue Feb 19 07:47:18 2013 From: sbose at redhat.com (Sumit Bose) Date: Tue, 19 Feb 2013 08:47:18 +0100 Subject: [Freeipa-users] trouble with trusts and gssapi In-Reply-To: <806F5FF7-01C5-4629-9F4B-F1B7895BE1DF@redhat.com> References: <7AABBEBA-0ECF-4960-837C-633B96CB5E22@redhat.com> <6E7BCFC0-C670-41BD-87BF-F46A152F52F6@redhat.com> <5122F31D.3090504@redhat.com> <806F5FF7-01C5-4629-9F4B-F1B7895BE1DF@redhat.com> Message-ID: <20130219074718.GF27418@localhost.localdomain> On Mon, Feb 18, 2013 at 09:02:13PM -0800, Brian Cook wrote: > This fixed in. That makes perfect sense, but nothing in the log made me think that this was the problem. > > There was an auth_to_local rule setup, which I saved, which did not work. Is this a bug that we need to open a ticket for? Seems like installer is putting an inadequate regular expression in the rule. You only see related messages in /var/log/secure if you increase the debug level of sshd. The auth_to_local rule not added by the installer but has to be added manually if you prefer this instead of using .k5login. The next major release of MIT Kerberos will have a plugin interface for auth_to_local which we plan to use. With this, the rules are not needed anymore. HTH bye, Sumit > > Thanks! > Brian > > > > On Feb 18, 2013, at 7:35 PM, Rob Crittenden wrote: > > > Brian Cook wrote: > >> More info - attached var/log/secure, and sshd_config. > >> > >> Password authentication works, just gssapi fails. in the securecrt provided I have disabled password auth as an option > > > > Create a .k5login in the home directory of your user. What I did was log in as Administratory at AD.EXAMPLE.COM using the password, create .k5login containing that principal, log out, then I was able to log back in using SSO. > > > > You should be able to add something like this to /etc/krb5.conf if you have a lot of users you want to do SSO: > > > > auth_to_local = RULE:[1:$1@$0](^.*@TRUSTED.DOMAIN$)s/@TRUSTED.DOMAIN/@trusted.domain/ > > auth_to_local = DEFAULT > > > > See 'info krb5-admin "Configuration Files" "krb5.conf" "realms (krb5.conf)"' for more details and examples for auth_to_local. > > > > rob > > > >> > >> > >> > >> > >> > >> > >> > >> On Feb 18, 2013, at 3:58 PM, Brian Cook wrote: > >> > >>> I am trying to ssh from Windows - > IPA server using GSS-API. I've tried putty, which provides very little debug out. I then downloaded securecrt which provides more output. > >>> > >>> On the server side, I just see postponed gss-with-mic and then a failure message. I'm attaching the output from securecrt. Any help would be greatly appreciated. > >>> > >>> Thanks, > >>> Brian > >>> > >>> _______________________________________________ > >>> 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 > >> > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From pspacek at redhat.com Tue Feb 19 07:51:03 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 19 Feb 2013 08:51:03 +0100 Subject: [Freeipa-users] named crash: RUNTIME_CHECK pthread_mutex_destroy failed In-Reply-To: <9EF03C7E-A7BE-4456-BED2-337E9FAFFFB5@gmail.com> References: <9EF03C7E-A7BE-4456-BED2-337E9FAFFFB5@gmail.com> Message-ID: <51232EE7.6030100@redhat.com> On 18.2.2013 17:27, Michael Mercier wrote: > Hello, > > Named stopped on one of my IPA servers over the weekend, this was the last message in the log file: > > ldap_helper.c:627: fatal error: > RUNTIME_CHECK(((pthread_mutex_destroy(((&ldap_conn->lock))) == 0) ? 0 : 34) == 0) failed > exiting (due to fatal error in library) > > Any ideas? > > All other IPA services (ipactl status) were shown as running when I checked this morning, the only service stopped was named. > > IPA on CentOS 6.3: > libipa_hbac-1.8.0-32.el6.x86_64 > ipa-admintools-2.2.0-17.el6_3.1.x86_64 > ipa-pki-ca-theme-9.0.3-7.el6.noarch > ipa-python-2.2.0-17.el6_3.1.x86_64 > ipa-client-2.2.0-17.el6_3.1.x86_64 > ipa-server-2.2.0-17.el6_3.1.x86_64 > libipa_hbac-python-1.8.0-32.el6.x86_64 > ipa-pki-common-theme-9.0.3-7.el6.noarch > python-iniparse-0.3.1-2.1.el6.noarch > ipa-server-selinux-2.2.0-17.el6_3.1.x86_64 > > bind-libs-9.8.2-0.10.rc1.el6_3.6.x86_64 > bind-utils-9.8.2-0.10.rc1.el6_3.6.x86_64 > bind-dyndb-ldap-1.1.0-0.9.b1.el6_3.1.x86_64 It is known problem: https://fedorahosted.org/bind-dyndb-ldap/ticket/101 You should get fixed bind-dyndb-ldap version with CentOS 6.4. Package version should look like "bind-dyndb-ldap-2.3-2". Simple "service named restart" is usable as a workaround, your data should be in safe. Thank you for reporting the bug! -- Petr^2 Spacek From janfrode at tanso.net Tue Feb 19 11:35:02 2013 From: janfrode at tanso.net (Jan-Frode Myklebust) Date: Tue, 19 Feb 2013 12:35:02 +0100 Subject: [Freeipa-users] Cannot obtain CA Certificate In-Reply-To: <80D02259-925A-4529-943F-0ACAD7B77BB3@digitalreasoning.com> References: <80D02259-925A-4529-943F-0ACAD7B77BB3@digitalreasoning.com> Message-ID: <20130219113502.GA21948@dibs.tanso.net> > ipa : ERROR Cannot obtain CA certificate > 'ldap://ipa1.example.com' doesn't have a certificate. > Installation failed. Rolling back changes. > IPA client is not configured on this system. FYI, I have this same issue when enrolling RHEL5 clients. Have been doing this as a workaround: wget -O /etc/ipa/ca.crt http://ipa1.example.com/ipa/config/ca.crt ipa-client-install --no-ntp --mkhomedir --ca-cert-file=/etc/ipa/ca.crt -jf From bret.wortman at damascusgrp.com Tue Feb 19 11:58:01 2013 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Tue, 19 Feb 2013 06:58:01 -0500 Subject: [Freeipa-users] Trouble creating replica Message-ID: I have a server running freeipa and I want to migrate it to a new host. I had thought that the easiest way might be to create a replica and load that onto the new host, but this is proving problematic: # ipa-replica-prepare ipamaster.my.com --ip-address 10.0.0.46 Directory Manager (existing master) password: Preparing replica for ipamaster.my.com from oldmaster.my.com Creating SSL certificate for the Directory Server preparation of replica failed: cannot connect to ' https://oldmaster.my.com:9444/ca/ee/ca/profileSubmitSSLClient': [Errno -5985] Cannot resolve oldmaster.my.com using family PR_AF_INET6 And then a stack trace follows. # netstat -rn | grep 9444 # lsof -i:9444 # * * I've also tried connecting to that URL via Firefox without success. It's just not listening there. What do I need to check? Someone else is running some apps (redmine and others) using Passenger on that server as well; could it be obscuring the port somehow? We're not running IPV6, so I'm not sure why it's being referenced.... Alternately, is there another way to migrate my current IPA data to a new host? * * *Bret Wortman* http://damascusgrp.com/ http://twitter.com/BretWortman -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdennis at redhat.com Tue Feb 19 14:08:44 2013 From: jdennis at redhat.com (John Dennis) Date: Tue, 19 Feb 2013 09:08:44 -0500 Subject: [Freeipa-users] Trouble creating replica In-Reply-To: References: Message-ID: <5123876C.6050201@redhat.com> On 02/19/2013 06:58 AM, Bret Wortman wrote: > I have a server running freeipa and I want to migrate it to a new host. > I had thought that the easiest way might be to create a replica and load > that onto the new host, but this is proving problematic: > > # ipa-replica-prepare ipamaster.my.com > --ip-address 10.0.0.46 > Directory Manager (existing master) password: > > Preparing replica for ipamaster.my.com from > oldmaster.my.com > Creating SSL certificate for the Directory Server > preparation of replica failed: cannot connect to > 'https://oldmaster.my.com:9444/ca/ee/ca/profileSubmitSSLClient': [Errno > -5985] Cannot resolve oldmaster.my.com using > family PR_AF_INET6 > > And then a stack trace follows. > > # netstat -rn | grep 9444 > # lsof -i:9444 > # > _ > _ > I've also tried connecting to that URL via Firefox without success. It's > just not listening there. What do I need to check? Someone else is > running some apps (redmine and others) using Passenger on that server as > well; could it be obscuring the port somehow? > > We're not running IPV6, so I'm not sure why it's being referenced.... I can't comment on why you can't connect but I can explain the error message. It's an internal mistake, if we can't connect we try another address family, that logic is incorrect and I thought we had fixed in this ticket https://fedorahosted.org/freeipa/ticket/2695, but apparently we didn't. Anyway the error message is a red herring, your connection problems lie elsewhere. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rmercer at harris.com Tue Feb 19 14:14:21 2013 From: rmercer at harris.com (Rodney L. Mercer) Date: Tue, 19 Feb 2013 09:14:21 -0500 Subject: [Freeipa-users] RHEL6 IPA and Active Directory synchronisation and Solaris RBAC In-Reply-To: <512121E9.2050608@redhat.com> References: <511BACEE.8050900@redhat.com> <511D2541.1000201@nixtra.com> <511D2CAC.6050400@redhat.com> <511D4693.8010502@redhat.com> <1360937840.21935.556.camel@osc145.evn.harris.com> <511EA93C.8060909@redhat.com>,<511F6D98.30700@nixtra.com> <512A3AF8DAE8454D95C05141F746ECE1512AC316@MLBMXUS21.cs.myharris.net> <512121E9.2050608@redhat.com> Message-ID: <1361283261.21935.914.camel@osc145.evn.harris.com> On Sun, 2013-02-17 at 13:31 -0500, Dmitri Pal wrote: > On 02/16/2013 12:14 PM, Mercer, Rodney wrote: > > ________________________________________ > > From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Sigbjorn Lie [sigbjorn at nixtra.com] > > Sent: Saturday, February 16, 2013 6:29 AM > > To: freeipa-users at redhat.com > > Subject: Re: [Freeipa-users] RHEL6 IPA and Active Directory synchronisation and Solaris RBAC > > > > On 02/15/2013 10:31 PM, Dmitri Pal wrote: > >> On 02/15/2013 09:17 AM, Rodney L. Mercer wrote: > >>> On Thu, 2013-02-14 at 21:44 +0100, Sigbjorn Lie wrote: > >>>> I agree with schema support being enough for now. I do not expect the > >>>> ipa mgmt tools to support Solaris rbac mgmt. > >>>> > >>>> The ipa mgmt tools are great, but I already have other data in the ipa > >>>> ldap that I have to manage manually anyway. > >>>> > >>>> > >>>> > >>>> Rgds, > >>>> Siggi > >>>> > >>>> > >>>> > >>>> Rob Crittenden wrote: > >>>> Dag Wieers wrote: > >>>> On Thu, 14 Feb 2013, Rob Crittenden wrote: > >>>> > >>>> Sigbjorn Lie wrote: > >>>> On 02/13/2013 04:10 PM, Rob Crittenden wrote: > >>>> > >>>> Also since we also require compatibility with Solaris, and roles > >>>> (RBAC) > >>>> is currently used on Solaris, does IPA support RBAC on Solar > >>>> is ? > >>>> (We > >>>> noticed that RBAC mentioned in the IPA web interface only > >>>> relates to > > IPA > >>>> management). > >>>> No, IPA doesn't support RBAC on Solaris. > >>>> > >>>> I've come across the same issue. This is just a matter of extending the > >>>> schema. > >>>> > >>>> Would there be any interest for adding the Solaris RBAC schema as a > >>>> part > >>>> of the standard IPA distributed LDAP schema? > >>> Consider the following: What else would have to be put in to support > >>> this? > >>> Once the schema is established, can SSSD be extended to use this and > >>> potentially be referenced in nsswitch.conf as it is implemented on > >>> Solaris? IE: > >>> tail -5 /etc/nsswitch.conf > >>> user_attr: sssd > >>> auth_attr: sssd > >>> prof_attr: sssd > >>> exec_attr: sssd > >>> project: sssd > >> Before we define how it is passed/exposed it would nice to understand > >> who on Linux will be consuming it out of SSSD? > >> > > I don't think Linux would consume these attributes. They are specific to > > the Role Based Access Control solution implemented in Solaris. > > > > > > Rgds, > > Siggi > > > > ---------------------------------- > > > > Yes, I understand that Linux has no mechanism currently built in to consume these Solaris name server switch attributes. But, If the Solaris RBAC schema is included as > > part of the standard IPA distributed LDAP schema, My question is how hard would it be to create an extension using SSSD/pam to do so? > > > > I agree that it is too much to ask for a full Solaris style RBAC implementation on RHEL. > > > > We have an application that currently uses the Solaris RBAC structure to authorize user/role accesses within the application. > > > > Our goal is to use existing OS calls or possibly extending SSSD to allow system calls that would give us back an answer to attrbutes placed within the LDAP > > tree that are composed in like fashion as how they are stored in Solaris. Defining the schema seemed to be well received and I understand that it is intended that it would be there to support Solaris clients. > > If SSSD could be extended to access these attributes and possibly pam modules to allow Linux clients to take advantage of this RBAC schema, then our application could perform as it does on Solaris. It would also > > open up the opportunity for other vendors to consider moving their Solaris RBAC applications to RHEL. > > > > I think with that as a goal, we could then create users and SELinux roles that are defined within the RBAC based schema much like our current Solaris implementation. > > We use Solaris nsswitch calls to get yes/no authorization answers for user/role privilege within our application. > > > > Since IdM and SSD already support > > a) HBAC > > b) SUDO > > c) SELinux user mapping > > > > I believe HBAC as already implemented in IdM will be an additional asset in defining and restricting access that can be used by our customers. > > We have decided to move away from sudo, but may reconsider some of its uses if it suits the situation. > > Maybe SSSD can be extended to access the RBAC schema in much the same way that it accesses SUDO or HBAC schema? > > > > We have decided to use RHEL as the primary OS platform of choice going forward and we need to create a solution to our application RBAC > > needs similar to that in which we have accomplished with Solaris. I have been speaking with Dmitri on the side about these possibilities and would like to know > > what each of your thoughts are. The feasibility of accomplishing this is a bit over my head but is certainly our goal. > > I believe our management is committed to creating such a solution by involving our software engineers. Helping with adding the Solaris RBAC schema and > > contributing the GUI to manage the RBAC Schema data would be a goal. > > > > Also, since this is not the SSSD development list, I would like to know the list info for SSSD development and see what their thoughts are. > > > > Dmitri to answer your questions directly to me: > > Certainly we can discuss additional security components such as centrally managed SSH keys and host fingerprints. We don't need any interaction within our application to include AD, > > but our customers may want to take advantage of that at some point. > The sssd user list is > > sssd-users at lists.fedorahosted.org > > The devel list is > sssd-devel at lists.fedorahosted.org > > > But I suggest we continue this conversation here because otherwise the > conversation might fork and I would be hard to track. Most of the SSSD > developers read this list too. > > Since you have a clearly defined interface your application consumes > from Solaris the best thing now would be for you to provide a man page > style description of the calls the application needs and we will see how > to satisfy them with what we have and identify what needs to be added. > IMO such interface would be a requirement list. How we deliver it to the > application is an important but yes an implementation detail that we can > discuss after we know what requirements are. > Dmitri, We only use one system call from our application. that is chkauthattr - get authorization entry http://www.unix.com/man-page/all/3secdb/chkauthattr/ we have users and roles defined in the user_attr map Each user is assigned one or more profiles. The profiles are kept in the prof_attr map. Top level Profiles can and often are mapped to groups of "sub" profiles, where each of the "sub" profiles are mapped to groups of authorizations. The authorizations are stored in the auth_attr map and map to strings that our application queries to determine if the user/role has mapped to via the profiles that they have been assigned. If the string is contained in the mapping, the chkautattr call returns an allowed response, if not, it returns a denied response to the system call. Example: Authorization check ruid = getuid(); if ((pwp = getpwuid(ruid)) == NULL) crabort(INVALIDUSER); strcpy(real_login, pwp->pw_name); if ((eflag || lflag || rflag) && argc == 1) { if ((pwp = getpwnam(*argv)) == NULL) crabort(INVALIDUSER); if (!chkauthattr("auth_string", real_login)) { if (pwp->pw_uid != ruid) crabort(NOTROOT); else pp = getuser(ruid); } else pp = *argv++; } else { Authorizations An authorization is a unique string that represents a user?s right to perform some operation or class of operations. Authorization definitions are stored in a database called auth_attr(4). For programming authorization checks, only the authorization name is significant. CreatingAuthorization Checks To check authorizations, use the chkauthattr(3SECDB) library function, which verifies whether or not a user has a given authorization. The synopsis is: int chkauthattr(const char *authname, const char *username); The chkauthattr() function checks the policy.conf(4), user_attr(4), and prof_attr(4) databases in order for a match to the given authorization From bret.wortman at damascusgrp.com Tue Feb 19 16:58:53 2013 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Tue, 19 Feb 2013 11:58:53 -0500 Subject: [Freeipa-users] Trouble creating replica In-Reply-To: References: <5123876C.6050201@redhat.com> Message-ID: Digging a bit deeper, I found this in /var/log/pki-ca/catalina.out: : Could not connect to LDAP server host oldmaster.my.com port 7389 Error netscape.ldap.LDAPException: failed to connect to server ldap:// oldmaster.my.com:7389 (91) Feb 19, 2013 11:46:50 AM org.apache.catalina.startup.Catalina stopServer SEVERE: Catalina.stop: java.net.ConnectException: Connection refused at java.net.PlainSocketImpl.socketConnect(Native Method) : : This certainly appears to be a problem, but everyone's authenticating against oldmaster just fine. Thoughts, anyone? * * *Bret Wortman* http://damascusgrp.com/ http://twitter.com/BretWortman On Tue, Feb 19, 2013 at 11:07 AM, Bret Wortman wrote: > Does anyone have an idea why I can't connect, or why this service isn't > running on my freeipa instance? It used to be, because I've created a > replica in the past.... > > > * > * > *Bret Wortman* > > http://damascusgrp.com/ > http://twitter.com/BretWortman > > > On Tue, Feb 19, 2013 at 9:08 AM, John Dennis wrote: > >> On 02/19/2013 06:58 AM, Bret Wortman wrote: >> >>> I have a server running freeipa and I want to migrate it to a new host. >>> I had thought that the easiest way might be to create a replica and load >>> that onto the new host, but this is proving problematic: >>> >>> # ipa-replica-prepare ipamaster.my.com >>> >>> --ip-address 10.0.0.46 >>> Directory Manager (existing master) password: >>> >>> Preparing replica for ipamaster.my.com from >>> oldmaster.my.com >>> >>> Creating SSL certificate for the Directory Server >>> preparation of replica failed: cannot connect to >>> 'https://oldmaster.my.com:**9444/ca/ee/ca/**profileSubmitSSLClient': >>> [Errno >>> -5985] Cannot resolve oldmaster.my.com using >>> >>> family PR_AF_INET6 >>> >>> And then a stack trace follows. >>> >>> # netstat -rn | grep 9444 >>> # lsof -i:9444 >>> # >>> _ >>> _ >>> I've also tried connecting to that URL via Firefox without success. It's >>> just not listening there. What do I need to check? Someone else is >>> running some apps (redmine and others) using Passenger on that server as >>> well; could it be obscuring the port somehow? >>> >>> We're not running IPV6, so I'm not sure why it's being referenced.... >>> >> >> I can't comment on why you can't connect but I can explain the error >> message. It's an internal mistake, if we can't connect we try another >> address family, that logic is incorrect and I thought we had fixed in this >> ticket https://fedorahosted.org/**freeipa/ticket/2695, >> but apparently we didn't. Anyway the error message is a red herring, your >> connection problems lie elsewhere. >> >> -- >> John Dennis >> >> Looking to carve out IT costs? >> www.redhat.com/carveoutcosts/ >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ninibaba at worldd.org Tue Feb 19 17:49:42 2013 From: ninibaba at worldd.org (ninibaba at worldd.org) Date: Tue, 19 Feb 2013 10:49:42 -0700 Subject: [Freeipa-users] KPasswd TCP issues Message-ID: <8f3641f286813dab7b616b63e5d0f4fd.squirrel@box318.bluehost.com> I used IPA from the CentOS 6 repositories and I am having an issue I can't seem to solve. ?I installed a server and a client with no issues, but upon Nessus scans of the server, port 464 kpasswd UDP was flagged for a ping-pong DoS attack. ?With this information I noticed kpasswd also listens on TCP 464 which I understand was used for over-sized requests and other errors. ?I attempted to IPTABLES block UDP for kerberos which resulted in kpasswd no longer functioning from the client. ?Kerberos authentication defaults to TCP without issue, but no matter what i cannot get the client to use TCP for kpasswd. ?Is there a way to force kpasswd on the client to use TCP (i was under the understanding that if UDP failed TCP would be attempted). ?I am running the latest from the CentOS 6 repo's on both server and client. ?Thank you! -------------- next part -------------- An HTML attachment was scrubbed... URL: From natxo.asenjo at gmail.com Tue Feb 19 18:09:13 2013 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Tue, 19 Feb 2013 19:09:13 +0100 Subject: [Freeipa-users] Trouble creating replica In-Reply-To: References: <5123876C.6050201@redhat.com> Message-ID: On Tue, Feb 19, 2013 at 5:58 PM, Bret Wortman wrote: > Digging a bit deeper, I found this in /var/log/pki-ca/catalina.out: > > : > Could not connect to LDAP server host oldmaster.my.com port 7389 Error > netscape.ldap.LDAPException: failed to connect to server ldap:// > oldmaster.my.com:7389 (91) > > This certainly appears to be a problem, but everyone's authenticating > against oldmaster just fine. Thoughts, anyone? > > can you connect to that port (7389) on oldmaster.my.com from the other replica? (try telnetting to the port: telnet oldmaster.my.com 7389) -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Tue Feb 19 18:26:58 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 19 Feb 2013 13:26:58 -0500 Subject: [Freeipa-users] Trouble creating replica In-Reply-To: References: <5123876C.6050201@redhat.com> Message-ID: <5123C3F2.9090205@redhat.com> Natxo Asenjo wrote: > On Tue, Feb 19, 2013 at 5:58 PM, Bret Wortman > > wrote: > > Digging a bit deeper, I found this in /var/log/pki-ca/catalina.out: > > : > Could not connect to LDAP server host oldmaster.my.com > port 7389 Error > netscape.ldap.LDAPException: failed to connect to server > ldap://oldmaster.my.com:7389 (91) > > This certainly appears to be a problem, but everyone's > authenticating against oldmaster just fine. Thoughts, anyone? > > > can you connect to that port (7389) on oldmaster.my.com > from the other replica? (try telnetting to the > port: telnet oldmaster.my.com 7389) 7389 is port in the 389-ds instance used by dogtag. Is the instance running on oldmaster? It isn't used for authentication which is why you aren't seeing problems with clients. rob From bret.wortman at damascusgrp.com Tue Feb 19 19:01:21 2013 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Tue, 19 Feb 2013 14:01:21 -0500 Subject: [Freeipa-users] Trouble creating replica In-Reply-To: <5123C3F2.9090205@redhat.com> References: <5123876C.6050201@redhat.com> <5123C3F2.9090205@redhat.com> Message-ID: No, can't telnet to 7389 or 9444 either one: [root at ipamaster]# telnet oldmaster.my.com 7389 Trying 10.0.0.42... telnet: connect to address 10.0.0.42: COnnection refused [root at ipamaster]# I do note that I only have packages called dogtag-*-theme installed: [root at oldmaster]# yum list "*dogtag*" Loaded plugins: lnagpacks, presto, refresh-packagekit Installed Packages dogtag-pki-ca-theme.noarch 9.0.11-1.fc17 @fedora dogtag-pki-common-theme.noarch 9.0.11-1.fc17 @fedora Available Packages dogtag-pki.noarch 9.0.0-13.fc17 @fedora : I also noticed that, according to /var/log/pki-ca/catalina.out and /var/log/pki-ca/debug, this hasn't successfully run since 05-Feb. And no, I'm not sure what happened on that day to change things, but I'm trying to find out. (At least, I assume this logdir relates to dogtag....) * * *Bret Wortman* http://damascusgrp.com/ http://twitter.com/BretWortman On Tue, Feb 19, 2013 at 1:26 PM, Rob Crittenden wrote: > Natxo Asenjo wrote: > >> On Tue, Feb 19, 2013 at 5:58 PM, Bret Wortman >> >> >> wrote: >> >> Digging a bit deeper, I found this in /var/log/pki-ca/catalina.out: >> >> : >> Could not connect to LDAP server host oldmaster.my.com >> port 7389 Error >> >> netscape.ldap.LDAPException: failed to connect to server >> ldap://oldmaster.my.com:7389 (91) >> >> >> This certainly appears to be a problem, but everyone's >> authenticating against oldmaster just fine. Thoughts, anyone? >> >> >> can you connect to that port (7389) on oldmaster.my.com >> from the other replica? (try telnetting to the >> port: telnet oldmaster.my.com 7389) >> > > 7389 is port in the 389-ds instance used by dogtag. Is the instance > running on oldmaster? > > It isn't used for authentication which is why you aren't seeing problems > with clients. > > 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 gmatz at collective.com Tue Feb 19 19:13:04 2013 From: gmatz at collective.com (Guy Matz) Date: Tue, 19 Feb 2013 14:13:04 -0500 Subject: [Freeipa-users] Do I need/want multiple kerberos realms? Message-ID: <5123CEC0.5020908@collective.com> Hi! FreeIPA newbie here, with experience in DNS & LDAP . . . I am inheriting a FreeIPA installation which needs to expand to multiple datacenters, and was hoping for a little advice. The current freeipa setup uses a subdomain, ny.company.com - with a kerberos realm NY7.COMPANY.COM - and I'm wondering if I want to continue this by creating additional subdomains & realms for the other datacenters, or if I'm better off flattening the namespace to company.com for all datacenters. The reasons to use subdomains are generally: 1. to avoid naming collisions 2. to delegate administration to some other unit. Did I miss anything? I don't plan on doing either of those, so I'm looking to flatten the namespace. Anyone have any thoughts? Especially on the kerberos portion of this question? Thanks a lot!! Guy From nalin at redhat.com Tue Feb 19 20:36:08 2013 From: nalin at redhat.com (Nalin Dahyabhai) Date: Tue, 19 Feb 2013 15:36:08 -0500 Subject: [Freeipa-users] KPasswd TCP issues In-Reply-To: <8f3641f286813dab7b616b63e5d0f4fd.squirrel@box318.bluehost.com> References: <8f3641f286813dab7b616b63e5d0f4fd.squirrel@box318.bluehost.com> Message-ID: <20130219203608.GA26433@redhat.com> On Tue, Feb 19, 2013 at 10:49:42AM -0700, ninibaba at worldd.org wrote: > I used IPA from the CentOS 6 repositories and I am having an issue I > can't seem to solve. ?I installed a server and a client with no > issues, but upon Nessus scans of the server, port 464 kpasswd UDP was > flagged for a ping-pong DoS attack. ?With this information I noticed > kpasswd also listens on TCP 464 which I understand was used for over-sized > requests and other errors. ?I attempted to IPTABLES block UDP for > kerberos which resulted in kpasswd no longer functioning from the client. > ?Kerberos authentication defaults to TCP without issue, but no matter > what i cannot get the client to use TCP for kpasswd. ?Is there a way > to force kpasswd on the client to use TCP (i was under the understanding > that if UDP failed TCP would be attempted). ?I am running the latest > from the CentOS 6 repo's on both server and client. ?Thank you! I just did a spot-check with udp port 464 set to REJECT on my server, with krb5-libs-1.9-33.el6_3.3. It looks like the client is getting an ECONNREFUSED after trying to use the UDP port, and then correctly falling back and opening a TCP connection. Do you have more information about what exactly happens when it fails? What does 'kpasswd' log when it's run with KRB5_TRACE set to /dev/stderr in its environment? Is anything logged to /var/log/kadmind.log on the server when you run 'kpasswd' on the client? Can you try it while using 'tcpdump -s0 -w cap -i any "port 464"' to capture traffic that's passed between the two? Nalin From orion at cora.nwra.com Tue Feb 19 21:38:48 2013 From: orion at cora.nwra.com (Orion Poplawski) Date: Tue, 19 Feb 2013 14:38:48 -0700 Subject: [Freeipa-users] Certificate Issues Message-ID: <5123F0E8.5030008@cora.nwra.com> This is a followup to some previous discussions. I have been lobbying to keep (and fix) the ability to install your own certificates when configuring IPA in order to make use of wildcard SSL certificates. But it seems this will not be the case. My last post on this went unanswered and I see tickets for the removal going forward. As I understand it though, I'll still be able to generate a CSR for the server and get it signed by and external CA? If this is the case, I guess this extra expense of individual SSL certificates for the various IPA servers could be acceptable, although unfortunate as this is what we had hoped to avoid with the wildcard cert. Finally, there was mention of the possibility of getting the IPA CA signed by an external authority. Just to let everyone know, this is a very expensive proposition. I was quoted a $22,500 start fee plus licensing costs. This is *way* out of our (and I suspect many other small businesses) price range. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com From ninibaba at worldd.org Tue Feb 19 21:51:37 2013 From: ninibaba at worldd.org (ninibaba at worldd.org) Date: Tue, 19 Feb 2013 14:51:37 -0700 Subject: [Freeipa-users] KPasswd TCP issues In-Reply-To: <20130219203608.GA26433@redhat.com> References: <8f3641f286813dab7b616b63e5d0f4fd.squirrel@box318.bluehost.com> <20130219203608.GA26433@redhat.com> Message-ID: <40e097b466657496aaa6496dd5d09b4e.squirrel@box318.bluehost.com> > On Tue, Feb 19, 2013 at 10:49:42AM -0700, ninibaba at worldd.org wrote: >> I used IPA from the CentOS 6 repositories and I am having an issue I >> can't seem to solve. ?I installed a server and a client with no >> issues, but upon Nessus scans of the server, port 464 kpasswd UDP was >> flagged for a ping-pong DoS attack. ?With this information I noticed >> kpasswd also listens on TCP 464 which I understand was used for >> over-sized >> requests and other errors. ?I attempted to IPTABLES block UDP for >> kerberos which resulted in kpasswd no longer functioning from the >> client. >> ?Kerberos authentication defaults to TCP without issue, but no matter >> what i cannot get the client to use TCP for kpasswd. ?Is there a way >> to force kpasswd on the client to use TCP (i was under the understanding >> that if UDP failed TCP would be attempted). ?I am running the latest >> from the CentOS 6 repo's on both server and client. ?Thank you! > > I just did a spot-check with udp port 464 set to REJECT on my server, > with krb5-libs-1.9-33.el6_3.3. It looks like the client is getting an > ECONNREFUSED after trying to use the UDP port, and then correctly > falling back and opening a TCP connection. > > Do you have more information about what exactly happens when it fails? > What does 'kpasswd' log when it's run with KRB5_TRACE set to /dev/stderr > in its environment? Is anything logged to /var/log/kadmind.log on the > server when you run 'kpasswd' on the client? Can you try it while using > 'tcpdump -s0 -w cap -i any "port 464"' to capture traffic that's passed > between the two? > > Nalin > ? /FACEPALM So problem solved, I allowed all the necessary ports via IPTABLES, but left the default REJECT rule in that comes by default to handle blocking the UDP port for kpasswd. ?The default Reject rule in this case still answers with prohibited instead of just a normal REJECT set for unreachable. ?Problem solved. ?Thanks for pointing me somewhere =) -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Tue Feb 19 22:10:27 2013 From: simo at redhat.com (Simo Sorce) Date: Tue, 19 Feb 2013 17:10:27 -0500 Subject: [Freeipa-users] Certificate Issues In-Reply-To: <5123F0E8.5030008@cora.nwra.com> References: <5123F0E8.5030008@cora.nwra.com> Message-ID: <1361311827.12328.384.camel@willson.li.ssimo.org> On Tue, 2013-02-19 at 14:38 -0700, Orion Poplawski wrote: > This is a followup to some previous discussions. I have been lobbying to keep > (and fix) the ability to install your own certificates when configuring IPA in > order to make use of wildcard SSL certificates. But it seems this will not be > the case. My last post on this went unanswered and I see tickets for the > removal going forward. > > As I understand it though, I'll still be able to generate a CSR for the server > and get it signed by and external CA? If this is the case, I guess this extra > expense of individual SSL certificates for the various IPA servers could be > acceptable, although unfortunate as this is what we had hoped to avoid with > the wildcard cert. > > Finally, there was mention of the possibility of getting the IPA CA signed by > an external authority. Just to let everyone know, this is a very expensive > proposition. I was quoted a $22,500 start fee plus licensing costs. This is > *way* out of our (and I suspect many other small businesses) price range. Why would you need to get your CA signed by a public authority ? When we say external we generally think of another "Internal CA" that you already use for your own services. Simo. -- Simo Sorce * Red Hat, Inc * New York From orion at cora.nwra.com Tue Feb 19 22:17:22 2013 From: orion at cora.nwra.com (Orion Poplawski) Date: Tue, 19 Feb 2013 15:17:22 -0700 Subject: [Freeipa-users] Certificate Issues In-Reply-To: <1361311827.12328.384.camel@willson.li.ssimo.org> References: <5123F0E8.5030008@cora.nwra.com> <1361311827.12328.384.camel@willson.li.ssimo.org> Message-ID: <5123F9F2.2000303@cora.nwra.com> On 02/19/2013 03:10 PM, Simo Sorce wrote: > On Tue, 2013-02-19 at 14:38 -0700, Orion Poplawski wrote: >> This is a followup to some previous discussions. I have been lobbying to keep >> (and fix) the ability to install your own certificates when configuring IPA in >> order to make use of wildcard SSL certificates. But it seems this will not be >> the case. My last post on this went unanswered and I see tickets for the >> removal going forward. >> >> As I understand it though, I'll still be able to generate a CSR for the server >> and get it signed by and external CA? If this is the case, I guess this extra >> expense of individual SSL certificates for the various IPA servers could be >> acceptable, although unfortunate as this is what we had hoped to avoid with >> the wildcard cert. >> >> Finally, there was mention of the possibility of getting the IPA CA signed by >> an external authority. Just to let everyone know, this is a very expensive >> proposition. I was quoted a $22,500 start fee plus licensing costs. This is >> *way* out of our (and I suspect many other small businesses) price range. > > Why would you need to get your CA signed by a public authority ? > > When we say external we generally think of another "Internal CA" that > you already use for your own services. > > Simo. > > https://www.redhat.com/archives/freeipa-users/2013-January/msg00216.html -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane orion at nwra.com Boulder, CO 80301 http://www.nwra.com From ninibaba at worldd.org Tue Feb 19 22:29:03 2013 From: ninibaba at worldd.org (ninibaba at worldd.org) Date: Tue, 19 Feb 2013 15:29:03 -0700 Subject: [Freeipa-users] KPasswd TCP issues In-Reply-To: <40e097b466657496aaa6496dd5d09b4e.squirrel@box318.bluehost.com> References: <8f3641f286813dab7b616b63e5d0f4fd.squirrel@box318.bluehost.com> <20130219203608.GA26433@redhat.com> <40e097b466657496aaa6496dd5d09b4e.squirrel@box318.bluehost.com> Message-ID: <004fb83b569c173edb651b1e29bb90e2.squirrel@box318.bluehost.com> > > > >> On Tue, Feb 19, 2013 at 10:49:42AM -0700, ninibaba at worldd.org > wrote: > >>> I used IPA from the CentOS 6 repositories and I am having an > issue I > >>> can't seem to solve. ?I installed a server and a client with > no > >>> issues, but upon Nessus scans of the server, port 464 kpasswd UDP > was > >>> flagged for a ping-pong DoS attack. ?With this information I > noticed > >>> kpasswd also listens on TCP 464 which I understand was used > for > >>> over-sized > >>> requests and other errors. ?I attempted to IPTABLES block UDP > for > >>> kerberos which resulted in kpasswd no longer functioning from > the > >>> client. > >>> ?Kerberos authentication defaults to TCP without issue, but no > matter > >>> what i cannot get the client to use TCP for kpasswd. ?Is there a > way > >>> to force kpasswd on the client to use TCP (i was under the > understanding > >>> that if UDP failed TCP would be attempted). ?I am running the > latest > >>> from the CentOS 6 repo's on both server and client. ?Thank > you! > >> > >> I just did a spot-check with udp port 464 set to REJECT on my > server, > >> with krb5-libs-1.9-33.el6_3.3. It looks like the client is getting > an > >> ECONNREFUSED after trying to use the UDP port, and then correctly > >> falling back and opening a TCP connection. > >> > >> Do you have more information about what exactly happens when it > fails? > >> What does 'kpasswd' log when it's run with KRB5_TRACE set to > /dev/stderr > >> in its environment? Is anything logged to /var/log/kadmind.log on > the > >> server when you run 'kpasswd' on the client? Can you try it while > using > >> 'tcpdump -s0 -w cap -i any "port 464"' to capture traffic > that's passed > >> between the two? > >> > >> Nalin > >> > ??? > /FACEPALM > So problem solved, I allowed all > the necessary ports via IPTABLES, but left the default REJECT rule in that > comes by default to handle blocking the UDP port for kpasswd. ???The > default Reject rule in this case still answers with prohibited instead of > just a normal REJECT set for unreachable. ???Problem solved. > ???Thanks for pointing me somewhere =) > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users ? ? Actually i'd like to take that back now, it works fine when running kpasswd, but if user password is expired when SSH to client, during the reset it only tried UDP same if issuing passwd command as well. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Tue Feb 19 22:42:41 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 19 Feb 2013 17:42:41 -0500 Subject: [Freeipa-users] Certificate Issues In-Reply-To: <5123F9F2.2000303@cora.nwra.com> References: <5123F0E8.5030008@cora.nwra.com> <1361311827.12328.384.camel@willson.li.ssimo.org> <5123F9F2.2000303@cora.nwra.com> Message-ID: <5123FFE1.5000609@redhat.com> Orion Poplawski wrote: > On 02/19/2013 03:10 PM, Simo Sorce wrote: >> On Tue, 2013-02-19 at 14:38 -0700, Orion Poplawski wrote: >>> This is a followup to some previous discussions. I have been >>> lobbying to keep >>> (and fix) the ability to install your own certificates when >>> configuring IPA in >>> order to make use of wildcard SSL certificates. But it seems this >>> will not be >>> the case. My last post on this went unanswered and I see tickets for >>> the >>> removal going forward. >>> >>> As I understand it though, I'll still be able to generate a CSR for >>> the server >>> and get it signed by and external CA? If this is the case, I guess >>> this extra >>> expense of individual SSL certificates for the various IPA servers >>> could be >>> acceptable, although unfortunate as this is what we had hoped to >>> avoid with >>> the wildcard cert. >>> >>> Finally, there was mention of the possibility of getting the IPA CA >>> signed by >>> an external authority. Just to let everyone know, this is a very >>> expensive >>> proposition. I was quoted a $22,500 start fee plus licensing costs. >>> This is >>> *way* out of our (and I suspect many other small businesses) price >>> range. >> >> Why would you need to get your CA signed by a public authority ? >> >> When we say external we generally think of another "Internal CA" that >> you already use for your own services. >> >> Simo. >> >> > https://www.redhat.com/archives/freeipa-users/2013-January/msg00216.html > The problems with this are: - Only a very small handful of people actually use this (or used it). - We don't test this (obviously) and there are a lot of bugs and corner cases - Even if we do fix it, we likely still won't test it very often, leading to more woes - This will blow up at cert renewal time - There is still an underlying CA hidden in there, doing nothing (but perhaps cause problems) - If you want to support FF < 15 you need an object signing cert too to sign the auto-configure jar A far better solution than replacing the certificates post-install is to have an option to have a CA-less IPA installation. I doubt we'd actively work on adding such an option. But it would likely be a lot more robust than changing things after-the-fact. rob From dpal at redhat.com Wed Feb 20 02:05:39 2013 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 19 Feb 2013 21:05:39 -0500 Subject: [Freeipa-users] RHEL6 IPA and Active Directory synchronisation and Solaris RBAC In-Reply-To: <1361283261.21935.914.camel@osc145.evn.harris.com> References: <511BACEE.8050900@redhat.com> <511D2541.1000201@nixtra.com> <511D2CAC.6050400@redhat.com> <511D4693.8010502@redhat.com> <1360937840.21935.556.camel@osc145.evn.harris.com> <511EA93C.8060909@redhat.com>, <511F6D98.30700@nixtra.com> <512A3AF8DAE8454D95C05141F746ECE1512AC316@MLBMXUS21.cs.myharris.net> <512121E9.2050608@redhat.com> <1361283261.21935.914.camel@osc145.evn.harris.com> Message-ID: <51242F73.9000309@redhat.com> On 02/19/2013 09:14 AM, Rodney L. Mercer wrote: > > On Sun, 2013-02-17 at 13:31 -0500, Dmitri Pal wrote: >> On 02/16/2013 12:14 PM, Mercer, Rodney wrote: >>> ________________________________________ >>> From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Sigbjorn Lie [sigbjorn at nixtra.com] >>> Sent: Saturday, February 16, 2013 6:29 AM >>> To: freeipa-users at redhat.com >>> Subject: Re: [Freeipa-users] RHEL6 IPA and Active Directory synchronisation and Solaris RBAC >>> >>> On 02/15/2013 10:31 PM, Dmitri Pal wrote: >>>> On 02/15/2013 09:17 AM, Rodney L. Mercer wrote: >>>>> On Thu, 2013-02-14 at 21:44 +0100, Sigbjorn Lie wrote: >>>>>> I agree with schema support being enough for now. I do not expect the >>>>>> ipa mgmt tools to support Solaris rbac mgmt. >>>>>> >>>>>> The ipa mgmt tools are great, but I already have other data in the ipa >>>>>> ldap that I have to manage manually anyway. >>>>>> >>>>>> >>>>>> >>>>>> Rgds, >>>>>> Siggi >>>>>> >>>>>> >>>>>> >>>>>> Rob Crittenden wrote: >>>>>> Dag Wieers wrote: >>>>>> On Thu, 14 Feb 2013, Rob Crittenden wrote: >>>>>> >>>>>> Sigbjorn Lie wrote: >>>>>> On 02/13/2013 04:10 PM, Rob Crittenden wrote: >>>>>> >>>>>> Also since we also require compatibility with Solaris, and roles >>>>>> (RBAC) >>>>>> is currently used on Solaris, does IPA support RBAC on Solar >>>>>> is ? >>>>>> (We >>>>>> noticed that RBAC mentioned in the IPA web interface only >>>>>> relates to > > IPA >>>>>> management). >>>>>> No, IPA doesn't support RBAC on Solaris. >>>>>> >>>>>> I've come across the same issue. This is just a matter of extending the >>>>>> schema. >>>>>> >>>>>> Would there be any interest for adding the Solaris RBAC schema as a >>>>>> part >>>>>> of the standard IPA distributed LDAP schema? >>>>> Consider the following: What else would have to be put in to support >>>>> this? >>>>> Once the schema is established, can SSSD be extended to use this and >>>>> potentially be referenced in nsswitch.conf as it is implemented on >>>>> Solaris? IE: >>>>> tail -5 /etc/nsswitch.conf >>>>> user_attr: sssd >>>>> auth_attr: sssd >>>>> prof_attr: sssd >>>>> exec_attr: sssd >>>>> project: sssd >>>> Before we define how it is passed/exposed it would nice to understand >>>> who on Linux will be consuming it out of SSSD? >>>> >>> I don't think Linux would consume these attributes. They are specific to >>> the Role Based Access Control solution implemented in Solaris. >>> >>> >>> Rgds, >>> Siggi >>> >>> ---------------------------------- >>> >>> Yes, I understand that Linux has no mechanism currently built in to consume these Solaris name server switch attributes. But, If the Solaris RBAC schema is included as >>> part of the standard IPA distributed LDAP schema, My question is how hard would it be to create an extension using SSSD/pam to do so? >>> >>> I agree that it is too much to ask for a full Solaris style RBAC implementation on RHEL. >>> >>> We have an application that currently uses the Solaris RBAC structure to authorize user/role accesses within the application. >>> >>> Our goal is to use existing OS calls or possibly extending SSSD to allow system calls that would give us back an answer to attrbutes placed within the LDAP >>> tree that are composed in like fashion as how they are stored in Solaris. Defining the schema seemed to be well received and I understand that it is intended that it would be there to support Solaris clients. >>> If SSSD could be extended to access these attributes and possibly pam modules to allow Linux clients to take advantage of this RBAC schema, then our application could perform as it does on Solaris. It would also >>> open up the opportunity for other vendors to consider moving their Solaris RBAC applications to RHEL. >>> >>> I think with that as a goal, we could then create users and SELinux roles that are defined within the RBAC based schema much like our current Solaris implementation. >>> We use Solaris nsswitch calls to get yes/no authorization answers for user/role privilege within our application. >>> >>> Since IdM and SSD already support >>> a) HBAC >>> b) SUDO >>> c) SELinux user mapping >>> >>> I believe HBAC as already implemented in IdM will be an additional asset in defining and restricting access that can be used by our customers. >>> We have decided to move away from sudo, but may reconsider some of its uses if it suits the situation. >>> Maybe SSSD can be extended to access the RBAC schema in much the same way that it accesses SUDO or HBAC schema? >>> >>> We have decided to use RHEL as the primary OS platform of choice going forward and we need to create a solution to our application RBAC >>> needs similar to that in which we have accomplished with Solaris. I have been speaking with Dmitri on the side about these possibilities and would like to know >>> what each of your thoughts are. The feasibility of accomplishing this is a bit over my head but is certainly our goal. >>> I believe our management is committed to creating such a solution by involving our software engineers. Helping with adding the Solaris RBAC schema and >>> contributing the GUI to manage the RBAC Schema data would be a goal. >>> >>> Also, since this is not the SSSD development list, I would like to know the list info for SSSD development and see what their thoughts are. >>> >>> Dmitri to answer your questions directly to me: >>> Certainly we can discuss additional security components such as centrally managed SSH keys and host fingerprints. We don't need any interaction within our application to include AD, >>> but our customers may want to take advantage of that at some point. >> The sssd user list is >> >> sssd-users at lists.fedorahosted.org >> >> The devel list is >> sssd-devel at lists.fedorahosted.org >> >> >> But I suggest we continue this conversation here because otherwise the >> conversation might fork and I would be hard to track. Most of the SSSD >> developers read this list too. >> >> Since you have a clearly defined interface your application consumes >> from Solaris the best thing now would be for you to provide a man page >> style description of the calls the application needs and we will see how >> to satisfy them with what we have and identify what needs to be added. >> IMO such interface would be a requirement list. How we deliver it to the >> application is an important but yes an implementation detail that we can >> discuss after we know what requirements are. >> > Dmitri, > > We only use one system call from our application. that is > chkauthattr - get authorization entry > http://www.unix.com/man-page/all/3secdb/chkauthattr/ > > we have users and roles defined in the user_attr map > Each user is assigned one or more profiles. > > The profiles are kept in the prof_attr map. > Top level Profiles can and often are mapped to groups of "sub" profiles, > where each of the "sub" profiles are mapped to groups of authorizations. > > The authorizations are stored in the auth_attr map and map to strings > that our application queries to determine if the user/role has mapped > to via the profiles that they have been assigned. > > If the string is contained in the mapping, the chkautattr call returns > an allowed response, if not, it returns a denied response to the system > call. > > > Example: Authorization check > > ruid = getuid(); > if ((pwp = getpwuid(ruid)) == NULL) > crabort(INVALIDUSER); > > strcpy(real_login, pwp->pw_name); > > if ((eflag || lflag || rflag) && argc == 1) { > if ((pwp = getpwnam(*argv)) == NULL) > crabort(INVALIDUSER); > > if (!chkauthattr("auth_string", real_login)) { > if (pwp->pw_uid != ruid) > crabort(NOTROOT); > else > pp = getuser(ruid); > } else > pp = *argv++; > } else { > > > > Authorizations > An authorization is a unique string that represents a user?s right to > perform some operation or class > of operations. Authorization definitions are stored in a database called > auth_attr(4). For > programming authorization checks, only the authorization name is > significant. > > CreatingAuthorization Checks > > To check authorizations, use the chkauthattr(3SECDB) library function, > which verifies whether > or not a user has a given authorization. The synopsis is: > > int chkauthattr(const char *authname, const char *username); > > The chkauthattr() function checks the policy.conf(4), user_attr(4), and > prof_attr(4) > databases in order for a match to the given authorization > > OK, this is helpful. It seems that we would have to implement the whole interface anyways for completeness or you think that implementing functions other than chkauthattr() would not be required? How common is this use of the RBAC? Is is this how it is usually done or it is a one off implementation and in general in Solaris world people use RBAC information differently or to the greater extent? I want to understand the scope of the solution. Would that be a one off that would work just for your application's use or RBAC or it would work for most of the Solaris applications that use RBAC. Is this the schema we are talking about: http://docs.oracle.com/cd/E19455-01/806-5580/appendixa-8/index.html The schema uses 4 different object classes but the functions mentioned above seem to deal only with the SolarisUserAttr and SolarisProfAttr object classes. What about other two: SolarisAuthAttr & SolarisExecAttr? Are they used or we do not need these on the server? IMO we have a good starting point to have a design page created by you. Here is the template and here are some guidelines that might be helpful when building a design page. http://www.freeipa.org/page/Feature_template http://www.freeipa.org/page/General_considerations Here is an example of the design that might give you some inspiration (not everything mentioned in those pages ended up being implemented but it gives a good hint of what needs to be covered in the design page) . http://www.freeipa.org/page/V2/DS_Design_Summary_2 (see roles section) http://www.freeipa.org/page/Overall_Design_of_Policy_Related_Components#Roles www.freeipa.org/page/V2/IPA_Client_Design_Overview Good luck! -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Wed Feb 20 02:17:41 2013 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 19 Feb 2013 21:17:41 -0500 Subject: [Freeipa-users] Do I need/want multiple kerberos realms? In-Reply-To: <5123CEC0.5020908@collective.com> References: <5123CEC0.5020908@collective.com> Message-ID: <51243245.60908@redhat.com> On 02/19/2013 02:13 PM, Guy Matz wrote: > Hi! FreeIPA newbie here, with experience in DNS & LDAP . . . > > I am inheriting a FreeIPA installation which needs to expand to > multiple datacenters, and was hoping for a little advice. The current > freeipa setup uses a subdomain, ny.company.com - with a kerberos realm > NY7.COMPANY.COM - and I'm wondering if I want to continue this by > creating additional subdomains & realms for the other datacenters, or > if I'm better off flattening the namespace to company.com for all > datacenters. > > The reasons to use subdomains are generally: > 1. to avoid naming collisions > 2. to delegate administration to some other unit. > > Did I miss anything? I don't plan on doing either of those, so I'm > looking to flatten the namespace. Anyone have any thoughts? > Especially on the kerberos portion of this question? Thanks a lot!! > > Guy IPA does not support multiple kerberos realms yet. In IPA case DNS domain might not match kerberos domain so AFAIU (and please correct me if I am wrong) you can use one Kerberos realm with multiple DNS sobdomains for different offices. And with the latest changes in IPA 3.0 you should be able to delegate administration of the DNS zones to other admins. > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Wed Feb 20 02:31:27 2013 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 19 Feb 2013 21:31:27 -0500 Subject: [Freeipa-users] Certificate Issues In-Reply-To: <5123FFE1.5000609@redhat.com> References: <5123F0E8.5030008@cora.nwra.com> <1361311827.12328.384.camel@willson.li.ssimo.org> <5123F9F2.2000303@cora.nwra.com> <5123FFE1.5000609@redhat.com> Message-ID: <5124357F.8070809@redhat.com> On 02/19/2013 05:42 PM, Rob Crittenden wrote: > Orion Poplawski wrote: >> On 02/19/2013 03:10 PM, Simo Sorce wrote: >>> On Tue, 2013-02-19 at 14:38 -0700, Orion Poplawski wrote: >>>> This is a followup to some previous discussions. I have been >>>> lobbying to keep >>>> (and fix) the ability to install your own certificates when >>>> configuring IPA in >>>> order to make use of wildcard SSL certificates. But it seems this >>>> will not be >>>> the case. My last post on this went unanswered and I see tickets for >>>> the >>>> removal going forward. >>>> >>>> As I understand it though, I'll still be able to generate a CSR for >>>> the server >>>> and get it signed by and external CA? If this is the case, I guess >>>> this extra >>>> expense of individual SSL certificates for the various IPA servers >>>> could be >>>> acceptable, although unfortunate as this is what we had hoped to >>>> avoid with >>>> the wildcard cert. >>>> >>>> Finally, there was mention of the possibility of getting the IPA CA >>>> signed by >>>> an external authority. Just to let everyone know, this is a very >>>> expensive >>>> proposition. I was quoted a $22,500 start fee plus licensing costs. >>>> This is >>>> *way* out of our (and I suspect many other small businesses) price >>>> range. >>> >>> Why would you need to get your CA signed by a public authority ? >>> >>> When we say external we generally think of another "Internal CA" that >>> you already use for your own services. >>> >>> Simo. >>> >>> >> https://www.redhat.com/archives/freeipa-users/2013-January/msg00216.html >> > > The problems with this are: > > - Only a very small handful of people actually use this (or used it). > - We don't test this (obviously) and there are a lot of bugs and > corner cases > - Even if we do fix it, we likely still won't test it very often, > leading to more woes > - This will blow up at cert renewal time > - There is still an underlying CA hidden in there, doing nothing (but > perhaps cause problems) > - If you want to support FF < 15 you need an object signing cert too > to sign the auto-configure jar > > A far better solution than replacing the certificates post-install is > to have an option to have a CA-less IPA installation. I doubt we'd > actively work on adding such an option. But it would likely be a lot > more robust than changing things after-the-fact. IMO this should eventually help https://fedoraproject.org/wiki/Features/SharedSystemCertificates Once this is solved the right certs can probably be delivered via OpenLMI or SSSD so rather than using already distributed certs it would be possible to easily distribute and apply the ones you need. Solves the problem but from a different side. Orion, if implemented would it work for you? > > 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 for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From orion at cora.nwra.com Wed Feb 20 03:18:40 2013 From: orion at cora.nwra.com (Orion Poplawski) Date: Tue, 19 Feb 2013 20:18:40 -0700 Subject: [Freeipa-users] Certificate Issues In-Reply-To: <5124357F.8070809@redhat.com> References: <5123F0E8.5030008@cora.nwra.com> <1361311827.12328.384.camel@willson.li.ssimo.org> <5123F9F2.2000303@cora.nwra.com> <5123FFE1.5000609@redhat.com> <5124357F.8070809@redhat.com> Message-ID: <51244090.9050509@cora.nwra.com> On 02/19/2013 07:31 PM, Dmitri Pal wrote: > IMO this should eventually help > https://fedoraproject.org/wiki/Features/SharedSystemCertificates > Once this is solved the right certs can probably be delivered via > OpenLMI or SSSD so rather than using already distributed certs it would > be possible to easily distribute and apply the ones you need. > Solves the problem but from a different side. > Orion, if implemented would it work for you? My biggest concerns are Windows and OS X clients. Probably need to look at the various mozilla deployment tools. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From pspacek at redhat.com Wed Feb 20 08:32:57 2013 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 20 Feb 2013 09:32:57 +0100 Subject: [Freeipa-users] KPasswd TCP issues In-Reply-To: <004fb83b569c173edb651b1e29bb90e2.squirrel@box318.bluehost.com> References: <8f3641f286813dab7b616b63e5d0f4fd.squirrel@box318.bluehost.com> <20130219203608.GA26433@redhat.com> <40e097b466657496aaa6496dd5d09b4e.squirrel@box318.bluehost.com> <004fb83b569c173edb651b1e29bb90e2.squirrel@box318.bluehost.com> Message-ID: <51248A39.5040001@redhat.com> On 19.2.2013 23:29, ninibaba at worldd.org wrote: > > > > > > > >> On Tue, Feb 19, 2013 at 10:49:42AM -0700, ninibaba at worldd.org > > wrote: > > > >>> I used IPA from the CentOS 6 repositories and I am having an > > issue I > > > >>> can't seem to solve. ?I installed a server and a client with > > no > > > >>> issues, but upon Nessus scans of the server, port 464 kpasswd UDP > > was > > > >>> flagged for a ping-pong DoS attack. ?With this information I > > noticed > > > >>> kpasswd also listens on TCP 464 which I understand was used > > for > > > >>> over-sized > > > >>> requests and other errors. ?I attempted to IPTABLES block UDP > > for > > > >>> kerberos which resulted in kpasswd no longer functioning from > > the > > > >>> client. > > > >>> ?Kerberos authentication defaults to TCP without issue, but no > > matter > > > >>> what i cannot get the client to use TCP for kpasswd. ?Is there a > > way > > > >>> to force kpasswd on the client to use TCP (i was under the > > understanding > > > >>> that if UDP failed TCP would be attempted). ?I am running the > > latest > > > >>> from the CentOS 6 repo's on both server and client. ?Thank > > you! > > > >> > > > >> I just did a spot-check with udp port 464 set to REJECT on my > > server, > > > >> with krb5-libs-1.9-33.el6_3.3. It looks like the client is getting > > an > > > >> ECONNREFUSED after trying to use the UDP port, and then correctly > > > >> falling back and opening a TCP connection. > > > >> > > > >> Do you have more information about what exactly happens when it > > fails? > > > >> What does 'kpasswd' log when it's run with KRB5_TRACE set to > > /dev/stderr > > > >> in its environment? Is anything logged to /var/log/kadmind.log on > > the > > > >> server when you run 'kpasswd' on the client? Can you try it while > > using > > > >> 'tcpdump -s0 -w cap -i any "port 464"' to capture traffic > > that's passed > > > >> between the two? > > > >> > > > >> Nalin > > > >> > > ? > > /FACEPALM > > So problem solved, I allowed all > > the necessary ports via IPTABLES, but left the default REJECT rule in that > > comes by default to handle blocking the UDP port for kpasswd. ?The > > default Reject rule in this case still answers with prohibited instead of > > just a normal REJECT set for unreachable. ?Problem solved. > > ?Thanks for pointing me somewhere =) > > > Actually i'd like to take that back now, it works fine when running kpasswd, > but if user password is expired when SSH to client, during the reset it only > tried UDP same if issuing passwd command as well. I would recommend to completely remove SRV records for kpasswd over UDP (in case you blocked kpasswd over UDP for all clients). # ipa dnsrecord-del example.com _kpasswd._udp This should prevent clients from even trying UDP. Don't forget to DNS amplification attacks if you are paranoid :-) -- Petr^2 Spacek From sbose at redhat.com Wed Feb 20 08:48:03 2013 From: sbose at redhat.com (Sumit Bose) Date: Wed, 20 Feb 2013 09:48:03 +0100 Subject: [Freeipa-users] KPasswd TCP issues In-Reply-To: <004fb83b569c173edb651b1e29bb90e2.squirrel@box318.bluehost.com> References: <8f3641f286813dab7b616b63e5d0f4fd.squirrel@box318.bluehost.com> <20130219203608.GA26433@redhat.com> <40e097b466657496aaa6496dd5d09b4e.squirrel@box318.bluehost.com> <004fb83b569c173edb651b1e29bb90e2.squirrel@box318.bluehost.com> Message-ID: <20130220084803.GO27418@localhost.localdomain> On Tue, Feb 19, 2013 at 03:29:03PM -0700, ninibaba at worldd.org wrote: > > > ? > ? > Actually > i'd like to take that back now, it works fine when running kpasswd, but if > user password is expired when SSH to client, during the reset it only > tried UDP same if issuing passwd command as well. Both use sssd here which in theory should behave as kpasswd. Can you run sssd with a high debug level, run the passwd command again and send logs? If you prefer you can send them as PM to me. Most interesting would be krb5_child.log but the others miht be useful as well. bye, Sumit > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From bret.wortman at damascusgrp.com Wed Feb 20 13:08:17 2013 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Wed, 20 Feb 2013 08:08:17 -0500 Subject: [Freeipa-users] Trouble creating replica In-Reply-To: References: <5123876C.6050201@redhat.com> <5123C3F2.9090205@redhat.com> Message-ID: Digging further into my logs this morning, I've discovered that there's no new entries in /var/log/dirsrv/slapd-PKI-IPA since Feb 5 either. How can I tell why this isn't running? /var/log/dirsrv/slapd-MY-COM is getting updated and logged to, it's just the PKI piece that seems to be dead. Nothing in /etc/pki-ca has changed since last year, and the last updates to /var/lib/dirsrv/slapd-PKI-IPA/db or changelogs occurred on Feb 5. I just can't tell what that change was.... Would a key change or certificate change have affected this? Worst case, if I do something like this: # ipa-server-install -U --uninstall # ipa-server-install will I lose the hosts, policies & users I already have configured? Does this stand a chance of getting me back up to where I can clone this box and get healthy again? * * *Bret Wortman* http://damascusgrp.com/ http://twitter.com/BretWortman On Tue, Feb 19, 2013 at 2:01 PM, Bret Wortman wrote: > No, can't telnet to 7389 or 9444 either one: > > [root at ipamaster]# telnet oldmaster.my.com 7389 > Trying 10.0.0.42... > telnet: connect to address 10.0.0.42: COnnection refused > [root at ipamaster]# > > I do note that I only have packages called dogtag-*-theme installed: > > [root at oldmaster]# yum list "*dogtag*" > Loaded plugins: lnagpacks, presto, refresh-packagekit > Installed Packages > dogtag-pki-ca-theme.noarch 9.0.11-1.fc17 > @fedora > dogtag-pki-common-theme.noarch 9.0.11-1.fc17 > @fedora > Available Packages > dogtag-pki.noarch 9.0.0-13.fc17 > @fedora > : > > I also noticed that, according to /var/log/pki-ca/catalina.out and > /var/log/pki-ca/debug, this hasn't successfully run since 05-Feb. And no, > I'm not sure what happened on that day to change things, but I'm trying to > find out. (At least, I assume this logdir relates to dogtag....) > > > > * > * > *Bret Wortman* > > http://damascusgrp.com/ > http://twitter.com/BretWortman > > > On Tue, Feb 19, 2013 at 1:26 PM, Rob Crittenden wrote: > >> Natxo Asenjo wrote: >> >>> On Tue, Feb 19, 2013 at 5:58 PM, Bret Wortman >>> >> >>> wrote: >>> >>> Digging a bit deeper, I found this in /var/log/pki-ca/catalina.out: >>> >>> : >>> Could not connect to LDAP server host oldmaster.my.com >>> port 7389 Error >>> >>> netscape.ldap.LDAPException: failed to connect to server >>> ldap://oldmaster.my.com:7389 (91) >>> >>> >>> This certainly appears to be a problem, but everyone's >>> authenticating against oldmaster just fine. Thoughts, anyone? >>> >>> >>> can you connect to that port (7389) on oldmaster.my.com >>> from the other replica? (try telnetting to the >>> port: telnet oldmaster.my.com 7389) >>> >> >> 7389 is port in the 389-ds instance used by dogtag. Is the instance >> running on oldmaster? >> >> It isn't used for authentication which is why you aren't seeing problems >> with clients. >> >> 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 bret.wortman at damascusgrp.com Wed Feb 20 13:39:08 2013 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Wed, 20 Feb 2013 08:39:08 -0500 Subject: [Freeipa-users] Trouble creating replica In-Reply-To: References: <5123876C.6050201@redhat.com> <5123C3F2.9090205@redhat.com> Message-ID: And just in case this is informative: [root at oldmaster]# pkicontrol start ca PKI-IPA PKI-IPA is an invalid 'pki-ca' instance [root at oldmaster]# * * *Bret Wortman* http://damascusgrp.com/ http://twitter.com/BretWortman On Wed, Feb 20, 2013 at 8:08 AM, Bret Wortman wrote: > Digging further into my logs this morning, I've discovered that there's no > new entries in /var/log/dirsrv/slapd-PKI-IPA since Feb 5 either. How can I > tell why this isn't running? /var/log/dirsrv/slapd-MY-COM is getting > updated and logged to, it's just the PKI piece that seems to be dead. > > Nothing in /etc/pki-ca has changed since last year, and the last updates > to /var/lib/dirsrv/slapd-PKI-IPA/db or changelogs occurred on Feb 5. I just > can't tell what that change was.... > > Would a key change or certificate change have affected this? > > Worst case, if I do something like this: > > # ipa-server-install -U --uninstall > # ipa-server-install > > will I lose the hosts, policies & users I already have configured? Does > this stand a chance of getting me back up to where I can clone this box and > get healthy again? > > > * > * > *Bret Wortman* > > http://damascusgrp.com/ > http://twitter.com/BretWortman > > > On Tue, Feb 19, 2013 at 2:01 PM, Bret Wortman < > bret.wortman at damascusgrp.com> wrote: > >> No, can't telnet to 7389 or 9444 either one: >> >> [root at ipamaster]# telnet oldmaster.my.com 7389 >> Trying 10.0.0.42... >> telnet: connect to address 10.0.0.42: COnnection refused >> [root at ipamaster]# >> >> I do note that I only have packages called dogtag-*-theme installed: >> >> [root at oldmaster]# yum list "*dogtag*" >> Loaded plugins: lnagpacks, presto, refresh-packagekit >> Installed Packages >> dogtag-pki-ca-theme.noarch 9.0.11-1.fc17 >> @fedora >> dogtag-pki-common-theme.noarch 9.0.11-1.fc17 >> @fedora >> Available Packages >> dogtag-pki.noarch 9.0.0-13.fc17 >> @fedora >> : >> >> I also noticed that, according to /var/log/pki-ca/catalina.out and >> /var/log/pki-ca/debug, this hasn't successfully run since 05-Feb. And no, >> I'm not sure what happened on that day to change things, but I'm trying to >> find out. (At least, I assume this logdir relates to dogtag....) >> >> >> >> * >> * >> *Bret Wortman* >> >> http://damascusgrp.com/ >> http://twitter.com/BretWortman >> >> >> On Tue, Feb 19, 2013 at 1:26 PM, Rob Crittenden wrote: >> >>> Natxo Asenjo wrote: >>> >>>> On Tue, Feb 19, 2013 at 5:58 PM, Bret Wortman >>>> >> >>>> wrote: >>>> >>>> Digging a bit deeper, I found this in /var/log/pki-ca/catalina.out: >>>> >>>> : >>>> Could not connect to LDAP server host oldmaster.my.com >>>> port 7389 Error >>>> >>>> netscape.ldap.LDAPException: failed to connect to server >>>> ldap://oldmaster.my.com:7389 (91) >>>> >>>> >>>> This certainly appears to be a problem, but everyone's >>>> authenticating against oldmaster just fine. Thoughts, anyone? >>>> >>>> >>>> can you connect to that port (7389) on oldmaster.my.com >>>> from the other replica? (try telnetting to >>>> the >>>> port: telnet oldmaster.my.com 7389) >>>> >>> >>> 7389 is port in the 389-ds instance used by dogtag. Is the instance >>> running on oldmaster? >>> >>> It isn't used for authentication which is why you aren't seeing problems >>> with clients. >>> >>> 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 simo at redhat.com Wed Feb 20 13:40:38 2013 From: simo at redhat.com (Simo Sorce) Date: Wed, 20 Feb 2013 08:40:38 -0500 Subject: [Freeipa-users] Trouble creating replica In-Reply-To: References: <5123876C.6050201@redhat.com> <5123C3F2.9090205@redhat.com> Message-ID: <1361367638.12328.394.camel@willson.li.ssimo.org> On Wed, 2013-02-20 at 08:08 -0500, Bret Wortman wrote: > Digging further into my logs this morning, I've discovered that > there's no new entries in /var/log/dirsrv/slapd-PKI-IPA since Feb 5 > either. How can I tell why this isn't > running? /var/log/dirsrv/slapd-MY-COM is getting updated and logged > to, it's just the PKI piece that seems to be dead. > > > Nothing in /etc/pki-ca has changed since last year, and the last > updates to /var/lib/dirsrv/slapd-PKI-IPA/db or changelogs occurred on > Feb 5. I just can't tell what that change was.... What error do you get if you try to start it ? > > Would a key change or certificate change have affected this? An expired CA cert might cause the server to stop, but then you would see expired certs all over and also the main IPA instance would not start. > > Worst case, if I do something like this: > > > # ipa-server-install -U --uninstall > # ipa-server-install > You will completely obliterate all your data. > will I lose the hosts, policies & users I already have configured? > Does this stand a chance of getting me back up to where I can clone > this box and get healthy again? > Healthy will be, but with no data, don't do it. (and I suggest you make a full backup just in case) Simo. -- Simo Sorce * Red Hat, Inc * New York From bret.wortman at damascusgrp.com Wed Feb 20 13:43:00 2013 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Wed, 20 Feb 2013 08:43:00 -0500 Subject: [Freeipa-users] Trouble creating replica In-Reply-To: <1361367638.12328.394.camel@willson.li.ssimo.org> References: <5123876C.6050201@redhat.com> <5123C3F2.9090205@redhat.com> <1361367638.12328.394.camel@willson.li.ssimo.org> Message-ID: On Wed, Feb 20, 2013 at 8:40 AM, Simo Sorce wrote: > On Wed, 2013-02-20 at 08:08 -0500, Bret Wortman wrote: > > Digging further into my logs this morning, I've discovered that > > there's no new entries in /var/log/dirsrv/slapd-PKI-IPA since Feb 5 > > either. How can I tell why this isn't > > running? /var/log/dirsrv/slapd-MY-COM is getting updated and logged > > to, it's just the PKI piece that seems to be dead. > > > > > > Nothing in /etc/pki-ca has changed since last year, and the last > > updates to /var/lib/dirsrv/slapd-PKI-IPA/db or changelogs occurred on > > Feb 5. I just can't tell what that change was.... > > What error do you get if you try to start it ? > [root at oldmaster]# pkicontrol start ca PKI-IPA PKI-IPA is an invalid 'pki-ca' instance [root at oldmaster]# Is there another, preferred way to start it? > > > > Would a key change or certificate change have affected this? > > An expired CA cert might cause the server to stop, but then you would > see expired certs all over and also the main IPA instance would not > start. > > > > Worst case, if I do something like this: > > > > > > # ipa-server-install -U --uninstall > > # ipa-server-install > > > You will completely obliterate all your data. > > > will I lose the hosts, policies & users I already have configured? > > Does this stand a chance of getting me back up to where I can clone > > this box and get healthy again? > > > Healthy will be, but with no data, don't do it. (and I suggest you make > a full backup just in case) > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmercer at harris.com Wed Feb 20 13:44:54 2013 From: rmercer at harris.com (Rodney L. Mercer) Date: Wed, 20 Feb 2013 08:44:54 -0500 Subject: [Freeipa-users] RHEL6 IPA and Active Directory synchronisation and Solaris RBAC In-Reply-To: <51242F73.9000309@redhat.com> References: <511BACEE.8050900@redhat.com> <511D2541.1000201@nixtra.com> <511D2CAC.6050400@redhat.com> <511D4693.8010502@redhat.com> <1360937840.21935.556.camel@osc145.evn.harris.com> <511EA93C.8060909@redhat.com>,<511F6D98.30700@nixtra.com> <512A3AF8DAE8454D95C05141F746ECE1512AC316@MLBMXUS21.cs.myharris.net> <512121E9.2050608@redhat.com> <1361283261.21935.914.camel@osc145.evn.harris.com> <51242F73.9000309@redhat.com> Message-ID: <1361367894.21935.1033.camel@osc145.evn.harris.com> On Tue, 2013-02-19 at 21:05 -0500, Dmitri Pal wrote: > On 02/19/2013 09:14 AM, Rodney L. Mercer wrote: > > > > On Sun, 2013-02-17 at 13:31 -0500, Dmitri Pal wrote: > >> On 02/16/2013 12:14 PM, Mercer, Rodney wrote: > >>> ________________________________________ > >>> From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Sigbjorn Lie [sigbjorn at nixtra.com] > >>> Sent: Saturday, February 16, 2013 6:29 AM > >>> To: freeipa-users at redhat.com > >>> Subject: Re: [Freeipa-users] RHEL6 IPA and Active Directory synchronisation and Solaris RBAC > >>> > >>> On 02/15/2013 10:31 PM, Dmitri Pal wrote: > >>>> On 02/15/2013 09:17 AM, Rodney L. Mercer wrote: > >>>>> On Thu, 2013-02-14 at 21:44 +0100, Sigbjorn Lie wrote: > >>>>>> I agree with schema support being enough for now. I do not expect the > >>>>>> ipa mgmt tools to support Solaris rbac mgmt. > >>>>>> > >>>>>> The ipa mgmt tools are great, but I already have other data in the ipa > >>>>>> ldap that I have to manage manually anyway. > >>>>>> > >>>>>> > >>>>>> > >>>>>> Rgds, > >>>>>> Siggi > >>>>>> > >>>>>> > >>>>>> > >>>>>> Rob Crittenden wrote: > >>>>>> Dag Wieers wrote: > >>>>>> On Thu, 14 Feb 2013, Rob Crittenden wrote: > >>>>>> > >>>>>> Sigbjorn Lie wrote: > >>>>>> On 02/13/2013 04:10 PM, Rob Crittenden wrote: > >>>>>> > >>>>>> Also since we also require compatibility with Solaris, and roles > >>>>>> (RBAC) > >>>>>> is currently used on Solaris, does IPA support RBAC on Solar > >>>>>> is ? > >>>>>> (We > >>>>>> noticed that RBAC mentioned in the IPA web interface only > >>>>>> relates to > > IPA > >>>>>> management). > >>>>>> No, IPA doesn't support RBAC on Solaris. > >>>>>> > >>>>>> I've come across the same issue. This is just a matter of extending the > >>>>>> schema. > >>>>>> > >>>>>> Would there be any interest for adding the Solaris RBAC schema as a > >>>>>> part > >>>>>> of the standard IPA distributed LDAP schema? > >>>>> Consider the following: What else would have to be put in to support > >>>>> this? > >>>>> Once the schema is established, can SSSD be extended to use this and > >>>>> potentially be referenced in nsswitch.conf as it is implemented on > >>>>> Solaris? IE: > >>>>> tail -5 /etc/nsswitch.conf > >>>>> user_attr: sssd > >>>>> auth_attr: sssd > >>>>> prof_attr: sssd > >>>>> exec_attr: sssd > >>>>> project: sssd > >>>> Before we define how it is passed/exposed it would nice to understand > >>>> who on Linux will be consuming it out of SSSD? > >>>> > >>> I don't think Linux would consume these attributes. They are specific to > >>> the Role Based Access Control solution implemented in Solaris. > >>> > >>> > >>> Rgds, > >>> Siggi > >>> > >>> ---------------------------------- > >>> > >>> Yes, I understand that Linux has no mechanism currently built in to consume these Solaris name server switch attributes. But, If the Solaris RBAC schema is included as > >>> part of the standard IPA distributed LDAP schema, My question is how hard would it be to create an extension using SSSD/pam to do so? > >>> > >>> I agree that it is too much to ask for a full Solaris style RBAC implementation on RHEL. > >>> > >>> We have an application that currently uses the Solaris RBAC structure to authorize user/role accesses within the application. > >>> > >>> Our goal is to use existing OS calls or possibly extending SSSD to allow system calls that would give us back an answer to attrbutes placed within the LDAP > >>> tree that are composed in like fashion as how they are stored in Solaris. Defining the schema seemed to be well received and I understand that it is intended that it would be there to support Solaris clients. > >>> If SSSD could be extended to access these attributes and possibly pam modules to allow Linux clients to take advantage of this RBAC schema, then our application could perform as it does on Solaris. It would also > >>> open up the opportunity for other vendors to consider moving their Solaris RBAC applications to RHEL. > >>> > >>> I think with that as a goal, we could then create users and SELinux roles that are defined within the RBAC based schema much like our current Solaris implementation. > >>> We use Solaris nsswitch calls to get yes/no authorization answers for user/role privilege within our application. > >>> > >>> Since IdM and SSD already support > >>> a) HBAC > >>> b) SUDO > >>> c) SELinux user mapping > >>> > >>> I believe HBAC as already implemented in IdM will be an additional asset in defining and restricting access that can be used by our customers. > >>> We have decided to move away from sudo, but may reconsider some of its uses if it suits the situation. > >>> Maybe SSSD can be extended to access the RBAC schema in much the same way that it accesses SUDO or HBAC schema? > >>> > >>> We have decided to use RHEL as the primary OS platform of choice going forward and we need to create a solution to our application RBAC > >>> needs similar to that in which we have accomplished with Solaris. I have been speaking with Dmitri on the side about these possibilities and would like to know > >>> what each of your thoughts are. The feasibility of accomplishing this is a bit over my head but is certainly our goal. > >>> I believe our management is committed to creating such a solution by involving our software engineers. Helping with adding the Solaris RBAC schema and > >>> contributing the GUI to manage the RBAC Schema data would be a goal. > >>> > >>> Also, since this is not the SSSD development list, I would like to know the list info for SSSD development and see what their thoughts are. > >>> > >>> Dmitri to answer your questions directly to me: > >>> Certainly we can discuss additional security components such as centrally managed SSH keys and host fingerprints. We don't need any interaction within our application to include AD, > >>> but our customers may want to take advantage of that at some point. > >> The sssd user list is > >> > >> sssd-users at lists.fedorahosted.org > >> > >> The devel list is > >> sssd-devel at lists.fedorahosted.org > >> > >> > >> But I suggest we continue this conversation here because otherwise the > >> conversation might fork and I would be hard to track. Most of the SSSD > >> developers read this list too. > >> > >> Since you have a clearly defined interface your application consumes > >> from Solaris the best thing now would be for you to provide a man page > >> style description of the calls the application needs and we will see how > >> to satisfy them with what we have and identify what needs to be added. > >> IMO such interface would be a requirement list. How we deliver it to the > >> application is an important but yes an implementation detail that we can > >> discuss after we know what requirements are. > >> > > Dmitri, > > > > We only use one system call from our application. that is > > chkauthattr - get authorization entry > > http://www.unix.com/man-page/all/3secdb/chkauthattr/ > > > > we have users and roles defined in the user_attr map > > Each user is assigned one or more profiles. > > > > The profiles are kept in the prof_attr map. > > Top level Profiles can and often are mapped to groups of "sub" profiles, > > where each of the "sub" profiles are mapped to groups of authorizations. > > > > The authorizations are stored in the auth_attr map and map to strings > > that our application queries to determine if the user/role has mapped > > to via the profiles that they have been assigned. > > > > If the string is contained in the mapping, the chkautattr call returns > > an allowed response, if not, it returns a denied response to the system > > call. > > > > > > Example: Authorization check > > > > ruid = getuid(); > > if ((pwp = getpwuid(ruid)) == NULL) > > crabort(INVALIDUSER); > > > > strcpy(real_login, pwp->pw_name); > > > > if ((eflag || lflag || rflag) && argc == 1) { > > if ((pwp = getpwnam(*argv)) == NULL) > > crabort(INVALIDUSER); > > > > if (!chkauthattr("auth_string", real_login)) { > > if (pwp->pw_uid != ruid) > > crabort(NOTROOT); > > else > > pp = getuser(ruid); > > } else > > pp = *argv++; > > } else { > > > > > > > > Authorizations > > An authorization is a unique string that represents a user?s right to > > perform some operation or class > > of operations. Authorization definitions are stored in a database called > > auth_attr(4). For > > programming authorization checks, only the authorization name is > > significant. > > > > CreatingAuthorization Checks > > > > To check authorizations, use the chkauthattr(3SECDB) library function, > > which verifies whether > > or not a user has a given authorization. The synopsis is: > > > > int chkauthattr(const char *authname, const char *username); > > > > The chkauthattr() function checks the policy.conf(4), user_attr(4), and > > prof_attr(4) > > databases in order for a match to the given authorization > > > > > OK, this is helpful. > > It seems that we would have to implement the whole interface anyways for > completeness or you think that implementing functions other than > chkauthattr() would not be required? > How common is this use of the RBAC? > Is is this how it is usually done or > it is a one off implementation and in general in Solaris world people > use RBAC information differently or to the greater extent? I can only speak for us, but, I'm fairly certain that we are most likely "one off" in our implementation. > I want to > understand the scope of the solution. Would that be a one off that would > work just for your application's use or RBAC or it would work for most > of the Solaris applications that use RBAC. > > Is this the schema we are talking about: > http://docs.oracle.com/cd/E19455-01/806-5580/appendixa-8/index.html > I think that this goes back to the beginning of this thread where Dag Wieers, Rob Crittenden, Simo Sorce and Sigbjorn Lie were discussing an Solaris RBAC schema implementation to support Solaris clients. https://www.redhat.com/archives/freeipa-users/2013-February/msg00250.html Certainly the schema would have to be complete to support that implementation. Once the schema is there to support Solaris clients, then it could be exploited by linux clients with some effort. > The schema uses 4 different object classes but the functions mentioned > above seem to deal only with the SolarisUserAttr and SolarisProfAttr > object classes. What about other two: SolarisAuthAttr & > SolarisExecAttr? Are they used or we do not need these on the server? > Again, we use user, prof and auth maps. We do not use the exec map. Our application uses chkauthattr calls to authorize commanding internal to our application. > IMO we have a good starting point to have a design page created by you. > Here is the template and here are some guidelines that might be helpful > when building a design page. > http://www.freeipa.org/page/Feature_template > http://www.freeipa.org/page/General_considerations > > Here is an example of the design that might give you some inspiration > (not everything mentioned in those pages ended up being implemented but > it gives a good hint of what needs to be covered in the design page) . > http://www.freeipa.org/page/V2/DS_Design_Summary_2 (see roles section) > http://www.freeipa.org/page/Overall_Design_of_Policy_Related_Components#Roles > www.freeipa.org/page/V2/IPA_Client_Design_Overview > > Good luck! > Thanks, Rodney. From bret.wortman at damascusgrp.com Wed Feb 20 14:34:03 2013 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Wed, 20 Feb 2013 09:34:03 -0500 Subject: [Freeipa-users] Trouble creating replica In-Reply-To: References: <5123876C.6050201@redhat.com> <5123C3F2.9090205@redhat.com> <1361367638.12328.394.camel@willson.li.ssimo.org> Message-ID: I think this keeps coming back to the fact that ldap isn't listening on 7389 for some reason. When I try to *really* manually start pki-ca like this, it complains about ldap before dying: # sudo -u pkiuser -s /usr/lib/jvm/jre/bin/java -classpath :/usr/share/tomcat6/bin/bootstrap.jar:/usr/share/tomcat6/bin/tomcat-juli.jar:/usr/share/java/commons-daemon.jar -Dcatalina.base=/var/lib/pki-ca -Dcatalina.home=/usr/share/tomcat6 -Djava.endorsed.dirs= -Djava.io.tmpdir=/var/cache/tomcat6/temp -Djava.util.logging.config.file=/var/lib/pki-ca/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager org.apache.catalina.startup.Bootstrap start : : Could not connect to LDAP server host oldmaster.my.com port 7389 Error netscape.ldap.LDAPException: failed to connect to server ldap:// oldmaster.my.com:7389 (91) [root at oldmaster]# This bears out what I see in /var/log/pki-ca/catalina.out too. * * *Bret Wortman* http://damascusgrp.com/ http://twitter.com/BretWortman On Wed, Feb 20, 2013 at 8:43 AM, Bret Wortman wrote: > On Wed, Feb 20, 2013 at 8:40 AM, Simo Sorce wrote: > >> On Wed, 2013-02-20 at 08:08 -0500, Bret Wortman wrote: >> > Digging further into my logs this morning, I've discovered that >> > there's no new entries in /var/log/dirsrv/slapd-PKI-IPA since Feb 5 >> > either. How can I tell why this isn't >> > running? /var/log/dirsrv/slapd-MY-COM is getting updated and logged >> > to, it's just the PKI piece that seems to be dead. >> > >> > >> > Nothing in /etc/pki-ca has changed since last year, and the last >> > updates to /var/lib/dirsrv/slapd-PKI-IPA/db or changelogs occurred on >> > Feb 5. I just can't tell what that change was.... >> >> What error do you get if you try to start it ? >> > > [root at oldmaster]# pkicontrol start ca PKI-IPA > PKI-IPA is an invalid 'pki-ca' instance > [root at oldmaster]# > > Is there another, preferred way to start it? > > > >> > >> > Would a key change or certificate change have affected this? >> >> An expired CA cert might cause the server to stop, but then you would >> see expired certs all over and also the main IPA instance would not >> start. >> > >> > Worst case, if I do something like this: >> > >> > >> > # ipa-server-install -U --uninstall >> > # ipa-server-install >> > >> You will completely obliterate all your data. >> >> > will I lose the hosts, policies & users I already have configured? >> > Does this stand a chance of getting me back up to where I can clone >> > this box and get healthy again? >> > >> Healthy will be, but with no data, don't do it. (and I suggest you make >> a full backup just in case) >> >> Simo. >> >> -- >> Simo Sorce * Red Hat, Inc * New York >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret.wortman at damascusgrp.com Wed Feb 20 14:41:21 2013 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Wed, 20 Feb 2013 09:41:21 -0500 Subject: [Freeipa-users] Trouble creating replica In-Reply-To: References: <5123876C.6050201@redhat.com> <5123C3F2.9090205@redhat.com> <1361367638.12328.394.camel@willson.li.ssimo.org> Message-ID: Eureka! Someone had deleted the contents of /etc/dirsrv/slapd-PKI-IPA/dse.ldif. I replaced it from a saved copy and now everything's working as expected. Thanks everyone for your contributions, patience, and indulgence. And for a wonderful product! * * *Bret Wortman* http://damascusgrp.com/ http://twitter.com/BretWortman On Wed, Feb 20, 2013 at 9:34 AM, Bret Wortman wrote: > I think this keeps coming back to the fact that ldap isn't listening on > 7389 for some reason. When I try to *really* manually start pki-ca like > this, it complains about ldap before dying: > > # sudo -u pkiuser -s /usr/lib/jvm/jre/bin/java -classpath > :/usr/share/tomcat6/bin/bootstrap.jar:/usr/share/tomcat6/bin/tomcat-juli.jar:/usr/share/java/commons-daemon.jar > -Dcatalina.base=/var/lib/pki-ca -Dcatalina.home=/usr/share/tomcat6 > -Djava.endorsed.dirs= -Djava.io.tmpdir=/var/cache/tomcat6/temp > -Djava.util.logging.config.file=/var/lib/pki-ca/conf/logging.properties > -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager > org.apache.catalina.startup.Bootstrap start > : > : > Could not connect to LDAP server host oldmaster.my.com port 7389 Error > netscape.ldap.LDAPException: failed to connect to server ldap:// > oldmaster.my.com:7389 (91) > [root at oldmaster]# > > This bears out what I see in /var/log/pki-ca/catalina.out too. > > > > * > * > *Bret Wortman* > > http://damascusgrp.com/ > http://twitter.com/BretWortman > > > On Wed, Feb 20, 2013 at 8:43 AM, Bret Wortman < > bret.wortman at damascusgrp.com> wrote: > >> On Wed, Feb 20, 2013 at 8:40 AM, Simo Sorce wrote: >> >>> On Wed, 2013-02-20 at 08:08 -0500, Bret Wortman wrote: >>> > Digging further into my logs this morning, I've discovered that >>> > there's no new entries in /var/log/dirsrv/slapd-PKI-IPA since Feb 5 >>> > either. How can I tell why this isn't >>> > running? /var/log/dirsrv/slapd-MY-COM is getting updated and logged >>> > to, it's just the PKI piece that seems to be dead. >>> > >>> > >>> > Nothing in /etc/pki-ca has changed since last year, and the last >>> > updates to /var/lib/dirsrv/slapd-PKI-IPA/db or changelogs occurred on >>> > Feb 5. I just can't tell what that change was.... >>> >>> What error do you get if you try to start it ? >>> >> >> [root at oldmaster]# pkicontrol start ca PKI-IPA >> PKI-IPA is an invalid 'pki-ca' instance >> [root at oldmaster]# >> >> Is there another, preferred way to start it? >> >> >> >>> > >>> > Would a key change or certificate change have affected this? >>> >>> An expired CA cert might cause the server to stop, but then you would >>> see expired certs all over and also the main IPA instance would not >>> start. >>> > >>> > Worst case, if I do something like this: >>> > >>> > >>> > # ipa-server-install -U --uninstall >>> > # ipa-server-install >>> > >>> You will completely obliterate all your data. >>> >>> > will I lose the hosts, policies & users I already have configured? >>> > Does this stand a chance of getting me back up to where I can clone >>> > this box and get healthy again? >>> > >>> Healthy will be, but with no data, don't do it. (and I suggest you make >>> a full backup just in case) >>> >>> Simo. >>> >>> -- >>> Simo Sorce * Red Hat, Inc * New York >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdennis at redhat.com Wed Feb 20 14:47:17 2013 From: jdennis at redhat.com (John Dennis) Date: Wed, 20 Feb 2013 09:47:17 -0500 Subject: [Freeipa-users] Trouble creating replica In-Reply-To: References: <5123876C.6050201@redhat.com> <5123C3F2.9090205@redhat.com> <1361367638.12328.394.camel@willson.li.ssimo.org> Message-ID: <5124E1F5.5000208@redhat.com> On 02/20/2013 08:43 AM, Bret Wortman wrote: > [root at oldmaster]# pkicontrol start ca PKI-IPA > PKI-IPA is an invalid 'pki-ca' instance > [root at oldmaster]# > > Is there another, preferred way to start it? pkiconsole is used to monitor/configure your instance, it's a GUI application. Perhaps it can also be used to start/stop instances but I've never seen it used that way and we don't use pkiconsole at all. Normally the pki-ca instance is controlled using the same service commands for any other daemon. Some of this has been in flux so the details may depend on your exact OS. If you don't provide a specific instance to start/stop then the service command will apply the action to all your instances, usaully this is fine as usaully you only have one instance. As for debugging what is going on. pki-ca is a tomcat instance. You need to locate it's log files under /var/log depending on the release it can be named slightly differently but it should be obvious. You need to understand how a tomcat instance starts, again this depends on the release. Early start up messages will be written to catalina.out, those are tomcat specific messages, if you have problems opening sockets (for instance bad certs) it should show up in this file. Once tomcat hands control over to the application (i.e. pki-ca) you will see messages in the "debug" file located under the /var/log/pki-ca (or whatever, depends on the release) directory. As I said it should be easy to find. Look in that file for obvious problems. HTH, I forget the exact version you're running on which OS. If the above is not specific enough we can get the dogtag folks to jump in. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Wed Feb 20 14:47:59 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 20 Feb 2013 09:47:59 -0500 Subject: [Freeipa-users] Trouble creating replica In-Reply-To: References: <5123876C.6050201@redhat.com> <5123C3F2.9090205@redhat.com> <1361367638.12328.394.camel@willson.li.ssimo.org> Message-ID: <5124E21F.9000608@redhat.com> Bret Wortman wrote: > Eureka! > > Someone had deleted the contents of /etc/dirsrv/slapd-PKI-IPA/dse.ldif. > I replaced it from a saved copy and now everything's working as expected. > > Thanks everyone for your contributions, patience, and indulgence. And > for a wonderful product! Glad you're up and running again. I'm curious, what version are you running? rob From bret.wortman at damascusgrp.com Wed Feb 20 14:51:22 2013 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Wed, 20 Feb 2013 09:51:22 -0500 Subject: [Freeipa-users] Trouble creating replica In-Reply-To: <5124E21F.9000608@redhat.com> References: <5123876C.6050201@redhat.com> <5123C3F2.9090205@redhat.com> <1361367638.12328.394.camel@willson.li.ssimo.org> <5124E21F.9000608@redhat.com> Message-ID: I'm running 2.2.0-1.fc17.x86_64 And FWIW, the replica data file I was able to create after this just installed successfully on the new host. * * *Bret Wortman* http://damascusgrp.com/ http://twitter.com/BretWortman On Wed, Feb 20, 2013 at 9:47 AM, Rob Crittenden wrote: > Bret Wortman wrote: > >> Eureka! >> >> Someone had deleted the contents of /etc/dirsrv/slapd-PKI-IPA/dse.**ldif. >> I replaced it from a saved copy and now everything's working as expected. >> >> Thanks everyone for your contributions, patience, and indulgence. And >> for a wonderful product! >> > > Glad you're up and running again. > > I'm curious, what version are you running? > > rob > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sakodak at gmail.com Thu Feb 21 01:00:18 2013 From: sakodak at gmail.com (KodaK) Date: Wed, 20 Feb 2013 19:00:18 -0600 Subject: [Freeipa-users] Trouble creating replica In-Reply-To: References: <5123876C.6050201@redhat.com> <5123C3F2.9090205@redhat.com> <1361367638.12328.394.camel@willson.li.ssimo.org> Message-ID: On Wed, Feb 20, 2013 at 8:41 AM, Bret Wortman wrote: > Eureka! > > Someone had deleted the contents of /etc/dirsrv/slapd-PKI-IPA/dse.ldif. I > replaced it from a saved copy and now everything's working as expected. > > Thanks everyone for your contributions, patience, and indulgence. And for > a wonderful product! > > I wouldn't be too sure that someone deleted it. A couple of weeks ago I had a crash and half of my replicas had an empty dse.ldif. I think you and I may be hitting a bug. --Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Thu Feb 21 01:15:42 2013 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 20 Feb 2013 18:15:42 -0700 Subject: [Freeipa-users] Trouble creating replica In-Reply-To: References: <5123876C.6050201@redhat.com> <5123C3F2.9090205@redhat.com> <1361367638.12328.394.camel@willson.li.ssimo.org> Message-ID: <5125753E.9090009@redhat.com> On 02/20/2013 06:00 PM, KodaK wrote: > > > On Wed, Feb 20, 2013 at 8:41 AM, Bret Wortman > > > wrote: > > Eureka! > > Someone had deleted the contents of > /etc/dirsrv/slapd-PKI-IPA/dse.ldif. I replaced it from a saved > copy and now everything's working as expected. > > Thanks everyone for your contributions, patience, and indulgence. > And for a wonderful product! > > > I wouldn't be too sure that someone deleted it. A couple of weeks ago > I had a crash and half of my replicas had an empty dse.ldif. I think > you and I may be hitting a bug. were these virtual machines? > > --Jason > > > _______________________________________________ > 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 bret.wortman at damascusgrp.com Thu Feb 21 01:43:15 2013 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Wed, 20 Feb 2013 17:43:15 -0800 (PST) Subject: [Freeipa-users] Trouble creating replica In-Reply-To: <5125753E.9090009@redhat.com> References: <5125753E.9090009@redhat.com> Message-ID: <1361410994756.97af79da@Nodemailer> Mine was not.? ? Bret Wortman On Wed, Feb 20, 2013 at 8:16 PM, Rich Megginson wrote: > On 02/20/2013 06:00 PM, KodaK wrote: >> >> >> On Wed, Feb 20, 2013 at 8:41 AM, Bret Wortman >> > >> wrote: >> >> Eureka! >> >> Someone had deleted the contents of >> /etc/dirsrv/slapd-PKI-IPA/dse.ldif. I replaced it from a saved >> copy and now everything's working as expected. >> >> Thanks everyone for your contributions, patience, and indulgence. >> And for a wonderful product! >> >> >> I wouldn't be too sure that someone deleted it. A couple of weeks ago >> I had a crash and half of my replicas had an empty dse.ldif. I think >> you and I may be hitting a bug. > were these virtual machines? >> >> --Jason >> >> >> _______________________________________________ >> 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 rmeggins at redhat.com Thu Feb 21 02:03:14 2013 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 20 Feb 2013 19:03:14 -0700 Subject: [Freeipa-users] Trouble creating replica In-Reply-To: <1361410994756.97af79da@Nodemailer> References: <5125753E.9090009@redhat.com> <1361410994756.97af79da@Nodemailer> Message-ID: <51258062.20702@redhat.com> On 02/20/2013 06:43 PM, Bret Wortman wrote: > > Mine was not. > What platform? What version of 389-ds-base? > ? > Bret Wortman > > > On Wed, Feb 20, 2013 at 8:16 PM, Rich Megginson > wrote: > > On 02/20/2013 06:00 PM, KodaK wrote: >> >> >> On Wed, Feb 20, 2013 at 8:41 AM, Bret Wortman >> > > wrote: >> >> Eureka! >> >> Someone had deleted the contents of >> /etc/dirsrv/slapd-PKI-IPA/dse.ldif. I replaced it from a >> saved copy and now everything's working as expected. >> >> Thanks everyone for your contributions, patience, and >> indulgence. And for a wonderful product! >> >> >> I wouldn't be too sure that someone deleted it. A couple of >> weeks ago I had a crash and half of my replicas had an empty >> dse.ldif. I think you and I may be hitting a bug. > > were these virtual machines? > >> >> --Jason >> >> >> _______________________________________________ >> 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 phalen at gmail.com Thu Feb 21 03:20:33 2013 From: phalen at gmail.com (Kendrick .) Date: Wed, 20 Feb 2013 22:20:33 -0500 Subject: [Freeipa-users] --external-ca is a bit confusing. Message-ID: I am trying to get cacert to sign the csr. I have tried searching about it and cant figure out what is what. some information i have found suggests it wont be possible. when I go to get the csr signed i get "The following hostnames were rejected because the system couldn't link them to your account, if they are valid please verify the domains against your account. Rejected: Certificate Authority" I would prefer my certificates to be valid on the internet as some of the user certs would be used to sign emails and such. any advice would be appriciated. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ninibaba at worldd.org Thu Feb 21 05:57:18 2013 From: ninibaba at worldd.org (ninibaba at worldd.org) Date: Wed, 20 Feb 2013 22:57:18 -0700 Subject: [Freeipa-users] KPasswd TCP issues In-Reply-To: <20130220084803.GO27418@localhost.localdomain> References: <8f3641f286813dab7b616b63e5d0f4fd.squirrel@box318.bluehost.com> <20130219203608.GA26433@redhat.com> <40e097b466657496aaa6496dd5d09b4e.squirrel@box318.bluehost.com> <004fb83b569c173edb651b1e29bb90e2.squirrel@box318.bluehost.com> <20130220084803.GO27418@localhost.localdomain> Message-ID: <363ffb187d7a5ff0d5afc4e0c2ace355.squirrel@box318.bluehost.com> > On Tue, Feb 19, 2013 at 03:29:03PM -0700, ninibaba at worldd.org wrote: >> >> >> ? >> ? >> Actually >> i'd like to take that back now, it works fine when running kpasswd, but >> if >> user password is expired when SSH to client, during the reset it only >> tried UDP same if issuing passwd command as well. > > > Both use sssd here which in theory should behave as kpasswd. Can you run > sssd with a high debug level, run the passwd command again and send > logs? If you prefer you can send them as PM to me. Most interesting > would be krb5_child.log but the others miht be useful as well. > > bye, > Sumit >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > ? I found my issue by disabled SELinux on the client, also did a search and found this bug related to my issue exactly: ? https://bugzilla.redhat.com/show_bug.cgi?id=889251 ? The selinux-policy in CentOS 6 is not the same as the current?selinux-policy-3.7.19-190.el6 in RHEL 6, CentOS 6 is using?selinux-policy-3.7.19-155.el6 ? Thank you for everyone's help, reviewing the krb5_child.log led me to search SELinux audit log which turned up the problem while looking for denied messages. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Thu Feb 21 08:30:45 2013 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 21 Feb 2013 03:30:45 -0500 Subject: [Freeipa-users] --external-ca is a bit confusing. In-Reply-To: References: Message-ID: <5125DB35.90709@redhat.com> On 02/20/2013 10:20 PM, Kendrick . wrote: > I am trying to get cacert to sign the csr. I have tried searching > about it and cant figure out what is what. some information i have > found suggests it wont be possible. > > when I go to get the csr signed i get > > "The following hostnames were rejected because the system couldn't > link them to your account, if they are valid please verify the domains > against your account. > Rejected: Certificate Authority > " > > > I would prefer my certificates to be valid on the internet as some of > the user certs would be used to sign emails and such. any advice > would be appriciated. > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users Can you please be more specific about what you are doing? The linking to the external CA is one time operation during the initial installation. If you want to use the IPA as a subordinate CA you need to specify a flag during installation (it seems that you are doing that based on the comments above). The installation will stop indicating that you need to take CSR and sign by the external CA. So you should take the CSR and sign. Then you present the result back to IPA and continue the installation. Based on the description above it is not clear which step is failing. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Thu Feb 21 08:53:23 2013 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 21 Feb 2013 03:53:23 -0500 Subject: [Freeipa-users] RHEL6 IPA and Active Directory synchronisation and Solaris RBAC In-Reply-To: <1361367894.21935.1033.camel@osc145.evn.harris.com> References: <511BACEE.8050900@redhat.com> <511D2541.1000201@nixtra.com> <511D2CAC.6050400@redhat.com> <511D4693.8010502@redhat.com> <1360937840.21935.556.camel@osc145.evn.harris.com> <511EA93C.8060909@redhat.com>, <511F6D98.30700@nixtra.com> <512A3AF8DAE8454D95C05141F746ECE1512AC316@MLBMXUS21.cs.myharris.net> <512121E9.2050608@redhat.com> <1361283261.21935.914.camel@osc145.evn.harris.com> <51242F73.9000309@redhat.com> <1361367894.21935.1033.camel@osc145.evn.harris.com> Message-ID: <5125E083.3040506@redhat.com> On 02/20/2013 08:44 AM, Rodney L. Mercer wrote: > > On Tue, 2013-02-19 at 21:05 -0500, Dmitri Pal wrote: >> On 02/19/2013 09:14 AM, Rodney L. Mercer wrote: >>> On Sun, 2013-02-17 at 13:31 -0500, Dmitri Pal wrote: >>>> On 02/16/2013 12:14 PM, Mercer, Rodney wrote: >>>>> ________________________________________ >>>>> From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Sigbjorn Lie [sigbjorn at nixtra.com] >>>>> Sent: Saturday, February 16, 2013 6:29 AM >>>>> To: freeipa-users at redhat.com >>>>> Subject: Re: [Freeipa-users] RHEL6 IPA and Active Directory synchronisation and Solaris RBAC >>>>> >>>>> On 02/15/2013 10:31 PM, Dmitri Pal wrote: >>>>>> On 02/15/2013 09:17 AM, Rodney L. Mercer wrote: >>>>>>> On Thu, 2013-02-14 at 21:44 +0100, Sigbjorn Lie wrote: >>>>>>>> I agree with schema support being enough for now. I do not expect the >>>>>>>> ipa mgmt tools to support Solaris rbac mgmt. >>>>>>>> >>>>>>>> The ipa mgmt tools are great, but I already have other data in the ipa >>>>>>>> ldap that I have to manage manually anyway. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Rgds, >>>>>>>> Siggi >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Rob Crittenden wrote: >>>>>>>> Dag Wieers wrote: >>>>>>>> On Thu, 14 Feb 2013, Rob Crittenden wrote: >>>>>>>> >>>>>>>> Sigbjorn Lie wrote: >>>>>>>> On 02/13/2013 04:10 PM, Rob Crittenden wrote: >>>>>>>> >>>>>>>> Also since we also require compatibility with Solaris, and roles >>>>>>>> (RBAC) >>>>>>>> is currently used on Solaris, does IPA support RBAC on Solar >>>>>>>> is ? >>>>>>>> (We >>>>>>>> noticed that RBAC mentioned in the IPA web interface only >>>>>>>> relates to > > IPA >>>>>>>> management). >>>>>>>> No, IPA doesn't support RBAC on Solaris. >>>>>>>> >>>>>>>> I've come across the same issue. This is just a matter of extending the >>>>>>>> schema. >>>>>>>> >>>>>>>> Would there be any interest for adding the Solaris RBAC schema as a >>>>>>>> part >>>>>>>> of the standard IPA distributed LDAP schema? >>>>>>> Consider the following: What else would have to be put in to support >>>>>>> this? >>>>>>> Once the schema is established, can SSSD be extended to use this and >>>>>>> potentially be referenced in nsswitch.conf as it is implemented on >>>>>>> Solaris? IE: >>>>>>> tail -5 /etc/nsswitch.conf >>>>>>> user_attr: sssd >>>>>>> auth_attr: sssd >>>>>>> prof_attr: sssd >>>>>>> exec_attr: sssd >>>>>>> project: sssd >>>>>> Before we define how it is passed/exposed it would nice to understand >>>>>> who on Linux will be consuming it out of SSSD? >>>>>> >>>>> I don't think Linux would consume these attributes. They are specific to >>>>> the Role Based Access Control solution implemented in Solaris. >>>>> >>>>> >>>>> Rgds, >>>>> Siggi >>>>> >>>>> ---------------------------------- >>>>> >>>>> Yes, I understand that Linux has no mechanism currently built in to consume these Solaris name server switch attributes. But, If the Solaris RBAC schema is included as >>>>> part of the standard IPA distributed LDAP schema, My question is how hard would it be to create an extension using SSSD/pam to do so? >>>>> >>>>> I agree that it is too much to ask for a full Solaris style RBAC implementation on RHEL. >>>>> >>>>> We have an application that currently uses the Solaris RBAC structure to authorize user/role accesses within the application. >>>>> >>>>> Our goal is to use existing OS calls or possibly extending SSSD to allow system calls that would give us back an answer to attrbutes placed within the LDAP >>>>> tree that are composed in like fashion as how they are stored in Solaris. Defining the schema seemed to be well received and I understand that it is intended that it would be there to support Solaris clients. >>>>> If SSSD could be extended to access these attributes and possibly pam modules to allow Linux clients to take advantage of this RBAC schema, then our application could perform as it does on Solaris. It would also >>>>> open up the opportunity for other vendors to consider moving their Solaris RBAC applications to RHEL. >>>>> >>>>> I think with that as a goal, we could then create users and SELinux roles that are defined within the RBAC based schema much like our current Solaris implementation. >>>>> We use Solaris nsswitch calls to get yes/no authorization answers for user/role privilege within our application. >>>>> >>>>> Since IdM and SSD already support >>>>> a) HBAC >>>>> b) SUDO >>>>> c) SELinux user mapping >>>>> >>>>> I believe HBAC as already implemented in IdM will be an additional asset in defining and restricting access that can be used by our customers. >>>>> We have decided to move away from sudo, but may reconsider some of its uses if it suits the situation. >>>>> Maybe SSSD can be extended to access the RBAC schema in much the same way that it accesses SUDO or HBAC schema? >>>>> >>>>> We have decided to use RHEL as the primary OS platform of choice going forward and we need to create a solution to our application RBAC >>>>> needs similar to that in which we have accomplished with Solaris. I have been speaking with Dmitri on the side about these possibilities and would like to know >>>>> what each of your thoughts are. The feasibility of accomplishing this is a bit over my head but is certainly our goal. >>>>> I believe our management is committed to creating such a solution by involving our software engineers. Helping with adding the Solaris RBAC schema and >>>>> contributing the GUI to manage the RBAC Schema data would be a goal. >>>>> >>>>> Also, since this is not the SSSD development list, I would like to know the list info for SSSD development and see what their thoughts are. >>>>> >>>>> Dmitri to answer your questions directly to me: >>>>> Certainly we can discuss additional security components such as centrally managed SSH keys and host fingerprints. We don't need any interaction within our application to include AD, >>>>> but our customers may want to take advantage of that at some point. >>>> The sssd user list is >>>> >>>> sssd-users at lists.fedorahosted.org >>>> >>>> The devel list is >>>> sssd-devel at lists.fedorahosted.org >>>> >>>> >>>> But I suggest we continue this conversation here because otherwise the >>>> conversation might fork and I would be hard to track. Most of the SSSD >>>> developers read this list too. >>>> >>>> Since you have a clearly defined interface your application consumes >>>> from Solaris the best thing now would be for you to provide a man page >>>> style description of the calls the application needs and we will see how >>>> to satisfy them with what we have and identify what needs to be added. >>>> IMO such interface would be a requirement list. How we deliver it to the >>>> application is an important but yes an implementation detail that we can >>>> discuss after we know what requirements are. >>>> >>> Dmitri, >>> >>> We only use one system call from our application. that is >>> chkauthattr - get authorization entry >>> http://www.unix.com/man-page/all/3secdb/chkauthattr/ >>> >>> we have users and roles defined in the user_attr map >>> Each user is assigned one or more profiles. >>> >>> The profiles are kept in the prof_attr map. >>> Top level Profiles can and often are mapped to groups of "sub" profiles, >>> where each of the "sub" profiles are mapped to groups of authorizations. >>> >>> The authorizations are stored in the auth_attr map and map to strings >>> that our application queries to determine if the user/role has mapped >>> to via the profiles that they have been assigned. >>> >>> If the string is contained in the mapping, the chkautattr call returns >>> an allowed response, if not, it returns a denied response to the system >>> call. >>> >>> >>> Example: Authorization check >>> >>> ruid = getuid(); >>> if ((pwp = getpwuid(ruid)) == NULL) >>> crabort(INVALIDUSER); >>> >>> strcpy(real_login, pwp->pw_name); >>> >>> if ((eflag || lflag || rflag) && argc == 1) { >>> if ((pwp = getpwnam(*argv)) == NULL) >>> crabort(INVALIDUSER); >>> >>> if (!chkauthattr("auth_string", real_login)) { >>> if (pwp->pw_uid != ruid) >>> crabort(NOTROOT); >>> else >>> pp = getuser(ruid); >>> } else >>> pp = *argv++; >>> } else { >>> >>> >>> >>> Authorizations >>> An authorization is a unique string that represents a user?s right to >>> perform some operation or class >>> of operations. Authorization definitions are stored in a database called >>> auth_attr(4). For >>> programming authorization checks, only the authorization name is >>> significant. >>> >>> CreatingAuthorization Checks >>> >>> To check authorizations, use the chkauthattr(3SECDB) library function, >>> which verifies whether >>> or not a user has a given authorization. The synopsis is: >>> >>> int chkauthattr(const char *authname, const char *username); >>> >>> The chkauthattr() function checks the policy.conf(4), user_attr(4), and >>> prof_attr(4) >>> databases in order for a match to the given authorization >>> >>> >> OK, this is helpful. >> >> It seems that we would have to implement the whole interface anyways for >> completeness or you think that implementing functions other than >> chkauthattr() would not be required? >> How common is this use of the RBAC? >> Is is this how it is usually done or >> it is a one off implementation and in general in Solaris world people >> use RBAC information differently or to the greater extent? > I can only speak for us, but, I'm fairly certain that we are most likely > "one off" in our implementation. We need to understand how limited it will be and what is the cost of making it applicable to other use cases. >> I want to >> understand the scope of the solution. Would that be a one off that would >> work just for your application's use or RBAC or it would work for most >> of the Solaris applications that use RBAC. >> >> Is this the schema we are talking about: >> http://docs.oracle.com/cd/E19455-01/806-5580/appendixa-8/index.html >> > I think that this goes back to the beginning of this thread where Dag > Wieers, Rob Crittenden, Simo Sorce and Sigbjorn Lie were discussing an > Solaris RBAC schema implementation to support Solaris clients. > https://www.redhat.com/archives/freeipa-users/2013-February/msg00250.html I did not find the exact reference to the schema in that conversation. May be I missed it but this is why I asked. So can someone confirm that the schema here is the right schema? http://docs.oracle.com/cd/E19455-01/806-5580/appendixa-8/index.html > > Certainly the schema would have to be complete to support that > implementation. > > Once the schema is there to support Solaris clients, then it could be > exploited by linux clients with some effort. Getting schema there is not a problem. You just drop a schema file into a directory and restart the DS and the schema will be loaded. So assume we have done it. Let us move on to the next step. > >> The schema uses 4 different object classes but the functions mentioned >> above seem to deal only with the SolarisUserAttr and SolarisProfAttr >> object classes. What about other two: SolarisAuthAttr & >> SolarisExecAttr? Are they used or we do not need these on the server? >> > Again, we use user, prof and auth maps. We do not use the exec map. But we probably should load it too. > Our application uses chkauthattr calls to authorize commanding internal > to our application. The description of the chauthattr function says it uses user and prof maps. It is unclear how it uses auth map. Other functions do but you do not seem to use them. http://docs.oracle.com/cd/E18752_01/html/816-5172/chkauthattr-3secdb.html Also I did a quick search. Is there any existing implementation of this functionality in Open Source? I doubt we can use some of the existing OpenSolaris code because of licensing. May we can at least use it for inspiration. > >> IMO we have a good starting point to have a design page created by you. >> Here is the template and here are some guidelines that might be helpful >> when building a design page. >> http://www.freeipa.org/page/Feature_template >> http://www.freeipa.org/page/General_considerations >> >> Here is an example of the design that might give you some inspiration >> (not everything mentioned in those pages ended up being implemented but >> it gives a good hint of what needs to be covered in the design page) . >> http://www.freeipa.org/page/V2/DS_Design_Summary_2 (see roles section) >> http://www.freeipa.org/page/Overall_Design_of_Policy_Related_Components#Roles >> www.freeipa.org/page/V2/IPA_Client_Design_Overview >> >> Good luck! >> > Thanks, > Rodney. > -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From hboetes at gmail.com Thu Feb 21 14:07:10 2013 From: hboetes at gmail.com (Han Boetes) Date: Thu, 21 Feb 2013 15:07:10 +0100 Subject: [Freeipa-users] [Feature request] Adding support for sudo to ipa-client-install Message-ID: This is what you have to do to enable sudo support while using freeipa: I got it all from sssd-sudo(5). # yum install libsss_sudo Add this line to /etc/nsswitch.conf sudoers: files sss Edit /etc/sssd/sssd.conf and make the following changes: Add sudo to the "services =" line. And add lines like these to the [domain/example.com] section sudo_provider = ldap ldap_uri = ldap://ipa.example.com ldap_sudo_search_base = ou=sudoers,dc=example,dc=com ldap_sasl_mech = GSSAPI ldap_sasl_authid = host/hostname.example.com ldap_sasl_realm = EXAMPLE.COM krb5_server = ipa.example.com And after that sudo should work. For debugging stop the sssd service and run sssd with the following options: /usr/sbin/sssd -D -f -d4 And then tail /var/log/sssd/sssd_example.com.log My request to the freeipa developers is to add an option to ipa-install-client script to support these changes. Perhaps even make it the default since it's so nice and useful to have. # Han -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret.wortman at damascusgrp.com Thu Feb 21 14:11:01 2013 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Thu, 21 Feb 2013 09:11:01 -0500 Subject: [Freeipa-users] Trouble creating replica In-Reply-To: <51258062.20702@redhat.com> References: <5125753E.9090009@redhat.com> <1361410994756.97af79da@Nodemailer> <51258062.20702@redhat.com> Message-ID: Rich, 389-ds-base-1.2.11.5-1.fc17.x86_64. The box is a DL360G8. * * *Bret Wortman* http://damascusgrp.com/ http://twitter.com/BretWortman On Wed, Feb 20, 2013 at 9:03 PM, Rich Megginson wrote: > On 02/20/2013 06:43 PM, Bret Wortman wrote: > > Mine was not. > > What platform? What version of 389-ds-base? > > > ? > Bret Wortman > > > On Wed, Feb 20, 2013 at 8:16 PM, Rich Megginson wrote: > >> On 02/20/2013 06:00 PM, KodaK wrote: >> >> >> >> On Wed, Feb 20, 2013 at 8:41 AM, Bret Wortman < >> bret.wortman at damascusgrp.com> wrote: >> >>> Eureka! >>> >>> Someone had deleted the contents of >>> /etc/dirsrv/slapd-PKI-IPA/dse.ldif. I replaced it from a saved copy and now >>> everything's working as expected. >>> >>> Thanks everyone for your contributions, patience, and indulgence. And >>> for a wonderful product! >>> >>> >> I wouldn't be too sure that someone deleted it. A couple of weeks ago >> I had a crash and half of my replicas had an empty dse.ldif. I think you >> and I may be hitting a bug. >> >> >> were these virtual machines? >> >> >> --Jason >> >> >> _______________________________________________ >> Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Thu Feb 21 14:11:21 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 21 Feb 2013 15:11:21 +0100 Subject: [Freeipa-users] [Feature request] Adding support for sudo to ipa-client-install In-Reply-To: References: Message-ID: <20130221141121.GB17964@hendrix.brq.redhat.com> On Thu, Feb 21, 2013 at 03:07:10PM +0100, Han Boetes wrote: > This is what you have to do to enable sudo support while using freeipa: I > got it all from > sssd-sudo(5). > > # yum install libsss_sudo > > Add this line to /etc/nsswitch.conf > > sudoers: files sss > > Edit /etc/sssd/sssd.conf and make the following changes: > > Add sudo to the "services =" line. > > And add lines like these to the [domain/example.com] section > > sudo_provider = ldap > ldap_uri = ldap://ipa.example.com > ldap_sudo_search_base = ou=sudoers,dc=example,dc=com > ldap_sasl_mech = GSSAPI > ldap_sasl_authid = host/hostname.example.com > ldap_sasl_realm = EXAMPLE.COM > krb5_server = ipa.example.com > > And after that sudo should work. For debugging stop the sssd service and > run sssd with the following options: > > /usr/sbin/sssd -D -f -d4 > > And then tail /var/log/sssd/sssd_example.com.log > > My request to the freeipa developers is to add an option to > ipa-install-client script to support these changes. Perhaps even make it > the default since it's so nice and useful to have. > > > > # Han There is already https://fedorahosted.org/freeipa/ticket/3358 open which is tracking the exact use case. From rmeggins at redhat.com Thu Feb 21 15:54:18 2013 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 21 Feb 2013 08:54:18 -0700 Subject: [Freeipa-users] Trouble creating replica In-Reply-To: References: <5125753E.9090009@redhat.com> <1361410994756.97af79da@Nodemailer> <51258062.20702@redhat.com> Message-ID: <5126432A.4030004@redhat.com> On 02/21/2013 07:11 AM, Bret Wortman wrote: > Rich, > > 389-ds-base-1.2.11.5-1.fc17.x86_64. > > The box is a DL360G8. > https://fedorahosted.org/389/ticket/518 > > _ > _ > *Bret Wortman* > > http://damascusgrp.com/ > http://twitter.com/BretWortman > > > On Wed, Feb 20, 2013 at 9:03 PM, Rich Megginson > wrote: > > On 02/20/2013 06:43 PM, Bret Wortman wrote: >> >> Mine was not. >> > What platform? What version of 389-ds-base? > > >> ? >> Bret Wortman >> >> >> On Wed, Feb 20, 2013 at 8:16 PM, Rich Megginson >> > wrote: >> >> On 02/20/2013 06:00 PM, KodaK wrote: >>> >>> >>> On Wed, Feb 20, 2013 at 8:41 AM, Bret Wortman >>> >> > wrote: >>> >>> Eureka! >>> >>> Someone had deleted the contents of >>> /etc/dirsrv/slapd-PKI-IPA/dse.ldif. I replaced it from a >>> saved copy and now everything's working as expected. >>> >>> Thanks everyone for your contributions, patience, and >>> indulgence. And for a wonderful product! >>> >>> >>> I wouldn't be too sure that someone deleted it. A couple of >>> weeks ago I had a crash and half of my replicas had an empty >>> dse.ldif. I think you and I may be hitting a bug. >> >> were these virtual machines? >> >>> >>> --Jason >>> >>> >>> _______________________________________________ >>> 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 erinn.looneytriggs at gmail.com Thu Feb 21 15:58:53 2013 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Thu, 21 Feb 2013 08:58:53 -0700 Subject: [Freeipa-users] Upgrading to 6.4 Message-ID: <5126443D.60806@gmail.com> For the fool hearty amongst us, as in me, I upgraded to RHEL 6.4 today. So far the Web UI portion of IPA is broken. I receive the following error via the UI: IPA Error 903 an internal error has occurred. Other things appear to be working fine, though my testing hasn't been all that thorough at this point. From the error logs: [Thu Feb 21 15:55:59 2013] [error] ipa: ERROR: non-public: KeyError: 'ipaExternalGroup' [Thu Feb 21 15:55:59 2013] [error] Traceback (most recent call last): [Thu Feb 21 15:55:59 2013] [error] File "/usr/lib/python2.6/site-packages/ipaserver/rpcserver.py", line 334, in wsgi_execute [Thu Feb 21 15:55:59 2013] [error] result = self.Command[name](*args, **options) [Thu Feb 21 15:55:59 2013] [error] File "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line 435, in __call__ [Thu Feb 21 15:55:59 2013] [error] ret = self.run(*args, **options) [Thu Feb 21 15:55:59 2013] [error] File "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line 747, in run [Thu Feb 21 15:55:59 2013] [error] return self.execute(*args, **options) [Thu Feb 21 15:55:59 2013] [error] File "/usr/lib/python2.6/site-packages/ipalib/plugins/internal.py", line 119, in execute [Thu Feb 21 15:55:59 2013] [error] (o.name, json_serialize(o)) for o in self.api.Object() [Thu Feb 21 15:55:59 2013] [error] File "/usr/lib/python2.6/site-packages/ipalib/plugins/internal.py", line 119, in [Thu Feb 21 15:55:59 2013] [error] (o.name, json_serialize(o)) for o in self.api.Object() [Thu Feb 21 15:55:59 2013] [error] File "/usr/lib/python2.6/site-packages/ipalib/util.py", line 55, in json_serialize [Thu Feb 21 15:55:59 2013] [error] return json_serialize(obj.__json__()) [Thu Feb 21 15:55:59 2013] [error] File "/usr/lib/python2.6/site-packages/ipalib/plugins/baseldap.py", line 644, in __json__ [Thu Feb 21 15:55:59 2013] [error] attrs = self.api.Backend.ldap2.schema.attribute_types(objectclasses) [Thu Feb 21 15:55:59 2013] [error] File "/usr/lib64/python2.6/site-packages/ldap/schema/subentry.py", line 277, in attribute_types [Thu Feb 21 15:55:59 2013] [error] object_class = self.sed[ObjectClass][object_class_oid] [Thu Feb 21 15:55:59 2013] [error] KeyError: 'ipaExternalGroup' [Thu Feb 21 15:55:59 2013] [error] ipa: INFO: erinn at EXAMPLE.COM: json_metadata(None, None, object=u'all'): KeyError -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 555 bytes Desc: OpenPGP digital signature URL: From rcritten at redhat.com Thu Feb 21 16:07:21 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 21 Feb 2013 11:07:21 -0500 Subject: [Freeipa-users] Upgrading to 6.4 In-Reply-To: <5126443D.60806@gmail.com> References: <5126443D.60806@gmail.com> Message-ID: <51264639.6000005@redhat.com> Erinn Looney-Triggs wrote: > For the fool hearty amongst us, as in me, I upgraded to RHEL 6.4 today. > > So far the Web UI portion of IPA is broken. I receive the following > error via the UI: IPA Error 903 an internal error has occurred. > > Other things appear to be working fine, though my testing hasn't been > all that thorough at this point. > > From the error logs: > [Thu Feb 21 15:55:59 2013] [error] ipa: ERROR: non-public: KeyError: > 'ipaExternalGroup' > [Thu Feb 21 15:55:59 2013] [error] Traceback (most recent call last): > [Thu Feb 21 15:55:59 2013] [error] File > "/usr/lib/python2.6/site-packages/ipaserver/rpcserver.py", line 334, in > wsgi_execute > [Thu Feb 21 15:55:59 2013] [error] result = > self.Command[name](*args, **options) > [Thu Feb 21 15:55:59 2013] [error] File > "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line 435, in __call__ > [Thu Feb 21 15:55:59 2013] [error] ret = self.run(*args, **options) > [Thu Feb 21 15:55:59 2013] [error] File > "/usr/lib/python2.6/site-packages/ipalib/frontend.py", line 747, in run > [Thu Feb 21 15:55:59 2013] [error] return self.execute(*args, **options) > [Thu Feb 21 15:55:59 2013] [error] File > "/usr/lib/python2.6/site-packages/ipalib/plugins/internal.py", line 119, > in execute > [Thu Feb 21 15:55:59 2013] [error] (o.name, json_serialize(o)) for o > in self.api.Object() > [Thu Feb 21 15:55:59 2013] [error] File > "/usr/lib/python2.6/site-packages/ipalib/plugins/internal.py", line 119, > in > [Thu Feb 21 15:55:59 2013] [error] (o.name, json_serialize(o)) for o > in self.api.Object() > [Thu Feb 21 15:55:59 2013] [error] File > "/usr/lib/python2.6/site-packages/ipalib/util.py", line 55, in > json_serialize > [Thu Feb 21 15:55:59 2013] [error] return json_serialize(obj.__json__()) > [Thu Feb 21 15:55:59 2013] [error] File > "/usr/lib/python2.6/site-packages/ipalib/plugins/baseldap.py", line 644, > in __json__ > [Thu Feb 21 15:55:59 2013] [error] attrs = > self.api.Backend.ldap2.schema.attribute_types(objectclasses) > [Thu Feb 21 15:55:59 2013] [error] File > "/usr/lib64/python2.6/site-packages/ldap/schema/subentry.py", line 277, > in attribute_types > [Thu Feb 21 15:55:59 2013] [error] object_class = > self.sed[ObjectClass][object_class_oid] > [Thu Feb 21 15:55:59 2013] [error] KeyError: 'ipaExternalGroup' > [Thu Feb 21 15:55:59 2013] [error] ipa: INFO: erinn at EXAMPLE.COM: > json_metadata(None, None, object=u'all'): KeyError > Hmm, this sounds like https://fedorahosted.org/freeipa/ticket/3398 Try this. Create an update file, say schema.update that contains: add:attributeTypes: (2.16.840.1.113730.3.8.11.1 NAME 'ipaExternalMember' DESC 'External Group Member Identifier' EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'IPA v3' ) add:objectClasses: (2.16.840.1.113730.3.8.12.1 NAME 'ipaExternalGroup' SUP top STRUCTURAL MUST ( cn ) MAY ( ipaExternalMember $$ memberOf $$ description $$ owner) X-ORIGIN 'IPA v3' ) Then run: ipa-ldap-updater /path/to/schema.update Restart httpd and things should work. rob From erinn.looneytriggs at gmail.com Thu Feb 21 16:29:31 2013 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Thu, 21 Feb 2013 09:29:31 -0700 Subject: [Freeipa-users] Upgrading to 6.4 In-Reply-To: <51264639.6000005@redhat.com> References: <5126443D.60806@gmail.com> <51264639.6000005@redhat.com> Message-ID: <51264B6B.9030109@gmail.com> On 02/21/2013 09:07 AM, Rob Crittenden wrote: > add:attributeTypes: (2.16.840.1.113730.3.8.11.1 NAME 'ipaExternalMember' > DESC 'External Group Member Identifier' EQUALITY caseIgnoreMatch > ORDERING caseIgnoreOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 > X-ORIGIN 'IPA v3' ) > add:objectClasses: (2.16.840.1.113730.3.8.12.1 NAME 'ipaExternalGroup' > SUP top STRUCTURAL MUST ( cn ) MAY ( ipaExternalMember $$ memberOf $$ > description $$ owner) X-ORIGIN 'IPA v3' ) Well that fails as well, though in sort of a self inflicted way: 2013-02-21T16:24:30Z INFO The ipa-ldap-updater command failed, exception: DatabaseError: Server is unwilling to perform: Minimum SSF not met. arguments: base="cn=config,cn=ldbm database,cn=plugins,cn=config", scope=0, filterstr="(objectclass=*)" 2013-02-21T16:24:30Z ERROR Unexpected error - see /var/log/ipaupgrade.log for details: DatabaseError: Server is unwilling to perform: Minimum SSF not met. arguments: base="cn=config,cn=ldbm database,cn=plugins,cn=config", scope=0, filterstr="(objectclass=*)" Now this probably comes about because I set: nsslapd-minssf: 56 For security. I can cange that back to the default and probably move past this, but is that a known issue? Is there another way around? -Erinn -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 555 bytes Desc: OpenPGP digital signature URL: From rcritten at redhat.com Thu Feb 21 16:40:13 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 21 Feb 2013 11:40:13 -0500 Subject: [Freeipa-users] Upgrading to 6.4 In-Reply-To: <51264D8E.70604@gmail.com> References: <5126443D.60806@gmail.com> <51264639.6000005@redhat.com> <51264B6B.9030109@gmail.com> <51264C83.50703@redhat.com> <51264D8E.70604@gmail.com> Message-ID: <51264DED.6010000@redhat.com> Erinn Looney-Triggs wrote: > On 02/21/2013 09:34 AM, Rob Crittenden wrote: >> Erinn Looney-Triggs wrote: >>> On 02/21/2013 09:07 AM, Rob Crittenden wrote: >>>> add:attributeTypes: (2.16.840.1.113730.3.8.11.1 NAME 'ipaExternalMember' >>>> DESC 'External Group Member Identifier' EQUALITY caseIgnoreMatch >>>> ORDERING caseIgnoreOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 >>>> X-ORIGIN 'IPA v3' ) >>>> add:objectClasses: (2.16.840.1.113730.3.8.12.1 NAME 'ipaExternalGroup' >>>> SUP top STRUCTURAL MUST ( cn ) MAY ( ipaExternalMember $$ memberOf $$ >>>> description $$ owner) X-ORIGIN 'IPA v3' ) >>> >>> Well that fails as well, though in sort of a self inflicted way: >>> >>> 2013-02-21T16:24:30Z INFO The ipa-ldap-updater command failed, >>> exception: DatabaseError: Server is unwilling to perform: Minimum SSF >>> not met. arguments: base="cn=config,cn=ldbm >>> database,cn=plugins,cn=config", scope=0, filterstr="(objectclass=*)" >>> 2013-02-21T16:24:30Z ERROR Unexpected error - see >>> /var/log/ipaupgrade.log for details: >>> DatabaseError: Server is unwilling to perform: Minimum SSF not met. >>> arguments: base="cn=config,cn=ldbm database,cn=plugins,cn=config", >>> scope=0, filterstr="(objectclass=*)" >>> >>> >>> Now this probably comes about because I set: >>> nsslapd-minssf: 56 >>> For security. >>> >>> I can cange that back to the default and probably move past this, but is >>> that a known issue? Is there another way around? >> >> As root try the --ldapi flag: >> >> # ipa-ldap-updater --ldapi /path/to/scheme.update >> >> rob >> > > ERROR: LDAPUpdate: syntax error: > dn is not defined in the update, data source=schema.update > > -Erinn > Sorry, add this to the top of your update file: dn: cn=schema rob From erinn.looneytriggs at gmail.com Thu Feb 21 16:44:32 2013 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Thu, 21 Feb 2013 09:44:32 -0700 Subject: [Freeipa-users] Upgrading to 6.4 In-Reply-To: <51264DED.6010000@redhat.com> References: <5126443D.60806@gmail.com> <51264639.6000005@redhat.com> <51264B6B.9030109@gmail.com> <51264C83.50703@redhat.com> <51264D8E.70604@gmail.com> <51264DED.6010000@redhat.com> Message-ID: <51264EF0.6070905@gmail.com> On 02/21/2013 09:40 AM, Rob Crittenden wrote: > Erinn Looney-Triggs wrote: >> On 02/21/2013 09:34 AM, Rob Crittenden wrote: >>> Erinn Looney-Triggs wrote: >>>> On 02/21/2013 09:07 AM, Rob Crittenden wrote: >>>>> add:attributeTypes: (2.16.840.1.113730.3.8.11.1 NAME >>>>> 'ipaExternalMember' >>>>> DESC 'External Group Member Identifier' EQUALITY caseIgnoreMatch >>>>> ORDERING caseIgnoreOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 >>>>> X-ORIGIN 'IPA v3' ) >>>>> add:objectClasses: (2.16.840.1.113730.3.8.12.1 NAME 'ipaExternalGroup' >>>>> SUP top STRUCTURAL MUST ( cn ) MAY ( ipaExternalMember $$ memberOf $$ >>>>> description $$ owner) X-ORIGIN 'IPA v3' ) >>>> >>>> Well that fails as well, though in sort of a self inflicted way: >>>> >>>> 2013-02-21T16:24:30Z INFO The ipa-ldap-updater command failed, >>>> exception: DatabaseError: Server is unwilling to perform: Minimum SSF >>>> not met. arguments: base="cn=config,cn=ldbm >>>> database,cn=plugins,cn=config", scope=0, filterstr="(objectclass=*)" >>>> 2013-02-21T16:24:30Z ERROR Unexpected error - see >>>> /var/log/ipaupgrade.log for details: >>>> DatabaseError: Server is unwilling to perform: Minimum SSF not met. >>>> arguments: base="cn=config,cn=ldbm database,cn=plugins,cn=config", >>>> scope=0, filterstr="(objectclass=*)" >>>> >>>> >>>> Now this probably comes about because I set: >>>> nsslapd-minssf: 56 >>>> For security. >>>> >>>> I can cange that back to the default and probably move past this, >>>> but is >>>> that a known issue? Is there another way around? >>> >>> As root try the --ldapi flag: >>> >>> # ipa-ldap-updater --ldapi /path/to/scheme.update >>> >>> rob >>> >> >> ERROR: LDAPUpdate: syntax error: >> dn is not defined in the update, data source=schema.update >> >> -Erinn >> > > Sorry, add this to the top of your update file: > > dn: cn=schema > > rob No worries! Thanks for the help, after a restart of IPA the web UI is working again. I reckon this is something that needs to be fixed, does opening a support case and pointing them to that bug help you folks out with this in any way? -Erinn -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 555 bytes Desc: OpenPGP digital signature URL: From erinn.looneytriggs at gmail.com Thu Feb 21 16:38:38 2013 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Thu, 21 Feb 2013 09:38:38 -0700 Subject: [Freeipa-users] Upgrading to 6.4 In-Reply-To: <51264C83.50703@redhat.com> References: <5126443D.60806@gmail.com> <51264639.6000005@redhat.com> <51264B6B.9030109@gmail.com> <51264C83.50703@redhat.com> Message-ID: <51264D8E.70604@gmail.com> On 02/21/2013 09:34 AM, Rob Crittenden wrote: > Erinn Looney-Triggs wrote: >> On 02/21/2013 09:07 AM, Rob Crittenden wrote: >>> add:attributeTypes: (2.16.840.1.113730.3.8.11.1 NAME 'ipaExternalMember' >>> DESC 'External Group Member Identifier' EQUALITY caseIgnoreMatch >>> ORDERING caseIgnoreOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 >>> X-ORIGIN 'IPA v3' ) >>> add:objectClasses: (2.16.840.1.113730.3.8.12.1 NAME 'ipaExternalGroup' >>> SUP top STRUCTURAL MUST ( cn ) MAY ( ipaExternalMember $$ memberOf $$ >>> description $$ owner) X-ORIGIN 'IPA v3' ) >> >> Well that fails as well, though in sort of a self inflicted way: >> >> 2013-02-21T16:24:30Z INFO The ipa-ldap-updater command failed, >> exception: DatabaseError: Server is unwilling to perform: Minimum SSF >> not met. arguments: base="cn=config,cn=ldbm >> database,cn=plugins,cn=config", scope=0, filterstr="(objectclass=*)" >> 2013-02-21T16:24:30Z ERROR Unexpected error - see >> /var/log/ipaupgrade.log for details: >> DatabaseError: Server is unwilling to perform: Minimum SSF not met. >> arguments: base="cn=config,cn=ldbm database,cn=plugins,cn=config", >> scope=0, filterstr="(objectclass=*)" >> >> >> Now this probably comes about because I set: >> nsslapd-minssf: 56 >> For security. >> >> I can cange that back to the default and probably move past this, but is >> that a known issue? Is there another way around? > > As root try the --ldapi flag: > > # ipa-ldap-updater --ldapi /path/to/scheme.update > > rob > ERROR: LDAPUpdate: syntax error: dn is not defined in the update, data source=schema.update -Erinn -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 555 bytes Desc: OpenPGP digital signature URL: From rcritten at redhat.com Thu Feb 21 16:34:11 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 21 Feb 2013 11:34:11 -0500 Subject: [Freeipa-users] Upgrading to 6.4 In-Reply-To: <51264B6B.9030109@gmail.com> References: <5126443D.60806@gmail.com> <51264639.6000005@redhat.com> <51264B6B.9030109@gmail.com> Message-ID: <51264C83.50703@redhat.com> Erinn Looney-Triggs wrote: > On 02/21/2013 09:07 AM, Rob Crittenden wrote: >> add:attributeTypes: (2.16.840.1.113730.3.8.11.1 NAME 'ipaExternalMember' >> DESC 'External Group Member Identifier' EQUALITY caseIgnoreMatch >> ORDERING caseIgnoreOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 >> X-ORIGIN 'IPA v3' ) >> add:objectClasses: (2.16.840.1.113730.3.8.12.1 NAME 'ipaExternalGroup' >> SUP top STRUCTURAL MUST ( cn ) MAY ( ipaExternalMember $$ memberOf $$ >> description $$ owner) X-ORIGIN 'IPA v3' ) > > Well that fails as well, though in sort of a self inflicted way: > > 2013-02-21T16:24:30Z INFO The ipa-ldap-updater command failed, > exception: DatabaseError: Server is unwilling to perform: Minimum SSF > not met. arguments: base="cn=config,cn=ldbm > database,cn=plugins,cn=config", scope=0, filterstr="(objectclass=*)" > 2013-02-21T16:24:30Z ERROR Unexpected error - see > /var/log/ipaupgrade.log for details: > DatabaseError: Server is unwilling to perform: Minimum SSF not met. > arguments: base="cn=config,cn=ldbm database,cn=plugins,cn=config", > scope=0, filterstr="(objectclass=*)" > > > Now this probably comes about because I set: > nsslapd-minssf: 56 > For security. > > I can cange that back to the default and probably move past this, but is > that a known issue? Is there another way around? As root try the --ldapi flag: # ipa-ldap-updater --ldapi /path/to/scheme.update rob From bret.wortman at damascusgrp.com Thu Feb 21 17:27:53 2013 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Thu, 21 Feb 2013 12:27:53 -0500 Subject: [Freeipa-users] Trouble creating replica In-Reply-To: <5126432A.4030004@redhat.com> References: <5125753E.9090009@redhat.com> <1361410994756.97af79da@Nodemailer> <51258062.20702@redhat.com> <5126432A.4030004@redhat.com> Message-ID: Thanks for the bug link. We let the developer we thought had messed things up out of the 4x4 cell we had stashed him in. He's still blinking from sunlight but the doctors tell us the facial twitching will stop in a month or two. * * *Bret Wortman* http://damascusgrp.com/ http://twitter.com/BretWortman On Thu, Feb 21, 2013 at 10:54 AM, Rich Megginson wrote: > On 02/21/2013 07:11 AM, Bret Wortman wrote: > > Rich, > > 389-ds-base-1.2.11.5-1.fc17.x86_64. > > The box is a DL360G8. > > https://fedorahosted.org/389/ticket/518 > > > * > * > *Bret Wortman* > > http://damascusgrp.com/ > http://twitter.com/BretWortman > > > On Wed, Feb 20, 2013 at 9:03 PM, Rich Megginson wrote: > >> On 02/20/2013 06:43 PM, Bret Wortman wrote: >> >> Mine was not. >> >> What platform? What version of 389-ds-base? >> >> >> ? >> Bret Wortman >> >> >> On Wed, Feb 20, 2013 at 8:16 PM, Rich Megginson wrote: >> >>> On 02/20/2013 06:00 PM, KodaK wrote: >>> >>> >>> >>> On Wed, Feb 20, 2013 at 8:41 AM, Bret Wortman < >>> bret.wortman at damascusgrp.com> wrote: >>> >>>> Eureka! >>>> >>>> Someone had deleted the contents of >>>> /etc/dirsrv/slapd-PKI-IPA/dse.ldif. I replaced it from a saved copy and now >>>> everything's working as expected. >>>> >>>> Thanks everyone for your contributions, patience, and indulgence. And >>>> for a wonderful product! >>>> >>>> >>> I wouldn't be too sure that someone deleted it. A couple of weeks ago >>> I had a crash and half of my replicas had an empty dse.ldif. I think you >>> and I may be hitting a bug. >>> >>> >>> were these virtual machines? >>> >>> >>> --Jason >>> >>> >>> _______________________________________________ >>> Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users >>> >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Thu Feb 21 17:31:22 2013 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 21 Feb 2013 12:31:22 -0500 Subject: [Freeipa-users] Upgrading to 6.4 In-Reply-To: <51264EF0.6070905@gmail.com> References: <5126443D.60806@gmail.com> <51264639.6000005@redhat.com> <51264B6B.9030109@gmail.com> <51264C83.50703@redhat.com> <51264D8E.70604@gmail.com> <51264DED.6010000@redhat.com> <51264EF0.6070905@gmail.com> Message-ID: <512659EA.5060808@redhat.com> On 02/21/2013 11:44 AM, Erinn Looney-Triggs wrote: > On 02/21/2013 09:40 AM, Rob Crittenden wrote: >> Erinn Looney-Triggs wrote: >>> On 02/21/2013 09:34 AM, Rob Crittenden wrote: >>>> Erinn Looney-Triggs wrote: >>>>> On 02/21/2013 09:07 AM, Rob Crittenden wrote: >>>>>> add:attributeTypes: (2.16.840.1.113730.3.8.11.1 NAME >>>>>> 'ipaExternalMember' >>>>>> DESC 'External Group Member Identifier' EQUALITY caseIgnoreMatch >>>>>> ORDERING caseIgnoreOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 >>>>>> X-ORIGIN 'IPA v3' ) >>>>>> add:objectClasses: (2.16.840.1.113730.3.8.12.1 NAME 'ipaExternalGroup' >>>>>> SUP top STRUCTURAL MUST ( cn ) MAY ( ipaExternalMember $$ memberOf $$ >>>>>> description $$ owner) X-ORIGIN 'IPA v3' ) >>>>> Well that fails as well, though in sort of a self inflicted way: >>>>> >>>>> 2013-02-21T16:24:30Z INFO The ipa-ldap-updater command failed, >>>>> exception: DatabaseError: Server is unwilling to perform: Minimum SSF >>>>> not met. arguments: base="cn=config,cn=ldbm >>>>> database,cn=plugins,cn=config", scope=0, filterstr="(objectclass=*)" >>>>> 2013-02-21T16:24:30Z ERROR Unexpected error - see >>>>> /var/log/ipaupgrade.log for details: >>>>> DatabaseError: Server is unwilling to perform: Minimum SSF not met. >>>>> arguments: base="cn=config,cn=ldbm database,cn=plugins,cn=config", >>>>> scope=0, filterstr="(objectclass=*)" >>>>> >>>>> >>>>> Now this probably comes about because I set: >>>>> nsslapd-minssf: 56 >>>>> For security. >>>>> >>>>> I can cange that back to the default and probably move past this, >>>>> but is >>>>> that a known issue? Is there another way around? >>>> As root try the --ldapi flag: >>>> >>>> # ipa-ldap-updater --ldapi /path/to/scheme.update >>>> >>>> rob >>>> >>> ERROR: LDAPUpdate: syntax error: >>> dn is not defined in the update, data source=schema.update >>> >>> -Erinn >>> >> Sorry, add this to the top of your update file: >> >> dn: cn=schema >> >> rob > No worries! Thanks for the help, after a restart of IPA the web UI is > working again. I reckon this is something that needs to be fixed, does > opening a support case and pointing them to that bug help you folks out > with this in any way? This is a know defect. We just did not realize it would have such a bad impact on upgrade. Sorry, the errata is on the way. I would recommend everyone to not upgrade to 6.4 until the errata is shipped. We will notify you as soon as it goes out. Sorry again. > > -Erinn > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrerobauru at gmail.com Thu Feb 21 17:32:28 2013 From: andrerobauru at gmail.com (Andre Rodrigues) Date: Thu, 21 Feb 2013 14:32:28 -0300 Subject: [Freeipa-users] login problem after set trust Message-ID: Hi all, I'm testing trust Freeipa-AD follow the "how to" http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup After set ipa trust-add users from AD domain can logon on ipa domain using ssh (ssh -l user at AD.DOMAIN linux.ipa), but FreeIPA users can't logon on Windows machine (winserver 2008) (using IPA.DOMAIN\user or user at IPA.DOMAIN as username): ?The name or security ID (SID) of the domain specified is inconsistent with the trust information for that domain? Sometimes another error appears: ?There are no logon servers available to service the logon request? Both errors seems to be from samba4, but I don't find a solution yet. Some users reported that after update samba this problem was solved, but my samba is updated. Someone has gone through this error or can help me? Att, andre rodrigues From abokovoy at redhat.com Thu Feb 21 18:33:35 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 21 Feb 2013 20:33:35 +0200 Subject: [Freeipa-users] login problem after set trust In-Reply-To: References: Message-ID: <20130221183335.GA4860@redhat.com> On Thu, 21 Feb 2013, Andre Rodrigues wrote: >Hi all, > >I'm testing trust Freeipa-AD follow the "how to" >http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup > >After set ipa trust-add users from AD domain can logon on ipa domain >using ssh (ssh -l user at AD.DOMAIN linux.ipa), but FreeIPA users can't >logon on Windows machine (winserver 2008) (using IPA.DOMAIN\user or >user at IPA.DOMAIN as username): >?The name or security ID (SID) of the domain specified is inconsistent >with the trust information for that domain? > >Sometimes another error appears: >?There are no logon servers available to service the logon request? > >Both errors seems to be from samba4, but I don't find a solution yet. >Some users reported that after update samba this problem was solved, >but my samba is updated. > >Someone has gone through this error or can help me? Yes, this is expected because we have not yet finished this part of the puzzle. Currently only IPA resources are available to Windows users, not vice versa. There is still work in progress slated for Fedora 19. -- / Alexander Bokovoy From phalen at gmail.com Fri Feb 22 00:23:34 2013 From: phalen at gmail.com (Kendrick .) Date: Thu, 21 Feb 2013 19:23:34 -0500 Subject: [Freeipa-users] --external-ca is a bit confusing. Message-ID: It is part of my initial setup. I copied the ipa.csr in to cacert's signing system so that the certificates would be valid outside of my local domain. and it errors because the host information said certificate authority instead of the host name if I understand that error mesage properly. I am trying to get the csr to provide all the information needed by cacerts free signing service. I was expecting to be able to use the user certificates that freeipa makes to sign emails and such that would go externally. - - *From*: Dmitri Pal - *To*: freeipa-users redhat com - *Subject*: Re: [Freeipa-users] --external-ca is a bit confusing. - *Date*: Thu, 21 Feb 2013 03:30:45 -0500 ------------------------------ On 02/20/2013 10:20 PM, Kendrick . wrote: I am trying to get cacert to sign the csr. I have tried searching about it and cant figure out what is what. some information i have found suggests it wont be possible. when I go to get the csr signed i get "The following hostnames were rejected because the system couldn't link them to your account, if they are valid please verify the domains against your account. Rejected: Certificate Authority" I would prefer my certificates to be valid on the internet as some of the user certs would be used to sign emails and such. any advice would be appriciated. _______________________________________________ Freeipa-users mailing listFreeipa-users redhat comhttps://www.redhat.com/mailman/listinfo/freeipa-users Can you please be more specific about what you are doing? The linking to the external CA is one time operation during the initial installation. If you want to use the IPA as a subordinate CA you need to specify a flag during installation (it seems that you are doing that based on the comments above). The installation will stop indicating that you need to take CSR and sign by the external CA. So you should take the CSR and sign. Then you present the result back to IPA and continue the installation. Based on the description above it is not clear which step is failing. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs?www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdennis at redhat.com Fri Feb 22 02:52:36 2013 From: jdennis at redhat.com (John Dennis) Date: Thu, 21 Feb 2013 21:52:36 -0500 Subject: [Freeipa-users] --external-ca is a bit confusing. In-Reply-To: References: Message-ID: <5126DD74.90406@redhat.com> On 02/21/2013 07:23 PM, Kendrick . wrote: > It is part of my initial setup. I copied the ipa.csr in to cacert's > signing system so that the certificates would be valid outside of my > local domain. and it errors because the host information said > certificate authority instead of the host name if I understand that > error mesage properly. > > I am trying to get the csr to provide all the information needed by > cacerts free signing service. I was expecting to be able to use the > user certificates that freeipa makes to sign emails and such that would > go externally. The CA will only sign a cert for a domain registered to you. To see what domain the CSR is for dump it's contents using openssl, for example: openssl req -in ipa.csr -noout -text Does the CN in the subject match the domain you registered with cacert.org? If not it's not going to sign it. But wait, there's more, you're not just asking cacert to sign a plain cert you're asking it to sign a CA cert effectively creating a sub-CA of cacert. That means with that cert you can issue new certs and cacert will "vouch" for them, but of course they can't control who you're issuing certs to which is a significant security issue. This FAQ entry from cacert will help clarify: http://wiki.cacert.org/SubRoot -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From hboetes at gmail.com Fri Feb 22 08:49:33 2013 From: hboetes at gmail.com (Han Boetes) Date: Fri, 22 Feb 2013 09:49:33 +0100 Subject: [Freeipa-users] Windows authentication against FreeIPA documentation question. Message-ID: Regarding: http://freeipa.org/page/Windows_authentication_against_FreeIPA I noticed that I have to create a matching user on the windows machine before the user can log in. I don't have to set the password, but I do have to add a user as the local admin on that windows machine. windows 7 32 bit in this case. Am I missing something or is the documentation missing something? # Han -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Fri Feb 22 09:04:36 2013 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 22 Feb 2013 10:04:36 +0100 Subject: [Freeipa-users] Windows authentication against FreeIPA documentation question. In-Reply-To: References: Message-ID: <512734A4.40808@redhat.com> On 22.2.2013 09:49, Han Boetes wrote: > Regarding: http://freeipa.org/page/Windows_authentication_against_FreeIPA > > I noticed that I have to create a matching user on the windows machine before > the user can log in. I don't have to set the password, but I do have to add a > user as the local admin on that windows machine. windows 7 32 bit in this case. > > Am I missing something or is the documentation missing something? You didn't miss anything. MS Windows are able to use IPA (standard Kerberos) for authentication, but there is no standard way to use external LDAP database for Windows user accounts. For this reason you have to create local account for each user manually. I.e. IPA != AD. IPA <-> AD trust could work better for you, it depends on requirements. Look at pGina [1] if you don't want AD. [1] http://pgina.org/ -- Petr^2 Spacek From pspacek at redhat.com Fri Feb 22 12:55:19 2013 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 22 Feb 2013 13:55:19 +0100 Subject: [Freeipa-users] Windows authentication against FreeIPA documentation question. In-Reply-To: <512734A4.40808@redhat.com> References: <512734A4.40808@redhat.com> Message-ID: <51276AB7.4000805@redhat.com> On 22.2.2013 10:04, Petr Spacek wrote: > On 22.2.2013 09:49, Han Boetes wrote: >> Regarding: http://freeipa.org/page/Windows_authentication_against_FreeIPA >> >> I noticed that I have to create a matching user on the windows machine before >> the user can log in. I don't have to set the password, but I do have to add a >> user as the local admin on that windows machine. windows 7 32 bit in this case. >> >> Am I missing something or is the documentation missing something? > > You didn't miss anything. MS Windows are able to use IPA (standard Kerberos) > for authentication, but there is no standard way to use external LDAP database > for Windows user accounts. > > For this reason you have to create local account for each user manually. > > I.e. IPA != AD. > > IPA <-> AD trust could work better for you, it depends on requirements. Look > at pGina [1] if you don't want AD. > > [1] http://pgina.org/ I added explanatory paragraph to http://freeipa.org/page/Windows_authentication_against_FreeIPA Han, could you check if is it understandable, please? -- Petr^2 Spacek From hboetes at gmail.com Fri Feb 22 13:35:55 2013 From: hboetes at gmail.com (Han Boetes) Date: Fri, 22 Feb 2013 14:35:55 +0100 Subject: [Freeipa-users] Fwd: Windows authentication against FreeIPA documentation question. In-Reply-To: References: <512734A4.40808@redhat.com> <51276AB7.4000805@redhat.com> Message-ID: That is the perfect explanation. For redundancy sake I would recommend to add change this part: 7. *** REBOOT *** 8. Log in as [user]@[REALM] with the initial password, you will be prompted to change the password then logged in. to 7. *** REBOOT *** 8. If you don't use an AD-trust add user accounts for all users that need to be able to log in. Do not set up a password for those users. 9. Log in as [user]@[REALM] with the initial password, you will be prompted to change the password then logged in. # Han -------------- next part -------------- An HTML attachment was scrubbed... URL: From sakodak at gmail.com Fri Feb 22 15:52:04 2013 From: sakodak at gmail.com (KodaK) Date: Fri, 22 Feb 2013 09:52:04 -0600 Subject: [Freeipa-users] IPA with ILO Message-ID: Just curious if anyone has configured HP ILO to authenticate against IPA. I'm just starting out and the fact that the ILO configuration screen has a section for a "SID" has me a bit concerned. -- The government is going to read our mail anyway, might as well make it tough for them. GPG Public key ID: B6A1A7C6 From natxo.asenjo at gmail.com Fri Feb 22 16:24:22 2013 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Fri, 22 Feb 2013 17:24:22 +0100 Subject: [Freeipa-users] IPA with ILO In-Reply-To: References: Message-ID: On Fri, Feb 22, 2013 at 4:52 PM, KodaK wrote: > Just curious if anyone has configured HP ILO to authenticate against > IPA. I'm just starting out and the fact that the ILO configuration > screen has a section for a "SID" has me a bit concerned. i have not touched new HP gear for a while, but on our HP ILO of g5/6 proliants there is an ldap option, so you should be able to use that. -- natxo From sakodak at gmail.com Fri Feb 22 16:41:29 2013 From: sakodak at gmail.com (KodaK) Date: Fri, 22 Feb 2013 10:41:29 -0600 Subject: [Freeipa-users] IPA with ILO In-Reply-To: References: Message-ID: On Fri, Feb 22, 2013 at 10:05 AM, Han Boetes wrote: > Hi Kodak, > > The question is: Which authentication mechanisms does HP ILO support? Their documentation kind of blurs the lines. It appears that the only directory that exists (according to HP) is AD, so they freely mix LDAP, AD and directory when talking about it in their documentation. It's a moot point now, though, because I brought it up that I needed a directory license for ILO to the Windows admins (who also "own" the hardware) and they nixed it -- they want to use AD or nothing. Sigh. Thanks, --Jason From dale at themacartneyclan.com Sat Feb 23 17:48:44 2013 From: dale at themacartneyclan.com (Dale Macartney) Date: Sat, 23 Feb 2013 17:48:44 +0000 Subject: [Freeipa-users] RHEL 6.4 , IPA 3.0 and bind-chroot Message-ID: <512900FC.3090608@themacartneyclan.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all I've just performed a clean IPA installation and noticed that if you're using integrated DNS, you are still unable to use bind in a chrooted environment with a default IPA install. Basically if its a chrooted environment, named will fail to start. To replicate what I've done, do the following. # yum install ipa-server bind bind-chroot bind-dyndb-ldap -y # ipa-server-install --setup-dns (do your usual thing here) - From what I've been testing, there needs to be quite a few libraries located in the chroot environment. I've done the below to get a little further (I should probably use symbolic links, but for now copying the files is a start). mkdir /var/named/chroot/lib64/ cp /lib64/libldap-2.4.so.2 /var/named/chroot/lib64/ cp /lib64/liblber-2.4.so.2 /var/named/chroot/lib64/ cp /lib64/libplds4.so /var/named/chroot/lib64/ cp /lib64/libplc4.so /var/named/chroot/lib64/ cp /lib64/libnspr4.so /var/named/chroot/lib64/ cp /lib64/libcrypt.so.1 /var/named/chroot/lib64/ cp /lib64/libfreebl3.so /var/named/chroot/lib64/ mkdir /var/named/chroot/usr/lib64/ cp /usr/lib64/libssl3.so /var/named/chroot/usr/lib64/ cp /usr/lib64/libsmime3.so /var/named/chroot/usr/lib64/ cp /usr/lib64/libnss3.so /var/named/chroot/usr/lib64/ cp /usr/lib64/libnssutil3.so /var/named/chroot/usr/lib64/ cp /usr/lib64/libsasl2.so.2 /var/named/chroot/usr/lib64/ Now when I restart named, I get the below error in /var/log/messages. Does anyone have any ideas of the best way to get around this error? Feb 23 17:35:29 ds01 named[2425]: Failed to parse the principal name DNS/ds01.example.com (Configuration file does not specify default realm) Thanks folks. Dale -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRKQD4AAoJEAJsWS61tB+qN4QP/1yICe5uzSQFvARf1wFPfLzV YWzS8orBTwtPAhVcTCfD6GNuFqiypzjumdqNwL75Gm4jBeB1dIoZnaMKaVWaTvau 0sryplL1YZVu4UBLWc5igOK5HRkIeV4yrzCnH/1vnDEiEkJQ8xPCRw7IEfXdD4/N Cas5uOL9aJo9TQf22cHoIRoESeULzkLmn+tIOYpeTFQlnrhIpFhLcNO35gJmuwyG revPahRhm4FsW368K+ZnhEouF3cBK+0rMpaC/yi7rUD6PXxK1LaSNMUREG9e6dh/ hx3LoR1tEhzu7buYymwQ33wKM3J9o+HOZiUkxann5YXG+4HBk96XgJ8Mh4bQ03ZJ A6kMh4CFQxxuOMzQ65c2jj94zvSZFnLRMFgbWuWdZklEyVFk7m1aZ+b7wRwRafBB BAnEYf+3yCnBjpXyKJSTIs1PZaOSQ0GFg1pLmLYr601ATJ5omcl/a5J4x/l2ofUq PjFOmARAOb7hIX6zrlGuHFoXoctrweAmorO1suWsUR3beecaQAfMqpfpS9OkDsng YM8C0IXAo31GGhJDOO0IzuGx+PMtb/ASrW+9ogWM9OI0cTPZvbZtUi0zrIt3lMzJ 62rTHJHvHbEk5sXZvZT9Omd42Tq2yNyt+40TrSZsQX5EBcTxiFD1aeI/UiISRQFI vEJAbiE+LtGGDrso+6J+ =QR+Y -----END PGP SIGNATURE----- From dpal at redhat.com Sat Feb 23 21:47:35 2013 From: dpal at redhat.com (Dmitri Pal) Date: Sat, 23 Feb 2013 16:47:35 -0500 Subject: [Freeipa-users] RHEL 6.4 , IPA 3.0 and bind-chroot In-Reply-To: <512900FC.3090608@themacartneyclan.com> References: <512900FC.3090608@themacartneyclan.com> Message-ID: <512938F7.40301@redhat.com> On 02/23/2013 12:48 PM, Dale Macartney wrote: > > Hi all > > I've just performed a clean IPA installation and noticed that if you're > using integrated DNS, you are still unable to use bind in a chrooted > environment with a default IPA install. > > Basically if its a chrooted environment, named will fail to start. > > To replicate what I've done, do the following. > > # yum install ipa-server bind bind-chroot bind-dyndb-ldap -y > # ipa-server-install --setup-dns (do your usual thing here) > > - From what I've been testing, there needs to be quite a few libraries > located in the chroot environment. > > I've done the below to get a little further (I should probably use > symbolic links, but for now copying the files is a start). > > mkdir /var/named/chroot/lib64/ > cp /lib64/libldap-2.4.so.2 /var/named/chroot/lib64/ > cp /lib64/liblber-2.4.so.2 /var/named/chroot/lib64/ > cp /lib64/libplds4.so /var/named/chroot/lib64/ > cp /lib64/libplc4.so /var/named/chroot/lib64/ > cp /lib64/libnspr4.so /var/named/chroot/lib64/ > cp /lib64/libcrypt.so.1 /var/named/chroot/lib64/ > cp /lib64/libfreebl3.so /var/named/chroot/lib64/ > > mkdir /var/named/chroot/usr/lib64/ > cp /usr/lib64/libssl3.so /var/named/chroot/usr/lib64/ > cp /usr/lib64/libsmime3.so /var/named/chroot/usr/lib64/ > cp /usr/lib64/libnss3.so /var/named/chroot/usr/lib64/ > cp /usr/lib64/libnssutil3.so /var/named/chroot/usr/lib64/ > cp /usr/lib64/libsasl2.so.2 /var/named/chroot/usr/lib64/ > > > > Now when I restart named, I get the below error in /var/log/messages. > > Does anyone have any ideas of the best way to get around this error? > > Feb 23 17:35:29 ds01 named[2425]: Failed to parse the principal name > DNS/ds01.example.com (Configuration file does not specify default realm) It should be DNS/ds01.example.com at YOURREALMNAME.SOMETHING I do not know the exact reason but it might be that bind ldap driver can't locate its kerberos configuration. I hope it will give you a hint and unblock you before the real masters of DNS chime in. > > > Thanks folks. > > Dale > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dale at themacartneyclan.com Sat Feb 23 22:01:14 2013 From: dale at themacartneyclan.com (Dale Macartney) Date: Sat, 23 Feb 2013 22:01:14 +0000 Subject: [Freeipa-users] RHEL 6.4 , IPA 3.0 and bind-chroot In-Reply-To: <512938F7.40301@redhat.com> References: <512900FC.3090608@themacartneyclan.com> <512938F7.40301@redhat.com> Message-ID: <51293C2A.9050302@themacartneyclan.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/23/2013 09:47 PM, Dmitri Pal wrote: > On 02/23/2013 12:48 PM, Dale Macartney wrote: > > >> Hi all >> >> I've just performed a clean IPA installation and noticed that if you're >> using integrated DNS, you are still unable to use bind in a chrooted >> environment with a default IPA install. >> >> Basically if its a chrooted environment, named will fail to start. >> >> To replicate what I've done, do the following. >> >> # yum install ipa-server bind bind-chroot bind-dyndb-ldap -y >> # ipa-server-install --setup-dns (do your usual thing here) >> >> - From what I've been testing, there needs to be quite a few libraries >> located in the chroot environment. >> >> I've done the below to get a little further (I should probably use >> symbolic links, but for now copying the files is a start). >> >> mkdir /var/named/chroot/lib64/ >> cp /lib64/libldap-2.4.so.2 /var/named/chroot/lib64/ >> cp /lib64/liblber-2.4.so.2 /var/named/chroot/lib64/ >> cp /lib64/libplds4.so /var/named/chroot/lib64/ >> cp /lib64/libplc4.so /var/named/chroot/lib64/ >> cp /lib64/libnspr4.so /var/named/chroot/lib64/ >> cp /lib64/libcrypt.so.1 /var/named/chroot/lib64/ >> cp /lib64/libfreebl3.so /var/named/chroot/lib64/ >> >> mkdir /var/named/chroot/usr/lib64/ >> cp /usr/lib64/libssl3.so /var/named/chroot/usr/lib64/ >> cp /usr/lib64/libsmime3.so /var/named/chroot/usr/lib64/ >> cp /usr/lib64/libnss3.so /var/named/chroot/usr/lib64/ >> cp /usr/lib64/libnssutil3.so /var/named/chroot/usr/lib64/ >> cp /usr/lib64/libsasl2.so.2 /var/named/chroot/usr/lib64/ >> >> >> >> Now when I restart named, I get the below error in /var/log/messages. >> >> Does anyone have any ideas of the best way to get around this error? >> >> Feb 23 17:35:29 ds01 named[2425]: Failed to parse the principal name >> DNS/ds01.example.com (Configuration file does not specify default realm) > > It should be > DNS/ds01.example.com at YOURREALMNAME.SOMETHING oh of course.. what a face palm moment. Where does the default ipa installation put the DNS keytab file? I did notice an /etc/named.keytab was present, but placing that in /var/named/chroot/etc didn't seem to improve matters. > > > I do not know the exact reason but it might be that bind ldap driver can't locate its kerberos configuration. > I hope it will give you a hint and unblock you before the real masters of DNS chime in. i I know this has been a rather long lasting rfe/bug/how ever you want to label it. https://fedorahosted.org/freeipa/ticket/126 If I make any progress I'll let the team know. > >> >> >> Thanks folks. >> >> Dale >> > > > > _______________________________________________ > > Freeipa-users mailing list > > Freeipa-users at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-users > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRKTwpAAoJEAJsWS61tB+qzUEQAIgijKHJx8tSOps5avQ58HU2 8ZDSHzeokeXqvZxHGnZ3O1AsOPukS9G37TdCdEe2GqvK3c159tgYCHoV7FrksYm9 9n6cWohVdwFBdSB/Qzc+G/w/lITtt5hnXf/yT1H1b5ERtUoJUCg+dc76FCfBhJ9q DQUBfXKwbbdctGRZpo8V2tq4Vc56Rt2cQ+XsFj1Tsvz8NfW6fSx24rYnpu0FEPnp 2CDeQufE3cbeViGE9AEM8sa/pqXqgL16KNoFZoRqtYWCcE/Ct/rTCrITkx8xMinw 8dc+6kvG0xvuQXpfi/iCEZq+sAr2WA/3vwBg2VDDjNrCQZurGEgD6/wmcNXclN8X jasRaAfw2YqnR40wB9zqNZS50KzF2F72xIDjiFsWF/DssJnEOR6QxxKWaZbjPH4K Ud/aEhk5p3NSOlz5XBMBlnHkrElbA9/c6J396fPqgyMNXFrc1t5ofaPtzaYNJzSz PdpCWmZ8+L4aJfci2vFo6aKuQHKgYetRLA/pemNEdQK1gYvD0/LJ8zExrXKHRszC ILPhpacO4n/SXcWx2EKY4rtD0RNyiWxdQAjAtFfyvwqXuD7a1mXNkaCL71dhvWWU xvrsGid6Bb5ca2/6A1C/VZvYFIQ9Fg6dYZrEERvbcPeV80qizVeWYDSetZwGhfPZ GiYyWRDdRZrUb5tW8Xtd =aaLP -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From dale at themacartneyclan.com Sat Feb 23 22:27:00 2013 From: dale at themacartneyclan.com (Dale Macartney) Date: Sat, 23 Feb 2013 22:27:00 +0000 Subject: [Freeipa-users] RHEL 6.4 ipa-client install on ipa member server Message-ID: <51294234.3080003@themacartneyclan.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Even folks I've verified this both in a kickstart and via manual install to verify any user error on my part. I have a clean installation of RHEL 6.4 for an IPA domain of example.com I also have several clients which are also clean installs of rhel 6.4 and although I can see ipa users via getent and even acquire a tgt's successfully, I am unable to login with any ipa user on any ipa member server. I see the same results for any type of login attempt, e.g. gnome desktop or ssh My client installation is done by this command. ipa-client-install -U -p admin -w redhat123 --mkhomedir --enable-dns-updates IPA client version 3.0.0-25 SSSD version 1.9.2-82 Logs from client as as follows. ==> /var/log/secure <== Feb 23 22:10:07 workstation02 sshd[2419]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.0.1.254 user=admin Feb 23 22:10:08 workstation02 sshd[2419]: pam_sss(sshd:auth): User info message: Your password will expire in 89 day(s). Feb 23 22:10:08 workstation02 sshd[2419]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.0.1.254 user=admin ==> /var/log/btmp <== s ssh:nottyadmin10.0.1.254@>)Q ? ==> /var/log/secure <== Feb 23 22:10:08 workstation02 sshd[2419]: pam_sss(sshd:account): Access denied for user admin: 4 (System error) Feb 23 22:10:08 workstation02 sshd[2419]: Failed password for admin from 10.0.1.254 port 55554 ssh2 Feb 23 22:10:08 workstation02 sshd[2421]: fatal: Access denied for user admin by PAM account configuration ==> /var/log/Xorg.0.log <== [ 604.308] AUDIT: Sat Feb 23 22:12:10 2013: 1908: client 17 connected from local host ( uid=42 gid=42 pid=1958 ) Auth name: MIT-MAGIC-COOKIE-1 ID: 284 [ 604.312] AUDIT: Sat Feb 23 22:12:10 2013: 1908: client 17 disconnected ==> /var/log/messages <== Feb 23 22:12:45 workstation02 ntpd[2359]: synchronized to LOCAL(0), stratum 5 Feb 23 22:13:48 workstation02 ntpd[2359]: synchronized to 10.0.1.12, stratum 11 interactive shell output as follows [mac at rhodey ~]$ ssh admin at 10.0.1.102 admin at 10.0.1.102's password: Your password will expire in 89 day(s). Connection closed by 10.0.1.102 [mac at rhodey ~]$ Am I doing something rather trivially wrong or is there something fishy going on here? Thanks in advance. Dale -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRKUIGAAoJEAJsWS61tB+q4p8P/jtKbSPIRlBiXolg/NyEv0jz tbOKb3OWITv5DzZ73+SsoaAnaRfvbZh0AvwmkOfT8BV3x87ogFrxPblNME23TT07 7kiwg2g+T2b/2Tq7zE3kgdNNrRQo02fwAMdtobmPa/jDzftCOe/01t5psAK+Jabd DcGnCFss4tif1IA5BRVa8tw8rn5XJ4J7ef3owF+LdEsKqpzdVV5xsq3W45EPJHQy pjEgsJemwrxosLg6NoJuKsSjNGrGCikEGV9E83fBQiFhp5muaU3yZcoKsttbnGXa KHZw+MdJWU7xHsFsP+kshWFjpyxt1mgtSI9JHurGdYvIPta3UJ15D+KetU78R24+ csL8zc+/qe+6qwzed5xgWYEjtrYnwNP6SnUgpupkDkl5GrSIzPCLz9elcye7IzPN mPu73wKJvwet88YpZ2+dVcYcDh68Mm2c5YPlIR31VsiiHkNcwniCT+Fed16RjoED uPxwRjNFcOWFYK7MWuFxjtNpx+8UhOrMYRbRYkYk1M/6Zxg1TvjTe92p17Hsb0dA NlJV0VvZu9lApR8hzhZ/Xke4NoyZrGR+y3NVWAwObGEmsxSX7Gg6VwNZvMgVMekJ blHbkp2LwU9KVLZRJpPRxn98UZclFdlQl/fPOKWKwVKiG6y0xIhUpPlDrhs0XYBQ NqNeBfEHUH0tSSpbhf1K =ZsnW -----END PGP SIGNATURE----- From rcritten at redhat.com Sat Feb 23 22:36:58 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Sat, 23 Feb 2013 17:36:58 -0500 Subject: [Freeipa-users] RHEL 6.4 ipa-client install on ipa member server In-Reply-To: <51294234.3080003@themacartneyclan.com> References: <51294234.3080003@themacartneyclan.com> Message-ID: <5129448A.5020506@redhat.com> Dale Macartney wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Even folks > > I've verified this both in a kickstart and via manual install to verify > any user error on my part. > > I have a clean installation of RHEL 6.4 for an IPA domain of example.com > > I also have several clients which are also clean installs of rhel 6.4 > and although I can see ipa users via getent and even acquire a tgt's > successfully, I am unable to login with any ipa user on any ipa member > server. > > I see the same results for any type of login attempt, e.g. gnome desktop > or ssh > > My client installation is done by this command. > > ipa-client-install -U -p admin -w redhat123 --mkhomedir --enable-dns-updates > > IPA client version 3.0.0-25 > SSSD version 1.9.2-82 > > > Logs from client as as follows. > > ==> /var/log/secure <== > Feb 23 22:10:07 workstation02 sshd[2419]: pam_unix(sshd:auth): > authentication failure; logname= uid=0 euid=0 tty=ssh ruser= > rhost=10.0.1.254 user=admin > Feb 23 22:10:08 workstation02 sshd[2419]: pam_sss(sshd:auth): User info > message: Your password will expire in 89 day(s). > Feb 23 22:10:08 workstation02 sshd[2419]: pam_sss(sshd:auth): > authentication success; logname= uid=0 euid=0 tty=ssh ruser= > rhost=10.0.1.254 user=admin > > ==> /var/log/btmp <== > s ssh:nottyadmin10.0.1.254@>)Q > ? > ==> /var/log/secure <== > Feb 23 22:10:08 workstation02 sshd[2419]: pam_sss(sshd:account): Access > denied for user admin: 4 (System error) > Feb 23 22:10:08 workstation02 sshd[2419]: Failed password for admin from > 10.0.1.254 port 55554 ssh2 > Feb 23 22:10:08 workstation02 sshd[2421]: fatal: Access denied for user > admin by PAM account configuration > > ==> /var/log/Xorg.0.log <== > [ 604.308] AUDIT: Sat Feb 23 22:12:10 2013: 1908: client 17 connected > from local host ( uid=42 gid=42 pid=1958 ) > Auth name: MIT-MAGIC-COOKIE-1 ID: 284 > [ 604.312] AUDIT: Sat Feb 23 22:12:10 2013: 1908: client 17 disconnected > > ==> /var/log/messages <== > Feb 23 22:12:45 workstation02 ntpd[2359]: synchronized to LOCAL(0), > stratum 5 > Feb 23 22:13:48 workstation02 ntpd[2359]: synchronized to 10.0.1.12, > stratum 11 > > > interactive shell output as follows > > [mac at rhodey ~]$ ssh admin at 10.0.1.102 > admin at 10.0.1.102's password: > Your password will expire in 89 day(s). > Connection closed by 10.0.1.102 > [mac at rhodey ~]$ > > > Am I doing something rather trivially wrong or is there something fishy > going on here? > > Thanks in advance. I'd check your HBAC configuration. rob From dale at themacartneyclan.com Sat Feb 23 22:40:03 2013 From: dale at themacartneyclan.com (Dale Macartney) Date: Sat, 23 Feb 2013 22:40:03 +0000 Subject: [Freeipa-users] RHEL 6.4 ipa-client install on ipa member server In-Reply-To: <5129448A.5020506@redhat.com> References: <51294234.3080003@themacartneyclan.com> <5129448A.5020506@redhat.com> Message-ID: <51294543.8000707@themacartneyclan.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/23/2013 10:36 PM, Rob Crittenden wrote: > Dale Macartney wrote: >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Even folks >> >> I've verified this both in a kickstart and via manual install to verify >> any user error on my part. >> >> I have a clean installation of RHEL 6.4 for an IPA domain of example.com >> >> I also have several clients which are also clean installs of rhel 6.4 >> and although I can see ipa users via getent and even acquire a tgt's >> successfully, I am unable to login with any ipa user on any ipa member >> server. >> >> I see the same results for any type of login attempt, e.g. gnome desktop >> or ssh >> >> My client installation is done by this command. >> >> ipa-client-install -U -p admin -w redhat123 --mkhomedir --enable-dns-updates >> >> IPA client version 3.0.0-25 >> SSSD version 1.9.2-82 >> >> >> Logs from client as as follows. >> >> ==> /var/log/secure <== >> Feb 23 22:10:07 workstation02 sshd[2419]: pam_unix(sshd:auth): >> authentication failure; logname= uid=0 euid=0 tty=ssh ruser= >> rhost=10.0.1.254 user=admin >> Feb 23 22:10:08 workstation02 sshd[2419]: pam_sss(sshd:auth): User info >> message: Your password will expire in 89 day(s). >> Feb 23 22:10:08 workstation02 sshd[2419]: pam_sss(sshd:auth): >> authentication success; logname= uid=0 euid=0 tty=ssh ruser= >> rhost=10.0.1.254 user=admin >> >> ==> /var/log/btmp <== >> s ssh:nottyadmin10.0.1.254@>)Q >> ? >> ==> /var/log/secure <== >> Feb 23 22:10:08 workstation02 sshd[2419]: pam_sss(sshd:account): Access >> denied for user admin: 4 (System error) >> Feb 23 22:10:08 workstation02 sshd[2419]: Failed password for admin from >> 10.0.1.254 port 55554 ssh2 >> Feb 23 22:10:08 workstation02 sshd[2421]: fatal: Access denied for user >> admin by PAM account configuration >> >> ==> /var/log/Xorg.0.log <== >> [ 604.308] AUDIT: Sat Feb 23 22:12:10 2013: 1908: client 17 connected >> from local host ( uid=42 gid=42 pid=1958 ) >> Auth name: MIT-MAGIC-COOKIE-1 ID: 284 >> [ 604.312] AUDIT: Sat Feb 23 22:12:10 2013: 1908: client 17 disconnected >> >> ==> /var/log/messages <== >> Feb 23 22:12:45 workstation02 ntpd[2359]: synchronized to LOCAL(0), >> stratum 5 >> Feb 23 22:13:48 workstation02 ntpd[2359]: synchronized to 10.0.1.12, >> stratum 11 >> >> >> interactive shell output as follows >> >> [mac at rhodey ~]$ ssh admin at 10.0.1.102 >> admin at 10.0.1.102's password: >> Your password will expire in 89 day(s). >> Connection closed by 10.0.1.102 >> [mac at rhodey ~]$ >> >> >> Am I doing something rather trivially wrong or is there something fishy >> going on here? >> >> Thanks in advance. > > I'd check your HBAC configuration. > > rob > That is actually the very first thing I did. As it is a 100% clean installation of IPA, plus the addition of one user and one IPA replica. all users are granted access to all hosts. [root at ds01 ~]# ipa hbacrule-find - ------------------- 1 HBAC rule matched - ------------------- Rule name: allow_all User category: all Host category: all Source host category: all Service category: all Description: Allow all users to access any host from any host Enabled: TRUE - ---------------------------- Number of entries returned 1 - ---------------------------- [root at ds01 ~]# -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRKUVAAAoJEAJsWS61tB+qmMwQAJgO3zJsbQkKqhgdj6qjfvbH EJHQOCEA55Mf2FgY4cUjeOj2oulny3HLxFQJql6OGYOk73zx48JR0VZdalyXp4Jc bUKkog+5jnamcEpm5qcRfvpLrITayamqMTgPzvOdrCWnVYSNTxjA07y7Sh/ZOpK5 XSsYTaMBKFLsE20CAE/a/PPJpL/43fP59+nK0yGgClwA5V3FIMBLZo7WKOGFsVJK lK+Couo3FPwiThp3klHudokQ4w24MdDc9aNKz4ZatcnqHK9nXeBNIya8FdYAtMqT Us6Lzkq0YOk7IKFU5qgqUtkXuCmRfRLZDZYngpug4S97S0wmG7eo191VPliKsCOO CuWDaSDtUMbD5li7yzUEnhwUOI+9tLSD98rTO7oqGADQQqvmgz78/A9uQAVfRSIS 7PpmqUsl2pdC1XZ7Vy0K6vrqc7ojQkwwlFVmvY+TMBs2ukKrDz38bnRzfevxpZNe pm77dn8iF2NGqGpPqbrRvXwenIqi35j/6adBhGtDkAkdSKFXyZbDXRms+ro3oxXI StrYPHy4td02Fe4MyFrc3s7uIJvYuZGB+ULRKDAptnZetKhaP58VoapQJYrKrxdd N5hqf4EMwQ9b++Y5Bf9fzlA4osIDgf3uS+8/orL0KuXBq0vGYMqyTDE9leRMqamh ruH0DYhFtmabbPzxv7uA =sdSi -----END PGP SIGNATURE----- From treydock at gmail.com Sun Feb 24 03:33:37 2013 From: treydock at gmail.com (Trey Dockendorf) Date: Sat, 23 Feb 2013 21:33:37 -0600 Subject: [Freeipa-users] New User - Possible to point authentication to external KDC Message-ID: I just begun evaluating FreeIPA, after having successfully used 389ds for a few months. The move from 389 ds to FreeIPA is to leverage the authorization for host logins and also for simpler management. The University I am deploying at has a campus wide KDC and for security and audit reasons I prefer to point my authentication services at that Kerberos realm rather than storing passwords. I have successfully implemented this using the 389 ds pam pass through authentication plug-in , but have not found any documentation on how to do this same thing with FreeIPA. The complication with doing this is I do not have even a 1 way trust with the KDC. Getting a trust (even 1-way) is very difficult if not impossible, but so far I've been able to make PAM work with that situation both using local authentication and now 389 ds, both through PAM. Is it possible to have FreeIPA query a remote KDC while still being able to fallback to the local password store (ie external users not in campus domain). Thanks - Trey From dpal at redhat.com Mon Feb 25 07:21:15 2013 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 25 Feb 2013 02:21:15 -0500 Subject: [Freeipa-users] New User - Possible to point authentication to external KDC In-Reply-To: References: Message-ID: <512B10EB.6080908@redhat.com> On 02/23/2013 10:33 PM, Trey Dockendorf wrote: > I just begun evaluating FreeIPA, after having successfully used 389ds > for a few months. The move from 389 ds to FreeIPA is to leverage the > authorization for host logins and also for simpler management. The > University I am deploying at has a campus wide KDC and for security > and audit reasons I prefer to point my authentication services at that > Kerberos realm rather than storing passwords. I have successfully > implemented this using the 389 ds pam pass through authentication > plug-in , but have not found any documentation on how to do this same > thing with FreeIPA. > > The complication with doing this is I do not have even a 1 way trust > with the KDC. Getting a trust (even 1-way) is very difficult if not > impossible, but so far I've been able to make PAM work with that > situation both using local authentication and now 389 ds, both through > PAM. Is it possible to have FreeIPA query a remote KDC while still > being able to fallback to the local password store (ie external users > not in campus domain). IPA uses the 389 DS so it might be possible to configure PAM pass through but there might be implications because if users are not in IPA you would not get a ticket and since you cant get a ticket you can't use UI and CLI. You can still bind using LDAP though as you do with the 389. So to manage IPA you would still have to have a user in IPA. However you will have two KDCs and I do not know what implications there would be for the clients, they might be confused. Frankly you are better off with 389 now untill we make setting up trusts with other IPAs or MIT KDCs simple. We did that for AD but it requires a clean DNS setup. I suspect DNS setup will be an issue in any case. > > Thanks > - Trey > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From sigbjorn at nixtra.com Mon Feb 25 08:46:49 2013 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Mon, 25 Feb 2013 09:46:49 +0100 (CET) Subject: [Freeipa-users] ipa: ERROR: attribute "idnsAllowTransfer" not allowed Message-ID: <24628.213.225.75.97.1361782009.squirrel@www.nixtra.com> Hi, I am trying to add a new DNS zone to our IPA server, but I receive the following error: $ ipa dnszone-add example.com --name-server=ns01.example.com --admin-email=hostmaster.example.com ipa: ERROR: attribute "idnsAllowTransfer" not allowed I get the same error no matter if I attempt to add a forward or a reverse zone. I am using IPA 2.2 on RHEL 6.3: bind-9.8.2-0.10.rc1.el6_3.3.x86_64 bind-dyndb-ldap-1.1.0-0.9.b1.el6_3.1.x86_64 bind-libs-9.8.2-0.10.rc1.el6_3.3.x86_64 bind-utils-9.8.2-0.10.rc1.el6_3.3.x86_64 ipa-admintools-2.2.0-16.el6.x86_64 ipa-client-2.2.0-16.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.2.0-16.el6.x86_64 ipa-server-2.2.0-16.el6.x86_64 ipa-server-selinux-2.2.0-16.el6.x86_64 krb5-libs-1.9-33.el6_3.3.x86_64 krb5-pkinit-openssl-1.9-33.el6_3.3.x86_64 krb5-server-1.9-33.el6_3.3.x86_64 krb5-server-ldap-1.9-33.el6_3.3.x86_64 krb5-workstation-1.9-33.el6_3.3.x86_64 selinux-policy-3.7.19-155.el6_3.4.noarch selinux-policy-targeted-3.7.19-155.el6_3.4.noarch slapi-nis-0.40-1.el6.x86_64 We do have several dns zones in IPA today, so this has worked earlier. Is this a known error? Regards, Siggi From jhrozek at redhat.com Mon Feb 25 10:15:24 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 25 Feb 2013 11:15:24 +0100 Subject: [Freeipa-users] RHEL 6.4 ipa-client install on ipa member server In-Reply-To: <51294543.8000707@themacartneyclan.com> References: <51294234.3080003@themacartneyclan.com> <5129448A.5020506@redhat.com> <51294543.8000707@themacartneyclan.com> Message-ID: <20130225101524.GB18383@hendrix.brq.redhat.com> On Sat, Feb 23, 2013 at 10:40:03PM +0000, Dale Macartney wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On 02/23/2013 10:36 PM, Rob Crittenden wrote: > > Dale Macartney wrote: > >> > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA1 > >> > >> Even folks > >> > >> I've verified this both in a kickstart and via manual install to verify > >> any user error on my part. > >> > >> I have a clean installation of RHEL 6.4 for an IPA domain of example.com > >> > >> I also have several clients which are also clean installs of rhel 6.4 > >> and although I can see ipa users via getent and even acquire a tgt's > >> successfully, I am unable to login with any ipa user on any ipa member > >> server. > >> > >> I see the same results for any type of login attempt, e.g. gnome desktop > >> or ssh > >> > >> My client installation is done by this command. > >> > >> ipa-client-install -U -p admin -w redhat123 --mkhomedir > --enable-dns-updates > >> > >> IPA client version 3.0.0-25 > >> SSSD version 1.9.2-82 > >> > >> > >> Logs from client as as follows. > >> > >> ==> /var/log/secure <== > >> Feb 23 22:10:07 workstation02 sshd[2419]: pam_unix(sshd:auth): > >> authentication failure; logname= uid=0 euid=0 tty=ssh ruser= > >> rhost=10.0.1.254 user=admin > >> Feb 23 22:10:08 workstation02 sshd[2419]: pam_sss(sshd:auth): User info > >> message: Your password will expire in 89 day(s). FTR, this is a known bug that will be fixed in an asynchronous errata Very Soon Now. > >> Feb 23 22:10:08 workstation02 sshd[2419]: pam_sss(sshd:auth): > >> authentication success; logname= uid=0 euid=0 tty=ssh ruser= > >> rhost=10.0.1.254 user=admin > >> > >> ==> /var/log/btmp <== > >> s ssh:nottyadmin10.0.1.254@>)Q > >> ? > >> ==> /var/log/secure <== > >> Feb 23 22:10:08 workstation02 sshd[2419]: pam_sss(sshd:account): Access > >> denied for user admin: 4 (System error) What state is your SELinux in? Permissive/Enforcing/Disabled ? > >> Feb 23 22:10:08 workstation02 sshd[2419]: Failed password for admin from > >> 10.0.1.254 port 55554 ssh2 > >> Feb 23 22:10:08 workstation02 sshd[2421]: fatal: Access denied for user > >> admin by PAM account configuration > >> > >> ==> /var/log/Xorg.0.log <== > >> [ 604.308] AUDIT: Sat Feb 23 22:12:10 2013: 1908: client 17 connected > >> from local host ( uid=42 gid=42 pid=1958 ) > >> Auth name: MIT-MAGIC-COOKIE-1 ID: 284 > >> [ 604.312] AUDIT: Sat Feb 23 22:12:10 2013: 1908: client 17 disconnected > >> > >> ==> /var/log/messages <== > >> Feb 23 22:12:45 workstation02 ntpd[2359]: synchronized to LOCAL(0), > >> stratum 5 > >> Feb 23 22:13:48 workstation02 ntpd[2359]: synchronized to 10.0.1.12, > >> stratum 11 > >> > >> > >> interactive shell output as follows > >> > >> [mac at rhodey ~]$ ssh admin at 10.0.1.102 > >> admin at 10.0.1.102's password: > >> Your password will expire in 89 day(s). > >> Connection closed by 10.0.1.102 > >> [mac at rhodey ~]$ > >> > >> > >> Am I doing something rather trivially wrong or is there something fishy > >> going on here? > >> > >> Thanks in advance. > > > > I'd check your HBAC configuration. > > > > rob > > > That is actually the very first thing I did. As it is a 100% clean > installation of IPA, plus the addition of one user and one IPA replica. > > all users are granted access to all hosts. > > [root at ds01 ~]# ipa hbacrule-find > - ------------------- > 1 HBAC rule matched > - ------------------- > Rule name: allow_all > User category: all > Host category: all > Source host category: all > Service category: all > Description: Allow all users to access any host from any host > Enabled: TRUE > - ---------------------------- > Number of entries returned 1 > - ---------------------------- > [root at ds01 ~]# > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.13 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBAgAGBQJRKUVAAAoJEAJsWS61tB+qmMwQAJgO3zJsbQkKqhgdj6qjfvbH > EJHQOCEA55Mf2FgY4cUjeOj2oulny3HLxFQJql6OGYOk73zx48JR0VZdalyXp4Jc > bUKkog+5jnamcEpm5qcRfvpLrITayamqMTgPzvOdrCWnVYSNTxjA07y7Sh/ZOpK5 > XSsYTaMBKFLsE20CAE/a/PPJpL/43fP59+nK0yGgClwA5V3FIMBLZo7WKOGFsVJK > lK+Couo3FPwiThp3klHudokQ4w24MdDc9aNKz4ZatcnqHK9nXeBNIya8FdYAtMqT > Us6Lzkq0YOk7IKFU5qgqUtkXuCmRfRLZDZYngpug4S97S0wmG7eo191VPliKsCOO > CuWDaSDtUMbD5li7yzUEnhwUOI+9tLSD98rTO7oqGADQQqvmgz78/A9uQAVfRSIS > 7PpmqUsl2pdC1XZ7Vy0K6vrqc7ojQkwwlFVmvY+TMBs2ukKrDz38bnRzfevxpZNe > pm77dn8iF2NGqGpPqbrRvXwenIqi35j/6adBhGtDkAkdSKFXyZbDXRms+ro3oxXI > StrYPHy4td02Fe4MyFrc3s7uIJvYuZGB+ULRKDAptnZetKhaP58VoapQJYrKrxdd > N5hqf4EMwQ9b++Y5Bf9fzlA4osIDgf3uS+8/orL0KuXBq0vGYMqyTDE9leRMqamh > ruH0DYhFtmabbPzxv7uA > =sdSi > -----END PGP SIGNATURE----- > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From dale at themacartneyclan.com Mon Feb 25 10:30:44 2013 From: dale at themacartneyclan.com (Dale Macartney) Date: Mon, 25 Feb 2013 10:30:44 +0000 Subject: [Freeipa-users] RHEL 6.4 ipa-client install on ipa member server In-Reply-To: <20130225101524.GB18383@hendrix.brq.redhat.com> References: <51294234.3080003@themacartneyclan.com> <5129448A.5020506@redhat.com> <51294543.8000707@themacartneyclan.com> <20130225101524.GB18383@hendrix.brq.redhat.com> Message-ID: <512B3D54.4030505@themacartneyclan.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/25/2013 10:15 AM, Jakub Hrozek wrote: > On Sat, Feb 23, 2013 at 10:40:03PM +0000, Dale Macartney wrote: >> > > On 02/23/2013 10:36 PM, Rob Crittenden wrote: > >>> Dale Macartney wrote: > >>>> > >>>> -----BEGIN PGP SIGNED MESSAGE----- > >>>> Hash: SHA1 > >>>> > >>>> Even folks > >>>> > >>>> I've verified this both in a kickstart and via manual install to verify > >>>> any user error on my part. > >>>> > >>>> I have a clean installation of RHEL 6.4 for an IPA domain of example.com > >>>> > >>>> I also have several clients which are also clean installs of rhel 6.4 > >>>> and although I can see ipa users via getent and even acquire a tgt's > >>>> successfully, I am unable to login with any ipa user on any ipa member > >>>> server. > >>>> > >>>> I see the same results for any type of login attempt, e.g. gnome desktop > >>>> or ssh > >>>> > >>>> My client installation is done by this command. > >>>> > >>>> ipa-client-install -U -p admin -w redhat123 --mkhomedir > --enable-dns-updates > >>>> > >>>> IPA client version 3.0.0-25 > >>>> SSSD version 1.9.2-82 > >>>> > >>>> > >>>> Logs from client as as follows. > >>>> > >>>> ==> /var/log/secure <== > >>>> Feb 23 22:10:07 workstation02 sshd[2419]: pam_unix(sshd:auth): > >>>> authentication failure; logname= uid=0 euid=0 tty=ssh ruser= > >>>> rhost=10.0.1.254 user=admin > >>>> Feb 23 22:10:08 workstation02 sshd[2419]: pam_sss(sshd:auth): User info > >>>> message: Your password will expire in 89 day(s). > > > FTR, this is a known bug that will be fixed in an asynchronous errata > > Very Soon Now. > > >>>> Feb 23 22:10:08 workstation02 sshd[2419]: pam_sss(sshd:auth): > >>>> authentication success; logname= uid=0 euid=0 tty=ssh ruser= > >>>> rhost=10.0.1.254 user=admin > >>>> > >>>> ==> /var/log/btmp <== > >>>> s ssh:nottyadmin10.0.1.254@>)Q > >>>> ? > >>>> ==> /var/log/secure <== > >>>> Feb 23 22:10:08 workstation02 sshd[2419]: pam_sss(sshd:account): Access > >>>> denied for user admin: 4 (System error) > > > What state is your SELinux in? Permissive/Enforcing/Disabled ? Another fail on my part. Works fine in permissive mode. AVC denials listed below.. type=AVC msg=audit(1361788146.020:28315): avc: denied { read } for pid=2271 comm="sshd" name="passwd" dev=dm-0 ino=914246 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:sssd_var_lib_t:s0 tclass=file type=AVC msg=audit(1361788146.020:28315): avc: denied { open } for pid=2271 comm="sshd" name="passwd" dev=dm-0 ino=914246 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:sssd_var_lib_t:s0 tclass=file type=AVC msg=audit(1361788146.020:28316): avc: denied { getattr } for pid=2271 comm="sshd" path="/var/lib/sss/mc/passwd" dev=dm-0 ino=914246 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:sssd_var_lib_t:s0 tclass=file type=AVC msg=audit(1361788155.330:28318): avc: denied { read } for pid=2275 comm="krb5_child" name="config" dev=dm-0 ino=392854 scontext=system_u:system_r:sssd_t:s0 tcontext=system_u:object_r:selinux_config_t:s0 tclass=file type=AVC msg=audit(1361788155.330:28318): avc: denied { open } for pid=2275 comm="krb5_child" name="config" dev=dm-0 ino=392854 scontext=system_u:system_r:sssd_t:s0 tcontext=system_u:object_r:selinux_config_t:s0 tclass=file type=AVC msg=audit(1361788155.330:28319): avc: denied { getattr } for pid=2275 comm="krb5_child" path="/etc/selinux/config" dev=dm-0 ino=392854 scontext=system_u:system_r:sssd_t:s0 tcontext=system_u:object_r:selinux_config_t:s0 tclass=file type=AVC msg=audit(1361788156.367:28321): avc: denied { write } for pid=1380 comm="sssd_pam" name="logins" dev=dm-0 ino=392943 scontext=system_u:system_r:sssd_t:s0 tcontext=system_u:object_r:selinux_config_t:s0 tclass=dir type=AVC msg=audit(1361788156.367:28321): avc: denied { add_name } for pid=1380 comm="sssd_pam" name="adminoTfIUQ" scontext=system_u:system_r:sssd_t:s0 tcontext=system_u:object_r:selinux_config_t:s0 tclass=dir type=AVC msg=audit(1361788156.367:28321): avc: denied { create } for pid=1380 comm="sssd_pam" name="adminoTfIUQ" scontext=system_u:system_r:sssd_t:s0 tcontext=system_u:object_r:selinux_config_t:s0 tclass=file type=AVC msg=audit(1361788156.367:28321): avc: denied { write } for pid=1380 comm="sssd_pam" name="adminoTfIUQ" dev=dm-0 ino=393233 scontext=system_u:system_r:sssd_t:s0 tcontext=system_u:object_r:selinux_config_t:s0 tclass=file type=AVC msg=audit(1361788156.367:28322): avc: denied { remove_name } for pid=1380 comm="sssd_pam" name="adminoTfIUQ" dev=dm-0 ino=393233 scontext=system_u:system_r:sssd_t:s0 tcontext=system_u:object_r:selinux_config_t:s0 tclass=dir type=AVC msg=audit(1361788156.367:28322): avc: denied { rename } for pid=1380 comm="sssd_pam" name="adminoTfIUQ" dev=dm-0 ino=393233 scontext=system_u:system_r:sssd_t:s0 tcontext=system_u:object_r:selinux_config_t:s0 tclass=file type=AVC msg=audit(1361788156.367:28322): avc: denied { unlink } for pid=1380 comm="sssd_pam" name="admin" dev=dm-0 ino=392951 scontext=system_u:system_r:sssd_t:s0 tcontext=system_u:object_r:selinux_config_t:s0 tclass=file > > >>>> Feb 23 22:10:08 workstation02 sshd[2419]: Failed password for admin from > >>>> 10.0.1.254 port 55554 ssh2 > >>>> Feb 23 22:10:08 workstation02 sshd[2421]: fatal: Access denied for user > >>>> admin by PAM account configuration > >>>> > >>>> ==> /var/log/Xorg.0.log <== > >>>> [ 604.308] AUDIT: Sat Feb 23 22:12:10 2013: 1908: client 17 connected > >>>> from local host ( uid=42 gid=42 pid=1958 ) > >>>> Auth name: MIT-MAGIC-COOKIE-1 ID: 284 > >>>> [ 604.312] AUDIT: Sat Feb 23 22:12:10 2013: 1908: client 17 disconnected > >>>> > >>>> ==> /var/log/messages <== > >>>> Feb 23 22:12:45 workstation02 ntpd[2359]: synchronized to LOCAL(0), > >>>> stratum 5 > >>>> Feb 23 22:13:48 workstation02 ntpd[2359]: synchronized to 10.0.1.12, > >>>> stratum 11 > >>>> > >>>> > >>>> interactive shell output as follows > >>>> > >>>> [mac at rhodey ~]$ ssh admin at 10.0.1.102 > >>>> admin at 10.0.1.102's password: > >>>> Your password will expire in 89 day(s). > >>>> Connection closed by 10.0.1.102 > >>>> [mac at rhodey ~]$ > >>>> > >>>> > >>>> Am I doing something rather trivially wrong or is there something fishy > >>>> going on here? > >>>> > >>>> Thanks in advance. > >>> > >>> I'd check your HBAC configuration. > >>> > >>> rob > >>> > That is actually the very first thing I did. As it is a 100% clean > installation of IPA, plus the addition of one user and one IPA replica. > > all users are granted access to all hosts. > > [root at ds01 ~]# ipa hbacrule-find > ------------------- > 1 HBAC rule matched > ------------------- > Rule name: allow_all > User category: all > Host category: all > Source host category: all > Service category: all > Description: Allow all users to access any host from any host > Enabled: TRUE > ---------------------------- > Number of entries returned 1 > ---------------------------- > [root at ds01 ~]# > > > >> >> _______________________________________________ >> 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRKz1MAAoJEAJsWS61tB+q5VoP/3Jre49XLeb00rUvfri+Ud9j c9GmrzAHH66Bckp2y/htaD23tnFraD94VSjwg485iCosqzuYDAd3U/+LXP3rjC92 Xt5rMBRJ3XAL7O32c9Z8FKPAeTCM+fR/UyjkKxGJaLaGeASnAZjg2Xek28z+jUuT 4+ITBMZWDdnhf34wpFeHL8FrhIq+oLYo3j5GKAH7YZn/XJnrs4gNH/pLBlnuegJQ ukiouadZOQRo2AZb/jxW4LoUWl3pCorQah1dPyL0PaOuhSYQ4v29NdIdsDBLC1nK U8V1TU+W59tyBfiMNwFYhxJ0IOvWYmIQY+oZNNzyo5+/tlqUlyGqpsgXmyoo7h1R WoInBit4JotJyC/ynVraJBUjSiHcJsiTSBCdfnvzRPHiJhaldDfe7+iIDATBweMg 5e3nskIjGyqPTAWkUiFcp1Xv7ch2RKEq51dg4qhf7OAEwhOX7HkudIY50jD51CXW X08vBqHzH3ViVBhsehZRzE73+B83RyaYOQaULgU8/GxAAH9r79/WFCA1H2Fl7fLE PYTDlebyyRM2qlDxu2AXiwAo7DqdT9OMShmjiMcSoZAnSSdUfmCAwOgV9Yg5YKy9 3e3GYWtyhOKGmVagO18/WR5ZkR9Ei+Cb5Bs44oyfrY17l2PRiDLZj4Doeu4nhbOu 3ugSBDfo6+3DziJjP1sT =EXH/ -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Mon Feb 25 10:58:35 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 25 Feb 2013 11:58:35 +0100 Subject: [Freeipa-users] RHEL 6.4 ipa-client install on ipa member server In-Reply-To: <512B3D54.4030505@themacartneyclan.com> References: <51294234.3080003@themacartneyclan.com> <5129448A.5020506@redhat.com> <51294543.8000707@themacartneyclan.com> <20130225101524.GB18383@hendrix.brq.redhat.com> <512B3D54.4030505@themacartneyclan.com> Message-ID: <20130225105835.GE18383@hendrix.brq.redhat.com> On Mon, Feb 25, 2013 at 10:30:44AM +0000, Dale Macartney wrote: > > > What state is your SELinux in? Permissive/Enforcing/Disabled ? > Another fail on my part. Works fine in permissive mode. > No, the SSSD should be working out of the box with SELinux Enforcing. > AVC denials listed below.. > > type=AVC msg=audit(1361788146.020:28315): avc: denied { read } for > pid=2271 comm="sshd" name="passwd" dev=dm-0 ino=914246 > scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 > tcontext=system_u:object_r:sssd_var_lib_t:s0 tclass=file > type=AVC msg=audit(1361788146.020:28315): avc: denied { open } for > pid=2271 comm="sshd" name="passwd" dev=dm-0 ino=914246 > scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 > tcontext=system_u:object_r:sssd_var_lib_t:s0 tclass=file > type=AVC msg=audit(1361788146.020:28316): avc: denied { getattr } for > pid=2271 comm="sshd" path="/var/lib/sss/mc/passwd" dev=dm-0 ino=914246 > scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 ^ This is SElinux denying access to the fast in-memory cache. > tcontext=system_u:object_r:sssd_var_lib_t:s0 tclass=file > type=AVC msg=audit(1361788155.330:28318): avc: denied { read } for > pid=2275 comm="krb5_child" name="config" dev=dm-0 ino=392854 > scontext=system_u:system_r:sssd_t:s0 > tcontext=system_u:object_r:selinux_config_t:s0 tclass=file > type=AVC msg=audit(1361788155.330:28318): avc: denied { open } for > pid=2275 comm="krb5_child" name="config" dev=dm-0 ino=392854 > scontext=system_u:system_r:sssd_t:s0 > tcontext=system_u:object_r:selinux_config_t:s0 tclass=file > type=AVC msg=audit(1361788155.330:28319): avc: denied { getattr } for > pid=2275 comm="krb5_child" path="/etc/selinux/config" dev=dm-0 > ino=392854 scontext=system_u:system_r:sssd_t:s0 Interesting, I'm not aware of any code in the krb5 child process that would do anything selinux-related. I wonder if libkrb5 might be the culprit..rpm says it *is* linked against libselinux as well. > tcontext=system_u:object_r:selinux_config_t:s0 tclass=file > type=AVC msg=audit(1361788156.367:28321): avc: denied { write } for > pid=1380 comm="sssd_pam" name="logins" dev=dm-0 ino=392943 > scontext=system_u:system_r:sssd_t:s0 > tcontext=system_u:object_r:selinux_config_t:s0 tclass=dir > type=AVC msg=audit(1361788156.367:28321): avc: denied { add_name } > for pid=1380 comm="sssd_pam" name="adminoTfIUQ" > scontext=system_u:system_r:sssd_t:s0 > tcontext=system_u:object_r:selinux_config_t:s0 tclass=dir > type=AVC msg=audit(1361788156.367:28321): avc: denied { create } for > pid=1380 comm="sssd_pam" name="adminoTfIUQ" > scontext=system_u:system_r:sssd_t:s0 > tcontext=system_u:object_r:selinux_config_t:s0 tclass=file > type=AVC msg=audit(1361788156.367:28321): avc: denied { write } for > pid=1380 comm="sssd_pam" name="adminoTfIUQ" dev=dm-0 ino=393233 > scontext=system_u:system_r:sssd_t:s0 > tcontext=system_u:object_r:selinux_config_t:s0 tclass=file > type=AVC msg=audit(1361788156.367:28322): avc: denied { remove_name } > for pid=1380 comm="sssd_pam" name="adminoTfIUQ" dev=dm-0 ino=393233 > scontext=system_u:system_r:sssd_t:s0 > tcontext=system_u:object_r:selinux_config_t:s0 tclass=dir > type=AVC msg=audit(1361788156.367:28322): avc: denied { rename } for > pid=1380 comm="sssd_pam" name="adminoTfIUQ" dev=dm-0 ino=393233 > scontext=system_u:system_r:sssd_t:s0 > tcontext=system_u:object_r:selinux_config_t:s0 tclass=file > type=AVC msg=audit(1361788156.367:28322): avc: denied { unlink } for > pid=1380 comm="sssd_pam" name="admin" dev=dm-0 ino=392951 > scontext=system_u:system_r:sssd_t:s0 > tcontext=system_u:object_r:selinux_config_t:s0 tclass=file This is SSSD trying to write the user login mapping. What version is your selinux-policy? Was your system properly labeled? Does restorecon -Rvv /etc/selinux help? From dale at themacartneyclan.com Mon Feb 25 11:06:09 2013 From: dale at themacartneyclan.com (Dale Macartney) Date: Mon, 25 Feb 2013 11:06:09 +0000 Subject: [Freeipa-users] RHEL 6.4 ipa-client install on ipa member server In-Reply-To: <20130225105835.GE18383@hendrix.brq.redhat.com> References: <51294234.3080003@themacartneyclan.com> <5129448A.5020506@redhat.com> <51294543.8000707@themacartneyclan.com> <20130225101524.GB18383@hendrix.brq.redhat.com> <512B3D54.4030505@themacartneyclan.com> <20130225105835.GE18383@hendrix.brq.redhat.com> Message-ID: <512B45A1.1090103@themacartneyclan.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/25/2013 10:58 AM, Jakub Hrozek wrote: > On Mon, Feb 25, 2013 at 10:30:44AM +0000, Dale Macartney wrote: >>>> What state is your SELinux in? Permissive/Enforcing/Disabled ? >> Another fail on my part. Works fine in permissive mode. >> > > No, the SSSD should be working out of the box with SELinux Enforcing. > >> AVC denials listed below.. >> >> type=AVC msg=audit(1361788146.020:28315): avc: denied { read } for >> pid=2271 comm="sshd" name="passwd" dev=dm-0 ino=914246 >> scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 >> tcontext=system_u:object_r:sssd_var_lib_t:s0 tclass=file >> type=AVC msg=audit(1361788146.020:28315): avc: denied { open } for >> pid=2271 comm="sshd" name="passwd" dev=dm-0 ino=914246 >> scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 >> tcontext=system_u:object_r:sssd_var_lib_t:s0 tclass=file >> type=AVC msg=audit(1361788146.020:28316): avc: denied { getattr } for >> pid=2271 comm="sshd" path="/var/lib/sss/mc/passwd" dev=dm-0 ino=914246 >> scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 > > ^ This is SElinux denying access to the fast in-memory cache. > >> tcontext=system_u:object_r:sssd_var_lib_t:s0 tclass=file >> type=AVC msg=audit(1361788155.330:28318): avc: denied { read } for >> pid=2275 comm="krb5_child" name="config" dev=dm-0 ino=392854 >> scontext=system_u:system_r:sssd_t:s0 >> tcontext=system_u:object_r:selinux_config_t:s0 tclass=file >> type=AVC msg=audit(1361788155.330:28318): avc: denied { open } for >> pid=2275 comm="krb5_child" name="config" dev=dm-0 ino=392854 >> scontext=system_u:system_r:sssd_t:s0 >> tcontext=system_u:object_r:selinux_config_t:s0 tclass=file >> type=AVC msg=audit(1361788155.330:28319): avc: denied { getattr } for >> pid=2275 comm="krb5_child" path="/etc/selinux/config" dev=dm-0 >> ino=392854 scontext=system_u:system_r:sssd_t:s0 > > Interesting, I'm not aware of any code in the krb5 child process that > would do anything selinux-related. I wonder if libkrb5 might be the > culprit..rpm says it *is* linked against libselinux as well. > >> tcontext=system_u:object_r:selinux_config_t:s0 tclass=file >> type=AVC msg=audit(1361788156.367:28321): avc: denied { write } for >> pid=1380 comm="sssd_pam" name="logins" dev=dm-0 ino=392943 >> scontext=system_u:system_r:sssd_t:s0 >> tcontext=system_u:object_r:selinux_config_t:s0 tclass=dir >> type=AVC msg=audit(1361788156.367:28321): avc: denied { add_name } >> for pid=1380 comm="sssd_pam" name="adminoTfIUQ" >> scontext=system_u:system_r:sssd_t:s0 >> tcontext=system_u:object_r:selinux_config_t:s0 tclass=dir >> type=AVC msg=audit(1361788156.367:28321): avc: denied { create } for >> pid=1380 comm="sssd_pam" name="adminoTfIUQ" >> scontext=system_u:system_r:sssd_t:s0 >> tcontext=system_u:object_r:selinux_config_t:s0 tclass=file >> type=AVC msg=audit(1361788156.367:28321): avc: denied { write } for >> pid=1380 comm="sssd_pam" name="adminoTfIUQ" dev=dm-0 ino=393233 >> scontext=system_u:system_r:sssd_t:s0 >> tcontext=system_u:object_r:selinux_config_t:s0 tclass=file >> type=AVC msg=audit(1361788156.367:28322): avc: denied { remove_name } >> for pid=1380 comm="sssd_pam" name="adminoTfIUQ" dev=dm-0 ino=393233 >> scontext=system_u:system_r:sssd_t:s0 >> tcontext=system_u:object_r:selinux_config_t:s0 tclass=dir >> type=AVC msg=audit(1361788156.367:28322): avc: denied { rename } for >> pid=1380 comm="sssd_pam" name="adminoTfIUQ" dev=dm-0 ino=393233 >> scontext=system_u:system_r:sssd_t:s0 >> tcontext=system_u:object_r:selinux_config_t:s0 tclass=file >> type=AVC msg=audit(1361788156.367:28322): avc: denied { unlink } for >> pid=1380 comm="sssd_pam" name="admin" dev=dm-0 ino=392951 >> scontext=system_u:system_r:sssd_t:s0 >> tcontext=system_u:object_r:selinux_config_t:s0 tclass=file > > This is SSSD trying to write the user login mapping. > > What version is your selinux-policy? > > Was your system properly labeled? > > Does restorecon -Rvv /etc/selinux help? Interesting, after using restorecon, yes it now allows a successful login. I am curious how the contexts would have become incorrectly set as the machine was provisioned with a rather trivial kickstart. output of restorecon is below. [root at workstation01 ~]# restorecon -Rvv /etc/selinux/ restorecon reset /etc/selinux/targeted/logins context system_u:object_r:selinux_config_t:s0->system_u:object_r:selinux_login_config_t:s0 restorecon reset /etc/selinux/targeted/logins/admin context system_u:object_r:selinux_config_t:s0->system_u:object_r:selinux_login_config_t:s0 [root at workstation01 ~]# selinux policy version 3.7.19-195.el6_4.1 > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRK0WgAAoJEAJsWS61tB+qnnYQAJJgXcVUUU2DdOUFR34GeU97 NgAoJfbPdL8wtXWT+qqnwdGWRRFO4fgfZF6DBh21suW0f4PrNiv8PPmq/jSXqbF6 K+PwT/txjU4nvm+9j2uvJGvgysisVXwVXkUHGlyljG9FyrilaLi0rnk2cuZ0LdC2 Zwt0x9u1f+yXU4l4IGWJNxW26C+wr5oAZvpCbzGO19ODCctBFvGTox0yFVCE1tB2 wFSIT/B8iLgSQeJgUnJsqXFpiqtGAAg7eAErqsMv1XbuC0RMwDCWcbZEgn24jp5D gE+Drx3fVZEZWFtdJBTQW6UICOdo+51aS5HtqpAevFod78CbMNJNFrEfV5j3uwhY xP6CjpJfxGbxXErVZJ/NTFATzcqt7C7Hy0WboSlCWrDYGsnpsFD3QbGJznWvORed LTwqPRlt/+qN+mZu+Kq+4qYtNxKazK7KcNqoIP5MncnMY7qOhy+PYlKNp61FFbSM dzOJXsVhmM7bZnFO8p0bANP5Mp9pY2Z6wuTIMN2LPz7FgceJJGoBn0gk60H/YmZi /L9vNtmPXRzOFs8gQA4E0/yFRhOBKPEydxjXjXBr0cDGi7V0GZxHBPpZnKpU5iXA 6BBoc+uA9+UYxRJ5Li36L/ZIDAuPUl7li7aAgclTop0i+Nc4lc50wMMlBgVK7QUw HOiAP+SPML/f9sDpM3/n =4zva -----END PGP SIGNATURE----- From jhrozek at redhat.com Mon Feb 25 11:15:05 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 25 Feb 2013 12:15:05 +0100 Subject: [Freeipa-users] RHEL 6.4 ipa-client install on ipa member server In-Reply-To: <512B45A1.1090103@themacartneyclan.com> References: <51294234.3080003@themacartneyclan.com> <5129448A.5020506@redhat.com> <51294543.8000707@themacartneyclan.com> <20130225101524.GB18383@hendrix.brq.redhat.com> <512B3D54.4030505@themacartneyclan.com> <20130225105835.GE18383@hendrix.brq.redhat.com> <512B45A1.1090103@themacartneyclan.com> Message-ID: <20130225111505.GF18383@hendrix.brq.redhat.com> On Mon, Feb 25, 2013 at 11:06:09AM +0000, Dale Macartney wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On 02/25/2013 10:58 AM, Jakub Hrozek wrote: > > On Mon, Feb 25, 2013 at 10:30:44AM +0000, Dale Macartney wrote: > >>>> What state is your SELinux in? Permissive/Enforcing/Disabled ? > >> Another fail on my part. Works fine in permissive mode. > >> > > > > No, the SSSD should be working out of the box with SELinux Enforcing. > > > >> AVC denials listed below.. > >> > >> type=AVC msg=audit(1361788146.020:28315): avc: denied { read } for > >> pid=2271 comm="sshd" name="passwd" dev=dm-0 ino=914246 > >> scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 > >> tcontext=system_u:object_r:sssd_var_lib_t:s0 tclass=file > >> type=AVC msg=audit(1361788146.020:28315): avc: denied { open } for > >> pid=2271 comm="sshd" name="passwd" dev=dm-0 ino=914246 > >> scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 > >> tcontext=system_u:object_r:sssd_var_lib_t:s0 tclass=file > >> type=AVC msg=audit(1361788146.020:28316): avc: denied { getattr } for > >> pid=2271 comm="sshd" path="/var/lib/sss/mc/passwd" dev=dm-0 ino=914246 > >> scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 > > > > ^ This is SElinux denying access to the fast in-memory cache. > > > >> tcontext=system_u:object_r:sssd_var_lib_t:s0 tclass=file > >> type=AVC msg=audit(1361788155.330:28318): avc: denied { read } for > >> pid=2275 comm="krb5_child" name="config" dev=dm-0 ino=392854 > >> scontext=system_u:system_r:sssd_t:s0 > >> tcontext=system_u:object_r:selinux_config_t:s0 tclass=file > >> type=AVC msg=audit(1361788155.330:28318): avc: denied { open } for > >> pid=2275 comm="krb5_child" name="config" dev=dm-0 ino=392854 > >> scontext=system_u:system_r:sssd_t:s0 > >> tcontext=system_u:object_r:selinux_config_t:s0 tclass=file > >> type=AVC msg=audit(1361788155.330:28319): avc: denied { getattr } for > >> pid=2275 comm="krb5_child" path="/etc/selinux/config" dev=dm-0 > >> ino=392854 scontext=system_u:system_r:sssd_t:s0 > > > > Interesting, I'm not aware of any code in the krb5 child process that > > would do anything selinux-related. I wonder if libkrb5 might be the > > culprit..rpm says it *is* linked against libselinux as well. > > > >> tcontext=system_u:object_r:selinux_config_t:s0 tclass=file > >> type=AVC msg=audit(1361788156.367:28321): avc: denied { write } for > >> pid=1380 comm="sssd_pam" name="logins" dev=dm-0 ino=392943 > >> scontext=system_u:system_r:sssd_t:s0 > >> tcontext=system_u:object_r:selinux_config_t:s0 tclass=dir > >> type=AVC msg=audit(1361788156.367:28321): avc: denied { add_name } > >> for pid=1380 comm="sssd_pam" name="adminoTfIUQ" > >> scontext=system_u:system_r:sssd_t:s0 > >> tcontext=system_u:object_r:selinux_config_t:s0 tclass=dir > >> type=AVC msg=audit(1361788156.367:28321): avc: denied { create } for > >> pid=1380 comm="sssd_pam" name="adminoTfIUQ" > >> scontext=system_u:system_r:sssd_t:s0 > >> tcontext=system_u:object_r:selinux_config_t:s0 tclass=file > >> type=AVC msg=audit(1361788156.367:28321): avc: denied { write } for > >> pid=1380 comm="sssd_pam" name="adminoTfIUQ" dev=dm-0 ino=393233 > >> scontext=system_u:system_r:sssd_t:s0 > >> tcontext=system_u:object_r:selinux_config_t:s0 tclass=file > >> type=AVC msg=audit(1361788156.367:28322): avc: denied { remove_name } > >> for pid=1380 comm="sssd_pam" name="adminoTfIUQ" dev=dm-0 ino=393233 > >> scontext=system_u:system_r:sssd_t:s0 > >> tcontext=system_u:object_r:selinux_config_t:s0 tclass=dir > >> type=AVC msg=audit(1361788156.367:28322): avc: denied { rename } for > >> pid=1380 comm="sssd_pam" name="adminoTfIUQ" dev=dm-0 ino=393233 > >> scontext=system_u:system_r:sssd_t:s0 > >> tcontext=system_u:object_r:selinux_config_t:s0 tclass=file > >> type=AVC msg=audit(1361788156.367:28322): avc: denied { unlink } for > >> pid=1380 comm="sssd_pam" name="admin" dev=dm-0 ino=392951 > >> scontext=system_u:system_r:sssd_t:s0 > >> tcontext=system_u:object_r:selinux_config_t:s0 tclass=file > > > > This is SSSD trying to write the user login mapping. > > > > What version is your selinux-policy? > > > > Was your system properly labeled? > > > > Does restorecon -Rvv /etc/selinux help? > Interesting, after using restorecon, yes it now allows a successful > login. I am curious how the contexts would have become incorrectly set > as the machine was provisioned with a rather trivial kickstart. > > output of restorecon is below. > > [root at workstation01 ~]# restorecon -Rvv /etc/selinux/ > restorecon reset /etc/selinux/targeted/logins context > system_u:object_r:selinux_config_t:s0->system_u:object_r:selinux_login_config_t:s0 > restorecon reset /etc/selinux/targeted/logins/admin context > system_u:object_r:selinux_config_t:s0->system_u:object_r:selinux_login_config_t:s0 > [root at workstation01 ~]# > > selinux policy version 3.7.19-195.el6_4.1 I'm not sure, was the system installed with that version or upgraded to it? I would also suggest to restorecon /var/lib/sss/mc/passwd to get rid of the memory cache denials. That should also allow faster initgroups (and by extension logins) operation. From dale at themacartneyclan.com Mon Feb 25 11:22:50 2013 From: dale at themacartneyclan.com (Dale Macartney) Date: Mon, 25 Feb 2013 11:22:50 +0000 Subject: [Freeipa-users] RHEL 6.4 ipa-client install on ipa member server In-Reply-To: <20130225111505.GF18383@hendrix.brq.redhat.com> References: <51294234.3080003@themacartneyclan.com> <5129448A.5020506@redhat.com> <51294543.8000707@themacartneyclan.com> <20130225101524.GB18383@hendrix.brq.redhat.com> <512B3D54.4030505@themacartneyclan.com> <20130225105835.GE18383@hendrix.brq.redhat.com> <512B45A1.1090103@themacartneyclan.com> <20130225111505.GF18383@hendrix.brq.redhat.com> Message-ID: <512B498A.6040202@themacartneyclan.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/25/2013 11:15 AM, Jakub Hrozek wrote: > On Mon, Feb 25, 2013 at 11:06:09AM +0000, Dale Macartney wrote: >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> >> On 02/25/2013 10:58 AM, Jakub Hrozek wrote: >>> On Mon, Feb 25, 2013 at 10:30:44AM +0000, Dale Macartney wrote: >>>>>> What state is your SELinux in? Permissive/Enforcing/Disabled ? >>>> Another fail on my part. Works fine in permissive mode. >>>> >>> >>> No, the SSSD should be working out of the box with SELinux Enforcing. >>> >>>> AVC denials listed below.. >>>> >>>> type=AVC msg=audit(1361788146.020:28315): avc: denied { read } for >>>> pid=2271 comm="sshd" name="passwd" dev=dm-0 ino=914246 >>>> scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 >>>> tcontext=system_u:object_r:sssd_var_lib_t:s0 tclass=file >>>> type=AVC msg=audit(1361788146.020:28315): avc: denied { open } for >>>> pid=2271 comm="sshd" name="passwd" dev=dm-0 ino=914246 >>>> scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 >>>> tcontext=system_u:object_r:sssd_var_lib_t:s0 tclass=file >>>> type=AVC msg=audit(1361788146.020:28316): avc: denied { getattr } for >>>> pid=2271 comm="sshd" path="/var/lib/sss/mc/passwd" dev=dm-0 ino=914246 >>>> scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 >>> >>> ^ This is SElinux denying access to the fast in-memory cache. >>> >>>> tcontext=system_u:object_r:sssd_var_lib_t:s0 tclass=file >>>> type=AVC msg=audit(1361788155.330:28318): avc: denied { read } for >>>> pid=2275 comm="krb5_child" name="config" dev=dm-0 ino=392854 >>>> scontext=system_u:system_r:sssd_t:s0 >>>> tcontext=system_u:object_r:selinux_config_t:s0 tclass=file >>>> type=AVC msg=audit(1361788155.330:28318): avc: denied { open } for >>>> pid=2275 comm="krb5_child" name="config" dev=dm-0 ino=392854 >>>> scontext=system_u:system_r:sssd_t:s0 >>>> tcontext=system_u:object_r:selinux_config_t:s0 tclass=file >>>> type=AVC msg=audit(1361788155.330:28319): avc: denied { getattr } for >>>> pid=2275 comm="krb5_child" path="/etc/selinux/config" dev=dm-0 >>>> ino=392854 scontext=system_u:system_r:sssd_t:s0 >>> >>> Interesting, I'm not aware of any code in the krb5 child process that >>> would do anything selinux-related. I wonder if libkrb5 might be the >>> culprit..rpm says it *is* linked against libselinux as well. >>> >>>> tcontext=system_u:object_r:selinux_config_t:s0 tclass=file >>>> type=AVC msg=audit(1361788156.367:28321): avc: denied { write } for >>>> pid=1380 comm="sssd_pam" name="logins" dev=dm-0 ino=392943 >>>> scontext=system_u:system_r:sssd_t:s0 >>>> tcontext=system_u:object_r:selinux_config_t:s0 tclass=dir >>>> type=AVC msg=audit(1361788156.367:28321): avc: denied { add_name } >>>> for pid=1380 comm="sssd_pam" name="adminoTfIUQ" >>>> scontext=system_u:system_r:sssd_t:s0 >>>> tcontext=system_u:object_r:selinux_config_t:s0 tclass=dir >>>> type=AVC msg=audit(1361788156.367:28321): avc: denied { create } for >>>> pid=1380 comm="sssd_pam" name="adminoTfIUQ" >>>> scontext=system_u:system_r:sssd_t:s0 >>>> tcontext=system_u:object_r:selinux_config_t:s0 tclass=file >>>> type=AVC msg=audit(1361788156.367:28321): avc: denied { write } for >>>> pid=1380 comm="sssd_pam" name="adminoTfIUQ" dev=dm-0 ino=393233 >>>> scontext=system_u:system_r:sssd_t:s0 >>>> tcontext=system_u:object_r:selinux_config_t:s0 tclass=file >>>> type=AVC msg=audit(1361788156.367:28322): avc: denied { remove_name } >>>> for pid=1380 comm="sssd_pam" name="adminoTfIUQ" dev=dm-0 ino=393233 >>>> scontext=system_u:system_r:sssd_t:s0 >>>> tcontext=system_u:object_r:selinux_config_t:s0 tclass=dir >>>> type=AVC msg=audit(1361788156.367:28322): avc: denied { rename } for >>>> pid=1380 comm="sssd_pam" name="adminoTfIUQ" dev=dm-0 ino=393233 >>>> scontext=system_u:system_r:sssd_t:s0 >>>> tcontext=system_u:object_r:selinux_config_t:s0 tclass=file >>>> type=AVC msg=audit(1361788156.367:28322): avc: denied { unlink } for >>>> pid=1380 comm="sssd_pam" name="admin" dev=dm-0 ino=392951 >>>> scontext=system_u:system_r:sssd_t:s0 >>>> tcontext=system_u:object_r:selinux_config_t:s0 tclass=file >>> >>> This is SSSD trying to write the user login mapping. >>> >>> What version is your selinux-policy? >>> >>> Was your system properly labeled? >>> >>> Does restorecon -Rvv /etc/selinux help? >> Interesting, after using restorecon, yes it now allows a successful >> login. I am curious how the contexts would have become incorrectly set >> as the machine was provisioned with a rather trivial kickstart. >> >> output of restorecon is below. >> >> [root at workstation01 ~]# restorecon -Rvv /etc/selinux/ >> restorecon reset /etc/selinux/targeted/logins context >> system_u:object_r:selinux_config_t:s0->system_u:object_r:selinux_login_config_t:s0 >> restorecon reset /etc/selinux/targeted/logins/admin context >> system_u:object_r:selinux_config_t:s0->system_u:object_r:selinux_login_config_t:s0 >> [root at workstation01 ~]# >> >> selinux policy version 3.7.19-195.el6_4.1 > > I'm not sure, was the system installed with that version or upgraded to > it? All repositories are available during install, so no need for upgrade post install. IPA client install runs as part of %post. > > > I would also suggest to restorecon /var/lib/sss/mc/passwd to get rid of > the memory cache denials. That should also allow faster initgroups (and > by extension logins) operation. Good to know, presumably this will be patched in an upcoming package release as well. > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRK0mJAAoJEAJsWS61tB+qpIMQAIXszRj6qvRaROuJYf0R4q/i ia3UYbIZvnnLjRXsNhP1DGwNOzZjLzShDo0iqfoREK6NQIyIJYWFE9oHJc8e/QkH H1m04VfBLDbTlYpyyqrcnUw1pqakdXY1pIDlXSQ5KSZoepqY2ql2NbLhl3LvMWdX s66bVFe0Yy6vqfDToS3M/S71Jv2jY4XPzNuVrw9kFe1yCwuzD4Rs8LQgwjj7sM1G KGmpfry0em3eJ+FYh8udfJrqaW5hmB8xHKRTtLRA3D+ztNtYeLicyJKmQHtPkr6f SbkRcRiTI6elGCxfrlMW0jKuc0vauvgJlVqr5MmsIG28fVj1HUf4z6/Luc07elaR ZmNf0IHS1asApuk3qbCWmmOJ/7+Rgkfwx/2yx808bGZLoxuvqP63eMjRWNk68fgp aFkQNXaNQS7DQsqaMg5GnfwJHnZ8uO5JX7rEOV55kZobWgJhPdDrDW/XYhnqWOa6 0sXU3JchZ0JELFIPBLqWZRk/rh3g5r17UUdhDStmdI6OSiPflLbBViyc+xcyqHau jS5ryXmur51WzkBjVyF5v8luIWnI8j+shiUFboPKGbN6uD1Emv3aOzFpJ8FQpG/q gpU2QUKnKBxJzk1CzlZWoNU7LBVRsNFUu4gBlGnZ3snQbRRXuf+YmxD1/34QsHag l5MqqjYW8SB1xVeZTO6t =qz0W -----END PGP SIGNATURE----- From chorn at fluxcoil.net Mon Feb 25 11:59:11 2013 From: chorn at fluxcoil.net (Christian Horn) Date: Mon, 25 Feb 2013 12:59:11 +0100 Subject: [Freeipa-users] ipa: ERROR: attribute "idnsAllowTransfer" not allowed In-Reply-To: <24628.213.225.75.97.1361782009.squirrel@www.nixtra.com> References: <24628.213.225.75.97.1361782009.squirrel@www.nixtra.com> Message-ID: <20130225115910.GA13961@fluxcoil.net> Hi, On Mon, Feb 25, 2013 at 09:46:49AM +0100, Sigbjorn Lie wrote: > > $ ipa dnszone-add example.com --name-server=ns01.example.com --admin-email=hostmaster.example.com > ipa: ERROR: attribute "idnsAllowTransfer" not allowed > > [..] > > Is this a known error? Yes, the idnsZone objectClass entry was not updated properly during ipa-server update process. To fix this the schema has to be modified, https://access.redhat.com/knowledge/solutions/301213 has the details. cheers, Christian From bret.wortman at damascusgrp.com Mon Feb 25 14:04:18 2013 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Mon, 25 Feb 2013 09:04:18 -0500 Subject: [Freeipa-users] Transferring "mastership" to a new server Message-ID: So I managed to replicate my old IPA master onto a new server, and now I'd like that server to be the center of the universe. The master from which all (new) replicas are created. At present, there are no other replicas, just this one server now that the original has been decommissioned. I did discover that I can't create replicas from it because it knows it was cloned from another. What do I need to do to it so that it can take over as the new master? * * *Bret Wortman* http://damascusgrp.com/ http://twitter.com/BretWortman -------------- next part -------------- An HTML attachment was scrubbed... URL: From pviktori at redhat.com Mon Feb 25 14:14:42 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 25 Feb 2013 15:14:42 +0100 Subject: [Freeipa-users] Transferring "mastership" to a new server In-Reply-To: References: Message-ID: <512B71D2.8030608@redhat.com> On 02/25/2013 03:04 PM, Bret Wortman wrote: > So I managed to replicate my old IPA master onto a new server, and now > I'd like that server to be the center of the universe. The master from > which all (new) replicas are created. At present, there are no other > replicas, just this one server now that the original has been > decommissioned. > > I did discover that I can't create replicas from it because it knows it > was cloned from another. What do I need to do to it so that it can take > over as the new master? > Install the CA on it (ipa-ca-install). If you have DNS set up, you'll want to run ipa-dns-install as well. -- Petr? From sigbjorn at nixtra.com Mon Feb 25 14:38:51 2013 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Mon, 25 Feb 2013 15:38:51 +0100 (CET) Subject: [Freeipa-users] ipa: ERROR: attribute 'idnsAllowTransfer' not allowed In-Reply-To: <20130225115910.GA13961@fluxcoil.net> References: <24628.213.225.75.97.1361782009.squirrel@www.nixtra.com> <20130225115910.GA13961@fluxcoil.net> Message-ID: <23480.213.225.75.97.1361803131.squirrel@www.nixtra.com> On Mon, February 25, 2013 12:59, Christian Horn wrote: > Hi, > > > On Mon, Feb 25, 2013 at 09:46:49AM +0100, Sigbjorn Lie wrote: > >> >> $ ipa dnszone-add example.com --name-server=ns01.example.com >> --admin-email=hostmaster.example.com >> ipa: ERROR: attribute "idnsAllowTransfer" not allowed >> >> >> [..] >> >> >> Is this a known error? >> > > Yes, > the idnsZone objectClass entry was not updated properly during ipa-server update process. To fix > this the schema has to be modified, https://access.redhat.com/knowledge/solutions/301213 has > the details. > Thank you. That worked just fine. :) Regards, Siggi From gmatz at collective.com Mon Feb 25 14:58:06 2013 From: gmatz at collective.com (Guy Matz) Date: Mon, 25 Feb 2013 09:58:06 -0500 Subject: [Freeipa-users] Non-Prod instance Message-ID: <512B7BFE.90201@collective.com> Hello! Does anyone out there run two instances of freeipa, prod & non-prod instances? Are there any issues to be wary of in this scenario? Any gotchas? Do you use the same realms & domain names between instances? Perhaps the fellow who upgraded his prod server to 6.4 might appreciate this . . . Thanks a lot, Guy From dale at themacartneyclan.com Mon Feb 25 15:07:27 2013 From: dale at themacartneyclan.com (Dale Macartney) Date: Mon, 25 Feb 2013 15:07:27 +0000 Subject: [Freeipa-users] Non-Prod instance In-Reply-To: <512B7BFE.90201@collective.com> References: <512B7BFE.90201@collective.com> Message-ID: <512B7E2F.1020809@themacartneyclan.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/25/2013 02:58 PM, Guy Matz wrote: > Hello! Does anyone out there run two instances of freeipa, prod & non-prod instances? Are there any issues to be wary of in this scenario? Any gotchas? Do you use the same realms & domain names between instances? I've seen in many organizations, the common practice of having two directory server environments. One for testing and development, and the other for production. It is rare that the same dns zones are used as it would be a nightmare to manage. In my own environments, I simply run a different domain name on a different IP range, and set up all my infrastructure that I want to test against that, before implementing into production. The important thing to remember is its for testing of the identity management solution, not for testing applications to interface with it. > > Perhaps the fellow who upgraded his prod server to 6.4 might appreciate this . . . > > Thanks a lot, > Guy > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRK34sAAoJEAJsWS61tB+qDzsP/2DqZsJkjaQlgB6m6j4yesET uGp3yOCWgMaNADHEQi8NQRNaJg51dLkTShZK7bHIcf1YRnLXLnjcgcnAgSG/SWHR vfDHQt+JZYViUcNGZSx7bD8X29yvauy0VsZlBvQ2+ArWo8iyCTVoW6xj0wobobrZ bhSx0B5odUUaQkEyptPI/FhhZDdRHvQ8MaOKF1RT47pFrubTU6ozwaR3uYMbQU7W vKxHVQtuTWPiQNSALAy+4KIVRi3KLMs1ZYxj87aQ64jxqD8TuBykamg1S9qrDwYh nBYEaRUggkKWRLy+MudWb6cutqY3gVqdCHjNVhyZ5+B2wEpzE7lnDaMuMZTwVDgw YU3BngXHMzbuPraPsqIYGfk0JQk7iBE42NGCtijXKdQe5EFIfL7XejV1q6lPhTEv 4zBL2Krws39jNrdvp7rE7/ff3OB0xNR2GVgRwroXUbYoV0CxeQzNw6F7IbJ4YSqi qYry9WSHdCxUrkX3X8j7bQ9nuTzdtz8xkRcyZL7q1RBO+b89LWUAPWOetXbTeFdd BT+vILwRnNazy7WSJiJqBK/IU0iK0vWs1+dbLPXGLvrtHPGyVpD68hHk2s9O2NoB sVXHd4oWkpnoG5qza5aGFVNozNX/SIyWNovjUyT6DhQ+G1lHs8w8EAlh15w91vyE URaMX0JzSpXRvGKTRs5G =W0I4 -----END PGP SIGNATURE----- From brs at usf.edu Mon Feb 25 15:38:01 2013 From: brs at usf.edu (Brian Smith) Date: Mon, 25 Feb 2013 10:38:01 -0500 Subject: [Freeipa-users] Password expiry when account provisioned/updated via JSON RPC Message-ID: It seems that regardless of the global password expiry setting, that setting a password via the methods user-add passwd i will always have a password that expires in 90 days. I followed the instructions here http://freeipa.org/page/PasswordSynchronization to avoid the immediate expiry, but I need at least 180 days for my configuration to work. Any help would be appreciated! -- Brian Smith Assistant Director Research Computing, University of South Florida 4202 E. Fowler Ave. SVC4010 Office Phone: +1 813 974-1467 Organization URL: http://rc.usf.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From kriss.prosst at gmail.com Mon Feb 25 18:33:14 2013 From: kriss.prosst at gmail.com (Kriss Von Prosst) Date: Mon, 25 Feb 2013 19:33:14 +0100 Subject: [Freeipa-users] nsslapd-changelogmaxage Message-ID: Hi, I have multimaster replication enviroment, IPA v2.2 on Fedora 17. On each replica, folder /var/lib/dirsrv/slapd-cosp/cldb/ has big size (~7GB). This is half of all available space for '/'. I found that changelog file can be trim using 'nsslapd-changelogmaxage' parameter. By default, this parameter is not set in dse.ldif (is this correct?). My questions are: a) where should I put 'nsslapd-changelogmaxage' parameter, into tree: cn=Retro Changelog Plugin, cn=config or cn=changelog5,cn=config. b) what are the consequences when I set this parameter to nsslapd-changelogmaxage: 10d? c) Is any other possibility to limit increase of this file? Kriss -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmercer at harris.com Mon Feb 25 18:48:58 2013 From: rmercer at harris.com (Mercer, Rodney) Date: Mon, 25 Feb 2013 18:48:58 +0000 Subject: [Freeipa-users] RHEL6 IPA and Active Directory synchronisation and Solaris RBAC In-Reply-To: <5125E083.3040506@redhat.com> References: <511BACEE.8050900@redhat.com> <511D2541.1000201@nixtra.com> <511D2CAC.6050400@redhat.com> <511D4693.8010502@redhat.com> <1360937840.21935.556.camel@osc145.evn.harris.com> <511EA93C.8060909@redhat.com>,<511F6D98.30700@nixtra.com> <512A3AF8DAE8454D95C05141F746ECE1512AC316@MLBMXUS21.cs.myharris.net> <512121E9.2050608@redhat.com> <1361283261.21935.914.camel@osc145.evn.harris.com> <51242F73.9000309@redhat.com> <1361367894.21935.1033.camel@osc145.evn.harris.com> <5125E083.3040506@redhat.com> Message-ID: <512A3AF8DAE8454D95C05141F746ECE1512E84A0@MLBMXUS21.cs.myharris.net> On Thu, 2013-02-21 at 03:53 -0500, Dmitri Pal wrote: > On 02/20/2013 08:44 AM, Rodney L. Mercer wrote: > > > > On Tue, 2013-02-19 at 21:05 -0500, Dmitri Pal wrote: > >> On 02/19/2013 09:14 AM, Rodney L. Mercer wrote: > >>> On Sun, 2013-02-17 at 13:31 -0500, Dmitri Pal wrote: > >>>> On 02/16/2013 12:14 PM, Mercer, Rodney wrote: > >>>>> ________________________________________ > >>>>> From: freeipa-users-bounces at redhat.com > [freeipa-users-bounces at redhat.com] on behalf of Sigbjorn Lie > [sigbjorn at nixtra.com] > >>>>> Sent: Saturday, February 16, 2013 6:29 AM > >>>>> To: freeipa-users at redhat.com > >>>>> Subject: Re: [Freeipa-users] RHEL6 IPA and Active Directory > synchronisation and Solaris RBAC > >>>>> > >>>>> On 02/15/2013 10:31 PM, Dmitri Pal wrote: > >>>>>> On 02/15/2013 09:17 AM, Rodney L. Mercer wrote: > >>>>>>> On Thu, 2013-02-14 at 21:44 +0100, Sigbjorn Lie wrote: > >>>>>>>> I agree with schema support being enough for now. I do not > expect the > >>>>>>>> ipa mgmt tools to support Solaris rbac mgmt. > >>>>>>>> > >>>>>>>> The ipa mgmt tools are great, but I already have other data > in the ipa > >>>>>>>> ldap that I have to manage manually anyway. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> Rgds, > >>>>>>>> Siggi > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> Rob Crittenden wrote: > >>>>>>>> Dag Wieers wrote: > >>>>>>>> On Thu, 14 Feb 2013, Rob Crittenden wrote: > >>>>>>>> > >>>>>>>> Sigbjorn Lie wrote: > >>>>>>>> On 02/13/2013 04:10 PM, Rob > Crittenden wrote: > >>>>>>>> > >>>>>>>> Also since > we also require compatibility with Solaris, and roles > >>>>>>>> (RBAC) > >>>>>>>> is currently > used on Solaris, does IPA support RBAC on Solar > >>>>>>>> is ? > >>>>>>>> (We > >>>>>>>> noticed that > RBAC mentioned in the IPA web interface only > >>>>>>>> relates to > > IPA > >>>>>>>> management). > >>>>>>>> No, IPA > doesn't support RBAC on Solaris. > >>>>>>>> > >>>>>>>> I've come across the same > issue. This is just a matter of extending the > >>>>>>>> schema. > >>>>>>>> > >>>>>>>> Would there be any interest > for adding the Solaris RBAC schema as a > >>>>>>>> part > >>>>>>>> of the standard IPA > distributed LDAP schema? > >>>>>>> Consider the following: What else would have to be put in to > support > >>>>>>> this? > >>>>>>> Once the schema is established, can SSSD be extended to use > this and > >>>>>>> potentially be referenced in nsswitch.conf as it is > implemented on > >>>>>>> Solaris? IE: > >>>>>>> tail -5 /etc/nsswitch.conf > >>>>>>> user_attr: sssd > >>>>>>> auth_attr: sssd > >>>>>>> prof_attr: sssd > >>>>>>> exec_attr: sssd > >>>>>>> project: sssd > >>>>>> Before we define how it is passed/exposed it would nice to > understand > >>>>>> who on Linux will be consuming it out of SSSD? > >>>>>> > >>>>> I don't think Linux would consume these attributes. They are > specific to > >>>>> the Role Based Access Control solution implemented in Solaris. > >>>>> > >>>>> > >>>>> Rgds, > >>>>> Siggi > >>>>> > >>>>> ---------------------------------- > >>>>> > >>>>> Yes, I understand that Linux has no mechanism currently built in > to consume these Solaris name server switch attributes. But, If the > Solaris RBAC schema is included as > >>>>> part of the standard IPA distributed LDAP schema, My question is > how hard would it be to create an extension using SSSD/pam to do so? > >>>>> > >>>>> I agree that it is too much to ask for a full Solaris style RBAC > implementation on RHEL. > >>>>> > >>>>> We have an application that currently uses the Solaris RBAC > structure to authorize user/role accesses within the application. > >>>>> > >>>>> Our goal is to use existing OS calls or possibly extending SSSD > to allow system calls that would give us back an answer to attrbutes > placed within the LDAP > >>>>> tree that are composed in like fashion as how they are stored > in Solaris. Defining the schema seemed to be well received and I > understand that it is intended that it would be there to support > Solaris clients. > >>>>> If SSSD could be extended to access these attributes and > possibly pam modules to allow Linux clients to take advantage of this > RBAC schema, then our application could perform as it does on Solaris. > It would also > >>>>> open up the opportunity for other vendors to consider moving > their Solaris RBAC applications to RHEL. > >>>>> > >>>>> I think with that as a goal, we could then create users and > SELinux roles that are defined within the RBAC based schema much like > our current Solaris implementation. > >>>>> We use Solaris nsswitch calls to get yes/no authorization > answers for user/role privilege within our application. > >>>>> > >>>>> Since IdM and SSD already support > >>>>> a) HBAC > >>>>> b) SUDO > >>>>> c) SELinux user mapping > >>>>> > >>>>> I believe HBAC as already implemented in IdM will be an > additional asset in defining and restricting access that can be used > by our customers. > >>>>> We have decided to move away from sudo, but may reconsider some > of its uses if it suits the situation. > >>>>> Maybe SSSD can be extended to access the RBAC schema in much the > same way that it accesses SUDO or HBAC schema? > >>>>> > >>>>> We have decided to use RHEL as the primary OS platform of choice > going forward and we need to create a solution to our application RBAC > >>>>> needs similar to that in which we have accomplished with > Solaris. I have been speaking with Dmitri on the side about these > possibilities and would like to know > >>>>> what each of your thoughts are. The feasibility of accomplishing > this is a bit over my head but is certainly our goal. > >>>>> I believe our management is committed to creating such a > solution by involving our software engineers. Helping with adding the > Solaris RBAC schema and > >>>>> contributing the GUI to manage the RBAC Schema data would be a > goal. > >>>>> > >>>>> Also, since this is not the SSSD development list, I would like > to know the list info for SSSD development and see what their thoughts > are. > >>>>> > >>>>> Dmitri to answer your questions directly to me: > >>>>> Certainly we can discuss additional security components such as > centrally managed SSH keys and host fingerprints. We don't need any > interaction within our application to include AD, > >>>>> but our customers may want to take advantage of that at some > point. > >>>> The sssd user list is > >>>> > >>>> sssd-users at lists.fedorahosted.org > >>>> > >>>> The devel list is > >>>> sssd-devel at lists.fedorahosted.org > >>>> > >>>> > >>>> But I suggest we continue this conversation here because > otherwise the > >>>> conversation might fork and I would be hard to track. Most of the > SSSD > >>>> developers read this list too. > >>>> > >>>> Since you have a clearly defined interface your application > consumes > >>>> from Solaris the best thing now would be for you to provide a man > page > >>>> style description of the calls the application needs and we will > see how > >>>> to satisfy them with what we have and identify what needs to be > added. > >>>> IMO such interface would be a requirement list. How we deliver it > to the > >>>> application is an important but yes an implementation detail that > we can > >>>> discuss after we know what requirements are. > >>>> > >>> Dmitri, > >>> > >>> We only use one system call from our application. that is > >>> chkauthattr - get authorization entry > >>> http://www.unix.com/man-page/all/3secdb/chkauthattr/ > >>> > >>> we have users and roles defined in the user_attr map > >>> Each user is assigned one or more profiles. > >>> > >>> The profiles are kept in the prof_attr map. > >>> Top level Profiles can and often are mapped to groups of "sub" > profiles, > >>> where each of the "sub" profiles are mapped to groups of > authorizations. > >>> > >>> The authorizations are stored in the auth_attr map and map to > strings > >>> that our application queries to determine if the user/role has > mapped > >>> to via the profiles that they have been assigned. > >>> > >>> If the string is contained in the mapping, the chkautattr call > returns > >>> an allowed response, if not, it returns a denied response to the > system > >>> call. > >>> > >>> > >>> Example: Authorization check > >>> > >>> ruid = getuid(); > >>> if ((pwp = getpwuid(ruid)) == NULL) > >>> crabort(INVALIDUSER); > >>> > >>> strcpy(real_login, pwp->pw_name); > >>> > >>> if ((eflag || lflag || rflag) && argc == 1) { > >>> if ((pwp = getpwnam(*argv)) == NULL) > >>> crabort(INVALIDUSER); > >>> > >>> if (!chkauthattr("auth_string", real_login)) { > >>> if (pwp->pw_uid != ruid) > >>> crabort(NOTROOT); > >>> else > >>> pp = getuser(ruid); > >>> } else > >>> pp = *argv++; > >>> } else { > >>> > >>> > >>> > >>> Authorizations > >>> An authorization is a unique string that represents a user?s right > to > >>> perform some operation or class > >>> of operations. Authorization definitions are stored in a database > called > >>> auth_attr(4). For > >>> programming authorization checks, only the authorization name is > >>> significant. > >>> > >>> CreatingAuthorization Checks > >>> > >>> To check authorizations, use the chkauthattr(3SECDB) library > function, > >>> which verifies whether > >>> or not a user has a given authorization. The synopsis is: > >>> > >>> int chkauthattr(const char *authname, const char *username); > >>> > >>> The chkauthattr() function checks the policy.conf(4), > user_attr(4), and > >>> prof_attr(4) > >>> databases in order for a match to the given authorization > >>> > >>> > >> OK, this is helpful. > >> > >> It seems that we would have to implement the whole interface > anyways for > >> completeness or you think that implementing functions other than > >> chkauthattr() would not be required? > >> How common is this use of the RBAC? > >> Is is this how it is usually done or > >> it is a one off implementation and in general in Solaris world > people > >> use RBAC information differently or to the greater extent? > > I can only speak for us, but, I'm fairly certain that we are most > likely > > "one off" in our implementation. > > We need to understand how limited it will be and what is the cost of > making it applicable to other use cases. > > > >> I want to > >> understand the scope of the solution. Would that be a one off that > would > >> work just for your application's use or RBAC or it would work for > most > >> of the Solaris applications that use RBAC. > >> > >> Is this the schema we are talking about: > >> http://docs.oracle.com/cd/E19455-01/806-5580/appendixa-8/index.html > >> > > I think that this goes back to the beginning of this thread where > Dag > > Wieers, Rob Crittenden, Simo Sorce and Sigbjorn Lie were discussing > an > > Solaris RBAC schema implementation to support Solaris clients. > > > https://www.redhat.com/archives/freeipa-users/2013-February/msg00250.html > > I did not find the exact reference to the schema in that conversation. > May be I missed it but this is why I asked. > So can someone confirm that the schema here is the right schema? > > http://docs.oracle.com/cd/E19455-01/806-5580/appendixa-8/index.html > ---------------- Yes, this looks to be the correct schema as the defined oids match the RBAC oids in the iPlanet Directory Server Setup. http://docs.oracle.com/cd/E19455-01/806-5580/6jej518pn/index.html ---------------- > > > > Certainly the schema would have to be complete to support that > > implementation. > > > > Once the schema is there to support Solaris clients, then it could > be > > exploited by linux clients with some effort. > > Getting schema there is not a problem. You just drop a schema file > into > a directory and restart the DS and the schema will be loaded. > So assume we have done it. Let us move on to the next step. > > > > >> The schema uses 4 different object classes but the functions > mentioned > >> above seem to deal only with the SolarisUserAttr and > SolarisProfAttr > >> object classes. What about other two: SolarisAuthAttr & > >> SolarisExecAttr? Are they used or we do not need these on the > server? > >> > > Again, we use user, prof and auth maps. We do not use the exec map. > > But we probably should load it too. > > > Our application uses chkauthattr calls to authorize commanding > internal > > to our application. > > The description of the chauthattr function says it uses user and prof > maps. > It is unclear how it uses auth map. Other functions do but you do not > seem to use them. > http://docs.oracle.com/cd/E18752_01/html/816-5172/chkauthattr-3secdb.html ---------------- Yes, it does state: The authorization name matches exactly any authorization assigned in the user_attr or prof_attr databases (authorization names are case-sensitive). It is my understanding that authorizations are defined in the auth_attr map and referenced via the prof_attr and/or user_attr. users/roles defined in user_attr can be assigned authorizations or profiles (groups of authorizations/profiles). profiles are groups of authorizations and they are defined in prof_attr. Also a profile can instead reference groups of other profiles which in turn would each reference a group of authorizations. The authorization are defined in auth_attr. Again this my understanding, but I am in no way an expert. ---------------- > Also I did a quick search. > Is there any existing implementation of this functionality in Open > Source? > I doubt we can use some of the existing OpenSolaris code because of > licensing. > May we can at least use it for inspiration. > > > > > >> IMO we have a good starting point to have a design page created by > you. > >> Here is the template and here are some guidelines that might be > helpful > >> when building a design page. > >> http://www.freeipa.org/page/Feature_template > >> http://www.freeipa.org/page/General_considerations > >> > >> Here is an example of the design that might give you some > inspiration > >> (not everything mentioned in those pages ended up being implemented > but > >> it gives a good hint of what needs to be covered in the design > page) . > >> http://www.freeipa.org/page/V2/DS_Design_Summary_2 (see roles > section) > >> > http://www.freeipa.org/page/Overall_Design_of_Policy_Related_Components#Roles > >> www.freeipa.org/page/V2/IPA_Client_Design_Overview > >> > >> Good luck! > >> > > Thanks, > > Rodney. > > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ Thanks and regards, Rodney. From rmeggins at redhat.com Mon Feb 25 18:53:52 2013 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 25 Feb 2013 11:53:52 -0700 Subject: [Freeipa-users] nsslapd-changelogmaxage In-Reply-To: References: Message-ID: <512BB340.7090601@redhat.com> On 02/25/2013 11:33 AM, Kriss Von Prosst wrote: > Hi, > > I have multimaster replication enviroment, IPA v2.2 on Fedora 17. On > each replica, folder /var/lib/dirsrv/slapd-cosp/cldb/ has big size > (~7GB). This is half of all available space for '/'. I found that > changelog file can be trim using 'nsslapd-changelogmaxage' parameter. > By default, this parameter is not set in dse.ldif (is this correct?). > My questions are: > > a) where should I put 'nsslapd-changelogmaxage' parameter, into tree: > cn=Retro Changelog Plugin, cn=config or cn=changelog5,cn=config. Not Retro Changelog https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication-Configuring-Replication-cmd.html#Configuring-Replication-Suppliers-cmd > b) what are the consequences when I set this parameter to > nsslapd-changelogmaxage: 10d? > c) Is any other possibility to limit increase of this file? There is also the nsslapd-changelogmaxentries parameter https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Directory_Server/9.0/html/Configuration_Command_and_File_Reference/Core_Server_Configuration_Reference.html#cnchangelog5 > > Kriss > > > _______________________________________________ > 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 rmercer at harris.com Mon Feb 25 19:29:07 2013 From: rmercer at harris.com (Mercer, Rodney) Date: Mon, 25 Feb 2013 19:29:07 +0000 Subject: [Freeipa-users] RHEL6 IPA and Active Directory synchronisation and Solaris RBAC In-Reply-To: <512A3AF8DAE8454D95C05141F746ECE1512E84A0@MLBMXUS21.cs.myharris.net> References: <511BACEE.8050900@redhat.com> <511D2541.1000201@nixtra.com> <511D2CAC.6050400@redhat.com> <511D4693.8010502@redhat.com> <1360937840.21935.556.camel@osc145.evn.harris.com> <511EA93C.8060909@redhat.com>,<511F6D98.30700@nixtra.com> <512A3AF8DAE8454D95C05141F746ECE1512AC316@MLBMXUS21.cs.myharris.net> <512121E9.2050608@redhat.com> <1361283261.21935.914.camel@osc145.evn.harris.com> <51242F73.9000309@redhat.com> <1361367894.21935.1033.camel@osc145.evn.harris.com> <5125E083.3040506@redhat.com> <512A3AF8DAE8454D95C05141F746ECE1512E84A0@MLBMXUS21.cs.myharris.net> Message-ID: <512A3AF8DAE8454D95C05141F746ECE1512E84F4@MLBMXUS21.cs.myharris.net> On Mon, 2013-02-25 at 18:48 +0000, Mercer, Rodney wrote: > > > On Thu, 2013-02-21 at 03:53 -0500, Dmitri Pal wrote: > > On 02/20/2013 08:44 AM, Rodney L. Mercer wrote: > > > > > > On Tue, 2013-02-19 at 21:05 -0500, Dmitri Pal wrote: > > >> On 02/19/2013 09:14 AM, Rodney L. Mercer wrote: > > >>> On Sun, 2013-02-17 at 13:31 -0500, Dmitri Pal wrote: > > >>>> On 02/16/2013 12:14 PM, Mercer, Rodney wrote: > > >>>>> ________________________________________ > > >>>>> From: freeipa-users-bounces at redhat.com > > [freeipa-users-bounces at redhat.com] on behalf of Sigbjorn Lie > > [sigbjorn at nixtra.com] > > >>>>> Sent: Saturday, February 16, 2013 6:29 AM > > >>>>> To: freeipa-users at redhat.com > > >>>>> Subject: Re: [Freeipa-users] RHEL6 IPA and Active Directory > > synchronisation and Solaris RBAC > > >>>>> > > >>>>> On 02/15/2013 10:31 PM, Dmitri Pal wrote: > > >>>>>> On 02/15/2013 09:17 AM, Rodney L. Mercer wrote: > > >>>>>>> On Thu, 2013-02-14 at 21:44 +0100, Sigbjorn Lie wrote: > > >>>>>>>> I agree with schema support being enough for now. I do not > > expect the > > >>>>>>>> ipa mgmt tools to support Solaris rbac mgmt. > > >>>>>>>> > > >>>>>>>> The ipa mgmt tools are great, but I already have other data > > in the ipa > > >>>>>>>> ldap that I have to manage manually anyway. > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> Rgds, > > >>>>>>>> Siggi > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> Rob Crittenden wrote: > > >>>>>>>> Dag Wieers wrote: > > >>>>>>>> On Thu, 14 Feb 2013, Rob Crittenden wrote: > > >>>>>>>> > > >>>>>>>> Sigbjorn Lie wrote: > > >>>>>>>> On 02/13/2013 04:10 PM, > Rob > > Crittenden wrote: > > >>>>>>>> > > >>>>>>>> Also since > > we also require compatibility with Solaris, and roles > > >>>>>>>> (RBAC) > > >>>>>>>> is > currently > > used on Solaris, does IPA support RBAC on Solar > > >>>>>>>> is ? > > >>>>>>>> (We > > >>>>>>>> noticed > that > > RBAC mentioned in the IPA web interface only > > >>>>>>>> relates to > > IPA > > >>>>>>>> > management). > > >>>>>>>> No, IPA > > doesn't support RBAC on Solaris. > > >>>>>>>> > > >>>>>>>> I've come across the same > > issue. This is just a matter of extending the > > >>>>>>>> schema. > > >>>>>>>> > > >>>>>>>> Would there be any > interest > > for adding the Solaris RBAC schema as a > > >>>>>>>> part > > >>>>>>>> of the standard IPA > > distributed LDAP schema? > > >>>>>>> Consider the following: What else would have to be put in to > > support > > >>>>>>> this? > > >>>>>>> Once the schema is established, can SSSD be extended to use > > this and > > >>>>>>> potentially be referenced in nsswitch.conf as it is > > implemented on > > >>>>>>> Solaris? IE: > > >>>>>>> tail -5 /etc/nsswitch.conf > > >>>>>>> user_attr: sssd > > >>>>>>> auth_attr: sssd > > >>>>>>> prof_attr: sssd > > >>>>>>> exec_attr: sssd > > >>>>>>> project: sssd > > >>>>>> Before we define how it is passed/exposed it would nice to > > understand > > >>>>>> who on Linux will be consuming it out of SSSD? > > >>>>>> > > >>>>> I don't think Linux would consume these attributes. They are > > specific to > > >>>>> the Role Based Access Control solution implemented in Solaris. > > >>>>> > > >>>>> > > >>>>> Rgds, > > >>>>> Siggi > > >>>>> > > >>>>> ---------------------------------- > > >>>>> > > >>>>> Yes, I understand that Linux has no mechanism currently built > in > > to consume these Solaris name server switch attributes. But, If the > > Solaris RBAC schema is included as > > >>>>> part of the standard IPA distributed LDAP schema, My question > is > > how hard would it be to create an extension using SSSD/pam to do so? > > >>>>> > > >>>>> I agree that it is too much to ask for a full Solaris style > RBAC > > implementation on RHEL. > > >>>>> > > >>>>> We have an application that currently uses the Solaris RBAC > > structure to authorize user/role accesses within the application. > > >>>>> > > >>>>> Our goal is to use existing OS calls or possibly extending > SSSD > > to allow system calls that would give us back an answer to > attrbutes > > placed within the LDAP > > >>>>> tree that are composed in like fashion as how they are stored > > in Solaris. Defining the schema seemed to be well received and I > > understand that it is intended that it would be there to support > > Solaris clients. > > >>>>> If SSSD could be extended to access these attributes and > > possibly pam modules to allow Linux clients to take advantage of > this > > RBAC schema, then our application could perform as it does on > Solaris. > > It would also > > >>>>> open up the opportunity for other vendors to consider moving > > their Solaris RBAC applications to RHEL. > > >>>>> > > >>>>> I think with that as a goal, we could then create users and > > SELinux roles that are defined within the RBAC based schema much > like > > our current Solaris implementation. > > >>>>> We use Solaris nsswitch calls to get yes/no authorization > > answers for user/role privilege within our application. > > >>>>> > > >>>>> Since IdM and SSD already support > > >>>>> a) HBAC > > >>>>> b) SUDO > > >>>>> c) SELinux user mapping > > >>>>> > > >>>>> I believe HBAC as already implemented in IdM will be an > > additional asset in defining and restricting access that can be used > > by our customers. > > >>>>> We have decided to move away from sudo, but may reconsider > some > > of its uses if it suits the situation. > > >>>>> Maybe SSSD can be extended to access the RBAC schema in much > the > > same way that it accesses SUDO or HBAC schema? > > >>>>> > > >>>>> We have decided to use RHEL as the primary OS platform of > choice > > going forward and we need to create a solution to our application > RBAC > > >>>>> needs similar to that in which we have accomplished with > > Solaris. I have been speaking with Dmitri on the side about these > > possibilities and would like to know > > >>>>> what each of your thoughts are. The feasibility of > accomplishing > > this is a bit over my head but is certainly our goal. > > >>>>> I believe our management is committed to creating such a > > solution by involving our software engineers. Helping with adding > the > > Solaris RBAC schema and > > >>>>> contributing the GUI to manage the RBAC Schema data would be a > > goal. > > >>>>> > > >>>>> Also, since this is not the SSSD development list, I would > like > > to know the list info for SSSD development and see what their > thoughts > > are. > > >>>>> > > >>>>> Dmitri to answer your questions directly to me: > > >>>>> Certainly we can discuss additional security components such > as > > centrally managed SSH keys and host fingerprints. We don't need any > > interaction within our application to include AD, > > >>>>> but our customers may want to take advantage of that at some > > point. > > >>>> The sssd user list is > > >>>> > > >>>> sssd-users at lists.fedorahosted.org > > >>>> > > >>>> The devel list is > > >>>> sssd-devel at lists.fedorahosted.org > > >>>> > > >>>> > > >>>> But I suggest we continue this conversation here because > > otherwise the > > >>>> conversation might fork and I would be hard to track. Most of > the > > SSSD > > >>>> developers read this list too. > > >>>> > > >>>> Since you have a clearly defined interface your application > > consumes > > >>>> from Solaris the best thing now would be for you to provide a > man > > page > > >>>> style description of the calls the application needs and we > will > > see how > > >>>> to satisfy them with what we have and identify what needs to be > > added. > > >>>> IMO such interface would be a requirement list. How we deliver > it > > to the > > >>>> application is an important but yes an implementation detail > that > > we can > > >>>> discuss after we know what requirements are. > > >>>> > > >>> Dmitri, > > >>> > > >>> We only use one system call from our application. that is > > >>> chkauthattr - get authorization entry > > >>> http://www.unix.com/man-page/all/3secdb/chkauthattr/ > > >>> > > >>> we have users and roles defined in the user_attr map > > >>> Each user is assigned one or more profiles. > > >>> > > >>> The profiles are kept in the prof_attr map. > > >>> Top level Profiles can and often are mapped to groups of "sub" > > profiles, > > >>> where each of the "sub" profiles are mapped to groups of > > authorizations. > > >>> > > >>> The authorizations are stored in the auth_attr map and map to > > strings > > >>> that our application queries to determine if the user/role has > > mapped > > >>> to via the profiles that they have been assigned. > > >>> > > >>> If the string is contained in the mapping, the chkautattr call > > returns > > >>> an allowed response, if not, it returns a denied response to the > > system > > >>> call. > > >>> > > >>> > > >>> Example: Authorization check > > >>> > > >>> ruid = getuid(); > > >>> if ((pwp = getpwuid(ruid)) == NULL) > > >>> crabort(INVALIDUSER); > > >>> > > >>> strcpy(real_login, pwp->pw_name); > > >>> > > >>> if ((eflag || lflag || rflag) && argc == 1) { > > >>> if ((pwp = getpwnam(*argv)) == NULL) > > >>> crabort(INVALIDUSER); > > >>> > > >>> if (!chkauthattr("auth_string", real_login)) { > > >>> if (pwp->pw_uid != ruid) > > >>> crabort(NOTROOT); > > >>> else > > >>> pp = getuser(ruid); > > >>> } else > > >>> pp = *argv++; > > >>> } else { > > >>> > > >>> > > >>> > > >>> Authorizations > > >>> An authorization is a unique string that represents a user?s > right > > to > > >>> perform some operation or class > > >>> of operations. Authorization definitions are stored in a > database > > called > > >>> auth_attr(4). For > > >>> programming authorization checks, only the authorization name is > > >>> significant. > > >>> > > >>> CreatingAuthorization Checks > > >>> > > >>> To check authorizations, use the chkauthattr(3SECDB) library > > function, > > >>> which verifies whether > > >>> or not a user has a given authorization. The synopsis is: > > >>> > > >>> int chkauthattr(const char *authname, const char *username); > > >>> > > >>> The chkauthattr() function checks the policy.conf(4), > > user_attr(4), and > > >>> prof_attr(4) > > >>> databases in order for a match to the given authorization > > >>> > > >>> > > >> OK, this is helpful. > > >> > > >> It seems that we would have to implement the whole interface > > anyways for > > >> completeness or you think that implementing functions other than > > >> chkauthattr() would not be required? > > >> How common is this use of the RBAC? > > >> Is is this how it is usually done or > > >> it is a one off implementation and in general in Solaris world > > people > > >> use RBAC information differently or to the greater extent? > > > I can only speak for us, but, I'm fairly certain that we are most > > likely > > > "one off" in our implementation. > > > > We need to understand how limited it will be and what is the cost of > > making it applicable to other use cases. > > > > > > >> I want to > > >> understand the scope of the solution. Would that be a one off > that > > would > > >> work just for your application's use or RBAC or it would work for > > most > > >> of the Solaris applications that use RBAC. > > >> > > >> Is this the schema we are talking about: > > >> > http://docs.oracle.com/cd/E19455-01/806-5580/appendixa-8/index.html > > >> > > > I think that this goes back to the beginning of this thread where > > Dag > > > Wieers, Rob Crittenden, Simo Sorce and Sigbjorn Lie were > discussing > > an > > > Solaris RBAC schema implementation to support Solaris clients. > > > > > > https://www.redhat.com/archives/freeipa-users/2013-February/msg00250.html > > > > I did not find the exact reference to the schema in that > conversation. > > May be I missed it but this is why I asked. > > So can someone confirm that the schema here is the right schema? > > > > http://docs.oracle.com/cd/E19455-01/806-5580/appendixa-8/index.html > > > ---------------- > > Yes, this looks to be the correct schema as the defined oids match the > RBAC oids in the iPlanet Directory Server Setup. > > http://docs.oracle.com/cd/E19455-01/806-5580/6jej518pn/index.html > > ---------------- > > > > > > Certainly the schema would have to be complete to support that > > > implementation. > > > > > > Once the schema is there to support Solaris clients, then it could > > be > > > exploited by linux clients with some effort. > > > > Getting schema there is not a problem. You just drop a schema file > > into > > a directory and restart the DS and the schema will be loaded. > > So assume we have done it. Let us move on to the next step. > > > > > > > >> The schema uses 4 different object classes but the functions > > mentioned > > >> above seem to deal only with the SolarisUserAttr and > > SolarisProfAttr > > >> object classes. What about other two: SolarisAuthAttr & > > >> SolarisExecAttr? Are they used or we do not need these on the > > server? > > >> > > > Again, we use user, prof and auth maps. We do not use the exec > map. > > > > But we probably should load it too. > > > > > Our application uses chkauthattr calls to authorize commanding > > internal > > > to our application. > > > > The description of the chauthattr function says it uses user and > prof > > maps. > > It is unclear how it uses auth map. Other functions do but you do > not > > seem to use them. > > > http://docs.oracle.com/cd/E18752_01/html/816-5172/chkauthattr-3secdb.html > > ---------------- > > Yes, it does state: > The authorization name matches exactly any authorization assigned in > the > user_attr or prof_attr databases (authorization names are > case-sensitive). > > It is my understanding that authorizations are defined in the > auth_attr > map and referenced via the prof_attr and/or user_attr. > > users/roles defined in user_attr can be assigned authorizations or > profiles (groups of authorizations/profiles). > > profiles are groups of authorizations and they are defined in > prof_attr. > Also a profile can instead reference groups of other profiles which in > turn would each reference a group of authorizations. > > The authorization are defined in auth_attr. > > Again this my understanding, but I am in no way an expert. > > ---------------- > > > > > Also I did a quick search. > > Is there any existing implementation of this functionality in Open > > Source? > > I doubt we can use some of the existing OpenSolaris code because of > > licensing. > > May we can at least use it for inspiration. > > > > > > > > > >> IMO we have a good starting point to have a design page created > by > > you. > > >> Here is the template and here are some guidelines that might be > > helpful > > >> when building a design page. > > >> http://www.freeipa.org/page/Feature_template > > >> http://www.freeipa.org/page/General_considerations > > >> > > >> Here is an example of the design that might give you some > > inspiration > > >> (not everything mentioned in those pages ended up being > implemented > > but > > >> it gives a good hint of what needs to be covered in the design > > page) . > > >> http://www.freeipa.org/page/V2/DS_Design_Summary_2 (see roles > > section) > > >> > > > http://www.freeipa.org/page/Overall_Design_of_Policy_Related_Components#Roles > > >> www.freeipa.org/page/V2/IPA_Client_Design_Overview > > >> > > >> Good luck! > > >> > > > Thanks, > > > Rodney. > > > > > > > > > -- > > Thank you, > > Dmitri Pal > > > > Sr. Engineering Manager for IdM portfolio > > Red Hat Inc. > > > > > > ------------------------------- > > Looking to carve out IT costs? > > www.redhat.com/carveoutcosts/ > > > Thanks and regards, > Rodney. > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > I think that this is a good explanation or the solaris rbac model. http://www.softpanorama.org/Solaris/Security/solaris_rbac.shtml Regards, Rodney. From treydock at gmail.com Tue Feb 26 06:31:10 2013 From: treydock at gmail.com (Trey Dockendorf) Date: Tue, 26 Feb 2013 00:31:10 -0600 Subject: [Freeipa-users] New User - Possible to point authentication to external KDC In-Reply-To: <512B10EB.6080908@redhat.com> References: <512B10EB.6080908@redhat.com> Message-ID: On Feb 25, 2013 1:23 AM, "Dmitri Pal" wrote: > > On 02/23/2013 10:33 PM, Trey Dockendorf wrote: > > I just begun evaluating FreeIPA, after having successfully used 389ds > > for a few months. The move from 389 ds to FreeIPA is to leverage the > > authorization for host logins and also for simpler management. The > > University I am deploying at has a campus wide KDC and for security > > and audit reasons I prefer to point my authentication services at that > > Kerberos realm rather than storing passwords. I have successfully > > implemented this using the 389 ds pam pass through authentication > > plug-in , but have not found any documentation on how to do this same > > thing with FreeIPA. > > > > The complication with doing this is I do not have even a 1 way trust > > with the KDC. Getting a trust (even 1-way) is very difficult if not > > impossible, but so far I've been able to make PAM work with that > > situation both using local authentication and now 389 ds, both through > > PAM. Is it possible to have FreeIPA query a remote KDC while still > > being able to fallback to the local password store (ie external users > > not in campus domain). > > IPA uses the 389 DS so it might be possible to configure PAM pass > through but there might be implications because if users are not in IPA > you would not get a ticket and since you cant get a ticket you can't use > UI and CLI. You can still bind using LDAP though as you do with the 389. > So to manage IPA you would still have to have a user in IPA. However you > will have two KDCs and I do not know what implications there would be > for the clients, they might be confused. > Frankly you are better off with 389 now untill we make setting up trusts > with other IPAs or MIT KDCs simple. We did that for AD but it requires a > clean DNS setup. I suspect DNS setup will be an issue in any case. > > > > > Thanks > > - Trey > > > > _______________________________________________ > > Freeipa-users mailing list > > Freeipa-users at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users Thanks for the response! I do plan to have all my users in freeIPA. My goal is to have my freeIPA install just attempt a password authentication against external KDC via pam on the IPA server before trying the local password store. With my current 389 setup, clients are unaware of our campus KDC, the authentication is handled my 389 server and currently users in my LDAP who have campus accounts get their password verified via PAM and others in my LDAP use the local password stored in 389. The aspects of IPA aside from 389 are where my uncertainty lies. For example, if I have LDAP authenticate against an external KDC via PAM, can the user still get a ticket from my IPA? Also getting a trust may not be possible even if freeipa makes the process easier. This is a politics issue with our campus' main IT group and something I've worked around thus far. Is there anything in changes of the stock 389 that would prevent this from working in IPA? Also is there a preferred method for enabling plugins in IPA? Also how could I test this? Would a client machine joined to my IPA install be the best method? Thanks - Trey -------------- next part -------------- An HTML attachment was scrubbed... URL: From umarzuki at gmail.com Tue Feb 26 08:01:52 2013 From: umarzuki at gmail.com (Umarzuki Mochlis) Date: Tue, 26 Feb 2013 16:01:52 +0800 Subject: [Freeipa-users] ipa-replica-install command failed Message-ID: hi, on tried to create a free-ipa replica on fedora 18 with freeipa-server-3.1.2-1.fc18.x86_64 below is last few lines of /var/log/ipareplica-install.log 2013-02-25T16:16:33Z DEBUG retrieving schema for SchemaCache url=ldap://ipa.domain.com:389 conn= 2013-02-25T16:18:42Z INFO File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 617, in run_script return_value = main_function() File "/usr/sbin/ipa-replica-install", line 633, in main ds = install_replica_ds(config) File "/usr/sbin/ipa-replica-install", line 161, in install_replica_ds pkcs12_info) File "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line 303, in create_replica self.start_creation(runtime=60) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 358, in start_creation method() File "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line 316, in __setup_replica r_bindpw=self.dm_password) File "/usr/lib/python2.7/site-packages/ipaserver/install/replication.py", line 864, in setup_replication raise RuntimeError("Failed to start replication") 2013-02-25T16:18:42Z INFO The ipa-replica-install command failed, exception: RuntimeError: Failed to start replication is this a known issue/bug or simply errors on my part? -- Regards, Umarzuki Mochlis http://debmal.my From mkosek at redhat.com Tue Feb 26 08:04:38 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 26 Feb 2013 09:04:38 +0100 Subject: [Freeipa-users] ipa: ERROR: attribute 'idnsAllowTransfer' not allowed In-Reply-To: <23480.213.225.75.97.1361803131.squirrel@www.nixtra.com> References: <24628.213.225.75.97.1361782009.squirrel@www.nixtra.com> <20130225115910.GA13961@fluxcoil.net> <23480.213.225.75.97.1361803131.squirrel@www.nixtra.com> Message-ID: <512C6C96.2050302@redhat.com> On 02/25/2013 03:38 PM, Sigbjorn Lie wrote: > On Mon, February 25, 2013 12:59, Christian Horn wrote: >> Hi, >> >> >> On Mon, Feb 25, 2013 at 09:46:49AM +0100, Sigbjorn Lie wrote: >> >>> >>> $ ipa dnszone-add example.com --name-server=ns01.example.com >>> --admin-email=hostmaster.example.com >>> ipa: ERROR: attribute "idnsAllowTransfer" not allowed >>> >>> >>> [..] >>> >>> >>> Is this a known error? >>> >> >> Yes, >> the idnsZone objectClass entry was not updated properly during ipa-server update process. To fix >> this the schema has to be modified, https://access.redhat.com/knowledge/solutions/301213 has >> the details. >> > > Thank you. That worked just fine. :) > > > Regards, > Siggi > Hi guys, I am glad you resolved the issue. I am just curious - from what version to what version did you upgrade? Is this is a bug in IPA in RHEL 6.4? Thank you, Martin From mkosek at redhat.com Tue Feb 26 08:09:07 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 26 Feb 2013 09:09:07 +0100 Subject: [Freeipa-users] ipa-replica-install command failed In-Reply-To: References: Message-ID: <512C6DA3.8040801@redhat.com> On 02/26/2013 09:01 AM, Umarzuki Mochlis wrote: > hi, > > on tried to create a free-ipa replica on fedora 18 with > freeipa-server-3.1.2-1.fc18.x86_64 > > below is last few lines of /var/log/ipareplica-install.log > > 2013-02-25T16:16:33Z DEBUG retrieving schema for SchemaCache > url=ldap://ipa.domain.com:389 conn= instance at 0x3b77758> > 2013-02-25T16:18:42Z INFO File > "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", > line 617, in run_script > return_value = main_function() > > File "/usr/sbin/ipa-replica-install", line 633, in main > ds = install_replica_ds(config) > > File "/usr/sbin/ipa-replica-install", line 161, in install_replica_ds > pkcs12_info) > > File "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", > line 303, in create_replica > self.start_creation(runtime=60) > > File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", > line 358, in start_creation > method() > > File "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", > line 316, in __setup_replica > r_bindpw=self.dm_password) > > File "/usr/lib/python2.7/site-packages/ipaserver/install/replication.py", > line 864, in setup_replication > raise RuntimeError("Failed to start replication") > > 2013-02-25T16:18:42Z INFO The ipa-replica-install command failed, > exception: RuntimeError: Failed to start replication > > is this a known issue/bug or simply errors on my part? > Hello Umarzuki, I am not aware of this bug. Can you please check 389-ds-base logs on the replica and see if there is any bug? The log should be in /var/log/dirsrv/slapd-YOUR-IPA-INSTANCE/errors. Martin From mkosek at redhat.com Tue Feb 26 08:22:14 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 26 Feb 2013 09:22:14 +0100 Subject: [Freeipa-users] Password expiry when account provisioned/updated via JSON RPC In-Reply-To: References: Message-ID: <512C70B6.6090408@redhat.com> On 02/25/2013 04:38 PM, Brian Smith wrote: > It seems that regardless of the global password expiry setting, that setting a > password via the methods > > user-add > passwd > > i will always have a password that expires in 90 days. I followed the > instructions here http://freeipa.org/page/PasswordSynchronization > > to avoid the immediate expiry, but I need at least 180 days for my > configuration to work. > > Any help would be appreciated! > > -- > Brian Smith > Assistant Director > Research Computing, University of South Florida > 4202 E. Fowler Ave. SVC4010 > Office Phone: +1 813 974-1467 > Organization URL: http://rc.usf.edu > Hello Brian, Updating maximum password expiration time with "ipa pwpolicy-mod" affects only new passwords, i.e. password that you already changed will have the old lifetime. When I tested this on Fedora 18, password change worked for me: # ipa pwpolicy-mod --maxlife 180 Group: global_policy Max lifetime (days): 180 Min lifetime (hours): 1 History size: 0 Character classes: 0 Min length: 8 Max failures: 6 Failure reset interval: 60 Lockout duration: 600 # ipa user-add --first=Foo --last=Bar fbar ----------------- Added user "fbar" ----------------- User login: fbar First name: Foo Last name: Bar Full name: Foo Bar Display name: Foo Bar Initials: FB Home directory: /home/fbar GECOS field: Foo Bar Login shell: /bin/sh Kerberos principal: fbar at EXAMPLE.COM Email address: fbar at example.com UID: 1758200001 GID: 1758200001 Password: False Member of groups: ipausers Kerberos keys available: False # ipa passwd fbar New Password: Enter New Password again to verify: --------------------------------------- Changed password for "fbar at EXAMPLE.COM" --------------------------------------- $ ssh fbar at ipa.client.fqdn fbar at ipa.client.fqdn's password: Password expired. Change your password now. Last login: Tue Feb 26 09:16:39 2013 from 10.0.0.1 WARNING: Your password has expired. You must change your password now and login again! Changing password for user fbar. Current Password: New password: Retype new password: Your password will expire in 180 day(s). <<<<<<<<<<<<<<< passwd: all authentication tokens updated successfully. Connection to ipa.client.fqdn closed. Does this usecase work for you or are you hitting a bug? As for the warning about expiring password, this is a bug in sssd component which was already fixed upstream: https://fedorahosted.org/sssd/ticket/1808 Martin From umarzuki at gmail.com Tue Feb 26 08:36:55 2013 From: umarzuki at gmail.com (Umarzuki Mochlis) Date: Tue, 26 Feb 2013 16:36:55 +0800 Subject: [Freeipa-users] ipa-replica-install command failed In-Reply-To: <512C6DA3.8040801@redhat.com> References: <512C6DA3.8040801@redhat.com> Message-ID: 2013/2/26 Martin Kosek : Hi Martin, I found below on errors file [26/Feb/2013:00:16:14 +0800] - 389-Directory/1.3.0.3 B2013.045.10 starting up [26/Feb/2013:00:16:14 +0800] - Db home directory is not set. Possibly nsslapd-directory (optionally nsslapd-db-home-directory) is missin g in the config file. . . [26/Feb/2013:00:16:32 +0800] - 389-Directory/1.3.0.3 B2013.045.10 starting up [26/Feb/2013:00:16:32 +0800] ipaenrollment_start - [file ipa_enrollment.c, line 390]: Failed to get default realm?! . . [26/Feb/2013:00:16:33 +0800] NSMMReplicationPlugin - agmt="cn=meToipa.domain.com" (ipa:389): Replica has a different generation ID than the local data. [26/Feb/2013:00:16:33 +0800] NSMMReplicationPlugin - multimaster_be_state_change: replica dc=domain,dc=com is going offline; disabling replication > Hello Umarzuki, > > I am not aware of this bug. Can you please check 389-ds-base logs on the > replica and see if there is any bug? The log should be in > /var/log/dirsrv/slapd-YOUR-IPA-INSTANCE/errors. > > Martin -- Regards, Umarzuki Mochlis http://debmal.my From mkosek at redhat.com Tue Feb 26 09:05:04 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 26 Feb 2013 10:05:04 +0100 Subject: [Freeipa-users] ipa-replica-install command failed In-Reply-To: References: <512C6DA3.8040801@redhat.com> Message-ID: <512C7AC0.9010206@redhat.com> Hm, all these are usually benign, when we are just setting up a replication. Can you please send me the whole ipareplica-install.log and dirsrv's errors log so I can see these errors in a broader context? You can do it in private message if you want. Btw I assume that you are running on the current Fedora 18 389-ds-base version (389-ds-base-0:1.3.0.2-1.fc18) Thanks, Martin On 02/26/2013 09:36 AM, Umarzuki Mochlis wrote: > 2013/2/26 Martin Kosek : > > Hi Martin, > > I found below on errors file > > [26/Feb/2013:00:16:14 +0800] - 389-Directory/1.3.0.3 B2013.045.10 starting up > [26/Feb/2013:00:16:14 +0800] - Db home directory is not set. Possibly > nsslapd-directory (optionally nsslapd-db-home-directory) is missin > g in the config file. > . > . > [26/Feb/2013:00:16:32 +0800] - 389-Directory/1.3.0.3 B2013.045.10 starting up > [26/Feb/2013:00:16:32 +0800] ipaenrollment_start - [file > ipa_enrollment.c, line 390]: Failed to get default realm?! > . > . > [26/Feb/2013:00:16:33 +0800] NSMMReplicationPlugin - > agmt="cn=meToipa.domain.com" (ipa:389): Replica has a different > generation ID than the local data. > [26/Feb/2013:00:16:33 +0800] NSMMReplicationPlugin - > multimaster_be_state_change: replica dc=domain,dc=com is going > offline; disabling replication > >> Hello Umarzuki, >> >> I am not aware of this bug. Can you please check 389-ds-base logs on the >> replica and see if there is any bug? The log should be in >> /var/log/dirsrv/slapd-YOUR-IPA-INSTANCE/errors. >> >> Martin > > > From arthur at deus.pro Tue Feb 26 10:49:07 2013 From: arthur at deus.pro (=?koi8-r?Q?=E1=D2=D4=D5=D2_?= =?koi8-r?Q?=E6=C1=CA=DA=D5=CC=CC=C9=CE?=) Date: Tue, 26 Feb 2013 16:49:07 +0600 Subject: [Freeipa-users] FreeIPA for AMM users management In-Reply-To: <509779AA.6010409@redhat.com> References: <20121101042710.GC8238@work.zhukoff.net> <1351799730.18469.138.camel@willson.li.ssimo.org> <1351804185.18469.146.camel@willson.li.ssimo.org> <20121102041246.GB1558@work.zhukoff.net> <5093C424.5010506@redhat.com> <20121103121243.GC1558@work.zhukoff.net> <509779AA.6010409@redhat.com> Message-ID: <1361875747.12967.1.camel@arthur.bashnl.ru> And what? Is there any result? I try same thing with my AMM and IPA ? ??., 05/11/2012 ? 09:32 +0100, Petr Spacek ?????: > On 11/03/2012 01:12 PM, Pavel Zhukov wrote: > >> Can you do NS lookup of the IPA server from the AMM box? > > yes > >> Can you do kinit from the AMM box against IPA? > >> Can you do ldapsearch from the AMM box against IPA? > > no, AMM has restricted shell and web GUI. > > Hmm, that is unfortunate. Can you run tcpdump (or sniffer provided on AMM) on > the link between AMM and IPA server? Because there are no records in access > log I will bet on some name resolution or firewall problem. > > Do AMM get right DNS responses (i.e. name and IP address of the IPA server)? > > Do AMM established TCP connection with the IPA server? > > -- > Petr^2 Spacek > > >> Do you see anything in the logs from such activity? > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From kriss.prosst at gmail.com Tue Feb 26 11:00:20 2013 From: kriss.prosst at gmail.com (Kriss Von Prosst) Date: Tue, 26 Feb 2013 12:00:20 +0100 Subject: [Freeipa-users] nsslapd-changelogmaxage In-Reply-To: <512BB340.7090601@redhat.com> References: <512BB340.7090601@redhat.com> Message-ID: ok, but setting nsslapd-changelogmaxage parameter doesnt automatically shrink changelog. The file size dosent change. Other idea how to trim changelog file? 2013/2/25 Rich Megginson > On 02/25/2013 11:33 AM, Kriss Von Prosst wrote: > > Hi, > > I have multimaster replication enviroment, IPA v2.2 on Fedora 17. On > each replica, folder /var/lib/dirsrv/slapd-cosp/cldb/ has big size (~7GB). > This is half of all available space for '/'. I found that changelog file > can be trim using 'nsslapd-changelogmaxage' parameter. By default, this > parameter is not set in dse.ldif (is this correct?). My questions are: > > a) where should I put 'nsslapd-changelogmaxage' parameter, into tree: > cn=Retro Changelog Plugin, cn=config or cn=changelog5,cn=config. > > Not Retro Changelog > > > https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication-Configuring-Replication-cmd.html#Configuring-Replication-Suppliers-cmd > > > > b) what are the consequences when I set this parameter to > nsslapd-changelogmaxage: 10d? > c) Is any other possibility to limit increase of this file? > > There is also the nsslapd-changelogmaxentries parameter > > https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Directory_Server/9.0/html/Configuration_Command_and_File_Reference/Core_Server_Configuration_Reference.html#cnchangelog5 > > > Kriss > > > _______________________________________________ > Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Tue Feb 26 11:41:49 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 26 Feb 2013 12:41:49 +0100 Subject: [Freeipa-users] FreeIPA for AMM users management In-Reply-To: <1361875747.12967.1.camel@arthur.bashnl.ru> References: <20121101042710.GC8238@work.zhukoff.net> <1351799730.18469.138.camel@willson.li.ssimo.org> <1351804185.18469.146.camel@willson.li.ssimo.org> <20121102041246.GB1558@work.zhukoff.net> <5093C424.5010506@redhat.com> <20121103121243.GC1558@work.zhukoff.net> <509779AA.6010409@redhat.com> <1361875747.12967.1.camel@arthur.bashnl.ru> Message-ID: <512C9F7D.9030509@redhat.com> On 26.2.2013 11:49, ????? ????????? wrote: > And what? > Is there any result? I try same thing with my AMM and IPA Unfortunately, we don't have sufficient information to give you any advice. Please, try to provide output from a sniffer as I asked in last reply. Then we will try to help you. (You can send the data to me privately, if you want.) Petr^2 Spacek > ? ??., 05/11/2012 ? 09:32 +0100, Petr Spacek ?????: >> On 11/03/2012 01:12 PM, Pavel Zhukov wrote: >>>> Can you do NS lookup of the IPA server from the AMM box? >>> yes >>>> Can you do kinit from the AMM box against IPA? >>>> Can you do ldapsearch from the AMM box against IPA? >>> no, AMM has restricted shell and web GUI. >> >> Hmm, that is unfortunate. Can you run tcpdump (or sniffer provided on AMM) on >> the link between AMM and IPA server? Because there are no records in access >> log I will bet on some name resolution or firewall problem. >> >> Do AMM get right DNS responses (i.e. name and IP address of the IPA server)? >> >> Do AMM established TCP connection with the IPA server? >> >> -- >> Petr^2 Spacek >> >>>> Do you see anything in the logs from such activity? From pspacek at redhat.com Tue Feb 26 13:39:58 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 26 Feb 2013 14:39:58 +0100 Subject: [Freeipa-users] RHEL 6.4 , IPA 3.0 and bind-chroot In-Reply-To: <51293C2A.9050302@themacartneyclan.com> References: <512900FC.3090608@themacartneyclan.com> <512938F7.40301@redhat.com> <51293C2A.9050302@themacartneyclan.com> Message-ID: <512CBB2E.2070905@redhat.com> On 23.2.2013 23:01, Dale Macartney wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On 02/23/2013 09:47 PM, Dmitri Pal wrote: >> On 02/23/2013 12:48 PM, Dale Macartney wrote: > > > > >> Hi all > >> > >> I've just performed a clean IPA installation and noticed that if you're > >> using integrated DNS, you are still unable to use bind in a chrooted > >> environment with a default IPA install. > >> > >> Basically if its a chrooted environment, named will fail to start. > >> > >> To replicate what I've done, do the following. > >> > >> # yum install ipa-server bind bind-chroot bind-dyndb-ldap -y > >> # ipa-server-install --setup-dns (do your usual thing here) > >> > >> - From what I've been testing, there needs to be quite a few libraries > >> located in the chroot environment. > >> > >> I've done the below to get a little further (I should probably use > >> symbolic links, but for now copying the files is a start). > >> > >> mkdir /var/named/chroot/lib64/ > >> cp /lib64/libldap-2.4.so.2 /var/named/chroot/lib64/ > >> cp /lib64/liblber-2.4.so.2 /var/named/chroot/lib64/ > >> cp /lib64/libplds4.so /var/named/chroot/lib64/ > >> cp /lib64/libplc4.so /var/named/chroot/lib64/ > >> cp /lib64/libnspr4.so /var/named/chroot/lib64/ > >> cp /lib64/libcrypt.so.1 /var/named/chroot/lib64/ > >> cp /lib64/libfreebl3.so /var/named/chroot/lib64/ > >> > >> mkdir /var/named/chroot/usr/lib64/ > >> cp /usr/lib64/libssl3.so /var/named/chroot/usr/lib64/ > >> cp /usr/lib64/libsmime3.so /var/named/chroot/usr/lib64/ > >> cp /usr/lib64/libnss3.so /var/named/chroot/usr/lib64/ > >> cp /usr/lib64/libnssutil3.so /var/named/chroot/usr/lib64/ > >> cp /usr/lib64/libsasl2.so.2 /var/named/chroot/usr/lib64/ > >> > >> > >> > >> Now when I restart named, I get the below error in /var/log/messages. > >> > >> Does anyone have any ideas of the best way to get around this error? > >> > >> Feb 23 17:35:29 ds01 named[2425]: Failed to parse the principal name > >> DNS/ds01.example.com (Configuration file does not specify default realm) > > > > It should be > > DNS/ds01.example.com at YOURREALMNAME.SOMETHING > oh of course.. what a face palm moment. > > Where does the default ipa installation put the DNS keytab file? I did notice > an /etc/named.keytab was present, but placing that in /var/named/chroot/etc > didn't seem to improve matters. I wrote short how-to: http://freeipa.org/page/Howto/FreeIPA_with_integrated_BIND_inside_chroot In my RHEL 6.4 test environment it worked, but it is a bit "hackish". Any improvements are welcome! > > I do not know the exact reason but it might be that bind ldap driver can't > locate its kerberos configuration. > > I hope it will give you a hint and unblock you before the real masters of > DNS chime in. i > I know this has been a rather long lasting rfe/bug/how ever you want to label it. > https://fedorahosted.org/freeipa/ticket/126 > > If I make any progress I'll let the team know. -- Petr^2 Spacek From rmeggins at redhat.com Tue Feb 26 14:17:23 2013 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 26 Feb 2013 07:17:23 -0700 Subject: [Freeipa-users] nsslapd-changelogmaxage In-Reply-To: References: <512BB340.7090601@redhat.com> Message-ID: <512CC3F3.9040103@redhat.com> On 02/26/2013 04:00 AM, Kriss Von Prosst wrote: > ok, but setting nsslapd-changelogmaxage parameter doesnt automatically > shrink changelog. The file size dosent change. Other idea how to trim > changelog file? I don't know. Looks like you have found a bug. > > > 2013/2/25 Rich Megginson > > > On 02/25/2013 11:33 AM, Kriss Von Prosst wrote: >> Hi, >> >> I have multimaster replication enviroment, IPA v2.2 on Fedora 17. >> On each replica, folder /var/lib/dirsrv/slapd-cosp/cldb/ has big >> size (~7GB). This is half of all available space for '/'. I >> found that changelog file can be trim using >> 'nsslapd-changelogmaxage' parameter. By default, this parameter >> is not set in dse.ldif (is this correct?). My questions are: >> >> a) where should I put 'nsslapd-changelogmaxage' parameter, into >> tree: cn=Retro Changelog Plugin, cn=config or >> cn=changelog5,cn=config. > Not Retro Changelog > > https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication-Configuring-Replication-cmd.html#Configuring-Replication-Suppliers-cmd > > > > >> b) what are the consequences when I set this parameter to >> nsslapd-changelogmaxage: 10d? >> c) Is any other possibility to limit increase of this file? > There is also the nsslapd-changelogmaxentries parameter > https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Directory_Server/9.0/html/Configuration_Command_and_File_Reference/Core_Server_Configuration_Reference.html#cnchangelog5 >> >> Kriss >> >> >> _______________________________________________ >> 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 Feb 26 15:29:39 2013 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 26 Feb 2013 10:29:39 -0500 Subject: [Freeipa-users] Upgrading to 6.4 - additional information In-Reply-To: <512659EA.5060808@redhat.com> References: <5126443D.60806@gmail.com> <51264639.6000005@redhat.com> <51264B6B.9030109@gmail.com> <51264C83.50703@redhat.com> <51264D8E.70604@gmail.com> <51264DED.6010000@redhat.com> <51264EF0.6070905@gmail.com> <512659EA.5060808@redhat.com> Message-ID: <512CD4E3.9080306@redhat.com> On 02/21/2013 12:31 PM, Dmitri Pal wrote: > On 02/21/2013 11:44 AM, Erinn Looney-Triggs wrote: >> On 02/21/2013 09:40 AM, Rob Crittenden wrote: >>> Erinn Looney-Triggs wrote: >>>> On 02/21/2013 09:34 AM, Rob Crittenden wrote: >>>>> Erinn Looney-Triggs wrote: >>>>>> On 02/21/2013 09:07 AM, Rob Crittenden wrote: >>>>>>> add:attributeTypes: (2.16.840.1.113730.3.8.11.1 NAME >>>>>>> 'ipaExternalMember' >>>>>>> DESC 'External Group Member Identifier' EQUALITY caseIgnoreMatch >>>>>>> ORDERING caseIgnoreOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 >>>>>>> X-ORIGIN 'IPA v3' ) >>>>>>> add:objectClasses: (2.16.840.1.113730.3.8.12.1 NAME 'ipaExternalGroup' >>>>>>> SUP top STRUCTURAL MUST ( cn ) MAY ( ipaExternalMember $$ memberOf $$ >>>>>>> description $$ owner) X-ORIGIN 'IPA v3' ) >>>>>> Well that fails as well, though in sort of a self inflicted way: >>>>>> >>>>>> 2013-02-21T16:24:30Z INFO The ipa-ldap-updater command failed, >>>>>> exception: DatabaseError: Server is unwilling to perform: Minimum SSF >>>>>> not met. arguments: base="cn=config,cn=ldbm >>>>>> database,cn=plugins,cn=config", scope=0, filterstr="(objectclass=*)" >>>>>> 2013-02-21T16:24:30Z ERROR Unexpected error - see >>>>>> /var/log/ipaupgrade.log for details: >>>>>> DatabaseError: Server is unwilling to perform: Minimum SSF not met. >>>>>> arguments: base="cn=config,cn=ldbm database,cn=plugins,cn=config", >>>>>> scope=0, filterstr="(objectclass=*)" >>>>>> >>>>>> >>>>>> Now this probably comes about because I set: >>>>>> nsslapd-minssf: 56 >>>>>> For security. >>>>>> >>>>>> I can cange that back to the default and probably move past this, >>>>>> but is >>>>>> that a known issue? Is there another way around? >>>>> As root try the --ldapi flag: >>>>> >>>>> # ipa-ldap-updater --ldapi /path/to/scheme.update >>>>> >>>>> rob >>>>> >>>> ERROR: LDAPUpdate: syntax error: >>>> dn is not defined in the update, data source=schema.update >>>> >>>> -Erinn >>>> >>> Sorry, add this to the top of your update file: >>> >>> dn: cn=schema >>> >>> rob >> No worries! Thanks for the help, after a restart of IPA the web UI is >> working again. I reckon this is something that needs to be fixed, does >> opening a support case and pointing them to that bug help you folks out >> with this in any way? > > This is a know defect. We just did not realize it would have such a > bad impact on upgrade. > Sorry, the errata is on the way. > > I would recommend everyone to not upgrade to 6.4 until the errata is > shipped. > We will notify you as soon as it goes out. > > Sorry again. > We did some research of this issue: 1) The upgrade works fine from 6.3 to 6.4 and the issue does not exhibit itself 2) We have been able to reproduce it with the direct upgrade from 6.2 to 6.4 3) Since the expected upgrade part is 6.2 -> 6.3 -> 6.4 the question comes up whether this fix is actually that urgent. 4) In the presence of the simple workaround we feel that it is not that important to include this fix into the errata that we are working on. Please let us know if you think that there is a problem with the plan above. >> -Erinn >> >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Tue Feb 26 15:48:16 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 26 Feb 2013 16:48:16 +0100 Subject: [Freeipa-users] Upgrading to 6.4 - additional information In-Reply-To: <512CD4E3.9080306@redhat.com> References: <5126443D.60806@gmail.com> <51264639.6000005@redhat.com> <51264B6B.9030109@gmail.com> <51264C83.50703@redhat.com> <51264D8E.70604@gmail.com> <51264DED.6010000@redhat.com> <51264EF0.6070905@gmail.com> <512659EA.5060808@redhat.com> <512CD4E3.9080306@redhat.com> Message-ID: <512CD940.9020706@redhat.com> On 02/26/2013 04:29 PM, Dmitri Pal wrote: > On 02/21/2013 12:31 PM, Dmitri Pal wrote: >> On 02/21/2013 11:44 AM, Erinn Looney-Triggs wrote: >>> On 02/21/2013 09:40 AM, Rob Crittenden wrote: >>>> Erinn Looney-Triggs wrote: >>>>> On 02/21/2013 09:34 AM, Rob Crittenden wrote: >>>>>> Erinn Looney-Triggs wrote: >>>>>>> On 02/21/2013 09:07 AM, Rob Crittenden wrote: >>>>>>>> add:attributeTypes: (2.16.840.1.113730.3.8.11.1 NAME >>>>>>>> 'ipaExternalMember' >>>>>>>> DESC 'External Group Member Identifier' EQUALITY caseIgnoreMatch >>>>>>>> ORDERING caseIgnoreOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 >>>>>>>> X-ORIGIN 'IPA v3' ) >>>>>>>> add:objectClasses: (2.16.840.1.113730.3.8.12.1 NAME 'ipaExternalGroup' >>>>>>>> SUP top STRUCTURAL MUST ( cn ) MAY ( ipaExternalMember $$ memberOf $$ >>>>>>>> description $$ owner) X-ORIGIN 'IPA v3' ) >>>>>>> Well that fails as well, though in sort of a self inflicted way: >>>>>>> >>>>>>> 2013-02-21T16:24:30Z INFO The ipa-ldap-updater command failed, >>>>>>> exception: DatabaseError: Server is unwilling to perform: Minimum SSF >>>>>>> not met. arguments: base="cn=config,cn=ldbm >>>>>>> database,cn=plugins,cn=config", scope=0, filterstr="(objectclass=*)" >>>>>>> 2013-02-21T16:24:30Z ERROR Unexpected error - see >>>>>>> /var/log/ipaupgrade.log for details: >>>>>>> DatabaseError: Server is unwilling to perform: Minimum SSF not met. >>>>>>> arguments: base="cn=config,cn=ldbm database,cn=plugins,cn=config", >>>>>>> scope=0, filterstr="(objectclass=*)" >>>>>>> >>>>>>> >>>>>>> Now this probably comes about because I set: >>>>>>> nsslapd-minssf: 56 >>>>>>> For security. >>>>>>> >>>>>>> I can cange that back to the default and probably move past this, >>>>>>> but is >>>>>>> that a known issue? Is there another way around? >>>>>> As root try the --ldapi flag: >>>>>> >>>>>> # ipa-ldap-updater --ldapi /path/to/scheme.update >>>>>> >>>>>> rob >>>>>> >>>>> ERROR: LDAPUpdate: syntax error: >>>>> dn is not defined in the update, data source=schema.update >>>>> >>>>> -Erinn >>>>> >>>> Sorry, add this to the top of your update file: >>>> >>>> dn: cn=schema >>>> >>>> rob >>> No worries! Thanks for the help, after a restart of IPA the web UI is >>> working again. I reckon this is something that needs to be fixed, does >>> opening a support case and pointing them to that bug help you folks out >>> with this in any way? >> >> This is a know defect. We just did not realize it would have such a bad >> impact on upgrade. >> Sorry, the errata is on the way. >> >> I would recommend everyone to not upgrade to 6.4 until the errata is shipped. >> We will notify you as soon as it goes out. >> >> Sorry again. >> > I would like to clarify the impact, we have found out it is broader than currently stated: > We did some research of this issue: > 1) The upgrade works fine from 6.3 to 6.4 and the issue does not exhibit itself > 2) We have been able to reproduce it with the direct upgrade from 6.2 to 6.4 > 3) Since the expected upgrade part is 6.2 -> 6.3 -> 6.4 the question comes up > whether this fix is actually that urgent. This issue also affects both upgrade paths (6.2 -> 6.4 and 6.2 -> 6.3 -> 6.4). This makes the fix urgent and it should be fixed in 6.4 too. Martin From john.moyer at digitalreasoning.com Tue Feb 26 16:55:10 2013 From: john.moyer at digitalreasoning.com (John Moyer) Date: Tue, 26 Feb 2013 11:55:10 -0500 Subject: [Freeipa-users] Cannot obtain CA Certificate In-Reply-To: <20130219113502.GA21948@dibs.tanso.net> References: <80D02259-925A-4529-943F-0ACAD7B77BB3@digitalreasoning.com> <20130219113502.GA21948@dibs.tanso.net> Message-ID: <9E4ACCDE-A5BF-4A1D-BFEA-6B8090D27B21@digitalreasoning.com> Sorry for the late response, so I tried this, and it changed the error to the following: Synchronizing time with KDC... Joining realm failed: HTTP response code is 401, not 200 Installation failed. Rolling back changes. Looking at debug this is what I see: < HTTP/1.1 401 Authorization Required < Date: Tue, 26 Feb 2013 16:54:21 GMT < Server: Apache/2.2.15 (CentOS) * gss_init_sec_context() failed: : Server krbtgt/COM at EXAMPLE.COM not found in Kerberos database< WWW-Authenticate: Negotiate < Last-Modified: Wed, 23 Jan 2013 22:16:50 GMT < ETag: "4627-740-4d3fc0cfd7880" < Accept-Ranges: bytes < Content-Length: 1856 < Connection: close < Content-Type: text/html; charset=UTF-8 Thanks, _____________________________________________________ John Moyer On Feb 19, 2013, at 6:35 AM, Jan-Frode Myklebust wrote: >> ipa : ERROR Cannot obtain CA certificate >> 'ldap://ipa1.example.com' doesn't have a certificate. >> Installation failed. Rolling back changes. >> IPA client is not configured on this system. > > FYI, I have this same issue when enrolling RHEL5 clients. Have been > doing this as a workaround: > > wget -O /etc/ipa/ca.crt http://ipa1.example.com/ipa/config/ca.crt > ipa-client-install --no-ntp --mkhomedir --ca-cert-file=/etc/ipa/ca.crt > > > > -jf From erinn.looneytriggs at gmail.com Tue Feb 26 17:05:25 2013 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Tue, 26 Feb 2013 12:05:25 -0500 Subject: [Freeipa-users] Upgrading to 6.4 - additional information In-Reply-To: <512CD4E3.9080306@redhat.com> References: <5126443D.60806@gmail.com> <51264639.6000005@redhat.com> <51264B6B.9030109@gmail.com> <51264C83.50703@redhat.com> <51264D8E.70604@gmail.com> <51264DED.6010000@redhat.com> <51264EF0.6070905@gmail.com> <512659EA.5060808@redhat.com> <512CD4E3.9080306@redhat.com> Message-ID: <512CEB55.3020205@gmail.com> On 02/26/2013 10:29 AM, Dmitri Pal wrote: > On 02/21/2013 12:31 PM, Dmitri Pal wrote: >> On 02/21/2013 11:44 AM, Erinn Looney-Triggs wrote: >>> On 02/21/2013 09:40 AM, Rob Crittenden wrote: >>>> Erinn Looney-Triggs wrote: >>>>> On 02/21/2013 09:34 AM, Rob Crittenden wrote: >>>>>> Erinn Looney-Triggs wrote: >>>>>>> On 02/21/2013 09:07 AM, Rob Crittenden wrote: >>>>>>>> add:attributeTypes: (2.16.840.1.113730.3.8.11.1 NAME >>>>>>>> 'ipaExternalMember' >>>>>>>> DESC 'External Group Member Identifier' EQUALITY caseIgnoreMatch >>>>>>>> ORDERING caseIgnoreOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 >>>>>>>> X-ORIGIN 'IPA v3' ) >>>>>>>> add:objectClasses: (2.16.840.1.113730.3.8.12.1 NAME 'ipaExternalGroup' >>>>>>>> SUP top STRUCTURAL MUST ( cn ) MAY ( ipaExternalMember $$ memberOf $$ >>>>>>>> description $$ owner) X-ORIGIN 'IPA v3' ) >>>>>>> Well that fails as well, though in sort of a self inflicted way: >>>>>>> >>>>>>> 2013-02-21T16:24:30Z INFO The ipa-ldap-updater command failed, >>>>>>> exception: DatabaseError: Server is unwilling to perform: Minimum SSF >>>>>>> not met. arguments: base="cn=config,cn=ldbm >>>>>>> database,cn=plugins,cn=config", scope=0, filterstr="(objectclass=*)" >>>>>>> 2013-02-21T16:24:30Z ERROR Unexpected error - see >>>>>>> /var/log/ipaupgrade.log for details: >>>>>>> DatabaseError: Server is unwilling to perform: Minimum SSF not met. >>>>>>> arguments: base="cn=config,cn=ldbm database,cn=plugins,cn=config", >>>>>>> scope=0, filterstr="(objectclass=*)" >>>>>>> >>>>>>> >>>>>>> Now this probably comes about because I set: >>>>>>> nsslapd-minssf: 56 >>>>>>> For security. >>>>>>> >>>>>>> I can cange that back to the default and probably move past this, >>>>>>> but is >>>>>>> that a known issue? Is there another way around? >>>>>> As root try the --ldapi flag: >>>>>> >>>>>> # ipa-ldap-updater --ldapi /path/to/scheme.update >>>>>> >>>>>> rob >>>>>> >>>>> ERROR: LDAPUpdate: syntax error: >>>>> dn is not defined in the update, data source=schema.update >>>>> >>>>> -Erinn >>>>> >>>> Sorry, add this to the top of your update file: >>>> >>>> dn: cn=schema >>>> >>>> rob >>> No worries! Thanks for the help, after a restart of IPA the web UI is >>> working again. I reckon this is something that needs to be fixed, does >>> opening a support case and pointing them to that bug help you folks out >>> with this in any way? >> >> This is a know defect. We just did not realize it would have such a >> bad impact on upgrade. >> Sorry, the errata is on the way. >> >> I would recommend everyone to not upgrade to 6.4 until the errata is >> shipped. >> We will notify you as soon as it goes out. >> >> Sorry again. >> > > We did some research of this issue: > 1) The upgrade works fine from 6.3 to 6.4 and the issue does not exhibit > itself > 2) We have been able to reproduce it with the direct upgrade from 6.2 to 6.4 > 3) Since the expected upgrade part is 6.2 -> 6.3 -> 6.4 the question > comes up whether this fix is actually that urgent. > 4) In the presence of the simple workaround we feel that it is not that > important to include this fix into the errata that we are working on. > > Please let us know if you think that there is a problem with the plan above. > > Well all I can tell you on this, is that mine was an upgrade from 6.3 to 6.4, so there is a case where it will fail going from 6.3 to 6.4, but how applicable it is I can't say. Otherwise, sure, sounds great to me. -Erin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 555 bytes Desc: OpenPGP digital signature URL: From mkosek at redhat.com Tue Feb 26 17:08:59 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 26 Feb 2013 18:08:59 +0100 Subject: [Freeipa-users] Upgrading to 6.4 - additional information In-Reply-To: <512CEB55.3020205@gmail.com> References: <5126443D.60806@gmail.com> <51264639.6000005@redhat.com> <51264B6B.9030109@gmail.com> <51264C83.50703@redhat.com> <51264D8E.70604@gmail.com> <51264DED.6010000@redhat.com> <51264EF0.6070905@gmail.com> <512659EA.5060808@redhat.com> <512CD4E3.9080306@redhat.com> <512CEB55.3020205@gmail.com> Message-ID: <512CEC2B.1050804@redhat.com> On 02/26/2013 06:05 PM, Erinn Looney-Triggs wrote: > On 02/26/2013 10:29 AM, Dmitri Pal wrote: >> On 02/21/2013 12:31 PM, Dmitri Pal wrote: >>> On 02/21/2013 11:44 AM, Erinn Looney-Triggs wrote: >>>> On 02/21/2013 09:40 AM, Rob Crittenden wrote: >>>>> Erinn Looney-Triggs wrote: >>>>>> On 02/21/2013 09:34 AM, Rob Crittenden wrote: >>>>>>> Erinn Looney-Triggs wrote: >>>>>>>> On 02/21/2013 09:07 AM, Rob Crittenden wrote: >>>>>>>>> add:attributeTypes: (2.16.840.1.113730.3.8.11.1 NAME >>>>>>>>> 'ipaExternalMember' DESC 'External Group Member >>>>>>>>> Identifier' EQUALITY caseIgnoreMatch ORDERING >>>>>>>>> caseIgnoreOrderingMatch SYNTAX >>>>>>>>> 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'IPA v3' ) >>>>>>>>> add:objectClasses: (2.16.840.1.113730.3.8.12.1 NAME >>>>>>>>> 'ipaExternalGroup' SUP top STRUCTURAL MUST ( cn ) MAY ( >>>>>>>>> ipaExternalMember $$ memberOf $$ description $$ owner) >>>>>>>>> X-ORIGIN 'IPA v3' ) >>>>>>>> Well that fails as well, though in sort of a self inflicted >>>>>>>> way: >>>>>>>> >>>>>>>> 2013-02-21T16:24:30Z INFO The ipa-ldap-updater command >>>>>>>> failed, exception: DatabaseError: Server is unwilling to >>>>>>>> perform: Minimum SSF not met. arguments: >>>>>>>> base="cn=config,cn=ldbm database,cn=plugins,cn=config", >>>>>>>> scope=0, filterstr="(objectclass=*)" 2013-02-21T16:24:30Z >>>>>>>> ERROR Unexpected error - see /var/log/ipaupgrade.log for >>>>>>>> details: DatabaseError: Server is unwilling to perform: >>>>>>>> Minimum SSF not met. arguments: base="cn=config,cn=ldbm >>>>>>>> database,cn=plugins,cn=config", scope=0, >>>>>>>> filterstr="(objectclass=*)" >>>>>>>> >>>>>>>> >>>>>>>> Now this probably comes about because I set: nsslapd-minssf: >>>>>>>> 56 For security. >>>>>>>> >>>>>>>> I can cange that back to the default and probably move past >>>>>>>> this, but is that a known issue? Is there another way >>>>>>>> around? >>>>>>> As root try the --ldapi flag: >>>>>>> >>>>>>> # ipa-ldap-updater --ldapi /path/to/scheme.update >>>>>>> >>>>>>> rob >>>>>>> >>>>>> ERROR: LDAPUpdate: syntax error: dn is not defined in the >>>>>> update, data source=schema.update >>>>>> >>>>>> -Erinn >>>>>> >>>>> Sorry, add this to the top of your update file: >>>>> >>>>> dn: cn=schema >>>>> >>>>> rob >>>> No worries! Thanks for the help, after a restart of IPA the web UI >>>> is working again. I reckon this is something that needs to be fixed, >>>> does opening a support case and pointing them to that bug help you >>>> folks out with this in any way? >>> >>> This is a know defect. We just did not realize it would have such a >>> bad impact on upgrade. Sorry, the errata is on the way. >>> >>> I would recommend everyone to not upgrade to 6.4 until the errata is >>> shipped. We will notify you as soon as it goes out. >>> >>> Sorry again. >>> >> >> We did some research of this issue: 1) The upgrade works fine from 6.3 >> to 6.4 and the issue does not exhibit itself 2) We have been able to >> reproduce it with the direct upgrade from 6.2 to 6.4 3) Since the >> expected upgrade part is 6.2 -> 6.3 -> 6.4 the question comes up whether >> this fix is actually that urgent. 4) In the presence of the simple >> workaround we feel that it is not that important to include this fix >> into the errata that we are working on. >> >> Please let us know if you think that there is a problem with the plan >> above. >> >> > > Well all I can tell you on this, is that mine was an upgrade from 6.3 to > 6.4, so there is a case where it will fail going from 6.3 to 6.4, but how > applicable it is I can't say. Hi Erinn, Is 6.3 the original RHEL version where IPA server was installed? Or was IPA installed on RHEL-6.2 and then you upgraded RHEL to 6.3? Thank you, Martin From erinn.looneytriggs at gmail.com Tue Feb 26 17:10:33 2013 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Tue, 26 Feb 2013 12:10:33 -0500 Subject: [Freeipa-users] Upgrading to 6.4 - additional information In-Reply-To: <512CEC2B.1050804@redhat.com> References: <5126443D.60806@gmail.com> <51264639.6000005@redhat.com> <51264B6B.9030109@gmail.com> <51264C83.50703@redhat.com> <51264D8E.70604@gmail.com> <51264DED.6010000@redhat.com> <51264EF0.6070905@gmail.com> <512659EA.5060808@redhat.com> <512CD4E3.9080306@redhat.com> <512CEB55.3020205@gmail.com> <512CEC2B.1050804@redhat.com> Message-ID: <512CEC89.2050706@gmail.com> On 02/26/2013 12:08 PM, Martin Kosek wrote: > On 02/26/2013 06:05 PM, Erinn Looney-Triggs wrote: >> On 02/26/2013 10:29 AM, Dmitri Pal wrote: >>> On 02/21/2013 12:31 PM, Dmitri Pal wrote: >>>> On 02/21/2013 11:44 AM, Erinn Looney-Triggs wrote: >>>>> On 02/21/2013 09:40 AM, Rob Crittenden wrote: >>>>>> Erinn Looney-Triggs wrote: >>>>>>> On 02/21/2013 09:34 AM, Rob Crittenden wrote: >>>>>>>> Erinn Looney-Triggs wrote: >>>>>>>>> On 02/21/2013 09:07 AM, Rob Crittenden wrote: >>>>>>>>>> add:attributeTypes: (2.16.840.1.113730.3.8.11.1 NAME >>>>>>>>>> 'ipaExternalMember' DESC 'External Group Member >>>>>>>>>> Identifier' EQUALITY caseIgnoreMatch ORDERING >>>>>>>>>> caseIgnoreOrderingMatch SYNTAX >>>>>>>>>> 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'IPA v3' ) >>>>>>>>>> add:objectClasses: (2.16.840.1.113730.3.8.12.1 NAME >>>>>>>>>> 'ipaExternalGroup' SUP top STRUCTURAL MUST ( cn ) MAY ( >>>>>>>>>> ipaExternalMember $$ memberOf $$ description $$ owner) >>>>>>>>>> X-ORIGIN 'IPA v3' ) >>>>>>>>> Well that fails as well, though in sort of a self inflicted >>>>>>>>> way: >>>>>>>>> >>>>>>>>> 2013-02-21T16:24:30Z INFO The ipa-ldap-updater command >>>>>>>>> failed, exception: DatabaseError: Server is unwilling to >>>>>>>>> perform: Minimum SSF not met. arguments: >>>>>>>>> base="cn=config,cn=ldbm database,cn=plugins,cn=config", >>>>>>>>> scope=0, filterstr="(objectclass=*)" 2013-02-21T16:24:30Z >>>>>>>>> ERROR Unexpected error - see /var/log/ipaupgrade.log for >>>>>>>>> details: DatabaseError: Server is unwilling to perform: >>>>>>>>> Minimum SSF not met. arguments: base="cn=config,cn=ldbm >>>>>>>>> database,cn=plugins,cn=config", scope=0, >>>>>>>>> filterstr="(objectclass=*)" >>>>>>>>> >>>>>>>>> >>>>>>>>> Now this probably comes about because I set: nsslapd-minssf: >>>>>>>>> 56 For security. >>>>>>>>> >>>>>>>>> I can cange that back to the default and probably move past >>>>>>>>> this, but is that a known issue? Is there another way >>>>>>>>> around? >>>>>>>> As root try the --ldapi flag: >>>>>>>> >>>>>>>> # ipa-ldap-updater --ldapi /path/to/scheme.update >>>>>>>> >>>>>>>> rob >>>>>>>> >>>>>>> ERROR: LDAPUpdate: syntax error: dn is not defined in the >>>>>>> update, data source=schema.update >>>>>>> >>>>>>> -Erinn >>>>>>> >>>>>> Sorry, add this to the top of your update file: >>>>>> >>>>>> dn: cn=schema >>>>>> >>>>>> rob >>>>> No worries! Thanks for the help, after a restart of IPA the web UI >>>>> is working again. I reckon this is something that needs to be fixed, >>>>> does opening a support case and pointing them to that bug help you >>>>> folks out with this in any way? >>>> >>>> This is a know defect. We just did not realize it would have such a >>>> bad impact on upgrade. Sorry, the errata is on the way. >>>> >>>> I would recommend everyone to not upgrade to 6.4 until the errata is >>>> shipped. We will notify you as soon as it goes out. >>>> >>>> Sorry again. >>>> >>> >>> We did some research of this issue: 1) The upgrade works fine from 6.3 >>> to 6.4 and the issue does not exhibit itself 2) We have been able to >>> reproduce it with the direct upgrade from 6.2 to 6.4 3) Since the >>> expected upgrade part is 6.2 -> 6.3 -> 6.4 the question comes up whether >>> this fix is actually that urgent. 4) In the presence of the simple >>> workaround we feel that it is not that important to include this fix >>> into the errata that we are working on. >>> >>> Please let us know if you think that there is a problem with the plan >>> above. >>> >>> >> >> Well all I can tell you on this, is that mine was an upgrade from 6.3 to >> 6.4, so there is a case where it will fail going from 6.3 to 6.4, but how >> applicable it is I can't say. > > Hi Erinn, > > Is 6.3 the original RHEL version where IPA server was installed? Or was IPA > installed on RHEL-6.2 and then you upgraded RHEL to 6.3? > > Thank you, > Martin > These systems have gone through all the point releases from 6 on up I believe. -Erinn -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 555 bytes Desc: OpenPGP digital signature URL: From mkosek at redhat.com Tue Feb 26 18:05:23 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 26 Feb 2013 19:05:23 +0100 Subject: [Freeipa-users] Upgrading to 6.4 - additional information In-Reply-To: <512CEC89.2050706@gmail.com> References: <5126443D.60806@gmail.com> <51264639.6000005@redhat.com> <51264B6B.9030109@gmail.com> <51264C83.50703@redhat.com> <51264D8E.70604@gmail.com> <51264DED.6010000@redhat.com> <51264EF0.6070905@gmail.com> <512659EA.5060808@redhat.com> <512CD4E3.9080306@redhat.com> <512CEB55.3020205@gmail.com> <512CEC2B.1050804@redhat.com> <512CEC89.2050706@gmail.com> Message-ID: <512CF963.2080809@redhat.com> On 02/26/2013 06:10 PM, Erinn Looney-Triggs wrote: > On 02/26/2013 12:08 PM, Martin Kosek wrote: >> On 02/26/2013 06:05 PM, Erinn Looney-Triggs wrote: >>> On 02/26/2013 10:29 AM, Dmitri Pal wrote: >>>> On 02/21/2013 12:31 PM, Dmitri Pal wrote: >>>>> On 02/21/2013 11:44 AM, Erinn Looney-Triggs wrote: >>>>>> On 02/21/2013 09:40 AM, Rob Crittenden wrote: >>>>>>> Erinn Looney-Triggs wrote: >>>>>>>> On 02/21/2013 09:34 AM, Rob Crittenden wrote: >>>>>>>>> Erinn Looney-Triggs wrote: >>>>>>>>>> On 02/21/2013 09:07 AM, Rob Crittenden wrote: >>>>>>>>>>> add:attributeTypes: (2.16.840.1.113730.3.8.11.1 NAME >>>>>>>>>>> 'ipaExternalMember' DESC 'External Group Member >>>>>>>>>>> Identifier' EQUALITY caseIgnoreMatch ORDERING >>>>>>>>>>> caseIgnoreOrderingMatch SYNTAX >>>>>>>>>>> 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'IPA v3' ) >>>>>>>>>>> add:objectClasses: (2.16.840.1.113730.3.8.12.1 NAME >>>>>>>>>>> 'ipaExternalGroup' SUP top STRUCTURAL MUST ( cn ) MAY ( >>>>>>>>>>> ipaExternalMember $$ memberOf $$ description $$ owner) >>>>>>>>>>> X-ORIGIN 'IPA v3' ) >>>>>>>>>> Well that fails as well, though in sort of a self inflicted >>>>>>>>>> way: >>>>>>>>>> >>>>>>>>>> 2013-02-21T16:24:30Z INFO The ipa-ldap-updater command >>>>>>>>>> failed, exception: DatabaseError: Server is unwilling to >>>>>>>>>> perform: Minimum SSF not met. arguments: >>>>>>>>>> base="cn=config,cn=ldbm database,cn=plugins,cn=config", >>>>>>>>>> scope=0, filterstr="(objectclass=*)" 2013-02-21T16:24:30Z >>>>>>>>>> ERROR Unexpected error - see /var/log/ipaupgrade.log for >>>>>>>>>> details: DatabaseError: Server is unwilling to perform: >>>>>>>>>> Minimum SSF not met. arguments: base="cn=config,cn=ldbm >>>>>>>>>> database,cn=plugins,cn=config", scope=0, >>>>>>>>>> filterstr="(objectclass=*)" >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Now this probably comes about because I set: nsslapd-minssf: >>>>>>>>>> 56 For security. >>>>>>>>>> >>>>>>>>>> I can cange that back to the default and probably move past >>>>>>>>>> this, but is that a known issue? Is there another way >>>>>>>>>> around? >>>>>>>>> As root try the --ldapi flag: >>>>>>>>> >>>>>>>>> # ipa-ldap-updater --ldapi /path/to/scheme.update >>>>>>>>> >>>>>>>>> rob >>>>>>>>> >>>>>>>> ERROR: LDAPUpdate: syntax error: dn is not defined in the >>>>>>>> update, data source=schema.update >>>>>>>> >>>>>>>> -Erinn >>>>>>>> >>>>>>> Sorry, add this to the top of your update file: >>>>>>> >>>>>>> dn: cn=schema >>>>>>> >>>>>>> rob >>>>>> No worries! Thanks for the help, after a restart of IPA the web UI >>>>>> is working again. I reckon this is something that needs to be fixed, >>>>>> does opening a support case and pointing them to that bug help you >>>>>> folks out with this in any way? >>>>> >>>>> This is a know defect. We just did not realize it would have such a >>>>> bad impact on upgrade. Sorry, the errata is on the way. >>>>> >>>>> I would recommend everyone to not upgrade to 6.4 until the errata is >>>>> shipped. We will notify you as soon as it goes out. >>>>> >>>>> Sorry again. >>>>> >>>> >>>> We did some research of this issue: 1) The upgrade works fine from 6.3 >>>> to 6.4 and the issue does not exhibit itself 2) We have been able to >>>> reproduce it with the direct upgrade from 6.2 to 6.4 3) Since the >>>> expected upgrade part is 6.2 -> 6.3 -> 6.4 the question comes up whether >>>> this fix is actually that urgent. 4) In the presence of the simple >>>> workaround we feel that it is not that important to include this fix >>>> into the errata that we are working on. >>>> >>>> Please let us know if you think that there is a problem with the plan >>>> above. >>>> >>>> >>> >>> Well all I can tell you on this, is that mine was an upgrade from 6.3 to >>> 6.4, so there is a case where it will fail going from 6.3 to 6.4, but how >>> applicable it is I can't say. >> >> Hi Erinn, >> >> Is 6.3 the original RHEL version where IPA server was installed? Or was IPA >> installed on RHEL-6.2 and then you upgraded RHEL to 6.3? >> >> Thank you, >> Martin >> > > These systems have gone through all the point releases from 6 on up I > believe. > > -Erinn > Ok, then this use case is also covered by the upcoming 6.4 fix. I just wanted to check that. Thanks, Martin From erinn.looneytriggs at gmail.com Tue Feb 26 18:13:31 2013 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Tue, 26 Feb 2013 13:13:31 -0500 Subject: [Freeipa-users] Upgrading to 6.4 - additional information In-Reply-To: <512CF963.2080809@redhat.com> References: <5126443D.60806@gmail.com> <51264639.6000005@redhat.com> <51264B6B.9030109@gmail.com> <51264C83.50703@redhat.com> <51264D8E.70604@gmail.com> <51264DED.6010000@redhat.com> <51264EF0.6070905@gmail.com> <512659EA.5060808@redhat.com> <512CD4E3.9080306@redhat.com> <512CEB55.3020205@gmail.com> <512CEC2B.1050804@redhat.com> <512CEC89.2050706@gmail.com> <512CF963.2080809@redhat.com> Message-ID: <512CFB4B.1070500@gmail.com> On 02/26/2013 01:05 PM, Martin Kosek wrote: > On 02/26/2013 06:10 PM, Erinn Looney-Triggs wrote: >> On 02/26/2013 12:08 PM, Martin Kosek wrote: >>> On 02/26/2013 06:05 PM, Erinn Looney-Triggs wrote: >>>> On 02/26/2013 10:29 AM, Dmitri Pal wrote: >>>>> On 02/21/2013 12:31 PM, Dmitri Pal wrote: >>>>>> On 02/21/2013 11:44 AM, Erinn Looney-Triggs wrote: >>>>>>> On 02/21/2013 09:40 AM, Rob Crittenden wrote: >>>>>>>> Erinn Looney-Triggs wrote: >>>>>>>>> On 02/21/2013 09:34 AM, Rob Crittenden wrote: >>>>>>>>>> Erinn Looney-Triggs wrote: >>>>>>>>>>> On 02/21/2013 09:07 AM, Rob Crittenden wrote: >>>>>>>>>>>> add:attributeTypes: (2.16.840.1.113730.3.8.11.1 NAME >>>>>>>>>>>> 'ipaExternalMember' DESC 'External Group Member >>>>>>>>>>>> Identifier' EQUALITY caseIgnoreMatch ORDERING >>>>>>>>>>>> caseIgnoreOrderingMatch SYNTAX >>>>>>>>>>>> 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'IPA v3' ) >>>>>>>>>>>> add:objectClasses: (2.16.840.1.113730.3.8.12.1 NAME >>>>>>>>>>>> 'ipaExternalGroup' SUP top STRUCTURAL MUST ( cn ) MAY ( >>>>>>>>>>>> ipaExternalMember $$ memberOf $$ description $$ owner) >>>>>>>>>>>> X-ORIGIN 'IPA v3' ) >>>>>>>>>>> Well that fails as well, though in sort of a self inflicted >>>>>>>>>>> way: >>>>>>>>>>> >>>>>>>>>>> 2013-02-21T16:24:30Z INFO The ipa-ldap-updater command >>>>>>>>>>> failed, exception: DatabaseError: Server is unwilling to >>>>>>>>>>> perform: Minimum SSF not met. arguments: >>>>>>>>>>> base="cn=config,cn=ldbm database,cn=plugins,cn=config", >>>>>>>>>>> scope=0, filterstr="(objectclass=*)" 2013-02-21T16:24:30Z >>>>>>>>>>> ERROR Unexpected error - see /var/log/ipaupgrade.log for >>>>>>>>>>> details: DatabaseError: Server is unwilling to perform: >>>>>>>>>>> Minimum SSF not met. arguments: base="cn=config,cn=ldbm >>>>>>>>>>> database,cn=plugins,cn=config", scope=0, >>>>>>>>>>> filterstr="(objectclass=*)" >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Now this probably comes about because I set: nsslapd-minssf: >>>>>>>>>>> 56 For security. >>>>>>>>>>> >>>>>>>>>>> I can cange that back to the default and probably move past >>>>>>>>>>> this, but is that a known issue? Is there another way >>>>>>>>>>> around? >>>>>>>>>> As root try the --ldapi flag: >>>>>>>>>> >>>>>>>>>> # ipa-ldap-updater --ldapi /path/to/scheme.update >>>>>>>>>> >>>>>>>>>> rob >>>>>>>>>> >>>>>>>>> ERROR: LDAPUpdate: syntax error: dn is not defined in the >>>>>>>>> update, data source=schema.update >>>>>>>>> >>>>>>>>> -Erinn >>>>>>>>> >>>>>>>> Sorry, add this to the top of your update file: >>>>>>>> >>>>>>>> dn: cn=schema >>>>>>>> >>>>>>>> rob >>>>>>> No worries! Thanks for the help, after a restart of IPA the web UI >>>>>>> is working again. I reckon this is something that needs to be fixed, >>>>>>> does opening a support case and pointing them to that bug help you >>>>>>> folks out with this in any way? >>>>>> >>>>>> This is a know defect. We just did not realize it would have such a >>>>>> bad impact on upgrade. Sorry, the errata is on the way. >>>>>> >>>>>> I would recommend everyone to not upgrade to 6.4 until the errata is >>>>>> shipped. We will notify you as soon as it goes out. >>>>>> >>>>>> Sorry again. >>>>>> >>>>> >>>>> We did some research of this issue: 1) The upgrade works fine from 6.3 >>>>> to 6.4 and the issue does not exhibit itself 2) We have been able to >>>>> reproduce it with the direct upgrade from 6.2 to 6.4 3) Since the >>>>> expected upgrade part is 6.2 -> 6.3 -> 6.4 the question comes up >>>>> whether >>>>> this fix is actually that urgent. 4) In the presence of the simple >>>>> workaround we feel that it is not that important to include this fix >>>>> into the errata that we are working on. >>>>> >>>>> Please let us know if you think that there is a problem with the plan >>>>> above. >>>>> >>>>> >>>> >>>> Well all I can tell you on this, is that mine was an upgrade from >>>> 6.3 to >>>> 6.4, so there is a case where it will fail going from 6.3 to 6.4, >>>> but how >>>> applicable it is I can't say. >>> >>> Hi Erinn, >>> >>> Is 6.3 the original RHEL version where IPA server was installed? Or >>> was IPA >>> installed on RHEL-6.2 and then you upgraded RHEL to 6.3? >>> >>> Thank you, >>> Martin >>> >> >> These systems have gone through all the point releases from 6 on up I >> believe. >> >> -Erinn >> > > Ok, then this use case is also covered by the upcoming 6.4 fix. I just > wanted to check that. > > Thanks, > Martin Sounds good, and thanks for fixing that. -Erinn -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 555 bytes Desc: OpenPGP digital signature URL: From Johan.Petersson at sscspace.com Tue Feb 26 19:03:57 2013 From: Johan.Petersson at sscspace.com (Johan Petersson) Date: Tue, 26 Feb 2013 19:03:57 +0000 Subject: [Freeipa-users] IPA,NFS4,krb5p Ticket expired error Message-ID: <558C15177F5E714F83334217C9A197DF7A554DA4@SSC-MBX2.ssc.internal> Hi, I have a IPA server, NFS4 Server sharing home directories with autofs and krb5p as only valid authentication. Mail Postfix/Dovecot both with startTLS and GSSAPI. All servers and clients are Red Hat 6.3 and updated with latest kernel and everything else. If i start and log in locally as user1 on a IPA Client machine everything works perfect including mail and home directory initially. I then start experience errors when trying to ssh other servers as ssh user1 at mail.example.com. Nothing happens, no password question, nothing until i have to ctrl-c (tried leaving it overnight - still same). Mail stops working, thunderbird complain about expired credentials. If i use ssh as root to the server and then try either: su user1 or su - user1 both get same result as ssh user1. Sometimes a su have actually worked and i can browse to my mounted home directory but get permission denied when trying to access. id works and permissions on home directory shows ok but can't access anyway. The only thing i have found helping is to logout user1 on the client, login root and then ssh as user1. In that case i get password question and it works with home directory. If i logout root then, login user1 then mail, ssh and su works again for some time. I guess the credential renewal works in that case. Firewalls turned off, tried setenforce=0 and autofs on debug log mode but find nothing. Even sshd logging on and verbose ssh shows nothing wrong. It is like everything works but a expired ticket or something similar generate the error, tickets are new though and should be valid. Only error messages i have been able to find is: IPA server /var/log/messages show: rpc.gssd[1116]: Error doing stat on file '/tmp/krb5cc_48' automount[1197]: sasl_log_func:98: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Ticket expired) Anyone have a idea what this could be and how to solve it? I am really thankful for any help. Regards, Johan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Tue Feb 26 19:18:43 2013 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 26 Feb 2013 14:18:43 -0500 Subject: [Freeipa-users] New User - Possible to point authentication to external KDC In-Reply-To: References: <512B10EB.6080908@redhat.com> Message-ID: <512D0A93.9050008@redhat.com> On 02/26/2013 01:31 AM, Trey Dockendorf wrote: > > > On Feb 25, 2013 1:23 AM, "Dmitri Pal" > wrote: > > > > On 02/23/2013 10:33 PM, Trey Dockendorf wrote: > > > I just begun evaluating FreeIPA, after having successfully used 389ds > > > for a few months. The move from 389 ds to FreeIPA is to leverage the > > > authorization for host logins and also for simpler management. The > > > University I am deploying at has a campus wide KDC and for security > > > and audit reasons I prefer to point my authentication services at that > > > Kerberos realm rather than storing passwords. I have successfully > > > implemented this using the 389 ds pam pass through authentication > > > plug-in , but have not found any documentation on how to do this same > > > thing with FreeIPA. > > > > > > The complication with doing this is I do not have even a 1 way trust > > > with the KDC. Getting a trust (even 1-way) is very difficult if not > > > impossible, but so far I've been able to make PAM work with that > > > situation both using local authentication and now 389 ds, both through > > > PAM. Is it possible to have FreeIPA query a remote KDC while still > > > being able to fallback to the local password store (ie external users > > > not in campus domain). > > > > IPA uses the 389 DS so it might be possible to configure PAM pass > > through but there might be implications because if users are not in IPA > > you would not get a ticket and since you cant get a ticket you can't use > > UI and CLI. You can still bind using LDAP though as you do with the 389. > > So to manage IPA you would still have to have a user in IPA. However you > > will have two KDCs and I do not know what implications there would be > > for the clients, they might be confused. > > Frankly you are better off with 389 now untill we make setting up trusts > > with other IPAs or MIT KDCs simple. We did that for AD but it requires a > > clean DNS setup. I suspect DNS setup will be an issue in any case. > > > > > > > > Thanks > > > - Trey > > > > > > _______________________________________________ > > > Freeipa-users mailing list > > > Freeipa-users at redhat.com > > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > > -- > > Thank you, > > Dmitri Pal > > > > Sr. Engineering Manager for IdM portfolio > > Red Hat Inc. > > > > > > ------------------------------- > > Looking to carve out IT costs? > > www.redhat.com/carveoutcosts/ > > > > > > > > _______________________________________________ > > Freeipa-users mailing list > > Freeipa-users at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-users > > Thanks for the response! I do plan to have all my users in freeIPA. > My goal is to have my freeIPA install just attempt a password > authentication against external KDC via pam on the IPA server before > trying the local password store. With my current 389 setup, clients > are unaware of our campus KDC, the authentication is handled my 389 > server and currently users in my LDAP who have campus accounts get > their password verified via PAM and others in my LDAP use the local > password stored in 389. > > The aspects of IPA aside from 389 are where my uncertainty lies. For > example, if I have LDAP authenticate against an external KDC via PAM, > can the user still get a ticket from my IPA? > > Also getting a trust may not be possible even if freeipa makes the > process easier. This is a politics issue with our campus' main IT > group and something I've worked around thus far. > > Is there anything in changes of the stock 389 that would prevent this > from working in IPA? Also is there a preferred method for enabling > plugins in IPA? Also how could I test this? Would a client machine > joined to my IPA install be the best method? > > Thanks > - Trey > If you hit IPA with a kerberos authentication to the best of my knowledge KDC will read the data from LDAP and use it for authentication. It would not do PAM proxy in this case. The pam proxy would be possible only for the LDAP binds so I am not sure whether things would work for you. I see that you try to augment the existing infrastructure but I am not sure I have a clear picture in my mind of the architecture you envision. Is there any chance that you can put together a diagram? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sakodak at gmail.com Tue Feb 26 19:29:56 2013 From: sakodak at gmail.com (KodaK) Date: Tue, 26 Feb 2013 13:29:56 -0600 Subject: [Freeipa-users] proper way to clear sssd cache without sss_cache? Message-ID: I know that at some point the sssd package (or maybe the tools package) started including sss_cache for managing the sssd cache. I have some RHEL5 boxes that don't have this utility. I've been stopping the sssd service, deleting the contents of /var/lib/sss/db/ and then restarting and things seem to be working OK, but I wanted to find out if there was a proper procedure? Thanks! -- The government is going to read our mail anyway, might as well make it tough for them. GPG Public key ID: B6A1A7C6 From dpal at redhat.com Tue Feb 26 19:30:01 2013 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 26 Feb 2013 14:30:01 -0500 Subject: [Freeipa-users] IPA,NFS4,krb5p Ticket expired error In-Reply-To: <558C15177F5E714F83334217C9A197DF7A554DA4@SSC-MBX2.ssc.internal> References: <558C15177F5E714F83334217C9A197DF7A554DA4@SSC-MBX2.ssc.internal> Message-ID: <512D0D39.80408@redhat.com> On 02/26/2013 02:03 PM, Johan Petersson wrote: > Hi, > > I have a IPA server, NFS4 Server sharing home directories with autofs > and krb5p as only valid authentication. > Mail Postfix/Dovecot both with startTLS and GSSAPI. > All servers and clients are Red Hat 6.3 and updated with latest kernel > and everything else. > > If i start and log in locally as user1 on a IPA Client machine > everything works perfect including mail and home directory initially. > I then start experience errors when trying to ssh other servers as ssh > user1 at mail.example.com. > Nothing happens, no password question, nothing until i have to ctrl-c > (tried leaving it overnight - still same). > Mail stops working, thunderbird complain about expired credentials. > If i use ssh as root to the server and then try either: su user1 or su > - user1 both get same result as ssh user1. > Sometimes a su have actually worked and i can browse to my > mounted home directory but get permission denied when trying to access. > id works and permissions on home directory shows ok but can't access > anyway. > > The only thing i have found helping is to logout user1 on the client, > login root and then ssh as user1. > In that case i get password question and it works with home directory. > If i logout root then, login user1 then mail, ssh and su works again > for some time. > > I guess the credential renewal works in that case. > > Firewalls turned off, tried setenforce=0 and autofs on debug log mode > but find nothing. > > Even sshd logging on and verbose ssh shows nothing wrong. > It is like everything works but a expired ticket or something similar > generate the error, tickets are new though and should be valid. > > Only error messages i have been able to find is: > > IPA server /var/log/messages show: > rpc.gssd[1116]: Error doing stat on file '/tmp/krb5cc_48' > > automount[1197]: sasl_log_func:98: GSSAPI Error: Unspecified GSS > failure. Minor code may provide more information (Ticket expired) > > Anyone have a idea what this could be and how to solve it? > > I am really thankful for any help. > > Regards, > Johan. > This looks very much as if when you ssh into the remote system the home directory NFS mount fails. Can you try to configure a local directory and see if the problem goes away? If this helps then I would see what is going on with the NFS client on the system. Also I do not know how your SSH is configured. Does it actually delegate the ticket? AFAIU the system you SSH into needs to have a TGT to be able to mount an NFS share on behalf of the user. This is as far as I can go with what I know and what can be done without actually looking at the logs on the system. HTH > > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Tue Feb 26 19:34:27 2013 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 26 Feb 2013 14:34:27 -0500 Subject: [Freeipa-users] RHEL6 IPA and Active Directory synchronisation and Solaris RBAC In-Reply-To: <512A3AF8DAE8454D95C05141F746ECE1512E84F4@MLBMXUS21.cs.myharris.net> References: <511BACEE.8050900@redhat.com> <511D2541.1000201@nixtra.com> <511D2CAC.6050400@redhat.com> <511D4693.8010502@redhat.com> <1360937840.21935.556.camel@osc145.evn.harris.com> <511EA93C.8060909@redhat.com>, <511F6D98.30700@nixtra.com> <512A3AF8DAE8454D95C05141F746ECE1512AC316@MLBMXUS21.cs.myharris.net> <512121E9.2050608@redhat.com> <1361283261.21935.914.camel@osc145.evn.harris.com> <51242F73.9000309@redhat.com> <1361367894.21935.1033.camel@osc145.evn.harris.com> <5125E083.3040506@redhat.com> <512A3AF8DAE8454D95C05141F746ECE1512E84A0@MLBMXUS21.cs.myharris.net> <512A3AF8DAE8454D95C05141F746ECE1512E84F4@MLBMXUS21.cs.myharris.net> Message-ID: <512D0E43.6000303@redhat.com> On 02/25/2013 02:29 PM, Mercer, Rodney wrote: > I think that this is a good explanation or the solaris rbac model. > > http://www.softpanorama.org/Solaris/Security/solaris_rbac.shtml > > Regards, > Rodney. I will definitely read it. But assume I did. What are the next steps? The schema is the right one so do you plan to start the design work? Would you start with the server side or with SSSD side? Adding schema to IPA and populating it with ldap modify or my loading ldif might give you enough to start designing and developing the SSSD component. The management interface for the server side can be added after the SSSD side is done. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Tue Feb 26 19:36:42 2013 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 26 Feb 2013 14:36:42 -0500 Subject: [Freeipa-users] proper way to clear sssd cache without sss_cache? In-Reply-To: References: Message-ID: <512D0ECA.70406@redhat.com> On 02/26/2013 02:29 PM, KodaK wrote: > I know that at some point the sssd package (or maybe the tools > package) started including sss_cache for managing the sssd cache. I > have some RHEL5 boxes that don't have this utility. > > I've been stopping the sssd service, deleting the contents of > /var/lib/sss/db/ and then restarting and things seem to be working OK, > but I wanted to find out if there was a proper procedure? > > Thanks! > Yes it was the proper procedure until we added a tool. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From Steven.Jones at vuw.ac.nz Tue Feb 26 19:39:37 2013 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Tue, 26 Feb 2013 19:39:37 +0000 Subject: [Freeipa-users] proper way to clear sssd cache without sss_cache? In-Reply-To: References: Message-ID: <833D8E48405E064EBC54C84EC6B36E40715F7914@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, Its what I have to do on most client side issues and what RH support advise. I was told that the sssd daemon would be upgraded in 6.4, its certainly seems to be my main pain point right now. 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 KodaK [sakodak at gmail.com] Sent: Wednesday, 27 February 2013 8:29 a.m. To: freeipa-users at redhat.com Subject: [Freeipa-users] proper way to clear sssd cache without sss_cache? I know that at some point the sssd package (or maybe the tools package) started including sss_cache for managing the sssd cache. I have some RHEL5 boxes that don't have this utility. I've been stopping the sssd service, deleting the contents of /var/lib/sss/db/ and then restarting and things seem to be working OK, but I wanted to find out if there was a proper procedure? Thanks! -- The government is going to read our mail anyway, might as well make it tough for them. GPG Public key ID: B6A1A7C6 _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users From dpal at redhat.com Tue Feb 26 19:45:59 2013 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 26 Feb 2013 14:45:59 -0500 Subject: [Freeipa-users] Non-Prod instance In-Reply-To: <512B7BFE.90201@collective.com> References: <512B7BFE.90201@collective.com> Message-ID: <512D10F7.5020006@redhat.com> On 02/25/2013 09:58 AM, Guy Matz wrote: > Hello! Does anyone out there run two instances of freeipa, prod & > non-prod instances? Are there any issues to be wary of in this > scenario? Any gotchas? Do you use the same realms & domain names > between instances? As long as you completely isolate one from another network wise you can use whatever names you want. > > Perhaps the fellow who upgraded his prod server to 6.4 might > appreciate this . . . > > Thanks a lot, > Guy > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From gmatz at collective.com Tue Feb 26 20:43:34 2013 From: gmatz at collective.com (Guy Matz) Date: Tue, 26 Feb 2013 15:43:34 -0500 Subject: [Freeipa-users] Non-Prod instance In-Reply-To: <512D10F7.5020006@redhat.com> References: <512B7BFE.90201@collective.com> <512D10F7.5020006@redhat.com> Message-ID: <512D1E76.4040401@collective.com> Thanks! Is it a matter of isolating the networks? Or just making sure clients are pointing to the correct server? Thanks again, Guy On 02/26/2013 02:45 PM, Dmitri Pal wrote: > On 02/25/2013 09:58 AM, Guy Matz wrote: >> Hello! Does anyone out there run two instances of freeipa, prod & >> non-prod instances? Are there any issues to be wary of in this >> scenario? Any gotchas? Do you use the same realms & domain names >> between instances? > As long as you completely isolate one from another network wise you can > use whatever names you want. > >> Perhaps the fellow who upgraded his prod server to 6.4 might >> appreciate this . . . >> >> Thanks a lot, >> Guy >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > From jhrozek at redhat.com Tue Feb 26 20:59:53 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 26 Feb 2013 21:59:53 +0100 Subject: [Freeipa-users] proper way to clear sssd cache without sss_cache? In-Reply-To: <512D0ECA.70406@redhat.com> References: <512D0ECA.70406@redhat.com> Message-ID: <20130226205953.GT3026@hendrix.brq.redhat.com> On Tue, Feb 26, 2013 at 02:36:42PM -0500, Dmitri Pal wrote: > On 02/26/2013 02:29 PM, KodaK wrote: > > I know that at some point the sssd package (or maybe the tools > > package) started including sss_cache for managing the sssd cache. I > > have some RHEL5 boxes that don't have this utility. > > > > I've been stopping the sssd service, deleting the contents of > > /var/lib/sss/db/ and then restarting and things seem to be working OK, > > but I wanted to find out if there was a proper procedure? > > > > Thanks! > > > Yes it was the proper procedure until we added a tool. The only thing to keep in mind is that by wiping out the whole cache removes all cached passwords. Depending on whether you use cache_credentials=True or whether your clients need to cache credentials at all you do or don't care :-) If you care, you might want to use the ldbmodify utility to instead set the dataExpire timestamp to a timestamp from the past (this is what sss_cache does internally btw) From sigbjorn at nixtra.com Tue Feb 26 21:18:17 2013 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Tue, 26 Feb 2013 22:18:17 +0100 Subject: [Freeipa-users] ipa: ERROR: attribute 'idnsAllowTransfer' not allowed In-Reply-To: <512C6C96.2050302@redhat.com> References: <24628.213.225.75.97.1361782009.squirrel@www.nixtra.com> <20130225115910.GA13961@fluxcoil.net> <23480.213.225.75.97.1361803131.squirrel@www.nixtra.com> <512C6C96.2050302@redhat.com> Message-ID: Hi. This is ipa 2.2 on rhel 6.3. Upgraded from rhel 6.2. Initial install on 6.2. Rgds Siggi Martin Kosek wrote: >On 02/25/2013 03:38 PM, Sigbjorn Lie wrote: >> On Mon, February 25, 2013 12:59, Christian Horn wrote: >>> Hi, >>> >>> >>> On Mon, Feb 25, 2013 at 09:46:49AM +0100, Sigbjorn Lie wrote: >>> >>>> >>>> $ ipa dnszone-add example.com --name-server=ns01.example.com >>>> --admin-email=hostmaster.example.com >>>> ipa: ERROR: attribute "idnsAllowTransfer" not allowed >>>> >>>> >>>> [..] >>>> >>>> >>>> Is this a known error? >>>> >>> >>> Yes, >>> the idnsZone objectClass entry was not updated properly during >ipa-server update process. To fix >>> this the schema has to be modified, >https://access.redhat.com/knowledge/solutions/301213 has >>> the details. >>> >> >> Thank you. That worked just fine. :) >> >> >> Regards, >> Siggi >> > >Hi guys, I am glad you resolved the issue. I am just curious - from >what >version to what version did you upgrade? Is this is a bug in IPA in >RHEL 6.4? > >Thank you, >Martin -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From freeipa at noboost.org Wed Feb 27 01:32:52 2013 From: freeipa at noboost.org (freeipa at noboost.org) Date: Wed, 27 Feb 2013 12:32:52 +1100 Subject: [Freeipa-users] FQDN Hostname Requirement Message-ID: <20130227013252.GA21191@noboost.org> Hi All, Spec: Red Hat Enterprise Linux Server release 6.3 (Santiago) ipa-server-2.2.0-16.el6.x86_64 Issue: I made a post a while back regarding IPA and the forcing of the hostname to be a FQDN entry, rather than utilising `hostname --fqdn` ref: https://www.redhat.com/archives/freeipa-users/2012-March/msg00012.html Has this issue ever been addressed? As I've now bumped into an issue with RSA Securid Auth Manager 6.1, which will not work on a server with more than 27 characters in the hostname. Sadly our hostname does break this is some cases. cya Craig From arthur at deus.pro Wed Feb 27 03:07:26 2013 From: arthur at deus.pro (=?koi8-r?Q?=E1=D2=D4=D5=D2_?= =?koi8-r?Q?=E6=C1=CA=DA=D5=CC=CC=C9=CE?=) Date: Wed, 27 Feb 2013 09:07:26 +0600 Subject: [Freeipa-users] FreeIPA for AMM users management In-Reply-To: <512C9F7D.9030509@redhat.com> References: <20121101042710.GC8238@work.zhukoff.net> <1351799730.18469.138.camel@willson.li.ssimo.org> <1351804185.18469.146.camel@willson.li.ssimo.org> <20121102041246.GB1558@work.zhukoff.net> <5093C424.5010506@redhat.com> <20121103121243.GC1558@work.zhukoff.net> <509779AA.6010409@redhat.com> <1361875747.12967.1.camel@arthur.bashnl.ru> <512C9F7D.9030509@redhat.com> Message-ID: <1361934446.12967.8.camel@arthur.bashnl.ru> Ok! I will try :) but would you give me some advice :) what configs to put. should I use: * "Use LDAP Servers for Authentication and Authorization" * "Use DNS to find LDAP Servers" and put here domain name if IPA-server? * should in "Active Directory Settings" Enhanced role-based security be enabled? And what means AMM Target Name? * root dn = something like this dc=example,dc=com ? * Binding method which one to choose? w/ Configured Credentials w/ Login Credentials Some questions may be stupid, but I want to be sure in them :) ? ??., 26/02/2013 ? 12:41 +0100, Petr Spacek ?????: > On 26.2.2013 11:49, ????? ????????? wrote: > > And what? > > Is there any result? I try same thing with my AMM and IPA > > Unfortunately, we don't have sufficient information to give you any advice. > > Please, try to provide output from a sniffer as I asked in last reply. Then we > will try to help you. (You can send the data to me privately, if you want.) > > Petr^2 Spacek > > > ? ??., 05/11/2012 ? 09:32 +0100, Petr Spacek ?????: > >> On 11/03/2012 01:12 PM, Pavel Zhukov wrote: > >>>> Can you do NS lookup of the IPA server from the AMM box? > >>> yes > >>>> Can you do kinit from the AMM box against IPA? > >>>> Can you do ldapsearch from the AMM box against IPA? > >>> no, AMM has restricted shell and web GUI. > >> > >> Hmm, that is unfortunate. Can you run tcpdump (or sniffer provided on AMM) on > >> the link between AMM and IPA server? Because there are no records in access > >> log I will bet on some name resolution or firewall problem. > >> > >> Do AMM get right DNS responses (i.e. name and IP address of the IPA server)? > >> > >> Do AMM established TCP connection with the IPA server? > >> > >> -- > >> Petr^2 Spacek > >> > >>>> Do you see anything in the logs from such activity? > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From rajnesh.siwal at gmail.com Wed Feb 27 04:25:32 2013 From: rajnesh.siwal at gmail.com (Rajnesh Kumar Siwal) Date: Wed, 27 Feb 2013 09:55:32 +0530 Subject: [Freeipa-users] Transferring "mastership" to a new server Message-ID: Is is still required if the replica is created using the following command:- # ipa-replica-install --setup-ca --setup-dns -- Regards, Rajnesh Kumar Siwal From janfrode at tanso.net Wed Feb 27 07:19:27 2013 From: janfrode at tanso.net (Jan-Frode Myklebust) Date: Wed, 27 Feb 2013 08:19:27 +0100 Subject: [Freeipa-users] meaning of several domains in sssd.conf Message-ID: <20130227071927.GA18688@dibs.tanso.net> What does it mean to have several domains listed in sssd.conf ? Will they all be queried on each login, or will only the first domain be queried if the user/groups is found there? Does having an IPA domain, and an LDAP domain pointing at the same servers give any protection against failures in the sssd_BE process allowing sssd to fail over to the next sssd_BE ? -jf From mkosek at redhat.com Wed Feb 27 08:14:40 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 27 Feb 2013 09:14:40 +0100 Subject: [Freeipa-users] Non-Prod instance In-Reply-To: <512D1E76.4040401@collective.com> References: <512B7BFE.90201@collective.com> <512D10F7.5020006@redhat.com> <512D1E76.4040401@collective.com> Message-ID: <512DC070.7020507@redhat.com> The main purpose of this isolation is that your production clients for example do not autodiscover testing IPA instance via DNS SRV records and do not use it instead of the production instance. Martin On 02/26/2013 09:43 PM, Guy Matz wrote: > Thanks! Is it a matter of isolating the networks? Or just making sure clients > are pointing to the correct server? > > Thanks again, > Guy > > On 02/26/2013 02:45 PM, Dmitri Pal wrote: >> On 02/25/2013 09:58 AM, Guy Matz wrote: >>> Hello! Does anyone out there run two instances of freeipa, prod & >>> non-prod instances? Are there any issues to be wary of in this >>> scenario? Any gotchas? Do you use the same realms & domain names >>> between instances? >> As long as you completely isolate one from another network wise you can >> use whatever names you want. >> >>> Perhaps the fellow who upgraded his prod server to 6.4 might >>> appreciate this . . . >>> >>> Thanks a lot, >>> Guy >>> >>> _______________________________________________ >>> 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 jhrozek at redhat.com Wed Feb 27 08:31:43 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 27 Feb 2013 09:31:43 +0100 Subject: [Freeipa-users] meaning of several domains in sssd.conf In-Reply-To: <20130227071927.GA18688@dibs.tanso.net> References: <20130227071927.GA18688@dibs.tanso.net> Message-ID: <20130227083143.GB16086@hendrix.redhat.com> On Wed, Feb 27, 2013 at 08:19:27AM +0100, Jan-Frode Myklebust wrote: > What does it mean to have several domains listed in sssd.conf ? Will > they all be queried on each login, or will only the first domain be > queried if the user/groups is found there? > If the user is found in the first domain, the result is returned. If it is not found, the second domain is queried etc. To query a user from the second domain directly, you'd have to use a fully qualified name - getent passwd user at domain2 > Does having an IPA domain, and an LDAP domain pointing at the same > servers give any protection against failures in the sssd_BE process > allowing sssd to fail over to the next sssd_BE ? In theory yes, but you'd lose the IPA specific functions such as HBAC or SELinux user mappings. Also for example the paths to Kerberos ccaches are stored in the sssd cache too, so your users would get a different ccache on this "failover". Are there any issues you are seeing with IPA's sssd_be? It would definitely be better to fix those first rather than attempting a workaround like this. From janfrode at tanso.net Wed Feb 27 08:47:39 2013 From: janfrode at tanso.net (Jan-Frode Myklebust) Date: Wed, 27 Feb 2013 09:47:39 +0100 Subject: [Freeipa-users] meaning of several domains in sssd.conf In-Reply-To: <20130227083143.GB16086@hendrix.redhat.com> References: <20130227071927.GA18688@dibs.tanso.net> <20130227083143.GB16086@hendrix.redhat.com> Message-ID: <20130227084739.GA19417@dibs.tanso.net> On Wed, Feb 27, 2013 at 09:31:43AM +0100, Jakub Hrozek wrote: > > Are there any issues you are seeing with IPA's sssd_be? It would > definitely be better to fix those first rather than attempting a > workaround like this. I've earlier been hit by a bug in nested groups (or netgroups) where the ipa backend would segfault, leaving sssd running but unable to authenticate. I believe it was this problem: https://fedorahosted.org/sssd/changeset/db90c1b60c729995f34af2431ede61ea7493e540/ And therefore wonder if it makes sense, or even is advisable to have backup backends to make sure to never lose the user database. -jf From jhrozek at redhat.com Wed Feb 27 09:12:34 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 27 Feb 2013 10:12:34 +0100 Subject: [Freeipa-users] meaning of several domains in sssd.conf In-Reply-To: <20130227084739.GA19417@dibs.tanso.net> References: <20130227071927.GA18688@dibs.tanso.net> <20130227083143.GB16086@hendrix.redhat.com> <20130227084739.GA19417@dibs.tanso.net> Message-ID: <20130227091234.GD16086@hendrix.redhat.com> On Wed, Feb 27, 2013 at 09:47:39AM +0100, Jan-Frode Myklebust wrote: > On Wed, Feb 27, 2013 at 09:31:43AM +0100, Jakub Hrozek wrote: > > > > Are there any issues you are seeing with IPA's sssd_be? It would > > definitely be better to fix those first rather than attempting a > > workaround like this. > > I've earlier been hit by a bug in nested groups (or netgroups) where the > ipa backend would segfault, leaving sssd running but unable to > authenticate. > > I believe it was this problem: > > https://fedorahosted.org/sssd/changeset/db90c1b60c729995f34af2431ede61ea7493e540/ > > And therefore wonder if it makes sense, or even is advisable to have > backup backends to make sure to never lose the user database. > > In general the IPA backend is more or less a wrapper around the LDAP and Kerberos backends with defaults set to match the IPA server setup and couple of exceptions: * nested groups are handled differently (due to the memberof attribute) * initgroups can be handled differently (due to the memberof attribute) * the netgroups code is different, IPA has native netgroups support So in the above cases, you might be able to work around a bug in the IPA provider by following a different code path, but in the general case, the same bugs would exist in both IPA and LDAP/Kerberos. Plus some features are IPA specific at the time being such as IPA support of HBAC access control rules and SELinux user mappings. From pspacek at redhat.com Wed Feb 27 09:31:05 2013 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 27 Feb 2013 10:31:05 +0100 Subject: [Freeipa-users] FreeIPA for AMM users management In-Reply-To: <1361934446.12967.8.camel@arthur.bashnl.ru> References: <20121101042710.GC8238@work.zhukoff.net> <1351799730.18469.138.camel@willson.li.ssimo.org> <1351804185.18469.146.camel@willson.li.ssimo.org> <20121102041246.GB1558@work.zhukoff.net> <5093C424.5010506@redhat.com> <20121103121243.GC1558@work.zhukoff.net> <509779AA.6010409@redhat.com> <1361875747.12967.1.camel@arthur.bashnl.ru> <512C9F7D.9030509@redhat.com> <1361934446.12967.8.camel@arthur.bashnl.ru> Message-ID: <512DD259.8010202@redhat.com> On 27.2.2013 04:07, ????? ????????? wrote: > Ok! I will try :) but would you give me some advice :) what configs to > put. should I use: Well, we don't know anything about AAM. This is freeipa-users list :-) We can try to give you some advices if you provide links to documentation for exact AAM version you use. My best guess (without looking to AAM docs): > * "Use LDAP Servers for Authentication and Authorization" Probably yes. > * "Use DNS to find LDAP Servers" > and put here domain name if IPA-server? Probably yes. > * should in "Active Directory Settings" Enhanced role-based security be > enabled? I would disable any AD specific things (at least for the beginning). > And what means AMM Target Name? I don't have an idea. Please consult AAM docs. > * root dn = something like this dc=example,dc=com ? Question is what "root" means in IBM's world. FreeIPA domain "example.com" has root of LDAP tree at "dc=example,dc=com". You can try also "cn=users,cn=compat,dc=example,dc=com" and "cn=users,cn=accounts,dc=ecample,dc=com". > * Binding method which one to choose? > w/ Configured Credentials I guess: This method will use special account created specifically for AAM. > w/ Login Credentials I guess: This method will try to do LDAP BIND with credentials provided by user for particular login attempt. I would prefer this method. > Some questions may be stupid, but I want to be sure in them :) I really don't know AAM specifics. Please read all AAM's documentation you find and try various settings. We can provide general advices and publish your findings on freeipa.org. Any contributions welcome! Petr^2 Spacek > ? ??., 26/02/2013 ? 12:41 +0100, Petr Spacek ?????: >> On 26.2.2013 11:49, ????? ????????? wrote: >>> And what? >>> Is there any result? I try same thing with my AMM and IPA >> >> Unfortunately, we don't have sufficient information to give you any advice. >> >> Please, try to provide output from a sniffer as I asked in last reply. Then we >> will try to help you. (You can send the data to me privately, if you want.) >> >> Petr^2 Spacek >> >>> ? ??., 05/11/2012 ? 09:32 +0100, Petr Spacek ?????: >>>> On 11/03/2012 01:12 PM, Pavel Zhukov wrote: >>>>>> Can you do NS lookup of the IPA server from the AMM box? >>>>> yes >>>>>> Can you do kinit from the AMM box against IPA? >>>>>> Can you do ldapsearch from the AMM box against IPA? >>>>> no, AMM has restricted shell and web GUI. >>>> >>>> Hmm, that is unfortunate. Can you run tcpdump (or sniffer provided on AMM) on >>>> the link between AMM and IPA server? Because there are no records in access >>>> log I will bet on some name resolution or firewall problem. >>>> >>>> Do AMM get right DNS responses (i.e. name and IP address of the IPA server)? >>>> >>>> Do AMM established TCP connection with the IPA server? >>>> >>>> -- >>>> Petr^2 Spacek >>>> >>>>>> Do you see anything in the logs from such activity? From pspacek at redhat.com Wed Feb 27 09:42:49 2013 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 27 Feb 2013 10:42:49 +0100 Subject: [Freeipa-users] Cannot obtain CA Certificate In-Reply-To: <9E4ACCDE-A5BF-4A1D-BFEA-6B8090D27B21@digitalreasoning.com> References: <80D02259-925A-4529-943F-0ACAD7B77BB3@digitalreasoning.com> <20130219113502.GA21948@dibs.tanso.net> <9E4ACCDE-A5BF-4A1D-BFEA-6B8090D27B21@digitalreasoning.com> Message-ID: <512DD519.7060801@redhat.com> On 26.2.2013 17:55, John Moyer wrote: > Sorry for the late response, so I tried this, and it changed the error to the following: > > Synchronizing time with KDC... > > Joining realm failed: HTTP response code is 401, not 200 > Installation failed. Rolling back changes. > > > > Looking at debug this is what I see: > > < HTTP/1.1 401 Authorization Required > < Date: Tue, 26 Feb 2013 16:54:21 GMT > < Server: Apache/2.2.15 (CentOS) > * gss_init_sec_context() failed: : Server krbtgt/COM at EXAMPLE.COM not found in Kerberos database< WWW-Authenticate: Negotiate krbtgt/COM at EXAMPLE.COM is definitely not correct. It should look like "krbtgt/EXAMPLE.COM at EXAMPLE.COM". I would recommend to double check name resolution. Are all records in /etc/hosts correct? Does /etc/resolv.conf point to the IPA server? Do forward (A) and reverse (PTR) records match for client and also IPA servers? Does dig -t TXT _kerberos.example.com return correct REALM? Do all domain and realm names in /etc/krb5.conf point to correct IPA domain? You can run ipa-client-install with KRB5_TRACE environment variable set. It could produce some useful output. E.g.: $ KRB5_TRACE=/tmp/kerberos_trace.log ipa-client-install <.. blah blah..> This should log actions done by Kerberos libraries to file /tmp/kerberos_trace.log. Also, "tcpdump -s 65535 -w /tmp/tcpdump -i any" could provide some clue. You can send both files to me privately if you don't want to send them to mailing list. Petr^2 Spacek > < Last-Modified: Wed, 23 Jan 2013 22:16:50 GMT > < ETag: "4627-740-4d3fc0cfd7880" > < Accept-Ranges: bytes > < Content-Length: 1856 > < Connection: close > < Content-Type: text/html; charset=UTF-8 > > > > > On Feb 19, 2013, at 6:35 AM, Jan-Frode Myklebust wrote: > >>> ipa : ERROR Cannot obtain CA certificate >>> 'ldap://ipa1.example.com' doesn't have a certificate. >>> Installation failed. Rolling back changes. >>> IPA client is not configured on this system. >> >> FYI, I have this same issue when enrolling RHEL5 clients. Have been >> doing this as a workaround: >> >> wget -O /etc/ipa/ca.crt http://ipa1.example.com/ipa/config/ca.crt >> ipa-client-install --no-ntp --mkhomedir --ca-cert-file=/etc/ipa/ca.crt >> >> >> >> -jf From janfrode at tanso.net Wed Feb 27 10:34:10 2013 From: janfrode at tanso.net (Jan-Frode Myklebust) Date: Wed, 27 Feb 2013 11:34:10 +0100 Subject: [Freeipa-users] Cannot obtain CA Certificate In-Reply-To: <512DD519.7060801@redhat.com> References: <80D02259-925A-4529-943F-0ACAD7B77BB3@digitalreasoning.com> <20130219113502.GA21948@dibs.tanso.net> <9E4ACCDE-A5BF-4A1D-BFEA-6B8090D27B21@digitalreasoning.com> <512DD519.7060801@redhat.com> Message-ID: <20130227103410.GA19829@dibs.tanso.net> On Wed, Feb 27, 2013 at 10:42:49AM +0100, Petr Spacek wrote: > > > > > >< HTTP/1.1 401 Authorization Required > >< Date: Tue, 26 Feb 2013 16:54:21 GMT > >< Server: Apache/2.2.15 (CentOS) > >* gss_init_sec_context() failed: : Server krbtgt/COM at EXAMPLE.COM not found in Kerberos database< WWW-Authenticate: Negotiate I have a similar problem getting a couple of RHEL 6.4 clients working with a 6.3 server (ipa-server-2.2.0-17.el6_3.1.x86_64). When doing the ipa-client-install I get: * gss_init_sec_context() failed: : Request is a replay< WWW-Authenticate: Negotiate I have a ticket opened with RH-support for this (00796525), so I hope to get it fixed that way soonish.. but -- one strange thing about my problem is that I can't even get sssd working if I do a manual enrollment. I've tried doing ipa host-add, ipa host-add-managedby, ipa-getkeytab on the ipa-server, transferred the keytab, but still sssd fails to work. To get sssd working on this machine I had to configure an LDAP backend against the ipa-servers, without "ldap_sasl_mech=GSSAPI". Is there a simple way to verify that the hosts keytab is OK? "klist -k -t -K FILE:/etc/krb5.keytab" works fine, but I'd like to test it against the ipa-server. -jf From pspacek at redhat.com Wed Feb 27 10:52:42 2013 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 27 Feb 2013 11:52:42 +0100 Subject: [Freeipa-users] Cannot obtain CA Certificate In-Reply-To: <20130227103410.GA19829@dibs.tanso.net> References: <80D02259-925A-4529-943F-0ACAD7B77BB3@digitalreasoning.com> <20130219113502.GA21948@dibs.tanso.net> <9E4ACCDE-A5BF-4A1D-BFEA-6B8090D27B21@digitalreasoning.com> <512DD519.7060801@redhat.com> <20130227103410.GA19829@dibs.tanso.net> Message-ID: <512DE57A.403@redhat.com> On 27.2.2013 11:34, Jan-Frode Myklebust wrote: > On Wed, Feb 27, 2013 at 10:42:49AM +0100, Petr Spacek wrote: >>> >>> >>> < HTTP/1.1 401 Authorization Required >>> < Date: Tue, 26 Feb 2013 16:54:21 GMT >>> < Server: Apache/2.2.15 (CentOS) >>> * gss_init_sec_context() failed: : Server krbtgt/COM at EXAMPLE.COM not found in Kerberos database< WWW-Authenticate: Negotiate > > I have a similar problem getting a couple of RHEL 6.4 clients working > with a 6.3 server (ipa-server-2.2.0-17.el6_3.1.x86_64). When doing the > ipa-client-install I get: > > * gss_init_sec_context() failed: : Request is a replay< WWW-Authenticate: Negotiate This is very suspicious. Could you double check time on all servers and the client? > I have a ticket opened with RH-support for this (00796525), so I hope > to get it fixed that way soonish.. but -- one strange thing about my > problem is that I can't even get sssd working if I do a manual > enrollment. I've tried doing ipa host-add, ipa host-add-managedby, > ipa-getkeytab on the ipa-server, transferred the keytab, but still > sssd fails to work. To get sssd working on this machine I had to > configure an LDAP backend against the ipa-servers, without > "ldap_sasl_mech=GSSAPI". > > Is there a simple way to verify that the hosts keytab is OK? > "klist -k -t -K FILE:/etc/krb5.keytab" works fine, but I'd > like to test it against the ipa-server. You can do kinit as host principal: $ klist -kt /etc/krb5.keytab Keytab name: FILE:/etc/krb5.keytab KVNO Timestamp Principal ---- ----------------- --------------------------------- 2 10/17/12 15:22:19 host/host.example.com at EXAMPLE.COM $ kinit -kt /etc/krb5.keytab host/host.example.com at EXAMPLE.COM $ klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: host/host.example.com at EXAMPLE.COM Valid starting Expires Service principal 02/27/13 11:45:02 02/28/13 11:45:02 krbtgt/EXAMPLE.COM at EXAMPLE.COM -- Petr^2 Spacek From Johan.Petersson at sscspace.com Wed Feb 27 13:15:19 2013 From: Johan.Petersson at sscspace.com (Johan Petersson) Date: Wed, 27 Feb 2013 13:15:19 +0000 Subject: [Freeipa-users] IPA,NFS4,krb5p Ticket expired error In-Reply-To: <512D0D39.80408@redhat.com> References: <558C15177F5E714F83334217C9A197DF7A554DA4@SSC-MBX2.ssc.internal>, <512D0D39.80408@redhat.com> Message-ID: <558C15177F5E714F83334217C9A197DF7A554E90@SSC-MBX2.ssc.internal> I think you are right, ssh always works to the nfs server and i believe that is because the home directory is situated there. All ssh/sshd configuration are default from IPA Client install. Only things changed are the necessary autofs configuration and that is straight from the manual. I use strict NFS4 with port 2049 only open. (tried all firewalls and selinux disabled, no difference) Home directory is exported as: /nethomes 192.168.1.0(rw,sync,sec=krb5p) IPA autofs map default/auto_nethome * -fstype=nfs4 -sec=krb5p,rw,soft, share.test.net:/nethomes/& -fstype=nfs4 i had to use to get autofs working, through firewall and only port 2049 open it got crazy otherwise rambling about nfs2 and3 -sec=krb5p i had to put in autofs map since otherwise autofs ignored settings in exports and tried empty -o when mounting and thus failed because no kerberos auth. I have updated everything to RHEL 6.4 now but no change. Thunderbird complains that my ticket was not accepted. NFS server shows this in logs: rpc.gssd[2060]: ERROR: failed to read service info rpc.gssd[2060]: WARNING: can't create tcp rpc_clnt to server laptop1.test.net for user with uid 0: RPC: Remote system error - No route to host Network is fine and all firewalls down. Do you want any other logs beside debug autofs? Thanks for the help. Regards, Johan. ________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Dmitri Pal [dpal at redhat.com] Sent: Tuesday, February 26, 2013 20:30 To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] IPA,NFS4,krb5p Ticket expired error On 02/26/2013 02:03 PM, Johan Petersson wrote: Hi, I have a IPA server, NFS4 Server sharing home directories with autofs and krb5p as only valid authentication. Mail Postfix/Dovecot both with startTLS and GSSAPI. All servers and clients are Red Hat 6.3 and updated with latest kernel and everything else. If i start and log in locally as user1 on a IPA Client machine everything works perfect including mail and home directory initially. I then start experience errors when trying to ssh other servers as ssh user1 at mail.example.com. Nothing happens, no password question, nothing until i have to ctrl-c (tried leaving it overnight - still same). Mail stops working, thunderbird complain about expired credentials. If i use ssh as root to the server and then try either: su user1 or su - user1 both get same result as ssh user1. Sometimes a su have actually worked and i can browse to my mounted home directory but get permission denied when trying to access. id works and permissions on home directory shows ok but can't access anyway. The only thing i have found helping is to logout user1 on the client, login root and then ssh as user1. In that case i get password question and it works with home directory. If i logout root then, login user1 then mail, ssh and su works again for some time. I guess the credential renewal works in that case. Firewalls turned off, tried setenforce=0 and autofs on debug log mode but find nothing. Even sshd logging on and verbose ssh shows nothing wrong. It is like everything works but a expired ticket or something similar generate the error, tickets are new though and should be valid. Only error messages i have been able to find is: IPA server /var/log/messages show: rpc.gssd[1116]: Error doing stat on file '/tmp/krb5cc_48' automount[1197]: sasl_log_func:98: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Ticket expired) Anyone have a idea what this could be and how to solve it? I am really thankful for any help. Regards, Johan. This looks very much as if when you ssh into the remote system the home directory NFS mount fails. Can you try to configure a local directory and see if the problem goes away? If this helps then I would see what is going on with the NFS client on the system. Also I do not know how your SSH is configured. Does it actually delegate the ticket? AFAIU the system you SSH into needs to have a TGT to be able to mount an NFS share on behalf of the user. This is as far as I can go with what I know and what can be done without actually looking at the logs on the system. HTH _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Wed Feb 27 13:54:57 2013 From: simo at redhat.com (Simo Sorce) Date: Wed, 27 Feb 2013 08:54:57 -0500 Subject: [Freeipa-users] Transferring "mastership" to a new server In-Reply-To: References: Message-ID: <1361973297.2962.57.camel@willson.li.ssimo.org> On Wed, 2013-02-27 at 09:55 +0530, Rajnesh Kumar Siwal wrote: > Is is still required if the replica is created using the following command:- > # ipa-replica-install --setup-ca --setup-dns In this case your new master has all required settings in place. Of course if you are using your main master as DNS server you may want to change your clients (or DHCP) configuration first to point them all at the new master, and wait to remove the former until all machines has switched to use the new DNS server. Simo. -- Simo Sorce * Red Hat, Inc * New York From Johan.Petersson at sscspace.com Wed Feb 27 14:01:15 2013 From: Johan.Petersson at sscspace.com (Johan Petersson) Date: Wed, 27 Feb 2013 14:01:15 +0000 Subject: [Freeipa-users] IPA,NFS4,krb5p Ticket expired error In-Reply-To: <558C15177F5E714F83334217C9A197DF7A554E90@SSC-MBX2.ssc.internal> References: <558C15177F5E714F83334217C9A197DF7A554DA4@SSC-MBX2.ssc.internal>, <512D0D39.80408@redhat.com>, <558C15177F5E714F83334217C9A197DF7A554E90@SSC-MBX2.ssc.internal> Message-ID: <558C15177F5E714F83334217C9A197DF7A554EBB@SSC-MBX2.ssc.internal> If i enable RPCGSSDARGS="-vvv" in one of the servers i can't ssh to i get the following in /var/log/messages: Feb 27 14:46:22 mail rpc.gssd[2210]: handling gssd upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt0) Feb 27 14:46:22 mail rpc.gssd[2210]: handle_gssd_upcall: 'mech=krb5 uid=1644800003 enctypes=18,17,16,23,3,1,2 ' Feb 27 14:46:22 mail rpc.gssd[2210]: handling krb5 upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt0) Feb 27 14:46:22 mail rpc.gssd[2210]: process_krb5_upcall: service is '' Feb 27 14:46:22 mail rpc.gssd[2210]: getting credentials for client with uid 1644800003 for server share.test.net Feb 27 14:46:22 mail rpc.gssd[2210]: CC file '/tmp/krb5cc_machine_TEST.NET' being considered, with preferred realm 'TEST.NET' Feb 27 14:46:22 mail rpc.gssd[2210]: CC file '/tmp/krb5cc_machine_TEST.NET' owned by 0, not 1644800003 Feb 27 14:46:22 mail rpc.gssd[2210]: CC file '/tmp/krb5cc_1644800003_8T4y9x' being considered, with preferred realm 'TEST.NET' Feb 27 14:46:22 mail rpc.gssd[2210]: CC file '/tmp/krb5cc_1644800003_8T4y9x' is expired or corrupt Feb 27 14:46:22 mail rpc.gssd[2210]: CC file '/tmp/krb5cc_0' being considered, with preferred realm 'TEST.NET' Feb 27 14:46:22 mail rpc.gssd[2210]: CC file '/tmp/krb5cc_0' owned by 0, not 1644800003 Feb 27 14:46:22 mail rpc.gssd[2210]: CC file '/tmp/krb5cc_1644800001_rNDIHA' being considered, with preferred realm 'TEST.NET' Feb 27 14:46:22 mail rpc.gssd[2210]: CC file '/tmp/krb5cc_1644800001_rNDIHA' owned by 1644800001, not 1644800003 Feb 27 14:46:22 mail rpc.gssd[2210]: WARNING: Failed to create krb5 context for user with uid 1644800003 for server share.test.net Feb 27 14:46:22 mail rpc.gssd[2210]: doing error downcall Regards, Johan. ________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Johan Petersson [Johan.Petersson at sscspace.com] Sent: Wednesday, February 27, 2013 14:15 To: dpal at redhat.com; freeipa-users at redhat.com Subject: Re: [Freeipa-users] IPA,NFS4,krb5p Ticket expired error I think you are right, ssh always works to the nfs server and i believe that is because the home directory is situated there. All ssh/sshd configuration are default from IPA Client install. Only things changed are the necessary autofs configuration and that is straight from the manual. I use strict NFS4 with port 2049 only open. (tried all firewalls and selinux disabled, no difference) Home directory is exported as: /nethomes 192.168.1.0(rw,sync,sec=krb5p) IPA autofs map default/auto_nethome * -fstype=nfs4 -sec=krb5p,rw,soft, share.test.net:/nethomes/& -fstype=nfs4 i had to use to get autofs working, through firewall and only port 2049 open it got crazy otherwise rambling about nfs2 and3 -sec=krb5p i had to put in autofs map since otherwise autofs ignored settings in exports and tried empty -o when mounting and thus failed because no kerberos auth. I have updated everything to RHEL 6.4 now but no change. Thunderbird complains that my ticket was not accepted. NFS server shows this in logs: rpc.gssd[2060]: ERROR: failed to read service info rpc.gssd[2060]: WARNING: can't create tcp rpc_clnt to server laptop1.test.net for user with uid 0: RPC: Remote system error - No route to host Network is fine and all firewalls down. Do you want any other logs beside debug autofs? Thanks for the help. Regards, Johan. ________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Dmitri Pal [dpal at redhat.com] Sent: Tuesday, February 26, 2013 20:30 To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] IPA,NFS4,krb5p Ticket expired error On 02/26/2013 02:03 PM, Johan Petersson wrote: Hi, I have a IPA server, NFS4 Server sharing home directories with autofs and krb5p as only valid authentication. Mail Postfix/Dovecot both with startTLS and GSSAPI. All servers and clients are Red Hat 6.3 and updated with latest kernel and everything else. If i start and log in locally as user1 on a IPA Client machine everything works perfect including mail and home directory initially. I then start experience errors when trying to ssh other servers as ssh user1 at mail.example.com. Nothing happens, no password question, nothing until i have to ctrl-c (tried leaving it overnight - still same). Mail stops working, thunderbird complain about expired credentials. If i use ssh as root to the server and then try either: su user1 or su - user1 both get same result as ssh user1. Sometimes a su have actually worked and i can browse to my mounted home directory but get permission denied when trying to access. id works and permissions on home directory shows ok but can't access anyway. The only thing i have found helping is to logout user1 on the client, login root and then ssh as user1. In that case i get password question and it works with home directory. If i logout root then, login user1 then mail, ssh and su works again for some time. I guess the credential renewal works in that case. Firewalls turned off, tried setenforce=0 and autofs on debug log mode but find nothing. Even sshd logging on and verbose ssh shows nothing wrong. It is like everything works but a expired ticket or something similar generate the error, tickets are new though and should be valid. Only error messages i have been able to find is: IPA server /var/log/messages show: rpc.gssd[1116]: Error doing stat on file '/tmp/krb5cc_48' automount[1197]: sasl_log_func:98: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Ticket expired) Anyone have a idea what this could be and how to solve it? I am really thankful for any help. Regards, Johan. This looks very much as if when you ssh into the remote system the home directory NFS mount fails. Can you try to configure a local directory and see if the problem goes away? If this helps then I would see what is going on with the NFS client on the system. Also I do not know how your SSH is configured. Does it actually delegate the ticket? AFAIU the system you SSH into needs to have a TGT to be able to mount an NFS share on behalf of the user. This is as far as I can go with what I know and what can be done without actually looking at the logs on the system. HTH _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbarr at snap-interactive.com Wed Feb 27 14:31:13 2013 From: mbarr at snap-interactive.com (Matthew Barr) Date: Wed, 27 Feb 2013 09:31:13 -0500 Subject: [Freeipa-users] Transferring "mastership" to a new server In-Reply-To: <1361973297.2962.57.camel@willson.li.ssimo.org> References: <1361973297.2962.57.camel@willson.li.ssimo.org> Message-ID: How about fixing up all the replication relationships, if you're looking at this from a (old) master w/ multiple replica's? Matthew From simo at redhat.com Wed Feb 27 15:37:37 2013 From: simo at redhat.com (Simo Sorce) Date: Wed, 27 Feb 2013 10:37:37 -0500 Subject: [Freeipa-users] Transferring "mastership" to a new server In-Reply-To: References: <1361973297.2962.57.camel@willson.li.ssimo.org> Message-ID: <1361979457.2962.69.camel@willson.li.ssimo.org> On Wed, 2013-02-27 at 09:31 -0500, Matthew Barr wrote: > How about fixing up all the replication relationships, if you're looking at this from a (old) master w/ multiple replica's? Look at the documentation of ipa-replica-manage on how to change replication topology. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Wed Feb 27 16:41:49 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 27 Feb 2013 11:41:49 -0500 Subject: [Freeipa-users] FQDN Hostname Requirement In-Reply-To: <20130227013252.GA21191@noboost.org> References: <20130227013252.GA21191@noboost.org> Message-ID: <512E374D.4050300@redhat.com> freeipa at noboost.org wrote: > Hi All, > > Spec: > Red Hat Enterprise Linux Server release 6.3 (Santiago) > ipa-server-2.2.0-16.el6.x86_64 > > Issue: > I made a post a while back regarding IPA and the forcing of the hostname > to be a FQDN entry, rather than utilising `hostname --fqdn` > > ref: https://www.redhat.com/archives/freeipa-users/2012-March/msg00012.html > > Has this issue ever been addressed? As I've now bumped into an issue > with RSA Securid Auth Manager 6.1, which will not work on a server with > more than 27 characters in the hostname. Sadly our hostname does break > this is some cases. I think Simo's answer in that thread is still true, there are many Kerberized programs that use gethostname() to create principals. If you removed this requirement you could be opening yourself up to other issues. rob From rcritten at redhat.com Wed Feb 27 16:43:16 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 27 Feb 2013 11:43:16 -0500 Subject: [Freeipa-users] Cannot obtain CA Certificate In-Reply-To: <512DE57A.403@redhat.com> References: <80D02259-925A-4529-943F-0ACAD7B77BB3@digitalreasoning.com> <20130219113502.GA21948@dibs.tanso.net> <9E4ACCDE-A5BF-4A1D-BFEA-6B8090D27B21@digitalreasoning.com> <512DD519.7060801@redhat.com> <20130227103410.GA19829@dibs.tanso.net> <512DE57A.403@redhat.com> Message-ID: <512E37A4.3040501@redhat.com> Petr Spacek wrote: > On 27.2.2013 11:34, Jan-Frode Myklebust wrote: >> On Wed, Feb 27, 2013 at 10:42:49AM +0100, Petr Spacek wrote: >>>> >>>> >>>> < HTTP/1.1 401 Authorization Required >>>> < Date: Tue, 26 Feb 2013 16:54:21 GMT >>>> < Server: Apache/2.2.15 (CentOS) >>>> * gss_init_sec_context() failed: : Server krbtgt/COM at EXAMPLE.COM not >>>> found in Kerberos database< WWW-Authenticate: Negotiate >> >> I have a similar problem getting a couple of RHEL 6.4 clients working >> with a 6.3 server (ipa-server-2.2.0-17.el6_3.1.x86_64). When doing the >> ipa-client-install I get: >> >> * gss_init_sec_context() failed: : Request is a replay< >> WWW-Authenticate: Negotiate > This is very suspicious. Could you double check time on all servers and > the client? > >> I have a ticket opened with RH-support for this (00796525), so I hope >> to get it fixed that way soonish.. but -- one strange thing about my >> problem is that I can't even get sssd working if I do a manual >> enrollment. I've tried doing ipa host-add, ipa host-add-managedby, >> ipa-getkeytab on the ipa-server, transferred the keytab, but still >> sssd fails to work. To get sssd working on this machine I had to >> configure an LDAP backend against the ipa-servers, without >> "ldap_sasl_mech=GSSAPI". >> >> Is there a simple way to verify that the hosts keytab is OK? >> "klist -k -t -K FILE:/etc/krb5.keytab" works fine, but I'd >> like to test it against the ipa-server. > > You can do kinit as host principal: > > $ klist -kt /etc/krb5.keytab > Keytab name: FILE:/etc/krb5.keytab > KVNO Timestamp Principal > ---- ----------------- --------------------------------- > 2 10/17/12 15:22:19 host/host.example.com at EXAMPLE.COM > > $ kinit -kt /etc/krb5.keytab host/host.example.com at EXAMPLE.COM > > $ klist > Ticket cache: FILE:/tmp/krb5cc_0 > Default principal: host/host.example.com at EXAMPLE.COM > > Valid starting Expires Service principal > 02/27/13 11:45:02 02/28/13 11:45:02 krbtgt/EXAMPLE.COM at EXAMPLE.COM > You can use kvno to see what the KDC things the version number should be, to compare to what is in the keytab. rob From rob.townley at gmail.com Wed Feb 27 17:12:11 2013 From: rob.townley at gmail.com (Rob Townley) Date: Wed, 27 Feb 2013 11:12:11 -0600 Subject: [Freeipa-users] IPA,NFS4,krb5p Ticket expired error In-Reply-To: <558C15177F5E714F83334217C9A197DF7A554E90@SSC-MBX2.ssc.internal> References: <558C15177F5E714F83334217C9A197DF7A554DA4@SSC-MBX2.ssc.internal> <512D0D39.80408@redhat.com> <558C15177F5E714F83334217C9A197DF7A554E90@SSC-MBX2.ssc.internal> Message-ID: /etc/exports does not look right. Try 192.168.1.0/24 or change to asterisk * On Wednesday, February 27, 2013, Johan Petersson < Johan.Petersson at sscspace.com> wrote: > I think you are right, ssh always works to the nfs server and i believe that is because the home directory is situated there. > > All ssh/sshd configuration are default from IPA Client install. > Only things changed are the necessary autofs configuration and that is straight from the manual. > > I use strict NFS4 with port 2049 only open. (tried all firewalls and selinux disabled, no difference) > Home directory is exported as: > /nethomes 192.168.1.0(rw,sync,sec=krb5p) > > IPA autofs map > default/auto_nethome * -fstype=nfs4 -sec=krb5p,rw,soft, share.test.net:/nethomes/& > > -fstype=nfs4 i had to use to get autofs working, through firewall and only port 2049 open it got crazy otherwise rambling about nfs2 and3 > -sec=krb5p i had to put in autofs map since otherwise autofs ignored settings in exports and tried empty -o when mounting and thus failed because no kerberos auth. > > I have updated everything to RHEL 6.4 now but no change. > > Thunderbird complains that my ticket was not accepted. > > NFS server shows this in logs: > rpc.gssd[2060]: ERROR: failed to read service info > rpc.gssd[2060]: WARNING: can't create tcp rpc_clnt to server laptop1.test.net for user with uid 0: RPC: Remote system error - No route to host > > Network is fine and all firewalls down. > Do you want any other logs beside debug autofs? > > Thanks for the help. > > Regards, > Johan. > > > > ________________________________ > From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Dmitri Pal [dpal at redhat.com] > Sent: Tuesday, February 26, 2013 20:30 > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] IPA,NFS4,krb5p Ticket expired error > > On 02/26/2013 02:03 PM, Johan Petersson wrote: > > Hi, > I have a IPA server, NFS4 Server sharing home directories with autofs and krb5p as only valid authentication. > Mail Postfix/Dovecot both with startTLS and GSSAPI. > All servers and clients are Red Hat 6.3 and updated with latest kernel and everything else. > If i start and log in locally as user1 on a IPA Client machine everything works perfect including mail and home directory initially. > I then start experience errors when trying to ssh other servers as ssh user1 at mail.example.com. > Nothing happens, no password question, nothing until i have to ctrl-c (tried leaving it overnight - still same). > Mail stops working, thunderbird complain about expired credentials. > If i use ssh as root to the server and then try either: su user1 or su - user1 both get same result as ssh user1. > Sometimes a su have actually worked and i can browse to my mounted home directory but get permission denied when trying to access. > id works and permissions on home directory shows ok but can't access anyway. > The only thing i have found helping is to logout user1 on the client, login root and then ssh as user1. > In that case i get password question and it works with home directory. > If i logout root then, login user1 then mail, ssh and su works again for some time. > I guess the credential renewal works in that case. > Firewalls turned off, tried setenforce=0 and autofs on debug log mode but find nothing. > Even sshd logging on and verbose ssh shows nothing wrong. > It is like everything works but a expired ticket or something similar generate the error, tickets are new though and should be valid. > Only error messages i have been able to find is: > IPA server /var/log/messages show: > rpc.gssd[1116]: Error doing stat on file '/tmp/krb5cc_48' > automount[1197]: sasl_log_func:98: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Ticket expired) > Anyone have a idea what this could be and how to solve it? > I am really thankful for any help. > Regards, > Johan. > > This looks very much as if when you ssh into the remote system the home directory NFS mount fails. > Can you try to configure a local directory and see if the problem goes away? If this helps then I would see what is going on with the NFS client on the system. > > Also I do not know how your SSH is configured. Does it actually delegate the ticket? > AFAIU the system you SSH into needs to have a TGT to be able to mount an NFS share on behalf of the user. > This is as far as I can go with what I know and what can be done without actually looking at the logs on the system. > > HTH > > > > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT co -------------- next part -------------- An HTML attachment was scrubbed... URL: From chip at innovates.com Wed Feb 27 18:35:45 2013 From: chip at innovates.com (Schweiss, Chip) Date: Wed, 27 Feb 2013 12:35:45 -0600 Subject: [Freeipa-users] Generate wildcard cert with FreeIPA CA Message-ID: Is it possible to generate a wild card certificate with the FreeIPA CA? I tried generating a CSR with *.mydomain.local but 'ipa cert-request star.mydomain.local.csr --principal=HTTP/*.mydomain.localr --add' returns the error: ipa: ERROR: The service principal for this request doesn't exist. No problem generating certs for fqdn of systems I have already joined to the domain. Is there anyway around this to generate a wildcard cert for my local domain? Thanks! -Chip -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed Feb 27 18:54:25 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 27 Feb 2013 13:54:25 -0500 Subject: [Freeipa-users] Generate wildcard cert with FreeIPA CA In-Reply-To: References: Message-ID: <512E5661.4020409@redhat.com> Schweiss, Chip wrote: > Is it possible to generate a wild card certificate with the FreeIPA CA? > > I tried generating a CSR with *.mydomain.local but 'ipa cert-request > star.mydomain.local.csr --principal=HTTP/*.mydomain.localr --add' > returns the error: > > ipa: ERROR: The service principal for this request doesn't exist. > > No problem generating certs for fqdn of systems I have already joined to > the domain. > > Is there anyway around this to generate a wildcard cert for my local domain? Not using the IPA interfaces, no. There might be a way to do this by calling out to the underlying dogtag CA directly but we don't provide any mechanism to do that. You'd be on your own there. rob From simo at redhat.com Wed Feb 27 19:00:38 2013 From: simo at redhat.com (Simo Sorce) Date: Wed, 27 Feb 2013 14:00:38 -0500 Subject: [Freeipa-users] Generate wildcard cert with FreeIPA CA In-Reply-To: <512E5661.4020409@redhat.com> References: <512E5661.4020409@redhat.com> Message-ID: <1361991638.2962.81.camel@willson.li.ssimo.org> On Wed, 2013-02-27 at 13:54 -0500, Rob Crittenden wrote: > Schweiss, Chip wrote: > > Is it possible to generate a wild card certificate with the FreeIPA CA? > > > > I tried generating a CSR with *.mydomain.local but 'ipa cert-request > > star.mydomain.local.csr --principal=HTTP/*.mydomain.localr --add' > > returns the error: > > > > ipa: ERROR: The service principal for this request doesn't exist. > > > > No problem generating certs for fqdn of systems I have already joined to > > the domain. > > > > Is there anyway around this to generate a wildcard cert for my local domain? > > Not using the IPA interfaces, no. There might be a way to do this by > calling out to the underlying dogtag CA directly but we don't provide > any mechanism to do that. You'd be on your own there. Feel free to open a RFE in our trac instance if you need this functionality. Simo. -- Simo Sorce * Red Hat, Inc * New York From Johan.Petersson at sscspace.com Wed Feb 27 19:20:52 2013 From: Johan.Petersson at sscspace.com (Johan Petersson) Date: Wed, 27 Feb 2013 19:20:52 +0000 Subject: [Freeipa-users] IPA,NFS4,krb5p Ticket expired error In-Reply-To: References: <558C15177F5E714F83334217C9A197DF7A554DA4@SSC-MBX2.ssc.internal> <512D0D39.80408@redhat.com> <558C15177F5E714F83334217C9A197DF7A554E90@SSC-MBX2.ssc.internal>, Message-ID: <558C15177F5E714F83334217C9A197DF7A554F3C@SSC-MBX2.ssc.internal> A typo from me, it is 192.168.1/24 in exports. Regards Johan ______________________________________ From: Rob Townley [rob.townley at gmail.com] Sent: Wednesday, February 27, 2013 18:12 To: Johan Petersson Cc: dpal at redhat.com; freeipa-users at redhat.com Subject: Re: [Freeipa-users] IPA,NFS4,krb5p Ticket expired error /etc/exports does not look right. Try 192.168.1.0/24 or change to asterisk * On Wednesday, February 27, 2013, Johan Petersson > wrote: > I think you are right, ssh always works to the nfs server and i believe that is because the home directory is situated there. > > All ssh/sshd configuration are default from IPA Client install. > Only things changed are the necessary autofs configuration and that is straight from the manual. > > I use strict NFS4 with port 2049 only open. (tried all firewalls and selinux disabled, no difference) > Home directory is exported as: > /nethomes 192.168.1.0(rw,sync,sec=krb5p) > > IPA autofs map > default/auto_nethome * -fstype=nfs4 -sec=krb5p,rw,soft, share.test.net:/nethomes/& > > -fstype=nfs4 i had to use to get autofs working, through firewall and only port 2049 open it got crazy otherwise rambling about nfs2 and3 > -sec=krb5p i had to put in autofs map since otherwise autofs ignored settings in exports and tried empty -o when mounting and thus failed because no kerberos auth. > > I have updated everything to RHEL 6.4 now but no change. > > Thunderbird complains that my ticket was not accepted. > > NFS server shows this in logs: > rpc.gssd[2060]: ERROR: failed to read service info > rpc.gssd[2060]: WARNING: can't create tcp rpc_clnt to server laptop1.test.net for user with uid 0: RPC: Remote system error - No route to host > > Network is fine and all firewalls down. > Do you want any other logs beside debug autofs? > > Thanks for the help. > > Regards, > Johan. > > > > ________________________________ > From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Dmitri Pal [dpal at redhat.com] > Sent: Tuesday, February 26, 2013 20:30 > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] IPA,NFS4,krb5p Ticket expired error > > On 02/26/2013 02:03 PM, Johan Petersson wrote: > > Hi, > I have a IPA server, NFS4 Server sharing home directories with autofs and krb5p as only valid authentication. > Mail Postfix/Dovecot both with startTLS and GSSAPI. > All servers and clients are Red Hat 6.3 and updated with latest kernel and everything else. > If i start and log in locally as user1 on a IPA Client machine everything works perfect including mail and home directory initially. > I then start experience errors when trying to ssh other servers as ssh user1 at mail.example.com. > Nothing happens, no password question, nothing until i have to ctrl-c (tried leaving it overnight - still same). > Mail stops working, thunderbird complain about expired credentials. > If i use ssh as root to the server and then try either: su user1 or su - user1 both get same result as ssh user1. > Sometimes a su have actually worked and i can browse to my mounted home directory but get permission denied when trying to access. > id works and permissions on home directory shows ok but can't access anyway. > The only thing i have found helping is to logout user1 on the client, login root and then ssh as user1. > In that case i get password question and it works with home directory. > If i logout root then, login user1 then mail, ssh and su works again for some time. > I guess the credential renewal works in that case. > Firewalls turned off, tried setenforce=0 and autofs on debug log mode but find nothing. > Even sshd logging on and verbose ssh shows nothing wrong. > It is like everything works but a expired ticket or something similar generate the error, tickets are new though and should be valid. > Only error messages i have been able to find is: > IPA server /var/log/messages show: > rpc.gssd[1116]: Error doing stat on file '/tmp/krb5cc_48' > automount[1197]: sasl_log_func:98: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Ticket expired) > Anyone have a idea what this could be and how to solve it? > I am really thankful for any help. > Regards, > Johan. > > This looks very much as if when you ssh into the remote system the home directory NFS mount fails. > Can you try to configure a local directory and see if the problem goes away? If this helps then I would see what is going on with the NFS client on the system. > > Also I do not know how your SSH is configured. Does it actually delegate the ticket? > AFAIU the system you SSH into needs to have a TGT to be able to mount an NFS share on behalf of the user. > This is as far as I can go with what I know and what can be done without actually looking at the logs on the system. > > HTH > > > > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT co From rcritten at redhat.com Wed Feb 27 20:10:15 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 27 Feb 2013 15:10:15 -0500 Subject: [Freeipa-users] IPA,NFS4,krb5p Ticket expired error In-Reply-To: <558C15177F5E714F83334217C9A197DF7A554F3C@SSC-MBX2.ssc.internal> References: <558C15177F5E714F83334217C9A197DF7A554DA4@SSC-MBX2.ssc.internal> <512D0D39.80408@redhat.com> <558C15177F5E714F83334217C9A197DF7A554E90@SSC-MBX2.ssc.internal>, <558C15177F5E714F83334217C9A197DF7A554F3C@SSC-MBX2.ssc.internal> Message-ID: <512E6827.9090107@redhat.com> Johan Petersson wrote: > > A typo from me, it is 192.168.1/24 in exports. Do you have forwardable tickets? $ klist -f It should have F in the flags. If so, try adding -o 'GSSAPIDelegateCredentials yes' into your ssh/slogin line to see if that helps. This should forward your credentials. rob > > Regards > Johan > > ______________________________________ > From: Rob Townley [rob.townley at gmail.com] > Sent: Wednesday, February 27, 2013 18:12 > To: Johan Petersson > Cc: dpal at redhat.com; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] IPA,NFS4,krb5p Ticket expired error > > /etc/exports does not look right. > Try 192.168.1.0/24 > or change to asterisk * > > On Wednesday, February 27, 2013, Johan Petersson > wrote: >> I think you are right, ssh always works to the nfs server and i believe that is because the home directory is situated there. >> >> All ssh/sshd configuration are default from IPA Client install. >> Only things changed are the necessary autofs configuration and that is straight from the manual. >> >> I use strict NFS4 with port 2049 only open. (tried all firewalls and selinux disabled, no difference) >> Home directory is exported as: >> /nethomes 192.168.1.0(rw,sync,sec=krb5p) >> >> IPA autofs map >> default/auto_nethome * -fstype=nfs4 -sec=krb5p,rw,soft, share.test.net:/nethomes/& >> >> -fstype=nfs4 i had to use to get autofs working, through firewall and only port 2049 open it got crazy otherwise rambling about nfs2 and3 >> -sec=krb5p i had to put in autofs map since otherwise autofs ignored settings in exports and tried empty -o when mounting and thus failed because no kerberos auth. >> >> I have updated everything to RHEL 6.4 now but no change. >> >> Thunderbird complains that my ticket was not accepted. >> >> NFS server shows this in logs: >> rpc.gssd[2060]: ERROR: failed to read service info >> rpc.gssd[2060]: WARNING: can't create tcp rpc_clnt to server laptop1.test.net for user with uid 0: RPC: Remote system error - No route to host >> >> Network is fine and all firewalls down. >> Do you want any other logs beside debug autofs? >> >> Thanks for the help. >> >> Regards, >> Johan. >> >> >> >> ________________________________ >> From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Dmitri Pal [dpal at redhat.com] >> Sent: Tuesday, February 26, 2013 20:30 >> To: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] IPA,NFS4,krb5p Ticket expired error >> >> On 02/26/2013 02:03 PM, Johan Petersson wrote: >> >> Hi, >> I have a IPA server, NFS4 Server sharing home directories with autofs and krb5p as only valid authentication. >> Mail Postfix/Dovecot both with startTLS and GSSAPI. >> All servers and clients are Red Hat 6.3 and updated with latest kernel and everything else. >> If i start and log in locally as user1 on a IPA Client machine everything works perfect including mail and home directory initially. >> I then start experience errors when trying to ssh other servers as ssh user1 at mail.example.com. >> Nothing happens, no password question, nothing until i have to ctrl-c (tried leaving it overnight - still same). >> Mail stops working, thunderbird complain about expired credentials. >> If i use ssh as root to the server and then try either: su user1 or su - user1 both get same result as ssh user1. >> Sometimes a su have actually worked and i can browse to my mounted home directory but get permission denied when trying to access. >> id works and permissions on home directory shows ok but can't access anyway. >> The only thing i have found helping is to logout user1 on the client, login root and then ssh as user1. >> In that case i get password question and it works with home directory. >> If i logout root then, login user1 then mail, ssh and su works again for some time. >> I guess the credential renewal works in that case. >> Firewalls turned off, tried setenforce=0 and autofs on debug log mode but find nothing. >> Even sshd logging on and verbose ssh shows nothing wrong. >> It is like everything works but a expired ticket or something similar generate the error, tickets are new though and should be valid. >> Only error messages i have been able to find is: >> IPA server /var/log/messages show: >> rpc.gssd[1116]: Error doing stat on file '/tmp/krb5cc_48' >> automount[1197]: sasl_log_func:98: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Ticket expired) >> Anyone have a idea what this could be and how to solve it? >> I am really thankful for any help. >> Regards, >> Johan. >> >> This looks very much as if when you ssh into the remote system the home directory NFS mount fails. >> Can you try to configure a local directory and see if the problem goes away? If this helps then I would see what is going on with the NFS client on the system. >> >> Also I do not know how your SSH is configured. Does it actually delegate the ticket? >> AFAIU the system you SSH into needs to have a TGT to be able to mount an NFS share on behalf of the user. >> This is as far as I can go with what I know and what can be done without actually looking at the logs on the system. >> >> HTH >> >> >> >> >> >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager for IdM portfolio >> Red Hat Inc. >> >> >> ------------------------------- >> Looking to carve out IT co > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > From Johan.Petersson at sscspace.com Thu Feb 28 07:11:54 2013 From: Johan.Petersson at sscspace.com (Johan Petersson) Date: Thu, 28 Feb 2013 07:11:54 +0000 Subject: [Freeipa-users] IPA,NFS4,krb5p Ticket expired error In-Reply-To: <512E6827.9090107@redhat.com> References: <558C15177F5E714F83334217C9A197DF7A554DA4@SSC-MBX2.ssc.internal> <512D0D39.80408@redhat.com> <558C15177F5E714F83334217C9A197DF7A554E90@SSC-MBX2.ssc.internal>, <558C15177F5E714F83334217C9A197DF7A554F3C@SSC-MBX2.ssc.internal>, <512E6827.9090107@redhat.com> Message-ID: <558C15177F5E714F83334217C9A197DF7A554F8B@SSC-MBX2.ssc.internal> These lines come up on every server i try connecting to when using -vvv for rpcgssapi on the server: Feb 27 14:46:22 mail rpc.gssd[2210]: CC file '/tmp/krb5cc_1644800003_8T4y9x' being considered, with preferred realm 'TEST.NET' Feb 27 14:46:22 mail rpc.gssd[2210]: CC file '/tmp/krb5cc_1644800003_8T4y9x' is expired or corrupt Feb 27 14:46:22 mail rpc.gssd[2210]: WARNING: Failed to create krb5 context for user with uid 1644800003 for server share.test.net Feb 27 14:46:22 mail rpc.gssd[2210]: doing error downcall the user with uid 1644800003 is the one i try connect with and are logged in locally on connecting client. Also on the IPA server i get this line on every connection attempt to any server: rpc.gssd[1116]: Error doing stat on file '/tmp/krb5cc_48' Regards, Johan ________________________________________ From: Rob Crittenden [rcritten at redhat.com] Sent: Wednesday, February 27, 2013 21:10 To: Johan Petersson Cc: Rob.Townley at gmail.com; freeipa-users at redhat.com Subject: Re: [Freeipa-users] IPA,NFS4,krb5p Ticket expired error Johan Petersson wrote: > > A typo from me, it is 192.168.1/24 in exports. Do you have forwardable tickets? $ klist -f It should have F in the flags. If so, try adding -o 'GSSAPIDelegateCredentials yes' into your ssh/slogin line to see if that helps. This should forward your credentials. rob > > Regards > Johan > > ______________________________________ > From: Rob Townley [rob.townley at gmail.com] > Sent: Wednesday, February 27, 2013 18:12 > To: Johan Petersson > Cc: dpal at redhat.com; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] IPA,NFS4,krb5p Ticket expired error > > /etc/exports does not look right. > Try 192.168.1.0/24 > or change to asterisk * > > On Wednesday, February 27, 2013, Johan Petersson > wrote: >> I think you are right, ssh always works to the nfs server and i believe that is because the home directory is situated there. >> >> All ssh/sshd configuration are default from IPA Client install. >> Only things changed are the necessary autofs configuration and that is straight from the manual. >> >> I use strict NFS4 with port 2049 only open. (tried all firewalls and selinux disabled, no difference) >> Home directory is exported as: >> /nethomes 192.168.1.0(rw,sync,sec=krb5p) >> >> IPA autofs map >> default/auto_nethome * -fstype=nfs4 -sec=krb5p,rw,soft, share.test.net:/nethomes/& >> >> -fstype=nfs4 i had to use to get autofs working, through firewall and only port 2049 open it got crazy otherwise rambling about nfs2 and3 >> -sec=krb5p i had to put in autofs map since otherwise autofs ignored settings in exports and tried empty -o when mounting and thus failed because no kerberos auth. >> >> I have updated everything to RHEL 6.4 now but no change. >> >> Thunderbird complains that my ticket was not accepted. >> >> NFS server shows this in logs: >> rpc.gssd[2060]: ERROR: failed to read service info >> rpc.gssd[2060]: WARNING: can't create tcp rpc_clnt to server laptop1.test.net for user with uid 0: RPC: Remote system error - No route to host >> >> Network is fine and all firewalls down. >> Do you want any other logs beside debug autofs? >> >> Thanks for the help. >> >> Regards, >> Johan. >> >> >> >> ________________________________ >> From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Dmitri Pal [dpal at redhat.com] >> Sent: Tuesday, February 26, 2013 20:30 >> To: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] IPA,NFS4,krb5p Ticket expired error >> >> On 02/26/2013 02:03 PM, Johan Petersson wrote: >> >> Hi, >> I have a IPA server, NFS4 Server sharing home directories with autofs and krb5p as only valid authentication. >> Mail Postfix/Dovecot both with startTLS and GSSAPI. >> All servers and clients are Red Hat 6.3 and updated with latest kernel and everything else. >> If i start and log in locally as user1 on a IPA Client machine everything works perfect including mail and home directory initially. >> I then start experience errors when trying to ssh other servers as ssh user1 at mail.example.com. >> Nothing happens, no password question, nothing until i have to ctrl-c (tried leaving it overnight - still same). >> Mail stops working, thunderbird complain about expired credentials. >> If i use ssh as root to the server and then try either: su user1 or su - user1 both get same result as ssh user1. >> Sometimes a su have actually worked and i can browse to my mounted home directory but get permission denied when trying to access. >> id works and permissions on home directory shows ok but can't access anyway. >> The only thing i have found helping is to logout user1 on the client, login root and then ssh as user1. >> In that case i get password question and it works with home directory. >> If i logout root then, login user1 then mail, ssh and su works again for some time. >> I guess the credential renewal works in that case. >> Firewalls turned off, tried setenforce=0 and autofs on debug log mode but find nothing. >> Even sshd logging on and verbose ssh shows nothing wrong. >> It is like everything works but a expired ticket or something similar generate the error, tickets are new though and should be valid. >> Only error messages i have been able to find is: >> IPA server /var/log/messages show: >> rpc.gssd[1116]: Error doing stat on file '/tmp/krb5cc_48' >> automount[1197]: sasl_log_func:98: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Ticket expired) >> Anyone have a idea what this could be and how to solve it? >> I am really thankful for any help. >> Regards, >> Johan. >> >> This looks very much as if when you ssh into the remote system the home directory NFS mount fails. >> Can you try to configure a local directory and see if the problem goes away? If this helps then I would see what is going on with the NFS client on the system. >> >> Also I do not know how your SSH is configured. Does it actually delegate the ticket? >> AFAIU the system you SSH into needs to have a TGT to be able to mount an NFS share on behalf of the user. >> This is as far as I can go with what I know and what can be done without actually looking at the logs on the system. >> >> HTH >> >> >> >> >> >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager for IdM portfolio >> Red Hat Inc. >> >> >> ------------------------------- >> Looking to carve out IT co > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > From sakodak at gmail.com Thu Feb 28 21:18:58 2013 From: sakodak at gmail.com (KodaK) Date: Thu, 28 Feb 2013 15:18:58 -0600 Subject: [Freeipa-users] What does the "u" mean in IPA messages? Message-ID: When performing an operation with the IPA tools, I get a message every time similar to this: ipa: INFO: Forwarding 'hbactest' to server u'https://ipaserver/ipa/xml' What does it mean? I've never seen it say anything other than "u" (that I've noticed.) A pointer to documentation is preferred, but I've been looking and haven't found anything. (Lots of stuff on the International Phonetic Alphabet's use of "u" though. I think I'm qualified to edit dictionaries now.) Thanks! -- The government is going to read our mail anyway, might as well make it tough for them. GPG Public key ID: B6A1A7C6 From jdennis at redhat.com Thu Feb 28 21:27:25 2013 From: jdennis at redhat.com (John Dennis) Date: Thu, 28 Feb 2013 16:27:25 -0500 Subject: [Freeipa-users] What does the "u" mean in IPA messages? In-Reply-To: References: Message-ID: <512FCBBD.30209@redhat.com> On 02/28/2013 04:18 PM, KodaK wrote: > When performing an operation with the IPA tools, I get a message every > time similar to this: > > ipa: INFO: Forwarding 'hbactest' to server u'https://ipaserver/ipa/xml' > > What does it mean? I've never seen it say anything other than "u" > (that I've noticed.) A pointer to documentation is preferred, but > I've been looking and haven't found anything. (Lots of stuff on the > International Phonetic Alphabet's use of "u" though. I think I'm > qualified to edit dictionaries now.) It means unicode, It's a Python'ism. In Python2 there are two different string types str and unicode. str's are have 8-bit characters, unicode have wide characters (either 16-bit UCS2 or 32-bit UCS4) depending on how Python was built (unicode is UCS4 on our builds). Since IPA in internationalized we use unicode for all strings. What the u prefix is telling you is the type of the string. The only reason you see it is because in some places we use the repr method to output string data and the repr method prefixes unicode with a u character. We've been fixing places where repr method is used, not sure if this is one of those or not. We were using repr because early on we were not consistent with whether we used str's or unicode objects and it was handy to know the difference, it's not so much of an issue any more. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rmercer at harris.com Thu Feb 28 22:07:09 2013 From: rmercer at harris.com (Rodney L. Mercer) Date: Thu, 28 Feb 2013 17:07:09 -0500 Subject: [Freeipa-users] RHEL6 IPA and Active Directory synchronisation and Solaris RBAC In-Reply-To: <512D0E43.6000303@redhat.com> References: <511BACEE.8050900@redhat.com> <511D2541.1000201@nixtra.com> <511D2CAC.6050400@redhat.com> <511D4693.8010502@redhat.com> <1360937840.21935.556.camel@osc145.evn.harris.com> <511EA93C.8060909@redhat.com>,<511F6D98.30700@nixtra.com> <512A3AF8DAE8454D95C05141F746ECE1512AC316@MLBMXUS21.cs.myharris.net> <512121E9.2050608@redhat.com> <1361283261.21935.914.camel@osc145.evn.harris.com> <51242F73.9000309@redhat.com> <1361367894.21935.1033.camel@osc145.evn.harris.com> <5125E083.3040506@redhat.com> <512A3AF8DAE8454D95C05141F746ECE1512E84A0@MLBMXUS21.cs.myharris.net> <512A3AF8DAE8454D95C05141F746ECE1512E84F4@MLBMXUS21.cs.myharris.net> <512D0E43.6000303@redhat.com> Message-ID: <1362089229.4209.84.camel@osc145.evn.harris.com> What is the preferred IPA platform for performing this endeavor? Would it be best to create an environment, virtual or physical, that has RHEL6 update 4 fully patched and IdM installed? or would Fedora 18 with the http://jdennis.fedorapeople.org/ipa-devel/fedora/18/x86_64/os/ yum repository enabled be better for this development? Thanks, Rodney. On Tue, 2013-02-26 at 14:34 -0500, Dmitri Pal wrote: > On 02/25/2013 02:29 PM, Mercer, Rodney wrote: > > I think that this is a good explanation or the solaris rbac model. > > > > http://www.softpanorama.org/Solaris/Security/solaris_rbac.shtml > > > > Regards, > > Rodney. > I will definitely read it. But assume I did. > What are the next steps? > The schema is the right one so do you plan to start the design work? > Would you start with the server side or with SSSD side? > > Adding schema to IPA and populating it with ldap modify or my loading > ldif might give you enough to start designing and developing the SSSD > component. The management interface for the server side can be added > after the SSSD side is done. > From rcritten at redhat.com Thu Feb 28 22:27:36 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 28 Feb 2013 17:27:36 -0500 Subject: [Freeipa-users] RHEL6 IPA and Active Directory synchronisation and Solaris RBAC In-Reply-To: <1362089229.4209.84.camel@osc145.evn.harris.com> References: <511BACEE.8050900@redhat.com> <511D2541.1000201@nixtra.com> <511D2CAC.6050400@redhat.com> <511D4693.8010502@redhat.com> <1360937840.21935.556.camel@osc145.evn.harris.com> <511EA93C.8060909@redhat.com>, <511F6D98.30700@nixtra.com> <512A3AF8DAE8454D95C05141F746ECE1512AC316@MLBMXUS21.cs.myharris.net> <512121E9.2050608@redhat.com> <1361283261.21935.914.camel@osc145.evn.harris.com> <51242F73.9000309@redhat.com> <1361367894.21935.1033.camel@osc145.evn.harris.com> <5125E083.3040506@redhat.com> <512A3AF8DAE8454D95C05141F746ECE1512E84A0@MLBMXUS21.cs.myharris.net> <512A3AF8DAE8454D95C05141F746ECE1512E84F4@MLBMXUS21.cs.myharris.net> <512D0E43.6000303@redhat.com> <1362089229.4209.84.camel@osc145.evn.harris.com> Message-ID: <512FD9D8.7090603@redhat.com> Rodney L. Mercer wrote: > What is the preferred IPA platform for performing this endeavor? > > Would it be best to create an environment, virtual or physical, that has > RHEL6 update 4 fully patched and IdM installed? > or would > Fedora 18 with the > http://jdennis.fedorapeople.org/ipa-devel/fedora/18/x86_64/os/ > yum repository enabled be better for this development? Building from git would make it easier to manage the changes and get the submitted upstream, otherwise I'd say go with F-18 builds as they are closer to the master branch than RHEL 6.4 (which is based on 3.0). regards rob > > Thanks, > Rodney. > > On Tue, 2013-02-26 at 14:34 -0500, Dmitri Pal wrote: >> On 02/25/2013 02:29 PM, Mercer, Rodney wrote: >>> I think that this is a good explanation or the solaris rbac model. >>> >>> http://www.softpanorama.org/Solaris/Security/solaris_rbac.shtml >>> >>> Regards, >>> Rodney. >> I will definitely read it. But assume I did. >> What are the next steps? >> The schema is the right one so do you plan to start the design work? >> Would you start with the server side or with SSSD side? >> >> Adding schema to IPA and populating it with ldap modify or my loading >> ldif might give you enough to start designing and developing the SSSD >> component. The management interface for the server side can be added >> after the SSSD side is done. >> > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > From sakodak at gmail.com Thu Feb 28 22:34:38 2013 From: sakodak at gmail.com (KodaK) Date: Thu, 28 Feb 2013 16:34:38 -0600 Subject: [Freeipa-users] What does the "u" mean in IPA messages? In-Reply-To: <512FCBBD.30209@redhat.com> References: <512FCBBD.30209@redhat.com> Message-ID: On Thu, Feb 28, 2013 at 3:27 PM, John Dennis wrote: > On 02/28/2013 04:18 PM, KodaK wrote: >> >> When performing an operation with the IPA tools, I get a message every >> time similar to this: >> >> ipa: INFO: Forwarding 'hbactest' to server u'https://ipaserver/ipa/xml' >> >> What does it mean? I've never seen it say anything other than "u" >> (that I've noticed.) A pointer to documentation is preferred, but >> I've been looking and haven't found anything. (Lots of stuff on the >> International Phonetic Alphabet's use of "u" though. I think I'm >> qualified to edit dictionaries now.) > > > It means unicode, It's a Python'ism. In Python2 there are two different > string types str and unicode. str's are have 8-bit characters, unicode have > wide characters (either 16-bit UCS2 or 32-bit UCS4) depending on how Python > was built (unicode is UCS4 on our builds). Since IPA in internationalized we > use unicode for all strings. > > What the u prefix is telling you is the type of the string. The only reason > you see it is because in some places we use the repr method to output string > data and the repr method prefixes unicode with a u character. We've been > fixing places where repr method is used, not sure if this is one of those or > not. We were using repr because early on we were not consistent with whether > we used str's or unicode objects and it was handy to know the difference, > it's not so much of an issue any more. Ah, thanks for the explanation. If I build parsing scripts for things, is the "u" going to disappear in the future with the discontinuation of the repr method? (That's what set this off in the first place.) From jdennis at redhat.com Thu Feb 28 23:01:18 2013 From: jdennis at redhat.com (John Dennis) Date: Thu, 28 Feb 2013 18:01:18 -0500 Subject: [Freeipa-users] What does the "u" mean in IPA messages? In-Reply-To: References: <512FCBBD.30209@redhat.com> Message-ID: <512FE1BE.50501@redhat.com> On 02/28/2013 05:34 PM, KodaK wrote: > On Thu, Feb 28, 2013 at 3:27 PM, John Dennis wrote: >> On 02/28/2013 04:18 PM, KodaK wrote: >>> >>> When performing an operation with the IPA tools, I get a message every >>> time similar to this: >>> >>> ipa: INFO: Forwarding 'hbactest' to server u'https://ipaserver/ipa/xml' >>> >>> What does it mean? I've never seen it say anything other than "u" >>> (that I've noticed.) A pointer to documentation is preferred, but >>> I've been looking and haven't found anything. (Lots of stuff on the >>> International Phonetic Alphabet's use of "u" though. I think I'm >>> qualified to edit dictionaries now.) >> >> >> It means unicode, It's a Python'ism. In Python2 there are two different >> string types str and unicode. str's are have 8-bit characters, unicode have >> wide characters (either 16-bit UCS2 or 32-bit UCS4) depending on how Python >> was built (unicode is UCS4 on our builds). Since IPA in internationalized we >> use unicode for all strings. >> >> What the u prefix is telling you is the type of the string. The only reason >> you see it is because in some places we use the repr method to output string >> data and the repr method prefixes unicode with a u character. We've been >> fixing places where repr method is used, not sure if this is one of those or >> not. We were using repr because early on we were not consistent with whether >> we used str's or unicode objects and it was handy to know the difference, >> it's not so much of an issue any more. > > Ah, thanks for the explanation. If I build parsing scripts for > things, is the "u" going to disappear in the future with the > discontinuation of the repr method? (That's what set this off in the > first place.) You should not depend on the type prefix. There are other prefixes besides u but I think u is the only one you'll see in practice. My suggestion for parsing would be to permit the prefix but to ignore it if it's present. BTW, why are you parsing diagnostic output? They are not part of the official API. We do not have any consistency rules for INFO and DEBUG messages, they can change at any time and often do. On the other hand command output is fairly consistent and not subject to the capricious whims of developers. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/