password API

[Luke Kenneth Casson Leighton]

On Thu, 28 May 1998, Danny Braniss wrote:

> In message <Pine.LNX.3.96.980528141415.5978P-100000 at regent.cb1.com>you write:
> i didn't send diffs because the changes where too big,

big diffs are preferential to files: they tell you *exactly* what's been
modified.  this is more important than the size of the diff itself
compared to the files themselves.


> and not realy final,

don't worry about that :-)

> and was/am waiting for comments. there is a piece of code that i
> think wont be liked by some compileres for example
> 
> }danny,
> }
> }looked at huji.c: your huji_getpwnam() function calls getpwnam() and then
> }does a unix2smb() conversion.
> }
> }1) if you do this, the structure returned will not have an NT or LM 16
> }byte hash.  the minimum requirements of the password API is to supply NT
> }LM hashes for unix users.
> }
> }2) it is not the password database's job to deal with the UNIX world: its
> }job is to deal with the NT world.  the verification checks to ensure that
> }the UNIX username exists for any given NT username are done in password.c.
> }
> }for both these reasons, the calls to getpwnam() and getpwuid() should be
> }removed, and you should always look for and return the struct smb_passwd
> }or struct sam_passwd.
> }
> }also, you create rather than store the NT hash.  for reasons previously
> }explained, the NT and LM hashes need to be stored in your authentication
> }database.
> }
> }for now, given that i deduce that a lot of your clients are using
> }clear-text unix passwords (encrypt passwords = no) i think you could get
> }away with _not_ having any encrypted communication of the clear-text
> }equivalent NT and LM hashes between samba and your authentication
> }database: you will have exactly the same security risks, which i
> }understand that you have already accepted.
> }
> no, i use regular nt hashed passwords (no clear text). 
> btw, wev'e been through this before, in my case im not interested in a
> BDC, and though am concidering allowing some administrativia to be
> done via nt/samba i still need to do some thinking about this.
> 
> as to 1) & 2):
> i need some more NT insight, as i mentioned in prev. exchanges, i
> could modify my auth-server to supply this info, but i would rather
> not. are the NT/LM hashes used for something else than logon/login and
> BDC?

yes: trust accounts.  if you provide NT LM hashes, you will be able to
have NT workstations as a member of a samba domain with your password
database.  if you do not, you will not (or will have to fudge it in an
insecure way: maintain the default trust account password, which will mean
that your network passwords can be reverse-rc4'd).
 
> }the rest of the stub / conversion functions look fine: i conclude that you
> }are going for a struct smb_passwd system for now, not a struct sam_passwd
> }one?
> }
> 
> my main first efford, was to figure out the code, hence the small
> re-structuring,

ok.

> i have to figure out why there is a smb & sam
> structures.

that's no great deal: this one's been discussed (sort of) and is in the
archives. struct sam_passwd is info supplied to the NT-side (srv_samr.c).
when you don't quite need as much info as that, use the struct smb_passwd
functions.

if you don't want to support struct sam_passwd, the pdb_smb_to_sam
conversion routine fills in "blanks".  later, it is expected to fill in
"defaults" instead.

it is therefore better, but not necessary, to support all the struct
sam_passwd fields in any given password database

luke