Active Directory in Longhorn...Feature Feedback Requested

re: Active Directory in Longhorn...Feature Feedback Requested

JamesR2 — Thu, 08 Feb 2007 16:57:15 GMT

Quick thought ... how about a recycle bin where the objects are moved. They are full attributes, but inactive, with a retention of a few days or so. I am still thinking.

re: Active Directory in Longhorn...Feature Feedback Requested

Twark — Thu, 08 Feb 2007 19:12:15 GMT

This idea seems really nice. We recently had one of our domains that deleted an OU by accident. They had to perform an authoritative restore of the given subtree. Even if there are currently two warnings, it does not seem enough, sadly.

I think, the major risk is deleting an OU and its subobjects. It would be interesting to have an option valid for the whole domain, which would prevent deleting OUs, comp. and/or user objects rather than having to activate manually the option on each AD object I'd want to protect.

Another hint would also be to prevent specifically mass deletion, by having an option which would forbid deleting an object that contain subobjects.

Also, would this option be checked by DSA MMC only, or directly on AD ?(it could also be interesting to lock unwanted mass deletions by bad scripts!). However, even if it protects only the MMC, it would be great.

re: Active Directory in Longhorn...Feature Feedback Requested

Tim Springston — Thu, 08 Feb 2007 20:30:16 GMT

I wanted to add something based on some of the feedback so far. This would work by using a Deny Deletion ACE. As a result, it would cover accidental/unintentional deletions no matter the source or tool it originated from. It's not simply DSA.MSC.

In addition, this would have the added effect of preventing moves between containers (OUs) for those objects since the a move has a delete at the parent.

Keep the feedback coming!

re: Active Directory in Longhorn...Feature Feedback Requested

Tim Springston — Fri, 09 Feb 2007 00:00:49 GMT

I also didn't point out one thing. this doesn't necessarily protect against tree deletes (clicking the OU and choosing to delete it) unless the parent of that OU is selected to "prevent accidental deletion".

Just thought I point that out.

re: Active Directory in Longhorn...Feature Feedback Requested

Jintel — Tue, 13 Feb 2007 12:46:00 GMT

It's a nice idea to prevent accidentally deleting objects however it's nothing that a bit of careful planning of permissions can't sort out in the first place.

As for the restore mechanism, I think there could be some sort of shadow copy service within AD. If you delete an object(s) you could bring up the properties for a OU further up the tree and restore deleted security principles at the click of a button! Infact, that sounds like a great idea.

re: Active Directory in Longhorn...Feature Feedback Requested

ptwilliams — Tue, 13 Feb 2007 19:15:07 GMT

I kind of like the idea of a protected object, but don't think something as simple as a deny ACE is going to be much help. These scenarios are usually the result of a subtree deletion, of which this isn't going to be much help. This is also more of a bandage than a solution.

Adding a delete ACE is an issue as you can't simply move, unless you remove the ACE move and re-add the ACE, which is not without issues (SD replication and additional permissions needed to perform a move).

Although a nice to have, I can't see it working in its current form.

--Paul

re: Active Directory in Longhorn...Feature Feedback Requested

Tim Springston — Wed, 14 Feb 2007 16:48:02 GMT

Thanks for your feedback Paul! True, it does not help with deletions of subtree above, but the idea is to protect top-level subtrees using the checkbox ACE.

And the side effect of not being able to move the object is actually good-if you're in a situation where you may be concerned about accidental deletions.

Tim

re: Active Directory in Longhorn...Feature Feedback Requested

jricha34 — Sun, 04 Mar 2007 19:40:14 GMT

I am not a fan of the idea. I don't think it is comprehensive and it is something that could already be put in place with simple third party tools or careful provisioning/permissioning. Obviously something special could be added in to the permissions like another special validated write right but I think that would be a horrendous idea as well. We don't need to make things more complicated, we need to make things simpler.

The proper solution, something I have recommended in the past a few times is a better deletion implementation. If you go back a few years you should find a DCR or two as well as activedir org posts where I asked for the ability to have a built in staged delete - something configurable based on the desires of the admins....

First stage: Objects initially get moved into a unusable stage but are fully populated. Groups in this state would not get added to user tokens, etc. Recall from first stage would be very simple, you could leverage normal undelete or if you want, have a specific container structure in every NC that is fully blocked from normal use by legacy calls as well as internal DS functions like group expansion, etc which happens with a deleted object now. Either way, current mechanisms could be used to recover object fully without special work. Obviously the tough item here is linked attributes... You don't want these deleted objects showing in non-deleted groups or in manager attributes... or do you? That may be better than just purging the info from those attibutes... Object is in first stage tombstone state.

Second stage: Delete as we see it now, attributes that aren't marked to be retained are stripped. However, change this so the ability to maintain linked attributes is available. Object is in second stage tombstone state.

Third stage: This is an optional stage... To the admin. The idea is that the object is further stripped down to its name, GUID, and SID... (maybe SAM Name for folks not using SAM Name for name) i.e. basic core NOS attributes that cannot be recreated if you have to recreate the user object. Object is is in third stage tombstone state. Make this configurable by object types - i.e. flag in schema. OU's maybe go straight to fourth stage but users/groups go to third stage.

Fourth state: Again, optional stage to the admin. Object is permanently removed from the DS. Like Third stage, this is configurable by object type. Maybe users NEVER hit this stage...

This whole thing again would be configurable by the admins so admins could tweak the environment based on how they use the DS. A test DS for instance could go from object to stage 2 to stage 4. A very conservative company with big DCs though may keep users, computers, groups, etc in Stage 1 for a year or maybe forever. So tombstone times for each stage configurable, object types for each stage configurable. Have the ability to force specific objects through the stages except for fourth stage which would follow the normal scavenging now so we make sure that the object is removed everywhere. Maybe have an attribute called mS-DS-DeletionStage which is an int which users can change between 1-3.

I believe I have written up more on this in the past, but this is the main gist that I recall.

re: Active Directory in Longhorn...Feature Feedback Requested

hilde — Thu, 15 Mar 2007 15:37:52 GMT

I think this is a FABULOUS idea and long overdue. I like the idea of the Recycle bin, too, and have had similar thoughts.

However it is done, making deletes more of a multi-step process would be a welcome insulator from "Uhhhhhhhhh, what happened to the Admins OU????!!!"

GREAT idea - GREAT post - GREAT BLOG!

Hilde