3

As a security best practice, I would like to keep track in my Windows Active Directory domain of any new "Protected Accounts and Groups". According Microsoft, this concerns any user or group which is directly or indirectly member of those specified groups (source). To achieve such detection, I have managed to collect all Windows servers logs into my SIEM after enabled proper auditing settings.

I'm currently focus on the event ID 4780 (The ACL was set on accounts which are members of administrators groups. - source). Again, according Microsoft, " If the ACL on the principal account differs from the ACL on the AdminSDHolder object, then the ACL on the principal account is reset to match the ACL on the AdminSDHolder object and this event is generated". So each time a new user or group is marked as "protected", it should trigger this event ID.

My problem here is that this event ID is generated hourly for all my "priviliged accounts" (see image below), as defined per default by the SDProp process. This concerns all built-in groups (domain admin, schema admin, ...) but also intermediate custom groups that are not directly part of those "built-in protected groups". Since those event are generated all the time, my detection is useless. The picture below represent the amount of event ID 4780 per user or group. I have taken it from different domain to ensure that this was not an isolate behavior. default account all accounts

In addition of this, I have also been looking on:

  • AdminSDHolder: attribute is set to 1 when object is marked as "protected". By modifying the attribute value manually, I'm able to trigger the event ID 5136. However, when the change is pushed by the SDProp process, nothing is triggered. Note that proper SACL auditing were in place on the object (full object audit).
  • Domain group membership change (ID 4728/4756): already in place but the limitation are intermediate groups. For example, group "SG_Admin1" is member of "Domain admin". Ideally I would need to monitor "SG_Admin1" but because we have so many customers, not all may report to us that this group is sensitive. Therefore, we would miss that a new "domain admin" member was added if someone add a user to "SG_Admin1".
  • LDAP query for AdminSDHolder: our detection is currently based only on Windows logs and not LDAP queries

So any one else is reaching this problem ? If yes how did you fix it ? Which others solution could I use to monitor any new "protected" objects ?

7
  • How is this a problem? This is expected behavior and completely normal.
    – Greg Askew
    Mar 21, 2019 at 16:21
  • Well problem is that this is happening all the time and it should not (from my understanding). Microsoft says " If the ACL on the principal account differs from the ACL on the AdminSDHolder object, then the ACL on the principal account is reset to match the ACL on the AdminSDHolder object and this event is generated". Since there is no "diff" between the ACL, no event should trigger. From my understanding, this should only happend each time a new "protected" account is detected. Is that correct ? Mar 21, 2019 at 17:39
  • You may want to include the Windows version of the PDCE DC, and the domain functional level.
    – Greg Askew
    Mar 21, 2019 at 18:28
  • 1
    PDCE: 2012 R2, DFL: 2012 R2, DC OS: Server 2012 R2 – However, and as you may see on the picture above, some accounts (eg: schema admins) were not triggering the event for some time. And this point remains unclear to me. Mar 22, 2019 at 14:10
  • 1
    Thanks for the feedback. But our current limitation is that we do not have LDAP access for security reasons. So we have to rely on the security logs instead. PS: I have also found the following PowerShell script which is doing a quiet good output regarding the AdminSDholder attribute. gallery.technet.microsoft.com/Reset-AD-adminCount-195bf65e Mar 24, 2019 at 22:01

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.