views:

256

answers:

1

I am designing a Service to run under LocalSystem account on Win2000, XP and Vista. It will need access to users registry hives, sometimes for extended periods of time, both when the users are logged-in, and also, when they are not logged-in (IF the profile is local. If the profile is Roaming and not loaded, I will not attempt to load it.)

If the user is logged-on, I can get the Users access token by various means (E.g. from its Explorer process, or by receiving Logon events from the Service Control Manager) then use ImpersonateLoggedOnUser and RegOpenCurrentUser to access the User's hive. However, what are the implications if the User selects LogOff from the start menu while I am impersonating and have his hive open? Will the logoff be prevented? Will my impersonation be terminated?

If the user is not logged on, I can use RegLoadKey to directly open the hive NTUSER.DAT. (Impossible for a logged-on user). But what are the implications of this if the user decides to log-on (I suppose the hive will be locked and the logon either prevented, or may experience difficulty?)

I will be setting up some test projects to explore these ideas however, regardless of their apparent results, these questions are theoretical in terms of what type of problems might, or would, be caused by the user loggin in/out during these actions by the service.

Caveat: ImpersonateLoggedOnUser can ONLY be used either for a logged-on user (token obtained from process or SCM event) OR for a user for which I have the plaintext password to call WinLogon and obtain a token - TRUE / FALSE ? In other words although I have maximum permissions as LocalSystem and am able to change the user's password or even delete the user's account, if the user is not logged-on, it is totally impossible to create a new token to impersonate the user without having the the password?

A: 

Apparently, there is some risk of damaging a user's profile if it is already loaded by another process when the user logs in. In that case, the system will try to create a new subdirectory for the user. (I haven't tested this scenario, but this thread makes a compelling case for it.)