KIX - Forum
Community => Anleitungen => Thema gestartet von: Fabian Seibt am 05.04.2018 14:14:40
Die folgenden Beiträge sollen dabei unterstützen, SSO für KIX einzurichten.
Es werden unterschiedliche Varianten aufgezeigt und es ist an manchen Stellen absichtlich allgemein gehalten, damit es jedem so gut wie möglich hilft.
Unabhängig von der Authentifizierungsmethode müssen in den unterschiedlichen Browsern zusätzliche Konfigurationen vorgenommen werden.
Wie z.B.:
- im Internet-Exporer / Edge muss die jeweilige Seite als vertrauenswürdige Seite hinterlegt werden
- im Firefox müsste die aufzurufende Seite unter der Konfiguration "network.negotiate-auth.trusted-uris" eingetragen werden, welche man über die Eingabe von "about:config" als URL finden kann
- für Google Chrome muss eine Auth-Server-Whitelist angelegt werden
Variante 1: Kerberos Single-Sign-On (Debian-, Ubuntu-, CentOS- oder SLES-Server)
1. Installation von Kerberos:
- dazu benötigt man das Modul mod_auth_kerb und das Paket krb5-client
z.B. unter Ubuntu mit
apt-get install libapache2-mod-auth-kerb krb5-clients
Paketnamen können in jeweiligen Distributionen variieren!
1.1 Test ob Kerberos prinzipiell auf KIX Server funktioniert
kinit <Domänenbenutzer>@<DOMÄNE>
- auf Konsole des KIX Servers ausführen - Passwort des Benutzers wird abgefragt
- wenn es zu keiner Ausgabe kommt, war der Test erfolgreich
2. Keytab für Apache erstellen:
- setzt sich zusammen aus dem Protokoll (HTTP), dem FQDN des KIX Servers und dem Realm der Domäne
- außerdem wird ein Domänenbenutzer benötigt, an welchen die keytab gebunden wird
- auf dem Domain Controller über Kommandozeile mittels dem Tool ktpass die keytab im Support Tools Verzeichnis erstellen (in der Regel C:\Programme\Support Tools)
- erstellte keytab ins Apache Verzeichnis des KIX Severs kopieren (/etc/apache2/keytabs)
Beispiel für Erstellung der Keytab:
C:>ktpass
princ HTTP/<FQDN KIX-Server>@<DOMÄNE>
mapuser <Domänenbenutzer>@<DOMÄNE>
crypto RC4-HMAC-NT
ptype KRB5_NT_PRINCIPAL
pass <Passwort Domänenbenutzer>
out c:\temp\keytab
3. Kerberos Konfiguration:
- erfolgt auf dem KIX Server unter /etc/krb5.conf
- im Abschnitt [libdefaults] muss das Domain-Realm groß geschrieben werden
- im Abschnitt [realms] definiert man die einzelnen Realms der Domänen mit ihren Domaincontrollern
z.B. (vereinfacht)
[libdefaults]
default_realm = DOMAIN1.NET
[realms]
DOMAIN1.NET = {
kdc = dc1.domain1.net
kdc = dc2.domain1.net
admin_server = dc1.domain1.net
}
[domain_realm]
.domain1.net = DOMAIN1.NET
domain1.net = DOMAIN1.NET
4. Apache Konfiguration:
Folgende Eintrage sollten in /etc/apache2/sites-available/zzz_kerb.conf hinzugefügt werden:
LoadModule auth_kerb_module /usr/lib/apache2/modules/mod_auth_kerb.so
<Directory "/opt/kix/bin/cgi-bin/">
AllowOverride None
AuthType Kerberos
AuthName "KIX"
Krb5Keytab /etc/apache2/keytabs/kixserver.keytab
KrbAuthRealms DOMAIN1.NET DOMAIN2.NET
KrbMethodNegotiate on
KrbSaveCredentials off
KrbMethodK5Passwd on
Require valid-user
Order allow,deny
Allow from all
</Directory>
- mit LoadModule auth_kerb_module sorgt man dafür, dass das Modul mod_auth_kerb gestartet wird
- die auf dem Domaincontroller erstellte keytab gibt man unter Krb5Keytab an
- unter KrbAuthRealms gibt man die Domain-Realms an
Anschließend muss noch die Apache-Konfiguration aktiviert werden:
4.1 Keytab vorbereiten:
kinit -k -t <Ordner-Keytab>/KeyTab HTTP/<FQDN KIX Server>
- wenn es zu keiner Ausgabe kommt, war der Test erfolgreich
5. KIX Konfiguration:
Folgende Einträge müssen in der <KIX-Home>/Kernel/Config.pm gemacht werden:
für die Authentifizierung der Agenten per SSO ist folgender Eintrag zuständig:
$Self->{'AuthModule'} = 'Kernel::System::Auth::HTTPBasicAuth';
$Self->{'AuthModule::HTTPBasicAuth::ReplaceRegExp'} ='@DOMAIN1.NET';
für die Authentifizierung der Customer sieht der Eintrag wie folgt aus:
$Self->{'Customer::AuthModule'} = 'Kernel::System::CustomerAuth::HTTPBasicAuth';
$Self->{'Customer::AuthModule::HTTPBasicAuth::ReplaceRegExp'} ='@DOMAIN1.NET';
Um die Authentifizierung Agenten mehrerer Domänen zu ermöglichen, muss für jede Domäne ein eigener Eintrag gemacht werden (gleiches gilt für die Customer Authentifizierung)
$Self->{'AuthModule'} = 'Kernel::System::Auth::HTTPBasicAuth';
$Self->{'AuthModule::HTTPBasicAuth::ReplaceRegExp'} ='@DOMAIN1.NET';
...
Variante 2: NTLM-Authentifizierung gegen Windows-Domäne (Debian/Ubuntu)
Anleitung wird benötigt, wenn Sie in einer Windows Domain arbeiten und KIX auf einem Linux Web-Server läuft (Ziel ist Singe Sign On (SSO) über Windows-Anmeldung)
1.a) Notwendige Konfiguration Firefox:
Mittels "about:config" müssen in den Schlüssel "network.automatic-ntlm-auth.trusted-uris" Komma-separiert die URLs der Webseite für die NTLM-Authentifizierung eingetragen werden.
1.b) Notwendige Konfiguration IE:
- IE sendet nur SSO-Informationen, wenn der Webserver in der Sicheren Zone/Intranet-Zone konfiguriert ist
- Für IE >= 6.0 ist zudem noch die Option "Enable Integrated Windows Authentication" zu aktivieren (Advanced Options/Security Group)
2. Notwendige Komponenten auf Web-Server für Apache:
- winbind
- Perl-Modul: Apache::AuthenNTLM (bei Ubuntu und Debian z.B. libapache2-authenntlm-perl)
3. Konfiguration /etc/apache2/sites-available/kix.conf:
Unten stehender Block muss in die kix.conf eingefügt und wie folgt ergänzt werden:
- DOMAIN:: ADS-Domain-Name in Großbuchstaben
- ADSERVER:: Hostname des AD-Server PDC (Hostname muss auflösbar sein)
- ntlmdebug kann nach erfolgreichem Test entfernt werden (Logs unter /var/log/apache2/...)
<Directory /pfad/zum/verzeichnis>
Options Indexes -FollowSymLinks -ExecCGI
IndexOptions FancyIndexing FoldersFirst NameWidth=*
AllowOverride None
Order Deny,Allow
Deny from all
Allow From xxx.xxx.xxx.xxx/255.255.255.0
# NTLM v1 Basic Auth against Windows Domain
PerlAuthenHandler Apache2::AuthenNTLM
AuthType ntlm,basic
AuthName NTLMTest
require valid-user
PerlAddVar ntdomain "DOMAIN ADSERVER"
PerlSetVar defaultdomain DOMAIN
PerlSetVar splitdomainprefix 1
PerlSetVar ntlmdebug 3
</Directory>
4. KIX Konfiguration:
Folgende Einträge müssen in der <KIX-Home>/Kernel/Config.pm gemacht werden:
für die Authentifizierung der Agenten per SSO ist folgender Eintrag zuständig:
$Self->{'AuthModule'} = 'Kernel::System::Auth::HTTPBasicAuth';
$Self->{'AuthModule::HTTPBasicAuth::ReplaceRegExp'} ='@DOMAIN';
für die Authentifizierung der Customer sieht der Eintrag wie folgt aus:
$Self->{'Customer::AuthModule'} = 'Kernel::System::CustomerAuth::HTTPBasicAuth';
$Self->{'Customer::AuthModule::HTTPBasicAuth::ReplaceRegExp'} ='@DOMAIN';
Um die Authentifizierung Agenten mehrerer Domänen zu ermöglichen, muss für jede Domäne ein eigener Eintrag gemacht werden (gleiches gilt für die Customer Authentifizierung)
$Self->{'AuthModule'} = 'Kernel::System::Auth::HTTPBasicAuth';
$Self->{'AuthModule::HTTPBasicAuth::ReplaceRegExp'} ='@DOMAIN1';
...
Variante 3: SSPI-Authentifizierung gegen Windows-Domäne (Windows Server)
Diese Anleitung wird benötigt, wenn Sie in einer Windows Domain arbeiten und KIX ebenfalls auf einem Windows Server läuft.
Die Windows Version von KIX nutzt den Plack Web-Server. Dieser unterstützt kein Single Sign On, daher muss in diesem Fall ein Apache Web-Server vorgeschaltet werden, welcher die Anmeldung vornimmt und an den Plack Server übergibt.
1. Installieren von ,,mod_auth_sspi"
2. Erweiterung der Apache Konfiguration unter /etc/apache2/sites-available/kix.conf:
Folgende Einträge müssen hinzugefügt und entsprechend der Pfade angepasst werden:
LoadModule sspi_auth_module modules/mod_auth_sspi.so
<Directory /PFAD/ZUM/VERZEICHNIS>
SSPIAuth On
SSPIAuthoritative On
SSPIDomain pdc.example.com
SSPIUsernameCase lower
SSPIOfferBasic On
Require valid-user
Options +ExecCGI -Includes
AllowOverride None
Order allow,deny
Allow from all
</Directory>
3. KIX Konfiguration:
Folgende Einträge müssen in der <KIX-Home>/Kernel/Config.pm ergänzt werden:
$Self->{'AuthModule'} = 'Kernel::System::Auth::HTTPBasicAuth';
$Self->{'AuthModule::HTTPBasicAuth::Replace'} = 'mydomain\\';