3

I'm implementing security restrictions for a client who would like to prevent admin accounts from logging into workstations.

For example each person has a user account and an admin account and only the user account should have access. The admin account is for troubleshooting purposes and for escalating privileges to resolve issues.

If I deny Interactive Log-on for the admin accounts, then the ability to use them for Run As is also removed. I also looked at "Allow Log on locally" and specifying only normal accounts but that means removing Administrators from Allow Log on locally which causes further issues.

My current recourse is to make a logon script that looks to see if the user is a normal account or admin account and in the latter circumstance start a logout process. Can anyone think of a better way of doing this? We are simply trying to implement least privileged access and ensure the administrators don't login with their admin accounts.

  • This is silly. It shouldn't make any difference whether they log on as a normal user or admin user - either way they get a UAC prompt when they try and escalate. – BlueCompute Sep 30 '14 at 9:08
1

This is really a personnel issue and not an IT problem. If users with administrative privileges can't respect the rules, they shouldn't have administrative privileges.

Even if there was an easy way of preventing an interactive logon, there's nothing to say they can't work around it - for example, they could terminate explorer.exe and re-start it running as their admin user, effectively giving them a full administrative environment. If you give them run as, you give them everything.

  • I suggest that tfrederick74656 not answer if he works in a world were all are honest. I do not live there and need to trust but verify. Your answer is no help to those that need assistance. – user514368 Mar 14 at 14:45
  • 1
    You missed the point of his answer. If you were able to prevent logging in with an admin account, that same user could still log in with their non-admin account and elevate using their admin account, and undo the login restriction. Applying restrictions that the user themselves can undo are not effective, and never will be. – longneck Mar 14 at 14:56
  • @longneck Unfortunately that's not the only reason to set up a system like this. You generally don't want to be logged into a machine as admin unless you need to be. Otherwise that opens up various applications you're running, such as a browser, to allowing a vulnerability elevated privileges. Additionally, in some environments, this kind of security design is mandated by policy and not optional. I've presented some alternatives in my answer. – duct_tape_coder Mar 14 at 18:15
0

Sad to say but last time I looked into the same issue it seemed that 'interactive logon' and 'run as' were inextricably tied to each other so that solution was impossible.

Hopefully this is ends up an XY problem for you.

The solution for us ended up being that we were looking at the problem wrong. What was needed was that admins for something else (e.g. domain admin, server admin) were needing to manage those resources from the desktop to which they didn't need admin rights. So we created a separate account (e.g. John.Smith.admin) to manage those resources and gave it logon to the desktop but no admin rights to the desktop.

Another option is to transfer the 'run as' tasks to something else that doesn't need credentials through interactive logon. Windows server management can be done with the new Admin center which is a webpage, linux management can be done with SSH.

If this is instead designed to stop privilege escalation attacks, then you'll need to either force actions through the intended system (e.g. RDP to that server with that credential) or create dedicated admin workstations for that purpose (a workstation that can only connect to a DC for example).

0

Came across a "similar" issue:

We didn't want to provide our service accounts with interactive logon privileges (which I think is standard practice).

However, various applications running on servers were configured using service accounts and modifying them required running the associated tools/ apps with "Run As"; which would fail because Run As is treated as interactive logon.

So, since the servers are all located in the data center, to which physical access is controlled, we removed the service accounts from remote desktop users and then allowed interactive login.

This should be a good enough compensatory control.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.