Read Me

# Domain Auditor 0.31
# Copyright (C) 2006 Mike Seigafuse 
# Contact information: mike@seigafuse.net
# This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by 
# the Free Software Foundation;either version 2 of the License, or (at your option) any later version.
# This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or 
# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
# See the file LICENSE.TXT included with the software distribution for license details
# You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 
# 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA

Domain Auditor was written to simplify the task of tracking "pooled" or generic accounts within an Active Directory domain.  The driver behind this need is/was
compliance with Sarbanes-Oxley (SOX) requirements to have effective controls in place.  The tool has been released under the GPL license
with the approval of my employer (for which I am grateful).  Pooled or generic accounts are those accounts that exist in a domain that cannot be directly tied 
to an employee.  For example when you implement resource calendars under Exchange (i.e. a a conference room calendar) an account must be created for the
mailbox.  Other examples include application accounts, test accounts, or even consultant/contractor accounts.  I think we all have them, and if you are a public
company or just want to be sure you know all the accounts on your domain and why they are there you may find this tool of some use.

In order to facilitate the tracking of these accounts this tool works by populating some field in AD with key data, primarily the description field.  In order
to enable tracking and reporting of the owner and purpose of pooled accounts the following format is suggested for the description field:

Account-Class : owner : Purpose or description of the account

The Account Class can be defined using the Sys Admin tab and by entering a LDAP query that will return only results for that Account Class.  For example lets
assume an account class of Application.  A suiteable decription may be:

Application : juser : Siebel Sales account required to enable Siebel to operate

A matching LDAP query for this account class might be:

(&(objectClass=user)(objectCategory=person)(cn=*)(description=Application*))

When entering an account class under Sys Admin you will also have the ability to put a description of the class in as well as a single User Definable LDAP 
attribute to be displayed in addition to the default results (name, container, owner and description are the defaults returned).  If you wanted to include
the email address in the report you can simply enter email as the User Defined field, or perhaps if you wanted to include the display name you could enter
displayname.  There is also a place to enter a user defined handler if the field you elect to enter a field that you may want to format before display.  For 
example if you include the attribute accountexpires you will note that the number returned is an offset in number of 100 nanosecond increments since some 
obscure date in 1960 - this isn't particularly useful unless you happen to be able to perform the calculations in your head.  The file includes/handlers.php has
a function in it called ExpirationDate that will take the value returned for this attribute from the LDAP query into AD and turn it into a suitably formatted
and correct date of account expiration.  If you add your own functions to format other fields you should add them in this file and they you can call them when
you run the report for your account class from Reports by simply including the function name in the User Handler field under Sys Admin.  

Once you enter your account class, LDAP query and user defined fields and handlers (if desired) you can click on the Reports tab and select them from the 
drop down menu and then click on display to see the results.  When you click on display LDAP queries will be performed against the LDAP server you defined under
Sys Admin and results will be returned in HTML.  When entering the owners in the description field you should enter them as the owner's samaccountname (aka logon 
ID).  Further LDAP queries will be performed to look up the owner's samaccountname in AD to be sure the entered owner is accurate and really exists.  If the 
owner is not correct or does not exist the owner will be returned as (in red text) INVALID - owner.  If the owner is valid then the text will be of normal color
(as defined by the da.css style sheet) and the display name will show on mouseover of the owner.  Using the output of the reports it is relatievely easy to see
which accounts may need to be deleted or have new owners identified.  The output of the reports can also be retained as evidence that you periodically review 
pooled accounts (shows effective management of the accounts in your domain).

Other useful account classes that may or may not apply to your organization could include:
Resource (shared mailboxes or conference room calendars for example)
Contractors (self explanatory)
Temporary (perhaps temporary office workers or administrative support staff)

In some organizations other fields are populated with key employee data.  One example might be to populate extensionattribute1 (or others) with the employee ID.
We use this field in my company to interface to our HR system and allow us to autoamtically maintain some key distribution lists of employees only, as well as
send demographic and orgnizational data to AD (and therefore to the Exchange Global Address List) - data such as title, phone number, etc. If you do this you
may also be able to create an account class and report that contains all the accounts that aren't already classified and/or don't directly belong to an 
employee.  The LDAP query might look like this:

(&(objectClass=user)(objectCategory=person)(cn=*)(!(extensionAttribute1=*))(!(description=Temporary*))(!(description=Resource*))(!(description=Application*))(!(description=Contractor*)))

Note that the LDAP query has (!(extensionAttribute1=*)) which basically means return results where extensionattribute1 does not exist.  The query is formed in
this way because if a field in LDAP has no value the attribute basically doesn't exist for the object with no value in that attribute.  If your configuration
is similar then this report can be used to identify orphaned accounts (or accounts without a clearly defined owner).

Security Notes

There are currently two roles for any given user account:

Admin - has full access to all functions
User - has ability to add new account classes and run reports, no access to system settings, user admin or audit logs

This tool is intended as an Intranet tool only.  Exposing this tool to the Internet is in no way intended or endorsed.  It is strongly advised you not use this
tool over the Internet.

Limitations
Please review the RELEASE_NOTES file for limitations, known issues and future possibilities.