Some groups are retrieved only when an actual authentication attempt happens. Listing groups in other situations may not yeld correct results in AD environments as the list of groups a user is in may vary depending on various factors. Only the PAC retrieved at auth time is a full source of truth.
Also we do not perform enumeration by default. HTH, Simo. On Tue, 2018-04-24 at 11:24 -0400, Max DiOrio wrote: > So as I stated, I upgraded, cleared the cache tested and it still wasn’t > working. I left it for about an hour, came back and did another ‘id username > | grep tech’ and the group showed up. > > There’s some strange disconnect where it forgets the groups, doesn’t bother > to look them up, then does again. Is there some other cache that needs to be > cleared that doesn’t get populated often? > > > > > On Apr 24, 2018, at 9:35 AM, Max DiOrio <[email protected]> wrote: > > > > I did upgrade to 1.16.0 on one server, restarted the service, invalidated > > the sssd cache (sss_cache -E) and did an 'id username | grep tech' and the > > group is still missing altogether. I thought it might be a token size > > issue, but it shouldn’t be, unless sssd doesn’t come close to handling the > > 48000 byte max tokens Windows does. > > > > Token Details for user > > ********************************** > > User's domain is INTERNAL. > > Total estimated token size is 5984. > > For access to DCs and delegatable resources the total estimated token > > delegation size is 11968. > > Effective MaxTokenSize value is: 48000 > > Problem not detected. > > > > *Token Details for user* > > There are 191 groups in the token. > > There are 0 SIDs in the users SIDHistory. > > There are 104 SIDs in the users groups SIDHistory attributes. > > There are 104 total SIDHistories for user and groups user is a member of. > > 77 are domain global scope security groups. > > 0 are domain local security groups. > > 1 are universal security groups inside of the users domain. > > 0 are universal security groups outside of the users domain. > > > > > > > > > On Apr 24, 2018, at 7:39 AM, Sumit Bose <[email protected] > > > <mailto:[email protected]>> wrote: > > > > > > On Tue, Apr 24, 2018 at 11:20:36AM +0000, Joakim Tjernlund wrote: > > > > On Tue, 2018-04-24 at 12:52 +0200, Sumit Bose wrote: > > > > > > > > > > On Tue, Apr 24, 2018 at 10:33:04AM +0000, Joakim Tjernlund wrote: > > > > > > On Tue, 2018-04-24 at 11:19 +0100, John Hodrien wrote: > > > > > > > CAUTION: This email originated from outside of the organization. > > > > > > > Do not click links or open attachments unless you recognize the > > > > > > > sender and know the content is safe. > > > > > > > > > > > > > > > > > > > > > On Tue, 24 Apr 2018, Joakim Tjernlund wrote: > > > > > > > > > > > > > > > It seems like a missing keytab file prevents any login in a AD > > > > > > > > connected > > > > > > > > sssd. Does it need to be so? > > > > > > > > > > > > > > > > I have a vague memory from the past that a missing/invalid > > > > > > > > keytab file > > > > > > > > only prevented SSO but allowed login using your password ? > > > > > > > > > > > > > > Presumably you can make it work without needing a keytab if you > > > > > > > use ldap as an > > > > > > > auth provider. > > > > > > > > Actually, this might have been the case long ago but cannot say for > > > > sure. > > > > > > > > > > > > > > > > > > If you're using AD, you're using kerberos and ldap. If you're > > > > > > > using kerberos, > > > > > > > you need to be able to validate the KDC. How would you plan on > > > > > > > doing that? > > > > > > > > > > > > I remember being able to login using pw when have a keytab but > > > > > > invalid > > > > > > kvno in the keytab. Is this case any different from not having a > > > > > > keytab at all? > > > > > > > > > > The AD LDAP service requires authentication and by default the keytab > > > > > created while joining the AD domain is used by SSSD's AD provider to > > > > > authenticate against AD to be able to lookup user, groups and other > > > > > data. > > > > > > > > > > For user authentication the keytab is used to validate the Kerberos > > > > > ticket returned by the AD DC. > > > > > > > > > > If SSSD is in offline state only cached data is used, in this case the > > > > > keytab is not needed. > > > > > > > > > > If you add the needed parameters to sssd.conf to use a simple LDAP > > > > > bind > > > > > for authentication and disable ticket validation you do not need a > > > > > valid > > > > > keytab. But I would recommend to just make sure a valid keytab is > > > > > available. > > > > > > > > Yes, but every now and then joining the domain or loosing the keytab > > > > during computer upgrade > > > > happens and then no one can login other than local root and that is > > > > impractical. > > > > Can one combine simple LDAP bind with xxx_provider=ad ? > > > > > > For the id provider you have to specify ldap_default_bind_dn and > > > ldap_default_authtok see man sssd-ldap for details. > > > > > > To disable ticket validation in the auth provider you can set > > > 'krb5_validate = False' see man sssd-krb5 for details. > > > > > > But I still would recommend to use the keytab and make sure it does not > > > get lost :-). To make authentication work setting krb5_validate should > > > be sufficient for user which are already in the cache. > > > > > > bye, > > > Sumit > > > > > > > > > > > > > > Jocke > > > > > > > > > > > > > > HTH > > > > > > > > > > bye, > > > > > Sumit > > > > > > > > > > > > > _______________________________________________ > > > > sssd-users mailing list -- [email protected] > > > > <mailto:[email protected]> > > > > To unsubscribe send an email to [email protected] > > > > <mailto:[email protected]> > > > > > > _______________________________________________ > > > sssd-users mailing list -- [email protected] > > > <mailto:[email protected]> > > > To unsubscribe send an email to [email protected] > > > <mailto:[email protected]> > > _______________________________________________ > sssd-users mailing list -- [email protected] > To unsubscribe send an email to [email protected] -- Simo Sorce Sr. Principal Software Engineer Red Hat, Inc _______________________________________________ sssd-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
