• Still running Windows 7 or earlier? Support for Windows 7 ended on January 14th 2020. Please review the thread here for more details.

fast user switching

Temmu

Temmu

Well-known member
Joined
Apr 18, 2012
Posts
436
Location
far reaches of the galaxy, but you knew that...
greets!

knowing that ms got rid of "gina" when it created vista, and now vista, 7 & 8 use a new way:
logonui.exe loads authui.dll, the credential provider (others possible.)

when one disables fast user switching, microsoft's words are "remove entry points" - which, of course, does not disable fast user switching, because that would disable logon.

is there a microsoft msdn or technet or kb article that links all that together?

thanks!
 
Hello!

I am slightly confused as to what you are trying to achieve, so please forgive me answering your question with another question.

From what I can see, fast user switching is now enabled/disabled using HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System:HideFastUserSwitching (HKCU for per-user control).

Presumably, explorer.exe/whatever makes a conditional check against this value when building the Start Menu, and probably a second check in whatever function actually performs the work, if it's publically accessible. Then there need be no changes in authui.dll/wherever, as excluded users can only logoff.

Is this what you're after, or am I way off?

Richard
 
For the lost hardware guy here, please specify exact Windows version we are talking about. I am using 8.1 and there is no "HideFastUserSwitching" entry in my Registry. That may be because I am the only user - I don't know.

This BC article suggests a user must manually create that entry.
 
thx, niemiro & digerati, but no.

this concept applies to any of vista 7 or 8.

i want a microsoft-authored explanation of logon + fast user switching demonstrating that you can only disable the entry points (like, switch user button) for fast user switching, but cannot disable fast user switching itself because logonui.exe can call any number of credential providers, like authui.dll

maybe i should ask in the programming section??
 
Temmu said:
thx, niemiro & digerati, but no.

this concept applies to any of vista 7 or 8.

i want a microsoft-authored explanation of logon + fast user switching demonstrating that you can only disable the entry points (like, switch user button) for fast user switching, but cannot disable fast user switching itself because logonui.exe can call any number of credential providers, like authui.dll

maybe i should ask in the programming section??
Click to expand...

Are you sure this isn't an X-Y problem? Please, what exactly are you trying to achieve exactly?

Let's assume for a moment that all entry points are disabled in a bullet proof manner, does it really matter whether the non-reachable code is there or not? With any level of disabling, there's a conditional somewhere, and code before that runs, code after that doesn't. Where you draw the mark is arbitrary, provided it's before the critical code runs, whether or not you remove the 'after' code is irrelevant provided that the disabling of all entry points is bullet proof.

So, are you worried that the disabling of entry points is not bullet proof? Or are you concerned that alternate credentials providers can bypass the entry point restrictions? Consult with "Credential Provider Technical Reference" available here: Shell:Revealed - Release: ShellRevealed Code Samples.

I can see no function or interface which allows credentials providers to initiate a fast user switch. That conclusion is repeated here, in the comments of this non-Microsoft source: Executing a Fast User Switch programmatically - part 2 - Remko Weijnen's Blog (Remko's Blog)

In Vista msgina support was dropped; and current credential providers just do not support Fast User Switching. You can simulate the behaviour of “Switch User” button by just executing WTSDisconnectSession(WTS_CURRENT_SERVER_HANDLE, WTS_CURRENT_SESSION, True);
Click to expand...

Of course, a disconnect is not exactly equal to a fast user switch, just very similar.

So, what's your *actual* problem. Please, you've accepted that you don't know the answer here (which is absolutely what a forum is for, I myself have asked many questions where I do not know the answer and there is absolutely no shame), but please don't also think that by necessity we can't help you better by knowing what you're trying to achieve, just not what you're trying now. Please also don't post in the programming section yet, I can call the appropriate people to this thread if it becomes necessary.

Richard
 
Temmu said:
there is no problem.
i am not trying to do anything.

i simply wish to demonstrate that removing the entry points does not disable fast user switching.
there are other ways to access an os besides the gui.
Click to expand...

I agree with/am aware of other ways of accessing system internals. Indeed, I am a programmer.

1: I have already provided you with strong evidence that credentials providers cannot initiate a fast user switch. If you are worried about credentials providers bypassing the start menu, you don't need to be.
2: I have also provided you with evidence that there exist no publicly exposed API functions or interfaces which provide this functionality.
3: Therefore we must presume that explorer.exe uses an internally exposed function. I have performed some basic analysis on explorer.exe, shell32.dll, shlwapi.dll and authui.dll on a Windows 7 computer, and have found absolutely no named (by the public symbol server) function which appears to offer this functionality.

If you want to investigate further exactly how it's done, look at

Code: 
CLogoffPane::_OnCreate
CLogoffPane::_InitShutdownObjects

in shlwapi.dll, to see if you can track down the callback function.

Also, Microsoft's track record on security is very good, and the quality of the code is allegedly excellent. If all checks were carried out at explorer.exe level, it would be far too easy to forget to go back and add in extra checks if an internal function is ever documented/made public --> security risk. Also, it's never a good way of handling security ("on the client"), so I'm sure it's almost never done.

Finally, if you're concerned about malicious users modifying Windows code, or directly invoking internal functions then all bets are off, and you've got much bigger issues than fast user switching?

I don't buy that there's no problem at all. I'm sure that there's nothing which needs fixing, but a question like this doesn't come out of nowhere. Are you concerned about security? If so, why?

Richard
 
In Group Policy (Server 2008 R2, for Win 7 machines), Computer Configuration, Polices, Administrative Templates, System, Logon, the setting for "Hide entry points for Fast user Switching" - its explanatory text is "By enabling the policy, Administrators hide the Switch user button in the Logon UI, the Start menu and the Task Manager."

Please note the word is "hide" stuff in the GUI, not "disable" this that or the other.
This Windows Administration: Inside the Windows Vista Kernel: Part 2 near the bottom, the "credential providers" paragraph states logonuil.exe is what loads credential providers (maybe several, if you write them.)
And as I was researching that Group Policy, I read either a MS KB or Technet article that clearly stated that the service responsible for FUS cannot be disabled because it was responsible for the login process (in stark contrast to XP.)

All I am trying to do is find that article.
I may have it bookmarked, but my stack is deep.
 

Has Sysnative Forums helped you? Please consider donating to help us support the site!

Back
Top