James Lloyd

This is the new home of phpADadmin

The php-AD-admin project was born from a mission I was given from a previous boss to reduce the support overhead of the systems we currently have, by enabling the delegation of would be technical operations to a normal user.

In this case Active Directory (AD), not because we bow down all thing M$. This is because this is the one I know and probably the most popular. Most companies will have various tools to keep track of their employees telephone numbers and contact information (Office, Address, Fax Number etc). Keeping these tools up to date is an administrative nightmare, and a nightmare that only gets worse the more and more users you have.

All of this information plus more is readily available and normally completely under utilised within your active directory. Giving you users to ability to update their own information, and a tool for them to search for there colleagues information. Will give you a user database that’s self maintaining and up to date, if its always up to date you have an invaluable tool for your environment.

The majority of service desk calls in most IT departments tend to be password resets. There are two things you can do to reduce this.

1. Reduce the number of passwords a user needs to remember
2. Allow the users to reset their own passwords.

The first point is easy in theory but harder to implement. Reducing the number of passwords a user has remember can be done by configuring applications to use the Active Directory as its user database. Applications that have an LDAP authentication mechanism can generally use AD.

If you allow users to reset their own passwords you will reduce the number of calls to your service desk, but could also reduce your security. In order to be able to do this and still be reasonably sure your user accounts haven’t been hijacked. You must make sure your users identify them selves before they can be allowed to reset the account. This can be done in two ways

1. Presenting the user with a number of randomly chosen questions (i.e. in a similar way that the bank would confirm your identity by asking you personal information )
   1. The questions and answers the user would setup up them selves before they forgot their password.
2. By sending authorising token or password to a device identified as being in that users possession (i.e. sending a one time password via SMS to their Mobile phone)
   1. The mobile phone number they set up them selves by editing their own AD account before they forgot their password.

Both of these methods are common place and have been accepted in highly secure environments, that I have seen and been involved with.