Problem: OpenDesk User portal tiles are not shown on the dashboard

[fschneider]

Problem

OpenDesk User portal tiles are not shown on the dashboard.

Environment

OpenDesk / Nubus

References

ldapsearch on Opendesk
UDM commands on OpenDesk
ldapvi on OpenDesk
receive group-cache from S3

Investigation

To understand where the issue may be sourced from, it’s important to first of all understand how the flow works in general:

OpenDesk determines which tiles are shown to a user based on group membership. The ums-portal-consumer generates a cache containing the resolved group assignments, which is then stored in the object storage and consumed by the frontend.

1. The user needs to have the proper objectClass.

If classes like “organizationalPerson” are missing, this will cause issues. It is usually easiest to compare the objectClasses in the LDIF of the affected user with a working one.

2. The user needs to be in the correct group for the tiles and the tiles need to be enabled / available.

The required group for the tile can for instance be checked via:

$ udm portals/entry list --filter cn=swp.fileshare_files  | awk '/allowedGroups/'
  allowedGroups: cn=managed-by-attribute-Fileshare,cn=groups,dc=swp-ldap,dc=internal

=> the user in question needs to be in this group. To double verify if there are any issues, it’s best to use another user in this group and check if he sees the tiles or just individual users are affected.

3. The ums-portal-consumer cache needs to be correct. To rebuild it, you can simply kill the corresponding pods.

The content of the cache can be checked within the ums-portal-consumer-* pod as follows after opening a python shell (adjust the group accordingly):

from univention.ldap_cache.cache import get_cache
 
shards = get_cache().get_shards_for_query("(univentionObjectType=groups/group)")

for shard in shards:
    cache = shard._cache
    value = cache.get("cn=managed-by-attribute-Fileshare,cn=groups,dc=swp-ldap,dc=internal".lower())
    print(shard._cache.name, value)

This should return the correct DN and UID of the user in question:

memberUids ['test.mail1', 'fabian.schneider']
uniqueMembers ['uid=test.mail1,cn=users,dc=swp-ldap,dc=internal', 'uid=fabian.schneider,cn=users,dc=swp-ldap,dc=internal']

Also double check the full DN, not that is contains deprecated information.

4. The portal-data group cache needs to contain the correct information.

The final generated portal-data cache which is used by the frontend is located in the S3 storage.

To verify it’s content, you first of all need to receive the current content from <endpoint>/<bucket>/portal-data/groups.

This file should contain the correctly assigned groups of the user, in particular the one in question (cn=managed-by-attribute-Fileshare,cn=groups,dc=swp-ldap,dc=internal)

$ cat groups | jq '."fabian.schneider"'
[
  "cn=domain users,cn=groups,dc=swp-ldap,dc=internal",
  "cn=managed-by-attribute-fileshare,cn=groups,dc=swp-ldap,dc=internal",
  "cn=managed-by-attribute-groupware,cn=groups,dc=swp-ldap,dc=internal",
  "cn=managed-by-attribute-knowledgemanagement,cn=groups,dc=swp-ldap,dc=internal",
  "cn=managed-by-attribute-livecollaboration,cn=groups,dc=swp-ldap,dc=internal",
  "cn=managed-by-attribute-projectmanagement,cn=groups,dc=swp-ldap,dc=internal",
  "cn=managed-by-attribute-videoconference,cn=groups,dc=swp-ldap,dc=internal"
]

Solution

• Verify that the correct group is assigned
• Verify that the correct objectClasses are assigned
• Check the groups for consistency

In the particular case, the issue was caused as the user was moved, but the uniqueMember within one of the groups not updated.

This became obvious by using the following command:

[…] ldapsearch […] | grep santa.claus
univentionPasswordSelfServiceEmail: santa.claus@univention.de
# santa.claus, users, swp-ldap.internl
[…]
memberUid: santa.claus
uniqueMember: uid=santa.claus,cn=users,dc=swp-ldap,dc=internal
memberUid: santa.claus
uniqueMember: uid=santa.claus,cn=administration,dc=swp-ldap,dc=internal
memberUid: santa.claus
uniqueMember: uid=santa.claus,cn=users,dc=swp-ldap,dc=internal
memberUid: santa.claus
uniqueMember: uid=santa.claus,cn=users,dc=swp-ldap,dc=internal
memberUid: santa.claus
uniqueMember: uid=santa.claus,cn=users,dc=swp-ldap,dc=internal

uid=santa.claus,cn=administration,dc=swp-ldap,dc=internal !== uid=santa.claus,cn=users,dc=swp-ldap,dc=internal. This had to be fixed using ldapvi.