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 <sb...@redhat.com> 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 -- sssd-users@lists.fedorahosted.org >> <mailto:sssd-users@lists.fedorahosted.org> >> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org >> <mailto:sssd-users-le...@lists.fedorahosted.org> > _______________________________________________ > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > <mailto:sssd-users@lists.fedorahosted.org> > To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org > <mailto:sssd-users-le...@lists.fedorahosted.org>
_______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
