From rcritten at redhat.com Tue Jul 6 17:54:24 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 06 Jul 2010 13:54:24 -0400 Subject: [Freeipa-users] Fedora 13 client login problems In-Reply-To: <4C28E61B.4060009@redhat.com> References: <4C28E61B.4060009@redhat.com> Message-ID: <4C336DD0.6090405@redhat.com> Stephen Gallagher wrote: > On 06/28/2010 12:14 PM, Dan Scott wrote: >> Hello, >> >> I've just installed a new Fedora 13 client and configured it to use >> FreeIPA. During ipa-client install, I received the following error: >> >> nss_ldap is not able to use DNS discovery! However, the /etc/ldap.conf >> and /etc/krb5.conf appear to be configured correctly. >> >> I am unable to login to the machine. Here is an extract from >> /var/log/secure: >> >> Jun 28 12:12:01 pc45 sshd[2263]: Invalid user djscott from 192.168.1.35 >> Jun 28 12:12:01 pc45 sshd[2264]: input_userauth_request: invalid user >> djscott >> Jun 28 12:12:07 pc45 sshd[2263]: pam_unix(sshd:auth): check pass; user >> unknown >> Jun 28 12:12:07 pc45 sshd[2263]: pam_unix(sshd:auth): authentication >> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=pc35.example.com >> Jun 28 12:12:07 pc45 sshd[2263]: pam_succeed_if(sshd:auth): error >> retrieving information about user djscott >> Jun 28 12:12:09 pc45 sshd[2263]: Failed password for invalid user >> djscott from 192.168.1.35 port 50502 ssh2 >> >> Here is the PAM configuration: >> >> [root at pc45 ~]# cat /etc/pam.d/sshd >> #%PAM-1.0 >> auth required pam_sepermit.so >> auth include password-auth >> account required pam_nologin.so >> account include password-auth >> password include password-auth >> # pam_selinux.so close should be the first session rule >> session required pam_selinux.so close >> session required pam_loginuid.so >> # pam_selinux.so open should only be followed by sessions to be >> executed in the user context >> session required pam_selinux.so open env_params >> #session optional pam_keyinit.so force revoke >> session include password-auth >> >> [root at pc45 ~]# cat /etc/pam.d/password-auth >> #%PAM-1.0 >> # This file is auto-generated. >> # User changes will be destroyed the next time authconfig is run. >> auth required pam_env.so >> auth sufficient pam_unix.so nullok try_first_pass >> auth requisite pam_succeed_if.so uid>= 500 quiet >> auth sufficient pam_krb5.so use_first_pass >> auth required pam_deny.so >> >> account required pam_unix.so broken_shadow >> account sufficient pam_localuser.so >> account sufficient pam_succeed_if.so uid< 500 quiet >> account [default=bad success=ok user_unknown=ignore] pam_krb5.so >> account required pam_permit.so >> >> password requisite pam_cracklib.so try_first_pass retry=3 >> password sufficient pam_unix.so sha512 shadow nullok >> try_first_pass use_authtok >> password sufficient pam_krb5.so use_authtok >> password required pam_deny.so >> >> session optional pam_keyinit.so revoke >> session required pam_limits.so >> session optional pam_mkhomedir.so >> session [success=1 default=ignore] pam_succeed_if.so service in >> crond quiet use_uid >> session required pam_unix.so >> session optional pam_krb5.so >> [root at pc45 ~]# >> >> >> Does anyone have any suggestions for why this is not working? >> > > Fedora 13 is using nss-ldapd, not nss_ldap anymore. Probably ipa-client > needs to be updated to modify /etc/nslcd.conf instead of /etc/ldap.conf. I have a partial patch pending that should address this in v2. I'll need to clean things up and get it backported to v1.2 (bug https://bugzilla.redhat.com/show_bug.cgi?id=611858). rob > > In the meantime, you might have better luck configuring sssd instead of > nss-ldap for user lookups. > > man sssd.conf > man sssd-ldap > > From Steven.Jones at vuw.ac.nz Tue Jul 6 21:04:15 2010 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Wed, 7 Jul 2010 09:04:15 +1200 Subject: [Freeipa-users] Fedora 12 install documentation 2.0.0 & admin documentation 2.0.0 and problems. In-Reply-To: <4C336DD0.6090405@redhat.com> References: <4C28E61B.4060009@redhat.com> <4C336DD0.6090405@redhat.com> Message-ID: <61DF826607311A4EBE75A77ED59E4CDE2CDDFFD589@STAWINCOEXMAIL1.staff.vuw.ac.nz> Hi, I have installed free-ipa on fedora 12... Install documentation Some issues...."3.2 To test your IPA installation", 3. Item should read "/usr/sbin/ipa-finduser admin" and not "/usr/bin/ipa user-find admin" Admin documentation 1.1.1.1 "Using the Web Interface", There is no explanation of how to do get to the user homepage.... I tried https://localhost:443 and I get a "Kerberos Authentication failed".....there is no workable documentation / indication on how to fix this.... =============== "Kerberos Authentication Failed Unable to verify your Kerberos credentials. Please make sure that you have valid Kerberos tickets (obtainable via kinit), and that you have configured your browser correctly. If you are still unable to access the IPA Web interface, please contact the helpdesk on for additional assistance. Import the IPA Certificate Authority. You can automatically configure your browser to work with Kerberos by importing the Certificate Authority above and clicking on the Configure Browser button. You must reload this page after importing the Certificate Authority for the automatic settings to work ============= So I run kinit as a local user and get told.... "kinit: Client not found in Kerberos database while getting initial credentials" So anyway I attempt to follow the instruction in the web browser window (as above) and keep getting the same thing when I restart Firefox. So what next? regards Steven -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed Jul 7 12:52:41 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 07 Jul 2010 08:52:41 -0400 Subject: [Freeipa-users] Fedora 12 install documentation 2.0.0 & admin documentation 2.0.0 and problems. In-Reply-To: <61DF826607311A4EBE75A77ED59E4CDE2CDDFFD589@STAWINCOEXMAIL1.staff.vuw.ac.nz> References: <4C28E61B.4060009@redhat.com> <4C336DD0.6090405@redhat.com> <61DF826607311A4EBE75A77ED59E4CDE2CDDFFD589@STAWINCOEXMAIL1.staff.vuw.ac.nz> Message-ID: <4C347899.7010109@redhat.com> Steven Jones wrote: > Hi, > > I have installed free-ipa on fedora 12... > > Install documentation > > Some issues...."3.2 To test your IPA installation", > > 3. Item should read "/usr/sbin/ipa-finduser admin" and not > "/usr/bin/ipa user-find admin" The command-line changed between 1.2 and 2.0. If you are using 1.2 (the default in Fedora 12) then the command is ipa-finduser. If you are running 2.0 (or more precisely one of the alphas named 1.9) then the command is ipa user-find. You can determine the version you have with: rpm -q ipa-server > > Admin documentation > > 1.1.1.1 > > "Using the Web Interface", > > There is no explanation of how to do get to the user homepage.... > > I tried https://localhost:443 > > and I get a "Kerberos Authentication failed".....there is no workable > documentation / indication on how to fix this.... http://freeipa.org/docs/1.2/Installation_Deployment_Guide/en-US/html/sect-Installation_and_Deployment_Guide-Setting_up_the_IPA_Server-Configuring_Your_Browser.html In short, you need to configure your browser to do kerberos authentication, trust the IPA root CA and you need a kerberos ticket in order to connect. > > > > =============== > > > "Kerberos Authentication Failed > > Unable to verify your Kerberos credentials. Please make sure that you > have valid Kerberos tickets (obtainable via kinit), and that you have > configured your browser correctly > . If you > are still unable to access the IPA Web interface, please contact the > helpdesk on for additional assistance. > > Import the IPA Certificate Authority > . > > You can automatically configure your browser to work with Kerberos by > importing the Certificate Authority above and clicking on the Configure > Browser button. > > You *must* reload this page after importing the Certificate Authority > for the automatic settings to work > > ============= > > > > > > So I run kinit as a local user and get told.... > > > > "kinit: Client not found in Kerberos database while getting initial > credentials" Did you add your user as a user in IPA? You can always try getting a ticket as the admin user for testing (kinit admin). > So anyway I attempt to follow the instruction in the web browser window > (as above) and keep getting the same thing when I restart Firefox. > > So what next? > > regards > > Steven Thanks for the feedback. rob From Steven.Jones at vuw.ac.nz Wed Jul 7 20:49:55 2010 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Thu, 8 Jul 2010 08:49:55 +1200 Subject: [Freeipa-users] Fedora 12 install documentation 2.0.0 & admin documentation 2.0.0 and problems. In-Reply-To: <4C347899.7010109@redhat.com> References: <4C28E61B.4060009@redhat.com> <4C336DD0.6090405@redhat.com> <61DF826607311A4EBE75A77ED59E4CDE2CDDFFD589@STAWINCOEXMAIL1.staff.vuw.ac.nz> <4C347899.7010109@redhat.com> Message-ID: <61DF826607311A4EBE75A77ED59E4CDE2CDDFFD8A6@STAWINCOEXMAIL1.staff.vuw.ac.nz> 8><---- > I tried https://localhost:443 > > and I get a "Kerberos Authentication failed".....there is no workable > documentation / indication on how to fix this.... http://freeipa.org/docs/1.2/Installation_Deployment_Guide/en-US/html/sect-Installation_and_Deployment_Guide-Setting_up_the_IPA_Server-Configuring_Your_Browser.html In short, you need to configure your browser to do kerberos authentication, trust the IPA root CA and you need a kerberos ticket in order to connect. > 8><------ I did this however it keeps coming up with the same msg. Also there is no instruction to tell me how to get the kerberos ticket recognised..... > =============== > > > "Kerberos Authentication Failed > > Unable to verify your Kerberos credentials. Please make sure that you > have valid Kerberos tickets (obtainable via kinit), and that you have > configured your browser correctly > . If you > are still unable to access the IPA Web interface, please contact the > helpdesk on for additional assistance. > > Import the IPA Certificate Authority > . > > You can automatically configure your browser to work with Kerberos by > importing the Certificate Authority above and clicking on the Configure > Browser button. > > You *must* reload this page after importing the Certificate Authority > for the automatic settings to work > > ============= > > > > > > So I run kinit as a local user and get told.... > > > > "kinit: Client not found in Kerberos database while getting initial > credentials" >Did you add your user as a user in IPA? You can always try getting a >ticket as the admin user for testing (kinit admin). No, the documentation didnt tell me to, or how....so this part of the "testing" needs to include suitable cli commands / instructions to allow a proper test. This should be a sequence all in order of all the steps needed and not dig your way through a 500 page manual and guess... Really I guess someone wants to write a quick start or evaluation guide. Its interesting when you watch the youtube on freeipa and they talk about not having to be an expert in every single aspect, yet that's exactly what we end up with here, again. I have run kinit as admin and that seems fine, however the I have not been able to figure out how to use the admin's kerberos ticket I assume its /tmp/krb5cc_0 (which is owned by root) in a user's webrowser...Fedora 12 prevents root logging in under a gui which is silly...and I have not been able to find how to allow that yet. Also I cant login as the admin user as I got told that the admin account already exists when I try a "adduser admin"....yet does not exist in /etc/passwd, group or shadow.... So what do I do with this ticket? simply change its permissions to that of the local user? hack a file somewhere to point to it? regards Steven From rcritten at redhat.com Wed Jul 7 21:45:11 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 07 Jul 2010 17:45:11 -0400 Subject: [Freeipa-users] Fedora 12 install documentation 2.0.0 & admin documentation 2.0.0 and problems. In-Reply-To: <61DF826607311A4EBE75A77ED59E4CDE2CDDFFD8A6@STAWINCOEXMAIL1.staff.vuw.ac.nz> References: <4C28E61B.4060009@redhat.com> <4C336DD0.6090405@redhat.com> <61DF826607311A4EBE75A77ED59E4CDE2CDDFFD589@STAWINCOEXMAIL1.staff.vuw.ac.nz> <4C347899.7010109@redhat.com> <61DF826607311A4EBE75A77ED59E4CDE2CDDFFD8A6@STAWINCOEXMAIL1.staff.vuw.ac.nz> Message-ID: <4C34F567.8090008@redhat.com> Steven Jones wrote: > 8><---- > >> I tried https://localhost:443 >> >> and I get a "Kerberos Authentication failed".....there is no workable >> documentation / indication on how to fix this.... > > http://freeipa.org/docs/1.2/Installation_Deployment_Guide/en-US/html/sect-Installation_and_Deployment_Guide-Setting_up_the_IPA_Server-Configuring_Your_Browser.html > > In short, you need to configure your browser to do kerberos > authentication, trust the IPA root CA and you need a kerberos ticket in > order to connect. > > 8><------ > > I did this however it keeps coming up with the same msg. > > Also there is no instruction to tell me how to get the kerberos ticket recognised..... I'm not sure what you mean recognized. The basic idea is this: 1. Do a kinit admin. You now have a ticket. 2. Fire up Firefox and configure it per the documentation. What this tells firefox is which what domains it will do kerberos negotiation with so single sign-on will work. 3. You need to trust the CA that issued the SSL certificate that IPA uses in the browser. This generally requires a restart. After that it should just work. If not then you should check out section 3.3.1 in the Installation & Deployment guide. The problem can be any number of things including DNS problems. Kerberos and SSL are super picky that the remote server you are talking to has the exact same name that you are requesting. So thinks like short names don't work so hot (foo.example.com != foo in other words). We do what we can to force things to work the right way but sometimes one has to delve into the logs to figure out why something isn't working. >> =============== >> >> >> "Kerberos Authentication Failed >> >> Unable to verify your Kerberos credentials. Please make sure that you >> have valid Kerberos tickets (obtainable via kinit), and that you have >> configured your browser correctly >> . If you >> are still unable to access the IPA Web interface, please contact the >> helpdesk on for additional assistance. >> >> Import the IPA Certificate Authority >> . >> >> You can automatically configure your browser to work with Kerberos by >> importing the Certificate Authority above and clicking on the Configure >> Browser button. >> >> You *must* reload this page after importing the Certificate Authority >> for the automatic settings to work >> >> ============= >> >> >> >> >> >> So I run kinit as a local user and get told.... >> >> >> >> "kinit: Client not found in Kerberos database while getting initial >> credentials" > >> Did you add your user as a user in IPA? You can always try getting a >> ticket as the admin user for testing (kinit admin). > > No, the documentation didnt tell me to, or how....so this part of the "testing" needs to include suitable cli commands / instructions to allow a proper test. This should be a sequence all in order of all the steps needed and not dig your way through a 500 page manual and guess... The Installation and Deployment guide does exactly this. Perhaps it needs more steps but it goes to the level of 'type this and you should see that'. When you run just 'kinit' then it assumes you want to use the principal of the current uid. So in my case my login name is rcritten. If I do 'kinit' it is the same thing as 'kinit rcritten'. If you haven't added an IPA user 'rcritten' then you'll see this error message. > > Really I guess someone wants to write a quick start or evaluation guide. Its interesting when you watch the youtube on freeipa and they talk about not having to be an expert in every single aspect, yet that's exactly what we end up with here, again. > I'm sorry you're having problems. If you've ever tried to set up a KDC by hand you'd know better what they mean. We try to hide a lot of the complexity and lousy error messages of kerberos but we can only do so much. Some basic understanding of kerberos (principals, tickets, keytabs, etc) is necessary to fully take advantage of IPA. > I have run kinit as admin and that seems fine, however the I have not been able to figure out how to use the admin's kerberos ticket I assume its /tmp/krb5cc_0 (which is owned by root) in a user's webrowser...Fedora 12 prevents root logging in under a gui which is silly...and I have not been able to find how to allow that yet. In kerberos the user you're logged in as doesn't have to match the kerberos principal you use, hence being able to 'kinit admin' while logged in as root. Kerberos credentials are cached by default as /tmp/krb5cc_. So /tmp/krb5cc_0 is root's kerberos credentials cache. If you did 'kinit admin' as root then yes, this is the cache being used. Once you have successfully done a kinit there isn't anything you need to "do" to use it in most cases. kerberized applications will use the cache automatically. There are some applications, such as the browser, that you need to provide additional configuration data to. Each user will have their own credentials cache. You don't do a single kinit and everyone just works. > Also I cant login as the admin user as I got told that the admin account already exists when I try a "adduser admin"....yet does not exist in /etc/passwd, group or shadow.... Right, the admin user is stored in the IPA database. The whole idea of IPA is for distributed identity management. You create users in IPA, configure your clients properly and the same user credentials can be used anywhere within your deployment. No more rsyncing /etc/passwd, /etc/shadow and /etc/group to keep users, groups and passwords synchronized. So once you get things going you can use standard nss commands to view your users and groups as well, things like: # getent passwd admin # getent group ipausers # id admin I'm not sure why the admin user can't log in, how were you trying to log in? ssh, X, telnet...? > > So what do I do with this ticket? simply change its permissions to that of the local user? hack a file somewhere to point to it? No, kinit to admin as a local user. If you want to see if things are working at a very basic level do: $ kinit admin $ ipa-finduser admin If that works (e.g. you get some output about the admin user) then your IPA installation is more or less functioning. At this point you can start adding users to IPA (ipa-adduser). Then you can run ipa-client-install on your other machines to configure them to authenticate against your IPA server. Once that's done you should be able to log into those client machines using your IPA credentials. Note that when you set a user password as an administrator the user will need to reset that password the first time they use it (so that only the end-user has the password). If you have problems logging in via ssh you need to set ChallengeResponseAuthentication to yes in /etc/ssh/sshd_config I'd recommend reading the Client Installation guide before trying to install additional client machines. rob From shan.sysadm at gmail.com Thu Jul 8 13:43:35 2010 From: shan.sysadm at gmail.com (Shan Kumaraswamy) Date: Thu, 8 Jul 2010 16:43:35 +0300 Subject: [Freeipa-users] ipa-finduser problem Message-ID: Dear All, [root at saprhds001 sbin]# kinit admin Password for admin at MYDOMAIN.COM: [root at saprhds001 sbin]# klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: admin at MYDOMAIN.COM Valid starting Expires Service principal 07/08/10 16:37:47 07/09/10 16:37:43 krbtgt/BMIBANK.COM at MYDOMAIN.COM Kerberos 4 ticket cache: /tmp/tkt0 klist: You have no tickets cached [root at saprhds001 sbin]# /usr/sbin/ipa-finduser admin There was a problem importing one of the required Python modules. The error was: No module named kerberos And when I try to restart the ipa server, the ipa_webgui service is not shouting down and web server not working. Please advice me what went wrong? -- Thanks & Regards Shan Kumaraswamy -------------- next part -------------- An HTML attachment was scrubbed... URL: From shan.sysadm at gmail.com Thu Jul 8 15:29:54 2010 From: shan.sysadm at gmail.com (Shan Kumaraswamy) Date: Thu, 8 Jul 2010 18:29:54 +0300 Subject: [Freeipa-users] ipa-finduser problem In-Reply-To: References: Message-ID: Dear All, FreeIPA ipa_webgui not starting Please find the below error message: [root at saprhds001 ~]# /usr/sbin/ipactl restart Shutting down ipa_webgui: [FAILED] Shutting down ipa_kpasswd: [ OK ] Stopping httpd: [ OK ] Stopping Kerberos 5 KDC: [ OK ] Shutting down dirsrv: MYDOMAIN-COM... [ OK ] Shutting down ntpd: [ OK ] Starting dirsrv: MYDOMAIN-COM... [ OK ] Starting ntpd: [ OK ] Starting Kerberos 5 KDC: [ OK ] Starting ipa_kpasswd: [ OK ] Starting ipa_webgui: [ OK ] Starting httpd: [ OK ] [root at saprhds001 ~]# tail -f /var/log/ipa_error.log File "/usr/lib/python2.4/site-packages/pkg_resources.py", line 2479, in ? working_set.require(__requires__) File "/usr/lib/python2.4/site-packages/pkg_resources.py", line 585, in require needed = self.resolve(parse_requirements(requirements)) File "/usr/lib/python2.4/site-packages/pkg_resources.py", line 483, in resolve raise DistributionNotFound(req) # XXX put more info here Please help me to fix this issue. On Thu, Jul 8, 2010 at 4:43 PM, Shan Kumaraswamy wrote: > Dear All, > > [root at saprhds001 sbin]# kinit admin > Password for admin at MYDOMAIN.COM: > [root at saprhds001 sbin]# klist > Ticket cache: FILE:/tmp/krb5cc_0 > Default principal: admin at MYDOMAIN.COM > Valid starting Expires Service principal > 07/08/10 16:37:47 07/09/10 16:37:43 krbtgt/BMIBANK.COM at MYDOMAIN.COM > > Kerberos 4 ticket cache: /tmp/tkt0 > klist: You have no tickets cached > [root at saprhds001 sbin]# /usr/sbin/ipa-finduser admin > There was a problem importing one of the required Python modules. The > error was: > No module named kerberos > > And when I try to restart the ipa server, the ipa_webgui service is not > shouting down and web server not working. Please advice me what went wrong? > > > > -- > Thanks & Regards > Shan Kumaraswamy > > -- Thanks & Regards Shan Kumaraswamy -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Thu Jul 8 15:30:03 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 08 Jul 2010 11:30:03 -0400 Subject: [Freeipa-users] ipa-finduser problem In-Reply-To: References: Message-ID: <4C35EEFB.2020209@redhat.com> Shan Kumaraswamy wrote: > Dear All, > > [root at saprhds001 sbin]# kinit admin > Password for admin at MYDOMAIN.COM : > [root at saprhds001 sbin]# klist > Ticket cache: FILE:/tmp/krb5cc_0 > Default principal: admin at MYDOMAIN.COM > Valid starting Expires Service principal > 07/08/10 16:37:47 07/09/10 16:37:43 krbtgt/BMIBANK.COM at MYDOMAIN.COM > > > Kerberos 4 ticket cache: /tmp/tkt0 > klist: You have no tickets cached > [root at saprhds001 sbin]# /usr/sbin/ipa-finduser admin > There was a problem importing one of the required Python modules. The > error was: > No module named kerberos > > And when I try to restart the ipa server, the ipa_webgui service is not > shouting down and web server not working. Please advice me what went wrong? You need the python-kerberos package. Did you install this from source? Our dependencies within the source tree are a bit weak but installing using rpms should have required it. For the restart problem, how are you restarting things? Can you look in /var/log/ipa_error.log to see if anything is logged? This is the web UI (TurboGears) error log. The Apache log in /var/log/httpd/error_log might have some relevant details as well. rob From rcritten at redhat.com Thu Jul 8 15:48:01 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 08 Jul 2010 11:48:01 -0400 Subject: [Freeipa-users] ipa-finduser problem In-Reply-To: References: Message-ID: <4C35F331.3050500@redhat.com> Shan Kumaraswamy wrote: > Dear All, > FreeIPA ipa_webgui not starting > > Please find the below error message: > > [root at saprhds001 ~]# /usr/sbin/ipactl restart > Shutting down ipa_webgui: [FAILED] > Shutting down ipa_kpasswd: [ OK ] > Stopping httpd: [ OK ] > Stopping Kerberos 5 KDC: [ OK ] > Shutting down dirsrv: > MYDOMAIN-COM... [ OK ] > Shutting down ntpd: [ OK ] > Starting dirsrv: > MYDOMAIN-COM... [ OK ] > Starting ntpd: [ OK ] > Starting Kerberos 5 KDC: [ OK ] > Starting ipa_kpasswd: [ OK ] > Starting ipa_webgui: [ OK ] > Starting httpd: [ OK ] > [root at saprhds001 ~]# tail -f /var/log/ipa_error.log > File "/usr/lib/python2.4/site-packages/pkg_resources.py", line 2479, in ? > working_set.require(__requires__) > File "/usr/lib/python2.4/site-packages/pkg_resources.py", line 585, in > require > needed = self.resolve(parse_requirements(requirements)) > File "/usr/lib/python2.4/site-packages/pkg_resources.py", line 483, in > resolve > raise DistributionNotFound(req) # XXX put more info here > > Please help me to fix this issue. Do you have any more context on this? Does it say anywhere what is not being found? What is your distribution and where did you get the packages? We've gotten reports of people trying to build ipa in CentOS and having problems like this related to python-cheetah. I've never seen a resolution nor have I been able to duplicate the problem so I'm not sure what the next step is, other than verifying that you have python-cheetah installed. rob > > On Thu, Jul 8, 2010 at 4:43 PM, Shan Kumaraswamy > wrote: > > Dear All, > > [root at saprhds001 sbin]# kinit admin > Password for admin at MYDOMAIN.COM : > [root at saprhds001 sbin]# klist > Ticket cache: FILE:/tmp/krb5cc_0 > Default principal: admin at MYDOMAIN.COM > Valid starting Expires Service principal > 07/08/10 16:37:47 07/09/10 16:37:43 > krbtgt/BMIBANK.COM at MYDOMAIN.COM > > Kerberos 4 ticket cache: /tmp/tkt0 > klist: You have no tickets cached > [root at saprhds001 sbin]# /usr/sbin/ipa-finduser admin > There was a problem importing one of the required Python modules. The > error was: > No module named kerberos > > And when I try to restart the ipa server, the ipa_webgui service is > not shouting down and web server not working. Please advice me what > went wrong? > > > > -- > Thanks & Regards > Shan Kumaraswamy > > > > > -- > Thanks & Regards > Shan Kumaraswamy > > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From shan.sysadm at gmail.com Thu Jul 8 16:18:18 2010 From: shan.sysadm at gmail.com (Shan Kumaraswamy) Date: Thu, 8 Jul 2010 19:18:18 +0300 Subject: [Freeipa-users] ipa-finduser problem In-Reply-To: References: Message-ID: Rob, After installed python-kerberos, now I can able to find the admin user. still I could not able to start ipa_webgui. please advice On Thu, Jul 8, 2010 at 4:43 PM, Shan Kumaraswamy wrote: > Dear All, > > [root at saprhds001 sbin]# kinit admin > Password for admin at MYDOMAIN.COM: > [root at saprhds001 sbin]# klist > Ticket cache: FILE:/tmp/krb5cc_0 > Default principal: admin at MYDOMAIN.COM > Valid starting Expires Service principal > 07/08/10 16:37:47 07/09/10 16:37:43 krbtgt/BMIBANK.COM at MYDOMAIN.COM > > Kerberos 4 ticket cache: /tmp/tkt0 > klist: You have no tickets cached > [root at saprhds001 sbin]# /usr/sbin/ipa-finduser admin > There was a problem importing one of the required Python modules. The > error was: > No module named kerberos > > And when I try to restart the ipa server, the ipa_webgui service is not > shouting down and web server not working. Please advice me what went wrong? > > > > -- > Thanks & Regards > Shan Kumaraswamy > > -- Thanks & Regards Shan Kumaraswamy -------------- next part -------------- An HTML attachment was scrubbed... URL: From kozlov at spbcas.ru Fri Jul 9 05:27:29 2010 From: kozlov at spbcas.ru (Konstantin Kozlov) Date: Fri, 9 Jul 2010 09:27:29 +0400 Subject: [Freeipa-users] ipa-finduser problem In-Reply-To: <4C35F331.3050500@redhat.com> References: <4C35F331.3050500@redhat.com> Message-ID: <20100709092729.4e486daa@wave.bio.spbcas.ru> As you use python 2.4 it is probably CentOS 5. Check if you have SPICE libs installed: tclspice-20-3.el5 qspice-libs-0.3.0-39.el5_4.3 qspice-0.3.0-39.el5_4.3 In CentOS rpm dependencies were broken sometime ago when I tried to install FreeIPA. Best regards, Kostya On Thu, 08 Jul 2010 11:48:01 -0400 Rob Crittenden wrote: > Shan Kumaraswamy wrote: > > Dear All, > > FreeIPA ipa_webgui not starting > > > > Please find the below error message: > > > > [root at saprhds001 ~]# /usr/sbin/ipactl restart > > Shutting down ipa_webgui: [FAILED] > > Shutting down ipa_kpasswd: [ OK ] > > Stopping httpd: [ OK ] > > Stopping Kerberos 5 KDC: [ OK ] > > Shutting down dirsrv: > > MYDOMAIN-COM... [ OK ] > > Shutting down ntpd: [ OK ] > > Starting dirsrv: > > MYDOMAIN-COM... [ OK ] > > Starting ntpd: [ OK ] > > Starting Kerberos 5 KDC: [ OK ] > > Starting ipa_kpasswd: [ OK ] > > Starting ipa_webgui: [ OK ] > > Starting httpd: [ OK ] > > [root at saprhds001 ~]# tail -f /var/log/ipa_error.log > > File "/usr/lib/python2.4/site-packages/pkg_resources.py", line > > 2479, in ? working_set.require(__requires__) > > File "/usr/lib/python2.4/site-packages/pkg_resources.py", line > > 585, in require > > needed = self.resolve(parse_requirements(requirements)) > > File "/usr/lib/python2.4/site-packages/pkg_resources.py", line > > 483, in resolve > > raise DistributionNotFound(req) # XXX put more info here > > > > Please help me to fix this issue. > > Do you have any more context on this? Does it say anywhere what is > not being found? > > What is your distribution and where did you get the packages? > > We've gotten reports of people trying to build ipa in CentOS and > having problems like this related to python-cheetah. I've never seen > a resolution nor have I been able to duplicate the problem so I'm not > sure what the next step is, other than verifying that you have > python-cheetah installed. > > rob > > > > On Thu, Jul 8, 2010 at 4:43 PM, Shan Kumaraswamy > > > wrote: > > > > Dear All, > > > > [root at saprhds001 sbin]# kinit admin > > Password for admin at MYDOMAIN.COM : > > [root at saprhds001 sbin]# klist > > Ticket cache: FILE:/tmp/krb5cc_0 > > Default principal: admin at MYDOMAIN.COM > > Valid starting Expires > > Service principal 07/08/10 16:37:47 07/09/10 16:37:43 > > krbtgt/BMIBANK.COM at MYDOMAIN.COM > > > > > > Kerberos 4 ticket cache: /tmp/tkt0 > > klist: You have no tickets cached > > [root at saprhds001 sbin]# /usr/sbin/ipa-finduser admin > > There was a problem importing one of the required Python > > modules. The error was: > > No module named kerberos > > > > And when I try to restart the ipa server, the ipa_webgui > > service is not shouting down and web server not working. Please > > advice me what went wrong? > > > > > > > > -- > > Thanks & Regards > > Shan Kumaraswamy > > > > > > > > > > -- > > Thanks & Regards > > Shan Kumaraswamy > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > 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 shan.sysadm at gmail.com Fri Jul 9 10:41:42 2010 From: shan.sysadm at gmail.com (Shan Kumaraswamy) Date: Fri, 9 Jul 2010 13:41:42 +0300 Subject: [Freeipa-users] PassSync file issue Message-ID: Dear All, Can you please any one installed and tested the PassSync.msi file against Windows2008R2 64 bit OS architecture? I tried the installation the PassSync.msi file which comes along with RHDS 8.1 but it is failed. Please let me know which version of PassSync.msi file I can use for Windows2008R2 64 bit OS? -- Thanks & Regards Shan Kumaraswamy -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Fri Jul 9 13:01:20 2010 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 09 Jul 2010 07:01:20 -0600 Subject: [Freeipa-users] PassSync file issue In-Reply-To: References: Message-ID: <4C371DA0.6090709@redhat.com> Shan Kumaraswamy wrote: > Dear All, > Can you please any one installed and tested the PassSync.msi file > against Windows2008R2 64 bit OS architecture? I tried the > installation the PassSync.msi file which comes along with RHDS 8.1 but > it is failed. Please let me know which version of PassSync.msi file I > can use for Windows2008R2 64 bit OS? http://directory.fedoraproject.org/wiki/Download This should work with RHDS, but note that RH does not support the use of 389 components with RHDS. That is, it should work, but if you run into problems, RH support might not be able to help you. > > > -- > Thanks & Regards > Shan Kumaraswamy > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From rcritten at redhat.com Fri Jul 9 13:01:52 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 09 Jul 2010 09:01:52 -0400 Subject: [Freeipa-users] ipa-finduser problem In-Reply-To: References: <4C35F331.3050500@redhat.com> <20100709092729.4e486daa@wave.bio.spbcas.ru> Message-ID: <4C371DC0.1060001@redhat.com> Shan Kumaraswamy wrote: > Rob/ Kostya, > > > Thanks for your quick response, as per Rob?s note I have compared the > old installation and new system installation, and I find that there is a > different versions of ?python-cheetah? rpm, so I removed old version and > installed appropriate version, now I can find the admin user as well as > ipa_webgui is working properly Glad to hear it. Do you happen to have the details on the version that works? thanks rob > > > > On Fri, Jul 9, 2010 at 8:27 AM, Konstantin Kozlov > wrote: > > As you use python 2.4 it is probably CentOS 5. > > Check if you have SPICE libs installed: > tclspice-20-3.el5 > qspice-libs-0.3.0-39.el5_4.3 > qspice-0.3.0-39.el5_4.3 > In CentOS rpm dependencies were > broken sometime ago when I tried to install FreeIPA. > > Best regards, > > Kostya > > > On Thu, 08 Jul 2010 11:48:01 -0400 > Rob Crittenden > wrote: > > > Shan Kumaraswamy wrote: > > > Dear All, > > > FreeIPA ipa_webgui not starting > > > > > > Please find the below error message: > > > > > > [root at saprhds001 ~]# /usr/sbin/ipactl restart > > > Shutting down ipa_webgui: [FAILED] > > > Shutting down ipa_kpasswd: [ OK ] > > > Stopping httpd: [ OK ] > > > Stopping Kerberos 5 KDC: [ OK ] > > > Shutting down dirsrv: > > > MYDOMAIN-COM... [ OK ] > > > Shutting down ntpd: [ OK ] > > > Starting dirsrv: > > > MYDOMAIN-COM... [ OK ] > > > Starting ntpd: [ OK ] > > > Starting Kerberos 5 KDC: [ OK ] > > > Starting ipa_kpasswd: [ OK ] > > > Starting ipa_webgui: [ OK ] > > > Starting httpd: [ OK ] > > > [root at saprhds001 ~]# tail -f /var/log/ipa_error.log > > > File "/usr/lib/python2.4/site-packages/pkg_resources.py", line > > > 2479, in ? working_set.require(__requires__) > > > File "/usr/lib/python2.4/site-packages/pkg_resources.py", line > > > 585, in require > > > needed = self.resolve(parse_requirements(requirements)) > > > File "/usr/lib/python2.4/site-packages/pkg_resources.py", line > > > 483, in resolve > > > raise DistributionNotFound(req) # XXX put more info here > > > > > > Please help me to fix this issue. > > > > Do you have any more context on this? Does it say anywhere what is > > not being found? > > > > What is your distribution and where did you get the packages? > > > > We've gotten reports of people trying to build ipa in CentOS and > > having problems like this related to python-cheetah. I've never seen > > a resolution nor have I been able to duplicate the problem so I'm not > > sure what the next step is, other than verifying that you have > > python-cheetah installed. > > > > rob > > > > > > On Thu, Jul 8, 2010 at 4:43 PM, Shan Kumaraswamy > > > > >> wrote: > > > > > > Dear All, > > > > > > [root at saprhds001 sbin]# kinit admin > > > Password for admin at MYDOMAIN.COM > >: > > > [root at saprhds001 sbin]# klist > > > Ticket cache: FILE:/tmp/krb5cc_0 > > > Default principal: admin at MYDOMAIN.COM > > > > > Valid > starting Expires > > > Service principal 07/08/10 16:37:47 07/09/10 16:37:43 > > > krbtgt/BMIBANK.COM @MYDOMAIN.COM > > > > /BMIBANK.COM > @MYDOMAIN.COM > > > > > > > Kerberos 4 ticket cache: /tmp/tkt0 > > > klist: You have no tickets cached > > > [root at saprhds001 sbin]# /usr/sbin/ipa-finduser admin > > > There was a problem importing one of the required Python > > > modules. The error was: > > > No module named kerberos > > > > > > And when I try to restart the ipa server, the ipa_webgui > > > service is not shouting down and web server not working. Please > > > advice me what went wrong? > > > > > > > > > > > > -- > > > Thanks & Regards > > > Shan Kumaraswamy > > > > > > > > > > > > > > > -- > > > Thanks & Regards > > > Shan Kumaraswamy > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > _______________________________________________ > > > 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 > > > > > -- > Thanks & Regards > Shan Kumaraswamy > From shan.sysadm at gmail.com Sun Jul 11 07:04:40 2010 From: shan.sysadm at gmail.com (Shan Kumaraswamy) Date: Sun, 11 Jul 2010 10:04:40 +0300 Subject: [Freeipa-users] ipa-finduser problem In-Reply-To: <4C371DC0.1060001@redhat.com> References: <4C35F331.3050500@redhat.com> <20100709092729.4e486daa@wave.bio.spbcas.ru> <4C371DC0.1060001@redhat.com> Message-ID: Sure Rob, Please find the below details: python-cheetah-2.0.1-1.el5.rf.x86_64.rpm (removed) from the current server and installed this version of python-cheetah-2.0.1-1.el5.x86_64.rpm (Installed New) On Fri, Jul 9, 2010 at 4:01 PM, Rob Crittenden wrote: > Shan Kumaraswamy wrote: > >> Rob/ Kostya, >> >> Thanks for your quick response, as per Rob?s note I have compared the old >> installation and new system installation, and I find that there is a >> different versions of ?python-cheetah? rpm, so I removed old version and >> installed appropriate version, now I can find the admin user as well as >> ipa_webgui is working properly >> > > Glad to hear it. Do you happen to have the details on the version that > works? > > thanks > > rob > >> >> >> >> On Fri, Jul 9, 2010 at 8:27 AM, Konstantin Kozlov > kozlov at spbcas.ru>> wrote: >> >> As you use python 2.4 it is probably CentOS 5. >> >> Check if you have SPICE libs installed: >> tclspice-20-3.el5 >> qspice-libs-0.3.0-39.el5_4.3 >> qspice-0.3.0-39.el5_4.3 >> In CentOS rpm dependencies were >> broken sometime ago when I tried to install FreeIPA. >> >> Best regards, >> >> Kostya >> >> >> On Thu, 08 Jul 2010 11:48:01 -0400 >> Rob Crittenden > >> wrote: >> >> > Shan Kumaraswamy wrote: >> > > Dear All, >> > > FreeIPA ipa_webgui not starting >> > > >> > > Please find the below error message: >> > > >> > > [root at saprhds001 ~]# /usr/sbin/ipactl restart >> > > Shutting down ipa_webgui: >> [FAILED] >> > > Shutting down ipa_kpasswd: [ OK >> ] >> > > Stopping httpd: [ OK >> ] >> > > Stopping Kerberos 5 KDC: [ OK >> ] >> > > Shutting down dirsrv: >> > > MYDOMAIN-COM... [ OK >> ] >> > > Shutting down ntpd: [ OK >> ] >> > > Starting dirsrv: >> > > MYDOMAIN-COM... [ OK >> ] >> > > Starting ntpd: [ OK >> ] >> > > Starting Kerberos 5 KDC: [ OK >> ] >> > > Starting ipa_kpasswd: [ OK >> ] >> > > Starting ipa_webgui: [ OK >> ] >> > > Starting httpd: [ OK >> ] >> > > [root at saprhds001 ~]# tail -f /var/log/ipa_error.log >> > > File "/usr/lib/python2.4/site-packages/pkg_resources.py", line >> > > 2479, in ? working_set.require(__requires__) >> > > File "/usr/lib/python2.4/site-packages/pkg_resources.py", line >> > > 585, in require >> > > needed = self.resolve(parse_requirements(requirements)) >> > > File "/usr/lib/python2.4/site-packages/pkg_resources.py", line >> > > 483, in resolve >> > > raise DistributionNotFound(req) # XXX put more info here >> > > >> > > Please help me to fix this issue. >> > >> > Do you have any more context on this? Does it say anywhere what is >> > not being found? >> > >> > What is your distribution and where did you get the packages? >> > >> > We've gotten reports of people trying to build ipa in CentOS and >> > having problems like this related to python-cheetah. I've never seen >> > a resolution nor have I been able to duplicate the problem so I'm >> not >> > sure what the next step is, other than verifying that you have >> > python-cheetah installed. >> > >> > rob >> > > >> > > On Thu, Jul 8, 2010 at 4:43 PM, Shan Kumaraswamy >> > > >> >> wrote: >> > > >> > > Dear All, >> > > >> > > [root at saprhds001 sbin]# kinit admin >> > > Password for admin at MYDOMAIN.COM >> >: >> >> > > [root at saprhds001 sbin]# klist >> > > Ticket cache: FILE:/tmp/krb5cc_0 >> > > Default principal: admin at MYDOMAIN.COM >> >> > > > Valid >> >> starting Expires >> > > Service principal 07/08/10 16:37:47 07/09/10 16:37:43 >> > > krbtgt/BMIBANK.COM > >@MYDOMAIN.COM >> >> >> > > /BMIBANK.COM >> @MYDOMAIN.COM < >> http://mydomain.com/>> >> > > >> > > Kerberos 4 ticket cache: /tmp/tkt0 >> > > klist: You have no tickets cached >> > > [root at saprhds001 sbin]# /usr/sbin/ipa-finduser admin >> > > There was a problem importing one of the required Python >> > > modules. The error was: >> > > No module named kerberos >> > > >> > > And when I try to restart the ipa server, the ipa_webgui >> > > service is not shouting down and web server not working. Please >> > > advice me what went wrong? >> > > >> > > >> > > >> > > -- >> > > Thanks & Regards >> > > Shan Kumaraswamy >> > > >> > > >> > > >> > > >> > > -- >> > > Thanks & Regards >> > > Shan Kumaraswamy >> > > >> > > >> > > >> >> ------------------------------------------------------------------------ >> > > >> > > _______________________________________________ >> > > 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 >> >> >> >> >> -- >> Thanks & Regards >> Shan Kumaraswamy >> >> > -- Thanks & Regards Shan Kumaraswamy -------------- next part -------------- An HTML attachment was scrubbed... URL: From afkkir at gmail.com Mon Jul 12 14:11:27 2010 From: afkkir at gmail.com (ALAHYANE Rachid) Date: Mon, 12 Jul 2010 16:11:27 +0200 Subject: [Freeipa-users] The ACI reloaded ! Message-ID: Hi, I want to add an ACI to the ldap server with the aci-add and i do not how can I do it ? The aci to add is the following : (targetattr = "friends,blockedfriends,givenName || sn || cn || displayName || title || initials || loginShell || gecos || homePhone || mobile || pager || facsimileTelephoneNumber || telephoneNumber || street || roomNumber || l || st || postalCode || manager || secretary || description || carLicense || labeledURI || inetUserHTTPURL || seeAlso || employeeType || businessCategory || ou")(version 3.0;acl "My Self service";allow (write) userdn = "ldap:///self";) Note that I added some new target attributes (also added on the ldap schema). The last time, I tried to modify an ACI, the aci entry was deleted. It is for this reason that i try to add a new one. Tanks for your help -- Meilleures salutations / Best Regards Rachid ALAHYANE -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Mon Jul 12 14:39:41 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 12 Jul 2010 10:39:41 -0400 Subject: [Freeipa-users] The ACI reloaded ! In-Reply-To: References: Message-ID: <4C3B292D.2030206@redhat.com> ALAHYANE Rachid wrote: > Hi, > > I want to add an ACI to the ldap server with the aci-add and i do not > how can I do it ? > > The aci to add is the following : > > > (targetattr = "friends,blockedfriends,givenName || sn || cn || > displayName || title || initials || loginShell || gecos || homePhone || > mobile || pager || facsimileTelephoneNumber || telephoneNumber || street > || roomNumber || l || st || postalCode || manager || secretary || > description || carLicense || labeledURI || inetUserHTTPURL || seeAlso || > employeeType || businessCategory || ou")(version 3.0;acl "My Self > service";allow (write) userdn = "ldap:///self";) The aci plugin can't handle self bind rules yet (I created ticket #80 to track this). You can still add this with ldapmodify though. First you need to replace the comma's in your targetattr with ||, then you should be able to add it with something like: ldapmodify -x -D 'cn=directory manager' -W dn: dc=example,dc=com changetype: modify add: aci aci: ^D > > Note that I added some new target attributes (also added on the ldap > schema). The last time, I tried to modify an ACI, the aci entry was > deleted. It is for this reason that i try to add a new one. What the aci plugin does in the modify case is delete the old aci and add a new one. The problem with the plugin wasn't shown until after the deletion, hence any aci you tried to modify you basically just deleted. rob From afkkir at gmail.com Tue Jul 13 13:09:29 2010 From: afkkir at gmail.com (ALAHYANE Rachid) Date: Tue, 13 Jul 2010 15:09:29 +0200 Subject: [Freeipa-users] The ACI reloaded ! In-Reply-To: <4C3B292D.2030206@redhat.com> References: <4C3B292D.2030206@redhat.com> Message-ID: Thank you Rob ^^ it works ! 2010/7/12 Rob Crittenden > ALAHYANE Rachid wrote: > >> Hi, >> >> I want to add an ACI to the ldap server with the aci-add and i do not how >> can I do it ? >> >> The aci to add is the following : >> >> >> (targetattr = "friends,blockedfriends,givenName || sn || cn || displayName >> || title || initials || loginShell || gecos || homePhone || mobile || pager >> || facsimileTelephoneNumber || telephoneNumber || street || roomNumber || l >> || st || postalCode || manager || secretary || description || carLicense || >> labeledURI || inetUserHTTPURL || seeAlso || employeeType || businessCategory >> || ou")(version 3.0;acl "My Self service";allow (write) userdn = >> "ldap:///self";) >> > > The aci plugin can't handle self bind rules yet (I created ticket #80 to > track this). > > You can still add this with ldapmodify though. > > First you need to replace the comma's in your targetattr with ||, then you > should be able to add it with something like: > > ldapmodify -x -D 'cn=directory manager' -W > dn: dc=example,dc=com > changetype: modify > add: aci > aci: > > ^D > > > >> Note that I added some new target attributes (also added on the ldap >> schema). The last time, I tried to modify an ACI, the aci entry was deleted. >> It is for this reason that i try to add a new one. >> > > What the aci plugin does in the modify case is delete the old aci and add a > new one. The problem with the plugin wasn't shown until after the deletion, > hence any aci you tried to modify you basically just deleted. > > rob > -- Meilleures salutations / Best Regards Rachid ALAHYANE -------------- next part -------------- An HTML attachment was scrubbed... URL: From prjctgeek at gmail.com Tue Jul 13 23:10:41 2010 From: prjctgeek at gmail.com (Doug Chapman) Date: Tue, 13 Jul 2010 16:10:41 -0700 Subject: [Freeipa-users] ipa-getkeytab automation Message-ID: Can anyone give me some tips or document links on client deployment automation (I'm using puppet) to update the /etc/krb5.keytab file? I'm using IPA 1.2.2 on Centos5 and it seems the direct approach is to script the creation of the service principles (ipa-addservice) and extract all of the keytabs into puppet deployed files. Is there anything I'm missing? The ipa-addservice would require a human to login with a valid ticket in order to work; is there any way I could create a service account with limited permissions to allow an application to populate the Directory with new hosts from an external source (eg: cobbler, or a database of hosts) ? tia -- DougC -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Tue Jul 13 23:33:42 2010 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 13 Jul 2010 19:33:42 -0400 Subject: [Freeipa-users] ipa-getkeytab automation In-Reply-To: References: Message-ID: <4C3CF7D6.7000809@redhat.com> Doug Chapman wrote: > Can anyone give me some tips or document links on client deployment > automation (I'm using puppet) to update the /etc/krb5.keytab file? > > I'm using IPA 1.2.2 on Centos5 and it seems the direct approach is > to script the creation of the service principles (ipa-addservice) and > extract all of the keytabs into puppet deployed files. Is there > anything I'm missing? > > The ipa-addservice would require a human to login with a valid ticket > in order to work; is there any way I could create a service account > with limited permissions to allow an application to populate the > Directory with new hosts from an external source (eg: cobbler, or a > database of hosts) ? > In v2 there is also an option for the automatic provisioning. * You create a host entry in the IPA and give it an OTP password. * You pass the same OTP password to the kickstart or some other client software * Client software invokes ipa-join and passes in the password. This completes the enrollment of the host. This host will have a keytab and would be able to work with IPA. * The host will have permissions to retrieve a keytab for a service running on the host. * Add a service to IPA server * Run ipa-getkeytab on the client under host identity. This will provision a key for the service running on the host. You can try one of the v2 alphas. Thanks Dmitri > tia > -- > DougC > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From shan.sysadm at gmail.com Wed Jul 14 08:21:11 2010 From: shan.sysadm at gmail.com (Shan Kumaraswamy) Date: Wed, 14 Jul 2010 11:21:11 +0300 Subject: [Freeipa-users] Disable IPA Web UI auto-login Message-ID: Dear All, Can anyone let me know how to disable IPA admin ?auto-login? from FreeIPA server, basically I need to use this URL https://ipaserver.example.com/ipa/ui and should ask user name and password every time while opening the login page, and also the administrator will login via ?Firefox? any machine in the intranet (LAN) using the IPA admin login credentials. -- Thanks & Regards Shan Kumaraswamy -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Wed Jul 14 13:19:45 2010 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 14 Jul 2010 09:19:45 -0400 Subject: [Freeipa-users] Disable IPA Web UI auto-login In-Reply-To: References: Message-ID: <4C3DB971.2040300@redhat.com> Shan Kumaraswamy wrote: > Dear All, > > > > Can anyone let me know how to disable IPA admin ?auto-login? from > FreeIPA server, basically I need to use this URL > https://ipaserver.example.com/ipa/ui and should ask user name and > password every time while opening the login page, > This is not a bug. It is a feature :-) A bit of explanation about how things work. When admin does authentication he gets a kerberos ticket. This ticket is used to get access to the UI (automatically). It is a feature of kerberos. You would not be able to login if you do not have a ticket. If you have a ticket, this means you already proved your identity to the server and there is no need to challenge you again. What you are asking for is a form based authentication. It is not implemented in IPA and not planned to be implemented in v2 because the scheme above has same security attributes but is much more convenient. So there is no way to disable the auto-login feature. > and also the administrator will login via ?Firefox? any machine in > the intranet (LAN) using the IPA admin login credentials. > Can you explain this part please? Login into any machine? Sure if you configured SSH to use kerberos you will be able to SSH into any machine unless you configures some access control rules that would prevent you from doing so. > > -- > Thanks & Regards > Shan Kumaraswamy > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Wed Jul 14 13:22:21 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 14 Jul 2010 09:22:21 -0400 Subject: [Freeipa-users] Disable IPA Web UI auto-login In-Reply-To: References: Message-ID: <4C3DBA0D.3030703@redhat.com> Shan Kumaraswamy wrote: > Dear All, > > > > Can anyone let me know how to disable IPA admin ?auto-login? from > FreeIPA server, basically I need to use this URL > https://ipaserver.example.com/ipa/ui and should ask user name and > password every time while opening the login page, and also the > administrator will login via ?Firefox? any machine in the intranet > (LAN) using the IPA admin login credentials. > Well, the reason to use kerberos is you get single sign-on. You enter your password when you kinit and then never have to provide it again (well, that's the Utopian ideal anyway). But if you really want it, set KrbMethodK5Passwd to on in /etc/httpd/conf.d/ipa.conf and restart the httpd process. It will still try to use kerberos negotiation (single sign-on) but will fall back to username/password. rob From shan.sysadm at gmail.com Wed Jul 14 13:26:00 2010 From: shan.sysadm at gmail.com (Shan Kumaraswamy) Date: Wed, 14 Jul 2010 16:26:00 +0300 Subject: [Freeipa-users] Disable IPA Web UI auto-login In-Reply-To: <4C3DB971.2040300@redhat.com> References: <4C3DB971.2040300@redhat.com> Message-ID: Hi Pal, Thank you very much for the clarificaiton, the secound question is I want to access the url from my laptop using firefox, and also I configured the browser as per the IPA installation browers configuration and its download the ipa certificate, after when I try the same url again its througing the kerberos auth failure. Please let me know what is the issure. On Wed, Jul 14, 2010 at 4:19 PM, Dmitri Pal wrote: > Shan Kumaraswamy wrote: > > Dear All, > > > > > > > > Can anyone let me know how to disable IPA admin ?auto-login? from > > FreeIPA server, basically I need to use this URL > > https://ipaserver.example.com/ipa/ui and should ask user name and > > password every time while opening the login page, > > > This is not a bug. It is a feature :-) > A bit of explanation about how things work. > When admin does authentication he gets a kerberos ticket. > This ticket is used to get access to the UI (automatically). It is a > feature of kerberos. > You would not be able to login if you do not have a ticket. > If you have a ticket, this means you already proved your identity to the > server and there is no need to challenge you again. > What you are asking for is a form based authentication. It is not > implemented in IPA and not planned to be implemented in v2 because the > scheme above has same security attributes but is much more convenient. > So there is no way to disable the auto-login feature. > > > > > and also the administrator will login via ?Firefox? any machine in > > the intranet (LAN) using the IPA admin login credentials. > > > > Can you explain this part please? Login into any machine? Sure if you > configured SSH to use kerberos you will be able to SSH into any machine > unless you configures some access control rules that would prevent you > from doing so. > > > > > > -- > > Thanks & Regards > > Shan Kumaraswamy > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Freeipa-users mailing list > > Freeipa-users at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > -- > Thank you, > Dmitri Pal > > Engineering Manager IPA project, > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > -- Thanks & Regards Shan Kumaraswamy -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed Jul 14 13:42:37 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 14 Jul 2010 09:42:37 -0400 Subject: [Freeipa-users] ipa-getkeytab automation In-Reply-To: References: Message-ID: <4C3DBECD.40003@redhat.com> Doug Chapman wrote: > Can anyone give me some tips or document links on client deployment > automation (I'm using puppet) to update the /etc/krb5.keytab file? > > I'm using IPA 1.2.2 on Centos5 and it seems the direct approach is > to script the creation of the service principles (ipa-addservice) and > extract all of the keytabs into puppet deployed files. Is there > anything I'm missing? > > The ipa-addservice would require a human to login with a valid ticket in > order to work; is there any way I could create a service account with > limited permissions to allow an application to populate the Directory > with new hosts from an external source (eg: cobbler, or a database of > hosts) ? > As Dmitri said, we're addressing this in v2. It requires a fair bit of work to get this done, mostly in the area of writing 389-ds ACIs. Off the top of my head I guess the way I'd approach is create a service principal used for creating other principals. You need an ACI granting add access to this principal to create other principals. And you'd need an ACI granting write privileges to the krb* attributes so you can use ipa-getkeytab to generate and retrieve a keytab. But you're probably better off giving v2 a look-see. rob From dpal at redhat.com Wed Jul 14 13:56:54 2010 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 14 Jul 2010 09:56:54 -0400 Subject: [Freeipa-users] Disable IPA Web UI auto-login In-Reply-To: References: <4C3DB971.2040300@redhat.com> Message-ID: <4C3DC226.7040505@redhat.com> Shan Kumaraswamy wrote: > Hi Pal, > Thank you very much for the clarificaiton, the secound question is I > want to access the url from my laptop using firefox, and also I > configured the browser as per the IPA installation browers > configuration and its download the ipa certificate, after when I try > the same url again its througing the kerberos auth failure. Please let > me know what is the issure. > Have you authenticated from your laptop and do you have a ticket? Is it a Windows client? If yes you need to do kinit from the Windows laptop first to obtain a ticket. To do this you need kerberos client installed and configured. If the laptop is a part of the IPA domain then this is one scenario if not then a different. http://www.freeipa.org/page/Implementing_FreeIPA_in_a_mixed_Environment_(Windows/Linux)_-_Step_by_step http://freeipa.org/docs/1.2/Client_Setup_Guide/en-US/html/chap-Client_Configuration_Guide-Using_MicrosoftWindows_to_Manage_IPA.html#sect-Client_Configuration_Guide-Using_MicrosoftWindows_to_Manage_IPA-Configuring_Windows_XP_Pro_and_Windows_2000_Pro > > > > On Wed, Jul 14, 2010 at 4:19 PM, Dmitri Pal > wrote: > > Shan Kumaraswamy wrote: > > Dear All, > > > > > > > > Can anyone let me know how to disable IPA admin ?auto-login? from > > FreeIPA server, basically I need to use this URL > > https://ipaserver.example.com/ipa/ui and should ask user name and > > password every time while opening the login page, > > > This is not a bug. It is a feature :-) > A bit of explanation about how things work. > When admin does authentication he gets a kerberos ticket. > This ticket is used to get access to the UI (automatically). It is a > feature of kerberos. > You would not be able to login if you do not have a ticket. > If you have a ticket, this means you already proved your identity > to the > server and there is no need to challenge you again. > What you are asking for is a form based authentication. It is not > implemented in IPA and not planned to be implemented in v2 because the > scheme above has same security attributes but is much more convenient. > So there is no way to disable the auto-login feature. > > > > > and also the administrator will login via ?Firefox? any machine in > > the intranet (LAN) using the IPA admin login credentials. > > > > Can you explain this part please? Login into any machine? Sure if you > configured SSH to use kerberos you will be able to SSH into any > machine > unless you configures some access control rules that would prevent you > from doing so. > > > > > > -- > > Thanks & Regards > > Shan Kumaraswamy > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Freeipa-users mailing list > > Freeipa-users at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > -- > Thank you, > Dmitri Pal > > Engineering Manager IPA project, > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > > -- > Thanks & Regards > Shan Kumaraswamy > -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From danieljamesscott at gmail.com Wed Jul 14 15:45:22 2010 From: danieljamesscott at gmail.com (Dan Scott) Date: Wed, 14 Jul 2010 11:45:22 -0400 Subject: [Freeipa-users] FreeIPA redundant server login problems Message-ID: Hi, I have 2 FreeIPA servers (Version 1). I am upgrading the slave server from Fedora 11 to 13, so I have shut it down. My client (Fedora 13, using SSSD) cannot authenticate against the master FreeIPA server and gives the following message: pam_sss(sshd:auth): system info: [Cannot contact any KDC for requested realm] I'm very confused about the role of the /etc/krb5.conf and /etc/sssd/sssd.conf files. They appear to contain very similar information and I'm not sure which is used by default. My krb5.conf file contains the following: [realms] EXAMPLE.COM = { kdc = fileserver1.example.com:88 kdc = fileserver2.example.com:88 admin_server = fileserver1.example.com:749 default_domain = example.com } fileserver2 is the master and fileserver1 the slave. Is it possible to have 2 entries for admin_server? If not, then how do I correctly configure multiple FreeIPA servers. I have tried changing admin_server to fileserver2, but no change. The /etc/sssd/sssd.conf file contains: [domain/default] ldap_id_use_start_tls = False cache_credentials = False auth_provider = krb5 debug_level = 0 krb5_kpasswd = ldap.example.com:749 ldap_schema = rfc2307bis krb5_realm = EXAMPLE.COM ldap_search_base = dc=example,dc=com chpass_provider = krb5 id_provider = ldap min_id = 500 ldap_uri = ldap://ldap.example.com/ krb5_kdcip = ldap.example.com:88 ldap_tls_cacertdir = /etc/openldap/cacerts where ldap.example.com resolves to both fileserver1 and fileserver2 in a round-robin. Can anyone explain the role of krb5.conf and sssd.conf and provide any ideas for why I cannot authenticate against fileserver2? Thanks, Dan Scott From dpal at redhat.com Wed Jul 14 16:07:15 2010 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 14 Jul 2010 12:07:15 -0400 Subject: [Freeipa-users] FreeIPA redundant server login problems In-Reply-To: References: Message-ID: <4C3DE0B3.5040400@redhat.com> Dan Scott wrote: > Hi, > > I have 2 FreeIPA servers (Version 1). I am upgrading the slave server > from Fedora 11 to 13, so I have shut it down. My client (Fedora 13, > using SSSD) cannot authenticate against the master FreeIPA server and > gives the following message: > > pam_sss(sshd:auth): system info: [Cannot contact any KDC for requested realm] > > I'm very confused about the role of the /etc/krb5.conf and > /etc/sssd/sssd.conf files. They appear to contain very similar > information and I'm not sure which is used by default. > If you use SSSD instead of pam_krb5 then kerberos configuration file is ignored. SSSD uses only the SSSD config file. > My krb5.conf file contains the following: > > > [realms] > EXAMPLE.COM = { > kdc = fileserver1.example.com:88 > kdc = fileserver2.example.com:88 > admin_server = fileserver1.example.com:749 > default_domain = example.com > } > > fileserver2 is the master and fileserver1 the slave. Is it possible to > have 2 entries for admin_server? If not, then how do I correctly > configure multiple FreeIPA servers. I have tried changing admin_server > to fileserver2, but no change. > > The /etc/sssd/sssd.conf file contains: > > [domain/default] > ldap_id_use_start_tls = False > cache_credentials = False > auth_provider = krb5 > debug_level = 0 > krb5_kpasswd = ldap.example.com:749 > ldap_schema = rfc2307bis > krb5_realm = EXAMPLE.COM > ldap_search_base = dc=example,dc=com > chpass_provider = krb5 > id_provider = ldap > min_id = 500 > ldap_uri = ldap://ldap.example.com/ > krb5_kdcip = ldap.example.com:88 > Shouldn't that be a fileserver1 or fileserver2? > ldap_tls_cacertdir = /etc/openldap/cacerts > > where ldap.example.com resolves to both fileserver1 and fileserver2 in > a round-robin. > > Can anyone explain the role of krb5.conf and sssd.conf and provide any > ideas for why I cannot authenticate against fileserver2? > > Thanks, > > Dan Scott > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > > -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From jhrozek at redhat.com Wed Jul 14 16:10:17 2010 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 14 Jul 2010 18:10:17 +0200 Subject: [Freeipa-users] FreeIPA redundant server login problems In-Reply-To: References: Message-ID: <4C3DE169.2070507@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/14/2010 05:45 PM, Dan Scott wrote: > [domain/default] > ldap_id_use_start_tls = False > cache_credentials = False > auth_provider = krb5 > debug_level = 0 > krb5_kpasswd = ldap.example.com:749 > ldap_schema = rfc2307bis > krb5_realm = EXAMPLE.COM > ldap_search_base = dc=example,dc=com > chpass_provider = krb5 > id_provider = ldap > min_id = 500 > ldap_uri = ldap://ldap.example.com/ > krb5_kdcip = ldap.example.com:88 > ldap_tls_cacertdir = /etc/openldap/cacerts > > where ldap.example.com resolves to both fileserver1 and fileserver2 in > a round-robin. > That sounds like https://fedorahosted.org/sssd/ticket/552 to me. Since you have two KDCs running, can you try putting: krb5_kdcip = fileserver1.example.com, fileserver2.example.com into SSSD config file instead and restarting the sssd service? We don't support fail over on multiple A records for the same hostname. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkw94WkACgkQHsardTLnvCXLTACbBB3I23RNMyP09snSz8noHL4p RfAAoM/5hop+X2boP8nWfyXZJTfBcDat =hU70 -----END PGP SIGNATURE----- From danieljamesscott at gmail.com Wed Jul 14 16:17:38 2010 From: danieljamesscott at gmail.com (Dan Scott) Date: Wed, 14 Jul 2010 12:17:38 -0400 Subject: [Freeipa-users] FreeIPA redundant server login problems In-Reply-To: <4C3DE0B3.5040400@redhat.com> References: <4C3DE0B3.5040400@redhat.com> Message-ID: Hi, On Wed, Jul 14, 2010 at 12:07, Dmitri Pal wrote: > If you use SSSD instead of pam_krb5 then kerberos configuration file is > ignored. > SSSD uses only the SSSD config file. Great, thanks. >> The /etc/sssd/sssd.conf file contains: >> >> [domain/default] >> ldap_id_use_start_tls = False >> cache_credentials = False >> auth_provider = krb5 >> debug_level = 0 >> krb5_kpasswd = ldap.example.com:749 >> ldap_schema = rfc2307bis >> krb5_realm = EXAMPLE.COM >> ldap_search_base = dc=example,dc=com >> chpass_provider = krb5 >> id_provider = ldap >> min_id = 500 >> ldap_uri = ldap://ldap.example.com/ >> krb5_kdcip = ldap.example.com:88 >> > > Shouldn't that be a fileserver1 or fileserver2? Well yes it could (should?) be, but I want 'both' so that the redundancy works. Can I have 2 krb5_kdcip entries? If I set it to one or the other then the redundant server won't work, will it? UPDATE: Have just received Jakub Hrozek email (Thanks Jakub). Adding fileserver1, fileserver2 appears to have fixed the problem. However, this means that I have to edit this file on all clients if I add a new IPA server. Is there any way around this? Thanks, Dan From dpal at redhat.com Wed Jul 14 17:43:52 2010 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 14 Jul 2010 13:43:52 -0400 Subject: [Freeipa-users] FreeIPA redundant server login problems In-Reply-To: References: <4C3DE0B3.5040400@redhat.com> Message-ID: <4C3DF758.60306@redhat.com> Dan Scott wrote: > Hi, > > On Wed, Jul 14, 2010 at 12:07, Dmitri Pal wrote: > >> If you use SSSD instead of pam_krb5 then kerberos configuration file is >> ignored. >> SSSD uses only the SSSD config file. >> > > Great, thanks. > > >>> The /etc/sssd/sssd.conf file contains: >>> >>> [domain/default] >>> ldap_id_use_start_tls = False >>> cache_credentials = False >>> auth_provider = krb5 >>> debug_level = 0 >>> krb5_kpasswd = ldap.example.com:749 >>> ldap_schema = rfc2307bis >>> krb5_realm = EXAMPLE.COM >>> ldap_search_base = dc=example,dc=com >>> chpass_provider = krb5 >>> id_provider = ldap >>> min_id = 500 >>> ldap_uri = ldap://ldap.example.com/ >>> krb5_kdcip = ldap.example.com:88 >>> >>> >> Shouldn't that be a fileserver1 or fileserver2? >> > > Well yes it could (should?) be, but I want 'both' so that the > redundancy works. Can I have 2 krb5_kdcip entries? If I set it to one > or the other then the redundant server won't work, will it? > > UPDATE: Have just received Jakub Hrozek email (Thanks Jakub). Adding > fileserver1, fileserver2 appears to have fixed the problem. However, > this means that I have to edit this file on all clients if I add a new > IPA server. Is there any way around this? > > https://fedorahosted.org/sssd/ticket/367 > Thanks, > > Dan > -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From jhrozek at redhat.com Thu Jul 15 12:16:21 2010 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 15 Jul 2010 14:16:21 +0200 Subject: [Freeipa-users] FreeIPA redundant server login problems In-Reply-To: <4C3DF758.60306@redhat.com> References: <4C3DE0B3.5040400@redhat.com> <4C3DF758.60306@redhat.com> Message-ID: <4C3EFC15.1090109@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/14/2010 07:43 PM, Dmitri Pal wrote: >> UPDATE: Have just received Jakub Hrozek email (Thanks Jakub). Adding >> > fileserver1, fileserver2 appears to have fixed the problem. However, >> > this means that I have to edit this file on all clients if I add a new >> > IPA server. Is there any way around this? >> > >> > > https://fedorahosted.org/sssd/ticket/367 > By using service records, you will still need to update the config file on all clients - but just this once, any further configuration changes can be made on the server in a centralized manner. Aside from the ticket Dmitri mentioned, other useful resource to get you started might be the "SERVICE DISCOVERY" section of either sssd-ldap or sssd-krb5. Also, I'm not sure about FreeIPA v1, but v2 will have SRV records by default on the server side. Hope this helps, Jakub -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkw+/BUACgkQHsardTLnvCUIXQCdH3BZgPCy4IHRpvpFKnWEOHBV 0ocAn2L0AK3giELVvmvBfZf2nd5et7On =tkpC -----END PGP SIGNATURE----- From rcritten at redhat.com Thu Jul 15 19:53:21 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 15 Jul 2010 15:53:21 -0400 Subject: [Freeipa-users] Announcing FreeIPA v2 Server Alpha 4 Release Message-ID: <4C3F6731.6000000@redhat.com> To all freeipa-interest, freeipa-users and freeipa-devel list members, The FreeIPA project team is pleased to announce the availability of the Alpha 4 release of freeIPA 2.0 server [1]. Binaries are available for F-12 and F-13. This alpha is mostly a bug fix release over the previous alpha. We have started the process of polishing so things should generally work more smoothly and look better. There are no improvements in the UI, those should appear in the next release. Please do not hesitate to share feedback, criticism or bugs with us on our mailing list: freeipa-users at redhat.com The changes in this release are: - Moved our dogtag SELinux to be installed with the rpm instead of during configuration. - Fedora 13 moved to gpg2 and dropped gpg. Fix our invocation so we work with either (this was preventing replica installations). - Query remote server during replica installation to see if the replica already exists. This prevents lots of really strange errors during replica installation. - Fixed SSL error in client enrollment. - Changed the way services are handled in HBAC. There is now a separate service and servicegroup object that you associate with HBAC rules. sssd is already using this new mechanism. - First pass at per-command documentation. It still needs a lot of work. - Fix aci-mod command. It wasn't really working well in almost all cases. - Add replication version checking. This is one step in better control during updates. - Don't try to convert a host's password into a keytab with bulk enrollment (this was causing krbPasswordExpiration to be set). - Add support for User-Private Groups. - Worked on error handling in mod_wsgi. Now hopefully a shorter and less scary backtrace will be thrown when things go bump in the night. - Add new api to disable service and host principals. - Significant cleanup of crypto code. Using python-nss for a lot more (and more to come). - Fixed some errirs in and made ipa-compat-manage and ipa-nis-manage more bullet-proof. - Fixed netgroups plugin, it was generating the wrong attributes. - Other minor polish and bug fixes. Known issues: - The CA must be installed in the en_US locale (#588375) rob [1] http://www.freeipa.org/page/Downloads From hyourinseta at gmail.com Sat Jul 17 02:36:42 2010 From: hyourinseta at gmail.com (Gugi Gustaman) Date: Sat, 17 Jul 2010 09:36:42 +0700 Subject: [Freeipa-users] about kpasswd on freeIPA Message-ID: I am a newbie with Kerberos and i need help. I have a Kerberos installed on my server and it is configured by freeIPA. When i make an IPA-user, the kerberos password always expires. And then i tried to doing kinit with that user and kerberos forced me to change the password because it has expired. And then i tried some password to change the expired password but i couldn't and kerberos told me that it rejected my new password. After three times i tried to change the password, the kinit command finished with error message like this "kinit : Password change failed while getting initial credentials". I don't know how to solve this problem and I need help. A week after i made that IPA user, i could doing kinit with that user (after kerberos asked for the password and forced me to change the password, the password was accepted and i could doing kinit). But after I tried to make new IPA user, i met the same problem with the problem above (Expired kerberos password). Please help me. I am sorry with my English, but I am an Indonesian. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ssorce at redhat.com Sun Jul 18 13:57:45 2010 From: ssorce at redhat.com (Simo Sorce) Date: Sun, 18 Jul 2010 09:57:45 -0400 Subject: [Freeipa-users] about kpasswd on freeIPA In-Reply-To: References: Message-ID: <20100718095745.448263f7@willson.li.ssimo.org> On Sat, 17 Jul 2010 09:36:42 +0700 Gugi Gustaman wrote: > I am a newbie with Kerberos and i need help. > I have a Kerberos installed on my server and it is configured by > freeIPA. When i make an IPA-user, the kerberos password always > expires. And then i tried to doing kinit with that user and kerberos > forced me to change the password because it has expired. And then i > tried some password to change the expired password but i couldn't and > kerberos told me that it rejected my new password. After three times > i tried to change the password, the kinit command finished with error > message like this "kinit : Password change failed while getting > initial credentials". I don't know how to solve this problem and I > need help. > > A week after i made that IPA user, i could doing kinit with that user > (after kerberos asked for the password and forced me to change the > password, the password was accepted and i could doing kinit). But > after I tried to make new IPA user, i met the same problem with the > problem above (Expired kerberos password). Please help me. > > I am sorry with my English, but I am an Indonesian. About password expiration on user creation, that is the normal behavior and here you can read an article that explains the feature: http://freeipa.org/page/NewPasswordsExpired For your other problem I am not sure, keep in mind that FreeIPA has a default password complexity policy that requires you to use a strong password. If you don't like that you will have to alter and relax the password policies. Simo. -- Simo Sorce * Red Hat, Inc * New York From sgallagh at redhat.com Mon Jul 19 12:23:37 2010 From: sgallagh at redhat.com (Stephen Gallagher) Date: Mon, 19 Jul 2010 08:23:37 -0400 Subject: [Freeipa-users] FreeIPA redundant server login problems In-Reply-To: <4C3DE0B3.5040400@redhat.com> References: <4C3DE0B3.5040400@redhat.com> Message-ID: <4C4443C9.90909@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/14/2010 12:07 PM, Dmitri Pal wrote: > If you use SSSD instead of pam_krb5 then kerberos configuration file is > ignored. > SSSD uses only the SSSD config file. > This statement is not 100% true, unfortunately. The SSSD provides a Kerberos locator plugin that answers requests for most of this information, but it cannot handle all options that are available to the krb5.conf (since the locator API does not support them). Furthermore, there exist some applications (I forget which at this moment) that will read the krb5.conf directly instead of using the locator API. As such, it is unfortunately necessary that both sssd.conf and krb5.conf be properly configured for the host system. If you use authconfig 6.1.4 or later (on Red Hat and Fedora systems) to set up LDAP/Kerberos, both of these files are automatically configured properly. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkxEQ8kACgkQeiVVYja6o6PPTQCfXGJpGTC8Rva69XU4rWQIFqV1 5/QAmwUabdnbzmJA+df+bRSxfeyW0Uu7 =1jc+ -----END PGP SIGNATURE----- From sduckwo at clemson.edu Wed Jul 21 19:22:29 2010 From: sduckwo at clemson.edu (Scott Duckworth) Date: Wed, 21 Jul 2010 15:22:29 -0400 Subject: [Freeipa-users] SSS problems with eDirectory Message-ID: I'm trying to setup a vanilla installation of Fedora 13 to authenticate against an eDirectory server. We have this working on RHEL5 using nss_ldap and pam_ldap, but doing this same configuration on Fedora 13 did not work. So I'm now attempting the configuration using SSS. I used the graphical tools to setup the basics, then started editing /etc/sssd/sssd.conf to get the specifics right. The directory server uses rfc2307bis groups. User DNs do not have memberOf attributes or any shadow or kerberos attributes. Kerberos is not available, LDAP is used for authentication. The SSSD client is sssd-1.2.1-15.fc13.x86_64. /etc/sssd/sssd.conf: [sssd] config_file_version = 2 reconnection_retries = 3 sbus_timeout = 30 services = nss, pam domains = CLEMSONU [nss] debug_level = 7 filter_groups = root filter_users = root reconnection_retries = 3 entry_cache_timeout = 1 entry_cache_nowait_timeout = 1 [pam] debug_level = 7 reconnection_retries = 3 [domain/CLEMSONU] debug_level = 20 enumerate = False cache_credentials = False id_provider = ldap auth_provider = ldap chpass_provider = none min_id = 1000 ldap_uri = ldaps://clemsonuldap.clemson.edu ldap_id_use_start_tls = False ldap_tls_cacertdir = /etc/openldap/cacerts tls_reqcert = demand ldap_default_bind_dn = cn=CoESProxy,ou=proxyUsers,o=CLEMSONU ldap_default_authtok_type = password ldap_default_authtok = xxxxxx ldap_schema = rfc2307bis ldap_search_base = ou=SoC,ou=CES,o=CLEMSONU ldap_user_search_base = o=CLEMSONU ldap_group_search_base = o=CLEMSONU ldap_user_shell = coesLoginShell ldap_user_gecos = fullName ldap_user_fullname = fullName ldap_pwd_policy = none nss_sss appears to be mostly functioning. "getent passwd sduckwo" works. "getent group xxxx" is flaky - the group name and GID are always found, but group members are only sometimes reported, with no rhyme or reason why they are or are not reported. For example: [root at duck2 ~]# getent group coes_socunix coes_socunix:*:120105:sduckwo,duckwos,jdabney,mdabney The log shows: (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] [be_get_account_info] (4): Got request for [4098][1][name=coes_socunix] (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] [sdap_get_generic_send] (6): calling ldap_search_ext with [(&(cn=coes_socunix)(objectclass=posixGroup))][o=CLEMSONU]. (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] [sdap_get_generic_send] (7): Requesting attrs: [objectClass] (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] [sdap_get_generic_send] (7): Requesting attrs: [cn] (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] [sdap_get_generic_send] (7): Requesting attrs: [userPassword] (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] [sdap_get_generic_send] (7): Requesting attrs: [gidNumber] (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] [sdap_get_generic_send] (7): Requesting attrs: [member] (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] [sdap_get_generic_send] (7): Requesting attrs: [nsUniqueId] (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] [sdap_get_generic_send] (7): Requesting attrs: [modifyTimestamp] (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] [sdap_get_generic_send] (8): ldap_search_ext called, msgid = 5 (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] [sdap_process_result] (8): Trace: sh[0x1cf13c0], connected[1], ops[0x1cc6ca0], ldap[0x1cca100] (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] [sdap_parse_entry] (9): OriginalDN: [cn=coes_socunix,ou=group,ou=SoC,ou=CES,o=CLEMSONU]. (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] [sdap_process_result] (8): Trace: sh[0x1cf13c0], connected[1], ops[0x1cc6ca0], ldap[0x1cca100] (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] [sdap_get_generic_done] (6): Search result: Success(0), (null) (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] [sdap_get_groups_process] (6): Search for groups, returned 1 results. (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] [sdap_process_result] (8): Trace: sh[0x1cf13c0], connected[1], ops[(nil)], ldap[0x1cca100] (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] [sdap_process_result] (8): Trace: ldap_result found nothing! (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] [ldb] (9): start ldb transaction (nesting: 0) (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] [sdap_save_group_send] (7): Adding original DN [cn=coes_socunix,ou=group,ou=SoC,ou=CES,o=CLEMSONU] to attributes of [coes_socunix]. (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] [sdap_save_group_send] (6): Storing info for group coes_socunix (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] [sysdb_search_entry_done] (6): Error: Entry not Found! (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] [sysdb_search_entry_done] (6): Error: Entry not Found! (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] [sdap_save_groups_loop] (9): Group 0 processed! (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] [sdap_save_grpmem_send] (7): Adding member users to group [coes_socunix] (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] [sdap_fill_memberships] (9): [IPA or AD Schema] (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] [sdap_fill_memberships] (7): member #0 (cn=SDUCKWO,ou=s,ou=EMPLOYEE,o=CLEMSONU): [name=sduckwo,cn=users,cn=CLEMSONU,cn=sysdb] (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] [sdap_fill_memberships] (7): member #1 (cn=DUCKWOS,ou=d,ou=Students,o=CLEMSONU): [name=duckwos,cn=users,cn=CLEMSONU,cn=sysdb] (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] [sdap_fill_memberships] (7): member #2 (cn=JDABNEY,ou=j,ou=Students,o=CLEMSONU): [name=jdabney,cn=users,cn=CLEMSONU,cn=sysdb] (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] [sdap_fill_memberships] (7): member #3 (cn=MDABNEY,ou=m,ou=Students,o=CLEMSONU): [name=mdabney,cn=users,cn=CLEMSONU,cn=sysdb] (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] [sysdb_search_entry_done] (6): Error: Entry not Found! (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] [sdap_fill_memberships] (7): member #4 (cn=DABNEY,ou=d,ou=EMPLOYEE,o=CLEMSONU): not found! (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] [sysdb_search_entry_done] (6): Error: Entry not Found! (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] [sdap_fill_memberships] (7): member #5 (cn=DABNEY2,ou=d,ou=EMPLOYEE,o=CLEMSONU): not found! (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] [sysdb_search_entry_done] (6): Error: Entry not Found! (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] [sdap_fill_memberships] (7): member #6 (cn=MADPROF,ou=m,ou=EMPLOYEE,o=CLEMSONU): not found! (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] [sysdb_search_entry_done] (6): Error: Entry not Found! (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] [sdap_fill_memberships] (7): member #7 (cn=WAYNE,ou=w,ou=EMPLOYEE,o=CLEMSONU): not found! (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] [sdap_save_grpmem_send] (6): Storing members for group coes_socunix (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] [ldb] (9): commit ldb transaction (nesting: 0) (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] [sdap_get_groups_done] (9): Saving 1 Groups - Done (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success Members #4 - #7 were not found, even though they are valid user DNs. Any thoughts? Moving on... pam_sss does not appear to work. Here's some entries from the SSS log when trying to login to the system on the command-line: (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] [simple_bind_send] (4): Executing simple bind as: cn=CoESProxy,ou=proxyUsers,o=CLEMSONU (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] [simple_bind_done] (3): Bind result: Success(0), (null) (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] [sdap_get_generic_send] (6): calling ldap_search_ext with [(&(uid=sduckwo)(objectclass=posixAccount))][o=CLEMSONU]. (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] [sdap_get_generic_send] (7): Requesting attrs: [objectClass] (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] [sdap_get_generic_send] (7): Requesting attrs: [uid] (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] [sdap_get_generic_send] (7): Requesting attrs: [userPassword] (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] [sdap_get_generic_send] (7): Requesting attrs: [uidNumber] (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] [sdap_get_generic_send] (7): Requesting attrs: [gidNumber] (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] [sdap_get_generic_send] (7): Requesting attrs: [fullName] (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] [sdap_get_generic_send] (7): Requesting attrs: [homeDirectory] (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] [sdap_get_generic_send] (7): Requesting attrs: [coesLoginShell] (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] [sdap_get_generic_send] (7): Requesting attrs: [krbPrincipalName] (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] [sdap_get_generic_send] (7): Requesting attrs: [fullName] (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] [sdap_get_generic_send] (7): Requesting attrs: [memberOf] (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] [sdap_get_generic_send] (7): Requesting attrs: [nsUniqueId] (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] [sdap_get_generic_send] (7): Requesting attrs: [modifyTimestamp] (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] [sdap_get_generic_send] (7): Requesting attrs: [shadowLastChange] (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] [sdap_get_generic_send] (7): Requesting attrs: [shadowMin] (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] [sdap_get_generic_send] (7): Requesting attrs: [shadowMax] (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] [sdap_get_generic_send] (7): Requesting attrs: [shadowWarning] (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] [sdap_get_generic_send] (7): Requesting attrs: [shadowInactive] (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] [sdap_get_generic_send] (7): Requesting attrs: [shadowExpire] (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] [sdap_get_generic_send] (7): Requesting attrs: [shadowFlag] (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] [sdap_get_generic_send] (7): Requesting attrs: [krbLastPwdChange] (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] [sdap_get_generic_send] (7): Requesting attrs: [krbPasswordExpiration] (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] [sdap_get_generic_send] (7): Requesting attrs: [pwdAttribute] (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] [sdap_save_user_send] (7): Adding original DN [cn=SDUCKWO,ou=s,ou=EMPLOYEE,o=CLEMSONU] to attributes of [sduckwo]. (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] [sdap_save_user_send] (7): Original memberOf is not available for [sduckwo]. (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] [sdap_save_user_send] (7): User principal is not available for [sduckwo]. (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] [sdap_save_user_send] (6): Storing info for user sduckwo Up to here, everything looks good. It would be nice to not ask for all of the shadow and krb attributes since they don't exist in our directory, but no harm done. But then things start to go wrong: (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] [sdap_get_initgr_process] (9): Process user's groups (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] [sdap_initgr_nested_send] (4): User entry lacks original memberof ? (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] [sdap_get_initgr_done] (9): Initgroups done (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] [acctinfo_callback] (4): Request processed. Returned 3,2,Init Groups Failed Our directory doesn't use the memberOf user attribute, it just uses rfc2307bis style groups (objectClass=posixUser, member=). Then, here's where things really go awry: (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] [find_password_expiration_attributes] (9): No password policy requested. (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] [simple_bind_send] (4): Executing simple bind as: cn=SDUCKWO,ou=s,ou=EMPLOYEE,o=CLEMSONU (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] [sdap_process_result] (4): ldap_result gave -1, something bad happend! (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] [auth_bind_user_done] (9): Found ppolicy data, assuming LDAP password policies are active. (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] [be_pam_handler_callback] (4): Backend returned: (3, 4, ) [Internal Error (Interrupted system call)] "something bad happened" isn't very useful. And since SSS refuses to try and authenticate users without an encrypted connection, I can't easily use wireshark and friends to debug at the protocol level. While I could probably patch the source to print the actual LDAP error with ldap_err2string(), or maybe gdb the process and set a breakpoint when things go wrong to hopefully get some more useful information, this is beyond what I'd normally consider doing when deploying new software. Any suggestions? Moving on... We will need to dereference LDAP aliases but I have not yet been able to find a setting to enable this. I also have not found the equivalent of the pam_password_prohibit_message setting in /etc/ldap.conf; while not strictly required, it is nice to refer users to the proper way to change passwords in our environment. Any help would be appreciated. Thanks! Scott Duckworth, Systems Programmer II Clemson University School of Computing -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Wed Jul 21 21:58:33 2010 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 21 Jul 2010 17:58:33 -0400 Subject: [Freeipa-users] SSS problems with eDirectory In-Reply-To: References: Message-ID: <4C476D89.6010603@redhat.com> Scott Duckworth wrote: > I'm trying to setup a vanilla installation of Fedora 13 to > authenticate against an eDirectory server. We have this working on > RHEL5 using nss_ldap and pam_ldap, but doing this same configuration > on Fedora 13 did not work. So I'm now attempting the configuration > using SSS. I used the graphical tools to setup the basics, then > started editing /etc/sssd/sssd.conf to get the specifics right. > > The directory server uses rfc2307bis groups. User DNs do not have > memberOf attributes or any shadow or kerberos attributes. Kerberos is > not available, LDAP is used for authentication. > > The SSSD client is sssd-1.2.1-15.fc13.x86_64. > > /etc/sssd/sssd.conf: > [sssd] > config_file_version = 2 > reconnection_retries = 3 > sbus_timeout = 30 > services = nss, pam > domains = CLEMSONU > [nss] > debug_level = 7 > filter_groups = root > filter_users = root > reconnection_retries = 3 > entry_cache_timeout = 1 > entry_cache_nowait_timeout = 1 > [pam] > debug_level = 7 > reconnection_retries = 3 > [domain/CLEMSONU] > debug_level = 20 > enumerate = False > cache_credentials = False > id_provider = ldap > auth_provider = ldap Try adding here ldap_schema = rfc2307bis > chpass_provider = none > min_id = 1000 > ldap_uri = ldaps://clemsonuldap.clemson.edu > > ldap_id_use_start_tls = False > ldap_tls_cacertdir = /etc/openldap/cacerts > tls_reqcert = demand > ldap_default_bind_dn = cn=CoESProxy,ou=proxyUsers,o=CLEMSONU > ldap_default_authtok_type = password > ldap_default_authtok = xxxxxx > ldap_schema = rfc2307bis > ldap_search_base = ou=SoC,ou=CES,o=CLEMSONU > ldap_user_search_base = o=CLEMSONU > ldap_group_search_base = o=CLEMSONU > ldap_user_shell = coesLoginShell > ldap_user_gecos = fullName > ldap_user_fullname = fullName > ldap_pwd_policy = none > > nss_sss appears to be mostly functioning. "getent passwd sduckwo" > works. "getent group xxxx" is flaky - the group name and GID are > always found, but group members are only sometimes reported, with no > rhyme or reason why they are or are not reported. For example: > > [root at duck2 ~]# getent group coes_socunix > coes_socunix:*:120105:sduckwo,duckwos,jdabney,mdabney > > The log shows: > > (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] [be_get_account_info] > (4): Got request for [4098][1][name=coes_socunix] > (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] > [sdap_get_generic_send] (6): calling ldap_search_ext with > [(&(cn=coes_socunix)(objectclass=posixGroup))][o=CLEMSONU]. > (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] > [sdap_get_generic_send] (7): Requesting attrs: [objectClass] > (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] > [sdap_get_generic_send] (7): Requesting attrs: [cn] > (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] > [sdap_get_generic_send] (7): Requesting attrs: [userPassword] > (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] > [sdap_get_generic_send] (7): Requesting attrs: [gidNumber] > (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] > [sdap_get_generic_send] (7): Requesting attrs: [member] > (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] > [sdap_get_generic_send] (7): Requesting attrs: [nsUniqueId] > (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] > [sdap_get_generic_send] (7): Requesting attrs: [modifyTimestamp] > (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] > [sdap_get_generic_send] (8): ldap_search_ext called, msgid = 5 > (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] [sdap_process_result] > (8): Trace: sh[0x1cf13c0], connected[1], ops[0x1cc6ca0], ldap[0x1cca100] > (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] [sdap_parse_entry] > (9): OriginalDN: [cn=coes_socunix,ou=group,ou=SoC,ou=CES,o=CLEMSONU]. > (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] [sdap_process_result] > (8): Trace: sh[0x1cf13c0], connected[1], ops[0x1cc6ca0], ldap[0x1cca100] > (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] > [sdap_get_generic_done] (6): Search result: Success(0), (null) > (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] > [sdap_get_groups_process] (6): Search for groups, returned 1 results. > (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] [sdap_process_result] > (8): Trace: sh[0x1cf13c0], connected[1], ops[(nil)], ldap[0x1cca100] > (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] [sdap_process_result] > (8): Trace: ldap_result found nothing! > (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] [ldb] (9): start ldb > transaction (nesting: 0) > (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] [sdap_save_group_send] > (7): Adding original DN > [cn=coes_socunix,ou=group,ou=SoC,ou=CES,o=CLEMSONU] to attributes of > [coes_socunix]. > (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] [sdap_save_group_send] > (6): Storing info for group coes_socunix > (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] > [sysdb_search_entry_done] (6): Error: Entry not Found! > (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] > [sysdb_search_entry_done] (6): Error: Entry not Found! > (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] > [sdap_save_groups_loop] (9): Group 0 processed! > (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] > [sdap_save_grpmem_send] (7): Adding member users to group [coes_socunix] > (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] > [sdap_fill_memberships] (9): [IPA or AD Schema] > (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] > [sdap_fill_memberships] (7): member #0 > (cn=SDUCKWO,ou=s,ou=EMPLOYEE,o=CLEMSONU): > [name=sduckwo,cn=users,cn=CLEMSONU,cn=sysdb] > (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] > [sdap_fill_memberships] (7): member #1 > (cn=DUCKWOS,ou=d,ou=Students,o=CLEMSONU): > [name=duckwos,cn=users,cn=CLEMSONU,cn=sysdb] > (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] > [sdap_fill_memberships] (7): member #2 > (cn=JDABNEY,ou=j,ou=Students,o=CLEMSONU): > [name=jdabney,cn=users,cn=CLEMSONU,cn=sysdb] > (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] > [sdap_fill_memberships] (7): member #3 > (cn=MDABNEY,ou=m,ou=Students,o=CLEMSONU): > [name=mdabney,cn=users,cn=CLEMSONU,cn=sysdb] > (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] > [sysdb_search_entry_done] (6): Error: Entry not Found! > (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] > [sdap_fill_memberships] (7): member #4 > (cn=DABNEY,ou=d,ou=EMPLOYEE,o=CLEMSONU): not found! > (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] > [sysdb_search_entry_done] (6): Error: Entry not Found! > (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] > [sdap_fill_memberships] (7): member #5 > (cn=DABNEY2,ou=d,ou=EMPLOYEE,o=CLEMSONU): not found! > (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] > [sysdb_search_entry_done] (6): Error: Entry not Found! > (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] > [sdap_fill_memberships] (7): member #6 > (cn=MADPROF,ou=m,ou=EMPLOYEE,o=CLEMSONU): not found! > (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] > [sysdb_search_entry_done] (6): Error: Entry not Found! > (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] > [sdap_fill_memberships] (7): member #7 > (cn=WAYNE,ou=w,ou=EMPLOYEE,o=CLEMSONU): not found! > (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] > [sdap_save_grpmem_send] (6): Storing members for group coes_socunix > (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] [ldb] (9): commit ldb > transaction (nesting: 0) > (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] [sdap_get_groups_done] > (9): Saving 1 Groups - Done > (Wed Jul 21 14:55:39 2010) [sssd[be[CLEMSONU]]] [acctinfo_callback] > (4): Request processed. Returned 0,0,Success > > Members #4 - #7 were not found, even though they are valid user DNs. > Any thoughts? > > Moving on... > > pam_sss does not appear to work. Here's some entries from the SSS log > when trying to login to the system on the command-line: > > (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] [simple_bind_send] > (4): Executing simple bind as: cn=CoESProxy,ou=proxyUsers,o=CLEMSONU > (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] [simple_bind_done] > (3): Bind result: Success(0), (null) > (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] > [sdap_get_generic_send] (6): calling ldap_search_ext with > [(&(uid=sduckwo)(objectclass=posixAccount))][o=CLEMSONU]. > (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] > [sdap_get_generic_send] (7): Requesting attrs: [objectClass] > (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] > [sdap_get_generic_send] (7): Requesting attrs: [uid] > (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] > [sdap_get_generic_send] (7): Requesting attrs: [userPassword] > (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] > [sdap_get_generic_send] (7): Requesting attrs: [uidNumber] > (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] > [sdap_get_generic_send] (7): Requesting attrs: [gidNumber] > (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] > [sdap_get_generic_send] (7): Requesting attrs: [fullName] > (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] > [sdap_get_generic_send] (7): Requesting attrs: [homeDirectory] > (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] > [sdap_get_generic_send] (7): Requesting attrs: [coesLoginShell] > (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] > [sdap_get_generic_send] (7): Requesting attrs: [krbPrincipalName] > (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] > [sdap_get_generic_send] (7): Requesting attrs: [fullName] > (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] > [sdap_get_generic_send] (7): Requesting attrs: [memberOf] > (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] > [sdap_get_generic_send] (7): Requesting attrs: [nsUniqueId] > (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] > [sdap_get_generic_send] (7): Requesting attrs: [modifyTimestamp] > (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] > [sdap_get_generic_send] (7): Requesting attrs: [shadowLastChange] > (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] > [sdap_get_generic_send] (7): Requesting attrs: [shadowMin] > (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] > [sdap_get_generic_send] (7): Requesting attrs: [shadowMax] > (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] > [sdap_get_generic_send] (7): Requesting attrs: [shadowWarning] > (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] > [sdap_get_generic_send] (7): Requesting attrs: [shadowInactive] > (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] > [sdap_get_generic_send] (7): Requesting attrs: [shadowExpire] > (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] > [sdap_get_generic_send] (7): Requesting attrs: [shadowFlag] > (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] > [sdap_get_generic_send] (7): Requesting attrs: [krbLastPwdChange] > (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] > [sdap_get_generic_send] (7): Requesting attrs: [krbPasswordExpiration] > (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] > [sdap_get_generic_send] (7): Requesting attrs: [pwdAttribute] > (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] [sdap_save_user_send] > (7): Adding original DN [cn=SDUCKWO,ou=s,ou=EMPLOYEE,o=CLEMSONU] to > attributes of [sduckwo]. > (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] [sdap_save_user_send] > (7): Original memberOf is not available for [sduckwo]. > (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] [sdap_save_user_send] > (7): User principal is not available for [sduckwo]. > (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] [sdap_save_user_send] > (6): Storing info for user sduckwo > > Up to here, everything looks good. It would be nice to not ask for > all of the shadow and krb attributes since they don't exist in our > directory, but no harm done. > > But then things start to go wrong: > > (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] > [sdap_get_initgr_process] (9): Process user's groups > (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] > [sdap_initgr_nested_send] (4): User entry lacks original memberof ? > (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] [sdap_get_initgr_done] > (9): Initgroups done > (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] [acctinfo_callback] > (4): Request processed. Returned 3,2,Init Groups Failed > > Our directory doesn't use the memberOf user attribute, it just uses > rfc2307bis style groups (objectClass=posixUser, member=). > > Then, here's where things really go awry: > > (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] > [find_password_expiration_attributes] (9): No password policy requested. > (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] [simple_bind_send] > (4): Executing simple bind as: cn=SDUCKWO,ou=s,ou=EMPLOYEE,o=CLEMSONU > (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] [sdap_process_result] > (4): ldap_result gave -1, something bad happend! > (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] [auth_bind_user_done] > (9): Found ppolicy data, assuming LDAP password policies are active. > (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] > [be_pam_handler_callback] (4): Backend returned: (3, 4, ) > [Internal Error (Interrupted system call)] > > "something bad happened" isn't very useful. And since SSS refuses to > try and authenticate users without an encrypted connection, I can't > easily use wireshark and friends to debug at the protocol level. > While I could probably patch the source to print the actual LDAP error > with ldap_err2string(), or maybe gdb the process and set a breakpoint > when things go wrong to hopefully get some more useful information, > this is beyond what I'd normally consider doing when deploying new > software. Any suggestions? > > Moving on... > > We will need to dereference LDAP aliases but I have not yet been able > to find a setting to enable this. I also have not found the > equivalent of the pam_password_prohibit_message setting in > /etc/ldap.conf; while not strictly required, it is nice to refer users > to the proper way to change passwords in our environment. > > Any help would be appreciated. Thanks! > > Scott Duckworth, Systems Programmer II > Clemson University School of Computing > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From sbose at redhat.com Thu Jul 22 08:19:37 2010 From: sbose at redhat.com (Sumit Bose) Date: Thu, 22 Jul 2010 10:19:37 +0200 Subject: [Freeipa-users] SSS problems with eDirectory In-Reply-To: References: Message-ID: <20100722081937.GN27552@localhost.localdomain> On Wed, Jul 21, 2010 at 03:22:29PM -0400, Scott Duckworth wrote: ... > > "something bad happened" isn't very useful. And since SSS refuses to try > and authenticate users without an encrypted connection, I can't easily use > wireshark and friends to debug at the protocol level. While I could > probably patch the source to print the actual LDAP error with > ldap_err2string(), or maybe gdb the process and set a breakpoint when things > go wrong to hopefully get some more useful information, this is beyond what > I'd normally consider doing when deploying new software. Any suggestions? I'm currently installing eDirectory and I will try to reproduce the behaviour you have found. > > Moving on... > > We will need to dereference LDAP aliases but I have not yet been able to > find a setting to enable this. I also have not found the equivalent of the I have added a RFE to sssd trac (https://fedorahosted.org/sssd/ticket/568). As a sort term fix you can add the appropriate DEREF option to /etc/openldap/ldap.conf. > pam_password_prohibit_message setting in /etc/ldap.conf; while not strictly > required, it is nice to refer users to the proper way to change passwords in > our environment. Currently there is only a configurable message if password resets by root fail. I have added https://fedorahosted.org/sssd/ticket/569 to track this. bye, Sumit > > Any help would be appreciated. Thanks! > > Scott Duckworth, Systems Programmer II > Clemson University School of Computing > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From sbose at redhat.com Thu Jul 22 15:07:41 2010 From: sbose at redhat.com (Sumit Bose) Date: Thu, 22 Jul 2010 17:07:41 +0200 Subject: [Freeipa-users] SSS problems with eDirectory In-Reply-To: <20100722081937.GN27552@localhost.localdomain> References: <20100722081937.GN27552@localhost.localdomain> Message-ID: <20100722150741.GP27552@localhost.localdomain> On Thu, Jul 22, 2010 at 10:19:37AM +0200, Sumit Bose wrote: > On Wed, Jul 21, 2010 at 03:22:29PM -0400, Scott Duckworth wrote: > > ... > > > > > "something bad happened" isn't very useful. And since SSS refuses to try > > and authenticate users without an encrypted connection, I can't easily use > > wireshark and friends to debug at the protocol level. While I could > > probably patch the source to print the actual LDAP error with > > ldap_err2string(), or maybe gdb the process and set a breakpoint when things > > go wrong to hopefully get some more useful information, this is beyond what > > I'd normally consider doing when deploying new software. Any suggestions? > > I'm currently installing eDirectory and I will try to reproduce the > behaviour you have found. I have run some basic authentication test with eDirectory 8.8-SP5 and everything worked fine. I have to admit that I have used the current master of sssd which includes a lot of changes to the LDAP code. Would you mind to test our current beta release from http://kojipkgs.fedoraproject.org/packages/sssd/1.2.91/21.fc14/ . It is for rawhide but should work fine on F13, too. I also didn't use LDAP aliases. Can you check if setting DEREF in /etc/openldap/ldap.conf helps? If not, can you give a short description how aliases are used in your case so that I can set up a similar environment? Thanks. bye, Sumit > > > > > Moving on... > > > > We will need to dereference LDAP aliases but I have not yet been able to > > find a setting to enable this. I also have not found the equivalent of the > > I have added a RFE to sssd trac > (https://fedorahosted.org/sssd/ticket/568). As a sort term fix you can > add the appropriate DEREF option to /etc/openldap/ldap.conf. > > > pam_password_prohibit_message setting in /etc/ldap.conf; while not strictly > > required, it is nice to refer users to the proper way to change passwords in > > our environment. > > Currently there is only a configurable message if password resets by > root fail. I have added https://fedorahosted.org/sssd/ticket/569 to > track this. > > bye, > Sumit > > > > > Any help would be appreciated. Thanks! > > > > Scott Duckworth, Systems Programmer II > > Clemson University School of Computing > > > _______________________________________________ > > 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 sduckwo at clemson.edu Thu Jul 22 15:10:25 2010 From: sduckwo at clemson.edu (Scott Duckworth) Date: Thu, 22 Jul 2010 11:10:25 -0400 Subject: [Freeipa-users] SSS problems with eDirectory In-Reply-To: <4C477238.8020008@redhat.com> References: <4C476D89.6010603@redhat.com> <4C477238.8020008@redhat.com> Message-ID: On Wed, Jul 21, 2010 at 6:18 PM, Dmitri Pal wrote: > Scott Duckworth wrote: > > On Wed, Jul 21, 2010 at 5:58 PM, Dmitri Pal > > wrote: > > > > Scott Duckworth wrote: > > > I'm trying to setup a vanilla installation of Fedora 13 to > > > authenticate against an eDirectory server. We have this working on > > > RHEL5 using nss_ldap and pam_ldap, but doing this same > configuration > > > on Fedora 13 did not work. So I'm now attempting the configuration > > > using SSS. I used the graphical tools to setup the basics, then > > > started editing /etc/sssd/sssd.conf to get the specifics right. > > > > > > The directory server uses rfc2307bis groups. User DNs do not have > > > memberOf attributes or any shadow or kerberos attributes. > > Kerberos is > > > not available, LDAP is used for authentication. > > > > > > The SSSD client is sssd-1.2.1-15.fc13.x86_64. > > > > > > /etc/sssd/sssd.conf: > > > [sssd] > > > config_file_version = 2 > > > reconnection_retries = 3 > > > sbus_timeout = 30 > > > services = nss, pam > > > domains = CLEMSONU > > > [nss] > > > debug_level = 7 > > > filter_groups = root > > > filter_users = root > > > reconnection_retries = 3 > > > entry_cache_timeout = 1 > > > entry_cache_nowait_timeout = 1 > > > [pam] > > > debug_level = 7 > > > reconnection_retries = 3 > > > [domain/CLEMSONU] > > > debug_level = 20 > > > enumerate = False > > > cache_credentials = False > > > id_provider = ldap > > > auth_provider = ldap > > Try adding here > > > > ldap_schema = rfc2307bis > > > > > > No difference. > > I assume you restarted SSSD and probably cleared the cache since it > might already got it wrong. > > Instructions for cleaning: > Beginning with version 0.6.0, SSSD maintains a separate database file > for each domain. This means that each domain has its own cache, and in > the event that problems occur and maintenance is necessary, it is very > easy to purge the cache for a single domain, by stopping |sssd| and > deleting the corresponding cache file. These cache files are stored in > the |/var/lib/sss/db/| directory. > All cache files are named according to the domain that they represent, > for example |cache_/|DOMAINNAME|/.ldb|. > I removed all files from /var/lib/sss/db/ and restarted sssd. Same behavior. nscd is disabled, so I don't think it's caching at any level. Here is what I ran: [root at duck2 ~]# getent passwd sduckwo sduckwo:*:45265:10000:Scott Duckworth:/home/sduckwo:/bin/bash [root at duck2 ~]# groups sduckwo sduckwo : cuuser [root at duck2 ~]# getent group coes_socunix coes_socunix:*:120105:sduckwo And here is what the domain log shows: (Thu Jul 22 10:59:15 2010) [sssd[be[CLEMSONU]]] [sbus_message_handler] (9): Received SBUS method [getAccountInfo] (Thu Jul 22 10:59:15 2010) [sssd[be[CLEMSONU]]] [be_get_account_info] (4): Got request for [4098][1][name=coes_socunix] (Thu Jul 22 10:59:15 2010) [sssd[be[CLEMSONU]]] [sdap_get_generic_send] (6): calling ldap_search_ext with [(&(cn=coes_socunix)(objectclass=posixGroup))][o=CLEMSONU]. (Thu Jul 22 10:59:15 2010) [sssd[be[CLEMSONU]]] [sdap_get_generic_send] (7): Requesting attrs: [objectClass] (Thu Jul 22 10:59:15 2010) [sssd[be[CLEMSONU]]] [sdap_get_generic_send] (7): Requesting attrs: [cn] (Thu Jul 22 10:59:15 2010) [sssd[be[CLEMSONU]]] [sdap_get_generic_send] (7): Requesting attrs: [userPassword] (Thu Jul 22 10:59:15 2010) [sssd[be[CLEMSONU]]] [sdap_get_generic_send] (7): Requesting attrs: [gidNumber] (Thu Jul 22 10:59:15 2010) [sssd[be[CLEMSONU]]] [sdap_get_generic_send] (7): Requesting attrs: [member] (Thu Jul 22 10:59:15 2010) [sssd[be[CLEMSONU]]] [sdap_get_generic_send] (7): Requesting attrs: [nsUniqueId] (Thu Jul 22 10:59:15 2010) [sssd[be[CLEMSONU]]] [sdap_get_generic_send] (7): Requesting attrs: [modifyTimestamp] (Thu Jul 22 10:59:15 2010) [sssd[be[CLEMSONU]]] [sdap_get_generic_send] (8): ldap_search_ext called, msgid = 6 (Thu Jul 22 10:59:15 2010) [sssd[be[CLEMSONU]]] [sdap_process_result] (8): Trace: sh[0xc55ad0], connected[1], ops[0xd5d5a0], ldap[0xc55cf0] (Thu Jul 22 10:59:15 2010) [sssd[be[CLEMSONU]]] [sdap_parse_entry] (9): OriginalDN: [cn=coes_socunix,ou=group,ou=SoC,ou=CES,o=CLEMSONU]. (Thu Jul 22 10:59:15 2010) [sssd[be[CLEMSONU]]] [sdap_process_result] (8): Trace: sh[0xc55ad0], connected[1], ops[0xd5d5a0], ldap[0xc55cf0] (Thu Jul 22 10:59:15 2010) [sssd[be[CLEMSONU]]] [sdap_get_generic_done] (6): Search result: Success(0), (null) (Thu Jul 22 10:59:15 2010) [sssd[be[CLEMSONU]]] [sdap_get_groups_process] (6): Search for groups, returned 1 results. (Thu Jul 22 10:59:15 2010) [sssd[be[CLEMSONU]]] [sdap_process_result] (8): Trace: sh[0xc55ad0], connected[1], ops[(nil)], ldap[0xc55cf0] (Thu Jul 22 10:59:15 2010) [sssd[be[CLEMSONU]]] [sdap_process_result] (8): Trace: ldap_result found nothing! (Thu Jul 22 10:59:15 2010) [sssd[be[CLEMSONU]]] [ldb] (9): start ldb transaction (nesting: 0) (Thu Jul 22 10:59:15 2010) [sssd[be[CLEMSONU]]] [sdap_save_group_send] (7): Adding original DN [cn=coes_socunix,ou=group,ou=SoC,ou=CES,o=CLEMSONU] to attributes of [coes_socunix]. (Thu Jul 22 10:59:15 2010) [sssd[be[CLEMSONU]]] [sdap_save_group_send] (6): Storing info for group coes_socunix (Thu Jul 22 10:59:15 2010) [sssd[be[CLEMSONU]]] [sysdb_search_entry_done] (6): Error: Entry not Found! (Thu Jul 22 10:59:15 2010) [sssd[be[CLEMSONU]]] [sysdb_search_entry_done] (6): Error: Entry not Found! (Thu Jul 22 10:59:15 2010) [sssd[be[CLEMSONU]]] [sdap_save_groups_loop] (9): Group 0 processed! (Thu Jul 22 10:59:15 2010) [sssd[be[CLEMSONU]]] [sdap_save_grpmem_send] (7): Adding member users to group [coes_socunix] (Thu Jul 22 10:59:15 2010) [sssd[be[CLEMSONU]]] [sdap_fill_memberships] (9): [IPA or AD Schema] (Thu Jul 22 10:59:15 2010) [sssd[be[CLEMSONU]]] [sdap_fill_memberships] (7): member #0 (cn=SDUCKWO,ou=s,ou=EMPLOYEE,o=CLEMSONU): [name=sduckwo,cn=users,cn=CLEMSONU,cn=sysdb] (Thu Jul 22 10:59:15 2010) [sssd[be[CLEMSONU]]] [sysdb_search_entry_done] (6): Error: Entry not Found! (Thu Jul 22 10:59:15 2010) [sssd[be[CLEMSONU]]] [sdap_fill_memberships] (7): member #1 (cn=DUCKWOS,ou=d,ou=Students,o=CLEMSONU): not found! (Thu Jul 22 10:59:15 2010) [sssd[be[CLEMSONU]]] [sysdb_search_entry_done] (6): Error: Entry not Found! (Thu Jul 22 10:59:15 2010) [sssd[be[CLEMSONU]]] [sdap_fill_memberships] (7): member #2 (cn=JDABNEY,ou=j,ou=Students,o=CLEMSONU): not found! (Thu Jul 22 10:59:15 2010) [sssd[be[CLEMSONU]]] [sysdb_search_entry_done] (6): Error: Entry not Found! (Thu Jul 22 10:59:15 2010) [sssd[be[CLEMSONU]]] [sdap_fill_memberships] (7): member #3 (cn=MDABNEY,ou=m,ou=Students,o=CLEMSONU): not found! (Thu Jul 22 10:59:15 2010) [sssd[be[CLEMSONU]]] [sysdb_search_entry_done] (6): Error: Entry not Found! (Thu Jul 22 10:59:15 2010) [sssd[be[CLEMSONU]]] [sdap_fill_memberships] (7): member #4 (cn=DABNEY,ou=d,ou=EMPLOYEE,o=CLEMSONU): not found! (Thu Jul 22 10:59:15 2010) [sssd[be[CLEMSONU]]] [sysdb_search_entry_done] (6): Error: Entry not Found! (Thu Jul 22 10:59:15 2010) [sssd[be[CLEMSONU]]] [sdap_fill_memberships] (7): member #5 (cn=DABNEY2,ou=d,ou=EMPLOYEE,o=CLEMSONU): not found! (Thu Jul 22 10:59:15 2010) [sssd[be[CLEMSONU]]] [sysdb_search_entry_done] (6): Error: Entry not Found! (Thu Jul 22 10:59:15 2010) [sssd[be[CLEMSONU]]] [sdap_fill_memberships] (7): member #6 (cn=MADPROF,ou=m,ou=EMPLOYEE,o=CLEMSONU): not found! (Thu Jul 22 10:59:15 2010) [sssd[be[CLEMSONU]]] [sysdb_search_entry_done] (6): Error: Entry not Found! (Thu Jul 22 10:59:15 2010) [sssd[be[CLEMSONU]]] [sdap_fill_memberships] (7): member #7 (cn=WAYNE,ou=w,ou=EMPLOYEE,o=CLEMSONU): not found! (Thu Jul 22 10:59:15 2010) [sssd[be[CLEMSONU]]] [sdap_save_grpmem_send] (6): Storing members for group coes_socunix (Thu Jul 22 10:59:15 2010) [sssd[be[CLEMSONU]]] [ldb] (9): commit ldb transaction (nesting: 0) (Thu Jul 22 10:59:15 2010) [sssd[be[CLEMSONU]]] [sdap_get_groups_done] (9): Saving 1 Groups - Done (Thu Jul 22 10:59:15 2010) [sssd[be[CLEMSONU]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success It looks like it's only recognizing user DNs which have already been cached. > If this does not help then you need to wait till tomorrow for Steve > Gallagher to reply to you. He is gone for the day. > > -- > Thank you, > Dmitri Pal > > Engineering Manager IPA project, > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ssorce at redhat.com Thu Jul 22 15:59:33 2010 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 22 Jul 2010 11:59:33 -0400 Subject: [Freeipa-users] SSS problems with eDirectory In-Reply-To: References: <4C476D89.6010603@redhat.com> <4C477238.8020008@redhat.com> Message-ID: <20100722115933.419f0614@willson.li.ssimo.org> On Thu, 22 Jul 2010 11:10:25 -0400 Scott Duckworth wrote: > I removed all files from /var/lib/sss/db/ and restarted sssd. Same > behavior. nscd is disabled, so I don't think it's caching at any > level. > > Here is what I ran: > > [root at duck2 ~]# getent passwd sduckwo > sduckwo:*:45265:10000:Scott Duckworth:/home/sduckwo:/bin/bash > [root at duck2 ~]# groups sduckwo > sduckwo : cuuser > [root at duck2 ~]# getent group coes_socunix > coes_socunix:*:120105:sduckwo When enumeration is disabled this is the normal behavior. You will see only users/groups that have been fetched. Generally at login time because of the initgroups call. Ie a users will always have correct memmberships, but groups may not should all user members they truly have in the ldap server. If you require perfect representation you will have to turn on enumeration. This will eventually show up all the memberships although on the first startup it may take a while to show all groups, until they have all been downloaded and cached. Changes to group memberships may also take some time to show as enumerations are scheduled periodically and results cached. Of cours when a user logs in its information (including its group membership) is refreshed and validated, so at login time the membership is correctly updated for that user across all its groups. Simo. -- Simo Sorce * Red Hat, Inc * New York From sduckwo at clemson.edu Thu Jul 22 15:19:44 2010 From: sduckwo at clemson.edu (Scott Duckworth) Date: Thu, 22 Jul 2010 11:19:44 -0400 Subject: [Freeipa-users] SSS problems with eDirectory In-Reply-To: <20100722150741.GP27552@localhost.localdomain> References: <20100722081937.GN27552@localhost.localdomain> <20100722150741.GP27552@localhost.localdomain> Message-ID: On Thu, Jul 22, 2010 at 11:07 AM, Sumit Bose wrote: > On Thu, Jul 22, 2010 at 10:19:37AM +0200, Sumit Bose wrote: > > On Wed, Jul 21, 2010 at 03:22:29PM -0400, Scott Duckworth wrote: > > > > ... > > > > > > > > "something bad happened" isn't very useful. And since SSS refuses to > try > > > and authenticate users without an encrypted connection, I can't easily > use > > > wireshark and friends to debug at the protocol level. While I could > > > probably patch the source to print the actual LDAP error with > > > ldap_err2string(), or maybe gdb the process and set a breakpoint when > things > > > go wrong to hopefully get some more useful information, this is beyond > what > > > I'd normally consider doing when deploying new software. Any > suggestions? > > > > I'm currently installing eDirectory and I will try to reproduce the > > behaviour you have found. > > I have run some basic authentication test with eDirectory 8.8-SP5 and > everything worked fine. I have to admit that I have used the current > master of sssd which includes a lot of changes to the LDAP code. Would > you mind to test our current beta release from > http://kojipkgs.fedoraproject.org/packages/sssd/1.2.91/21.fc14/ . It is > for rawhide but should work fine on F13, too. > Sure, I'll give it a shot and report back what I find. > I also didn't use LDAP aliases. Can you check if setting DEREF in > /etc/openldap/ldap.conf helps? If not, can you give a short description > how aliases are used in your case so that I can set up a similar > environment? > Setting DEREF to always in /etc/openldap/ldap.conf works. Aliasing is only needed for one DN in our tree: everyone's default group is aliased to another DN in another branch of the tree. I wish there were some way to enable aliasing on a per-map basis (e.g. only groups or only users) so that you'd only take the performance hit where necessary, but I'm not aware of any NSS LDAP client that does this. > Thanks. > > bye, > Sumit > > > > > > > > > Moving on... > > > > > > We will need to dereference LDAP aliases but I have not yet been able > to > > > find a setting to enable this. I also have not found the equivalent of > the > > > > I have added a RFE to sssd trac > > (https://fedorahosted.org/sssd/ticket/568). As a sort term fix you can > > add the appropriate DEREF option to /etc/openldap/ldap.conf. > > > > > pam_password_prohibit_message setting in /etc/ldap.conf; while not > strictly > > > required, it is nice to refer users to the proper way to change > passwords in > > > our environment. > > > > Currently there is only a configurable message if password resets by > > root fail. I have added https://fedorahosted.org/sssd/ticket/569 to > > track this. > > > > bye, > > Sumit > > > > > > > > Any help would be appreciated. Thanks! > > > > > > Scott Duckworth, Systems Programmer II > > > Clemson University School of Computing > > > > > _______________________________________________ > > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sduckwo at clemson.edu Thu Jul 22 15:47:08 2010 From: sduckwo at clemson.edu (Scott Duckworth) Date: Thu, 22 Jul 2010 11:47:08 -0400 Subject: [Freeipa-users] SSS problems with eDirectory In-Reply-To: References: <20100722081937.GN27552@localhost.localdomain> <20100722150741.GP27552@localhost.localdomain> Message-ID: On Thu, Jul 22, 2010 at 11:19 AM, Scott Duckworth wrote: > On Thu, Jul 22, 2010 at 11:07 AM, Sumit Bose wrote: > >> On Thu, Jul 22, 2010 at 10:19:37AM +0200, Sumit Bose wrote: >> > On Wed, Jul 21, 2010 at 03:22:29PM -0400, Scott Duckworth wrote: >> > >> > ... >> > >> > > >> > > "something bad happened" isn't very useful. And since SSS refuses to >> try >> > > and authenticate users without an encrypted connection, I can't easily >> use >> > > wireshark and friends to debug at the protocol level. While I could >> > > probably patch the source to print the actual LDAP error with >> > > ldap_err2string(), or maybe gdb the process and set a breakpoint when >> things >> > > go wrong to hopefully get some more useful information, this is beyond >> what >> > > I'd normally consider doing when deploying new software. Any >> suggestions? >> > >> > I'm currently installing eDirectory and I will try to reproduce the >> > behaviour you have found. >> >> I have run some basic authentication test with eDirectory 8.8-SP5 and >> everything worked fine. I have to admit that I have used the current >> master of sssd which includes a lot of changes to the LDAP code. Would >> you mind to test our current beta release from >> http://kojipkgs.fedoraproject.org/packages/sssd/1.2.91/21.fc14/ . It is >> for rawhide but should work fine on F13, too. >> > > Sure, I'll give it a shot and report back what I find. > "yum localinstall libcollection-0.5.0-21.fc14.* libini_config-0.6.0-21.fc14.* sssd-1.2.91-21.fc14.* sssd-client-1.2.91-21.fc14.*" requires python 2.7. Adding python-2.7-3.fc14.* and python-libs-2.7-3.fc14.* results in a slew of dependency resolution errors. If I get the chance in the few days, I'll try it under rawhide. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbose at redhat.com Thu Jul 22 16:05:36 2010 From: sbose at redhat.com (Sumit Bose) Date: Thu, 22 Jul 2010 18:05:36 +0200 Subject: [Freeipa-users] SSS problems with eDirectory In-Reply-To: References: <20100722081937.GN27552@localhost.localdomain> <20100722150741.GP27552@localhost.localdomain> Message-ID: <20100722160536.GQ27552@localhost.localdomain> On Thu, Jul 22, 2010 at 11:19:44AM -0400, Scott Duckworth wrote: > On Thu, Jul 22, 2010 at 11:07 AM, Sumit Bose wrote: > > > On Thu, Jul 22, 2010 at 10:19:37AM +0200, Sumit Bose wrote: > > > On Wed, Jul 21, 2010 at 03:22:29PM -0400, Scott Duckworth wrote: > > > > > > ... > > > > > > > > > > > "something bad happened" isn't very useful. And since SSS refuses to > > try > > > > and authenticate users without an encrypted connection, I can't easily > > use > > > > wireshark and friends to debug at the protocol level. While I could > > > > probably patch the source to print the actual LDAP error with > > > > ldap_err2string(), or maybe gdb the process and set a breakpoint when > > things > > > > go wrong to hopefully get some more useful information, this is beyond > > what > > > > I'd normally consider doing when deploying new software. Any > > suggestions? > > > > > > I'm currently installing eDirectory and I will try to reproduce the > > > behaviour you have found. > > > > I have run some basic authentication test with eDirectory 8.8-SP5 and > > everything worked fine. I have to admit that I have used the current > > master of sssd which includes a lot of changes to the LDAP code. Would > > you mind to test our current beta release from > > http://kojipkgs.fedoraproject.org/packages/sssd/1.2.91/21.fc14/ . It is > > for rawhide but should work fine on F13, too. > > > > Sure, I'll give it a shot and report back what I find. > > > > I also didn't use LDAP aliases. Can you check if setting DEREF in > > /etc/openldap/ldap.conf helps? If not, can you give a short description > > how aliases are used in your case so that I can set up a similar > > environment? > > > > Setting DEREF to always in /etc/openldap/ldap.conf works. Aliasing is only nice, so authentication is working for you now? > needed for one DN in our tree: everyone's default group is aliased to > another DN in another branch of the tree. I wish there were some way to > enable aliasing on a per-map basis (e.g. only groups or only users) so that > you'd only take the performance hit where necessary, but I'm not aware of > any NSS LDAP client that does this. > The reason might be that the OpenLDAP libraries do not let you specify the deref option in the exported ldap_search routines. It is only an option for the whole connection. bye, Sumit > > > Thanks. > > > > bye, > > Sumit > > > > > > > > > > > > > Moving on... > > > > > > > > We will need to dereference LDAP aliases but I have not yet been able > > to > > > > find a setting to enable this. I also have not found the equivalent of > > the > > > > > > I have added a RFE to sssd trac > > > (https://fedorahosted.org/sssd/ticket/568). As a sort term fix you can > > > add the appropriate DEREF option to /etc/openldap/ldap.conf. > > > > > > > pam_password_prohibit_message setting in /etc/ldap.conf; while not > > strictly > > > > required, it is nice to refer users to the proper way to change > > passwords in > > > > our environment. > > > > > > Currently there is only a configurable message if password resets by > > > root fail. I have added https://fedorahosted.org/sssd/ticket/569 to > > > track this. > > > > > > bye, > > > Sumit > > > > > > > > > > > Any help would be appreciated. Thanks! > > > > > > > > Scott Duckworth, Systems Programmer II > > > > Clemson University School of Computing > > > > > > > _______________________________________________ > > > > 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 sgallagh at redhat.com Thu Jul 22 16:38:55 2010 From: sgallagh at redhat.com (Stephen Gallagher) Date: Thu, 22 Jul 2010 12:38:55 -0400 Subject: [Freeipa-users] SSS problems with eDirectory In-Reply-To: References: <20100722081937.GN27552@localhost.localdomain> <20100722150741.GP27552@localhost.localdomain> Message-ID: <4C48741F.8030304@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/22/2010 11:47 AM, Scott Duckworth wrote: > > "yum localinstall libcollection-0.5.0-21.fc14.* > libini_config-0.6.0-21.fc14.* sssd-1.2.91-21.fc14.* > sssd-client-1.2.91-21.fc14.*" requires python 2.7. Adding > python-2.7-3.fc14.* and python-libs-2.7-3.fc14.* results in a slew of > dependency resolution errors. > > If I get the chance in the few days, I'll try it under rawhide. > Sorry, that was the wrong package. Please try: http://koji.fedoraproject.org/koji/buildinfo?buildID=182852 The one Sumit sent you mistakenly was from an in-progress rebuild of python for Fedora 14. This one uses Python 2.6 and should install cleanly on Fedora 13. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkxIdB8ACgkQeiVVYja6o6MpMQCfch5jTZlOHvuWaBNePVFVLK7s Fg4AoItYQ6rNj8lwxwLb0pSgZfYdzhtL =jdnq -----END PGP SIGNATURE----- From sduckwo at clemson.edu Thu Jul 22 19:30:23 2010 From: sduckwo at clemson.edu (Scott Duckworth) Date: Thu, 22 Jul 2010 15:30:23 -0400 Subject: [Freeipa-users] SSS problems with eDirectory In-Reply-To: <20100722115933.419f0614@willson.li.ssimo.org> References: <4C476D89.6010603@redhat.com> <4C477238.8020008@redhat.com> <20100722115933.419f0614@willson.li.ssimo.org> Message-ID: On Thu, Jul 22, 2010 at 11:59 AM, Simo Sorce wrote: > On Thu, 22 Jul 2010 11:10:25 -0400 > Scott Duckworth wrote: > > > I removed all files from /var/lib/sss/db/ and restarted sssd. Same > > behavior. nscd is disabled, so I don't think it's caching at any > > level. > > > > Here is what I ran: > > > > [root at duck2 ~]# getent passwd sduckwo > > sduckwo:*:45265:10000:Scott Duckworth:/home/sduckwo:/bin/bash > > [root at duck2 ~]# groups sduckwo > > sduckwo : cuuser > > [root at duck2 ~]# getent group coes_socunix > > coes_socunix:*:120105:sduckwo > > I should add to this, that what I expected to see is this (from one of the RHEL boxes using nss_ldap): [root at potter commands]# groups sduckwo sduckwo : cuuser coes_dpa coes_socunix coes_web_cs coes_web_fx In other words, I don't so much care that all members of the group are represented, but rather that all groups of which a user is a member are represented. When enumeration is disabled this is the normal behavior. > You will see only users/groups that have been fetched. Generally at > login time because of the initgroups call. > Ie a users will always have correct memmberships, but groups may not > should all user members they truly have in the ldap server. > > If you require perfect representation you will have to turn on > enumeration. This will eventually show up all the memberships although > on the first startup it may take a while to show all groups, until they > have all been downloaded and cached. > Changes to group memberships may also take some time to show as > enumerations are scheduled periodically and results cached. > There are almost 120,000 users in our directory, and we currently have ~200 Linux systems that might use SSSD, soon scaling to >500 systems. I imagine that even 500 systems is only a medium-scale installation compared to some sites. Client-side, it's taking 100% of one core (Core i7) at least 45 minutes (so far) to do the enumeration (the first time around I had logging enabled and it got up to ~13000 users in ~10 minutes, but decided to disable logging to reduce processing). Meanwhile, all other NSS queries using SSSD are blocking and timing out after a few minutes, apparently waiting on the enumeration to finish. I'm not sure what's happening server-side, but I can just see the directory administrators breathing down our neck if we unleashed 200-500 systems to enumerate every user at the same time. Even with caching in effect, I respectfully question this design decision. What was wrong with the design of nss_ldap and pam-nss-ldapd to query the directory for group membership for a single user upon login, then cache it locally? Of cours when a user logs in its information (including its group > membership) is refreshed and validated, so at login time the membership > is correctly updated for that user across all its groups. > This seems to contradict your statement above, and also the behavior I'm seeing. It's not picking up secondary group memberships unless they've already been cached, either through an explicit getent or, presumably (if it ever finishes), via enumeration. Thanks, Scott Duckworth -------------- next part -------------- An HTML attachment was scrubbed... URL: From ssorce at redhat.com Thu Jul 22 19:39:06 2010 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 22 Jul 2010 15:39:06 -0400 Subject: [Freeipa-users] SSS problems with eDirectory In-Reply-To: References: <4C476D89.6010603@redhat.com> <4C477238.8020008@redhat.com> <20100722115933.419f0614@willson.li.ssimo.org> Message-ID: <20100722153906.1903650f@willson.li.ssimo.org> On Thu, 22 Jul 2010 15:30:23 -0400 Scott Duckworth wrote: > On Thu, Jul 22, 2010 at 11:59 AM, Simo Sorce > wrote: > > > On Thu, 22 Jul 2010 11:10:25 -0400 > > Scott Duckworth wrote: > > > > > I removed all files from /var/lib/sss/db/ and restarted sssd. > > > Same behavior. nscd is disabled, so I don't think it's caching > > > at any level. > > > > > > Here is what I ran: > > > > > > [root at duck2 ~]# getent passwd sduckwo > > > sduckwo:*:45265:10000:Scott Duckworth:/home/sduckwo:/bin/bash > > > [root at duck2 ~]# groups sduckwo > > > sduckwo : cuuser > > > [root at duck2 ~]# getent group coes_socunix > > > coes_socunix:*:120105:sduckwo > > > > > I should add to this, that what I expected to see is this (from one > of the RHEL boxes using nss_ldap): > > [root at potter commands]# groups sduckwo > sduckwo : cuuser coes_dpa coes_socunix coes_web_cs coes_web_fx If you log in as sduckwo you should just see that. The same if you do "id sduckwo" > In other words, I don't so much care that all members of the group are > represented, but rather that all groups of which a user is a member > are represented. > > When enumeration is disabled this is the normal behavior. > > You will see only users/groups that have been fetched. Generally at > > login time because of the initgroups call. > > Ie a users will always have correct memmberships, but groups may not > > should all user members they truly have in the ldap server. > > > > If you require perfect representation you will have to turn on > > enumeration. This will eventually show up all the memberships > > although on the first startup it may take a while to show all > > groups, until they have all been downloaded and cached. > > Changes to group memberships may also take some time to show as > > enumerations are scheduled periodically and results cached. > > > > There are almost 120,000 users in our directory, and we currently > have ~200 Linux systems that might use SSSD, soon scaling to >500 > systems. I imagine that even 500 systems is only a medium-scale > installation compared to some sites. > > Client-side, it's taking 100% of one core (Core i7) at least 45 > minutes (so far) to do the enumeration (the first time around I had > logging enabled and it got up to ~13000 users in ~10 minutes, but > decided to disable logging to reduce processing). Meanwhile, all > other NSS queries using SSSD are blocking and timing out after a few > minutes, apparently waiting on the enumeration to finish. > > I'm not sure what's happening server-side, but I can just see the > directory administrators breathing down our neck if we unleashed > 200-500 systems to enumerate every user at the same time. We completely discourage enableing enumeration in bi sites, that's why it is disabled by default. > Even with caching in effect, I respectfully question this design > decision. What was wrong with the design of nss_ldap and > pam-nss-ldapd to query the directory for group membership for a > single user upon login, then cache it locally? This is exactly what we do. Although we currently are trying to do a little too much on initgroups and trying to save all user members for groups we retrieved. We are going to change initgroups to not request group members for the groups we are interested in. > Of cours when a user logs in its information (including its group > > membership) is refreshed and validated, so at login time the > > membership is correctly updated for that user across all its groups. > > > > This seems to contradict your statement above, and also the behavior > I'm seeing. It's not picking up secondary group memberships unless > they've already been cached, either through an explicit getent or, > presumably (if it ever finishes), via enumeration. Your configuration showed that enumeration is disabled (as it should be), have you changed that ? If you are witnessing long dealys on login then you are hitting the initgroups problem we are going to fix shortly. Simo. -- Simo Sorce * Red Hat, Inc * New York From sduckwo at clemson.edu Thu Jul 22 20:19:53 2010 From: sduckwo at clemson.edu (Scott Duckworth) Date: Thu, 22 Jul 2010 16:19:53 -0400 Subject: [Freeipa-users] SSS problems with eDirectory In-Reply-To: <4C48741F.8030304@redhat.com> References: <20100722081937.GN27552@localhost.localdomain> <20100722150741.GP27552@localhost.localdomain> <4C48741F.8030304@redhat.com> Message-ID: On Thu, Jul 22, 2010 at 12:38 PM, Stephen Gallagher wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 07/22/2010 11:47 AM, Scott Duckworth wrote: > > > > "yum localinstall libcollection-0.5.0-21.fc14.* > > libini_config-0.6.0-21.fc14.* sssd-1.2.91-21.fc14.* > > sssd-client-1.2.91-21.fc14.*" requires python 2.7. Adding > > python-2.7-3.fc14.* and python-libs-2.7-3.fc14.* results in a slew of > > dependency resolution errors. > > > > If I get the chance in the few days, I'll try it under rawhide. > > > > Sorry, that was the wrong package. Please try: > http://koji.fedoraproject.org/koji/buildinfo?buildID=182852 > > The one Sumit sent you mistakenly was from an in-progress rebuild of > python for Fedora 14. This one uses Python 2.6 and should install > cleanly on Fedora 13. > Updated: [root at duck2 ~]# rpm -qa | grep fc14 | sort libcollection-0.5.0-20.fc14.i686 libcollection-0.5.0-20.fc14.x86_64 libdhash-0.4.0-20.fc14.i686 libdhash-0.4.0-20.fc14.x86_64 libini_config-0.6.0-20.fc14.i686 libini_config-0.6.0-20.fc14.x86_64 libpath_utils-0.2.0-20.fc14.i686 libpath_utils-0.2.0-20.fc14.x86_64 libref_array-0.1.0-20.fc14.i686 libref_array-0.1.0-20.fc14.x86_64 sssd-1.2.91-20.fc14.x86_64 sssd-client-1.2.91-20.fc14.i686 sssd-client-1.2.91-20.fc14.x86_64 But I'm still having the same issue. (Thu Jul 22 16:12:49 2010) [sssd[be[CLEMSONU]]] [simple_bind_send] (4): Executing simple bind as: cn=SDUCKWO,ou=s,ou=EMPLOYEE,o=CLEMSONU (Thu Jul 22 16:12:49 2010) [sssd[be[CLEMSONU]]] [simple_bind_send] (8): ldap simple bind sent, msgid = 2 I have a feeling that a real LDAP error message would provide more insight into the situation. - -- > Stephen Gallagher > RHCE 804006346421761 > > Delivering value year after year. > Red Hat ranks #1 in value among software vendors. > http://www.redhat.com/promo/vendor/ > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.14 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkxIdB8ACgkQeiVVYja6o6MpMQCfch5jTZlOHvuWaBNePVFVLK7s > Fg4AoItYQ6rNj8lwxwLb0pSgZfYdzhtL > =jdnq > -----END PGP SIGNATURE----- > > _______________________________________________ > 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 sduckwo at clemson.edu Thu Jul 22 20:22:45 2010 From: sduckwo at clemson.edu (Scott Duckworth) Date: Thu, 22 Jul 2010 16:22:45 -0400 Subject: [Freeipa-users] SSS problems with eDirectory In-Reply-To: <20100722153906.1903650f@willson.li.ssimo.org> References: <4C476D89.6010603@redhat.com> <4C477238.8020008@redhat.com> <20100722115933.419f0614@willson.li.ssimo.org> <20100722153906.1903650f@willson.li.ssimo.org> Message-ID: On Thu, Jul 22, 2010 at 3:39 PM, Simo Sorce wrote: > On Thu, 22 Jul 2010 15:30:23 -0400 > Scott Duckworth wrote: > > > On Thu, Jul 22, 2010 at 11:59 AM, Simo Sorce > > wrote: > > > > > On Thu, 22 Jul 2010 11:10:25 -0400 > > > Scott Duckworth wrote: > > > > > > > I removed all files from /var/lib/sss/db/ and restarted sssd. > > > > Same behavior. nscd is disabled, so I don't think it's caching > > > > at any level. > > > > > > > > Here is what I ran: > > > > > > > > [root at duck2 ~]# getent passwd sduckwo > > > > sduckwo:*:45265:10000:Scott Duckworth:/home/sduckwo:/bin/bash > > > > [root at duck2 ~]# groups sduckwo > > > > sduckwo : cuuser > > > > [root at duck2 ~]# getent group coes_socunix > > > > coes_socunix:*:120105:sduckwo > > > > > > > > I should add to this, that what I expected to see is this (from one > > of the RHEL boxes using nss_ldap): > > > > [root at potter commands]# groups sduckwo > > sduckwo : cuuser coes_dpa coes_socunix coes_web_cs coes_web_fx > > If you log in as sduckwo you should just see that. > The same if you do "id sduckwo" > No go... [root at duck2 ~]# service sssd stop [root at duck2 ~]# rm -f /var/lib/sss/db/* [root at duck2 ~]# service nscd stop [root at duck2 ~]# service sssd start Starting sssd: [ OK ] [root at duck2 ~]# id sduckwo uid=45265(sduckwo) gid=10000(cuuser) groups=10000(cuuser) [root at duck2 ~]# su - sduckwo [16:05:24] sduckwo at duck2:~ [1] id uid=45265(sduckwo) gid=10000(cuuser) groups=10000(cuuser) [16:05:26] sduckwo at duck2:~ [2] groups cuuser I'm unable to actually login due to pam_sss not working (see another branch of this thread). > Of cours when a user logs in its information (including its group > > > membership) is refreshed and validated, so at login time the > > > membership is correctly updated for that user across all its groups. > > > > > > > This seems to contradict your statement above, and also the behavior > > I'm seeing. It's not picking up secondary group memberships unless > > they've already been cached, either through an explicit getent or, > > presumably (if it ever finishes), via enumeration. > > Your configuration showed that enumeration is disabled (as it should > be), have you changed that ? > I did enable enumeration per what I thought was your previous suggestion. I've now disabled it again. To be clear, my current sssd.conf is: [sssd] config_file_version = 2 reconnection_retries = 3 sbus_timeout = 30 services = nss, pam domains = CLEMSONU [nss] debug_level = 7 filter_groups = root filter_users = root reconnection_retries = 3 entry_cache_timeout = 1 entry_cache_nowait_timeout = 1 [pam] debug_level = 7 reconnection_retries = 3 [domain/CLEMSONU] debug_level = 20 enumerate = False cache_credentials = False id_provider = ldap auth_provider = ldap ldap_schema = rfc2307bis chpass_provider = ldap min_id = 1000 ldap_uri = ldaps://clemsonuldap.clemson.edu ldap_id_use_start_tls = False ldap_tls_cacertdir = /etc/openldap/cacerts tls_reqcert = demand ldap_default_bind_dn = cn=CoESProxy,ou=proxyUsers,o=CLEMSONU ldap_default_authtok_type = password ldap_default_authtok = xxxxxx ldap_search_base = ou=SoC,ou=CES,o=CLEMSONU ldap_user_search_base = o=CLEMSONU ldap_group_search_base = o=CLEMSONU ldap_user_shell = coesLoginShell ldap_user_gecos = fullName ldap_user_fullname = fullName ldap_pwd_policy = none and /etc/openldap/ldap.conf is: DEREF always URI ldaps://clemsonuldap.clemson.edu BASE ou=SoC,ou=CES,o=CLEMSONU TLS_CACERTDIR /etc/openldap/cacerts > If you are witnessing long dealys on login then you are hitting the > initgroups problem we are going to fix shortly. > I believe the long delays were caused by enumeration. There are no such delays with enumeration disabled. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ssorce at redhat.com Thu Jul 22 20:49:50 2010 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 22 Jul 2010 16:49:50 -0400 Subject: [Freeipa-users] SSS problems with eDirectory In-Reply-To: References: <4C476D89.6010603@redhat.com> <4C477238.8020008@redhat.com> <20100722115933.419f0614@willson.li.ssimo.org> <20100722153906.1903650f@willson.li.ssimo.org> Message-ID: <20100722164950.31fe9253@willson.li.ssimo.org> On Thu, 22 Jul 2010 16:22:45 -0400 Scott Duckworth wrote: > On Thu, Jul 22, 2010 at 3:39 PM, Simo Sorce wrote: > > > On Thu, 22 Jul 2010 15:30:23 -0400 > > Scott Duckworth wrote: > > > > > On Thu, Jul 22, 2010 at 11:59 AM, Simo Sorce > > > wrote: > > > > > > > On Thu, 22 Jul 2010 11:10:25 -0400 > > > > Scott Duckworth wrote: > > > > > > > > > I removed all files from /var/lib/sss/db/ and restarted sssd. > > > > > Same behavior. nscd is disabled, so I don't think it's > > > > > caching at any level. > > > > > > > > > > Here is what I ran: > > > > > > > > > > [root at duck2 ~]# getent passwd sduckwo > > > > > sduckwo:*:45265:10000:Scott Duckworth:/home/sduckwo:/bin/bash > > > > > [root at duck2 ~]# groups sduckwo > > > > > sduckwo : cuuser > > > > > [root at duck2 ~]# getent group coes_socunix > > > > > coes_socunix:*:120105:sduckwo > > > > > > > > > > > I should add to this, that what I expected to see is this (from > > > one of the RHEL boxes using nss_ldap): > > > > > > [root at potter commands]# groups sduckwo > > > sduckwo : cuuser coes_dpa coes_socunix coes_web_cs coes_web_fx > > > > If you log in as sduckwo you should just see that. > > The same if you do "id sduckwo" > > > > No go... > > [root at duck2 ~]# service sssd stop > [root at duck2 ~]# rm -f /var/lib/sss/db/* > [root at duck2 ~]# service nscd stop > [root at duck2 ~]# service sssd start > Starting sssd: [ OK ] > [root at duck2 ~]# id sduckwo > uid=45265(sduckwo) gid=10000(cuuser) groups=10000(cuuser) > [root at duck2 ~]# su - sduckwo > [16:05:24] sduckwo at duck2:~ [1] id > uid=45265(sduckwo) gid=10000(cuuser) groups=10000(cuuser) > [16:05:26] sduckwo at duck2:~ [2] groups > cuuser Uhmmm this may be a side effect of your directory not having memberof I think we need to add special code to handle servers that use rfc2307bis schema but that do not use memberof. > I'm unable to actually login due to pam_sss not working (see another > branch of this thread). Yes, I think we need to file a few bugs and add support for servers like yours. > > Of cours when a user logs in its information (including its group > > > > membership) is refreshed and validated, so at login time the > > > > membership is correctly updated for that user across all its > > > > groups. > > > > > > > > > > This seems to contradict your statement above, and also the > > > behavior I'm seeing. It's not picking up secondary group > > > memberships unless they've already been cached, either through an > > > explicit getent or, presumably (if it ever finishes), via > > > enumeration. > > > > Your configuration showed that enumeration is disabled (as it should > > be), have you changed that ? > > > > I did enable enumeration per what I thought was your previous > suggestion. I've now disabled it again. To be clear, my current > sssd.conf is: > > [sssd] > config_file_version = 2 > reconnection_retries = 3 > sbus_timeout = 30 > services = nss, pam > domains = CLEMSONU > [nss] > debug_level = 7 > filter_groups = root > filter_users = root > reconnection_retries = 3 > entry_cache_timeout = 1 > entry_cache_nowait_timeout = 1 > [pam] > debug_level = 7 > reconnection_retries = 3 > [domain/CLEMSONU] > debug_level = 20 > enumerate = False > cache_credentials = False > id_provider = ldap > auth_provider = ldap > ldap_schema = rfc2307bis > chpass_provider = ldap > min_id = 1000 > ldap_uri = ldaps://clemsonuldap.clemson.edu > ldap_id_use_start_tls = False > ldap_tls_cacertdir = /etc/openldap/cacerts > tls_reqcert = demand > ldap_default_bind_dn = cn=CoESProxy,ou=proxyUsers,o=CLEMSONU > ldap_default_authtok_type = password > ldap_default_authtok = xxxxxx > ldap_search_base = ou=SoC,ou=CES,o=CLEMSONU > ldap_user_search_base = o=CLEMSONU > ldap_group_search_base = o=CLEMSONU > ldap_user_shell = coesLoginShell > ldap_user_gecos = fullName > ldap_user_fullname = fullName > ldap_pwd_policy = none > > and /etc/openldap/ldap.conf is: > > DEREF always > URI ldaps://clemsonuldap.clemson.edu > BASE ou=SoC,ou=CES,o=CLEMSONU > TLS_CACERTDIR /etc/openldap/cacerts > > > > If you are witnessing long dealys on login then you are hitting the > > initgroups problem we are going to fix shortly. > > > > I believe the long delays were caused by enumeration. There are no > such delays with enumeration disabled. yes, it is expected that enumeration is quite heavy, as it has to query all users and groups and cache that information. That's why we disable it by default. Simo. -- Simo Sorce * Red Hat, Inc * New York From sbose at redhat.com Thu Jul 22 21:24:34 2010 From: sbose at redhat.com (Sumit Bose) Date: Thu, 22 Jul 2010 23:24:34 +0200 Subject: [Freeipa-users] SSS problems with eDirectory In-Reply-To: References: <20100722081937.GN27552@localhost.localdomain> <20100722150741.GP27552@localhost.localdomain> <4C48741F.8030304@redhat.com> Message-ID: <20100722212434.GR27552@localhost.localdomain> On Thu, Jul 22, 2010 at 04:19:53PM -0400, Scott Duckworth wrote: > On Thu, Jul 22, 2010 at 12:38 PM, Stephen Gallagher wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > On 07/22/2010 11:47 AM, Scott Duckworth wrote: > > > > > > "yum localinstall libcollection-0.5.0-21.fc14.* > > > libini_config-0.6.0-21.fc14.* sssd-1.2.91-21.fc14.* > > > sssd-client-1.2.91-21.fc14.*" requires python 2.7. Adding > > > python-2.7-3.fc14.* and python-libs-2.7-3.fc14.* results in a slew of > > > dependency resolution errors. > > > > > > If I get the chance in the few days, I'll try it under rawhide. > > > > > > > Sorry, that was the wrong package. Please try: > > http://koji.fedoraproject.org/koji/buildinfo?buildID=182852 > > > > The one Sumit sent you mistakenly was from an in-progress rebuild of > > python for Fedora 14. This one uses Python 2.6 and should install > > cleanly on Fedora 13. > > > > Updated: > > [root at duck2 ~]# rpm -qa | grep fc14 | sort > libcollection-0.5.0-20.fc14.i686 > libcollection-0.5.0-20.fc14.x86_64 > libdhash-0.4.0-20.fc14.i686 > libdhash-0.4.0-20.fc14.x86_64 > libini_config-0.6.0-20.fc14.i686 > libini_config-0.6.0-20.fc14.x86_64 > libpath_utils-0.2.0-20.fc14.i686 > libpath_utils-0.2.0-20.fc14.x86_64 > libref_array-0.1.0-20.fc14.i686 > libref_array-0.1.0-20.fc14.x86_64 > sssd-1.2.91-20.fc14.x86_64 > sssd-client-1.2.91-20.fc14.i686 > sssd-client-1.2.91-20.fc14.x86_64 > > But I'm still having the same issue. > > (Thu Jul 22 16:12:49 2010) [sssd[be[CLEMSONU]]] [simple_bind_send] (4): > Executing simple bind as: cn=SDUCKWO,ou=s,ou=EMPLOYEE,o=CLEMSONU > (Thu Jul 22 16:12:49 2010) [sssd[be[CLEMSONU]]] [simple_bind_send] (8): ldap > simple bind sent, msgid = 2 So the next line in the log still looks like: (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] [sdap_process_result] (4): ldap_result gave -1, something bad happend! ? > > I have a feeling that a real LDAP error message would provide more insight > into the situation. Can you find anything in the server logs? I can prepare a special build for you which prints the LDAP_OPT_DIAGNOSTIC_MESSAGE LDAP option and let you use wireshark. But I'm afraid this has to wait until tomorrow, it's nearly half to midnight, here. bye, Sumit > > - -- > > Stephen Gallagher > > RHCE 804006346421761 > > > > Delivering value year after year. > > Red Hat ranks #1 in value among software vendors. > > http://www.redhat.com/promo/vendor/ > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v2.0.14 (GNU/Linux) > > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ > > > > iEYEARECAAYFAkxIdB8ACgkQeiVVYja6o6MpMQCfch5jTZlOHvuWaBNePVFVLK7s > > Fg4AoItYQ6rNj8lwxwLb0pSgZfYdzhtL > > =jdnq > > -----END PGP SIGNATURE----- > > > > _______________________________________________ > > Freeipa-users mailing list > > Freeipa-users at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-users > > From dpal at redhat.com Thu Jul 22 21:59:03 2010 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 22 Jul 2010 17:59:03 -0400 Subject: [Freeipa-users] SSS problems with eDirectory In-Reply-To: <20100722164950.31fe9253@willson.li.ssimo.org> References: <4C476D89.6010603@redhat.com> <4C477238.8020008@redhat.com> <20100722115933.419f0614@willson.li.ssimo.org> <20100722153906.1903650f@willson.li.ssimo.org> <20100722164950.31fe9253@willson.li.ssimo.org> Message-ID: <4C48BF27.2000306@redhat.com> [snip] > Uhmmm this may be a side effect of your directory not having memberof > I think we need to add special code to handle servers that use > rfc2307bis schema but that do not use memberof. > > Are we sure that this is the case? Is there any chance we can get a schema file that shows what is the schema used on the server? May be it is one of the early drafts of the rfc2307bis that is implemented in the server? I think the ldapsearch results listing any one user and a group he is a member in your server of will be very helpful. -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From ssorce at redhat.com Thu Jul 22 22:12:35 2010 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 22 Jul 2010 18:12:35 -0400 Subject: [Freeipa-users] SSS problems with eDirectory In-Reply-To: <4C48BF27.2000306@redhat.com> References: <4C476D89.6010603@redhat.com> <4C477238.8020008@redhat.com> <20100722115933.419f0614@willson.li.ssimo.org> <20100722153906.1903650f@willson.li.ssimo.org> <20100722164950.31fe9253@willson.li.ssimo.org> <4C48BF27.2000306@redhat.com> Message-ID: <20100722181235.5f8e2569@willson.li.ssimo.org> On Thu, 22 Jul 2010 17:59:03 -0400 Dmitri Pal wrote: > [snip] > > Uhmmm this may be a side effect of your directory not having > > memberof I think we need to add special code to handle servers that > > use rfc2307bis schema but that do not use memberof. > > > > > > Are we sure that this is the case? > Is there any chance we can get a schema file that shows what is the > schema used on the server? > May be it is one of the early drafts of the rfc2307bis that is > implemented in the server? > > I think the ldapsearch results listing any one user and a group he is > a member in your server of will be very helpful. > memberof is not required by rfc2307bis. Actually it is not even mentioned by rfc2307bis, so it is our fault if we depend on it. rfc2307bis actually mentions only uniquemember. Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Thu Jul 22 22:21:58 2010 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 22 Jul 2010 18:21:58 -0400 Subject: [Freeipa-users] SSS problems with eDirectory In-Reply-To: <20100722181235.5f8e2569@willson.li.ssimo.org> References: <4C476D89.6010603@redhat.com> <4C477238.8020008@redhat.com> <20100722115933.419f0614@willson.li.ssimo.org> <20100722153906.1903650f@willson.li.ssimo.org> <20100722164950.31fe9253@willson.li.ssimo.org> <4C48BF27.2000306@redhat.com> <20100722181235.5f8e2569@willson.li.ssimo.org> Message-ID: <4C48C486.5070201@redhat.com> Simo Sorce wrote: > On Thu, 22 Jul 2010 17:59:03 -0400 > Dmitri Pal wrote: > > >> [snip] >> >>> Uhmmm this may be a side effect of your directory not having >>> memberof I think we need to add special code to handle servers that >>> use rfc2307bis schema but that do not use memberof. >>> >>> >>> >> Are we sure that this is the case? >> Is there any chance we can get a schema file that shows what is the >> schema used on the server? >> May be it is one of the early drafts of the rfc2307bis that is >> implemented in the server? >> >> I think the ldapsearch results listing any one user and a group he is >> a member in your server of will be very helpful. >> >> > > memberof is not required by rfc2307bis. Actually it is not even > mentioned by rfc2307bis, so it is our fault if we depend on it. > > rfc2307bis actually mentions only uniquemember. > > I agree that if this is the case we definitely have a bug that we need to fix. But a confirmation that this is actually the case in the LDAP server in question is needed for us to test and verify the fix. > Simo. > > -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Thu Jul 22 23:04:59 2010 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 22 Jul 2010 19:04:59 -0400 Subject: [Freeipa-users] Support of SUDO in IPA Message-ID: <4C48CE9B.1070601@redhat.com> Hello, Once again after some delay we are taking a look at implementing centrally managed SUDOERS in IPA. First effort was based on the policy engine approach and since the whole policy part got deferred it got postponed too. However it became apparent that there is a need to support central management SUDO sooner rather than later. So we are taking the second look at it. Please review the following page to see our plans: http://www.freeipa.org/page/SUDO_integration_plans We are looking for the feedback regarding this effort. Help is welcome! Also it is very important to do it right. Please find the first cut at the design of the server side here: http://www.freeipa.org/page/SUDO_Schema_Design Please help us find the right answers to the questions asked at the bottom of the page. -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From ssorce at redhat.com Fri Jul 23 00:37:20 2010 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 22 Jul 2010 20:37:20 -0400 Subject: [Freeipa-users] SSS problems with eDirectory In-Reply-To: References: <4C476D89.6010603@redhat.com> <4C477238.8020008@redhat.com> <20100722115933.419f0614@willson.li.ssimo.org> Message-ID: <20100722203720.08597faf@willson.li.ssimo.org> On Thu, 22 Jul 2010 15:30:23 -0400 Scott Duckworth wrote: > There are almost 120,000 users in our directory, and we currently > have ~200 Linux systems that might use SSSD, soon scaling to >500 > systems. I imagine that even 500 systems is only a medium-scale > installation compared to some sites. Scott, can you tell me roughly how many groups you have, and how big they get up to ? Also do you have nested groups (groups containing other groups) ? Simo. -- Simo Sorce * Red Hat, Inc * New York From chorn at fluxcoil.net Fri Jul 23 08:49:41 2010 From: chorn at fluxcoil.net (Christian Horn) Date: Fri, 23 Jul 2010 10:49:41 +0200 Subject: [Freeipa-users] SSS problems with eDirectory In-Reply-To: References: <4C476D89.6010603@redhat.com> <4C477238.8020008@redhat.com> <20100722115933.419f0614@willson.li.ssimo.org> Message-ID: <20100723084941.GA1817@fluxcoil.net> On Thu, Jul 22, 2010 at 03:30:23PM -0400, Scott Duckworth wrote: > > There are almost 120,000 users in our directory, and we currently have ~200 > Linux systems that might use SSSD, soon scaling to >500 systems. I imagine > that even 500 systems is only a medium-scale installation compared to some > sites. I recentl had a look at rhel6beta which offers sssd and nscd/nslcd. Had implemented ldap authorization/authentication with sssd when i dis- covered that netgroups are not available yet. Mainly used with pam_access and sudo here for authorization. Do you mind what you are using instead in your environment? Or are these users just all authorized to do the same? Christian From sbose at redhat.com Fri Jul 23 09:43:53 2010 From: sbose at redhat.com (Sumit Bose) Date: Fri, 23 Jul 2010 11:43:53 +0200 Subject: [Freeipa-users] SSS problems with eDirectory In-Reply-To: <20100723084941.GA1817@fluxcoil.net> References: <4C476D89.6010603@redhat.com> <4C477238.8020008@redhat.com> <20100722115933.419f0614@willson.li.ssimo.org> <20100723084941.GA1817@fluxcoil.net> Message-ID: <20100723094353.GS27552@localhost.localdomain> On Fri, Jul 23, 2010 at 10:49:41AM +0200, Christian Horn wrote: > On Thu, Jul 22, 2010 at 03:30:23PM -0400, Scott Duckworth wrote: > > > > There are almost 120,000 users in our directory, and we currently have ~200 > > Linux systems that might use SSSD, soon scaling to >500 systems. I imagine > > that even 500 systems is only a medium-scale installation compared to some > > sites. > > I recentl had a look at rhel6beta which offers sssd and nscd/nslcd. > Had implemented ldap authorization/authentication with sssd when i dis- > covered that netgroups are not available yet. > Mainly used with pam_access and sudo here for authorization. > > Do you mind what you are using instead in your environment? > Or are these users just all authorized to do the same? Netgroup support is planned for version 1.4.0 (see https://fedorahosted.org/sssd/ticket/358). The most flexible way of access control is to use sssd together with a FreeIPA v2 server (the Alpha4 release was published recently). There are also plan to add sudo support into FreeIPA (see http://www.freeipa.org/page/SUDO_integration_plans for details). You can use the 'simple' access control provider (see man sssd-simple) or use sssd for users and groups and let nslcd fetch netgroups until sssd supports it natively. HTH bye, Sumit > > > Christian > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From sbose at redhat.com Fri Jul 23 10:16:29 2010 From: sbose at redhat.com (Sumit Bose) Date: Fri, 23 Jul 2010 12:16:29 +0200 Subject: [Freeipa-users] SSS problems with eDirectory In-Reply-To: <20100722164950.31fe9253@willson.li.ssimo.org> References: <4C476D89.6010603@redhat.com> <4C477238.8020008@redhat.com> <20100722115933.419f0614@willson.li.ssimo.org> <20100722153906.1903650f@willson.li.ssimo.org> <20100722164950.31fe9253@willson.li.ssimo.org> Message-ID: <20100723101629.GT27552@localhost.localdomain> On Thu, Jul 22, 2010 at 04:49:50PM -0400, Simo Sorce wrote: > On Thu, 22 Jul 2010 16:22:45 -0400 > Scott Duckworth wrote: > > > On Thu, Jul 22, 2010 at 3:39 PM, Simo Sorce wrote: > > > > > On Thu, 22 Jul 2010 15:30:23 -0400 > > > Scott Duckworth wrote: > > > > > > > On Thu, Jul 22, 2010 at 11:59 AM, Simo Sorce > > > > wrote: > > > > > > > > > On Thu, 22 Jul 2010 11:10:25 -0400 > > > > > Scott Duckworth wrote: > > > > > > > > > > > I removed all files from /var/lib/sss/db/ and restarted sssd. > > > > > > Same behavior. nscd is disabled, so I don't think it's > > > > > > caching at any level. > > > > > > > > > > > > Here is what I ran: > > > > > > > > > > > > [root at duck2 ~]# getent passwd sduckwo > > > > > > sduckwo:*:45265:10000:Scott Duckworth:/home/sduckwo:/bin/bash > > > > > > [root at duck2 ~]# groups sduckwo > > > > > > sduckwo : cuuser > > > > > > [root at duck2 ~]# getent group coes_socunix > > > > > > coes_socunix:*:120105:sduckwo > > > > > > > > > > > > > > I should add to this, that what I expected to see is this (from > > > > one of the RHEL boxes using nss_ldap): > > > > > > > > [root at potter commands]# groups sduckwo > > > > sduckwo : cuuser coes_dpa coes_socunix coes_web_cs coes_web_fx > > > > > > If you log in as sduckwo you should just see that. > > > The same if you do "id sduckwo" > > > > > > > No go... > > > > [root at duck2 ~]# service sssd stop > > [root at duck2 ~]# rm -f /var/lib/sss/db/* > > [root at duck2 ~]# service nscd stop > > [root at duck2 ~]# service sssd start > > Starting sssd: [ OK ] > > [root at duck2 ~]# id sduckwo > > uid=45265(sduckwo) gid=10000(cuuser) groups=10000(cuuser) > > [root at duck2 ~]# su - sduckwo > > [16:05:24] sduckwo at duck2:~ [1] id > > uid=45265(sduckwo) gid=10000(cuuser) groups=10000(cuuser) > > [16:05:26] sduckwo at duck2:~ [2] groups > > cuuser > > Uhmmm this may be a side effect of your directory not having memberof > I think we need to add special code to handle servers that use > rfc2307bis schema but that do not use memberof. In my test setup eDirectory uses an attribute named groupMembership in the user object to store the DN of the groups the user belongs to. Can you check if adding the option ldap_user_member_of = groupMembership does help here? bye, Sumit > > > I'm unable to actually login due to pam_sss not working (see another > > branch of this thread). > > Yes, I think we need to file a few bugs and add support for servers > like yours. > > > > Of cours when a user logs in its information (including its group > > > > > membership) is refreshed and validated, so at login time the > > > > > membership is correctly updated for that user across all its > > > > > groups. > > > > > > > > > > > > > This seems to contradict your statement above, and also the > > > > behavior I'm seeing. It's not picking up secondary group > > > > memberships unless they've already been cached, either through an > > > > explicit getent or, presumably (if it ever finishes), via > > > > enumeration. > > > > > > Your configuration showed that enumeration is disabled (as it should > > > be), have you changed that ? > > > > > > > I did enable enumeration per what I thought was your previous > > suggestion. I've now disabled it again. To be clear, my current > > sssd.conf is: > > > > [sssd] > > config_file_version = 2 > > reconnection_retries = 3 > > sbus_timeout = 30 > > services = nss, pam > > domains = CLEMSONU > > [nss] > > debug_level = 7 > > filter_groups = root > > filter_users = root > > reconnection_retries = 3 > > entry_cache_timeout = 1 > > entry_cache_nowait_timeout = 1 > > [pam] > > debug_level = 7 > > reconnection_retries = 3 > > [domain/CLEMSONU] > > debug_level = 20 > > enumerate = False > > cache_credentials = False > > id_provider = ldap > > auth_provider = ldap > > ldap_schema = rfc2307bis > > chpass_provider = ldap > > min_id = 1000 > > ldap_uri = ldaps://clemsonuldap.clemson.edu > > ldap_id_use_start_tls = False > > ldap_tls_cacertdir = /etc/openldap/cacerts > > tls_reqcert = demand > > ldap_default_bind_dn = cn=CoESProxy,ou=proxyUsers,o=CLEMSONU > > ldap_default_authtok_type = password > > ldap_default_authtok = xxxxxx > > ldap_search_base = ou=SoC,ou=CES,o=CLEMSONU > > ldap_user_search_base = o=CLEMSONU > > ldap_group_search_base = o=CLEMSONU > > ldap_user_shell = coesLoginShell > > ldap_user_gecos = fullName > > ldap_user_fullname = fullName > > ldap_pwd_policy = none > > > > and /etc/openldap/ldap.conf is: > > > > DEREF always > > URI ldaps://clemsonuldap.clemson.edu > > BASE ou=SoC,ou=CES,o=CLEMSONU > > TLS_CACERTDIR /etc/openldap/cacerts > > > > > > > If you are witnessing long dealys on login then you are hitting the > > > initgroups problem we are going to fix shortly. > > > > > > > I believe the long delays were caused by enumeration. There are no > > such delays with enumeration disabled. > > yes, it is expected that enumeration is quite heavy, as it has to query > all users and groups and cache that information. That's why we disable > it by default. > > 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 From sgallagh at redhat.com Fri Jul 23 11:36:40 2010 From: sgallagh at redhat.com (Stephen Gallagher) Date: Fri, 23 Jul 2010 07:36:40 -0400 Subject: [Freeipa-users] SSS problems with eDirectory In-Reply-To: <20100723094353.GS27552@localhost.localdomain> References: <4C476D89.6010603@redhat.com> <4C477238.8020008@redhat.com> <20100722115933.419f0614@willson.li.ssimo.org> <20100723084941.GA1817@fluxcoil.net> <20100723094353.GS27552@localhost.localdomain> Message-ID: <4C497EC8.8070004@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/23/2010 05:43 AM, Sumit Bose wrote: > The most flexible way of access control is to use sssd together with a > FreeIPA v2 server (the Alpha4 release was published recently). There are > also plan to add sudo support into FreeIPA (see > http://www.freeipa.org/page/SUDO_integration_plans for details). > > You can use the 'simple' access control provider (see man sssd-simple) > or use sssd for users and groups and let nslcd fetch netgroups until > sssd supports it natively. > We also have an LDAP access provider that allows you to set up access control based on an LDAP search query. E.g.: access_provider = ldap ldap_access_filter = groupMembership=allowedgroup This would grant access on this host to any user in the allowedgroup (if I'm understanding correctly that eDirectory includes this in the user entry) - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkxJfsgACgkQeiVVYja6o6N/twCfV2YPiuVLj0xyCVas2buKMEIT WtkAoIGM+dt1D0AqTuXAL/bglB2jcUZ/ =0xPV -----END PGP SIGNATURE----- From sduckwo at clemson.edu Fri Jul 23 21:01:22 2010 From: sduckwo at clemson.edu (Scott Duckworth) Date: Fri, 23 Jul 2010 17:01:22 -0400 Subject: [Freeipa-users] SSS problems with eDirectory In-Reply-To: <20100722203720.08597faf@willson.li.ssimo.org> References: <4C476D89.6010603@redhat.com> <4C477238.8020008@redhat.com> <20100722115933.419f0614@willson.li.ssimo.org> <20100722203720.08597faf@willson.li.ssimo.org> Message-ID: On Thu, Jul 22, 2010 at 8:37 PM, Simo Sorce wrote: > On Thu, 22 Jul 2010 15:30:23 -0400 > Scott Duckworth wrote: > > > There are almost 120,000 users in our directory, and we currently > > have ~200 Linux systems that might use SSSD, soon scaling to >500 > > systems. I imagine that even 500 systems is only a medium-scale > > installation compared to some sites. > > Scott, > can you tell me roughly how many groups you have, and how big they get > up to ? > In our branch of the tree, we currently have 64 groups, ranging from 0 to ~50 members. In the entire tree there are over 7500 groups. > Also do you have nested groups (groups containing other groups) ? > No, at least not in our branch of the tree. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sduckwo at clemson.edu Fri Jul 23 21:17:11 2010 From: sduckwo at clemson.edu (Scott Duckworth) Date: Fri, 23 Jul 2010 17:17:11 -0400 Subject: [Freeipa-users] SSS problems with eDirectory In-Reply-To: <20100723101629.GT27552@localhost.localdomain> References: <4C476D89.6010603@redhat.com> <4C477238.8020008@redhat.com> <20100722115933.419f0614@willson.li.ssimo.org> <20100722153906.1903650f@willson.li.ssimo.org> <20100722164950.31fe9253@willson.li.ssimo.org> <20100723101629.GT27552@localhost.localdomain> Message-ID: On Fri, Jul 23, 2010 at 6:16 AM, Sumit Bose wrote: > On Thu, Jul 22, 2010 at 04:49:50PM -0400, Simo Sorce wrote: > > On Thu, 22 Jul 2010 16:22:45 -0400 > > Scott Duckworth wrote: > > > > > On Thu, Jul 22, 2010 at 3:39 PM, Simo Sorce wrote: > > > > > > > On Thu, 22 Jul 2010 15:30:23 -0400 > > > > Scott Duckworth wrote: > > > > > > > > > On Thu, Jul 22, 2010 at 11:59 AM, Simo Sorce > > > > > wrote: > > > > > > > > > > > On Thu, 22 Jul 2010 11:10:25 -0400 > > > > > > Scott Duckworth wrote: > > > > > > > > > > > > > I removed all files from /var/lib/sss/db/ and restarted sssd. > > > > > > > Same behavior. nscd is disabled, so I don't think it's > > > > > > > caching at any level. > > > > > > > > > > > > > > Here is what I ran: > > > > > > > > > > > > > > [root at duck2 ~]# getent passwd sduckwo > > > > > > > sduckwo:*:45265:10000:Scott Duckworth:/home/sduckwo:/bin/bash > > > > > > > [root at duck2 ~]# groups sduckwo > > > > > > > sduckwo : cuuser > > > > > > > [root at duck2 ~]# getent group coes_socunix > > > > > > > coes_socunix:*:120105:sduckwo > > > > > > > > > > > > > > > > > I should add to this, that what I expected to see is this (from > > > > > one of the RHEL boxes using nss_ldap): > > > > > > > > > > [root at potter commands]# groups sduckwo > > > > > sduckwo : cuuser coes_dpa coes_socunix coes_web_cs coes_web_fx > > > > > > > > If you log in as sduckwo you should just see that. > > > > The same if you do "id sduckwo" > > > > > > > > > > No go... > > > > > > [root at duck2 ~]# service sssd stop > > > [root at duck2 ~]# rm -f /var/lib/sss/db/* > > > [root at duck2 ~]# service nscd stop > > > [root at duck2 ~]# service sssd start > > > Starting sssd: [ OK ] > > > [root at duck2 ~]# id sduckwo > > > uid=45265(sduckwo) gid=10000(cuuser) groups=10000(cuuser) > > > [root at duck2 ~]# su - sduckwo > > > [16:05:24] sduckwo at duck2:~ [1] id > > > uid=45265(sduckwo) gid=10000(cuuser) groups=10000(cuuser) > > > [16:05:26] sduckwo at duck2:~ [2] groups > > > cuuser > > > > Uhmmm this may be a side effect of your directory not having memberof > > I think we need to add special code to handle servers that use > > rfc2307bis schema but that do not use memberof. > > In my test setup eDirectory uses an attribute named groupMembership in > the user object to store the DN of the groups the user belongs to. Can > you check if adding the option > > ldap_user_member_of = groupMembership > > does help here? > I've learned that this attribute does exist in our tree, but it's not being populated when we add users to groups since our proxy user does not have rights to write groupMembership to users. I'm trying to find out if we can get our hands on native eDirectory tools that keep groupMembership of posixAccount and member of posixGroup in sync. Still, if groupOf/groupMembership is not required by rfc2307bis, it would be nice if SSSD did not require it. If a user has a groupOf/groupMembership attribute pointing to a group outside of ldap_group_search_base, will this be handled gracefully? -------------- next part -------------- An HTML attachment was scrubbed... URL: From sduckwo at clemson.edu Fri Jul 23 21:45:55 2010 From: sduckwo at clemson.edu (Scott Duckworth) Date: Fri, 23 Jul 2010 17:45:55 -0400 Subject: [Freeipa-users] SSS problems with eDirectory In-Reply-To: <20100722212434.GR27552@localhost.localdomain> References: <20100722081937.GN27552@localhost.localdomain> <20100722150741.GP27552@localhost.localdomain> <4C48741F.8030304@redhat.com> <20100722212434.GR27552@localhost.localdomain> Message-ID: On Thu, Jul 22, 2010 at 5:24 PM, Sumit Bose wrote: > On Thu, Jul 22, 2010 at 04:19:53PM -0400, Scott Duckworth wrote: > > On Thu, Jul 22, 2010 at 12:38 PM, Stephen Gallagher >wrote: > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > Hash: SHA1 > > > > > > On 07/22/2010 11:47 AM, Scott Duckworth wrote: > > > > > > > > "yum localinstall libcollection-0.5.0-21.fc14.* > > > > libini_config-0.6.0-21.fc14.* sssd-1.2.91-21.fc14.* > > > > sssd-client-1.2.91-21.fc14.*" requires python 2.7. Adding > > > > python-2.7-3.fc14.* and python-libs-2.7-3.fc14.* results in a slew of > > > > dependency resolution errors. > > > > > > > > If I get the chance in the few days, I'll try it under rawhide. > > > > > > > > > > Sorry, that was the wrong package. Please try: > > > http://koji.fedoraproject.org/koji/buildinfo?buildID=182852 > > > > > > The one Sumit sent you mistakenly was from an in-progress rebuild of > > > python for Fedora 14. This one uses Python 2.6 and should install > > > cleanly on Fedora 13. > > > > > > > Updated: > > > > [root at duck2 ~]# rpm -qa | grep fc14 | sort > > libcollection-0.5.0-20.fc14.i686 > > libcollection-0.5.0-20.fc14.x86_64 > > libdhash-0.4.0-20.fc14.i686 > > libdhash-0.4.0-20.fc14.x86_64 > > libini_config-0.6.0-20.fc14.i686 > > libini_config-0.6.0-20.fc14.x86_64 > > libpath_utils-0.2.0-20.fc14.i686 > > libpath_utils-0.2.0-20.fc14.x86_64 > > libref_array-0.1.0-20.fc14.i686 > > libref_array-0.1.0-20.fc14.x86_64 > > sssd-1.2.91-20.fc14.x86_64 > > sssd-client-1.2.91-20.fc14.i686 > > sssd-client-1.2.91-20.fc14.x86_64 > > > > But I'm still having the same issue. > > > > (Thu Jul 22 16:12:49 2010) [sssd[be[CLEMSONU]]] [simple_bind_send] (4): > > Executing simple bind as: cn=SDUCKWO,ou=s,ou=EMPLOYEE,o=CLEMSONU > > (Thu Jul 22 16:12:49 2010) [sssd[be[CLEMSONU]]] [simple_bind_send] (8): > ldap > > simple bind sent, msgid = 2 > > So the next line in the log still looks like: > > (Wed Jul 21 12:32:24 2010) [sssd[be[CLEMSONU]]] [sdap_process_result] (4): > ldap_result gave -1, something bad happend! > > ? > > sssd_CLEMSONU.log: (Fri Jul 23 17:43:06 2010) [sssd[be[CLEMSONU]]] [sbus_dispatch] (9): dbus conn: 6A5130 (Fri Jul 23 17:43:06 2010) [sssd[be[CLEMSONU]]] [sbus_dispatch] (9): Dispatching. (Fri Jul 23 17:43:06 2010) [sssd[be[CLEMSONU]]] [sbus_message_handler] (9): Received SBUS method [ping] (Fri Jul 23 17:43:08 2010) [sssd[be[CLEMSONU]]] [sbus_dispatch] (9): dbus conn: 6ABE30 (Fri Jul 23 17:43:08 2010) [sssd[be[CLEMSONU]]] [sbus_dispatch] (9): Dispatching. (Fri Jul 23 17:43:08 2010) [sssd[be[CLEMSONU]]] [sbus_message_handler] (9): Received SBUS method [pamHandler] (Fri Jul 23 17:43:08 2010) [sssd[be[CLEMSONU]]] [be_pam_handler] (4): Got request with the following data (Fri Jul 23 17:43:08 2010) [sssd[be[CLEMSONU]]] [pam_print_data] (4): command: PAM_AUTHENTICATE (Fri Jul 23 17:43:08 2010) [sssd[be[CLEMSONU]]] [pam_print_data] (4): domain: CLEMSONU (Fri Jul 23 17:43:08 2010) [sssd[be[CLEMSONU]]] [pam_print_data] (4): user: sduckwo (Fri Jul 23 17:43:08 2010) [sssd[be[CLEMSONU]]] [pam_print_data] (4): service: login (Fri Jul 23 17:43:08 2010) [sssd[be[CLEMSONU]]] [pam_print_data] (4): tty: tty2 (Fri Jul 23 17:43:08 2010) [sssd[be[CLEMSONU]]] [pam_print_data] (4): ruser: (Fri Jul 23 17:43:08 2010) [sssd[be[CLEMSONU]]] [pam_print_data] (4): rhost: (Fri Jul 23 17:43:08 2010) [sssd[be[CLEMSONU]]] [pam_print_data] (4): authtok type: 1 (Fri Jul 23 17:43:08 2010) [sssd[be[CLEMSONU]]] [pam_print_data] (4): authtok size: 8 (Fri Jul 23 17:43:08 2010) [sssd[be[CLEMSONU]]] [pam_print_data] (4): newauthtok type: 0 (Fri Jul 23 17:43:08 2010) [sssd[be[CLEMSONU]]] [pam_print_data] (4): newauthtok size: 0 (Fri Jul 23 17:43:08 2010) [sssd[be[CLEMSONU]]] [pam_print_data] (4): priv: 0 (Fri Jul 23 17:43:08 2010) [sssd[be[CLEMSONU]]] [pam_print_data] (4): cli_pid: 17646 (Fri Jul 23 17:43:08 2010) [sssd[be[CLEMSONU]]] [fo_resolve_service_send] (4): Trying to resolve service 'LDAP' (Fri Jul 23 17:43:08 2010) [sssd[be[CLEMSONU]]] [get_server_status] (7): Status of server 'clemsonuldap.clemson.edu' is 'working' (Fri Jul 23 17:43:08 2010) [sssd[be[CLEMSONU]]] [get_port_status] (7): Port status of port 636 for server 'clemsonuldap.clemson.edu' is 'working' (Fri Jul 23 17:43:08 2010) [sssd[be[CLEMSONU]]] [get_server_status] (7): Status of server 'clemsonuldap.clemson.edu' is 'working' (Fri Jul 23 17:43:08 2010) [sssd[be[CLEMSONU]]] [be_resolve_server_done] (4): Found address for server clemsonuldap.clemson.edu: [130.127.255.249] (Fri Jul 23 17:43:08 2010) [sssd[be[CLEMSONU]]] [sdap_connect_send] (4): Executing START TLS (Fri Jul 23 17:43:08 2010) [sssd[be[CLEMSONU]]] [sdap_ldap_connect_callback_add] (9): New LDAP connection to [ldaps:// clemsonuldap.clemson.edu:636] with fd [26]. (Fri Jul 23 17:43:08 2010) [sssd[be[CLEMSONU]]] [sdap_process_result] (8): Trace: sh[0x7c9780], connected[1], ops[0x7c1a40], ldap[0x7bb840] (Fri Jul 23 17:43:08 2010) [sssd[be[CLEMSONU]]] [sdap_connect_done] (3): START TLS result: Success(0), (null) (Fri Jul 23 17:43:08 2010) [sssd[be[CLEMSONU]]] [sdap_connect_done] (9): SSL/TLS handler already in place. (Fri Jul 23 17:43:08 2010) [sssd[be[CLEMSONU]]] [fo_set_port_status] (4): Marking port 636 of server 'clemsonuldap.clemson.edu' as 'working' (Fri Jul 23 17:43:08 2010) [sssd[be[CLEMSONU]]] [set_server_common_status] (4): Marking server 'clemsonuldap.clemson.edu' as 'working' (Fri Jul 23 17:43:08 2010) [sssd[be[CLEMSONU]]] [ldb] (9): tevent: Added timed event "ltdb_callback": 0x7b0830 (Fri Jul 23 17:43:08 2010) [sssd[be[CLEMSONU]]] [ldb] (9): tevent: Added timed event "ltdb_timeout": 0x7adcd0 (Fri Jul 23 17:43:08 2010) [sssd[be[CLEMSONU]]] [ldb] (9): tevent: Destroying timer event 0x7adcd0 "ltdb_timeout" (Fri Jul 23 17:43:08 2010) [sssd[be[CLEMSONU]]] [ldb] (9): tevent: Ending timer event 0x7b0830 "ltdb_callback" (Fri Jul 23 17:43:08 2010) [sssd[be[CLEMSONU]]] [find_password_expiration_attributes] (9): No password policy requested. (Fri Jul 23 17:43:08 2010) [sssd[be[CLEMSONU]]] [simple_bind_send] (4): Executing simple bind as: cn=SDUCKWO,ou=s,ou=EMPLOYEE,o=CLEMSONU (Fri Jul 23 17:43:08 2010) [sssd[be[CLEMSONU]]] [simple_bind_send] (8): ldap simple bind sent, msgid = 2 (Fri Jul 23 17:43:08 2010) [sssd[be[CLEMSONU]]] [sdap_process_result] (8): Trace: sh[0x7c9780], connected[1], ops[0x7be100], ldap[0x7bb840] (Fri Jul 23 17:43:08 2010) [sssd[be[CLEMSONU]]] [sdap_process_result] (8): Trace: ldap_result found nothing! (Fri Jul 23 17:43:08 2010) [sssd[be[CLEMSONU]]] [sdap_process_result] (8): Trace: sh[0x7c9780], connected[1], ops[0x7be100], ldap[0x7bb840] (Fri Jul 23 17:43:08 2010) [sssd[be[CLEMSONU]]] [sdap_process_result] (4): ldap_result gave -1, something bad happend! (Fri Jul 23 17:43:08 2010) [sssd[be[CLEMSONU]]] [sdap_handle_release] (8): Trace: sh[0x7c9780], connected[1], ops[0x7be100], ldap[0x7bb840], destructor_lock[0], release_memory[0] (Fri Jul 23 17:43:08 2010) [sssd[be[CLEMSONU]]] [remove_connection_callback] (9): Successfully removed connection callback. (Fri Jul 23 17:43:08 2010) [sssd[be[CLEMSONU]]] [auth_bind_user_done] (9): Found ppolicy data, assuming LDAP password policies are active. (Fri Jul 23 17:43:08 2010) [sssd[be[CLEMSONU]]] [be_pam_handler_callback] (4): Backend returned: (3, 4, ) [Internal Error (Interrupted system call)] (Fri Jul 23 17:43:08 2010) [sssd[be[CLEMSONU]]] [be_pam_handler_callback] (4): Sending result [4][CLEMSONU] (Fri Jul 23 17:43:08 2010) [sssd[be[CLEMSONU]]] [be_pam_handler_callback] (4): Sent result [4][CLEMSONU] > > > I have a feeling that a real LDAP error message would provide more > insight > > into the situation. > > Can you find anything in the server logs? > I don't have access to the server. > I can prepare a special build for you which prints the > LDAP_OPT_DIAGNOSTIC_MESSAGE LDAP option and let you use wireshark. But > I'm afraid this has to wait until tomorrow, it's nearly half to > midnight, here. > That may be useful to others, too. Why not put it in the production build? There's no sense of urgency on my end. I'm just testing this stuff out before it does become urgent. > > bye, > Sumit > > > > > > - -- > > > Stephen Gallagher > > > RHCE 804006346421761 > > > > > > Delivering value year after year. > > > Red Hat ranks #1 in value among software vendors. > > > http://www.redhat.com/promo/vendor/ > > > -----BEGIN PGP SIGNATURE----- > > > Version: GnuPG v2.0.14 (GNU/Linux) > > > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ > > > > > > iEYEARECAAYFAkxIdB8ACgkQeiVVYja6o6MpMQCfch5jTZlOHvuWaBNePVFVLK7s > > > Fg4AoItYQ6rNj8lwxwLb0pSgZfYdzhtL > > > =jdnq > > > -----END PGP SIGNATURE----- > > > > > > _______________________________________________ > > > 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 Fri Jul 23 22:15:29 2010 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 23 Jul 2010 18:15:29 -0400 Subject: [Freeipa-users] SSS problems with eDirectory In-Reply-To: References: <4C476D89.6010603@redhat.com> <4C477238.8020008@redhat.com> <20100722115933.419f0614@willson.li.ssimo.org> <20100722153906.1903650f@willson.li.ssimo.org> <20100722164950.31fe9253@willson.li.ssimo.org> <20100723101629.GT27552@localhost.localdomain> Message-ID: <20100723181529.0e649b6f@willson.li.ssimo.org> On Fri, 23 Jul 2010 17:17:11 -0400 Scott Duckworth wrote: > I've learned that this attribute does exist in our tree, but it's not > being populated when we add users to groups since our proxy user does > not have rights to write groupMembership to users. I'm trying to > find out if we can get our hands on native eDirectory tools that keep > groupMembership of posixAccount and member of posixGroup in sync. > > Still, if groupOf/groupMembership is not required by rfc2307bis, it > would be nice if SSSD did not require it. Yes, we should handle this gracefully, at least through an option. > If a user has a groupOf/groupMembership attribute pointing to a group > outside of ldap_group_search_base, will this be handled gracefully? Yes, the entry will simply be ignored if not resolvable. Simo. -- Simo Sorce * Red Hat, Inc * New York From sgallagh at redhat.com Mon Jul 26 13:33:22 2010 From: sgallagh at redhat.com (Stephen Gallagher) Date: Mon, 26 Jul 2010 09:33:22 -0400 Subject: [Freeipa-users] SSS problems with eDirectory In-Reply-To: <20100723181529.0e649b6f@willson.li.ssimo.org> References: <4C476D89.6010603@redhat.com> <4C477238.8020008@redhat.com> <20100722115933.419f0614@willson.li.ssimo.org> <20100722153906.1903650f@willson.li.ssimo.org> <20100722164950.31fe9253@willson.li.ssimo.org> <20100723101629.GT27552@localhost.localdomain> <20100723181529.0e649b6f@willson.li.ssimo.org> Message-ID: <4C4D8EA2.8020503@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/23/2010 06:15 PM, Simo Sorce wrote: > On Fri, 23 Jul 2010 17:17:11 -0400 > Scott Duckworth wrote: > >> I've learned that this attribute does exist in our tree, but it's not >> being populated when we add users to groups since our proxy user does >> not have rights to write groupMembership to users. I'm trying to >> find out if we can get our hands on native eDirectory tools that keep >> groupMembership of posixAccount and member of posixGroup in sync. >> >> Still, if groupOf/groupMembership is not required by rfc2307bis, it >> would be nice if SSSD did not require it. > > Yes, we should handle this gracefully, at least through an option. > >> If a user has a groupOf/groupMembership attribute pointing to a group >> outside of ldap_group_search_base, will this be handled gracefully? > > Yes, the entry will simply be ignored if not resolvable. > > Simo. > I was discussing this with Dmitri this morning. I propose that we should probably do the following: After retrieving the user entry, verify whether the entry contains at least one memberOf attribute. If it does, continue processing as we do now (since it will be more efficient). If not, then we should slip into compatibility mode where we will search all groups for member= Does this seem sensible? - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkxNjp8ACgkQeiVVYja6o6MkagCfRVK6+fEOs/3PUp2HiGeACu4g iWYAoKkgwvH5wJooMh1MCuyUewrbu692 =vwp8 -----END PGP SIGNATURE----- From sgallagh at redhat.com Mon Jul 26 13:36:37 2010 From: sgallagh at redhat.com (Stephen Gallagher) Date: Mon, 26 Jul 2010 09:36:37 -0400 Subject: [Freeipa-users] SSS problems with eDirectory In-Reply-To: References: <20100722081937.GN27552@localhost.localdomain> <20100722150741.GP27552@localhost.localdomain> <4C48741F.8030304@redhat.com> <20100722212434.GR27552@localhost.localdomain> Message-ID: <4C4D8F65.5060707@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/23/2010 05:45 PM, Scott Duckworth wrote: > On Thu, Jul 22, 2010 at 5:24 PM, Sumit Bose > >> I can prepare a special build for you which prints the >> LDAP_OPT_DIAGNOSTIC_MESSAGE LDAP option and let you use wireshark. But >> I'm afraid this has to wait until tomorrow, it's nearly half to >> midnight, here. > > >> That may be useful to others, too. Why not put it in the production build? > I have just built a scratch build in Koji containing two additional patches: 1) Print the LDAP_OPT_DIAGNOSTIC_MESSAGE as Sumit suggested. This patch will likely go upstream, as you are correct that it is very useful. 2) Custom for you, there is a patch included that will allow you to perform auth unencrypted, so you can examine the wire data. This patch will NOT go upstream, since we really don't want people doing this in the real world. Please try the build available at http://koji.fedoraproject.org/koji/taskinfo?taskID=2351272 (it will only be available for about two weeks from today) - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkxNj2UACgkQeiVVYja6o6MhZQCdEUKpx2R0DSA1ARLQmwqlPpyh Rv0AoKnIfR2ZkaNziIHpvHPaZ7i3cIeR =k+lz -----END PGP SIGNATURE----- From shan.sysadm at gmail.com Mon Jul 26 14:01:01 2010 From: shan.sysadm at gmail.com (Shan Kumaraswamy) Date: Mon, 26 Jul 2010 17:01:01 +0300 Subject: [Freeipa-users] Rebuild FreeIPA V2 In-Reply-To: References: Message-ID: All, Can I rebuild FreeIPA v2 (released alpha version 3) against RHEL 5.5? If possible, please let me know the source rpm location and steps. And let me know when we can avail final version FreeIPA v2 -- Thanks & Regards Shan Kumaraswamy -------------- next part -------------- An HTML attachment was scrubbed... URL: From ssorce at redhat.com Mon Jul 26 14:46:17 2010 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 26 Jul 2010 10:46:17 -0400 Subject: [Freeipa-users] SSS problems with eDirectory In-Reply-To: <4C4D8EA2.8020503@redhat.com> References: <4C476D89.6010603@redhat.com> <4C477238.8020008@redhat.com> <20100722115933.419f0614@willson.li.ssimo.org> <20100722153906.1903650f@willson.li.ssimo.org> <20100722164950.31fe9253@willson.li.ssimo.org> <20100723101629.GT27552@localhost.localdomain> <20100723181529.0e649b6f@willson.li.ssimo.org> <4C4D8EA2.8020503@redhat.com> Message-ID: <20100726104617.35123f52@willson.li.ssimo.org> On Mon, 26 Jul 2010 09:33:22 -0400 Stephen Gallagher wrote: > I was discussing this with Dmitri this morning. I propose that we > should probably do the following: > > After retrieving the user entry, verify whether the entry contains at > least one memberOf attribute. If it does, continue processing as we do > now (since it will be more efficient). If not, then we should slip > into compatibility mode where we will search all groups for > member= > > Does this seem sensible? yes and no. Actually we should really have a switch that tells us whether we fully trust memberof to give us the complete picture (IPA case) or if we should use it only as a hint (AD and servers that do not use memberof at all). In AD for example we currently return only direct memberships because in AD member/memberof are linked attributes, this means memberof does not contains DNs of indirect group memberships. I believe eDirectory is probably the same even when their memberof-equivalent attribute is set (assuming they support nesting at all). Of course we can also have a switch to allow searching for nested groups or not, so that we do not cause unnecessary searches on deployments that do not use any form of nesting. The parameter should actually probably be an integer that determines the level of nesting we allow to search at runtime, with 0 meaning none and any other value up to a maximum we define allowing deeper and deeper nesting. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Mon Jul 26 15:06:59 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 26 Jul 2010 11:06:59 -0400 Subject: [Freeipa-users] Rebuild FreeIPA V2 In-Reply-To: References: Message-ID: <4C4DA493.4030908@redhat.com> Shan Kumaraswamy wrote: > All, > > > Can I rebuild FreeIPA v2 (released alpha version 3) against RHEL 5.5? If > possible, please let me know the source rpm location and steps. > > And let me know when we can avail final version FreeIPA v2 We recently released IPA v2 alpha 4. You can get the srpms at http://freeipa.org/downloads/devel/srpms/ipa-1.9.0.pre4-0.fc12.src.rpm I don't think you'll have much luck building this on RHEL 5.x though. We are dropping support for running the server on RHEL 5 in v2. It might still build and be usable but I couldn't guarantee it. rob From jinchausti at citdev.com Wed Jul 28 11:20:45 2010 From: jinchausti at citdev.com (Juan =?iso-8859-1?Q?Jos=E9_Inchausti?=) Date: Wed, 28 Jul 2010 13:20:45 +0200 (CEST) Subject: [Freeipa-users] (no subject) Message-ID: Hi all, I was looking for Penrose and arrive here! I'm facing a big LDAP project that involves two LDAPs, #users about 750.000, and I think Penrose would be the right choice. Is Penrose a part of freeipa??? May I use Penrose as a standalone component??? My apps must access the information stored in the two big LDAPs, but they only have to look at one LDAP, so I wonder if ipa can help me, or I have only to use Penrose. Thanks in advance From dpal at redhat.com Wed Jul 28 12:43:29 2010 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 28 Jul 2010 08:43:29 -0400 Subject: [Freeipa-users] (no subject) In-Reply-To: References: Message-ID: <4C5025F1.7040301@redhat.com> Juan Jos? Inchausti wrote: > Hi all, > > I was looking for Penrose and arrive here! I'm facing a big LDAP project > that involves two LDAPs, #users about 750.000, and I think Penrose would > be the right choice. Is Penrose a part of freeipa??? It is not at the moment. Penrose is more a migration tool from NIS to IPA for now. > May I use Penrose as > a standalone component??? Yes > My apps must access the information stored in > the two big LDAPs, but they only have to look at one LDAP, so I wonder if > ipa can help me, or I have only to use Penrose. > If your applications use identities provided by NSS via nsswitch you can use SSSD and configure it to get identities from the two LDAP sources. Can you please be more specific about the use cases you have? Do you need to do searches against to LDAP servers or it is just user identity and authentication? Are your applications web applications? > Thanks in advance > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > > -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From jinchausti at citdev.com Wed Jul 28 13:12:20 2010 From: jinchausti at citdev.com (Juan =?iso-8859-1?Q?Jos=E9_Inchausti?=) Date: Wed, 28 Jul 2010 15:12:20 +0200 (CEST) Subject: [Freeipa-users] (no subject) In-Reply-To: <4C5025F1.7040301@redhat.com> References: <4C5025F1.7040301@redhat.com> Message-ID: <7947b5fee570c693d590cb9486106283.squirrel@webmail.citdev.com> Hi Dmitri, First of all, thanks for your quick answer... Well, my apps are web apps. By the moment, it's only identity and authentication, but my customer would like not to close doors by the moment. In the future, it will be possible to get some stathistics from the data stored in the LDAP's (geographic criteria, for instance) So, in this right moment, we are starting thinking is the whole architecture of the solution, and I would like to use a virtual directory like Penrose, because I think it would give us some flexibility I don't want to lack for in the future. Regards > Juan Jos? Inchausti wrote: >> Hi all, >> >> I was looking for Penrose and arrive here! I'm facing a big LDAP project >> that involves two LDAPs, #users about 750.000, and I think Penrose would >> be the right choice. Is Penrose a part of freeipa??? > > It is not at the moment. Penrose is more a migration tool from NIS to > IPA for now. > >> May I use Penrose as >> a standalone component??? > > Yes > >> My apps must access the information stored in >> the two big LDAPs, but they only have to look at one LDAP, so I wonder >> if >> ipa can help me, or I have only to use Penrose. >> > If your applications use identities provided by NSS via nsswitch you can > use SSSD and configure it to get identities from the two LDAP sources. > Can you please be more specific about the use cases you have? Do you > need to do searches against to LDAP servers or it is just user identity > and authentication? > Are your applications web applications? > > >> Thanks in advance >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> >> > > > -- > Thank you, > Dmitri Pal > > Engineering Manager IPA project, > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > >