Migrating from LogonUser to SSPI
- From: "navels" <navels@xxxxxxxxx>
- Date: 13 Sep 2006 20:33:05 -0700
I am maintaining a C++ client/server app for distributed computing.
The client connects to the server over TCP/IP and requests and runs a
job. The job executable resides on the server in a shared folder. The
job writes its output to that same folder.
In the past, the client would run under the LocalSystem account and we
would have to configure the shared folder on the server for access from
null sessions so the client could access it. More recently, the server
shared folder is owned by a dedicated account, whose login information
(user name, domain, and password, encrypted) are passed to the client
when a job is requested. The client then does:
1. LogonUser (with LOGON32_LOGON_NETWORK_CLEARTEXT)
2. ImpersonateLoggedOnUser (to access the job executable)
3. CreateProcessAsUser
4. RevertToSelf
There are clearly some problems with this approach. For one, the
server has to have the password of the account that owns the shared
folder. It would be more desirable for the server to
1. Get the credentials of the shared folder account, and
2. Pass them to the client over TCP/IP for impersonation/process
creation.
Unfortunately this KB article, http://support.microsoft.com/kb/180548/,
says
"The end result of using the SSPI services to validate the credentials
is a logon that is analogous to calling the LogonUser API with the
LOGON32_LOGON_NETWORK logon type. The biggest downside to this type of
logon is that you cannot access remote network resources after
impersonating a network type logon."
So my question is . . . is there a way to use SSPI that will allow the
client to access a shared folder on the server? If so, I'd appreciate
a rough sketch of how to approach this, analogous to the steps 1-4
above. (I am totally new to SSPI...)
Thanks,
Lee
.
- Follow-Ups:
- Re: Migrating from LogonUser to SSPI
- From: Alun Jones [MS-MVP - Windows Security]
- Re: Migrating from LogonUser to SSPI
- Prev by Date: Determine unique user in non-domain win2000/xp/win2003
- Next by Date: Re: Changing Integrity Level
- Previous by thread: Determine unique user in non-domain win2000/xp/win2003
- Next by thread: Re: Migrating from LogonUser to SSPI
- Index(es):
Relevant Pages
|