We wish to give certain "non-trusted" admins the right to register new 
workstations, but without handing them over the root password for our 
server. 
 
So we created a domain admin entry containing the username for this 
user (winadm): 
 
	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: 
 
[IPC$] 
	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 
 client 
 2. Samba server calls add user script 
 3. Samba server itselfs opens smbpasswd, and adds machine account 
 there 
 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 
    clause...) 
    b. looks up the username corresponding to the uid in /etc/passwd 
    (i.e. root) 
    c. checks the client-supplied passwords against that user's 
    (i.e. root's) smbpasswd entry (instead of checking it against 
    winadm's) 
  (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) 
 
 
Another try: 
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: 
 
[IPC$] 
   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. 
 
Thanks, 
 
Alain