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.com(a)AMER.COMPANY.COM
<.us.dell.com(a)AMER.DELL.COM&gt;


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


host/ddlplhdc4036.us.company.com(a)AMER.COMPANY.COM
<host/ddlplhdc4036.us.dell.com(a)AMER.DELL.COM&gt;


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/
myhost(a)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

[Sumit Bose]

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.com(a)AMER.COMPANY.COM
>  <.us.dell.com(a)AMER.DELL.COM&gt;
>  
>  
>  but in /etc/krb5.keytab file ii has:
>  
>  
>  host/ddlplhdc4036.us.company.com(a)AMER.COMPANY.COM
>  <host/ddlplhdc4036.us.dell.com(a)AMER.DELL.COM&gt;
>  
>  
>  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/
>  myhost(a)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(a)lists.fedorahosted.org
>  To unsubscribe send an email to sssd-users-leave(a)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/[e-mail]...
>  Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Spike White]

Sumit,

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

You tested this by putting in:

                ldap_sasl_authid = ewfk(a)FWEF.ED



on your test server called “client.samba.test”.    It failed to find
“ewfk(a)FWEF.xn--ed-02t or “host/ewfk(a)FWEF.xn--ed-02t in /etc/krb5.keytab file, so it tried
(in order):



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



It found host/client.samba.test(a)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 <sbose(a)redhat.com&gt; 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.com(a)AMER.COMPANY.COM
>  > <.us.dell.com(a)AMER.DELL.COM&gt;
>  >
>  >
>  > but in /etc/krb5.keytab file ii has:
>  >
>  >
>  > host/ddlplhdc4036.us.company.com(a)AMER.COMPANY.COM
>  > <host/ddlplhdc4036.us.dell.com(a)AMER.DELL.COM&gt;
>  >
>  >
>  > 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/
>  > myhost(a)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(a)lists.fedorahosted.org
>  > To unsubscribe send an email to sssd-users-leave(a)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/[e-mail]...
>  > Do not reply to spam, report it:
>  https://pagure.io/fedora-infrastructure/new_issue
>  --
>  _______________________________________________
>  sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
>  To unsubscribe send an email to sssd-users-leave(a)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/[e-mail]...
>  Do not reply to spam, report it:
>  https://pagure.io/fedora-infrastructure/new_issue
>

[Sumit Bose]

Am Wed, Jan 31, 2024 at 08:35:30AM -0600 schrieb Spike White:
>  Sumit,
>  
>  Thank you so much for responding.  I believe you're saying this.
>  
>  You tested this by putting in:
>  
>                  ldap_sasl_authid = ewfk(a)FWEF.ED
>  
>  
>  
>  on your test server called “client.samba.test”.    It failed to find
>  “ewfk(a)FWEF.xn--ed-02t or “host/ewfk(a)FWEF.xn--ed-02t in /etc/krb5.keytab file, so it tried
>  (in order):
>  
>  
>  
>  >                hostname@REALM
>  >                netbiosname$@REALM
>  >                host/hostname@REALM
>                         ...
>  
>  
>  
>  It found host/client.samba.test(a)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? 
Hi,

yes

bye,
Sumit

>  
>  Spike
>  
>  On Wed, Jan 31, 2024 at 8:01 AM Sumit Bose <sbose(a)redhat.com&gt; 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.com(a)AMER.COMPANY.COM
>  > > <.us.dell.com(a)AMER.DELL.COM&gt;
>  > >
>  > >
>  > > but in /etc/krb5.keytab file ii has:
>  > >
>  > >
>  > > host/ddlplhdc4036.us.company.com(a)AMER.COMPANY.COM
>  > > <host/ddlplhdc4036.us.dell.com(a)AMER.DELL.COM&gt;
>  > >
>  > >
>  > > 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/
>  > > myhost(a)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(a)lists.fedorahosted.org
>  > > To unsubscribe send an email to sssd-users-leave(a)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/[e-mail]...
>  > > Do not reply to spam, report it:
>  > https://pagure.io/fedora-infrastructure/new_issue
>  > --
>  > _______________________________________________
>  > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
>  > To unsubscribe send an email to sssd-users-leave(a)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/[e-mail]...
>  > Do not reply to spam, report it:
>  > https://pagure.io/fedora-infrastructure/new_issue
>  > 
>  --
>  _______________________________________________
>  sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
>  To unsubscribe send an email to sssd-users-leave(a)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/[e-mail]...
>  Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue