|
I’m curious, Al, as to what you mean
about .NET not handling group memberships well… do you mind elaborating
on that (can be a separate thread)…? Thanks! Dan From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe 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 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 No. -- From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Grillenmeier, Guido 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 > 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 didn’t 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 can’t 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
