Diary of an Identity Project #2

Apologies for not maintaining the diary of the identity project; the first two days of the project have been spent discussing targets, technical platforms, Active Directory contents, and incorporation into SharePoint and Microsoft's Enterprise Search solutions, so it's been extremely busy and all hands to the pumps.

Typically in an identity project we attend site to undertake an in-depth investigation, scoping and proposal, which gives both ourselves and the client the opportunity to examine the facts and mull them over before arriving at a project methodology and a series of work packages. With this engagement, due to time constraints on the client side, we have not been able to scope the work beforehand but have set aside the first 3 days of the engagement do perform this task.

The client has a SQL database (at leat we were told it was SQL; it turned out late yesterday afternoon that it is in fact MySQL and located in a hosting centre remote from the offices - these are the small things that crawl out of the woodwork during a scoping exercise that make so much difference!). The database is completely stand alone and has been developed to store contact details of users and partners. There was never any intention to have any connection to the client's Active Directory, and as a result there is no common key easily available within the two systems.

The most likely key for us to use is the email address within the SQL rows, and the mail attribute in AD. The problem being here that only about 60% of the 15,000+ users have the mail attribute populated, and that raises another issue: the reason not all objects have a mail address populated is because the client maintains a Notes environment. This means that all users have an AD user account but Notes users also have a contact object which has the mail attribute populated, so using mail as a key is impossible on its own.

Therefore we are now investigating the adoption and population of a logon ID or sAMAccountName column in the SQL database, which is a big task, but as sAMAccountName is not in the contact object schema we can safely adopt this attribute as our primary key, *IF* we can get it populated.....