Setting up Samba on Red Hat Linux 6.1

Peter Samuelson peter at
Wed Apr 12 19:17:21 GMT 2000

[cc back to samba at because this info might be of general interest]

[Chris Mauricio]
> If I use "encrypt passwords = yes" and "security = user", then each
> user on my NT Domain who wishes to access a share on the linux box
> must have a username and password equivelant to the one on the NT
> domain. ( right? ) If I do that, then they ALSO have a valid login on
> the linux box ( right? ) So that means in theory, they could telnet
> into the box, or I should disable some script somewhere to prevent
> this. ( right?)

Yes, but there are ways around it.

"encrypt=yes" "sec=user" means the Samba server authenticates users.
Each user must have an entry in /etc/passwd -- Samba uses this for
the person's real name, home directory, UID, GID and /etc/group for
other groups.  The user *also* has to have an entry in
/usr/local/samba/private/smbpasswd -- or wherever you designate
smbpasswd to live -- to determine the actual password used.

Basically, when you're in "security=user", the Samba server acts as
though it's just in a workgroup, not a domain -- UNLESS you also use
"domain logons=yes" in which case it behaves as either a PDC or BDC.  I 
have no direct personal experience with Samba as DC, however.  I
wouldn't try it with 2.0.x.

> if I use "encrypt passwords = yes" and "security = domain" , then
> automatically, NT auths the users, maintains the passwords, so here
> is the part that I am not clear on: How do I set either user A, B, C
> to access the samba share, and deny others from the domain, if NT is
> the one doing the auth?

With "sec=domain", you must also have "password server = SOME_SERVER"
where SOME_SERVER is an NT domain controller (or a Samba DC...) -- or
possibly an NT workstation with local accounts you want to use, but
that won't work as well and requires knowing what you are doing.  Well,
actually, you can use "password server = *" (some versions of Samba)
and it will broadcast for one, just like NT does, but that's not
recommended because it makes it easier for an attacker to spoof you.

In any case, Samba is no longer in control of the passwords.  However,
Samba is *still* in complete control of the UID, because you can map
any NT user to any Unix user.  Use the "username map=FILENAME"

> related question: How do I set permissions on certain files within
> the public share, ( 'A' can read, 'B' has no access, 'C' can read/
> write ) if NT is maintainig the passwords? If the user doesn't exist
> on the linux box, I can't readily set permissions can I ?

The user *must* exist, either way.  That paragraph above where I
described the duties of /etc/passwd -- it also applies to "sec=domain".
The only things /etc/passwd are not used for in this case are password
and login shell.  (Login shell doesn't mean much to SMB, after all.)
After the username is substituted in from your username map file (if
you have one), the resulting Unix user must be in /etc/passwd.  Thus he
will have a UID and at least one GID.  Thus you can use the regular
Unix permissions mechanisms to restrict access however you wish.



More information about the samba mailing list