10.5.7: Windows File Sharing - passwords not stored, only guest access poss
*The problem:*
A friend of mine recently updated his Mac from Tiger to Leopard (10.5.7) and lost access to his Samba shares on the Mac from his Linux system.
Various tests with the command line samba client smbclient that didn't involve credentials were successful and confirmed that samba was running and the shares exist:
smbclient -L //local-ip
But trying to log in with a user name and password failed (from the local terminal as well as from the Linux box):
smbclient //local-ip/share -U username
*The conclusion:*
The tests I made - which are described in the next section - suggest that Samba (i.e. Windows File Sharing) does not or can not access the password hash that has been calculated by the OS.
Prerequisites
* smb.conf is the one installed by Leopard.
* The folder has been shared.
* File sharing has been activated.
* SMB has been selected.
* The user has been assigned to that folder in the file sharing pane.
* I have been prompted for a user password the first time.
* The user has permissions to the shared folder. (However, the problem described here happens before we reach that point).
We also tried a "fresh" user account, shared one of the new users sub-folder, assigned the user to his file share, and tried to connect to that folder with the new users' credentials. The password was successfully re-checked by an ssh login and switching user accounts - no luck with Samba.
*The evidence:*
Most of the evidence comes from the samba log file: /var/log/samba/log.smbd
After an unsuccessful login the log file showed:
ntlm passwordcheck:
NO NT password stored for user ...
or
NO NT MD4 password check failed for user ...
and
NEITHER LanMan nor NT password supplied for user ....
followed by
Authentication for user ... -> .... FAILED with error NT STATUS_WRONGPASSWORD
which leads to
(SMBsesssetupX) NT STATUS_LOGONFAILURE
If I use an unknown user, I find this in the log file:
check samsecurity: Couldn't find user '...' in passdb.
That means: there is a password database, samba can access the username, but not the password, or the password is not stored in that database.
According to internet sources, the password in question is actually a (NTLM) password hash which should be stored in the first line of /private/var/db/shadow/hash/UUID-of-the-user
I checked that file and found the hash in the first line.
However:
sudo pdbedit -Lw
which displays the password hashes that Samba is going to use, showed only "xxx" where the NTLM hashes were supposed to be. And I guess that if pdbedit can't see it, neither can the Samba daemon.
Trying to add a password using
sudo smbpasswd -a -e user
or
sudo smbpasswd user
only results in:
Failed to modify entry for user ...
Failed to modify password entry for user ...
*The work-around:*
I switched the Samba password backend from the default odsam to smbpasswd in /etc/smb.conf
; passdb backend = odsam
passdb backend = smbpasswd
smb passwd file = /etc/smbpasswd
This time
sudo smbpasswd -a user
did work without an error message. A new user appeared in /etc/smbpasswd, but the password hash was still "xxxx". As expected, I still couldn't log in to that samba account.
I calculated the NTLM hash externally and pasted the result into the right place in the smbpasswd file.
After restarting Samba, the samba user was able to log-in and access the share... Yeah!
But...
... any subsequent calls of
sudo smbpasswd user
did not update /etc/smbpasswd
It seems the only action that the command smbpasswd is capable of doing is to insert a new user, but forgetting to encode the password.
*What it looks like*
It seems that the NTLM hash is being calculated, but not stored in a place that Samba can access. When an user tries to log-in, his account is found in the database, but the stored password is invalid. The log-in fails and the request is mapped to user nobody.
Any hints on how to fix this are appreciated.
Mike
A friend of mine recently updated his Mac from Tiger to Leopard (10.5.7) and lost access to his Samba shares on the Mac from his Linux system.
Various tests with the command line samba client smbclient that didn't involve credentials were successful and confirmed that samba was running and the shares exist:
smbclient -L //local-ip
But trying to log in with a user name and password failed (from the local terminal as well as from the Linux box):
smbclient //local-ip/share -U username
*The conclusion:*
The tests I made - which are described in the next section - suggest that Samba (i.e. Windows File Sharing) does not or can not access the password hash that has been calculated by the OS.
Prerequisites
* smb.conf is the one installed by Leopard.
* The folder has been shared.
* File sharing has been activated.
* SMB has been selected.
* The user has been assigned to that folder in the file sharing pane.
* I have been prompted for a user password the first time.
* The user has permissions to the shared folder. (However, the problem described here happens before we reach that point).
We also tried a "fresh" user account, shared one of the new users sub-folder, assigned the user to his file share, and tried to connect to that folder with the new users' credentials. The password was successfully re-checked by an ssh login and switching user accounts - no luck with Samba.
*The evidence:*
Most of the evidence comes from the samba log file: /var/log/samba/log.smbd
After an unsuccessful login the log file showed:
ntlm passwordcheck:
NO NT password stored for user ...
or
NO NT MD4 password check failed for user ...
and
NEITHER LanMan nor NT password supplied for user ....
followed by
Authentication for user ... -> .... FAILED with error NT STATUS_WRONGPASSWORD
which leads to
(SMBsesssetupX) NT STATUS_LOGONFAILURE
If I use an unknown user, I find this in the log file:
check samsecurity: Couldn't find user '...' in passdb.
That means: there is a password database, samba can access the username, but not the password, or the password is not stored in that database.
According to internet sources, the password in question is actually a (NTLM) password hash which should be stored in the first line of /private/var/db/shadow/hash/UUID-of-the-user
I checked that file and found the hash in the first line.
However:
sudo pdbedit -Lw
which displays the password hashes that Samba is going to use, showed only "xxx" where the NTLM hashes were supposed to be. And I guess that if pdbedit can't see it, neither can the Samba daemon.
Trying to add a password using
sudo smbpasswd -a -e user
or
sudo smbpasswd user
only results in:
Failed to modify entry for user ...
Failed to modify password entry for user ...
*The work-around:*
I switched the Samba password backend from the default odsam to smbpasswd in /etc/smb.conf
; passdb backend = odsam
passdb backend = smbpasswd
smb passwd file = /etc/smbpasswd
This time
sudo smbpasswd -a user
did work without an error message. A new user appeared in /etc/smbpasswd, but the password hash was still "xxxx". As expected, I still couldn't log in to that samba account.
I calculated the NTLM hash externally and pasted the result into the right place in the smbpasswd file.
After restarting Samba, the samba user was able to log-in and access the share... Yeah!
But...
... any subsequent calls of
sudo smbpasswd user
did not update /etc/smbpasswd
It seems the only action that the command smbpasswd is capable of doing is to insert a new user, but forgetting to encode the password.
*What it looks like*
It seems that the NTLM hash is being calculated, but not stored in a place that Samba can access. When an user tries to log-in, his account is found in the database, but the stored password is invalid. The log-in fails and the request is mapped to user nobody.
Any hints on how to fix this are appreciated.
Mike
Other OS