Bug 13480 - Connecting to AD with kerberos forces username to uppercase causing authentication failure
Summary: Connecting to AD with kerberos forces username to uppercase causing authentic...
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: Winbind (show other bugs)
Version: 4.8.2
Hardware: All All
: P5 normal (vote)
Target Milestone: ---
Assignee: Karolin Seeger
QA Contact: Samba QA Contact
Depends on:
Reported: 2018-06-20 12:59 UTC by Andreas Schneider
Modified: 2018-06-27 08:39 UTC (History)
4 users (show)

See Also:

patch for 4.8 (10.34 KB, patch)
2018-06-21 14:19 UTC, Andreas Schneider
ab: review+
asn: review? (gd)

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Schneider 2018-06-20 12:59:08 UTC
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:


This will allow to handle usernames more gracefully.

Patch which the implementation will follow.
Comment 1 Andreas Schneider 2018-06-21 09:49:36 UTC
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.
Comment 2 Andreas Schneider 2018-06-21 14:19:43 UTC
Created attachment 14251 [details]
patch for 4.8
Comment 3 Alexander Bokovoy 2018-06-21 14:28:22 UTC
Comment on attachment 14251 [details]
patch for 4.8

Comment 4 Andreas Schneider 2018-06-22 09:37:18 UTC
Karolin, could you please add it to 4.8? Thanks.
Comment 5 Karolin Seeger 2018-06-25 10:56:20 UTC
(In reply to Andreas Schneider from comment #4)
Pushed to autobuild-v4-8-test.
Comment 6 Karolin Seeger 2018-06-27 08:39:20 UTC
(In reply to Karolin Seeger from comment #5)
Pushed to v4-8-test.
Closing out bug report.