agreed on most of what you say, Eric. it's just that many companies don't have a full fledged provisioning service today, which takes care of all the group-links etc - especially when regarding groups used to manage file-systems. Ofcourse this could be extended, if the sytem itself is inplace.
I've worked with quite a few ISVs on this and none took the described approach - all either have their own DB where they store the data (I won't mention the details of one "quick and dirty" effort of a vendor to store the backup-data in the SysVol container of AD, as it's no longer available anyways...). They then leverage their DB to fill in the blanks after tombstone re-animation. Others use a copy of a restored DIT file and read the data right from that file - they try to get around the cross-NC links via other methods (such as extra files that contain the relevant data). This still doesn't help with restoring SID-History or an account's password, as the one can't be written (assuming orginal object of SID is gone) and the other can't be saved in their DB in a way that it can be applied via a normal API. So you're stuck anyways with the necessity to change the search flag on various attributes to allow "full" recovery using tombstone reanimation - so it's not so far away to try to get the rest as well. Not to say that I don't link the third party tool (which I do very much and I encourage anybody to have a look at them as they can be a real life saver), but you can also achieve a lot with a script and some schema changes to fully reanimate/recover natively. BTW - I'd be interested to see any solution which has gone down this solution path. So if you have any pointers, just let me know. cheers, Guido -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Fleischman Sent: Sunday, December 05, 2004 6:24 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Restore AD Yes Guido what you noted would work well. It has been done before. Someone who has good provisioning might not even care about this in fact. Most linked attributes tend to be provisioned by the nature of what they are used for (group memberships, manager, etc.) and therefore tend to be able to be recreated from your provisioning solution so long as your provisioning solution has a retention period upon object deletion. Extending your provisioning solution to do them all is probably worth your time if you do "most" already. I would note, if you were already sync-ing out a lot of data, I would be inclined to only extend the schema to keep those attributes which are non-trivial to bring back (sidhistory, secret data, etc.) and just let the sync populate the rest back. That way you get your DIT space preserving in the average case, and repopulate in the rare. Perhaps one could call my statement a "better than good" approach. :) And of course, none of this is new. This is what I'm sure the ISVs that offer this service today do already (though I will admit I have never tried their products). You can re-implement it, but note that this is a RE-implementation, not an original implementation. :) ~Eric ________________________________ From: [EMAIL PROTECTED] on behalf of Grillenmeier, Guido Sent: Sun 12/5/2004 6:55 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Restore AD it's important to note, that adding sIDHistory to a reanimated object via DsAddSidHistory won't work, if the original object to that SID is no longer available (e.g. from domain, which has been shutdown in the meantime). A good approach would be to add further attributes to keep in the tombstone (this would also allow to keep the PW) - basically you could add all the object's attribute in the tombstone for easier recovery (will naturally have an impact on the available whitespace in the database), but you can't do this for linked attributes (e.g. the member/memberOf attribute). This doesn't mean, that you can't extend the schema and do a nightly "backup" of all linked objects (pref. via their GUIDs) for an object to this attribute on the object itself (this again will have an impact on db size). The challenge with cross-NC links remain, but could be solved the same way. You could then leverage this information after tombstone reanimation to get everything back => this will require additional rights to the target objects which must be updated (e.g. groups where the membership needs to be readded - especially in other NCs). I've never implemented it this way, but have been thinking about it quite a bit ;-) /Guido -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Fleischman Sent: Sunday, December 05, 2004 1:12 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Restore AD To be clear, they don't "mimic" tombstone reanimation, they probably leverage it. Tombstone reanimation should probably be thought of as a powerful API applications can leverage, not a solution itself. Through tombstone reanimation one can bring an object back to life with properties that could not otherwise be restored (SID, GUID) such that you can repopulate other attributes as you see fit. This is not to say repopulation is trivial.....think about linked values in other NCs in the forest.....but it is doable. The approach some apps might take (I'm speculating, I have not written one) is to sync out of the forest data the user wishes to be able to restore, then upon deletion they can use tombstone reanimation then recreate the lost data. ldifde can do *most* of what you want, so long as you wrap it up right. Some of the caveats that come to mind: 1) One may need to touch many naming contexts so as to properly restore the object to the original state 2) Secret data need be considered, if it is lost 3) sIDHistory need be added through a method other than ldif (DsAddSidHistory) But think through what needs to be done....if you delete user1 then restore that user, you don't want to just restore that user....you also want to "touch" the forward links which point to that user and recreate them too. That implies your ldif export can't be used as is but rather you need to parse out the appropriate forward links and recreate them, not the objects which they are attached to. My $0.02, just some offhanded thoughts. ~Eric ________________________________ From: [EMAIL PROTECTED] on behalf of Bryan Zink Sent: Fri 12/3/2004 2:44 PM To: [EMAIL PROTECTED] Subject: Re: [ActiveDir] Restore AD I've seen third party "recovery" consoles that mimic tombstone reanimation. They do this by maintaining a recent copy of all the attributes of all user/group objects. As far as specific products, why not try something simple like making an LDIFDE or CSVDE dump of your user and group objects part of a nightly system state backup? The biggest issue with recovering SIDs is making sure your tombstone lifetime is sufficiently long enough to cover a deletion that occurred "a long time ago". ----- Original Message ----- From: "Shawn Hayes" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, December 03, 2004 2:01 PM Subject: [ActiveDir] Restore AD Why is it that MS hasn't added a deleted Security Principal retention for AD much like Exchange Server's deleted mailbox retention? Wouldn't that greatly simply recovering from small mishaps? I am not talking about the tombstone feature with Windows 2003 AD where you still have to manually recover Group Membership when recovering an account, but something actually intelligent and useful that would restore Group Membership when restoring accounts. Shit, recover a Group from Deleted Security Principal retention and have it add the back links to the memberof attribute of the users that were members of the Group before the Group was deleted. Recover an OU and it restores Security Principals and Members and Memberof attributes of all Security Principals within the OU. Anybody heard of something like this coming down the pike? Shawn Hayes MCSE (2003, 2000, NT) Messaging Systems Engineer City of Virginia Beach (757) 219-2057 List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
