One alternative (if this is a 2000 server) may be to install terminal
services on the server in question, in remote administration mode, configure
the RDP connection to allow auto logon, then set up a TS connection for the
user that has the administrative user name and password already entered into
it. The user will not be able to see the password, and when initiating the
connection, will be automatically logged on to the TS server. Note that by
default terminal services does not allow this automatic logon; you must
configure it to do so. If you don't, the user will still be prompted for a
password in the logon dialog box, which would defeat the purpose.

With that said, depending on the application in question, there may be
better ways to allow a user administrative capabilities for the app without
granting him/her administrative capabilities for the machine.

HTH,

Laura Robinson
----- Original Message -----
From: "Harper, Jason (CAP, CARD)" <Jason.Harpergecapital.com>
To: "Michael Leone" <turgonmike-leone.com>; "Gustavo Basualdo"
<guasamanhotmail.com>; <focus-mssecurityfocus.com>
Sent: Tuesday, June 19, 2001 9:51 AM
Subject: RE: sudo for windows

>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> For the sake of correctness, although a bit OT:
>
> Michael Leone Said in regards to SUDO:
>
> I've never seen a sudo implementation (on Linux, anyway) that did NOT
> ask for the admin password. Consider - if it doesn't ask for the
> admin password, that's the same as the admin having NO password,
> since anyone can be admin, with no password.
>
> Actually one of the really nice things about SUDO is that you don't
> use the Root or admin password but *your own*. You can do this if
> you have been added to the SUDOERS group, and it functions as
> described at http://www.courtesan.com/sudo/intro.html which I quote
> here:
>
> Sudo (superuser do) allows a system administrator to give certain
> users (or groups of users) the ability to run some (or all) commands
> as root while logging all commands and arguments. Sudo operates on a
> per-command basis, it is not a replacement for the shell. It's
> features include:
>
> The ability to restrict what commands a user may run on a per-host
> basis.
>
> Sudo does copious logging of each command, providing a clear audit
> trail of who did what. When used in tandem with syslogd, the system
> log daemon, sudo can log all commands to a central host (as well as
> on the local host). At CU, all admins use sudo in lieu of a root
> shell to take advantage of this logging.
>
> Sudo uses timestamp files to implement a "ticketing" system. When a
> user invokes sudo and enters their password, they are granted a
> ticket for 5 minutes (this timeout is configurable at compile-time).
> Each subsequent sudo command updates the ticket for another 5
> minutes. This avoids the problem of leaving a root shell where others
> can physically get to your keyboard. There is also an easy way for a
> user to remove their ticket file, useful for placing in a .logout
> file.
>
> Sudo's configuration file, the sudoers file, is setup in such a way
> that the same sudoers file may be used on many machines. This allows
> for central administration while keeping the flexibility to define a
> user's privileges on a per-host basis. Please see the samples sudoers
> file below for a real-world example.
>
> Although not a Microsoft thing, its nice to see how the other side
> does it.
>
> Cheers.
>
> jason
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGP Desktop Security 7.0.1 Evaluation
>
> iQA/AwUBOy9ZO5rUvXfrws78EQLzxQCg/eUVxSkoKpyuYMXexWrcfiXU96YAoPXm
> mpPT1pMZ7IQ7tyhArpYzllTq
> =G29w
> -----END PGP SIGNATURE-----

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]