[Daniel Kempkens]

Hallo zusammen,

ich habe gestern unser OTOBO (Docker) auf das neueste Patchlevel 11.0.17 gehoben. Seitdem gibt es sporadisch den Fehler 500. Ich habe gerade in einer längeren Session den Fehler eingekreist und bin dabei auf Folgendes gestoßen:

• neues Telefonticket funktioniert
• neues Mail-Ticket funktioniert nicht. Sobald ich den Kundenbenutzer ausgewählt habe und danach die Queue auswähle, bekomme ich einen Error 500
• bei bestehenden Tickets bekomme ich die gleiche Meldung, wenn ich nachträglich den Kundenbenutzer ändere.

Ich habe in unserer Config.pm eine LDAP-Datenbank als Quelle für die Kundenbenutzer hinterlegt. Wir ziehen dort auch deren Zertifikate für die Kommunikation mit S/MIME. Wenn ich in der Config.pm im Bereich CustomerUser exakt diese Zeile aus dem Mapping auskommentiere, ist der Fehler verschwunden:

# this is needed, if "SMIME::FetchFromCustomer" is active

[ 'UserSMIMECertificate', 'SMIMECertificate', 'userCertificate', 0, 0, 'var', '', 1, undef, undef ],

Ich finde in den Patchnotes jedoch keinen Hinweis, der auf eine Änderung bei der Kundenanbindung schließen lässt. Kann jemand den Fehler eventuell nachvollziehen?

Vielen Dank und viele Grüße,

Daniel

[marcel-graf]

Hallo Daniel,

wir haben auch letzte Woche auf die 11.0.17 geupdated und hatten Probleme mit den Kundennbenutzern.

Bei uns war aber aktuell das Problem, dass wir in der Sytemconfig aus scheibar früheren Tests den „CustomerGroupSupport“ aktiv hatten. Wir binden die Agents und Kundenbenutzer per OIDC an.

 

-> Folgendes habe ich noch gefunden, das könntest du ja mal probieren.

#############################

Wenn OTOBO Binärdaten (wie Zertifikate oder Fotos) aus einem LDAP-Verzeichnis liest, muss Perl explizit angewiesen werden, diese Daten nicht als UTF-8-String, sondern als Binärdaten zu behandeln. Prüfen Sie in Ihrer Config.pm im betroffenen CustomerUser-Abschnitt die Parameter-Einstellung Params. Dort sollte das Feld als binär deklariert sein:

$Self->{CustomerUser} = {
Name => ‚LDAP-Datenbank‘,
Module => ‚Kernel::System::CustomerUser::LDAP‘,
# …
Params => {
Host => ‚ihr-ldap-server.local‘,
BaseDN => ‚dc=ihre-firma,dc=de‘,
SSLOpts => {
verify => ’none‘,
},
# WICHTIG: Hier wird definiert, welche Felder binär ausgelesen werden
Binary => {
‚userCertificate‘ => 1,
},
},
# …
};

Fehlt dieser Eintrag, versucht OTOBO seit dem Sicherheitsupdate das Zertifikat als Text zu interpretieren, was bei der Weiterverarbeitung zum Absturz führt.

Gruß Marcel

[Daniel Kempkens]

Hallo Marcel,

vielen Dank für den Tipp, ich habe es so in der Config.pm eingebaut:

$Self->{CustomerUser} = {
    Name => 'LDAP Backend',
    Module => 'Kernel::System::CustomerUser::LDAP',
    Params => {
        Host => '...',
        BaseDN => '...',
        SSCOPE => 'one',
        UserDN => '...',
        UserPw => '...',
        AlwaysFilter => '(objectclass=...)',
        SourceCharset => 'utf-8',
        DestCharset => 'iso-8859-1',
        Binary => {
            'userCertificate' => 1,
        },
        # die if backend can't work, e. g. can't connect to server
        Die => 0,
        # Net::LDAP new params (if needed - for more info see perldoc Net::LDAP)
        Params => {
            port => 636,
            timeout => 120,
            async => 0,
            version => 3,
        },
    },

...

Leider bleibt der Fehler aber bestehen. Oder habe ich den Parameter an der falschen Stelle eingebaut?

Viele Grüße,

Daniel

[marcel-graf]

kannst du es mal so einfügen?

$Self->{CustomerUser} = {
Name => ‚LDAP Backend‘,
Module => ‚Kernel::System::CustomerUser::LDAP‘,

# WICHTIG: Binary muss exakt auf dieser Ebene stehen!
Binary => {
‚userCertificate‘ => 1,
},

Params => {
Host => ‚…‘,
BaseDN => ‚…‘,
SSCOPE => ‚one‘,
UserDN => ‚…‘,
UserPw => ‚…‘,
AlwaysFilter => ‚(objectclass=…)‘,
SourceCharset => ‚utf-8‘,
DestCharset => ‚iso-8859-1′,
Die => 0,
Params => {
port => 636,
timeout => 120,
async => 0,
version => 3,
},
},

# Map-Array:
CustomerKey => ’sAMAccountName‘, # oder Ihre UID
CustomerID => ‚mail‘,
CustomerUserListFields => [‚cn‘, ‚mail‘],
CustomerUserSearchFields => [’sAMAccountName‘, ‚cn‘, ‚mail‘],

Map => [
# … Ihre anderen Standardfelder (Name, E-Mail, etc.) …

# Syntax: [ ‚InterneVariable‘, ‚Anzeigename‘, ‚LDAP-Attribut‘, Sichtbar, Pflicht, ‚Datentyp‘ ]
[ ‚UserCertificate‘, ‚Zertifikat‘, ‚userCertificate‘, 0, 0, ‚binary‘ ],
],
};

 

# In den Web-Container einwählen (falls Docker genutzt wird)

docker exec -it otobo_web_1 bash

Cache leeren und Konfiguration neu aufbauen

/opt/otobo/bin/otobo.Console.pl Maint::Cache::Delete

/opt/otobo/bin/otobo.Console.pl Maint::Config::Sync

 

Gruß Marcel

 

[marcel-graf]

noch als Ergänzung:

für Znuny (OTRS Fork) habe ich folgendes gefunden, diesen Punkt gibt es tatsächlich auch bei Otobo.

###In der SysConfig aktivieren###
Aktivieren Sie die grundlegende Unterstützung für das Abrufen von Zertifikaten aus dem Kunden-Backend. [1, 2]
Navigieren Sie im Admin-Bereich zu Admin → Systemkonfiguration (SysConfig).
Suchen Sie nach der Einstellung: SMIME::FetchFromCustomer.
Setzen Sie den Wert auf Ja (bzw. 1).

Ergänzen Sie Ihr bestehendes $Self->{CustomerUser}-Mapping in der Datei /opt/znuny/Kernel/Config.pm um den Eintrag für UserSMIMECertificate innerhalb des Map-Arrays:

$Self->{CustomerUser} = {
Name => ‚LDAP Backend‘,
Module => ‚Kernel::System::CustomerUser::LDAP‘,
# […] Ihre bestehenden LDAP-Konfigurationen

Map => [
# […] Bestehende Felder wie Vorname, Nachname, E-Mail usw.

# HIER DIESE ZEILE HINZUFÜGEN (Wichtig für SMIME::FetchFromCustomer):
# [ ‚Znuny-Feldname‘, ‚Anzeigename‘, ‚LDAP-Attribut‘, Sichtbar, Pflicht, Typ ]
[ ‚UserSMIMECertificate‘, ‚SMIMECertificate‘, ‚userSMIMECertificate‘, 0, 1, ‚var‘, “, 0 ],
],
};

Da wir kein Ldap nutzen, kann ich leider auch nicht testen.

[Daniel Kempkens]

Hallo Marcel,

ich habe in der Zwischenzeit das Problem mal mit Copilot analysieren lassen. Nach einigen Tests scheint es wohl so zu sein, dass trotz des „Binary“-Settings die Zertifikate in UTF-8 gespeichert werden, was seit dem letzten Patch ein Problem ist. Tatsächlich hatte ich bisher immer beim Import pro Zertifikat die Fehlermeldung „Wide character in print at /opt/otobo/Kernel/System/Crypt/SMIME.pm line 898“ gesehen, welche ich aber immer ignoriert habe, da die Funktionalität trotzdem gegeben war. :roll:

Wenn ich Copilot Glauben schenken darf (ich kenne mich mit Pearl eigentlich gar nicht aus) dann gibt es eine Unschärfe in der /opt/otobo/Kernel/System/CustomerUser/LDAP.pm, die dafür sorgt, dass das Binary-Setting ignoriert wird. Ich habe in unserem Testsystem ein paar Zeilen geändert, und nun funktioniert OTOBO wieder wie gewünscht.

Ich habe das mal im Issue-Tracker bei Github eingekippt, eventuell schaut da ein Entwickler drüber und kann etwas dazu sagen…

Viele Grüße,

Daniel

[marcel-graf]

ok, danke für die Rückmeldung.

Gruß Marcel

[Autor]

Beiträge