[Freeipa-users] SSS problems with eDirectory

[Sumit Bose]

On Thu, Jul 22, 2010 at 04:49:50PM -0400, Simo Sorce wrote:
> On Thu, 22 Jul 2010 16:22:45 -0400
> Scott Duckworth <sduckwo at clemson.edu> wrote:
> 
> > On Thu, Jul 22, 2010 at 3:39 PM, Simo Sorce <ssorce at redhat.com> wrote:
> > 
> > > On Thu, 22 Jul 2010 15:30:23 -0400
> > > Scott Duckworth <sduckwo at clemson.edu> wrote:
> > >
> > > > On Thu, Jul 22, 2010 at 11:59 AM, Simo Sorce <ssorce at redhat.com>
> > > > wrote:
> > > >
> > > > > On Thu, 22 Jul 2010 11:10:25 -0400
> > > > > Scott Duckworth <sduckwo at clemson.edu> 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