VPP and LDAP - Can't remove Limitation - bug?

[dmillertds]

We are deploying VPP to LDAP OUs by targeting "All Users" and using the Limitations to restrict to particular Active Directory OUs (as described in multiple threads). I am trying to update the limitations. I am able to add additional OUs, but unable to remove existing ones. I can click the "Remove" button and the OU goes away, but after clicking Save, exiting the setup, and coming back in, the original OU is back in the list. Anyone else seeing this behavior? We are on 9.6.1, FWIW.

UPDATE: I talked to our Acct Mgr, and this is a known defect in our version. Upgrading to 9.6.2 as well as 9.7.2 resolved the issue.

[Deoly]

I am also experiencing this behaviour on JSS 9.99.0-t1494340586. My work around is to clone and remove the ldap group from the limitation.

Done some test and found that this affected old policies only (policies created in previous version). In effect, my work around is the same as creating a new policy on the current version.

[dgreening]

I can confirm that I have seen this in Mac policies on 9.99.0. I too clone/replace the offending policy.

[MacMaul]

This is still happening with 9.101.0-t1504998263. You don't need to be in the VPP side at all. This just happens with LDAP groups in the Limitations section on any Policy.

[Kotovsky]

We are experiencing exactly the same issue with 9.100.0-t1499435238. Are there any solutions for that problem

[JayDuff]

This bug appears to have resurfaced. We are running 10.10.1-t1551187745 and seeing the exact same issue. We can add OUs to limitations and exceptions, but when we try to remove them, they go away until we click Save, then they come back.

[cbrewer]

This issue (for us) was caused by Jamf's default behavior of mapping "Group ID" to "uSNCreated" in your Jamf LDAP binding. The uSNCreated value is unique to each domain controller so if you have multiple domain controllers (or retire an old domain controller), you'll likely run into this.

The work-around is to map "Group ID" to "cn". If you do this, you'll want to work with Jamf support as you'll likely need to make some database edits to get the existing groups that you can't remove back in sync.

objectSid would be a better value to map to but there is bug related to that (pi-006706). Please push on Jamf to change their default behavior. Using uSNCreated is setting customers up for problems down the road.

[JayDuff]

@cbrewer Genius.

We had that mapping alright. I've a case open with Jamf Support.