DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Newsletter
Log In / Join
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Related

  • Zero-Touch Patch Management With PowerShell and Intune: How We Automated Compliance at Scale
  • Multiplatform Directory Bookmarks on the Command Line
  • Effective Secrets Management: Retrieving Secrets From Azure Key Vault With Powershell Script
  • Apache Ranger and AWS EMR Automated Installation and Integration Series (5): Windows AD + Open-Source Ranger

Trending

  • Going All In On the JVM 25 Virtual Threads
  • Java 8 Optional - Avoid Null and NullPointerException Altogether - and Keep It Pretty
  • Who Should Grade Your AI? Rules vs LLM Judges vs Humans
  • Putting Guardrails Around What Your AI Agent Is Allowed to Touch

Draft This article hasn't been published, so readers can't see it.

In moderation This article is waiting for review, so readers can't see it yet.

Deleted This article has been deleted, so readers can't see it.

  1. DZone
  2. Coding
  3. Languages
  4. Manage ServicePrincipalName Properties Using PowerShell

Manage ServicePrincipalName Properties Using PowerShell

Check out these awesome PowerShell tips on setting up service accounts in Active Directory.

By 
Rob Sanders
·
Mar. 29, 16 · Analysis
Post on X (opens in a new tab) Share on LinkedIn (opens in a new tab)
8.9K Views

Join the DZone community Save articles, join the discussion, and download Refcards and Trend Reports with a free account.

Join for free Already a member? Log in

A few years ago [1] I wrote about how you could enable Domain Accounts to self-manage their ServicePrincipalNames.  This is particularly advantageous when using Kerberos to secure services.

We recently needed to set up some service accounts in Active Directory to participate in establishing a Kerberos capability for middleware integration. I began unpacking the ADSIEdit approach, but stopped.  Whilst you can reach your end goal using the “established” approaches, it’s an absolute pain to deploy these changes to other environments.  Surely there must be a better way?

Enter PowerShell. We can automate (by scripting) the ability to grant Active Directory accounts the ability to read and write ServicePrincipalName. Eureka!  Full credit goes to this excellent answer on StackOverflow [2].

Function Set-SpnPermission {
  param(
    [adsi]$TargetObject,
    [Security.Principal.IdentityReference]$Identity,
    [switch]$Write,
    [switch]$Read
  )
  if(!$write -and !$read){
    throw "Missing either -read or -write"
  }
  $rootDSE = [adsi]"LDAP://RootDSE"
  $schemaDN = $rootDSE.psbase.properties["schemaNamingContext"][0]
  $spnDN = "LDAP://CN=Service-Principal-Name,$schemaDN"
  $spnEntry = [adsi]$spnDN
  $guidArg=@("")
  $guidArg[0]=$spnEntry.psbase.Properties["schemaIDGUID"][0]
  $spnSecGuid = new-object GUID $guidArg
  if($read ){$adRight=[DirectoryServices.ActiveDirectoryRights]"ReadProperty" }
  if($write){$adRight=[DirectoryServices.ActiveDirectoryRights]"WriteProperty"}
  if($write -and $read){$adRight=[DirectoryServices.ActiveDirectoryRights]"readproperty,writeproperty"}
  $accessRuleArgs = $identity,$adRight,"Allow",$spnSecGuid,"None"
  $spnAce = new-object DirectoryServices.ActiveDirectoryAccessRule $accessRuleArgs
  $TargetObject.psbase.ObjectSecurity.AddAccessRule($spnAce)
  $TargetObject.psbase.CommitChanges()    
  return $spnAce
}

Now, you’d invoke this function this way:

$TargetObject = "LDAP://CN=svc_account,OU=Service Accounts,DC=Development,DC=sanderstechnology,DC=com"
$Identity = [security.principal.ntaccount]"DEVELOPMENT\svc_account" 
Set-SpnPermission -TargetObject $TargetObject -Identity $Identity -write -read

Voila!

[1] http://sanderstechnology.com/2010/some-handy-articles-on-configuring-kerberos-with-service-principal-names-spns/9987/
[2] http://stackoverflow.com/questions/4156743/powershell-how-do-you-set-the-read-write-service-principal-name-ad-permissions

PowerShell

Published at DZone with permission of Rob Sanders. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

  • Zero-Touch Patch Management With PowerShell and Intune: How We Automated Compliance at Scale
  • Multiplatform Directory Bookmarks on the Command Line
  • Effective Secrets Management: Retrieving Secrets From Azure Key Vault With Powershell Script
  • Apache Ranger and AWS EMR Automated Installation and Integration Series (5): Windows AD + Open-Source Ranger

Partner Resources

×

Comments

Loading comments

The comments didn't load

Please try again in a moment.

Likes

Loading

The next likes didn't load. Please try again.

The likes didn't load

Please try again in a moment.

See who liked this

Log in or join DZone for free to see who liked this article.

Log in Join for free
  • RSS
  • X
  • Facebook

ABOUT US

  • About DZone
  • Support and feedback
  • Community research

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 215
  • Nashville, TN 37211
  • [email protected]

Let's be friends:

  • RSS
  • X
  • Facebook