> I don't consider storing the PW in a tombstone a particularily high risk
I agree with Guido here. I expect I wouldn't think twice about doing this if it came up. When you reanimate even if you set pwdLastSet to be recovered it won't be. It won't be stripped on the tombstoning process, it will be stripped when the object is reanimated. Also the object will be disabled on reanimate. So the user/computer has to be reenabled and unexpired (Set the pwdlastset to -1) to be used, it isn't like you would accidently reanimate and have a fully functioning account. Could be handy to have that old password there for the cases like Ulf said for old computers or Service IDs that you don't want to go change the password in 1000 different places for (not that I like that excuse). joe -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Grillenmeier, Guido Sent: Wednesday, April 19, 2006 4:51 AM To: [email protected] Subject: RE: [ActiveDir] Tombstone attributes it all comes down to: - what are you trying to protect yourself from? - what are your procedures or tools for restoring the objects? - what are the risks involved and potential costs for recovery? protecting from accidental deletion of a single object is different from trying to protect yourself from accidental mass deletions (such as a whole OU containing many hundred or thousand objects). Planning recovery in a single-domain forest is different from planning recovery in multi-domain forests. Planning to use online recovery tools (tombstone reanimation) is different from planning to recover objects using the native recovery options (systemstate restore + NTDSUTIL authoritative restore). A combination of both approaches (online recovery + native tools) could be the right answer => no matter what tools you use, you'll always want to perform system state backups of at least 2 DCs in every domain anyways to be on the safe side and be prepared for a true forest recovery. But you couldn't care less to reboot a DC just to recover a single or very few objects (depends on size of your environment and if you have deliberately planned a "recovery" DC that's not used by users or apps). Online recovery tools do a perfect job of recovering these objects - and if it's only a few, then you're fine with setting the PW at recovery time. Logistics is the main pain here: you'll have to tell the recovered user the new PW so that he can logon again - and as Ulf mentioned, you'll have to rejoin computer accounts to the domain if you plan to recover them online as well, but for a few objects, this could be acceptable (yet painful). When planning recovery of accidental mass deletions, you could argue to do this via the "native" way, restoring a DC from a sys-state backup and performing an auth. restore. And since the PW is obviously stored in the sys-state backup you'll get (almost) everything back (ofcourse, you'll have the same trouble with passwords that just expired or that a user had just changed after doing your backup...). But in general, users' passwords will be recovered just fine and computers actually leverage the last two passwords during authentication so in general there's no issue with expired computer passwords either. You're main challenge with using the native tools now lies in correct recovery of the links between the various objects you've just restored - this is particularly painful for multi-domain environemnts. On the other side, if you plan to use the online recovery tools for mass recovery, you'd certainly wish to have the password in the tombstone since otherwise this would be a logistical nightmare - yet the tools to handle link recovery in multi-domain environments just fine, which is a big painpoint when recovering natively. So it's up to you to weight the risk of storing passwords in tombstones to allow easier recovery - or to choose native recovery when recovering from mass deletion. I don't consider storing the PW in a tombstone a particularily high risk - especially if you weight it against the cost you have to recover things correctly the native way. Realize, that you don't need to store all the PW related attributes, only Unicode-Pwd is required to successfully restore the PW (and using most online recovery tools you could still choose to have the user reset his PW at next logon). Some of this is discussed in more detail in the following guide: http://www.netpro.com/media/pdf/NetPro_ADDR_Guide.pdf /Guido -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tomasz Onyszko Sent: Mittwoch, 19. April 2006 00:43 To: [email protected] Subject: Re: [ActiveDir] Tombstone attributes Ulf B. Simon-Weidner wrote: > Unfortunately the passwords is the same attribute for users and computers. I > thought recently to put the password in the tombstone to ease computer > account reanimation - after the account is deleted the computer is not able > to change it's password, and if it was deleted accidentally it's easy to > reanimate the account and the computer will still be happy. > > I know that it'll be easy to put the computers in the domain again, however > I've had a customer with hundreds of sites which lost a couple hundred > computer accounts across those sites, and bandwidth didn't allow to remotly > script the addition of the computer accounts to the domain via netdom. We > were able to perform an authoritative restore, and were lucky that we lost > almost no computer accounts due to changed password, however this was a > unlikely event with the computers recently joined the newly created domain. > In running domains we'd have to calculate an average of 1/15th of computers > per day of the age of the backup to join manually. > > I agree on user objects - and if I'd decide to keep the password for > computer account in the tombstone I'd would prefer to put a procedure in > place to change a users password before deleting it. > Jup, I can agree with it - but still I don't like idea of restoring the user with old password. What about password age and complying with security policy - I can imagine situation in which user's password was 89 day's old (wit 90 days maximum password age), then was deleted an restored - password will be valid for another 90 days. What about complexity requirements ? -- Tomasz Onyszko http://www.w2k.pl/blog/ - (PL) http://blogs.dirteam.com/blogs/tomek/ - (EN) List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
