Brandon Craig Rhodes
2003-Oct-25 18:12 UTC
[Samba] checking passwords from a different domain
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@oit.gatech.edu