Tag Archives: LDAP

Active Directory Friday: Use the ANR filter for LDAP Queries

ANR or Ambiguous Name Resolution is used to query for objects in Active Directory if the exact identity of an object is not known. A query containing Ambigious Name Resolution will query for all the attributes for example, Given Name, Sur Name, Display Name and samaccountname. For Windows Server 2008 and later versions this is the full list of ANR Attributes included in the search results:

For a full list of all the attributes that are queried please refer to the following TechNet article: ANR Attributes.

  • Display-Name
  • Given-Name
  • Physical-Delivery-Office-Name
  • Proxy-Addresses
  • RDN
  • SAM-Account-Name
  • Surname
  • Legacy-Exchange-DN
  • ms-DS-Additional-Sam-Account-Name
  • ms-DS-Phonetic-Company-Name
  • ms-DS-Phonetic-Department
  • ms-DS-Phonetic-Display-Name
  • ms-DS-Phonetic-First-Name
  • ms-DS-Phonetic-Last-Name

For a full list of all the attributes that are queried please refer to the following TechNet article: ANR Attributes.

An ANR query is useful in a number of scenarios, for example when relying on user input in your script. In this case querying against a samaccountname might fail if the spelling does not match the samaccountname. Similarly an export from a different department or database might be close to what is stored in Active Directory but not an exact match, again this is somewhere where an ANR query might be useful. Something that should be kept in mind is that this is a relatively expensive query and therefore should be avoided when it is not required. In this article we will discuss how to create an ANR filter and what happens exactly in such a query.

In the next example we will be using Get-ADUser cmdlet, which is part of the ActiveDirectory module, in combination with the LDAPFilter parameter in order to execute our query:

1
Get-ADUser -LDAPFilter '(anr=Jaap Brasser)'

This will query against all the attributes in the list as ‘Jaap Brasser*’ and two additionally queries: ‘GivenName=Jaap*’ and ‘SurName=Brasser*’ as well as ‘GivenName=Brasser*’ and ‘SurName=Jaap*’. As a result more than one result might be returned, as different attributes of a user account might overlap or are not unique to a single user account. This is the downside of this method of querying.

In the following example I will use the [adsisearcher] type accelerator to execute the same query:

1
([adsisearcher]'(anr=Jaap Brasser)').FindAll()

Alternatively the DirectorySearcher object can be manually created to execute a query:

$ADSearcher = New-Object DirectoryServices.DirectorySearcher -Property @{
 Filter = '(anr=Jaap Brasser)'
 PageSize = 100
}
$ADSearcher.FindAll()

For more information on this Ambiguous Name Resolution (ANR) have a look at the following resources:

Ambiguous Name Resolution
MSDN Ambiguous Name Resolution
ANR Attributes
KB Ambiguous Name Resolution for LDAP in Windows 2000
Share

Active Directory Friday: Find users with password never expires

Having password set to never expires might be something that is not allowed by your IT policy, or perhaps you would like to get some insight about how widespread this setting is in your domain. In order to find accounts the Search-ADAccount cmdlet can be used. In order to find all user accounts that do have the password never expires option enabled the following code can be used:

1
Search-ADAccount -UsersOnly -PasswordNeverExpires

Alternatively the Get-ADObject cmdlet can also be used in combination with an LDAP filter to filter out the user accounts and the password never expires option. To filter out user accounts we should filter the following: ‘(objectCategory=person)(objectClass=user)‘. To search for password never expires the following filter is used: ‘(userAccountControl:1.2.840.113556.1.4.803:=65536)‘. Combined that gives us the following code:

1
Get-ADObject -LDAPFilter "(&(objectCategory=person)(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=65536))"

It is of course also possible to do this using the DirectoryServices.DirectorySearcher. This time we use a slightly different LDAP filter, instead of filtering on ‘(objectCategory=person)(objectClass=user)‘ we filter on ‘(sAMAccountType=805306368)‘ which gives the same output but is a more efficient query. Also we set pagesize to 100 so we ensure that all results are displayed:

1
2
3
4
5
$ADSearcher = New-Object DirectoryServices.DirectorySearcher -Property @{
  Filter = '(&(sAMAccountType=805306368)(userAccountControl:1.2.840.113556.1.4.803:=65536))'
  PageSize = 100
}
$ADSearcher.FindAll()

And that is all that is required in order to find AD users with the password never expires option set, with or without the ActiveDirectory module.

Share

Active Directory Friday: Change a user’s password

It is one of the most common tasks Active Directory administrators face, changing a user’s password or unlocking their account. Today we will discuss how this can be done in Powershell using either the Active Directory module or [adsi] type accelerator for this purpose.

Setting or resetting a password is rather straight forward using the Active Directory cmdlets, simply use Get-ADUser to get the AD user object and pipe it into Set-ADAccountPassword:

1
Get-ADUser jaapbrasser | Set-ADAccountPassword -Reset -NewPassword (ConvertTo-SecureString -AsPlainText "secretpassword01" -Force)

To unlock an account the Unlock-ADAccount cmdlet can be used:

1
Get-ADUser jaapbrasser | Unlock-ADAccount

To both unlock and change the password of a user using the ADSI type accelerator the following code can be used:

1
2
3
4
$User = [adsi]([adsisearcher]'samaccountname=jaapbrasser').findone().path
$User.SetPassword("secretpassword01")
$User.lockoutTime = 0
$User.SetInfo()
Share

Active Directory Friday: Create new OU

PowerShell can be used to create any number of objects in Active Directory. Today I will demonstrate how to create an organizational unit using both the ActiveDirectory module as well as the [adsi] alternative.

Creating an OU using the New-ADOrganizationalUnit is quite straight forward:

1
New-ADOrganizationalUnit -Name Departments -Path "ou=Resources,DC=jaapbrasser,DC=com'

Using the [adsi] accelerator to create an OU requires some additional steps. First the parent object has to be selected, in this example the Resources OU in the jaapbrasser.com domain. The next step is create a new object, an organizationalunit in this case, finally the changes are committed to Active Directory by using the SetInfo() method.

1
2
3
$TargetOU = [adsi]'LDAP://ou=Resources,DC=jaapbrasser,DC=com'
$NewOU = $TargetOU.Create('organizationalUnit','ou=Departments')
$NewOU.SetInfo()

That is all there is to it, creating an Organizational Unit in Active Directory is quite easy, with or without the ActiveDirectory module.

Share

Active Directory Friday: Determine tombstone lifetime

In Active Directory objects are tomb stoned after a deletion occurs. This is allow replication to occur between domain controllers before an object is deleted from the Active Directory data store. The default value depends on the server when the forest was initially created, Microsoft recommends that this is set at 180 days.

The tombstone lifetime is set at the forest level and can be viewed by running the following code:

1
([adsi]"LDAP://CN=Directory Service,CN=Windows NT,CN=Services,$(([adsi](“LDAP://RootDSE”)).configurationNamingContext)").tombstoneLifetime

Alternatively this can also be retrieved by using the Get-ADObject cmdlet:

1
2
3
4
5
6
$HashSplat = @{
    Identity = 'CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=jaapbrasser,DC=com'
    Partition = 'CN=Configuration,DC=jaapbrasser,DC=com'
    Properties = 'tombstoneLifetime'
}
Get-ADObject @HashSplat | Select-Object -Property tombstoneLifetime
Share