dce/rpc "client" api
Luke Kenneth Casson Leighton
lkcl at samba.org
Fri Aug 25 04:41:05 GMT 2000
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
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
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.
More information about the samba-technical