Audit Policies Incorrectly Set To "No auditing" across the entire domain.
-
Tuesday, November 13, 2012 12:15 AM
Consider the following scenario:
Default Domain Policy had local security auditing policies with very specific settings:
Audit account logon events Success, Failure
Audit account management Success
Audit directory service access Success
Audit logon events Success
Audit policy change Success,Failure
Audit privilege use Success
Audit process tracking Failure
Audit system events Success
These setting are working and applied across the domain to all workstations and servers (not domain controllers). A decision is made to alter the policy settings such that they revert to the default behavior for servers and workstations based on setting all of the audit policies to "Not Configured" in the Default Domain Policy. When put into effect, all servers and workstations that do not have explicitly defined local policies do not display "Not Configured" when the Default Domain Policy applied. Instead they all display "No Auditing", which is not what was set in the Default Domain Policy.
There is a big difference between "Not Configured" and "No Auditing". My hat's off to anyone that can provide an explanation as Microsoft India has been toiling to provide me an explanation for over two months. I've provided all kinds of diagnostic logs and they have had multiple people remotely connect and attempt to figure out what has happened, so far no explanation.
The domain is a mix of Windows 2003 and 2008 R8 domain controllers running @ Windows 2003 funtional level. The servers are a mix of 2003 through 2008 R2. The workstations are both Windows XP and 7. Explicitly setting the policies on a local server or workstation is allowed, and is one of the reasons the change was made in the first place. The expected behavior was that all computer getting hte policy applied would log events under the default setting for the O/S type as explained in each descrete audit policy, for example:
Audit logon events
This security setting determines whether the OS audits each instance of a user attempting to log on to or to log off to this computer.
Log off events are generated whenever a logged on user account's logon session is terminated. If this policy setting is defined, the administrator can specify whether to audit only successes, only failures, both successes and failures, or to not audit these events at all (i.e. neither successes nor failures).
Default values on Client editions:
Logon: Success
Logoff: Success
Account Lockout: Success
IPsec Main Mode: No Auditing
IPsec Quick Mode: No Auditing
IPsec Extended Mode: No Auditing
Special Logon: Success
Other Logon/Logoff Events: No Auditing
Network Policy Server: Success, FailureWhat we got instead was a blank security log on all systems in the domain from the time the Default Domain Policy went into effect.
All Replies
-
Wednesday, November 14, 2012 2:20 AMModerator
Hi ,
Thank you for posting your issue in the forum.
I am trying to involve someone familiar with this topic to further look at this issue. There might be some time delay. Appreciate your patience.
Thank you for your understanding and support.
Best Regards,
Andy Qi
If you are TechNet Subscription user and have any feedback on our support quality, please send your feedback here.
-
Wednesday, November 14, 2012 3:51 AM
So, I think I'm missing something here but let me try to work through it. In the DDP you set some audit policy (success and/or failure) for a number of event types. That presumably applied successfully to all workstations/servers. Then you came along again and set those DDP policies to No Auditing (Not Configured is not the correct term, at least on Win7/2008-R2). And then what you expected to happen is that those clients would go back to their default audit state locally?
If that is correct, then here is an observation. First off, I have a number of test Win7 systems on my network with essentially vanilla out-of-the-box Win7 installs on them. In those cases, there is no local auditing configured at all, meaning that removing central auditing via the DDP will return these machines to "No Auditing". I'm not sure where you got the Default Values on Client editions above, but it doesn't correspond to what I'm seeing. Also, what's kind of odd is that you mention that "explicit setting of policies on a local server or workstations is allowed"--what does that mean? Does that mean your users are free to muck with the local GPO?
Finally, as a test, I did this scenario. On my Win7 test machine, with no auditing previously configured locally, I started up the GP Editor and set Success auditing on Logon Events. Then I went into the DDP and enabled Success AND Failure auditing on logon events. When the Win7 machine processed this policy, sure enough the local GPO now reflected the new auditing setting of Success and Failure, and it was grayed out from making local changes, as expected. Then, I went back into the DDP and un-configured Logon Events auditing. When the client then processed that updated GPO, the local settings reverted back to as they were, with only Success auditing, and I could once again edit the policy. That is what I would expect as "normal behavior". I'm not entirely sure you're not actually setting that.
Darren
Darren Mar-Elia MS-MVP, Group Policy
www.gpoguy.com
www.sdmsoftware.com - "The Group Policy Experts" -
Wednesday, November 14, 2012 9:23 AM
Hi,
I'm afriad it's a normal behavior. Security settings are written to security database, they cannot be reverted back to default value once some settings are applied, we can only replace them with new settings.
Do a try:
Pick up one of workstations which have applied the new policy, and then rename securiyt database secedit.sdb under C:\Windows\security\database, run "gpupdate /force"(wihtout the quotes) to refresh group policy. Check what will happen.
Note: All current security settings will be lost after renaming security database.
Regards,
Diana
Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
- Marked As Answer by Andy QiMicrosoft Contingent Staff, Moderator Wednesday, November 28, 2012 10:19 AM
-
Wednesday, November 14, 2012 6:25 PM
Hi,
I'm afriad it's a normal behavior. Security settings are written to security database, they cannot be reverted back to default value once some settings are applied, we can only replace them with new settings.
Do a try:
Pick up one of workstations which have applied the new policy, and then rename securiyt database secedit.sdb under C:\Windows\security\database, run "gpupdate /force"(wihtout the quotes) to refresh group policy. Check what will happen.
Note: All current security settings will be lost after renaming security database.
Regards,
Diana
Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
When you say it is normal behavior, why does the group policy describe otherwise? Why would the description say that if you set policy X to "Not Configured", the clients and servers will audit according to the OS type:
Audit account logon events
This security setting determines whether the OS audits each time this computer validates an account’s credentials.
Account logon events are generated whenever a computer validates the credentials of an account for which it is authoritative. Domain members and non-domain-joined machines are authoritative for their local accounts; domain controllers are all authoritative for accounts in the domain. Credential validation may be in support of a local logon, or, in the case of an Active Directory domain account on a domain controller, may be in support of a logon to another computer. Credential validation is stateless so there is no corresponding logoff event for account logon events.
If this policy setting is defined, the administrator can specify whether to audit only successes, only failures, both successes and failures, or to not audit these events at all (i.e. neither successes nor failures).
Default values on Client editions:
Credential Validation: No Auditing
Kerberos Service Ticket Operations: No Auditing
Other Account Logon Events: No Auditing
Kerberos Authentication Service: No AuditingDefault values on Server editions:
Credential Validation: Success
Kerberos Service Ticket Operations: Success
Other Account Logon Events: No Auditing
Kerberos Authentication Service: SuccessIf the policy description stated that setting the policy to "Not Configured" will result in "No Auditing" for all Servers and Clients, then I would understand. If the intended behavior is in fact for "No Auditing" to be in effect for all local audit policies that are set to "Not Configured", then the description in the policy should say so.
The statement about the "settings can't be reverted" doesn't make sense, because the security database had to be modified to switch from "Success,Failure" auditing to "No Auditing". What made that modification? Based on what you're saying, the local machines all set themselves to "No Auditing" when they stopped receiving a policy setting? If this is true, then I would say this is a major flaw in the design, particularly because this behavior is not documented anywhere that I can find.
If your statement was true, what I would expect to happen is that all servers and clients would have held their existing settings in the absense of receiving a policy that applied specific settings. It appears to me that something specifically set the "No Auditing" policies across the board. I want to know what that something is and why it did that.
-
Wednesday, November 14, 2012 6:37 PM
So, I think I'm missing something here but let me try to work through it. In the DDP you set some audit policy (success and/or failure) for a number of event types. That presumably applied successfully to all workstations/servers. Then you came along again and set those DDP policies to No Auditing (Not Configured is not the correct term, at least on Win7/2008-R2). And then what you expected to happen is that those clients would go back to their default audit state locally?
If that is correct, then here is an observation. First off, I have a number of test Win7 systems on my network with essentially vanilla out-of-the-box Win7 installs on them. In those cases, there is no local auditing configured at all, meaning that removing central auditing via the DDP will return these machines to "No Auditing". I'm not sure where you got the Default Values on Client editions above, but it doesn't correspond to what I'm seeing. Also, what's kind of odd is that you mention that "explicit setting of policies on a local server or workstations is allowed"--what does that mean? Does that mean your users are free to muck with the local GPO?
Finally, as a test, I did this scenario. On my Win7 test machine, with no auditing previously configured locally, I started up the GP Editor and set Success auditing on Logon Events. Then I went into the DDP and enabled Success AND Failure auditing on logon events. When the Win7 machine processed this policy, sure enough the local GPO now reflected the new auditing setting of Success and Failure, and it was grayed out from making local changes, as expected. Then, I went back into the DDP and un-configured Logon Events auditing. When the client then processed that updated GPO, the local settings reverted back to as they were, with only Success auditing, and I could once again edit the policy. That is what I would expect as "normal behavior". I'm not entirely sure you're not actually setting that.
Darren
Darren Mar-Elia MS-MVP, Group Policy
www.gpoguy.com
www.sdmsoftware.com - "The Group Policy Experts"
The thing to keep in mind is that the policies describe default local audit bahavior for both Clients and Servers. Out of the box, clients and servers have different local auditing. Our old Default Domain policy modified all of the local auditing settings for both client and servers. It was decided to not set specific auditing policies because that made troubleshooting a problem when we needed to modify an auditing category on a specific server or client (we didn't want to change everything in the domain to work on one server). When we set the Default Domain policy to "Not Configured", we expected that each Server or Client would either retain their existing auditing settings, or they would revert to the default settings as described in each audit policy. What we got instead was every policy being changed from what ever it was to "No Auditing" on all Servers and Clients.
If this is supposed to happen, it isn't described anywhere, and it is a pretty bad design in any case. By bad, I mean really stupid.
- Edited by bmcmcm Wednesday, November 14, 2012 6:50 PM
-
Wednesday, November 14, 2012 9:05 PM> If this is supposed to happen, it isn't described anywhere, and it is> a pretty bad design in any case. By bad, I mean really stupid.Security policies do NOT behave like ADM Templates do... Some of themcan be reverted, some cannot (e.g. File System ACLs). The fulldocumentation for this is available at Microsoft, but hard to understand- at least to me...[MS-GPSB]: Group Policy: Security Protocol ExtensionThis document heavily relies and refers to[MS-LSAD]: Local Security Authority (Domain Policy)And here, I'm giving up ;-))regards, Martin
NO THEY ARE NOT EVIL, if you know what you are doing: Good or bad GPOs?
Wenn meine Antwort hilfreich war, freue ich mich über eine Bewertung! If my answer was helpful, I'm glad about a rating! -
Wednesday, November 14, 2012 9:16 PM
Do a try:
Pick up one of workstations which have applied the new policy, and then rename securiyt database secedit.sdb under C:\Windows\security\database, run "gpupdate /force"(wihtout the quotes) to refresh group policy. Check what will happen.
Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
I tried this on a Windows 2008 R2 member server. I deleted the secedit.sdb and then executed gpupdate /force. The secedit.sdb was recreated. I went to Local Security Policy and the settings are exactly the same as before deleting secedit.sdb. I note that the description for the Audit Account Management policy states:
Audit account management
This security setting determines whether to audit each event of account management on a computer. Examples of account management events include:
A user account or group is created, changed, or deleted.
A user account is renamed, disabled, or enabled.
A password is set or changed.
If you define this policy setting, you can specify whether to audit successes, audit failures, or not audit the event type at all. Success audits generate an audit entry when any account management event succeeds. Failure audits generate an audit entry when any account management event fails. To set this value to No auditing, in the Properties dialog box for this policy setting, select the Define these policy settings check box and clear the Success and Failure check boxes.Default values on Client editions:
User Account Management: Success
Computer Account Management: No Auditing
Security Group Management: Success
Distribution Group Management: No Auditing
Application Group Management: No Auditing
Other Account Management Events: No AuditingDefault values on Server editions:
User Account Management: Success
Computer Account Management: Success
Security Group Management: Success
Distribution Group Management: No Auditing
Application Group Management: No Auditing
Other Account Management Events: No AuditingImportant: For more control over auditing policies, use the settings in the Advanced Audit Policy Configuration node. For more information about Advanced Audit Policy Configuration, see http://go.microsoft.com/fwlink/?LinkId=140969.
So after the secedit.sdb was recreated I created a local test account on the server and looked at the event viewer under security. There are no entries for user account management. I deleted the test account and looked at the event viewer again, there are still no entries for user account management.
What does this mean?
-
Thursday, November 15, 2012 9:25 AM
Sorry for misunderstanding.
Not configured does not mean default value. Default value only takes effect on standalone workstation/server, or in the situation where you have not defined the audit policies in default domain policy, the value is configured in local group policy. After you configure audit policies in default domain policy, settings in default domain policy override defautl value in local group policy, and finally the settings in default domain policy take effect(Local group policy has lowest priority, and next site, next domain and GPOs in OU has highest priority.)
Order of processing settings
http://technet.microsoft.com/en-us/library/cc778890(v=WS.10).aspx
Currently you set audit policies to Not Configured in default domain policy, thus the settings in local group policy will take effect. However, No Auditing is in local group policy, so it's normal no log entryies are logged in event log.
Regards,
Diana
Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
- Marked As Answer by Andy QiMicrosoft Contingent Staff, Moderator Wednesday, November 28, 2012 10:20 AM
-
Wednesday, November 21, 2012 4:59 PM
Let me try asking about this issue in a different manner:
1. I start with servers that are local auditing according to their out of the box default local auditing settings, which I must assume are like this (as an example for one policy setting):
Default values on Server editions:
User Account Management: Success
Computer Account Management: Success
Security Group Management: Success
Distribution Group Management: No Auditing
Application Group Management: No Auditing
Other Account Management Events: No Auditing2. I then apply a GPO that specifically sets all of the local audit policies to Success,Failure.
3. I later alter the GPO from Success,Failure for all local audit policies to Not Configured and apply the GPO.
What should I expect to happen to the local audit policies on the servers?
What has happened is that they all went from Success,Failure to No Auditing. Why would that be the case? I understand that No Auditing is the default for some auditing, but it is not the default for all of the auditing. What mechanism caused the servers to end up with No Auditing?
What isn't explained anywhere that I can find is that altering a defined local audit policy setting to Not Configured is literally the same thing as setting the policy to No Auditing, except that the setting can be changed locally as it is not enforced by a GPO.
-
Thursday, November 22, 2012 8:44 AM
Q: What should I expect to happen to the local audit policies on the servers?
A: Audit policies defined in local group policy will take effect on the servers. If their audit settings are previously configured Success and Failure, now these settings take effect. If No Audit is in local group policy, No Audit will take effect after you altered the GPO.
Q: Why would that be the case? I understand that No Auditing is the default for some auditing, but it is not the default for all of the auditing. What mechanism caused the servers to end up with No Auditing?
A: Changing to Not Configured does not replace audit settings in local group policy, neither set the audit settings to No Auditing. You see all settings as No Auditing on the servers, because all settings in local group policy previously are set to No Auditing. I'm not sure if you checked them in gpresult output.
I have done the following testing on one of servers(I suppose no any audit policies defined in Default Domain Policy).
1. Logon to the server, run "gpedit.msc" to open Local Group Policy.
2. Expand to Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy, enabled Audit Logon events for Failure.
3. Then ran "gpudpate /force", the setting is applied to the server.
4. And then I configured Default Domain Policy and enable Audit Logon events for Success and Failure, ran "gpupdate /force" on the server, the server applied the settings in default domain policy, so the settings override local group policy settings.(based on group policy apply order)
5. At this time I changed the Audit Logon events in domain GPO to Not Configured, after the command above on the server, Failure audit took effect again. Because it is defined in local group policy.
Hope the explanation above is clear.
Regards,
Diana
Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
- Marked As Answer by Andy QiMicrosoft Contingent Staff, Moderator Wednesday, November 28, 2012 10:20 AM
- Unmarked As Answer by bmcmcm Tuesday, December 18, 2012 6:58 PM
-
Tuesday, December 18, 2012 6:57 PM
I talked to a thrid level support person at Microsoft and I finally got some useful information. The support rep pointed me at these articles regarding restoration of default settings for various O/S versions:
http://support.microsoft.com/kb/816585
http://support.microsoft.com/kb/313222
http://support.microsoft.com/kb/816297/EN-USIt appears that something in the distant past obliterated the default local audit settings across the domain or the computers were installed/cloned with the settings set as no auditing instead of the defaults. When the audit settings in the Default Domain GPO were set to not configured, all of the systems reverted to their local auditing settings, which were somehow set to no auditing in the past. The main problem now is that there is no easy way to order all of the clients and servers to restore default auditing settings. It will be a cumbersome process requiring handling each operating system version on an individual basis.
.png)
