Use case

Some customers want to use an administrator account only for "elevated" tasks, much like how unix systems support the concept of "sudo".  In addition, unix systems are commonly configured to block direct logon by administrator accounts.  The established procedure is to log on with an unprivileged user, and then elevate tasks with the "sudo" command where necessary.

There is not an exact mapping of these concepts to the Windows environment.  Microsoft made some steps in this direction with User Account Control.  Also, the "run as" command allows a similar behavior pattern as the unix "sudo" (although not identical). 

Since many customers have best practices to avoid use of admin accounts wherever possible, let's explore whether we can allow an account to be used with the "run as" command, but block that account from logging in interactively to the desktop.

Internals

Authentications to the Windows desktop (whether via console or Remote desktop access) are known as "Interactive" logons.  Group policy allows us to restrict who can log on interactively, but this same policy also controls use of the "run as" command.   (Windows uses the same logon type when you establish a secondary authentication, even though no additional desktop is shown.)  Thus, there's not any direct way (via policy) to restrict one, but not the other. 

Group policy does allow a user account to have a different "shell" specified (the normal shell is "Explorer.exe").  We can use this feature to force an interactive session to log off immediately instead of displaying the Windows desktop.

Procedure

  • Create or select an Organizational Unit that will hold your logon-restricted users.
  • Move users into the group (if necessary).
  • Create a group policy object and apply to the OU
  • Edit the group policy object.  Navigate to: 
    User Configuration > Policies > Administrative Templates > System
    and set the policy named "Custom User Interface" to "logoff.exe"
  • Note that this policy will not apply immediately; you will need to use "gpupdate" on your systems if you intend to test right away.

Cautions

  • Use only true group policy for this setting.  Do not apply this policy using the "Local" group policy object of specific machines, because it will then apply to all users.  Effectively, no users will be able to log on to the machine (which is probably not what you want).
  • If you apply this policy to domain admin user accounts, make sure to also change the policy that allows only Administrators to authenticate to domain controllers.  Otherwise the only users allowed to log on to the DCs will immediately be logged off (which is probably not what you want).

Limitations

The purpose of this procedure is only to guide the behavior of legitimate users by preventing the inadvertent (or lazy) use of their elevated account for desktop sessions.  It does not restrict what an attacker or malicious admin can do with their credentials.  Recall that authenticating to the interactive desktop is not necessary in order to change any setting, including changing their shell back to "explorer.exe".

It is still important, therefore, to secure administrative users with 2-factor credentials.