your mail

[Luke Kenneth Casson Leighton]

On Sat, 23 May 1998, Danny Braniss wrote:

> In message <Pine.LNX.3.96.980523092052.643B-200000 at regent.cb1.com>you write:
> }> One Time Password - we have these cards that generate a otp, for
> }> people that login from untrusted-sites, and will be giving them out to
> }> student's so they can work in the open spaces.
> }
> }so that's unix-side only, yes?  for which you do not use "encrypt password
> }= yes"?
> 
> no, we have a gina thinggy that asks for the otp first,

*ah*.

_that's_ specialist.

> and if that's
> ok then the regular nt logon is used, still experimental, but seems to
> be working ok.
> 
> }oh dear.  what happens when you store trust accounts?  those do not _have_
> }a clear-text password: you only get a 16 byte NT hash.
> 
> are you refering to 'administrator' priviled accounts?

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.

> Samba scales very nicely too.

yeah.

> }i think you will find that in order to support even just a PDC properly
> }you will need a get/add/mod - even if it means at the first stage passing
> }the hashes in the clear (and trusting your users) for at _least_ the 16
> }byte LM and 16 byte NT hashes, as well as the rest of the account
> }information.
> }
> i will have to think this one out, in the mean time, if from the NT
> side one cannot add users, change password then my version of PDC
> would work? (and ignore BPC for now)

ignoring BDC for now: still if you have:

- no add users from samba but a manual add users system then you're ok.  a
pain, but ok.

- 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...

luke