Login script fails to run if a user has local admin privs!

[localzuk]

I have a rather backwards and weird issue at the moment. If I add the staff group as part of the local administrators group, their login script will not run!

 

The login script is defined in a group policy, rather than on the accounts themselves.

 

If we use the accounts themselves to define it, it works fine...

 

If they don't have local admin rights, it all works fine.

 

So, in summary - wtf?

[Duke5A]

Does the script show up in the registry for that user?

HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\System\Scripts\Logon\0\0

 

Does the entire script fail to run, or just a portion that was intended for users who have local admin privileges? Is there a debug mode you can enable? Do you use nested group membership?

[Arthur]

UAC perhaps?

 

Symptom

After you turn on User Account Control (UAC) in Windows Vista or Windows 7, programs may not be able to access some network locations. This problem may also occur when you use the command prompt to access a network location.

 

Cause

This problem occurs because UAC treats members of the Administrators group as standard users. Therefore, network shares that are mapped by logon scripts are shared with the standard user access token instead of with the full administrator access token.

 

When a member of the Administrators group logs on to a computer running Windows Vista or Windows 7 that has UAC enabled, the user runs as a standard user. Standard users are members of the Users group. If you are a member of the Administrators group and you want to perform a task that requires a full administrator access token, UAC prompts you for approval. For example, if you try to edit security policies on the computer, you are prompted. If you approve the action in the User Account Control dialog box, you can then complete the administrative task by using the full administrator access token.

 

When an administrator logs on to a computer running Windows Vista or Windows 7, the Local Security Authority (LSA) creates two access tokens. If LSA is notified that the user is a member of the Administrators group, LSA creates the second logon that has the administrator rights removed (filtered). This filtered access token is used to start the user's desktop. Applications can use the full administrator access token if the administrator user provides approval in a User Account Control dialog box.

 

If a user is logged on to a computer running Windows Vista or Windows 7 and if UAC is enabled, a program that uses the user's filtered access token and a program that uses the user's full administrator access token can run at the same time. Because LSA created the access tokens during two separate logon sessions, the access tokens contain separate logon IDs.

 

When network shares are mapped, they are linked to the current logon session for the current process access token. This means that if a user uses the command prompt (cmd.exe) together with the filtered access token to map a network share, the network share is not mapped for processes that run with the full administrator access token. (Source)

 

Once the username and password have been captured, they are sent to the local security authentication server process (%SystemRoot%\Lsass.exe, described in Chapter 6) to be authenticated. LSASS calls the appropriate authentication package (implemented as a DLL) to perform the actual verification, such as checking whether a password matches what is stored in the Active Directory or the SAM (the part of the registry that contains the definition of the users and groups).

 

Upon a successful authentication, LSASS calls a function in the security reference monitor (for example, NtCreateToken) to generate an access token object that contains the user’s security profile. If User Account Control (UAC) is used and the user logging on is a member of the administrators group or has administrator privileges, LSASS will create a second, restricted version of the token. This access token is then used by Winlogon to create the initial process(es) in the user’s session. The initial process(es) are stored in the registry value Userinit under the registry key HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon. (The default is Userinit.exe, but there can be more than one image in the list).

 

Userinit performs some initialization of the user environment (such as running the login script and applying group policies) and then looks in the registry at the Shell value (under the same Winlogon key referred to previously) and creates a process to run the system-defined shell (by default, Explorer.exe). Then Userinit exits. This is the reason Explorer.exe is shown with no parent—its parent has exited, and as explained in Chapter 1, tlist left-justifies processes whose parent isn’t running. (Another way of looking at it is that Explorer is the grandchild of Winlogon).

 

Winlogon is active not only during user logon and logoff but also whenever it intercepts the SAS from the keyboard. For example, when you press Ctrl+Alt+Delete while logged on, the Windows Security dialog box comes up, providing the options to log off, start the Task Manager, lock the workstation, shut down the system, and so forth. Winlogon is the process that handles this interaction. (Source, p80)

[psydii]

Superb references. Both should be compulsory reading for any Windows Admin. I hadn't seen the first one before.