I am currently working on scripting some of our access at work and would love an easy way to enter and retrieve the last 4 of a user's social sec number. It's the primary way we identify people that call. Currently we have to log in and search through our HR application which is pretty cumbersome to use and adds time to a call. Chances of me getting management/senior engineers to approve of and extend the schema are almost nil. I was thinking of writing this number to the employeeNumber attribute but unsure if there are any unseen consequences in doing so. Apparently someone at our old helpdesk started entering this info into the 'telephones' tab in AD which can be seen through Outlook-global catalogue...managmeent was not too happy.
Is this a decent idea with what I have to work with? or?...
The employeeNumber field while not viewable via the GUI is still able to be queried by anyone with read access to AD if I'm not mistaken. It may take more effort than "Outlook" though.
But honestly...it's the last 4 of the SSN...so I think your approach, if management is fine with it, is good enough.
Just make sure you don't care about an actual employee ID number in the future being stored there. But yeah, it's not something that will mess up something else if you arbitrarily pick a number to store there.
The default, out of the box schema already contains both an employeeNumber and an employeeID attribute...
Reading the attributes:
Setting the attributes:
I'd be really careful about storing even the last 4 of the employee's SSN in Active Directory. By default, this information will be readable by all authenticated users. And I personally would consider even the last 4 digits of other people's social security numbers to be worthy of more confidentiality than that.
If you're going to do this, I would at least recommend marking the attribute as confidential by modifying the searchFlags attribute: http://support.microsoft.com/kb/922836