Skip to main content

Active Directory Searcher - Part 1

One of the first things I learnt to do in powershell was to search AD. I could search in VB but there were a few quirks and limitations that gave me the incentive to take the leap in to PS. That and I had just started a new job supporting a large financial AD environment where we had to do a lot of data capture across multiple domains!

As anyone would, I looked at the way VB works and tried to convert it. Here is a direct translation of VB to PS in terms of searching AD ...


VB Script :


Set objConnection = CreateObject("ADODB.Connection")
objConnection.Provider = "ADsDSOObject"
objConnection.Open "Active Directory Provider"
Set objCommand = CreateObject("ADODB.Command")
objCommand.ActiveConnection = objConnection
objCommand.CommandText = "<LDAP://dc=other,dc=com>;(objectclass=user);name;subtree"
Set objRecordSet = objCommand.Execute

If objRecordset.RecordCount > 0 Then
   objRecordSet.MoveFirst
   Do Until objRecordSet.EOF
      wscript.echo objRecordSet.Fields("name")
      objRecordSet.MoveNext
   Loop
End If

objConnection.Close
which converts to :


$objConnection = New-Object -comObject "ADODB.Connection"
$objCommand = New-Object -comObject "ADODB.Command"
$objConnection.Open("Provider=ADsDSOObject;")
$objCommand.ActiveConnection = $objConnection
$objCommand.CommandText = "<LDAP://dc=other,dc=com>;(objectclass=user);name;subtree"
$objRecordSet = $objCommand.Execute()
if ($objRecordSet.pagesize -gt 0){
   Do {
      $objRecordSet.Fields.item("name") | Select-Object Value
      $objRecordSet.MoveNext()
   }
   Until ($objRecordSet.eof)
}
$objConnection.Close()

And there we have it, how to write VB in powershell! Actually there is more to powershell than using the same tools that you would use in VB. Here is where one of my resource links comes in handy ... let’s explore .net.

Where we would use the ADODB commands of old, they can be replaced with the .net object :

System.DirectoryServices.DirectorySearcher()

Which can be used in the following way (note this is a one line command, it may have wrapped on to multiple lines in this blog) :


$Searcher = New-Object System.DirectoryServices.DirectorySearcher("LDAPdomain", "LdapQuery","properties","searchscope")

You may see a similarity to the commandtext line in the ADODB way of connecting. I have specifically used the “constructor” in the .net class that accepts 4 arguments to match ADODB as closely as possible. You can create an empty object and populate the options later. See this link for all available constructors.

The LDAPdomain needs to be a DirectoryEntry object, and the other 3 need to be strings. The strings are pretty easy, but how do I get a DirectoryEntry object? The answer is there are many ways, it all depends where you are in your script and what objects you have. When you only have an LDAP path to the entry you want to retrieve, the most standard way is to call the .net class as we did with the $Searcher (again, one line command) :


$LDAPdomain = New-Object System.DirectoryServices.DirectoryEntry('LDAP://dc=other,dc=com')

There is, however, a neat little shortcut in powershell which you can use :


$LDAPdomain = [ADSI]('LDAP://dc=other,dc=com')

Obviously, you have to define this prior to creating the searcher so at the moment, using the same options as our VB example our script looks like this :


$LDAPdomain = [ADSI]('LDAP://dc=other,dc=com')
$Searcher = New-Object System.DirectoryServices.DirectorySearcher($LDAPdomain,"(objectclass=user)","name","subtree")

We have set up the searching mechanism, now let’s run the search...


$Results = $Searcher.FindAll()

... and loop through the results using a foreach cmdlet :


foreach ($Object in $Results){
   $Object.Properties.name
}

Note, the use of $object.properties.name rather than $object.name. I have fallen foul a few times to this and then was very confused to why I was not getting any values back.

So, the complete script :


$LDAPdomain = [ADSI]('LDAP://dc=other,dc=com')
$Searcher = New-Object System.DirectoryServices.DirectorySearcher($LDAPdomain,"(objectclass=user)","name","subtree")
$Results = $Searcher.FindAll()
foreach ($Object in $Results){
   $Object.Properties.name
}

Quite neat and tidy! That’s it for part 1, Part 2 will take things a bit further by looking into pulling information from AD rather than hard coding variables, other options you can specify and how to deal with certain types of values returned.

Comments

Popular posts from this blog

Enable Powershell Remoting (WinRM) via Group Policy

I have been doing some testing on enabling WinRM via group policy, being that WinRM is the service that Powershell v2 sets up it remoting capabilities. Here are the GPO settings that you need to configure WinRM .... set the winrm service to auto start Computer Configuration \ Policies \ Windows Settings \ Security Settings \ System Services Windows Remote Management (WS-Management)  set Startup Mode to Automatic start the service incorporated in to the above - you may need a restart. create a winrm listener Computer Configuration / Policies / Administrative Templates / Windows Components / Windows Remote Management (WinRM) / WinRM Service / Allow automatic configuration of listeners IPv4 filter: * * is listen on all addresses, or if you only want a particular IP address to respond use an iprange eg 10.1.1.1-10.1.1.254 - don't forget that this IP range has to be valid for all hosts that fall in the scope of the GPO you are creating.  You can use 1...

Assigning Permissions - AGDLP

AGDLP It seems I have been mildly distracted away from the title of this blog site.   It does say AD Admin, but I seem to have been taken away by file system stuff.   I have to say, it has all been worthwhile, but it’s probably time I got back to the real heart of what I do. There are probably a million permission assigning advice pages, but I thought I would put another one out there after referring to AGDLP in my last post. So, what is this all about – AGDLP.   Well, it is something I learned in my MCSE 2003 studies and has become ingrained into my ideals since.   As a contractor, I get to move job often.   This enables me to forge opinions on how to configure things in a domain, and more importantly how NOT to configure things. AGDLP is definitely on the to do list…for anyone in any size domain or forest, as it follows some very basic principals.   I will explain these whilst I go through what AGDPL stands for. A A is for...

Finding out what 'SearchFlags' are set on you AD attributes

Whilst doing some research into indexed attributes, I posted this  a while back on how to find your index attributes.  Since then, I have looked a little deeper into what indexing really means and found this excellent explanation on the numbers that can be found in the searchflags attribute of a schema object. Using Florian’s reference, I built the following script (which is both powershell v1 and v2 compatible) to get the schema attributes from the forest schema and return (among other things) the breakdown of your attributes search flags. $forest = [System.DirectoryServices.ActiveDirectory.forest]::getcurrentforest() $schema = [ADSI]('LDAP://CN=Schema,CN=Configuration,dc=' + ($($forest).name -replace "[.]",",dc=")) $attributes = $schema.psbase.children | where {$_.objectClass -eq "attributeSchema"} $collection = @() foreach ($attr in $attributes){ $store = "" | select "Name","lDAPDisplayName","singlev...