dce/rpc "client" api

[Luke Kenneth Casson Leighton]

On Thu, 24 Aug 2000, Elrond wrote:

> On Thu, Aug 24, 2000 at 02:05:43PM +1000, Luke Kenneth Casson Leighton wrote:
> [...]
> > > USER_3 isn't the only struct, that is associated with a
> > > user in TNG, USER_3 is part of a samba-specific struct,
> > 
> > no, it comes straight off-the-wire from the NetrSamLogon response.
> 
> Wait a sec? Look at parse_vuid.c and the user_struct, don't
> you store that in the credential-db and retrieve it from
> there, when you need the credentials for a vuid?

yep, that as well.

the data comes from the PDC at NetrSamLogon time [it's the user profile].
it goes either on loop-back or over-the-wire - basically to the Domain
Client - and gets "associated" - cached - with the VUID.

[side note: when an api_NetWkstaUserInfo call is made [by a win9x system],
the vuid is looked up to obtain the cached info.

jeremy seems to have missed the point i was making that 2.0.x "fakes" up
this info, whereas TNG returns [most of!] the correct / required
parameters.]

additionally, the NET_USER_INFO_3 structure contains *critical* data - the
"User Session Key", without which you cannot run USRMGR.EXE
(SamrQueryUserInfo and SamrSetUserInfo require the usrsesskey to decrypt /
encrypt the user's password).

the issue of storing it in a credential-db is so that on the _other_ side
of a unix domain socket, i.e. it can be picked up by a
forked-msrpc-daemon.

i do not like this particular implementation: i prefer revision 2, where
the user_struct, including the NET_USER_INFO_3 structure, was shipped
over-the-socket immediately after the socket was opened.
 
> > > that is associated with the VUID. 
> 
> Where this creds-db being the "association-storage".

yep.  which as i said i don't like.