The State of Play: (what smb.conf changes can we do for 3.0
Martin.Sheppard at csiro.au
Martin.Sheppard at csiro.au
Mon Nov 12 22:02:02 GMT 2001
I don't think that the browsing parameters like domain master should be
removed. There are legitimate reasons why your PDC may not be the same as
your Domain Master. That being said, it's fine for "server role" to set the
default value of "domain master". It's just removing it completely that I
object to. It has a very specific meaning that I may want to adjust
independently of other parameters.
You also need to take into account how the server role parameter is going to
be handled in a W2K environment should samba ever get native support for it.
In that environment every DC has a writable copy of the directory, so are
they all defined as PDCs in the "server role"? Which one does the PDC
emulator functions, like being the domain master browser? Is this yet
another server role or is it more sensible to just use "domain master" for
that. Thinking about these things now will avoid making more changes to this
new parameter in the future.
From: Andrew Bartlett [mailto:abartlet at pcug.org.au]
Sent: Tuesday, 13 November 2001 3:54 PM
To: Multiple recipients of list SAMBA-TECHNICAL
Subject: The State of Play: (what smb.conf changes can we do for 3.0)
This is just an update as to where I see the debate at present, and what
I'm still proposing:
Firstly, I would like to thank everybody involved, because it has been
very worthwhile getting these changes (and more importantly the
associated policies) debated and decided.
Regarding 'security = [domain|server]':
My changes to create a new 'auth order = ' parameter obsolete both of
these options back to 'security = user'. However, given the wealth of
documentation involved and the need to maintain smb.conf syntax where
possible I am currently proposing (as others have suggested) that
security=domain|server be used to provide sane defaults for 'auth order
='. (This applies particularly because auth order is by its very nature
a more complex parameter).
I am presently preparing a patch on this basis, which will make *no*
changes to existing parameters. (Aside from minor parameters like 'use
rhosts' and 'plain text to smbpasswd').
Regarding 'server role = [pdc|bdc|domain member|dmb]'
This change is the change that has proved controversial. Inside samba
many functions (particularly in nmbd, but also in the lsa subsystem and
elsewhere) need to be told what NT role we play on the network. There
is a function in samba already called 'lp_server_role()', which
determines its value based on the following combinations:
Some pieces of samba (nmbd and lsa stuff in particular) use the
Security Domain Logons
USER Y = PDC
USER N = Standalone
DOMAIN/SERVER Y = BDC
DOMAIN/SERVER N = DOMAIN MEMBER
SHARE * = Standalone
Others use (mostly nmbd):
Domain Master Domain Logons Security
Y Y = PDC
N Y = BDC
N N = STANDALONE
While still others (lib/util_sid.c) uses
Domain Logons Security
Y USER = PDC
What we should have instead is this mapping: (With pdc, bdc, member,
standalone, dmb being an enumerated type) that can provide constant
policy across the entirety of Samba.
PDC BDC Standalone (also member) DMB
domain master = Y N N Y
domain logons = Y Y N N
Similarly, I don't actually care if it only provides defaults for these
parameters (rather than killing them), but I think it is time to clean
up settings that are often misused, and while referenced in external
documentation are often referenced so *incorrectly*.
I was recently given a sample smb.conf file for an article I've written
on using Samba as a PDC - I killed most of the settings before
submitting it back, because samba now has sane defaults. Still we have
things like 'os level' 'master browser' ' domain master' and so on, and
people pass around folklore about these being needed for *generic*
Similarly, we can use the 'server role =' parameter to provide defaults
to 'auth order' in the same way I'm proposing 'secuity=' would as a
In any case, you will see that the setting for server role (as used in
important bits of samba, like the lsa code) will no longer depend on
secuirty=, and therfore security=server and security=domain can be
depreciated over time. Furthermore, this will allow Samba greater
flexibility because its status as a BDC is no longer tied to *not*
having local access to passwords. (BDC capabilities have *nothing* to
do with what the security= parameter implies).
Finally, I would like to look into *disabling* parts of samba when the
server role precludes their use. In particular I would like to look
into removing the ability to conduct a domain logon to the printer down
the hall - as a security measure if nothing else.
The task for admins is to fill in one new line in their smb.conf:
My server is a ____ (PDC/BDC/Domain Member/Standalone/DMB).
This is particulary for users who are new to samba, why make the job
more complex than it needs to be?
In many cases this can be easily determined by a migration script, and
will not be required for users already in secuiry=user (and not a pdc)
because that will be the default.
I hope this makes my (revised) position clearer. (And yes, this is a
debate not an argument, and I have found many of the arguments put very
Andrew Bartlett abartlet at pcug.org.au
Manager, Authentication Subsystems, Samba Team abartlet at samba.org
Student Network Administrator, Hawker College abartlet at hawkerc.net
http://samba.org http://build.samba.org http://hawkerc.net
More information about the samba-technical