On Thu, 22 Jul 2010 16:22:45 -0400 Scott Duckworth <sduc...@clemson.edu> wrote:
> On Thu, Jul 22, 2010 at 3:39 PM, Simo Sorce <sso...@redhat.com> wrote: > > > On Thu, 22 Jul 2010 15:30:23 -0400 > > Scott Duckworth <sduc...@clemson.edu> wrote: > > > > > On Thu, Jul 22, 2010 at 11:59 AM, Simo Sorce <sso...@redhat.com> > > > wrote: > > > > > > > On Thu, 22 Jul 2010 11:10:25 -0400 > > > > Scott Duckworth <sduc...@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: > > > > > > > > > > [r...@duck2 ~]# getent passwd sduckwo > > > > > sduckwo:*:45265:10000:Scott Duckworth:/home/sduckwo:/bin/bash > > > > > [r...@duck2 ~]# groups sduckwo > > > > > sduckwo : cuuser > > > > > [r...@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): > > > > > > [r...@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... > > [r...@duck2 ~]# service sssd stop > [r...@duck2 ~]# rm -f /var/lib/sss/db/* > [r...@duck2 ~]# service nscd stop > [r...@duck2 ~]# service sssd start > Starting sssd: [ OK ] > [r...@duck2 ~]# id sduckwo > uid=45265(sduckwo) gid=10000(cuuser) groups=10000(cuuser) > [r...@duck2 ~]# su - sduckwo > [16:05:24] sduc...@duck2:~ [1] id > uid=45265(sduckwo) gid=10000(cuuser) groups=10000(cuuser) > [16:05:26] sduc...@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 _______________________________________________ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
