March is finally here! The walls of snow are melting down quickly here in New England. I can finally see grass! Well ok… it is more like torn up chunks of sod from completely missing the side walk with the snow blower, but it has remnants of grass.
During my hibernation, I remembered some conversations from the past. Mainly they had to do with “discussions” with users about their needs on their systems. They commonly revolved around the requirement of administrative rights on their local workstations. Which of course lead them to believe their current user account was the one that needed those rights. Well most of us in security, as well as many others in the Systems Admin side of things, know that this is bad and should never be granted without a really good reason. But does this mean it isn’t possible to grant these users their wishes? We all know that not all apps are created equal and that some certainly require elevated rights to perform certain types of operations.
But this does not mean they require that the specific user that needs the app, needs those permissions. In a standalone install of Windows, the first thing you are required to do is create a user. Now one would think the user is just a user, but in a workgroup, that user is given local admin rights. Now Microsoft attempts to mitigate escalation of privileges by forcing, even an admin user, to click a box to confirm they want to run something as admin. They call this “User Access Control” or UAC for short. Unfortunately there are many ways to bypass UAC and even disable it completely. Now domain members are a bit different. Unless you put a user into an admin group, they will have normal user level access to machines. This is where we will focus the rest of this discussion.
Sally is a developer, she was brought in as a consultant to work on a project for this Acme, Inc. They are a big fortune 100 company and have pretty strict security policies for user workstations. Sally needs admin rights to run Visual Studio. Sally knows that when she launches Visual Studio with just a regular click, she will only be running in an non-elevated state. Since she needs to do some work in Azure, she knows she needs to run it as an admin. So she right clicks the icon and selects “Run as Administrator”. But rather than just a confirmation box, she receives a logon dialogue. She attempts to enter her credentials and receives an error. She realizes her account is not an administrator of the machine. So Sally calls Bob, her point-of-contact for the project, he tells her to contact the help desk. Eventually after being bounced around different techs, she is told that they cannot grant her access unless she completes form ID-10T. They direct her to Jim who processes the security request forms and approves them from the business side. Sally is a bit upset at this point, so naturally Jim is the new target for her frustrations.
“I NEED LOCAL ADMIN ON MY WORKSTATION OR I CAN’T WORK!!!”
Jim calmly replies “Ok, why do you require this access? Do you need to run an application with those rights?”
Sally, was expecting to get a blanket “NO” from Jim, so she had to regroup with her next response. She explains she needs to run Visual Studio as an admin. Jim quickly googles to see if such a claim is true as he has not run Visual Studio in a very long time. Sure enough, for certain functions to work, VS requires admin rights. After confirming a few other things, he agrees to grant her local admin. He explains the company policy that she will be given a separate ID to use for this access. She understands and fills out the request form accordingly.
A few days later Jim gets a call from Sally who sounds like she is back where she was the first time they spoke.
“JIM! THIS DOESN’T WORK! I CAN’T ACCESS MY PROJECT FILES ON THE NETWORK!!!”
Jim gets the details and realizes since Sally is now running Visual Studio as a different user, she is not able to get to the files because those drives are mapped under her normal account. See when you do a “Run As…” on an application, you now run in a separate profile from the currently logged on user. This can certainly pose a problem when dealing with things like network drives, network printers etc… This is because you are connected using specific credentials that are attached to the user NOT the computer. But all is not lost! You can map drives for your elevated user pretty easily. OK maybe not too easy but it can be scripted. To get drives mapped for your admin ID, you can use the NET USE command from CMD being run as the elevated user. You would do this the same way Sally ran Visual Studio. NET USE is pretty simple.
So the actual command for Sally would look something like this:
net use P: \\SERVER01\vsprojects /user:ACME\Sally *
So the “P:” is the drive letter, and the “*” tells the command that Sally will enter her password to connect. She can also include her actual password, but it is not always advisable since it is shown in clear text. Powershell would probably be the best method to use to automate drive mappings using secure strings for the password. Also there is a chance that she might receive an error about being connected with another account. In that case, she may need to request that her admin ID have similar access to the share as her regular one.
So that is it! Now when Sally goes to Visual Studio as her admin user she should now see the network share when she goes to open a project. She has what she wants, with minimal risk to the company.