subscribe.folders und Wrong Password

[asteini]

Hallo an alle, mit dem Update auf 6.18 bekommen wir noch die u.g. Fehlermeldung.

Sep 6, 2010 2:16:52 PM com.openexchange.subscribe.folders.HasSubscriptions getValue
SEVERE: CRP-0001 Category=1 Message=Wrong Password. exceptionID=2117214136-2239
CRP-0001 Category=1 Message=Wrong Password. exceptionID=2117214136-2239
        at com.openexchange.subscribe.AbstractSubscribeService.decrypt(AbstractSubscribeService.java:177)
        at com.openexchange.subscribe.crawler.internal.GenericSubscribeService.modifyOutgoing(GenericSubscribeService.java:141)
        at com.openexchange.subscribe.AbstractSubscribeService.loadSubscriptions(AbstractSubscribeService.java:82)
        at com.openexchange.subscribe.folders.HasSubscriptions.getValue(HasSubscriptions.java:99)
        at com.openexchange.ajax.writer.FolderWriter$23.writeField(FolderWriter.java:693)
        at com.openexchange.ajax.writer.FolderWriter.writeOXFolderFieldsAsArray(FolderWriter.java:441)
        at com.openexchange.ajax.Folder.actionGetSubfolders(Folder.java:800)
        at com.openexchange.ajax.Folder.actionGetSubfolders(Folder.java:406)
        at com.openexchange.ajax.Folder.actionGet(Folder.java:271)
        at com.openexchange.ajax.Folder.doGet(Folder.java:224)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:596)
        at com.openexchange.ajax.AJAXServlet.service(AJAXServlet.java:392)
        at com.openexchange.ajax.SessionServlet.service(SessionServlet.java:174)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
        at com.openexchange.ajp13.najp.AJPv13RequestHandlerImpl.doServletService(AJPv13RequestHandlerImpl.java:504)
        at com.openexchange.ajp13.AJPv13Request.response(AJPv13Request.java:129)
        at com.openexchange.ajp13.najp.AJPv13RequestHandlerImpl.createResponse(AJPv13RequestHandlerImpl.java:316)
        at com.openexchange.ajp13.najp.AJPv13ConnectionImpl.createResponse(AJPv13ConnectionImpl.java:207)
        at com.openexchange.ajp13.najp.AJPv13Task.call(AJPv13Task.java:346)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
        at java.util.concurrent.FutureTask.run(FutureTask.java:166)
        at com.openexchange.threadpool.internal.CustomThreadPoolExecutor$Worker.runTask(CustomThreadPoolExecutor.java:738)
        at com.openexchange.threadpool.internal.CustomThreadPoolExecutor$Worker.run(CustomThreadPoolExecutor.java:764)
        at java.lang.Thread.run(Thread.java:636)
Caused by: CRP-0001 Category=1 Message=Wrong Password. exceptionID=2117214136-2238
        at com.openexchange.crypto.internal.CryptoExceptionFactory.createException(CryptoExceptionFactory.java:64)
        at com.openexchange.crypto.internal.CryptoExceptionFactory.createException(CryptoExceptionFactory.java:60)
        at com.openexchange.exceptions.Exceptions.create(Exceptions.java:144)
        at com.openexchange.exceptions.Exceptions.create(Exceptions.java:164)
        at com.openexchange.crypto.CryptoErrorMessage.create(CryptoErrorMessage.java:111)
        at com.openexchange.crypto.internal.CryptoServiceImpl.decrypt(CryptoServiceImpl.java:251)
        at com.openexchange.crypto.internal.CryptoServiceImpl.decrypt(CryptoServiceImpl.java:149)
        at com.openexchange.crypto.internal.CryptoServiceImpl.decrypt(CryptoServiceImpl.java:137)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:616)
        at com.openexchange.server.osgiservice.DynamicWhiteboardFactory$ServiceTrackerInvocationHandler.invoke(DynamicWhiteboardFactory.java:175)
        at $Proxy14.decrypt(Unknown Source)
        at com.openexchange.subscribe.AbstractSubscribeService.decrypt(AbstractSubscribeService.java:175)
        ... 23 more
Caused by: javax.crypto.BadPaddingException: Given final block not properly padded
        at com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:811)
        at com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:676)
        at com.sun.crypto.provider.AESCipher.engineDoFinal(AESCipher.java:317)
        at javax.crypto.Cipher.doFinal(Cipher.java:1813)
        at com.openexchange.crypto.internal.CryptoServiceImpl.decrypt(CryptoServiceImpl.java:246)
        ... 32 more

Wir verwenden imapauth als Authentifizierung und lassen diese gegen LDAP Laufen. Siehe hier. Wir nehmen aber an, dass "com.openexchange.subscribe.folders" das Passwort aus der DB verwenden möchte (reine Annahme). Wenn dies der Falls ist - Kann man das und wo nachkonfen? Danke ... kann gar nicht genug sagen!

[Martin Heiland]

Hallo,

das Passwort für Subscriptions (Abonements) wird generell in der Datenbank gespeichert und durch das OX Login-Passwort verschlüsselt. Möglicherweise hat ein Benutzer sein Passwort per LDAP geändert und es passt nun nicht mehr zu dem verschlüsselten Passwort in der Datenbank?

Gruß

[asteini]

Sorry für die späte Antwort. Bin gestern verfrüht in den Feierabend. So aber zum Thema:

Meines Wissens stimmt das Passwort im OpenLDAP nicht mit dem Passwort in der Datenbank überein. Mittels imapauth authentifizieren wir unsere Benutzer über indirekten Weg (cyrus->sasl->OpenLDAP) mit LDAP. Die Benutzer und Gruppen synchronisieren wir mittels oxldapsync in die Datenbank. Und dieses Prinzip synct ja nicht die Passwörter.

Kriegt man in irgend einer Weise die Passwörter synchron?

[Martin Heiland]

Hallo,

wie gesagt - wenn das Passwort extern verwaltet wird, bekommt OX eine Änderung dessen nicht mit. Daher können die verschlüsselten Passwörter mit dem geänderten Passwort nicht entschlüsselt werden. Die Passwörter für die externen Accounts müssen neu eingegeben und gespeichert werden. Natürlich wäre ein schicker Dialog, der einen darauf hinweist, besser.

Gruß

[asteini]

Äha ... darf ich mal laut denken: Wenn ich also Benutzer extern verwalte (OpenLDAP) kann ich diese mittels oxldapsync in die Datenbank transferieren. Mit einem cronjob kann ich diesen synchron halten. Das Mapping der Datenfelder erfolgt ja in der mapping.openldap.conf oder mapping.ads.conf(für AD). Dabei wird das Passwort nicht repliziert. Ergebniss dessen ist, dass das Passwortfeld in der OX Datenbank nicht mit dem Passwort im LDAP übereinstimmt. Der Anmeldevorgang, sei es direkt über ldapauth oder imapauth, würde ja funktionieren, da die Vorgang externe Quellen anfragt.

Und jetzt gibt es mit der Version 6.18 wohl interne Plugins oder Bundles, die nur mit Passwortfeld aus der OX Datenbank arbeiten? Man muss jetzt praktisch zu sehen, dass die Passwörter in der OX DB und OpenLDAP übereinstimmen damit dieser Fehler verschwindet. Oder kann man dieses Plugin bzw. Bundle deaktivieren?

[Martin Heiland]

Wenn der Fehler auftritt, werden die entsprechenden Plugins offenbar schon benutzt, sie einfach zu deaktivieren wäre also nicht besonders gut. Man muss nun wie gesagt dafür sorgen, dass der Benutzer das Passwort für den entsprechenden externen account (z.B. einen Google E-Mail Account, XING Kontaktdatenbank etc) erneut eingibt damit wieder Zugriff möglich ist.

[asteini]

ja wir haben ja keine :-) Das einzige was wir nutzen ist das Webinterface des OX. Die Authentifizierung der Benutzer läuft über imapauth. Das wars. Keine externen Account oder ähnliches.

[asteini]

Hallo Martin,

ich hab da echt ein Verständnisproblem: Darf ich da mal ganz naiv fragen - korregiere mich, falls ich etwas falsch dar stelle.

Also mit imapauth.properties oder ldapauth.properties kann ich den Authentifizierungvorgang an die jeweiligen Dienste(IMAP o. LDAP) weiterreichen. Stimmt bei der Anmeldung das Passwort und Benutzer überein, kriegt der Nutzer den Zugang zum GUI. Wobei der Benutzername auch bei mehreren Contexten in der OX DB vorhanden sein muss.

Die Subscriptions (Abonements) ist ja ein Plugin das neu hinzu kam. Damit abonniert man parktisch z.B. einen GoogleCal in einen neu erstellten Kalender Ordner im OX. In dieser Konfiguration werden eingetragene Passwörter mit dem OX DB Passwort praktisch nochmal verschlüsselt.

Dadurch das Plugin nichts vom externen LDAP ode IMAP Passwort weiß, kommt es zum erfolglosem Entschlüsseln der Abboszugänge? ist das richtig, sorry!

[Martin Heiland]

Also das sieht wie folgt aus:

Der Benutzer loggt sich mit passwort "foobar" ein, das heisst die OX leitet die User/Passwort Kombination an LDAP weiter und bekommt eine positive Rückmeldung. Das Passwort "foobar" ist der OX ja intern noch bekannt auch wenn es nicht über die Datenbank bestätigt wurde.
Nun legt der Benutzer ein Abonement an, Google Kalender mit Benutzername irgendwas@googlemail.com und Passwort "wasganzanderes". Die Passwörter fürs Abonement werden in der Datenbank gespeichert. Damit dies nicht im Klartext passiert, wird "wasganzanderes" verschlüsselt und zwar mit "foobar" als Schlüssel. Damit steht dann "fojshhewghw" als Passwort für das Abonement in der Datenbank. Wenn die OX nun wieder auf den Google Kalender zugreifen will, muss "fojshhewghw" mit "foobar" entschlüsselt werden um "wasganzanderes" zu erhalten. Symmetrische Verschlüsselung halt.

Nun ändert der Benutzer sein Passwort von "foobar" auf "geheim". Dadurch kennt die OX "foobar" nicht mehr und die Entschlüsselung von "fojshhewghw" durch "geheim" schlägt fehl, da der korrekte Schlüssel "foobar" wäre. Durch die Änderung des OX Passworts werden also gespeicherte Passwörter für externe Dienste unbrauchbar und müssen neu eingegeben werden, damit sie mit dem neuen OX Passwort verschlüsselt werden um eine Entschlüsselung zu ermöglichen.

Gruß

[asteini]

Martin danke für die ausführlich Beschreibung. Haben es jetzt hingekriegt ... :-) Einige Ordner wurden für andere Benutzer freigegeben. Diese entfernt und neu freigegegen, dass aber mit einem neuen Passwort und klappts. Danke für die Unterstützung!