[Samba] Samba SSSD authentication via userPrincipalName does not work because samba claims that the username does not exist.

Markus Jansen jansen at schmitzmine.eu
Wed Oct 14 14:07:15 UTC 2020

Am 14.10.20 um 08:31 schrieb Nico Kadel-Garcia via samba:
> On Tue, Oct 13, 2020 at 10:30 AM Rowland penny via samba
> <samba at lists.samba.org> wrote:
>> On 13/10/2020 15:01, Markus Jansen via samba wrote:
>>> Thank you very much for your hints.
>>> I got rid of SSSD and managed to get a successful kerberos
>>> authentication via wbinfo -K and the UPN.
>>> But accessing via SMB (using MAC OS' smbutil or Finder) still fails with
>>> As I'm using CentOS 8, I used authselect to configure winbind
>>> integration to PAM (do I really need this for SMB?) and enabled
>>> "with-krb5" and "with-pamaccess" - features to let /etc/pam.d/-files be
>>> configured automatically.
>>> I'm really confused. What's missing?
>> Probably libpam-krb5 that Red-Hat has removed from RHEL8 and hence
>> Centos8, I had to compile the Centos7 package and install it before I
>> could get Centos8 to work correctly.
>> BIG NOTE: this is just my opinion.
>> I really do not think that red-hat wants you to use Samba with RHEL8, I
>> think they really want you to use sssd with freeipa instead. They have
>> removed openldap, smbldap-tools  and libpam-krb5 that I am aware of,
>> there may be others.

Good hint. I switched to Debian Buster - same issue:

Interestinly, "id tim-upn" (the userPrincipalname) works and refers to
the sAMAccountName.

"uid=3000(tim-sam) gid=3000(domain users) groups=3000(domain

"login tim-upn" works, "ssh tim-upn at localhost", too.  Also: "smbclient
-L //localhost -W ADTEST -U tim-sam%Qwertz12345" works, but "smbclient
-L //localhost -W ADTEST -U tim-upn%Qwertz12345" doesn't.

Still confused.

> This matches my direct observations. Also sssd has many options for
> tuning that get *thrown out* with any security update of the software,
> they are flushed by any run of authconfig which is often built into
> related software updates. sssd is *not your friend* if you want any
> tuning of your LDAP or related behavior, and it insists on pre-caching
> all of your LDAP before completing the setup of sssd. SO it starts up,
> times out on the pre-caching, and *fails* with no legible log of what
> the problem was and no good way to tune it except to resttrict your
> LDAP access to a wafer thin sliver of the upstream setup, *which
> configuration gets overwritten!!!!* with updates of anything that uses
> authconfig.
> This iss a condemnation of authconfig's poor management of the
> sophisticated options to sssd, but unless you're running something
> like ansible or chef to replace your /etc/sssd/ files as needed, it's
> an ongoing problem, A  backdoor also cannot rely on sssd to be working
> correctly, so you're compelled to use something like SSH keys for an
> ansible service account or direct root SSH access to support this.
>> How wedded are you to Centos ? I personally would advise you to switch
>> to Debian or Ubuntu, everything just works.
> Just ditch sssd if you want actual reliable LDAP. It's handy if you
> need no sophistaction of a smal LDAP setup, but I have real problems
> with it for sophisticated production use. It's not a well integrated
> wrapper for LDAP, Kerberos, and other settihngs.
>> If you must use Centos8, then it is possible to get Linux to connect to
>> a Samba share running on a Centos domain member, not sure about a Mac, I
>> do not have one.

More information about the samba mailing list