Active Directory Services, 2008, Prevent Accidental Deletion

geoffc

By: geoffc

April 2, 2009 5:25 pm

Reads: 709

Comments:2

Rating:0

Active Directory Services, 2008, Prevent Accidental Deletion:

With the release of Microsoft Windows 2008 server new features have appeared in the operating system, and since Active Directory is currently tightly linked to the operating system, and not in any way cross platform at all, updates to Active Directory as well. Few things are as funny as listening to someone try and explain that Active Directory is cross platform since it runs on Windows 2000, 2003, and 2008 servers.

One new feature that will probably come back to bite us, from an Identity Manager perspective is a new feature of the Active Directory Users and Computers Microsoft Management Console (ADUC MMC) snapin. (Now was that a mouthful or what!) On a side note, easiest way to load it is to run dsa.msc as the executable. Just like compmgmt.msc will launch the Computer Management MMC snapin.

On Windows 2008 server, ADUC has a new option tick box (on by default), called “Protect container from accidental deletion”, if you use it, it sets an Access Control Entry (ACE) for the group Everyone, to Deny access to Delete and Delete subtree. (Via special rights grants.)

You can see in this image, the new tick box item when trying to create an Organizational Unit.

I found a link to what this is doing, which you can look at:
http://blogs.technet.com/industry_insiders/pages/windows-server-2008-protection-from-accidental-deletion.aspx

Basically the option adds an Access Control Entry (ACE), what we would call in eDirectory an ACL (Access Control List). I am not sure why Microsoft decided on ACE vs ACL for the same basic attribute, but probably just a nomenclature thing. (If anyone happens to know what the subtly in the difference is, let me know, as I am curious. I suspect an ACE is a singular, and ACL is a list of ACE’s but that seems sort of silly to me.) Active Directory uses a lot of Deny ACE’s so they deny Delete and Delete subtree to the group Everyone, (Though the more I think about it, that may be a spec ail pseudo group, since now that I think about it, I do not recall seeing an Everyone group maintained anywhere!). Thus blocking the ability to delete it.

To fix it, you could manually remove the ACE, or if you select Advanced Options in the ADUC MMC snapin, from the View menu, see figure 2,

then when you go to Properties of the Organizational Unit object, you know will see more tabs (including Security! Which is not on by default, interestingly enough) and on the Object tab, at the bottom you can see a “Protect object from accidental deletion” tick box, see figure 3.

As it happens, although this option only seems to be part of the ADUC MMC snapin that comes with Windows Server 2008, it is supported on all versions of Active Directory, since as I just described, it is really just applying an ACE under the covers, and that is supported in earlier versions. The pretty tick box interface is what is new.

To fix this manually by hand, look at figure 4,

and lets walk through the steps.

Right click on the object (Organizational Unit in my examples) and select Properties. Then click on the Security tab. You will see a bunch of default ACE’s that get applied.

Yet some people get annoyed at the Login Script and Print Job Properties default ACL entries on every object in eDirectory? Look at that list in Active Directory, I did not even show all of them in the image! For a brand new Organizational Unit I just created? Goodness!

If you do not know what I am talking about, within schema in eDirectory there are a set of default template ACL’s (Access Control Lists) that all newly created objects get. For Users, that includes Read entry rights to Login Script attributes of the current object, and Read entry rights to the Print Job Configurations. I know people who have eDirectory trees that are used exclusively for LDAP that will both remove all these useless and extra ACL’s from their users, and in fact modify base schema so that new users do not get them. If you want an Identity Manager toolkit rule to remove these ACL’s, you can read through my toolkit rule series:

Specifically part 4, which talks about using it to look at ACL values, and then you could look at the article on using XPATH to look at DirXML-Association values, http://www.novell.com/communities/node/5845/using-xpath-examine-association-values
(which use an almost identical syntax to ACL’s. Technically ACL is a special syntax of its own, but its actual composition is almost identical to Path syntax, which is what DirXML-Association uses. The main difference is for Snapins to Console One and iManager to recognize this is ACL syntax and give you a different toolset for managing it. You can read more about the Schema syntaxes in eDirectory in this series of articles:

but the approach used is similar.

You could pretty easily manipulate the rules provided there to remove the two ACL’s if you really wanted to get rid of them. What is nice, you could use the rule to report how many exist in your tree (every user object for sure, unless you tried to fix it) and then to clean them up afterwards. Later you could rerun it and see if more have shown up. Which is what would happen, unless you edited the Template ACL’s in schema to prevent them from being applied on new objects. That is a trickier task, that can only be done via LDIF as it is considered modifying base schema, and the only way to do it is via LDIF, (or I suppose DSDump, if you call NTS and convinced them to do it for you).

Back to the topic at hand, if you are looking figure 4, you will see I have the number 1, highlighting the Everyone group, and then you would click on the Advanced button (With the #2 by it).

In the Advanced Security view, you will see that Everyone has a Special permission of Type Deny and note it is not inherited from above, and only applies to the current object (#3).

If you select the ACE for Everyone, and click the Edit button, you will see that Delete and Delete Subtree (#4) are set to Deny.

You could just untick these, or delete the ACE for the Everyone group entirely and then it goes away.

The problem is that if you are synchronizing containers between eDirectory and Active Directory, and you want to be able to synchronize deletes of containers. Now there is an entire other class of problem in doing that, because a container with contents in it, can be deleted in Active Directory, but that is not a legal operation in eDirectory, I think you get a 629 error, Object is not a Leaf object. The trick will be to read back all the contents of the container and delete the lowest nodes first and work your way up. I have to solve this problem for myself a little later, so I will write about how to do it then. For now, however, assume the simple case that via policy, all Admins in Active Directory have been told to only delete EMPTY containers.

If you do try to let the delete through, you will get the following error LDAP Insufficient Rights error, which is correct, you (as a member of everyone) do not have rights to delete this object. I wonder if removing the user the driver is connecting as, from the Everyone group would work? That would be interesting if it worked.

<nds dtdversion="1.1" ndsversion="8.7">
  <source>
    <product asn1id="" build="20080229_143300" instance="\acme-LAB-IDV\acme\Drivers\IDM\Active Directory" version="3.5.3">AD</product>
    <contact>Novell, Inc.</contact>
  </source>
  <output>
    <status event-id="Xidv1#20090313191133#1#1" level="error" type="driver-general">
      <ldap-err ldap-rc="50" ldap-rc-name="LDAP_INSUFFICIENT_RIGHTS">
        <client-err ldap-rc="50" ldap-rc-name="LDAP_INSUFFICIENT_RIGHTS">Insufficient Rights</client-err>
        <server-err>00000005: SecErr: DSID-031522EC, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0
</server-err>
        <server-err-ex win32-rc="5"/>
      </ldap-err>
    </status>
  </output>
</nds>
[03/13/09 15:11:33.485]:Active Directory ST:Applying schema mapping policies to input.
[03/13/09 15:11:33.485]:Active Directory ST:Applying policy: %+C%14C%5Bacme%5D+AD-SchemaMapping%-C.
[03/13/09 15:11:33.485]:Active Directory ST:Resolving association references.
[03/13/09 15:11:33.486]:Active Directory ST:Processing returned document.
[03/13/09 15:11:33.486]:Active Directory ST:Processing operation <status> for .
[03/13/09 15:11:33.486]:Active Directory ST:
DirXML Log Event -------------------
     Driver:   \acme-LAB-IDV\acme\Drivers\IDM\Active Directory
     Channel:  Subscriber
     Object:   \acme-LAB-IDV\acme\Structure\corp\acme\Americas\MidWest
     Status:   Error
     Message:  <ldap-err ldap-rc="50" ldap-rc-name="LDAP_INSUFFICIENT_RIGHTS">
        <client-err ldap-rc="50" ldap-rc-name="LDAP_INSUFFICIENT_RIGHTS">Insufficient Rights</client-err>
        <server-err>00000005: SecErr: DSID-031522EC, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0
</server-err>
        <server-err-ex win32-rc="5"/>
</ldap-err>

With this setting (the Protect container from Accidental Deletions) the driver cannot delete the container.

The driver shim alas, does not have access to Active Directory ACE values. This is really a shame, since it would be really useful and powerful to be able to read them, and to be able to manipulate them.

It would be useful to read them, since for another instance, I wrote a toolkit rule that looks at eDirectory ACL’s and figures out users in a tree who have too many rights and reports on them. This is very useful for PCI (Payment Card Industry) audit compliance as you have to know who is a Super User in each system. With access to read the ACE’s in Active Directory, it would be a lot of fun to write a similar rule for Active Directory Super Users. Having the ability to write to ACE’s would be great as there all sorts of things we could do via DirXML Script then, on creating a user that would be useful. Rather than what we have to do currently, where we have to use group memberships where the ACE is set by some one some when on the group to handle rights assignments.

I opened a bug #485306 in Bugzilla, and lets see if they can do something about it. In case you are not aware, everyone can open bugs in Bugzilla now, and for most eDirectory and Identity Manager bugs, they are considered public and open for everyone to see. Obviously security hole bugs will remain private and hidden from the public until they are resolved, which is appropriate, since it would be foolish to reveal problems before Novell has had a chance to fix them. You just need to go to http://bugzilla.novell.com and login using your eLogin credentials (What you would use to download files, or open an incident with Novell) and once authenticated you can search for bugs and submit news one as appropriate.

The best solution would be for them to open up ACE’s to be available to us as attributes on a user in the general case. That would be great and add a lot of power to the driver, opening up all sorts of interesting new possibilities on what can be done with the Active Directory driver.

When you use a regular LDAP tool, you cannot see the ACE values, unlike in eDirectory where you see an attribute named ACL on each user with an ACL. (And noted above, since every user gets those two default ACL values of Login Script and Print Job Configuration, EVERYBODY has an ACL to look at, regardless of how useless it might be!). However, if you use the Microsoft LDP.EXE tool that ships with Windows, (possibly the worst LDAP browser I have ever used, but that is a personal User Interface opinion, so take it with a grain of salt. Well I guess it is technically better than the ldapsearch command line utility in the sense that it actually has a user interface!) you apparently can see ACE values. Thus the data is clearly available, probably through an LDAP extension, which is the usual way of handling this. Thus I assume it should be possible to get access to the attributes. To be fair, most of the NMAS (Novell Modular Authentication Services) stuff in eDirectory needs to use an LDAP extension to get at it as well. These are the approved method of handling slightly out of specification functionality being exposed via LDAP.

This should also be resolvable via Powershell, which you could get access too via the Scripting driver, but that is an additional expense, and a bit of work to synchronize the handling of events to get the timing correct.

I imagine a tool could be written on the Active Directory side that every night would run, and remove these ACE’s from any organizational unit that has them set, in the simplest approach to cleaning this mess up, but that is not particularly elegant as a solution.

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Tags: , , ,
Categories: Uncategorized

Disclaimer: As with everything else at NetIQ Cool Solutions, this content is definitely not supported by NetIQ, so Customer Support will not be able to help you if it has any adverse effect on your environment.  It just worked for at least one person, and perhaps it will be useful for you too.  Be sure to test in a non-production environment.

2 Comments

  1. By:brentrockwood

    This page explains it.

    http://msdn.microsoft.com/en-us/library/aa374868(VS.85).aspx

    In a nutshell, an access control entry is a single element in an access control list.

  2. By:geoffc

    Thanks for that. I guess I knew that distinction. An ACE is one entry an in ACL. Ok.

    Now how can we get access to read and manipulate the ACL and thus child ACE’s via the AD driver. :)

    No doubt we could do it in a Scripting driver.

    As for the bug itself, Bugzilla seems to implied it is fixed in IDM 4. Now patches for the ADDriver have been back ported for the last while, so the same ADDriver works on IDM 3.5, 3.5.1, 3.6 and 3.6.1. I am hoping the same will be true with IDM 4, and thus that the next patch to the AD driver would be from the IDM 4 codebase and include this fix, but I have no evidence to support this.

Comment