Identifying the dormant/inactive users is a critical task and possess a risk to an organization or company. A new userid is created in SAP systems, whenever any new employee is on boarded or requests access similar to other employees. However, very few organizations reviews their access and usage. It is a best practice to identify, review and take appropriate action on dormant/inactive users regularly so that there wouldn't be any issues related to license and audit
Many companies have a policy to lock active SAP users who didn’t logon for more than 'N' No.of days. Usually this activity is done manually (executing the report RSUSR_LOCK_USERS) and this can possess a RISK, because this activity can be done irregularly. Sometimes the same activity is automated by executing a custom ABAP program/report or standard SAP report RSUSR_LOCK_USERS via scheduled job.
So, in this blog post I would like to share how the same can be achieved via SAP IDM.
Key Benefits:
Functional Requirement:
Prerequisites: Have SAP IDM in your company landscape and it is your leading Identity management System.
Use Case:
Implementation Steps:
2) Following read passes, retrieves information from Target system into IDM Staging tables.
ReadTable: USR02 - Retrieves user logon information like Logon Name(User ID), UserType, User Group, LastLogonDate, UserLockStatus Flag, Validity End date from table USR02.
Usually the below passes are not required, by can be used in the following scenarios
Either of the below passes can be used to retrieve the user email address. Reading the data from tables is much quicker than using the BAPI call.
ReadTable: USR21 & ADR6 - Retrieves email address of the users maintained in the target system. Usually if SAP IDM is your leading identity management system, the data would be in sync between IDM & target systems, so email address can be retrieved from IDM based on the user logon name.
Read ABAP Users - To retrieve other user details like first name, last name, email address or other fields via standard ABAP BAPI Call.
3) Export List - Calculate Users who Last Logon is between 60 and 90 Days
A csv/html based report is generated based on the following criteria
4) Send Notification - Notify the Individual Users (Remainder Mail)
A mail notification is triggered to each individual user falling under above mentioned criteria, stating that your account would be locked if you doesn't logon or use it by end of this month.
5) Send Notification - Notify the Security Audit/Admin Team (Include attachment - Users Didnt Logon List)
The users list is sent as a mail attachment to the Audit team for reference.
6) Export List - Calculate Users who Last Logon is Greater than 90 Days
A csv/html based report is generated based on the following criteria
7) Lock Users In IDM - Update Repository Specific Lock Attribute (ByPass Modify Trigger Task)
We doesn't update MX_LOCKED attribute, as it would lock the users in all the systems he has access too. There would be case where the user wouldn't be using System A but would be using System B. Hence to handle these cases, a repository specific attribute needs to be created in IDM, so that the user would be locked in that particular system alone.
The reason why we are bypassing modify trigger task is that, if there are bulk users then many event tasks can be triggered and affect system performance, so to avoid it you can by pass the modify trigger task and directly lock the user in target system using below pass.
Note - Use bypass modify trigger only when there are more number of user accounts to be handled.
😎 Target System - Set Validity End Date To Yesterdays Date & Lock User
The users validity end date is expired by setting validity end date to yesterday's date and locking the user using ToCustomPass.
Note - Lock the Users directly in the target system, only when there more no.of accounts else, lock them up by using above pass with out by passing the system privilege
9) Send Notification - Notify the Individual Users (Expired Notification)
The expired users are notified, about their account expiration and next steps they need to follow, if they want to use their account in future.
10) Send Notification - Notify the Security Audit/Admin Team (Include attachment - Locked Users List)
The expired users list is sent as a mail attachment to the Audit team for reference.
The job can be customized depending upon the company policies.
Kindly provide your feedback regarding this blog and let me know in case of any suggestions or improvements further.
Do let us know how you would be handling the active users who haven't logged in for more than 'N' No.of Days
Many companies have a policy to lock active SAP users who didn’t logon for more than 'N' No.of days. Usually this activity is done manually (executing the report RSUSR_LOCK_USERS) and this can possess a RISK, because this activity can be done irregularly. Sometimes the same activity is automated by executing a custom ABAP program/report or standard SAP report RSUSR_LOCK_USERS via scheduled job.
So, in this blog post I would like to share how the same can be achieved via SAP IDM.
Key Benefits:
- Reduce SAP Audit Risk.
- Redundancy in Manual work.
- Save operational and user's License cost.
Functional Requirement:
- Identify the users who didn’t logon for a certain period of time.
- Send remainder mail to the users stating that, their account would be expired, if they haven't logged in next few days.
- The list is sent to the security audit/admin team for reference.
- calculate the users who didn’t logon for more than 'N' no.of days,
- Lock the users in IDM & Target system
- Expire the users, by updating their validity end date to Previous date in target system
- Notify the user about his account expiration in the target system and next steps to be followed, if he would like to access the system in future.
- Notify the security audit/admin team along with consolidated list.
Prerequisites: Have SAP IDM in your company landscape and it is your leading Identity management System.
Use Case:
- A job is scheduled in IDM to run, starting of every month.
- IDM reads the users necessary information from target systems.
- Calculates the users (Only Dialog (A) Users) whose last logon date is between 60 - 90 days and send an email notification stating that, their user account would be locked in the system <SystemName along with client>, if they wouldn't use the system by starting of next month.
- Users list is sent as mail attachment to Relevant Security or Audit team
- For users who didn't logon for more than 90 Days, their account is locked in IDM for that particular repository and also validity is expired in the target system.
- The locked users is sent as a mail attachment to Relevant Security or Audit team.
Implementation Steps:
- Create a new repository based job as below. The same job can be run for multiple repositories.
2) Following read passes, retrieves information from Target system into IDM Staging tables.
ReadTable: USR02 - Retrieves user logon information like Logon Name(User ID), UserType, User Group, LastLogonDate, UserLockStatus Flag, Validity End date from table USR02.
Usually the below passes are not required, by can be used in the following scenarios
- Few systems in your landscape is not connected to IDM
- Inconsistencies between IDM & Target systems in terms of user data
Either of the below passes can be used to retrieve the user email address. Reading the data from tables is much quicker than using the BAPI call.
ReadTable: USR21 & ADR6 - Retrieves email address of the users maintained in the target system. Usually if SAP IDM is your leading identity management system, the data would be in sync between IDM & target systems, so email address can be retrieved from IDM based on the user logon name.
Read ABAP Users - To retrieve other user details like first name, last name, email address or other fields via standard ABAP BAPI Call.
3) Export List - Calculate Users who Last Logon is between 60 and 90 Days
A csv/html based report is generated based on the following criteria
- User Type - A
- Last Logon is between 60 and 90 Days
- User lock status is '0'
4) Send Notification - Notify the Individual Users (Remainder Mail)
A mail notification is triggered to each individual user falling under above mentioned criteria, stating that your account would be locked if you doesn't logon or use it by end of this month.
5) Send Notification - Notify the Security Audit/Admin Team (Include attachment - Users Didnt Logon List)
The users list is sent as a mail attachment to the Audit team for reference.
6) Export List - Calculate Users who Last Logon is Greater than 90 Days
A csv/html based report is generated based on the following criteria
- User Type - A
- Last Logon is greater than 90 Days
- User lock status is '0'
7) Lock Users In IDM - Update Repository Specific Lock Attribute (ByPass Modify Trigger Task)
We doesn't update MX_LOCKED attribute, as it would lock the users in all the systems he has access too. There would be case where the user wouldn't be using System A but would be using System B. Hence to handle these cases, a repository specific attribute needs to be created in IDM, so that the user would be locked in that particular system alone.
| Attribute | Value |
| MSKEYVALUE | %MSKEYVALUE% |
| changetype | modify |
| Z_IDEN_REP_LOCKED_%$rep.$NAME% | 1 |
| MXREF_MX_PRIVILEGE | {BYPASS_MODIFY_TASK=1}<PRIV:SYSTEM:%$rep.$NAME%> |
The reason why we are bypassing modify trigger task is that, if there are bulk users then many event tasks can be triggered and affect system performance, so to avoid it you can by pass the modify trigger task and directly lock the user in target system using below pass.
Note - Use bypass modify trigger only when there are more number of user accounts to be handled.
😎 Target System - Set Validity End Date To Yesterdays Date & Lock User
The users validity end date is expired by setting validity end date to yesterday's date and locking the user using ToCustomPass.
Note - Lock the Users directly in the target system, only when there more no.of accounts else, lock them up by using above pass with out by passing the system privilege
9) Send Notification - Notify the Individual Users (Expired Notification)
The expired users are notified, about their account expiration and next steps they need to follow, if they want to use their account in future.
10) Send Notification - Notify the Security Audit/Admin Team (Include attachment - Locked Users List)
The expired users list is sent as a mail attachment to the Audit team for reference.
The job can be customized depending upon the company policies.
Kindly provide your feedback regarding this blog and let me know in case of any suggestions or improvements further.
Do let us know how you would be handling the active users who haven't logged in for more than 'N' No.of Days
- SAP Managed Tags:
6 Comments
