Show
6144: Security policy in the group policy objects has been applied successfully On this page
This is a useful event. This event does not just get logged each time Group Policy refreshes. It only gets logged (based on testing Win2012R2) when something in Security Settings the RSOP has changed (i.e. someone edited a Security Setting in one of the GPOs applicable to this computer, or Local Security Policy)thus necessitating Windows to adjust local configuration to meet Group Policy. So basically this event tells you a security configuration change has occurred due to Group Policy (including Local Security Settings). It doesn't tell you which policy(ies) but at least you know something has changed. Free Security Log Resources by Randy
Supercharger Free Edition Your entire Windows Event Collection environment on a single pane of glass. Free. Examples of 6144Security policy in the group policy objects has been applied successfully. Return Code: 0 GPO
List: Top 10 Windows Security Events to Monitor Free Tool for Windows Event Collection
Upcoming Webinars Additional Resources Group Policy is a series of settings in the Windows registry that control security, auditing and other operational behaviors. For example, Group Policy enables you to prevent users from accessing certain files or settings in the system, run specific scripts when the system starts up or shuts down, or force a particular home page to open for every user in the network. Here are Active Directory Group Policy best practices that will help you to secure your systems and optimize Group Policy performance. Do not modify the Default Domain Policy and Default Domain Controller PolicyUse the Default Domain Policy for account, account lockout, password and Kerberos policy settings only; put other settings in other GPOs. The Default Domain Policy applies at the domain level so it affects all users and computers in the domain. Use the Default Domain Controller Policy for the User Rights Assignment Policy and Audit Policy only; put other settings in separate GPOs. However, even for the policies listed above, it is better to use separate GPOs. Create a well-designed organizational unit (OU) structure in Active DirectoryHaving a good OU structure makes it easier to apply and troubleshoot Group Policy. Don’t mix different types of AD objects in the same OUs; instead, separate users and computers into their own OUs and then create sub OUs for each department or business function. Putting users and computers in separate OUs makes it easier to apply computer policies to all computers and user policies to only the users. It is easier to create a GPO and link it in many OUs than to link it to one OU and deal with computers or users that the policy should not affect. However, don’t plan your OU architecture based solely on how you will linking Group Policies to it. Give GPOs descriptive namesBeing able to quickly identify what a GPO does just looking at the name will make Group Policy administration much easier. Giving a GPO a generic name like “pc settings” will confuse sysadmins. For example, you might use the following naming patterns:
Here are few examples using those naming rules:
Create each GPO according to its purpose rather than where you're linking it to. For example, if you want to have a GPO that has server hardening settings in it, put only server hardening settings in it and label it as such. Add comments to your GPOsIn addition to creating good names, you should add comments to each GPO explaining why it was created, its purpose and what settings it contains. This information can be priceless years later. Do not set GPOs at the domain levelEach Group Policy object that is set at the domain level will be applied to all user and computer objects. This could lead to some settings being applied to objects that you don’t want to. Therefore, the only GPO that should be set at the domain level is the Default Domain Policy. It’s better to apply other policies at a more granular level. Apply GPOs at the OU root levelApplying GPOs at the OU level will allow sub OUs to inherit these policies; you don’t need to link the policy to each sub OU. If you have users or computers that you don’t want to inherit a setting, then you can put them in their own OU and apply a policy directly to that OU. Do not use the root Users or Computers folders in Active DirectoryThose folders are not OUs so they cannot have GPOs linked to them. The only way to apply policies to those folders is to link them to the domain level, but as stated above, you should avoid doing that. So as soon as a new user or computer object appears in these folders, move it to the appropriate OU immediately. Don’t disable GPOsIf a GPO is linked to an OU and you don’t want it to be applied, delete the link instead of disabling the GPO. Deleting the link from an OU will not delete the GPO; it just removes the link from the OU and its settings are not applied. Disabling the GPO will stop it from being applied entirely on the domain, which could cause problems because if you use this Group Policy in another OU, it will no longer work there. Implement change management for Group PolicyGroup Policy can get out of control if you let all your administrators make changes as they feel necessary. But tracking changes to Group Policy can be difficult because security logs cannot give you full picture of exact which setting was changed and how. You can take a look at how you can track changes to Group Policy in the Group Policy Auditing Quick Reference Guide. The most important GPO changes should be discussed with management and fully documented. In addition, you should set up email alerts for changes to critical GPOs because you need to know about these changes ASAP in order to avoid system downtime. You can do this using PowerShell scripts or, more conveniently, with IT auditing software like Netwrix Auditor for Active Directory. Avoid using blocking policy inheritance and policy enforcementIf you have a good OU structure, then you can most likely avoid using blocking policy inheritance and policy enforcement. These settings can make GPO troubleshooting and management more difficult. Blocking policy inheritance and policy enforcement are never necessary if the OU structure is designed properly. Use small GPOs to simplify administrationHaving small GPOs makes troubleshooting, managing, design and implementation easier. Here are some ways to break out GPOs into smaller policies:
However, keep in mind that larger GPOs with more settings will require less processing at log on (since systems have to make fewer requests for GPO information); loading many small GPOs can take more time. However, large GPOs can have GPO setting conflicts that you have to troubleshoot, and you’ll have to pay more attention to GPO inheritance. Speed GPO processing by disabling unused computer and user configurationsIf you have a GPO that has computer settings but no user settings, you should disable the User configuration for that GPO to improve Group Policy processing performance at systems logon. Here are some other factors that can cause slow startup and logon times:
Avoid using a lot of WMI filtersWMI contains a huge number of classes with which you can describe almost any user and computer settings. However, using many WMI filters will slow down user logins and lead to a bad user experience. Try to use security filters over WMI, when possible, because they need less resources. Use loopback processing for specific use casesLoopback processing limits user settings to the computer that the GPO is applied to. A common use of loopback processing is on terminal servers: Users are logging into a server and you need specific user settings applied when they log into only those servers. You need to create a GPO, enable loopback processing and apply the GPO to the OU that has the servers in it. Use “gpresult” to troubleshoot GPO issuesThe gpresult command displays Group Policy information for a remote user and computer. In addition, it breaks down how long it takes to process the GPO. This command is available only in Windows 10 and Windows Server 2016. The gpresult utility has many settings; you can view them by entering the command “gpresult /?”. Use Advanced Group Policy Management (AGPM)AGPM provides GPO editing with versioning and change tracking. It is part of the Microsoft Desktop Optimization Pack (MDOP) for Software Assurance and can be downloaded from https://www.microsoft.com/en-us/download/details.aspx?id=54967. Back up your Group PoliciesConfigure daily or weekly backup of policies using Power Shell scripting or a third-party solution so that in case of configuration errors, you can always restore your settings. GPO settings best practicesLimit access to the Control Panel in WindowsIt’s important to limit access to the Control Panel, even if the user is not an administrator on the Windows machine. You can block all access to the Control Panel or allow limited access to specific users using the following policies:
Do not allow removable media drivesRemovable media can be dangerous. If someone plugs an infected drive into your system, it unleash malware into the whole network. In an office environment, it’s best to disable removable drives entirely using the “Prevent installation of removable devices” policy. You can also disable DVDs, CDs and even floppy drives if you want, but the primary concern is removable drives. Disabling automatic driver updates on your systemDriver updates can cause serious problems for Windows users: They can cause Windows errors, performance drop or even the dreaded blue screen of death (BSOD). Regular users can’t switch updates off since it’s an automated feature. Windows Group Policy settings can be changed to disable automatic driver updates, using the “Turn off Windows Update device driver searching” policy. However, you must specify the hardware IDs of the devices you want to stop updates on. You can find this information in Device Manager. Make sure access to command prompt is restrictedThe command prompt is very useful for system administrators, but in the wrong hands, it can turn into a nightmare because gives users the opportunity to run commands that could harm your network. Therefore, it’s best to disable it for regular users. You can do that using the “Prevent access to the command prompt” policy. Turn off forced restarts on your serversIf your Windows Update is turned on, you probably know that Windows pushes you to reboot the system after updating. But some users don’t turn off their computers when they leave work, so if their desktops are forcibly rebooted by a Windows Update, they can lose their unsaved files. You can use Group Policy settings to permanently disable these forced restarts. Disable software installations by AppLocker and Software Restriction PolicyThere are many ways you can block users from installing new software on their system. Doing this reduces maintenance work and helps avoid the cleanup required when something bad is installed. You can prevent software installation by changing the AppLocker and Software Restriction Group Policy settings and disabling certain extensions (such as “.exe”) from running. Disable NTLM in your network infrastructureNTLM is used for computers that are members of a workgroup and local authentication. In an Active Directory environment, Kerberos authentication has to be used instead of NTLM, because it is stronger authentication protocol that uses mutual authentication rather than the NTLM challenge/response method. NTLM has a lot of known vulnerabilities and uses weaker cryptography, so it is very vulnerable to brute-force attacks. You should disable NTLM authentication in your network using Group Policy to allow only Kerberos authentication, but first ensure that both Microsoft and third-party applications in your network do not require NTLM authentication. How do I change the local security policy on a domain controller?In the console tree, click Computer Configuration, click Windows Settings, and then click Security Settings. Do one of the following: Click Account Policies to edit the Password Policy or Account Lockout Policy. Click Local Policies to edit an Audit Policy, a User Rights Assignment, or Security Options.
What is local security policy in Active Directory?The Local Security Policy is used to set lockout parameters for logging on to the computer, and the Domain Policy is used to set lockout parameters for logging on to the domain. To set the lockout policies, open the appropriate (local or domain) GPO and follow these steps: 1.
How do I allow local login in Group Policy?Navigate to “Computer Configuration-> Windows Settings->Security Settings->Local Policies->User Rights Assignment”. Double click “Deny Log on locally”. Click the “Add User or Group…” button. Add the name of the security group you created in step 1.
How do I grant logon locally permission?Allow Logon Locally In Windows Server. Under Computer configuration > go to Windows Settings > Security Settings > Local Policies > User Rights Assignemnts.. Right Click on Allow Logon Locally > Properties.. Click on Add User and Group then add the new user account.. |
