I always preferred the two-key system personally.
Ben's a very smart guy but in this case I think he's being
a bit shortsighted - this solution lacks practicality in many if not most
enterprise environments. As Deji points out, if you need that password for some
reason in New York, you also have to start changing services in Zimbabwe, and
you just might not want or even be able to do that right
now.
With the two-key approach two highly trusted folks each
enter a half, and write their half down on a piece of paper and seals it in an
envelope. Both envelopes are then escrowed somewhere very secure - safety
deposit box for example. When they are unsealed for whatever reason (one
key holder is unavailable for example) then the password will need to be
changed, usually during the next available scheduled outage
window.
On a
slightly related note, though, I prefer to use a less obvious name for service
accounts then SRVACCT - a little obscurity never hurts
either.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Deji Akomolafe
Sent: Thursday, September 30, 2004 2:49 AM
To: [EMAIL PROTECTED]
Subject: RE: [ActiveDir] Password Policy question
>>>If
you need to access it, just change it (as above) since you should have a process
in place to change those on a reqular basis anyways.
I don't understand the logic
of this recommendation. I have an account called "SRVACCT" with a
gazillion-length password. I use it to configure certain services on 30 or so
servers. I now want to use this account for another service on a new server, so
I change the password (because I couldn't memorize the old one). Now I have
services on 30 other servers that I have to manually touch and reconfigure. I
hope I am fast enough so that those services don't start failing. I also need to
pray very hard that I haven't forgotten to reconfigure one service on one
server whereby I now get constant lockout of this account because of invalid
login attempts.
The logic of this idea will
probably come to me in my sleep or the next time I sit under the apple tree
;)
Sincerely,
D�j� Ak�m�l�f�, MCSE MCSA MCP+I
D�j� Ak�m�l�f�, MCSE MCSA MCP+I
Microsoft MVP
- Directory Services
www.readymaids.com - we know
IT
www.akomolafe.com
Do you now realize that Today is the Tomorrow you were worried about Yesterday? -anon
www.akomolafe.com
Do you now realize that Today is the Tomorrow you were worried about Yesterday? -anon
From: Ulf B. Simon-Weidner
Sent: Wed 9/29/2004 11:03 PM
To: [EMAIL PROTECTED]
Subject: RE: [ActiveDir] Password Policy question
Hi Steve, Usually service accounts should be treated more sensitive than reqular user accounts since they are more exposed to threads (they are configured on multiple machines, mostly including the least trusted machine, and in many environments they have way more rights than necessary). Ben Smith at MS once suggested to create a random password with 127 chars length, copy and paste it wherever you need it and don't bother to keep it somewhere safe. If you need to access it, just change it (as above) since you should have a process in place to change those on a reqular basis anyways. Gruesse - Sincerely, Ulf B. Simon-Weidner MVP-Book "Windows XP - Die Expertentipps": http://tinyurl.com/44zcz Weblog: http://msmvps.org/UlfBSimonWeidner WebSite: http://www.windowsserverfaq.org > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Steve Schofield > Sent: Thursday, September 30, 2004 4:37 AM > To: [EMAIL PROTECTED] > Subject: Re: [ActiveDir] Password Policy question > > Thanks Darren/Douglas > > Its amazing such a simple concept can raise so many > questions. This question was really just pertaining to > strictly to admin, service type > accounts. Through some further research, the ONLY way to > really achive > what I want is to protect service accounts from being > affecting by the password policy is have them reside in > another domain inside the forest. > Dealing with 80k users, a password policy and service > accounts can cause > headaches when trying to fully implement. Ole well security > is a journey, > not a destination. Thanks for the help. > > Steve > > > ----- Original Message ----- > From: "Darren Mar-Elia" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Wednesday, September 29, 2004 10:01 PM > Subject: RE: [ActiveDir] Password Policy question > > > Also, keep in mind that password policy is a machine policy, so in any > case, its not being applied to user accounts--but rather machines. In > the case of domain password policy, the machine(s) actually processing > the password policy settings are your DCs, which of course house your > domain accounts. And, it is an all or nothing thing, so even if you > wanted to filter the GPO by user account, you really couldn't. > > ________________________________ > > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Douglas M. Long > Sent: Wednesday, September 29, 2004 6:00 PM > To: [EMAIL PROTECTED] > Subject: RE: [ActiveDir] Password Policy question > > > The password policy is a domain wide thing. You cant restrict it to > certain OUs. Whatever you set it as is what it will be. Would > be helpful > to apply it to certain OUs, but password policies are there to protect > the entire environment, so objecst that would not be using the same > policy would be opening you up (that is why it is a domain wide thing) > > ________________________________ > > From: [EMAIL PROTECTED] on behalf of Steve Schofield > Sent: Wed 9/29/2004 8:13 PM > To: [EMAIL PROTECTED] > Subject: [ActiveDir] Password Policy question > > > > We've implemented a domain wide password policy using the > default domain > policy, this applies to authenticated users. One question Im not sure > about > is I have an OU that all Admin id's and service accounts reside in, > We've > applied block inheritance on this OU but the Default Domain Policy is > still > being applied and password restrictions are being enforced. This might > be my > mis-understanding but shouldn't block inheritance stop this from > applying to > the user 'ids in this OU? > > Steve > > 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/
