sssd-devel August 2010

sssd-devel@lists.fedorahosted.org

17 participants
48 discussions

Re: [SSSD] sudo
by Stephen Gallagher 20 Aug '10

20 Aug '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/20/2010 10:09 AM, Marcus Moeller wrote: > Hi Stephen. > > Yes, then it's listed correctly. > > Greets > Marcus > > > > -- Gesendet von meinem Palm Pre > > ------------------------------------------------------------------------ > Stephen Gallagher <sgallagh(a)redhat.com> schrieb am 20.08.2010 16:06: > > On 08/20/2010 10:02 AM, Marcus Moeller wrote: >> Hi Stephen. > >>>>>>> While trying to use sudo with sssd I got an error like: >>>>>>> >>>>>>> Aug 9 16:20:41 HOST sudo: pam_sss(sudo:auth): received for user USER: >>>>>>> 9 (Authentication service cannot retrieve authentication info) >>>>>>> >>>>>> >>>>>> During authentication, the sssd Kerberos backend returns >>>>>> PAM_AUTHINFO_UNAVAIL (which is the error code 9 you are seeing) > when the >>>>>> KDC is unreachable and cached credentials not available. >>>>>> >>>>>> Would you mind checking the sssd logs if there is something > interesting >>>>>> either from the backend process or the krb5_child one? If sssd is >>>>>> running as daemon, that would be in /var/log/sss/sssd_$DOMAIN.log or >>>>>> /var/log/sss/krb5_child.log. >>>>> >>>>> This is the only output I got during sudo: >>>>> >>>>> (Wed Aug 11 13:22:07 2010) [sssd[be[MYDOMAIN]]] [get_server_status] >>>>> (7): Status of server 'kdc.mydomain' is 'working' >>>>> (Wed Aug 11 13:22:07 2010) [sssd[be[MYDOMAIN]]] [get_port_status] (7): >>>>> Port status of port 88 for server 'kdc.mydomain' is 'working' >>>>> (Wed Aug 11 13:22:07 2010) [sssd[be[MYDOMAIN]]] [resolve_srv_send] >>>>> (6): The status of SRV lookup is resolved >>>>> (Wed Aug 11 13:22:07 2010) [sssd[be[MYDOMAIN]]] [get_server_status] >>>>> (7): Status of server 'kdc.mydomain' is 'working' >>>>> (Wed Aug 11 13:22:07 2010) [sssd[be[MYDOMAIN]]] >>>>> [be_resolve_server_done] (4): Found address for server kdc.mydomain: >>>>> [192.168.1.201] >>>>> (Wed Aug 11 13:22:07 2010) [sssd[be[MYDOMAIN]]] >>>>> [be_pam_handler_callback] (4): Backend returned: (1, 9, <NULL>) >>>>> [Provider is Offline (Bad file descriptor)] >>>> >>>> The problem was not related to sssd. Sorry for the noice. >>>> >>> >>> Just to make sure: was this reply related to the sudo thread, or was >>> this meant to be a reply to the machine startup thread? >>> >>> I only ask because this thread is 9 days silent, but we've been talking >>> on the other thread this morning. > >> Sorry, this one was related to the other thread. > >> On the sudo problem I got a little update: groups with no () can be >> used successfully. But trying to use a group name like: > >> %mygroup\ $ISG$ > >> does not really work. > > > > Hmm, very interesting. If you do a 'getent group "mygroup (ISG)" at the > commandline, do you get it back? I wonder if we have a bug in our > communication protocol with the SSSD. > In that case, I'd say it's probably a bug in sudo. Something to try: create a similarly-named group in /etc/group and see if sudo has trouble with it there as well. If so, file a bug with sudo. - -- 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/ iEYEARECAAYFAkxujSYACgkQeiVVYja6o6O9fACfWhbhU7ejUp5MdCXjklfsFOzL /JkAnjXHOHL/ZHWLDZ/nOsqW3V/fniJj =mkT0 -----END PGP SIGNATURE-----

1 0

Re: [SSSD] sudo
by Stephen Gallagher 20 Aug '10

20 Aug '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/20/2010 10:02 AM, Marcus Moeller wrote: > Hi Stephen. > >>>>>> While trying to use sudo with sssd I got an error like: >>>>>> >>>>>> Aug 9 16:20:41 HOST sudo: pam_sss(sudo:auth): received for user USER: >>>>>> 9 (Authentication service cannot retrieve authentication info) >>>>>> >>>>> >>>>> During authentication, the sssd Kerberos backend returns >>>>> PAM_AUTHINFO_UNAVAIL (which is the error code 9 you are seeing) when the >>>>> KDC is unreachable and cached credentials not available. >>>>> >>>>> Would you mind checking the sssd logs if there is something interesting >>>>> either from the backend process or the krb5_child one? If sssd is >>>>> running as daemon, that would be in /var/log/sss/sssd_$DOMAIN.log or >>>>> /var/log/sss/krb5_child.log. >>>> >>>> This is the only output I got during sudo: >>>> >>>> (Wed Aug 11 13:22:07 2010) [sssd[be[MYDOMAIN]]] [get_server_status] >>>> (7): Status of server 'kdc.mydomain' is 'working' >>>> (Wed Aug 11 13:22:07 2010) [sssd[be[MYDOMAIN]]] [get_port_status] (7): >>>> Port status of port 88 for server 'kdc.mydomain' is 'working' >>>> (Wed Aug 11 13:22:07 2010) [sssd[be[MYDOMAIN]]] [resolve_srv_send] >>>> (6): The status of SRV lookup is resolved >>>> (Wed Aug 11 13:22:07 2010) [sssd[be[MYDOMAIN]]] [get_server_status] >>>> (7): Status of server 'kdc.mydomain' is 'working' >>>> (Wed Aug 11 13:22:07 2010) [sssd[be[MYDOMAIN]]] >>>> [be_resolve_server_done] (4): Found address for server kdc.mydomain: >>>> [192.168.1.201] >>>> (Wed Aug 11 13:22:07 2010) [sssd[be[MYDOMAIN]]] >>>> [be_pam_handler_callback] (4): Backend returned: (1, 9, <NULL>) >>>> [Provider is Offline (Bad file descriptor)] >>> >>> The problem was not related to sssd. Sorry for the noice. >>> >> >> Just to make sure: was this reply related to the sudo thread, or was >> this meant to be a reply to the machine startup thread? >> >> I only ask because this thread is 9 days silent, but we've been talking >> on the other thread this morning. > > Sorry, this one was related to the other thread. > > On the sudo problem I got a little update: groups with no () can be > used successfully. But trying to use a group name like: > > %mygroup\ $ISG$ > > does not really work. > Hmm, very interesting. If you do a 'getent group "mygroup (ISG)" at the commandline, do you get it back? I wonder if we have a bug in our communication protocol with the SSSD. - -- 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/ iEYEARECAAYFAkxui84ACgkQeiVVYja6o6PN4ACeL39mjvExsD1tFO9sGIo9l6Px 668An0ib1AoJ+vUPS2a3xISwcI4L/ZTN =yHZH -----END PGP SIGNATURE-----

1 0

sudo
by Marcus Moeller 20 Aug '10

20 Aug '10

Hi all. While trying to use sudo with sssd I got an error like: Aug 9 16:20:41 HOST sudo: pam_sss(sudo:auth): received for user USER: 9 (Authentication service cannot retrieve authentication info) -- Greets Marcus

3 4

authentication failure after machine start
by Marcus Moeller 20 Aug '10

20 Aug '10

Hi all. Directly after machine startup I get an authentication failure while trying to login. If I wait about 3 or 5 minutes, the failure is gone. Could it be that sssd first needs to generate some caches? -- Greets Marcus

2 3

how does ldap_access_filter work
by Eric Doutreleau 20 Aug '10

20 Aug '10

hi i m using sssd sssd-1.2.2-19 on Fedora 13 machine and i m a bit puzzled by how ldap_access_filter work indeed i have in my sssd.conf file the following lines access_provider = ldap ldap_access_filter = IntEPersInetServ=*unix-rst* when i run ldapsearch -x -h ldap2.int-evry.fr -b dc=int-evry,dc=fr -D "cn=mcibind,ou=System,dc=int-evry,dc=fr" -W "(&(IntEPersInetServ="*unix-rst*")(uid=test))" Enter LDAP Password: # extended LDIF # # LDAPv3 # base <dc=int-evry,dc=fr> with scope subtree # filter: (&(IntEPersInetServ=*unix-rst*)(uid=test)) # requesting: ALL # # search result search: 2 result: 0 Success i got no answer for the test account but when i run getent passwd test test:*:14527:145:compte de test s2ia:/mci/test/test:/usr/local/bin/bash but when i want to log as test user with the good password i can't log i see in the secure log file Aug 20 12:15:00 rst-9119 sshd[2888]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=157.159.21.234 user=test Aug 20 12:15:00 rst-9119 sshd[2888]: pam_sss(sshd:account): Access denied for user test: 6 (Permission denied) is it supposed to work like that? it s a bit different from the parameter pam_filter in the ldap.conf file.

2 2

SSSD offline authentication
by Andy Kannberg 20 Aug '10

20 Aug '10

Hi again, I'm trying to setup offline authentication. I've added the cache_credentials = true for the LDAP domain in the /etc/sssd/sssd.conf but when I try to login (while network is not connected), I get a timeout. Is there anything else that needs to be configured ? cheers, Andy

2 1

[PATCHES 1/2] Separate the common libraries into their own repository
by Stephen Gallagher 19 Aug '10

19 Aug '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The attached patches are applied atop the repository resulting after the following command is run: git filter-branch --subdirectory-filter common This causes the common directory to become the base directory in this branch, and rewrites the branch history so that only the changes to the files in this branch are retained. Then these eleven patches are applied to have the new "ding-libs" build individual tarballs and RPMs. Each patch is very small and self-contained, so I'm not explaining them individually. - -- 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/ iEYEARECAAYFAkxlqMEACgkQeiVVYja6o6MtfQCfXFfaFwIjOT0ZW9mJxjIJkoRv UGoAmwabr/LQ9wvPLu46EKtfGtxfLPvg =CDY1 -----END PGP SIGNATURE-----

2 3

[PATCHES 2/2] Have SSSD build against ding-libs
by Stephen Gallagher 19 Aug '10

19 Aug '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Patch 0001: Remove the common directory (does not impact history) This patch is bzip2-compressed, as it is enormous, since it contains the contents of every file being removed. Patch 0002: Move source files up to the root directory Patch 0003: Update the RPM-generation to rely on the ding-libs - -- 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/ iEYEARECAAYFAkxlqzMACgkQeiVVYja6o6MG5wCeLwxyYuMBZa5RQnjGJwXOR0KT RnAAn3lxnIGx/KS6yOmlbQd5Z7NiUNB6 =Un/I -----END PGP SIGNATURE-----

2 6

Special HBAC rules
by Dmitri Pal 16 Aug '10

16 Aug '10

Hello, On a discussion about the UI for HBAC rules it occured to me that there is a use case that we currently do not support with IPA<->SSSD. I do not think it will be an issue for IPAv2 and SSSD 1.5 or but down the road probably yes. So I want to put together a good description of the feature into a trac ticket. But I need to ask questions first, thus this email. The HBAC is good for the cases when a group of admins has access to the group of the machines. But those rules are not that good for the laptop use case. Effectively the access to any laptop will usually be controlled by the two logical rules: * Allow a group of admins to access a group of the laptops - this is handled well with HBAC rules. * Allow the owner of the laptop to access the laptop locally and remotely. Hm... But how to express this without creating individual rules for every user-laptop pair? Here is what comes to mind. In the HBAC rule we have the concept of the hostCategory. Currently we support only "All". But we can easily support the category "Laptop" or "Personal Computer" to be more generic and add a special string attribute "hostPattern" that will contain a pattern that will allow to match host name and the user name. By placing users and groups into such rule we will effectively allow laptop users access to their own machines. Here is the example: my login name is dpal (short one) and dpal(a)redhat.com is long one. My host name is dpal.laptop So if I create an HBAC rule: dn: ipaUniqueID=49af8430-cbed-11dd-ad8b-0800200c9a66, cn=hbac,... objectClass: top objectClass: ipaAssociation objectClass: ipaHBACRule ipaUniqueID: 49af8430-cbed-11dd-ad8b-0800200c9a66 accessRuleType: allow memberUser: cn=dpal,cn=users,cn=accounts,... memberUser: cn=sgallagh,cn=users,cn=accounts,... memberUser: cn=ssorce,cn=users,cn=accounts,... memberUser: cn=ssbose,cn=users,cn=accounts,... memberUser: cn=Brnodev,cn=groups,cn=accounts,... memberService: cn=ssh,cn=hbacservices,cn=accounts,... hostCategory: laptop hostPattern: %short%.laptop ... This rule grants individual users listed above and Brno developers access to the machines who's name starts with the short name of user and has suffix ".laptop". The only drawback is that the admins would have to use some kind of pattern for the personal machine names derived from the user name. IMO this is a reasonable suggestion for those who want to start to control access via HBAC rules, Potentially we can support several patterns in one HBAC rule if there different naming conventions due to acquisitions and other historical reasons. Thoughts? -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/

3 3

ding-libs and SSSD
by Stephen Gallagher 16 Aug '10

16 Aug '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 As you have probably already seen by my previous patches, we are planning to separate out the 'common' directory of the SSSD and build them as separate libraries (the 'ding-libs'). I have pushed my work to my FedoraPeople repositories for review. The new ding-libs structure: http://fedorapeople.org/gitweb?p=sgallagh/public_git/ding-libs.git;a=summary A view of the SSSD after splitting off the ding-libs: http://fedorapeople.org/gitweb?p=sgallagh/public_git/sssd.git;a=shortlog;h=… And finally, a set of patches from Dmitri for the ding-libs, rebased onto the split-out tree: http://fedorapeople.org/gitweb?p=sgallagh/public_git/ding-libs.git;a=shortl… The plan is that the ding-libs will follow their own development cycle, and we will pull them into SSSD whenever we need a particular new feature from them. This will save the SSSD from having to build and package an update to each of the ding-libs every time we have to do a release. In addition, we will be giving over creative control of the ding-libs to Dmitri, and we will reduce our review requirements for a few months while heavy proof-of-concept development is going on. - -- 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/ iEYEARECAAYFAkxpZ9cACgkQeiVVYja6o6NWSQCeP58tBfZMieL2ZJ917C5gnuno egwAn0RsikrZ3JC1ITWOyJvbxdYxEeuP =I0P8 -----END PGP SIGNATURE-----

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

sssd-devel August 2010