Univention Bugzilla – Bug 44621
INVALID_CREDENTIALS: SAML: authentication failure: condition NotOnOrAfter doesn't match
Last modified: 2019-03-06 19:30:51 CET
I think this are 2 different issues. Splitting the bug. Die Initialisierung des Moduls ist fehlgeschlagen: Traceback (most recent call last): File "%PY2.7%/univention/management/console/protocol/modserver.py", line 178, in _recv self.handle(msg) File "%PY2.7%/univention/management/console/protocol/modserver.py", line 290, in handle self.__handler.init() File "%PY2.7%/univention/management/console/modules/udm/__init__.py", line 157, in init self.settings = UDM_Settings() File "%PY2.7%/univention/management/console/modules/udm/udm_ldap.py", line 886, in __init__ self.read() File "%PY2.7%/univention/management/console/modules/udm/udm_ldap.py", line 889, in read self._read_directories() File "%PY2.7%/univention/management/console/modules/udm/udm_ldap.py", line 88, in _decorated return method(*args, **kwargs) File "%PY2.7%/univention/management/console/ldap.py", line 140, in _decorated kwargs[loarg], kwargs[poarg] = lo, po = getter() File "%PY2.7%/univention/management/console/ldap.py", line 130, in getter conn = connection() File "%PY2.7%/univention/management/console/ldap.py", line 53, in connection bind(lo) File "%PY2.7%/univention/management/console/modules/udm/__init__.py", line 173, in bind_user_connection super(Instance, self).bind_user_connection(lo) File "%PY2.7%/univention/management/console/base.py", line 348, in bind_user_connection lo.lo.bind_saml(self._password) File "%PY2.7%/univention/uldap.py", line 175, in bind_saml self.lo.sasl_interactive_bind_s('', saml) File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 892, in sasl_interactive_bind_s res = self._apply_method_s(SimpleLDAPObject.sasl_interactive_bind_s,*args,**kwargs) File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 860, in _apply_method_s return func(self,*args,**kwargs) File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 236, in sasl_interactive_bind_s return self._ldap_call(self._l.sasl_interactive_bind_s,who,auth,RequestControlTuples(serverctrls),RequestControlTuples(clientctrls),sasl_flags) File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 106, in _ldap_call result = func(*args,**kwargs) INVALID_CREDENTIALS: {'info': 'SASL(-13): authentication failure: condition NotOnOrAfter 2017-04-08T14:00:40Z, current time is 2017-04-08T14:30:01Z', 'desc': 'Invalid credentials'} +++ This bug was initially created as a clone of Bug #44382 +++
#2017051721000317
(In reply to Florian Best from comment #1) > #2017051721000317 Florian, did it happen in every given ticket? Is the user pain value correctly? I asked because you split the bug report.
(In reply to Stefan Gohmann from comment #2) > (In reply to Florian Best from comment #1) > > #2017051721000317 > > Florian, did it happen in every given ticket? > > Is the user pain value correctly? > > I asked because you split the bug report. I split the bug report because the traceback is very similar but not exact the same. I only assumed the reason is the same but I am not sure, so better treat it as 2 bugs currently. We could later resolve as duplicate if the reason is the same. Yes, it did happen in every given ticket, so we have 15 reports for Bug #44621 and 16 for Bug #44382 since the UCS 4.2 release. Let't think again about the user pain: 5: Major Usability: → because one cannot use any UDM UMC module any more or any UMC module which uses a ldap connection of the user. 2: Will affect a few domains: → 16 reports is very much, much much more than a lot of feedback we get. I would even increase it to 3 but 15 of maybe X*1000 systems might not be 3? 5. Blocking further progress on the daily work: → If you cannot use UMC modules (maybe until you restart slapd) this is a blocking issue.
Reported again, 4.2-0 errata15 (Lesum) #2017052321000412
Reported again, 4.2-0 errata15 (Lesum) #2017052521000374
Reported again, 4.2-0 errata29 (Lesum) 2017060921000027
4.2-0 errata29 (Lesum), #2017061221000833
4.2-0 errata29 (Lesum), #2017061321000573
4.2-0 errata29 (Lesum), #2017061521000891
This happens if univention.uldap is used. Most udm modules use univention.admin.uldap in which case the "INVALID_CREDENTIALS" gets wrapped and ends up as a 401 server code which gets handled correctly by the frontend. Catching "INVALID_CREDENTIALS" in management/console/base.py and throwing a Unauthorized error instead might fix this. How to reproduce: Login using saml Change the clock 10min+ into the future Open the exam module from @school
*** Bug 45720 has been marked as a duplicate of this bug. ***
[4.2-3 bcad7af5d9] Bug #44621: Fix LDAP INVALID_CREDENTIALS with SAML [4.2-3 22b3fab7b1] Bug #44621: Merge branch 'juern/44621_invalid_saml_creds' into 4.2-3 [4.2-3 a3d529a24b] Bug #44621: Changelog [4.2-3 236f57f471] Bug #44621: YAML This also happened after the ldap server closed the connection due to ldap/idletimeout. The saml message used as a password for a reconnect by python ldap was never updated. The connection cache needs to be reseted in that case. [4.3-0 ad6c547c8f] Bug #44621: Fix LDAP INVALID_CREDENTIALS with SAML [4.3-0 c4c8065285] Bug #44621: Changelog
OK: catch ldap.INVALID_CREDENTIALS OK: yaml Verified
I think it might be better to use the following javascript code change: diff --git a/management/univention-management-console/www/login/main.js b/management/univention-management-console/www/login/main.js index d0e2264..daa7062 100644 --- a/management/univention-management-console/www/login/main.js +++ b/management/univention-management-console/www/login/main.js @@ -338,11 +338,7 @@ define([ » » autorelogin: function(args) { » » » if (tools.status('authType') === 'SAML') { -» » » » var passiveLogin = this.passiveSingleSignOn(args); -» » » » passiveLogin.then(lang.hitch(this, function(response) { -» » » » » return this.authenticated(response.result.username); -» » » » })); -» » » » return passiveLogin; +» » » » return this.passiveSingleSignOn(args).then(lang.hitch(this, 'sessioninfo')); » » » } » » » return this.autologin(); » » }, This checks if the login really was successfull and sessioninfo() makes the call to this.authenticated() in that case as well.
(In reply to Florian Best from comment #14) > I think it might be better to use the following javascript code change: > > diff --git a/management/univention-management-console/www/login/main.js > b/management/univention-management-console/www/login/main.js > index d0e2264..daa7062 100644 > --- a/management/univention-management-console/www/login/main.js > +++ b/management/univention-management-console/www/login/main.js > @@ -338,11 +338,7 @@ define([ > > » » autorelogin: function(args) { > » » » if (tools.status('authType') === 'SAML') { > -» » » » var passiveLogin = this.passiveSingleSignOn(args); > -» » » » passiveLogin.then(lang.hitch(this, function(response) { > -» » » » » return this.authenticated(response.result.username); > -» » » » })); > -» » » » return passiveLogin; > +» » » » return this.passiveSingleSignOn(args).then(lang.hitch(this, > 'sessioninfo')); > » » » } > » » » return this.autologin(); > » » }, > > This checks if the login really was successfull and sessioninfo() makes the > call to this.authenticated() in that case as well. Already set to verified. Can we not trust SAML here? Otherwise it just adds another request.
<http://errata.software-univention.de/ucs/4.2/317.html>
Hiding every "ldap.INVALID_CREDENTIALS" behind "Unauthorized" is not the best idea. It took me a while to debug an error in the UMC-Server. Maybe we can revert / improve this somewhen.