When authenticating with AD using Kerberos the returned username is in the ticket is canonicalized. If the username in the system are lowercase or the user is trying to use GSSAPI and specifies the username in lowcer case, the GSSAPI auth fails. To correctly map principals to the local systems accounts, we can implement a Kerberos localauth plugin: https://web.mit.edu/kerberos/krb5-latest/doc/plugindev/localauth.html This will allow to handle usernames more gracefully. Patch which the implementation will follow.
More detailed explanation from Alexander Bokovoy: While Kerberos is an authentication mechanism and its principals in general have no relationship to identities of underlying operating system, Samba needs an identity to run smbd process and that identity is directly derived from the authenticated identity. There are other applications which perform similar action. Both Kerberos and higher level GSS API have functions to transform an authenticated identity into a local identity to help the applications with this task. Traditionally a particular way this can be configured is by using ~/.k5login or (in case of MIT Kerberos) auth_to_local rules in krb5.conf. These were checked by krb5_userok() and krb5_aname_to_localname() functions. If an application wanted to know that a particular principal can represent a user on the system, it called krb5_kuserok(). If it needed to know which local user name to use for a principal, it called krb5_aname_to_localname(). Implementations of theese both methods didn't scale in large organizations, so for those cases we introduced a pluggable localauth interface in MIT Kerberos in 2013. It allowed to delegate krb5_kuserok() and krb5_aname_to_localname() checks to external modules. For SMB protocol we know that we can construct a user name based on the security token we received. We can also use Kerberos ticket's MS-PAC content for that. However, other applications don't have this information. For example, OpenSSH server wouldn't know you are Foo\Administrator if you present a Kerberos ticket Administrator@FOO.COM. It needs an explicit user name to be specified by the SSH client (ssh -l Foo\Administrator) and then it would ask krb5_kuserok() to validate that Kerberos principal Administrator@FOO.COM is allowed to be a user Foo\Administrator on the system. This knowledge can be in ~/.k5login or as an auth_to_local rule in krb5.conf. However, maintaining such rules on each system is quite heavy in terms of up-to-dateness. We made it first with SSSD for FreeIPA and direct AD usage. SSSD allows using any name associated with the user as its POSIX id when resolving it. You can say getpwnam_r("Foo\Administrator") or getpwnam_r("Administrator@FOO.COM"), they'll point to the same user entry. This allows to make a generic localauth plugin to MIT Kerberos that simply validates a Kerberos principal and a user name resolve to the same entry (same UID). When winbindd is used to perform identity resolution, we can do the same. This is what Andreas' localauth plugin does, allowing us to have unified identity experience across multiple protocols and multiple client software stacks.
Created attachment 14251 [details] patch for 4.8
Comment on attachment 14251 [details] patch for 4.8 LGTM.
Karolin, could you please add it to 4.8? Thanks.
(In reply to Andreas Schneider from comment #4) Pushed to autobuild-v4-8-test.
(In reply to Karolin Seeger from comment #5) Pushed to v4-8-test. Closing out bug report. Thanks!