Skip to main content

HomeDirectory name inconsistency and LDAP Query weirdness

Recently I was doing some work where I had to archive some home directories of people who were no longer associated with the company. A typical configuration looks something like this:


User:samAccountName  -> \\Server\Home\%username%

Such that the samAccountName property has the same name as the directory in whatever home share is being used.

What I ran up against, though, was that over the years - through marriages or divorces or other personal reasons, sometimes people would request that their username be changed. The company I was working with sometimes accommodates these requests. My job was to identify if any of the home folders were associated with accounts that had different names.

For example - consider this timeline:

1. User bjones is created with home directory \\Server\Home\bjones
2. bjones gets married and her account name is changed to bsmith

Now user bsmith has \\server\home\bjones for her home directory. This typically isn't a problem technically but administratively it's a pain.  The question is, how do we quickly find out which folder is associated with which Active Directory user?

First, I'll tell you what did not work - and this is surprising!  Within Powershell, I browsed to the Home Folder share and issued the following command:

dir | select fullname | % { Get-ADUser -LDAPFilter "(homeDirectory=$($_.fullname))" }

(Logic: the folder names correspond with the samAccountName so I could use that for the ADUser and for the homeDirectory LDAP query)

This command worked but only on some accounts. In some cases, even though the homeDirectory matched exactly, no result was returned from Active Directory. Why?   I don't know. Independent testing of this has not yielded any solutions, though it has yielded the same results.  So - this is a problem I'm going to have to re-approach.

Still - the problem had to be solved so I came up with another way to get that information. That solution was this:

Get-ADUser -Filter * -Properties homedirectory,enabled -ResultSetSize $null | ? {$_.homeDirectory -ne $null -and $_.homeDirectory -notmatch $_.samAccountName }| select na

e,samaccountname, homedirectory, enabled, @{l="path_Exists";e={test-path $_.homedirectory}} | ft 

The logic here as as follows:
1. Get a list of all AD users and include the homedirectory (and just for fun) the enabled property
2. Use "where-object" (?) to filter out users without a homeDirectory and require that their samAccountName is not found in the path of their homeDirectory
3. Select the properties I want and build a new property for whether or not the folder name defined in homeDirectory actually exists

With this information I am able to quickly see users who have an inconsistently named Home Directory folder, if their account is enabled, if the specified path exists, and of course, their full name.  Enough information to make some decisions on.


Comments

Popular posts from this blog

Automating IP addresses with TMG

In the past few months I've had the "opportunity" (note the quotes, maybe I'll write a post about all the troubles I've run into) to deal with some Office 365 integration projects.

When integrating one or more cloud services with Office 365 or Office 365 with on-prem Exchange, it is typical to limit the IP addresses that are aloud to communicate between services. This is an important layer on the security model and obviously reduces the attack surface. Microsoft maintains lists of IP addresses for the various services here:

http://onlinehelp.microsoft.com/en-us/office365-enterprises/hh373144.aspx

That page links to other pages with more specific information about various other Microsoft cloud services such as the link below for Exchange online.

http://help.outlook.com/en-us/140/gg263350.aspx for example.

At the time of this writing, you'll notice that the lists are inconsistent between pages. >:-(

Microsoft on two separate Premier Support Calls has told me…

Windows Last Logon problem and solution

As someone who has been involved in Network Administration (in Microsoft Land) since Windows NT 4.0, I find it surprising that is still so difficult to get simple (yet important) information such as "When was the last time Joe User logged in?".

One would think that, with the fourth edition of Active Directory in production (Windows Server 2008 R2), a tool or set of tools would have been issued with Windows to provide those answers.  Well, because they don't, I've decided to go ahead and write one.  (Yes, I know that there are probably others out there to be downloaded or purchased but... you know, I don't care.)

All that is required: PowerShell 2.0 (and a functioning Active Directory).

Defining the Problem:
Active Directory stores numerous properties on objects in the Directory. Some of these properties are replicated amongst the Domain Controllers and some are not. Unfortunately, for some reason, one of the design decisions was to not replicate the "LastLogo…

LDAP and SAN Certificates

Hey everyone - I ran across an interesting problem with certificates and services. The problem was that I needed to see which certificate is being presented to the client on a non-HTTPS service; specifically - binding to LDAP over SSL (LDAPS). So the question is, how can you be sure what certificate is being presented?

Windows, so far as I've been able to find, does not offer any native help in this regard. Luckily there is a solution, but first let me give you a slightly longer description of the scenario so you can appreciate what we're talking about a little bit better.

An environment exists with some number of Domain Controllers, let's say ten. Within this environment, third party applications (think Java apps, Linux systems, etc) need to bind to LDAP to enumerate groups or validate authentication or whatever. These systems, however, can only have a single (or at best, two) LDAP hosts configured. What do you do? Pick two DCs? Round-Robin DNS?

Well, in my case, a load-b…