This is what I am talking about....!

This article succinctly captures the business need for developing discipline around the management of identity data, and contextualizes the security posture and excess risk when it is not done.

The Intersection of Business Intelligence and Identity Management: Identity Governance

Beware the Enemy

Does your organization have some set of processes that live on paper, or in spreadsheets, or some other "out of band" method of administration? And you, the Directory Manager are trying to explain why there are some interesting number of accounts in your directory that are non-conforming in some way? Don't have password expiration, or don't have a long enough password?
You need a strategy for controlling the data that governs these exceptions; maybe even would like to to know the who what where of what is governing them. A reasonable request. You started looking into it. You found some things, but others eluded you. Time and effort constraints caused the pertinence of these issue to slip off your radar.

Then the auditors came...

They gave your boss a report. It was full of words like "non-conforming", "out of standards", "in violation of" and the like. Sheesh! Your boss sends you the 6:00AM email that asks what this is all about. How can it be??

Wait - isn't this admitting defeat?

This is a curious turn. I guess Novell is dropping the idea that one day it will conquer Sharepoint with Novell Teaming and Conferencing....

Microsoft, Novell collaborate on LDAP access to SharePoint

Softerra Releases new Beta of LDAP Administrator

Quick sidebar plug - Looking forward to putting the new version through its paces. I have long been a fan of Softerra's LDAP Admin for managing several LDAP directories at once. I will be reporting on what I find out about the new features. Stay Tuned.

Part 2 - Identity Management vs Provisioning

Is the Provisioning approach really all that bad?? - it doesn't have to be. There are things that you can do to guard against the pitfalls.

For example... if the provisioning system you are looking at deploying has as its first dialog, do you want to "Create a New User" or do you want to "Modify an Existing User" - run the other way as fast as you can. The first dialog should be...
"Enter the demographic data for the person you wish to operate on: " By getting the name, phone number, SSN fragment DOB, or other personally identifying info, you have a chance of making it out alive. By getting this info first, you allow the system to see if there appears to be a match in the provisioned system already. (And for the love of God, - don't perform the match check on any variation of name!).

Even better, use a different identifier altogether. Look at all the new measures that banks are taking in order to make sure that they have the right person. Have you forgotten the password to your online banking account lately? If you have, you probably have seen the need for going back to the basics of system authentication: "something you have, or something you know". For strong authentication, require 2 forms of authentication in serial. The point is, once a bank establishes an account (checking or savings account); they associate that account with an Identity (with a capital "I") and all access from the consumer side requires comprehensive knowledge of the Identity details. From the provider side, no action is taken until the authentication happens. A new "create" event for an account should only be programmatically allowed after there is a substantiation that the data entered matches no existing Identities. For a "modify" event - it must perfectly match an existing Identity...

Note: I said Identities, not accounts. Your system design may require that an Identity have multiple accounts, and in almost any modern real-world system, likely will. This point of contention must be addressed. Programmatic controls must be devised that link new / existing accounts to the correct Identity. Without solid Identity data that is linked to personal attributes (date of birth and SSN leap out) you can't strongly ensure appropriate Identity matching.

So - fun detour; back to avoiding the pitfalls of the Provisioning approach; - if you firmly establish a process for acquisition of personal data at all provisioning "points of administration" prior to account actions, you stand a chance. The trick is to acquire the data and still honor organizational requirements for privacy and security. There are actually some very straightforward ways for achieving this that I will hopefully address in a post fairly soon.

Bottom line - in your design phase, make sure that you establish the difference between an Identity and an account. Make sure that you establish the Identity before any / all of the account actions. What is required for your organization will be different for another organization. Talk to your lawyers / Chief Privacy Officer about what they feel needs to happen. By all means, get down into the weeds about what will be the possible relationship between accounts and identities. Will it be possible for an account to have more than one owner? (Think of a joint checking account that a husband or wife share.) In the corporate LDAP world, a service account may require (or be allowed) more than one owner. All Secondary accounts need to be linked to a primary. In this case, the primary is tightly coupled to the Identity, and the secondary is coupled to the primary. Your design should include smooth handling of all instances where a secondary or primary account goes away, and the Identity is retained; in accordance with your organizational needs / regulatory requirements.

Above all - look at your environment, if you are creating accounts based on arbitrary, "non-business event driven" conditions, you will have a major headache in some amount of time. The smaller, less complex your environment is (under 5,000, or 2,000 accounts) the more the issue may be masked. When your environment is complex, or large (more than 10,000 complex accounts) it will very quickly become apparent.

Again, everything in this post addresses an approach to account provisioning that offers alternatives to direct, comprehensive linking of Authoritative Source data to operational account data. Use Authoritative Sources as much as is practical. This is another careful consideration in your design phase. Provisioning needs to happen for systems that offer discretionary services. This is a rabbit hole trip down into RBAC theory, and will be saved for another lesson, but an example may be an account in the corporate email system, or certain services for an ISP. Someone may be approved to, or buy into access to a system that is completely discretionary. Before you take action in that system, adhere to the principles we are discussing.

Part 1 - "User Provisioning" vs "Identity Management" - what is the difference?

I see these two terms lumped into the same "bucket" all the time. Executive-Level management uses the terms interchangeably in negotiations and discussions of departmental roles and responsibilities. I roll my eyes and shake my head every time that I see this done. They are (to my definition) significantly different things. How so? Lets have a look into the differences....

A "Provisioning" system, in terms of an enterprise system that creates accounts in LDAP sources, user tables in databases, mail systems, and the like, is characterized by the following:
1. Arbitrary creation processes; -- in other words, when the provisioner thinks that some entity needs to have an account created, they use the Provisioning tool to "provision" a new account. The account appears to have come out of thin air.
2. Lack of "connectedness" -- this is characterized by the lack of linking to source data, and difficulty with subjecting the process to technical controls. The system is not event or data driven. The arbitrary process described in bullet one is kicked off as the result of a phone call, or an email, which describes the "entitlement" to the provisioned system in ad hoc terms. The Provisioning system is an interface / front end to the account store, and nothing more.
3. Requires a very clear layer of persistent manual intervention. Since we are not connected to any source data, and are not truly event driven, someone has to take action on behalf of someone else to make the system work. I say "truly" event driven, because there is a very real difference between being really event driven, and appearing to be event driven. Phone calls, emails, and conversations do not constitute the basis for something being "connected" or event driven.

I now highlight what the key piece of the difference really is....
In order to be an Identity Management solution and not a Provisioning system, the "trigger event" needs to come from a line of business application; - that's it. What is a Line of Business application? It is one that manages or serves core business transactions; it is not one that exists for the purposes of serving the Provisioning system. For example, a contracts database that manages all the data on contracts and contractors, - or the corporate Human Resources database, or the customer transaction database. In other words, you get a new contractor, you get a new employee, you get a new customer, - the Identity Management system takes action based on programmatic hooks into the data source.

To put it in a nutshell, the IDM system listens for business transactions, and takes action based on what it hears. A provisioning system listens to itself. It takes action arbitrarily. Stayed tuned for Part 2 where we explore why you need to stay as far away from a classic provisioning system, if you can. For data integrity, I am hanging my hat on the identity management approach.

A favorite quote of mine....

I don't know who to attribute this to originally, - I have adopted it as my own. (Please forgive me for not citing the correct source if discovered). I call it the "Identity Management Premise":


" Firewalls, Intrusion Detection, VPN, Anti-virus and other perimeter security measures would be really great technologies if the people that you really needed to worry about actually sat outside your firewall"

Spring this one on your boss / client right before budget time, you'll certainly get his attention