Afternoon,
Does anyone have any experience with Open LDAP & posix groups?
The connector has been built, users & entitlements have been aggregated. But when I try to revoke an entitlement, it gets removed from the cube, but not on the source, so on the next entitlement aggregation, it comes straight back. This is not a permission issue, as I can remove the user from the entitlement directly on the VA
Removed from cube:
Not getting removed on the source:
Hi @PhilRawlings1 Have you added uid as the membership attribute in the POSIX Groups setting?
Agreed that’s the membership attribute for the group; but ISC needs to know which Account attribute is stored in there, so on the connector settings (POSIX Groups) there’s the membership attribute parameter to indicate which account attribute to use; uid in this case.
This is a typical user showing the uid and posixgroups:
And membership attribute has been set to UID.
(doesn’t help that’s a dead link)
Observationally, it feels like ISC is trying to remove the entitlement from the user (standard process) rather than the user from the group (posixgroup process). But that might just be the front end display
Hi Phil. I’m not sure I agree. The ldap error message is saying it can’t find the value passed within the groups memberUid values to remove.
Can you confirm the memberUid attribute contains uids?
Warning: pedant alert:
It’s actually standard to remove the user from the group, it’s just some implementations (eg Microsoft) include extensions which allow you to remove the group from the user.
Again, apols 
Hi Phil. And you confirm that the uid of the user is in the memberUid of the group from which you are trying to remove it?
Hi Phil. So you confirm that tapank value is held within the memberUid attribute of cn=gtpdq group?
Hi Phil,
@j_place is reading the error correctly. LDAP result code 16 is noSuchAttribute (RFC 4511): OpenLDAP received a delete on memberUid of cn=gtpdq for a value that attribute does not hold. The connector logs that as a warning (“Cannot remove non-existing entitlement”) and marks the request complete. That is why the entitlement drops off the account in ISC and returns on the next aggregation.
Jeremy’s last question is the first thing to settle. The group you posted is gtpadmin, and the account screenshots may have been taken before or after the revoke, so the thread does not yet show tapank in memberUid of cn=gtpdq. A base search on cn=gtpdq,ou=group,... returning memberUid answers it directly.
If tapank is there, the value the connector sends is the likely problem. The POSIX Groups Settings Membership Attribute is documented for retrieving memberships, which explains why aggregation matches tapank correctly. For provisioning, the connector follows the group schema. Your gtpadmin screenshot shows the entitlement type as group. The connector docs describe a separate posixgroup schema whose configuration tells the connector which account attribute goes into memberUid:
"configuration": {
"memberAttribute": ["cn", "uid"],
"groupMemberAttribute": "memberUid"
}
A standard LDAP group schema uses the account DN as the member value. If your posixgroups entitlements sit under a group schema without memberAttribute set to uid, the connector sends uid=tapank,ou=people,... as the value to remove, and OpenLDAP returns this exact error.
To check, please post the schema that the posixgroups account attribute points to, including its configuration block. GET /v3/sources/{sourceId}/schemas returns all schemas on the source with that block. You can also grant one of these groups to a test account through ISC: if a DN lands in memberUid, that settles it.
If the schema is the cause, add a posixgroup schema like the one in the docs, point posixgroups at it, and run an entitlement aggregation. A user hit the same DN-instead-of-uid behavior in this thread and fixed it with a separate posixgroup schema.
Yes, its there:
However, something odd is now happening within the connector. The same entitlement is appearing as both a group and an entitlement: I am wondering if this causing the issue
@Pratyush27 The thread you mentioned details using an LDAP connector rather than an OpenLDAP connector. The latter handles posixGroups natively.
But otherwise
tapank in the memeberUid on the group
Further to this, when the ‘gtpadmin’ appears as a ‘group’ it does not show on the users entitlements page. Which means it can’t be revoked. Only an ‘entitlement’ can be revoked.
If I reset the entitlements and then aggregate, I only get back the ‘groups’ (eg: gtpadmin) but if I then aggregate the source I also get the ‘entitlements’ (eg. cn=gtpadmin).
Its a pity that this is a dead link:
All of this points, observational, towards ISC not being able to revoke membership of a posixgroup. Either that, or there is something very wrong with how I’ve built the connector
Hi Phil,
OK, so the data is right and this looks like config. I haven’t tested this on OpenLDAP myself, so it’s a suggestion to try.
Can you check which source each copy of gtpadmin belongs to? Your identity’s Access tab shows entitlements from both TDN_DEV_HZL and TDN_DEV_HZL_NEW, and most of the DN-named ones there come from TDN_DEV_HZL. The entitlement search doesn’t show a source column, so the group copy and the DN-named copy could be one per source. Filtering the entitlement list by source will show it.
If both copies are on TDN_DEV_HZL_NEW, my guess is that posixgroups isn’t linked to a group schema, so ISC treats each value as a plain entitlement. Your account’s posixgroups values are DNs (cn=gtpadmin,ou=group,...), and the group entries have that same DN as their value, yet the one TDN_DEV_HZL_NEW entitlement visible on the identity, tdnopsl2, is listed by its full DN. That would explain the duplicates. It might also explain the failed removal, if the connector skips the posixgroup schema’s memberAttribute: ["uid"] when nothing points to it.
To check, can you post the posixgroups attribute from the account schema, plus the name of the posixgroup schema you shared? GET /v3/sources/{sourceId}/schemas returns both. I’m asking for the name because the entries show type group. If your schema is called posixgroup, those entries are coming from somewhere else, maybe a default group schema matching groupOfNames.
If posixgroups has no schema reference, try linking it. The schema PATCH docs cover this exact case. Use PATCH, since PUT replaces the whole account schema:
[
{
"op": "replace",
"path": "/attributes/<index of posixgroups>",
"value": {
"name": "posixgroups",
"type": "STRING",
"schema": {
"type": "CONNECTOR_SCHEMA",
"id": "<posixgroup schema id>",
"name": "<posixgroup schema name>"
},
"isMulti": true,
"isEntitlement": true,
"isGroup": true
}
}
]
Export the source config first, then run an entitlement aggregation and an account aggregation. If gtpadmin shows up once on the identity, retry the revoke. I’d also set features to ["PROVISIONING"] on the posixgroup schema to match the docs example, though I don’t know if it matters for membership.
Also, if both sources read the same directory, TDN_DEV_HZL will keep showing the membership, and if the identity’s role includes any of these groups, ISC will provision them again.
Fair point on the other thread, it started on the LDAP connector. The OpenLDAP docs don’t say whether posixgroups needs a schema link, so testing here is the only way to know.
Hi Phil. It looks like group objects are getting aggregated and posixgroups are getting detected. I don’t think it’s related to your issue, but you could check:
Your posixGroup schema - is the nativeObjectType “posixGroup” (check case)
The group schema - what is the nativeObjectType
What is your filter(s) on group aggregation
As to your initial error message - you still haven’t confirmed that tapank is in gtpdq memberUid
Hi Phil, This could be due to the difference in the groups architecture and design between the posixGroup and the standard open LDAP directory. Although I haven’t work much on that but as per the all conversation I can say that you can try to use usedirectMapping flag and use the short UID string during provisioning/deprovisioning. chek if this helps in your error or issue.
Thanks
Deepak
@Pratyush27
This is from the account schema:
Though I am concerned as to why they are not appearing as entitlements on either the source, or the identity cube:
There are two identical sources, the _NEW one is for me to play around with and try and fix the issue. It will get deleted once resolved
________________
@j_place
The nativeObjectType is “posixgroup” for the account schema, as per Posix Group Attributes (I know that’s for an LDAP connector though): I’m going to try camelCase next
Here is ‘tapank’ in the memberUid of the entitlement ‘gtpdq’:
Hi Phil
You mean for the posixGroup schema?
are you saying you updated the existing group schema to map posixGroups, or created a new schema for posixGroup and removed the Group schema?
There is only this entitlement schema:
It was a group schema that got amended top map posixGroups:
{
"nativeObjectType": "posixgroup",
"identityAttribute": "dn",
"displayAttribute": "cn",
"hierarchyAttribute": null,
"includePermissions": false,
"features": [],
"configuration": {
"memberAttribute": [
"uid"
],
"cloudGoverned": false,
"groupMemberAttribute": "memberUid"
},
"attributes": [
{
"name": "dn",
"nativeName": null,
"type": "STRING",
"schema": null,
"description": "Distinguished name of the POSIX group",
"isMulti": false,
"isEntitlement": false,
"isGroup": false,
"isManaged": false
},
{
"name": "cn",
"nativeName": null,
"type": "STRING",
"schema": null,
"description": "POSIX group name",
"isMulti": false,
"isEntitlement": false,
"isGroup": false,
"isManaged": false
},
{
"name": "gidNumber",
"nativeName": null,
"type": "STRING",
"schema": null,
"description": "Numeric identifier of the POSIX group",
"isMulti": false,
"isEntitlement": false,
"isGroup": false,
"isManaged": false
},
{
"name": "memberUid",
"nativeName": null,
"type": "STRING",
"schema": null,
"description": "UID values of the secondary group members",
"isMulti": true,
"isEntitlement": false,
"isGroup": false,
"isManaged": false
},
{
"name": "description",
"nativeName": null,
"type": "STRING",
"schema": null,
"description": "Description of the POSIX group",
"isMulti": false,
"isEntitlement": false,
"isGroup": false,
"isManaged": false
},
{
"name": "objectClass",
"nativeName": null,
"type": "STRING",
"schema": null,
"description": "LDAP object classes assigned to the group",
"isMulti": true,
"isEntitlement": false,
"isGroup": false,
"isManaged": false
}
],
"id": "e7e25abe37644a0981aa4a37083a385e",
"name": "group",
"created": "2026-10-05T13:05:30.818Z",
"modified": "2026-10-05T13:17:51.715Z"
}
I have tried creating a entitlement type ‘posixgroups’ and that brought back all the users rather than the posixgroups