+ Post New Thread
Results 1 to 4 of 4
Windows 7 Thread, Login script fails to run if a user has local admin privs! in Technical; I have a rather backwards and weird issue at the moment. If I add the staff group as part of ...
  1. #1

    localzuk's Avatar
    Join Date
    Dec 2006
    Location
    Minehead
    Posts
    17,868
    Thank Post
    518
    Thanked 2,486 Times in 1,928 Posts
    Blog Entries
    24
    Rep Power
    838

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

    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?

  2. #2
    Duke5A's Avatar
    Join Date
    Jul 2010
    Posts
    807
    Thank Post
    83
    Thanked 132 Times in 115 Posts
    Blog Entries
    8
    Rep Power
    32
    Does the script show up in the registry for that user?
    Code:
    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?

  3. #3


    Join Date
    Feb 2007
    Location
    51.403651, -0.515458
    Posts
    9,058
    Thank Post
    231
    Thanked 2,716 Times in 2,004 Posts
    Rep Power
    794
    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)

  4. Thanks to Arthur from:

    psydii (24th August 2012)

  5. #4

    Join Date
    Jul 2006
    Location
    London
    Posts
    1,264
    Thank Post
    111
    Thanked 242 Times in 193 Posts
    Blog Entries
    1
    Rep Power
    74
    Superb references. Both should be compulsory reading for any Windows Admin. I hadn't seen the first one before.

SHARE:
+ Post New Thread

Similar Threads

  1. Replies: 4
    Last Post: 3rd August 2012, 02:48 PM
  2. login script needed to set file associations
    By goodhead in forum Windows
    Replies: 5
    Last Post: 6th March 2009, 02:59 PM
  3. Replies: 4
    Last Post: 15th December 2006, 12:14 PM
  4. Java Script fails to work on one user profile!
    By pmassingham in forum Windows
    Replies: 0
    Last Post: 29th June 2006, 07:32 AM
  5. Replies: 1
    Last Post: 16th February 2006, 09:57 AM

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •