Unix and Samba password sync on Debian Etch
May 14, 2007
Assumptions
- All users of the system are happy with using their Unix passwords for Samba,
- all Unix users will have a Samba account with the same username,
- Unix and/or Samba accounts might already exist, possibly with non-matching passwords.
Prerequisites
Install the following packages, if you do not already have them installed:
# apt-get install libpam-smbpass smbclient
Unix - > Samba
In order to update the Samba password whenever a user changes their Unix password, change
/etc/pam.d/common-password:
from
password required pam_unix.so nullok obscure min=4 max=8 md5
to
password requisite pam_unix.so nullok obscure min=4 max=8 md5
password required pam_smbpass.so nullok use_authtok try_first_pass
Changing “required” to “requisite” for pam_unix will make sure that if Unix password change fails, the execution of plugins ends immediately.
In order for this to work, users must already have Samba accounts, and their Samba passwords must match their Unix passwords. Because this is not necessarily the case, we must change
/etc/pam.d/common-auth:
from
auth required pam_unix.so nullok_secure
to
auth requisite pam_unix.so nullok_secure
auth optional pam_smbpass.so migrate
This will create a Samba user, if it doesn’t already exist, and change it’s password to the Unix password, whenever the user logs in using SSH or any other service that uses default system (common-auth) authentication.
You should see a message “Added user <username>” when logging in using SSH with an account that doesn’t already have a Samba account.
Because this will also create a Samba account for root, you might want to disable root access in Samba (Debian Etch has it disabled by default):
/etc/samba/smb.conf:
invalid users = root
Caveat: This will not work if the user logs in via SSH or other services without using a password (for example by using public/private key authentication). In this case, PAM won’t have the plain-text password, which is needed to create the Samba password.
Notice: When you modify common-password to also require Samba passwords updates, any currently logged in users will not be able to change their password using “passwd” until they re-login, unless they already have an existing Samba account with a password equal to their Unix password.
Samba -> Unix
While synchronization in this direction isn’t necessary if your user’s won’t be changing their Samba passwords directly using smbpasswd, it is nice to enable it just to prevent any mistakes which would break the above configuration.
We instruct Samba to use PAM when changing passwords:
/etc/samba/smb.conf:
unix password sync = yes
pam password change = yes
Restart Samba using /etc/init.d/samba restart.
Configure PAM to support changing of password by Samba:
/etc/pam.d/samba:
@include common-auth
@include common-account
@include common-session
@include common-password
This will use the same mechanism to change passwords when using Samba as when using “passwd”. This means it will require an update of the Unix password before attempting to change the Samba password.
Creating new users
If you attempt to create a new Unix user and set their password using passwd, you will get:
# passwd test
passwd: User not known to the underlying authentication module
passwd: password unchanged
This is because the user does not have a Samba account yet. To avoid using PAM and set the Unix password directly, use chpasswd:
# useradd test
# echo “test:newpass” | chpasswd
If you know of a way around this, don’t hesitate to tell me about it.
Testing
You can check if a given Samba password is correct by using:
$ smbclient -L localhost -U username
To test everything:
- Create a new Unix user, use a user without a Samba account, or delete the user’s samba account using smbpasswd -x <username> (as root),
- login as the user using SSH. You should see a message: “Added user <username>” at the very beginning of the output. Test Samba account using the user’s Unix (and now also Samba) password,
- change user’s Unix password using passwd and test Samba account again with the new password, to see if changes are reflected there,
- change the Samba password using smbpasswd and check both Samba account and try to log in using SSH and the new password,
- change user’s Samba password to something else, as root, using smbpasswd <useranme>,
- you should not be able to change your account’s password as a normal user at this point, using either passwd or smbpasswd. This is an incorrect state, but it should be fixed automatically the next time the user logs in,
- login using SSH and your Unix password again. Try connecting to Samba again, to see whether the password was synced correctly at login time.
If everything works, congratulations.
Posted in 
July 31st, 2007 at 5:00 am
Didn’t work… I followed every step.
This happens when I try to make a new user and set his password:
$ useradd -d /home/test -m -s /usr/bin/tcsh test
$ passwd test
passwd: User not known to the underlying authentication module
passwd: password unchanged
Unable to login with exsisting users, so had to revert.
July 31st, 2007 at 7:38 am
Hi,
I don’t know why you were unable to login with existing users, but another caveat is that you cannot change users’ passwords using ‘passwd’ until they login at least once.
Basically, until they (re-)login, their unix and samba accounts aren’t synced and every attempt to change the password fails. This might explain the first part of your problem.
The approach I described has been in used on (at least) two Etch installs, and should work, but there indeed are some annoying limitations.
Jaka
July 31st, 2007 at 12:13 pm
How can they login if they don’t have password? Most security schemes would disallow this.
I’ve also tried to just do the samba -> unix way. That didn’t work either! :/ The password is updated in samba but not unix…
July 31st, 2007 at 7:12 pm
Ohh, now I understand what your problem is. Try:
# useradd test
# echo “test:newpass” | chpasswd
Jaka
October 6th, 2007 at 12:43 pm
Thank you for your tutorial. It is wat I was looking for since a long time
It worked for me (debian etch), but then I had a problem with gnome-screen-saver: I was not able to unlock the screen anymore.
I solved it by changing the content of /etc/pam.d/gnome-screensaver from:
@include common-auth
to:
auth required pam_unix.so
account required pam_unix.so
session required pam_unix.so
password required pam_unix.so
October 6th, 2007 at 12:55 pm
I don’t understand why @include common-auth didn’t work by default, but I have a couple of suspicions. Could you paste some logs (auth.log) from when it failed?
Also, if you do change the file as you described, I think the first line (auth) is enough.
October 8th, 2007 at 5:57 pm
These are just a few lines from
grep screensaver auth.log
before editing /etc/pam.d/gnome-screensaver
Oct 4 16:47:45 localhost gnome-screensaver-dialog: (pam_unix) authentication failure; logname= uid=1000 euid=1000 tty=:0.0 ruser= rhost= user=claudio
Oct 4 16:47:47 localhost gnome-screensaver-dialog: (pam_unix) authentication failure; logname= uid=1000 euid=1000 tty=:0.0 ruser= rhost= user=root
Oct 4 16:49:14 localhost gnome-screensaver-dialog: (pam_unix) authentication failure; logname= uid=1000 euid=1000 tty=:0.0 ruser= rhost= user=claudio
Oct 4 16:49:15 localhost gnome-screensaver-dialog: (pam_unix) authentication failure; logname= uid=1000 euid=1000 tty=:0.0 ruser= rhost= user=root
Oct 5 18:55:53 localhost gnome-screensaver-dialog: (pam_unix) authentication failure; logname= uid=1000 euid=1000 tty=:0.0 ruser= rhost= user=claudio
Oct 5 18:55:55 localhost gnome-screensaver-dialog: (pam_unix) authentication failure; logname= uid=1000 euid=1000 tty=:0.0 ruser= rhost= user=root
As you can see, there is always a double failure (with two seconds of difference) the first with user claudio and the second from user root.
What does it mean?
October 8th, 2007 at 7:38 pm
Is this all you get? Perhaps something else on another line nearby, which doesn’t get caught using “grep screensaver”? Or in some other log file?
“Authentication failure” just doesn’t say much
October 10th, 2007 at 3:22 pm
Maybe this can be related (other messages are too far in the past)
Oct 4 16:49:14 localhost unix_chkpwd[16361]: no password supplied
Oct 4 16:49:14 localhost gnome-screensaver-dialog: (pam_unix) authentication failure; logname= uid=1000 euid=1000 tty=:0.0 ruser= rhost= user=claudio
Oct 4 16:49:15 localhost gnome-screensaver-dialog: (pam_unix) authentication failure; logname= uid=1000 euid=1000 tty=:0.0 ruser= rhost= user=root
Unfortunately, there’s no “gnome-screensaver” in the other log files.
November 12th, 2007 at 2:27 pm
Hi,
My unix password changes are reflected in samba. But when I change the samba passwprd using ’smbpasswd -a’ the changes are not reflected in the system(/etc/passwd)
Nothing shows up in auth.log wither
November 12th, 2007 at 9:56 pm
Are you sure you put the following into /etc/samba/smb.conf?
unix password sync = yes
pam password change = yes
November 12th, 2007 at 9:58 pm
On second thought, what you’re trying to do won’t work. The “local mode” smbpasswd operations operate on the samba user database directly, afaik.
Just add users like described in the how-to.
November 24th, 2007 at 1:46 am
Thank you very much for publishing this instructions. I wanted to do this for long time and never succeeded.
Jordi
December 22nd, 2007 at 12:07 pm
lost my ssh access to my machine from outside after following all the above. any suggestions ??
or how can i revert back, pl help
December 22nd, 2007 at 12:35 pm
Well, either way you’ll have to gain access to your machine somehow.
If you have physical access, that shouldn’t be a problem. Or is it a collocated server or something similar?
After you do, check the logs (auth.log, most importantly) and see what they reveal.
January 10th, 2008 at 7:19 pm
Thanks for the guide. The issue you are having with the passwd stuff (if the user hasn’t logged in via ssh first) is similar to the issue highlighted in Debian bug #394886 (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=394886).
In this case (and where I have tripped over!) adduser (I use this rather than useradd) calls passwd, but hasn’t previously called something like “smbpasswd -n -a newuser”.
Of course, that bug is pretty old (though not as old as the one it was merged into - in this case, I think I’m going to have to make my own adjustments to adduser. :sigh:
January 12th, 2008 at 8:01 pm
If you are being authenticated … you can log in but when the screensaver comes on it does not authenticate run change the permissions of the following files /etc/libnss-ldap.conf /etc/pam_ldap.conf and /etc/ldap/ldap.conf to 644
this will give everyone read access therefore allowing anyone to bind to ldap
March 17th, 2008 at 5:35 am
Any solution beside using ‘chpasswd’? I still looking for other alternative? How about add pam_smbpass.so into /etc/pam.d/useradd. I still can’t figure out how? How about you?
March 17th, 2008 at 8:49 am
I don’t have that file on Debian Etch.
Also, I finally got rid of Samba, so I don’t use the method I described anymore.
What you would have to do somehow, I guess, is use pam_smbpass.so for the “password” module type (probably in /etc/pam.d/common-password) in a way that would not complain if the user did not exist, but instead just created it.
Using the “migrate” option might work, but I doubt it, since the documentation says “Only meaningful in an “auth” context; used to update smbpasswd file with a password used for successful authentication.”
If you do get it to work, notify me so that I’ll update the how-to.
August 22nd, 2008 at 1:58 am
This tutorial was very helpful and worked a charm. Thank you. I am now able to use samba over my openvpn network and users for samba are created as soon as I log in through ssh and the unix password is being updated when i set the samba password.