Security stratagy
I do a lot of small NT networks with 3 to 50 win98 clients. I would like to try samba in place of the NT PDC or as a secondary server to add storage.
Because these setups are so small and their is no one on site to manage I do the following on NT?
1. Enable the guest Account and create a public folder that everyone has access to.
2. Create a private folder that only allows access to an accounting group.
The public group all have usernames and may have scripts than run kxstart. But all have blank passwords.
The accounting group have real passwords and are the only ones that can access the private share. Permissions are setup on the share level. The server is locked.
I kind of like the idea of encripted passwords because I would hate to have to explain to someone what I am doing if they caught me turning encripted pw's off.
With Samba I have used the map to guest paramater but am not sure how to restrict on the private share.
1. do as little username and pw settting as possible
2. duplicate the above functionality
3. Easy to teach a secretary/admin how to add a person.
4. What if the linux box is sharing win98 users with an existing PDC
5. Print to a Jetdirect connected printer
Because these setups are so small and their is no one on site to manage I do the following on NT?
1. Enable the guest Account and create a public folder that everyone has access to.
2. Create a private folder that only allows access to an accounting group.
The public group all have usernames and may have scripts than run kxstart. But all have blank passwords.
The accounting group have real passwords and are the only ones that can access the private share. Permissions are setup on the share level. The server is locked.
I kind of like the idea of encripted passwords because I would hate to have to explain to someone what I am doing if they caught me turning encripted pw's off.
With Samba I have used the map to guest paramater but am not sure how to restrict on the private share.
1. do as little username and pw settting as possible
2. duplicate the above functionality
3. Easy to teach a secretary/admin how to add a person.
4. What if the linux box is sharing win98 users with an existing PDC
5. Print to a Jetdirect connected printer
ASKER
I'm sure I'll understand all that in a few days but as of now??
I'll do my best to to, based on my current understanding list the steps I'll have to take. Please corrent them for me so it will actually work.
1. mkdir /export
2. mkdir /export/public
3. mkdir /export/acct
4. chmod 770 /export/acct
5. chmod 777 /export/public
6. linuxconf (add group accouting and group public
7. linuxconf (add user user1 and user2 to group public)
8. linuxconf (add user acct1 and acct2 to group acct
9. In sbm.conf set security = user
Now I know I'm missing a bunch of stuff.
1. the smbpasswd file? I do need to add to it how.
2. How do I get blank passwords for user1 and user2 and get them allowed by smb and linux. I get errors saying a blank password is not allowed
3. I believe I need a smb.conf command to make sure new files and subfolders have the corrent permisions.
4. I believe I need smb.conf commands to allow two groups on public and one group on acct
5. I'll bet I'll have to do a chown somewhere.
6. I'm not familier with a differnce in permissions for files and directorys and how to make it happen and why.
The above 5 things I have read about and suspect have something to do with all this but I do not know exactly what is really needed and how do to it.
I'll do my best to to, based on my current understanding list the steps I'll have to take. Please corrent them for me so it will actually work.
1. mkdir /export
2. mkdir /export/public
3. mkdir /export/acct
4. chmod 770 /export/acct
5. chmod 777 /export/public
6. linuxconf (add group accouting and group public
7. linuxconf (add user user1 and user2 to group public)
8. linuxconf (add user acct1 and acct2 to group acct
9. In sbm.conf set security = user
Now I know I'm missing a bunch of stuff.
1. the smbpasswd file? I do need to add to it how.
2. How do I get blank passwords for user1 and user2 and get them allowed by smb and linux. I get errors saying a blank password is not allowed
3. I believe I need a smb.conf command to make sure new files and subfolders have the corrent permisions.
4. I believe I need smb.conf commands to allow two groups on public and one group on acct
5. I'll bet I'll have to do a chown somewhere.
6. I'm not familier with a differnce in permissions for files and directorys and how to make it happen and why.
The above 5 things I have read about and suspect have something to do with all this but I do not know exactly what is really needed and how do to it.
ASKER
I think I have a few of theese things worked out tonite.
smbpasswd -n -a username
adds the username with a null password
I used linuxconf to add a new user. I wanted to leave the password null and it seemed to work but complained loudly.
I use the map to guest = bad user because I figure that way I do not have to enter any of the people that have null passwords and access to public only.
I added null passwords = yes for them also.
Still a little fuzzy re: directory and file permissions.
Also I want to make sure file shareing is on for .dbf and .mdb database files.
smbpasswd -n -a username
adds the username with a null password
I used linuxconf to add a new user. I wanted to leave the password null and it seemed to work but complained loudly.
I use the map to guest = bad user because I figure that way I do not have to enter any of the people that have null passwords and access to public only.
I added null passwords = yes for them also.
Still a little fuzzy re: directory and file permissions.
Also I want to make sure file shareing is on for .dbf and .mdb database files.
From a comment ago...
To use Unix groups to secure a directory, you'd:
1) create the Unix group (say acctng).
2) set the group ownership and perms on the the directory and it's contents:
chgrp -R acctng /path-to/acct-data
chmod -R o-rwx /path-to/acct-data
chmod -R g+rw /path-to/acct-data
3) create or change the accounts of the users who are allowed access to be group acctng.
It doesn't matter what group the other users are in. Only those users in group acctng will be able to read or write anything within the protected directory.
To make a directoy completely public, you'd:
chmod -R go+rw /path-to/public
That's it. The world has read/write privs and it doesn't matter who the users is or what group they are in.
Note that I didn't use file modes to set the perms. The reason being that directories and ordinary files typically need different modes. A directory has to have it's executable bit set, but ordinary files done need or should have the executable bit set (unless the file is actually supposed to be executable). For example a public directory would need a mode of 777 (rwxrwxrwx), but ordinary files in that dir should be mode 666 (rw-rw-rw-).
To use Unix groups to secure a directory, you'd:
1) create the Unix group (say acctng).
2) set the group ownership and perms on the the directory and it's contents:
chgrp -R acctng /path-to/acct-data
chmod -R o-rwx /path-to/acct-data
chmod -R g+rw /path-to/acct-data
3) create or change the accounts of the users who are allowed access to be group acctng.
It doesn't matter what group the other users are in. Only those users in group acctng will be able to read or write anything within the protected directory.
To make a directoy completely public, you'd:
chmod -R go+rw /path-to/public
That's it. The world has read/write privs and it doesn't matter who the users is or what group they are in.
Note that I didn't use file modes to set the perms. The reason being that directories and ordinary files typically need different modes. A directory has to have it's executable bit set, but ordinary files done need or should have the executable bit set (unless the file is actually supposed to be executable). For example a public directory would need a mode of 777 (rwxrwxrwx), but ordinary files in that dir should be mode 666 (rw-rw-rw-).
ASKER
I printed this out and will sudy it while I am traveling on business for a couple of days. Thanks
ASKER
I did what you sugested above and indeed it did work. One thing did work differently than expected however.
If from win98 I put in the accting1 user a user in the accting group and the correct password I can connect to //linux2/accting fine. If however I login to windows with a blank password for accting1 I get no option to provide a password when connecting to linux2. It just denies entry.
I have map to guest = bad user
That's it isn't it.
Is there a rule as to when an attempt is make to open linux2:
1. password required to connect to this resource
2. Password to connect to /ic$ (or whatever that path is)
2. You do not have permission to open this resource.
I have seen three different errors and am not sure what the differce is.
I'm not sure exactly what the implication of this is?
>Note that I didn't use file modes to set the perms. The reason being that directories and ordinary files typically need different modes. A directory has to have it's executable bit set, but ordinary files done need or should have the executable bit set (unless the file is actually supposed to be executable)
Are you saying that if you use the octal format you will force a change on either files or directorys that is not wanted?
That the default permissions are closer to what we want so just + or - the changes is more exact.
I may be missing the significance of what you are doing.
Also I am concerned about the permissons given to newly created files and folders by the win users.
If from win98 I put in the accting1 user a user in the accting group and the correct password I can connect to //linux2/accting fine. If however I login to windows with a blank password for accting1 I get no option to provide a password when connecting to linux2. It just denies entry.
I have map to guest = bad user
That's it isn't it.
Is there a rule as to when an attempt is make to open linux2:
1. password required to connect to this resource
2. Password to connect to /ic$ (or whatever that path is)
2. You do not have permission to open this resource.
I have seen three different errors and am not sure what the differce is.
I'm not sure exactly what the implication of this is?
>Note that I didn't use file modes to set the perms. The reason being that directories and ordinary files typically need different modes. A directory has to have it's executable bit set, but ordinary files done need or should have the executable bit set (unless the file is actually supposed to be executable)
Are you saying that if you use the octal format you will force a change on either files or directorys that is not wanted?
That the default permissions are closer to what we want so just + or - the changes is more exact.
I may be missing the significance of what you are doing.
Also I am concerned about the permissons given to newly created files and folders by the win users.
Windows 95/98 has to already have the username and password before it opens a remote share, i.e., the user has logged into windows with a username & password that the server will accept for the share(s). NT can obtain from the user and supply to the server the username & password when the share is accessed, but not 95/98. Thus the implication of "all of this" is that if you don't log into windows correctly, you can't access the shares.
File modes... yes directories and files get different permissions. There are a couple of ways to solve this. One is to use the "chmod -R o-rwx"/"chmod -R g+rw" forms of the commands. Those say to remove any of "rwx" for "other" (i.e., world) and add "rw" to each item. After the first of the two a directory would change from "rwxr-xr-x" to "rwxr-x---" and a file would change from "rw-r--r--" to "rw-r-----". The second of the two would change the dir to "rwxrwx---" and a file to "rw-rw----". Make sense?
Another way is to explicity set the modes, but this requres distinguishing between directories and files. The following commands would restrict access to the acctng group:
> chown -R acctng /path-to/accounting
> find /path-to/accounting -type d -exec chmod 770 {} \;
> find /path-to/accounting -type f -exec chmod 660 {} \;
Check out the man page for find & chmod for details, but basically I "found" each node in the directory structure and distinquished between dirs (-type d) and files (-type f), seeting the absolute mode accordingly.
The mode/ownership of a newly created file is a function of what Unix group/user they are and what default mode Samab has been told to use for that share ("create mask" in smb.conf).
File modes... yes directories and files get different permissions. There are a couple of ways to solve this. One is to use the "chmod -R o-rwx"/"chmod -R g+rw" forms of the commands. Those say to remove any of "rwx" for "other" (i.e., world) and add "rw" to each item. After the first of the two a directory would change from "rwxr-xr-x" to "rwxr-x---" and a file would change from "rw-r--r--" to "rw-r-----". The second of the two would change the dir to "rwxrwx---" and a file to "rw-rw----". Make sense?
Another way is to explicity set the modes, but this requres distinguishing between directories and files. The following commands would restrict access to the acctng group:
> chown -R acctng /path-to/accounting
> find /path-to/accounting -type d -exec chmod 770 {} \;
> find /path-to/accounting -type f -exec chmod 660 {} \;
Check out the man page for find & chmod for details, but basically I "found" each node in the directory structure and distinquished between dirs (-type d) and files (-type f), seeting the absolute mode accordingly.
The mode/ownership of a newly created file is a function of what Unix group/user they are and what default mode Samab has been told to use for that share ("create mask" in smb.conf).
ASKER
Thanks!!!
I get both example, not at first, but I do now.
Is there any functional difference as to the result of these options other than syntax? I suspect not.
Also I see you used chgrp in a previous entry and chown this last time. Again identical results, yes?
This is all working for me now. Thanks again
The next step to replace the NT box is to make it possible to use logon scripts. I currently use kixstart sometimes and just a directory mapping batch file other times. Where do I start for that.
This would require me to have a logon for each user even the public group.
In order to force a linux pw to null I had to edit /etc/shadow and delete everything between the first two colons.
Then I found smbpasswd syntex to set it to null in the smbpasswd file.
linuxconf seems to keep the two file synced which saves a step but will not allow a null pw. Can that behavior be changed?
Does the rpm for samba automatically make the change to linuxconf to sync passwords or does this come from somewhere else?
a passwd or useradd by it's self does not seem to effect smbpasswd.
I get both example, not at first, but I do now.
Is there any functional difference as to the result of these options other than syntax? I suspect not.
Also I see you used chgrp in a previous entry and chown this last time. Again identical results, yes?
This is all working for me now. Thanks again
The next step to replace the NT box is to make it possible to use logon scripts. I currently use kixstart sometimes and just a directory mapping batch file other times. Where do I start for that.
This would require me to have a logon for each user even the public group.
In order to force a linux pw to null I had to edit /etc/shadow and delete everything between the first two colons.
Then I found smbpasswd syntex to set it to null in the smbpasswd file.
linuxconf seems to keep the two file synced which saves a step but will not allow a null pw. Can that behavior be changed?
Does the rpm for samba automatically make the change to linuxconf to sync passwords or does this come from somewhere else?
a passwd or useradd by it's self does not seem to effect smbpasswd.
Re: chgrp/chown... My mistake, I meant chgrp. As to the equivalency of the two methods, yes they can have exactly the same results. The difference would be that adding perms, say via "chmod g+rw" on a file that was "rwxr-x---" wouldn't remove the executable mode and the file would wind up as "rwxrwx---". Using the absolute mode 660 would make the file "rw-rw----". For ordinary data files the difference isn't important, but for Unix/Linux executables removing execute is important.
The rest shortly...
The rest shortly...
ASKER
Surprisingly enough I think I have it.
Some of the files I would like samba to manage will be desktop database files. .mdb for MS access and .dbf for dBase4/foxpro. I am unclear as to what the settings are required for samba to handle the filesharing requirements of muli-user programs accessing these files.
Also scripts are of interest.
Some of the files I would like samba to manage will be desktop database files. .mdb for MS access and .dbf for dBase4/foxpro. I am unclear as to what the settings are required for samba to handle the filesharing requirements of muli-user programs accessing these files.
Also scripts are of interest.
ASKER
Edited text of question.
Passwords...
Linux really doesn't like null passwords as you've found. Other than saving a user a few keystrokes, I don't see any reason to not have a password and I can think of lots of reasons that they ought to be used and be GOOD passwords.
The usual argument for not having passwords is that none of the data that those users access needs to be protected, but if there's any form of connectivity outside the local net that argument just doesn't make sense. The data might not need to be protected, but the systems those users access do need to be protected from outside crackers. Good passwords help a lot in that respect. Any security hole that's present, even to a unprivlidged account just makes the cracker's job easier as he can use that account to look for other security holes.
Logon scripts...
The current distributed, stable, version of Samba doesn't provide for logon scripts, for that you need PDC functionality. The next version of Samba will have PDC support. I've been running three instances of various versions of the "developemental code" since Novemember in a production environment, principally to get the PDC functionality with excellent results. I don't know when this stuff will go into a "release" state, but I wouldn't imagine it would be much longer.
I see you edited the question. Was the edit about the JetDirect printing? If so, it's pretty trivial. Set the Jetdirect boxes up with an IP address and configure the printer in Linux as network printer. If you want to print to one from Linux, it needs to have the right filters in place (hint, one with postscript is the best to use as a Linux printer). More than likely you'll just want to print from Windows in that case all you need is a printcap that specifies the network address and the queue.
Linux really doesn't like null passwords as you've found. Other than saving a user a few keystrokes, I don't see any reason to not have a password and I can think of lots of reasons that they ought to be used and be GOOD passwords.
The usual argument for not having passwords is that none of the data that those users access needs to be protected, but if there's any form of connectivity outside the local net that argument just doesn't make sense. The data might not need to be protected, but the systems those users access do need to be protected from outside crackers. Good passwords help a lot in that respect. Any security hole that's present, even to a unprivlidged account just makes the cracker's job easier as he can use that account to look for other security holes.
Logon scripts...
The current distributed, stable, version of Samba doesn't provide for logon scripts, for that you need PDC functionality. The next version of Samba will have PDC support. I've been running three instances of various versions of the "developemental code" since Novemember in a production environment, principally to get the PDC functionality with excellent results. I don't know when this stuff will go into a "release" state, but I wouldn't imagine it would be much longer.
I see you edited the question. Was the edit about the JetDirect printing? If so, it's pretty trivial. Set the Jetdirect boxes up with an IP address and configure the printer in Linux as network printer. If you want to print to one from Linux, it needs to have the right filters in place (hint, one with postscript is the best to use as a Linux printer). More than likely you'll just want to print from Windows in that case all you need is a printcap that specifies the network address and the queue.
ASKER
Does the default ftp user have any default password? It would seem that if one user did not have a password then any other users in the same category do not need one either. So you must delete the ftp user and perhaps others as part of your securing your new systems?
That does bring up the question of guest user. The default is something like nobody. The help from swat suggests ftp. What are the rules for the guest user and shouldn't it have a null password?
In regards to the printer one of the neat features in NT is the ability to copy the win98 drives to a share and have the auto install by clicking on the share in NN. Is that available in Smb? How?
I am very impressed with the prerelease of samba running production. How many hosts? What features are you using besides scripts?
That does bring up the question of guest user. The default is something like nobody. The help from swat suggests ftp. What are the rules for the guest user and shouldn't it have a null password?
In regards to the printer one of the neat features in NT is the ability to copy the win98 drives to a share and have the auto install by clicking on the share in NN. Is that available in Smb? How?
I am very impressed with the prerelease of samba running production. How many hosts? What features are you using besides scripts?
ASKER
Adjusted points to 100
ASKER
I was able to get the HP4000TN working throught the built in jetdirect.
1. printed the config page to see the default ip address
2. reserved an ip address in my dhcp webramp server
3. telnet from a computer to the jetdirect and changed the ip address to the one I wanted.
4. used the X printtool to create lp0 as a network printer and put in the printer ip address
Somehow the lp0 spool directory got created by it's self.
5. I tried a kill -HUP on the pid of lpd but I had to reboot to get lpd working again.
6. Ran swat and turned the printer thing to on and configed lp0 to allow gurest
7 Printed a test page
I found a section in one of my books that explains how to create a printer$ share for the window printer def file will check it out tomorrow.
Making progress
Does that all sound about right
What's the story on any sharing switches for desktop database files?
What is needed?
1. printed the config page to see the default ip address
2. reserved an ip address in my dhcp webramp server
3. telnet from a computer to the jetdirect and changed the ip address to the one I wanted.
4. used the X printtool to create lp0 as a network printer and put in the printer ip address
Somehow the lp0 spool directory got created by it's self.
5. I tried a kill -HUP on the pid of lpd but I had to reboot to get lpd working again.
6. Ran swat and turned the printer thing to on and configed lp0 to allow gurest
7 Printed a test page
I found a section in one of my books that explains how to create a printer$ share for the window printer def file will check it out tomorrow.
Making progress
Does that all sound about right
What's the story on any sharing switches for desktop database files?
What is needed?
The printer setup sounds right for a normal linux printer. As I mentioned, the queues can also be set up without any filtering to allow the windows clients essentially direct access to the printer, which is sometimes helpful... Which way to do it depends on what printers and windows printer drivers are involved.
As to the database files, I don't know if there's anything special that needs to be done or not. There's probably something about it on the Samba site, but I've never looked.
You asked what features of the new stuff I'm using. We use the new code to get the PDC support so that we don't have to make accounts on the NT workstations (that's the majority of the clients at present) and so we can use login scripts. There's not that many clients using the Samba servers right now, probably less than 100. Potentially that number could get up into the 500-700 range and loading tests on the servers (Sun Ultra 60's) don't indicate that we'd have any problem sustaining that kind of load.
I'm probably forgetting something, but...
As to the database files, I don't know if there's anything special that needs to be done or not. There's probably something about it on the Samba site, but I've never looked.
You asked what features of the new stuff I'm using. We use the new code to get the PDC support so that we don't have to make accounts on the NT workstations (that's the majority of the clients at present) and so we can use login scripts. There's not that many clients using the Samba servers right now, probably less than 100. Potentially that number could get up into the 500-700 range and loading tests on the servers (Sun Ultra 60's) don't indicate that we'd have any problem sustaining that kind of load.
I'm probably forgetting something, but...
ASKER
I am interested in managing the samba server from a windows client using swat and telnet.
I noticed that the windows telnet mangles linuxconf. Am I missing a setting. I did find a gnu win32 telnet client that works great but if the built in windows one will work that will save keeping track of a floppy.
Also I configured the printer with printtool from X. I could not find any other character printtool. Could not belive that linuxconf did not include it. Is there a character printtool you know of or use.
Manual editing of printcap is of course possible but there were warnings and the syntex seemed fussy.
What you mean by a printer with no filtering is just a printcap def with out the filter line, is that it?
I noticed that the windows telnet mangles linuxconf. Am I missing a setting. I did find a gnu win32 telnet client that works great but if the built in windows one will work that will save keeping track of a floppy.
Also I configured the printer with printtool from X. I could not find any other character printtool. Could not belive that linuxconf did not include it. Is there a character printtool you know of or use.
Manual editing of printcap is of course possible but there were warnings and the syntex seemed fussy.
What you mean by a printer with no filtering is just a printcap def with out the filter line, is that it?
ASKER
I believe I have found answers to two of my questions.
/etc/rc.d/init.d/lpd restart
to force printcap to be reread
http://x.x.x.x:10000
to configure a printer with webmin
Not a character base app like I was looking for but can be run from a remote host with a browser so x does not have to loaded on the target host.
My next step is to put it all together and build another machine from scratch.
/etc/rc.d/init.d/lpd restart
to force printcap to be reread
http://x.x.x.x:10000
to configure a printer with webmin
Not a character base app like I was looking for but can be run from a remote host with a browser so x does not have to loaded on the target host.
My next step is to put it all together and build another machine from scratch.
To configure a printer without an output filter you don't need anything but a shell and an editor.
This is all covered by "man printcap", but if I have a networked printer at 192.168.2.233, I can create a /etc/printcap entry like:
raw1:\
:sd=/var/spool/lpd/raw1:\
:mx#0:\
:sh:\
:rm=192.168.2.233:\
:rp=raw1:
And make the spool directory with:
> mkdir /var/spool/lpd/raw1
> chmod 755 /var/spool/lpd/raw1
> chown root:lp /var/spool/lpd/raw1
And restart lpd.
The advantage of this kind of printer for windows clients is that the navite windows drivers can print without having the printer data massaged bt the Linux filter... It just gets shipped straight to the printer.
This is all covered by "man printcap", but if I have a networked printer at 192.168.2.233, I can create a /etc/printcap entry like:
raw1:\
:sd=/var/spool/lpd/raw1:\
:mx#0:\
:sh:\
:rm=192.168.2.233:\
:rp=raw1:
And make the spool directory with:
> mkdir /var/spool/lpd/raw1
> chmod 755 /var/spool/lpd/raw1
> chown root:lp /var/spool/lpd/raw1
And restart lpd.
The advantage of this kind of printer for windows clients is that the navite windows drivers can print without having the printer data massaged bt the Linux filter... It just gets shipped straight to the printer.
ASKER
I just did a few reinstalls on different hardware just to make sure my homegrown installation guide makes sense. I noticed that when I did a fresh install of rh 6.1 using samba3.softdesigns.com for a host name and a static address of 192.168.1.11 for the ip address after booting the /etc/hosts file looks like this:
127.0.0.1 localhost.localdomain localhost samba3.softdesigns.com
Which I had to edit to:
127.0.0.1 localhost.localdomain localhost
192.168.1.11 samba3.softdesigns.com samba3
I also noticed that I had to create a file with the following command:
touch /var/lock/samba/STATUS..LC
Are both of these edits necessary because of an error in the RH installation procedure or is there some error I'm making during the initial install.
I want to make my installation procedure as simple as possible and not introduce steps that could be avoided.
I'm ready to wrap this one up and am thankfull for all the help.
127.0.0.1 localhost.localdomain localhost samba3.softdesigns.com
Which I had to edit to:
127.0.0.1 localhost.localdomain localhost
192.168.1.11 samba3.softdesigns.com samba3
I also noticed that I had to create a file with the following command:
touch /var/lock/samba/STATUS..LC
Are both of these edits necessary because of an error in the RH installation procedure or is there some error I'm making during the initial install.
I want to make my installation procedure as simple as possible and not introduce steps that could be avoided.
I'm ready to wrap this one up and am thankfull for all the help.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thank you very much. I can now blast in RH and Samba with confidence in record time. I now get to face my NT techs and convince them of the wonders of Samba. The sales guys will be easy. <g>
When your NT techs learn that everything, and I mean everything, is in a file that can be inspected, modified, and corrected without having to re-load the OS (the NT way), they'll start becomming Linux advocates. At least that's been my experience.
It doesn't hurt, if you can find a few bucks, to get each one of them any of the decent beginner books on Linux/Unix. I think that by now you could pretty easily scan a few and pick one out that would give them a good start.
It doesn't hurt, if you can find a few bucks, to get each one of them any of the decent beginner books on Linux/Unix. I think that by now you could pretty easily scan a few and pick one out that would give them a good start.
The second level can be done within Samba. You can explictly define (valid users being a list or a unix group) who can access a particular share which denies access to all others.
The combination of these two mechanisms provides very good security for sensitve data. It doesn't matter how the users get to the data, via Samba or via Unix, (as long as they aren't root), if they aren't the right person in the right group they just aren't going to be able to access the protected directory or directories.
Okay, what else... Yes Samba can be configured to authenticate against an existing PDC. The next version of Samba can be a PDC, and at some point you'll be able to administer Samba via the NT User Manager. I've had three instances of the 2.1.x developmental code tree running as PDC's since November with really good results.
If your setup/environment isn't too complicated and you use the same arraingement for each site, it would be pretty easy to set up some shell scripts to automate user account creation/deletion that would make it trivial, even for a computer illiterate. And yes I wouldn't consider using other than encrypted passwords in Samba. It just doesn;t make sense to have to fiddle the registry on each client.
I think I covered everything, but if I missed something... Well that's what comment are for...