samba - Jun 2023 - [EXTERNAL] Re: Unable to authenticate to share using UPN

On 26/06/2023 17:02, Mike Robbert via samba wrote:
> ?
> On 6/24/23, 03:17, "samba" <samba-bounces at
lists.samba.org> wrote:
> 
> 
> On 23/06/2023 19:08, Mike Robbert wrote:
>> Sorry about that I typed and sent a full message, but it looks like the
entire body got swallowed up in transit. Here is the full text again. Let's
hope this one works.
>>
>> I have a server running CentOS 7.9 with the system provided Samba
packages (4.10.16-24.el7_9). It is joined to an Active Directory domain and
acting as a member server. The active Directory domain has a user object with
among others, the following attributes defined
>> sAMAccountName = m12345678
>> gecos = Zach Detest
>> gidNumer = 12345678
>> uid = zach_detest
>> uidNumer = 12345678
>> unixHomeDirectory = /home/m12345678
>> userPrincipalName = zach_destest at domain.tld
>>
>> The smb.conf on the server looks like this:
>>
>> [global]
>> additional dns hostnames = dct-hanas-2.domain.tld
> 
> Unless red-hat backported this, 'additional dns hostnames'
didn't appear
> until Samba 4.11.0 at the earliest (I say that because I cannot find
> just when it was added, but it isn't in 'man smb.conf' for
4.10.x, but
> it is in 'man smb.conf' for 4.11.x).
> 
> RedHat must have backported this because it is in the man page and this
line was not inserted manually by me, it was inserted when I joined the machine
to the domain using ?net ads join?
> 
> 
>> idmap config * : range = 1-999
>> idmap config addom : unix_primary_group = yes
>> idmap config addom : unix_nss_info = yes
>> idamp config addom : schema_mode = rfc2307
>> idmap config addom : backend = ad
>> idmap config addom : range = 1000-999999999
>> idmap config * : backend = tdb
> 
> Do you mind if I ask why you are using such strange (to me) ranges ?
> They would seem to preclude having any local users and groups.
> 
> We don?t have any local users other than the OS system users which all fall
under 1000. All other users are in AD.
I take it that you do not use sudo and just log on as root when required.
The default range '*' is meant for the Well Known SIDs, the BUILTIN 
users and groups and anything outside the 'ADDOM' domain, you also have 
system users & groups that start at 0 and theoretically go up to 999.
> 
> 
> They are the attributes that work with user searches, however 'uid'
> (being a multi value ldap attribute) doesn't, This isn't just a
Samba or
> Unix thing, Windows works in the same way.
> 
> It looks to me (and I could be totally wrong) that sssd must have code
> that can use the 'uid' value and then set that as the owner of a
file.
> If it is doing this, then how does it get around 'uid' being a
multi
> valued attribute ?
> 
> It is strange you have raised this, Stefan Kania raised virtually the
> same subject about a week ago and during this week, a bug report was
listed:
> 
> Rowland
> 
> 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>
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

?
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>