Skip to main content

Powershell 3.0 - Kerberos and SPN


Just a quick post about Powershell and SPN. I have "used" powershell for several years now. I mean used as in having created some very, very small scripts and cmdlets starting back in 2007 when Microsoft launched their powershell cmdlets for Exchange 2007. Any way, the last months I have been playing heavily with Powershell and have learned the beauty of it quite recently. 

I am kind of excited about the new Powershell 3.0 released with Win8 and Microsoft Server 2012. If you have not tried it, I recommend you download it and give it a go. The new built-in editor from Microsoft has actually become very good with intellisense and other goodies.



Quick-tip: When you install the Powershell ISE editor, you get a new cmdlet that gives you the ability to output the results to a sortable gridview. You may also copy and paste to Excel or other applications!




Recently I was tasked with creating a script to be able to set SPN for an Active Directory user. I created to functions named Get-ADUserSPN and Set-ADUserSPN. 


Function Get-ADUserSPN
{
<#

.Synopsis 
 This function returns the SPNs for a user object in ActiveDirectory 
.Description 
 Must be executed on a server with the active Directory module present
.Example 
 Get-ADUserSPN usera 
 Returns the SPNs for a user with sAMaccountName 'usera' 
.Example 
 Get-ADUserSPN -SAM usera 
 Returns the SPNs for a user with sAMaccountName 'usera'.   
.Parameter UserAccount [string] 
.Role 
 General 
.Component 
 FP 
.Notes 
 NAME: Get-ADUserSPN 
 AUTHOR: Tore Groneng LASTEDIT: November 2012 
 KEYWORDS: General scripting SCCM 
.Link 
 Http://www.firstpoint.no 
 Created by: Tore Groneng 
 tore@firstpoint.no #toregroneng tore.groneng@gmail.com 

#Requires -Version 2.0 
#> 

PARAM(
[Parameter(Position=0, Mandatory=$true, ValueFromPipeline=$true)]
[Alias("SAM")]
[string]$UserAccount
)

# Load the AD module, if needed (in powershell 3.0 it will automatically load modules as needed and import-module will kind of be redundant)

if ((get-Module -Name ActiveDirectory -ErrorAction SilentlyContinue) -eq $null )
{
Import-Module ActiveDirectory
}

$theUser = get-aduser $UserAccount -properties *

if ($theUser.servicePrincipalName.count -eq 0){
write-host "No SPN found for the user '$UserAccount'" -fore yellow
}
else{
# Print the SPNs to the console
$theUser.servicePrincipalName
}
}

So to be able to set SPN for a user, we must do something like this:

Function Set-ADUserSPNSQL
{
<# 
.Synopsis 
 This function sets the SPNs for a user object in ActiveDirectory 
.Description 
 Must be executed on a server with the activeDirectory module present. 
 Exception is thrown if you try to set an SPN that already exists for the target       server and user.
.Example 
 Set-ADUserSPNSQL "usera" "bgo-vm-sql-01" 
 Sets the SPN for user 'usera' with target server bgo-vm-sql-01 using the default   port 1433 
.Example 
 Set-ADUserSPNSQL -SAM "usera" -target "bgo-vm-sql-01" 
 Sets the SPN for user 'usera' with target server bgo-vm-sql-01 using the default port 1433 
.Example 
 Set-ADUserSPNSQL -SAM "usera" -target "bgo-vm-sql-01" -port 14433 
 Sets the SPN for user 'usera' with target server bgo-vm-sql-01 using the port 14433 
.Parameter 
 UserAccount UserAccount [string] 
.Parameter 
 TargetServer TargetServer [string] 
.Parameter 
 PortNumber PortNumber [int] 
.Role 
 General 
.Component FP 
.Notes 
 NAME: Set-ADUserSPNSQL 
 AUTHOR: Tore Groneng 
 LASTEDIT: November 2012 
 KEYWORDS: General scripting 
.Link 
 Http://www.firstpoint.no C
Created by: 
Tore Groneng tore@firstpoint.no #toregroneng tore.groneng@gmail.com 
#Requires -Version 2.0 
#> 
PARAM(
[Parameter(Position=0, Mandatory=$true, ValueFromPipeline=$true)]
[Alias("SAM")]
[string]$UserAccount
,
[Parameter(Position=1, Mandatory=$true)]
[Alias("target")]
[string]$TargetServer
,
[Parameter(Position=2)]
[Alias("Port")]
[INT]$PortNumber = 1433
)
[string]$targetKerb = "MSSQLSvc/"
[string]$dnsDomain = $env:UserDNSdomain
[string]$colon = ":"

# Load the AD module, if needed (in powershell 3.0 it will automatically load  modules as needed and import-module will kind of be redundant)

if ((get-Module -Name ActiveDirectory -ErrorAction SilentlyContinue) -eq $null )
{
Import-Module ActiveDirectory
}

$theUser = get-aduser $UserAccount -properties *

if ($theUser -eq $null{
write-host "Error - could not find user $UserAccount"
}
else {
$theUser.servicePrincipalName += "$targetKerb$TargetServer$colon$PortNumber"
$theUser.servicePrincipalName += "$targetKerb$TargetServer.$dnsDomain$colon$PortNumber"

try {
set-aduser -instance $theUser
write-host "Successfully set the SPN for the user ('$UserAccount'), user now have these SPNs:" -fore yellow
$theUser = get-aduser $UserAccount -properties *
write-host $theUser.servicePrincipalName -fore green
}
catch {
write-host "Exception - $_.Exception"
write-host "Useraccount:::$UserAccount" -fore yellow
write-host "TargetServer:::$TargetServer" -fore yellow
}


Comments

Popular posts from this blog

Developing PowerShell modules for REST APIs – Part1

Over the years I have developed different PowerShell modules for different web APIs. I thought it would be a good idea to write a 2 series post about how you could go about to do this. This will be a 2 part blog series where we will run through the entire process of building a module for a REST API. I will try my best to keep this as simple as possible and leave more advanced stuff for a follow up post if the interest is there.What you needDepending on your experience with source control and PowerShell in general, you might want to use GIT or some other software repro for the code. In addition we are going to create a test REST API using the splendid UniversalDashboard PowerShell module created by Adam Driscoll. It is available on the PowershellGallery. Other prerequisites are built-in to Powershell. I will assume that you will be following along using at least PowerShell version 5 or greater.
What is HTTP metods for REST API.The primary or most common HTTP verbs used are POST, GET, PU…

Build your local powershell module repository - ProGet

So Windows Powershell Blog released a blog a couple of days ago (link). Not too long after, a discussion emerged about it being to complicated to setup. Even though the required software is open source (nugetgalleryserver), it looks like you need to have Visual Studio Installed to compile it. I looked into doing it without visual stuidio, however I have been unable to come up with a solution. I even tweeted about it since I am not an developer. Maybe someone how is familiar with “msbuild” could do a post on how to do it without VS.

Anyhow one of my twitter-friends (@sstranger) came to the rescue and pointed me in the direction of ProGet, hence the title of this post. ProGet comes in 2 different licensing modes
Free (reduced functionality)Enterprise (paid version with extra features)The good news is that the free version supports hosting a local PowershellGet repository which was my intention anyway. So off we go and create a Configration that can install ProGet for us. This is the conf…

Serialize data with PowerShell

Currently I am working on a big new module. In this module, I need to persist data to disk and reprocess them at some point even if the module/PowerShell session was closed. I needed to serialize objects and save them to disk. It needed to be very efficient to be able to support a high volume of objects. Hence I decided to turn this serializer into a module called HashData.



Other Serializing methods

In PowerShell we have several possibilities to serialize objects. There are two cmdlets you can use which are built in:
Export-CliXmlConvertTo-JSON
Both are excellent options if you do not care about the size of the file. In my case I needed something lean and mean in terms of the size on disk for the serialized object. Lets do some tests to compare the different types:


(Hashdata.Object.ps1)

You might be curious why I do not use the Export-CliXML cmdlet and just use the [System.Management.Automation.PSSerializer]::Serialize static method. The static method will generate the same xml, however we …