Noticing that public self-service tasks are deployed and on client workstations, but that the vast majority, if not all of the end-users, either refuse to use them or give up on attempting without contacting the help desk.
My thought is that this has to do with the QnA pairs and that this isn't built into the enrollment process, or onboarding process for new identities and existing users can't utilize these features without issues. Within another solution, I recall a clever workaround of triggering a pxp to run a powershell script which would trigger a login script that would launch a web browser on the client workstation at user login that prompts the end user to fill out their QnA so that they could use their password self-service tasks when they need them. After filling out their QnA then the PxP would disable the login script or registry setting on the domain client workstation.
Essentially what I'm looking for is ideas on
1) how to ascertain who is using the public tasks (successfully & unsuccessfully) maybe through submitted tasks, ldap or the database
2) who isn't setup properly for identity verification with public tasks and how best to encourage or require these users to complete their enrollment (PXP or some other methods)?
3) how best to encourage the use of these self-service features currently deployed on workstations throughout the enterprise.
My concern is that this ca identity manager self-service technology is the first touch point for ca identity manager and if every time a user clicks these self-service links, on their computer, ca identity manager simply says that the user is disabled this isn't useful. It requires the end user to call the helpdesk anyway, how does this create a positive impression for the identity management features and functionality currently rolled out when simple self-service is inaccessible for most users?
I'm sure this has come up before with CA services, CA support, and other customers, so I'm looking for real world feedback to not only check a check box that self-service was implemented, but to truly roll it out effectively, to the entire organization, and encourage the use of these self service features by ensuring that every user within the enterprise is authorized to self-service themselves without having to contact the help desk every time they have an issue.
In an AD-windows world there are a few real-life implementations of CA IDM public tasks incorporated into Windows Credential Provider/GINA (previously) with wide user adoption. Setting/unsetting user attributes (through policy xpress or task handlers) are an effective way for one to capture usage metrics; just as audit log perusal. LoginScript trick has been used at a handful of sites to auto-spawn IDM tasks.
In my understanding the adoption issue with these QnA and such are not the technology itself per se - it is simply that most of us are not willing to be bothered and forced into supplying responses to arbitrary questions (and memorizing them) - it is an artificial contraption. A truer approach is to provide security transparently, which is not currently in most security products. However, quite a few researchers are attempting proximate ideas.
Hope that helps
Thanks. I'm wondering though is this truly is it a product adoption issue or more of an ineffective roll out issue in how public self-service has been delivered to the end users? Perhaps if we published more details on the "LoginScript trick" for use with the password self service tasks this would help drive CA IdM product adoption and it would significantly increase wide spread utilization in this area?
What I've seen is in deployments where they've implemented the "LoginScript trick" the usage of public tasks is much, much higher then in deployments without the "LoginScript trick", even though they both have public tasks rolled out on the end-user client workstations.
My thought is if communities could help by providing more examples of the "LoginScript trick" perhaps the community as a whole would benefit from this and drive more product adoption for self-service tasks in all ca identity manager deployments in general, especially those struggling in this area and having difficulty getting their end-users to effectively use the product and feature which was a key selling point in the roll-out initially.
Having the mindset or perception that it's a client's cultural or end-user base who's too lazy to be bothered setting up QnA isn't at the root of the problem. I think it's more that end-users aren't required to or aren't prompted too, pointing more to a design issue, which I feel could be mitigated with more details published on the "LoginScript trick" by publishing example PXP's and doc on how to effectively set this up. It's worth noting that public tasks are typically the first thing to be rolled out to an complex and large organization with nothing else within the IdM UI for end-users to consume. There may be password QnA collected in other applications because the end user needs to gain access to that application for something to do their job, but if we wait until the end-user needs to gain access to ca idm through the public task, we've already missed the ball because at that point enrollment is impossible. It seems more work needs to be done in this area to ensure a smoother product adoption considering quite a few of CA's largest customers use only this and a few other features of CA IdM in their enterprise and encouraging product adoption by all users would only assist in the "land and expand" motto.
PPM is currently being used in this enterprise and requires the end user to answer QnA before accessing, is it possible to reutilize these QnA pairs within CA IdM? If so, how do you populate CA IdM with CA PPM QnA pairs for the same identity?
Does anyone have a copy of the "LoginScript trick" that they can post to this thread to help with enrollment and utilization of the password self service tasks?
The login script itself could be a simple logon.cmd file located on the domain controllers, at %SystemRoot%\SYSVOL\sysvol\<domain DNS name>\scripts folder (try this out for your domain controllers though). You can assign these though AD Users and Computers or GPO. The content of the logon script could be something like (check this for your environment, for e.g. use of 'start', use of powershell, etc.):
I'm trying to get more insight into how many users are having issues using the public tasks. I'm going to get reports from the help desk (CA Service Desk) to see how many account unlock or password reset calls they're taking and compare them to CA IdM VST results. Specifically I'm interested in getting more analysis of the utilization, or mis-utilization of the public tasks, through IdM. I'm poking around but wanted to try and figure out how to query the audited transaction for when you try to run forgotten password reset or account unlock and it responds back to the end user with "account disabled". I want to count up all these unique instances, per user ID, for a set period of time, which I think will help gauge how prolific the underutilization of the public tasks are within the enterprise, or if it's functioning well. It's easy to find the public network account unlock that are completed successfully by using the VST GUI filtered on Description, Status and Initiated by PUBLIC TASK, but I want to catch the ones that are failing to complete. Only looking at the successful ones is likely not the full picture because it doesn't include the attempts that were made, but failed because CA IdM reports back to the end user that public task can't proceed because user account disabled.. Any more information you could share on this point too, would be greatly appreciated and I will post more as I continue to research VST and audited transactions.