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

What is Authentication? -- really?

Username and Password please....

to authenticate is to prove or serve to prove the authenticity of something. I have a guy (okay, more than one guy!) at work that is questioning "why have 2 authentication sources; - why do we have Active Directory and eDirectory??" I said - "2 sources??; we have a few hundred when you look at every place there is a store of login IDs and passwords". Just a typical organization with well over 50,000 identity-related objects to keep tabs on, that has grown by necessity and not careful planning. What are you ensuring the authenticity of?? Well - its an account in my system of course. But where does that account come from, - how did it get there, and what are you doing to make sure that its presence in your system is appropriate? Aren't these more pressing issues?

The key idea in this post is to point out that when you give somebody in your organization a username and a password to some system, database, or application, you are saying that knowledge of these credentials is all you need to gain access to whatever data or power is behind the curtain. If that is all you need to prove, why not just give out a single user ID and password of "password" to everyone?? What differentiates one user of the system from another? Wouldn't that save a lot of headache to just have one ID and password? Is this really authenticating? No - its surely not. This is a fundamental data integrity issue (or more so, the metadata the for the user accounts), and the potential for undermining the value of the data stored the in protected system. Not a wise move in the current regulatory environment...

What you allow / require in order for an account to be created is your declaration of value of whatever resource you are hoping to protect by authenticating. Your diligence in making sure that any account, for whatever reason fails the appropriateness test for access to your system, is promptly and verifiably removed from the account store is your profession of how serious you are about data security. Of course there are all kinds of ways (besides a username and password) to authenticate someone or something for access, but the business need / grounds for possession of credentials is the real issue. The way to ensure that access is appropriate is to maintain the integrity of your Identity data to an appropriately high standard. What are you doing to ensure that all accounts in your system are appropriate? Does the data you maintain give you a clear picture on this?

So - why 2 authentication sources? - why 400? because it is not the role of the information security professional to decide what is the best / most cost effective tool for the organization, it is to make sure that the accounts granted access are valid. This is done by making sure that what data / metadata that exists in the account store is authentic; that it is not allowed to be altered in any inappropriate way, that it is kept clean and consistent. The heavy lifting of the authentication process is not done in the exchange of usernames and passwords, it is done when the account is created, disabled, and deleted. The battle is won in making sure that the data that gets into the account store is appropriate, and is removed when it is not. Consider these issues when thinking about what account stores (vendors and products) are appropriate for your organization.