Portal entries disappear when restricted to groups

We installed UCS 4.3-3 and configured groups on portal entries.
My user account is a member of group “Domain Users” as a univention-ldapsearch uid=XXX memberof shows.
memberof is also active:

root@ucs:~# ucr get ldap/overlay/memberof

I did check all the steps in Problem: Restricting Portal Entries to Groups will Make them Disappear, even though it should not be necessary on 4.3 anymore.

In the logfile /var/log/univention/management-console-web-server.log I found the following error message:

13.03.19 12:41:23.805  MAIN        ( ERROR   ) : Could not get groups for u'Administrator': Traceback (most recent call last):
  File "/usr/sbin/univention-management-console-web-server", line 380, in get_user_groups
    user_dn = lo.searchDn(ldap.filter.filter_format('(&(uid=%s)(objectClass=person))', (self.username,)))[0]
  File "/usr/lib/pymodules/python2.7/univention/admin/uldap.py", line 750, in searchDn
    raise univention.admin.uexceptions.ldapError(_err2str(msg), original_exception=msg)
ldapError: Insufficient access

What else can I check?


this is a known bug. If it is urgent I would recommend to update to UCS 4.4 as (according to comments in the bug) the code has been redesigned there.


have you tried to restart the webserver?

systemctl restart univention-management-console-server.service
systemctl restart univention-management-console-web-server.service
1 Like

This is a productive system and I don’t want to run a release upgrade there right now. As far as I know privacyIDEA has a major version change in UCS 4.4.
The customer I am working for on this project has a subscription. So we will contact via support.
We would prefer a backport of the bugfix to UCS 4.3

@scheinig, yes I also did a service restart.

I restarted the services again and know it is working.
Question to me is if this solves it permanently or if this will happen again?

This will happen again if I’ve understood the bug report correctly.

had the same problem on 4.3-3 err456… and following your commands solved the issue. for the moment.

From @scheinig via support ticket I got the information that this might be caused by the regular server password change. The interval can be checked via ucr get server/password/interval which is 21 days by default.

Until Univention releases a fix, you can simply drop in your own hook script for server password changes in /usr/lib/univention-server/server_password_change.d. Create a file, e.g. zz-fix-web-console-server, make it executable and use the following content (untested):


if [ "$1" = "postchange" ] ; then
  systemctl restart univention-management-console-server.service
  systemctl restart univention-management-console-web-server.service

Univention’s fix will most likely be nothing more than such a hook script. It’s safe to have your own script in there even if the official fix has been applied.