|
As Al indicated interesting thread, my
comments
1. I don't see the reason not to do this. I like it
and think it is a good idea. The point I would start to reconsider is if
you do a lot of deleting and creating, saying in a test lab, this may make your
DIT grow out of control. Also if you have an excessively long TSL it may not be
optimum as well. Otherwise, I think this is extremely useful and MUCH easier
than following the auth restore processes which are, frankly IMO, rather
involved for what it is. That is why people are willing to shell out so much
money for third party products. I agree this should be a very rare thing to do,
but if would be willing to do an auth restore to get something back, I think
being willing to do this first makes more sense.
2. As Guido mentioned, this doesn't work for everything. Be
aware of what it does and doesn't work for PRIOR to hoping it saves your butt on
something. For the things that it doesn't work for, it shouldn't be too terribly
hard to set up an AD/AM instance or a DB to maintain the info you want
repopulated. The really hard things are like objectSID, ObjectGUID, sIDHistory,
etc as you can't easily put those back into place.
3. I am with ~Eric and I don't see where password is
being kept. I have also been over that section of the source and don't recall
anything with passwords. It also doesn't appear the password attributes are
marked in the schema either. Are we
sure passwords are being kept? I admit to not trying it. I really haven't done
much with SP1 yet due to the Virtual Server guest bits blunder. The docs I have
seen mention sIDHistory but not the password attributes (there are several
password attributes that would need to be
saved).
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al Mulnick Sent: Tuesday, July 12, 2005 9:08 AM To: [email protected] Subject: RE: [ActiveDir] Keep existing attributes from users restored. Interesting thread.
I've always been a fan of keeping the information separate for this
situation. I need the sid in order to allow the user to access the
resources he had prior to accidental deletion (that's another thread :) but
otherwise, I wouldn't want password for a user I restored. That would be
very dangerous in my mind as it could allow a rogue admin (yet another thread
right?) access to resources that purposefully deleted users had and they'd be
able to do so in a relatively covert manner. They'd be hard to track for sure.
Additionally, restoring the user to groups
could be a nightmare. I'd prefer to keep that information in a separate
off-line format (text file? db?) where I can report against it and use it to
breath life into a reanimated user should the need absolutely arise.
I'm a huge fan of setting up process to do
as much as possible to prevent the accidental deletion of users at every turn.
My thoughts are that those shops with the wherewithal to set the schema mods,
aren't the ones that need an undelete in most cases, but good processes are
always a good idea.
Still, the odd accident can occur. I
realize that. Now I'm just not sure that taking the time to practice
against such a thing is worth the effort of practicing this on a regular basis
to make sure you don't mess it up. Besides, you'll have to restore
the other information anyway, so you may as well get what's absolutely needed
(sidHistory should be in that list IMHO) but plan to get other
information (fax #? Phone #, group information, nickname, petname, etc)
separately. To try and hold it in deleted items would be more of a PITA
due to replication than it would be to store it out of band for other
uses.
My $0.04 (USD) anyway.
Al
P.S. if you use .NET to write an app to
suck the data out to an off-line storage medium, be aware that it doesn't
natively handle group membership very well. Trust me, that's important
;)
From: [EMAIL PROTECTED] on behalf of Dean Wells Sent: Mon 7/11/2005 5:36 PM To: Send - AD mailing list Subject: RE: [ActiveDir] Keep existing attributes from users restored. No.
-- http://msetechnology.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Grillenmeier, Guido Sent: Monday, July 11, 2005 5:05 PM To: [email protected] Subject: RE: [ActiveDir] Keep existing attributes from users restored. thanks for the useful information, Eric. You've only
mentioned sidHistory - does the same apply for the password?
/Gudo From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Fleischman Sent: Montag, 11. Juli 2005 16:45 To: [email protected] Subject: RE: [ActiveDir] Keep existing attributes from users restored. > BTW, Win2003 SP1 has updated some search flags, so as to add the SIDhistory and Password attributes to the tombstone (I believe this > is only valid for new installation of AD).
Actually, not quite. For sidHistory, the SP1 change in behavior works for existing installations juts as well as existing ones. However, to be safe, we didnt actually modify searchFlags. Instead, we added sidHistory to the list of attributes we always preserve on tombstones no matter what the schema tells us we should (there is a list so that you cant subvert replication and strip off more than should be allowed). This was deemed safer than modifying your schema out from under you on SP upgrade. I tend to agree. This of course leads to the fact that non-SP1 DCs will strip sidHistory where SP1 will keep it. This was well understood, but we did not want a schema change for SP1. So we figured, it was this or wait for Longhorn. We went with this as being better than nothing.
~Eric
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Grillenmeier,
Guido
realize that this search-flag can't be applied to all attributes (e.g. linked attributes such as member/memberOf) => as such you will always require a combination of actions to successfully recover users to a previous state. If you do want to leverage the tombstone reanimation feature of 2003 (such as leveraged by SysInternal's adrestore), you'll have to have mechanisms in place to recover attributes which you can't contain in the tombstone object.
BTW, Win2003 SP1 has updated some search flags, so as to add the SIDhistory and Password attributes to the tombstone (I believe this is only valid for new installation of AD). These are the ones that other third-party tools which help with re-populating the missing attributes can't rewrite after tombstone revival occures => as such I would certainly consider changing these search flags in other AD implementations, which leverage restore tools that also use the tombstone reanimation method.
/Guido
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of TIROA
YANN Thanks Dean,
I will test it.
Cheers,
Yann De:
[EMAIL PROTECTED] de la part de Dean Wells <Resent
for clarity, odd formatting in previous post ... at least on my
end> |
Title: RE: [ActiveDir] Keep existing attributes from users restored.
- RE: [ActiveDir] Keep existing attributes from users re... joe
- RE: [ActiveDir] Keep existing attributes from use... Dan Holme
- RE: [ActiveDir] Keep existing attributes from use... Grillenmeier, Guido
