Bug 44621 - INVALID_CREDENTIALS: SAML: authentication failure: condition NotOnOrAfter doesn't match
INVALID_CREDENTIALS: SAML: authentication failure: condition NotOnOrAfter doe...
Status: CLOSED FIXED
Product: UCS
Classification: Unclassified
Component: SAML
UCS 4.2
Other Linux
: P5 normal (vote)
: UCS 4.2-3-errata
Assigned To: Jürn Brodersen
Erik Damrose
:
: 45720 (view as bug list)
Depends on: 44382 45438
Blocks:
  Show dependency treegraph
 
Reported: 2017-05-17 15:28 CEST by Florian Best
Modified: 2019-03-06 19:30 CET (History)
7 users (show)

See Also:
What kind of report is it?: Bug Report
What type of bug is this?: 5: Major Usability: Impairs usability in key scenarios
Who will be affected by this bug?: 3: Will affect average number of installed domains
How will those affected feel about the bug?: 5: Blocking further progress on the daily work
User Pain: 0.429
Enterprise Customer affected?:
School Customer affected?: Yes
ISV affected?:
Waiting Support: Yes
Flags outvoted (downgraded) after PO Review:
Ticket number: 2017040821000211, 2017040821000229, 2017041221000515, 2017041221000506, 2017041621000017, 2017040521001573, 2017041621000026, 2017042921000109, 2017050221000318, 2017050221000425, 2017051221000602, 2017051121000551, 2017051621000766, 2017051621000757
Bug group (optional): External feedback, Usability
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Florian Best univentionstaff 2017-05-17 15:28:34 CEST
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 +++
Comment 1 Florian Best univentionstaff 2017-05-17 15:40:18 CEST
#2017051721000317
Comment 2 Stefan Gohmann univentionstaff 2017-05-22 07:26:27 CEST
(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.
Comment 3 Florian Best univentionstaff 2017-05-22 12:49:36 CEST
(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.
Comment 4 Florian Best univentionstaff 2017-05-23 16:49:07 CEST
Reported again, 4.2-0 errata15 (Lesum)
#2017052321000412
Comment 5 Florian Best univentionstaff 2017-05-30 10:52:17 CEST
Reported again, 4.2-0 errata15 (Lesum)
#2017052521000374
Comment 6 Florian Best univentionstaff 2017-06-12 13:59:18 CEST
Reported again, 4.2-0 errata29 (Lesum)
2017060921000027
Comment 7 Florian Best univentionstaff 2017-06-16 18:45:42 CEST
4.2-0 errata29 (Lesum), #2017061221000833
Comment 8 Florian Best univentionstaff 2017-06-16 18:47:37 CEST
4.2-0 errata29 (Lesum), #2017061321000573
Comment 9 Florian Best univentionstaff 2017-06-16 18:50:46 CEST
4.2-0 errata29 (Lesum), #2017061521000891
Comment 10 Jürn Brodersen univentionstaff 2018-03-06 09:53:07 CET
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
Comment 11 Jürn Brodersen univentionstaff 2018-03-08 10:56:38 CET
*** Bug 45720 has been marked as a duplicate of this bug. ***
Comment 12 Jürn Brodersen univentionstaff 2018-03-08 12:14:37 CET
[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
Comment 13 Erik Damrose univentionstaff 2018-03-29 11:35:54 CEST
OK: catch ldap.INVALID_CREDENTIALS
OK: yaml
Verified
Comment 14 Florian Best univentionstaff 2018-03-29 13:17:50 CEST
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.
Comment 15 Jürn Brodersen univentionstaff 2018-04-03 11:41:03 CEST
(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.
Comment 16 Philipp Hahn univentionstaff 2018-04-04 16:17:33 CEST
<http://errata.software-univention.de/ucs/4.2/317.html>
Comment 17 Florian Best univentionstaff 2019-03-06 19:26:52 CET
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.