[Samba] Access to s3 shares when userPrincipalName differs from the sAMAccountName

[Angelos Oikonomopoulos]

Hello all,

I've been trying to use a Samba3 fileserver with security = ADS in a 
domain where the DC is Samba4. It all seems to work, except for users 
with long names.

What happens is that users can log in to the domain with their 
userPrincipalName as well as the sAMAccountName. Unfortunately, if the 
username is longer than 20 characters (which, because of our username = 
first_name.last_name policy, is the case for a few users), then the 
userPrincipalName and the sAMAccountName differ. So when users that have 
logged in using their userPrincipalName try to access a share on the 
Samba3 server, they try to authenticate using the userPrincipalName, 
which winbind doesn't know about, and fail.

This looks to be a problem that a lot of people should have run into 
over the past few years, but I haven't been able to find any clues by 
searching the mailing list archives.

Is there a workaround I could use? At the moment my options seem to be:

1) Ask users with long names to only log in using the sAMAccountName. 
This is very suboptimal of course.
2) Change these users' userPrincipalName to be the same as the 
sAMAccountName so that they will /have/ to use the sAMAccountName to log 
in. Doable but ugly and it will complicate our email setup too.
3) Find a magic GPO configuration option that will force windows clients 
to always use the sAMAccountName to authenticate when accessing a 
network share. After a few hours searching on the web and manually going 
through each option in the GPO editor, there doesn't appear to be such a 
setting.
4) Hack winbindd to do an ldap search to convert the userPrincipalName 
to the sAMAccountName when it is obvious we're dealing with the former 
(i.e. when it's larger than 20 characters).
5) Hack winbindd to trim the username so that the userPrincipalName will 
be converted to the sAMAccountName. I can't even imagine the ways this 
could break and it would be a huge burden to maintain such hacks in the 
long term.

Any insight on this? I'm sure there's a better option!

Thanks,
Aggelos