Hi Everyone,
TrueNAS-SCALE-22.12.4.2 installation that has been running fine for a couple of months. Existing dataset with UNIX ACLs and an SMB share that I need to access from an iPad. Accessing it from the iPad did not work, so I created a test dataset + share using NFSv4 ACLs and SMB sharing which worked well with the iPad. Changed the existing dataset to NFSv4 ACLs, re-created the SMB share and tested these from MacOS 14.1 (my desktop). Connections to SMB shares using existing accounts where the password has been changed, or newly created accounts, all fail with a wrong password error. There is one account that existed before the ACL switch where the password has not been changed - accessing SMB shares using this account still works. Using smbclient on the TrueNAS server to make local SMB connections (127.0.0.1) authenticates successfully with new accounts, but only after a passdb sync.
So in summary:
I have spent quite a few hours trying to figure this out but I am really at my wits end. Can anyone suggest some more diagnosis options? Or is there something in the network auth that needs to be reset? Any help would be most welcome.
Cheers
Mark
"sudo pdbedit -Lwv" shows all the accounts it should, including the new test account that fails and the lisbeth account (the older one with an unchanged password) that still works. Note that they both have the same NT hash as they both use the same password, so I know the password is being entered correctly on the MacOS client (the only difference between connection attempts is the account name).
Unix username: test
NT username:
Account Flags: [U ]
User SID: S-1-5-21-2813400636-2121464641-797741664-20072
Primary Group SID: S-1-5-21-2813400636-2121464641-797741664-513
Full Name: test
Home Directory: \\TRUENAS\test
HomeDir Drive:
Logon Script:
Profile Path: \\TRUENAS\test\profile
Domain: TRUENAS
Account desc:
Workstations:
Munged dial:
Logon time: 0
Logoff time: Wed, 06 Feb 2036 16:06:39 CET
Kickoff time: Wed, 06 Feb 2036 16:06:39 CET
Password last set: Sun, 29 Oct 2023 18:57:52 CET
Password can change: Sun, 29 Oct 2023 18:57:52 CET
Password must change: never
Last bad password : 0
Bad password count : 0
Logon hours : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
LM hash : XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
NT hash : C4E66191EE03F8BF1B618866CE5E748F
Unix username: lisbeth
NT username:
Account Flags: [U ]
User SID: S-1-5-21-2813400636-2121464641-797741664-20068
Primary Group SID: S-1-5-21-2813400636-2121464641-797741664-513
Full Name: Lisbeth
Home Directory: \\TRUENAS\lisbeth
HomeDir Drive:
Logon Script:
Profile Path: \\TRUENAS\lisbeth\profile
Domain: TRUENAS
Account desc:
Workstations:
Munged dial:
Logon time: 0
Logoff time: Wed, 06 Feb 2036 16:06:39 CET
Kickoff time: Wed, 06 Feb 2036 16:06:39 CET
Password last set: Sun, 29 Oct 2023 15:37:17 CET
Password can change: Sun, 29 Oct 2023 15:37:17 CET
Password must change: never
Last bad password : 0
Bad password count : 0
Logon hours : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
LM hash : XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
NT hash : C4E66191EE03F8BF1B618866CE5E748F
------------------------------------------------------------------------------------------------------
"sudo midclt call smb.status AUTH_LOG | jq" shows two auth events, one success using the lisbeth account and a failure using the newly created test account (I have X'd out the IPv6 network ID, but the rest is unchanged).
{
"timestamp": "2023-10-29T19:00:22.343841+0100",
"type": "Authentication",
"Authentication": {
"version": {
"major": 1,
"minor": 2
},
"eventId": 4624,
"logonId": "0",
"logonType": 3,
"status": "NT_STATUS_OK",
"localAddress": "ipv6:XXXX:XXXX:XXXX:XXXX:7c8b:d5ff:fedb:7077:445",
"remoteAddress": "ipv6:XXXX:XXXX:XXXX:XXXX:6d3a:f06c:bcbf:7cb7:51353",
"serviceDescription": "SMB2",
"authDescription": null,
"clientDomain": "TRUENAS",
"clientAccount": "lisbeth",
"workstation": "MERCURY",
"becameAccount": "lisbeth",
"becameDomain": "TRUENAS",
"becameSid": "S-1-5-21-2813400636-2121464641-797741664-20068",
"mappedAccount": "lisbeth",
"mappedDomain": "TRUENAS",
"netlogonComputer": null,
"netlogonTrustAccount": null,
"netlogonNegotiateFlags": "0x00000000",
"netlogonSecureChannelType": 0,
"netlogonTrustAccountSid": null,
"passwordType": "NTLMv2",
"duration": 2443
},
"timestamp_tval": {
"tv_sec": 1698602422,
"tv_usec": 343841
}
},
{
"timestamp": "2023-10-29T19:00:47.934725+0100",
"type": "Authentication",
"Authentication": {
"version": {
"major": 1,
"minor": 2
},
"eventId": 4625,
"logonId": "0",
"logonType": 3,
"status": "NT_STATUS_WRONG_PASSWORD",
"localAddress": "ipv6:XXXX:XXXX:XXXX:XXXX:7c8b:d5ff:fedb:7077:445",
"remoteAddress": "ipv6:XXXX:XXXX:XXXX:XXXX:6d3a:f06c:bcbf:7cb7:51361",
"serviceDescription": "SMB2",
"authDescription": null,
"clientDomain": "TRUENAS",
"clientAccount": "test",
"workstation": "MERCURY",
"becameAccount": null,
"becameDomain": null,
"becameSid": null,
"mappedAccount": "test",
"mappedDomain": "TRUENAS",
"netlogonComputer": null,
"netlogonTrustAccount": null,
"netlogonNegotiateFlags": "0x00000000",
"netlogonSecureChannelType": 0,
"netlogonTrustAccountSid": null,
"passwordType": "NTLMv2",
"duration": 3373
},
"timestamp_tval": {
"tv_sec": 1698602447,
"tv_usec": 934725
}
},
------------------------------------------------------------------------------------------------------
"sudo midclt call smb.passdb_list" shows the correct list of user accounts including lisbeth and test with the correct UID numbers.
------------------------------------------------------------------------------------------------------
"sudo smbclient //127.0.0.1/MEDIA -U test" shows an "smb: \>" prompt but in /var/log/samba4/log.smbd I can see the failed authentication attempts like this one:
Auth: [SMB2,(null)] user [WORKGROUP]\[test] at [Sun, 29 Oct 2023 22:40:16.538365 CET] with [NTLMv2] status [NT_STATUS_WRONG_PASSWORD] workstation [SATURN] remote host [ipv4:127.0.0.1:59058] mapped to [WORKGROUP]\[test]. local host [ipv4:127.0.0.1:445]
and the successful attempts after a "sudo midclt call smb.synchronize_passdb" like this one:
[2023/10/29 23:13:28.304279, 2] ../../source3/auth/auth.c:324(auth_check_ntlm_password)
check_ntlm_password: authentication for user [test] -> [test] -> [test] succeeded
TrueNAS-SCALE-22.12.4.2 installation that has been running fine for a couple of months. Existing dataset with UNIX ACLs and an SMB share that I need to access from an iPad. Accessing it from the iPad did not work, so I created a test dataset + share using NFSv4 ACLs and SMB sharing which worked well with the iPad. Changed the existing dataset to NFSv4 ACLs, re-created the SMB share and tested these from MacOS 14.1 (my desktop). Connections to SMB shares using existing accounts where the password has been changed, or newly created accounts, all fail with a wrong password error. There is one account that existed before the ACL switch where the password has not been changed - accessing SMB shares using this account still works. Using smbclient on the TrueNAS server to make local SMB connections (127.0.0.1) authenticates successfully with new accounts, but only after a passdb sync.
So in summary:
- Network access over IPv4/6 to SMB shares using new accounts or where the password on an existing account has been changed fails with a NT_STATUS_WRONG_PASSWORD.
- Network access over IPv4/6 to SMB shares using an account setup before the ACL switch, that has not had the password changed, succeeds.
- Local access on the TrueNAS server using smbclient works for all accounts but only after I sync'd the passdb.
- Even after the passdb is sync'd, the network IPv4/6 access still fails for new accounts and existing accounts that had the password changed.
I have spent quite a few hours trying to figure this out but I am really at my wits end. Can anyone suggest some more diagnosis options? Or is there something in the network auth that needs to be reset? Any help would be most welcome.
Cheers
Mark
"sudo pdbedit -Lwv" shows all the accounts it should, including the new test account that fails and the lisbeth account (the older one with an unchanged password) that still works. Note that they both have the same NT hash as they both use the same password, so I know the password is being entered correctly on the MacOS client (the only difference between connection attempts is the account name).
Unix username: test
NT username:
Account Flags: [U ]
User SID: S-1-5-21-2813400636-2121464641-797741664-20072
Primary Group SID: S-1-5-21-2813400636-2121464641-797741664-513
Full Name: test
Home Directory: \\TRUENAS\test
HomeDir Drive:
Logon Script:
Profile Path: \\TRUENAS\test\profile
Domain: TRUENAS
Account desc:
Workstations:
Munged dial:
Logon time: 0
Logoff time: Wed, 06 Feb 2036 16:06:39 CET
Kickoff time: Wed, 06 Feb 2036 16:06:39 CET
Password last set: Sun, 29 Oct 2023 18:57:52 CET
Password can change: Sun, 29 Oct 2023 18:57:52 CET
Password must change: never
Last bad password : 0
Bad password count : 0
Logon hours : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
LM hash : XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
NT hash : C4E66191EE03F8BF1B618866CE5E748F
Unix username: lisbeth
NT username:
Account Flags: [U ]
User SID: S-1-5-21-2813400636-2121464641-797741664-20068
Primary Group SID: S-1-5-21-2813400636-2121464641-797741664-513
Full Name: Lisbeth
Home Directory: \\TRUENAS\lisbeth
HomeDir Drive:
Logon Script:
Profile Path: \\TRUENAS\lisbeth\profile
Domain: TRUENAS
Account desc:
Workstations:
Munged dial:
Logon time: 0
Logoff time: Wed, 06 Feb 2036 16:06:39 CET
Kickoff time: Wed, 06 Feb 2036 16:06:39 CET
Password last set: Sun, 29 Oct 2023 15:37:17 CET
Password can change: Sun, 29 Oct 2023 15:37:17 CET
Password must change: never
Last bad password : 0
Bad password count : 0
Logon hours : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
LM hash : XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
NT hash : C4E66191EE03F8BF1B618866CE5E748F
------------------------------------------------------------------------------------------------------
"sudo midclt call smb.status AUTH_LOG | jq" shows two auth events, one success using the lisbeth account and a failure using the newly created test account (I have X'd out the IPv6 network ID, but the rest is unchanged).
{
"timestamp": "2023-10-29T19:00:22.343841+0100",
"type": "Authentication",
"Authentication": {
"version": {
"major": 1,
"minor": 2
},
"eventId": 4624,
"logonId": "0",
"logonType": 3,
"status": "NT_STATUS_OK",
"localAddress": "ipv6:XXXX:XXXX:XXXX:XXXX:7c8b:d5ff:fedb:7077:445",
"remoteAddress": "ipv6:XXXX:XXXX:XXXX:XXXX:6d3a:f06c:bcbf:7cb7:51353",
"serviceDescription": "SMB2",
"authDescription": null,
"clientDomain": "TRUENAS",
"clientAccount": "lisbeth",
"workstation": "MERCURY",
"becameAccount": "lisbeth",
"becameDomain": "TRUENAS",
"becameSid": "S-1-5-21-2813400636-2121464641-797741664-20068",
"mappedAccount": "lisbeth",
"mappedDomain": "TRUENAS",
"netlogonComputer": null,
"netlogonTrustAccount": null,
"netlogonNegotiateFlags": "0x00000000",
"netlogonSecureChannelType": 0,
"netlogonTrustAccountSid": null,
"passwordType": "NTLMv2",
"duration": 2443
},
"timestamp_tval": {
"tv_sec": 1698602422,
"tv_usec": 343841
}
},
{
"timestamp": "2023-10-29T19:00:47.934725+0100",
"type": "Authentication",
"Authentication": {
"version": {
"major": 1,
"minor": 2
},
"eventId": 4625,
"logonId": "0",
"logonType": 3,
"status": "NT_STATUS_WRONG_PASSWORD",
"localAddress": "ipv6:XXXX:XXXX:XXXX:XXXX:7c8b:d5ff:fedb:7077:445",
"remoteAddress": "ipv6:XXXX:XXXX:XXXX:XXXX:6d3a:f06c:bcbf:7cb7:51361",
"serviceDescription": "SMB2",
"authDescription": null,
"clientDomain": "TRUENAS",
"clientAccount": "test",
"workstation": "MERCURY",
"becameAccount": null,
"becameDomain": null,
"becameSid": null,
"mappedAccount": "test",
"mappedDomain": "TRUENAS",
"netlogonComputer": null,
"netlogonTrustAccount": null,
"netlogonNegotiateFlags": "0x00000000",
"netlogonSecureChannelType": 0,
"netlogonTrustAccountSid": null,
"passwordType": "NTLMv2",
"duration": 3373
},
"timestamp_tval": {
"tv_sec": 1698602447,
"tv_usec": 934725
}
},
------------------------------------------------------------------------------------------------------
"sudo midclt call smb.passdb_list" shows the correct list of user accounts including lisbeth and test with the correct UID numbers.
------------------------------------------------------------------------------------------------------
"sudo smbclient //127.0.0.1/MEDIA -U test" shows an "smb: \>" prompt but in /var/log/samba4/log.smbd I can see the failed authentication attempts like this one:
Auth: [SMB2,(null)] user [WORKGROUP]\[test] at [Sun, 29 Oct 2023 22:40:16.538365 CET] with [NTLMv2] status [NT_STATUS_WRONG_PASSWORD] workstation [SATURN] remote host [ipv4:127.0.0.1:59058] mapped to [WORKGROUP]\[test]. local host [ipv4:127.0.0.1:445]
and the successful attempts after a "sudo midclt call smb.synchronize_passdb" like this one:
[2023/10/29 23:13:28.304279, 2] ../../source3/auth/auth.c:324(auth_check_ntlm_password)
check_ntlm_password: authentication for user [test] -> [test] -> [test] succeeded