Active Directory in OTOBO per LDAP

Active Directory ist für die meisten OTOBO-Installationen die Quelle der Agenten. LDAP prüft das Passwort und übernimmt Name, E-Mail und Rollen in OTOBO. Das ist noch kein SSO.

Weg	Was der Agent tut	Wann
LDAP	Tippt das AD-Passwort in OTOBO	Immer der erste Schritt, damit Konten und Rollen existieren
Kerberos-SSO	Öffnet OTOBO am domänengebundenen PC, ohne Passwort	Büronetz, SPNEGO am Nginx
OpenID Connect	Meldet sich bei Microsoft Entra ID oder Keycloak an	Auch außerhalb der Domäne, ab OTOBO 11

Kerberos und OpenID Connect lösen die LDAP-Anmeldung ab. Die Synchronisation der Stammdaten bleibt sinnvoll, solange das Active Directory die Rollen führt. Das Kerberos-Konto HTTP/… ist dafür der falsche Benutzer.

Die Schlüssel stehen so in Kernel/Config/Defaults.pm von OTOBO 11.1. Sie gehören nach Kernel/Config.pm, nicht in die Defaults.

Anmeldung

$Self->{AuthModule} = 'Kernel::System::Auth::LDAP';
$Self->{'AuthModule::LDAP::Host'} = 'ldaps://dc1.example.com';
$Self->{'AuthModule::LDAP::BaseDN'} = 'dc=example,dc=com';
$Self->{'AuthModule::LDAP::UID'} = 'sAMAccountName';
$Self->{'AuthModule::LDAP::SearchUserDN'} = 'CN=otobo-ldap,OU=Service,DC=example,DC=com';
$Self->{'AuthModule::LDAP::SearchUserPw'} = 'search-user-secret';
$Self->{'AuthModule::LDAP::AlwaysFilter'} = '(&(objectClass=user)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))';
$Self->{'AuthModule::LDAP::Params'} = {
    verify => 'require',
};

Host mit ldaps:// nutzt Port 636. Ein anderer Port steht in der URL, zum Beispiel ldaps://dc1.example.com:737.
UID ist sAMAccountName. Damit heißt der OTOBO-Login so wie die kurze AD-Anmeldung.
Der Suchbenutzer liest nur. Anonyme Suche ist im Active Directory in der Regel geschlossen.
AlwaysFilter lässt deaktivierte Konten weg. Die OID 1.2.840.113556.1.4.803 ist der AD-Bit-Vergleich; das Flag 2 ist ACCOUNTDISABLE.
verify => 'require' prüft das TLS-Zertifikat des Domaincontrollers. Dafür muss der Host dem Aussteller vertrauen.

Wer die Mitgliedschaft in einer AD-Gruppe zur Bedingung macht, setzt UserAttr auf DN und AccessAttr auf member. AD-Gruppen speichern das Mitglied als Distinguished Name, nicht als memberUid.

$Self->{'AuthModule::LDAP::GroupDN'} = 'CN=OTOBO-Agents,OU=Groups,DC=example,DC=com';
$Self->{'AuthModule::LDAP::AccessAttr'} = 'member';
$Self->{'AuthModule::LDAP::UserAttr'} = 'DN';

Lassen Sie einen lokalen Administrator als zweite Quelle stehen. Fällt der Domaincontroller aus, bleibt dieser Zugang benutzbar:

$Self->{AuthModule2} = 'Kernel::System::Auth::DB';

Die Synchronisation läuft nach einer erfolgreichen Anmeldung. Sie legt den Agenten an und setzt Gruppen. Ein nächtlicher Vollabgleich ist das nicht.

$Self->{AuthSyncModule} = 'Kernel::System::Auth::Sync::LDAP';
$Self->{'AuthSyncModule::LDAP::Host'} = 'ldaps://dc1.example.com';
$Self->{'AuthSyncModule::LDAP::BaseDN'} = 'dc=example,dc=com';
$Self->{'AuthSyncModule::LDAP::UID'} = 'sAMAccountName';
$Self->{'AuthSyncModule::LDAP::SearchUserDN'} = 'CN=otobo-ldap,OU=Service,DC=example,DC=com';
$Self->{'AuthSyncModule::LDAP::SearchUserPw'} = 'search-user-secret';
$Self->{'AuthSyncModule::LDAP::AlwaysFilter'} = '(&(objectClass=user)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))';
$Self->{'AuthSyncModule::LDAP::UserSyncMap'} = {
    UserFirstname => 'givenName',
    UserLastname  => 'sn',
    UserEmail     => 'mail',
};
$Self->{'AuthSyncModule::LDAP::AccessAttr'} = 'member';
$Self->{'AuthSyncModule::LDAP::UserAttr'} = 'DN';
$Self->{'AuthSyncModule::LDAP::NestedGroupSearch'} = '1';
$Self->{'AuthSyncModule::LDAP::UserSyncRolesDefinition'} = {
    'CN=OTOBO-Admins,OU=Groups,DC=example,DC=com' => {
        'Service Desk Admin' => 1,
    },
    'CN=OTOBO-Agents,OU=Groups,DC=example,DC=com' => {
        'Service Desk' => 1,
    },
};

NestedGroupSearch folgt verschachtelten Verzeichnisgruppen. Links stehen Distinguished Names aus dem Active Directory. Rechts stehen OTOBO-Rollen, und 1 weist die Rolle zu. Die Rolle legen Sie vorher an und hängen die Rechte unter Rolle ↔ Gruppe an.

Die Beschriftung Gruppe im Admin ist ein Bündel von Rechten (ro, rw und die übrigen), kein Team. UserSyncGroupsDefinition schreibt diese Rechte direkt und lässt die Rollen aus. Den Schlüssel lassen Sie weg. Dieselbe Zuordnung, einschließlich der irreführenden Beschriftung, steht unter OpenID Connect. Das Basisrecht users hängen Sie an die Rolle. UserSyncInitialGroups legt dieses Bündel nur bei der ersten Anlage an.

Wechseln Sie später auf Kerberos, bleibt dieser Block. Weg fällt nur AuthModule = LDAP, ersetzt durch HTTPBasicAuth. Der Suchbenutzer bleibt otobo-ldap, nicht HTTP/otobo.example.com.

Kundenbenutzer

Dieselbe Form gibt es für das Kundenportal unter Customer::AuthModule mit Kernel::System::CustomerAuth::LDAP. Interne Agenten und externe Kunden gehören in getrennte Suchbasen. Eine Kundenfirma im Active Directory ist kein Grund, alle Mitarbeiter zu Kundenbenutzern zu machen.

Häufig gestellte Fragen

Ist LDAP gegen Active Directory dasselbe wie Single Sign-On?

Nein. LDAP prüft das Passwort, das der Agent in der OTOBO-Maske eintippt, und legt den Benutzer danach in OTOBO an. Single Sign-On ohne diese Maske ist Kerberos im Büronetz oder OpenID Connect mit Microsoft Entra ID.

Welches Attribut ist der OTOBO-Login im Active Directory?

sAMAccountName. Das Attribut uid gibt es in einem normalen Active Directory nicht. Der Login in OTOBO muss diesem Wert entsprechen, auch wenn die Anmeldung später auf Kerberos oder OpenID Connect wechselt.

Wann aktualisiert OTOBO Rollen aus dem Active Directory?

Beim erfolgreichen Login, nicht nach einem Zeitplan. Ein Agent, der sich nie anmeldet, behält die alten Rollen. Verschachtelte Verzeichnisgruppen brauchen AuthSyncModule::LDAP::NestedGroupSearch. Diese Verzeichnisgruppen bilden Sie auf OTOBO-Rollen ab, nicht auf die Rechtebündel, die der Admin als Gruppen beschriftet.

Active Directory in OTOBO per LDAP

Anmeldung

Synchronisation nach dem Login

Kundenbenutzer

Häufig gestellte Fragen