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 I'm unable to actually login due to pam_sss not working (see another branch of this thread). > 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.
_______________________________________________ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
