samba - Nov 1997 - More than one password server? (PR#1609)

> right.  the reason is because the loop in server_cryptkey() is checking 
> for a "valid password server", not a "valid password server
and also
> checking the password".
> 
> so, some more mods are needed.  namely, to combine the server_cryptkey() 
> and server_validate() functionality in some simple way.
Not possible I'm afraid!

The server cryptkey will be different for each password server. The client
uses it to encrypt the password. The resulting 24 byte hashed password
is only any use to the server that generated the cryptkey.

It is split into two functions because one of the functions has to be
called before the client sends the password, and one after.

Cheers, Andrew

On Sun, 9 Nov 1997, Andrew Tridgell wrote:
> > right.  the reason is because the loop in server_cryptkey() is
checking
> > for a "valid password server", not a "valid password
server and also
> > checking the password".
> > 
> > so, some more mods are needed.  namely, to combine the
server_cryptkey()
> > and server_validate() functionality in some simple way.
> 
> Not possible I'm afraid!
> 
> The server cryptkey will be different for each password server. The client
> uses it to encrypt the password. The resulting 24 byte hashed password
> is only any use to the server that generated the cryptkey.
> 
> It is split into two functions because one of the functions has to be
> called before the client sends the password, and one after.
i've been looking at this code a little more closely - you're absolutely
right, andrew.

so, there are two possible solutions to the original problem (having two 
password servers which don't have a trust relationship)

1) set up a trust relationship
2) use the include mechanism and NIS netgroups, to sub-divide the users.  
this will need further exploration.

lukes


<a href="mailto:lkcl@switchboard.net"  > Luke Kenneth Casson
Leighton  </a>
<a href="http://mailhost.cb1.com/~lkcl"> Samba Consultancy and
Support </a>

> so, there are two possible solutions to the original problem (having two 
> password servers which don't have a trust relationship)
> 
> 1) set up a trust relationship
> 2) use the include mechanism and NIS netgroups, to sub-divide the users.  
> this will need further exploration.
There is a 3rd possibility. Remember the ugly scheme I proposed to allow
us to do password migration? When we get back the result of the node
status request we will also know what workgroup the client is in. We
can use this to choose a password server (either via a % macro or by
explicitly doing a netbios lookup for GROUP#1B). We wouldn't do this
by default, but it might be a useful capability.

Maybe it's time to write that node status hack :-)

Andrew