Univention portal says "Unauthorized" for Administrator

#1

Hi,

I wanted to log in as Administrator today, as I did plenty of times before. While clicking on the Users menu item, I received a “Your session has expired, please login again”. First I suspected a browser problem. I tried the private modes of 2 different browsers (Chromium / Firefox) to no avail.

I then logged in via SSH, installed an update (just in case) and did a reboot. This also did not help. Then I looked into the syslog and found the following message (verbose slapd logging enabled):

Mar  3 10:14:23 ucs slapd[1909]: conn=1181 fd=29 ACCEPT from IP=[XXXX::5]:60678 (IP=[::]:7389)
Mar  3 10:14:23 ucs slapd[1909]: conn=1181 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Mar  3 10:14:23 ucs slapd[1909]: conn=1181 op=0 STARTTLS
Mar  3 10:14:23 ucs slapd[1909]: conn=1181 op=0 RESULT oid= err=0 text=
Mar  3 10:14:23 ucs slapd[1909]: conn=1181 fd=29 TLS established tls_ssf=256 ssf=256
Mar  3 10:14:23 ucs slapd[1909]: conn=1181 op=1 BIND dn="uid=Administrator,cn=users,dc=mydomain,dc=com" method=128
Mar  3 10:14:23 ucs slapd[1909]: conn=1181 op=1 RESULT tag=97 err=49 text=
Mar  3 10:14:23 ucs slapd[1909]: conn=1181 op=2 BIND dn="" method=163
Mar  3 10:14:23 ucs slapd[1909]: conn=1181 op=2 RESULT tag=97 err=80 text=SASL(-7): invalid parameter supplied:

The last line looks pretty suspicious. I’m not exactly sure, but it could be that I installed UCS exactly one year ago.

Also, I have plenty of services attached via LDAP, which still work fine. Also udm still works, therefore I can still work with the system.

Can anyone hint me towards a solution?

*edit: I looked into the network communication of the browser. The endpoint that produces a 401 Unauthorized is https://DOMAIN/univention/command/udm/license . So it may actually be related to the license. I also looked up the timestamp attribute for the license: createTimestamp: 20200416101226Z.

Looking into the Apache2 logs, I can see that other endpoints also produce a 401, but /univention/get/session-info produces a 200 OK

[03/Mar/2021:11:23:21 +0100] "POST /univention/get/session-info HTTP/1.1" 200 673 "https://DOMAIN/univention/management/"
[03/Mar/2021:11:23:21 +0100] "POST /univention/command/udm/containers HTTP/1.1" 401 567 "https://DOMAIN/univention/management/"
[03/Mar/2021:11:23:21 +0100] "POST /univention/command/udm/meta_info HTTP/1.1" 401 720 "https://DOMAIN/univention/management/"
[03/Mar/2021:11:23:21 +0100] "POST /univention/command/udm/license HTTP/1.1" 401 720 "https://DOMAIN/univention/management/"
[03/Mar/2021:11:23:21 +0100] "POST /univention/command/udm/types HTTP/1.1" 401 720 "https://DOMAIN/univention/management/"

The returned content of session-info is {"status": 200, "message": "", "result": {"username": "Administrator", "auth_type": null, "remaining": 28797}}.

Thanks

#2

Where would it make sense to increase log verbosity? Is it possible to do that for the portal.log?

#3

I stopped the univention-management-console-web-server and started it in the foreground with /usr/sbin/univention-management-console-web-server start -d 5 -n

The debug information on first sight is not telling me much:

127.0.0.1 - - [10/Mar/2021:15:19:45] "POST /get/session-info HTTP/1.1" 200 110 "https://DOMAIN/univention/management/" "Mozilla/5.0 (X11; Linux x86_64; rv:86.0) Gecko/20100101 Firefox/86.0"
10.03.21 15:19:46.295  MAIN        ( INFO    ) : CPCommand (::4c82:59514) got new request
10.03.21 15:19:46.296  MAIN        ( INFO    ) : CPCommand (::4c82:59514) pushed request(0x7f1068631230) to queue(0x7f106869c638) - waiting for response
10.03.21 15:19:46.327  MAIN        ( INFO    ) : UMCP_Dispatcher: check_queue: new request: 0x7f1068631230
10.03.21 15:19:46.327  MAIN        ( INFO    ) : SessionClient(0x7f10686dbba8): sending request(161538598629602-22)
10.03.21 15:19:46.327  PROTOCOL    ( INFO    ) : Sending UMCP COMMAND REQUEST 161538598629602-22
10.03.21 15:19:46.342  MAIN        ( INFO    ) : CPCommand (::4c82:59518) got new request
10.03.21 15:19:46.342  MAIN        ( INFO    ) : CPCommand (::4c82:59518) pushed request(0x7f1068631140) to queue(0x7f10686813f8) - waiting for response
10.03.21 15:19:46.346  PARSER      ( INFO    ) : UMCP RESPONSE 161538598629602-22 parsed successfully
10.03.21 15:19:46.346  PROTOCOL    ( INFO    ) : Received UMCP RESPONSE 161538598629602-22
10.03.21 15:19:46.346  MAIN        ( INFO    ) : SessionClient(0x7f10686dbba8): got response(161538598629602-22): status=401 queue=0x7f106869c638
10.03.21 15:19:46.346  MAIN        ( INFO    ) : UMCP_Dispatcher: check_queue: new request: 0x7f1068631140
10.03.21 15:19:46.346  MAIN        ( INFO    ) : SessionClient(0x7f10686dbba8): sending request(161538598634225-23)
10.03.21 15:19:46.346  PROTOCOL    ( INFO    ) : Sending UMCP COMMAND REQUEST 161538598634225-23
10.03.21 15:19:46.346  MAIN        ( INFO    ) : CPCommand (::4c82:59514) got response(0x7f106866c750) from queue(0x7f106869c638): status=401
10.03.21 15:19:46.346  MAIN        ( PROCESS ) : CPCommand (::4c82:59514) response status code: 401
10.03.21 15:19:46.346  MAIN        ( PROCESS ) : CPCommand (::4c82:59514) response reason : None
10.03.21 15:19:46.346  MAIN        ( PROCESS ) : CPCommand (::4c82:59514) response message: Unauthorized
10.03.21 15:19:46.346  MAIN        ( PROCESS ) : CPCommand (:.4c82:59514) response result: None
10.03.21 15:19:46.346  MAIN        ( PROCESS ) : CPCommand (::4c82:59514) response error: {u'traceback': None, u'command': u'containers'}

I’ll continue to follow the requests through all daemons. If someone knows shortcuts, it would be very welcome.

#4

I found a fix: change the Administrator password via udm. I’m wondering why I did not try this earlier. However I’m still wondering why this happened. Maybe due to some special characters in the password?

1 Like
Mastodon