[Samba] Domain Security and Mapping as More than One User

[Steve Waltner]

I have Samba 3.0.21c installed on Fedora Core 3 and would finally  
like to get rid of the cleartext passwords on our server. The current  
smb.conf file

[global]
   workgroup = WORKGROUP
   wins server = 10.0.0.1
   security = share
   encrypt passwords = No
[homes]
    comment = Home Directories
    read only = no
    guest ok = no
    preserve case = yes
    short preserve case = yes

This is working fine, but requires users to make registry changes to  
allow cleartext passwords. I don't want to deal with yet another  
password database on the network, so I don't want to use the private  
smbpasswd file. I switched the server over to use domain  
authentication by updating the smb.conf file to

[global]
   workgroup = DOMAIN
   wins server = 10.0.0.1
   security = domain
[homes]
    comment = Home Directories
    read only = no
    guest ok = no
    preserve case = yes
    short preserve case = yes

and running "net rpc join ...." on the Samba server. This works in  
that the users are able to map a drive to the Samba server using  
their domain account. Unfortunately, we have several users that  
currently attach to the server with multiple login names, which is  
why I have the "security = share" config option set. By setting this  
to domain, we lose this ability and users get the error stating:

Multiple connections to a server or shared resource by the same user,  
using more than one user name, are not allowed. Disconnect all  
previous connections to the server or shared resource and try again..

It sounds like there is no way to authenticate using our Active  
Directory domain to avoid the cleartext passwords and still allow the  
users to connect to the Samba server as multiple users.

One kludgy workaround is to run VMware on this system or switch to  
Solaris 10 and use their zones feature to start multiple instances of  
Samba (ie: samba1, samba2, samba3, samba4) to allow multiple  
connections to the same physical computer although each connection  
would be going to a different virtual computer. Hopefully this hack  
won't be required.

Steve