Or use smartcards. Laura
> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > [EMAIL PROTECTED] > Sent: Thursday, September 07, 2006 6:35 AM > To: ActiveDir@mail.activedir.org > Subject: RE: [ActiveDir] Separate Administrator password policy > > Why not use certificates or rsa for admin accounts? > IF you have a pki environment that would be my suggestion. > Then only then default administrator account would be > insecure. But that can be mitigated with very long password. > > An other option is to put admin accounts in a separate child > or top domain. > > /petter borling > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > [EMAIL PROTECTED] > Sent: den 7 september 2006 05:54 > To: ActiveDir@mail.activedir.org > Subject: Re: [ActiveDir] Separate Administrator password policy > > Hi Al, > > All good questions. I'll answer here, but if it starts to > get hairy, lets take it offline (same as my post to Susan - I > don't want this to become a deep discussion of our product on > the list). > > > Not to pick, but it occurs to me that you're trying to > complicate the > > problem. While I agree that changing the passwords every 24 hours > > (whatever freq works is likely going to be fine), is not a > bad idea, > > it has the likely problem of being very problematic. This > is similar > > to a push vs. pull paradigm and if looked at that way, you have > > similar issues such as connectivity and reliability. i.e. > how do you > > ensure that the password change was successful if there's a network > outage? Or just a network blip? > > Is it important that you do so is assumed from the previous > > information to date. > > 100% reliability is mandatory in this kind of app. Funny > that you raise push vs. pull, as we have two modes of > operations, called push and pull. > :-) We "push" passwords to server-class target systems > (e.g., AD, mainframes, whatever), and "pull" password changes > from workstations (i.e., the workstations push to the > server). The handshake used ensures that password changes > are 100% reliable - we abort if there isn't a connection, > etc.; and password history is retained just in case something > went wrong anyways. > > > A solution that scales up, down, or laterally is appropriate. > > Something that allows an account to traverse the different sites, > > possibly into the hundreds or even thousands, and allows almost > > instant revocation of the user account with administrative > privileges > > should that become necessary during the course of normal business. > > Scaling is easy enough - just arrange for different devices, > of which there may be tens of thousands, to contact a central > server at somewhat randomized times, and keep trying in case > of powerdown, connection failures, etc. etc. This eliminates > nasty traffic bursts. > > Traversing sites is easy too - use HTTPS to connect to the > central server, and use whatever proxy settings are needed to > "get out." > > Instant revocation is another matter. Our approach provides > for timed revocation on workstations (due to limitations > fundamental to pull mode), and instant revocation on servers > (since push allows for it). > > > Now, if only we had such an technology....... > > We sell it, more or less as described. > > > Some suggestions that come to mind would be everything from a > > "toaster"-like device placed at the client site to a > certificate based > > > credential system come to mind. Hybrid ideas also > entertained. Plenty > > of pros and cons for each, such as the ability to have something > > tangible at the client site that can also be a > multi-functional device > > > and can work semi-autonmously to monitor even if the WAN link goes > > away (different issues can be monitored.) It can also > provide the 8th > > layer with a sense of investment and partnership. Downside is that > > it's more to manage and monitor. But that can be mitigated > by allowing > > > it to be <gasp> sales person installable meaning that if something > > goes wrong with the device, then you roll a salesperson to > replace it. > > > That gives the salesperson reason to have more facetime with the > client and gives a chance to sell more business. > > A service on each client device is probably cheaper than yet > another machine at the client site, if you're managing lots > of small-ish clients... Of course, you pointed to other, > unrelated but quite useful functionality above, such as WAN > link monitoring. > > > The conversation could be longer, but I'm sure that a solution is > > possible that fits many of the criteria defined. Because > the original > > > problem scope is to remove the administrative access, using > a hybrid > > solution that relies on certificates and a toaster item > would be more > > likely. The details and pricing would need to be hammered > out in such > > > a way that the final solution is reliable, inexpensive (drive > > adoption), and easy to use (dumb down the interface such that your > > salesforce or interns could deploy or you could even just drop ship > > one to the client and they could hook it up in 5 steps or less - > > similar to voip device installation in that sense.) > > Personally, I'm not big on appliances ("toasters") -- in the > end they are mostly just cheap Intel/AMD boxes, but without > the hardware support that Dell/HP/IBM offer. Niche market > vendors really can't offer the kind of hardware support that > these huge vendors do. Better for nice guys (yeah, that's > me) to stick to what they *can* do well - specialized > software, and avoid what others do well - local and prompt > hardware support. > > > Just my random thoughts. I haven't really put much effort into it, > > Susan. :) > > Maybe random, but insightful. :-) > > -- > Idan Shoham > Chief Technology Officer > M-Tech Information Technology, Inc. > [EMAIL PROTECTED] > http://mtechIT.com > List info : http://www.activedir.org/List.aspx > List FAQ : http://www.activedir.org/ListFAQ.aspx > List archive: http://www.activedir.org/ml/threads.aspx > List info : http://www.activedir.org/List.aspx > List FAQ : http://www.activedir.org/ListFAQ.aspx > List archive: http://www.activedir.org/ml/threads.aspx List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx
