There are Security Privileges in the IDMS security catalog held by USERs that no longer exist.

Products

• IDMS
• IDMS - Database
• IDMS - ADS

Issue/Introduction

Question: 

There are Security Privileges in the IDMS security catalog held by USERs that no longer exist. How does this happen and how can we get rid of these "orphaned" privileges?

 

 

Environment

Release: 19.0
Component:

Resolution

As documented in Security Administration manual under the Usage section of the DROP USER chapter, dropping a USER is a three step process. The same process is described for DROP GROUP.

Answer: 

As documented in Security Administration manual under the Usage section of the DROP USER chapter, dropping a USER is a three step process. The same process is described for DROP GROUP.

1. In OCF or IDMSBCF, issue the 'DROP USER userid' or 'DROP GROUP grpname' statement.
2. Execute the task code SDEL from ENTER NEXT TASK CODE:
3. In OCF or IDMSBCF, reissue the 'DROP USER' or 'DROP GROUP' statement

The first time you issue a DROP USER/GROUP statement for a user or group identifier, the identifier is flagged for logical deletion. Executing the SDEL task, in each system of the domain and against each dictionary in the system that contains security definitions, deletes all privileges associated with each logically deleted user or group. Then you reissue the DROP USER/GROUP statement to physically delete the user or group from the user catalog.

If you issue the second 'DROP USER/GROUP' command before before running SDEL on all systems, all privileges associated with the user or group will remain, even though the user or group definition has been deleted.
If you subsequently re-add the same USER or GROUP for a new user or group, it will have all the privileges that were granted to the original user or group. This will most likely not be desired.

For example:

A drop user statement was issued twice on USERA, but the SDEL task was not executed in between those two drop user statements. Hence the user identification for USERA was deleted from the user catalog, but the privileges granted to USERA remain.

For example: DISPLAY USER USERA; shows the user is not defined, but holds EXECUTE privilege on a Resource Category.

If you physically delete a user before running SDEL on all systems, follow these steps to correct the situation:

1. Create the user again. E.G. 'CREATE USER USERA;'
2. Drop the user once
3. Run SDEL on all systems and dictionaries
4. Drop the user a second time

 

Additional Information: 

Additional Information

DROP USER Usage

DROP GROUP Usage