How can I get the logon script to be executed while having a custom GINA replacement? [updated]
- From: "Bernard Bastien" <labcaldev@xxxxxxxxxxxxxxxx>
- Date: Fri, 25 Nov 2005 14:23:14 -0500
I never realized that the managed groups were here. Here I am again with
the correct account.
I am working on a biometric SSO solution that offers the option to
interactively logon to Windows using biometric input. Naturally, this
requires the replacement of GINA by our own customized version, which must
be a full-featured replacement, not a hook or a stub over the MSGINA
component.
Things are running quite well with our "home-made" component, except for one
thing: I can't have the login script to be executed when a user logs in
using our GINA. This login script is set by the system administrator at the
domain level, and is a VBS-based script, and it is well done when returning
to plain MSGINA configuration.
It seems that the USERINIT.EXE program should have done it but is unable to
do so. The "pszMprLogonScript" argument to the "WlxActivateUserShell" is
empty, even if calls to "LsaLogonUser" or "NetUserGetInfo" are giving me the
name of the script to be executed. Is the fact that Winlogon can't give me
that info is related to the same situation than UserInit not starting the
script?
I have searched throughout the web for days and got very little info about
that. I know that I am not alone who encountered that problem but answers
have not made their way up to the web and newsgroups. A similar thread in
this group here, six years ago, got me some parts of the answer. Richard
Ward, I think he worked on Winloon, made a reply that stated that:
"the GINA returns the profile information, including where to load the
profile from, in the return from WlxLoggedOuSAS. In between that return and
the call to WlxActivateUserShell, winlogon will do all the grunt work." and
"The GINA is responsible for setting the LOGON_SERVER environment variable,
and any other variables specific to the logon, this too can be sent up to
winlogon in the profile structure."
Using this knowledge, I started a brand new project using the source code
published by Keith Brown in a pair of articles in MSDN magazine of last
spring ("Customizing GINA"). When compiled as is, that GINA replacement
has the same problem of not running the logon scripts. Then I tried to add
data to the "ppWinLogonProfile" output structure in the "LoggedOutSAS"
method, using info from the LsaLogonUser, and even hardcoded stuff, just to
make it work, but never succeded. I even tried to copy hardcoded values
over the
environment table, like this:
wchar_t* EnvTable =
L"ALLUSERSPROFILE=C:\\Documents and Settings\\All Users\x0000"
L"APPDATA=C:\\Documents and Settings\\bbastien\\Application Data\x0000"
...
L"HOMEDRIVE=C:\x0000"
L"HOMEPATH=\\Documents and Settings\\bbastien\x0000"
L"LOGONSERVER=\\\\SRV6\x0000"
L"LOGONSCRIPT=ShowMessage.vbs\x0000"
...
LPVOID pEnvironment;
CreateEnvironmentBlock(&pEnvironment, _hToken, TRUE);
memcpy(pEnvironment, EnvTable, sizeof(EnvTable));
((WLX_PROFILE_V2_0*)*ppWinLogonProfile)->pszEnvironment =
(PWSTR)pEnvironment;
But the environment variables I added (such as LOGONSERVER or USERNAME)
disappeared when looking at the environment table in a logged-on session.
Almost the same thing happened when replacing the environment table just
before starting USERINIT, some values are not there when looking at the
table afterwards.
What I have understood from the messages and docs I have read, I think I can
rely on Winlogon to load the user profile, and on UserInit to run the login
script, without programming myself the loading of user profile in
LoggedOutSAS (which seems to be quite tricky) or the execution of scripts in
WlxActivateUserShell. But there is a trick that I did not catch.
So, to summarize it, using the "fullgina" sample code from the MSDN article,
what is missing to make it run the login scripts like when using MSGINA?
Thank you for any help,
Bernard
.
- Prev by Date: RE: Help disabling a device using SetupDiXXX fns after WM_DEVICECHANGE
- Next by Date: Re: Access HKEY_LOCAL_MACHINE Registry Key from non-Administrator'
- Previous by thread: Help disabling a device using SetupDiXXX fns after WM_DEVICECHANGE
- Next by thread: Creatng 100% separate process from Parent
- Index(es):
Relevant Pages
|
