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
