how flexible is domain authentication?

[Brandon Craig Rhodes]

Consider samba1.university.edu that runs samba-3 to provide a Windows
cluster with logins, home directories, and printers, and that uses a
central campus password server also running samba-3:

(samba1.university.edu)
   workgroup = CLUSTER1
   security = server
   password server = campusauth.university.edu

(campusauth.university.edu)
   workgroup = CAMPUS_AUTH
   security = user

But "security = server" is unstable and often breaks, so we want to
move to a domain security relationship between the samba servers:

(samba1.university.edu)
   workgroup = CLUSTER1
   security = domain
   password server = campusauth.university.edu

(campusauth.university.edu)
   workgroup = CLUSTER1
   security = user
   domain logins = yes

which works fine once samba1 has been given a machine account on
campusauth and has then run "net rpc join".

Our problem:

This requires "campusauth" and "samba1" to have the same domain; but
campusauth must check passwords for samba servers all across campus,
which are in dozens of different (and locally-administered) domains.
Since "campusauth" can only be in one domain, we have several options:

   - (Our least favorite, but the only one we know to be possible:)
   Run dozens of samba servers on "campusauth" on different IP
   addresses or ports, each with a different domain, and point each
   client samba at the IP or port that uses the same domain.  This
   would be easier if we could override the port which samba uses to
   connect to its password server, but this seems to be hard-wired.

Does the domain authentication protocol allow any more flexible
alternatives?  Here our expertise reaches its end and we must solicit
any help that readers of this mailing list might be able to provide.
Are any of the following approaches possible, or do all break up on
the sharp rocks of authentication protocol inflexibility:

   - Could an interdomain trust relationship allow the client sambas
   to verify user passwords in CAMPUS_AUTH, and then give them
   CLUSTER1 resources once they are authenticated?

   - Could the password server be convinced to check passwords against
   other domains besides the one given in its "workgroup =" parameter,
   authenticating users in whatever domain the client samba happened
   to need its users in?

   - Could the client sambas be modified to check their users against
   the CAMPUS_AUTH domain, then let them access resources in CLUSTER1?

I suppose it is clear that we do not quite understand why each samba
server has only one "workgroup =" parameter.  Why, for instance, can
individual shares not be given their own "workgroup = " settings?
Does this all boil down to inflexibility in the underlying protocols?

Thanks for *any* help that you can provide, and we are rather grateful
that samba exists at all, :-)
-- 
Brandon Craig Rhodes                         http://www.rhodesmill.org/brandon
Georgia Tech                                            brandon at oit.gatech.edu