|
thanks Eriic for lending me that i - I've just added
another one to your name so you won't have to miss out on one in your next mail
;-)
ok - I've just checked myself as well - keeping the
password was more like wishful thinking as I've planned before to change the
searchFlags to keep it since it's another one of those attributes you wouldn't
be able to store offline => however, I do agree it's not critical.
Though even that statement certainly "depends" => if you
just have to recover a single user or a few, you wouldn't worry about the
password and simply set it after tombstone reanimation. If you have to recover a
whole OU with many users, setting the PW and communicating it to the users could
be quite a pain-point. As such - if you can't recover it online (i.e. via
tombstone reanimation), I'd actually vote for the native auth.-restore to get
back as much as I can (and then tackle to repair the missing links
etc.)...
Towards what Al wrote: I don't see recovering users with
passwords more of a security risk than recovering them without the password
=> this is not a process that normal users can perfom anyways and a service
admin has a multitude of options to circumvent AD security. And since the PW
won't ever be readable, I don't really see the point.
/Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Fleischman Sent: Dienstag, 12. Juli 2005 00:09 To: [email protected] Subject: RE: [ActiveDir] Keep existing attributes from users restored. Having been in this
code before, I never noticed this applying to passwords. I dont believe we keep
them on tombstones today. Can you confirm that we
do in fact keep them on tombstones as of SP1? If so Ill take a peak at this in
further detail to see if there is some magic there that I just didnt pick up on
last time through. But I didnt think we did. ~Erc (Wheres did the i in
my name go? Well, when you replied in the last mail, you forgot the i in your
name, so Ive taken it out of mine so you can borrow it for your next
reply.) 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 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
