MSIgnite 2015 Trip Report

I'm going to post a trip report on Sway this year. You can check it out at MSIgnite Trip Report

I'll be updating this through out the week.

Thycotic SercretServer and PowerShell

PowerShell is great at bridging the gap between different applications that normally don’t integrate. The problem is sometimes those different technologies have different ways of managing access and even if its based on Active Directory, it may not pass on the credential of the logged in user. Luckily most cmdlet developers will take a PowerShell Credential object for an access credential. But what do you do when you don’t want prompt for a password or embed it in the script. I’ve gotten to work with an excellent enterpise password manager made by Thycotic Software called SecretServer, it holds not just just user accounts but credit card, certificates, encryption keys, and almost anything else. It’s a web based application and includes a set of web services for accessing it outside the UI.
So let’s get to the script. I’ll be working with the Windows Authenticated service for now but SecretServer includes an non-Windows Authenticated service as well. First we need to create a Web Service Proxy object to connect to Secret Server and just use the logged in user to authenticate

#Url to the SercretServer application
$SSUri = "http://secretserver/winauthwebservices/sswinauthwebservice.asmx"
$SS = New-WebServiceProxy –UseDefaultCredential –Uri "$SSUri"

You can point your browser to the same URL to see a list of all the different methods available. Now that we have the proxy, we want to access a method called “GetSecret()” it takes the Secret Id as an argument and returns an XML Secret Definition. You can get the Secret Id by viewing the secret and looking in the url.
 

Rather that working with the full definition for we’ll pull the list of the Secrets attributes

$secretdef = $SS.GetSecret(4).Secret.Items

The properties we care about are FieldName and Value. We’re going to extract the values of the fields into variables to make them easier to work with. Since credentials that are domain based require that as part of the username we’ll check the use the presence of a “Domain” field so we can construct our credential properly.

$user = $($secretdef|Where-Object {$_.FieldName -eq "Username" }).Value
$domain = $($secretdef|where-object {$_.FieldName -eq "Domain" }).Value

#Have to force SecurString to take the PlainText
$secpasswd = ConvertTo-SecureString $($secretdef|where-object {$_.FieldName -eq "Password" }).Value -asPlainText -Force
 
Now we have everything we need to create a Credential object

#check to see if the account is a domain account
  
if ( $domain ) {   
 $cred = New-Object System.Management.Automation.PSCredential("$user@$domain",$secpasswd)
 } else {  
 $cred = New-Object System.Management.Automation.PSCredential($user,$secpasswd) 
 }

Now we can pass “$cred” on to any cmdlet that accepts a PSCredential object as a parameter. I’ve included a function that wraps it all up.

Get-SecretServerCred

Next time I’ll show how we can use the Secret’s Name rather than Id number to make it a little easier.

Prepping for TechEd 2013

Since the last post on this blog, a lot has happened to me personally and it's time to bring this hiatus to an end. So... I'm still with my same company. I'm still getting more projects that I want to do rather than projects I don't want to do. They're also getting bigger! As I get ready to attend my 3rd TechEd, I'm thinking about where I'm at and where I want to go. My projects are focused around monitoring and beginning to move some of our applications and services to "the cloud". Aside from our continuing Active Directory cleanup, my getting to play with PowerShell has been pretty much limited to helping the other guys on my team when they get stuck. This isn't happening as much as it use to and their problems are getting more interesting, so I must be doing something right. We've had one engineer leave our team and was replaced by someone from our helpdesk. As soon as a local class at Microsoft was available, my boss had him scheduled; no discussion or question except that to ensure that it was the right course.

While at a local SharePoint conference, I heard one of the speakers say something that really resonated with me on how we were looking at SharePoint. I'm paraphrasing; "SharePoint is not the Application, SharePoint is the Platform that you build your Application on." I've realized in trying to explain PowerShell to other people that something similar could be said. PowerShell isn't the Solution; PowerShell is what you build your Solution out of. Most of the scripts I've written are either focused on a single technology (managing AD) or merging data from two systems together (VMware and NetApp).

So as I get ready for TechEd and plan the sessions I'm going to attend. I'm also starting another project to fill a need I have at work that I think will be useful. Most everyone I'm sure either uses or is at least aware of password management software. If you work in a medium to large IT shop, you might even have and enterprise password management solution. A couple of years ago, I started working with one from Thycotic Software called SecretServer. Its an awesome internal web application for managing, auditing, and reporting on secrets. You can store user accounts, credit card information, even digital certificates and launch helper programs from the secret and even let SecretServer manage the changing of the password for you. Over the next few posts, I'll show you how to use SecretServer in your PowerShell scripts for working with passwords, think credential objects, easier.

TechEd 2012 Personal Goal

Last year I got to meet 5 PowerShell MVPs last year at TechEd 2011

• Don Jones
• Kirk Munro
• Jeffery Hicks
• Aleksandar Nikolic
• Steven Murawski (not a MVP at the time but I was following him before TechEd)

Most of these were thanks to Ed Wilson @ScriptingGuys, Teresa Wilson @ScriptingWife, and Mark Schill @meson3902. Meeting these people and others gave me great ideas that turned into solutions in our environment. It also gave me the information needed to convince my management to make PowerShell a training priority. Today of the 12 people on our infrastructure engineering teams, 9 have had formal PowerShell training. Of the 3 without, 1 is a manager and the other 2 work 85% with network gear and Cisco telephony. I want to continue that trend. My goals for this year

1. Continue to meet new people in the PowerShell community
2. Re-connect with ones I've already met.
3. Show the vendors we use how PowerShell and their products work in our environment 
4. Give back to the community by helping anyone that ask and start posting tools and solutions to problems I solve.