[olug] samba qs - pswds and trust?

Brian Wiese bwiese at cotse.com
Fri Mar 14 05:56:00 UTC 2003


see inline... sidenote: anyone setup Samba 2.2 with LDAP yet?

On Thu, 13 Mar 2003 13:58:18 -0600
ktb <xyf at nixnotes.org> wrote:

|On Thu, Mar 13, 2003 at 09:53:21AM -0600, Brian Wiese wrote:
|> I am in the process of setting up an windows network domain with Samba
|> 2.2(debian woody) as the primary domain controller[1] and many Win98
|> clients. Just a couple of the questions I've been trying to figure out
|> lately are, wondering if anyone on the list has experienced this...
|> 
|> Q 1.
|> Can the PAM modules cracklib or passwdqc be used to test the security
|> of smbpasswds?  I honestly haven't tried this yet, so I am just looking
|> for a quick answer before I start messing with (learning) PAM configs. 
|> I have set in smb.conf on the PDC: security = user
|> encrypted passwords = yes
|> obey pam restrictions = yes
|> pam password change = yes
|> 
|
|Take a look at the pam section in smb.conf for this.  Pam is only used
|if you use plain text passwords.  Pam is ignored if encrypted passwords
|are used.

(I will play with this more when I get a chance...)

That is what I thought at first, but I guess I am confused -- as using PAM
for say 'password' enforcement and then sending the passwords plain text
on the network kinda defeats the purpose.  Anything above Win9x it sounds
'needs' to use encrypted passwords to join a domain.

It seems like 'encrypted passwords = yes' only disables the
'authentication'[1] services of PAM.  I imagine the 'account', 'session',
and 'password' services should still work.  Or does it only pertain to
'account' and 'session'??

[1] http://marc.theaimsgroup.com/?l=samba&m=104751341004799&w=2
------------------------------
obey pam restrictions (G)
When Samba 2.2 is configured to enable PAM  support  (i.e.  --with-pam),
this  parameter  will  control  whether  or  not Samba should obey PAM's
account and session management directives. The default  behavior  is  to
use  PAM for clear text authentication only and to ignore any account or
session management. Note that Samba always ignores PAM  for  authentica-
tion  in  the  case  of encrypt passwords = yes . The reason is that PAM
modules cannot support the challenge/response  authentication  mechanism
needed in the presence of SMB password encryption.

Default: obey pam restrictions = no
------------------------------
pam password change (G)
With the addition of better PAM support in Samba 2.2, this parameter, it
is  possible  to  use  PAM's  password change control flag for Samba. If
enabled, then PAM will be used for password changes when requested by an
SMB  client  instead of the program listed in passwd program.  It should
be possible to enable this without changing your passwd  chat  parameter
for most setups.

Default: pam password change = no
------------------------------

I just find it hard to believe that all of these networks using Samba
instead of Windoze SMB servers have no password policy enforcement at all.
 I imagine it's then even harder to use this as any type of single-sign-on
as it is used in M$ environments.  Any suggestions for single sign-on?  

|> Q 2.
|> There is also a WinNT4 PDC on this network for a different domain which
|> many of the Win98 clients belong to.  On the Samba PDC I've tried
|> setting up 'allow trusted domains = yes'[2] in the smb.conf, added a
|> unix and samba machine (trust) account for the WinNT4 PDC -- and thats
|> it?  Anyhow, it doesn't work.  That should allow any users of the NT4
|> domain to access resources on my Samba domain.  Is this at all
|> possible, or must the trust be between NT4/2k domains, and samba can
|> only act as a member server?  I'm not sure how else to specifiy which
|> domains to trust either.  The samba pdc documentation[1] sounds like
|> this is not/no longer possible, but the smb.conf does not say this
|> function is depricated or anything.  How is'allow trusted domains'
|> supposed to work?
|
|I found security_level.{txt|html} or DOMAIN_MEMBER.{txt|html} to be real
|helpful.  You will find the two files in the source code.  
|
|Also take a look at "man smb.conf" there is a section dedicated to "allow
|trusted domains."  You say the WinNT4 PDC is on a different network.
|If the two PDCs are on different subnets WINS has to be enabled IIRC.  
|
|I've not tried merging two networks with WinNT4 in the mix so can't
|really answer your questions directly.
|hth,
|kent

I've given up on this, as I sadly don't believe that it is possible.  I
reread over the line in the smb.conf file, and I remembered that I cannot
run this feature on a PDC since the PDC is set to 'security = user' and so
it would only be effective on a member server in a domain.  Also the Samba
PDC Howto[2] says that this is not possible among other things.  Seems
pretty limited so far, hopefully Samba 3.0[3] or TNG[4] will have more
features to support.

"The following pieces of functionality are not included in the 2.2
release: Windows NT 4 domain trusts ..."

[2] http://us1.samba.org/samba/ftp/docs/htmldocs/Samba-PDC-HOWTO.html
[3] http://us1.samba.org/samba/ftp/alpha/WHATSNEW.txt
[4] http://www.samba-tng.org/

------------------------------
allow trusted domains (G)
This  option only takes effect when the security option is set to server
or domain.  If it is set to no, then attempts to connect to  a  resource
from  a  domain  or workgroup other than the one which smbdis running in
will fail, even if that domain is trusted by the remote server doing the
authentication.

This  is useful if you only want your Samba server to serve resources to
users in the domain it is a member of. As an example, suppose that there
are  two  domains DOMA and DOMB. DOMB is trusted by DOMA, which contains
the Samba server. Under normal circumstances, a user with an account  in
DOMB  can  then  access  the  resources  of a UNIX account with the same
account name on the Samba server even if they do not have an account  in
DOMA. This can make implementing a security boundary difficult.

Default: allow trusted domains = yes
------------------------------


More information about the OLUG mailing list