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.....

Diary of an Identity Project

We were chatting last week about what people actually understand when they hear the term 'identity management', and after asking a few people and carrying out a quick straw poll we have decided to expand on our thoughts on the subject.

To go a step further we have also decided to publish a diary of an identity project that we are just about to engage with so that we can pass on tips and tricks and give everyone an idea of what we mean by 'identity management'.

Of course, this will only be one aspect of idm, and there are many more, and yes, we do those as well!

For now though, the engagement we will be describing has a number of phases and deliverables, but the main deliverable is to synchronise a SQL database with Active Directory so that the latest information in the SQL database is always used to update AD and to keep it up to date.

Interestingly enough, the database itself isn't a HR database, and so it isn't necessarily authoritative when it comes to user accounts and numbers of accounts. What it is authoritative for is a number of key attributes such as phone number, address, company, department, title, and some others that we'll use and populate into extensionAttributes.

Before all this can start though, we have a different problem to overcome, and this involves out of date AD account information. More on this tomorrow when we have agreed how we want to address the problem!

Phil