Fedora Linux Support Community & Resources Center
  #1  
Old 20th December 2010, 05:08 AM
chakkerz Offline
Registered User
 
Join Date: Dec 2010
Posts: 8
macosfirefox
sssd is a default permit setup?

Hello there

I'm a complete newcomer to sssd, lured by the promise of caching credentials. I've played with it for about 3 hours now (on RHEL6) and so far all is going great but I've come up against a problem:

I have a bunch of people in my ldap who belong to various groups but not all of them have access to individual servers. So, I'd like to disallow their logging in to my hosts. Previously we set /etc/security/access.conf to exclude the groups in question, and really that wasn't a great solution because I'd set allow and deny for each group. I can do the same thing in effect in sssd by filtering the groups I don't want to allow to log in, but, really I would like to set the people I want to allow login instead.

Now I figure I can do this in pam.d somehowby requiring it to look at access.conf rather than going with the default example which gets around this, but really, I'd prefer not to stray too far of the beaten pam.d track. and washoping that I'm just missing some simple setting in sssd.conf.

Any thoughts on how I can achieve this easily, or if this is a pam thing, where I can find some information about this. I've not had a lot of luck finding much sssd related things and RHEL and sssd's guides are lacking the depth I seek (or I'm just blind )

Any help appreciated!

chakkerz
Reply With Quote
  #2  
Old 20th December 2010, 01:30 PM
sgallagh Offline
Registered User
 
Join Date: Aug 2010
Posts: 25
linuxfedorafirefox
Re: sssd is a default permit setup?

Look at sssd-simple(5)

You can set
access_provider = simple
simple_allow_users = user1, user2, user3

And only the users in this list will be allowed access. SSSD 1.5.0 (being released upstream this week) also supports a new option
simple_allow_groups = group1, group2

To allow you to specify a group membership that is allowed. (You can also make exceptions with the simple_deny_* options)

---------- Post added at 08:30 AM ---------- Previous post was at 08:27 AM ----------

Additionally, if you want to centralize this more, you can look at sssd-ldap(5)

If you set:
access_provider = ldap
You can do:

ldap_access_filter (string)
If using access_provider = ldap, this option is mandatory. It specifies an LDAP search filter criteria
that must be met for the user to be granted access on this host. If access_provider = ldap and this
option is not set, it will result in all users being denied access. Use access_provider = allow to change
this default behavior.

Example:

access_provider = ldap
ldap_access_filter = memberOf=cn=allowedusers,ou=Groups,dc=example,dc=c om

This example means that access to this host is restricted to members of the "allowedusers" group in ldap.

Offline caching for this feature is limited to determining whether the user´s last online login was
granted access permission. If they were granted access during their last login, they will continue to be
granted access while offline and vice-versa.

Default: Empty
Reply With Quote
  #3  
Old 21st December 2010, 12:42 AM
chakkerz Offline
Registered User
 
Join Date: Dec 2010
Posts: 8
macosfirefox
Re: sssd is a default permit setup?

sssd-simple, especially for groups is along the lines of what I want, but since it may not pop up in RHEL anyway, I'll go with the other one that is in RHEL.

my sssd.conf file contains:
Code:
auth_provider = ldap
ldap_schema = rfc2307
ldap_uri = ldaps://tangelo.example.org
ldap_search_base = dc=its,dc=example,dc=org
ldap_tls_reqcert = demand
cache_credentials = true
enumerate = true
ldap_tls_cacert = /etc/certs/cacert.pem
# quest for hashes
debug_level = 10
#chpass_provider = ldap
#ldap_pwd_policy = shadow
ldap_default_bind_dn = cn=authenticated_LDAP,dc=its,dc=example,dc=org
ldap_default_authtok_type = password
ldap_default_authtok = wh@tever
access_provider = ldap
ldap_access_filter = memberOf=cn=nsysadm,ou=Group,dc=its,dc=example,dc=org
And if i query my ldap service i am listed (as memberUid ?) in the output:
Code:
[root@squeak ~]# ldapsearch -x -b 'cn=nsysadm,ou=Group,dc=its,dc=example,dc=org' 

# nsysadm, Group, its.example.org
dn: cn=nsysadm,ou=Group,dc=its,dc=example,dc=org
objectClass: posixGroup
objectClass: top
cn: nsysadm
gidNumber: 902
memberUid: chakkerz

# search result
search: 2
result: 0 Success
but sssd is not happy:

Code:
[root@pomelo ~]# tail -f /var/log/sssd/sssd_LDAP.log  | grep chakkerz
(Tue Dec 21 10:14:36 2010) [sssd[be[LDAP]]] [sdap_save_user_send] (7): Adding original DN [cn=Christian Unger,ou=People,dc=its,dc=example,dc=org] to attributes of [chakkerz].
(Tue Dec 21 10:14:36 2010) [sssd[be[LDAP]]] [sdap_save_user_send] (7): Original memberOf is not available for [chakkerz].
(Tue Dec 21 10:14:36 2010) [sssd[be[LDAP]]] [sdap_save_user_send] (7): User principal is not available for [chakkerz].
(Tue Dec 21 10:14:36 2010) [sssd[be[LDAP]]] [sdap_save_user_send] (6): Storing info for user chakkerz
(Tue Dec 21 10:14:36 2010) [sssd[be[LDAP]]] [sysdb_attrs_users_from_ldb_vals] (7):     member #0: [name=chakkerz,cn=users,cn=LDAP,cn=sysdb]
(Tue Dec 21 10:14:43 2010) [sssd[be[LDAP]]] [be_get_account_info] (4): Got request for [3][1][name=chakkerz]
(Tue Dec 21 10:14:43 2010) [sssd[be[LDAP]]] [sdap_get_generic_send] (6): calling ldap_search_ext with [(&(uid=chakkerz)(objectclass=posixAccount))][dc=its,dc=example,dc=org].
(Tue Dec 21 10:14:43 2010) [sssd[be[LDAP]]] [sdap_save_user_send] (7): Adding original DN [cn=Christian Unger,ou=People,dc=its,dc=example,dc=org] to attributes of [chakkerz].
(Tue Dec 21 10:14:43 2010) [sssd[be[LDAP]]] [sdap_save_user_send] (7): Original memberOf is not available for [chakkerz].
(Tue Dec 21 10:14:43 2010) [sssd[be[LDAP]]] [sdap_save_user_send] (7): User principal is not available for [chakkerz].
(Tue Dec 21 10:14:43 2010) [sssd[be[LDAP]]] [sdap_save_user_send] (6): Storing info for user chakkerz
(Tue Dec 21 10:14:43 2010) [sssd[be[LDAP]]] [sdap_get_generic_send] (6): calling ldap_search_ext with [(&(memberuid=chakkerz)(objectclass=posixGroup))][dc=its,dc=example,dc=org].
(Tue Dec 21 10:14:43 2010) [sssd[be[LDAP]]] [pam_print_data] (4): user: chakkerz
(Tue Dec 21 10:14:43 2010) [sssd[be[LDAP]]] [sdap_password_cache_done] (4): Password successfully cached for chakkerz
(Tue Dec 21 10:14:43 2010) [sssd[be[LDAP]]] [pam_print_data] (4): user: chakkerz
(Tue Dec 21 10:14:43 2010) [sssd[be[LDAP]]] [sdap_access_send] (6): Performing access check for user [chakkerz]
(Tue Dec 21 10:14:43 2010) [sssd[be[LDAP]]] [sdap_get_generic_send] (6): calling ldap_search_ext with [(&(uid=chakkerz)(objectclass=posixAccount)(memberOf=cn=nsysadm,ou=Group,dc=its,dc=example,dc=org))][cn=Christian Unger,ou=People,dc=its,dc=example,dc=org].
(Tue Dec 21 10:14:43 2010) [sssd[be[LDAP]]] [sdap_access_get_access_done] (4): User [chakkerz] was not found with the specified filter. Denying access.
Now, I'm not that in depth with ldap, but i was also considering that it might be looking at my record and looking for a memberOf field, but that's not there anywhere either (and phpldapadmin / my schema don't allow me to add it).

The version of the sssd i'm running is:
[root@pomelo ~]# rpm -q sssd
sssd-1.2.1-28.el6_0.4.x86_64

Any thoughts?
Cheers
chakkerz
Reply With Quote
  #4  
Old 21st December 2010, 12:14 PM
sgallagh Offline
Registered User
 
Join Date: Aug 2010
Posts: 25
linuxfirefox
Re: sssd is a default permit setup?

First of all, you can reasonably assume that SSSD 1.5.0 will be in an upcoming RHEL 6 release (https://bugzilla.redhat.com/show_bug.cgi?id=644072).

Yeah, you can only use "memberOf" in your ldap filter if you actually have the memberOf attribute on your users (for example, FreeIPA has an automatic memberOf plugin in its directory server that creates member/memberOf bi-directional links between users and groups). In your case, you're using an RFC2307 server which does not have member/memberOf available (that's an RFC2307bis feature)

The ldap_access_filter rule allows you to create an ldap search filter that, if it returns anything, means that the user is granted access. One common way this is used would be to add an attribute on the user entry named "host" whose value might be "client.example.com". Then you could have:
Code:
ldap_access_filter = host=client.example.com
and only users with that matching attribute would be allowed access.
Reply With Quote
  #5  
Old 21st December 2010, 11:55 PM
chakkerz Offline
Registered User
 
Join Date: Dec 2010
Posts: 8
macosfirefox
Re: sssd is a default permit setup?

re bugzilla - fantastic, though 6.1 is a long way off and I want to roll RHEL6 out ... anyway great news!

Ok, understanding that syntax a bit more, and can get that to work. Is there any means of doing a logic OR, so i can have members of different groups having equal login ability. Incidentally though I've found a curious feature: I'm member of 902, but i want to allow 911 access as well, if I have the following I can get in:
Code:
access_provider = ldap
ldap_access_filter = gidNumber=911
ldap_access_filter = gidNumber=902
but if i do the following, i can't:
Code:
access_provider = ldap
ldap_access_filter = gidNumber=902
ldap_access_filter = gidNumber=911
The log indicates it uses only the last thing... Not sure if that's intentional or not...

Last edited by chakkerz; 21st December 2010 at 11:56 PM. Reason: code tags
Reply With Quote
  #6  
Old 22nd December 2010, 12:08 PM
sgallagh Offline
Registered User
 
Join Date: Aug 2010
Posts: 25
linuxfirefox
Re: sssd is a default permit setup?

There are no values in the sssd.conf that can be specified multiple times. In an upcoming release, we're going to be doing better validation in the parser to throw an error if you try to set the same option twice.

The ldap_access_filter option format conforms to an LDAP search filter. So if you want to have an OR or an AND in it, you need to follow the LDAP search filter syntax. A decent reference for this can be found here.

In the specific example below, you'd want:

Code:
access_provider = ldap
ldap_access_filter = (|(gidNumber=911)(gidNumber=902))
Just a word of caution, however. This search filter will only be restricting access to users whose primary group is 911 or 902. It won't be allowing access to all members of those groups (e.g. those users who have a different primary group, but are members of 911 or 902 as well) To include all members of a group you either need to use the simple access provider as I mentioned above, or modify your LDAP server such that it includes a memberOf (or similar) plugin that creates a back-link attribute in the users.
Reply With Quote
  #7  
Old 23rd December 2010, 04:39 AM
chakkerz Offline
Registered User
 
Join Date: Dec 2010
Posts: 8
macossafari
Re: sssd is a default permit setup?

Thanks for that link. I would have hoped someone here (including someone who did post grad on LDAP) would have perked up and said something about there being LDAP search filters syntax...

Ah well, at least I learnt something

Thanks also for pointing out the primary group "issue" though that was the behaviour I was hoping for (and was guessing at from what debug output shows me).

Looks like it works a treat, which means I can just use a template file in puppet to manage this centrally.

Thank you very much for your help! And have a good Christmas!

---------- Post added at 02:39 PM ---------- Previous post was at 12:21 PM ----------

OK, this might be a bug or intentional (though the documentation does not appear to reflect this).

I have a user here, who as my faithful guinea pig logged into the box and should have been blocked by the ldap_access_filter because his gidNumber isn't there. But he got in, and the log (debug cranked up to 6) indicates that the filter is NOT invoked:

Code:
(Thu Dec 23 14:19:43 2010) [sssd[be[USG_LDAP_2010]]] [sdap_get_generic_send] (6): calling ldap_search_ext with [(&(uid=chakkerzis)(objectclass=posixAccount))][dc=its,dc=example,dc=org].
(Thu Dec 23 14:19:43 2010) [sssd[be[USG_LDAP_2010]]] [sdap_save_user_send] (6): Storing info for user chakkerzis
(Thu Dec 23 14:19:43 2010) [sssd[be[USG_LDAP_2010]]] [sdap_get_generic_send] (6): calling ldap_search_ext with [(&(memberuid=chakkerzis)(objectclass=posixGroup))][dc=its,dc=example,dc=org].
(Thu Dec 23 14:19:43 2010) [sssd[be[USG_LDAP_2010]]] [pam_print_data] (4): user: chakkerzis
A lot of tweaking and so forth and we found it is linked to the pam.d/system-auth setting for the UID where users (mere mortals) start. His UID is (due to oversight many moons ago) below the 500 threshold, so lowering the two 500's in the file to 200 causes a different output in the log:

Code:
(Thu Dec 23 14:26:10 2010) [sssd[be[USG_LDAP_2010]]] [sdap_get_generic_send] (6): calling ldap_search_ext with [(&(uid=chakkerzis)(objectclass=posixAccount)(|(gidNumber=902)(gidNumber=911)))][cn=Christian Unger IS TEST,ou=people,dc=its,dc=example,dc=org].
(Thu Dec 23 14:26:10 2010) [sssd[be[USG_LDAP_2010]]] [sdap_access_get_access_done] (4): User [chakkerzis] was not found with the specified filter. Denying access.
The code here is simulated with the uid actually being above 2000 but i doubt that matters, because the result is the same.

So is this special treatment of said UID intentional, because if I have this:
Code:
auth        required      pam_env.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        sufficient    pam_sss.so use_first_pass
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        required      pam_deny.so
... my sub 500 UID user can login, regardless of the filter setting, but with
Code:
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_sss.so use_first_pass
auth        required      pam_deny.so
... he fails at the third line. So there is some interplay.... which one might argue is by design. But, I'm thinking it might be a bug... because the documentation with min_ID indicates/implies that this should be independent...

Sorry

There is more to this, because when i edited system-auth i also edited the second instance of the UID test:
Code:
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_sss.so
account     required      pam_permit.so
Which at this stage is doing my head in.... but i thought i should mention because it might explain some of the interplay and at worst allow reproduction...

Last edited by chakkerz; 23rd December 2010 at 04:59 AM. Reason: missing information added, royal we removed, real we retained
Reply With Quote
  #8  
Old 23rd December 2010, 12:54 PM
sgallagh Offline
Registered User
 
Join Date: Aug 2010
Posts: 25
linuxfirefox
Re: sssd is a default permit setup?

First, you need to undestand the meaning of "required", "requisite", "sufficient" and "optional"

Required: This check must be performed, and if it fails, the PAM stack returns failure eventually (but it will still run further checks)
Requisite: This check must be performed, and if it fails, the PAM stack returns failure immediately, not running further checks.
Sufficient: If this check passes, the PAM stack returns success immediately. Otherwise it just moves on.
Optional: The result of this check doesn't affect the overall return value of the PAM stack.

The PAM stack proceeds from the top to the bottom. So let's go through my PAM stack a step at a time.

Code:
account     required      pam_unix.so broken_shadow
The account is checked against access-control checks in /etc/shadow. If the user is not recognized, it continues on.

Code:
account     sufficient    pam_localuser.so
Checks whether the account is local (appears in /etc/passwd). If it does, then the result from pam_unix.so is returned.

[CODE]account sufficient pam_succeed_if.so uid < 500 quiet[CODE]
This is intended to ensure that local accounts for system services (which by Fedora policy are all users with UID < 500) get automatic access. So even if the user is not a local user, if its ID < 500, it's allowed in as a service.

Code:
account     [default=bad success=ok user_unknown=ignore] pam_sss.so
This one's a little complicated, but essentially it means to consider the pam_sss.so result only if it doesn't return "user unknown".

Code:
account     required      pam_permit.so
And finally, if nothing above has denied access, the default (on this system) is to allow.


This is all normal behavior of PAM and has nothing to do with SSSD. My strong recommendation is that you should change this user's ID if at all possible. All IDs below 500 are reserved for known system services, so sooner or later that user is going to conflict with the service user.
Reply With Quote
  #9  
Old 23rd December 2010, 11:26 PM
chakkerz Offline
Registered User
 
Join Date: Dec 2010
Posts: 8
macossafari
Re: sssd is a default permit setup?

Right, so it is due to the account, not the auth section, which i suspected because of how the log was indicating sssd was processing the requests.

I think we will need to relocate the UIDs from sub 500 to the range I reserved on our systems some time ago...

Once again thanks so much for all your help and patience. Merry Christmas!
chakkerz
Reply With Quote
  #10  
Old 3rd March 2011, 01:56 AM
linux4guru Offline
Registered User
 
Join Date: Jan 2005
Posts: 12
windows_7chrome
Re: sssd is a default permit setup?

my problem now is that gdm login failed for ldap user account. I can login with a local account or root account and then su - ldapuser

that works fine!
Reply With Quote
  #11  
Old 4th March 2011, 12:54 AM
sgallagh Offline
Registered User
 
Join Date: Aug 2010
Posts: 25
linuxfedorafirefox
Re: sssd is a default permit setup?

Quote:
Originally Posted by linux4guru View Post
my problem now is that gdm login failed for ldap user account. I can login with a local account or root account and then su - ldapuser

that works fine!
On Fedora, GDM uses /etc/pam.d/password instead of /etc/pam.d/system-auth

You need to make sure that you set up /etc/pam.d/password to use pam_sss.so the same way that system-auth does.
Reply With Quote
Reply

Tags
ldap, pam, pam.d, sssd, sssd.conf

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] sssd ??? GoinEasy9 F16 Development 0 4th April 2010 02:41 AM
permit required for sheetrock??? hiberphoptik Wibble 5 13th March 2009 01:50 AM
Default login setup madhuti Using Fedora 6 21st February 2008 09:10 AM
Setup KDE as default desktop satimis Using Fedora 7 27th September 2004 04:38 PM


Current GMT-time: 03:59 (Friday, 31-10-2014)

TopSubscribe to XML RSS for all Threads in all ForumsFedoraForumDotOrg Archive
logo

All trademarks, and forum posts in this site are property of their respective owner(s).
FedoraForum.org is privately owned and is not directly sponsored by the Fedora Project or Red Hat, Inc.

Privacy Policy | Term of Use | Posting Guidelines | Archive | Contact Us | Founding Members

Powered by vBulletin® Copyright ©2000 - 2012, vBulletin Solutions, Inc.

FedoraForum is Powered by RedHat
King of Prussia Instagram Photos - Barreiros Photos on Instagram - Kyle Instagram Photos