[ale] Samba setup

[Michael Trausch]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mark Wright wrote:
> I added a root passwd to the smbpasswd file and then made sure I added
> myself.  I did put a UID for myself on the system.  After I did this I
> have changed the failure message (which I forgot to mention in the
> original post)  Now I am getting a message that says a "machine account
> does not exist."
> 
> That helps.  There is a script that is supposed to create this.  Here is
> the log data from this failure.
> 
> [2005/08/03 20:30:08, 0] rpc_server/srv_samr_nt.c:_samr_create_user(2324)
>   _samr_create_user: Running the command `/usr/sbin/useradd -s
> /bin/false \-d /dev/null l200772$' gave 1
> useradd: unable to lock password file
> 
> "unable to lock password file?"  What is that for?  More reading.....
> 

Okay.

You need to create the Machine Trust Account on the domain controller.
Also, ever user that you want to authenticate, must have a UNIX logon
and a Samba logon.  You do not need to explictly create their home share
- -- only their extra fileshares that they would use for the purpose of
filesharing, and make sure that it has a reasonable umask so that they
can actually "share".

The Machine Trust Account (both in UNIX and Samba) has a $ in it.  So,
for a computer named "fd0man"

To create the Machine Account:

"To add machine account, use your system script, most likely adduser. If
your system does not support user names with $ (i.e. FreeBSD), you must
edit your password database to add it manualy. So on FreeBSD, use vipw."

And in Samba:  smbpasswd -a -m <machine-name>$

"The system accounts for machines do not need login shell neither home
dir, so use false as login shell and /dev/null as home dir.
After adding system accounts, you must use smbpasswd to add Samba
machine account. There you can use $ in usernames."

Now, some of the other quirks that I've found -- I use a mostly default
setup (it's secure and it works).

** If you need extra drives, then give them those drives via a logon
script (or scripts) in the \\SERVER\netlogon share.

** The user that is the Domain Administrator, at least in Samba 2.x, not
sure if this is still true in 3.x, because I haven't tried to go against
it with my network, must be 'root'.  This means that Windows NT
"Administrator" user name can't be a domain administrator.  But that's okay.

You can map Windows system groups to UNIX groups.  If you want a user to
be a Windows Administrator on the local machines when they login to
them, you can set that.  Same for Power User and all of that -- it's
handled directly on Samba.  If you do not do this, I believe they all
default to Administrators.

You have the [homes] section defined, as well as the multiple user
definitions.  This is redundant -- they will get two shares available to
them, however, Windows NT/2k/XP will connect to the [homes] share --
that's the one offered as the user's "network home", which will hold the
Windows profile (and be mapped as Drive Z:).

In reference to the above, I'd recommend that you remove your dedicated
[Profiles] section and store that in each user's UNIX home directory.
This keeps things centralized, and that's their system accountable
space, anyway.  This makes it easier because then the share for the
"roaming profiles" is always available right with the user's
automatically mapped Z: drive.  (\\server\homes\profile or something
like that.)

I would recommend that you create a seperate drive/share so that they
can share their files amongst each other and keep their home directories
private.  Please note that their home directories will also contain
their registry settings and so forth from Windows.  You don't want
everying having access to that.  That's just silly.  Put that command in
your logon.bat in your Netlogon share.

Lastly, I would recommend that you upgrade this setup to Samba 3 -- it
has more up-to-date support for systems on the network, and as your
userbase there migrates upward towards Windows XP, you won't have any
issues with the Samba server running 3.0.  It does a great job.

	- Mike

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC8hZ1PXInbkqM7nwRAj6EAJ9dDtnrLPlsn3e0QhE6rt0LP/ZMjwCfXNQe
PGF9f5WSRyN+a+rDSNDMY2s=
=N+02
-----END PGP SIGNATURE-----