[Samba] checking passwords from a different domain
Brandon Craig Rhodes
brandon at oit.gatech.edu
Sat Oct 25 18:12:00 GMT 2003
Consider a cluster of Windows workstations whose logins, home
directories, and printers are served by a samba-3 server configured
thus:
workgroup = CLUSTER
security = server
password server = campusauth.university.edu
where the "campusauth" machine also runs samba, configured thus:
workgroup = CAMPUS_AUTH
security = user
in order to check user passwords.
This is, of course, a very unstable and problem-ridden configuration
because of the problems described for "security = server" in the
manuals and HOWTO.
Now imagine that you want to move to domain authentication. This can
be accomplished by changing the cluster server configuration to
workgroup = CLUSTER
security = domain
password server = campusauth.university.edu
then changing the configuration of "campusauth" to
workgroup = CLUSTER
security = user
domain logins = yes
then creating a "cluster$" machine account on "campusauth" using the
smbpassword command, and finally using the "net rpc join" command on
the cluster server to establish a trust relationship between the two
machines.
The problem with this is that it requires the "campusauth" machine to
belong to the same workgroup as the cluster server. While this is
possible for one cluster, the campusauth machine serves dozens of
clusters, each with its own workgroup, and thus cannot be in the
domain of all of the clusters at once. This was fine under the
"security = server" model, which apparently did not care whether
client samba and password samba were in the same domain; but it does
not seem to be the way that domain trust works under samba.
Possible solutions we are considering:
- (Our least favorite, but maybe the only one possible:) Running
a few dozen instances of samba on "campusauth", one to serve each
domain, and using either separate IP addresses or NAT to direct
each client to the server that has the same domain (since,
tragically, samba seems to include no option for connecting to a
password server on a non-standard port; one could conceivably
compile each cluster samba to connect to a different port, but we
hope to use stock sambas on the clusters since they are so many,
and since they are administered by different people).
- Setting up an inter-domain trust relationship that convinced
the cluster samba to verify user passwords in the CAMPUS_AUTH
domain, and then grant them access to its CLUSTER resources as a
result; or maybe that convinced the password server that it could
verify passwords in other domains besides the one given in its
"workgroup = " parameter. Does anyone know how either situation
could be established?
- Modify the samba source code used on the cluster machines so
that they check user passwords in the CAMPUS_AUTH domain and then
let them into the local CLUSTER resources as that user. My own
reading of the source code has not yet suggested where this
change might be made, nor whether the protocol makes this
possible.
I suppose much of this boils down to the question: does a samba
running as a password server, and another samba using it, have to have
the same "workgroup = " parameter because of convention, or because
the password-verification protocol will actually break if the two
strings do not match? Asked another way: why does samba have only one
"workgroup = " parameter, and not allow its authentication workgroup
to differ from its service workgroup - and for that matter, why does
Samba not allow a different "workgroup = " parameter for each share it
serves? Is this, again, dictated by an inflexibility in the
underlying protocols?
Thanks for any help that you can provide,
--
Brandon Craig Rhodes http://www.rhodesmill.org/brandon
Georgia Tech brandon at oit.gatech.edu
More information about the samba
mailing list