#199692 - 2010-08-30 10:31 AM
Problem with login script on Windows 7 run as scheduled task
|
Sam_B
Getting the hang of it
Registered: 2005-10-25
Posts: 68
Loc: Bern, Switzerland
|
Hello all,
first of all, I don't think that I am the first person on this planet having the issue I'll describe below, I tried to search for solutions in the board, but was not clever enough to find it... Sorry for that.
My problem: we move to Windows 7 from XP and as you all know, the kix login script on windows 7 doesn't run with elevated right causing problems with our legacy scripts during some file operations that need admin rights on users workstation. We need to rework the complete login process in a way that such kind of operations won't needed in the near future, but as a workaround I'm searching for a solution to run the login script with elevated rights.
I found one: creating a scheduled tasks that triggers the login script at users logon, having the possibility to run the script with elevated rights a perfect solution! But it's causing me some headache...
The login script should run under the user account of the user currently login in. To be able to this in a generic way, I added a AD group as user account to run the script under. All my users are member of this group. And local admins on the workstations they're login. This means that each time any user that is member of this group logs on to the machine, the login script should run with admin rights.
I tested this and it worked great! Until i rebooted the machine... Then, the script wasn't fired anymore at login. I found an error in the task scheduler history: Task Scheduler failed to load tak "my Login" at service startup. Additional Data: Error Value 214744189.
When I remove the group and replace it by a dedicated user account and do tests with this configuration, everything seems to work. So the group seems to cause the issue with the task scheduler at startup of the machine.
Now my question: Do you know a way to schedule a login script with task scheduler and trigger it to run under the user account of the current user with elevated rights?
many thanks for your feedback!
|
Top
|
|
|
|
#199695 - 2010-08-30 03:36 PM
Re: Problem with login script on Windows 7 run as scheduled task
[Re: Glenn Barnas]
|
Sam_B
Getting the hang of it
Registered: 2005-10-25
Posts: 68
Loc: Bern, Switzerland
|
Hi Glenn,
many thanks for your post and the correction regaring the differen rights. I think I need to learn a lot regarding this... Will do that and also check the tcLib stuff
Regards
Samuel
|
Top
|
|
|
|
#199701 - 2010-08-31 12:19 PM
Re: Problem with login script on Windows 7 run as scheduled task
[Re: Arend_]
|
Arend_
MM club member
Registered: 2005-01-17
Posts: 1894
Loc: Hilversum, The Netherlands
|
Btw, if you are using the logonscript in the classic way, using Netlogon, please set this key prior to running the logonscript:
$=WriteValue("HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\EnableLinkedConnections","1","REG_DWORD")
|
Top
|
|
|
|
#199705 - 2010-08-31 02:46 PM
Re: Problem with login script on Windows 7 run as scheduled task
[Re: Arend_]
|
Allen
KiX Supporter
Registered: 2003-04-19
Posts: 4545
Loc: USA
|
Unfortunately, using the EnableLinkedConnections is not supported by MS.
If you are using a GPO Login Script, their suggested method was to use something called lanchapp.wsf, which basically creates a scheduled task that runs as the current user. This way you can map drives, printers, access their desktop, registry, etc in the context of the user, while still having admin privs for other things.
I tried converting lauchapp.wsf to kix, but have had little response as to how well it works.
RunAsInteractiveUser() - http://www.kixtart.org/forums/ubbthreads.php?ubb=showflat&Main=26830&Number=199093#Post199093
|
Top
|
|
|
|
#199706 - 2010-08-31 04:16 PM
Re: Problem with login script on Windows 7 run as scheduled task
[Re: Allen]
|
Arend_
MM club member
Registered: 2005-01-17
Posts: 1894
Loc: Hilversum, The Netherlands
|
Here is MS's own provided solution link
|
Top
|
|
|
|
#199709 - 2010-08-31 09:42 PM
Re: Problem with login script on Windows 7 run as scheduled task
[Re: Arend_]
|
Allen
KiX Supporter
Registered: 2003-04-19
Posts: 4545
Loc: USA
|
For what it's worth... here is the technet article discussing, amongst other things, the launchapp.wsf...
http://technet.microsoft.com/en-us/library/cc766208%28WS.10%29.aspx To get around this issue, administrative users should map network drives under the limited user token. This mapping is accomplished by using the launchapp.wsf script shown in Appendix A, which works by scheduling the commands using the task scheduler. The task scheduler launches the script under the administrative full token, thereby allowing Windows Explorer, other limited token processes, and the elevated token process to view the mapped network drives.
Full Context Consumption of Windows Vista settings Group Policy Scripts can fail due to User Account Control
The main goal of User Account Control (UAC) is to lessen the exposure and attack surface of the operating system. UAC does this by requiring all users to run in standard user mode. This limit minimizes the ability for users to make changes that could destabilize their computers or unintentionally expose the network to viruses through undetected malicious software (also called malware) that has infected their computer.
With UAC, you can run most applications, components, and processes with a limited privilege, but have "elevation potential" for specific administrative tasks and application functions. Windows accomplishes this by using two access tokens for each user: limited and elevated access tokens. Access tokens identify the user, the user's groups, and the user's privileges. The system uses access tokens to control access to securable objects and to control the ability of the user to perform various system-related operations on the local computer.
An elevated token, for a local administrator, includes and enables all of the administrative privileges. UAC requires local administrators to use their elevated token when attempting to perform a system-only task or administrative task. A limited token, for a local administrator, includes all of the administrative privileges; however, these privileges are disabled. This allows Windows to view the administrative user and a normal user, with the option to elevate their privileges.
By default, all users logging on to Windows Vista use their full token to process Group Policy and logon scripts. However, they use their limited user token to load the desktop and all subsequent processes. Nonadministrative limited and elevated tokens are mostly identical, with regard to privileges and groups. Therefore, a process started with a nonadministrative limited user token can view processes started with a nonadministrative elevated token. Windows allows this because the viewing application does not require any elevation to view the process started with the elevated token.
Windows processes a locally logging on administrator the same way. Group Policy and logon scripts process using the elevated user token, and the desktop and all subsequent processes use the limited token. However, there is a privilege difference between the limited and elevated user token. Therefore, Windows restricts processes started with a limited token from the ability to share information with processes started with the elevated token.
UAC may prevent Group Policy logon scripts from appearing to work properly. For example, a domain environment contains a GPO that includes a logon script to map network drives. A nonadministrative user logs on to the domain from a Windows Vista computer. After Windows Vista loads the desktop, the nonadministrative user starts Windows Explorer. The user sees their mapped drives. Under the same environment, an administrative user logs on to the domain from a Windows Vista computer. After Windows Vista loads the desktop, the administrative user starts Windows Explorer. The user does not see their mapped drives.
When the administrative user logs on, Windows processes the logon scripts using the elevated token. The script actually works and maps the drive. However, Windows blocks the view of the mapped network drives because the desktop uses the limited token while the drives were mapped using the elevated token.
To get around this issue, administrative users should map network drives under the limited user token. This mapping is accomplished by using the launchapp.wsf script shown in Appendix A, which works by scheduling the commands using the task scheduler. The task scheduler launches the script under the administrative full token, thereby allowing Windows Explorer, other limited token processes, and the elevated token process to view the mapped network drives.
|
Top
|
|
|
|
Moderator: Jochen, Allen, Radimus, Glenn Barnas, ShaneEP, Ruud van Velsen, Arend_, Mart
|
1 registered
(Allen)
and 466 anonymous users online.
|
|
|