Group members are not synced with FreeIPA LDAP (lack of uid and cn member support?)

[BioSehnsucht]

From #103 it appears that this may be due to only supporting dn rather than uid and cn.

We need this to work with member=uid=... and member=cn=... to support groups in FreeIPA. It uses uid for user membership and cn for group membership (nested groups). As it is, we can't even use flat groups, much less nested groups. Since all groups appear in the user's memberof attributes, alternatively, if it was doing group membership simply by looking at the memberof attributes of the users, then there wouldn't need to be any support for nesting, just match the memberof contents to the corresponding groups.

We have users in various role groups, and then create larger groups from those roles in a nested fashion. It's fine for it to be flattened in Bitwarden by the directory connector since we manage all this in FreeIPA. Until this is fixed we'll have to manually add people to groups within Bitwarden, which is a pain.

Example of a flat group (which is also nested into another group) in that ends up having no members in Bitwarden (sanitized and simplified by excluding all the irrelevant information):

dn: cn=system-admin,cn=groups,cn=accounts,dc=example,dc=org
memberOf: cn=access-vpn,cn=groups,cn=accounts,dc=example,dc=org
memberOf: cn=access-bitwarden,cn=groups,cn=accounts,dc=example,dc=org
memberOf: cn=role-bitwarden-clients,cn=groups,cn=accounts,dc=example,dc=org
member: uid=user1,cn=users,cn=accounts,dc=example,dc=org
member: uid=user2,cn=users,cn=accounts,dc=example,dc=org
member: uid=user3,cn=users,cn=accounts,dc=example,dc=org
cn: system-admin
objectClass: top
objectClass: groupofnames
objectClass: nestedgroup

And a group that is only used in a nested fashion (it includes only other groups, i.e. the example above):

dn: cn=role-bitwarden-clients,cn=groups,cn=accounts,dc=example,dc=org
member: cn=role-admin,cn=groups,cn=accounts,dc=example,dc=org
member: cn=role-dev,cn=groups,cn=accounts,dc=example,dc=org
member: cn=system-admin,cn=groups,cn=accounts,dc=example,dc=org
cn: role-bitwarden-clients
objectClass: top
objectClass: groupofnames
objectClass: nestedgroup

And example user (again sanitized and simplified):

dn: uid=user1,cn=users,cn=accounts,dc=example,dc=org
memberOf: cn=system-admin,cn=groups,cn=accounts,dc=example,dc=org
memberOf: cn=access-vpn,cn=groups,cn=accounts,dc=example,dc=org
memberOf: cn=role-dev,cn=groups,cn=accounts,dc=example,dc=org
memberOf: cn=access-bitwarden,cn=groups,cn=accounts,dc=example,dc=org
memberOf: cn=role-bitwarden-clients,cn=groups,cn=accounts,dc=example,dc=org
mail: [email protected]
givenName: User
sn: 1
uid: user1
cn: User 1
displayName: User 1
objectClass: top
objectClass: person
objectClass: organizationalperson
objectClass: inetorgperson
objectClass: inetuser

What happens is that the groups are created in Bitwarden, but no users are members. We have to add them manually. And if we don't then disable syncing groups, the connector will remove all memberships on the next sync. So for now we have to fully manage the groups manually within Bitwarden, and BWDC is only providing creation/removal of users.

What should happen is that the groups are created, and the collection of nested users/groups is flattened and placed into each group.

I.e. the system-admin group should contain user1, user2, user3, while the role-bitwarden-clients group should contain those users (via system-admin being a member) plus whatever users (i.e. user4 and so on) that are in the other groups role-dev and role-admin.

At a minimum, we need uid to work which would at least get flat groups to work (versus no groups working at all), and leave us with having to manually manage flat groups instead of nested groups. Ideally, it should support nested groups using cn in which case nested groups would work with FreeIPA. Since it supposedly already supports nested groups, this should only need expanding the supported entry types.

I would make an attempt at adding this support but I'm not particularly well versed in JS/TS. From browsing the source, I still haven't figured out what is picking only dn, so I'm not even sure what would need to be changed (assuming the issue I referenced at the start is correct).

BWDC config (only relevant portions and sanitized):

{
  "directoryType": 0,
  "directoryConfig_0": {
    "ssl": true,
    "startTls": true,
    "sslAllowUnauthorized": true,
    "port": 389,
    "currentUser": false,
    "ad": false,
    "pagedSearch": false,
    "password": "[redacted]",
    "hostname": "localhost",
    "username": "[redacted]",
    "rootPath": "dc=example,dc=org"
  },
  "syncConfig": {
    "users": true,
    "groups": true,
    "interval": 5,
    "removeDisabled": true,
    "overwriteExisting": true,
    "largeImport": false,
    "useEmailPrefixSuffix": false,
    "creationDateAttribute": "whenCreated",
    "revisionDateAttribute": "whenChanged",
    "emailPrefixAttribute": "sAMAccountName",
    "memberAttribute": "memberof",
    "userObjectClass": "inetorgperson",
    "groupObjectClass": "groupofnames",
    "userEmailAttribute": "mail",
    "groupNameAttribute": "cn",
    "groupPath": "cn=groups,cn=accounts",
    "userPath": "cn=users,cn=accounts",
    "userFilter": "(&(memberof=cn=access-bitwarden,cn=groups,cn=accounts,dc=example,dc=org))",
    "groupFilter": "(|(cn=role-*)(cn=system-admin))"
  }  
}

[bitwarden-bot]

Hi @BioSehnsucht,
We're cleaning up our repositories in preparation for a major reorganization. Issues from last year will be marked as stale and closed after two weeks. If you still need help, simply clear the label and we'll look into it.
Thanks!

[BioSehnsucht]

This is still a problem as far as I know, though I haven't updated the connector software since then, from a glance, none of the commits look to have touched anything relevant.

[BioSehnsucht]

Don't think I have access to remove the stale label?

[florian-bellencontre]

The posixGroup still doesn't seem to be supported, the uid doesn't work, but if I set the full path, it finds my users. Is it possible to fix this problem?