[SSSD-users] Re: Clarification about ldap_sasl_authid string from sssd-ldap man page?

[Spike White]

Thank you for clarifying.

Spike


On Mon, May 20, 2024 at 8:14 AM Tomas Halman  wrote:

> Hi,
>
> There is always confusion when talking about hostnames and FQDN :-)
>
> Here we are talking about a hostname that has a domain part in it - i. e.
> long one. But strictly speaking it is not the same thing as FQDN because
> the machine can have multiple addresses/interfaces and various FQDNs
> associated with them on a DNS server. So we stick to the term `hostname` in
> the man page rather than FQDN.
>
> I think that it is also one of the requirements when enrolling into the
> IPA domain, that the hostname has the domain part and this name can be
> resolved to one of host's addresses.
>
>
> HTH
> Tom
>
> On Fri, May 17, 2024 at 10:37 PM Spike White 
> wrote:
>
>> sssd professionals,
>>
>> When the sssd-ldap man page refers to "hostname", is it referring to the
>> short name or the FQDN?
>> I know nebiosname is short, with a '$' on the end.
>>
>> From sssd-ldap man page:
>>
>>ldap_sasl_authid (string)
>>Specify the SASL authorization id to use. When
>> GSSAPI/GSS-SPNEGO are used, this represents the Kerberos principal used for
>> authentication to
>>the directory. This option can either contain the full
>> principal (for example host/myh...@example.com) or just the principal
>> name (for
>>example host/myhost). By default, the value is not set and the
>> following principals are used:
>>
>>hostname@REALM
>>netbiosname$@REALM
>>host/hostname@REALM
>>*$@REALM
>>host/*@REALM
>>host/*
>>
>>If none of them are found, the first principal in keytab is
>> returned.
>>
>>Default: host/hostname@REALM
>>
>> Spike White
>> --
>> ___
>> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
>> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
>> Fedora Code of Conduct:
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
>> Do not reply to spam, report it:
>> https://pagure.io/fedora-infrastructure/new_issue
>>
>
>
> --
> Tomáš Halman
>
> --
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
--
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[SSSD-users] Clarification about ldap_sasl_authid string from sssd-ldap man page?

[Spike White]

sssd professionals,

When the sssd-ldap man page refers to "hostname", is it referring to the
short name or the FQDN?
I know nebiosname is short, with a '$' on the end.

>From sssd-ldap man page:

   ldap_sasl_authid (string)
   Specify the SASL authorization id to use. When GSSAPI/GSS-SPNEGO
are used, this represents the Kerberos principal used for authentication to
   the directory. This option can either contain the full principal
(for example host/myh...@example.com) or just the principal name (for
   example host/myhost). By default, the value is not set and the
following principals are used:

   hostname@REALM
   netbiosname$@REALM
   host/hostname@REALM
   *$@REALM
   host/*@REALM
   host/*

   If none of them are found, the first principal in keytab is
returned.

   Default: host/hostname@REALM

Spike White
--
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[SSSD-users] Re: sssd failing due to self-signed certificates--but that's not what openssl says

[Spike White]

Are you connecting an AD server or an LDAP server?  If the former is
ad_use_ldaps set to true or false?

Spike

On Wed, Feb 21, 2024 at 11:46 AM Johnnie W Adams  wrote:

> Hi, folks,
>
>
>  So I've got a very puzzling situation. Just today, when I look at
> sssd with systemctl status, I get this error: *Could not start TLS
> encryption. error:1416F086:SSL
> routines:tls_process_server_certificate:certificate verify failed (self
> signed certificate in certificate chain)*
>
>  However, when I run openssl s_client -showcerts -connect
> ldap.example.com:636, it shows a completely valid, not-self-signed
> certificate chain.
>
>  This is happening on RHEL7 through 9. I'm puzzled. Anyone else have
> ideas?
>
> Thanks,
>
>  John A
>
> --
> John Adams
> Senior Linux/Middleware Administrator  | Information Technology Services
> +1-501-916-3010 | jxad...@ualr.edu | http://ualr.edu/itservices
> *UA Little Rock*
>
> Reminder:  IT Services will never ask for your password over the phone or
> in an email. Always be suspicious of requests for personal information that
> come via email, even from known contacts.  For more information or to
> report suspicious email, visit IT Security
> .
> --
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
--
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[SSSD-users] Re: Undocumented ldap_sasl_authid feature causing sssd to succeed?

[Spike White]

Sumit,

Thank you so much for responding.  I believe you're saying this.

You tested this by putting in:

ldap_sasl_authid = e...@fwef.ed



on your test server called “client.samba.test”.It failed to find
“e...@fwef.ed” or “host/e...@fwef.ed” in /etc/krb5.keytab file, so it tried
(in order):



>hostname@REALM
>netbiosname$@REALM
>host/hostname@REALM
   ...



It found host/client.samba.t...@samba.test in /etc/krb5.keytab file and it
used that.


That's why you see in the sssd logs these lines:


[sdap_set_sasl_options] (0x0080): Configured SASL auth ID not found in
keytab. Requested ewfk, found host/client.samba.test
[sdap_set_sasl_options] (0x0080): Configured SASL realm not found in
keytab. Requested FWEF.ED, found SAMBA.TEST

Have I stated that all correctly?

Spike

On Wed, Jan 31, 2024 at 8:01 AM Sumit Bose  wrote:

> Am Mon, Jan 22, 2024 at 03:08:30PM -0600 schrieb Spike White:
> > All,
> >
> >
> > We’re auditing for successful & healthy AD join of our 32K+ servers.  Our
> > check is basically this:
> >
> >
> > AUTHID=$(grep ldap_sasl_authid /etc/sssd/sssd.conf | awk '{print $3}')
> >
> > [[ $AUTHID != host/* ]]  && AUTHID=host/$AUTHID
> >
> > kinit -k $AUTHID
> >
> >
> >
> > i.e., kinit with the same service principal that sssd uses (prepending
> the
> > "host/" prefix if not already existing).
> >
> >
> > We’ve identified about 200 “failing” servers, but upon closer inspection
> > only about 30 of them are really failing.
> >
> >
> > The other 170 are failing the above naïve check, but sssd is properly
> > working.  Here’s an example:
> >
> >
> > Server ddlplhdc4036.us.company.com has
> >
> >
> > ldap_sasl_authid = ddlplhdc4034.us.company@amer.company.com
> > <.us.dell@amer.dell.com>
> >
> >
> > but in /etc/krb5.keytab file ii has:
> >
> >
> > host/ddlplhdc4036.us.company@amer.company.com
> > 
> >
> >
> > If you look at the sssd-ldap man page, it states:
> >
> >ldap_sasl_authid (string)
> >Specify the SASL authorization id to use. When
> GSSAPI/GSS-SPNEGO
> > are used, this represents the Kerberos principal used for authentication
> to
> > the directory. This option can
> >either contain the full principal (for example host/
> > myh...@example.com) or just the principal name (for example
> host/myhost). By
> > default, the value is not set and the
> >following principals are used:
> >
> >hostname@REALM
> >netbiosname$@REALM
> >host/hostname@REALM
> >*$@REALM
> >host/*@REALM
> >host/*
> >
> >If none of them are found, the first principal in keytab is
> > returned.
> >
> >Default: host/hostname@REALM
> >
> > If we have ldap_sasl_authid defined in /etc/sssd/sssd.conf file and it
> > fails, does it try those other permutations above?
> >
> > I'm guessing so, based on these 170 servers that are allegedly failing,
> but
> > sssd is truly succeeding.
>
> Hi,
>
> yes, SSSD is trying best-effort here and ignores the principal from the
> ldap_sasl_authid if it is not in the keytab. You should see messages
> like:
>
> [sdap_set_sasl_options] (0x0080): Configured SASL auth ID not found in
> keytab. Requested ewfk, found host/client.samba.test
> [sdap_set_sasl_options] (0x0080): Configured SASL realm not found in
> keytab. Requested FWEF.ED, found SAMBA.TEST
>
> in the SSSD backend logs if this happens.
>
> HTH
>
> bye,
> Sumit
>
> >
> > Spike White
>
> > --
> > ___
> > sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> > To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> > Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> > Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
> --
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct:
> 

[SSSD-users] Undocumented ldap_sasl_authid feature causing sssd to succeed?

[Spike White]

All,


We’re auditing for successful & healthy AD join of our 32K+ servers.  Our
check is basically this:


AUTHID=$(grep ldap_sasl_authid /etc/sssd/sssd.conf | awk '{print $3}')

[[ $AUTHID != host/* ]]  && AUTHID=host/$AUTHID

kinit -k $AUTHID



i.e., kinit with the same service principal that sssd uses (prepending the
"host/" prefix if not already existing).


We’ve identified about 200 “failing” servers, but upon closer inspection
only about 30 of them are really failing.


The other 170 are failing the above naïve check, but sssd is properly
working.  Here’s an example:


Server ddlplhdc4036.us.company.com has


ldap_sasl_authid = ddlplhdc4034.us.company@amer.company.com
<.us.dell@amer.dell.com>


but in /etc/krb5.keytab file ii has:


host/ddlplhdc4036.us.company@amer.company.com



If you look at the sssd-ldap man page, it states:

   ldap_sasl_authid (string)
   Specify the SASL authorization id to use. When GSSAPI/GSS-SPNEGO
are used, this represents the Kerberos principal used for authentication to
the directory. This option can
   either contain the full principal (for example host/
myh...@example.com) or just the principal name (for example host/myhost). By
default, the value is not set and the
   following principals are used:

   hostname@REALM
   netbiosname$@REALM
   host/hostname@REALM
   *$@REALM
   host/*@REALM
   host/*

   If none of them are found, the first principal in keytab is
returned.

   Default: host/hostname@REALM

If we have ldap_sasl_authid defined in /etc/sssd/sssd.conf file and it
fails, does it try those other permutations above?

I'm guessing so, based on these 170 servers that are allegedly failing, but
sssd is truly succeeding.

Spike White
--
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[SSSD-users] Re: SSSD LDAP provider fails to fetch nested groups (groups member of groups)

[Spike White]

Finn,

with LDAP, recursively searching for all nested subgroups, sub-sub-groups,
etc. -- that can be an expensive operation.

 the default ldap_group_nesting_level is 2.  You might try to set that to
some larger number (like 5 or 6) to see if it makes any difference.

If you're connecting to AD, there's an optimization that's not expensive
(to clients doing LDAP searches) called 'tokengroups'.

Spike White


On Thu, Jan 18, 2024 at 5:28 PM Finn Fysj  wrote:

> I'm experiencing problems on my RHEL 9 instance when looking up members of
> group using
> getent group . I can only get users which has direct access to
> a group,
> and no the "user groups" part of the group.
>
>
>
> My sssd.conf:
> [domain/]
> id_provider = ldap
> auth_provider = ldap
> chpass_provider = ldap
> sudo_provider = ldap
>
> ldap_uri = ldaps:/ipa.example.com
> ldap_schema = rfc2307bis
>
> ldap_search_base = dc=example,dc=com
> ldap_sudo_search_base = ou=sudoers,dc=example,dc=com
> ldap_user_search_base = cn=users,cn=accounts,dc=example,dc=com
> ldap_group_search_base = cn=groups,cn=accounts,dc=example,dc=com
>
> [sssd]
> services = nss, pam, sudo
> domains = default
>
> [nss]
> homedir_substring = /home
>
> [pam]
>
> [sudo]
> --
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
--
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[SSSD-users] Re: Does sssd (on RHEL8 and RHEL9) RPM have an implied dependency on sssd-kcm RPM?

[Spike White]

Alejandro,

I don't have any failing servers right in front of me now, so this is from
memory.  (all reported servers fixed).

> During the upgrade KCM was not updated. How was the upgrade done? Just a
simple `dnf upgrade` or something more complex?

Yes, dnf update of all outstanding RPMs.

> There is a /usr/libexec/sssd/sssd_kcm file that belongs to no RPM. Are
you sure there were no errors during the update? No KCM RPM installed, even
the previous version?

Prior to latest round of patching, app teams were not complaining about any
sssd login issues.  After patching, they were.

> Once the RPM is manually installed, KCM successfully starts. Does `kinit`
still fail at this point? If KCM fails to start, it is normal that `kinit`
also fails if it is configured to use KCM.

Once sssd-kcm manually installed, kinit works.  there's a file
/etc/krb5.conf.d/kcm_default_ccache with this content:

# This file should normally be installed by your distribution into a
# directory that is included from the Kerberos configuration file
(/etc/krb5.conf)
# On Fedora/RHEL/CentOS, this is /etc/krb5.conf.d/
#
# To enable the KCM credential cache enable the KCM socket and the service:
#   systemctl enable sssd-kcm.socket
#   systemctl start sssd-kcm.socket
#
# To disable the KCM credential cache, comment out the following lines.

[libdefaults]
default_ccache_name = KCM:


So with the sssd-kcm RPM missing, kinit -k fails.  I can make it succeed
(even with sssd-kcm service not running) via:

# export KRB5CCNAME="FILE:/tmp/krb5cc_0"

# kinit -k


This is overriding the setting in /etc/krb5.conf.d/kcm_default_ccache
above.

BTW, /etc/krb5.conf.d/kcm_default_ccache file comes from sssd-kcm RPM so
that tells me that certainly at one time (prior to patching) the sssd-kcm
RPM was on the server.

Spike


On Thu, Jan 11, 2024 at 3:27 AM Alejandro Lopez  wrote:

> Hi Spike,
>
> During the upgrade KCM was not updated. How was the upgrade done? Just a
> simple `dnf upgrade` or something more complex?
>
> There is a /usr/libexec/sssd/sssd_kcm file that belongs to no RPM. Are you
> sure there were no errors during the update? No KCM RPM installed, even the
> previous version?
>
> Once the RPM is manually installed, KCM successfully starts. Does `kinit`
> still fail at this point? If KCM fails to start, it is normal that `kinit`
> also fails if it is configured to use KCM.
>
> Alejandro
>
> On Wed, Jan 10, 2024 at 11:02 PM Spike White 
> wrote:
>
>> All,
>>
>> Is there a packaging problem on the latest version of RHEL8 sssd?
>>
>> On several of our RHEL8 servers during the last update cycle, sssd logins
>> start failing.  It appears to be when upgrading to version
>> sssd-2.9.1-4.0.1.el8_9.x86_64.
>>
>> Upon deep dive, it turns out the sssd-kcm RPM is missing.
>>
>> The sssd-kcm service fails to start, complaining about missing symbols in
>> /usr/libexec/sssd_kcm file.
>>
>> Sure enough, there is a problem with that file:
>>
>> [root@mftplat1wplp105 ~]# rpm -qf /usr/libexec/sssd/sssd_kcm
>>
>> file /usr/libexec/sssd/sssd_kcm is not owned by any package
>>
>>
>> Once the sssd-kcm RPM is installed,  then this looks normal:
>>
>>
>> [root@mftplat1wplp105 ~]# rpm -qf /usr/libexec/sssd/sssd_kcm
>>
>> sssd-kcm-2.9.1-4.0.1.el8_9.x86_64
>>
>>
>> Then sssd-kcm service will restart fine.  and then sssd logins again work
>> fine.
>>
>>
>> Also, it appears that a yum downgrade of sssd seems to work too --
>> presumably because this downgrade also triggers an install of sssd-kcm RPM.
>>
>>
>> I see that the sssd RPM has no direct explicit RPM dependency on
>> sssd-kcm.  But is there some indirect or implied dependency that was missed
>> on this latest packaging for sssd-2.9.1-4.0.1.el8_9.x86_64?
>>
>>
>> We've run sssd for years and never had significant sssd-kcm problems
>> until last month.
>>
>>
>> BTW, another clue that it was KCM is that 'kinit -k' fails with error:
>>
>>
>> # knit -k
>>
>> Cannot update default cache
>>
>>
>> But if you tell it to store creds under /tmp, it works:
>>
>>
>> # export KRB5CCNAME="FILE:/tmp/krb5cc_0"
>>
>> # kinit -k
>>
>>
>> Spike
>>
>> --
>> ___
>> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
>> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
>> Fedora Code of Conduct:
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Ar

[SSSD-users] Does sssd (on RHEL8 and RHEL9) RPM have an implied dependency on sssd-kcm RPM?

[Spike White]

All,

Is there a packaging problem on the latest version of RHEL8 sssd?

On several of our RHEL8 servers during the last update cycle, sssd logins
start failing.  It appears to be when upgrading to version
sssd-2.9.1-4.0.1.el8_9.x86_64.

Upon deep dive, it turns out the sssd-kcm RPM is missing.

The sssd-kcm service fails to start, complaining about missing symbols in
/usr/libexec/sssd_kcm file.

Sure enough, there is a problem with that file:

[root@mftplat1wplp105 ~]# rpm -qf /usr/libexec/sssd/sssd_kcm

file /usr/libexec/sssd/sssd_kcm is not owned by any package


Once the sssd-kcm RPM is installed,  then this looks normal:


[root@mftplat1wplp105 ~]# rpm -qf /usr/libexec/sssd/sssd_kcm

sssd-kcm-2.9.1-4.0.1.el8_9.x86_64


Then sssd-kcm service will restart fine.  and then sssd logins again work
fine.


Also, it appears that a yum downgrade of sssd seems to work too --
presumably because this downgrade also triggers an install of sssd-kcm RPM.


I see that the sssd RPM has no direct explicit RPM dependency on sssd-kcm.
But is there some indirect or implied dependency that was missed on this
latest packaging for sssd-2.9.1-4.0.1.el8_9.x86_64?


We've run sssd for years and never had significant sssd-kcm problems until
last month.


BTW, another clue that it was KCM is that 'kinit -k' fails with error:


# knit -k

Cannot update default cache


But if you tell it to store creds under /tmp, it works:


# export KRB5CCNAME="FILE:/tmp/krb5cc_0"

# kinit -k


Spike
--
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[SSSD-users] Re: Kerberos authentication only works with aes256-cts-hmac-sha1-96 for Windows 10 joined to RHEL IDM

[Spike White]

I don't understand why that full list of permitted_enctypes is a problem,
while your abbreviated list is not.

I do know that windows AD controllers seem to favor aes256-cts-hmac-sha1-96
and aes128-cts-hmac-sha1-96.   For most AD domains, DES was deprecated long
ago and as of last year, I think most customers are trying to deprecate RC4
as well.

Our AD DCs are W2016, 2020 and (formerly) W2012.  I have no experience with
RedHat IDM and no experience with Win10 servers (I thought Win 10 were all
desktops and integrated natively with AD).

But I do know that the krb5-libs will attempt to negotiate the encryption
types in the order they are listed in your permitted_enctypes line.  So
change your line to do aes256-cts-hmac-sha1-96 first.  something like:

permitted_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
aes256-cts-hmac-sha384-192 aes128-cts-hmac-sha256-128 camellia256-cts-cmac
camellia128-cts-cmac

This will at least give you another data point.  to my mind, it should
proceed like this:

Attempt aes256-cts-hmac-sha384-192, fail,
Attempt aes128-cts-hmac-sha256-128, fail.
Attempt  aes256-cts-hmac-sha1-96, succeed.


Spike

On Thu, Nov 30, 2023 at 11:23 PM Deepak Ramanath 
wrote:

> I have a Windows 10 server joined to a RedHat IDM (RHEL 8.9) realm using
> Kerberos. When a user tries to authenticate on a Windows 10 server, the
> following error is shown
>
> "We cannot sign you in with this credential because your domain isn't
> available"
>
> On the IDM, looking at the `/var/log/krb5kdc.log`, I see the following...
>
> Nov 30 23:08:17 idm.server.local krb5kdc[11775](info): AS_REQ (6 etypes
> {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17),
> DEPRECATED:arcfour-hmac(23), DEPRECATED:arcfour-hmac-exp(24),
> UNSUPPORTED:(-135), UNSUPPORTED:des-cbc-md5(3)}) 192.168.124.55:
> NEEDED_PREAUTH: win.user@server.local for krbtgt/server.local@server.local,
> Additional pre-authentication required
> Nov 30 23:08:17 idm.server.local krb5kdc[11774](info): AS_REQ (6 etypes
> {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17),
> DEPRECATED:arcfour-hmac(23), DEPRECATED:arcfour-hmac-exp(24),
> UNSUPPORTED:(-135), UNSUPPORTED:des-cbc-md5(3)}) 192.168.124.55: ISSUE:
> authtime 1701385697, etypes {rep=aes256-cts-hmac-sha1-96(18),
> tkt=aes256-cts-hmac-sha384-192(20), ses=aes256-cts-hmac-sha1-96(18)},
> win.user@server.local for krbtgt/server.local@server.local
> Nov 30 23:08:17 idm.server.local krb5kdc[11775](info): TGS_REQ (5 etypes
> {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17),
> DEPRECATED:arcfour-hmac(23), DEPRECATED:arcfour-hmac-exp(24),
> UNSUPPORTED:(-135)}) 192.168.124.55: ISSUE: authtime 1701385697, etypes
> {rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha1-96(18),
> ses=aes256-cts-hmac-sha1-96(18)}, win.user@server.local for
> host/win-server.server.local@server.local
>
> In the `/etc/crypto-policies/back-ends/krb5.config`, `libdefaults` has
> been set to
>
> [libdefaults]
> permitted_enctypes = aes256-cts-hmac-sha384-192 aes128-cts-hmac-sha256-128
> aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 camellia256-cts-cmac
> camellia128-cts-cmac
>
> Interestingly, if all encryption types are removed except
> aes256-cts-hmac-sha1-96 from the permitted_enctypes, the authentication on
> Windows 10 is successful.
>
> Any idea why only setting to aes256-cts-hmac-sha1-96 works while a list of
> supported methods including aes256-cts-hmac-sha1-96 does not?
> --
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
--
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[SSSD-users] Re: Is there anything in the sssd RHEL server OS settings that performs LDAP binds or connections to AD every 30 mins?

[Spike White]

So Trellix did not accept this as a bug in their healthcheck script.  We
put in a RFE with tem to do this healthcheck invocation  using setpriv or
su -c.  Which doesn't trigger the LDAP queries.

Now we have an open case with RH Tech Support on this.  Basically, when
sudo is invoked as root and we have early in the /etc/sudoers file:

rootALL=(ALL)   ALL

and then later on in /etc/sudoers file we have:

## Read drop-in files from /etc/sudoers.
#includedir /etc/sudoers.d

then sudo should not be making  group membership queries to enumerate all
the various AD groups in /etc/sudoers.d/*  files.  which is triggering
multiple LDAP queries on thousands of servers -- all on the hour and
half-hour.

Spike

On Fri, Oct 6, 2023 at 12:16 PM Larkin, Patrick 
wrote:

> On 10/6/23, 11:52, "Sam Morris"  wrote:
> __
> On 04/10/2023 17:02, Spike White wrote:
> > We see in other places in this McAfee script that they run this command
> > using 'su' instead of 'sudo'.
> >
> > su -s /bin/sh -c "LD_LIBRARY_PATH=...  ${PROGROOT}/bin/macmnsvc
> > status" mfe
> …
> > Anyway, it's McAfee's problem to fix now.  We'll report it and I'm sure
> > they'll figure out a solution.
>
> If they are root and want to drop privileges then they would be better
> served by runuser or setpriv. …
>
>
>
> …or start out as non-root user to begin with…
>
> (It’s a peeve of mine when security companies don’t follow best practice
> of elevating only if absolutely necessary.)
>
>
>
> --
>
> Pat Larkin | Manager – LinuxIMO
>
> Sabre  TEO | Texas USA
>
>
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[SSSD-users] Re: Is there anything in the sssd RHEL server OS settings that performs LDAP binds or connections to AD every 30 mins?

[Spike White]

This gave us enough insight to track down the culprit.

BTW, it seems that RHEL7 sssd_amer.corp.com.log does not give sufficient
detail to tell us it's sssd.nss service.  But RHEL8 or RHEL9 version of
sssd gives us this detail.

So we find consistently, it's sudo.  Example:

(2023-10-04  9:00:01): [nss] [get_client_cred] (0x4000): Client
[0x559189778c70][23] creds: euid[0] egid[0] pid[3587183] cmd_line['sudo'].
(2023-10-04  9:00:01): [nss] [setup_client_idle_timer] (0x4000): Idle timer
re-set for client [0x559189778c70][23]
(2023-10-04  9:00:01): [nss] [accept_fd_handler] (0x0400): [CID#1754] Client
[cmd sudo][uid 0][0x559189778c70][23] connected!

Suspecting a cron job somewhere, we were able to find this

# cat /etc/cron.d/ma_healthcheck
0,30 * * * * root /opt/McAfee/agent/scripts/ma checkhealth >/dev/null
2>/dev/null

This is a cron job that comes as part of the McAfee agent (now called
Trellix agent).  Sure enough, inside that script they are doing this:

 sudo -u mfe /bin/sh -c
"LD_LIBRARY_PATH=/opt/McAfee/agent/lib/lib64:/opt/McAfee/agent/lib/lib64/tools:/opt/McAfee/agent/lib/lib64/rsdk:/opt/McAfee/agent/lib:/opt/McAfee/agent/lib/tools:/opt/McAfee/agent/lib/rsdk:$LD_LIBRARY_PATH
${PROGROOT}/bin/macmnsvc status" > /dev/null 2>&1

Where 'mfe' is a local account that gets created as part of this Trellix
agent install.

Apparently, what sudo does is enumerate every group it finds in
/etc/sudoers.d/*  to see if that particular user is a member of that group
and has that associated sudo privilege.  On a particular server we might
have 7 - 10 privileged groups.  For monitoring support, backup support.
DBAs, etc.

For example, /etc/sudoers.d/puppet_client file might look like:

# Allows puppet users to do a puppet agent run.
Cmnd_Alias  PUPPET_APP_TEAMS =  /usr/local/bin/puppet agent -t,
\
/usr/local/bin/puppet agent -t
--noop

%pptuserpac  ALL=NOPASSWD: PUPPET_APP_TEAMS


Apparently, sudo enumerates this pptuserpac AD group to see if mfe is a
member, to see if that account has sudo privs to perform this operation.
(Of course, local account mfe is not a member of any AD group -- but sudo
doesn't know that.)

Because the sssd cache times out and because McAfee has set up all its
installs to run on the hour and half-hour, that's a thundering herd
problem.  We could increase the sssd cache timeout, but that's just
delaying the thundering herd.  Say we set the cache expiration to 2 1/2
hrs.  Then on the 3rd hr, it'd still be a thundering herd.

We see in other places in this McAfee script that they run this command
using 'su' instead of 'sudo'.

su -s /bin/sh -c "LD_LIBRARY_PATH=...  ${PROGROOT}/bin/macmnsvc status" mfe


Running this command via 'su' instead of 'sudo' would not trigger this
thundering herd.  (We have verified that.)  Alternatively, randomizing
their healthcheck execution times would avoid this thundering herd problem.

Anyway, it's McAfee's problem to fix now.  We'll report it and I'm sure
they'll figure out a solution.

Spike White






On Wed, Oct 4, 2023 at 4:45 AM Alexey Tikhonov  wrote:

>
>
> On Wed, Oct 4, 2023 at 11:40 AM Alexey Tikhonov 
> wrote:
>
>>
>>
>> On Tue, Oct 3, 2023 at 11:22 PM Spike White 
>> wrote:
>>
>>> Alexey,
>>>
>>> Yes I see that now.  That every time it starts a new LDAP connection, it
>>> starts by querying rootDSE.  So I have to look further in the logs.
>>>
>>> I think I have discerned a pattern.  It appears that on each hour and
>>> half-hour, it's querying the members of the simple_allow_groups line.
>>>
>>
>> A cron job run under a corresponding user?
>>
>> In the domain log, next line after "Got request for" there should be line
>> like
>> ```
>> DP Request [Account #2]: REQ_TRACE: New request. [sssd.nss CID #1]
>> ```
>>   --  this tells you what service ('sssd_nss' in this case) requested
>> this lookup and what is request ID in its logs ('#1' in this case).
>>
>> Next you can grep sssd_nss.log to figure out who app triggered this:
>> ```
>> (2023-04-14 14:02:08): [nss] [get_client_cred] (0x4000): Client
>> [0x55eb3ac27760][27] creds: euid[0] egid[0] pid[181089] cmd_line['id'].
>> (2023-04-14 14:02:08): [nss] [setup_client_idle_timer] (0x4000): Idle
>> timer re-set for client [0x55eb3ac27760][27]
>> (2023-04-14 14:02:08): [nss] [accept_fd_handler] (0x0400): [CID#1] Client
>> [cmd id][uid 0][0x55eb3ac27760][27] connected!
>> ```
>>   --  'id' in this case.
>>
>
> You could also give a try `sssctl analyze request list` and `sssctl
> analyze --logdir . request show ...`
>
>
>
>>
>>
>>
>>>   I have examined this on 5 different servers in different
&g

[SSSD-users] Re: Is there anything in the sssd RHEL server OS settings that performs LDAP binds or connections to AD every 30 mins?

[Spike White]

 request for [0x2][BE_REQ_GROUP][name=
apacstorageadm...@amer.corp.com]
(2023-10-03 12:41:16): [be[amer.corp.com]] [dp_get_account_info_send]
(0x0200): Got request for [0x2][BE_REQ_GROUP][name=
apacstorageadm...@emea.corp.com]
...
(2023-10-03 12:49:01): [be[amer.corp.com]] [dp_get_account_info_send]
(0x0200): Got request for [0x2][BE_REQ_GROUP][name=ora...@amer.corp.com]
(2023-10-03 12:49:01): [be[amer.corp.com]] [dp_get_account_info_send]
(0x0200): Got request for [0x2][BE_REQ_GROUP][name=ora...@emea.corp.com]
(2023-10-03 12:49:01): [be[amer.corp.com]] [dp_get_account_info_send]
(0x0200): Got request for [0x2][BE_REQ_GROUP][name=ora...@apac.corp.com]
(2023-10-03 12:49:01): [be[amer.corp.com]] [dp_get_account_info_send]
(0x0200): Got request for [0x2][BE_REQ_GROUP][name=ora...@japn.corp.com]
(2023-10-03 12:49:01): [be[amer.corp.com]] [dp_get_account_info_send]
(0x0200): Got request for [0x2][BE_REQ_GROUP][name=ora...@corp.com]
...
(2023-10-03 13:00:01): [be[amer.corp.com]] [dp_get_account_info_send]
(0x0200): Got request for [0x2][BE_REQ_GROUP][name=
pptadmins...@amer.corp.com]
(2023-10-03 13:00:01): [be[amer.corp.com]] [dp_get_account_info_send]
(0x0200): Got request for [0x2][BE_REQ_GROUP][name=
unv_svcgrid_lo...@amer.corp.com]
(2023-10-03 13:00:01): [be[amer.corp.com]] [dp_get_account_info_send]
(0x0200): Got request for [0x2][BE_REQ_GROUP][name=
gbl_storage_adm...@amer.corp.com]
...
(2023-10-03 13:26:18): [be[amer.corp.com]] [dp_get_account_info_send]
(0x0200): Got request for [0x2][BE_REQ_GROUP][name=
zabbix-supp...@amer.corp.com]
(2023-10-03 13:26:18): [be[amer.corp.com]] [dp_get_account_info_send]
(0x0200): Got request for [0x2][BE_REQ_GROUP][name=
emeastorageadm...@amer.corp.com]
...
(2023-10-03 13:30:02): [be[amer.corp.com]] [dp_get_account_info_send]
(0x0200): Got request for [0x2][BE_REQ_GROUP][name=
apaclinux...@amer.corp.com]
(2023-10-03 13:30:02): [be[amer.corp.com]] [dp_get_account_info_send]
(0x0200): Got request for [0x2][BE_REQ_GROUP][name=
apaclinux...@emea.corp.com]
(2023-10-03 13:30:02): [be[amer.corp.com]] [dp_get_account_info_send]
(0x0200): Got request for [0x2][BE_REQ_GROUP][name=
apaclinux...@amer.corp.com]
(2023-10-03 13:30:02): [be[amer.corp.com]] [dp_get_account_info_send]
(0x0200): Got request for [0x2][BE_REQ_GROUP][name=
apaclinux...@emea.corp.com]
...
and it continues on, each and every half-hour.

So it appears that something is waking up every half-hour and validating
memberships in the simple_allow_groups.  I don't claim that's all that's
being performed on this half-hour wake-up, but it is clear this is occuring.

Different servers have different simple_allow_group memberships;  it's
always the memberships for that specific server that's being queried.

Spike


On Mon, Oct 2, 2023 at 12:23 PM Alexey Tikhonov  wrote:

> On Mon, Oct 2, 2023 at 7:01 PM Spike White  wrote:
> >
> > So the idea to turn on debug_level = 9 on the client and view the logs
> was inspired.  We turned on debug level 9 on 4 clients;
> >
> > 2 in the list (that we got from AD team of servers in that AMERAustin
> site hitting the non-AMER Austin AD DCs).
> > 2 not in their list.  (1 in another AMER site).
> >
> > Consistently, we see them querying the rootDSE for all these domains on
> the hour and the half-hour.  Querying the local AMER rootDSE in Austin is
> not a problem;  they have beaucoup AD DCs in Austin.  Querying the other
> domains' rootDSEs in Austin is a problem;  they typically only have 2 AD
> DCs from each region.
> >
> > Here’s an example from the client logs.  First client:
> >
> >
> >
> > (2023-10-03  0:30:06): [be[amer.corp.com]]
> [sdap_ldap_connect_callback_add] (0x1000): New LDAP connection to [ldap://
> ausdc16corp05.corp.com:389/??base] with fd [30].
> >
> > (2023-10-03  0:30:06): [be[amer.corp.com]] [sdap_get_rootdse_send]
> (0x4000): Getting rootdse
> >
> > …
> >
> > (2023-10-03  0:41:18): [be[amer.corp.com]]
> [sdap_ldap_connect_callback_add] (0x1000): New LDAP connection to [ldap://
> AUSDC16ROAMER01.amer.corp.com:389/??base] with fd [20].
> >
> > (2023-10-03  0:41:18): [be[amer.corp.com]] [sdap_get_rootdse_send]
> (0x4000): Getting rootdse
> >
> >
> >
> > Another client:
> >
> >
> >
> > (2023-10-02 11:30:02): [be[amer.corp.com]]
> [sdap_ldap_connect_callback_add] (0x4000): [RID#48] New connection to
> [ldap://ausdc16amer33.amer.corp.com:3268/??base] with fd [25]
> >
> > (2023-10-02 11:30:02): [be[amer.corp.com]] [sdap_get_rootdse_send]
> (0x4000): [RID#48] Getting rootdse
> >
>
> What goes next for this 'RID#48', after 'rootdse' is read?
>
> SSSD doesn't query 'rootdse' on its own. It is being read (as a first
> operation) when a new connection is established.
> You need to see what happens next to figure out *wh

[SSSD-users] Re: Is there anything in the sssd RHEL server OS settings that performs LDAP binds or connections to AD every 30 mins?

[Spike White]

So the idea to turn on debug_level = 9 on the client and view the logs was
inspired.  We turned on debug level 9 on 4 clients;

2 in the list (that we got from AD team of servers in that AMERAustin site
hitting the non-AMER Austin AD DCs).
2 not in their list.  (1 in another AMER site).

Consistently, we see them querying the rootDSE for all these domains on the
hour and the half-hour.  Querying the local AMER rootDSE in Austin is not a
problem;  they have beaucoup AD DCs in Austin.  Querying the other domains'
rootDSEs in Austin is a problem;  they typically only have 2 AD DCs from
each region.

Here’s an example from the client logs.  First client:



(2023-10-03  0:30:06): [be[amer.corp.com]] [sdap_ldap_connect_callback_add]
(0x1000): New LDAP connection to [ldap://ausdc16corp05.corp.com:389/??base]
with fd [30].

(2023-10-03  0:30:06): [be[amer.corp.com]] [sdap_get_rootdse_send]
(0x4000): Getting rootdse

…

(2023-10-03  0:41:18): [be[amer.corp.com]] [sdap_ldap_connect_callback_add]
(0x1000): New LDAP connection to [ldap://
AUSDC16ROAMER01.amer.corp.com:389/??base] with fd [20].

(2023-10-03  0:41:18): [be[amer.corp.com]] [sdap_get_rootdse_send]
(0x4000): Getting rootdse



Another client:



(2023-10-02 11:30:02): [be[amer.corp.com]] [sdap_ldap_connect_callback_add]
(0x4000): [RID#48] New connection to [ldap://
ausdc16amer33.amer.corp.com:3268/??base] with fd [25]

(2023-10-02 11:30:02): [be[amer.corp.com]] [sdap_get_rootdse_send]
(0x4000): [RID#48] Getting rootdse

--

(2023-10-02 11:30:04): [be[amer.corp.com]] [sdap_ldap_connect_callback_add]
(0x4000): [RID#49] New connection to [ldap://
ausdc16emea05.emea.corp.com:389/??base] with fd [26]

(2023-10-02 11:30:04): [be[amer.corp.com]] [sdap_get_rootdse_send]
(0x4000): [RID#49] Getting rootdse

--

(2023-10-02 11:30:05): [be[amer.corp.com]] [sdap_ldap_connect_callback_add]
(0x4000): [RID#50] New connection to [ldap://
ausdc16apac06.apac.corp.com:389/??base] with fd [27]

(2023-10-02 11:30:05): [be[amer.corp.com]] [sdap_get_rootdse_send]
(0x4000): [RID#50] Getting rootdse

--

(2023-10-02 11:30:05): [be[amer.corp.com]] [sdap_ldap_connect_callback_add]
(0x4000): [RID#51] New connection to [ldap://
AUSDC16JAPN02.japn.corp.com:389/??base] with fd [28]

(2023-10-02 11:30:05): [be[amer.corp.com]] [sdap_get_rootdse_send]
(0x4000): [RID#51] Getting rootdse

--

(2023-10-02 11:32:52): [be[amer.corp.com]] [sdap_ldap_connect_callback_add]
(0x4000): [RID#84] New connection to [ldap://
ausdc16emea05.emea.corp.com:389/??base] with fd [26]

(2023-10-02 11:32:52): [be[amer.corp.com]] [sdap_get_rootdse_send]
(0x4000): [RID#84] Getting rootdse

--



BTW, this seems to occurs on both RHEL7 and RHEL8.  (Haven't looked at our
RHEL9 builds yet).   It's occurring on all servers to all rootDSEs, but
only a problem for AMERAustin, since Austin is such a heavily-populated.


These rootDSEs change almost never.  Any way to have it query not as
frequently, or randomize when servers query these rootDSEs.

Spike

On Mon, Oct 2, 2023 at 2:37 AM Alexey Tikhonov  wrote:

> Hi,
>
> On Mon, Oct 2, 2023 at 6:20 AM Spike White  wrote:
>
>> All,
>>
>> Is there anything in sssd's RHEL and RHEL-like Linux server OS settings
>> that perform LDAP binds or connections to AD every 30 minutes?
>>
>> What our AD team is seeing is all of the DCs in our biggest AMER AD site
>> peak with LDAP sessions for about 10 minutes at the top of the hour then
>> again at the bottom of the hour.  No other AD site in the world appears to
>> see this behavior not even other AD sites in this metro area.
>>
>> The reason they noticed is that our non-amer DCs in this biggest AD site
>> hit their 5k LDAP client session limit during those 10 minutes every 30
>> minutes.  Meaning any clients attempting to establish a LDAP session past
>> 5000 are dropped by the DC.  In their research they see thousands LDAP
>> Binds by RHEL Linux servers against two specific non-AMER AD DCs in a short
>> period of time after digging through some LDAP log samples that they pulled
>> from these DCs.
>>
>
> Can they also say what operations are being performed by those connections?
> Or can you check SSSD logs on the client side?
>
> I wonder if this could be `ldap_sudo_smart_refresh_interval`...
>
>
>
>>
>> In this major AD sites, we have dozens and dozens of AMER AD DCs.  So
>> there's enough preferred AD DCs to spread the load.  But typically for the
>> non-AMER regions, the AD team puts 2 of each regions DCs in a site.  For
>> instance, for APAC they would be put two APAC DCs in this AMER major site.
>> Thus all AMER RHEL servers in this site would randomly hit dozens of AMER
>> DCs, but concentrate on these two preferred APAC DCs.  (preferred because
>> they're in this locatiion).
>>
>> I know our older AD integrati

[SSSD-users] Is there anything in the sssd RHEL server OS settings that performs LDAP binds or connections to AD every 30 mins?

[Spike White]

All,

Is there anything in sssd's RHEL and RHEL-like Linux server OS settings
that perform LDAP binds or connections to AD every 30 minutes?

What our AD team is seeing is all of the DCs in our biggest AMER AD site
peak with LDAP sessions for about 10 minutes at the top of the hour then
again at the bottom of the hour.  No other AD site in the world appears to
see this behavior not even other AD sites in this metro area.

The reason they noticed is that our non-amer DCs in this biggest AD site
hit their 5k LDAP client session limit during those 10 minutes every 30
minutes.  Meaning any clients attempting to establish a LDAP session past
5000 are dropped by the DC.  In their research they see thousands LDAP
Binds by RHEL Linux servers against two specific non-AMER AD DCs in a short
period of time after digging through some LDAP log samples that they pulled
from these DCs.

In this major AD sites, we have dozens and dozens of AMER AD DCs.  So
there's enough preferred AD DCs to spread the load.  But typically for the
non-AMER regions, the AD team puts 2 of each regions DCs in a site.  For
instance, for APAC they would be put two APAC DCs in this AMER major site.
Thus all AMER RHEL servers in this site would randomly hit dozens of AMER
DCs, but concentrate on these two preferred APAC DCs.  (preferred because
they're in this locatiion).

I know our older AD integration product used to hit AD every 30 mins to
check GPOs, but we're not implementing GPOs with sssd.

Spike
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[SSSD-users] Re: Doubt about integration between Samba 4 and OpenLDAP

[Spike White]

Redhat also has some good documentation and white papers about "directly
integrating Linux servers to AD".

for instance, Red Hat Enterprise Linux 8 Integrating RHEL systems directly
with Windows Active Directory


You want to skip to the sssd sections.

That is, if you're using a RHEL-flavor Linux.  You didn't specify which
Linux flavor you use.

Spike

On Fri, Aug 11, 2023 at 2:38 AM Alejandro Lopez  wrote:

> Hi Cairo,
>
> Most of the documentation is hosted on https://sssd.io There you will
> find from how to build it, test it and how to collaborate upto how to
> install it, configure it and use it.
>
> HTH,
>
>
>
> On Thu, Aug 10, 2023 at 6:37 PM Cairo Campos 
> wrote:
>
>> I need to continuously synchronize OpenLDAP users and passwords with a
>> Samba 4 DC. However, this doesn't seem to be a good idea due to
>> incompatibilities.
>>
>> Searching the internet, I saw some pages mentioning SSSD, so that I can
>> use OpenLDAP as the basis of authentication for Samba 4.
>>
>> Currently, my production Samba 4 domain uses internal LDAP and DNS.
>>
>> I wanted material or documentation that showed me how to make the switch
>> to using SSSD robustly.
>>
>> Can you help me?
>> ___
>> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
>> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
>> Fedora Code of Conduct:
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
>> Do not reply to spam, report it:
>> https://pagure.io/fedora-infrastructure/new_issue
>>
>
>
> --
> Alejandro
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[SSSD-users] Re: best practice, using machine-account keytab for service SPNs

[Spike White]

Stefan,

>From what I'm reading, it looks like James supplied the answer.  gssproxy.
This URL:
gssproxy/docs/Apache.md at main · gssapi/gssproxy · GitHub
<https://github.com/gssapi/gssproxy/blob/main/docs/Apache.md>

seems to demonstrate how to implement this for Apache webserver.

Spike

On Tue, Jul 25, 2023 at 12:50 AM Stefan Bauer  wrote:

> Thank you Spike and James for your reply. That was quite helpful.
> Yes i currently do have a single host principal in Active-Directory, that
> has numerous servicePrincipalNames:
> HOST/...
> HTTP/
> SQL/...
>
> for al services, running on this specific host.
>
> So it can not be separated as the only credential for that host is the
> machine account itself. Correct?
>
> Is it bad practice to have additional SPNs on the host principal?
>
> How do you associate and rotate your keytabs for services?
>
> Thank you.
>
> Stefan
>
>
>
> Am Mo., 24. Juli 2023 um 23:14 Uhr schrieb Spike White <
> spikewhit...@gmail.com>:
>
>> I know on a former commercial product I used the monthly machine
>> account credential renewal had a "hook" parameter where you could specify
>> an executable script to be called.  It was designed to work with Samba, so
>> that you could write the samba keytab file without Samba needing to access
>> the /etc/krb5.keytab file.
>>
>> Possibly sssd has such a post-rotate hook parameter as well.
>>
>> That worked great for creating a Samba-viewable credentials.
>>
>> However, it sounds like you're defining SPNs as alternate names for the
>> host principal.  I don't see how you could write a HTTP.keytab file or so
>> with entries for HTTP/@   without embedding the
>> credentials for the host principal (under the HTTP/ SPN of course).
>>
>> Spike
>>
>> On Thu, Jul 20, 2023 at 7:38 AM Stefan Bauer  wrote:
>>
>>> Dear Users,
>>>
>>> i really love SSSD and also the auto-renewal of the host-keytab file.
>>>
>>> On many hosts we add the SPNs
>>>
>>> HTTP/
>>> SQL/...
>>>
>>> directly to the machine-account in Active-Directory. This is all fine
>>> and works.
>>>
>>> However i have a bad feeling about letting services read the keytab file
>>> as it gives access to the machine-account.
>>>
>>> Opinions?
>>>
>>> How do you handle service keytabs and it's rotation?
>>>
>>> Thank you.
>>>
>>> Stefan
>>> ___
>>> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
>>> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
>>> Fedora Code of Conduct:
>>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>>> List Archives:
>>> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
>>> Do not reply to spam, report it:
>>> https://pagure.io/fedora-infrastructure/new_issue
>>>
>> ___
>> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
>> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
>> Fedora Code of Conduct:
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
>> Do not reply to spam, report it:
>> https://pagure.io/fedora-infrastructure/new_issue
>>
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[SSSD-users] Re: best practice, using machine-account keytab for service SPNs

[Spike White]

I know on a former commercial product I used the monthly machine
account credential renewal had a "hook" parameter where you could specify
an executable script to be called.  It was designed to work with Samba, so
that you could write the samba keytab file without Samba needing to access
the /etc/krb5.keytab file.

Possibly sssd has such a post-rotate hook parameter as well.

That worked great for creating a Samba-viewable credentials.

However, it sounds like you're defining SPNs as alternate names for the
host principal.  I don't see how you could write a HTTP.keytab file or so
with entries for HTTP/@   without embedding the
credentials for the host principal (under the HTTP/ SPN of course).

Spike

On Thu, Jul 20, 2023 at 7:38 AM Stefan Bauer  wrote:

> Dear Users,
>
> i really love SSSD and also the auto-renewal of the host-keytab file.
>
> On many hosts we add the SPNs
>
> HTTP/
> SQL/...
>
> directly to the machine-account in Active-Directory. This is all fine and
> works.
>
> However i have a bad feeling about letting services read the keytab file
> as it gives access to the machine-account.
>
> Opinions?
>
> How do you handle service keytabs and it's rotation?
>
> Thank you.
>
> Stefan
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[SSSD-users] Re: Is there a way to restrict nss group membership searches for local users to only /etc/group?

[Spike White]

All,

Turns out this particular application connects to kerberos (AD in our env)
directly.  So the errors that show up in their app logs:

ddlflhdm201.us.company.com
WARN June 15, 2023 10:08 AM Groups Potential performance problem:
getGroups(user=hbase) took 58022 milliseconds
ddlflhdm304.us.company.com
WARN June 15, 2023 8:38 AM Groups Potential performance problem:
getGroups(user=mapred) took 39962 milliseconds
ddlplhdm505.us.company.com
WARN June 16, 2023 5:37 AM Groups Potential performance problem:
getGroups(user=hdfs) took 62437 milliseconds.
ddlplhdm305.us.company.com
WARN June 15, 2023 9:36 PM Groups Potential performance problem:
getGroups(user=hdfs) took 58017 milliseconds
ddlplhdm505.us.company.com
WARN June 10, 2023 8:01 AM Groups Potential performance problem:
getGroups(user=yarn) took 58017 milliseconds.

arise from their kerberos client implementation.  Not from sssd.  The
insights about filtering on local users might be useful for the app team
when communicating back with their app vendor.  But ultimately, it's
between this app team and their app vendor.  sssd is in no way involved in
this.

Sorry for the confusion, but the app team was blaming sssd for this
slowness.  Only on exhaustive research did they determine their app is
contacting kerberos directly.

Spike



On Fri, Jun 23, 2023 at 11:07 AM Spike White  wrote:

> Appreciate the insight.  These are production RHEL7 servers, which I see
> are based on sssd-1.16.5-xxx.  As in anything production, I am risk-adverse.
>
> I'll just filter and move on.  Appreciate your help.
>
> Spike
>
> On Fri, Jun 23, 2023 at 9:02 AM Alexey Tikhonov 
> wrote:
>
>> Hi,
>>
>>
>> On Thu, Jun 22, 2023 at 7:52 PM Spike White 
>> wrote:
>>
>>> Alexey,
>>>
>>> Thanks for the suggestion.
>>>
>>> This is a commercial application.  Cloudera's hadoop implementation.  No
>>> idea if they use getgrouplist() under the hood.  I can ask our Cloudera
>>> tech engineer, but I doubt he knows either.
>>>
>>> sssd-ad seems to work pretty well on these servers, except for these
>>> occasional hiccups.  It's over 150 nodes in this hadoop cluster, with only
>>> these occasional hiccups.  Been AD integrated for >1 yr and app team happy
>>> (except for one annoying occasional cross-domain caching issue.)
>>>
>>> In particular, sssd finds its AD site so it's binding to AD DCs local to
>>> this datacenter.  (I checked that first thing.)
>>>
>>> These sporadic hiccups I discuss earlier seem limited to local users
>>> only, looking up their group memberships.
>>>
>>> Would the /etc/nsswitch.conf file syntax be:
>>>
>>>  initgroups:  files [SUCCESS=return] systemd sss
>>>
>>> It seems this would apply for all accounts that were members of local
>>> groups and not just these specific accounts.  (Not sure that's a problem
>>> for this particular app team, but I've seen AD accounts added in /etc/group
>>> as members of local groups.)
>>>
>>> To me, "filter_users" in sssd.conf where I specify the specific accounts
>>> would be safer.
>>>
>>
>> Then filtering sounds as a way to go.
>>
>> If you are courageous you can also try to read SSSD logs to figure out
>> the reason for those "sporadic hiccups".
>> Latest version, around sssd-2.8+, should make it easier to track a
>> specific lookup across a set of logs.
>>
>>
>>
>>>
>>> Spike
>>>
>>> On Thu, Jun 22, 2023 at 10:44 AM Alexey Tikhonov 
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> On Thu, Jun 22, 2023 at 4:47 PM Spike White 
>>>> wrote:
>>>>
>>>>> All,
>>>>>
>>>>> Successful sssd consumer here.
>>>>>
>>>>> Have an app team running Hadoop.  They're getting these performance
>>>>> errors in their app.
>>>>>
>>>>> This is from their app logs.
>>>>>
>>>>> ddlflhdm201.us.company.com
>>>>> WARN June 15, 2023 10:08 AM Groups Potential performance problem:
>>>>> getGroups(user=hbase) took 58022 milliseconds
>>>>>
>>>>
>>>> Does it use `getgrouplist()` under the hood?
>>>>
>>>>
>>>>> ddlflhdm304.us.company.com
>>>>> WARN June 15, 2023 8:38 AM Groups Potential performance problem:
>>>>> getGroups(user=mapred) took 39962 milliseconds
>>>>> ddlplhdm505.us.company.com
>>>>> WARN June 16, 2023 5:37 AM Groups

[SSSD-users] Re: Group caching issue

[Spike White]

Vivianne,

Is this with a simple AD forest (single domain)?

We see lost memberships for accounts sporadically too, but only for
cross-domain accounts.  (another domain, same forest).  And it does not
occur nearly as frequently as you -- might be a single account once every 5
hrs.  Like you, invalidating it clears the error for the account
temporarily.

Are you using tokengroups to ascertain your AD group memberships?
 Initially we weren't but we found tokengroups are dependable and great
performance win (over recursive LDAP searches).

Spike

On Wed, Jun 28, 2023 at 10:14 AM  wrote:

> Hello,
>
> I'm using SSSD with LDAP and NSS enabled for user/group information.
> Originally, groups besides the primary group would be "forgotten"/no longer
> be present. Invalidating the cache with sss_cache -u (username) temporarily
> fixes it, and through testing I found it'd reoccur 5 minutes after forced
> cache invalidation. I realized NIS was mistakenly in our nsswitch.conf and
> removed it, and now it seems to happen about every 45 minutes consistently.
> If you leave the machine for a while and come back then they'll be present
> again. I've set debug_log=10 under all our conf sections but don't really
> see anything relevant in the logs watching them with tail while checking
> group presence. I'm not experienced with SSSD administration, so I'd
> appreciate any tips on triaging this further. Thanks all.
>
> Vivianne
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[SSSD-users] Re: Is there a way to restrict nss group membership searches for local users to only /etc/group?

[Spike White]

Appreciate the insight.  These are production RHEL7 servers, which I see
are based on sssd-1.16.5-xxx.  As in anything production, I am risk-adverse.

I'll just filter and move on.  Appreciate your help.

Spike

On Fri, Jun 23, 2023 at 9:02 AM Alexey Tikhonov  wrote:

> Hi,
>
>
> On Thu, Jun 22, 2023 at 7:52 PM Spike White 
> wrote:
>
>> Alexey,
>>
>> Thanks for the suggestion.
>>
>> This is a commercial application.  Cloudera's hadoop implementation.  No
>> idea if they use getgrouplist() under the hood.  I can ask our Cloudera
>> tech engineer, but I doubt he knows either.
>>
>> sssd-ad seems to work pretty well on these servers, except for these
>> occasional hiccups.  It's over 150 nodes in this hadoop cluster, with only
>> these occasional hiccups.  Been AD integrated for >1 yr and app team happy
>> (except for one annoying occasional cross-domain caching issue.)
>>
>> In particular, sssd finds its AD site so it's binding to AD DCs local to
>> this datacenter.  (I checked that first thing.)
>>
>> These sporadic hiccups I discuss earlier seem limited to local users
>> only, looking up their group memberships.
>>
>> Would the /etc/nsswitch.conf file syntax be:
>>
>>  initgroups:  files [SUCCESS=return] systemd sss
>>
>> It seems this would apply for all accounts that were members of local
>> groups and not just these specific accounts.  (Not sure that's a problem
>> for this particular app team, but I've seen AD accounts added in /etc/group
>> as members of local groups.)
>>
>> To me, "filter_users" in sssd.conf where I specify the specific accounts
>> would be safer.
>>
>
> Then filtering sounds as a way to go.
>
> If you are courageous you can also try to read SSSD logs to figure out the
> reason for those "sporadic hiccups".
> Latest version, around sssd-2.8+, should make it easier to track a
> specific lookup across a set of logs.
>
>
>
>>
>> Spike
>>
>> On Thu, Jun 22, 2023 at 10:44 AM Alexey Tikhonov 
>> wrote:
>>
>>> Hi,
>>>
>>> On Thu, Jun 22, 2023 at 4:47 PM Spike White 
>>> wrote:
>>>
>>>> All,
>>>>
>>>> Successful sssd consumer here.
>>>>
>>>> Have an app team running Hadoop.  They're getting these performance
>>>> errors in their app.
>>>>
>>>> This is from their app logs.
>>>>
>>>> ddlflhdm201.us.company.com
>>>> WARN June 15, 2023 10:08 AM Groups Potential performance problem:
>>>> getGroups(user=hbase) took 58022 milliseconds
>>>>
>>>
>>> Does it use `getgrouplist()` under the hood?
>>>
>>>
>>>> ddlflhdm304.us.company.com
>>>> WARN June 15, 2023 8:38 AM Groups Potential performance problem:
>>>> getGroups(user=mapred) took 39962 milliseconds
>>>> ddlplhdm505.us.company.com
>>>> WARN June 16, 2023 5:37 AM Groups Potential performance problem:
>>>> getGroups(user=hdfs) took 62437 milliseconds.
>>>> ddlplhdm305.us.company.com
>>>> WARN June 15, 2023 9:36 PM Groups Potential performance problem:
>>>> getGroups(user=hdfs) took 58017 milliseconds
>>>>
>>>> ddlplhdm505.us.company.com
>>>> WARN June 10, 2023 8:01 AM Groups Potential performance problem:
>>>> getGroups(user=yarn) took 58017 milliseconds.
>>>>
>>>>
>>>> Interestingly, all these users are local users created by the Hadoop
>>>> package installation.  (hbase, mapred, hdfs, yarn are all local users).
>>>>
>>>>
>>>> These local users are members only of local groups.  So theoretically
>>>> the search for group memberships should be lightning quick as the groups
>>>> are found only in /etc/group.
>>>>
>>>>
>>>> But since my /etc/nsswitch.conf looks like this:
>>>>
>>>>
>>>> passwd: files systemd sss
>>>>
>>>> group:  files systemd sss
>>>>
>>>> netgroup:   files sss
>>>>
>>>> automount:  files sss
>>>>
>>>> services:   files
>>>>
>>>> shadow: files sss
>>>>
>>>> hosts:  files dns myhostname
>>>>
>>>
>>> You might consider specifying 'initgroups' explicitly and using
>>> something like '[SUCCESS=return]' between databases to avoid going to 

[SSSD-users] Re: Is there a way to restrict nss group membership searches for local users to only /etc/group?

[Spike White]

Alexey,

Thanks for the suggestion.

This is a commercial application.  Cloudera's hadoop implementation.  No
idea if they use getgrouplist() under the hood.  I can ask our Cloudera
tech engineer, but I doubt he knows either.

sssd-ad seems to work pretty well on these servers, except for these
occasional hiccups.  It's over 150 nodes in this hadoop cluster, with only
these occasional hiccups.  Been AD integrated for >1 yr and app team happy
(except for one annoying occasional cross-domain caching issue.)

In particular, sssd finds its AD site so it's binding to AD DCs local to
this datacenter.  (I checked that first thing.)

These sporadic hiccups I discuss earlier seem limited to local users only,
looking up their group memberships.

Would the /etc/nsswitch.conf file syntax be:

 initgroups:  files [SUCCESS=return] systemd sss

It seems this would apply for all accounts that were members of local
groups and not just these specific accounts.  (Not sure that's a problem
for this particular app team, but I've seen AD accounts added in /etc/group
as members of local groups.)

To me, "filter_users" in sssd.conf where I specify the specific accounts
would be safer.

Spike

On Thu, Jun 22, 2023 at 10:44 AM Alexey Tikhonov 
wrote:

> Hi,
>
> On Thu, Jun 22, 2023 at 4:47 PM Spike White 
> wrote:
>
>> All,
>>
>> Successful sssd consumer here.
>>
>> Have an app team running Hadoop.  They're getting these performance
>> errors in their app.
>>
>> This is from their app logs.
>>
>> ddlflhdm201.us.company.com
>> WARN June 15, 2023 10:08 AM Groups Potential performance problem:
>> getGroups(user=hbase) took 58022 milliseconds
>>
>
> Does it use `getgrouplist()` under the hood?
>
>
>> ddlflhdm304.us.company.com
>> WARN June 15, 2023 8:38 AM Groups Potential performance problem:
>> getGroups(user=mapred) took 39962 milliseconds
>> ddlplhdm505.us.company.com
>> WARN June 16, 2023 5:37 AM Groups Potential performance problem:
>> getGroups(user=hdfs) took 62437 milliseconds.
>> ddlplhdm305.us.company.com
>> WARN June 15, 2023 9:36 PM Groups Potential performance problem:
>> getGroups(user=hdfs) took 58017 milliseconds
>>
>> ddlplhdm505.us.company.com
>> WARN June 10, 2023 8:01 AM Groups Potential performance problem:
>> getGroups(user=yarn) took 58017 milliseconds.
>>
>>
>> Interestingly, all these users are local users created by the Hadoop
>> package installation.  (hbase, mapred, hdfs, yarn are all local users).
>>
>>
>> These local users are members only of local groups.  So theoretically the
>> search for group memberships should be lightning quick as the groups are
>> found only in /etc/group.
>>
>>
>> But since my /etc/nsswitch.conf looks like this:
>>
>>
>> passwd: files systemd sss
>>
>> group:  files systemd sss
>>
>> netgroup:   files sss
>>
>> automount:  files sss
>>
>> services:   files
>>
>> shadow: files sss
>>
>> hosts:  files dns myhostname
>>
>
> You might consider specifying 'initgroups' explicitly and using something
> like '[SUCCESS=return]' between databases to avoid going to sss altogether
> (but see below)
>
>>
>>
>> It not only searches local files for group membership, it searches AD as
>> well.  And doesn't find it, as there is no such AD user or uid.
>>  Eventually timing out.
>>
>>
>> In /var/log/messages we see this around the same time frame as
>>
>>
>> Jun 15 10:08:09 ddlflhdm201 sssd[be[amer.company.com]]: GSSAPI Error: An
>> invalid name was supplied (Success)
>>
>
> Is sssd-ad properly configured at this host?
> Initgroups lookup for unknown users should be fast.
>
>
>
>>
>> Is there a way to restrict these particular local app accounts from
>> having their group memberships looked up in AD?
>>
>> I.e., my [nss] section looks like this today:
>>
>> [nss]
>> #debug_level = 9
>> filter_groups = root
>> filter_users = root
>> #override_homedir = /home/%u
>>
>> Can I do this?
>>
>> [nss]
>> filter_users = root,  hbase, mapred, hdfs, yarn
>>
>> And would I want to set filter_users_in_groups = false?
>>
>> Spike White
>>
>>
>> ___
>> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
>> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
>> Fedora Code of Conduct:
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.o

[SSSD-users] Is there a way to restrict nss group membership searches for local users to only /etc/group?

[Spike White]

All,

Successful sssd consumer here.

Have an app team running Hadoop.  They're getting these performance errors
in their app.

This is from their app logs.

ddlflhdm201.us.company.com
WARN June 15, 2023 10:08 AM Groups Potential performance problem:
getGroups(user=hbase) took 58022 milliseconds
ddlflhdm304.us.company.com
WARN June 15, 2023 8:38 AM Groups Potential performance problem:
getGroups(user=mapred) took 39962 milliseconds
ddlplhdm505.us.company.com
WARN June 16, 2023 5:37 AM Groups Potential performance problem:
getGroups(user=hdfs) took 62437 milliseconds.
ddlplhdm305.us.company.com
WARN June 15, 2023 9:36 PM Groups Potential performance problem:
getGroups(user=hdfs) took 58017 milliseconds

ddlplhdm505.us.company.com
WARN June 10, 2023 8:01 AM Groups Potential performance problem:
getGroups(user=yarn) took 58017 milliseconds.


Interestingly, all these users are local users created by the Hadoop
package installation.  (hbase, mapred, hdfs, yarn are all local users).


These local users are members only of local groups.  So theoretically the
search for group memberships should be lightning quick as the groups are
found only in /etc/group.


But since my /etc/nsswitch.conf looks like this:


passwd: files systemd sss

group:  files systemd sss

netgroup:   files sss

automount:  files sss

services:   files

shadow: files sss

hosts:  files dns myhostname


It not only searches local files for group membership, it searches AD as
well.  And doesn't find it, as there is no such AD user or uid.
 Eventually timing out.


In /var/log/messages we see this around the same time frame as


Jun 15 10:08:09 ddlflhdm201 sssd[be[amer.company.com]]: GSSAPI Error: An
invalid name was supplied (Success)

Is there a way to restrict these particular local app accounts from having
their group memberships looked up in AD?

I.e., my [nss] section looks like this today:

[nss]
#debug_level = 9
filter_groups = root
filter_users = root
#override_homedir = /home/%u

Can I do this?

[nss]
filter_users = root,  hbase, mapred, hdfs, yarn

And would I want to set filter_users_in_groups = false?

Spike White
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[SSSD-users]How to do an ‘adcli join’ (or re-join) without creating an msDS-supportedEncryptionTypes LDAP attribute in the machine account?

[Spike White]

Sssd experts,



Our AD team is in the process of eradicating deprecated arcfour-hmac
encryption type from AD.  (It’s a long road).


Our strong preference on the machine accounts is to not even have an
msDS-supportedEncryptionTypes LDAP attribute associated with it.  In that
way, the machine account takes on the AD domain’s default.


Windows servers do this when they AD join.  Their machine accounts don’t
have an explicit msDS-supportedEncryptionTypes LDAP attribute.  Only our
Linux machine accounts have an explicit msDS-supportedEncryptionTypes LDAP
attribute.   (Our Linux machines AD integrate via sssd, using adcli join to
join the domain).


Right now, the AD domain default is aes256/aes128/rc4, but when all rc4
traffic is eradicated they’ll change the domain default to aes256/aes128
only.


We would prefer to not have to circle around and clean up all the explicit
msDS-supportedEncryptionTypes LDAP attributes associated with all the Linux
machine accounts.  To that end, weeks ago one of the AD engineers removed
all msDS-supportedEncryptionTypes LDAP attributes from all our Linux
machine accounts.


But just today, we noticed that some have come back.  And we can’t even
figure out a pattern.  Some have aes256/aes128/rc4 and some have
aes256/aes128 only.


It appears that new builds are setting an explicit
msDS-supportedEncryptionTypes LDAP attribute.  If we re-join (via adcli
join), is it then setting an explicit msDS-supportedEncryptionTypes LDAP
attribute?


(When sssd drops off the domain, our Linux support engineers often just
re-join the server to the domain via a script that does ‘adcli join’.)


I looked at the adcli man page.  It has flags for setting random LDAP
attributes, but doesn’t take explicitly about msDS-supportedEncryptionTypes
LDAP attribute.


Seeking enlightenment,

Spike White

(Happy sssd customer)
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[SSSD-users] Re: Guidance on setting ideal enctypes?

[Spike White]

Kodiak,

I'm actually in the midst of this now.  Our company is running a
'deprecated protocols' project, where they're trying to eliminate rc4
encryption, SNMPv1, v2c and a few other weak protocols I won't mention here.

For AD, that eventually means change the LDAP attribute
msDS-SupportedEncryptionTypes of the computer accounts to a value of 24
(i.e., AES256 and AES120 only).  See:
https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/decrypting-the-selection-of-supported-kerberos-encryption-types/ba-p/1628797
for values of this LDAP attribute msDS-SupportedEncryptionTypes.

Also, you have to ensure that any AD cross-domain trusts are not using
rc4.  (That bit us).

For Linux servers, that means modifying the /etc/ssh/sshd_config file, the
/etc/krb5.conf and maybe the /etc/krb5.conf.d/* files.

In RHEL8/9, the sshd ciphers are managed by the system-wide
crypto-policies.  See man page for 'update-crypto-polciies'.The details
of how the ciphers are managed between RHEL8 and 9 differ in the back-end,
but you probably don't care about that level of detail.

In RHEL 6/7, you edit the /etc/ssh/sshd_config file and edit the 'Ciphers'
line.

For sssd and kerberos, again in RHEL8/9 it is managed by the system-wide
crypto policies.Which sets up an /etc/krb5.conf.d/crypto-policies file
(a symlink).  It has 'permitted_enctypes'.

For RHEL 6/7, as you state -- you set permitted_enctypes in /etc/krb5.conf
or /etc/krb5.conf.d/*.   These encryptions are tried in the order listed,
so you put your strongest encryptions first (AES256).

If you have an existing /etc/krb5.conf file with default_tkt_enctypes or
default_tgs_enctypes, those settings are used preferentially over
permitted_enctypes.

I'm not aware that sssd.conf file specifies encryption types directly.  At
least in our company's sssd.conf files, it does not.

Spike White


On Wed, Mar 29, 2023 at 7:19 AM Kodiak Firesmith 
wrote:

> Hi Folks,
>
> I'm nominally aware that the ability for adcli joins to honor custom
> enctypes became a thing around 2018, but I'm having a heck of a time
> finding guidance online for setting permitted enctypes so that keytabs
> don't create keys for DES and RC4.
>
> Our environment uses a mixture of SSSD 2.2.3, and 2.6.3, joining to MS
> Active Directory, which my Windows admins have said run MS Server 2019 with
> Active Directory 2016.
>
> I've been digging around on search engines and picking through various
> krb5 docs, and I think SSSD will refer to krb5.conf, and might be reading 
> supported_enctypes
> or permitted_enctypes, but I'm not sure how to put it all together.
>
> Thanks very much!
>  - Kodiak Firesmith
>
> Sent with Proton Mail <https://proton.me/> secure email.
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[SSSD-users] Re: not getting cached ticket from PuTTY login

[Spike White]

Pieter,

Never mind.  I am wrong.  restarted sssd and waited for AD replication.
Setting TRUSTED_FOR_DELEGATION on the machine account is sufficient.

I now get a Kerberos cred when I SSH SSO (via Putty) onto Linux server.

Spike

On Tue, Mar 28, 2023 at 3:06 PM Spike White  wrote:

> Pieter,
>
> I was playing around with this also.I was setting
> TRUSTED_FOR_DELEGATION on the machine account as well.  And it was
> accomplishing nothing.
>
> I'm guessing it's the user's account that needs to have
> TRUSTED_FOR_DELEGATION.  Not the machine account.
>
> So when you start putty, you start it under a particular account.  (I have
> to do a 'RunAs' to start putty under the desired account).  I think putty
> is looking at the userAccountControl attribute of this user account.  To
> decide whether to delegate credentials.   (Also, the putty config setting
> "allow delegate credentials" has to be set).
>
> My user account has userAccountControl == NORMAL_ACCOUNT.
>
> Spike
>
> On Tue, Mar 28, 2023 at 6:34 AM Pieter Voet  wrote:
>
>> Hi James,   thanks a lot for your interesting reply..
>>
>> in order to investigate this issue, I've set up an Windows Server 2012
>> evaluation copy on my Linux laptop as an VM using QEMU.
>> With that, I also added two more VM's : a Windows 10 client and a Linux
>> Fedora 37 server with sssd configured and both VMs joined to the Active
>> Directory domain.
>>
>> I now can login to the Windows 10 VM using my AD account and password.
>> Next I use Putty ( with 'Allow GSSAPI Credential Delegation'  enabled )
>> to get to the Linux server, and I get logged in without specifying a
>> password, because sshd is configured to allow GSSAPIAuthentication and
>> detected a valid Kerberos ticket.
>> And then :  yesss !'klist'  showed that I have a valid Kerberos
>> ticket !
>>
>> While reading your post, I looked at the Linux machine object using
>> Adsiedit.msc...
>>
>> this is the userAccountControl for that server :  0x11000 = (
>> WORKSTATION_TRUST_ACCOUNT | DONT_EXPIRE_PASSWORD)
>>
>> umm..  the TRUSTED_FOR_DELEGATION flag is not set, but still , Putty
>> login gives me a TGT.
>> This does not match your explanation..  Am I doing something not right ?
>>
>> Thanks !
>> ___
>> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
>> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
>> Fedora Code of Conduct:
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
>> Do not reply to spam, report it:
>> https://pagure.io/fedora-infrastructure/new_issue
>>
>
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[SSSD-users] Re: not getting cached ticket from PuTTY login

[Spike White]

Pieter,

I was playing around with this also.I was setting
TRUSTED_FOR_DELEGATION on the machine account as well.  And it was
accomplishing nothing.

I'm guessing it's the user's account that needs to have
TRUSTED_FOR_DELEGATION.  Not the machine account.

So when you start putty, you start it under a particular account.  (I have
to do a 'RunAs' to start putty under the desired account).  I think putty
is looking at the userAccountControl attribute of this user account.  To
decide whether to delegate credentials.   (Also, the putty config setting
"allow delegate credentials" has to be set).

My user account has userAccountControl == NORMAL_ACCOUNT.

Spike

On Tue, Mar 28, 2023 at 6:34 AM Pieter Voet  wrote:

> Hi James,   thanks a lot for your interesting reply..
>
> in order to investigate this issue, I've set up an Windows Server 2012
> evaluation copy on my Linux laptop as an VM using QEMU.
> With that, I also added two more VM's : a Windows 10 client and a Linux
> Fedora 37 server with sssd configured and both VMs joined to the Active
> Directory domain.
>
> I now can login to the Windows 10 VM using my AD account and password.
> Next I use Putty ( with 'Allow GSSAPI Credential Delegation'  enabled ) to
> get to the Linux server, and I get logged in without specifying a password,
> because sshd is configured to allow GSSAPIAuthentication and detected a
> valid Kerberos ticket.
> And then :  yesss !'klist'  showed that I have a valid Kerberos ticket
> !
>
> While reading your post, I looked at the Linux machine object using
> Adsiedit.msc...
>
> this is the userAccountControl for that server :  0x11000 = (
> WORKSTATION_TRUST_ACCOUNT | DONT_EXPIRE_PASSWORD)
>
> umm..  the TRUSTED_FOR_DELEGATION flag is not set, but still , Putty login
> gives me a TGT.
> This does not match your explanation..  Am I doing something not right ?
>
> Thanks !
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[SSSD-users] Re: not getting cached ticket from PuTTY login

[Spike White]

Pieter,

I have Connection -> SSH -> Auth -> GSSAPI -> Allow GSSAPI -> credential
delegation turned on in putty.

As well as on the target Linux server, it has [libdefaults] forwardable =
true.  The error I get when I ssh in is:

[admspike_white@austgcore17 ~]$ klist
klist: Credentials cache 'KCM:2025431' not found
[admspike_white@austgcore17 ~]$

where 2025431 is my UID.

Spike

On Mon, Mar 27, 2023 at 1:36 PM Pieter Voet  wrote:

> On the Windows laptop, I  opened up a CMD windows and entered 'klist'..
> All tickets listed there have Ticket Flags 'forwardable'..
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[SSSD-users] Re: not getting cached ticket from PuTTY login

[Spike White]

Pieter,

We use GSSAPI instead of  GSS-SPNEGO for ssh SSO, but it should work the
same.  This does not really involve sssd at all (for the authentication).
What happens is that your ssh daemon is Kerberos-aware.  So when it is
presented with a Kerberos ticket, the ssh daemon contacts the Kerberos
server (AD DC in our case) to verify the ticket.  If authenticated, it
allows login.  That is, it bypasses PAM for the 'authentication' phase.  It
still consults PAM stack for the 'account' and 'session' phases however,

Because the sshd service in this situation does not call PAM stack for the
authentication phase, it does not consult pam_sss during the authentication
phase.   For your account phase and session phase, it will consult pam_sss,
but that doesn't involve kerberos.

I am looking at my (Windows) putty to (Linux) ssh login.  Yes, it SSO's to
Linux just fine.  But once on the Linux server, I see I don't have a
Kerberos ticket.  I've never noticed that before,  as we essentially never
ssh SSO linux to linux,   Always run 'new session' off the existing putty
session to pop to a new Linux server.

Years ago, I know we used to have a Kerberos ticket when we SSH SSO'd in,
so then we could SSO Linux to Linux.  Don't know when that disappeared.

Spike

On Sun, Mar 26, 2023 at 3:41 PM Pieter Voet  wrote:

> OK.. too stupid !   I forgot to clear the credentials using 'kdestroy -A'
> before retrying with Putty..
>
> so, the original problem is still there...  I don't get a Kerberos ticket
> if logging on to Linux from Windows using Putty.
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[SSSD-users] What are adcli testjoin and sssd doing for us? How do we equivalently kinit -k?

[Spike White]

All,

We are surveying our ecosystem of Linux servers, trying to slowly eradicate
the weak rc4 encryption from AD.  (Our AD team has done all the legwork;
plus we’ve tested and we’re certain that rc4 is not required for OS-level
AD integration.)

We’re focusing on eliminating rc4 from our sssd-based OS-level logins
now.What we want to do is determine which servers are currently relying
on rc4 for their Kerberos OS-level creds.

A simple way to do this (usually) is to acquire a Kerberos host credential
and see what encryption it negotiated.

kinit -k

klist -e | grep Etype

renew until 03/09/2023 12:41:32, Etype (skey, tkt):
aes256-cts-hmac-sha1-96,
aes256-cts-hmac-sha1-96



Normally, it’ll get aes256 or aes128; either of which are good.

But we’ve hit on some old builds (RHEL7) where we don’t understand what’s
going on.  We frankly don’t understand how sssd is working on them.  (48
servers in total).  We want to audit these, but we’re unclear how.

Sssd is starting and running fine on them.  Adcli testjoin is working.  But
we don’t know why!

We think because the server names are in upper-case on these builds, that’s
part of our problem.

ldap_sasl_authid is set as so in /etc/sssd/sssd.conf file:

ldap_sasl_authid = srspls3bwcof104.us.example@amer.example.com


default_realm and mapping from DNS domain to AD domain isn’t set in
/etc/krb5.conf file.  (Yes, we know this is bad.)

adcli testjoin succeeds.

[root@SRSPLS3BWCOF104 etc]# adcli testjoin -D AMER.EXAMPLE.COM -v

 * Found realm in keytab: AMER.EXAMPLE.COM

 * Found computer name in keytab: SRSPLS3BWCOF104

 * Found service principal in keytab: host/srspls3bwcof104.us.example.com

 * Found host qualified name in keytab: srspls3bwcof104.us.example.com

 * Found service principal in keytab: host/SRSPLS3BWCOF104

 * Found service principal in keytab: RestrictedKrbHost/SRSPLS3BWCOF104

 * Found service principal in keytab: RestrictedKrbHost/
srspls3bwcof104.us.example.com

 * Using domain name: AMER.EXAMPLE.COM

 * Calculated computer account name from fqdn: SRSPLS3BWCOF104

 * Using domain realm: AMER.EXAMPLE.COM

 * Discovering domain controllers: _ldap._tcp.AMER.EXAMPLE.COM

 * Sending NetLogon ping to domain controller:
AUSDC16AMER41.amer.example.com

 * Received NetLogon info from: AUSDC16AMER41.amer.example.com

 * Discovering site domain controllers: _ldap._tcp.AMERAustin._sites.dc._
msdcs.amer.example.com

 * Sending NetLogon ping to domain controller:
AUSDC16AMER14.amer.example.com

 * Received NetLogon info from: AUSDC16AMER14.amer.example.com

 * Wrote out krb5.conf snippet to
/tmp/adcli-krb5-62UEmj/krb5.d/adcli-krb5-conf-EvFdQ4

 * Authenticated as default/reset computer account: SRSPLS3BWCOF104

 * Using GSS-SPNEGO for SASL bind

 * Looked up short domain name: AMERICAS

 * Looked up domain SID: S-1-5-21-1802859667-647903414-1863928812

Sucessfully validated join to domain AMER.EXAMPLE.COM

[root@SRSPLS3BWCOF104 etc]#



Sssd service is fat and happy.

[root@SRSPLS3BWCOF104 etc]# systemctl status sssd

● sssd.service - System Security Services Daemon

   Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled; vendor
preset: disabled)

   Active: active (running) since Thu 2023-03-02 11:30:25 EST; 2h 25min ago

 Main PID: 28053 (sssd)

   CGroup: /system.slice/sssd.service

   ├─28053 /usr/sbin/sssd -i --logger=files

   ├─28054 /usr/libexec/sssd/sssd_be --domain amer.example.com
--uid 0 --gid 0 --logger=files

   ├─28055 /usr/libexec/sssd/sssd_nss --uid 0 --gid 0 --logger=files

   ├─28056 /usr/libexec/sssd/sssd_pam --uid 0 --gid 0 --logger=files

   ├─28057 /usr/libexec/sssd/sssd_ifp --uid 0 --gid 0 --logger=files

   └─28058 /usr/libexec/sssd/sssd_autofs --uid 0 --gid 0
--logger=files



Mar 02 13:15:35 SRSPLS3BWCOF104.us.example.com sssd_be[28054]: GSSAPI
client step 1

Mar 02 13:15:35 SRSPLS3BWCOF104.us.example.com sssd_be[28054]: GSSAPI
client step 2

Mar 02 13:30:35 SRSPLS3BWCOF104.us.example.com sssd_be[28054]: GSSAPI
client step 1

Mar 02 13:30:35 SRSPLS3BWCOF104.us.example.com sssd_be[28054]: GSSAPI
client step 1

Mar 02 13:30:35 SRSPLS3BWCOF104.us.example.com sssd_be[28054]: GSSAPI
client step 1

Mar 02 13:30:35 SRSPLS3BWCOF104.us.example.com sssd_be[28054]: GSSAPI
client step 2

Mar 02 13:45:35 SRSPLS3BWCOF104.us.example.com sssd_be[28054]: GSSAPI
client step 1

Mar 02 13:45:35 SRSPLS3BWCOF104.us.example.com sssd_be[28054]: GSSAPI
client step 1

Mar 02 13:45:35 SRSPLS3BWCOF104.us.example.com sssd_be[28054]: GSSAPI
client step 1

Mar 02 13:45:35 SRSPLS3BWCOF104.us.example.com sssd_be[28054]: GSSAPI
client step 2

[root@SRSPLS3BWCOF104 etc]#



/etc/krb5.keytab file has new updated entries in the last 30 days.

[root@SRSPLS3BWCOF104 etc]# klist -kte

Keytab name: FILE:/etc/krb5.keytab

KVNO Timestamp   Principal

 ---
--

  28 02/09/2023 16:14:59 SRSPLS3BWCOF104$@AMER.EXAMPLE.COM 

[SSSD-users] Re: Does sssd support direct integration to AzureAD?

[Spike White]

Sam,

Appreciate the clarification.  Makes sense now.

Spike

On Mon, Jan 9, 2023 at 10:05 AM Sam Morris  wrote:

> On 09/01/2023 15:38, Spike White wrote:
> > Sumit,
> >
> > Thanks for answer.
> >
> > MS claims that adcli + sssd allows you to join an Azure AD domain
> services.
> >
> >
> https://learn.microsoft.com/en-us/azure/active-directory-domain-services/join-rhel-linux-vm
> <
> https://learn.microsoft.com/en-us/azure/active-directory-domain-services/join-rhel-linux-vm
> >
>
> It looks like that's for Azure AD DS - not 'pure' Azure AD.
>
> (Azure AD DS is like AD DS but Microsoft host the DCs for you, so as far
> as your Linux system is concerned it's like "direct integration" with AD
> DS).
>
> --
> Sam Morris <https://robots.org.uk/>
> PGP: rsa4096/CAAA AA1A CA69 A83A 892B  1855 D20B 4202 5CDA 27B9
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[SSSD-users] Re: Does sssd support direct integration to AzureAD?

[Spike White]

Sumit,

Thanks for answer.

MS claims that adcli + sssd allows you to join an Azure AD domain
services.

https://learn.microsoft.com/en-us/azure/active-directory-domain-services/join-rhel-linux-vm

Like I say, I'm not an AD expert.  Certainly not AzureAD.

Spike


On Fri, Jan 6, 2023 at 12:42 AM Sumit Bose  wrote:

> Am Thu, Jan 05, 2023 at 11:03:55AM -0600 schrieb Spike White:
> > All,
> >
> > Our org uses sssd for direct integration to our corp AD forest, which has
> > the std MS schema extension (RFC 2307bis IIRC).
> >
> > Currently, we have some Windows builds running in the Azure cloud,
> > integrated via AzureAD.  I'm not a Windows engineer, so I don't know the
> > details of this Windows-based user authentication.  Other than it works.
> >
> > Does sssd support direct integration to AzureAD?
> >
> > I read this with great interest:
> >
> https://research.redhat.com/blog/engineering_project/integrate-sssd-with-azure-ad/
> >
> > So if sssd supports this, any sssd config changes required for AzureAD?
>
> Hi,
>
> currently this is only possilbe with the help of FreeIPA. See
>
> https://freeipa.readthedocs.io/en/latest/workshop/12-external-idp-support.html
> for an example with keycloak as IdP, but you can use AzureAD as well.
>
> There is a chapter in the official RHEL IdM documentation at
>
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/managing_idm_users_groups_hosts_and_access_control_rules/assembly_using-external-identity-providers-to-authenticate-to-idm_managing-users-groups-hosts
> too.
>
> bye,
> Sumit
>
> >
> > Spike
>
> > ___
> > sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> > To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> > Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> > Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[SSSD-users] Does sssd support direct integration to AzureAD?

[Spike White]

All,

Our org uses sssd for direct integration to our corp AD forest, which has
the std MS schema extension (RFC 2307bis IIRC).

Currently, we have some Windows builds running in the Azure cloud,
integrated via AzureAD.  I'm not a Windows engineer, so I don't know the
details of this Windows-based user authentication.  Other than it works.

Does sssd support direct integration to AzureAD?

I read this with great interest:
https://research.redhat.com/blog/engineering_project/integrate-sssd-with-azure-ad/

So if sssd supports this, any sssd config changes required for AzureAD?

Spike
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[SSSD-users] Re: missing secondary groups that have Global scope

[Spike White]

Jeffrey,

Follow-on question.  How does your sssd configuration ever bind to a
nonlocal-domain global catalog server?

Are you relying on sssd's site-awareness to determine preferred AD DCs and
global catalog servers?   Or are you hard-coding global catalog servers in
your sssd.conf file?

If the former,  then I'd beat up on your maintainer for AD site and
services;  they have defined non-local global catalog servers for your site.

Spike

On Thu, Dec 22, 2022 at 4:14 PM Spike White  wrote:

> Jeffrey,
>
> Bear in mind I'm a Linux engineer.  (I speak regularly to our AD team).
> As I understand it, the domain-local memberships are housed in the local
> domain, not the GC.
>
> If you look at the output of 'sssctl domain-status ', you will see
> it references two DCs that it's bound to.  The local DC and the global
> catalog server.
>
> So for domain-local groups, it would consult the first DC and get back the
> proper membership.  For universal groups, yes their membership is contained
> in the GC, so it'd have to consult that second DC (the global catalog
> server).
>
> That leaves only the global groups.  and I think your reasoning is correct
> for those.
>
> To be honest, when we were transitioning to sssd from our previous AD
> integration tool, we were under a time crunch.  So while we saw (same as
> you) that not all global group memberships showed up, we didn't have time
> to deep-dive into the actual culprit.  (I suspect it's exactly as you
> state, because at that time we were doing 'tokengroups = false').
>
> Since we were under a severe time crunch, we just promoted any global
> group that got called out by the users.   We promoted that global group to
> a univeral group.
>
> I haven't seen a global group getting called out for missing membership in
> over a year.  However, we have transitioned to 'tokengroups = true', so
> that's likely why.
>
> Spike
>
> On Thu, Dec 22, 2022 at 2:53 PM Jeffrey Chung  wrote:
>
>> Thanks for the reply Spike.  We will do some performance tests in our AD
>> environment for this.
>>
>> There are situations where tokenGroups should be disabled to get
>> consistent results like changing the search base for groups.
>>
>> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/windows_integration_guide/changing-the-ldap-search-base-for-users-and-groups-in-a-trusted-ad-domain
>>
>> In this scenario with tokenGroups disabled we would still hit the same
>> issue in my original post.  To me this seems to be a bug in sssd, it can't
>> rely just on the GC to get back a complete list of groups a user is member
>> of because you'll be missing other group scopes like Global and Domain
>> Local.  Am I thinking about this wrong?
>>
>> -Jeff
>> ___
>> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
>> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
>> Fedora Code of Conduct:
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
>> Do not reply to spam, report it:
>> https://pagure.io/fedora-infrastructure/new_issue
>>
>
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[SSSD-users] Re: missing secondary groups that have Global scope

[Spike White]

Jeffrey,

Bear in mind I'm a Linux engineer.  (I speak regularly to our AD team).  As
I understand it, the domain-local memberships are housed in the local
domain, not the GC.

If you look at the output of 'sssctl domain-status ', you will see
it references two DCs that it's bound to.  The local DC and the global
catalog server.

So for domain-local groups, it would consult the first DC and get back the
proper membership.  For universal groups, yes their membership is contained
in the GC, so it'd have to consult that second DC (the global catalog
server).

That leaves only the global groups.  and I think your reasoning is correct
for those.

To be honest, when we were transitioning to sssd from our previous AD
integration tool, we were under a time crunch.  So while we saw (same as
you) that not all global group memberships showed up, we didn't have time
to deep-dive into the actual culprit.  (I suspect it's exactly as you
state, because at that time we were doing 'tokengroups = false').

Since we were under a severe time crunch, we just promoted any global group
that got called out by the users.   We promoted that global group to a
univeral group.

I haven't seen a global group getting called out for missing membership in
over a year.  However, we have transitioned to 'tokengroups = true', so
that's likely why.

Spike

On Thu, Dec 22, 2022 at 2:53 PM Jeffrey Chung  wrote:

> Thanks for the reply Spike.  We will do some performance tests in our AD
> environment for this.
>
> There are situations where tokenGroups should be disabled to get
> consistent results like changing the search base for groups.
>
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/windows_integration_guide/changing-the-ldap-search-base-for-users-and-groups-in-a-trusted-ad-domain
>
> In this scenario with tokenGroups disabled we would still hit the same
> issue in my original post.  To me this seems to be a bug in sssd, it can't
> rely just on the GC to get back a complete list of groups a user is member
> of because you'll be missing other group scopes like Global and Domain
> Local.  Am I thinking about this wrong?
>
> -Jeff
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[SSSD-users] Re: New sssd-related message this week in /var/log/messages

[Spike White]

Sumit,

So in reviewing my notes, I see that the reason we set:

   krb5_validate = false

was during that krb5-libs race condition that appeared last year.  That if
the KVNO between AD and /etc/krb5.keytab file ever got off,  then the
client would no longer validate its krb5 host creds (that's what my notes
say for our justification for setting this sssd.conf setting.)

This might have been an early (misguided) attempt to work around this
krb5-libs race condition.  As we later discovered, the krb5-libs call would
have AD update its machine creds on a 30 day cycle.  But it would report
back to sssd an error, so sssd would not update its local /etc/krb5.keytab
file.   Thus,  the resulting KVNO in AD would be 1 more than the KVNO in
/etc/krb5.keytab file.

But this is a real problem;  not just a problem with krb5 validation.
Because those machine account creds in AD with the (N+1) KVNO are truly
different than the (expiring) machine account creds in /etc/krb5.keytab
with the (N) KVNO.

So whether we set krb5_validate = true or krb5_validate = false, it should
fail to validate its host creds (after the old creds expire).

BTW, with your kind assistance and with that MIT krb5-libs developer's
assistance, that krb5-libs race condition was fixed in a krb5-libs RPM
update last year.  At least for RHEL 7, 8 and (presumably) 9.

So I don't think we need to specify krb5_validate = false any more (if we
ever did).

Agreed?

Spike



On Thu, Dec 15, 2022 at 1:09 AM Sumit Bose  wrote:

> Am Wed, Dec 14, 2022 at 07:52:38PM + schrieb Christian, Mark:
> > On Wed, 2022-12-14 at 13:00 -0600, Spike White wrote:
> > > Sssd experts,
> > > We have been running sssd to AD integrate to a cross-domain AD forest
> > > for ~2 years now.  With RHEL 7, 8 and (now) 9 servers.  Has worked
> > > great.
> > > Just this week, we have a new message appearing in /var/log/messages
> > > related to sssd that we’ve never seen before:
> > > Dec 10 06:11:19 pshnldur01.amer.company.com sssd_be[343144]: PAC
> > > check is requested but krb5_validate is set to false. PAC checks will
> > > be skipped.
> > > This is a RHEL8 server, running sssd 2.7.3-4.0.1.el8_7.1 -- installed
> > > Fri 02 Dec 2022.  We notice a new sssd_pac process running, even
> > > though in /etc/sssd/sssd.conf, we did not explicitly define any “pac”
> > > service.
> > > In RHEL7 servers, we do not see any such sssd_pac process.  We do see
> > > this process in RHEL9 servers.
> > > In the change log for this new RHEL8 sssd version, I notice this
> > > recent entry:
> > > [2.7.3-4.1]
> > > - Resolves: rhbz#2128902 - Cannot SSH with AD user to ipa-client
> > > (krb5_validate and pac_check settings conflict) [rhel-9.1.0.z]
> > >
> > > Yes, in our /etc/sssd/sssd.conf file we set:
> > > krb5_validate = False
> > >
> > > All seems to be behaving.The server appears to be able to
> > > communicate fine with this local domain.  All expected logins appear
> > > to work.
> > > 1. Can we ignore these messages?
>
> Hi,
>
> as mentioned below the PAC is part of the Kerberos ticket you receive
> during authentication from an AD DC. Over the last year Microsoft added
> some new information into the PAC and started to add more checks for the
> consistency of the PAC and the mapping to the operation system account.
> Since the Kerberos ticket is by design independent of the operating
> system account there must be some additional information to map the
> Kerberos ticket to the operating system account during authentication
> and Microsoft is using the PAC for this.
>
> Since the mapping is also important for the login to Linux system we
> implemented some of the checks as well. To be able to decode the PAC we
> have to request a service ticket first. This is the same operation which
> is done during the generic ticket validation (krb5_validate) and if this
> is disabled we skip the PAC check as well since we assume that ticket
> validation is disabled because there are issues requesting the service
> ticket.
>
> So, coming back to your question 'Can we ignore these messages?'. The
> message should make you aware that something which we consider as a
> security feature is skipped due to a not strictly related configuration
> option and it might be worth to reconsider if 'krb5_validate = False' is
> really necessary.
>
> If you disabled the PAC check explicitly by setting
> 'pac_check = no_check' in the [pac] section of sssd.conf, the log
> message should go away, see man sssd.conf for details.
>
> > > 2. Are they due to this new sssd version?
>
> yes
>
> > > 3. Why does a pac service start up 

[SSSD-users] Re: missing secondary groups that have Global scope

[Spike White]

Jeffrey,

I'm told that the alternative to tokengroups would be recursive LDAP
queries.  Which would be expensive for the clients, particularly with
heavily-nested subgroups.

Prior to us using tokengroups, we tried to limit the cost of these LDAP
queries by limiting the LDAP query depth to false.

Interestingly,  we also formerly used to have problems with global AD group
memberships not being properly reflected.  Our solution was to promote any
such global groups up to universal groups and then the membership was seen.

But for performance reasons, we started using tokengroups.  We haven't seen
this global group problem in a while.  Interesting (and totally obscure!!)
that it's related to use of tokengroups.

BTW, if tokengroups is an expensive operation on AD DCs, seems like your AD
team needs to size your AD DCs appropriately.  Doesn't seem reasonable to
throttle clients, due to some DC hardware.

Spike

On Wed, Dec 21, 2022 at 5:30 PM Jeffrey Chung  wrote:

> The primary reason we disabled tokenGroups is because our sssd logs were
> filling up with 'Unable to resolve SID S-1-5-21-XXX-XXX-XXX-XXX - will try
> next sid.' entries.  We found a work-around from this doc.
> https://pagure.io/SSSD/sssd/issue/2914
>
> In our environment not all of our AD groups are POSIX enabled, so I think
> that's why we see a lot of those log entries.
>
> I just tested enabling tokenGroups and that seem to have solved the
> issue.  I'm seeing the LDAP query (port 389) going to a domain controller
> from the same domain as the user.
>
> Is enabling tokenGroups the recommended configuration when using the AD
> provider? The one thing I read is querying for tokenGroups is an expensive
> operation on the domain controllers and care should be taken when scaling
> this to larger environments.
> https://learn.microsoft.com/en-us/windows/win32/adschema/a-tokengroups
> Any insight into this?  Is SSSD more efficient with tokenGroups enabled
> versus not?
>
> -Jeff
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[SSSD-users] New sssd-related message this week in /var/log/messages

[Spike White]

Sssd experts,

We have been running sssd to AD integrate to a cross-domain AD forest for
~2 years now.  With RHEL 7, 8 and (now) 9 servers.  Has worked great.

Just this week, we have a new message appearing in /var/log/messages
related to sssd that we’ve never seen before:

*Dec 10 06:11:19 pshnldur01.amer.company.com
<http://pshnldur01.amer.company.com> sssd_be[343144]: PAC check is
requested but krb5_validate is set to false. PAC checks will be skipped.*

This is a RHEL8 server, running sssd 2.7.3-4.0.1.el8_7.1 -- installed Fri
02 Dec 2022.  We notice a new sssd_pac process running, even though in
/etc/sssd/sssd.conf, we did not explicitly define any “pac” service.

In RHEL7 servers, we do not see any such sssd_pac process.  We do see this
process in RHEL9 servers.

In the change log for this new RHEL8 sssd version, I notice this recent
entry:

[2.7.3-4.1]
- Resolves: rhbz#2128902 - Cannot SSH with AD user to ipa-client
(krb5_validate and pac_check settings conflict) [rhel-9.1.0.z]



Yes, in our /etc/sssd/sssd.conf file we set:

krb5_validate = False



All seems to be behaving.The server appears to be able to communicate
fine with this local domain.  All expected logins appear to work.

1. Can we ignore these messages?

2. Are they due to this new sssd version?

3. Why does a pac service start up if we do not explicitly define it in
our list of services?

Spike White
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[SSSD-users] Re: Microsoft November 2022 updates breaks Active Directory integration]

[Spike White]

All,

It appears that this Nov 2022 AD DC patch does not directly break our
sssd-based AD integration.  This was done in a test AD domain.

However, if the AD domain admin clicks the button to "use AES256 only" on
this test account it does break login.

Which led to further discovery.

Our particular AD integration allows AES256, AES128 and arcfour-hmac
encryption types.  That is, our crypto policy is DEFAULT:AD-SUPPORT.
(Originally, we turned off arcfour-hmac support, but for obscure reasons we
had to turn it back on.)

If we changed our crypto policy to "DEFAULT"  (i.e., no arcfour-hmac
encryption support), then this Nov 2022 AD DC patch does seem to break our
sssd-based AD integration.

Thus, it appears that companies that have implemented good security and
disabled arcfour-hmac encryption will be bitten by this Nov 2022 AD DC
patch.

Spike

On Tue, Nov 15, 2022 at 3:46 PM Spike White  wrote:

> Really really appreciate the head's up on this Sumit!
>
> We'd seen the notice yesterday, but from the brief description our
> guess was that sssd was unaffected.  Then your message showed up.  So
> timely!
>
> We're coordinating with our AD team now.
>
> Spike
>
> Spike White
>
>
> On Tue, Nov 15, 2022 at 12:07 AM Sumit Bose  wrote:
>
>> - Weitergeleitete Nachricht von Rob Crittenden via FreeIPA-users <
>> freeipa-us...@lists.fedorahosted.org> -
>>
>> Date: Mon, 14 Nov 2022 10:19:15 -0500
>> From: Rob Crittenden via FreeIPA-users <
>> freeipa-us...@lists.fedorahosted.org>
>> To: FreeIPA users list 
>> Cc: Rob Crittenden 
>> Subject: [Freeipa-users] Microsoft November 2022 updates breaks Active
>> Directory integration
>>
>> Microsoft addressed a number of CVEs last week which introduced some
>> authentication issues. After installation of these patches, user
>> authentication on Linux systems integrated in Active Directory no longer
>> works and new systems are unable to join an AD domain that is managed by
>> domain controllers where these patches have been applied.
>>
>> For more details see https://access.redhat.com/solutions/6985061 (open
>> to the public).
>>
>> rob
>> ___
>> FreeIPA-users mailing list -- freeipa-us...@lists.fedorahosted.org
>> To unsubscribe send an email to
>> freeipa-users-le...@lists.fedorahosted.org
>> Fedora Code of Conduct:
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedorahosted.org/archives/list/freeipa-us...@lists.fedorahosted.org
>> Do not reply to spam, report it:
>> https://pagure.io/fedora-infrastructure/new_issue
>>
>> - Ende weitergeleitete Nachricht -
>> ___
>> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
>> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
>> Fedora Code of Conduct:
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
>> Do not reply to spam, report it:
>> https://pagure.io/fedora-infrastructure/new_issue
>>
>
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[SSSD-users] Re: Microsoft November 2022 updates breaks Active Directory integration]

[Spike White]

Really really appreciate the head's up on this Sumit!

We'd seen the notice yesterday, but from the brief description our
guess was that sssd was unaffected.  Then your message showed up.  So
timely!

We're coordinating with our AD team now.

Spike

Spike White


On Tue, Nov 15, 2022 at 12:07 AM Sumit Bose  wrote:

> - Weitergeleitete Nachricht von Rob Crittenden via FreeIPA-users <
> freeipa-us...@lists.fedorahosted.org> -
>
> Date: Mon, 14 Nov 2022 10:19:15 -0500
> From: Rob Crittenden via FreeIPA-users <
> freeipa-us...@lists.fedorahosted.org>
> To: FreeIPA users list 
> Cc: Rob Crittenden 
> Subject: [Freeipa-users] Microsoft November 2022 updates breaks Active
> Directory integration
>
> Microsoft addressed a number of CVEs last week which introduced some
> authentication issues. After installation of these patches, user
> authentication on Linux systems integrated in Active Directory no longer
> works and new systems are unable to join an AD domain that is managed by
> domain controllers where these patches have been applied.
>
> For more details see https://access.redhat.com/solutions/6985061 (open
> to the public).
>
> rob
> ___
> FreeIPA-users mailing list -- freeipa-us...@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/freeipa-us...@lists.fedorahosted.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
> - Ende weitergeleitete Nachricht -
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[SSSD-users] Re: How to correctly omit the AD domain prefix from hostnames etc

[Spike White]

Kodiak,

I think when your DNS domain != your kerberos realm, you have to do this:

/etc/krb5.conf:

[domain_realm]
.whoi.edu <http://adwhoi.whoi.edu/> = ADWHOI.WHOI.EDU
<http://adwhoi.whoi.edu/>


i.e., this DNS domain (whoi.edu)  == this kerberos realm (aka AD domain) .

/etc/sssd/sssd.conf:
[sssd]
domains = whoi.edu <http://adwhoi.whoi.edu/>
...
[domain/whoi.edu <http://adwhoi.whoi.edu/>]
..
krb5_realm = ADWHOI.WHOI.EDU <http://adwhoi.whoi.edu/>
...
ad_domain = adwhoi.whoi.edu


I think your adcli join would be something like this:

export KRB5CCNAME="FILE:/tmp/krb5cc_${SVCNAME}"
kinit ${ACCOUNTNAME}
JOINDOMAIN=adwhoi.whoi.edu
adcli join --domain="$JOINDOMAIN" --login-user=${ACCOUNTNAME}
--login-ccache="/tmp/krb5cc_$SVCNAME" --service-name='host'
--service-name='RestrictedKrbHost' --os-name="$OS_NAME"
--os-version="$OS_VERSION_FULL " --domain-ou="$OU_CONTAINER" --show-details
--host-keytab=/etc/krb5.keytab --host-fqdn=$FQDN
--user-principal="host/$FQDN@$JOINDOMAIN"

If I've missed a step please advise.

Spike White

On Tue, Oct 18, 2022 at 2:39 PM Kodiak Firesmith 
wrote:

> Hi Folks,
> I currently have SSSD-AD working exactly as I want it, less one drawback -
> I have to include the AD domain prefix everywhere to get things working.
>
> For example, we are whoi.edu, and in non-AD DNS, all of our hosts are $
> hostname.whoi.edu.
> We'll call our AD domain 'adwhoi' for this discussion.
>
> To get things working cleanly, Ansible reconfigures  each host right
> before the AD join to use the hostname $hostname.adwhoi.whoi.edu instead
> of $hostname.whoi.edu.
>
> Hosts join AD via adcli and set the usual UPN and SPNs.  AD-based identity
> and authentication works just fine.  GSSAPI auth works fine.  Users are
> granted a valid TGT upon login.  Root can kinit the host keytab fine.
>
> Deploying a new major release of Linux is always an opportunity to make a
> clean break and fix annoyances like this, so I'd love to know how we can
> get all of the above working, but without having to include the domain
> prefix in our hostnames and in our ssh references.
>
> I've done a fair bit of digging on this while setting up our AD join
> scheme and authoring our Ansible code, but I've never been able to crack
> this issue, so I'd love it if someone could clue me in.
>
> Here's some of the relevant files in case they are helpful:
>
> ===
> /etc/sssd/sssd.conf:
> [sssd]
> domains = adwhoi.whoi.edu
> services = nss, pam
> debug_level = 3
> [domain/adwhoi.whoi.edu]
> krb5_store_password_if_offline = True
> cache_credentials = True
> krb5_realm = ADWHOI.WHOI.EDU
> id_provider = ad
> fallback_homedir = /home/%u
> override_homedir = /home/%u
> default_shell = /bin/bash
> ad_domain = adwhoi.whoi.edu
> use_fully_qualified_names = False
> ldap_id_mapping = False
> access_provider = ad
> ad_gpo_access_control = disabled
> ad_server = jimbob.adwhoi.whoi.edu,cleetus.adwhoi.whoi.edu
> ad_backup_server = jedidiah.adwhoi.whoi.edu
> ad_maximum_machine_account_password_age = 0
> ldap_referrals = False
> ===
> /etc/krb5.conf
> [libdefaults]
> default_realm = ADWHOI.WHOI.EDU
> rdns = False
> dns_canonicalize_hostname = False
>
> # The following krb5.conf variables are only for MIT Kerberos.
> kdc_timesync = 1
> ccache_type = 4
> forwardable = true
> proxiable = true
>
> # The following libdefaults parameters are only for Heimdal Kerberos.
> fcc-mit-ticketflags = true
>
> [realms]
> ADWHOI.WHOI.EDU = {
> kdc = jimbob.adwhoi.whoi.edu
> kdc = cleetus.adwhoi.whoi.edu
> kdc = jedidiah.adwhoi.whoi.edu
>
> admin_server = jimbob.adwhoi.whoi.edu
> default_domain = adwhoi.whoi.edu
> }
>
> [domain_realm]
> .adwhoi.whoi.edu = ADWHOI.WHOI.EDU
> adwhoi.whoi.edu = ADWHOI.WHOI.EDU
> ===
> Example keytab:
> Keytab name: FILE:/etc/krb5.keytab
> KVNO Principal
> 
> --
>2 SOMEHOST$@ADWHOI.WHOI.EDU (arcfour-hmac)
>2 SOMEHOST$@ADWHOI.WHOI.EDU (aes128-cts-hmac-sha1-96)
>2 SOMEHOST$@ADWHOI.WHOI.EDU (aes256-cts-hmac-sha1-96)
>2 host/somehost.adwhoi.whoi@adwhoi.whoi.edu (arcfour-hmac)
>2 host/somehost.adwhoi.whoi@adwhoi.whoi.edu
> (aes128-cts-hmac-sha1-96)
>2 host/somehost.a

[SSSD-users] RFE: option to not block all permitted users and groups if an unknown domain entered...

[Spike White]

sssd personnel,

When a Linux SE fat-fingers the domain name when doing a 'realm permit' or
'realm permit -g', it locks all permitted users and groups.

Even worse, it's not usually obvious from looking at the
'simple_allow_users' and 'simple_allow_groups'  lines which entry is the
culprit.

Here's an example:

simple_allow_groups = amerlinux...@amer.company.com,
amerlinux...@amer.company.com, emealinux...@emea.company.com,
emealinux...@emea.company.com, apaclinux...@apac.company.com,
apaclinux...@apac.company.com, gbllinuxsu...@amer.company.com,
pptsupport...@amer.company.com, unv_legato_adm...@amer.company.com,
scheduling_glo...@amer.company.com, amerlinuxengtfss...@amer.company.com,
amerlnxsvcdelaut...@apac.company.com, fnms_...@amer.company.com,
zabbix-supp...@amer.company.com, bladelogic_linux_us...@amer.company.com,
iasnp...@amer.company.com, unv_dba_lo...@amer.company.com,
engit-e...@amer.company.com

simple_allow_users = processehcprofi...@amer.company.com,
svc_prdaut...@amer.company.com, processfogli...@amer.company.com,
svc_prdprofogligh...@amer.company.com, service_ome_li...@amr.company.com,
svc_prdesquadscou...@apac.company.com, admmmiko...@amer.company.com


The offending entry is 'service_ome_li...@amr.company.com'.The Linux SE
fat-fingered that user when doing a realm permit.  Since sssd treats this
as an unknown domain (to sssd), it locks all permitted users and groups.

I've tried to submit this to my OS vendor as a bug, but they claim it's a
'feature'.  Ok, but it would be nice to have a configuration option to
ignore permitted users and groups from unknown realms -- to not lock all
existing permitted users and groups.

Spike
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[SSSD-users] Re: AD site discovery with IPA provider

[Spike White]

Sumit,

AD administrators maintain the relationship between subnet and sites in the
"AD Sites and Services" administrative tool.

They associate particular subnets with a particular site there.  From your
URL, it appears that the client sends its IP address in its CLDAP query.
The AD DC does the subnet math and looks up the matching site in the AD
Sites and Services data  (most specific matches matches first, then more
general).

Our AD team has an ultimate back-stop of 0.0.0.0/1 and 128.0.01/1  (most
general), I think aka "CompanyGeneral".

It sounds like a lot of work, but if they logically group their IP
addresses so that they can use big supranets (say 10.0.0.0/9 for siteA and
10.128.0.0./9 for siteB), it's not so much manual effort.

I would guess that AD sites and services lookups wouldn't work across
forests;  which forest would be authoritative?  If you're searching your
local forest, with ultimate back-stops of above you'd always find a site in
your local forest and never traverse to another forest.

Spike

On Fri, Jun 24, 2022 at 4:22 AM Sumit Bose  wrote:

> Am Thu, Jun 23, 2022 at 10:24:33AM -0600 schrieb Orion Poplawski:
> > The docs seem a little unclear to me on this.  They note what when using
> the
> > AD provider sssd will perform site discovery to find the closest AD
> > controller.  But what about when using the IPA provider?  It seems to me
> like
> > it doesn't, and if not - why not?
>
> Hi,
>
> afaik site discovery does not work across forest boundaries. To my
> knowledge AD DCs determine the site based on IP addresses given out by
> the DCs via DHCP, so only the DC of the domain you are joined to can
> return the site reliable. There is the concept of NextClosestSiteName
> (see MS-ADTS 6.3.3.2
>
> https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/3d71aefb-787e-4d14-9a8a-a70def9e1f6c
> )
> but I'm not sure if this would give more reliable results. Based on this
> we decided that if might be better to set the site explicitly in
> sssd.conf.
>
> Please let me know if you are aware of additional documentation which
> covers sites across forest boundaries.
>
> HTH
>
> bye,
> Sumit
>
> (I posted the same reply to your question in
> https://github.com/SSSD/sssd/issues/5958)
>
> >
> >
> > --
> > Orion Poplawski
> > IT Systems Manager 720-772-5637
> > NWRA, Boulder/CoRA Office FAX: 303-415-9702
> > 3380 Mitchell Lane   or...@nwra.com
> > Boulder, CO 80301 https://www.nwra.com/
>
>
>
> > ___
> > sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> > To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> > Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> > Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[SSSD-users] Re: large multirealm AD deployment, slow id $account / ls -l results

[Spike White]

Mark,

We have tens of thousands of RHEL7/OL7  (sssd 1.16.*)  and RHEL8/OL8
servers connected to a single (multi-domain)  AD forest.

Before RHEL7/OL7, sssd would technically work but you didn't have any of
the good trouble-shooting calls.  So we didn't AD integrate older OS
versions.

In your sssd.conf file, it looks right.  You might add:

[sssd]
...
domains = DOM1.COM
domain_resolution_order = DOM1.com, DOM2.com, DOM3.com
...

I also notice you are using tokengroups (which is the default).  That was a
huge win for enumerating group memberships with nested subgroups.

We originally tried:
ldap_group_nesting_level = 0

But use of tokengroups was better.

It looks like you're letting sssd detect its site and determine its
preferred AD DCs from the details of the site.  (That's how we do it too.)

Do you have all your sites appropriately set up in AD sites & services?
And do you have local AD DCs for each of your DOM1.COM, DOM2.COM, DOM3.COM,
etc?

Spike



On Tue, Jun 7, 2022 at 2:54 PM Mark Christian  wrote:

> On Tue, Jun 7, 2022 at 10:42 AM Gregory Carter 
> wrote:
> >
> > I went with OpenLDAP.  I had AD running for integration with Windows
> users using PowerBroker, but found it hard to justify shutting my linux
> users down when I had to work on a Microsoft product, or vice versa for
> that matter.  Far fewer issues really even though I am running two
> different systems (OpenLDAP/Active Directory) the problem time went away
> trying to get both of them to work. I spend far less time managing two
> separate systems now than trying to get them both to work together.
> >
> > 1.16 is pretty old for something with as much churn as sssd.  I would
> try to stay within at least a year of the current version if you are
> concerned about support issues.
> >
> > I normally get around that sort of thing with the bosses by doing
> extensive testing in the lab before I roll out something not found in my
> RHEL 7 package list.  (i.e. sssd 1.16>)
>
> Agreed, I will be looking at the feasibility of using a more current
> client.
>
> > Diplomacy I found was the best option.  :-)
> >
> > PS: https://bugzilla.redhat.com/show_bug.cgi?id=1984591
>
> Thanks for the bug report which has  "id sssd" taking 7.3 seconds to
> complete and then increasing to ~90 seconds post software update. The
> pre-update time of 7 seconds seems slow to me. Is that the initial,
> first time response?  e.g. once "id sssd" is cached, additional "id
> sssd" operations are near instantaneous, with perhaps a background
> process keeping the cache up to date?   Or do sssd customers expect id
> $account and ls -l large_directory_contents to take a few seconds
> after some inactivity of a few hours?
>
> I'm hoping that a combination of a streamlined, well organized AD or
> equivalent ldap backend, along with a well configured sssd cache will
> give my customers who are used to NIS performance a similar experience
> with an sssd client.
>
> >
> > On Tue, Jun 7, 2022 at 8:41 AM Mark Christian 
> wrote:
> >>
> >> I'm wondering what configuration options I should be tweaking to
> >> improve id to name resolution when running commands such as ls -l, and
> >> id?  My sssd version is 1.16.*, and the sssd configuration consists
> >> of:
> >> [sssd]
> >> domains = DOM1.COM
> >> ...
> >> [nss]
> >> entry_cache_timeout=5400
> >> refresh_expired_interval=4050
> >> ...
> >> [domain/DOM1.COM]
> >> id_provider = ad
> >> auth_provider = ad
> >> ad_enabled_domains = dom1.com, dom2.com, dom3.com, dom4.com
> >> ldap_referrals = false
> >> ldap_id_mapping = false
> >> ldap_access_order = expire
> >> ldap_account_expire_policy = ad
> >> ldap_force_upper_case_realm = true
> >> ldap_group_nesting_level = 0
> >> ldap_use_tokengroups = false
> >> ...
> >> [domain/DOM1.COM/DOM2.COM]
> >> ...
> >> [domain/DOM1.COM/DOM3.COM]
> >> ...
> >> [domain/DOM1.COM/DOM4.COM]
> >> ...
> >>
> >> ldap_user_search_base/ ldap_group_search_base are used to limit which
> >> OUs to query.  But at this moment I'm not able to use the filter
> >> option for these parameters to possibly help performance.  Some
> >> accounts have as many as 250 groups.  enumerating group membership via
> >> "id -G $account" happens quickly enough. Initial name to id mapping is
> >> a bit slow (id $account), but I can tolerate that.  I was hoping that
> >> the refresh_expired_interval setting would keep the entry cache from
> >> "losing" the id to name mappings, but it seems that after some period
> >> of time, running something like ls -l on a directory full of hundreds
> >> of different group owned dirs takes longer than I would like.
> >>
> >> What sssd.conf options should I be considering to keep the id to name
> >> cache from expiring?  What other options or strategies might I
> >> consider to prepopulate the sssd cache?  I'm trying to migrate off a
> >> NIS environment, where name to id mapping is near instantaneous and
> >> I'm hoping sssd might perform as well.  I'm also investigating
> >> re-architecting AD, 

[SSSD-users] Re: Do any commercial NAS vendors use the SSD ID mapping algorithm?

[Spike White]

Ed,

I'm a Linux engineer, reading and learning on this sssd mailing list.  I
had just never seen a large company that used that algorithm that's all.

Spike

On Mon, May 9, 2022 at 2:21 AM  wrote:

> Hey Spike,
>
> I'm curious, why is it you previously said that SSSD based ID mapping is
> only used at small scale?
>
> I understand that it's not using a single source of truth (the directory)
> to provide UID and GID values, but the algorithm is so consistent. I ran a
> test across all our systems in one network today and I couldn't find any
> UIDs which didn't match. We've even got different versions of SSSD
> (different RHEL and Ubuntu releases).
>
>
> Thanks!
> Ed
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[SSSD-users] Re: Do any commercial NAS vendors use the SSD ID mapping algorithm?

[Spike White]

Ed,

That sounds like an excellent plan.  Every major NAS vendor (I work for
one) supports LDAP authentication.   Even against AD domain controllers.

(I'm a Linux engineer, not a storage engineer -- so I don't know the
details of the NAS LDAP auth, only that it's fully supported and used here
internally on the NAS mgmt heads.)

Are you doing NFSv3 or NFSv4?  I believe that NFSv4 bases file/dir access
on 'user@domain', not UIDs.  NFSv3 uses traditional UIDs/GIDs.  I'm
guessing you're doing NFSv3.

(We do NFSv3 from the NAS shares onto our Linux servers whenever possible
ourselves.  We do NFSv4 only when one of the new NFSv4 features is
required.)

Spike

On Wed, May 4, 2022 at 5:21 PM  wrote:

> Thanks Spike!
>
> It looks like extending the AD to cater for UIDs and GIDs is the most
> supported and least effort change to allow us to use any NAS.
>
> If we get approval, we'll likely come up with a system to populate these
> values in the AD from an existing SSSD Linux client so that they match,
> then we can transition all other Linux clients over from using the SSSD
> mapping algorithm to using these values from AD.
>
>
> Ed
>
>
> 4 May 2022 12:26:01 am Spike White :
>
> > Ed,
> >
> > Got this from our AD team:
> >
> > This MS article contains info regarding RFC 2307 and mentions it being
> included in Window 2003 and later.  Hopefully, this helps.
> >
> >
> https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/213f515b-9cf2-43e8-b6c8-47b13cd61281
> >
> > We are currently up to schema version 88 (Windows 2019).
> >
> > Spike
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[SSSD-users] Re: Do any commercial NAS vendors use the SSD ID mapping algorithm?

[Spike White]

Ed,

Got this from our AD team:

This MS article contains info regarding RFC 2307 and mentions it being
included in Window 2003 and later.  Hopefully, this helps.



https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/213f515b-9cf2-43e8-b6c8-47b13cd61281


We are currently up to schema version 88 (Windows 2019).


Spike

On Sun, May 1, 2022 at 11:02 PM  wrote:

> On 30/4/22 8:03 am, Ed wrote:
> >  From what I've read that RFC and the schema extension for AD has been
> deprecated for some time. (Sorry I can't find the link now on my phone but
> I'm confident that it's right)
>
>
> Hi Spike,
>
> Turns out that I might be wrong.  Microsoft pulled their "Identity
> Management for UNIX" product back in 2014 [1] and an article from back
> then [2] states that you could continue to use RFC 2307 GID/UID
> attributes with Active Directory.  I'm struggling to find out if they
> can/should be added to a modern AD in 2022 now.  Do you have any
> information on that or are you using an AD which has been running for
> years?
>
> Thanks!
> Ed
>
> [1]
>
> https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc772571(v=ws.11)?redirectedfrom=MSDN
>
> [2]
>
> https://docs.microsoft.com/en-gb/archive/blogs/activedirectoryua/identity-management-for-unix-idmu-is-deprecated-in-windows-server1
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[SSSD-users] Re: Do any commercial NAS vendors use the SSD ID mapping algorithm?

[Spike White]

Ed,

When you say "uses the SSSD ID mapping algorithm to calculate UID and GID",
do you mean that algorithm that formulaically calculates the user's UID off
the Windows SID?

We are a large company (~25 - 27k sssd clients), but we use the RFC 2307bis
schema extension from Microsoft.  Beaucoup NAS vendors support this,
because they can do LDAP authentication and set their desired LDAP filters
to pull the correct AD object attribute.

I thought that other SSSD algorithm is mainly used in smaller shops.  Where
they didn't want to extend the AD schema.

Spike

On Thu, Apr 28, 2022 at 9:39 PM  wrote:

> Hello,
>
> I work in an enterprise environment which has both Linux and Windows
> systems and an Active Directory for identity.
>
> For good reasons we need to move from Linux based file servers to a NAS.
> The problem is that all our Linux systems use the SSD ID mapping algorithm
> to calculate UID and GIDs (and it works great!). We've not found a
> commercial NAS vendor who supports this algorithm so we can't just drop
> their products in place.
>
> Do you know of any who do please?
>
> Surely there must be some as many NASs run on Linux and BSD and use open
> source software heavily.
>
> My colleague asked this in a GitHub issue [1] but I thought that it might
> be best to ask here.
>
> Thanks in advance!
> Ed.
>
>
> [1]: https://github.com/SSSD/sssd/issues/6126
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[SSSD-users] Re: sssd 1.16.5 gives no results for other domains in the AD Forest

[Spike White]

Any updates on this AD domain under-discovery?

We have SRs open with our OS vendors, but developers on this mailing list
seem far more knowledgeable about the minute details of 'sssd domain
auto-discovery' than the first level of the support queue of our OS vendors.

sssd-*-1.16.5-10.0.1.el7_9.12.x86_64 RPMs do not fix the problem.  The
problem is very easily reproducible;  we have a test box with it exhibiting
this under-discovery.

Spike White

On Thu, Feb 3, 2022 at 11:43 AM Bill Conn  wrote:

> Hello Spike,
>
> Thanks for the info and links.  It looks like rolling back sssd and it's
> associated packages to 1.16.4 might be my best bet until a working update
> is rolled out.  I also took a look at the test rpms on the bugzilla ticket
> and they didn't work for me either.
>
> Bill
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[SSSD-users] Access report not implemented for domains of type ad...

[Spike White]

All,

Occasionally some of our app teams work with external auditors that wish to
verify proper login access to servers.

In our older commercial AD integration tool, they'd just run an "access
report" which would provide all desired information.  I got hit up today to
run an access report for sssd-enabled prod servers.

I saw with great interest the "sssctl access-report" command.


# sssctl access-report amer.company.com

Access report not implemented for domains of type ad

Any plans to implement this access-report subcommand for domains of type
AD?

 No urgency; you  can get most of what's needed via

realm list

and

sssctl user-checks 


Spike
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[SSSD-users] Re: sssd 1.16.5 gives no results for other domains in the AD Forest

[Spike White]

Bill,

Same situation here.  In our case, it's an overarching global AD domain
with 4 regional child domains.  One child domain cannot discover the other
domains.  In specifics, these are the bad sssd versions:

OL7:  1.16.5-10*.0.1*.el7_9.11

RHEL7: 1.16.5-10.el7_9.11


We had to roll back to version 1.16.4 or older and all was good.


It was with interest we read this bugzilla that seems relevant:
https://bugzilla.redhat.com/show_bug.cgi?id=2032867


However we downloaded this test RPM and tried it on this child domain.
It didn't help.


Curiously, other child domains can discover all expected domains.


Spike

On Wed, Feb 2, 2022 at 5:19 PM Bill Conn  wrote:

> I'm working on a university's research cluster with nodes that all run
> CentOS7 and are joined to the school's Active Directory domain.  Our domain
> is part of a statewide forest that contains every state university, and we
> have used this arrangement to grant cluster access to users from other
> Universities to our cluster.
>
> Recently, a user from outside my Universities domain have said they cannot
> log in anymore which caused me to look into this issue.  I found that if I
> issue an id command for a user in a different domain in the forest, it
> gives me the error "no such user".  I know that our setup used to work, and
> after looking into it and trying to replicate the old and new behavior I
> found out that CentOS7 machines with sssd 1.16.4 can get results from other
> domains in the forest, but machines with 1.16.5 cannot.
>
> Is there some setting that changed between these minor versions that would
> cause this?  Is it possible this is not caused by sssd?  I'm testing a node
> with CentOS 7.9.2009 which doesn't return other domains in the forest and a
> node with CentOS 7.7.1908 which does return results from other domains.
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[SSSD-users] Re: kvon in keytab is getting out of sync

[Spike White]

Justin,

if it's https://krbdev.mit.edu/rt/Ticket/Display.html?id=9037 , then it's
even more evil to positively prove than dialing up the sssd debug level.
The min debug level to get verbose adcli update output is debug level 7.
Even running at this debug level for just a few days swamps the /var/log or
other filesystem housing /var/log/sssd/*.

You can fine-tune this in sssd.conf with debug_level = 0x0100 , which gives
just the desired 'adcli update' verbosity with not much else.  And you can
tune the default logrotate.d setting to rotate logs more frequently.

However, this bug is quite infrequent and the adcli update verbosity is
insufficient to determine exactly what's going on.

Ultimately, we have to disable the 30-day  'adcli update' from sssd.conf
and write our own crontab file to fire off every 3-4 days.   In this cron
job that called adcli update, we wrapped this manual adcli update with
tcpdump to get the raw packet capture.  In that way, we were finally able
to get a full packet capture and see this race condition.  We also call
adcli update with KRB5_TRACE enabled, so that we get the full krb5 verbose
output.

Attached is the simple wrapped adcli update shell script that this cron job
calls.

We had to push this cron job out to thousands of servers and update the
machine accounts passwords every 3-4 days to obtain 2-3 failed client
packet captures.  That race condition is that infrequent.
It occurs on 0.3 - 0.4% of all adcli update invocations.

Most all of these ideas we obtained from this sssd mailing list (such as
disabling automatic password renewal and running adcli update as a cron
job).

I'm not convinced that Sebastian's situation is this bug,  so Sebastian
might be able to get away with debug_level = 0x0100 to see what his bug
is.

Spike





On Wed, Jan 19, 2022 at 9:15 AM Justin Stephenson 
wrote:

> Hi,
>
> It sounds like a problem occurs when SSSD executes 'adcli update' to
> renew the machine account password, if successful the AD DC computer
> object password is updated and the new keys are written to the keytab.
> If a failure occurs however it may have caused these two things to go
> out of sync.
>
> You may need to set a high enough 'debug_level' in your
> [domain/$domain] section of sssd.conf then check the adcli output
> written into the domain logs when the issue happens.
>
> -Justin
>
> On Wed, Jan 19, 2022 at 5:40 AM Sebastian Grebe
>  wrote:
> >
> > Hello,
> >
> > we are getting report from users where they suddenly can‘t authenticate
> to their Linux computers anymore. These computers are joint to ore MS
> Domain using adcli und sssd. Checking the log reveals that the kerberos
> tickets stored in  /etc/krb5.keytab do not have the expected KVON. At the
> moment we can’t tell what’s causing the issue. It happens only
> sporadically. I’m under the impression only computer without permanent
> network connection (Laptops) are affected.
> >
> > The log shows:
> >
> > Jan 11 09:30:52 lc015564 systemd[1]: Starting System Security Services
> Daemon...
> > Jan 11 09:30:52 lc015564 sssd[1376]: Starting up
> > Jan 11 09:30:52 lc015564 sssd_be[1609]: Starting up
> > Jan 11 09:30:52 lc015564 sssd_ifp[1633]: Starting up
> > Jan 11 09:30:52 lc015564 systemd[1]: Started System Security Services
> Daemon.
> > Jan 11 09:30:55 lc015564 sssd_be[1609]: Backend is offline
> > Jan 11 09:49:32 lc015564 sssd_be[1609]: Backend is online
> > Jan 11 09:49:41 lc015564 krb5_child[6111]: Cannot find key for
> LC015564$@WAGO.LOCAL kvno 11 in keytab
> > Jan 11 09:49:41 lc015564 krb5_child[6111]: Cannot find key for
> LC015564$@WAGO.LOCAL kvno 11 in keytab
> > Jan 11 09:49:49 lc015564 adcli[6102]: GSSAPI client step 1
> > Jan 11 09:49:49 lc015564 adcli[6102]: GSSAPI client step 1
> > Jan 11 09:49:50 lc015564 adcli[6102]: GSSAPI client step 1
> > Jan 11 10:00:57 lc015564 krb5_child[6838]: Cannot find key for
> LC015564$@WAGO.LOCAL kvno 11 in keytab
> > Jan 11 10:00:57 lc015564 krb5_child[6838]: Cannot find key for
> LC015564$@WAGO.LOCAL kvno 11 in keytab
> >
> > And klist -k shows:
> >
> > Keytab name: FILE:/etc/krb5.keytab
> > KVNO Principal
> > 
> --
> >   10 LC015564$@WAGO.LOCAL
> >   10 LC015564$@WAGO.LOCAL
> >   10 LC015564$@WAGO.LOCAL
> >   10 host/LC015564@WAGO.LOCAL
> >   10 host/LC015564@WAGO.LOCAL
> >   10 host/LC015564@WAGO.LOCAL
> >   10 host/lc015564.wago.local@WAGO.LOCAL
> >   10 host/lc015564.wago.local@WAGO.LOCAL
> >   10 host/lc015564.wago.local@WAGO.LOCAL
> >   10 RestrictedKrbHost/LC015564@WAGO.LOCAL
> >   10 RestrictedKrbHost/LC015564@WAGO.LOCAL
> >   10 RestrictedKrbHost/LC015564@WAGO.LOCAL
> >   10 RestrictedKrbHost/lc015564.wago.local@WAGO.LOCAL
> >   10 RestrictedKrbHost/lc015564.wago.local@WAGO.LOCAL
> >   10 RestrictedKrbHost/lc015564.wago.local@WAGO.LOCAL
> >9 LC015564$@WAGO.LOCAL
> >9 LC015564$@WAGO.LOCAL
> >9 LC015564$@WAGO.LOCAL
> >9 host/LC015564@WAGO.LOCAL
> >9 

[SSSD-users] Re: sssd-1.16.5-10.0.1.el7_9.11.x86_64 is under-discovering AD domains

[Spike White]

Alexey,

Yes -- same bug.

Here's what's cute.  It only occurs on specific child AD domains.  for
instance, APAC (asia pacific) can see only EMEA (Europe-Middle
East-Africa).  Cannot see AMER (Americas).   Consistently, all servers in
that child domain cannot discover (with this new sssd version).

In other AD domains (like AMER), consistently all servers with this new
sssd version do discover all AD domains.  So servers in AMER discover all
expected domains.

Spike



On Tue, Jan 18, 2022 at 12:11 PM Alexey Tikhonov 
wrote:

>
>
> On Tue, Jan 18, 2022 at 5:52 PM Spike White 
> wrote:
>
>> sssd experts,
>>
>> This sssd version (released Tue 23 Nov 2021) is under-discovering AD
>> domains.
>>
>> A similar sssd bug occurred last July, where sssd over-discovered AD
>> domains (AD domains for which there was not a legal trust relationship with
>> this AD domain.)  Now, it appears that sssd is under-discovering AD domains
>> (not discovering AD domains which have a valid trust relationship with this
>> AD domain).
>>
>> Ultimately, an sssd developer on this sssd mailing list (Sumit Rose)
>> resolved the July bug of AD domain over-discovery.   Hopefully, someone
>> will recognize this new AD domain under-discovery bug.
>>
>> We have opened RedHat support case #03124778 for this new AD domain
>> under-discovery bug.  But to be frank, such complicated sssd bugs don’t get
>> resolved by RHEL L1 customer support.  (RHEL customer support is great, but
>> not for complicated sssd bugs.)
>>
>> For now, we have pulled sssd-*-1.16.5-10.0.1.el7_9.11.x86_64 RPMs out of
>> our Jan OS patching cycle.
>>
>
> Please check the description of
> https://bugzilla.redhat.com/show_bug.cgi?id=2032867
> Does it match your issue?
>
> Btw, ".0.1." in "1.16.5-10.0.1.el7_9.11" looks weird. Package version
> should be 1.16.5-10.el7_9.10
>
>
>
>
>
>> Spike
>> ___
>> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
>> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
>> Fedora Code of Conduct:
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
>> Do not reply to spam on the list, report it:
>> https://pagure.io/fedora-infrastructure
>>
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[SSSD-users] sssd-1.16.5-10.0.1.el7_9.11.x86_64 is under-discovering AD domains

[Spike White]

sssd experts,

This sssd version (released Tue 23 Nov 2021) is under-discovering AD
domains.

A similar sssd bug occurred last July, where sssd over-discovered AD
domains (AD domains for which there was not a legal trust relationship with
this AD domain.)  Now, it appears that sssd is under-discovering AD domains
(not discovering AD domains which have a valid trust relationship with this
AD domain).

Ultimately, an sssd developer on this sssd mailing list (Sumit Rose)
resolved the July bug of AD domain over-discovery.   Hopefully, someone
will recognize this new AD domain under-discovery bug.

We have opened RedHat support case #03124778 for this new AD domain
under-discovery bug.  But to be frank, such complicated sssd bugs don’t get
resolved by RHEL L1 customer support.  (RHEL customer support is great, but
not for complicated sssd bugs.)

For now, we have pulled sssd-*-1.16.5-10.0.1.el7_9.11.x86_64 RPMs out of
our Jan OS patching cycle.

Spike
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[SSSD-users] Re: Building sssd RPMs from source for RHEL8....

[Spike White]

Alexey,

Yes, recreate the binary RPMs.  And install  those new binary RPMs on a
RHEL8 test server.

I was interested in testing some code mods.  Now that a recent sssd bugix
has been supplied, it's mainly a curiosity/personal growth sort of question.

Spike

On Wed, Dec 8, 2021 at 12:13 PM Alexey Tikhonov  wrote:

> Hi,
>
> what exactly do you want to achieve?
> Do you want to rebuild binary rpm?
>
> On Wed, Dec 8, 2021 at 3:34 PM Spike White  wrote:
>
>> All,
>>
>> I have reviewed:
>>
>> https://github.com/SSSD/sssd
>> https://sssd.io/
>>
>>
>> And most especially:
>>
>> https://sssd.io/contrib/building-sssd.html
>>
>>
>> In an attempt to build RHEL8 sssd RPMs from  github.com:SSSD/sssd.git.
>>
>> In the past, I have attempted to build RHEL8 RPMs on RHEL8.  That is a
>> fool's errand!  I realize that now, because RHEL is not self-hosting.
>>
>> (I have loads of test RHEL & OL 7 & 8 servers available, no Fedora.)
>>
>> So I have to stand up a Fedora server to build the RHEL 8 RPMs.
>> Currently, Fedora is at Fedora 35 and RHEL8 is based on Fed 28.  Is that
>> ok, or do I have to find Fed 28?
>>
>
> Latest RHEL8 source package:
> https://composes.centos.org/latest-CentOS-Stream-8/compose/BaseOS/source/tree/Packages/sssd-2.5.2-2.el8_5.1.src.rpm
>
> But you need a proper buildroot to rebuild it. I don't think those are
> published. And neither F28 nor F35 match it.
>
>
>>
>> I've reviewed the RHEL9 beta (which is based on Fed 35).  Doesn't seem
>> that different than RHEL8.
>>
>> Spike
>> ___
>> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
>> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
>> Fedora Code of Conduct:
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
>> Do not reply to spam on the list, report it:
>> https://pagure.io/fedora-infrastructure
>>
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[SSSD-users] Building sssd RPMs from source for RHEL8....

[Spike White]

All,

I have reviewed:

https://github.com/SSSD/sssd
https://sssd.io/


And most especially:

https://sssd.io/contrib/building-sssd.html


In an attempt to build RHEL8 sssd RPMs from  github.com:SSSD/sssd.git.

In the past, I have attempted to build RHEL8 RPMs on RHEL8.  That is a
fool's errand!  I realize that now, because RHEL is not self-hosting.

(I have loads of test RHEL & OL 7 & 8 servers available, no Fedora.)

So I have to stand up a Fedora server to build the RHEL 8 RPMs.  Currently,
Fedora is at Fedora 35 and RHEL8 is based on Fed 28.  Is that ok, or do I
have to find Fed 28?

I've reviewed the RHEL9 beta (which is based on Fed 35).  Doesn't seem that
different than RHEL8.

Spike
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[SSSD-users] How to kindly, gently expire bogus cached auto-discovered AD domains?

[Spike White]

All,

This new sssd version for RHEL7  (sssd-1.16.5-10.el7_9.11)  fixes a bug
we’ve seen in sssd.  This bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1984591  .   (Thanks, Sumit!)

We’ve verified this bugfix – that it only auto-discovers the expected
domains now, not the extra domains that it shouldn’t discover.   So how
best to roll out this new bugfixed sssd version?   (We do “no downtime” OS
patching + kernel splicing monthly, so we try to be gentle in our monthly
patching.)

Right now,  the following domains have been auto-discovered:



[root@spikeol73canbo yum.repos.d]# sssctl domain-list

amer.company.com

company.com

emea.company.com

apac.company.com

japn.company.com

EMEAICMD.geodll.company.com

geocompany.company.com

EMEAICM.GEOCOMPANY.COMPANY.COM

alienware.com

corp.svcs

perotsystems.net

companyservices.dmz

Beer.Town

production.online.company.com

jp-poclab.companypoc.com

emea-poclab.companypoc.com

oldev.preol.company.com

olqa.preol.company.com

ap-poclab.companypoc.com

[root@spikeol73canbo yum.repos.d]#



Only the top 5 AD domains are good domains that should be discovered.



When I yum upgrade to this new good sssd version all the above domains are
still cached.   Even if I do ‘sssctl cache-expire -E’, these cached bogus
domains still are not cleaned up.  If I aggressively clear the sssd cache
as so:



systemctl stop sssd

cd /var/lib/sss

rm -rf db/*

rm -f /mc/*

systemctl start sssd



that clears the cache.  But that’s pretty invasive to push out as part of
monthly patching.

1.Is there a kinder, gentler way to expire these bogus cached AD
domains?  Along the lines of sssctl cache-expire -E or sssctl cache-expire
-d ?

2.   If we let this new sssd version sit for 1-2 days, will these bogus
auto-discovered AD domains auto-expire from cache on their own?

Spike
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[SSSD-users] Re: SSSD keeps retrieving LDAP groups while online, degrading performance (no matter what settings I try)

[Spike White]

Sumit,

Good day!  I'm curious about your statement "during authentication".  I
seek clarification.  It's when you said:

 ... until recently SSSD unconditionally updated the group-memberships
of the user *during authentication*.

We do a lot of GSSAPI-based ssh logins.  That is, we acquire a Kerberos
credential up front and then ssh to the Linux server.  The ssh client
(putty or equiv) passes the kerberos credentials and ssh daemon
automatically logs us in.  No passwords.  It's secure because ssh daemon is
verifying the Kerberos identity with KDC (AD controllers).

So effectively, sshd is bypassing the pam "auth" phase for these Kerberized
logins.it is doing the "account" and "session" phase for these logins
only.

Also, we have set up some sudo privs with "NOPASSWD:" flag like so:

% ALL=NOPASSWD: /bin/su

then it appears that sudo is by passing the PAM "auth" phase when these
engineers issue "sudo su -l oracle".   Again, doing the "account" and
"session" phases only.

In these cases, does that mean that sssd is bypassing updating
group-memberships?

Spike

On Tue, Nov 30, 2021 at 9:36 AM Sumit Bose  wrote:

> Am Tue, Nov 30, 2021 at 02:24:34PM - schrieb Robert Wagensveld:
> > Hi all,
> >
> > We've been using SSSD for a while successfully in our Kerberos over
> > LDAP enterprise environment. However, our SSSD online query time,
> > especially over VPN, is very poor, usually each login request or sudo
> > requests takes about 1 minute. There does not seem to be a way around
> > it, not even forcing SSSD to use the cache for a while even when
> > online again.  entry_cache_timeout does not help. Is there anything
> > I'm missing? Some configuration options I do not know about yet?
>
> Hi,
>
> until recently SSSD unconditionally updated the group-memberships of the
> user during authentication. With recent versions of SSSD there is the new
> option pam_initgroups_scheme and SSSD does not update the
> group-memberships if the related user is already logged in. This should
> already help for sudo. To speed up the login as well if the user is not
> already logged in you can set 'pam_initgroups_scheme = never' and SSSD
> will used cached data as long as the cached data is valid.
>
> HTH
>
> bye,
> Sumit
>
> >
> > [sssd]
> > config_file_version = 2
> > services = nss, pam, ifp
> > domains = company.nl
> > debug_level = 9
> > [nss]
> > entry_cache_nowait_percentage = 5
> > filter_groups = root
> > filter_users = root
> > debug_level = 9
> > [pam]
> > offline_failed_login_attempts = 3
> > offline_failed_login_delay = 30
> > debug_level = 9
> > [domain/company.nl]
> > debug_level = 9
> > id_provider = ldap
> > ignore_group_members = true
> > auth_provider = krb5
> > chpass_provider = krb5
> > access_provider = permit
> > cache_credentials = true
> > min_id = 1000
> > entry_cache_timeout = 28800
> > krb5_realm = COMPANY.NL
> > krb5_canonicalize = false
> > krb5_renewable_lifetime = 24h
> > krb5_renew_interval = 6h
> > krb5_server = dc03.company.nl
> > krb5_store_password_if_offline = true
> > krb5_ccname_template = FILE:%d/krb5cc_%U
> > ldap_uri = ldap://dc03.company.nl
> > ldap_search_base = DC=Company,DC=nl
> > ldap_user_search_base = OU=CompanyCompany,DC=nl
> > ldap_group_search_base = OU=Company,DC=Company,DC=nl??
> > ldap_referrals = false
> > enumerate = false
> > ldap_force_upper_case_realm = true
> > ldap_schema = rfc2307bis
> > ldap_id_use_start_tls = false
> > ldap_tls_reqcert = demand
> > ldap_tls_cacert = /etc/ssl/certs/ca-certificates.crt
> > ldap_sasl_canonicalize = true
> > ldap_sasl_mech = GSSAPI
> > ldap_user_object_class = user
> > ldap_user_name = sAMAccountName
> > ldap_user_uid_number = uidNumber
> > ldap_user_gid_number = gidNumber
> > ldap_user_gecos = gecos
> > ldap_user_shell = loginShell
> > ldap_user_home_directory = unixHomeDirectory
> > ldap_user_principal = nonExistingAttribute
> > ldap_group_object_class = group
> > ldap_group_name = cn
> > ldap_group_gid_number = gidNumber
> > ldap_group_member = member
> > ___
> > sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> > To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> > Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> > Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> 

[SSSD-users] Re: Samba filesharing, ssh and sssd

[Spike White]

Answers to questions.

(Notice I said up front that Samba is not my forte.  I answered the
question when it looked like no one else was going to.   I'm glad that my
limited response spurred more full and accurate responses.)

> Might I ask what commercial grade NAS solutions you're using?

Previously, we used early EMC NAS solutions.  They were dicey, as they
tried to maintain one single user permission stack (between CIFS and
NFSv3).  It tried to map between the two and as you stated, the stacks are
considerably different.  They mostly worked, but not 100%.

Now we use a Dell Isilon NAS solution.  It has two totally separate user
permission stacks that the storage engineers have to set up.  One for CIFS
and one for NFS.  But once set up, the stacks operate as expected.   We're
very happy with that solution.  Pretty good performance too.

> Also, how are you able to get permissions on shared filesystems to work
properly with this set up?  I.e., the CIFS Windows mounts will set Windows
ACLs -- do your NFS mounts respect these permissions; i.e. are you using
NFS ACLs on this shares and does this recognize Windows ACLs?

Yes, definitely a problem on those early EMC NAS heads that were trying to
maintain only one security stack and map between Windows ACLs and NFS
ACLs.  Didn't seem to always work that well.  From our Linux engineer
perspective, maintaining two separate security stacks is definitely the way
to go.  (The storage engineers might be less of a fan however.)

> Definitely won't recognize DENYs -- that's not supported by NFSv4 AFAIK.

We do CIFS (mainly for Windows), NFSv3 and basic NFSv4.  Not significant
advanced-feature NFSv4.  I believe the Isilon supports most or all of the
features of NFS v4.1 (but don't quote me on that.) I know we've had to use
some of the mandatory file-locking features of v4.x.   But that's it.

> What's the difference between RFC2307 and RFC2307bis?

This explains it.

https://unofficialaciguide.com/2019/07/31/ldap-schemas-for-aci-administrators-rfc2307-vs-rfc2307bis/

Also, a couple of the specific user attributes have slightly different
names.  I had to consider that when I moved autofs data from NIS to AD:

https://ldapwiki.com/wiki/LDAP%20schema%20used%20by%20autofs

Spike




On Fri, Nov 26, 2021 at 12:01 PM Patrick Goetz 
wrote:

> Just mentioning that as pointed out in the subscriber-walled RHEL
> article, for Samba >= version 4.8, you must run windbind. And don't have
> a choice.  My current Samba + sssd servers use an older version of
> Samba, and this works great. I need to continue to have Samba and I also
> need to retain the sssd UID mappings, so am stuck making this work myself.
>
> For the benefit of the OP, there are a number of people on the Samba
> mailing list who are successfully using sssd and winbind at the same
> time, so it is do-able.  I would check in with that list to see how
> they're doing it.  Otherwise, I have a couple of questions for Spike --
> see below.
>
> On 11/25/21 10:15, Spike White wrote:
> > Harald,
> >
> > I was hoping someone smarter than me would respond; someone who knew the
> > answer.  But no one else did, so let me take a crack at it.   I know the
> > problems and I know the possible approaches to the solution, but I do
> > not know the solution.
> >
> > FYI – we avoid Samba (servers) like the plague at work.  Because the AD
> > integration is so fragile.  We have commercial-grade NAS heads, that
> > talk CIFS to Windows servers and NFS to Linux servers.  If your company
> > can afford it, that’s definitely the way to go.
> >
>
> Might I ask what commercial grade NAS solutions you're using?
>
> Also, how are you able to get permissions on shared filesystems to work
> properly with this set up?  I.e., the CIFS Windows mounts will set
> Windows ACLs -- do your NFS mounts respect these permissions; i.e. are
> you using NFS ACLs on this shares and does this recognize Windows ACLs?
>   Definitely won't recognize DENYs -- that's not supported by NFSv4 AFAIK.
>
>
> > We’re fine with SMB mounts on Linux.  Other than the slight annoyance
> > about username/password having to be put (in clear text) in some creds
> > file, it’s a slam dunk.  (SMB filesystem support is embedded in any
> > recent Linux kernel.)
>
> Yes, but as far as I know CIFS mounts don't respect POSIX extended ACls,
> which is a problem if you're using these for authorization control on
> linux systems.  Not supporting POSIX ACLs would be a deal killer for me,
> unfortunately.
>
> >
> > Anyway, back to Samba server with sssd & sshd.  There’s two fundamental
> > problems:
> >
> > 1.Samba typically uses its own AD integration backend.  Winbind.   Like
> > sssd, winbindd  expects its own machine account created and register

[SSSD-users] Re: Samba filesharing, ssh and sssd

[Spike White]

Harald,

I was hoping someone smarter than me would respond; someone who knew the
answer.  But no one else did, so let me take a crack at it.   I know the
problems and I know the possible approaches to the solution, but I do not
know the solution.

FYI – we avoid Samba (servers) like the plague at work.  Because the AD
integration is so fragile.  We have commercial-grade NAS heads, that talk
CIFS to Windows servers and NFS to Linux servers.  If your company can
afford it, that’s definitely the way to go.

We’re fine with SMB mounts on Linux.  Other than the slight annoyance about
username/password having to be put (in clear text) in some creds file, it’s
a slam dunk.  (SMB filesystem support is embedded in any recent Linux
kernel.)

Anyway, back to Samba server with sssd & sshd.  There’s two fundamental
problems:

1.   Samba typically uses its own AD integration backend.  Winbind.
Like sssd, winbindd  expects its own machine account created and registered
in the back-end AD domain.  That machine account will (usually) conflict
with sssd’s machine account. sssd stores its machine account password in
/etc/krb5.keytab file.  Samba usually stores its machine account password
in a secrets.tdb file.



2.   The particular UID mapping that is in use for sssd may not be
supported by winbind.  For instance, at work we use Microsoft’s RFC 2307bis
AD schema extension, which associates UNIX attributes with each user and
group account.  Not sure if winbind supports this method of UID mapping.

Anyway, those are the two main problems.   Let’s first explore the
solutions to problem #1.

1.   You can register sssd under one machine account (maybe the
server’s FQN) and then register winbindd under another machine account.
This is conceptually the simplest approach; you have two totally different
AD integration stacks.  One for ssh and login (sssd + AD backend) and then
another stack for samba server (i.e., winbindd).  Thus, every 30 days sssd
will update its machine account password and store it in the
/etc/krb5.keytab file.  Also, every 30 days, winbindd will also update its
(own different) machine account password and store it in its secrets.tdb
file.



2.   You register to AD using adcli’s –add-samba-data flag (and
possibly –samba-data-tool*=/path/to/net*). So then every 30 days, sssd will
call adcli to update its machine account password.You have to add to
your sssd.conf file ad_update_samba_machine_account_password=true.   So
that sssd every 30 days calls adcli update with the correct flags.  You
also have to inform samba (or winbindd) not to update its machine account
password every 30 days.In that way, when sssd calls adcli update every
30 days to update its machine account password, it stores the new password
in /etc/krb5.keytab file and in the samba secrets.tdb file.  You are still
running two AD integration stacks, but now you have just one machine
account.



You might look at https://access.redhat.com/discussions/3646491 .Looks
like they’re successfully doing a variant of this.  They’re instructing
both sssd and samba to not update the machine account password.  Then they
run a cron job every 30 days to call adcli update to update both the
/etc/krb5.keytab file and the secrets.tdb file.



3.   Have samba use sssd for its AD integration back-end, instead of
winbindd.This is actually how we did it at work years ago, when we had
to have a samba server.  (This was pre-sssd, a commercial AD integration
product.)  sssd (& this commercial product) offers a “idmap” shim so that
samba thinks it’s talking to a winbindd back-end.  But really it’s talking
to sssd (or the commercial AD integration product).
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/windows_integration_guide/smb-sssd
discusses use of this idmap_sss module, as does
https://access.redhat.com/solutions/3802321  (you have to have a RH
subscription to read this second link).

There are limitations of this approach.  They are discussed in the first
link and also in
https://www.thegeekdiary.com/choosing-sssd-or-winbind-samba-for-active-directory-integration-in-centos-rhel/
.



Let’s next explore the solutions to problem #2.  Here is where I’m weak.
We used solution #3 above, so then problem #2 disappeared.  (Since sssd’s
AD backend is handling all the UID mapping, then as long as your AD UID
mapping scheme is one supported by sssd-ad, you’re golden).  If you do
solution #1 or #2 above, you have to check your Samba documentation to
ensure your particular AD UID mapping scheme is accepted.

I know I’ve set up a Samba server with an LDAP server back-end and I had to
diddle some of the "AD attributes to UNIX ID attribute" mappings in the
conf file.   (the Samba server had support for RFC2307 mapping, but not
RFC2307bis.  They’re very close but not identical).

Spike White





On Tue, Nov 23, 2021 at 9:36 AM Harald 11  wrote:

> Hello!
>
> I am using sssd 2.4 with De

[SSSD-users] Re: SSSD and Kerberos-related problems during joining a RHEL8.4-host to AD

[Spike White]

Yeah,

When 'kinit -k' is failing, you have really fundamental Kerberos failures
going on.  It's not even involving sssd at that point.  Usually,
1. your entries in /etc/krb5.keytab file are stale or wrong, or
2. it can't find or access your AD DCs or
3. other DNS problems.

You can run 'kinit -k' in debug mode (export KRB5_TRACE=/tmp/krb5.out) and
view that debug file to see more specifics about the specific failure.

For instance, we have two Linux VMs in a cloud provider now where the AD
integration is misbehaving.  kinit -k is failing.  From the debug log of
'kinit -k', we can tell it's the DNS discovers of the AD DCs that's
failing.  Turns out, it's a stealth MTU problem.

I believe until recently, sssd didn't support storing its kerberos creds in
the KCM, so your particular error condition is not one I've run across yet.

Glad to hear your problem is resolved.

Spike

On Fri, Nov 19, 2021 at 5:55 AM Aron Kelemen Szabo <
aron.kele...@stralfors.se> wrote:

> Hi again!
>
>
>
> I think I have found the problem! 
>
>
>
> kinit -k returned the following error:
>
> kinit: Connection refused while getting default ccache
>
> …while kvno -S host TEST0003 returned the following error:
>
> kvno: Connection refused while opening ccache
>
>
>
> A bit of googling on these error messages revealed that the culprit might
> be the KCM-service not running... When googling a bit on the error messages
> thrown by kinit and kvno and issuing the following commands revealed that
> this was indeed the case.
>
> systemctl status sssd-kcm.socket
>
> systemctl status sssd-kcm.service
>
>
>
> I came across this error report which among other things recommends
> upgrading the packages:
> https://bugzilla.redhat.com/show_bug.cgi?id=1716981
>
>
>
> So I run a “yum update” and re-joined the host to the realm, and now the
> AD-logons seem to be working fine! Now I “only” need to find out the very
> happening that rendered KCM to fail. :-)
>
>
>
> Thanks for all your input again!
>
>
>
> Best regards,
>
> Áron
>
>
>
>
>
> *From:* Spike White 
> *Sent:* den 18 november 2021 18:46
> *To:* End-user discussions about the System Security Services Daemon <
> sssd-users@lists.fedorahosted.org>
> *Subject:* [SSSD-users] Re: SSSD and Kerberos-related problems during
> joining a RHEL8.4-host to AD
>
>
>
> Aron,
>
>
>
> Several things.Some backgroun -- in our company, we have thousands of
> OL8.x and hundreds of RHEL 8.x Linux servers directly AD integrated to our
> corp AD domain.
>
>
>
> I compared our sssd.conf with yours.  I think you want to add the 'ifp'
> service for *L8.  It's the infopipe service.  Used by support utilities
> such as sssctl domain-list, etc.
>
>
>
> I thought you had to have a sssd.conf stanza for each service you enable.
> For instance, we have this:
>
>
>
> [nss]
> debug_level = 0x0100
> #debug_level = 9
> filter_groups = root
> filter_users = root
>
> [pam]
> pam_verbosity = 3
> #debug_level = 9
> offline_credentials_expiration = 3
>
> [ifp]
>
>
>
> Because we have
>
> [sssd]
>
> ...
>
> services = nss,pam,ifp
>
>
>
>
>
> From your ldap_child.log, it looks like your SASL bind and then the LDAP
> query is working.  Which is surprising to me.  We set up
>
>
>
> ldap_sasl_authid = host/@
>
>
>
> in our sssd.conf file.  But I'm guessing if that's not explicitly set, it
> uses HOSTNAME$@REALM.  At least that's what it appears from your
> ldap_child.log. It appears to use:  TEST0003$@ourlab.se
> <https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fourlab.se%2F=04%7C01%7Caron.kelemen%40stralfors.se%7Cee4423c7606c4b41204308d9aabb6635%7C91f09566a8504faebbe129ad3804a2f6%7C1%7C1%7C637728544138573813%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=aOUkFrUQ067nE%2BpYXJ5S2o%2BnFBsq81bT%2FohpsjkPX50%3D=0>
>
>
>
> Several things to try to narrow down where the failure is occuring.
>
> 1. try 'kinit -k'  on the command line.   That uses the first entry in
> /etc/krb5.keytab file to attempt to authenticate as this machine account.
> It's not a perfect test, since it's acquiring a TGT ticket instead of a
> service ticket.
>
> 2. If that succeeds, try kvno -S host TEST0003
>
>  That should report the KVNO of your machine account credentials, as
> stored in AD.  This is a better test, as you're acquiring a service ticket
> here.  (Like sssd does).
>
> 3. Try 'adcli testjoin -D ourlab.se
> <https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fourlab.se%2F=04%7C01%7Caron.kelemen%40stralfors.se%7Cee4423c7606c4b41204

[SSSD-users] Re: SSSD and Kerberos-related problems during joining a RHEL8.4-host to AD

[Spike White]

Aron,

Several things.Some backgroun -- in our company, we have thousands of
OL8.x and hundreds of RHEL 8.x Linux servers directly AD integrated to our
corp AD domain.

I compared our sssd.conf with yours.  I think you want to add the 'ifp'
service for *L8.  It's the infopipe service.  Used by support utilities
such as sssctl domain-list, etc.

I thought you had to have a sssd.conf stanza for each service you enable.
For instance, we have this:

[nss]
debug_level = 0x0100
#debug_level = 9
filter_groups = root
filter_users = root

[pam]
pam_verbosity = 3
#debug_level = 9
offline_credentials_expiration = 3

[ifp]

Because we have
[sssd]
...
services = nss,pam,ifp


>From your ldap_child.log, it looks like your SASL bind and then the LDAP
query is working.  Which is surprising to me.  We set up

ldap_sasl_authid = host/@

in our sssd.conf file.  But I'm guessing if that's not explicitly set, it
uses HOSTNAME$@REALM.  At least that's what it appears from your
ldap_child.log. It appears to use:  TEST0003$@ourlab.se

Several things to try to narrow down where the failure is occuring.
1. try 'kinit -k'  on the command line.   That uses the first entry in
/etc/krb5.keytab file to attempt to authenticate as this machine account.
It's not a perfect test, since it's acquiring a TGT ticket instead of a
service ticket.
2. If that succeeds, try kvno -S host TEST0003
 That should report the KVNO of your machine account credentials, as
stored in AD.  This is a better test, as you're acquiring a service ticket
here.  (Like sssd does).
3. Try 'adcli testjoin -D ourlab.se -v'.  This tests the sssd connectivity,
similar to how sssd does it.

if all that works, your problem is not with LDAP or your SASL binding.  So
then,

4. try 'getent passwd aron.kele...@ourlab.se'.  That should return the
entry for this user.  If this fails, possibly your /etc/nsswitch.conf file
isn't set up right or maybe your attribute mapping in AD isn't agreeing
with your sssd.conf setting.  (We use the MS-supported RFC2307bis AD schema
extension)..

5. If that's good, then probably the problem is something in your PAM
stack.  Specifically, the auth phase.   In our /etc/pam.d/sshd file, we
have:

#%PAM-1.0
auth   substack password-auth
auth   include  postlogin
...

and in password-auth, we have:

authrequired pam_env.so
# OL7/8 version. Per I/T's stated policy for service & process accounts,
lock-out time = 30 mins
authrequired pam_faillock.so
preauth silent deny=5 unlock_time=1800
authsufficient   pam_sss.so
forward_pass
authsufficient   pam_unix.so nullok
try_first_pass
authrequisitepam_succeed_if.so
uid >= 1000 quiet_success
authrequired pam_faillock.so
authfail deny=5 unlock_time=1800
authrequired pam_deny.so


Spike






On Thu, Nov 18, 2021 at 7:16 AM Aron Kelemen Szabo <
aron.kele...@stralfors.se> wrote:

> Hello!
>
>
>
> We are trying to join a RHEL8.4-server to our Active Directory with the
> realm name ourlab.se.
>
>
>
> Our first attempt was to follow the RedHat-guide (
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/integrating_rhel_systems_directly_with_windows_active_directory/connecting-rhel-systems-directly-to-ad-using-sssd_integrating-rhel-systems-directly-with-active-directory#discovering-and-joining-an-ad-domain-using-sssd_connecting-directly-to-ad)
> to join RHEL8.4 to an AD, also covering the installation and configuration
> of SSSD and the machine seem to have got joined to the AD (the computer
> account appears and both adcli info ourlab.se as well as the id
> usern...@ourlab.se commands return valid lookup-results from the Active
> Directory)… The TGT also seems to be fetched successfully.
>
>
>
> However, we cannot log on to the system with any AD-account and
> /var/log/sssd/krb5_child.log contains the errors below (please view the
> attached log-files for a complete log-listing), hitting the critical
> failure (SSSDBG_CRIT_FAILURE), emitting the internal error
> “[111][Connection refused]” already at the call to the function
> krb5_cc_cache_match(), called from the function create_ccache():
>
>
>
> (2021-11-18 11:02:16): [krb5_child[3585]] [sss_send_pac] (0x0080): failed
> to contact PAC responder
>
> (2021-11-18 11:02:16): [krb5_child[3585]] [validate_tgt] (0x0040):
> sss_send_pac failed, group membership for user with principal
> [aron.kelemen\@ourlab...@ourlab.se] might not be correct.
>
> (2021-11-18 11:02:16): [krb5_child[3585]] [sss_child_krb5_trace_cb]
> (0x4000): [3585] 1637229736.192904: Destroying ccache MEMORY:rd_req2
>
>
>
> (2021-11-18 11:02:16): [krb5_child[3585]] [get_and_save_tgt] (0x2000):
> Running as [285279201][285200513].
>
> (2021-11-18 11:02:16): 

[SSSD-users] Re: System Error (4) SSSD + Smartcard + NIS

[Spike White]

Leon,

Granted we're not doing NIS + SSSD on OL8.  Only RHEL6/7 and OL6/7.

But where we do NIS + SSSD,   we're putting NIS in /etc/nsswitch.conf.
Something like:

passwd: files sss nis
group:  files sss nis
netgroup:   files sss
automount:  sss files

This is from a OL7 server running NIS + sssd (AD backend).

Instead of setting up a NIS domain in sssd.conf file.

Spike

On Wed, Nov 10, 2021 at 3:21 PM Alexey Tikhonov  wrote:

> On Wed, Nov 10, 2021 at 5:29 PM Leon Castellano
>  wrote:
> >
> > Hello Users,
> >
> > I'm hoping with your ample expertise you may be able to help me figure
> out how to fix the issue I'm running into.
> >
> > A bit of background for context: I'm a sysadmin with NASA out of GSFC
> where we manage many legacy systems still using NIS. We cannot get rid of
> NIS or replace it with FreeIPA/LDAP/AD/etc. It would affect systems
> currently processing data coming down from space craft, labs, etc.
> >
> > We're currently in the process of adopting Oracle Linux 8 as the default
> OS for our workstations and servers. As part of this process, I need to be
> able to:
> >
> > 1) Bind to NIS for the passwd/group/netgroup DBs
> > 2) Use smartcard for SSH/GDM/Console access
> >
> > Prior to OL8 we've been relying on NIS + PAM + "pam_pkcs11.so" and that
> has worked well enough for most of our needs.
> >
> > However, with RH8/OL8 focusing primarily on SSSD, I've been trying to
> switch us to it.
> >
> > So far I've managed to get smartcard auth to work when the user is local
> (files), but when the user is coming from NIS,
>
> In your `sssd.conf`:
> ```
> [domain/nis]
> auth_provider = none
> ```
>   --  I guess that's why 'SSS_PAM_AUTHENTICATE' sent by sssd_pam to
> sssd_be[nis] fails:
> ```
> [pam] [pam_print_data] (0x0100): command: SSS_PAM_AUTHENTICATE
> ...
> [pam] [pam_dp_send_req_done] (0x0020): PAM handler failed
> [1432158215]: DP target is not configured
> ```
>
> Who is expected to do auth in your setup?
>
> In the case of local users, everything (matching/mapping of
> certificate on the smart card to a user and then verification that the
> card really has a private key that corresponds to public certificate)
> is done by SSSD.
> In the case of IPA/AD users, SSSD performs matching/mapping, but
> actual authentication is done by Kerberos PKINIT mechanism.
>
> It looks like you expect the former for your use case (please correct
> me if I'm wrong).
> But this is only supported for sssd_be[files], I don't know how to mix
> 'files' and 'nis'. I don't think sssd_be[files] support '+' NIS style
> entries in /etc/passwd...
>
>
>
> > I am getting the following error from gdm-smartcard (REDACTED = my
> username) in sssd_pam.log:
> >
> > (2021-11-09 19:34:12): [pam] [sbus_dispatch] (0x4000): Dispatching.
> > (2021-11-09 19:34:12): [pam] [cache_req_search_cache] (0x0400): CR #12:
> Looking up [REDACTED@nis] in cache
> > (2021-11-09 19:34:12): [pam] [ldb] (0x1): Added timed event
> "ldb_kv_callback": 0x5598d1f410b0
> >
> > (2021-11-09 19:34:12): [pam] [ldb] (0x1): Added timed event
> "ldb_kv_timeout": 0x5598d1f5e390
> >
> > (2021-11-09 19:34:12): [pam] [ldb] (0x1): Running timer event
> 0x5598d1f410b0 "ldb_kv_callback"
> >
> > (2021-11-09 19:34:12): [pam] [ldb] (0x1): Destroying timer event
> 0x5598d1f5e390 "ldb_kv_timeout"
> >
> > (2021-11-09 19:34:12): [pam] [ldb] (0x1): Destroying timer event
> 0x5598d1f410b0 "ldb_kv_callback"
> >
> > (2021-11-09 19:34:12): [pam] [ldb] (0x1): Added timed event
> "ldb_kv_callback": 0x5598d1f5c4f0
> >
> > (2021-11-09 19:34:12): [pam] [ldb] (0x1): Added timed event
> "ldb_kv_timeout": 0x5598d1f410b0
> >
> > (2021-11-09 19:34:12): [pam] [ldb] (0x1): Running timer event
> 0x5598d1f5c4f0 "ldb_kv_callback"
> >
> > (2021-11-09 19:34:12): [pam] [ldb] (0x1): Destroying timer event
> 0x5598d1f410b0 "ldb_kv_timeout"
> >
> > (2021-11-09 19:34:12): [pam] [ldb] (0x1): Destroying timer event
> 0x5598d1f5c4f0 "ldb_kv_callback"
> >
> > (2021-11-09 19:34:12): [pam] [ldb] (0x1): Added timed event
> "ldb_kv_callback": 0x5598d1f410b0
> >
> > (2021-11-09 19:34:12): [pam] [ldb] (0x1): Added timed event
> "ldb_kv_timeout": 0x5598d1f43580
> >
> > (2021-11-09 19:34:12): [pam] [ldb] (0x1): Running timer event
> 0x5598d1f410b0 "ldb_kv_callback"
> >
> > (2021-11-09 19:34:12): [pam] [ldb] (0x1): Added timed event
> "ldb_kv_callback": 0x5598d1f632e0
> >
> > (2021-11-09 19:34:12): [pam] [ldb] (0x1): Added timed event
> "ldb_kv_timeout": 0x5598d1f633b0
> >
> > (2021-11-09 19:34:12): [pam] [ldb] (0x1): Destroying timer event
> 0x5598d1f43580 "ldb_kv_timeout"
> >
> > (2021-11-09 19:34:12): [pam] [ldb] (0x1): Destroying timer event
> 0x5598d1f410b0 "ldb_kv_callback"
> >
> > (2021-11-09 19:34:12): [pam] [ldb] (0x1): Running timer event
> 0x5598d1f632e0 "ldb_kv_callback"
> >
> > (2021-11-09 19:34:12): [pam] [ldb] (0x1): Added timed event
> "ldb_kv_callback": 0x5598d1f43580
> >
> > (2021-11-09 19:34:12): [pam] [ldb] 

[SSSD-users] Re: SSSD entry_cache_nowait_percentage/ enum_cache_timeout not working properly?

[Spike White]

Alexey,

I'm not going to speak for another, but for us -- enumeration is a
wonderful tool for troubleshooting login/access issues.  Even though it's a
performance hit, we'll accept that hit, in exchange for the ability of the
support engineers to be able to enumerate sssd's idea of group membership.

Spike

On Wed, Oct 27, 2021 at 4:19 AM Alexey Tikhonov  wrote:

>
>
> On Mon, Oct 18, 2021 at 1:27 PM Robert Wagensveld <
> robertwagensv...@live.nl> wrote:
>
>> Is this a hard question?
>>
>
> It is an unclear question.
>
> What the actual problem is and why do you need enumeration to be enabled?
>
>
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[SSSD-users] Re: SSSD entry_cache_nowait_percentage/ enum_cache_timeout not working properly?

[Spike White]

This sounds very familiar to something we recently encountered.

Are you having login/sudo times on the order of 3-5 mins?  did this start
around the July time frame?  Do you have additional untrusted lab AD
domains used for testing? Are those lab domains possibly inaccessible to
particular servers?  Does sssctl domain-list show additional domains more
than the expected trusted domains?

Spike

On Fri, Oct 8, 2021 at 2:42 AM Robert Wagensveld 
wrote:

> Hi all, I was hoping you could help me with this, as I am essentially
> clueless by this point.Even setting debug logging to 8 does not give much
> information as to what the problem might be.
> I have chosen to set the enum_cache_timeout to a high value, e.g. 26000
> seconds. This because we have a very large environment in terms of AD
> groups (we use Kerberos over LDAP) and this takes a long time to retrieve
> all groups. Weird part is, although this helped on some clients, it does
> not actually reduce login/sudo times on others. I have set the following
> values in sssd.conf:
> entry_cache_nowait_percentage = 50
> entry_cache_timeout = 60
>
> My reason for this is that defining a value for the nowait percentage
> automatically update entries in the background. Not sure if I set the
> percentage rights though. https://linux.die.net/man/5/sssd.conf
> What is wise to do in this regard? My desired behavior would be that it
> returns entries from cache even while offline as often as possible, and
> updates the cache in the background. I don't want users to have to wait for
> SSSD to iterate through all our insane amounts of groups in the foreground.
>
> Thanks in advance!
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[SSSD-users] Re: sss_ssh_authorizedkeys returning "Error looking up public keys"

[Spike White]

Phillip,

By no means do I pretend to be an expert on building sssd.  I fully realize
how there's dozens, probably a hundred of prereq pkgs that have to be
installed.  In order to have the proper build env for sssd.  Even more if
you wish to package up into RPMs.

I particularly don't pretend to be an expert in building on Ubuntu.

But I did run across this page.  https://sssd.io/contrib/building-sssd.html,
Go mid-way down and it has a 'Ubuntu' tab.See if that helps.

Spike

On Thu, Oct 7, 2021 at 2:47 AM Philip Colmer 
wrote:

> We are using Ubuntu 18.04 with sssd 1.16.1-1ubuntu1.8.
>
> sssd is being used to allow users to sign in with SSH keys matched against
> keys stored in OpenLDAP. This has been used for several years but, just
> recently, a couple of users were reporting that they could not SSH to the
> server. Further investigation showed that running "sss_ssh_authorizedkeys"
> for these specific users returned "Error looking up public keys". The tool
> continues to work correctly for other users.
>
> I cannot find any information that might suggest why the tool is not
> managing to get the keys for these users.
>
> I have tried building the code from the GitHub source but it errors out
> with this:
>
> In file included from ./src/util/sss_pam_data.h:33:0,
>  from src/util/sss_pam_data.c:27:
> ./src/util/debug.h:92:44: error: unknown type name ‘uid_t’; did you mean
> ‘__id_t’?
>  int chown_debug_file(const char *filename, uid_t uid, gid_t gid);
> ^
> __id_t
> ./src/util/debug.h:92:55: error: unknown type name ‘gid_t’; did you mean
> ‘__id_t’?
>  int chown_debug_file(const char *filename, uid_t uid, gid_t gid);
>^
>__id_t
> Makefile:22359: recipe for target
> 'src/util/libsss_util_la-sss_pam_data.lo' failed
>
> Can anyone suggest how I can troubleshoot this tool in order to fix the
> error or how I can get it to build on Ubuntu?
>
> Thanks.
>
> Philip
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[SSSD-users]Re: Trouble-shooting sssd’s ‘Automatic Kerberos Host Keytab Renewal’ with AD back-end….

[Spike White]

Patrick,

Oh, I know the answer to that one!

if you're also binding in Samba to winbindd or equivalent, then when sssd
renews the machine account passwords monthly it also has to inform samba of
that new machine account password.  So that it can stash it away in its
secrets store.

I believe that Samba even provides some helper script or program that you
can call -- passing in the new monthly password.  So adcli update could
call such a Samba heiper script.

Spike

On Fri, Oct 8, 2021 at 8:58 AM Patrick Goetz  wrote:

>
>
> On 10/7/21 12:01, Spike White wrote:
> > FYI -- update on this situation.
> >
> > AD DC logs no help.  They show the exact same response sent back to a
> > good machine account password renewal as for a failed renewal.
> >
> > One of the AD administrators have identified a particular AD DC NIC
> > teaming configuration that they state has caused problems with Kerberos
> > on the past.  It's on a small percentage of their AD DCs and they will
> > work to correct.  They will keep us apprised as to update.
> >
> > I'm skeptical that's the underlying root cause -- for two reasons:
> > 1.  If Kerberos was sensitive to this, it should affect all Kerberos
> > operations  (Kerberos auth, etc.) and not just the kpasswd operations.
> > 2. This is not occurring on our older RHEL6 and RHEL7 builds AD
> > integrated via our older commercial AD integration product.  It's
> > occurring only on our sssd-integrated builds.
> >
> > At this point, we're turned off debug level 7 (it was filling up our
> > /var/log filesystems and we have the verbose adcli update output from at
> > least two failed clients).   We're going to take the alternate
> > suggestion of setting ad_maximum_machine_account_password_age to 0
> > (disabling sssd from updating password) and run a cron job to do 'adcli
> > update'.
> >
> > We're wrapping this adcli_update with tcpdump to get the exact kpasswd
> > request/response packets, as well as wrapping with KRB5_TRACE.
> >
> > We want to call adcli update exactly as sssd calls it.
> > From SOURCES/sssd-2.4.0/src/providers/ad/ad_machine_pw_renewal.c, this
> > appears to be how sssd calls external program /usr/sbin/adcli to do its
> > adcli update:
> >
> >/usr/sbin/adcli update --verbose --domain=$AD_DOMAIN
> > --host-keytab=/etc/krb5.keytab --host-fqdn=$FQDN
> > --computer-password-lifetime=30
> >
> > because we aren't doing any Samba stuff.
>
>
> Question: how would Samba stuff be relevant to updating the Kerberos
> ticket using adcli?
>
>
>
>Is that the correct
> > invocation?   We'll set computer-password-lifetime lower, say to 7.
> > Because we want to see examples more frequently, to find failed updates.
> >
> > BTW, the packet capture on a successful machine account password renewal
> > is only 8K, so that very targeted debug will not swamp our /var/log or
> > /tmp filesystems.
> >
> > Spike
> >
> > On Wed, Aug 25, 2021 at 10:32 AM Spike White  > <mailto:spikewhit...@gmail.com>> wrote:
> >
> > Sssd experts,
> >
> > *_Short summary:_//* How can we troubleshoot sssd’s ‘Automatic
> > Kerberos Host Keytab Renewal’ process?We have ~0.4% of our Linux
> > servers dropping off the AD domain monthly.
> >
> > *_Longer explanation:_*
> >
> > Over the past two years, we have on-boarded sssd as our Linux AD
> > integration component.  Largely displacing a former commercial
> > product that did the same.
> >
> > We have about ~20K Linux servers that are sssd-enabled.  A mix of
> > RHEL6, RHEL7, RHEL8, Oracle Linux 6, 7 and 8.   We have ~7K Linux
> > servers still on the old commercial product.  (For certain edge-case
> > scenarios, such as DMZs, the commercial product works better.)
> >
> > Our AD forest is a single AD forest, with 4 regional child domains.
> > All with transitive trust.  Sssd auto-discovers parent domain and
> > all 4 child domains, no problem – whenever it’s adcli joined to its
> > regional local domain.
> >
> > Why are I writing this?
> >
> > Because we are researching an ongoing problem reported by L1 server
> > ops.  About 70 – 80 sssd-enabled Linux servers / month drop off the
> > domain.  Out of our current sssd-enabled population of ~20K server,
> > that’s not horrible.  But still it should be better.  (Our former
> > commercial product did better.)
> >
> > It’s not limited to one particular OS, OS version, build location 

[SSSD-users]Re: https://bugzilla.redhat.com/show_bug.cgi?id=1984591 not understanding the nature of the sssd bug introduced recently…

[Spike White]

Sumit,

It appears I spoke too soon.  Yes, properly it does not discover those
untrusted AD domains (i.e., one way trust -- the wrong way).But it also
does not discover a couple of the expected trusted domains.

I see this in the sssd_amer.company.com.log when turning on debug level 9:

(2021-10-08 18:31:10): [be[amer.company.com]]
[ad_create_2way_trust_options] (0x0400): 2way trust is defined to domain '
company.com'
(2021-10-08 18:31:10): [be[amer.company.com]]
[ad_create_2way_trust_options] (0x0400): 2way trust is defined to domain '
emea.company.com'
...
(2021-10-08 18:31:11): [be[amer.company.com]] [ad_subdomains_process]
(0x0400): Enabling subdomain japn.company.com
(2021-10-08 18:31:11): [be[amer.company.com]] [ad_subdomains_process]
(0x0400): Enabling subdomain amer.company.com
(2021-10-08 18:31:11): [be[amer.company.com]] [ad_subdomains_process]
(0x2000): Not including primary domain amer.company.com in the subdomain
list
(2021-10-08 18:31:11): [be[amer.company.com]] [ad_subdomains_process]
(0x0400): Enabling subdomain emea.company.com
(2021-10-08 18:31:11): [be[amer.company.com]] [ad_subdomains_process]
(0x0400): Enabling subdomain apac.company.com
(2021-10-08 18:31:11): [be[amer.company.com]] [ad_filter_domains] (0x0200):
TRUST_ATTRIBUTE_WITHIN_FOREST not set for [japn.company.com].
(2021-10-08 18:31:11): [be[amer.company.com]] [ad_filter_domains] (0x0200):
TRUST_ATTRIBUTE_WITHIN_FOREST not set for [emea.company.com].
(2021-10-08 18:31:11): [be[amer.company.com]] [ad_filter_domains] (0x0200):
TRUST_ATTRIBUTE_WITHIN_FOREST not set for [apac.company.com].
...
(2021-10-08 18:31:11): [be[amer.company.com]] [ad_filter_domains] (0x0200):
TRUST_ATTRIBUTE_WITHIN_FOREST not set for [EMEAICMD.geodll.company.com].
(2021-10-08 18:31:11): [be[amer.company.com]] [ad_filter_domains] (0x0200):
TRUST_ATTRIBUTE_WITHIN_FOREST not set for [geocompany.company.com].
(2021-10-08 18:31:11): [be[amer.company.com]] [ad_filter_domains] (0x0200):
TRUST_ATTRIBUTE_WITHIN_FOREST not set for [EMEAICM.GEOCOMPANY.COMPANY.COM].
(2021-10-08 18:31:11): [be[amer.company.com]] [ad_filter_domains] (0x0200):
TRUST_ATTRIBUTE_WITHIN_FOREST not set for [alienware.com].
(2021-10-08 18:31:11): [be[amer.company.com]] [ad_filter_domains] (0x0200):
TRUST_ATTRIBUTE_WITHIN_FOREST not set for [corp.svcs].
(2021-10-08 18:31:11): [be[amer.company.com]] [ad_filter_domains] (0x0200):
TRUST_ATTRIBUTE_WITHIN_FOREST not set for [perotsystems.net].
(2021-10-08 18:31:11): [be[amer.company.com]] [ad_filter_domains] (0x0200):
TRUST_ATTRIBUTE_WITHIN_FOREST not set for [companyservices.dmz].
(2021-10-08 18:31:11): [be[amer.company.com]] [ad_filter_domains] (0x0200):
TRUST_ATTRIBUTE_WITHIN_FOREST not set for [Beer.Town].
(2021-10-08 18:31:11): [be[amer.company.com]] [ad_filter_domains] (0x0200):
TRUST_ATTRIBUTE_WITHIN_FOREST not set for [production.online.company.com].
(2021-10-08 18:31:11): [be[amer.company.com]] [ad_filter_domains] (0x0200):
TRUST_ATTRIBUTE_WITHIN_FOREST not set for [jp-poclab.companypoc.com].
(2021-10-08 18:31:11): [be[amer.company.com]] [ad_filter_domains] (0x0200):
TRUST_ATTRIBUTE_WITHIN_FOREST not set for [japn.company.com].
(2021-10-08 18:31:11): [be[amer.company.com]] [ad_filter_domains] (0x0200):
TRUST_ATTRIBUTE_WITHIN_FOREST not set for [apac.company.com].
(2021-10-08 18:31:11): [be[amer.company.com]] [ad_filter_domains] (0x0200):
TRUST_ATTRIBUTE_WITHIN_FOREST not set for [emea-poclab.companypoc.com].
(2021-10-08 18:31:11): [be[amer.company.com]] [ad_filter_domains] (0x0200):
TRUST_ATTRIBUTE_WITHIN_FOREST not set for [oldev.preol.company.com].
(2021-10-08 18:31:11): [be[amer.company.com]] [ad_filter_domains] (0x0200):
TRUST_ATTRIBUTE_WITHIN_FOREST not set for [olqa.preol.company.com].
(2021-10-08 18:31:11): [be[amer.company.com]] [ad_filter_domains] (0x0200):
TRUST_ATTRIBUTE_WITHIN_FOREST not set for [ap-poclab.companypoc.com].


It looks like it's discovering any AD domain with a two-way trust.  Which
is good.

And it's not discovering any domain with a one-way trust.  That's good when
it's a one-way trust the wrong way.  I.e., untrusted from this domain.
That's bad when it's a one-way trust (or a transitive trust) the right
way.

Spike


On Fri, Oct 8, 2021 at 5:54 PM Spike White  wrote:

> Sumit,
>
> It took all day, but I finally got these RPMs on a test box:
>
> libsss_simpleifp-2.4.0-9.el8_4.2sb1.x86_64
> sssd-ipa-2.4.0-9.el8_4.2sb1.x86_64
> sssd-client-2.4.0-9.el8_4.2sb1.x86_64
> sssd-krb5-common-2.4.0-9.el8_4.2sb1.x86_64
> libsss_idmap-2.4.0-9.el8_4.2sb1.x86_64
> sssd-common-2.4.0-9.el8_4.2sb1.x86_64
> python3-sssdconfig-2.4.0-9.el8_4.2sb1.noarch
> sssd-common-pac-2.4.0-9.el8_4.2sb1.x86_64
> sssd-ad-2.4.0-9.el8_4.2sb1.x86_64
> libsss_certmap-2.4.0-9.el8_4.2sb1.x86_64
> sssd-dbus-2.4.0-9.el8_4.2sb1.x86_64
> sssd-tools-2.4.0-9.el8_4.2sb1.x86_64
> libipa_hbac-2.4.0-9.el8_4.2sb1.x86_64
> libsss_nss_idmap-2.4.0-9.el8_4.2sb1.x86_64
> sssd-kcm-2.4.0-9.el8_4.2sb1.x86_64
&

[SSSD-users]Re: https://bugzilla.redhat.com/show_bug.cgi?id=1984591 not understanding the nature of the sssd bug introduced recently…

[Spike White]

Sumit,

It took all day, but I finally got these RPMs on a test box:

libsss_simpleifp-2.4.0-9.el8_4.2sb1.x86_64
sssd-ipa-2.4.0-9.el8_4.2sb1.x86_64
sssd-client-2.4.0-9.el8_4.2sb1.x86_64
sssd-krb5-common-2.4.0-9.el8_4.2sb1.x86_64
libsss_idmap-2.4.0-9.el8_4.2sb1.x86_64
sssd-common-2.4.0-9.el8_4.2sb1.x86_64
python3-sssdconfig-2.4.0-9.el8_4.2sb1.noarch
sssd-common-pac-2.4.0-9.el8_4.2sb1.x86_64
sssd-ad-2.4.0-9.el8_4.2sb1.x86_64
libsss_certmap-2.4.0-9.el8_4.2sb1.x86_64
sssd-dbus-2.4.0-9.el8_4.2sb1.x86_64
sssd-tools-2.4.0-9.el8_4.2sb1.x86_64
libipa_hbac-2.4.0-9.el8_4.2sb1.x86_64
libsss_nss_idmap-2.4.0-9.el8_4.2sb1.x86_64
sssd-kcm-2.4.0-9.el8_4.2sb1.x86_64
python3-sss-2.4.0-9.el8_4.2sb1.x86_64


samba-client-libs-4.13.3-5.el8_4  must be *brand new*; the latest we have
in our mirrored repos is samba-client-libs-4.13.3-4.el8_4.Which caused
no end of manual work and installing 2-3 of the above rpms with 'rpm -Uvh
--nodeps'.

Originally, all the bogus domains still appeared in sssctl domain-list and
I was sad!But I realized they could have been cached from previously.
  Sure enough, when I shut down sssd and removed *all* cache:

rm -rf /var/lib/sss/db/*

rm -rf /var/lib/sss/mc/*

Then when it started it found only the expected 5 AD domains.  (1 parent +
4 regional child sub-domains).

I'll let my fellow engineers poke at it in the next few days -- but I think
it looks good.  I think you've fixed it.

Spike
PS I  git cloned your github.com source tree, checked out your
ad_domain_filter branch and attempted to build according to build
instructions.  Using a RHEL7 test box since it's what a fellow engineer had
handy.  Using the build instructions.
https://sssd.io/contrib/building-sssd.html

It was an epic fail, even when I installed and enabled the devtoolset-9
SCL.   I eventually generated binaries, but they installed into
/usr/local/bin.  I started to generate RPMs, but you had your RPMs ready
for me by then and I switched over to a 8.4 test box, using your pre-build
RPMs.  Will the Fedora sssd build instructions on
https://sssd.io/contrib/building-sssd.html  ( dnf builddep sssd  and
following) work on RHEL8.4?


On Fri, Oct 8, 2021 at 12:42 PM Sumit Bose  wrote:

> Am Fri, Oct 08, 2021 at 08:51:55AM -0500 schrieb Spike White:
> > Sumit,
> >
> > It would probably be faster for you to do a test build.  I'd have to
> fumble
> > through pulling the source RPM, rpmbuild invocation, rpm install.You
> > probably know those commands at your fingertips.
> >
> > We have ~20K servers with RHEL7, RHEL8, OL7 (RHCK) and OL8 (RHCK)
> > exhibiting this behavior.  All x86_64.  We have test servers of each of
> > those flavors on which we can test.Your call.
> >
> > We have beaucoup RHEL8/OL8 test boxes, so if that's convenient for you,
> > it'll work for us.
>
> Hi,
>
> please have a look at
> https://sbose.fedorapeople.org/sssd-2.4.0-9.el8_4.2sb1.tar.gz, a test
> build for RHEL-8.4. You do not have to install all packages, calling
> 'yum update *' in the new directory should just update the installed
> packages.
>
> bye,
> Sumit
>
> >
> > It is super-easy for us to determine.if it's fixed or not.  Previously
> > 'sssctl domain-list' only showed the 5 trusted domains.  Now with this
> new
> > sssd version (~July), 'sssctl domain-list' shows the expected 5 trusted
> > domains and the 14 untrusted domains.
> >
> > Spike
> >
> > On Fri, Oct 8, 2021 at 1:01 AM Sumit Bose  wrote:
> >
> > > Am Thu, Oct 07, 2021 at 11:38:54AM -0500 schrieb Spike White:
> > > > All  (but particularly Sumit since he wrote the comments on
> > > > https://bugzilla.redhat.com/show_bug.cgi?id=1984591),
> > > >
> > >
> > > Hi,
> > >
> > > jfyi, I'm currently working on a fix for this to filter out domains
> from
> > > other forests and untrusted domains. My WIP branch is at
> > > https://github.com/sumit-bose/sssd/tree/ad_filter_domains. Can you do
> a
> > > test build of SSSD based on this or shall I try to create a test build
> > > for you? For the latter, please tell me for which platform.
> > >
> > > bye,
> > > Sumit
> > >
> > > >
> > > >
> > > > There are at least two problems created by this recently-introduced
> sssd
> > > > bug.  One problem is solvable by the suggested work-around, the
> other is
> > > > not.  The work-around suggested is:
> > > >
> > > > [domain/name.of.joined.domain]
> > > >
> > > > ad_enabled_domains = dom1.example.com, dom2.example.com,
> > > > dom3.example.com
> > > >
> > > > In order to query only the desired AD domains.
> > >

[SSSD-users]Re: https://bugzilla.redhat.com/show_bug.cgi?id=1984591 not understanding the nature of the sssd bug introduced recently…

[Spike White]

Sumit,

It would probably be faster for you to do a test build.  I'd have to fumble
through pulling the source RPM, rpmbuild invocation, rpm install.You
probably know those commands at your fingertips.

We have ~20K servers with RHEL7, RHEL8, OL7 (RHCK) and OL8 (RHCK)
exhibiting this behavior.  All x86_64.  We have test servers of each of
those flavors on which we can test.Your call.

We have beaucoup RHEL8/OL8 test boxes, so if that's convenient for you,
it'll work for us.

It is super-easy for us to determine.if it's fixed or not.  Previously
'sssctl domain-list' only showed the 5 trusted domains.  Now with this new
sssd version (~July), 'sssctl domain-list' shows the expected 5 trusted
domains and the 14 untrusted domains.

Spike

On Fri, Oct 8, 2021 at 1:01 AM Sumit Bose  wrote:

> Am Thu, Oct 07, 2021 at 11:38:54AM -0500 schrieb Spike White:
> > All  (but particularly Sumit since he wrote the comments on
> > https://bugzilla.redhat.com/show_bug.cgi?id=1984591),
> >
>
> Hi,
>
> jfyi, I'm currently working on a fix for this to filter out domains from
> other forests and untrusted domains. My WIP branch is at
> https://github.com/sumit-bose/sssd/tree/ad_filter_domains. Can you do a
> test build of SSSD based on this or shall I try to create a test build
> for you? For the latter, please tell me for which platform.
>
> bye,
> Sumit
>
> >
> >
> > There are at least two problems created by this recently-introduced sssd
> > bug.  One problem is solvable by the suggested work-around, the other is
> > not.  The work-around suggested is:
> >
> > [domain/name.of.joined.domain]
> >
> > ad_enabled_domains = dom1.example.com, dom2.example.com,
> > dom3.example.com
> >
> > In order to query only the desired AD domains.
> >
> >
> >
> > What is the bug?
> >
> > the sssd-ad man page says "The AD provider can be used to get user
> > information and authenticate users from trusted domains. Currently
> > only trusted domains in the same forest are recognized.".
> >
> > What is happening is that untrusted AD domains are being discovered.  A
> > very specific type of untrusted domains.When the joined domain has no
> > trust with that other domain, but that other domain trusts the original
> > domain – that is a one-way trust (the wrong way).  To the joined domain,
> > this is an untrusted domain and should not be discovered.
> >
> > This is actually very common in corporate environments.
> >
> > You may have a main AD domain, call it  CORP.COMPANY.COM.  Then for
> testing
> > and new production evaluation, you might have a test AD domain called
> > LAB-TEST.COMPANY.COM.  CORP.COMPANY.COM is tightly controlled, with full
> > audits and corporate security.   LAB-TEST.COMPANY.COM is a test AD
> domain –
> > it’s the wild, wild west!
> >
> > So LAB-TEST.COMPANY.COM trusts the main AD domain (in order that users
> can
> > log into this test domain with their CORP accounts).   But
> CORP.COMPANY.COM
> > does not trust LAB-TEST.COMPANY.COM – nor should it!! (That’s the wild,
> > wild west, doing so would compromise corporate security.)
> >
> > Thus, a server joined to domain CORP.COMPANY.COM should discover
> > CORP.COMPANY.COM and any domains trusted by CORP.COMPANY.COM.   It
> should
> > *NOT* discover LAB-TEST.COMPANY.COM, as CORP.COMPANY.COM does not trust
> > this domain.
> >
> > A server joined to LAB-TEST.COMPANY.COM should discover
> LAB-TEST.COMPANY.COM
> > and all domains trusted by LAB-TEST.COMPANY.COM.  Including
> CORP.COMPANY.COM,
> > as LAB-TEST.COMPANY.COM trusts CORP.COMPANY.COM.
> >
> > The bug is that a server joined to CORP.COMPANY.COM discovers
> > LAB-TEST.COMPANY.COM, which it shouldn’t.
> >
> >
> >
> > What problems does this cause?
> >
> > Two problems.
> >
> > 1.   Many of these untrusted discovered “lab” domains  are accessible
> > only to specific network locations.  That is, they’re firewalled off to a
> > particular lab.  So sssd attempts to query these inaccessible AD domains
> > and  takes a long time to time out.  This problem can be worked around by
> > the suggested work-around in the Bugzilla:
> >
> >
> >
> > [domain/corp.company.com]
> >
> > ad_enabled_domains = corp.company.com
> >
> >
> >
> > So then, while LAB-TEST.COMPANY.COM is still erroneously discovered,
> it is
> > no longer searched.  Sssd is again fast.
> >
> >
> >
> > 2.   Bogus messages in /var/log/sssd_nss.log file.  Even with no
> debug
>

[SSSD-users]Re: Trouble-shooting sssd’s ‘Automatic Kerberos Host Keytab Renewal’ with AD back-end….

[Spike White]

Grigory,

It's quite likely that it's something client-related like that.  But I know
it's not exactly that;  we turn off SELinux.   in the verbose log of adcli
update on a failed renewal, it says:

! Cannot change computer password: Authentication error
adcli: updating membership with domain amer.dell.com failed: Cannot change
computer password: Authentication error

While on a good renewal, the verbose adcli output says:

* Changed computer password
* kvno incremented to 110

Sumit informs me that this output:

! Cannot change computer password: Authentication error

means that adcli update received a response back from the AD DC that it's
interpreting as a failed attempt to change the computer password.  But I
don't what local components get traversed between the network and adcli (is
it routed over dbus or polkit for instance, so if /tmp or /var is 100% full
is that a problem?)

Spike

On Thu, Oct 7, 2021 at 12:15 PM Grigory Trenin  wrote:

> Hi Spike,
>
> I have once seen such an issue on RHEL7. It was caused by a wrong SELinux
> context on /etc/krb5.keytab file. That is, SSSD updated the password in AD,
> attempted to update /etc/krb5.keytab, and SELinux denied this attempt.
> Audit log will contain a denied entry if that is the case. Maybe it will
> help you.
>
>
> Kind regards,
> Grigory Trenin
>
> чт, 7 окт. 2021 г. в 20:02, Spike White :
>
>> FYI -- update on this situation.
>>
>> AD DC logs no help.  They show the exact same response sent back to a
>> good machine account password renewal as for a failed renewal.
>>
>> One of the AD administrators have identified a particular AD DC NIC
>> teaming configuration that they state has caused problems with Kerberos on
>> the past.  It's on a small percentage of their AD DCs and they will work to
>> correct.  They will keep us apprised as to update.
>>
>> I'm skeptical that's the underlying root cause -- for two reasons:
>> 1.  If Kerberos was sensitive to this, it should affect all Kerberos
>> operations  (Kerberos auth, etc.) and not just the kpasswd operations.
>> 2. This is not occurring on our older RHEL6 and RHEL7 builds AD
>> integrated via our older commercial AD integration product.  It's occurring
>> only on our sssd-integrated builds.
>>
>> At this point, we're turned off debug level 7 (it was filling up our
>> /var/log filesystems and we have the verbose adcli update output from at
>> least two failed clients).   We're going to take the alternate suggestion
>> of setting ad_maximum_machine_account_password_age to 0 (disabling sssd
>> from updating password) and run a cron job to do 'adcli update'.
>>
>> We're wrapping this adcli_update with tcpdump to get the exact kpasswd
>> request/response packets, as well as wrapping with KRB5_TRACE.
>>
>> We want to call adcli update exactly as sssd calls it.
>> From SOURCES/sssd-2.4.0/src/providers/ad/ad_machine_pw_renewal.c, this
>> appears to be how sssd calls external program /usr/sbin/adcli to do its
>> adcli update:
>>
>>   /usr/sbin/adcli update --verbose --domain=$AD_DOMAIN
>> --host-keytab=/etc/krb5.keytab --host-fqdn=$FQDN
>> --computer-password-lifetime=30
>>
>> because we aren't doing any Samba stuff.  Is that the correct
>> invocation?   We'll set computer-password-lifetime lower, say to 7.
>> Because we want to see examples more frequently, to find failed updates.
>>
>> BTW, the packet capture on a successful machine account password renewal
>> is only 8K, so that very targeted debug will not swamp our /var/log or /tmp
>> filesystems.
>>
>> Spike
>>
>> On Wed, Aug 25, 2021 at 10:32 AM Spike White 
>> wrote:
>>
>>> Sssd experts,
>>>
>>> *Short summary: * How can we troubleshoot sssd’s ‘Automatic Kerberos
>>> Host Keytab Renewal’ process?We have ~0.4%  of our Linux servers
>>> dropping off the AD domain monthly.
>>>
>>> *Longer explanation:*
>>>
>>> Over the past two years, we have on-boarded sssd as our Linux AD
>>> integration component.  Largely displacing a former commercial product that
>>> did the same.
>>>
>>> We have about ~20K Linux servers that are sssd-enabled.  A mix of RHEL6,
>>> RHEL7, RHEL8, Oracle Linux 6, 7 and 8.   We have ~7K Linux servers still on
>>> the old commercial product.  (For certain edge-case scenarios, such as
>>> DMZs, the commercial product works better.)
>>>
>>> Our AD forest is a single AD forest, with 4 regional child domains.  All
>>> with transitive trust.  Sssd auto-discovers parent domain and all 4 child
>>> domains, no proble

[SSSD-users]Re: Trouble-shooting sssd’s ‘Automatic Kerberos Host Keytab Renewal’ with AD back-end….

[Spike White]

FYI -- update on this situation.

AD DC logs no help.  They show the exact same response sent back to a good
machine account password renewal as for a failed renewal.

One of the AD administrators have identified a particular AD DC NIC teaming
configuration that they state has caused problems with Kerberos on the
past.  It's on a small percentage of their AD DCs and they will work to
correct.  They will keep us apprised as to update.

I'm skeptical that's the underlying root cause -- for two reasons:
1.  If Kerberos was sensitive to this, it should affect all Kerberos
operations  (Kerberos auth, etc.) and not just the kpasswd operations.
2. This is not occurring on our older RHEL6 and RHEL7 builds AD integrated
via our older commercial AD integration product.  It's occurring only on
our sssd-integrated builds.

At this point, we're turned off debug level 7 (it was filling up our
/var/log filesystems and we have the verbose adcli update output from at
least two failed clients).   We're going to take the alternate suggestion
of setting ad_maximum_machine_account_password_age to 0 (disabling sssd
from updating password) and run a cron job to do 'adcli update'.

We're wrapping this adcli_update with tcpdump to get the exact kpasswd
request/response packets, as well as wrapping with KRB5_TRACE.

We want to call adcli update exactly as sssd calls it.
>From SOURCES/sssd-2.4.0/src/providers/ad/ad_machine_pw_renewal.c, this
appears to be how sssd calls external program /usr/sbin/adcli to do its
adcli update:

  /usr/sbin/adcli update --verbose --domain=$AD_DOMAIN
--host-keytab=/etc/krb5.keytab --host-fqdn=$FQDN
--computer-password-lifetime=30

because we aren't doing any Samba stuff.  Is that the correct invocation?
 We'll set computer-password-lifetime lower, say to 7.  Because we want to
see examples more frequently, to find failed updates.

BTW, the packet capture on a successful machine account password renewal is
only 8K, so that very targeted debug will not swamp our /var/log or /tmp
filesystems.

Spike

On Wed, Aug 25, 2021 at 10:32 AM Spike White  wrote:

> Sssd experts,
>
> *Short summary: * How can we troubleshoot sssd’s ‘Automatic Kerberos Host
> Keytab Renewal’ process?We have ~0.4%  of our Linux servers dropping
> off the AD domain monthly.
>
> *Longer explanation:*
>
> Over the past two years, we have on-boarded sssd as our Linux AD
> integration component.  Largely displacing a former commercial product that
> did the same.
>
> We have about ~20K Linux servers that are sssd-enabled.  A mix of RHEL6,
> RHEL7, RHEL8, Oracle Linux 6, 7 and 8.   We have ~7K Linux servers still on
> the old commercial product.  (For certain edge-case scenarios, such as
> DMZs, the commercial product works better.)
>
> Our AD forest is a single AD forest, with 4 regional child domains.  All
> with transitive trust.  Sssd auto-discovers parent domain and all 4 child
> domains, no problem – whenever it’s adcli joined to its regional local
> domain.
>
> Why are I writing this?
>
> Because we are researching an ongoing problem reported by L1 server ops.
> About 70 – 80 sssd-enabled Linux servers / month drop off the domain.  Out
> of our current sssd-enabled population of ~20K server, that’s not
> horrible.  But still it should be better.  (Our former commercial product
> did better.)
>
> It’s not limited to one particular OS, OS version, build location or
> region.  We have surveyed; it seems to occur randomly among all OS
> versions, regions and locations.
>
> To be clear, it’s extremely likely that this behavior arising from some
> subtle misconfiguration on our part – not from any sssd or adcli or
> Kerberos bug.  We have a couple of configuration improvements we’re
> pursuing.  (Kerberos max ticket lifetime mismatch between AD and
> /etc/krb5.conf file for instance.)
>
> We are taking sssd’s default settings for
> ad_maximum_machine_account_password_age and
> ad_machine_account_password_renewal_opts.   So after 30 days, sssd will
> attempt daily to renew the host Kerberos keytab file.  It should re-attempt
> daily if not renewed.  By company policy, our AD disables any machine
> accounts that have not renewed their credentials in 40 days.   So when we
> find servers that have dropped off the domain, it’s because they have not
> renewed their AD machine accounts in 40 days.
>
> We have SR’s open with our OS vendors (Redhat and Oracle respectively) for
> months now.  To no great help.  (They gave a few suggestions, but none
> panned out.)
>
> We thought we were hitting this bug:
>
> https://github.com/SSSD/sssd/issues/4762
>
> But packet captures proved that adcli update is using TCP on RHEL7/8.
> Thus, this might be a potential problem, but only on RHEL6.  (BTW
> ‘udp_preference_limit = 0’ doesn’t force use of TCP for the kpasswd
>

[SSSD-users]https://bugzilla.redhat.com/show_bug.cgi?id=1984591 not understanding the nature of the sssd bug introduced recently…

[Spike White]

All  (but particularly Sumit since he wrote the comments on
https://bugzilla.redhat.com/show_bug.cgi?id=1984591),



There are at least two problems created by this recently-introduced sssd
bug.  One problem is solvable by the suggested work-around, the other is
not.  The work-around suggested is:

[domain/name.of.joined.domain]

ad_enabled_domains = dom1.example.com, dom2.example.com,
dom3.example.com

In order to query only the desired AD domains.



What is the bug?

the sssd-ad man page says "The AD provider can be used to get user
information and authenticate users from trusted domains. Currently
only trusted domains in the same forest are recognized.".

What is happening is that untrusted AD domains are being discovered.  A
very specific type of untrusted domains.When the joined domain has no
trust with that other domain, but that other domain trusts the original
domain – that is a one-way trust (the wrong way).  To the joined domain,
this is an untrusted domain and should not be discovered.

This is actually very common in corporate environments.

You may have a main AD domain, call it  CORP.COMPANY.COM.  Then for testing
and new production evaluation, you might have a test AD domain called
LAB-TEST.COMPANY.COM.  CORP.COMPANY.COM is tightly controlled, with full
audits and corporate security.   LAB-TEST.COMPANY.COM is a test AD domain –
it’s the wild, wild west!

So LAB-TEST.COMPANY.COM trusts the main AD domain (in order that users can
log into this test domain with their CORP accounts).   But CORP.COMPANY.COM
does not trust LAB-TEST.COMPANY.COM – nor should it!! (That’s the wild,
wild west, doing so would compromise corporate security.)

Thus, a server joined to domain CORP.COMPANY.COM should discover
CORP.COMPANY.COM and any domains trusted by CORP.COMPANY.COM.   It should
*NOT* discover LAB-TEST.COMPANY.COM, as CORP.COMPANY.COM does not trust
this domain.

A server joined to LAB-TEST.COMPANY.COM should discover LAB-TEST.COMPANY.COM
and all domains trusted by LAB-TEST.COMPANY.COM.  Including CORP.COMPANY.COM,
as LAB-TEST.COMPANY.COM trusts CORP.COMPANY.COM.

The bug is that a server joined to CORP.COMPANY.COM discovers
LAB-TEST.COMPANY.COM, which it shouldn’t.



What problems does this cause?

Two problems.

1.   Many of these untrusted discovered “lab” domains  are accessible
only to specific network locations.  That is, they’re firewalled off to a
particular lab.  So sssd attempts to query these inaccessible AD domains
and  takes a long time to time out.  This problem can be worked around by
the suggested work-around in the Bugzilla:



[domain/corp.company.com]

ad_enabled_domains = corp.company.com



So then, while LAB-TEST.COMPANY.COM is still erroneously discovered,  it is
no longer searched.  Sssd is again fast.



2.   Bogus messages in /var/log/sssd_nss.log file.  Even with no debug
level set in the [nss] stanza, these error messages appear multiple times a
second.It quickly fills up the /var/log filesystem.

[root@auspdfdlobv01 sssd]# cat sssd_nss.log |grep "The Data Provider
returned an error"

(2021-10-07  9:50:02): [nss] [sss_dp_get_reply] (0x0010): The Data Provider
returned an error [org.freedesktop.DBus.Error.Failed]

(2021-10-07  9:50:02): [nss] [sss_dp_get_reply] (0x0010): The Data Provider
returned an error [org.freedesktop.DBus.Error.Failed]

(2021-10-07  9:50:02): [nss] [sss_dp_get_reply] (0x0010): The Data Provider
returned an error [org.freedesktop.DBus.Error.Failed]

(2021-10-07  9:50:02): [nss] [sss_dp_get_reply] (0x0010): The Data Provider
returned an error [org.freedesktop.DBus.Error.Failed]

(2021-10-07  9:50:02): [nss] [sss_dp_get_reply] (0x0010): The Data Provider
returned an error [org.freedesktop.DBus.Error.Failed]

(2021-10-07  9:50:02): [nss] [sss_dp_get_reply] (0x0010): The Data Provider
returned an error [org.freedesktop.DBus.Error.Failed]

(2021-10-07  9:50:02): [nss] [sss_dp_get_reply] (0x0010): The Data Provider
returned an error [org.freedesktop.DBus.Error.Failed]

(2021-10-07  9:50:02): [nss] [sss_dp_get_reply] (0x0010): The Data Provider
returned an error [org.freedesktop.DBus.Error.Failed]

(2021-10-07  9:50:02): [nss] [sss_dp_get_reply] (0x0010): The Data Provider
returned an error [org.freedesktop.DBus.Error.Failed]

(2021-10-07  9:50:02): [nss] [sss_dp_get_reply] (0x0010): The Data Provider
returned an error [org.freedesktop.DBus.Error.Failed]

(2021-10-07  9:50:02): [nss] [sss_dp_get_reply] (0x0010): The Data Provider
returned an error [org.freedesktop.DBus.Error.Failed]

(2021-10-07  9:50:02): [nss] [sss_dp_get_reply] (0x0010): The Data Provider
returned an error [org.freedesktop.DBus.Error.Failed]

(2021-10-07  9:50:02): [nss] [sss_dp_get_reply] (0x0010): The Data Provider
returned an error [org.freedesktop.DBus.Error.Failed]

(2021-10-07  9:50:02): [nss] [sss_dp_get_reply] (0x0010): The Data Provider
returned an error [org.freedesktop.DBus.Error.Failed]

(2021-10-07  9:50:02): [nss] [sss_dp_get_reply] (0x0010): The Data 

[SSSD-users]Re: Trouble-shooting sssd’s ‘Automatic Kerberos Host Keytab Renewal’ with AD back-end….

[Spike White]

Sumit,

Thanks.   BTW, this occurs primarily on RHEL7, RHEL8, Oracle Linux 7 and
8.  (We have very few RHEL6 servers left, but some of them are sssd
enabled.)

We verified (via tcpdump, wireshark) that *L7/8 use TCP exclusively for
this kpasswd operation.  As we're aware of this UDP problem.  So this is a
new password change problem, not the old UDP-related problem.

BTW, we also verified that RHEL6 uses UDP exclusively for this kpasswd
operation.  Regardless of setting of udp_preference_limit in
/etc/krb5.conf.  That setting apparently is only for the Kerberos port
(TCP/UDP 88), not for the kpasswd port.

Yes, we're very anxious to hear what our AD admins will tell us from their
AD DC logs.

Spike


On Wed, Sep 29, 2021 at 5:13 AM Sumit Bose  wrote:

> Am Tue, Sep 28, 2021 at 03:18:06PM -0500 schrieb Spike White:
> > All,
> >
> > We took Sumit’s advice and enabled sssd’s debug level 7 on the “domain”
> > section of sssd.conf.   On about 2300 non-prod Linux servers.
> >
> > FYI – beware if you do this!  We found occurrences where that
> > sssd_amer.company.com_log was 8 GB after 24 hrs.  So you’ll likely have
> to
> > fine-tune your sssd logrotate file or even more drastic actions.
> >
> > RECAP:  Randomly on 0.24% of our Linux servers, after 30 days sssd will
> > drop off the AD domain.  We find this occurs during the automatic
> Kerberos
> > Host Keytab renewal.  The KVNO number in AD is one more than the latest
> > KVNO number in /etc/krb5.keytab file.
> >
> > Due to sssd debug level 7, we now have verbose ‘adcli update’  output in
> > our sssd_.company.com_log files.   For two such culprits.  The
> > output shows the same error condition.  Here is example output:
> >
> > (2021-09-28  3:44:23): [be[amer.company.com]]
> > [ad_machine_account_password_renewal_done] (0x1000): --- adcli output
> > start---
> >
> >  * Found realm in keytab: AMER.COMPANY.COM
> >
> >  * Found computer name in keytab: KEWNLR2CU2APP01
> >
> >  * Found service principal in keytab: host/
> kewnlr2cu2app01.amer.company.com
> >
> >  * Found host qualified name in keytab: kewnlr2cu2app01.amer.company.com
> >
> >  * Found service principal in keytab: host/KEWNLR2CU2APP01
> >
> >  * Found service principal in keytab: RestrictedKrbHost/KEWNLR2CU2APP01
> >
> >  * Found service principal in keytab: RestrictedKrbHost/
> > kewnlr2cu2app01.amer.company.com
> >
> >  * Using fully qualified name: kewnlr2cu2app01.amer.company.com
> >
> >  * Using domain name: amer.company.com
> >
> >  * Using computer account name: KEWNLR2CU2APP01
> >
> >  * Using domain realm: amer.company.com
> >
> >  * Sending NetLogon ping to domain controller:
> > AUSDC16AMER23.amer.company.com
> >
> >  * Received NetLogon info from: AUSDC16AMER23.amer.company.com
> >
> >  * Wrote out krb5.conf snippet to
> > /tmp/adcli-krb5-HRsQ9K/krb5.d/adcli-krb5-conf-yBNrRI
> >
> >  * Authenticated as default/reset computer account: KEWNLR2CU2APP01
> >
> >  * Using GSS-SPNEGO for SASL bind
> >
> >  * Looked up short domain name: AMERICAS
> >
> >  * Looked up domain SID: S-1-5-21-1802859667-647903414-1863928812
> >
> >  * Using fully qualified name: kewnlr2cu2app01.amer.company.com
> >
> >  * Using domain name: amer.company.com
> >
> >  * Using computer account name: KEWNLR2CU2APP01
> >
> >  * Using domain realm: amer.company.com
> >
> >  * Using fully qualified name: kewnlr2cu2app01.amer.company.com
> >
> >  * Enrolling computer name: KEWNLR2CU2APP01
> >
> >  * Generated 120 character computer password
> >
> >  * Using keytab: FILE:/etc/krb5.keytab
> >
> >  * Found computer account for KEWNLR2CU2APP01$ at:
> > CN=KEWNLR2CU2APP01,OU=Servers,OU=UNIX,DC=amer,DC=company,DC=com
> >
> >  * Retrieved kvno '17' for computer account in directory:
> > CN=KEWNLR2CU2APP01,OU=Servers,OU=UNIX,DC=amer,DC=company,DC=com
> >
> >  * Sending NetLogon ping to domain controller:
> > AUSDC16AMER23.amer.company.com
> >
> >  * Received NetLogon info from: AUSDC16AMER23.amer.company.com
> >
> >  ! Cannot change computer password: Authentication error
> >
> > adcli: updating membership with domain amer.company.com failed: Cannot
> > change computer password: Authentication error
> >
> > ---adcli output end---
> >
> >
> >
> > Within 1.5 mins of the above, we receive errors in /var/log/messages as
> > below:
> >
> > Sep 28 03:45:51 kewnlr2cu2app01 sssd[ldap_child[288005]][288005]: Failed
> 

[SSSD-users]Re: Trouble-shooting sssd’s ‘Automatic Kerberos Host Keytab Renewal’ with AD back-end….

[Spike White]

 Found service principal in keytab: RestrictedKrbHost/
kewnlr2cu2app01.amer.company.com

 * Using fully qualified name: kewnlr2cu2app01.amer.company.com

 * Using domain name: amer.company.com

 * Using computer account name: KEWNLR2CU2APP01

 * Using domain realm: amer.company.com

 * Discovering domain controllers: _ldap._tcp.amer.company.com

 * Sending NetLogon ping to domain controller:
RDUDC16AMER04.amer.company.com

 * Received NetLogon info from: RDUDC16AMER04.amer.company.com

 * Discovering site domain controllers: _ldap._tcp.AMERAustin._sites.dc._
msdcs.amer.company.com

 * Sending NetLogon ping to domain controller:
AUSDC16AMER34.amer.company.com

 * Received NetLogon info from: AUSDC16AMER34.amer.company.com

 * Wrote out krb5.conf snippet to
/tmp/adcli-krb5-i7P6zR/krb5.d/adcli-krb5-conf-vkBoqT

 ! Couldn't authenticate as machine account: KEWNLR2CU2APP01:
Preauthentication failed

adcli: couldn't connect to amer.company.com domain: Couldn't authenticate
as machine account: KEWNLR2CU2APP01: Preauthentication failed

---adcli output end---



In summary, for some reason adcli update after attempting to set the
machine account password thinks that it’s receiving a Kerberos
authentication error.  Actually, it has successfully set the machine
account password in AD.  Because it thinks that it did not successfully
update the machine account password, it does not update the entiries in the
local /etc/krb5.keytab file.



We have our AD admins examining the AD domain controller logs now (since we
have an exact DC name, exact time and exact client FQDN above).



At this point, we’re unsure whether this is an adcli problem or an AD
problem.



Does adcli update attempt to authenticate back to the same AD DC with the
new password?  Or does it randomly pick an AD DC to authentication back to,
with the new password?



Spike White

On Wed, Aug 25, 2021 at 10:32 AM Spike White  wrote:

> Sssd experts,
>
> *Short summary: * How can we troubleshoot sssd’s ‘Automatic Kerberos Host
> Keytab Renewal’ process?We have ~0.4%  of our Linux servers dropping
> off the AD domain monthly.
>
> *Longer explanation:*
>
> Over the past two years, we have on-boarded sssd as our Linux AD
> integration component.  Largely displacing a former commercial product that
> did the same.
>
> We have about ~20K Linux servers that are sssd-enabled.  A mix of RHEL6,
> RHEL7, RHEL8, Oracle Linux 6, 7 and 8.   We have ~7K Linux servers still on
> the old commercial product.  (For certain edge-case scenarios, such as
> DMZs, the commercial product works better.)
>
> Our AD forest is a single AD forest, with 4 regional child domains.  All
> with transitive trust.  Sssd auto-discovers parent domain and all 4 child
> domains, no problem – whenever it’s adcli joined to its regional local
> domain.
>
> Why are I writing this?
>
> Because we are researching an ongoing problem reported by L1 server ops.
> About 70 – 80 sssd-enabled Linux servers / month drop off the domain.  Out
> of our current sssd-enabled population of ~20K server, that’s not
> horrible.  But still it should be better.  (Our former commercial product
> did better.)
>
> It’s not limited to one particular OS, OS version, build location or
> region.  We have surveyed; it seems to occur randomly among all OS
> versions, regions and locations.
>
> To be clear, it’s extremely likely that this behavior arising from some
> subtle misconfiguration on our part – not from any sssd or adcli or
> Kerberos bug.  We have a couple of configuration improvements we’re
> pursuing.  (Kerberos max ticket lifetime mismatch between AD and
> /etc/krb5.conf file for instance.)
>
> We are taking sssd’s default settings for
> ad_maximum_machine_account_password_age and
> ad_machine_account_password_renewal_opts.   So after 30 days, sssd will
> attempt daily to renew the host Kerberos keytab file.  It should re-attempt
> daily if not renewed.  By company policy, our AD disables any machine
> accounts that have not renewed their credentials in 40 days.   So when we
> find servers that have dropped off the domain, it’s because they have not
> renewed their AD machine accounts in 40 days.
>
> We have SR’s open with our OS vendors (Redhat and Oracle respectively) for
> months now.  To no great help.  (They gave a few suggestions, but none
> panned out.)
>
> We thought we were hitting this bug:
>
> https://github.com/SSSD/sssd/issues/4762
>
> But packet captures proved that adcli update is using TCP on RHEL7/8.
> Thus, this might be a potential problem, but only on RHEL6.  (BTW
> ‘udp_preference_limit = 0’ doesn’t force use of TCP for the kpasswd
> invocation in RHEL6 – it still uses UDP.  Thus, the recommended work-around
> for this bug doesn’t work.)
>
> So that isn’t our underlying problem.
>
> We’re at a 

[SSSD-users]Re: Trouble-shooting sssd’s ‘Automatic Kerberos Host Keytab Renewal’ with AD back-end….

[Spike White]

Sumit and others,

Our level 1 server support team has identified 107 servers that dropped out
of the domain in Aug.By far, that's their biggest burden with sssd --
the automatic machine account renewal.

Over the long weekend, our team ran a report that identified any pingable
candidates that (according to AD) had a passwordLastSet age between 31 and
40 days.  These would be our interesting candidates;  candidates > 40 days
would not be of interest to us because AD would have locked the account.

We identified 13 candidates today.From our various research, so far we
have determined 8 categories of such sssd "automatic machine account
renewal" failure.

1.   Some SE cloned VM and renamed hostname, IP address, rejoined AD.
Old $ entries early in /etc/krb5.keytab file and adcli update
grabs first entry in /etc/krb5.keytab with $ at end of it.

2.   CPU spiked to 100% for 30 days.

3.   Polkit service not running.

4.   msDS-KeyVersionNumber in AD set to one more than KVNO in local
/etc/krb5.keytab file.  passwordLastSet Set to 30 days past last timestamp
in local /etc/krb5.keytab file.  IOW, sssd called adcli update after 30
days.  Adcli update updated AD, not local /etc/krb5.keytab file.

5.   DNS firewall problems.  Specifically, DNS TCP port 53 blocked, so
adcli update could not find Kerberos servers (_kerberos._
tcp.AMER.COMPANY.COM) or LDAP servers (_ldap._tcp.AMER.COMPANY.COM).

6.   SELinux enabled;  adcli not allowed to update /etc/krb5.keytab
file (from Sumit).

7.   Time sync too far out for adcli update to successfully do an
update on machine account.

8.   /var filesystem:  Input/Output errors.

By far, today the most common category is #4.  It amounted to 9 of the 13
candidates today.  Category #7 was another 2 candidates today.

So by far, it's category #4 we want to drill down into -- if we can
eliminate that,  we've strongly decreased the sssd burden.  Also, we think
we can put pro-active monitoring in place for category #3 and #7.

Our old commerical AD integration product didn't depend on polkit/dbus.  So
categories #3 and #4 are new for sssd.  If we can understand #4 and
proactively monitor for #3,  we can reduce the sssd burden to that of the
former product.

Category #4 appears to occur randomly -- no rhyme or reason.  Also we have
not found any repeat offenders -- so it's very hard to track down.

We plan to turn on sssd debug_level 7 (on that one sssd [domain/xxx] stanza
only). Debug level 7 is  min level to get verbose output from adcli
update.   We  know that turning on debug level 9 on all sssd stanzas (nss,
pam, ifp, [domain/xxx]) fills /var/log filesystem to 100% in a few days.

Spike

On Tue, Sep 7, 2021 at 9:53 AM Patrick Goetz  wrote:

>
>
> On 9/6/21 4:49 AM, Sumit Bose wrote:
> > Am Thu, Sep 02, 2021 at 10:02:54AM -0500 schrieb Patrick Goetz:
> >>
> >> On 9/2/21 12:49 AM, Sumit Bose wrote:
> >>> The reason is that 'kinit -k' constructs the principal by calling
> >>> gethostname() or similar, adding the 'host/' prefix and the realm. But
> >>> by default this principal in AD is only a service principal can cannot
> >>> be used to request a TGT as kinit does. AD only allows user principals
> >>> for request a TGT and this is by default 'SHORT$@AD.REALM'. If the
> >>> userPrincipalName attribute is set, this principal given here is
> allowed
> >>> as well.
> >>>
> >>
> >> This raises a couple of questions. Because of AD's flat address space,
> we
> >> use a host naming convention in AD as a sort of low rent namespacing;
> so,
> >> for example, for this host the college is cns and the research group
> cryo,
> >> so the AD hostname is cns-cryo-ross1$
> >>
> >> However,
> >>
> >> # hostname
> >> rossmann.biosci.utexas.edu
> >>
> >>
> >> which is easier for the users to remember for ssh purposes.  We set
> >>
> >>ad_hostname = cns-cryo-ross1.austin.utexas.edu
> >>
> >> in /etc/sssd/sssd.conf.
> >>
> >> But I just checked, and kinit does not use ad_hostname, so I have to
> run it
> >> as
> >>
> >>kinit -k -R cns-cryo-ross1$
> >>
> >> The question is, then what does use the ad_hostname key/value pair?
> >>
> >> Next, the kinit example provided by Spike was `kinit -k` -- we always
> run
> >> `kinit -k -R`
> >>
> >> -R renews the TGT, which is what I thought is the thing set to expire
> in AD
> >> that needs to be periodically renewed.  What's the purpose of running
> `kinit
> >> -k` without the -R?
> >
> > Hi,
> >
> > there are two different things.
> >
> > First, there are the host keys in the keytab which are equivalent to a
> > user password. Those keys are renewed by 'adcli update' if they are
> > older then 30 days, similar as you would renew you user password if the
> > AD DC tells you to do it.
> >
> > Second, with those keys you can request a Kerberos TGT
> >
> >  kinit -k 'shortname$'
> >
>
> I thought, based on the kinit man page, that the -k flag is just an
> ordinary ticket request and that you need to add the -R flag to 

[SSSD-users]Re: Trouble-shooting sssd’s ‘Automatic Kerberos Host Keytab Renewal’ with AD back-end….

[Spike White]

Patrick,

kinit -k acquires a new fresh TGT ticket.

kinit -R renews an existing TGT ticket (if it's not already expired).  Even
if renewed, "renew until" doesn't change (usually 7 days).

None of these are updating any computer account password on AD.  That's an
AD-specific requirement, that machines update their machine account
passwords every 40 days or be locked out.

sssd wakes up every 24 hrs by default (controlled by
ad_machine_account_password_renewal_opts).   It checks to see if machine
account password is older than ad_maximum_machine_account_password_age
(default 30 days).  If it's < 30 days, sssd do nothing.  If 31 days or
greater, it calls adcli update with various flags.  to update the machine
account password.

Spike

On Tue, Sep 7, 2021 at 9:53 AM Patrick Goetz  wrote:

>
>
> On 9/6/21 4:49 AM, Sumit Bose wrote:
> > Am Thu, Sep 02, 2021 at 10:02:54AM -0500 schrieb Patrick Goetz:
> >>
> >> On 9/2/21 12:49 AM, Sumit Bose wrote:
> >>> The reason is that 'kinit -k' constructs the principal by calling
> >>> gethostname() or similar, adding the 'host/' prefix and the realm. But
> >>> by default this principal in AD is only a service principal can cannot
> >>> be used to request a TGT as kinit does. AD only allows user principals
> >>> for request a TGT and this is by default 'SHORT$@AD.REALM'. If the
> >>> userPrincipalName attribute is set, this principal given here is
> allowed
> >>> as well.
> >>>
> >>
> >> This raises a couple of questions. Because of AD's flat address space,
> we
> >> use a host naming convention in AD as a sort of low rent namespacing;
> so,
> >> for example, for this host the college is cns and the research group
> cryo,
> >> so the AD hostname is cns-cryo-ross1$
> >>
> >> However,
> >>
> >> # hostname
> >> rossmann.biosci.utexas.edu
> >>
> >>
> >> which is easier for the users to remember for ssh purposes.  We set
> >>
> >>ad_hostname = cns-cryo-ross1.austin.utexas.edu
> >>
> >> in /etc/sssd/sssd.conf.
> >>
> >> But I just checked, and kinit does not use ad_hostname, so I have to
> run it
> >> as
> >>
> >>kinit -k -R cns-cryo-ross1$
> >>
> >> The question is, then what does use the ad_hostname key/value pair?
> >>
> >> Next, the kinit example provided by Spike was `kinit -k` -- we always
> run
> >> `kinit -k -R`
> >>
> >> -R renews the TGT, which is what I thought is the thing set to expire
> in AD
> >> that needs to be periodically renewed.  What's the purpose of running
> `kinit
> >> -k` without the -R?
> >
> > Hi,
> >
> > there are two different things.
> >
> > First, there are the host keys in the keytab which are equivalent to a
> > user password. Those keys are renewed by 'adcli update' if they are
> > older then 30 days, similar as you would renew you user password if the
> > AD DC tells you to do it.
> >
> > Second, with those keys you can request a Kerberos TGT
> >
> >  kinit -k 'shortname$'
> >
>
> I thought, based on the kinit man page, that the -k flag is just an
> ordinary ticket request and that you need to add the -R flag to request
> a TGT.  What you're saying is it also renews the TGT?
>
> OTOH I thought `kinit -k` was updating the computer account password on
> the domain controller, but that doesn't seem to be the case, in which
> case I'm not even sure what the purpose of an ordinary (non-TGT) ticket
> is if you're not requesting automatic login to some specifically
> requested service.
>
> Also, just to make sure I'm clear on this, the "renew until" doesn't
> change because this is based on the computer account password
> expiration, and further that sssd runs `adcli update` for you
> periodically?  How often, by the way?
>
>
> > as you can do with your user password:
> >
> >  kinit user@REALM
> >  Password for user@REALM
> >
> > This TGT has a lifetime and it might have a renewal time as well:
> >
> > # klist
> > Ticket cache: KCM:0:69840
> > Default principal: administra...@child.ad.vm
> >
> > Valid starting   Expires  Service principal
> > 09/06/2021 09:39:28  09/06/2021 19:39:28  krbtgt/child.ad...@child.ad.vm
> >  renew until 09/07/2021 09:39:24
> >
> >
> > In the example above the TGT will expire at '09/06/2021 19:39:28' but
> > can be renewed until '09/07/2021 09:39:24'. This means that if you call
> >
> >  kinit -R
> >
> > before '09/06/2021 19:39:28' you will get a fresh TGT without entering
> > your password. The new TGT will have a new lifetime but 'renew until'
> > will stay the same. After '09/07/2021 09:39:24' 'kinit -R' will not work
> > anymore and you have to enter your password again. It does not matter
> > here if the TGT was originally requested with a keytab with 'kinit -k'
> > or with plain 'kinit' and a password.
> >
> > However, since the keytab is present in the file system calling
> >
> >  kinit -k 'shortname$'
> >
> > will always get a fresh TGT without manual intervention. So in case you
> > have a valid keytab this is even more flexible than 'kinit -R'
> >
> > HTH
> >
> 

[SSSD-users] SOLVED: automounts in non-local AD domain....

[Spike White]

SOLVED:  find automount maps in non-local AD domain.

All,

We solved this a couple of months ago; just took a while to get time to
write it up.   We have automounts in our AD domains and autofs finds them.

By default, autofs always looks in the local domain for its automount
maps.

We have an AD forest with 3 trusted regional subdomains.  Parent COMPANY.COM,
with children: AMER.COMPANY.COM, APAC.COMPANY.COM and EMEA.COMPANY.COM.

For boring historical reasons, we have all our automount maps in AMER child
domain.  That works great for Linux servers in AMER.  But what about
servers in APAC and EMEA?You could replicate your automounts in all 3
child domains, but this is tedious and error-prone.  Instead,  you have to
modify their sssd.conf file to coerce them to look in AMER for the
automount maps.

So for servers in AMER, the sssd.conf file is pretty straightforward:

…

[sssd]

….

domains = amer.company.com

domain_resolution_order = amer.company.com, emea.company.com,
apac.company.com, company.com

…

services = nss,pam,ifp,autofs

….



[autofs]



[domain/amer.company.com]

id_provider = ad

autofs_provider = ad

ldap_autofs_search_base = ou=automount,ou=UNIX,dc=AMER,dc=COMPANY,dc=COM

access_provider = simple

auth_provider = ad

ldap_sasl_authid = @AMER.COMPANY.COM

…

simple_allow_groups = …



# look at
https://docs.pagure.org/SSSD.sssd/design_pages/subdomain_configuration.html

[domain/amer.company.com/company.com]

ldap_search_base = dc=COMPANY,dc=COM



[domain/amer.company.com/apac.company.com]

ldap_search_base = dc=APAC,dc=COMPANY,dc=COM



[domain/amer.company.com/emea.company.com]

ldap_search_base = dc=EMEA,dc=COMPANY,dc=COM



(Technically we don’t even need ldap_search_base for each child domain.
Sssd will look it up from each AD domain’s rootDSE.  But explaining to the
average Linux SE what is an AD rootDSE and how to perform a rootDSE search
to verify the search base?  That’s complicated.  It’s easier just to put
ldap_search_base in for each child domain.)



Ok, so then for an EMEA sssd.conf, we have to invent a new sssd domain
purely for autofs.  That new sssd domain is associated with the AMER child
AD domain and the only provider it provides is the autofs_provider.



[sssd]

domains = emea.company.com, amer.autofs

…

domain_resolution_order = emea.company.com, amer.company.com,
apac.company.com, company.com

services = nss,pam,ifp,autofs

…



[autofs]



[domain/emea.company.com]

…

id_provider = ad

auth_provider = ad

autofs_provider = none

…

ldap_sasl_authid = @EMEA.COMPANY.COM

ldap_search_base = dc=EMEA,dc=COMPANY,dc=COM

…

simple_allow_groups = …



# look at
https://docs.pagure.org/SSSD.sssd/design_pages/subdomain_configuration.html

[domain/emea.company.com/company.com]

ldap_search_base = dc=COMPANY,dc=COM



[domain/emea.company.com/apac.company.com]

ldap_search_base = dc=APAC,dc=COMPANY,dc=COM



[domain/emea.company.com/amer.company.com]

ldap_search_base = dc=AMER,dc=COMPANY,dc=COM



[domain/amer.autofs]

id_provider = none

dns_discovery_domain = amer.company.com

autofs_provider = ldap

ldap_sasl_mech = GSSAPI

ldap_sasl_authid = @EMEA.COMPANY.COM

krb5_server = ORKDC16EMEA02.emea.company.com, ATHDC16EMEA02.emea.company.com,
ORKDC16EMEA01.emea.company.com



The “secret sauce”  is in this krb5_servers line for this autofs sssd
domain.  All the other lines in this autofs AD domain make sense;  it’s not
clear why this krb5_server line is required (but it is).



Spike
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[SSSD-users]Re: Trouble-shooting sssd’s ‘Automatic Kerberos Host Keytab Renewal’ with AD back-end….

[Spike White]

/
casnlrritpgm206.us.company@amer.company.com (aes128-cts-hmac-sha1-96)

   6 06/28/2021 06:53:31 RestrictedKrbHost/
casnlrritpgm206.us.company@amer.company.com (aes256-cts-hmac-sha1-96)

   5 05/29/2021 02:08:37 CASNLRRITPGM206$@AMER.COMPANY.COM (arcfour-hmac)

   5 05/29/2021 02:08:37 CASNLRRITPGM206$@AMER.COMPANY.COM
(aes128-cts-hmac-sha1-96)

   5 05/29/2021 02:08:37 CASNLRRITPGM206$@AMER.COMPANY.COM
(aes256-cts-hmac-sha1-96)


So 7/28 is 30 days after 6/28.It appears on 7/28 that sssd invoked
adcli update to update the machine account password in AD.  adcli update
updated it in AD, but not in the local /etc/krb5.keytab file.


The next candidate is similar.  It has a KVNO in AD one more than in
/etc/krb5.keytab file with a timestamp 30 days past the timestamp of the
latest entry in /etc/krb5.keytab file.


This sure seems similar to the Kerberos kpasswd UDP problem.  But it's not
-- krb5-libs quit using UDP for kpasswd after RHEL6/OL6.


We know how to remediate when we hit such a candidate.  adcli update with
the valid user principal and valid login ccache of a principal that have AD
privs to update these machine accounts.


So -- this is the ultimate question?  *Why* is this happening?  Why is the
adcli update (called by sssd) updating the passwd in AD and
the msDS-KeyVersionNumber, but not updating /etc/krb5.keytab?


I think this is the common case that we're seeing -- that these other cases
(plus one other) are the unusual end-corner cases.


Spike

On Thu, Sep 2, 2021 at 12:49 AM Sumit Bose  wrote:

> Am Wed, Sep 01, 2021 at 11:39:30AM -0500 schrieb Spike White:
> > So to respond to my own email, but a co-worker did finally find some
> > references to that bizarre name ZZZKBTDURBOL8.
> >
> > [root@nwpllv8bu100 post_install]# klist -kte
> > Keytab name: FILE:/etc/krb5.keytab
> > KVNO Timestamp   Principal
> >  ---
> > --
> >2 07/13/2021 16:42:17 ZZZKBTDURBOL8$@AMER.COMPANY.COM
> > (aes128-cts-hmac-sha1-96)
> >2 07/13/2021 16:42:17 ZZZKBTDURBOL8$@AMER.COMPANY.COM
> > (aes256-cts-hmac-sha1-96)
> >2 07/13/2021 16:42:17 host/
> > zzzkbtdurbol8.amer.company@amer.company.com
> (aes128-cts-hmac-sha1-96)
> >2 07/13/2021 16:42:17 host/
> > zzzkbtdurbol8.amer.company@amer.company.com
> (aes256-cts-hmac-sha1-96)
> >2 07/13/2021 16:42:17 host/zzzkbtdurb...@amer.company.com
> > (aes128-cts-hmac-sha1-96)
> >2 07/13/2021 16:42:17 host/zzzkbtdurb...@amer.company.com
> > (aes256-cts-hmac-sha1-96)
> >2 07/13/2021 16:42:17 RestrictedKrbHost/
> zzzkbtdurb...@amer.company.com
> > (aes128-cts-hmac-sha1-96)
> >2 07/13/2021 16:42:17 RestrictedKrbHost/
> zzzkbtdurb...@amer.company.com
> > (aes256-cts-hmac-sha1-96)
> >2 07/13/2021 16:42:17 RestrictedKrbHost/
> > zzzkbtdurbol8.amer.company@amer.company.com
> (aes128-cts-hmac-sha1-96)
> >2 07/13/2021 16:42:17 RestrictedKrbHost/
> > zzzkbtdurbol8.amer.company@amer.company.com
> (aes256-cts-hmac-sha1-96)
> >3 07/29/2021 13:38:27 NWPLLV8BU100$@AMER.COMPANY.COM
> > (DEPRECATED:arcfour-hmac)
> >3 07/29/2021 13:38:27 NWPLLV8BU100$@AMER.COMPANY.COM
> > (aes128-cts-hmac-sha1-96)
> >3 07/29/2021 13:38:27 NWPLLV8BU100$@AMER.COMPANY.COM
> > (aes256-cts-hmac-sha1-96)
> >3 07/29/2021 13:38:27 host/
> nwpllv8bu100.amer.company@amer.company.com
> > (DEPRECATED:arcfour-hmac)
> >3 07/29/2021 13:38:27 host/
> nwpllv8bu100.amer.company@amer.company.com
> > (aes128-cts-hmac-sha1-96)
> >3 07/29/2021 13:38:27 host/
> nwpllv8bu100.amer.company@amer.company.com
> > (aes256-cts-hmac-sha1-96)
> >3 07/29/2021 13:38:27 host/nwpllv8bu...@amer.company.com
> > (DEPRECATED:arcfour-hmac)
> >3 07/29/2021 13:38:27 host/nwpllv8bu...@amer.company.com
> > (aes128-cts-hmac-sha1-96)
> >3 07/29/2021 13:38:27 host/nwpllv8bu...@amer.company.com
> > (aes256-cts-hmac-sha1-96)
> >3 07/29/2021 13:38:27 RestrictedKrbHost/nwpllv8bu...@amer.company.com
> > (DEPRECATED:arcfour-hmac)
> >3 07/29/2021 13:38:27 RestrictedKrbHost/nwpllv8bu...@amer.company.com
> > (aes128-cts-hmac-sha1-96)
> >3 07/29/2021 13:38:27 RestrictedKrbHost/nwpllv8bu...@amer.company.com
> > (aes256-cts-hmac-sha1-96)
> >3 07/29/2021 13:38:27 RestrictedKrbHost/
> > nwpllv8bu100.amer.company@amer.company.com (DEPRECATED:arcfour-hmac)
> >3 07/29/2021 13:38:27 RestrictedKrbHost/
> > nwpllv8bu100.amer.company@amer.company.com (aes128-cts-hmac-sha1-96)
> >3 07/29/2021 13:38:27 RestrictedKrbHost/
> > nwpllv8bu100.amer.company@amer.company.com (aes256-cts-hmac-sha1-96)

[SSSD-users]Re: Trouble-shooting sssd’s ‘Automatic Kerberos Host Keytab Renewal’ with AD back-end….

[Spike White]

So to respond to my own email, but a co-worker did finally find some
references to that bizarre name ZZZKBTDURBOL8.

[root@nwpllv8bu100 post_install]# klist -kte
Keytab name: FILE:/etc/krb5.keytab
KVNO Timestamp   Principal
 ---
--
   2 07/13/2021 16:42:17 ZZZKBTDURBOL8$@AMER.COMPANY.COM
(aes128-cts-hmac-sha1-96)
   2 07/13/2021 16:42:17 ZZZKBTDURBOL8$@AMER.COMPANY.COM
(aes256-cts-hmac-sha1-96)
   2 07/13/2021 16:42:17 host/
zzzkbtdurbol8.amer.company@amer.company.com (aes128-cts-hmac-sha1-96)
   2 07/13/2021 16:42:17 host/
zzzkbtdurbol8.amer.company@amer.company.com (aes256-cts-hmac-sha1-96)
   2 07/13/2021 16:42:17 host/zzzkbtdurb...@amer.company.com
(aes128-cts-hmac-sha1-96)
   2 07/13/2021 16:42:17 host/zzzkbtdurb...@amer.company.com
(aes256-cts-hmac-sha1-96)
   2 07/13/2021 16:42:17 RestrictedKrbHost/zzzkbtdurb...@amer.company.com
(aes128-cts-hmac-sha1-96)
   2 07/13/2021 16:42:17 RestrictedKrbHost/zzzkbtdurb...@amer.company.com
(aes256-cts-hmac-sha1-96)
   2 07/13/2021 16:42:17 RestrictedKrbHost/
zzzkbtdurbol8.amer.company@amer.company.com (aes128-cts-hmac-sha1-96)
   2 07/13/2021 16:42:17 RestrictedKrbHost/
zzzkbtdurbol8.amer.company@amer.company.com (aes256-cts-hmac-sha1-96)
   3 07/29/2021 13:38:27 NWPLLV8BU100$@AMER.COMPANY.COM
(DEPRECATED:arcfour-hmac)
   3 07/29/2021 13:38:27 NWPLLV8BU100$@AMER.COMPANY.COM
(aes128-cts-hmac-sha1-96)
   3 07/29/2021 13:38:27 NWPLLV8BU100$@AMER.COMPANY.COM
(aes256-cts-hmac-sha1-96)
   3 07/29/2021 13:38:27 host/nwpllv8bu100.amer.company@amer.company.com
(DEPRECATED:arcfour-hmac)
   3 07/29/2021 13:38:27 host/nwpllv8bu100.amer.company@amer.company.com
(aes128-cts-hmac-sha1-96)
   3 07/29/2021 13:38:27 host/nwpllv8bu100.amer.company@amer.company.com
(aes256-cts-hmac-sha1-96)
   3 07/29/2021 13:38:27 host/nwpllv8bu...@amer.company.com
(DEPRECATED:arcfour-hmac)
   3 07/29/2021 13:38:27 host/nwpllv8bu...@amer.company.com
(aes128-cts-hmac-sha1-96)
   3 07/29/2021 13:38:27 host/nwpllv8bu...@amer.company.com
(aes256-cts-hmac-sha1-96)
   3 07/29/2021 13:38:27 RestrictedKrbHost/nwpllv8bu...@amer.company.com
(DEPRECATED:arcfour-hmac)
   3 07/29/2021 13:38:27 RestrictedKrbHost/nwpllv8bu...@amer.company.com
(aes128-cts-hmac-sha1-96)
   3 07/29/2021 13:38:27 RestrictedKrbHost/nwpllv8bu...@amer.company.com
(aes256-cts-hmac-sha1-96)
   3 07/29/2021 13:38:27 RestrictedKrbHost/
nwpllv8bu100.amer.company@amer.company.com (DEPRECATED:arcfour-hmac)
   3 07/29/2021 13:38:27 RestrictedKrbHost/
nwpllv8bu100.amer.company@amer.company.com (aes128-cts-hmac-sha1-96)
   3 07/29/2021 13:38:27 RestrictedKrbHost/
nwpllv8bu100.amer.company@amer.company.com (aes256-cts-hmac-sha1-96)

I realize this is reflecting the literal entries in the /etc/krb5.keytab
file.  So it appears that when this VM was born (on July 13th), it was
named zzzkbtdurbo18.amer.company.com.   (I see other supporting evidence
for this).  On or before July 29th, it was renamed to final FQDN
nwpllv8bu100.amer.company.com.  /etc/hostname, /etc/hosts,
/etc/sysconfig/network etc were all updated and it was rejoined to AD.

kinit -k works fine.  It picks up the current hostname and apparently uses
host/nwpllv8bu100.amer.company@amer.company.com as its service
principal.  Since there's a valid entry in /etc/krb5.keytab file for this,
it uses this and all is good.  (I'm guessing it uses the 14th or 15th
/etc/krb5.keytab file entry above.)

sssd works, because it has this line:

ldap_sasl_authid = host/nwpllv8bu100.amer.company@amer.company.com

But when sssd invokes adcli update to refresh the machine account password,
adcli update fails.

Also, I see that adcli testjoin fails.

[root@nwpllv8bu100 tmp]# adcli testjoin -D AMER.COMPANY.COM
adcli: couldn't connect to AMER.COMPANY.COM domain: Couldn't authenticate
as machine account: ZZZKBTDURBOL8: Preauthentication failed
[root@nwpllv8bu100 tmp]#

>From a strace of this adcli testjoin, it appears that adcli is opening the
/etc/krb5.keytab file to determine the default service principal to use and
is pulling the old server name.  (instead of using the correct service
principal, as kinit -k somehow does.)

Maybe when sssd constructs this adcli update invocation, it's not passing
the ldap_sasl_authid, so the adcli update is doing the above logic to pull
the old server name?

Sounds like an adcli problem.  Adcli should do as 'kinit -k' does when it's
passed no explicit service principal.  Should dive into /etc/krb5.keytab
file and use the most recent set of entries (KVNO = 3 in above example).
Maybe derive the default service principal off the current FQDN and
Kerberos realm?

Spike
PS As a general policy, we are not supposed to clone a VM and rename it to
another FQDN/IP address.  I'll be trying to track down who did this and for
what reason.

On Wed, Sep 1, 2021 at 10:08 AM Spike White  wrote:

> Ok, this is *very* illuminating!
>

[SSSD-users]Re: Trouble-shooting sssd’s ‘Automatic Kerberos Host Keytab Renewal’ with AD back-end….

[Spike White]

Ok, this is *very* illuminating!

I see this in sssd_amer.company.com.log"

(2021-09-01  3:44:46): [be[amer.company.com]]
[ad_machine_account_password_renewal_done] (0x1000): --- adcli output
start---
adcli: couldn't connect to amer.company.com domain: Couldn't authenticate
as machine account: ZZZKBTDURBOL8: Preauthentication failed
---adcli output end---

However, I don't find that host name ZZZKBTDURBOL8 anywhere on the system.
(By company convention, servers named ZZZ* are test servers that linux SEs
spin up themselves).

This server that's not renewing its creds is named:
nwpllv8bu100.amer.company.com.  it's a std dev server.  in
/etc/sssd/sssd.conf file, it has that as its sasl auth ID:

[root@nwpllv8bu100 sssd]# grep sasl /etc/sssd/sssd.conf
ldap_sasl_authid = host/nwpllv8bu100.amer.dell@amer.company.com
[root@nwpllv8bu100 sssd]#

If I do 'kinit -k',  the /etc/krb5.keytab file has that name as well:

[root@nwpllv8bu100 sssd]# kinit -k
[root@nwpllv8bu100 sssd]# klist
Ticket cache: KCM:0
Default principal: host/nwpllv8bu100.amer.dell@amer.company.com

Valid starting   Expires  Service principal
09/01/2021 11:04:16  09/01/2021 21:04:16  krbtgt/
amer.dell@amer.company.com
renew until 09/08/2021 11:04:16
[root@nwpllv8bu100 sssd]#

I searched /etc/sssd/sssd.conf -- no "zzz" or "ZZZ" string is anywhere in
there.   So where is sssd picking up this name ZZZKBTDURBOL8 and passing it
to adcli update?

Spike







On Wed, Sep 1, 2021 at 2:46 AM Sumit Bose  wrote:

> Am Tue, Aug 31, 2021 at 09:53:01PM +0200 schrieb Alexey Tikhonov:
> > On Tue, Aug 31, 2021 at 6:47 PM Spike White 
> wrote:
> >
> > > All,
> > >
> > > OK we have a query we run in AD for machine account passwords for a
> > > certain age.  In today's run, 31 - 32 days.  Then we verify it's
> pingable.
> > >
> > > We have found such one such suspicious candidate today (two actually,
> but
> > > the other Linux server is quite sick).  So one good research candidate.
> > > According to both AD and /etc/krb5.keytab file, the machine account
> > > password was last set on 7/29.  Today is 8/31, so that would be 32
> days.
> > > This 'automatic machine account keytab renewal'  background task should
> > > trigger again today.
> > >
> > > sssd service was last started 2 weeks ago and, by all appearances,
> appears
> > > healthy.  sssctl domain-status  shows online, connected to AD
> > > servers (both domain and GC servers)..  All logins and group
> enumerations
> > > working as expected.
> > >
> > > Just now, we dynamically set the debug level to 9 with 'sssctl
> debug-level
> > > 9'.  This particular server is Oracle Linux 8.4,
> > > running sssd-*-2.4.0-9.0.1.el8_4.1.x86_64.   Installed July 13th,
> 2021.  So
> > > -- very recent sssd version.  (This problem occurs with both RHEL & OL
> > > 6/7/8, it's just today's candidate happens to be OL8.)
> > >
> > > We can't keep debug level 9 up for a great many days;  it swamps the
> > > /var/log filesystem.  But we can leave up for a few days.  We
> purposely did
> > > not restart sssd server as we know that would trigger a machine account
> > > renewal.
> > >
> > > Speaking of that -- from Sumit's sssd source code in
> > > ad_provider/ad_machine_pw_renewal.c, it appears that sssd is creating a
> > > back-end task to call external program /usr/sbin/adcli with certain
> args.
> > >  What string can I look for in which sssd log file (now that I have
> debug
> > > level 9 enabled) to tell me when this 'adcli update' task (aka
> 'automatic
> > > machine account keytab renewal')  is triggered?
> > >
> >
> > It seems SSSD itself only logs in case of errors. I didn't find any
> > explicit logs around `ad_machine_account_password_renewal_send()`.
> > But perhaps there will be something like "[be_ptask_execute] (0x0400):
> Task
> > [AD machine account password renewal]: executing task" from generic
> > be_ptask_* helpers in the sssd_$domain.log (I'm not sure).
> >
> > Also at this verbosity level `--verbose` should be supplied to adcli
> itself
> > and I guess output should be captured in sssd_$domain.log as well. I'm
> not
> > familiar with `adcli` internals, you can take a glance at
> > https://gitlab.freedesktop.org/realmd/adcli to find its log messages.
>
> Hi,
>
> if SSSD's debug_level is 7 or higher the '--verbose' option is set
> when calling adcli and the output is added to the backend logs. It will
> start with log message "--- adcli output start---".
>
> HTH
>
> 

[SSSD-users]Re: Trouble-shooting sssd’s ‘Automatic Kerberos Host Keytab Renewal’ with AD back-end….

[Spike White]

All,

OK we have a query we run in AD for machine account passwords for a certain
age.  In today's run, 31 - 32 days.  Then we verify it's pingable.

We have found such one such suspicious candidate today (two actually, but
the other Linux server is quite sick).  So one good research candidate.
According to both AD and /etc/krb5.keytab file, the machine account
password was last set on 7/29.  Today is 8/31, so that would be 32 days.
This 'automatic machine account keytab renewal'  background task should
trigger again today.

sssd service was last started 2 weeks ago and, by all appearances, appears
healthy.  sssctl domain-status  shows online, connected to AD
servers (both domain and GC servers)..  All logins and group enumerations
working as expected.

Just now, we dynamically set the debug level to 9 with 'sssctl debug-level
9'.  This particular server is Oracle Linux 8.4,
running sssd-*-2.4.0-9.0.1.el8_4.1.x86_64.   Installed July 13th, 2021.  So
-- very recent sssd version.  (This problem occurs with both RHEL & OL
6/7/8, it's just today's candidate happens to be OL8.)

We can't keep debug level 9 up for a great many days;  it swamps the
/var/log filesystem.  But we can leave up for a few days.  We purposely did
not restart sssd server as we know that would trigger a machine account
renewal.

Speaking of that -- from Sumit's sssd source code in
ad_provider/ad_machine_pw_renewal.c, it appears that sssd is creating a
back-end task to call external program /usr/sbin/adcli with certain args.
 What string can I look for in which sssd log file (now that I have debug
level 9 enabled) to tell me when this 'adcli update' task (aka 'automatic
machine account keytab renewal')  is triggered?

I'm less certain now that we've surveyed our env that this background
'adcli update' task is the reason behind 70 - 80 servers / month dropping
off the domain.  It might be a slight contributor, but I find only a very
few pingable servers with machine account last renewal date between 30 and
40 days.

Yes, I can disable this default 30 day automatic update and roll my own
'adcli update' cron.  But that's a mass deployment, to fix what might not
be the problem.   I want to verify this is the actual culprit before I take
those drastic steps.

Spike



On Mon, Aug 30, 2021 at 11:39 AM Patrick Goetz 
wrote:

> So i think you just want:
>
>kinit -R -k $HOSTNAME$
>
>
>
> On 8/30/21 11:28 AM, Mote, Todd wrote:
> > I wrote that from memory.  What's needed is the shortname and a $, but
> thinking more about it now, that's needed at the end of the shortname not
> the beginning.
> >
> > -Original Message-
> > From: Patrick Goetz 
> > Sent: Monday, August 30, 2021 11:25 AM
> > To: sssd-users@lists.fedorahosted.org
> > Subject: [SSSD-users]Re: Trouble-shooting sssd’s ‘Automatic Kerberos
> Host Keytab Renewal’ with AD back-end….
> >
> > Todd,
> >
> > On 8/27/21 9:41 AM, Mote, Todd wrote:
> >> We ultimately decided to deploy a cron job with the install that ran
> periodically (less than the renewal period) to keep the keytab fresh (kinit
> -R -k $($hostname -s)).  We haven't had computers falling off the domain
> since we implemented that.
> >>
> >
> > Are you sure about this syntax?  Adding a -s flag in $( ) containing a
> bash variable doesn't do anything.
> >
> > ___
> > sssd-users mailing list -- sssd-users@lists.fedorahosted.org To
> unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> > Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> > Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
> >>> This message is from an external sender. Learn more about why this <<
> >>> matters at https://links.utexas.edu/rtyclf.<<
> > ___
> > sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> > To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> > Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> > Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
> >>> This message is from an external sender. Learn more about why this <<
> >>> matters at https://links.utexas.edu/rtyclf.<<
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List 

[SSSD-users]Re: Trouble-shooting sssd’s ‘Automatic Kerberos Host Keytab Renewal’ with AD back-end….

[Spike White]

Todd,

I confess I don't completely understand your solution.   I get that
configuration management tools use the passwordlastset attribute with a
value that's greater than XX days to cull objects.   My Windows server
engineering counterparts have a scheduled job that deletes all machine
accounts from their Windows OU where passwordlastset attribute > 60 days
and server not pingable.   (Actually, it moves the machine account to an
archival OU and then deletes it from archival OU if a Windows SE hasn't
moved it back in 90 days).

Also, by policy our AD forest locks all machine accounts where
passwordlastset attribute > 40 days.

So I get that part.

But you said:
 We ultimately decided to deploy a cron job with the install that ran
periodically (less than the renewal period) to keep the keytab fresh (kinit
-R -k $($hostname -s)).

I get what this is doing.  Actually, sssd typically uses the service
principal 'host/@'.   For example:  host/
austgcore17.us.example@amer.example.com.  So I would do this:

 kinit -R -k host/austgcore17.us.example@amer.example.com

or (even simpler):
   kinit -R -k

since kinit appears to assume this host/  service principal if you don't
specify it.  What you're doing is refresh the host's Kerberos TGT ticket.
 Actually, you're doing it for your cron job only -- sssd seems to store
its host credential in
cache FILE:/var/lib/sss/db/ccache_AMER.EXAMPLE.COM_VgdSdK or some such.

So you're renewing your host's TGT ticket.  But by default, the max
lifetime for a TGT ticket is 24hrs (our AD DCs allow max 10 hrs -- that's
pretty std recommendation for AD).  And your max renewal lifetime is 7 days
by default.  After that, you'd have to get a fresh kerberos TGT ticket.

So are you completely disabling sssd's automatic machine account password
renewal (by setting ad_maximum_machine_account_password_age = 0)?  And then
you're never changing your machine account passwords ever;  your cron job
is just refreshing your host's TGT ticket every 9 hrs or so for 7 days?

I'm not fully following the explanation of your approach.

Also, machine account passwords are related to kerberos keytab entries.
For a machine account, a Kerberos keytab entry is the machine account
password (encrypted) with other relevant information, such as timestamp,
KVNO, service principal name and encryption type.  The machine account
password stored in AD (with a particular msDS-KeyVersionNumber) must change
the corresponding /etc/krb5.keytab entry (with the same KVNO number).
That's how this client authenticates to Kerberos (AD) that it's who it
claims to be.

Spike

On Fri, Aug 27, 2021 at 9:41 AM Mote, Todd  wrote:

> As a follow on to that, to keep themselves clear of debris, configuration
> management tools use the passwordlastset attribute with a value that's
> greater than XX days to cull objects as well.  We had similar issues when
> we first implemented SSSD several years ago too.  We ultimately decided to
> deploy a cron job with the install that ran periodically (less than the
> renewal period) to keep the keytab fresh (kinit -R -k $($hostname -s)).  We
> haven't had computers falling off the domain since we implemented that.
>
> Isn’t the issue that the keytab expires and is not renewed in time, then
> the computer can't change its password because the domain can't verify the
> keytab?  Also, aren't machine passwords different from Kerberos keytabs?
> Related, because a machine can't change it's password if it can't prove who
> it is via Kerberos and the keytab.  I just want to make sure those aren't
> being conflated.  Similarly, a computer can't update it's DNS record in the
> domain with out Kerberos, so similarly, if the keytab is not kept fresh,
> little domain object maintenance can happen, because Kerberos is stale.
>
> Computer account password changes are always initiated by clients, not the
> domain, even on windows.
>
> Todd
>
> -Original Message-
> From: James Ralston 
> Sent: Thursday, August 26, 2021 10:31 PM
> To: End-user discussions about the System Security Services Daemon <
> sssd-users@lists.fedorahosted.org>
> Subject: [SSSD-users]Re: Trouble-shooting sssd’s ‘Automatic Kerberos Host
> Keytab Renewal’ with AD back-end….
>
> On Thu, Aug 26, 2021 at 8:11 PM Christian, Mark 
> wrote:
> > [W]hy bother with updating the machine account password?
>
> For sites that have a lot of machine churn, where machine accounts aren't
> reliably purged from AD when the underlying host is decommissioned,
> disabling and/or purging machine accounts with old passwords is essentially
> a garbage collection activity, to prevent stale machine accounts from
> continuing to exist in AD in perpetuity.
>
> Also, some sites must conform with security guidelines that *require*
> frequent changes of machine account passwords:
>
>
> https://www.stigviewer.com/stig/microsoft_windows_server_2016/2021-03-05/finding/V-225033
>
> Granted, that STIG rule applies to Windows machine accounts, not Linux
> 

[SSSD-users]Re: Trouble-shooting sssd’s ‘Automatic Kerberos Host Keytab Renewal’ with AD back-end….

[Spike White]

Sumit and Gordon,

You have given me much to think on and digest.  Thanks.

Gordon, we religiously patch monthly. Except for sssd in July, where a new
update sssd*-2.4.0-9.0.1.el8_4.1.x86_64  broke our env and we had to roll
back the update to previous version sssd*-2.4.0-9.0.1.el8.x86_64 .  (We
pushed a work-around and rolled out the new sssd version in Aug.)  This
problem with automatic machine account renewal has been a problem for many
months, server ops informs us.

I see Sumit is the author of
SOURCES/sssd-x.x.x/src/providers/ad/ad_machine_pw_renewal.c.I see it’s
doing a be_ptask_create() to do the AD Machine PW renewal.

Sumit, we have dozens and dozens of dropped-off servers that we can
survey.  All it takes is some slight time to find a machine account in our
OU where 'passwordLastSet'  > 40 days.  For instance, using the powershell
invocation that Gordon calls out.  (If it’s too old, chances are it’s a
server decomm, where AD was not successfully cleaned up.  That happens –
rarely.)

Yesterday, we surveyed one such server that had dropped of the domain.  We
see that the msDS-KeyVersionNumber  (in AD) is one higher than the latest
KVNO (in the local /etc/krb5.keytab file).   This indicates (to me) that AD
was able to successfully update the machine account password, but this
local be_task did not think AD successfully updated the entry, so it did
not update the local /etc/krb5.keytab file with the new entry.

Again, this communication failure must be very infrequent, as it’s
occurring only 0.3% of the time or so.  On random Linux servers – no
discernible geographic or build location pattern.

BTW, we are not the AD admins.  We’re trying to get the content of the AD
DC logs for the specified time period, but these logs are considered highly
sensitive.  Also, I don’t know how frequently these logs cycle.

On a random test server, we set debug level == 5 and set
ad_maximum_machine_account_password_age to less than passwordLastSet
duration.   I.e., to trigger a machine account password renewal.  Then we
restarted sssd.  Sure enough, 15 mins after sssd service restart, there was
a machine account password renewal.  We saw it in the /etc/krb5.keytab
entries.  But we didn’t see any indications of this in the sssd logs when
we reviewed them.  (Of course, our password renewal was successful – so
don’t expect much logging with successful be_ptasks).

Debug level 5 does not seem to fill up the /var/log filesystem to 100% like
debug level 9 does.  We’ll keep monitoring disk space on this test server.
Until we track this down, we might set debug level 5 across all servers.

Spike



On Thu, Aug 26, 2021 at 10:31 PM James Ralston  wrote:

> On Thu, Aug 26, 2021 at 8:11 PM Christian, Mark
>  wrote:
> > [W]hy bother with updating the machine account password?
>
> For sites that have a lot of machine churn, where machine accounts
> aren't reliably purged from AD when the underlying host is
> decommissioned, disabling and/or purging machine accounts with old
> passwords is essentially a garbage collection activity, to prevent
> stale machine accounts from continuing to exist in AD in perpetuity.
>
> Also, some sites must conform with security guidelines that *require*
> frequent changes of machine account passwords:
>
>
> https://www.stigviewer.com/stig/microsoft_windows_server_2016/2021-03-05/finding/V-225033
>
> Granted, that STIG rule applies to Windows machine accounts, not Linux
> machine accounts, but disabling any machine account in AD whose
> password is older than 30 days is one way to detect any Windows
> clients that are nonconforming with the STIG. And in many cases it's
> easier to apply that rule globally than on a per-OU basis (to exempt
> non-Windows machine accounts).
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[SSSD-users]Trouble-shooting sssd’s ‘Automatic Kerberos Host Keytab Renewal’ with AD back-end….

[Spike White]

Sssd experts,

*Short summary: * How can we troubleshoot sssd’s ‘Automatic Kerberos Host
Keytab Renewal’ process?We have ~0.4%  of our Linux servers dropping
off the AD domain monthly.

*Longer explanation:*

Over the past two years, we have on-boarded sssd as our Linux AD
integration component.  Largely displacing a former commercial product that
did the same.

We have about ~20K Linux servers that are sssd-enabled.  A mix of RHEL6,
RHEL7, RHEL8, Oracle Linux 6, 7 and 8.   We have ~7K Linux servers still on
the old commercial product.  (For certain edge-case scenarios, such as
DMZs, the commercial product works better.)

Our AD forest is a single AD forest, with 4 regional child domains.  All
with transitive trust.  Sssd auto-discovers parent domain and all 4 child
domains, no problem – whenever it’s adcli joined to its regional local
domain.

Why are I writing this?

Because we are researching an ongoing problem reported by L1 server ops.
About 70 – 80 sssd-enabled Linux servers / month drop off the domain.  Out
of our current sssd-enabled population of ~20K server, that’s not
horrible.  But still it should be better.  (Our former commercial product
did better.)

It’s not limited to one particular OS, OS version, build location or
region.  We have surveyed; it seems to occur randomly among all OS
versions, regions and locations.

To be clear, it’s extremely likely that this behavior arising from some
subtle misconfiguration on our part – not from any sssd or adcli or
Kerberos bug.  We have a couple of configuration improvements we’re
pursuing.  (Kerberos max ticket lifetime mismatch between AD and
/etc/krb5.conf file for instance.)

We are taking sssd’s default settings for
ad_maximum_machine_account_password_age and
ad_machine_account_password_renewal_opts.   So after 30 days, sssd will
attempt daily to renew the host Kerberos keytab file.  It should re-attempt
daily if not renewed.  By company policy, our AD disables any machine
accounts that have not renewed their credentials in 40 days.   So when we
find servers that have dropped off the domain, it’s because they have not
renewed their AD machine accounts in 40 days.

We have SR’s open with our OS vendors (Redhat and Oracle respectively) for
months now.  To no great help.  (They gave a few suggestions, but none
panned out.)

We thought we were hitting this bug:

https://github.com/SSSD/sssd/issues/4762

But packet captures proved that adcli update is using TCP on RHEL7/8.
Thus, this might be a potential problem, but only on RHEL6.  (BTW
‘udp_preference_limit = 0’ doesn’t force use of TCP for the kpasswd
invocation in RHEL6 – it still uses UDP.  Thus, the recommended work-around
for this bug doesn’t work.)

So that isn’t our underlying problem.

We’re at a loss now – as you can see, we’re grasping at straws.

How can we troubleshoot sssd’s ‘automatic Kerberos Host keytab renewal’
process?  Whenever we inspect a particular server it works.  We can’t run
all sssd clients at debug level 9;  it fills up /var/log filesystem after a
few days of that.  We’re interested in troubleshooting that one particular
sssd process on all clients;  not all parts of sssd.

Other than a steep learning curve (on our part), obscure situations (like
DMZ auto-discovery of AD controllers) and exotic scenarios (like above),
we’re quite happy with our 2 yr journey of direct AD integration with
sssd.Obviously, the troubleshooting tools on RHEL6 are very minimal.
But certainly, overall the quality of sssd on RHEL7/8 is excellent.  AD
integration has innumerable devils in the details; I’m amazed that sssd
performs as well as it does against our multi-domain forest.

Spike

PS the problem with sssd auto-discovery of AD controllers in DMZs has been
fixed in a recent sssd release.  The better discovery algorithm was
implemented – same one used by Windows clients and commercial products.
It’s just that recent sssd version is not on RHEL7 or 8.
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[SSSD-users] One slight enhancement to sssctl user-checks...

[Spike White]

All,

sssctl user-check is very good.In particular, when you want to see if a
particular user is conferred access, you look for the:

pam_acct_mgmt: Success

or the:

pam_acct_mgmt: Permission denied

lines.

But often, users are members of multiple various groups.  It's often
difficult to track down which of the particular groups or user entries are
actually conferring the access to the user.

It would be nice to output on success, which user or group is conferring
the login access.

I'm not saying it needs to be exhaustive.  I.e., no need to parse every
group to see which groups.
But sssctl at that point in time has determined (based on some rule) that
login access is permitted.  Just output whatever that matching rule is.

If you wanted this additional output only in a verbose mode, that'd be
fine.

I suppose I could probably turn on debug level on sssd, restart it and grub
through all the sssd log files to find which user or group conferred
access.  But that'd be painful.  Usually I construct a list of all AD
groups this individual is a member of (often it's 15-20).  Then which of
these groups are UNIX-enabled in AD.  Then of those, which are permitted.

Spike
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[SSSD-users] Re: [RFC] What would you like to see on sssd.io

[Spike White]

Pavel,

To me, what was most helpful in the old documentation was the architectural
discussions embedded in the enhancement requests.  When the requests were
satisfied.

Examples:
 use of short names in non-local domains
 auto-discovery of trusted domains

For instance, until I read that discussion I was unaware that if you turned
off auto-discovery and explicitly defined each child domain, that sssd
would no longer contact the global catalog (GC) and thus, full membership
in universal groups was not found.  Only if you turned on auto-discovery
did the sssd code query the GC.  this is not intuitive, so having that
documentation was a great help.

Another example is the discussion of that better discovery algorithm for AD
DCs.   It came out in a recent sssd release, maybe in the last 6-9 months.
 But I can't find that algorithm discussion now.

Spike

On Wed, May 12, 2021 at 7:15 AM Pavel Březina  wrote:

> Dear SSSD community,
> we have recently introduced new SSSD project web page at
> https://sssd.io. We would like to keep adding new content, we have
> plenty of ideas but we would also like to get some tips from you:
>
> What articles would you like to see on the page? What knowledge gaps are
> hard to fill with existing documentation? Feel free to suggest both user
> and developer facing content.
>
> Thanks,
> Pavel
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[SSSD-users] Finding auto.master and other automount maps from non-local AD domain

[Spike White]

All,

I have sssd working fine for my AD regional child domains (all have a
transitive trust).  It can find users & (universal) groups from all AD
domains.

For instance, a server in amer.company.com will auto-discover non-local
child domains apac.company.com and emea.company.com.

I have this:

[sssd]

domains = amer.company.com

domain_resolution_order = amer.company.com, emea.company.com,
apac.company.com, japn.company.com, company.com

services = nss,pam,ifp,autofs

….



[domain/amer.company.com]

autofs_provider = ad

ldap_autofs_search_base = ou=automount,ou=UNIX,dc=AMER,dc=COMPANY,dc=COM

…



[domain/amer.company.com/emea.company.com]

...



In AMER,  automount works great.  Can find the automount maps no problem.
With the ldap_autofs_search_base above.  (all our automount maps are housed
in amer AD domain).



However, we’re looking closely at an EMEA server and we realize it doesn’t
find the automount maps out of AD.



In the sssd_autofs.log file, we notice it was looking for unqualified
“auto.master”, so it converted that to auto.mas...@emea.company.com.
  Whereas on an amer server, it converted that unqualified name to
auto.mas...@amer.company.com.



This gave us the idea to change /etc/auto.master from this line:



+auto.master



To this line:



+auto.mas...@amer.company.com



This seems to do better.  From the sssd_autofs.log file:



(2021-05-11 20:51:25): [autofs] [sss_autofs_cmd_setautomntent] (0x0400):
Obtaining autofs map auto.mas...@amer.company.com

(2021-05-11 20:51:25): [autofs] [cache_req_set_plugin] (0x2000): CR #0:
Setting "Get autofs map" plugin

(2021-05-11 20:51:25): [autofs] [cache_req_send] (0x0400): CR #0: New
request 'Get autofs map'

(2021-05-11 20:51:25): [autofs] [cache_req_process_input] (0x0400): CR #0:
Parsing input name [auto.mas...@amer.company.com]

(2021-05-11 20:51:25): [autofs] [sss_domain_get_state] (0x1000): Domain
emea.company.com is Active

(2021-05-11 20:51:25): [autofs] [sss_domain_get_state] (0x1000): Domain
company.com is Active

(2021-05-11 20:51:25): [autofs] [sss_domain_get_state] (0x1000): Domain
japn.company.com is Active

(2021-05-11 20:51:25): [autofs] [sss_domain_get_state] (0x1000): Domain
amer.company.com is Active

(2021-05-11 20:51:25): [autofs] [sss_parse_name_for_domains] (0x0200): name
'auto.mas...@amer.company.com' matched expression for domain '
amer.company.com', user is auto.master

(2021-05-11 20:51:25): [autofs] [cache_req_set_name] (0x0400): CR #0:
Setting name [auto.master]

(2021-05-11 20:51:25): [autofs] [cache_req_select_domains] (0x0400): CR #0:
Performing a single domain search

(2021-05-11 20:51:25): [autofs] [sss_domain_get_state] (0x1000): Domain
emea.company.com is Active

(2021-05-11 20:51:25): [autofs] [sss_domain_get_state] (0x1000): Domain
amer.company.com is Active

(2021-05-11 20:51:25): [autofs] [cache_req_search_domains] (0x0400): CR #0:
Search will check the cache and check the data provider

(2021-05-11 20:51:25): [autofs] [cache_req_global_ncache_add] (0x2000): CR
#0: This request type does not support global negative cache

(2021-05-11 20:51:25): [autofs] [cache_req_process_result] (0x0400): CR #0:
Finished: Not found

(2021-05-11 20:51:25): [autofs] [client_recv] (0x0200): Client disconnected!



However, it does not find the child auto.* maps.  Whereas a server in amer
does.



I would rather not have to copy my correct autofs AD structure to each
child AD domain.  It’s tested and working for over a year in amer.



How can I get a non-amer server to see the automount maps?



Spike White
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[SSSD-users] Re: RHEL 8.3 KDC has no support for encryption type

[Spike White]

Jeremy,

My understanding is that even AD 2016 will support arcfour-hmac (even
though it's deprecated and not recommended).   Local company AD teams will
make the decision to stop supporting arcfour-hmac or not.  (for instance,
our company's team tried -- and it broke something to do with cross-domain
auth. So they reverted.)

I don't know when AD quit supporting 3des-cbc.

Spike

On Sun, May 9, 2021 at 5:09 PM Jeremy Monnet  wrote:

> Hi,
>
> > To allow all the old (weak) RHEL7 crypto ciphers (like 3des-cbc and
> arcfour-hmac).
> >
> > It's not advisable to leave crypto-polcies at LEGACY -- that accepts
> some truly weak ciphers.
> >
> >
> You are right, only I do not decide the AD version used... 2012R2 is
> still supported by Microsoft, so people are not eager to migrate to
> 2016 or 2019. That brings me to another question :
> - Is there a reference to supported ciphers, eg will rhel without
> enabling weak ciphers will work out of the box with an AD 2016 (that
> could another argument to upgrade) ?
>
> And yes you are right, the issue is pure kerberos, sssd just sits on top...
>
> Regards,
>
> Jeremy
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[SSSD-users] Re: RHEL 8.3 KDC has no support for encryption type

[Spike White]

Jeremy,

First off, this is not a sssd problem.  You've proven that by your kinit -k
attempts failing.  This is an underlying problem between your kerberos
client, your AD DC and your /etc/krb5.keytab file.  Once you fix this
underlying issue, I expect sssd will work.

Your AD domain may be accepting only weak crypto ciphers.  By default,
RHEL8 sets crypto-policies to DEFAULT.

You can do this:

update-crypto-policies --show

to see the current crypto policy.  As a simple test, you can do this:

update-crypto-policies --set LEGACY

To allow all the old (weak) RHEL7 crypto ciphers (like 3des-cbc and
arcfour-hmac).

It's not advisable to leave crypto-polcies at LEGACY -- that accepts some
truly weak ciphers.


Spike

On Wed, May 5, 2021 at 2:27 PM Jeremy Monnet  wrote:

> Hello,
>
> We upgraded today a RHEL 7.9 to RHEL8.3. We encounter now that error
> KDC has no support for encryption type
>
> which prevents authentication. The server has been remove and rejoin
> to the Active Directory with realm join -U user@DOMAIN. The object has
> been created in the AD (2012R2 in case it would be relevant) with
> SPNs:
> host/HOSTNAME
> host/fqdn
> RestrictedKrbHost/HOSTNAME
> RestrictedKrbHost/fqdn
>
>
> sssd_domain.log contains
> (2021-05-05 21:06:55): [be[bcrs.fr]] [sasl_bind_send] (0x0100):
> Executing sasl bind mech: GSS-SPNEGO, user: HOSTNAME$
> (2021-05-05 21:06:55): [be[bcrs.fr]] [ad_sasl_log] (0x4000): SASL:
> GSSAPI client step 1
> (2021-05-05 21:06:55): [be[bcrs.fr]] [ad_sasl_log] (0x4000): SASL:
> GSSAPI client step 1
> (2021-05-05 21:06:55): [be[bcrs.fr]] [ad_sasl_log] (0x0040): SASL:
> GSSAPI Error: Unspecified GSS failure.  Minor code may provide more
> information (KDC has no support for encryption type)
> (2021-05-05 21:06:55): [be[bcrs.fr]] [sasl_bind_send] (0x0020):
> ldap_sasl_bind failed (-2)[Local error]
> (2021-05-05 21:06:55): [be[bcrs.fr]] [sasl_bind_send] (0x0080):
> Extended failure message: [SASL(-1): generic failure: GSSAPI Error:
> Unspecified GSS failure.  Minor code may provide more information (KDC
> has no support for encryption type)]
> (2021-05-05 21:06:55): [be[bcrs.fr]] [child_sig_handler] (0x1000):
> Waiting for child [2234].
> (2021-05-05 21:06:55): [be[bcrs.fr]] [child_sig_handler] (0x0100):
> child [2234] finished successfully.
> (2021-05-05 21:06:55): [be[bcrs.fr]] [sdap_cli_connect_recv] (0x0040):
> Unable to establish connection [1432158227]: Authentication Failed
> (2021-05-05 21:06:55): [be[bcrs.fr]] [_be_fo_set_port_status]
> (0x8000): Setting status: PORT_NOT_WORKING. Called from:
> src/providers/ldap/sdap_async_connection.c: sdap_cli_connect_recv:
> 2095
>
> We have tried numerous things with kinit for example :
> [root@hostname sssd]# klist -ke
> Keytab name: FILE:/etc/krb5.keytab
> KVNO Principal
> 
> --
>2 HOSTNAME$@DOMAIN (aes128-cts-hmac-sha1-96)
>2 HOSTNAME$@DOMAIN (aes256-cts-hmac-sha1-96)
>2 host/HOSTNAME@DOMAIN (aes128-cts-hmac-sha1-96)
>2 host/HOSTNAME@DOMAIN (aes256-cts-hmac-sha1-96)
>2 host/fqdn@DOMAIN (aes128-cts-hmac-sha1-96)
>2 host/fqdn@DOMAIN (aes256-cts-hmac-sha1-96)
>2 RestrictedKrbHost/HOSTNAME@DOMAIN (aes128-cts-hmac-sha1-96)
>2 RestrictedKrbHost/HOSTNAME@DOMAIN (aes256-cts-hmac-sha1-96)
>2 RestrictedKrbHost/fqdn@DOMAIN (aes128-cts-hmac-sha1-96)
>2 RestrictedKrbHost/fqdn@DOMAIN (aes256-cts-hmac-sha1-96)
>
> [root@hostname sssd]# kinit -V -k
> Using new cache: persistent:0:krb_ccache_PECiZeh
> Using principal: host/fqdn@DOMAIN
> kinit: Client 'host/fqdn@domain' not found in Kerberos database while
> getting initial credentials
>
> [root@hostname sssd]# kinit -V -k HOSTNAME$
> Using new cache: persistent:0:krb_ccache_cFLtQ1H
> Using principal: HOSTNAME$@DOMAIN
> kinit: Keytab contains no suitable keys for HOSTNAME$@DOMAIN while
> getting initial credentials
>
> We have added
> krb5_validate = False
> in sssd.conf and
> [libdefaults]
>  allow_weak_crypto = true
>  default_tgs_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc
> des-cbc-md5
>  default_tkt_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc
> des-cbc-md5
>  permitted_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc
> des-cbc-md5
> in krb5.conf
>
> and set msDS-SupportedEncTypes to 31 (which means "all" if I
> understand correctly) on the AD object.
>
> With no success.
>
> I do not know what to do now :-)
>
> Thanks for your help
>
> Jeremy
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> Do not reply to spam on the list, report it:
> 

[SSSD-users] Re: How to lower case home dirs in sssd with AD as a backend?

[Spike White]

Sumit,

Yes exactly.

   override_homedir = %o

would return the original  home directory retrieved from the identity
provider.  What would be nice is another % flag, which retrieves the
original home dir, but lower cases this original home dir.  for instance:

   override_homedir = %L

(%l is already in use.)

Or an equiv option for case_sensitive (which is for user and groups only).
  Say:

case_sensitive_homedirs = {True|False|Preserving}

Spike

On Wed, May 5, 2021 at 12:35 AM Sumit Bose  wrote:

> Am Tue, May 04, 2021 at 11:58:56AM -0500 schrieb Spike White:
> > sssd experts,
> >
> > With an AD backend, by default the AD provider sets case_sensitive ==
> > False.  This has the desired action of lower-casing user names.  (and
> group
> > names).  But not home directories.
> >
> > How can we similarly lower case home directories?  Our AD admins have an
> > edict to camel-case their home directory and user name entries in AD.
> > (Apparently, some high-level manager wishes to see user names in camel
> > case.)
> >
> > In our old commercial AD integration product, it had a setting:
> >
> > lowercase-homedirs = true
> >
> > and then it took whatever it found in AD and merely lower cased it.
> >
> > To sort of work around this problem when doing a sssd migration, we have
> > set:
> >
> > [nss]
> >
> > override_homedirs = /home/%u
> >
> >
> >
> > This works.  But effectively, this is throwing out whatever is in AD and
> > replacing it with /home/
> >
> > This only works because all our home dirs. are under /home.  What about
> > other companies that need to lower-case their home dirs., but they’re not
> > always under /home?  How would you lower-case home dirs. in sssd?
>
> Hi,
>
> you are right, currently SSSD uses the home directory string provided by
> AD as is without modifications. I guess you are looking for something
> like '%o' for override_homedirs which does not add the original value
> but the lower-case version.
>
> bye,
> Sumit
>
> >
> > Spike
>
> > ___
> > sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> > To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> > Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> > Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[SSSD-users] How to lower case home dirs in sssd with AD as a backend?

[Spike White]

sssd experts,

With an AD backend, by default the AD provider sets case_sensitive ==
False.  This has the desired action of lower-casing user names.  (and group
names).  But not home directories.

How can we similarly lower case home directories?  Our AD admins have an
edict to camel-case their home directory and user name entries in AD.
(Apparently, some high-level manager wishes to see user names in camel
case.)

In our old commercial AD integration product, it had a setting:

lowercase-homedirs = true

and then it took whatever it found in AD and merely lower cased it.

To sort of work around this problem when doing a sssd migration, we have
set:

[nss]

override_homedirs = /home/%u



This works.  But effectively, this is throwing out whatever is in AD and
replacing it with /home/

This only works because all our home dirs. are under /home.  What about
other companies that need to lower-case their home dirs., but they’re not
always under /home?  How would you lower-case home dirs. in sssd?

Spike
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[SSSD-users] Where is the reference to the better AD DC discovery algorithm recently implemented in a recent release?

[Spike White]

All,

I read with great interest the release notes on a recent sssd release
notes.  That terse note had a link to a fuller discussion on the better AD
DC discovery algorithm.

The original sssd AD DC discovery algorithm  looked up the SRV records in
DNS for this local AD domain.   It randomly picked 5 AD DCs to send the
CLDAP ping.  the first AD DC that responded it would query to determine AD
site and thus, preferred servers.

However, if none of these 5 AD DCs respond -- game over!

The new better discovery algorithm  implements the same as Windows (& some
commercial AD integration products such as Quest) implement.   They do a
CLDAP ping to *all* AD DCs found via SRV DNS lookup.  The first AD DC that
responds, it queries to determine AD site and thus, preferred servers.

What is the difference?  Quite a lot actually -- in the real world.  Lots
of companies when implementing DMZs or other tightly-firewalled segments
(like back-traffic from public cloud) only allow access to 2-3 read-only
DCs.  Yet, the DNS SRV lookup will return all the DCs.  RW and RO.  You
might be back 80 - 90 DCs, of which only 2-3 are truly reachable.

Thus Windows, Quest and new sssd versions work here -- out of the box.  Old
sssd version only work if you specifically disable site discovery and
hard-code the specific 2-3 RO DCs.

BTW there is an RFC that documents this new better discovery algorithm.

So -- where is the reference to this new discovery algorithm?  And which
recent sssd release implements it?  I can't find it now.

I'm stuck administering RHEL6, 7 and 8 servers.  So it'll be years before I
can enjoy this new discovery algorithm.  But at least I have something to
look forward to -- years from now.

Spike
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[SSSD-users] Re: Is this still a security problem to be concerned about?

[Spike White]

Pawel,

Thank you for the detailed  explanation.   I know for the "Kerb-roasting"
hacking technique, if you avoid the weak KRB5 ciphers (3des-cbc,
arcfour-hmac), that thwarts this attack.

If we limit our KRB5 encryption algorithms to only strong cyphers (AES128
and AES256), would that  thwart the above SSSD attack?

Also, our KRB5 tickets expire every 10 hrs.

Spike

On Sat, Mar 20, 2021 at 6:43 PM Pawel Polawski  wrote:

> Hi Spike,
>
> The KCM module mentioned in article was introduced in SSSD 1.15.3 [1]
> Latest RHEL7 version is 7.9 with SSSD 1.16.5
> Latest RHEL8 version is 8.3.0 with SSSD 2.3.0
> Last RHEL7 version without KCM module implemented in SSSD was RHEL 7.3
> with SSSD 1.14
> RHEL8 uses KCM by default, where RHEL7 is using KEYRING by default.
> For more information about KCM in SSSD you can check KCM design documents
> [2].
>
> Quoting the linked article:
> "With the right Kerberos tickets, it is possible to move laterally to the
> rest of the Active Directory domain.
> If a privileged user authenticates to a compromised Linux system (such as
> a Domain Admin) and leaves
> a ticket behind, it would be possible to steal that user's ticket and
> obtain privileged rights in the Active Directory domain."
>
> I would say that no matter if KCM is used or not, if the attacker has root
> access to the machine which is part of the domain
> this is already a security concern. Using tools described in article it is
> possible to decrypt KCM disk cache and extract
> access tokens. If a privileged user will authenticate on a machine
> controlled by the attacker his access tokens will be stolen.
> Restrictive access policies inside the domain can make reusing those
> stolen tokens harder for attacker.
>
> [1] https://sssd.io/docs/users/relnotes/notes_1_15_3
> [2] https://sssd.io/docs/design_pages/kcm.html
>
> Best regards,
> Pawel
>
> On Sat, Mar 20, 2021 at 4:06 AM Spike White 
> wrote:
>
>> All,
>>
>>
>> https://www.fireeye.com/blog/threat-research/2020/04/kerberos-tickets-on-linux-red-teams.html
>>
>>
>> Is this a security concern for the sssd version on RHEL7 & 8?  I.e., if a
>> hacker acquires root on one low-value asset, can move laterally to more
>> high-value assets?
>>
>>
>> Spike White
>> ___
>> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
>> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
>> Fedora Code of Conduct:
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
>> Do not reply to spam on the list, report it:
>> https://pagure.io/fedora-infrastructure
>>
>
>
> --
>
> Paweł Poławski
>
> Senior Software Engineer
>
> Red Hat <https://www.redhat.com/>
>
> ppola...@redhat.com
> @RedHat <https://twitter.com/redhat>   Red Hat
> <https://www.linkedin.com/company/red-hat>  Red Hat
> <https://www.facebook.com/RedHatInc>
> <https://red.ht/sig>
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[SSSD-users] Is this still a security problem to be concerned about?

[Spike White]

All,

https://www.fireeye.com/blog/threat-research/2020/04/kerberos-tickets-on-linux-red-teams.html


Is this a security concern for the sssd version on RHEL7 & 8?  I.e., if a
hacker acquires root on one low-value asset, can move laterally to more
high-value assets?


Spike White
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[SSSD-users] Re: ldap_use_tokengroups=False is not returning correct results

[Spike White]

Sanjay,

We had the opposite problem.  with ldap_use_tokengroups = True, we were
getting incorrect group memberships.  It's been a couple of years, but I
seem to recall it was either universal group membership, or else
memberships in non-local AD domains that weren't being show.  (global
groups).

Spike

On Tue, Jan 12, 2021 at 4:13 AM Sumit Bose  wrote:

> On Fri, Jan 08, 2021 at 09:57:12PM +, Sanjay Agrawal wrote:
> > We are noticing that with ldap_use_tokengroups=False is not returning
> same results as with tokengroups. We think, it is due to two issues show
> below. Can you please confirm if they are a known issues.Â
> >
> > Thanks,
> >
> > Issue 1: It is not checking nested membership of gidNumber group, so
> missing group "group1498" from the list
> > $ ldapsearch -Q -h ad_server -LLL -b 'CN=user3901,OU=Service
> Accounts,DC=mydomain,DC=com' -s base 'objectclass=*' | grep -E
> "primaryGroupID|gidNumber|memberOf"
> > memberOf: CN=group548,OU=Groups,DC=mydomain,DC=com
> > memberOf: CN=group1414,OU=Groups,DC=mydomain,DC=com
> > primaryGroupID: 513
> > gidNumber: 32771
> > Â
> > $ ldapsearch -Q -h ad_server -LLL -b 'OU=Groups,DC=mydomain,DC=com'
> '(msSFU30Name=group1191)' | grep -E "gidNumber|memberOf"
> > memberOf: CN=group1498,CN=Builtin,DC=mydomain,DC=com
> > gidNumber: 32771
> > Â
> > testhost4:0# tail -1 /etc/sssd/sssd.conf
> > ldap_use_tokengroups = False
>
> Hi,
>
> can you send your full sssd.conf so that I can better understand which
> provider, schema etc are used?
>
> bye,
> Sumit
>
> > Â
> > testhost4:0# groups  user3901
> > user3901 : group1191 group548 group1414
> >
> >
> >
> > Issue 2: without tokengroups, It's not considering primaryGroupID as
> group of the user, so this is missing from group list
> > All tokengroups for this user
> >
> > $ ldapsearch -Q -h ad_server -LLL -b
> 'CN=user5305,CN=Users,DC=mydomain,DC=com' -s base 'objectclass=*'
> tokenGroups
> > dn: CN=user5305,CN=Users,DC=mydomain,DC=com
> > tokenGroups:: AQIAAAUgIQIAAA==
> > tokenGroups:: AQUAAAUVDk/CBIowfwb4F/I9gBwCAA==
> > tokenGroups:: AQUAAAUVDk/CBIowfwb4F/I95d4AAA==
> > tokenGroups:: AQUAAAUVDk/CBIowfwb4F/I9FwQBAA==
> > tokenGroups:: AQUAAAUVDk/CBIowfwb4F/I9YB0BAA==
> > tokenGroups:: AQUAAAUVDk/CBIowfwb4F/I91uIAAA==
> > tokenGroups:: AQUAAAUVDk/CBIowfwb4F/I9kQQAAA==
> > tokenGroups:: AQUAAAUVDk/CBIowfwb4F/I9vBwCAA==
> > tokenGroups:: AQUAAAUVDk/CBIowfwb4F/I9594AAA==
> > tokenGroups:: AQUAAAUVDk/CBIowfwb4F/I9gHABAA==
> > tokenGroups:: AQUAAAUVDk/CBIowfwb4F/I9KAYBAA==
> > tokenGroups:: AQUAAAUVDk/CBIowfwb4F/I9C4gBAA==
> > tokenGroups:: AQUAAAUVDk/CBIowfwb4F/I9xgQBAA==
> > tokenGroups:: AQUAAAUVDk/CBIowfwb4F/I9fOIAAA==
> > tokenGroups:: AQUAAAUVDk/CBIowfwb4F/I9K14AAA==
> > tokenGroups:: AQUAAAUVDk/CBIowfwb4F/I97BwBAA==
> > tokenGroups:: AQUAAAUVDk/CBIowfwb4F/I98j4BAA==
> > tokenGroups:: AQUAAAUVDk/CBIowfwb4F/I9sQUBAA==
> > tokenGroups:: AQUAAAUVDk/CBIowfwb4F/I9Zt8AAA==
> > tokenGroups:: AQUAAAUVDk/CBIowfwb4F/I9s7sAAA==
> > tokenGroups:: AQUAAAUVDk/CBIowfwb4F/I95aoAAA==
> > tokenGroups:: AQUAAAUVDk/CBIowfwb4F/I9tOIAAA==
> > tokenGroups:: AQUAAAUVDk/CBIowfwb4F/I98M4AAA==
> > tokenGroups:: AQUAAAUVDk/CBIowfwb4F/I9AQIAAA==
> >
> > All memberof/PrimaryGid and gidNumber for the user
> > ldapsearch -Q -h ad_server -LLL -b 'DC=mydomain,DC=com'
> '(ldap_group=user5305)' | egrep
> "name|gidNumber|memberOf|primary|AccountName"
> > memberOf: CN=group136,OU=Groups,DC=mydomain,DC=com
> > memberOf: CN=group404,OU=Groups,DC=mydomain,DC=com
> > memberOf: CN=group938,OU=Groups,DC=mydomain,DC=com
> > memberOf: CN=group717,OU=Groups,DC=mydomain,DC=com
> > memberOf: CN=group655,OU=Groups,DC=mydomain,DC=com
> > memberOf: CN=group714,OU=Groups,DC=mydomain,DC=com
> > memberOf: CN=group1015,OU=Groups,DC=mydomain,DC=com
> > memberOf: CN=group715,OU=Groups,DC=mydomain,DC=com
> > memberOf: CN=group945,OU=Groups,DC=mydomain,DC=com
> > memberOf: CN=group863,OU=Groups,DC=mydomain,DC=com
> > memberOf: CN=group1243,OU=Groups,DC=mydomain,DC=com
> > memberOf: CN=group721,OU=Groups,DC=mydomain,DC=com
> > memberOf: CN=group588,OU=Groups,DC=mydomain,DC=com
> > memberOf: CN=group869,OU=Groups,DC=mydomain,DC=com
> > memberOf: CN=group1110,OU=Groups,DC=mydomain,DC=com
> > memberOf: CN=group934,OU=Groups,DC=mydomain,DC=com
> > memberOf: CN=group1099,OU=Groups,DC=mydomain,DC=com
> > memberOf: CN=group669,OU=Groups,DC=mydomain,DC=com
> > memberOf: CN=group1520,OU=Groups,DC=mydomain,DC=com
> > memberOf: CN=group768,OU=Groups,DC=mydomain,DC=com
> > memberOf: CN=group1375,OU=Groups,DC=mydomain,DC=com
> > memberOf: CN=group226,OU=Groups,DC=mydomain,DC=com
> > name: user5305
> > primaryGroupID: 513
> > sAMAccountName: user5305
> > gidNumber: 33040
> >
> > check group with objectSid  AQUAAAUVDk/CBIowfwb4F/I9AQIAAA==
> > $ ldapsearch -Q -h ad_server -LLL -b 

[SSSD-users] CVE-2020-1472 vulnerablity for samba-client-libs RPM on RHEL7...

[Spike White]

sssd experts,

On ~Dec 14th, CVE-2020-1472 was reported against RHEL7.  It's a samba
vulnerability.  Among the very many vulnerable RPMs identified in the
errata, they list samba-client-libs RPM.

The sssd-ad RPM has an RPM dependency on this samba-client-libs RPM.  I
believe the sssd-ad RPM is the RPM that provides the sssd backend to
integrate with AD.  Thus, if we remove sssd-ad RPM, I believe we'll break
our current direct AD integration with sssd.

I'm trying to gauge our exposure.  As documented exploits using this CVE
are allegedly being seen in the wild, MITRE is rating this CVE as a 100.
But I question that -- for our environment.

We directly integrate our RHEL7 and 8 clients to AD.  Our AD DCs are true
Windows domain controllers.

As I understand it, our exposure should be minimal or none because:
1. This CVE is mainly for if you run a Samba server as an AD DC (we do
not), and
2. Since we directly integrate to AD from our sssd clients, I'm not sure
that any code in this
   samba-client-libs RPM ever gets exercised.

Comments?

I realize this CVE will be remediated in our next Linux patch cycle
(~mid-Jan).  But I'm not sure all companies are as pro-active.

Spike
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org

[SSSD-users] Re: select sssd method for authentication

[Spike White]

Marc,

Sumit raises a good point about account lock-outs.  But if that is not a
concern for you, it seems that you could accomplish this in your PAM stack.
Right now, you probably have something like:

...
authsufficient   pam_sss.so
forward_pass  try_cert_auth
...
account [default=ignore perm_denied=bad success=ok user_unknown=ignore]
pam_sss.so quiet

So you could change this first pam_sss auth line to something like:

  authsufficient   pam_sss.so
forward_pass  try_cert_auth
  authsufficient   pam_sss.so
forward_pass

That is, try smart card first and if it fails, invoke pam_sss again,
specifying password auth.

This has the disadvantage of calling pam_sss twice (which should not be too
costly due to sssd's local cache).It also could have 2x the failure
attempts, but if you rely on another PAM module for lock-out (like
pam_faillock), you'll increment your failures only once.

Spike


On Fri, Dec 18, 2020 at 10:49 AM Sumit Bose  wrote:

> On Fri, Dec 18, 2020 at 05:01:48PM +0100, mbalembo wrote:
> > Hello,
> >
> >
> > I would like to configure pam_sss.so as to separate authentication
> methods ;
> > in my case i use both password and smartcard.
> >
> > My problem is that when a smartcard is inserted, you can't use password
> > anymore because
> > it will prompt for the PIN and fail without fallback.
> >
> > Ideally i'd like to configure pam/sssd/sddm to try the "password" as a
> > password, then try as a PIN for inserted smartcards.
> > Can i configure sssd to do that ?
> > My understanding in that even if you set pam_sss to/try_cert_auth/, it
> will
> > not fallback to password if a smartcard is inserted.
>
> Hi,
>
> this is currently not possible because SSSD strongly tries to avoid
> try-and-error methods. Imo your use case is even a good example why this
> should be avoided.
>
> Assuming that you have a Smartcard inserted but you use your password
> for authentication. Since SSSD cannot know if it is the PIN or the
> password it will try the input as PIN first and then tries password
> verification. Depending on your Smartcard settings there is a fair
> chance that your Smartcard will be locked after doing this 3 or 5 times.
>
> If the password is checked first there is the same chance that your
> account will be locked on the server side if you use the PIN for
> authentication.
>
> bye,
> Sumit
>
> >
> >
> > Thanks for your help,
> > Marc
> > ___
> > sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> > To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> > Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
>
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org

[SSSD-users] Re: group member denied access to directory

[Spike White]

Is this a NFS mount point?  If so, maybe you're hitting the "16
supplemental group" NFS inherent bug.

Spike

On Fri, Nov 20, 2020 at 2:21 PM Tung, Paul  wrote:

> Hi,
>
>
>
> I was hoping someone on this list might be able to help.
>
> I’m getting permission denied when trying to access a directory owned by
> root, but with group that I’m a member of.
>
> I’m getting:  -bash: cd: testdir: Permission denied
>
>
>
> I have the following scenario:
>
> Running CentOS Linux release 7.6.1810 and sssd 1.16.5
>
>
>
> I have a mount set up /data/testdir
>
> As root, I chown/chmod testdir:
>
>Chown root:testgrpa testdir
>
>Chmod 770 testdir
>
>
>
> When I log in as user1, I currently can’t cd into /data/testdir
>
> It gives:
>
> -bash: cd: testdir: Permission denied
>
>
>
> user1 is a member of testgrpa:
>
> OUTPUT of id user1:
>
> uid=129371342(user1) gid=129371342(user1) groups=129371342(user1)
> ,29042750285(group1),1435459822(group2),3456349245(group3),……,
> *239705249(testgrpa)*
>
>
>
> OUTPUT of getent group testgrpa:
>
>  testgrpa:*: 239705249:*user1*,user2,user2,user4,…..,user50
>
>
>
>
>
> CONTENTS OF Sssd.conf:
>
> [sssd]
>
> config_file_version = 2
>
> services = nss,pam
>
> domains = dept.domain.com
>
>
>
> [nss]
>
> filter_users = root
>
> filter_groups = root
>
>
>
> [pam]
>
>
>
> [domain/dept.domai.com]
>
> id_provider = ldap
>
> auth_provider = ldap
>
> access_provider = ldap
>
> ldap_use_tokengroups = false
>
>
>
> enumerate = false
>
> cache_credentials = True
>
> case_sensitive = false
>
> ignore_group_members = false
>
> auto_private_groups = true
>
>
>
> ldap_schema = ad
>
>
>
> ldap_uri = ldaps://ldapsserver.dept.domain.com:636
>
> ldap_user_search_base = dc=ad,dc=dept,dc=domain,dc=com
>
> ldap_group_search_base = OU=Security
> Groups,OU=Groups,dc=ad,dc=dept,dc=domain,dc=com?sub?(|(cn=domain
> users)(cn=testgrpa))
>
> ldap_referrals = False
>
> ldap_group_nesting_level = 3
>
>
>
> ldap_tls_reqcert = allow
>
> ldap_tls_cacertdir = /etc/sssd
>
>
>
> ldap_use_tokengroups = True
>
> ldap_id_mapping = True
>
>
>
> override_homedir = /mnt/exports/shared/home/%u
>
> fallback_homedir = /shared/home/%u
>
>
>
> default_shell = /bin/bash
>
>
>
> ldap_access_order = filter, expire
>
> ldap_account_expire_policy = ad
>
> ldap_access_filter = (|(memberOf=cn=testgrpa,OU=Security
> Groups,OU=Groups,DC=ad,DC=dept,DC=domain,DC=com))
>
>
>
> ldap_default_bind_dn = 
>
> ldap_default_authtok_type = obfuscated_password
>
> ldap_default_authtok = 
>
>
>
>
>
> Thanks,
>
>
>
> *Paul T*
>
> --
>
> UCLA HEALTH SCIENCES IMPORTANT WARNING: This email (and any attachments)
> is only intended for the use of the person or entity to which it is
> addressed, and may contain information that is privileged and confidential.
> You, the recipient, are obligated to maintain it in a safe, secure and
> confidential manner. Unauthorized redisclosure or failure to maintain
> confidentiality may subject you to federal and state penalties. If you are
> not the intended recipient, please immediately notify us by return email,
> and delete this message from your computer.
> ___
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
>
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org

[SSSD-users] Funky machine accounts created, then adcli join will not correctly succeed.

[Spike White]

All,

This is just an annoyance that occurs periodically and we can't figure out
why.  We know how to remediate once seen.

Every now and then, on a new build the sssd join/configure will fail.
For example, a server provisioner today built 10 boxes and 2 failed.  Upon
closer inspection, we see that AD domain has machine accounts with funky
names.

For example, these three VMs were built.  ausflinfsfdcap01 - 03.  01 and 02
built fine, sssd installed, adcli join succeeded, life was good.  We find
the usual machine accounts in the usual OU.
CN=ausflinfsfdcap01, CN=ausflinfsfdcap02

On 03, the adcli join failed.  In AD, we find the following funky machine
accounts (in the usual OU):

CN=AUSFLINFSFDCAP0\0ACNF:5020ab3d-243a-4ef1-827b-d421c0dcf3d0
CN=AUSFLINFSFDCAP0

This first machine account name is fairly typical when this
failure occurs.  This second I've never seen this particular type of funky
name server.  I.e., a truncated hostname.

When I try adcli join again right now, it will fail (because of these funky
named machine accounts).

I delete these funky machine accounts via ldapdelete.  Example:

ldapdelete -H ldap://ausdcamer.example.com
'CN=AUSFLINFSFDCAP0\0ACNF:5020ab3d-243a-4ef1-827b-d421c0dcf3d0,OU=Servers,OU=UNIX,DC=example,DC=com'

then I delete /etc/krb5.keytab file (if it exists) and re-run the adcli
join -- which then succeeds.

So like I say -- we know how to work around this failure mode.  It's just a
nuisance at this point.  Usually occurs << 10% of builds.

But does anyone know why these funky-named machine accounts arise?  And how
to avoid this?

Spike
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org

[SSSD-users] Re: user names in Match blocks in sshd_config (when using sssd with AD back-end)...

[Spike White]

Sumit,

Good info.

Unfortunately for us, that would not work.  A very high-level management
decision is to use camel-case in AD for names.  Windows doesn't care --
it's case-insensitive.  But as we see here, Linux and Kerberos client very
much cares.  Luckily, we're good -- for our one use case.

Spike

On Tue, Nov 10, 2020 at 12:23 AM Sumit Bose  wrote:

> On Mon, Nov 09, 2020 at 12:06:05PM -0600, Spike White wrote:
> > All,
> >
> > In this particular case, it's an automation script that logs in (via SSH)
> > and performs activities as those two service accounts.  So we were able
> to
> > convert the automation to using lower case and then use lower case in our
> > sshd 'Match User' block.  So all is happy now.
> >
> > But in the general case, is there a way to have sssd disallow users
> logging
> > in with upper case or mixed case?  I'd much prefer forcing the users to
> log
> > in with lower case, than not matching my sshd 'Match User' blocks.
>
> Hi,
>
> currently there is only 'case_sensitive = True' but this does not force
> lower-case names but names which match the spelling from the
> server-side. So if the name is stored with all-caps on the server it
> must be all-caps at login as well. If the names on the server are all
> lower-case it would do want you want.
>
> bye,
> Sumit
>
> >
> > I realize that sssd is mapping whatever entry the user types into lower
> > case.  But that's apparently too late (for sshd).
> >
> > BTW, I realize this is not a sssd problem.  It's a sshd problem (when
> > relying on a case-insensitive back-end user auth, such as AD).
> >
> > Spike
> >
> > On Thu, Nov 5, 2020 at 3:03 AM Sumit Bose  wrote:
> >
> > > On Wed, Nov 04, 2020 at 12:03:16PM -0600, Spike White wrote:
> > > >sssd professionals,
> > > >
> > > >Interesting problem;  seems to be an interaction with sshd daemon when
> > > >using an AD back-end.
> > > >
> > > >When using sssd (with an AD back-end), what should my “Match” blocks
> in
> > > >/etc/ssh/sshd_config file look like for over-riding user values?
> > > >
> > > >Right now, my Match blocks look like:
> > > >
> > > >   MaxSessions 10
> > > >
> > > >  
> > > >
> > > >Match User SERVICEPPTPRDVRA
> > > >
> > > >   MaxSessions 999
> > > >
> > > >   ClientAliveInterval 360
> > > >
> > > >   ClientAliveCountMax 3
> > > >
> > > >
> > > >
> > > >Match User SERVICEPPTPRDDCA
> > > >
> > > >   MaxSessions 999
> > > >
> > > >   ClientAliveInterval 360
> > > >
> > > >   ClientAliveCountMax 3
> > > >
> > > >
> > > >
> > > >And in the system log files, it looks like:
> > > >
> > > >Nov 4 10:40:22 peplpc1mom01 sshd[2400354]: debug2:
> parse_server_config:
> > > >config reprocess config len 1479
> > > >Nov 4 10:40:22 peplpc1mom01 sshd[2400354]: debug3: checking match for
> > > 'User
> > > >SERVICEPPTPRDVRA' user SERVICEPPTPRDVRA host 10.175.99.51 addr
> > > 10.175.99.51
> > > >laddr 10.174.120.203 lport 22
> > > >Nov 4 10:40:22 peplpc1mom01 sshd[2400354]: debug1: user
> SERVICEPPTPRDVRA
> > > >matched 'User SERVICEPPTPRDVRA' at line 158
> > > >Nov 4 10:40:22 peplpc1mom01 sshd[2400354]: debug3: match found
> > > >Nov 4 10:40:22 peplpc1mom01 sshd[2400354]: debug3: reprocess
> config:159
> > > >setting MaxSessions 999
> > > >Nov 4 10:40:22 peplpc1mom01 sshd[2400354]: debug3: reprocess
> config:160
> > > >setting ClientAliveInterval 360
> > > >Nov 4 10:40:22 peplpc1mom01 sshd[2400354]: debug3: reprocess
> config:161
> > > >setting ClientAliveCountMax 3
> > > >Nov 4 10:40:22 peplpc1mom01 sshd[2400354]: debug3: checking match for
> > > 'User
> > > >SERVICEPPTPRDDCA' user SERVICEPPTPRDVRA host 10.175.99.51 addr
> > > 10.175.99.51
> > > >laddr 10.174.120.203 lport 22
> > > >Nov 4 10:40:22 peplpc1mom01 sshd[2400354]: debug3: match not found
> > > >
> > > >
> > > >
> > > >Here's where it gets weird.  Because this is an AD back-end, by
> default
> > > >sssd is setting
> > > >
> > > >case_sensitive = false
> > > >
> > > >That is, it matches any case of user names.  Exampl