No announcement yet.

Active Directory User DACL Troubles

  • Filter
  • Time
  • Show
Clear All
new posts

  • Active Directory User DACL Troubles

    Having an issue with AD that's driving me mad, perhaps someone has come across this before.

    Some potentially relevant facts:
    -Domain Functional Level 2008, Forest Functional Level 2003
    -3 DC's: Windows Server 2008 (virtual), Windows Server 2008 R2, Windows Server 2012 (virtual)
    -Domain has two-way trust with another domain and one-way trust to another domain (our users can log into that domain's machines, but not vice versa)
    -We were using Microsoft Online Services for E-mail, but we've moved on to Office 365 with Directory Synchronization.
    -In order to have our VPN appliance work with AD, we've added an attribute to the user schema, VPN-Access, which is a numerical value that translates on the appliance to a set of VPN rights. As far as I'm aware, there's been no other changes to the user object Schema.

    Within this domain, we have created new OUs for Computers, Users, and Groups, so we're not using any of the default structure. We have our users in the Created OU For Users (call it COUFU for short), separated into sub-OUs based on role (COUFU-Employees, COUFU-Consultants, COUFU-Disabled, etc). We are trying to designate our new Helpdesk guy's security group with permissions to create new, edit current, and reset password. We've used the Delegation Wizard to apply the correct permissions, and it appears to work (permissions appear in the DACL). However, a subset of our users have their DACLs reset automatically at certain intervals, and lock the Helpdesk back out again. They are not, however, resetting to system defaults: they're resetting to a set list of permissions, which makes me think a past admin has something running that does this automatically. (No, I don't have access to past admins).

    I've sniffed for Group Policy that resets the permissions, but no dice. There are no scheduled tasks running on any of the 3 DC's that I can see that would be doing this as well. And I don't know where in the logs to look in order to see if any kind of script has been applied by the domain controller or the permissions have been changed.

    So the questions:
    -Is this a function of AD I don't know about or don't remember?
    -When someone changes the DACL of a user object in AD, is it logged somewhere in Windows Event Viewer?
    -If not, how would I find out who, what, where, and when this change of files is taking place?

  • #2
    Can you enable auditing of GP changes and start tracking down when the changes are being made, then start looking for scripts running in the background\?
    Tom Jones
    MCT, MCSE (2000:Security & 2003), MCSA:Security & Messaging, MCDBA, MCDST, MCITP(EA, EMA, SA, EDA, ES, CS), MCTS, MCP, Sec+
    IT Trainer / Consultant
    Ossian Ltd

    ** Remember to give credit where credit is due and leave reputation points where appropriate **


    • #3
      Are these users members of any protected groups?


      • #4
        Scripts that affect AD can be run from any computer that has the RSAT installed, so maybe think about any remote management methods used now or previously, and check out those devices for scheduled tasks that run scripts. The RSAT install can/will include the Powershell modules for those tools, which makes it easy to do remote control.
        MSCA (2003/XP), Security+, CCNA

        ** Remember: credit where credit is due, and reputation points as appropriate **


        • #5
          Thanks for all the answers so far.

          I think this is going to end up being the answer:

          Originally posted by joeqwerty View Post
          Are these users members of any protected groups?

          So it turns out a past admin used the BUILTIN\Print Operators group as a mechanism to allow users to have print access on their systems. Print Operators, being a protected group, made all its members protected, and since the group I was trying to add was not on the AdminSDHolder DACL (this is our first operator that will not have Domain Admin rights, which is why we haven't seen this before), it was being rejected after a set period of time (somewhere between 15 and 60 minutes; I never got a handle on the exact time).

          I've taken all the users out of the Print Operators group and ran the script I had built to turn off the adminCount parameter and add the requested group to the DACL. We also ran the same script against users that are in the protected groups (a group of test accounts in the Backup Operators group that otherwise have no access to anything critical), so if those users are reset to the permissions of AdminSDHolder, and the other users are not, then we'll know for sure what the score was. I should know for sure within the hour, but this is the most confident I've been in a while about a proper solution to this issue.

          What's disturbing is that, despite ALL the auditing being turned on, that action does not appear to have been logged anywhere. As Darth Admin says, I find your lack of logging disturbing...

          Thanks again for all the help guys. I'll confirm tomorrow whether that was it.