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 <sbose(a)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(a)lists.fedorahosted.org
<mailto:sssd-users@lists.fedorahosted.org>
> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
<mailto:sssd-users-leave@lists.fedorahosted.org>
_______________________________________________
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
<mailto:sssd-users@lists.fedorahosted.org>
To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
<mailto:sssd-users-leave@lists.fedorahosted.org>