your mail

[Luke Kenneth Casson Leighton]

> }no, to what are known as "trust" accounts.  a "workstation" trust account,
> }for example, allows a user to log in from that workstation.  it is used to
> }encrypt the user's password, for example.

> for the time being, samba generates that one on-the-fly (hash("host")),

ok, if you support only this and do not support a direct "set NT 16 byte
password hash", then you can't support the "workstation password change
function", which is a workstation trust account set function.  this is a
security risk. 

> and i have an ACL (access-control-list) function that is used to
> allow/disallow a user access to a specific ws, for example only first
> year students have access to certain hosts, etc.

cool!  that is actually automatically supported, as it were, in NT SAMs.
but only up to 8 workstations can be put in the list.  

> 
> }- a _direct_ change NT / LM password hash, ok
> }
> }- let's think.  a "is_smb_passwd_ok(NThash and/or LMhash)" function: 
> }maybe. yeah, i reckon you could get away with this.  we'd have to add it
> }to the password api...
> }
> if you could unify all calls for (smb only?)authentication into:
>    is_smb_passwd_ok(user-name, type, challenge, NThash, LMhash)
> 
> and type: i don't have a nice name - yet - but i see two types
> according to the hash function to use:
> 
>     1) for logon
>     2) for all other services.

all services use nt lm hashes.  there actually need (and are) two versions
of this function.

one takes NT hash and LM hash; the other takes an 8 byte challenge plus
the 24 byte NT response (generated by client from 16 byte blah blah) plus
24 byte LM response (generate by client from blah blah) you know the
score. 

these two functions already exist therefore in password.c.  from what you
are saying
 
> this is fun, im working in the garden, and i get down to the basement
> for some e-mail exhanges, software/hardware.

cool!  how are the roses?