What would be the difference between those solutions and smart cards as you see it? You make me think I missed something in the previous conversations.
On 9/7/06, Laura A. Robinson <[EMAIL PROTECTED]> wrote:
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: [email protected]
> 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: [email protected]
> 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
