none
Possible bug: MIM 2016 PAM and removal of Shadow Principal membership RRS feed

  • Question

  • TL;DR: 
    Users do not get removed from shadow principals by PAM Component Service upon manual deactivation of PAM role membership. Removal from regular security groups works as intended. TTL based group membership also works. Correct access has been granted to the service account. 


    So I have a 2016 AD domain/forest (PRIV) with MIM 2016 SP1 and PAM configured (4.4.1302.0). I also have a 2012 domain (CORP - One-way trust). 

    I have configured PAM groups and roles using the cmdlets, which creates a shadow principal object as expected. Any access requests through the API results in the user being added to the shadow principal (with a TTL as expected). So far so good.

    But if the role is manually deactivated before the TTL has expired, I can see all the request go through successfully (the TTL of the PAM request is set to 0 and it is expired). However the user is never removed from the shadow principal by the PAM Component service. Yes, the service account has been granted the proper permissions to do so, and no failure audit is logged. It simply seems as it never even tries to remove it from the shadow principal at all. The ETW trace shows a few log messages saying that it found an expired/closed membership and that the user was removed from the shadow principal, so it knows that it's dealing with a shadow principal and not a security group at this stage. 

    "User 'sAMAccountName', (Priv SID 'S-1-5-21-PRIV-SID-1688') was removed from shadow principal CORP.GroupName (SID 'S-1-5-21-CORP-SID-131870')"

    However no removal (or failure events in MIM/Event logs) actually occur. 

    If I on the other hand create a regular security group and assign a role to it, the above procedure works. The user is added to the group when requested, and if the request is manually closed, the user is removed from the security group by the PAM Component service. 

    User 'sAMAccountName', (Priv SID 'S-1-5-21-PRIV-SID-1688') was removed from group GroupName (SID 'S-1-5-21-PRIV-SID-3106')

    So in other words, log wise everything looks OK, but when it's dealing with a shadow principal nothing actually happens even though the logs state that 'the user was removed'. 

    Has anyone else run into this and perhaps can shed some light on this behavior? 


    Andreas


    • Edited by ANHU Wednesday, December 14, 2016 9:04 AM Typo
    Tuesday, December 13, 2016 9:24 AM

All replies

  • Hi,

    The only cause I know would be AD permissions. If you have verified AD permissions, my suggestion would be to open up a case with support.

    Best,

    Jeff Ingalls

    Thursday, December 15, 2016 4:09 AM
  • Did you manage to solve this?

    Nosh Mernacaj, Identity Management Specialist

    Sunday, May 14, 2017 1:51 AM
  • Unfortuantely I did not. As far as I can tell the function ("remove user from shadow principal") returns a false positive, as in it always returns a success message regardless if the user was actually removed or not. 

    Are you experiencing the same issue? 

    Sunday, May 14, 2017 3:34 PM
  • Yes I am.   I am using Windows 2016 AD.  It works when the request expires, but not when you expire it manually

    Nosh Mernacaj, Identity Management Specialist



    Sunday, May 14, 2017 6:33 PM
  • Have you configured any server hardening? For example Microsoft Security Compliance Manager, or something similar? 

    Tuesday, May 16, 2017 2:18 PM
  • These are pretty clean Vanilla DCs. Nothing of that sort.

    Nosh Mernacaj, Identity Management Specialist

    Wednesday, May 17, 2017 12:35 PM
  • I've been doing a bit of testing, and I'd like to check a few things with you, if you don't mind? 

    1. Do you have any special characters in the user names? For example a - character, or something of that sort?
    2. How many domain components (DC=) do you have in your domain name?


    Andreas Hultgren<br/> MCTS, MCITP<br/> <a href="http://ahultgren.blogspot.com/">http://ahultgren.blogspot.com/</a>

    Wednesday, May 23, 2018 9:32 AM
  • Was there ever a solution found for this issue? We're seeing the same behavior...
    Thursday, February 14, 2019 8:19 PM
  • Yeah, I logged a support case. 

    Try installing this: 
    https://support.microsoft.com/en-us/help/4469694/hotfixrolluppackagebuild452860isavailableformicrosoftidentitymanager20

    I believe this update should contain the fix. 


    Andreas Hultgren<br/> MCTS, MCITP<br/> <a href="http://ahultgren.blogspot.com/">http://ahultgren.blogspot.com/</a>

    • Proposed as answer by A.Hultgren Thursday, September 5, 2019 9:44 AM
    Thursday, February 14, 2019 8:37 PM
  • Aidan,

    What permissions are set on the Shadow Principal Configuration container for the account running the PAM Component service? (referring back to Jeff's comment)

    For example, in my lab, I have Allow "Write Member" on Descendant msDS-ShadowPrincipal objects. 

    Also, are you on the most recent release 4.5.286.0.?

    Thursday, February 14, 2019 8:42 PM
  • Andreas,

    Did you manage to solve this issue? I'm experiencing similar behavior with the latest hotfix 4.5.412.0

    Regards,

    Jaksa

    Wednesday, October 9, 2019 1:50 PM
  • I am not sure which patch is that, but there is a fix for this. It was a bug and a patch was released to fix it.

    Nosh Mernacaj, Identity Management Specialist

    Wednesday, October 9, 2019 5:26 PM
  • Jaksa,

    Did you resolve your issue?  I too am seeing this issue with a new install of 4.5.412.0.  When user closes the request the portal shows request is closed but when the TTL expires or user is removed from the group.  

    Regards,

    Jason

    Tuesday, December 10, 2019 6:03 PM
  • Hi Jason,

    Unfortunately I did not resolve the issue. I can see the same behavior after installing Service Pack 2 for MIM/PAM. I don't have any Windows Server 2012 R2 deployments. Maybe in that case PAM component service removes user from a group when PAM request is deactivated. In Windows Server 2016 that simply doesn't work.

    Regards,

    Jaksa

    Wednesday, December 11, 2019 1:31 PM