5:16 a.m.
It seems like a missing keytab file prevents any login i 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 ?
Jocke
5:19 a.m.
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.
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?
jh
5:33 a.m.
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.
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?
Jocke
5:52 a.m.
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.
>
> 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.
HTH
bye,
Sumit
>
> Jocke
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
6:20 a.m.
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 ?
Jocke
HTH
bye,
Sumit
6:35 a.m.
On Tue, 24 Apr 2018, Joakim Tjernlund wrote:
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?
How often are you finding you're losing your keytab? If you update a machine,
you shouldn't lose your keytab.
If you reinstall a machine, you should either preserve your keytab, or rejoin
the domain as part of the install.
But for an installed system, I think you quickly reach a point where using
krb5 for NFS/Samba or other services becomes highly desirable, and none of
that flies unless you've got a local keytab.
There are other authentication methods you can use to access a machine
remotely other than as root with a password when SSSD is in an unusable state.
Whether it's possible or not, I'd question whether you really want to go down
that road.
jh
6:39 a.m.
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
> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
8:35 a.m.
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>
10:24 a.m.
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 <mdiorio(a)gmail.com>
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 <sbose(a)redhat.com
<mailto:sbose@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>
8:40 p.m.
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 <mdiorio(a)gmail.com> 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 <sbose(a)redhat.com
<mailto:sbose@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>
_______________________________________________
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
--
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc
2192
days inactive
2193
days old
sssd-users@lists.fedorahosted.org
9 comments
5 participants
participants (5)
-
Joakim Tjernlund -
John Hodrien -
Max DiOrio -
Simo Sorce -
Sumit Bose