In Active Directory (AD) environments, Group Policy Objects (GPOs) can be used to configure logon scripts. These scripts can be powerful tools to manage and automate the logon process for users and computers in the AD environment. You can assign and place such scripts in any GPO within the organization. A large organization might have tens or even hundreds of GPOs, each containing one or more logon, logoff, startup, and shutdown scripts, and together they can be used to control many aspects of the users’ profiles, desktop apps and settings and much more.
But as with most benefits of Active Directory, there’s a catch.
As your AD environment evolves and changes over time, the complexity of the GPOs assigned to domain, sites, or organizational units (OUs) increases. Over time, and as more objects are added and more hands touch the AD environment, what was once a well-documented and well-monitored GPO structure can become difficult to manage, assess, and control. Cyberattackers know this—and will take advantage of poorly maintained logon scripts.
What are GPO logon scripts?
GPO logon scripts are a series of commands or instructions that are executed automatically when a user logs on to a computer. You can use these scripts to map network drives, assign printers, execute specific applications, and perform other tasks that are required during the logon process.
To configure a GPO logon script, you first need to create a new GPO or edit an existing GPO that applies to the users or computers that you want to configure. After linking the GPO at the relevant domain, site or OU level, you can use the Group Policy Editor app to specify the script that you want to run. Once you configure a GPO with the right logon script, it is applied to all users or computers that the GPO targets.
Scripts are not limited to logon process. You can also assign logoff scripts that execute when a user logs off their computer. Similarly, you can assign startup or shutdown scripts that execute when the computer is rebooted or shut down, respectively. This post discusses the logon scripts specifically but same concept applies to all types of GPO-assigned scripts.
How do logon scripts work?
Each GPO has an associated scripts.ini file. This file is basically a configuration file that is created automatically when a GPO is created in AD. The file is used to store information about the scripts that are assigned to the GPO, including the path to where the script resides on disk and whether it should be executed during the logon, logoff, startup, or shutdown process.
The scripts.ini file is stored in the SYSVOL folder on each domain controller (DC) and is replicated to all DCs in the domain. When a user logs on to a domain-joined computer, the scripts.ini file of each relevant GPO is read to determine which scripts should be executed.
The scripts.ini file provides a central location for storing information about the scripts assigned to a GPO. This makes it easier to manage and update scripts across multiple GPOs and helps to ensure that the correct scripts are executed during the logon process.
To configure a GPO logon script:
- Open Group Policy Editor.
- Navigate to the User Configuration or Computer Configuration section, depending on whether you want to apply the logon script to users or computers.
- Go to the Windows Settings section.
- Select Scripts (Logon/Logoff).
- Specify the path to the script that you want to run during the logon process.
Whenever a user logs on to a computer that the GPO affects, the relevant script is executed automatically, depending on the type and assignment of the script. A logon script runs on any computer that the user logs on to; a startup script runs regardless of the user that logs on to the computer (depending on how you assigned the GPO).
Logon scripts and AD security
Group Policy security vulnerabilities are a common risk for organizations that use AD. Respondents in our most recent Purple Knight Report reported an overall Group Policy Security score of just 63—a barely passing grade. Given the potential influence that logon scripts have over the organization’s computers, users, assets, services, applications, and data, ensuring their security and integrity is crucial.
Monitoring the security of your logon scripts requires enumerating all GPOs, parsing those GPOs, and finding logon script paths. To minimize the risk of unauthorized access and potential security breaches, you need to verify that the logon scripts are well-formed, monitored, and placed in secure paths.
Attackers that gain permission to modify a logon script can manipulate the script to create new files in the script paths. Doing this, they can place malware in the path, leading not only to data destruction or encryption for ransom purposes, but also to a persistent presence on the target machines. Such persistence enables attackers to gain access to your systems even after a reboot.
What should you look for when assessing logon scripts? As a starting point, determine:
- Whether any non-well-known SID user (such as users that are not members of the Domain Admins group) has permissions for the script’s path
- Which OUs the GPO applies to
- Which inheritance or enforcement settings apply to the GPO
Additionally, check the scripts.ini in each GPO and the set of permissions on the path.
Regular, ongoing monitoring of all logon scripts is essential to AD security. To ease these task, you can use tools such as Purple Knight or Semperis Directory Services Protector (DSP). These tools can enumerate all GPOs, parse them, find all the scripts that the GPOs configure, and examine the script paths, then show this information in a generated report.
Mitigating logon script risk
To mitigate the risk associated with logon scripts:
- Examine the GPO report and outlined findings.
- Remove any unnecessary scripts from the GPOs in your environment.
- Make any necessary changes to the permissions assigned to reported paths and file names.
- Rescan the AD environment to determine whether any additional changes are required.
Logon script risk mitigation using Purple Knight
Figure 1 shows the results of a Purple Knight scan that found several issues in GPO logon scripts and their paths.
The report shows the GPOs that assigned the scripts, whether the file exists, and whether any non-well-known SIDs are assigned any permissions that should be examined.
Logon script risk mitigation using DSP
Figure 2 shows a DSP scan report.
This report explains the concept behind the indicators, the results of the scan, and suggested remediation steps.
AD security: an ongoing task
However you choose to monitor GPO logon scripts, you should regularly scan AD to ensure that no unauthorized changes have been made to permissions and that no uncontrolled scripts have been added to GPOs. Adding this task to your to-do list can save your organization from the pain of a successful cyberattack.
Learn more about AD security
