[Jürgen F]

Ich habe Probleme die Kundendaten aus der AD zu importieren. Agenten können sich anmelden und die Zuordnung aus einer Gruppe in der AD funktioniert.

Nun möche ich die Kundendaten aus der AD einlesen, damit ich sie im Ticket suchen kann. Wenn ich aber den folgenden Abschnitt in der Config.pm einfüge, bekomme ich den Fehler “syntax error at /opt/otobo/Kernel/Config.pm line 98, near “BaseDN” Global symbol “$Self” requires explicit package name”

Hier der Abschnitt:

$Self->{CustomerUser} = {
Name => ‘LDAP Userdaten’,
Module => ‘Kernel::System::CustomerUser::LDAP’,
Params => {
Host => ‘dc1.domain.de’
BaseDN => ‘dc=domain,dc=de’,
SSCOPE => ‘sub’,
UserDN => ‘Domainbenutzer@domain.de’,
UserPW => ‘GeheimesPasswort’,
AlwaysFilter => ”,
# die if backend can’t work
Die => 0,
Params => {
port => 389,
timeout => 120,
async => 0,
version => 3,
},
},
CustomerKey => ‘sAMAccountName’,
# customer #
CustomerID => ‘mail’,
CustomerUserListFields => [‘cn’, ‘mail’],
CustomerUserSearchFields => [‘sAMAccountName’, ‘cn’, ‘mail’],
CustomerUserSearchPrefix => ”,
CustomerUserSearchSuffix => ‘*’,
CustomerUserSearchListLimit => 250,
CustomerUserPostMasterSearchFields => [‘mail’],
CustomerUserNameFields => [‘givenname’, ‘sn’],
# Configures the character for joining customer user name parts. Join single space if it is not defined.
CustomerUserNameFieldsJoin => ”,
# show customer user and customer tickets in the external interface
CustomerUserExcludePrimaryCustomerID => 0,
# add a ldap filter for valid users (expert setting)
# # CustomerUserValidFilter => ‘(!(description=gesperrt))’,
# admin can’t change customer preferences
AdminSetPreferences => 0,
# cache time to live in sec. – cache any ldap queries
# CacheTTL => 0,
Map => [
[ ‘UserTitle’, Translatable(‘Title or salutation’), ‘title’, 1, 0, ‘var’, ”, 1, undef, undef ],
[ ‘UserFirstname’, Translatable(‘Firstname’), ‘givenname’, 1, 1, ‘var’, ”, 1, undef, undef ],
[ ‘UserLastname’, Translatable(‘Lastname’), ‘sn’, 1, 1, ‘var’, ”, 1, undef, undef ],
[ ‘UserLogin’, Translatable(‘Username’), ‘sAMAccountName’, 1, 1, ‘var’, ”, 1, undef, undef ],
[ ‘UserEmail’, Translatable(‘Email’), ‘mail’, 1, 1, ‘var’, ”, 1, undef, undef ],
[ ‘UserCustomerID’, Translatable(‘CustomerID’), ‘mail’, 0, 1, ‘var’, ”, 1, undef, undef ],
[ ‘UserDepartment’, Translatable(‘Department’), ‘department’, 1, 0, ‘var’, ”, 1, undef, undef ],
[ ‘UserPhone’, Translatable(‘Phone’), ‘telephonenumber’, 1, 0, ‘var’, ”, 1, undef, undef ],
[ ‘UserAddress’, Translatable(‘Address’), ‘postaladdress’, 1, 0, ‘var’, ”, 1, undef, undef ],
[ ‘UserComment’, Translatable(‘Comment’), ‘description’, 1, 0, ‘var’, ”, 1, undef, undef ],
],
};

Wo muss ich einen expliziten Paketnamen einfügen? Hat jemand einen Tipp was ich übersehe?

 

[Anonym]

Servus Jürgen!

Fehlt hinter Host => ‚dc1.domain.de‘ einfach das Komma?

[Jürgen F]

Das hatte ich gestern auch bemerkt, vielen Dank für deine Antwort!

Als ich das Komma ergänzt habe, konnte der Server noch immer nicht starten. Ich bekam ich folgenden Fehler:

[Wed Jun 01 14:50:45.697323 2022] [:error] [pid 1036163:tid 140569095427840] Attempt to reload Kernel/System/ObjectManager.pm aborted.
Compilation failed in require at /opt/otobo/bin/cgi-bin/index.pl line 32.
BEGIN failed–compilation aborted at /opt/otobo/bin/cgi-bin/index.pl line 32.

Heute Morgen kann ich mich ohne Servererror wieder an Otobo anmelden. Der obige Fehler ist verschwunden. Das importieren der Kundendaten funktioniert aber weiterhin nicht.

Im Apache Error Log findet sich nun die Meldung:

Message: Search failed! 000004DC: LdapErr: DSID-0C0907E9, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v2580

Im Syslog auch:

OTOBO-CGI-51[2082226]: [Error][Kernel::System::CustomerUser::LDAP::CustomerSearch][Line:517]: Search failed! 000004DC: LdapErr: DSID-0C0907E9, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v2580

Hat jemand eine Idee, wie ich herausfinden kann, an welcher Stelle die Verbindung zur AD abbricht / nicht komplett ist?

[Jürgen F]

Hier nochmal der komplette Kundenteil:

$Self->{‘Customer::AuthModule’} = ‘Kernel::System::CustomerAuth::LDAP’;
$Self->{‘Customer::AuthModule::LDAP::Host’} = ‘dc1.domain.de’;
$Self->{‘Customer::AuthModule::LDAP::BaseDN’} = ‘dc=domain,dc=de’;
$Self->{‘Customer::AuthModule::LDAP::UID’} = ‘sAMAccountName’;
$Self->{‘Customer::AuthModule::LDAP::SearchUserDN’} = ‘Domainbenutzer@domain.de’;
$Self->{‘Customer::AuthModule::LDAP::SearchUserPw’} = ‘GeheimesPasswort’;

$Self->{CustomerUser} = {
Name => ‘LDAP Backend’,
Module => ‘Kernel::System::CustomerUser::LDAP’,
Params => {
Host => ‘dc1.domain.de’,
BaseDN => ‘ou=Mitarbeiter,dc=domain,dc=de’,
SSCOPE => ‘sub’,
UserDN => ‘Domainbenutzer@domain.de’,
UserPW => ‘GeheimesPasswort’,
AlwaysFilter => ‘(objectclass=user)’,
# die if backend can’t work
Die => 0,
Params => {
port => 389,
timeout => 120,
async => 0,
version => 3,
},
},
CustomerKey => ‘sAMAccountName’,
# customer #
CustomerID => ‘mail’,
CustomerUserListFields => [‘cn’, ‘mail’],
CustomerUserSearchFields => [‘sAMAccountName’, ‘cn’, ‘mail’],
CustomerUserSearchPrefix => ”,
CustomerUserSearchSuffix => ‘*’,
CustomerUserSearchListLimit => 250,
CustomerUserPostMasterSearchFields => [‘mail’],
CustomerUserNameFields => [‘givenname’, ‘sn’],

Map => [
[ ‘UserTitle’, Translatable(‘Title or salutation’), ‘title’, 1, 0, ‘var’, ”, 1, undef, undef ],
[ ‘UserFirstname’, Translatable(‘Firstname’), ‘givenname’, 1, 1, ‘var’, ”, 1, undef, undef ],
[ ‘UserLastname’, Translatable(‘Lastname’), ‘sn’, 1, 1, ‘var’, ”, 1, undef, undef ],
[ ‘UserLogin’, Translatable(‘Username’), ‘sAMAccountName’, 1, 1, ‘var’, ”, 1, undef, undef ],
[ ‘UserEmail’, Translatable(‘Email’), ‘mail’, 1, 1, ‘var’, ”, 1, undef, undef ],
[ ‘UserCustomerID’, Translatable(‘CustomerID’), ‘mail’, 0, 1, ‘var’, ”, 1, undef, undef ],
[ ‘UserDepartment’, Translatable(‘Department’), ‘department’, 1, 0, ‘var’, ”, 1, undef, undef ],
[ ‘UserPhone’, Translatable(‘Phone’), ‘telephonenumber’, 1, 0, ‘var’, ”, 1, undef, undef ],
[ ‘UserAddress’, Translatable(‘Address’), ‘postaladdress’, 1, 0, ‘var’, ”, 1, undef, undef ],
[ ‘UserComment’, Translatable(‘Comment’), ‘description’, 1, 0, ‘var’, ”, 1, undef, undef ],
],
};

# Die if backend can’t work, e. g. can’t connect to server.
$Self->{‘Customer::AuthModule::LDAP::Die’} = 1;

[Anonym]

Wenn Du ein halbwegs aktuelles AD hast, dann funktioniert die Verbindung nicht unverschlüsselt über Port 389…

Bei mir steht in der Config.pm:
Customer::AuthModule::LDAP::SearchUserDN'} = 'cn=Domainbenutzer,dc=domain,dc=de';
(bei UserDN ebenfalls)

[Jürgen F]

Vielen Dank für die Antwort!

Die Verbindung funktioniert noch intern über Port 389, die Agenten werden so einwandfrei synchronisiert.

Irgendwo wird die Verbindung nicht abgeschlossen. Im Systemprotokoll kommt bei jeder Kundenabfrage:

Search failed! 000004DC: LdapErr: DSID-0C0907E9, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v2580

Bin für jede Idee dankbar wie ich das besser debuggen kann.

[Jürgen F]

Hab jetzt mal mit ldp.exe versucht eine einfache Bindung zum AD herzustellen.

Wenn ich nur den Benutzernamen eingebe und das PW bekomme ich folgenden Fehler:

Error <49>: ldap_simple_bind_s() failed: Ungültige Anmeldeinformationen
Server error: 80090308: LdapErr: DSID-0C09044E, comment: AcceptSecurityContext error, data 52e, v2580
Error 0x80090308 Das Token, das der Funktion übergeben wurde, ist ungültig.

Wenn ich den Benutzernamen@Domain.de eingebe funktioniert die Verbindung.

ld = ldap_open(“dc1.domain.de”, 389);
Established connection to dc1.domain.de.

Was eigentlich klar ist, da die Agenten ja fehlerfrei synchronisiert werden.

Das Problem ist also, dass bei dem {CustomerUser} nur Benutzername und PW an die AD übergeben werden und nicht “@Domain.de” und so die Verbindung in einen Fehler läuft.

 

[Anonym]

Hast du es schon mit dem “Distinguished Name” in der Config.pm probiert?

Also: ‘cn=Domainbenutzer,dc=domain,dc=de’

[Jürgen F]

Jupp, habe ich probiert, bleibt aber beim gleichen Ergebnis. Anscheinend wird nur der sAMAccountName und das PW übergeben.

Die Frage ist warum es bei den Agenten mit
$Self->{‘AuthSyncModule::LDAP::SearchUserDN’} = ‘Domainbenutzer@domain.de‘;
funktioniert, mit den Params UserDN => ‘Domainbenutzer@domain.de‘; aber nicht.
Finde auch keinen anderen Weg wie ich die Userdaten anders mappen kann.
Laut Doku soll es ja genau so funktionieren.

 

[Jürgen F]

Hier mal die vollständige Fehlermeldung aus dem Apache Error.log:

ERROR: OTOBO-CGI-51 Perl: 5.32.1 OS: linux Time: Tue Jun 7 12:57:49 2022

Message: Search failed! 000004DC: LdapErr: DSID-0C0907E9, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v2580

RemoteAddress: xxx.xxx.xxx.xxx
RequestURI: /otobo/index.pl?Action=AdminCustomerUser;Nav=None;Subject=;What=;ChallengeToken=3tAAQyiJBzd8xtGVtiKxMpUJAP7XMW0r

Traceback (27764):
Module: Kernel::System::CustomerUser::LDAP::CustomerSearch Line: 535
Module: Kernel::System::CustomerUser::CustomerSearch Line: 295
Module: Kernel::Modules::AdminCustomerUser::_Overview Line: 934
Module: Kernel::Modules::AdminCustomerUser::Run Line: 830
Module: Kernel::System::Web::InterfaceAgent::Run Line: 1258
Module: ModPerl::ROOT::ModPerl::Registry::opt_otobo_bin_cgi_2dbin_index_2epl::handler Line: 37
Module: (eval) (v1.99) Line: 207
Module: ModPerl::RegistryCooker::run (v1.99) Line: 207
Module: ModPerl::RegistryCooker::default_handler (v1.99) Line: 173
Module: ModPerl::Registry::handler (v1.99) Line: 32

[Jürgen F]

Hab jetzt probiert das Suffix noch dazu zu bekommen:

$Self->{‚Customer::AuthModule::LDAP::SearchUserDN‘} = ‚CN=Domainbenutzer,OU=OrganizationalUnit,DC=domain,DC=de‘;
$Self->{‘Customer::AuthModule::LDAP::SearchUserSuffix’} = ‘@domain.de’;

und unter $Self->{CustomerUser} = {

UserDN => ‚CN=Domainbenutzer,OU=OrganizationalUnit,DC=domain,DC=de‘,
UserSuffix => ‘@domain.de’,
UserPW => ‚GeheimesPasswort‘,

Nach wie vor bleibt der Fehler:
Message: Search failed! 000004DC: LdapErr: DSID-0C0907E9, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v2580

So langsam gehen mir die Ideen aus.

[Stefan Rother]

Hallo Jürgen,

ich würde nochmal ein Schritt zurückgehen, die Konfiguration schaut mir nicht ganz vollständig aus. Die aktuelle Konfiguration findest Du in der Datei /opt/otobo/Kernel/Config/Defaults.pm. Hier bitte den CustomerUser für LDAP Teil rauskopieren und in die Datei /opt/otobo/Kernel/Config.pm übernehmen.

Zuerst war Deine Syntax nicht richtig (fehlendes Komma), daran hatte sich der Apache verschluckt (daher ging es am nächsten Tag wieder, ein “service apache restart” hätte hier auch geholfen).

Der Fehler gerade sagt eigentlich nur, dass der Bind nicht erfolgreich war, entweder es stimmt etwas mit dem Bind-User nicht.

Ich gebe hier immer den gesamten Pfad zu dem User an (UserPrincipalName glaube ich). Den Teil mit dem Suffix kannst Du einfach wieder rauswerfen und die UserDN wie folgt angeben:

UserDN => ‚CN=Domainbenutzer,OU=OrganizationalUnit,DC=domain,DC=de‘,

Wenn Du das gemacht hast, liegt es sicher an irgendeiner Kleinigkeit. Also alles nochmal raus und aus der Defaults.pm neu machen, eventuell hast Du irgendwelche Hochkommas falsch reimkopiert o.ä.

Schöne Grüße,

Stefan

Team OTOBO

 

[Jürgen F]

Das hat funktioniert vielen Dank!

[Autor]

Beiträge