Users can map shares without password in domain-security mode

[Jeffry Smith]

On Wed, 20 Sep 2000, Seip Christian wrote:

> From: Seip Christian <cseip at sr-online.de>
> To: 'Jeffry Smith' <smith at mclinux.com>
> Cc: "'samba at lists.samba.org'" <samba at us4.samba.org>
> Subject: RE: Users can map shares without password in domain-security mode
> 
> Hi!
> 
> 	> What software are you using to do the clustering? 
> 
> It's the Wizard software Watchdog in the light version. Wizard is a german
> company and has been renamed to AppTime recently.
> 
> 	> You need to make certain in clustering that the clustered machines
> have an identical
> 	> view of things (this includes users).
> 
> That's what I'm trying to do and it works. But with the unix users I can't
> guarantee this without additional efforts to keep the user lists
> synchronized. That's the reason why I use the "add user script" feature.
> Samba creates every user that does not yet exist by itself. That works too.
> 
> 	> The best way to do this is 
> 	> to ensure that the path to samba's password & lock files is on
> 	> the shared storage.  Also, how do you have
> 
> It shouldn't be a problem to put the smbpasswd on the shared storage. That
> could work, I'll try this today. That does not interfere with generating all
> users on the fly. Putting the /etc/passwd on the shared storage is a bad
> idea. :-) So I think I have to live with the user homes owned by root
> because of different UIDs on the clusternodes for the same user account.
> Hey, I like your idea with putting that stuff on the storage. So I can put
> the whole private-dir on the storage and have to add only one of the nodes
> to the domain. I tried to solve my problem with "smbpasswd -j DOM -r PDC"
> all the time because I have to add two machines to the domain with the same
> netbios name and a different MAC-address.
> 
> Yes, I do a IP-address-takeover but no, I don't do a MAC-address-takeover. A
> MAC-address-takeover delays the failover a few more seconds because the
> switch has to learn that a MAC-address now appears on a different port. I
> can live with a IP-only-takeover and it seems to work too.
> 
> BTW: I don't think I have to put the lock files on the shared storage
> because there's only one clusternode running smbd at a time. This is managed
> by the Watchdog. Since I have an asymmetric cluster configuration the second
> node is only a stand-by-node. No load-balancing.

My work has been with our GPL'd Kimberlite product, so I can't
guarantee these answers are 100% correct, but since it is shared SCSI,
it should help.

The reason for failing the lockfiles over with Kimberlite is to
maintain state during failover (i.e. the client doesn't need to know
that sambaclu was on node1, is now on node2).  We don't do MAC
takeover, but do ensure you do bind-hosts-only.

I admit, I haven't tested Kimberlite with NT domains (only used share
or user level), but that's going to be one of the next steps.



> 
> 	> the [homes] section of smb.conf set up?  Are you using the %U (if
> they
> 	> don't have a unix account)? 
> 
> Hmmm, here's an excerpt of my smb.conf:
> 
> -------------------------------------- schnipp
> --------------------------------------
> 
> # Global parameters
> [global]
>         workgroup = SR
>         netbios name = SMB
>         interfaces = 192.168.1.77/255.255.255.0
add:
	  bind interfaces only = yes
          smb passwd file = /var/samba/.samba/smbpasswd
	  log file = /var/samba/.samba/log.%m
(assumes a /var/samba/.samba that is shared)


>         security = DOMAIN
>         encrypt passwords = Yes
>         password server = DVDC02
>         name resolve order = wins lmhosts bcast host
>         wins server = 192.168.1.2
>         create mask = 0777
>         directory mask = 0777
>         character set = ISO8859-1
>         local master = no
>         domain master = no
> 
>         browseable = No
>         nt acl support = true
>         add user script = /usr/sbin/smb_useradd.pl %u
> #       null passwords = true
>         mangle case = yes
> 
> [homes]
>         comment = Home-Verzeichnis %u
>         writeable = yes
>         browseable = No
>         guest ok = no
OK, I haven't tried the homes yet, I've used explicit sharing (your
public & pub directories).  I'll have to try this.

> 
> [public] 
>         path = /shares/public
>         read only = No
>         browseable = Yes
>         guest ok = Yes
I assume /shares/public is on the shared storage
> 
> [pub]
>         path = /home/public
>         read only = No
>         browseable = Yes
>         guest ok = yes
same assumption

> 
> -------------------------------------- schnipp
> --------------------------------------
> 
> I tried an additional "valid users = %u" in the [homes]-section, too. But
> that didn't work either. Argh, that can't work. I see that now. Stupid idea.
> :-)
> 
> Maybe this could work but I don't think so because it does the same what the
> [homes]-section does as far as I see:
> 
> -------------------------------------- schnipp
> --------------------------------------
> 
> [%u] 
>         path = /shares/home/%u
>         read only = No
>         browseable = Yes
>         guest ok = Yes
>         valid users = %u
> 
> -------------------------------------- schnipp
> --------------------------------------
> 
> I've got another samba-server from which I have copied the smb.conf and
> which authenticates the users against the same PDC. On the other server
> everything works, here on my machine it doesn't.
> 
> Here's basically what my smb_useradd.pl does, not exactly in perl code but
> understandable I hope.
> 
> -------------------------------------- schnipp
> --------------------------------------
> 
> /usr/sbin/useradd -c "created by smb_useradd.pl" -d /shares/home/%u -s
> "/bin/false" %u
> chmod 777 /shares/home/%u
> chown root.root /shares/home/%u
> 
> -------------------------------------- schnipp
> --------------------------------------

Since it works with one, but not with the cluster, my guess would be
that the two machines in the cluster are not seeing things the same.
You're running useradd on one machine, so it knows about the person,
but not on the other.  I'll have to do some testing, see what happens.
Don't have time right now, I'll see if I can get to it as soon as
possible.

Suspect it would need a script to copy the passwd file to the second
node, or run useradd on the second node (preference would be some kind
of copying, to ensure the systems see the same passwd file, but I
don't know about the effect of changing the passwd file under a
running system).

> 
> My smb_useradd.pl is a modified version of the script posted by Randy
> O'Meara to the list here in April 1999.
> 
> Thanks for taking the time and having a look.
> 
> Best regards,
> 
> Christian
> 
> 
> 

------------------------------------------------------------------------
Jeffry Smith      Technical Sales Consultant     Mission Critical Linux
smith at missioncriticallinux.com   phone:603.930.9739   fax:978.446.9470
------------------------------------------------------------------------
Thought for today:  spell n. 

 Syn. incantation.