What is a one sentence summary of your feature request?
The Idea request is to enable the display of the DN (Distinguished Name) for DeleteRequests in the logs, similar to how it is shown for create and modify actions.
Please describe your idea in detail. What is your problem, why do you feel this idea is the best solution, etc.
The issue we’re encountering is that when reviewing the logs for delete actions, the DN (Distinguished Name) of the deleted user is not displayed, making it difficult to determine which specific user was deleted. This lack of clarity can hinder troubleshooting and accountability, especially when investigating incidents related to user deletions. Currently, the DN is shown for create and modify actions, so it would be logical and beneficial to have consistent logging for delete actions as well. This would provide better visibility, improve the auditing process, and help identify potential issues or confirm if the deletion was triggered by Usercube. I believe this would improve the overall logging capabilities and transparency in the system. The logs are generated after the deletion process, so once the user is deleted, the system no longer has access to the user object and cannot log the specific user that was deleted.
How do you currently solve the challenges you have by not having this feature?
Currently, we attempt to cross-reference other available logs and perform manual checks to identify which user might have been deleted, but this process is time-consuming and often inconclusive. Without the DN for delete actions, we rely on circumstantial evidence and indirect methods, which can lead to inefficiencies and potential errors in tracking and resolving incidents related to user deletions.
Upload any supporting images that you think should be considered in this idea.
Sorry if I wasn’t too clear — the idea is not about when an identity is deleted, but rather when the resource type of an identity is deleted.
Unfortunately, we have a customer with multiple applications performing overlapping tasks, which sometimes causes incidents (INCs).
In such cases, we need to investigate which system, script, or person deleted the account (resource type).
If we can see which delete requests were performed on who by Usercube, we can identify whether the action was triggered by Usercube or by another application.
Hi,
So just to make sure we’re all on the same page, you are talking about deleting a resource type (in this example it would be an account) and seeing in the logs the identifier of the resource type (so the DN of the account) as well as the person (or job) responsible for the deletion. Yes?
Yes, only adding the DN of the account in the JobLogs before it gets deleted instead of just seeing a line with “DeleteRequest”.
Currently, I decrypt all the JobLogs from a specific range of dates and then search for any DeleteRequests. If there are none, we can be sure that Usercube didn’t delete anything and that it was another system. When there is a DeleteRequest, it’s hard to identify what was deleted.
When I see the delete request, I can work backward to determine which job it was and for which system, but I still need to decrypt them all in bulk from the agent to search through them. Atleast seeing what was removed would be good.
