May 25th, 2013

Weekend Scripter: Use PowerShell to Find Computers SIDs in AD DS

Doctor Scripto
Scripter

Summary: Microsoft Scripting Guy, Ed Wilson, talks about using Windows PowerShell to find computer security identifiers (SIDs) in Active Directory Domain Services.

Microsoft Scripting Guy, Ed Wilson, is here. TechEd 2013 is soon upon us—both in New Orleans and in Madrid. The Scripting Wife has been extremely busy working on her schedule and the schedule for the Scripting Guys booth. I, on the other hand, have been really busy working on the instructor-led labs for Windows PowerShell for New Orleans and Madrid. (Actually, the labs will be basically the same in New Orleans and Madrid…the “basically” portion depends on how much I have to change after New Orleans.)

Anyway, this post is not related to my instructor-led labs, but it is something I wanted to talk about for a while—that is, I am continually amazed at all the cool things I can do with the Active Directory cmdlets from the Active Directory module. One thing to keep in mind is that the module is updated in Windows Server 2012 and in the Remote Server Administration Tools for Windows 8.

Today I want to play around with SIDs…

Use the Get-ADComputer cmdlet

From time-to-time, I need to know the security identifier (SID) for a computer. Not often, mind you, but occasionally the need arises. A quick look on the Internet, turns up a lot of scripts that attempt to read from the registry. The problem is that on modern operating systems the registry key is protected.

A computer’s SID is stored in the HKLM\SECURITY\SAM\Domains\Account registry, but that registry key is protected, and not even the Administrator has rights to the key. This means that the administrator must take ownership of the key, and then add rights to the key. This is not a good idea.

The easy way to find the SID for a computer on the domain is to retrieve the value from Active Directory Domain Services (AD DS). To do this, I use the Get-ADComputer cmdlet and filter based on the computer name. In this example, I return the SID for my local computer. By using the Select-Object (select is an alias) at the end of the line, I return an object that has two properties: name and SID. I can then use those properties in other computations if I need to do so. This command and its output are shown here:

PS C:\> Get-ADComputer -Filter “name -eq ‘edlt'” -Properties sid | select name, sid

 

name sid

—- —

EDLT S-1-5-21-1457956834-3844189528-3541350385-1147

The cool thing is that because I am querying from Active Directory, I can easily return the SID from a “remote” computer. In the example shown here, I retrieve the SID from a computer named DC1 in the domain. I use the Format-List cmdlet (fl is the alias) at the end of the command so the output displays better on the blog.

PS C:\> Get-ADComputer -Filter “name -eq ‘dc1′” -Properties sid | select name, sid | fl *

 

name : DC1

sid  : S-1-5-21-1457956834-3844189528-3541350385-1000

PS C:\> C:\fso\PsGetsid.exe

I used to use the PSGetSid.exe utility from the SysInternals tools. This tool also works remotely. However, there are two issues with the tool. The first is that it is a bit slower than querying AD DS. The second is that it returns a string that must be parsed if I want to use the information in other cmdlets. The output from the Get-ADComputer cmdlet and from PSGetSid.exe are shown in the following image.  The results are the same.

Image of command output

Well, that is it for now. I have to get back to work on my labs. Hope to see you in New Orleans or Madrid. If you are there, make sure to come by and say “hi” to the Scripting Wife and me.

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 

Author

The "Scripting Guys" is a historical title passed from scripter to scripter. The current revision has morphed into our good friend Doctor Scripto who has been with us since the very beginning.

0 comments

Discussion are closed.