AD without Quest: Getting and Using ADSPath

 Active Directory, PowerShell  3 Responses »
Jul 032011
 

This is the second post in my AD without Quest series. I am covering individual functions that can be combine to produce a wide variety of scripts. Today I am going to be covering how to connect to AD to read an object ADSPath. The ADSPath is basically the LDAP string to connect to that object. Once you have an object’s LDAP path it is very easy to work with the object.

When searching in AD all you need to do is use the directory searcher object and continue to narrow down the filter. There are some slight changes between searching for a user, computer and group, so I’ll cover each.

 Function Get-UserADSPathbyName{
    Param([STRING]$User)
   
    $Searcher=New-Object System.DirectoryServices.DirectorySearcher
    $Searcher.Filter="(&(SamAccountName=$User)(objectcategory=user))"
    $Searcher.PageSize = 1000
    $Results=$Searcher.FindAll()
    If(!$?){"AD searcher failed on $User"}

    If ($Results.Count -eq 1){
        $Results[0].properties.adspath
    }Else{
        Return $false
    }
}

On the line with $Results[0].properties.adspath it is important to note that the “adspath” portion is case sensitive. I really have no clue why that is the case. If you know, drop me a comment to help me out!

 Function Get-ComputerADSPathbyName{
    Param([STRING]$Computer)
   
    $Searcher=New-Object System.DirectoryServices.DirectorySearcher
    $Searcher.Filter=”(&(CN=$Computer)(objectcategory=computer))”
    $Searcher.PageSize = 1000
    $Results=$Searcher.FindAll()
    If(!$?){"AD searcher failed on $Computer"}

    If ($Results.Count -eq 1){
        $Results[0].properties.adspath
    }Else{
        Return $false
    }
}

So as you can see, a couple of small changes will convert the function for use with computers instead of users. One final function converts this again for use with groups.

 Function Get-GroupADSPathbyName{
    Param([STRING]$Group)
   
    $Searcher=New-Object System.DirectoryServices.DirectorySearcher
    $Searcher.Filter=”(&(CN=$Group)(objectcategory=group))”
    $Searcher.PageSize = 1000
    $Results=$Searcher.FindAll()
    If(!$?){"AD searcher failed on $Group"}

    If ($Results.Count -eq 1){
        $Results[0].properties.adspath
    }Else{
        Return $false
    }
}

So there they are, but what can you do with them? There is a great variable type in PowerShell defined with the ADSI tag. Once a LDAP string is defined as and ADSI variable you can interact directly with that object by reading any property you want, and even changing them.

$UserLDAP = [ADSI]$(Get-UserADSPathbyName “MyUserName”)
$UserLDAP.extensionAttribute1
>MyOldValue
$UserLDAP.Put(“extensionAttribute1”,”MyNewValue”)
$UserLDAP.SetInfo()
$UserLDAP.extensionAttribute1
>MyNewValue

AD Without Quest: Listing Servers and Users

 Active Directory, PowerShell  No Responses »
Jul 022011
 

I’ve decided to start an Active Directory series. I have discovered that when you search online for any AD related code everything points back to the Quest tools. I prefer to do everything natively and not rely on a third party tool kits that have to be installed. As an admin, I understand that we do rely on our workstations, but when you start needing to install third party tools on server you are entering dangerous ground. I wouldn’t want to explain that Exchange went down because I installed some tool that locked the server.

I have been using PowerShell since its inception and I still haven’t found an instance where I need to use the Quest tools. Sometimes it might be easier, but once you’ve created a well written function, it’s easy to copy and paste it into your next script. So I am going to base this series off of individual functions that can be added to scripts to work with AD.

We’ll start with the basic ones. The following functions can be used to pull all the server names and user name out of Active Directory. This can be modified to pull whatever property you’d like, but I find that either account name or ADSPath (the LDAP string) are the most useful. I use some variation of these in almost every script I make.

First, let’s look at pulling all AD servers. Now these are only for the domain that you are running it from. There is some extra work to do to change domains, but I’ll cover that in a later blog post. The basic idea is to create a directory searcher, then set a filter (or you will return every object in AD). Then you need to set the page size. That, basically, tells the searcher how many objects it can return in a single search, so if you set it to 1000 and you have 8000 total objects, it will run a total of 8 searches. This step can be skipped if you have a very small domain, but AD has a built in limit to how many objects can be returned in a single search. This value can be set by the admin, but 1000 works with default domains. Finally, you run the search and then return the property you want from the function.

 Function Get-ServerList{
    $Searcher=New-Object System.DirectoryServices.DirectorySearcher
    $Searcher.Filter="(&(objectcategory=computer)(operatingSystem=*Server*))"
    $Searcher.PageSize = 1000
    $Results=$Searcher.FindAll()

    $Results | % {$_.Properties.name}
}

So, that’s it. You can drop this into your script and then run it with $servers = Get-ServerList to get a list of all your server names. This function runs very quickly and can be put into any script to make things really easily.

However, part of what I am trying to get across is that these functions can be quickly changed to suite your needs. So this is the function very slightly changed to pull all the users instead. In this case the PageSize parameter really comes into use.

 Function Get-UserList{
    $Searcher=New-Object System.DirectoryServices.DirectorySearcher
    $Searcher.Filter="(objectcategory=user)"
    $Searcher.PageSize = 1000
    $Results=$Searcher.FindAll()

    $Results | % {$_.Properties.samaccountname}
}

More AD entries to come! You can find them via my blogs tags to the right.