How not to get lost in group policies: conduct their audit

Imagine the situation, you are in charge of the IT service of a large company, you have several domains and several thousand users in Active Directory. You have at least several system administrators, each of whom performs his or her duties. Suddenly, employees in one of the departments complain that they can’t think of new passwords for themselves after the expiration of the old ones - the system does not accept newly created passwords. After a quick review of the password policy of the respective department, you realize that the length and complexity of the password have been changed. To find out what caused it, you refer to the event logs and understand that there is no information about when and by whom the password policy was changed - the logs have already been overwritten. Who changed the policy - will remain a secret.

And here is another example: the administrator suddenly discovers that one of the users can install software on his machine without any problems . And this is despite the fact that in the group policy for the OU, in which the user is, such a setting was prohibited. Again, information about who and when allowed such a setup should be sought in the event logs, wading through the “noise” of non-informative data.

All this leads to an unequivocal conclusion. The IT service of the company should pay attention to the changes occurring in group policies. It is necessary to do this in order to prevent both the formation of holes in the information security system (“what kind of software will the negligent user put in?”) And the continuity of activities (when 200 people cannot access their cars at the same time, because they are unable to come up with a suitable password).
Only in practice, it turns out that control over changes in group policies is rarely practiced . And only when a problem occurs or a suspicious activity is detected, does the search for the source of the problem begin by analyzing the event logs and interviewing colleagues.

However, it is important not only to find out the causes of the problem, but also to prevent its appearance. In the case of group policies, you can be assured that the administrator would like to know that the password policy has been changed and to take the necessary action before the shaft of calls from users whose work has now risen to it.
In order to promptly investigate and prevent such incidents, it is necessary to be aware of the changes occurring in group policies. You can try to solve this problem by regular means .
')
For example, view event logs manually. However, even if we set up an audit in advance and took care of the possible rewriting of data in the log, viewing the log events will happen only after receiving complaints from users. And it will only help in finding the culprit, and not preventing the problem.

In Windows Server 2008 R2, the process of tracking changes (and the warnings of related problems) becomes a bit easier. Along with a more convenient event viewer (Event Viewer), it became possible to set up email alerts for certain events, which allows you to be one step ahead, because now there is an opportunity to correct the situation before it reaches the end user.

However, even with the expansion of the standard audit capabilities in Windows Server 2008 R2, several aggravating factors arise at once. What events to choose? How to quickly filter their contents when events with the same number can contain information about different objects (for example, event 4662 is generated both for group policy changes and for other objects in Active Directory)? Events contain only a GUID, and not the name of a specific group policy, which forces one to carry out a GUID recognition procedure after receiving the necessary event. And what if there are dozens of such events?

As can be seen from the examples above, the staff audit system is far from ideal , and a separate point is also worth noting the display of the values ​​“before” and “after” for each change . They simply do not exist. It turns out that in the case of group policies, the administrator must keep their contents in his head or periodically export the policies and then manually compare how they differ.

Of course, the use of a standard audit system gives a certain control over the changes that are taking place, but still it will not be possible to avoid the following drawbacks :

1. The analysis of information about changes in events is rather laborious, requires certain knowledge for perception and cannot be presented in its original form to those people who are not very well versed in these issues (for example, top management)
2. Security log analysis should be done manually on each domain controller
3. No data consolidation
4. Log rewriting - event loss possible
5. Only the fact of the change is recorded, there is no obvious information about what exactly has changed.

And much more…

In part, the problems described above allow solving various log processing methods (starting from scripts and utilities that are allowed to analyze logs, to specialized SIEM solutions). However, they do not solve all the problems described. For example, they do not provide the values ​​of “before” and “after” for each change, as a result of which the administrator must manually create and maintain an archive with the current settings of group policies.

The drawbacks of a full-fledged audit system and the growing need for managing the IT infrastructure lead to the emergence of third-party specialized solutions for auditing changes. Based on the above-described deficiencies of the staffing system, we will determine which characteristics underlie the decisions for auditing group policies :

• Displaying the changeable value of the object in the form of “before” and “after” changes,
• Automatic generation of reports on changes that have occurred for a specific period of time (for example, every 12 hours or days),
• The ability to filter data and obtain information about changes in individual policies,
• Obviously the visibility of the information provided (who, what, where and when changed),
• The ability to store audit data in a specialized repository (in a SQL database, in an archive on a file server, or in both places at once),
• Backup and restore group policies.

We will consider in the article one of such solutions - our program NetWrix Group Policy Change Reporter , which audits group policy changes. First of all, let us tell you how the product works.

1. During data collection, the product takes snapshots of the current state of group policies and collects information from security logs from all domain controllers in which the audit is performed.
2. After data collection, they are added to the specified storage location (for example, to a dedicated file server), after which they are analyzed. The detected changes are uploaded to the database (if connected to the product), and also sent as a report to the specified addresses. Email.
3. The initialization of data collection is based on the task scheduler, in which a scheduled task is created (automatically when the product is configured), which starts the data collection.
4. By default, the report is sent once a day (at 3 am) and contains information on changes in the past 24 hours. However, the frequency and time of sending the report can be easily changed. Also sending a report can be initiated manually at any time.

Work program:

Consider the results of the product, namely, we reproduce the scenario described at the beginning of this article - we will edit the policy applied to the division of the main office (central office) of the company N:

• change the minimum password length from 7 to 14 characters
• lower the maximum password age from 45 days to 20
• enable password complexity requirements
• let users install software

So, the data collection is complete, and we received the following report :



Read more



The report clearly shows the changes we made. In our example, the administrator John Smith mistakenly lowered the maximum password validity period from 45 to 20 days, which is why some users had their password expired 25 days earlier; moreover, the minimum password length increased by 7 characters - imagine a situation waiting for users?

John Smith made these changes after the end of the working day at 8:13 pm, and the report was generated in three nights. Thus, in the morning the administrator was already aware of the changes in the morning and managed to correct them before they turned into a problem.
As you can see, the report includes the “before” and “after” values ​​for each change. Which is very convenient for assessing the criticality of a change.

The structure of the report itself is based on the following principle:

• What type of change was made (Change type)
• When the change occurred (When Changed)
• Who made the change (Who Changed)
• Where the change occurred, i.e. on which domain controller (Where Changed)
• Which group policy object was changed and which changes were made (Group Policy object)

For greater clarity, different types of changes (add, delete, modify) are marked with different colors, which is very convenient and allows you to easily select the critical type of changes (for example, delete) in the report.

In our example, the schedule for sending reports was configured to be sent once a day, and the report was generated automatically at night, however, if you do not want to wait for the report on a schedule, you can initiate its sending manually by clicking the Run button for the domain you need:



A separate item should be noted library of reports based on SQL Reporting Services (Advanced Reports):



The library is divided into subcategories of reports developed for specific audit goals and objectives. For example, if we need to raise all changes that have occurred in group policies for several months, we can use the report All Group Policy Changes , which reflects all the changes made during a specified period of time. All reports also allow you to filter the displayed information, for example, in our report below we brought out all the changes made by the user Administrator.



If we are interested in changing some specific policy settings, we can use the corresponding report, for example, changes in the policy settings that are part of the Administrative Templates Changes :



It is worth noting that a subscription can be set up for each of the reports included in the library, according to which the report will be automatically delivered to the specified email addresses in accordance with a specified schedule.

Separately it is necessary to say about the storage of audit data . Unlike regular tools, data storage is organized on two levels. The detected changes are saved in the SQL Server database - this is the first level of data storage. While the second level of storage is used to store snapshots of group policies and related data — the data is stored in the file storage. Data storage can be used at any time to generate changes (for a specific period) and upload changes to the database of SQL-server (for example, in the case of transition to a new SQL server).

Data retention is limited only by the internal objectives of the company. Thus, you can be sure that information about any change made in the past can be quickly obtained and analyzed. For example, get retrospective information about changing password policies over the past year. A number of such reports are required by regulations on information security for individual industries.

It is also worth adding that the product automatically creates backup copies of group policies , which can then be used to roll back the changes made and restore policies.

Total:
Being aware of group policy changes is necessary. Prompt resolution of problems allows you to avoid both downtime in the company and possible incidents of information security breaches. And this helps NetWrix Group Policy Change Reporter.

PS The program is available in basic free and full versions. You can familiarize yourself with their differences and download the program on our website.