Hello,
Does anyone know if rdr.sys uses msv1_0.dll to do NTLM? If so, I’m guessing
that it would need to signal the user mode portion of the LSA (I think this
is lsass.exe) to do this on rdr.sys’s behalf. Does this sound right? Or can
rdr.sys do NTLM without a transition to a user mode process for help?
tia,
Marc
> Does anyone know if rdr.sys uses msv1_0.dll to do NTLM? If so, I’m
guessing
that it would need to signal the user mode portion of the LSA (I think
this
is lsass.exe) to do this on rdr.sys’s behalf. Does this sound right? Or
can
rdr.sys do NTLM without a transition to a user mode process for help?
IIRC rdr.sys calls ksecdd.sys for this work.
And ksecdd.sys (which is the same thing as ntlmssp.dll but in kmode) - calls
LSA (LsaCallAuthenticationPackage) to do the job.
Surely msv1_0.dll (in LSASS process) is the only thing in NT which keeps the
current user’s password hash.
Max
> IIRC rdr.sys calls ksecdd.sys for this work.
And ksecdd.sys (which is the same thing as ntlmssp.dll but in
kmode) - calls
LSA (LsaCallAuthenticationPackage) to do the job.
Surely msv1_0.dll (in LSASS process) is the only thing in NT
which keeps the
current user’s password hash.
If msv1_0.dll (in LSASS process) is the only thing in NT which keeps the
user’s password hash, then is it safe to assume that control ends up in
msv1_0.dll in *usermode*?.
Marc
> If msv1_0.dll (in LSASS process) is the only thing in NT which keeps the
user’s password hash, then is it safe to assume that control ends up in
msv1_0.dll in *usermode*?.
How the NT’s security subsystem works:
The kernel exports LsaCallAuthenticationPackage function (as the user mode
advapi32.dll).
Both functions assemble the LPC message and send it to the LSA’s port to be
processed by user mode LSA code.
ksecdd.sys uses LsaCallAuthenticationPackage (exported from the kernel) to
generate a valid NTLM response from the challenge based on the current
user’s or explicitly specified password. It’s user mode “twin” -
ntlmssps.dll - too (the one exported from advapi32.dll).
LsaCallAuthenticationPackage ends in some msv1_0 function call inside the
lsass process. msv1_0 looks to the credential cache maintained by LSA, finds
a current user’s password hash for this server (the same user could IIRC
specify several passwords for several servers - and one for the local NT
logon. The local password will be used if there no password for the
particular server) - and generates a response from the challenge.
The response then travels back to ksecdd or ntlmssps.
rdr.sys relies on ksecdd to generate NTLM responses necessary for SMB logon.
RPC (and thus DCOM) rely on ntlmssps.dll (NTLM Security Support Provider
service) to generate cryptographic BLOBs necessary for RPC/DCOM
authentication.
The only exception is RPC on top of named pipes - in this case, the RPC
security and ntlmssps are not used - and relies on the security provided by
SMB (named pipes are part of SMB) and the pipe impersonation ability.
DCOM uses RPC/UDP as a default. The NT’s tools like User Manager and Server
Manager - RPC/named pipes.
Surely, the same is correct on the server side - with the exception that
LsaLogonUser is used instead of LsaCallAuthenticationPackage.
LsaLogonUser results in msv1_0 logon function call. msv1_0 checks whether
this is a domain account. If yes - it handles the request to netlogon DLL to
pass it to DC and to obtain the user SID/group SIDs list from it. (note that
netlogon.dll caches the last successful domain logons in the local LSA
database - NL$Cache entries - to allow domain logons even if no DC is
accessible on the network. You know the “you was logged on using cached
password information” message which is displayed by WinLogon/GINA in this
case.
This feature is known to be unsecure - this is the ONLY circumstances when
the domain account’s password hash is stored permanently on the machine
which is not a DC - so, it is better to disable it if you trust your
network).
If no - it does the same using the local SAM database in the registry which
contains the password hashes.
Then msv1_0 returns the array of user SID/group SIDs to the lsasrv.dll, it
checks the local LSA/SAM database for the local group SIDs and privilege
sets, then calls NtCreateToken, then writes a 528 event (successful logon)
to the security log.
The token created by NtCreateToken is returned to the entity which called
LsaLogonUser. This entity (ksecdd.sys+srv.sys or ntlmssps.dll+RPC layer)
uses the token to impersonate it and thus execute server code on behalf of
the client’s user.
WinLogon/GINA also call LsaLogonUser to both user logon and workstation
unlock.
The kernel’s SRM invents a LUID for each NtCreateToken request and allocates
a structure called the “logon session” which contains this LUID and a
reference count.
This LUID is returned to the LSA as “logon session ID” and is used by LSA to
maintain the credentials cache associated with this logged-on user. Also
IIRC this LUID (which is accessible by the user mode code by
GetTokenInformation/TokenStatistics) - is used by the window manager to
assign ACLs to window station objects.
When the token is duplicated by NtDuplicateToken - the “logon session” is
addrefed.
When the token dies - the “logon session” is dereferenced.
If the logon session’s reference count have dropped to zero - the kernel’s
SRM calls the logon session termination callbacks registered by the
filesystems (rdr.sys uses it to drop the connection to the server) and then
sends an LPC message to the LSA’s port which forces LSA to write a 538 event
(user logoff) to the security log and to wipe the entries from the
credentials cache.
So, the 538 event is always caused by the token object death - which is
usually the death of the last process running under this token.
Theoretically, all of this could run unchanged on Terminal Server - though
there are possibly some additional complexities there.
Surely, w2k changed it greatly for Kerberos support. IIRC obtaining a
primary ticket replaced sending the logon attempt to the DC by the
netlogon.dll, obtaining a ticket for a particular server replaced the
response generation in LsaCallAuthenticationPackage, and checking the
client’s ticket for validity replaced the challenge/response pair-based
logon.
SMB protocol is extended to support Kerberos for logons too.
Max