1153
社区成员
- 全部
vista下如何从System的帐户获得当前登录的是帐号
因为需要从服务那里弹出一个窗体，所以在vista下面用CreateProcessAsUser把这个窗体所在的程序B弹出来，经过大量的查证，Vista下，虽然以CreateProcessAsUser创建了用户进程，比如说当前的登录帐户是A，进程管理器里面的用户也是A，但是事实上这个程序B所用的用户还是System.
但是我想在我的程序里面可以很快地让用户找到当前用户的桌面文件夹等。发现用 SHGetSpecialFolderLocation(0, CSIDL_APPDATA, pidl);
SHGetPathFromIDList(pidl, appPath);
获取到路径是空，所以只好用拼字串的方式来实现。
现在我的问题是如何在这个程序B里面获取到当前便当的帐户名？
但是我想在我的程序里面可以很快地让用户找到当前用户的桌面文件夹等。发现用 SHGetSpecialFolderLocation(0, CSIDL_APPDATA, pidl);
SHGetPathFromIDList(pidl, appPath);
获取到路径是空，所以只好用拼字串的方式来实现。
现在我的问题是如何在这个程序B里面获取到当前便当的帐户名？
...全文
当前发帖距今超过3年，不再开放新的回复
发表回复
chinahuman 2008-05-04
结贴，自己搞定了，加一个CreateEnvironmentBlock就可以了
meiZiNick 2008-05-01
好像没那么简单,呵呵.
knowledge_Is_Life 2008-04-30
有问题请先GOOGLE,BAIDU
蒋晟 2008-04-30
In Vista, the session 0 is not the "console session" anymore. Session 0 is reserved for services and the first console user gets session 1.
WTSGetActiveConsoleSessionId should always give you the correct console
session id at the time of the call. On win2k and nt4 tse, you can safely
assume that 0 is always the active console session id, otherwise you should
use WTSGetActiveConsoleSessionId.
CreateProcessAsUser will work in XP or later if you duplicate the token
returned by WTSQueryUserToken into another primary token via
DuplicateTokenEx(...TokenPrimary...) (only one process can be assigned to a
particular token as its primary token). Remember that you need to have
SeTcbPrivilege enabled to use WTSQueryUserToken.
The defining factor in determining which session a process appears in is the
session id in the primary token for the process. This can be accessed and
set via Get/SetTokenInformation(...TokenSessionId...). The token returned
by WTSQueryUserToken should have the same session id and authentication id
as the `interactive user' associated with the session in question. In other
words, it should relate to the token created by the winlogon instance in the
remote session when that user was logged on (and should be associated with
the same LSA logon session, i.e. it will have the same authentication id as
well).
You could also theoretically craft your own token (perhaps from LogonUser)
and set the right session id into it via
SetTokenInformation(...TokenSessionId..) (requires SeTcbPrivilege), and that
token would work for CreateProcessAsUser as well. If you just call
LogonUser, though, it will have a different associated LSA logon session -
authentication id - as the token for the `interactive user' associated with
the target session, which means that it will behave like a process started
via runas on that session. In other words, going that route would probably
break access to the remote user's network shares created under the original
LSA logon session that was created by winlogon.
--
Ken Johnson (Skywing)
Windows SDK MVP
WTSGetActiveConsoleSessionId should always give you the correct console
session id at the time of the call. On win2k and nt4 tse, you can safely
assume that 0 is always the active console session id, otherwise you should
use WTSGetActiveConsoleSessionId.
CreateProcessAsUser will work in XP or later if you duplicate the token
returned by WTSQueryUserToken into another primary token via
DuplicateTokenEx(...TokenPrimary...) (only one process can be assigned to a
particular token as its primary token). Remember that you need to have
SeTcbPrivilege enabled to use WTSQueryUserToken.
The defining factor in determining which session a process appears in is the
session id in the primary token for the process. This can be accessed and
set via Get/SetTokenInformation(...TokenSessionId...). The token returned
by WTSQueryUserToken should have the same session id and authentication id
as the `interactive user' associated with the session in question. In other
words, it should relate to the token created by the winlogon instance in the
remote session when that user was logged on (and should be associated with
the same LSA logon session, i.e. it will have the same authentication id as
well).
You could also theoretically craft your own token (perhaps from LogonUser)
and set the right session id into it via
SetTokenInformation(...TokenSessionId..) (requires SeTcbPrivilege), and that
token would work for CreateProcessAsUser as well. If you just call
LogonUser, though, it will have a different associated LSA logon session -
authentication id - as the token for the `interactive user' associated with
the target session, which means that it will behave like a process started
via runas on that session. In other words, going that route would probably
break access to the remote user's network shares created under the original
LSA logon session that was created by winlogon.
--
Ken Johnson (Skywing)
Windows SDK MVP
蒋晟 2008-04-29
http://blogs.msdn.com/ts/archive/2006/11/27/console-behavior-differences-in-longhorn-server-terminal-services.aspx
chinahuman 2008-04-29
楼上的，只是解说了问题的根源，但是并有提出解决办法呀？
