As a company grows, so does its number of personnel. And, as any systems administrator can tell you, as the number of personnel grows, so does the number of user accounts that the administrator needs to manage. For the most part, Active Directory (AD) scales up well so that managing large numbers of users isn't typically difficult. Because each user has a unique user account, locating and modifying a user's profile settings is easy. However, there's one exception to this rule: the vast sea of email addresses that can plague the network administrator.
Administrators often create multiple email accounts for one user. As a prime example, even the administrator probably has multiple addresses, such as admin@yourcompany.com, administrator@yourcompany.com, hostmaster@yourcompany.com, and webadmin@yourcompany.com. The existence of multiple addresses (aka proxy addresses) can make it difficult to determine which user account receives email for any given email address.
In this article, I offer a script that leverages Perl and some Windows technologies to query AD and determine which user account receives mail for a given email address. From any machine on the network, you can simply open a command-line window, run this script, and achieve the desired results.
Managing Email Addresses
You can use an AD account's E-Mail property to identify a particular user's email address. Because AD doesn't offer native email support, this email address can be pretty much anything—jon.doe@gmail.com, 12345@ yourcompany.com, and so on. I equate the usefulness of this address with some of the other AD account properties, such as Telephone Number and Web Page URL. The primary value of these properties is that some programs can query AD for them and display them onscreen for the user.
However, if you have Microsoft Exchange Server installed in your AD network, giving your accounts email addresses can be particularly useful: Users can actually send email to these accounts. One interesting Exchange property associated with a user account's mailbox is called proxyAddresses. This property is a list of all email accounts that the mailbox can receive. This list of addresses lets a given user receive mail that's sent to separate addresses— for example, a sales rep can receive mail for the addresses sales@my company.com, customer_questions@ mycompany.com, and leads@my company.com.
Querying AD
In a network of thousands of user accounts, with potential multitudes of unusually named email addresses for each user account, determining the sole recipient of several email addresses can be challenging. There are many ways to query AD for information (e.g., the proxyAddresses lists)—for example, you can use Lightweight Directory Access Protocol (LDAP), among other technologies. However, by using ADO databases (ADODB) and Active Directory Service Interfaces (ADSI), the FindEmail.pl script— which you'll find in Web Listing 1—turns a monumental task into an easy one.
One of the main reasons for using ADODB and ADSI is that they both use Windows' user credentials to query AD so that your script doesn't have to specify user IDs and passwords to gain access to the database. And ADODB is a quick and efficient way to perform database queries into ADSI.
Generally speaking, querying AD is pretty simple. You use ADSI to locate an AD server on your network, then submit a query looking for email addresses. Finally, you walk through the resulting list of accounts that match your query criteria. Of course, the actual execution is a bit more complicated, as you'll see in the next section. The most complicated aspect of querying AD is constructing the query criteria. For information about how to do it, see the Microsoft article "Microsoft OLE DB Provider for Microsoft Active Directory Service" (http://msdn.microsoft.com/library/en-us/ ado270/ htm/ mdrefad sprovspec.asp).
To query AD, the FindEmail.pl script uses the following criteria:
<LDAP://$Config{address_path}
$DomainContext>
(| (mail=*$EmailAddress*)
(proxyAddresses=*:*
$EmailAddress*));ADsPath;
subtree
This criteria specifies that the query will start at the tree level of $Config {address_path}$DomainContext. When the script runs, the query will default to the top level of the AD domain, which is what $ DomainContext represents.
If your AD domain is large, searching for email addresses can take considerable time. Therefore, you can specify an address path—for example, only within a particular organizational unit (OU). Suppose your AD domain has separate OUs for the Sales Department, Executives, and IT. You can search only the Sales Department by specifying an address path of OU =Sales,OU=Company_Departments. The next part of the query is the filter. In this case, the filter criteria are looking for any account that has a mail or proxyAddresses property that contains the string the user specified. In the case of proxyAddresses, the email address is in the protocol:address format. Internet mail (aka SMTP) addresses would be in the smtp:john .doe@mycompany.com format. Note that the protocol is case-sensitive; an address with uppercase protocol is the primary address for that particular protocol. Exchange uses this primary address in the From field of outgoing messages from the account. Only one proxy address can be a protocol's primary address.
The next part of the query— ADsPath—specifies a list of commadelimited AD properties that you want the query to return. In this example, the query is asking only for the ADsPath (e.g., LDAP://CN=Administrator, CN= Users,DC=mycompany,DC=com). The script later uses this data to obtain the actual user account ADSI object.
The final part of the query specifies the query's scope. The script's query criteria indicate the scope to be subdir, which recursively searches for matches from the address path and below. Other options are base and onelevel, about which you can find details in the aforementioned Microsoft article.