In this economy, I've been repeatedly pinged by clients on how to maximize their investment in their existing Identity Management software investment. In other words "I want to do all this stuff, but I don't want to buy more software, and barely buy any services."
So here is an idea that came from a conversation with one of our engineers. This is for clients that own a Password Management solution only, but want to be able to deprovision users. They could create a workflow to change the password to all target systems to a random password that no one knows. In effect, the user would be locked out of all accounts. A small program could be written to call the workflow's SPML interface (assuming it has one) based on a feed from Payroll or HR as well for a nightly process. No new software, barely any services, but an effective deprovision of accounts.
I'm noodling if this would pass an audit, but I doubt it would since the account is still active. But it would work, it would leverage the clients investment in connectors built for all target systems, and could be accomplished in no time.
I think it's the best thing since sliced bread, but I'm sure I'll find a new favorite tomorrow. Would this work?
Subscribe to:
Post Comments (Atom)
Posts
11 comments:
Changing the password on a target system is often harder or at least roughly equivalent than deactivating/disabling/deleting account.
True, but I think the point is licensing and effort. If a password system is already in place, the time and effort to add this feature is minimal. It might also be cheaper is the product is licensed like that.
Depending on the password reste system was implemented, what would stop the end-user from just resetting the password again? You would also need to be able to set the cannot change password attribute, if there even is one.
@Anonymous ... if connectors are already configured with pw reset capabilities, all this would require is a new workflow.
@Jeff ... Good point and good resolution.
Good points - could do all. Many systems such as anything AD, LDAP, or Domino based can just send the 'disabled' flag, or toggle the bit scriptomatically or with standard LDAP tools. Would be similar to the sunset workflow on IdM systems.
RE: Audit -- Could pass audit *if*
1)Documented and followed religiously
2)Target accounts could be consistently queried & results returned
3)The new process takes next step querying and bulk deleting disabled accounts.
Assuming any workflow can call external scripts, they're in business.
Could all be scripted in perl/vbs/shell in addition to PW system. If they're really cash strapped, a cost-effective, though inelegant solution would be just to have a third party script the plugin script that the PW system, or workflow would call.
Interesting ideas! Best of luck with it.
-Corbin
Hey,
I think that this is more complicated than it seems,
First, connectors, second, task queuing(what happens if the password fails? due to connectivity failures or any other problems that might happen), audits, what about password policy that is different on each system...
Check Velo, it covers it all, and it's open source :-)
Asaf.
@corbin - hack city! :) but all good ideas.
@asaf - you might be missing my point. in my scenario, im assuming they already have a pw system in place (for example, velo). now they want deprovisioning with the least amount of additional expense and management overhead.
If I'm attacking the system from the inside I would go after the disabling password. This means you are going to have to look at the logs regularly for activity in one of these disabled accounts; that could get expensive.
Also userid's that are still active require license fees to be paid to the software vendor. At least that's the case in the SAP/ERP world ... Could get very expensive after all.
http://identityman.blogspot.com/2008
cheap wow power leveling buy wow gold cheapest wow power leveling CHEAP wow gold BUY power leveling CHEAPEST wow powerleveling
wow goldwow goldwow goldwow goldweiwei
Post a Comment