[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