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

Reply via email to