Skip to Content
Author's profile photo Brandon Bollin

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:

 

File Apr 28, 9 16 44 AM.png

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.

Assigned Tags

      8 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Brandon Bollin
      Brandon Bollin
      Blog Post Author

      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!  🙂

      Author's profile photo Matt Pollicove
      Matt Pollicove

      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

      Author's profile photo Brandon Bollin
      Brandon Bollin
      Blog Post Author

      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.

      Author's profile photo Former Member
      Former Member

      Have you had a change to follow up on this? I am also curious about an efficient way to resolve these orphaned privileges.

      Author's profile photo Brandon Bollin
      Brandon Bollin
      Blog Post Author

      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.

      Author's profile photo Brandon Bollin
      Brandon Bollin
      Blog Post Author

      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.

      Author's profile photo Steffi Warnecke
      Steffi Warnecke

      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. 🙂

      Author's profile photo Brandon Bollin
      Brandon Bollin
      Blog Post Author

      I think I can do that.  🙂