Re: password API needed

Luke Kenneth Casson Leighton (lkcl@cb1.com)
Tue, 12 May 1998 11:37:47 +0000 (GMT)

Date:	Tue, 12 May 1998 11:37:47 +0000 (GMT)
From:	Luke Kenneth Casson Leighton <lkcl@cb1.com>
To:	Multiple recipients of list <samba-technical@samba.anu.edu.au>, Samba NT Domains Mailing List <samba-ntdom@samba.anu.edu.au>
Subject: Re: password API needed
In-Reply-To: <Pine.LNX.3.96.980511160226.207U-100000@regent.cb1.com>

ok, short (1/2 hour) brainstorm yesterday with jeremy came up with some
ideas on the password database system.

jeremy doesn't want any new fields added to struct smb_pass, particularly
those that will not be relevant to unix-side-only code (e.g "full name",
"workstations" etc).

this reflects NT's generation of "info levels", namely that you can obtain
frequently used important information (username / pass) in one structure,
and ask for larger and larger structures as the info level increases.

so, i created sam_passwd, which contains _all_ NT SAM fields, and left
smb_passwd alone.

now there are two database systems: private/smbpasswd (smbpass.c) and LDAP
(ldap.c) which are brought together in a single api (passdb.c). smbpass.c
only supports the fields listed in struct smb_passwd, of which there are
only 5 or so; ldap.c (as it is under development) will support all the
fields listed in struct sam_passwd.

so, in the spirit of leaving private/smbpasswd alone, and not extending
it, jeremy suggested creating a private/sampasswd file which contains all
the missing NT SAM fields.

not only that, but both jean-francois and jeremy also suggested that if
fields are missing (NULL) in either the private/sampasswd file or the LDAP
database, that the default option from smb.conf is read. currently, this
only means:

- lp_homedir()
- lp_logon_script()
- lp_profile_path()
- lp_homedrive()

now, this is where there is a slight amount of contention. i want(ed) to
add lp_workstations(); lp_logon_hours(); lp_kickoff_time();
lp_dialup_info() etc, and jeremy went "argh" and jean-francois went
"argh". jeremy went "argh" because he didn't want extraneous parameters,
and jean-francois went "argh" because i suggested doing
include=smb.conf.%U and putting "workstations = WKS1 WKS2 ..." in a
smb.conf.USERNAME file, but this was only as an example: you can also do
include=smb.conf.%G (where G is substituted for the user's group) or you
can use the NIS netgroup or whatever. jean-francois thought that i was
suggesting the creation of 2,000 smb.conf.USERNAME files: one per user.

_or_ you could do "workstations = %<x>" where %<x> is the substitution
parameter for a NIS netgroup of workstations (i think unfortunately,
though, that NT limits the number to 8 workstations: i'd be interested to
see what happens if you put more...)

i _still_ want to add the above-named parameters, particularly in light of
the fact that they will only be used as fall-back parameters when either
private/sampasswd or the LDAP database field for that parameter is blank.

also, i would like to see swat or some other config tool be able to
generate a full set of NT SAM fields in whatever password database is
used.

summary:

- create a private/sampasswd file to work alongside private/smbpasswd and
provide the full set of NT SAM fields

- a blank field in private/sampasswd or the LDAP database means "fall back
to a default value in smb.conf".

- add new smb.conf parameters to offer the above-mentioned "default value"
support for the full set of NT SAM fields.

- configuration tools to create private/sampasswd entries or LDAP database
entries _from_ the full set of SAM smb.conf options, so that those
parameters are effectively cached and accessed far quicker.

comments, anyone?