Omgili, forum search, forums search, search forums, discussion search,discussions search, search discussions, board search, boards search, search boards
  Advanced Search

Use restrictec accounts instead of Admin accounts. Problem with runas and deny logon locally

On Wed, 24 Jun 2009 17:17:23 +0200, Eric <...@nospam.hotmail.com

Hello,

we would like to secure the way our users are logging on to their
computers.

Some of them are travelling a lot; others need to launch a specific
application etc... So I was thinking about creating another user
account for each of them who need one and to configure the policy "Deny
Logon Locally".

So they would have two accounts :
1. The normal account "username" used by default and for the basic
needs
2. The admin account "adm-username" with the "Deny logon locally"
applied to this account to restrict the user to open a session with
this account.

BUT...

It seems that the "runas" command cannot work if the account used for
the runas doesnt have the "logon locally" right.

So my question is "How can I prevent the "adm-username" account to be
able to logon locally and in the meanwhile to allow this account to
launch programs as admin ?

Thank you

--
Eric



On Thu, 25 Jun 2009 22:31:36 +0100, "Anthony [MVP]" <...@no-reply.com

Eric,
I can see what you mean. You want the users to be able to use an Admin
password but not to be able to log on with that account.
Vista UAC sounds like it may be the best you can do. That way the user is
prompted for if they really meant to do something, but they are able to do
it if they choose.
I think that is the best you are going to do
Anthony,
http://www.airdesk.com

"Eric" <...@nospam.hotmail.com...
>

On Wed, 24 Jun 2009 20:12:12 +0000 (UTC), Meinolf Weber [MVP-DS] <...@gmx.de

Hello Eric,

If an account is restricted from local logon, how should it work locally?
If you really need some user with local elevated permissions, why not using
restricted groups and make them power users if this will be enough or local
administrator?

Best regards

Meinolf Weber
Disclaimer: This posting is provided "AS IS" with no warranties, and confers
no rights.
** Please do NOT email, only reply to Newsgroups
** HELP us help YOU!!! http://www.blakjak.demon.co.uk/mul_crss.htm


On Thu, 25 Jun 2009 09:50:43 +0200, Eric <...@nospam.hotmail.com

Hello,

thank you for your answer.
The idea is to create a local admin account that will be ONLY available
for the "run as" command and that will not be able to logon to an
interactive session.

Why ?
Because in this situation the user will logon with a basic user account
and only needed applications will be launched with admin priviledges
(via the RunAS command). So, applications like Internet Explorer,
Outlook etc... will not run with admin priviledges.

But ?
But the problem is that I would like to be sure that users will not
logon directly with the admin accounts but it seems that the RunAS
command need the "logon locally right".

So my question is "How can I force users to use only their basic user
account and not the admin account when they logon interactively ?

I hope I am clear enough this time =)

Thanks

--
Eric


On Thu, 25 Jun 2009 17:27:39 -0600, "Al Dunbar" <...@hotmail.com

"Eric" <...@nospam.hotmail.com...

Just to give us an idea, what sorts of applications are being run that need
local administrator privileges? Might you have the option to modify these so
that the can be run by an account with regular user privileges?

Are these users administrators in any other context in your organization? Or
are they regular users that need privileges just in order to run
applications that require elevated privileges?

If they are trusted with other privileged accounts, I'd suspect you would
only need ask them; if they are regular users, a better bet would be to find
a way to make the applications run without elevated privileges.

If you are concerned what havoc they might wreak on a computer or that they
would have access to other user files when logging in with a privileged
account, don't forget that logging in interactively is not the only way
these things can be done.

I think you were clear enough the first time. I'm just not sure that what
you see as your solution is actually possible. It's kind of like the old
story of the unhittable ball and the unmissable bat. Or maybe it's like the
question the little kid asked: "if god can do *anything*, can he make a rock
so heavy that he cannot lift it".

That said, have you tried your applications to see if they can be run by
"power users"?

/Al