Authentifizierung/Autorisierung und Anbindung Active Directory
Die Authentifizierung und Autorisierung von Nutzern in KIX wird über sog. Authentifizierungs- und Synchronisations- Backends gesteuert. Standardmäßig wird die Authentifizierung gegen die KIX-eigene Nutzerverwaltung verwendet.
Verzeichnisdienst nutzen (AD, LDAP)
Konfigurationsschlüssel | Authentication###000- Default |
Für die Verwaltung der Nutzer-Logins können Sie Nutzerdaten und Berechtigungen Ihres LDAP/AD-Servers (Domaincontrollers) verwenden. Der Vorteil liegt dabei in der zentralen Nutzerverwaltung sowohl für Ihre Infrastruktur als auch für KIX. Die Pflege der Nutzer entfällt somit in KIX und erfolgt zentral im Active Directory. Der Initialnutzer ist jedoch immer erforderlich.
Die Einrichtung der Authentifizierung und Autorisierung erfolgt über die Konfiguration des JSON-Strings im SysConfig-Schlüssel: . Der im SysConfig-Schlüssel enthaltene JSON-String ist bereits grundlegend vorbereitet. Für die Verwendung eines LDAP-Verzeichnisdienstes müssen lediglich die entsprechenden Parameter wie Domain, Pfad, Verzeichnis und Attribute angegeben werden. KIX weist dem Nutzer automatisch die hinterlegten Rollen in KIX zu. Grundlage dafür sind Gruppenzuordnungen des Nutzers im LDAP/AD. Welche Attribute (Eigenschaften) auf welche Rollen gemappt werden, ist bei der Konfiguration des JSON-Strings festzulegen.
Sie können mehrere Authentifizierungs-Backends einrichten (Anzahl unbegrenzt) und diese separat konfigurieren. Voraussetzung ist mindestens ein vom Backend des KIX erreichbarer LDAP/ AD-Server mit konfigurierten Nutzern und Rechten.
Es können mehrere Hosts unterschiedlicher Formate angegeben werden. Im KIX-Log können Sie eruieren, welches Backend die Authentifizierung vorgenommen hat. Dazu ist am Log-Eintrag einer erfolgreichen Authentifizierung der Name des Backends vermerkt (Menü System > Logs > Datei: kix.log.[yyyy-mm]).
Es werden sowohl das Microsoft Active Directory (AD) sowie alle gängigen LDAP-Verzeichnisdienste unterstützt. Als Fallback für die Autorisierung dient die KIX-eigne Datenbank.
Eine Begrenzung der Nutzeranzahl ist nicht gegeben. Kontakt- und Nutzerdaten werden lokal vorgehalten, sodass keine Verzögerungen durch Latenzen in Kommunikation mit LDAP/AD entstehen.
Logt sich ein Nutzer in KIX ein, erfolgt ein Datenabgleich von KIX mit den eingerichteten LDAP-Servern. Sind Unterschiede vorhanden, werden die Daten in KIX mit denen der LDAP-Server synchronisiert. Die Reihenfolge der angegebenen LDAP-Server gibt vor, welches Backend zuerst geprüft wird (von oben nach unten). Kommt es dabei zu einem Fehler (Server nicht erreichbar, Nutzer nicht vorhanden, etc.), dann wird das nächste Backend geprüft.
Abb.: Schema LDAP/AD-Anbindung an KIX 18
Hinweis
Passwortänderungen für Nutzerlogins erfolgen hierbei ausschließlich via LDAP. Anpassungen im KIX sind nicht wirksam.
Tipp
In KIX Pro können neben den Nutzerdaten auch die Kontaktdaten mit dem LDAP/AD synchronisiert werden. Die Pflege der Nutzer und der Kontakte erfolgt somit zentral über das LDAP/AD und erfordert keine aktive Anmeldung des Nutzers um seine Kontaktdaten in KIX verfügbar zu machen.
Um KIX an einen LDAP/AD-Server anzubinden, gehen Sie wie folgt vor:
Navigieren Sie im Explorer zu .
Suchen Sie den Schlüssel .
Klicken Sie diesen an, um ihn zur Bearbeitung zu öffnen.
Es wird ein Formular-Dialog geöffnet, welcher bereits einen vorbereiteten JSON-String im Feld Wert enthält.
Optional: Kopieren Sie diesen String zur leichteren Bearbeitung in einen JSON-Editor (z. B. www.jsonformatter.io).
Passen Sie die Konfiguration an.
Definieren Sie die Verbindungs- und Authentifizierungsparameter sowie den Host (s. Konfigurationsbeispiel ).
Achtung
Änderungen am letzten Codeblock können zum Ausschluss aus dem System führen!
Die KIX-Datenbank (letztes Backend im JSON-Sring) sollte im Normalfall weder entfernt noch ausgeschaltet ("disabled") werden. Sie dient als Fallback, falls der LDAP-Server nicht erreichbar oder der Nutzer nicht vorhanden ist.
Ändern Sie die Konfiguration wirklich nur im Ausnahmefall! Anderenfalls könnten Sie sich gänzlich aus dem System aussperren.
Abb.: Beispiel eines konfigurierten Authentifizierungsbackends
Minimieren Sie den JSON-String und kopieren Sie ihn (ohne Leerzeichen und Umbrüche) zurück ins Feld Wert.
Klicken Sie abschließend auf .
Klicken Sie in der Übersicht auf , um die Ansicht im Frontend zu aktualisieren.
Die Standardkonfiguration ist nun durch eine angepasste Konfiguration ersetzt worden.
Logt sich ein Nutzer in KIX ein, kommuniziert KIX mit den so angebundenen Verzeichnisdiensten und prüft die Logins.
Das nachfolgende Konfigurationsbeispiel zeigt, wie die Anbindung an einen LDAP-Server aussehen könnte. Es sind 2 Authentifizierungsbackends konfiguriert: eins für das Self Service Portal und eins für das Agentenportal (s. Attribut "UsageContext")
[
{
"Enabled": 1,
"Module": "Kernel::System::Auth::LDAP",
"Name": "1st Backend: Customer Contact From LDAP (use mail address as login)",
"UsageContext": "Customer",
"Config": {
"AlwaysFilter": "(&(objectclass=person)(mail=*))",
"BaseDN": "dc=example,dc=com",
"Charset": "utf-8",
"Die": 1,
"Host": "ldap.example.com",
"Params": {
"async": 0,
"port": 389,
"timeout": 10,
"version": 3
},
"SearchUserDN": "cn=read-only-admin,dc=example,dc=com",
"SearchUserPw": "password",
"GroupDN": "dc=customercontacts,dc=example,dc=com",
"AccessAttr": "uid",
"UID": "uid",
"UserAttr": "UID",
"AuthAttr": "mail",
"UserSuffix": ""
},
"Sync": [
{
"Enabled": 1,
"Module": "Kernel::System::Auth::Sync::LDAP",
"Config": {
"ContactUserSync": {
"Email": "mail",
"Firstname": "givenname",
"Lastname": "sn",
"UserLogin": "uid",
"PrimaryOrganisationID": "SET:13",
"OrganisationIDs": [
"department",
"SET:13"
],
"DynamicField_Source": "SET:Backend001-LDAP"
},
"GroupDNBasedRoleSync": {
"dc=customercontacts,dc=example,dc=com": {
"Some Customer Role": 1,
}
},
"GroupDNBasedUsageContextSync": {
"dc=serviceteam,dc=example,dc=com": {
"IsAgent": 1,
"IsCustomer": 1
},
"dc=agentsonly,dc=example,dc=com": {
"IsAgent": 1,
"IsCustomer": 0
},
"dc=customercontacts,dc=example,dc=com": {
"IsCustomer": 1
},
"dc=externals,dc=example,dc=com": {
"IsCustomer": 1
}
}
}
}
]
},
{
"Enabled": 1,
"Module": "Kernel::System::Auth::LDAP",
"Name": "2nd Backend: Agent Users from Active Directory (via multiple LDAPS)",
"UsageContext": "Agent",
"Config": {
"AlwaysFilter": "(&(objectclass=person)(mail=*))",
"BaseDN": "dc=example,dc=com",
"Charset": "utf-8",
"Die": 1,
"Host": [
"ldaps://dc1.example.com",
"ldaps://dc2.example.com"
],
"Params": {
"async": 0,
"port": 636,
"timeout": 10,
"version": 3
},
"SearchUserDN": "cn=read-only-admin,dc=example,dc=com",
"SearchUserPw": "password",
"GroupDN": "dc=serviceteam,dc=example,dc=com",
"AccessAttr": "member",
"UID": "sAMAccountName",
"UserAttr": "DN",
"UserSuffix": ""
},
"Sync": [
{
"Enabled": 1,
"Module": "Kernel::System::Auth::Sync::LDAP",
"Config": {
"ContactUserSync": {
"Email": "mail",
"Title": "title",
"Firstname": "givenname",
"Lastname": "sn",
"Street": "streetAddress",
"City": "l",
"Zip": "postalCode",
"Phone": "telephoneNumber",
"Mobile": "mobile",
"Fax": "facsimileTelephoneNumber",
"UserLogin": "sAMAccountName",
"PrimaryOrganisationID": "department",
"OrganisationIDs": [
"department",
"SET:13"
],
"DynamicField_Source": "SET:Backend002-AD"
},
"GroupDNBasedRoleSync": {
"dc=serviceteam,dc=example,dc=com": {
"News Manager": 1,
"Ticket Agent": 1,
"Asset Maintainer": 1,
"Customer Manager": 1,
"FAQ Editor": 1
}
},
"AttributeBasedRoleSync": {
"sAMAccountName": {
"m.mustermann": {
"Superuser": 1
}
}
}
}
}
]
},
{
"Enabled": 1,
"Module": "Kernel::System::Auth::DB",
"Name": "Local Database",
"Config": {
"CryptType": "sha2"
}
}
]Folgende Attribute können verwendet werden, um sich gegen ein LDAP/AD zu authentifizieren.
Die im Beispiel aufgeführten Attribute (Server, LDAP-Attribute usw.) müssen durch Ihre jeweiligen Werte ersetzt werden und Leerzeichen sowie Zeilenumbrüche müssen entfernt werden.
Bei LDAP-Abruf der Gruppe aus GroupDN erscheinen die Nutzerzuordnungen unter Attribut uid (vorm.: memberUid) oder member (Active Directory: member).
Wert (Beispiel): uid | member
Permanenter Filter der für LDAP/AD-Anfragen angewandt wird - siehe https://tools.ietf.org/html/rfc2254.
Hier können auch Gruppenfilter eingetragen werden.
Weitere Beispiele finden Sie unter: http://www.selfadsi.de/ldap-filter.htm.
Wert (Beispiel) | Beispiele |
|---|---|
"(&(mail=*)(sn=*))" |
|
Datenabgleich (Sync).
Zuordnung von Berechtigungsrollen in KIX basierend auf Pattermatching in AD-/LDAP-Attributen.
Ebene 1: Schlüssel definiert das AD-/LDAP-Attribut.
Ebene 2: Schlüssel definiert das zu machende Muster
Ebene 3: Schlüssel benennt die KIX-Berechtigungsrolle und der Zuordnung der Rolle mittels Wert "1"
Hinweis: das Setzen einer "0" führt zum expliziten Entzug der Berechtigungsrolle
Wert (Beispiel)
"AttributeBasedRoleSync":{
"sAMAccountName": {
"m.mustermann": {
"Superuser": 1
}
}
}Alternativer, eindeutiger Kenner zur Anmeldung.
Ermöglicht die Verwendung eines anderen, eindeutigen Kontaktattributs als der im System am Nutzer hinterlegte UserLogin (gilt nur für die Authentifizierung über AD).
Wird bspw. mail angegeben, so wird die in der Nutzerverwaltung hinterlegte E-Mail-Adresse des Nutzer zur Authentifizierung akzeptiert.
Ist dieses Attribut nicht gesetzt oder sollte diese Authentifizierung fehlschlagen, dann wird die unter UID gesetzte Einstellung verwendet (Fallback).
Wert (Beispiel): <empty> | mail | userPrincipalName | principalName | ...
Tipp
Werden numerische, schlecht zu merkende Nutzerkenner verwendet, kann der Nutzer sich immer mit seiner aktuellen Mailadresse anwenden.
Sollte sich diese ändern (aber der Nutzername beibehalten werden) kann dennoch eine Anmeldung erfolgen.
Einstiegspunkt in die Verzeichnisstruktur.
Wert (Beispiel): dc=example,dc=com
Datenabgleich (Sync).
Abgleich der Kontaktattribute eines Nutzers bei erfolgreicher Authentifizierung.
Die Angaben für das Mapping erfolgen als Schlüssel-Wert-Paar: KIXAttributName : LDAPAttributName.
Der einem Nutzerkonto zugeordnete Kontakteintrag wird erstellt bzw. aktualisiert. Die Angabe folgender Attribute ist dazu mindestens erforderlich:
Email
Firstname
Lastname
UserLogin
Achtung
Sind diese Angaben im LDAP-/AD-Eintrag nicht gesetzt, kann bei Nichtvorhandensein kein Kontakt und damit auch kein Nutzereintrag erzeugt werden.
Die Nutzung des Systems für (noch nicht) manuell oder anderweitig erfasste Kontakte und Nutzer ist dann NICHT möglich.
Wert (Beispiel)
"ContactUserSync": {
"Email": "mail",
"Email1": "SET:mail@example.com",
"Email3": "mail",
"Email5": "automatedmail",
"Title": "title",
"Firstname": "givenname",
"Lastname": "sn",
"Street": "streetAddress",
"City": "l",
"Zip": "postalCode",
"Phone": "telephoneNumber",
"Mobile": "mobile",
"Fax": "facsimileTelephoneNumber",
"UserLogin": "sAMAccountName",
"PrimaryOrganisationID": "SET:123",
"OrganisationIDs": [
"department",
"SET:13"
],
"FallbackUnknownOrgID": "SET:123",
"ImgThumbNail": "TOBASE64:LDAPAttributeName",
"DynamicField_Source": "SET:ActiveDirectory1",
"DynamicField_XYZ": "department",
"DynamicField_ZIPCity":"CONCAT: postalCode}-{l}-DE"
}Gruppe der ein Eintrag angehören muss, um sich authentifizieren zu können.
Wert (Beispiel) cn=kixallow,ou=posixGroups,dc=example,dc=com
Datenabgleich (Sync).
Zuordnung von Berechtigungsrollen in KIX basierend auf Zugehörigkeit zu Gruppen im AD/LDAP.
Ebene 1: Schlüssel definiert die AD-/LDAP-Gruppe
Ebene 2: Schlüssel benennt die KIX-Berechtigungsrolle und der Zuordnung der Rolle mittels Wert "1"
Hinweis: das Setzen einer "0" führt zum expliziten Entzug der Berechtigungsrolle
Wert (Beispiel) | Hinweise |
|---|---|
"GroupDNBasedRoleSync": {
"dc=serviceteam,dc=example,dc=com": {
"Ticket Agent": 1,
"Asset Maintainer": 1,
"Customer Manager": 1,
"FAQ Editor": 1
}
} | Die Basisrollen "Agent User" und "Customer" werden ausschließlich und indirekt über die Zuordnung des Nutzungskontextes (UsageContext via IsAgent/IsCustomer) vergeben. Um inkonsistentes Verhalten zu vermeiden, sollten diese Rollen nicht in expliziten Zuordnungen wie in GroupDNBasedRoleSync vergeben werden - es sei denn, in der Konfiguration wird auf die Angabe des Parameters GroupDNBasedUsageContextSync vollständig verzichtet. Es kann dann Einträge im Log geben, dass die Rolle nicht zugeteilt wurde. Dies ist einer versuchten doppelten Zuteilung begründet und kann ignoriert werden ("Known Error"). |
Datenabgleich (Sync).
Automatisches Setzen des Nutzungskontextes aus der LDAP/AD-Gruppenzugehörigkeit.
Die Angabe eines "0"-Wertes entzieht den Nutzungskontext ungeachtet weiterer ggf. bestehender Zuordnungen durch andere Gruppenzugehörigkeiten.
Die Angabe einer übergeordneten LDAP-Gruppe überschreibt Angaben einer untergeordneten Gruppe.
Wert (Beispiel) | Hinweise |
|---|---|
"GroupDNBasedUsageContextSync": {
"cn=agentsonly,dc=example,dc=com":{
"IsAgent": 1,
"IsCustomer": 0
},
"cn=agents,dc=example,dc=com": {
"IsAgent": 1
},
"cn=customer,dc=example,dc=com": {
"IsCustomer": 1
}
} |
|
Hostname, IP-Adresse oder URI eines LDAP/AD-Servers.
Wert (Beispiel): ldap.meinUnternehmen.de
Alternativ kann auch eine Liste von Host oder URIs angegeben werden:["ldaps://dc1.example.com", "ldaps://dc1.example.com"]
Wenn LDAP über SSL abgefragt werden soll, geben sie als Hostnamen "ldaps://<eigentliche Hostname>" an.
Legt die LDAP-Authentifizierung fest.
Wert (Beispiel): Kernel::System::Auth::LDAP
LDAP/AD-Parameter für das Authentifizierungsmodul.
Wert (Beispiel) | Hinweise |
|---|---|
{
"port": "389",
"timeout": "10",
"async": "0",
"version": "3"
} | Für LDAPS (LDAP via SSL) sollte Die Angabe von "scheme": "ldaps" ist damit nicht erforderlich. |
User DN des Nutzers, über den sich KIX mit dem LDAP Server verbindet, um die Suche durchzuführen.
Wert (Beispiel): cn=kix,ou=user,dc=example,dc=com
Passwort des Nutzers, über das sich KIX mit dem LDAP Server verbindet, um die Suche durchzuführen.
Wert (Beispiel): some_password
Name des LDAP-Attributes, welches zur eindeutigen Identifikation eines LDAP-Eintrages verwendet wird (Nutzerlogin).
Für gewöhnlich UID für LDAP und sAMAccountName für Active Directories.
Sollte kein UserLogin in der Sync Map angegeben werden, wird auf Basis der UID in der KIX Datenbank ein Nutzerlogin erstellt und auf invalid gesetzt. UID und UserLogin können ohne Probleme auf das selbe Attribut zeigen.
Die UID dient als Fallback, wenn keine andere Authentifizierung möglich ist.
Wert (Beispiel): UID | sAMAccountName
Definiert, welche Authentifizierungs-Konfiguration für welchen Nutzungskontext genutzt wird (optionale Angabe).
Legen Sie den UsageContext fest, wenn ein Nutzer sowohl Kunde als auch Agent ist und für beide Nutzungskontexte verschiedene Authentifizierungsmethoden genutzt werden (Agent: KIX-DB, SSP: LDAP). Sie können damit den Zugriff des Nutzers auf die Portale steuern:
Nutzungskontext "Customer": Der Nutzer kann sich nicht im Agentenportal anmelden
Nutzungskontext "Agent": Der Nutzer kann sich nicht im Self Service Portal anmelden
keine Angabe des Nutzungskontextes: Der Nutzer kann sich in beiden Portalen anmelden.
Wert (Beispiel) | Hinweise |
|---|---|
{
"Config": {...},
"Enabled": 1,
"Module": "Kernel::System::Auth::LDAP",
"Name": "openLDAP|nur Agent",
"UsageContext": "Agent",
"Sync": [...]
} | Die Angabe hat keine Auswirkung auf die zugeordneten Nutzungskontexte in der Synchronisation. Sie beschränkt nur die Verwendung des Authentifizierungsbackends. |
Für LDAP-posixGroups UID, für Nicht-LDAP-posixGroups with full DN (Active Directory: DN)
Wert (Beispiel) UID | DN
Wird an jede Login-Eingabe bei Authentifizierung angehangen und an den LDAP-/AD-Server gesendet.
Zum Beispiel: Nutzer gibt ein "m.power", an AD-Server wird "m.power@ValueInUserSuffix" gesendet.
Wert (Beispiel): <empty> | @somedomain.tld
Achtung
Das Authentifizierungsbackend ValidUser ist initial inaktiv.
Verwenden Sie dies nur in begrenzten Ausnahmefällen für Nutzerkonten mit beschränkten Berechtigungen!
Begrenzen Sie den Zugriff auf tatsächlich notwendige Nutzer und IP-Adressen, um keine unbeabsichtigte Sicherheitslücke zu erzeugen!
Mit Hilfe des Authentifizierungsbackends ValidUser kann der Zugriff allein auf Basis des Anmeldenamens und der aufrufenden IP-Adresse gewährt werden.
Praktische Anwendungsszenarien sind bspw.:
Ein Self Service Portal (KIX Pro), das nur eine Erstellung von Meldungen zulässt, aber keine offenen Vorgänge anzeigt.
Clients, die mit der gleichen IP-Adresse von der gleichen Person benutzt werden und keinen oder nur sehr geringen Sicherheitsanforderungen genügen müssen.
Voraussetzungen sind:
dass ein gültiges Nutzerkonto verwendet wird
der Aufruf den definierten Bedingungen (Login-Name/n und Client-IP-Adresse) genügt.
ValidUser gilt als eine Möglichkeit des Single Sign On (SSO). SSO für das Agenten- und für das Self Service Portal muss explizit aktiviert werden.
Dazu müssen Sie die jeweiligen Konfigurationen in der environment-Datei Ihrer KIX On-Premises-Konfiguration aktivieren:
SSO_ENABLED = true SSO_ENABLED_SSP = true
Anschließend ist ein Neustart des Stacks erforderlich.
Folgende Attribute können für die automatische Anmeldung (ValidUser) verwendet werden:
Attribut | Wert | Beschreibung |
|---|---|---|
Module | Kernel::System::Auth::ValidUser | Automatische Anmeldung festlegen |
Enabled | 0 | 1 | De-/Aktiviert das Authentifizierungsbackend |
UsageContext | "Agent" | "Customer" | Definiert, welche Authentifizierungs-Konfiguration für welchen Nutzungskontext genutzt wird (optionale Angabe). Legen Sie den UsageContext fest, wenn ein Nutzer sowohl Kunde als auch Agent ist und für beide Nutzungskontexte verschiedene Authentifizierungsmethoden genutzt werden (Agent: KIX-DB, SSP: LDAP). Sie können damit den Zugriff des Nutzers auf die Portale steuern:
|
RelevantClientIPs | ".*" | Regulärer Ausdruck, dem die IP des Clients entsprechen muss. Es werden auch "X-Forwarded-For"-Header zur Einschränkung auf bestimmte Client-IP-Adressen ausgewertet. |
RelevantUsers | ".*" | Regulärer Ausdruck, dem der Nutzername entsprechen muss. |
Wichtig
Statt des URL-Parameters "username" kann auch ein HTTP-Header "X-KIX-User" ausgewertet werden. Damit kann die Authentifizierung vorgeschalteten Proxy-Servern überlassen und eine Art Single Sign On abgebildet werden.
Achten Sie in diesem Fall darauf, dass der Header nicht von externen Requests übernommen wird, um eine nicht autorisierte Anmeldung zu unterbinden!
Im nachfolgenden Beispiel kann sich der Self Service Portal-Nutzer "mamu" ohne Eingabe eines Passworts direkt am am Self Service Portal anmelden, wenn er von den IP-Adressen "172.21.16.*" kommt. Er muss lediglich die URL zum Self Service Portal aufrufen, z. B.:
On-Premises:
http://your.kix-docker-host.org:20002/login?username=mamu&password=not_relevantKIX.Cloud:
https://your.agentenportal-ssp.kix.cloud/login?username=mamu&password=not_relevant
Ein Nutzer mit Login "mamu" und Zugriff auf das Self Service Portal muss dazu in der Nutzerverwaltung angelegt sein.
[
# ...other authentication backends...
{
"Name": "Valid User",
"Module": "Kernel::System::Auth::ValidUser",
"Enabled": 1,
"UsageContext": "Customer",
"Config": {
"RelevantClientIPs": [
"^172.21.16.\d\d?\d?$"
],
"RelevantUsers": [
"(mamu | login\d+)"
]
}
},
# ...other authentication backends...
]