Batman PRIVs or Why PRIVs Hide in the Shadows
I recently started a new project and one of the first things I ran into was privilages assigned to a user that weren’t showing up in the UI. When you did a search of their complete record in the Identity Store, their MSKEYs were listed on the user’s record but you couldn’t see them in the UI.
Having never encountered this before, I went into investigative mode. I’m the kind of person where unanswered questions bore holes in my brain so, I had to know what was happening here! In short, as it turns out, these PRIVs were inherited from someplace else and the parent was removed but, for whatever reason, the child remained; they were orphans, like Batman. So now, they hide in the shadows, granting their users the rights they shouldn’t have but still do because of this failed removal process.
Why doesn’t the UI show these PRIVs? The user still has it even though he/she shouldn’t. Shouldn’t it at least still show up if even with some kind of status that shows that it’s an orphan? Apparently the UI, when deciding what PRIVs to show on a user’s record in the UI, looks at two columns on the IDMV_LINK_EXT view, mcAssignedDirect and mcAssignedInheritCount. If those two columns are both less than or equal to 0, the mcOrphan column goes to 1 and the PRIV stops being shown on the UI. Here’s a screenshot to show what I’m talking about:
So if you’re ever in a spot where the UI isn’t showing PRIVs that your user clearly has, this might be why. The clean up? Well, that’s up to you to figure out. 🙂
Update: This solution is in the comments too.
OK so… After talking with another technician at my current job and working with SAP via an OSS ticket for this issue, here is the fix! You can do this on a one-off basis or create a reoccurring job that runs a query like this:
UPDATE mxi_link SET mcAssignedDirect = 1, mcOrphan = 0 WHERE mcThismskey = <usermskey> and mcOthermskey = <privmskey> AND mcOrphan = 1
Essentially… Wherever you have an orphaned PRIV, you need to set the link record so that this PRIV is assigned directly. Then you can have the job record those records that it fixed and in a subsequent pass, remove them.
Hey all, feel free to like, comment, give a rating, etc. My content will improve based on the community's feelings so please, feedback; even if that feedback contains critizism! 🙂
Well done Brandon. Would have been nice to see some ideas on how we fix this if it happens to us. Maybe that's another blog for you 🙂
Matt
I wanted to say you could just use a job targeting the users' records via MSKEY or MSKEYVALUE then remove any privilages where the MSKEY is in the list of MSKEYs you pull from my sample screen shot of orphaned PRIVs but, since I'm not sure how my current shop is handling this problem, I honestly don't know if that would work. Once I find out how they do clean up, I'll update this blog.
Have you had a change to follow up on this? I am also curious about an efficient way to resolve these orphaned privileges.
Sorry this answer has taken so long. It stopped using the SCN for quite awhile as I really don't like all the changes they made last year. Now that I'm working for a new company, I'm going to try to get back into the SCN.
Anyway, what we ended up doing to fix this issue was we simply set the link state, the execState and execState hierarchy to their appropriate settings for a removed link record and then we went into the backend system directly and removed the corresponding roles. I know that's not a really good way to do thing but I remember we did a lot of things to try and solve this and eventually just got tired of trying.
OK so... After talking with another technician at my current job and working with SAP via an OSS ticket for this issue, here is the fix! You can do this on a one-off basis or create a reoccurring job that runs a query like this:
UPDATE mxi_link SET mcAssignedDirect = 1, mcOrphan = 0 WHERE mcThismskey = <usermskey> and mcOthermskey = <privmskey> AND mcOrphan = 1
Essentially... Wherever you have an orphaned PRIV, you need to set the link record so that this PRIV is assigned directly. Then you can have the job record those records that it fixed and in a subsequent pass, remove them.
Thanks for the update, Brandon. Will you update the blog itself, too? Could be great for those who only read the blog and do not expect to find the solution in den comments. 🙂
I think I can do that. 🙂