[duxhelp] Re: Should we allow power users to activate?
- From: "Peter Sullivan" <peter@xxxxxxxxxx>
- To: <duxhelp@xxxxxxxxxxxxx>
- Date: Mon, 24 Apr 2006 10:27:53 -0400
Michael,
You raise two good points. The first is one that we've already addressed.
DBT should, by design, limit deactivation to users running on the machine
that is itself activated. That is, when you have client machines that
obtain activation from a server, the clients should not be able to
de-activate the server (or, for that matter, to activate it), even with
administrative rights. George Bell recently reported an apparent defect,
such that this limitation may not presently be enforced. But, rest assured,
that is the intent, and it will be the case with shipping software. You
won't have to worry about any user de-activating the setup for all of your
users, unless that user happens to be running on the server machine. Our
working assumption has been that you'd limit access to the server.
Now your second point is, to me, more interesting.
I'm not sure whether you've explored "Auto Activation". When you "push" an
installation out to many client machines, DBT itself is not actually run.
This has two important implications:
1. DBT will not be activated.
2. The Embosser Setup Wizard will not have been run.
Activating DBT ordinarily requires Administrative rights. However, if you
opted, while creating your network installation image, to allow "Auto
Activation", then in fact any non-restricted user can already activate DBT.
The activation happens automatically when DBT is first launched. This is
intended specifically to facilate such "broadcast" installations. Each
machine, as it activates, supplies our activation server with its "Computer
Name" (without the domain suffix). This way, if there is any difficulty
with the activation later on, we can locate the activation record based on
the Computer Name.
When DBT first runs, it will also ordinarily run the Embosser Setup Wizard,
unless:
1. You have opted to replicate embosser definitions from the network
installation image, or
2. Embosser definitions can be migrated from an earlier version of DBT.
Usually, Power Users have sufficient rights to get through the Embosser
Setup Wizard just fine. The exception is when you have an Index embosser
without Index drivers installed. In this case, DBT will offer to install
the drivers for you. But this, as you know, generally requires
Administrative rights.
The need to activate and the possible need to install Index drivers are the
two reasons that DBT's installer offers to launch DBT for you when it is
finished, because these tasks can require Administrative rights. Activation
can be achieved instead by enabling "Auto Activation". Index driver
installation, if required, is best handled by separately installing the
drivers before installing DBT, if you intend to "push" installations onto
client machines.
That's pretty much the whole story. We'll keep your comments about
de-activation in mind.
- Peter
-----Original Message-----
From: duxhelp-bounce@xxxxxxxxxxxxx [mailto:duxhelp-bounce@xxxxxxxxxxxxx] On
Behalf Of Michael Surato
Sent: Monday, April 24, 2006 9:24 AM
To: duxhelp@xxxxxxxxxxxxx
Subject: [duxhelp] Re: Should we allow power users to activate?
It all depends. In the setup here we have a central system (run as
administrator) and several clients (run as users). In this setup I would not
want anyone as users activating or de-activating the software since this
will effect all of the clients. However, in a single system setup, I would
probably want to allow users to activate, but not de-activate.
This will allow me to push the software out via policy, but not to allow a
semi-technical user to de-activate the software maliciously. This is
assuming that this is a multi-user system where the un-install routine
deactivates the software automatically as an administrator. A single user
system is assumed to have administrator privileges, and thus a moot point to
discuss.
Does anyone else have thoughts on this?
+-------------------------------------------+
| Michael Surato |
| Resource Center for Persons |
| with Disabilities |
| Michigan State University |
| 120 Bessey Hall |
| East Lansing, MI 48824 |
| Voice: (517) 353-9643 Fax: (517) 432-3191 |
+-------------------------------------------+
> -----Original Message-----
> From: duxhelp-bounce@xxxxxxxxxxxxx
> [mailto:duxhelp-bounce@xxxxxxxxxxxxx] On Behalf Of Peter Sullivan
> Sent: Monday, April 24, 2006 9:06 AM
> To: duxhelp@xxxxxxxxxxxxx
> Subject: [duxhelp] Re: Should we allow power users to activate?
>
> Michael,
>
> Presumably so. But you can let us know if you think that is a bad
> idea.
>
> - Peter
>
> -----Original Message-----
> From: duxhelp-bounce@xxxxxxxxxxxxx
> [mailto:duxhelp-bounce@xxxxxxxxxxxxx] On Behalf Of Michael Surato
> Sent: Monday, April 24, 2006 8:55 AM
> To: duxhelp@xxxxxxxxxxxxx
> Subject: [duxhelp] Re: Should we allow power users to activate?
>
> Would this allow anyone with this access to deactivate?
>
> +-------------------------------------------+
> | Michael Surato |
> | Resource Center for Persons |
> | with Disabilities |
> | Michigan State University |
> | 120 Bessey Hall |
> | East Lansing, MI 48824 |
> | Voice: (517) 353-9643 Fax: (517) 432-3191 |
> +-------------------------------------------+
>
>
> > -----Original Message-----
> > From: duxhelp-bounce@xxxxxxxxxxxxx
> > [mailto:duxhelp-bounce@xxxxxxxxxxxxx] On Behalf Of Mike Gorse
> > Sent: Friday, April 21, 2006 1:45 PM
> > To: duxhelp@xxxxxxxxxxxxx
> > Subject: [duxhelp] Should we allow power users to activate?
> >
> > We are considering allowing users to activate if they have write
> > access to features.ini (this would have the effect of
> allowing power
> > users to activate unless the administrator has customized the
> > permissions on it). This would, in some cases, remove the need for
> > the administrator to run DBT after installing it in order
> for it to be
> > activated for other users.
> >
> > Is this what people want?
> >
> > -Mike
> >
> > * * *
> > * This message is via list duxhelp at freelists.org.
> > * To unsubscribe, send a blank message with
> > * unsubscribe
> > * as the subject to <duxhelp-request@xxxxxxxxxxxxx>. You may also
> > * subscribe, unsubscribe, and set vacation mode and other
> subscription
> > * options by visiting //www.freelists.org. The list archive
> > * is also located there.
> > * Duxbury Systems' web site is http://www.duxburysystems.com
> > * * *
> >
> * * *
> * This message is via list duxhelp at freelists.org.
> * To unsubscribe, send a blank message with
> * unsubscribe
> * as the subject to <duxhelp-request@xxxxxxxxxxxxx>. You may also
> * subscribe, unsubscribe, and set vacation mode and other subscription
> * options by visiting //www.freelists.org. The list archive
> * is also located there.
> * Duxbury Systems' web site is http://www.duxburysystems.com
> * * *
>
>
> * * *
> * This message is via list duxhelp at freelists.org.
> * To unsubscribe, send a blank message with
> * unsubscribe
> * as the subject to <duxhelp-request@xxxxxxxxxxxxx>. You may also
> * subscribe, unsubscribe, and set vacation mode and other subscription
> * options by visiting //www.freelists.org. The list archive
> * is also located there.
> * Duxbury Systems' web site is http://www.duxburysystems.com
> * * *
>
* * *
* This message is via list duxhelp at freelists.org.
* To unsubscribe, send a blank message with
* unsubscribe
* as the subject to <duxhelp-request@xxxxxxxxxxxxx>. You may also
* subscribe, unsubscribe, and set vacation mode and other subscription
* options by visiting //www.freelists.org. The list archive
* is also located there.
* Duxbury Systems' web site is http://www.duxburysystems.com
* * *
* * *
* This message is via list duxhelp at freelists.org.
* To unsubscribe, send a blank message with
* unsubscribe
* as the subject to <duxhelp-request@xxxxxxxxxxxxx>. You may also
* subscribe, unsubscribe, and set vacation mode and other subscription
* options by visiting //www.freelists.org. The list archive
* is also located there.
* Duxbury Systems' web site is http://www.duxburysystems.com
* * *
Other related posts:
