Get registry settings for a specific user

[Ian MacDonald]

We have an application that is running in the SYSTEM security context.
We figured out how to spawn a new process on behalf of the current user
but one nagging question remains. How do you get the HKEY_CURRENT_USER
info for the current logged in user. We know that the user info is
stored in HKEY_USER\{SID}. But which SID is used? And what is the
proper way to get it? How is this affected when the user logs onto a
domain versus logging on locally?

Thanks in advance,

-- Ian MacDonald

[Felix Kasza [MVP]]

Ian,

> How do you get the HKEY_CURRENT_USER info for the
> current logged in user.

Welcome. You just opened a can of worms.

First, the good news: On NT5, you just call LoadUserProfile(). Now for
the hard part.

> We know that the user info is stored in HKEY_USER\{SID}.
> But which SID is used?

The SID for the user in question, converted to text, in canonical form.
Both the Platform SDK docs and the KB have sample routines which do
that.

> And what is the proper way to get it?

The SID? Easy. You know which user you log on, no? Just call
LookupAccountName().

The profile? Ugh. There are several places, and the search order is
influenced by the presence (or absence) of NT4-style policies, by the
user's roaming- or non-roaming status, and so on. In principle, you get
the user's profile directory and look for a ntuser.dat file. (Yes, the
name varies with the profile type.) Do a RegLoadKey() on it, and you are
all set.

Unfortunately, the only place where you can get all the necessary info
under NT4 (without having to guess that is) is a GINA.

> How is this affected when the user logs onto a
> domain versus logging on locally?

Badly: Roaming profiles, policies, the whole shebang. A real headache.

--

Cheers,

Felix.

If you post a reply, kindly refrain from emailing it, too.
Note to spammers: fel...@mvps.org is my real email address.
No anti-spam address here. Just one comment: IN YOUR FACE!

[Ian MacDonald]

Hi Felix,

In article <367e3ce2....@207.68.144.15>, fel...@mvps.org says...

> The SID? Easy. You know which user you log on, no? Just call
> LookupAccountName().
>
> The profile? Ugh. There are several places, and the search order is
> influenced by the presence (or absence) of NT4-style policies, by the
> user's roaming- or non-roaming status, and so on. In principle, you get
> the user's profile directory and look for a ntuser.dat file. (Yes, the
> name varies with the profile type.) Do a RegLoadKey() on it, and you are
> all set.
>

Since _we_ are assuming the user is already logged on (our process would
not get control otherwise), we are also assuming that the user's profile
had been also loaded.

Getting the SID: When we call LookupAccountName() we need to supply the
machine name to lookup the account on. How can we tell if the user has
logged on to a domain versus logging on locally? Is the USERDOMAIN
environment variable a reliable way to do this?

Thanks again for your help,

-- Ian

[Felix Kasza [MVP]]

Ian,

> we are also assuming that the user's profile
> had been also loaded.

Good on you! Note, btw, that newer NTs (like the NTS 5.0b2 I am typing
this on) actually publish _two_ keys under HKEY_USERS -- one is the
expected HKU\{SID}, the other one is HKU\{SID}_Classes. If I understood
you correctly, this won't bother you, will it?

> Getting the SID: When we call LookupAccountName() we need to supply the
> machine name to lookup the account on. How can we tell if the user has
> logged on to a domain versus logging on locally?

This is a don't-care. You can always use the local machine (since if the
local box can't validate the user, he wouldn't be logged on); if you
worry about name collisions between the local account domain and the
DC's domain, use the syntax DOMAIN\username to disambiguate (LOCAL\user
is unnecessary, as local resolution is tried first anyway).

One thing about getting the SID -- I just reread the thread, and if I
read you right, you either gain access to an existing token for the
user, or you build a new one, correct? In that case, you might as well
use GetTokenInformation( TokenUser ) against the token, which will give
you the desired SID without further ado.