[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-mail]

on your test server called “client.samba.test”.    It failed to find
“[e-mail]” or “host/[e-mail]” in /etc/krb5.keytab file, so it tried
(in order):
>            hostname@REALM
>            netbiosname$@REALM
>            host/hostname@REALM

...

It found host/[e-mail] 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 = [e-mail]
> >
> > but in /etc/krb5.keytab file ii has:
> >
> > host/[e-mail]
> >
> > 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/
> > [e-mail]) 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 -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> > 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].o...
> > Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
> sssd-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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].o...
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue