Hi deano_ferrari
at last some opportunity to test. Thanks for your links in your last two posts. Especially the last link (https://www.claudiokuenzler.com/blog…nd-event-31017) seems to be elaborate. I like the effort he puts in explaining the why behind certain options/settings.
In spite of this, like a typical technician I already had started my test sequence before reading anything:shame:, though the link mentioned explained a bit what I experienced. Before proceeding, the situation described is only created for the sake of testing. Having the same password everywhere is not my ideal world, But I wanted to rule out this aspect in this way.
First I did analyze the log I exported last weekend. This proofed much to long with a repetition of the same sections. Besides this it became impossible to related to the action in the W10 system
That is why I’ve done some testing again, now with tailing the resulting logging after each action in W10. Look below for the given situation.
- Current smb.conf and shares.conf are already shared
- Workgroup: THUIS
- Non AD network
- The w10 system, DESKTOPFERD2015, is a W10 Pro version, with the guest access restriction in place (which I prefer to keep that way)
- The shares are created in the root level of the Linux System (FS-002). Of them the stash is relevant for this test and only intended for testing purposes.
ferd@FS-002:~> cd /
ferd@FS-002:/> ls -al
total 16
...]
drwxrwxrwx 1 ferd users 0 Aug 28 15:16 stash
drwxrwxr-x 1 smbuser smbgroup 76 Aug 21 15:12 store
...]
ferd@FS-002:/>
- The stash is set completely open and put on my (ferd) ownership.
- Current password setup:
[LIST]
- Windows OS account , passwd_x
- Windows credential against server FS-002: DESKTOPFERD2015\ferd, passwd_x
- Linux OS user account: ferd, passwd_x
- Samba user: ferd, passwd_x (for certainty this password was re-initiated this test session)
[/LIST]
The way it is now set up, with an entry in the credential manager I need to access the shared folder with logging in. I tried different approaches to test what could work. After each try the smb log were obtained:
logged in with credential ferd@W10desktop
DESKTOPFERD2015\ferd - not successfull
Result in smb log:
ferd@FS-002:~> sudo tail -f /var/log/samba/log.smbd
[sudo] password for root:
[2022/09/17 17:14:53.781531, 5] ../../auth/gensec/gensec.c:543(gensec_update_done)
gensec_update_done: ntlmssp[0x557ff234eae0]: NT_STATUS_WRONG_PASSWORD
[2022/09/17 17:14:53.781562, 3] ../../auth/gensec/spnego.c:1445(gensec_spnego_server_negTokenTarg_step)
gensec_spnego_server_negTokenTarg_step: SPNEGO(ntlmssp) login failed: NT_STATUS_WRONG_PASSWORD
[2022/09/17 17:14:53.781591, 5] ../../auth/gensec/gensec.c:543(gensec_update_done)
gensec_update_done: spnego[0x557ff233a7e0]: NT_STATUS_WRONG_PASSWORD
[2022/09/17 17:14:53.781652, 3] ../../source3/smbd/smb2_server.c:3955(smbd_smb2_request_error_ex)
smbd_smb2_request_error_ex: smbd_smb2_request_error_ex: idx[1] status[NT_STATUS_LOGON_FAILURE] || at ../../source3/smbd/smb2_sesssetup.c:147
[2022/09/17 17:14:53.782632, 3] ../../source3/smbd/server_exit.c:240(exit_server_common)
Server exit (NT_STATUS_CONNECTION_RESET)
**logged in with THUIS\ferd
**but making mistake with entering ferd huis - in spite of this eventually “successfull”
Result in smb log:
:
...]
[2022/09/17 17:22:49.539818, 3] ../../source3/auth/auth.c:202(auth_check_ntlm_password)
check_ntlm_password: Checking password for unmapped user [ferd]\[thuis]@[DESKTOPFERD2015] with the new password interface
[2022/09/17 17:22:49.539852, 3] ../../source3/auth/auth.c:205(auth_check_ntlm_password)
check_ntlm_password: mapped user is: [ferd]\[thuis]@[DESKTOPFERD2015]
[2022/09/17 17:22:49.539938, 5] ../../source3/passdb/pdb_tdb.c:602(tdbsam_getsampwnam)
pdb_getsampwnam (TDB): error fetching database.
Key: USER_thuis
[2022/09/17 17:22:49.540028, 3] ../../source3/auth/check_samsec.c:399(check_sam_security)
check_sam_security: Couldn't find user 'thuis' in passdb.
[2022/09/17 17:22:49.540080, 5] ../../source3/auth/auth.c:264(auth_check_ntlm_password)
auth_check_ntlm_password: sam_ignoredomain authentication for user [thuis] FAILED with error NT_STATUS_NO_SUCH_USER, authoritative=1
[2022/09/17 17:22:49.540141, 2] ../../source3/auth/auth.c:348(auth_check_ntlm_password)
check_ntlm_password: Authentication for user [thuis] -> [thuis] FAILED with error NT_STATUS_NO_SUCH_USER, authoritative=1
[2022/09/17 17:22:49.540213, 2] ../../auth/auth_log.c:665(log_authentication_event_human_readable)
Auth: [SMB2,(null)] user [ferd]\[thuis] at [Sat, 17 Sep 2022 17:22:49.540179 CEST] with [NTLMv1] status [NT_STATUS_NO_SUCH_USER] workstation [DESKTOPFERD2015] remote host [ipv6:xxxx] mapped to [ferd]\[thuis]. local host [ipv6:xxxx]
{"timestamp": "2022-09-17T17:22:49.540397+0200", "type": "Authentication", "Authentication": {"version": {"major": 1, "minor": 2}, "eventId": 4625, "logonId": "0", "logonType": 3, "status": "NT_STATUS_NO_SUCH_USER", "localAddress": "xxxx", "remoteAddress": "xxxx", "serviceDescription": "SMB2", "authDescription": null, "clientDomain": "ferd", "clientAccount": "thuis", "workstation": "DESKTOPFERD2015", "becameAccount": null, "becameDomain": null, "becameSid": null, "mappedAccount": "thuis", "mappedDomain": "ferd", "netlogonComputer": null, "netlogonTrustAccount": null, "netlogonNegotiateFlags": "0x00000000", "netlogonSecureChannelType": 0, "netlogonTrustAccountSid": null, "passwordType": "NTLMv1", "duration": 2853}}
[2022/09/17 17:22:49.540548, 3] ../../source3/auth/auth_util.c:2310(do_map_to_guest_server_info)
No such user thuis [ferd] - using guest account
...]
[2022/09/17 17:23:28.356036, 3] ../../source3/smbd/smb2_server.c:3955(smbd_smb2_request_error_ex)
smbd_smb2_request_error_ex: smbd_smb2_request_error_ex: idx[1] status[NT_STATUS_NOT_FOUND] || at ../../source3/smbd/smb2_ioctl.c:353
[2022/09/17 17:23:28.356906, 3] ../../lib/util/access.c:372(allow_access)
Allowed connection from xxxx (xxxx)
[2022/09/17 17:23:28.357065, 3] ../../source3/smbd/service.c:611(make_connection_snum)
make_connection_snum: Connect path is '/stash' for service [stash]
[2022/09/17 17:23:28.357168, 3] ../../source3/smbd/vfs.c:115(vfs_init_default)
Initialising default vfs hooks
[2022/09/17 17:23:28.357211, 3] ../../source3/smbd/vfs.c:141(vfs_init_custom)
Initialising custom vfs hooks from /[Default VFS]/]
[2022/09/17 17:23:28.357509, 2] ../../source3/smbd/service.c:854(make_connection_snum)
desktopferd2015 (ipv6:xxxx) connect to service stash initially as user nobody (uid=65534, gid=65534) (pid 3069)
[2022/09/17 17:23:38.932871, 2] ../../source3/smbd/service.c:1129(close_cnum)
desktopferd2015 (ipv6:xxxx) closed connection to service stash
Somehow, in spite of wrong entry got access to the folder. Making this a sort of “**** the system” approach.
Double clicked it to open it:
https://tweakers.net/fotoalbum/image/I8YdUacIqCu6qLCDxKQawri9.png
But I did not have permission to access, repeating the error of last time:
https://tweakers.net/fotoalbum/image/gJGrG2sC8e1jT1DHPYbRpm9S.png
In the smb
log the following was shown:
[2022/09/17 17:25:28.986585, 3] …/…/lib/util/access.c:372(allow_access)
Allowed connection from xxxx (xxxx)
[2022/09/17 17:25:28.986750, 3] …/…/source3/smbd/service.c:611(make_connection_snum)
make_connection_snum: Connect path is ‘/stash’ for service [stash]
[2022/09/17 17:25:28.986838, 3] …/…/source3/smbd/vfs.c:115(vfs_init_default)
Initialising default vfs hooks
[2022/09/17 17:25:28.986880, 3] …/…/source3/smbd/vfs.c:141(vfs_init_custom)
Initialising custom vfs hooks from /[Default VFS]/]
[2022/09/17 17:25:28.987070, 2] …/…/source3/smbd/service.c:854(make_connection_snum)
desktopferd2015 (ipv6:xxxx) connect to service stash initially as user nobody (uid=65534, gid=65534) (pid 3069)
[2022/09/17 17:25:28.991049, 5] …/…/source3/auth/auth.c:566(make_auth3_context_for_ntlm)
make_auth3_context_for_ntlm: Making default auth method list for server role = ‘standalone server’, encrypt passwords = yes
…]
[2022/09/17 17:25:28.994917, 3] …/…/source3/smbd/smb2_server.c:3955(smbd_smb2_request_error_ex)
smbd_smb2_request_error_ex: smbd_smb2_request_error_ex: idx[1] status[NT_STATUS_FS_DRIVER_REQUIRED] || at …/…/source3/smbd/smb2_ioctl.c:353
…]
[2022/09/17 17:25:29.195368, 3] …/…/source3/smbd/filename.c:1559(get_real_filename_full_scan)
scan dir didn’t open dir .]
…]
[2022/09/17 17:25:29.196151, 3] …/…/source3/smbd/smb2_server.c:3955(smbd_smb2_request_error_ex)
smbd_smb2_request_error_ex: smbd_smb2_request_error_ex: idx[1] status[NT_STATUS_ACCESS_DENIED] || at …/…/source3/smbd/smb2_create.c:337
Googling on the string * smbd_smb2_request_error_ex: smbd_smb2_request_error_ex: idx[1] status[NT_STATUS_ACCESS_DENIED]
*https://serverfault.com/questions/900440/samba-configuration-statusnt-status-access-denied gave me a working approach to deal with this issue:
- In a command prompt on the W10 platform a net use * /delete was executed (that *&^^%^$ windows registry):
[INDENT=2]
Microsoft Windows [Version 10.0.19043.2006]
(c) Microsoft Corporation. All rights reserved.
C:\Users\Ferdinand>net use * /delete
You have these remote connections:
\\Fs-002\stash
\\fs-002\IPC$
Continuing will cancel the connections.
Do you want to continue this operation? (Y/N) [N]: y
The command completed successfully.
[/INDENT]
- in the smb.conf the entry *passdb backend = smbpasswd*
was added (and after that a restart of the smb process)
[INDENT=2]
global]
server string = FS-002
workgroup = THUIS
security = user
map to guest = Bad User
passdb backend = smbpasswd
#log file = /var/log/samba/%m.log
log level = 3
log level = 3 passdb:5 auth:5
#name resolve order = bcast hostinclude = /etc/samba/shares.conf
[/INDENT]
[INDENT=3]
[/INDENT]
These two steps resulted in me being able to access the folder. This made me quite positive, while being able to uberhaupt create a cause-effect.
Still a moving target though:
- I expect I can go back to the desired linux accesses I had in mind.
- not so glad with having to log in to access the remote share (the cretential stuff) and with the credential stuff no matter what. My vulnerable password in that credential database. I suppose I should try to arrange things at the linux side by the
- But: I can now conclude the access to the folder is an independent mechanism of that of the credential mechanism.
- This is a user specific access (suppose). Still need to test I this access can work for a two user approach I expect the force user
- A question from my side concering the *But what about guest access from non-AD machines?*
section of the https://www.claudiokuenzler.com/blog/879/windows-10-server-2016-access-samba-share-guest-account-analysis-workaround-event-31017 source: isn't this as unsecure as grant access to all guests in the W10 pro manchine? Do not understand the repercussions of map to guest = bad password fully.
These are my findings until now. Tomorrow I hope to do some further steps, and look more into your sources.
Thanks for your effort,
Ferd