[Samba] [EXTERNAL] Re: Unable to authenticate to share using UPN

[Mike Robbert]


On 6/26/23, 10:38, "samba" <samba-bounces at lists.samba.org> wrote: 


> I did see Stafan’s post and the replies, but it did not address the issue that I am asking about. I don’t care about SSH access of users on this server and while it may a useful part of the solution, I am not asking about how users files ownership is displayed from the console/CLI. This server is only used as a file server and I would like for users to be able to map SMB/CIFS shares by entering their UPN as the username. The log that I sent was from a connection where I tried that with my test user zach_detest at domain.tld <mailto:zach_detest at domain.tld <mailto:zach_detest at domain.tld>>

I did some further testing using the standard UPN
i.e username at dns.domain.tld

With chown, the command returned correctly, but when checked, the file
was owned by the users samaccountname.

I setup a user with a UPN 'user at example.com' and tried this, chown flat
out refused to change the file ownership.

>
> It looks like the server received that from the client here:
> [2023/06/23 10:05:50.006889, 3, pid=22679, effective(0, 0), real(0, 0), class=auth] ../../auth/ntlmssp/ntlmssp_server.c:552(ntlmssp_server_preauth)
> Got user=[zach_detest] domain=[domain.tld] workstation=[ITS-MACBOOK09] len1=24 len2=254
>
> Then when it checks the password against the AD domain it mangles the input by moving the UPN suffix to the AD domain field:
> [2023/06/23 10:05:50.008789, 3, pid=22679, effective(0, 0), real(0, 0), class=auth] ../../source3/auth/auth.c:189(auth_check_ntlm_password)
> check_ntlm_password: Checking password for unmapped user [domain.tld]\[zach_detest]@[ITS-MACBOOK09] with the new password interface
>
> Which fails:
> [2023/06/23 10:05:50.011820, 2, pid=22679, effective(0, 0), real(0, 0), class=auth] ../../source3/auth/auth.c:334(auth_check_ntlm_password)
> check_ntlm_password: Authentication for user [zach_detest] -> [zach_detest] FAILED with error NT_STATUS_NO_SUCH_USER, authoritative=1

Your problem there appears to be that you are trying to use the contents
of the 'uid' attribute and (as far as I am aware) no tools use that
attribute for authentication.

>
>
> It tries again using the correct AD domain name, but doesn’t include the UPN suffix that was sent to it.
> [2023/06/23 10:05:50.080011, 3, pid=22679, effective(0, 0), real(0, 0), class=auth] ../../auth/ntlmssp/ntlmssp_server.c:552(ntlmssp_server_preauth)
> Got user=[zach_detest] domain=[ADDOM] workstation=[ITS-MACBOOK09] len1=24 len2=254
> Fails again:
> [2023/06/23 10:05:50.083899, 2, pid=22679, effective(0, 0), real(0, 0), class=auth] ../../source3/auth/auth.c:334(auth_check_ntlm_password)
> check_ntlm_password: Authentication for user [zach_detest] -> [zach_detest] FAILED with error NT_STATUS_NO_SUCH_USER, authoritative=1
>
> It tries one last time with another mangling of the input
> [2023/06/23 10:05:50.171506, 3, pid=22679, effective(0, 0), real(0, 0), class=auth] ../../auth/ntlmssp/ntlmssp_server.c:552(ntlmssp_server_preauth)
> Got user=[zach_detest] domain=[domain.tld@\server-dev.domain.tld] workstation=[ITS-MACBOOK09] len1=24 len2=254
>
> But still isn’t sending the full UPN so it fails again:
> [2023/06/23 10:05:50.175367, 2, pid=22679, effective(0, 0), real(0, 0), class=auth] ../../source3/auth/auth.c:334(auth_check_ntlm_password)
> check_ntlm_password: Authentication for user [zach_detest] -> [zach_detest] FAILED with error NT_STATUS_NO_SUCH_USER, authoritative=1
>
> Is there anything we can do to in order to get Samba/winbind to try sending the full UPN that the user entered to the domain controller?

I do not think that winbind is reading the UPN from AD, I could be wrong
though.
The problem is, as I said earlier, whilst you can feed a UPN to chown,
the file ends up belonging to the users samaccountname.

I personally do not think you can get Samba to do what you require, but
I could be wrong and if I am, someone will explain where I am going wrong.

Rowland


I am not trying to authenticate using the uid field. I would like it if we could, but I realize that is not possible. I believe that Samba is authenticating against the samaccountname field, but I believe that the protocol allows for authentication against the UPN field. The problem, as far as I can interpret from the logs, is that something in the Samba or Winbind code is mangling the username that is sent from the client such that the full UPN never gets tried against the DC. 
I don’t need chown to work with the UPN. We will be switching our idmap backend to use SSSD (idmap_sss provided by SSSD) and SSSD is mapping usernames to the uid field in AD with the ldap_user_name option in sssd.conf. I don’t know how they handle the fact that uid can have multiple values, but we are ensuring that all user objects only have a single uid value in our domain, so it seems to work fine for us. 

Am I missing some configuration option that will pass a full UPN from the client, through Samba/Winbind on to the AD DC without pulling off the UPN suffix? If this doesn’t currently exist what would it take to get it added to the code? 

Thanks, 
Mike Robbert 





-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 9275 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba/attachments/20230627/b6fb320d/smime.bin>