Re: Logging, Login API and SSPI

Hi Will.

Thank you for your comments.

Regarding your answer to SSPI.

-----> FWIW: SSPI doesn't require elevated privileges. LogonUser() requires
-----> SE_TCB_NAME privilege on platforms older than XP.

I experimented within SSPI.
Apparently SSPI will allow you to impersonate for credentials validation but
would not allow resource access if you do not have SE_TCB_NAME.

The following is excerpt from
MSDN(http://msdn2.microsoft.com/en-us/library/aa375497.aspx):
"All impersonate functions, including ImpersonateSecurityContext allow the
requested impersonation if one of the following is true:

a.. The requested impersonation level of the token is less than
SecurityImpersonation, such as SecurityIdentification or SecurityAnonymous.
b.. The caller has the SeImpersonatePrivilege privilege.
c.. A process (or another process in the caller's logon session) created
the token using explicit credentials through LogonUser or LsaLogonUser
function.
d.. The authenticated identity is same as the caller.
"

When we use SSPI from a user without SE_TCB_NAME, impersonation works but
the token level is valid for credential validation only.

If we call GetTokenInformation on the impersonation handle specifying
SECURITY_IMPERSONATION_LEVEL the result is:

"SecurityIdentification
The server process can obtain information about the client, such as security
identifiers and privileges, but it cannot impersonate the client. This is
useful for servers that export their own objects, for example, database
products that export tables and views. Using the retrieved client-security
information, the server can make access-validation decisions without being
able to use other services that are using the client's security context."


"William DePalo [MVP VC++]" <willd.no.spam@xxxxxxxx> wrote in message
news:O6OlCHCQHHA.4492@xxxxxxxxxxxxxxxxxxxxxxx
"James V" <jamesv123@xxxxxxxxxxx> wrote in message
news:u%23csy5$PHHA.3960@xxxxxxxxxxxxxxxxxxxxxxx
I am trying to add logging capabilities to a Windows(2000/XP/2003)
application that can run under any user context(not neceseraly a member
of admin).

The problem is that every time a diffrent user will run the application,
the log files would be created/written under his credentials.

Some users can have limited permissions and not allowed to access various
parts of the file system. Further more, if a limited user created/written
a/to file he has permissions to view and change it and I do not want
limited users to be able to view modify the log files.

The standard way to deal with a set of requirements such as yours would be
to split the application into two pieces. One, a service installed and run
under the local system account. Two, an interactive aplication which runs
under the current logged on user. Then what you do is use an impersonable
mechanism (a pipe works nicely) to communicate requests from the
interactive application to the service. When required, the service can use
ImpersonateNamedPipeClient() to "do stuff" as the user making a request,
and when not impersonating it "does stuff" under the local system acccount
which has free reign over local resources such as the log you speak of.

I could create a logging service that uses IPC to connect to the server
application and manage the loging for it, but it seems like an overkill.

Not at all.

I considered using a special user account that would be impersonated by
our application(using login API and SSPI ) and would do the actual log
file manipulation, but the problem is that login API and SSPI can
require certain privilged user permissions (SE_TCB_NAME ) for the
impersonation to work properly (The impersonation level does not allow
resource access).

FWIW: SSPI doesn't require elevated privileges. LogonUser() requires
SE_TCB_NAME privilege on platforms older than XP.

Regards,
Will

www.ivrforbeginners.com





.

Relevant Pages

  • Re: Logging, Login API and SSPI
    ... the log files would be created/written under his credentials. ... but the problem is that login API and SSPI can require ... work properly (The impersonation level does not allow resource access). ... SSPI doesn't require elevated privileges. ...
    (microsoft.public.win32.programmer.kernel)
  • XP SP2, SSPI, Bad Impersonation level Error
    ... password which allowed me to use SSPI to impersonate the admin user ... Since installing XP SP2, the SSPI impersonation code works the same ...
    (microsoft.public.platformsdk.security)
Loading