how flexible is domain authentication?
Brandon Craig Rhodes
brandon at oit.gatech.edu
Sun Oct 26 18:38:07 GMT 2003
Andrew Bartlett <abartlet at samba.org> writes:
> On Sun, 2003-10-26 at 15:05, Brandon Craig Rhodes wrote:
>> [Brandon asked whether moving from one samba verifying against
>> another with "security = server" to "security = domain" really
>> required the client samba to be moved into the same domain as the
>> password server.]
> I am looking at *useful* ways to make the authentication scheme more
> flexible, however you should also consider if you have made your site
> more complex than it really needs to be ;-)
Our rough history is: samba servers were installed by groups that
needed Unix connectivity and file sharing; when people started asking
for user passwords to be the same everywhere, we set up a password
server and pointed each group samba at it with "security = server"
(which I think was the only option Samba offered back then); and now
that recent Windows versions are breaking quite regularly with the
"security = server" model, we want to upgrade to domain security.
Our challenge: there are today dozens of groups using the password
server in "security = server" mode, serving perhaps 1,500 or 2,000
among them. Your basic advice, Andrew - and thanks for the detailed
response! - seemed to involve changing the workgroup of every client
> Samba will verify the password against whatever domain the client
> chose to provide. If the client is a machine in CAMPUS_AUTH, then
> this should 'just work'. ... Samba 3.0 will always ask [its] DC for
> all non-local users. That DC will use the domain portion of the
> username to decide where to send the request.
Unfortunately changing the domain of more than a thousand clients
spread all across our campus would be a herculean effort and lots of
work for our customer support team. By comparison, modifying samba or
its configuration on the password server would be fairly easy, and
modifying samba or its configuration on the groups servers would
involve a few days of work but nothing like the support nightmare of a
campus-wide Windows client domain migration.
Therefore I am extremely interested in your other idea:
> If the [clients] use a domain that is not CLUSTER1 and not any of
> [its] trusted domains, then it will use the local domain to
> authenticate the user. We could add flexibility, such that the
> default domain is chosen to be something else.
This sounds almost exactly like what we need; say, a configuration
file option "rewrite user domain = CAMPUS_AUTH" that causes all users
trying to authenticate to appear to be in the foreign "CAMPUS_AUTH"
domain, rather than in the local domain of the group-level server.
(Am I correct in assuming that the CAMPUS_AUTH domain would have to be
trusted by CLUSTER1 in this case?)
But not knowing if this were possible, I had not taken my experiments
with the code past an unsuccessful attempt in check_ntlm_password() to
rewrite the user_info->domain at the top of the function to another
value. Where in the code is the process you outlined above - where an
unrecognized client domain is rewritten - undertaken?
I will continue exploring the code myself, but welcome any pointers
you or other authors on the mailing list might be able to provide.
Brandon Craig Rhodes http://www.rhodesmill.org/brandon
Georgia Tech brandon at oit.gatech.edu
More information about the samba-technical