thr3ads.net - samba - [Samba] Samba SSSD authentication via userPrincipalName does not work because samba claims that the username does not exist. [Oct 2020]

If this information is useful, please help other people find it:
Share via:

Markus Jansen

2020-Oct-05 15:14 UTC

[Samba] Samba SSSD authentication via userPrincipalName does not work because samba claims that the username does not exist.

Dear all,

i'm investigating the issue that I can't authenticate against a Samba
(as Active-Directory Member) using the userPrincipalName (UPN). (Using Samba and
sAMAccountName works fine.)

After some research I'm quite sure that winbind is limited to the
sAMAccountName and can't use UPN. So I deciced to use SSSD and configured
the `ldap_user_name = userPrincipalName` in the sssd.conf

Example:

* sAMAccountName: timfin01
* userPrincipalName: tim.finnigan

"getent passwd tim.finnigan" works, i.e. returns
"tim.finnigan:*:1238402723:1238400513:Tim Finnigan:/home/tim.finnigan at
ad.adtest.de:/bin/bash", so I guess SSSD authentication using UPN should
function.

But Samba refuses to work. I increased the SSSD-Logging and examined, that
authentication with UPN like "smbutil view -A
//tim.finnigan at smb-test" doesn't lead to any entry in the logs. The
SMB-Log instead shows the following:


[2020/09/29 16:08:42.196546,  3]
../../source3/auth/auth.c:200(auth_check_ntlm_password)
  check_ntlm_password:  Checking password for unmapped user
[ADTEST]\[tim.finnigan]@[MJBOOK] with the new password interface
[2020/09/29 16:08:42.196559,  3]
../../source3/auth/auth.c:203(auth_check_ntlm_password)
  check_ntlm_password:  mapped user is: [ADTEST]\[tim.finnigan]@[MJBOOK]
[2020/09/29 16:08:42.196573,  4] ../../source3/smbd/sec_ctx.c:216(push_sec_ctx)
  push_sec_ctx(0, 0) : sec_ctx_stack_ndx = 2
[2020/09/29 16:08:42.196584,  4] ../../source3/smbd/uid.c:576(push_conn_ctx)
  push_conn_ctx(0) : conn_ctx_stack_ndx = 1
[2020/09/29 16:08:42.196594,  4]
../../source3/smbd/sec_ctx.c:320(set_sec_ctx_internal)
  setting sec ctx (0, 0) - sec_ctx_stack_ndx = 2
[2020/09/29 16:08:42.198802,  4] ../../source3/smbd/sec_ctx.c:438(pop_sec_ctx)
  pop_sec_ctx (0, 0) - sec_ctx_stack_ndx = 1
[2020/09/29 16:08:42.198849,  2]
../../source3/auth/auth.c:346(auth_check_ntlm_password)
  check_ntlm_password:  Authentication for user [tim.finnigan] ->
[tim.finnigan] FAILED with error NT_STATUS_NO_SUCH_USER, authoritative=1
[2020/09/29 16:08:42.198916,  2]
../../auth/auth_log.c:653(log_authentication_event_human_readable)
  Auth: [SMB2,(null)] user [ADTEST]\[tim.finnigan] at [Tue, 29 Sep 2020
16:08:42.198899 CEST] with [NTLMv2] status [NT_STATUS_NO_SUCH_USER] workstation
[MJBOOK] remote host [ipv4:10.10.230.10:51669] mapped to
[ADTEST]\[tim.finnigan]. local host [ipv4:134.100.203.47:445]
  {"timestamp": "2020-09-29T16:08:42.198974+0200",
"type": "Authentication", "Authentication":
{"version": {"major": 1, "minor": 2},
"eventId": 4625, "logonId": "0",
"logonType": 3, "status":
"NT_STATUS_NO_SUCH_USER", "localAddress":
"ipv4:134.100.203.47:445", "remoteAddress":
"ipv4:10.10.230.10:51669", "serviceDescription":
"SMB2", "authDescription": null, "clientDomain":
"ADTEST", "clientAccount": "tim.finnigan",
"workstation": "MJBOOK", "becameAccount": null,
"becameDomain": null, "becameSid": null,
"mappedAccount": "tim.finnigan", "mappedDomain":
"ADTEST", "netlogonComputer": null,
"netlogonTrustAccount": null, "netlogonNegotiateFlags":
"0x00000000", "netlogonSecureChannelType": 0,
"netlogonTrustAccountSid": null, "passwordType":
"NTLMv2", "duration": 77558}}
[2020/09/29 16:08:42.199043,  4] ../../source3/smbd/sec_ctx.c:438(pop_sec_ctx)


When authenticating via "smbutil view -A //timfin01 at smb-test" it
works when setting the "ldap_user_name = sAMAccountName" in the
sssd.conf for test purposes. Then, I can also see that SSSD is used for
authentication in the SSSD logs.

I guess Samba has a kind of fallback to NTLM, that isn't supported by SSSD.
And Samba first checks the username existence before using the authentication
backend (SSSD). My smb.conf:

[global]
        workgroup = ADTEST
        security = ads
        encrypt passwords = yes
        client signing = yes
        client use spnego = yes
        kerberos method = system keytab
        #kerberos method = secrets and keytab
        log file = /var/log/samba/%m.log
        # password server         realm = ad.adtest.de
        idmap config * : backend = sss
        idmap config * : range = 200000-2147483647
        unix extensions = no
        log level = 4 winbind:5 nmbd:3
        log file = /var/log/samba/%m.log

[share1]
        vfs objects = fileid
        fielid:algorithm = fsname
        path = /share1
        browseable = yes
        writeable = yes
        guest ok = no
        public = yes
        wide links = yes


Finally, the sssd.conf:

[sssd]
config_file_version = 2
domains = ad.adtest.de
services = nss, pam

[domain/ad.adtest.de]
id_provider = ad
auth_provider = ad
access_provider = ad
ad_domain = ad.adtest.de
krb5_realm = ad.adtest.de
realmd_tags = manages-system joined-with-samba
cache_credentials = True
krb5_store_password_if_offline = True
default_shell = /bin/bash
# ldap_id_mapping = True
use_fully_qualified_names = False
fallback_homedir = /home/%u@%d
ldap_user_name = userPrincipalName
debug_level = 9

I'm using Samba 4.10.4-11.el7_8 on CentOS 8.

I'm not sure if I understand this right, but if so, is there a way to force
Samba to use SSSD? Any hints are very appreciated.

Rowland penny

2020-Oct-05 15:45 UTC

head link

[Samba] Samba SSSD authentication via userPrincipalName does not work because samba claims that the username does not exist.

On 05/10/2020 16:14, Markus Jansen via samba wrote:> Dear all,
>
> i'm investigating the issue that I can't authenticate against a
Samba (as Active-Directory Member) using the userPrincipalName (UPN). (Using
Samba and sAMAccountName works fine.)
>
> After some research I'm quite sure that winbind is limited to the
sAMAccountName and can't use UPN. So I deciced to use SSSD and configured
the `ldap_user_name = userPrincipalName` in the sssd.conf
>
> Example:
>
> * sAMAccountName: timfin01
> * userPrincipalName: tim.finnigan
>
> "getent passwd tim.finnigan" works, i.e. returns
"tim.finnigan:*:1238402723:1238400513:Tim Finnigan:/home/tim.finnigan at
ad.adtest.de:/bin/bash", so I guess SSSD authentication using UPN should
function.
>
> But Samba refuses to work. I increased the SSSD-Logging and examined, that
authentication with UPN like "smbutil view -A
> //tim.finnigan at smb-test" doesn't lead to any entry in the logs.
The SMB-Log instead shows the following:
>
>
> [2020/09/29 16:08:42.196546,  3]
../../source3/auth/auth.c:200(auth_check_ntlm_password)
>    check_ntlm_password:  Checking password for unmapped user
[ADTEST]\[tim.finnigan]@[MJBOOK] with the new password interface
> [2020/09/29 16:08:42.196559,  3]
../../source3/auth/auth.c:203(auth_check_ntlm_password)
>    check_ntlm_password:  mapped user is: [ADTEST]\[tim.finnigan]@[MJBOOK]
> [2020/09/29 16:08:42.196573,  4]
../../source3/smbd/sec_ctx.c:216(push_sec_ctx)
>    push_sec_ctx(0, 0) : sec_ctx_stack_ndx = 2
> [2020/09/29 16:08:42.196584,  4]
../../source3/smbd/uid.c:576(push_conn_ctx)
>    push_conn_ctx(0) : conn_ctx_stack_ndx = 1
> [2020/09/29 16:08:42.196594,  4]
../../source3/smbd/sec_ctx.c:320(set_sec_ctx_internal)
>    setting sec ctx (0, 0) - sec_ctx_stack_ndx = 2
> [2020/09/29 16:08:42.198802,  4]
../../source3/smbd/sec_ctx.c:438(pop_sec_ctx)
>    pop_sec_ctx (0, 0) - sec_ctx_stack_ndx = 1
> [2020/09/29 16:08:42.198849,  2]
../../source3/auth/auth.c:346(auth_check_ntlm_password)
>    check_ntlm_password:  Authentication for user [tim.finnigan] ->
[tim.finnigan] FAILED with error NT_STATUS_NO_SUCH_USER, authoritative=1
> [2020/09/29 16:08:42.198916,  2]
../../auth/auth_log.c:653(log_authentication_event_human_readable)
>    Auth: [SMB2,(null)] user [ADTEST]\[tim.finnigan] at [Tue, 29 Sep 2020
16:08:42.198899 CEST] with [NTLMv2] status [NT_STATUS_NO_SUCH_USER] workstation
[MJBOOK] remote host [ipv4:10.10.230.10:51669] mapped to
[ADTEST]\[tim.finnigan]. local host [ipv4:134.100.203.47:445]
>    {"timestamp": "2020-09-29T16:08:42.198974+0200",
"type": "Authentication", "Authentication":
{"version": {"major": 1, "minor": 2},
"eventId": 4625, "logonId": "0",
"logonType": 3, "status":
"NT_STATUS_NO_SUCH_USER", "localAddress":
"ipv4:134.100.203.47:445", "remoteAddress":
"ipv4:10.10.230.10:51669", "serviceDescription":
"SMB2", "authDescription": null, "clientDomain":
"ADTEST", "clientAccount": "tim.finnigan",
"workstation": "MJBOOK", "becameAccount": null,
"becameDomain": null, "becameSid": null,
"mappedAccount": "tim.finnigan", "mappedDomain":
"ADTEST", "netlogonComputer": null,
"netlogonTrustAccount": null, "netlogonNegotiateFlags":
"0x00000000", "netlogonSecureChannelType": 0,
"netlogonTrustAccountSid": null, "passwordType":
"NTLMv2", "duration": 77558}}
> [2020/09/29 16:08:42.199043,  4]
../../source3/smbd/sec_ctx.c:438(pop_sec_ctx)
>
>
> When authenticating via "smbutil view -A //timfin01 at smb-test"
it works when setting the "ldap_user_name = sAMAccountName" in the
sssd.conf for test purposes. Then, I can also see that SSSD is used for
authentication in the SSSD logs.
>
> I guess Samba has a kind of fallback to NTLM, that isn't supported by
SSSD. And Samba first checks the username existence before using the
authentication backend (SSSD). My smb.conf:
>
> [global]
>          workgroup = ADTEST
>          security = ads
>          encrypt passwords = yes
>          client signing = yes
>          client use spnego = yes
>          kerberos method = system keytab
>          #kerberos method = secrets and keytab
>          log file = /var/log/samba/%m.log
>          # password server >          realm = ad.adtest.de
>          idmap config * : backend = sss
>          idmap config * : range = 200000-2147483647
>          unix extensions = no
>          log level = 4 winbind:5 nmbd:3
>          log file = /var/log/samba/%m.log
>
> [share1]
>          vfs objects = fileid
>          fielid:algorithm = fsname
>          path = /share1
>          browseable = yes
>          writeable = yes
>          guest ok = no
>          public = yes
>          wide links = yes
>
>
> Finally, the sssd.conf:
>
> [sssd]
> config_file_version = 2
> domains = ad.adtest.de
> services = nss, pam
>
> [domain/ad.adtest.de]
> id_provider = ad
> auth_provider = ad
> access_provider = ad
> ad_domain = ad.adtest.de
> krb5_realm = ad.adtest.de
> realmd_tags = manages-system joined-with-samba
> cache_credentials = True
> krb5_store_password_if_offline = True
> default_shell = /bin/bash
> # ldap_id_mapping = True
> use_fully_qualified_names = False
> fallback_homedir = /home/%u@%d
> ldap_user_name = userPrincipalName
> debug_level = 9
>
> I'm using Samba 4.10.4-11.el7_8 on CentOS 8.
>
> I'm not sure if I understand this right, but if so, is there a way to
force Samba to use SSSD? Any hints are very appreciated.You cannot use sssd with Samba >= 4.8.0 even red-hat tells you this.

On top of which, you should be able to authentication using a UPN:

pi at raspberrypi:~ $ wbinfo -K SAMDOM\\rowland at samdom.example.com
Enter SAMDOM\rowland at samdom.example.com's password:
plaintext kerberos password authentication for 
[SAMDOM\rowland at samdom.example.com] succeeded (requesting cctype: FILE)
credentials were put in: FILE:/tmp/krb5cc_1000

Rowland

Nico Kadel-Garcia

2020-Oct-06 01:24 UTC

head link

[Samba] Samba SSSD authentication via userPrincipalName does not work because samba claims that the username does not exist.

On Mon, Oct 5, 2020 at 11:46 AM Rowland penny via samba
<samba at lists.samba.org> wrote:
> You cannot use sssd with Samba >= 4.8.0 even red-hat tells you this.
And sssd is *not* your friend if you do anything remotely
sophisticated. It's configuration tools erase any sophisticated setups
in sssd. For any even repotely sophisticated setup, I'll encourage you
to configure Keberos and LDAP more directly.
> On top of which, you should be able to authentication using a UPN:
>
> pi at raspberrypi:~ $ wbinfo -K SAMDOM\\rowland at samdom.example.com
> Enter SAMDOM\rowland at samdom.example.com's password:
> plaintext kerberos password authentication for
> [SAMDOM\rowland at samdom.example.com] succeeded (requesting cctype: FILE)
> credentials were put in: FILE:/tmp/krb5cc_1000
>
> Rowland
>
>
>
> --
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba

Maybe Matching Threads

Search for more reasonably related threads

samba - Oct 2020 - Samba SSSD authentication via userPrincipalName does not work because samba claims that the username does not exist.

[Samba] Samba SSSD authentication via userPrincipalName does not work because samba claims that the username does not exist.

[Samba] Samba SSSD authentication via userPrincipalName does not work because samba claims that the username does not exist.

[Samba] Samba SSSD authentication via userPrincipalName does not work because samba claims that the username does not exist.

Maybe Matching Threads