Summary: Guest blogger, Marc Carter, talks about learning to use Windows PowerShell and reducing security risks.
Microsoft Scripting Guy, Ed Wilson, is here. Today we have back with us guest blogger, Marc Carter. Take it away Marc…
Despite it becoming more and more of a necessity, I’m always surprised whenever I hear about colleagues who have yet to take the opportunity to really get acquainted with Windows PowerShell. What’s not surprising are the initial concerns revolving around security with anything (new) that if not adequately examined can become a stumbling block for those in my network. Like other products and technologies, Windows PowerShell is not immune to scrutiny and misunderstanding, whether due to lack of communication, assumptions, or insufficient understanding.
One of the responsibilities in my role as a sys admin is to evaluate and minimize change introduced into an environment that could potentially compromise information security. One method we implement to reduce that potential in our environment is to employ the Policy of Least Privilege and the Least-Privileged User Account approaches. The following quote about Applying the Principle of Least Privilege to User Accounts is posted on TechNet:
“A defense-in-depth strategy, with overlapping layers of security, is the best way to counter these threats, and the least-privileged user account (LUA) approach is an important part of that defensive strategy. The LUA approach ensures that users follow the principle of least privilege and always log on with limited user accounts. This strategy also aims to limit the use of administrative credentials to administrators, and then only for administrative tasks.”
Windows PowerShell plays a significant role in my ability to adhere to those best practices while allowing me to accomplish the routine and complex duties that are associated with my job. As asserted by Mr. Mike Krieger, U.S. Army Chief Information Officer, “PowerShell is a significant enabler for sys admins. It enables the automation of a significant number of mundane tasks without comprising security. So it improves operational effectiveness and efficiency and maintains same security levels.”
In this blog post, I hope to dispel some misunderstandings that surround concerns over security, and demonstrate how Windows PowerShell lends itself to overcoming those issues. So, let’s take a look at one way we can take advantage of inherit qualities of Windows PowerShell by looking at the Invoke-Command cmdlet.
The Invoke-Command cmdlet runs commands on a local or remote computer and returns all output from the commands, including errors. With a single Invoke-Command command, you can run commands on multiple computers.
Accepted practice for every sys admin in our organization is to log on to their workstation environments with a non-privileged account, lacking elevated permissions on the domain. That account provides credentials sufficient to utilize office automation tools (such as email, document processing, and web surfing), but not much else.
Therefore, to simply view or control services in our server environment, I’m constantly faced with the hurdle of authentication. Although Remote Desktop permits me to abandon my cubical for occasional Starbucks iced coffee refills and subsequent restroom breaks, it inhibits my ability to manage several systems at one time. Neither can I easily extract information from those systems and compile it.
So, my first step is to open a Windows PowerShell console with my non-privileged account. By using the Get-Credential cmdlet, I specify the credentials for an account with sufficient permissions and save them in a $c variable. As long as I keep this Windows PowerShell session open, I can reuse those credentials as many times as needed by simply referring to the variable.
$c = Get-Credential <PSCredential>
This creates a credential object for a specified user name and password. More importantly, notice in the following example, that it stores the Password property as a System.Security.SecureString. The System.Security.SecureString class represents text that should be kept confidential. The text is encrypted for privacy when being used, and deleted from computer memory when it is no longer needed.
A SecureString object is similar to a String object in that it has a text value. However, the value of a SecureString object is automatically encrypted, and it can be deleted from computer memory by your application or the .NET Framework garbage collector. (For more information, see SecureString Class.)
A common scenario that I’m faced with is validating the existence and consistency of files between multiple servers. In the following examples, I’ll demonstrate how I utilize Invoke-Command to compare files on two SharePoint web front end (WFE) servers. Keep in mind that the only time I’m utilizing my elevated credentials is during the execution of my command on the remote systems.
Within our farm, we utilize a Site Map web part, to display the site structure in a hierarchical tree view. It requires me to deploy a .sitemap XML file to both WFEs and maintain strict consistency between both servers.
Note For my examples I’ll be connecting to systems running Windows Server 2008 R2 and configured with the Windows Remote Management (WinRM) tool which is the Microsoft implementation of the WS-Management Protocol. For more information, see An Introduction to WinRM Basics.
One of the cool things about Invoke-Command is the default output that includes the PSComputerName property, which returns the system name with each result. This makes it easy for me to quickly compare results.
I simply specify the name of each of my WFEs, and the –ComputerName parameter allows me to use the NETBIOS name, IP address, or fully qualified domain name of one or more computers in a comma-separated list. I pass my elevated credentials within –Credential parameter, and the command that I want to execute within the –ScriptBlock parameter:
Invoke-Command -ComputerName wfe1 -Credential $c -ScriptBlock { dir "c:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\LAYOUTS\*.sitemap" }
In the previous example, I first executed Invoke-Command with my Windows PowerShell session credentials. Notice the Access is denied error message. Next I executed the same command again, this time specifying my stored credentials contained within the $c variable. In the directory that lists the results at the bottom of the console window, I highlighted (in yellow) the differences in the file results. Obviously, a mistake like this could cause our SharePoint site to not render properly and be unavailable.
This is only one way to leverage Windows PowerShell to help minimize risk while performing administrative tasks. By using this basic example, I can execute commands on a number of systems concurrently again without exposing my elevated credentials to all the other desktop office applications running on my workstation. After all, it’s one thing to compromise your workstation by browsing to a website or opening a file with malicious code when logged in as a non-privileged user—it’s a resume-generating event if you do that with your domain or network admin account.
So there we have it, an exercise in secure automation and system administration. Can it get any better? Well actually, on the topic of securing credentials, I recommend an interesting article by Windows PowerShell MVP, Tome Tanasovski. Storing Passwords to Disk in PowerShell with Machine-key Encryption presents some great insight and easy-to-follow steps for how to encrypt and store a password to disk so that it can be used later.
~Marc
Thank you, Marc, for sharing your time and knowledge. I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Ed Wilson, Microsoft Scripting Guy