The Samba-Bugzilla – Bug 884
It is impossible to register an XP workstation into the domain using a non-root account
Last modified: 2005-11-14 09:24:32 UTC
We wish to give certain "non-trusted" admins the right to register new
workstations, but without handing them over the root password for our
So we created a domain admin entry containing the username for this
domain admin group = winadm root
We also created an appropriate add user script.
However, we noticed that winadm still cannot register any machines:
the entry does show up in /etc/passwd, but not in /etc/samba/smbpasswd
Next attempt was to declare winadm as admin user for the [IPC$] share:
admin users = winadm
Now, we did get an entry in /etc/samba/smbpasswd, but we still get the
"Access denied" error on the client workstation.
However, if the password for winadm happens to be the same as the
password for root, it works (but would be pointless in our case).
Experimentations with strace and using "non-standard" root login name
(root2) showed us that apparently the following is happening.
1. Client workstation connects as winadm to samba server, samba
server authenticates using winadm and the password passed by the
2. Samba server calls add user script
3. Samba server itselfs opens smbpasswd, and adds machine account
4. Samba server fchowns smbpasswd to 600 (a security measure?)
5. Samba server tries to authenticate the user a second time, but
this time it
a. does a geteuid() (which returns 0 because of our admin users
b. looks up the username corresponding to the uid in /etc/passwd
c. checks the client-supplied passwords against that user's
(i.e. root's) smbpasswd entry (instead of checking it against
(c) obviously fails unless both passwords (winadm and root) happen
to be the same
Ok, next try:
We drop the admin users clause, and instead chown smbpasswd to the
ntadmin group (winadm's group), and make it group writeable.
This still fails, because of step 3 outlined above (not only does that
step 3 attempt to remove the group write bit, but it also exits the
process if this fchmod fails)
We chown smbpasswd to the winadm user. This works ok, but is
questionable from a security point of view. And, moreover, it does not
allow us to have several distinct users which have the right to add
machines to the domain.
Finally we settled to the following type of solution:
root preexec = chown winadm /etc/samba/smbpasswd
root postexec = chown root /etc/samba/smbpasswd
(more than one winadm user may be handled by use of the %u variable
and a suitable wrapper script)
We are not entirely satisfied with this workaround however, since it
leaves smbpasswd read/writeable to the "untrusted" winadm user for a
fraction of a second.
IMHO, there are several issues within samba which need fixing:
1. Smbd should acquire root rights when adding the machine account to
smbpasswd, even if no admin users is specified; it may drop these
privileges after the operation. IMHO, this is implementable in a
safe way, after all, this is also what happens if an unprivileged
user changes his own smb user password
2. Smbd should not consider the failure of the fchmod on
/etc/samba/smbpasswd to be fatal (this would allow the "group
writeable" hack to work)
3. Smbd should save the initial username used for authentication, and
use that same username for the second authentication as well, even
if the euid of the samba process has changed since then.
Sorry, but the 2.2 is not under development any longer.
If you can reproduce this bug against the latest 3.0 release,
please reopen this bug and change the version in the report.