Re: [SSSD] sudo
by Stephen Gallagher
-----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-----
13 years, 8 months
Re: [SSSD] sudo
by Stephen Gallagher
-----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-----
13 years, 8 months
sudo
by Marcus Moeller
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
13 years, 8 months
authentication failure after machine start
by Marcus Moeller
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
13 years, 8 months
how does ldap_access_filter work
by Eric Doutreleau
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.
13 years, 8 months
SSSD offline authentication
by Andy Kannberg
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
13 years, 8 months
[PATCHES 1/2] Separate the common libraries into their own repository
by Stephen Gallagher
-----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-----
13 years, 8 months
[PATCHES 2/2] Have SSSD build against ding-libs
by Stephen Gallagher
-----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-----
13 years, 8 months
Special HBAC rules
by Dmitri Pal
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/
13 years, 8 months
ding-libs and SSSD
by Stephen Gallagher
-----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;...
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=shor...
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-----
13 years, 8 months
