title: Enterprise Password Management, Part 1 link: https://onemoretech.wordpress.com/2009/02/13/enterprise-password-management-part-1/ author: lembobro description: post_id: 378 created: 2009/02/13 15:12:58 created_gmt: 2009/02/13 15:12:58 comment_status: open post_name: enterprise-password-management-part-1 status: publish post_type: post

Enterprise Password Management, Part 1

Password management across systems is an old problem. The usual solution is to pay for some software to provide a common infrastructure piece to do the job. All of these systems also provide password synchronization of some kind. Examples are Oracle’s Identity Manager or Sun’s Windows Password Sync. Pretty much every vendor who does identity management has their own solution. There is another way though.

It’s what I call “password provisioning”. Basically the idea is that you don’t bother to sync passwords between systems. Instead, what you do is provide a central web page where people can reset their passwords. The app behind the web page then communicates to the various systems to be provisioned and forces whatever new password the user has chosen onto those systems.

The big problem with this is that you wind up circumventing any built-in security features on the particular platforms targeted. In addition, you have to custom build all the security you’d want around this kind of utility, including password hints and password hint answers. You also need to settle on one of these systems as “authoritative” for authenticating to the password provisioning page in the first place. Another issue is that all the target systems will have their own password policy and their own way of notifying users that a password has expired or account locked for some reason — redirecting the user to the target’s own proprietary password management mechanism. The key to making a “third party” solution work is educating users to see it as special “tool” they can employ to bring some sanity back into their lives, with full knowledge of the eccentricities of how the native system operated.

Here’s a conversation that begins to go down that road, specifically discussing the challenges of doing Active Directory password management with a non-Microsoft API (in this case LDAP):

(09:38:45 AM) Rob: do you think you could do something in perl to do the password sync?
(09:53:23 AM) Phil:_ nope. not a true sync. we can’t capture the pw changes from the ad side without an agent. what we could do is ldaps-enable an ad dc and then force changed down into it from a central web page. password management rather than password sync._
(09:54:57 AM) Phil:_ of course then you have the replication interval on the deal with, unless pw changes are prioritized over other traffic and are sent immediately. otherwise you’d need to have all dc’s with ssl and have a drop-down to select the user’s home dc._

Enough to make you run to your commercial vendor’s sales rep, ain’t it?

Copyright 2004-2019 Phil Lembo