Active Directory in Longhorn...Feature Feedback Requested

Active Directory in Longhorn...Feature Feedback Requested

  • Comments 9
  • Likes

 

One of the most time consuming, aggravating and emotionally draining issues our customers can go through is a disaster recovery issue.  The general gyst of this type of thing is:

 

-Accidental deletion of <insert terrifyingly large number here> users, groups or other objects in AD

-Mad scramble to immediately hinder AD replication throughout the enterprise only to realize that…

-AD replication is lightning fast and the deletion has already replicated everywhere.

-Simultaneous throbbing headache along with realization that you will likely be up all night recovering these objects and verifying that they are in good state.

 

Not a pretty picture is it?

 

Longhorn has planned features to help with that.  With a bold statement like that though I must give a caveat:  Longhorn Server is currently beta, and beta means incomplete.  Unfortunately, my statements are not law, so the end product can change before the “release to manufacturing” or final RTM version.

 

However, because it is beta the Microsoft Directory Services Community has a unique opportunity to provide feedback.  One of our devs has an idea around the above headache-all-nighter-disaster recovery scenario depicted above.  Hear me out, then weigh in by either emailing me through the blog or posting a comment on the blog.  I guarantee your feedback will be heard by the AD dev team.

 

The first part of the above scenario is key: accidental. Unintentional mass deletion of objects from AD.

 

What if, when viewing the properties of an object (like a user) in Active Directory Users and Computers (DSA.MSC) you had a checkbox that would say something like “prevent accidental deletion”?  Have the check there, and the object cannot be deleted.  Remove the checkbox, delete away.

 

Having this checked on all of your users, or perhaps a critical segment of them, could certainly save someone from an “oops” moment.  On the other  hand, maybe it will prevent some utility you need.  I don’t know…what do you think?

 

Does that sound useful to you?  Sound out!  Let us know. 

 

One other thing.  I'll my next post or posts wil be regarding some features you may see (remember it's beta) in Active Directory for Longhorn.  Don't miss the posts, I promise it's really good stuff.

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • 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.

  • 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.

  • 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!

  • 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.

  • 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.

  • 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

  • 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

  • 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.

  • 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