Prev: HandlerEx and SERVICE_CONTROL_PRESHUTDOWN
Next: How to use __readmsr(int address) to get MSR of CPU
From: Chad Blomquist on 13 Dec 2006 11:14
System configuration:
remote system is running Windows XP Pro, SP2
custom-built GINA
running the Remote Desktop Connection application from a different Windows
XP Pro SP2 system.

I am in the process of writing a custom GINA. It seems to work well for
logging into a local system, but Remote Desktop logon attempts fail in a
strange way -- It seems that the actual session running on the remote
system's local terminal is captured upon successful authentication. If the
remote system is logged out, after logging in remotely you the logon dialog
is displayed. If the remote system was already logged in, the remote session
is. And the remote system's screen blanks and user input from the keyboard
or mouse seem to do nothing.

After some web searching, some others had a similar problem and the proposed
solution was to properly populate the WLX_CONSOLESWITCH_CREDENTIALS_INFO_V1_0
object with the appropriate credential information inside the
WlxGetConsoleSwitchCredentials API function.

I have 2 questions. First, where do you get the information with which you
populate, and are all fields required? Second, for the sake of my own
curiosity, why does improperly populated object cause the Remote connection
to steal the local session?


From: "Jeffrey Tan[MSFT]" on 13 Dec 2006 22:27
Hi Nick,

Windows XP and remote desktop is known as Single User Terminal Server, the
behavior of MSGINA is slightly different from when a user physically logs
onto a console session.

When you logon to an XP machine via remote desktop, the logon initially
happens in a dummy session. The user will type in their credentials and
WlxLoggedOutSAS()
will be called. At this point, the function
WlxGetConsoleSwitchCredentials() will be called and the information typed
by the user in the remote session will be used to fill in the
WLX_CONSOLESWITCH_CREDENTIALS_INFO_V1_0 structure. After this happens, the
WlxLoggedOutSAS() in the console session, different Winlogon/MSGINA
(from the remote session) will be called and the logon type returned by
WlxLoggedOutSAS() will be WLX_SAS_TYPE_AUTHENTICATED. The console session
will
then call the function QuerySwitchConsoleCredentials() to obtain the
authentication information that was type by the remote session user. The
console session MSGINA
will use this information to do an autologon. If the logon succeeds, it
will redirect the console session to the remote session and the MSGINA that
is running is the console session one and NOT the remote/dummy session.

You need to detect the WLX_SAS_TYPE_AUTHENTICATED and when you receive
this, you know the logon was done via a remote session and do everything
from the console session MSGINA and NOT from the dummy session. You
shouldn't collect password in this case, since MSGINA calls the function
QuerySwitchConsoleCredentials() to obtain the authentication information
installed of passing it to WlxLoggedOutSAS. In the dummy session when
WlxLoggedOutSAS() is called which is going to be called before the
WlxLoggedOutSAS() in the console session, you should call
GetSystemMetrics() with SM_REMOTESESSION, if you are in a remote session
you should ignore this and wait for the WlxLoggedOutSAS() in the console
session which returns a logon type of WLX_SAS_TYPE_AUTHENTICATED.

My colleague Rhett Gong [MSFT] provided a sample code regarding filling
WLX_CONSOLESWITCH_CREDENTIALS_INFO_V1_0 in the link below:
http://groups.google.com/group/microsoft.public.platformsdk.security/msg/987
586cbf6161a23

Does it meets your need?

If you need any further help, please feel free to tell me, thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.



From: "Jeffrey Tan[MSFT]" on 17 Dec 2006 23:05
Hi Chad,

Have you reviewed my reply? Does it make sense to you? If you still have
any concern or need any help, please feel free to tell me, thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

From: Chad Blomquist on 8 Jan 2007 18:56
Thanks for the initial response. Sorry for not getting back to you. The day
after posted the original question, my focus was diverted to a more pressing
need, and I have only just found my way back here.

I have verified that the LoggedOutSAS handler is being called twice. The
first time, it gathers the user's infomation and authenticates them. Then it
is called again with WLX_SAS_TYPE_AUTHENTICATED. On this 2nd attempt, my
handler calls wlxQueryConsoleSwitchCredentials, but the resultant
WLX_CONSOLESWITCH_CREDENTIALS_INFO_V1_0 structure is not properly populated.
For Example, the token and profile path are both NULL.

It is my belief that my GetConsoleSwitchCredentials is the problem. Rhett
Gong's code certainly populates the structure. My problem is, where does
that information come from? His GINA class seems to have a member called
pLogonNT that contains all of the right information... but where did that
object come from?

thanks.
From: "Jeffrey Tan[MSFT]" on 9 Jan 2007 05:01
Hi Chad,

Customizing Gina is not a simple task and it is not very efficient to be
supported in newsgroup.

I recommend you contact the Microsoft PSS for a case support for this
issue. You can contact Microsoft Product Support by contacting us at
1-(800)936-5800 or by choosing one of the options listed at
http://www.microsoft.com/services/microsoftservices/supp.mspx

Thanks for your understanding.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

 | 
Pages: 1
Prev: HandlerEx and SERVICE_CONTROL_PRESHUTDOWN
Next: How to use __readmsr(int address) to get MSR of CPU