No announcement yet.

Local admin password via GPO/Hiding Startup script from RSOP question...

  • Filter
  • Time
  • Show
Clear All
new posts

  • Local admin password via GPO/Hiding Startup script from RSOP question...

    Hi guys

    Hope someone can help - this is ruining my friday morning!

    I have the task of setting the local admin password, via a GPO on our computers OU.

    So far I have done the following:

    1) Setup a test OU and created a test GPO.
    2) Created a script on a test share which runs "NET USER Administrator %1"
    3) Set the startup script in the GPO to run to the batch file, with the parameters as "password" (the acutal test password should have hit the security requirements, it was in the form Password1)
    4) Set the Security filtering of the GPO to domain computers (we dont want it to hit all domain computers, just the computer accounts in this particualr OU that the GPO is linked too.)
    5) Removed authenticated users from the delegation rights of the GPO (domain computers had inherited)

    Now my understanding is that this should hit all computers in the OU, and prevent a domain user from running RSOP.msc and viewing the startup scripts/parameters...

    However, in the original test, I used the individual computer accounts in the delegation rights, not the domain computers group. When I sucesfully tested the individual computer accounts, i switched it over to domain computers, and now the GPO applies, but it allows RSOP to read the GPO as a domain user!

    I cannot get my head round it! Is there something strange about the domain computers group? Or they way i've set it up?

    Many thanks for any advice


  • #2
    Re: Local admin password via GPO/Hiding Startup script from RSOP question...

    Morning guys

    Just done some more investigating - and using a security group manually created, also does the same thing!

    Any ideas?


    • #3
      Re: Local admin password via GPO/Hiding Startup script from RSOP question...

      FYI, What RSoP logging shows is basically what's been logged in the WMI repository on the machine by each Client Side Extension (CSE) during the processing of the computer-configuration or the user-configuration policies. So this will answer your question, RSoP does not read the group policies from the server.
      Additionally, RSoP does show if the CSE itself might have failed to run successfully, but it does not guarantee that every settting that was delivered was actually successfully applied (more:

      BTW, users can read the script parameters also from registry (in subkeys of: HKLM\SOFTWARE\Policies\Microsoft \Windows\System\Scripts\Startup).

      It is not recommended to use startup scripts or logon script that utilizes alternate credentials.
      But if you realy have too, then the best option is to encrypt and compile the code. If you don't have the programming tools and skills to do that, well... then better hide the hardcoded username and password as deep you can.

      For your startup script,
      1. In the first place remove the 'authenticated users'-group from the folder permissions and addin 'read and execute'-permissions for the 'Domain Computers'-group.
      2. Don't use the script parameter option for providing username or password.
      3. Vbs would be a slightly better choice than using the DOS command interpreter since batches are processed by reading and processing line after line and can run visible. It is also possible to encode vbs scripts (however, a clever user could download a decoder then still be able to read the script).
      4. Change password of the account that is used in the script very frequently (then adjust the script accordanly).
      5. Finally, use a bit of your creativity to to mask the real purpose of the script and its powers for the nosey users. There is a way to hide the script-file from visability by copying it to the NTFS alternate data streams of an other file or folder. However users are still able to reveal the content, but they first have to know it is there. E.g. Copy an encoded-vbs file to the alternate data streams of a batch file, The vbs can be launched from within the batch. The batch mainly constist of misleading code. (This might look unprofessional and you probably right but, so is hardcoding credentials in an uncompiled startup script, you know what I mean).

      There is also an option to download one of the available free bat-to-exe or vbs-to-exe tools from the internet. Be aware though - these tools do not compile or encrypt the code! It'll just be wrapped into an exe package, that likely can be unpacked by the user. Furthermore, the exe-files created by most of these tool even unpack the code to a txt-file on the local computer while executing. I wouldn't recommend to use one of these tools.

      IMHO the best choice is to run a script from the server by an Administrator. The script contact every computer that is found in a certain OU(s), and log the successes and failures. Continue re-running this script for the computers that were unsuccessfull.

      Last edited by Rems; 3rd June 2009, 22:11.

      This posting is provided "AS IS" with no warranties, and confers no rights.


      ** Remember to give credit where credit's due **
      and leave Reputation Points for meaningful posts


      • #4
        Re: Local admin password via GPO/Hiding Startup script from RSOP question...

        Interesting points, Rems. I hadn't considered the bat-to-exe route before. Instead we only have the script available a few times a month where I work.
        This message represents the official view of the voices in my head


        • #5
          Re: Local admin password via GPO/Hiding Startup script from RSOP question...

          We use PWDMAN all the time.. work great.. perhaps you can give it a try.. its free