Although, from a ITIM point of view a RACF account blocked by excessive number of failed logons and a suspended account by administrative reasons is showed on the same way, account disabled, we are interested to be able to manage both situations on a different way. On the former issue the user should be able to unlock its account; on the latter, just an user administrator should be able to restore the account.
There are systems when both situation are flagged on a different manner. In Windows, for instance, there are two account attributes, eradaccountlocked and eraccountstatus
Any clues how this approach could be managed? Take into consideration that the blocked account by excessive number of failed logon is showed as inactive by ITIM thus, a change password cannot be done. On the other hand, the user must not restore an inactive account since it could be done by an administrator.
Thank in advance.
This topic has been locked.
3 replies Latest Post - 2013-02-14T11:04:59Z by SystemAdmin
Pinned topic How to manage disabled RACF accounts
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
Updated on 2013-02-14T11:04:59Z at 2013-02-14T11:04:59Z by SystemAdmin
Re: How to manage disabled RACF accounts2013-02-07T09:28:54Z in response to SystemAdminVery good question...
I am afraid that the answers are not that good.....
I am not a RACF expert - but I believe that what the adapter is designed to is to map the individual RACF commands to attributes as per the Adapter guide App. A
So : basically there is no way ITIM can know if the reason for a locking of the account is due to failed logins or revoking the user unless this can be derived by a combination of the revoke data attributes and the account status (which I doubt).
If your information is available in RACF the I would propose to raise an RFE to get a new attribute.
In a more philosophical attempt to solve this one could argue that ITIM should add another set of operations namely Account Lock/Unlock with associated adapter functionality, GUI status and operations... - but I doubt that this would be something that our product management/development would consider a high priority (but if you dare you can raise an RFE).
As a work around you may be able to retrieve the status in RACF by other means and then use an Unsolicited Notification Event to update a custom attribute on the account - this sounds simpler than it is as the attribute must be excluded from reconciliation processes - luckily there is such ONE attribute (came in 4.6) erLastOperation which you use for this purpose. But I do not know if it possible to update this attribute using the Event provider (but then you could write you own little ITIM Java code that did this instead - but is more expensive than just hooking into the ITIM solution framework)
I can think up other ways to work around the problem (code in operations) - but this in general quite ugly and not recommendable....
Re: How to manage disabled RACF accounts2013-02-11T16:44:29Z in response to SystemAdminHi Franz,
thanks for your reply. I think any solution has a bigger effort that the benefic will be got.
I'm try to implement next procedure:
1.- Taking into consideration a Change Password request means the account is "active" (from an ITIM point of view), ie, the account has not been Suspend by the User Administrator by means of ITIM interface, modify the Change Password workflow for requesting a Restore account operation before. It allows the end-users to unlock its accounts before next reconcilation will be done, ie, next working day.
2.- If the account is showed as disabled on ITIM, mandate the end-users get in contact with their administrators for unlocking their accounts, they will be the responsable for the final decisions.
Re: How to manage disabled RACF accounts2013-02-14T11:04:59Z in response to SystemAdminLong time since I worked with RACF and I can't find the latest adapter documentation but I think there may be an easy way to do this.
Although in ITIM the account is showing as inactive it should be possible to look at the raw account attributes in the Account Restore workflow to differentiate betwen whether it is inactive through max-password attempts or because it has been suspended. For instance doesn't the revoke data get set when a RACF account has been suspended by an administrator but doesn't get set when the max password count has been exceeded??
So you could allow user to Restore their own account and then make a decision in the workflow and email the user if the Account has been suspended by the user.