OpenLDAP & POSIX groups

SailPoint Human Fabric (SHF) SHF Discussion and Questions
, ,
21

Ah, now we’re getting there :wink:

That is still a “group” schema (see name), so when groups are aggregating it is aggregating posixGroups as groups.

The “detected” posixGroups are getting aggregated as Entitlements during Account aggregation, but not matching with the aggregated groups.

The definition of which attribute to use for memberUid values is on the schema, so ISC is attempting to use DN (which will fail) as it doesn’t know to use UID.

Make sure that the name of the Entitlement Type definition is posixgroup (create a new one if necessary) and it matches the name of the schema in the source definition (if it’s a new one, you should be safe). Could be posixGroup, doesn’t really matter just so long as it matches.

22

you need to inject with the given code … You can update source using API REST in the following way:

PATCH  https://sailpoint.api.identitynow.com/v3/sources/:id


[
  {
    "op": "replace",
    "path": "/connectorAttributes/memberAttribute",
    "value": "uid"
  }
]
23

That’s already present on the source:

image

We’ve got a ticket open with expert services. I think that its best to wait to see what they come back with.
Thanks for the advice

24

Hey @PhilRawlings1

Good Luck!
Do share when they come back back with a solution as it may help others facing the same question in the future!

25

We have successfully resolved the issue and confirmed that the revocation is now working.

For you future reference, a posixGroup contains two separate membership attributes:

  • mbr, which stores the user’s full distinguished name
  • mbrUid, which stores the user’s short UID

SailPoint was attempting to update memberUid using the user’s full DN instead of the short UID. We resolved the issue by configuring SailPoint to use the member attribute with the account DN and granting the service account the required write permissions on member.

26

Hi Phil - !!Pedant alert number 2!!

member is an attribute on the groupOfNames class
memberUid is an attribute on the posixGroup class

Your openLDAP implementation has managed to combine the two classes onto a single object class and (I assume) synchronise member values to memberUid values.

As I said above, you’re detecting posixGroups and aggregating groups (groupOfNames). The fix you’ve gone with is actually a workaround for revocation which is relying on your specific LDAP implementation config rather than using a standard config, so, as such, I’m not sure it will cover all scenarios.