Konzept Single-Sign-On

Transcription

Konzeptpapier
TYPO3 Single Sign-On mit Kerberos
und LDAP unter Apache / IIS
VERSION 1.0
Herzlichen Dank für Ihr Interesse an Lösungen und Dienstleistungen!
Unser Kontakt für Consulting-Anfragen
internezzo ag, Grundstrasse 14, 6343 Rotkreuz
Kontakt
Funktion
Telefon / Mail
Marcel Burkhalter
Projektleiter TYPO3
+41 41 748 02 41
[email protected]
Copyright © internezzo ag
Inhaltliche Änderungen vorbehalten. Alle Rechte an dieser Dokumentation, insbesondere das Recht
der Vervielfältigung und Verbreitung, bleiben vorbehalten. Kein Teil der Dokumentation darf in
irgendeiner Form ohne vorherige schriftliche Zustimmung der internezzo ag reproduziert werden.
Hinweis: Das Konzeptpapier hat den Stand von April 2008. Die Grundlagen sind noch
dieselben, diverse Details im Konzept sind aber nicht mehr up-to-date.
© internezzo ag 2013
12. Juni 2013 / Seite 2 von 24
Inhaltsverzeichnis
1 Vorwort
5
2 Beschreibung der Lösung
6
2.1 Ablauf für den Benutzer .......................................................................................................... 6
2.2 Technischer Ablauf ................................................................................................................. 6
2.2.1 Apache ............................................................................................................................ 6
2.2.2 Internet Information Services ............................................................................................ 6
3 Voraussetzungen Server & Client
7
3.1 Webserver .............................................................................................................................. 7
3.1.1 Linux ............................................................................................................................... 7
3.1.2 Windows .......................................................................................................................... 7
3.2 Active Directory Server ............................................................................................................ 7
3.3 Firewall / Ports ....................................................................................................................... 7
3.4 Allgemein .............................................................................................................................. 7
3.5 Browser ................................................................................................................................. 8
3.5.1 Firefox ............................................................................................................................. 8
3.5.2 Internet Explorer............................................................................................................... 8
4 Umsetzung / Vorgehen
9
4.1 Konfiguration Active Directory ................................................................................................. 9
4.1.1 Benutzer für Kerberos (nur Apache) ................................................................................... 9
4.1.2 AD Kerberos Benutzers als Keytab exportieren (nur Apache) ................................................ 9
4.1.3 Benutzer für LDAP ............................................................................................................ 9
4.1.4 Active Directory Attribut dSHeuristics ................................................................................ 9
4.2 Konfiguration Webserver ....................................................................................................... 11
4.2.1 Apache .......................................................................................................................... 11
4.2.1.1 Kerberos-Schutz via .htaccess ................................................................................... 11
4.2.1.2 Kerberos-Schutz via httpd.conf .................................................................................. 11
4.2.2 Internet Information Services .......................................................................................... 12
4.3 Konfiguration TYPO3 ............................................................................................................ 13
4.3.1 Extensions ..................................................................................................................... 13
4.3.1.1 ldap_auth ................................................................................................................ 13
4.3.1.2 ldap_server .............................................................................................................. 15
5 Fehlersuche & Tests
19
5.1 Authentifikation.................................................................................................................... 19
5.1.1 Apache (Kerberos) .......................................................................................................... 19
5.1.2 Kontrolle des Benutzernamens in der PHP $_SERVER Variable .......................................... 19
5.2 LDAP ................................................................................................................................... 20
5.2.1 ldapsearch Beispielaufrufe .............................................................................................. 20
6 Glossar und Abkürzungen
21
7 Links
23
7.1
7.2
Kerberos .............................................................................................................................. 23
LDAP ................................................................................................................................... 23
8 Tools
8.1
8.2
8.3
23
Kerberos .............................................................................................................................. 23
LDAP ................................................................................................................................... 23
Diverses ............................................................................................................................... 23
9 Konditionen Support
9.1
9.2
9.3
9.4
9.5
24
Consulting............................................................................................................................ 24
TYPO3 Extensions ................................................................................................................ 24
Spesenansätze ..................................................................................................................... 24
Zahlungsbedingungen ........................................................................................................... 24
Allgemeines ......................................................................................................................... 24
1 Vorwort
Da ein Intranet die üblichste Anwendung (wenn auch nicht einzige) für eine SSO Lösung sein
dürfte, wird der Einfachheit halber in diesem Konzept die Bezeichnung "Intranet" allgemein
für die mit SSO zu schützende Seite verwendet.
Das vorliegende Konzept beschreibt die SSO Implementation unter Apache und Internet
Information Services. Da viele Kapitel für Apache und IIS gleichermassen relevant sind, wurde
auf eine Zweiteilung des Dokuments verzichtet.
Dort, wo es Unterschiede gibt, werden diese in separaten Unterkapiteln für Apache und IIS
behandelt. Alle Kapitel ohne diese Unterscheidung gelten für Apache und IIS.
Dieses Konzept ist keine detaillierte Schritt-für-Schritt Anleitung.
Gute Kenntnisse in den Bereichen Active Directory, LDAP, TYPO3 und ein technischer
Background werden vorausgesetzt.
2 Beschreibung der Lösung
2.1
Ablauf für den Benutzer
 Der Benutzer meldet sich mit seinem Benutzernamen und Passwort an der WindowsDomäne an
 Er startet den Internet Explorer oder Firefox und öffnet die Intranetseite
 Der Benutzer sieht nur Seiten und Inhaltselemente, die seinen Berechtigungen
entsprechen
2.2
Technischer Ablauf
2.2.1 Apache
1. Der Benutzer meldet sich an der Windows-Domäne an. Ab diesem Zeitpunkt ist er
gegenüber dem Active Directory (AD) authentifiziert.
2. Der Benutzer ruft die Intranet Seite auf, welche mittels .htaccess File (AuthType
Kerberos) geschützt ist.
3. Der Server meldet: 401 Authorization Required.
4. Der Client-Browser fordert beim AD ein Service Ticket für "HTTP/intranet.tld" an.
5. Das AD stellt ein Kerberos Service Ticket für den Benutzer aus.
6. Der Browser ruft die ursprüngliche Seite erneut auf und überträgt das Kerberos Ticket via
SPNEGO in den HTTP Headers.
7. Der Webserver kann das Ticket anhand seiner lokalen Keytab (exportiert aus dem AD)
authentifizieren, ohne mit dem AD kommunizieren zu müssen.
8. Das Apache Modul "mod_auth_kerb" speichert den AD Benutzernamen in der Form
"username@REALM" in der Variabel: $_SERVER['REMOTE_USER']
9. Der Webserver gibt den Zugriff für den Benutzer frei.
10. Die TYPO3 Extension "ldap_auth" setzt den Benutzer auf "authorisiert" und gibt den
Benutzernamen (ohne @REALM) weiter an "ldap_sync".
11. Die LDAP Sync Extension sucht den Benutzer via LDAP im AD. Falls der Benutzer
gefunden wird, wird automatisch ein TYPO3 Frontend Benutzer angelegt bzw.
aktualisiert, falls dieser schon vorhanden ist. Bei diesem Sync-Vorgang können diverse
Felder aus dem AD wie Vorname, Telefon, E-Mail etc. in den FE Benutzer übernommen
werden. Die Benutzergruppen aus dem AD werden ebenfalls synchronisiert, was den
Zugriff des Benutzers auf Seiten und Inhaltselemente im TYPO3 steuert.
12. Der synchronisierte FE Benutzer wird automatisch eingeloggt.
13. Der Single Sign-On Vorgang ist abgeschlossen. Der Benutzer sieht beim Surfen im
Intranet nur Seiten/Inhaltselemente, die für alle sichtbar sind und zusätzlich geschützte
Elemente, auf die er Zugriff hat.
2.2.2 Internet Information Services
Der Ablauf mit IIS ist weitgehend identisch mit dem Ablauf unter Apache. Der grösste
Unterschied liegt zwischen Punkt 4 und 8. Hier findet mit IIS eine NTLM anstatt einer
Kerberos Authentifizierung statt.
Das Ergebnis ist dasselbe. Der AD Benutzername ist anschliessend in einer PHP Variabel
gespeichert und kann zur LDAP Synchronisation verwendet werden.
3 Voraussetzungen Server & Client
3.1
Webserver
3.1.1 Linux
 Betriebssystem: Linux Derivat (wir empfehlen Fedora oder Red Hat Enterprise)
 Webserver: Apache mit Modul "mod_auth_kerb"
 PHP mit geladener LDAP Extension
 OpenLDAP (inkl. "openldap-clients") installiert für Shell-Tests mit dem Tool "ldapsearch"
3.1.2 Windows
 Betriebssystem: Windows 2003 Server
 Webserver: Internet Information Services (Version >= 6.x)
3.2
Active Directory Server
 Active Directory mit Attribut "dSHeuristics = 0000002"
Konfiguration siehe Kapitel 4.1.4
 Windows 2003 Server Support Tools (nicht SP1!) installiert
3.3
Firewall / Ports
 Der Webserver braucht mind. über den LDAP Port 389 Zugriff auf den Active Directory
Server
 Für Kerberos Passwort Abfragen (Benutzer ohne Kerberos Ticket) muss zusätzlich Port 88
offen sein. In diesem Fall ist HTTPS dringen zu empfehlen, da sonst AD Passwörter
unverschlüsselt übertragen werden!
3.4
Allgemein
 Kerberos ist zeitsensitiv. Alle involvierten Server und Clients sollten via NTP ihre
Systemzeit mit einer zuverlässigen Quelle synchronisieren (z.B. ntp.metas.ch)
 Kerberos ist sensibel in Bezug auf DNS. Die Intranet-Domain sollte von allen Servern und
Clients aus vorwärts und rückwärts auflösen (rückwärts nur ein Domainname!)
3.5
3.5.1
Browser
Firefox
 In den Optionen (URL "about:config" in der Adresszeile) muss die Intranet URL bei den
folgenden beiden Werten hinzugefügt werden:
network.negotiate-auth.trusted-uris
network.negotiate-auth.delegation-uris
3.5.2
Internet Explorer
 Die Intranet URL muss in der Sicherheitszone "Lokales Intranet" hinzugefügt werden. Am
einfachsten wird dies auf den Clients via Logonscript für alle Domänen-Benutzer gesetzt
 In der Sicherheitsstufe der Zone "Lokales Intranet" muss die Option "Automatisches
Anmelden nur in der Intranetzone" gesetzt sein (normalerweise ist dies schon so)
 In den erweiterten Internetoptionen muss die Option "Integrierte WindowsAuthentifizierung aktivieren" gesetzt sein (normalerweise ist dies schon so)
4 Umsetzung / Vorgehen
4.1
Konfiguration Active Directory
4.1.1 Benutzer für Kerberos (nur Apache)
Für Kerberos Authentifizierungen mit Apache muss im AD ein Benutzer angelegt werden. Von
diesem Benutzer wird im nächsten Kapitel eine "keytab" Datei exportiert. Anhand dieser Datei
ist das Apache Modul "mod_auth_kerb" später in der Lage, das Kerberos Ticket des Benutzers
offline zu validieren.
4.1.2 AD Kerberos Benutzers als Keytab exportieren (nur Apache)
Beispielaufruf von ktpass.exe zum Export des Keytab Files:
"C:\Program Files\Support Tools\ktpass.exe" -princ HTTP/intranet.tld@REALM -mapuser
DOMAIN\KERB -crypto DES-CBC-MD5 -ptype KRB5_NT_PRINCIPAL -mapop set +desonly -pass
einPasswort -out C:\temp\intranet.keytab
Hinweise:
 ktpass.exe ist Bestandteil der "Windows 2003 Server Support Tools" (siehe Kapitel 3.2)
 Der Kerberos Benutzername in diesem Beispiel lautet "KERB"
 Die Bezeichnung des Service Principals "HTTP/intranet.tld@REALM" muss absolut korrekt
sein. Um dies sicherzustellen, kann man die Kerberos Ticket Anforderung auf einem Client
mittels Wireshark (siehe Kapitel 5.1.1) aufzeichnen und die Bezeichnungen überprüfen.
 Die exportierte Datei "intranet.keytab" muss auf den Webserver kopiert und der absolute
Pfad im .htaccess File definiert werden (siehe Kapitel 4.2.1.1)
4.1.3 Benutzer für LDAP
Für die LDAP Abfragen aus TYPO3 sollte ein separater Benutzer im AD angelegt werden. Der
Benutzer benötigt keine speziellen Berechtigungen.
Benutzername und Passwort werden später im "LDAP server" Datensatz im TYPO3 eingetragen
(siehe Kapitel 4.3.1.2).
4.1.4 Active Directory Attribut dSHeuristics
Gemäss Microsoft braucht es das Attribut "dSHeuristics = 0000002", damit anonyme LDAP
Abfragen beantwortet werden. Die LDAP Abfragen aus TYPO3 erfolgen jedoch mit
Benutzernamen und Passwort, weshalb es dieses Attribut eigentlich nicht brauchen sollte.
Unsere Erfahrung hat jedoch gezeigt, dass ohne dieses Attribut keine LDAP-Suche über das
ganze AD bzw. keine LDAP Suchfilter mit mehr als 2 AND Verknüpfungen möglich sind.
Um die LDAP Synchronisation in TYPO3 intelligent zu filtern, sind jedoch mehr als 2 AND
Verknüpfungen nötig, was das Setzen dieses Attributs erforderlich macht.
Da dieses Verhalten vermutlich ein Bug ist, kann es sein, dass dies inzwischen durch
Microsoft behoben wurde. Wir empfehlen daher via "ldapsearch" (siehe Kapitel 5.2) eine
Testabfrage mit mehr als 2 AND Verknüpfungen abzusetzen.
Falls dies funktioniert, muss das Attribut nicht erstellt werden. Wenn eine leere LDAP Antwort
zurückgeliefert wird, muss das Attribut gemäss folgender Anleitung gesetzt werden:
Attribut erstellen:
1. ldp.exe starten (Start - Ausführen - ldp - OK)
2. Connection - New (Ctrl +N)
3. Bind (Ctrl + B) - User mit AD Administrator-Rechten verwenden - OK
4. Browse - Modify
5. Dn: CN=Directory Service,CN=Windows
NT,CN=Services,CN=Configuration,DC=domain,DC=tld
Attribute: dSHeuristics
Values: 0000002 (inkl. führender Nullen!)
Operation: Replace
6. <Enter> Button klicken
7. <Run> Button klicken
Attribut kontrollieren:
1. Start - Ausführen - Adsiedit.msc
2. Navigieren zu: Dn: CN=Directory Service,CN=Windows
NT,CN=Services,CN=Configuration,DC=domain,DC=tld
3. Kontextmenü - Eigenschaften
4. Attribut sollte mit Wert "0000002" in der Liste erscheinen (siehe Screenshot unten)
Abbildung 1: Eigenschaften auf dem Ast "Directory Service" (Adsiedit.msc)
Weitere Informationen von Microsoft:
http://support.microsoft.com/?scid=kb%3Ben-us%3B326690&x=20&y=14
12. Juni 2013 / Seite 10 von 24
4.2
4.2.1
Konfiguration Webserver
Apache
4.2.1.1 Kerberos-Schutz via .htaccess
Unter Apache muss das gesamte Intranet Kerberos geschützt werden. Dazu wird die .htaccess
Datei im Root des Webordners abgelegt.
Beispielkonfiguration:
# KERBEROS AUTHENTIFICATION
AuthType Kerberos
AuthName "Intranet Kerberos Login"
KrbAuthRealms INTRANET.TLD
KrbVerifyKDC on
KrbMethodNegotiate on
KrbMethodK5Passwd off
KrbServiceName HTTP
Krb5Keytab /etc/httpd/conf/intranet.keytab
require valid-user
Hinweise
Die Option "KrbMethodK5Passwd" muss nur auf "on" sein, falls man Benutzern ohne
Kerberos-Ticket (z.B. mit Mac Workstations) einen Login via Passwort ermöglichen will. Eine
Anmeldung via Kerberos ohne Tickert, aber dafür mit Passwort, ist kein Single Sign-On mehr
und erfordert weitergehende Konfigurationen, als in diesem Konzept beschrieben. Gemäss
unseren Erfahrungen funktioniert eine solche Anmeldung nicht zuverlässig.
4.2.1.2 Kerberos-Schutz via httpd.conf
Unter Angabe einer "Directory" Direktive, kann der Kerberos-Schutz auch im httpd.conf (oder
einer Apache-Konfigurationsdatei, welche im httpd.conf inkludiert wird) platziert werden:
<Directory "/var/www/vhosts/intranet.tld/httpdocs/">
--> Konfiguration wie bei .htaccess
</Directory>
12. Juni 2013 / Seite 11 von 24
4.2.2 Internet Information Services
Beim IIS genügt es, den anonymen Zugriff auf die Webseite zu deaktivieren. Sofern der
Browser korrekt konfiguriert ist (siehe Kapitel 3.5), erfolgt die Anmeldung automatisch.
12. Juni 2013 / Seite 12 von 24
4.3
Konfiguration TYPO3
4.3.1 Extensions
Die vier mitgelieferten LDAP Extensions müssen via Extension Manager in TYPO3 installiert
werden.
Die folgenden Kapitel behandeln die LDAP Extensions, welche konfiguriert oder angepasst
werden müssen. Die restlichen Extensions muss man nur installieren.
4.3.1.1 ldap_auth
Beispielkonfiguration von "ldap_auth" für Frontend Single Sign-On:
Abbildung 2: Optionen der Extension "ldap_auth" im TYPO3 Extension Manager
Die Methode, welche den Benutzernamen (gesetzt durch Kerberos oder NTLM) zur FE
Benutzer Synchronisation und Login weiterreicht, wird in der Datei
"/sv1/class.tx_ldapauth_sv1.php" implementiert. Der Aufruf der Methode wird im LDAP Server
Objekt konfiguriert (siehe Kapitel 4.3.1.2).
12. Juni 2013 / Seite 13 von 24
Beispiel-Implementation:
/**
* Function for SSO with Kerberos
*
* The apache module mod_auth_kerb saves the authenticated principal
(username@REALM) in
* the following variable: $_SERVER['REMOTE_USER']
* if the username is found via LDAP, the user record is updated and logged in
* --> Single Sign-On
*
* @param array $data: usually empty
* @param array $conf: usually empty
* @return array sets output for initUser()
*/
function authKerberos($data, $conf = '')
{
$user = array();
// get the authenticated principal
$remoteUser = $_SERVER['REMOTE_USER'];
// debug login without kerberos ticket
if (empty($remoteUser))
{
$remoteUser = t3lib_div::_GET('sso') ? t3lib_div::_GET('sso') .'@DEBUG' : '';
}
if (! empty($remoteUser))
{
// cut off the @REALM part and pass the username along for LDAP synchronisation
// and authorisation
$user['username'] = substr($remoteUser, 0, strrpos($remoteUser, '@'));
$user['authenticated'] = '1';
}
return $user;
}
Hinweise:
 Wenn man einen Zugang zum Intranet ohne Kerberos-Schutz (z.B. für einen IP-Bereich;
nicht Teil dieses Konzepts) einrichtet, kann man mit dem GET Parameter "sso" beliebige
User simulieren. Beispiel: http://intranet.tld/index.php?sso=username
 Unter IIS mit NTLM Authentifizierung wird der Benutzername im Format
"DOMAIN\username" abgelegt. Dementsprechend muss die fett gedruckte Zeile aus dem
Beispiel oben angepasst werden, damit nur der Benutzername weitergereicht wird
12. Juni 2013 / Seite 14 von 24
4.3.1.2 ldap_server
 Im Seitenbaum muss ein Sysfolder für die zu synchronisierenden FE Benutzer erstellt
werden.
 Dieser Sysfolder muss auf der Rootseite des Seitenbaums unter "Allgemeine
Datensatzsammlung" ausgewählt werden.
 Im FE Benutzer Sysfolder wird ein Datensatz vom Typ "LDAP server" erstellt. In diesem
Datensatz wird die gesamte LDAP Synchronisation konfiguriert.
Beispielkonfiguration:
Abbildung 3: TYPO3 Datensatz "LDAP server" mit Beispielkonfiguration
12. Juni 2013 / Seite 15 von 24
Beispielkonfiguration für Copy&Paste:
Filter for persons:
(&(objectClass=user)(objectClass=person)(!(objectClass=computer))(!(userAcc
ountControl:1.2.840.113556.1.4.803:=2))(sAMAccountName=###USERNAME###))
Configuration:
FEusers = LDAP_SYNC
FEusers {
enable = 1
table = fe_users
basedn = DC=domain,DC=tld
uniqueField = tx_ldapserver_dn
# LDAP synchronisierte Benutzer (von Hand im BE erstellte werden nicht verändert)
# die im Active Directory nicht mehr vorhanden sind werden versteckt (disabled=1)
handleNotFound = 1
handleNotFound {
markHidden = 1
hiddenField = disable
markDeleted = 0
deletedField = deleted
delete = 0
identField = username
}
# ID des Sysfolders in welchem die Benutzer synchronisiert werden
pid = xxx
# nur Benutzer-Accounts (keine Computer etc.) syncen, nur Accounts die nicht
deaktiviert
# sind
# 1.2.840.113556.1.4.803 = LDAP_MATCHING_RULE_BIT_AND
# 2 = ACCOUNTDISABLE (0x0002 Bit-Flag im userAccountControl Feld vom Microsoft
Active
# Directory)
filter =
(&(objectClass=user)(objectClass=person)(!(objectClass=computer))(logonCount>=1)(!(
userAccountControl:1.2.840.113556.1.4.803:=2)))
fields {
username = MAP_OBJECT
username.attribute = sAMAccountName
username.userFunc = tx_ldapserver->getSingleValue
email = MAP_OBJECT
email.attribute = mail
email.userFunc = tx_ldapserver->getSingleValue
name = MAP_OBJECT
name.attribute = cn
name.userFunc = tx_ldapserver->getSingleValue
12. Juni 2013 / Seite 16 von 24
title = MAP_OBJECT
title.attribute = mailNickname
title.userFunc = tx_ldapserver->getSingleValue
company = MAP_OBJECT
company.attribute = physicalDeliveryOfficeName
company.userFunc = tx_ldapserver->getSingleValue
disable = MAP_OBJECT
disable.special = setFalse
# HTML Mails as default (for dmail newsletter)
module_sys_dmail_html = MAP_OBJECT
module_sys_dmail_html.special = setTrue
tx_ldapserver_dn = MAP_OBJECT
tx_ldapserver_dn.special = DN
usergroup = MAP_OBJECT
usergroup {
attribute = memberOf
userFunc = tx_ldapserver->getFEGroups
userFunc.pid = 585
}
}
}
FEgroups < FEusers
FEgroups {
table = fe_groups
# Zentrale Ablage der Intranet Benutzergruppen im Active Directory
basedn = OU=Ablage Gruppen,DC=domain,DC=tld
handleNotFound = 0
filter = (&(objectClass=group))
fields >
fields {
title = MAP_OBJECT
title.attribute = cn
title.userFunc = tx_ldapserver->getSingleValue
tx_ldapserver_dn = MAP_OBJECT
tx_ldapserver_dn.special = DN
}
}
FEauth = LDAP_AUTH
FEauth {
enable = 1
table = fe_users
SSO = 1
SSO.10.userFunc = tx_ldapauth_sv1->authKerberos
12. Juni 2013 / Seite 17 von 24
sync < FEusers
}
Nach abgeschlossener Konfiguration kann mit dem neuen Web Backend Modul "LDAP Sync"
eine Synchronisation simuliert werden:
Abbildung 4: TYPO3 Backend Modul "LDAP Sync"
Abbildung 5: Beispiel-Ergebnis eines FE Benutzers nach simulierter LDAP Synchronisation
Anhand der Simulation kann kontrolliert werden, ob alle Felder korrekt mit den Daten aus
dem AD befüllt werden. Falls nötig, kann die Konfiguration noch angepasst und erneut
simuliert werden bis alles korrekt ist.
Anschliessend kann ein "Do Sync" durchgeführt werden, wobei dann die Benutzer und
Benutzergruppen effektiv im konfigurierten Sysfolder angelegt werden.
Weil beim ersten Sync Vorgang die Benutzergruppen erst angelegt wurden (die ID ist erst nach
dem Anlegen definiert), kann noch ein zweites Mal synchronisiert werden, damit die
Benutzergruppen-Zuordnungen bei den Benutzern korrekt gesetzt werden.
Diese manuellen Sync Vorgänge dienen vor allem zu Testzwecken. Im laufenden Betrieb
werden Benutzer bei jeder Anmeldung am Intranet automatisch synchronisiert.
12. Juni 2013 / Seite 18 von 24
5 Fehlersuche & Tests
5.1
Authentifikation
5.1.1 Apache (Kerberos)
Mit dem Tool "kerbtray.exe" (siehe Kapitel 8.1) können alle Kerberos Tickets, die der Client
PC erfolgreich angefordert hat, eingesehen werden.
Wird das Ticket für SSO nicht ausgestellt, kann die Kommunikation zwischen Server und
Client mit dem Network Protocol Analyzer "Wireshark" (siehe Kapitel 8.3) aufgezeichnet und
ausgewertet werden. Die Antwort des Servers auf eine abgelehnte Ticketanfrage enthält einen
Fehlertext, welcher mit "Wireshark" einfach ausgelesen werden kann:
Abbildung 6: Anzeige eines Kerberos Errors in "Wireshark"
5.1.2 Kontrolle des Benutzernamens in der PHP $_SERVER Variable
Wenn die Authentifikation für das Intranet ohne Passworteingabe funktioniert hat, kann mit
folgendem einfachen PHP Skript kontrolliert werden, ob der Benutzername korrekt in der PHP
Variable $_SERVER gespeichert wurde:
<?php
echo nl2br(print_r($_SERVER, TRUE));
?>
Die Anzeige im Browser sollte so aussehen (Beispiel mit IIS/NTLM, bei Apache/Kerberos wird
der Benutzername nicht mehrfach befüllt):
HTTP_AUTHORIZATION:Negotiate TlRMTVNTUAADAAAAGA...
[AUTH_PASSWORD] =>
[AUTH_TYPE] => Negotiate
[AUTH_USER] => DOMAIN\firstname.lastname
[REMOTE_USER] => DOMAIN\firstname.lastname
[LOGON_USER] => DOMAIN\firstname.lastname
[HTTP_AUTHORIZATION] => Negotiate TlRMTVNTUAADAAAAGA...
12. Juni 2013 / Seite 19 von 24
5.2
LDAP
Um den LDAP Zugriff vom Webserver aus auf das AD zu testen, kann man unter Linux den
Shellbefehl "ldapsearch" verwenden.
Für Windows gibt es das Freeware Tool "LDAP Browser" (siehe Kapitel 8.2).
5.2.1 ldapsearch Beispielaufrufe
Die wichtigsten "ldapsearch" Parameter:
-x
Simple Authentifikation (mit Passwort)
-w
Angabe des Passworts
-h
Angabe des Hosts oder IP
-D
AD Benutzer, der für die Abfrage verwendet wird (muss zu -w passen)
-b
Startpunkt im AD Baum für die Abfrage
Anzeigen aller Datensätze (Abfrage ohne Filter):
ldapsearch -x -w password -h 192.168.x.x -D "cn=username,ou=unit,dc=company" -b
"ou=unit,dc=company"
Anzeigen aller Benutzer (Filter: nur Personen, keine Computer):
'(&(objectClass=user)(objectClass=person)(!(objectClass=computer)))'
Anzeigen aller aktiven Benutzer (Filter: nur nicht deaktivierte Personen, keine Computer):
'(&(objectClass=user)(objectClass=person)(!(objectClass=computer))(!(userAccountCon
trol:1.2.840.113556.1.4.803:=2)))'
Anzeigen eines bestimmten Benutzers (Filter: nur Personen, definierter Accountname):
'(&(objectClass=user)(objectClass=person)(!(objectClass=computer))
(sAMAccountName=username))'
12. Juni 2013 / Seite 20 von 24
6 Glossar und Abkürzungen
Dieses Glossar soll nur einen groben Überblick bieten. Die meisten Begriffe sind bei
Wikipedia sehr gut beschrieben.
.htaccess File
Apache Konfigurationsdatei welche in beliebigen Verzeichnissen
platziert werden kann. Die Einstellungen vererben sich auf alle
Unterverzeichnisse. In einem .htaccess File kann z.B. ein
Passwortschutz eingerichtet werden.
Active Directory
Verzeichnisdienst von Microsoft mit welchem Benutzer, Computer und
ähnliches verwaltet werden.
AD
siehe Active Directory
HTTP Headers
Kopfdaten die beim Aufruf einer Webseite vor dem Inhalt übertragen
werden. HTTP Header können u.a. Cookiedaten oder auch
Informationen zur Authentifizierung enthalten.
IIS
siehe Internet Information Services
Internet Information
Services
Webserver von Microsoft (beinhaltet weitere Dienste wie FTP, POP3
etc.).
Kerberos
Netzwerk Authentifizierungsverfahren zur sicheren Authentifizierung in
ungesicherten TCP/IP Netzwerken.
Kerberos Ticket
Die Informationspakete, welche Kerberos zwischen Client und Server
zur Authentifizierung austauscht, werden Ticket genannt.
Keytab File
Wird aus dem AD exportiert und enthält die Schlüssel für einen Service
principal. Anhand des Keytab Files können Kerberos Tickets offline
authentifiziert werden.
LDAP
Lightweight Directory Access Protocol. Mit diesem Protokoll kann auf
das Active Directory zugegriffen werden.
NTLM
NT LAN Manager. Proprietäres Authentifizierungsschema von Microsoft.
Kann in einer TYPO3 Single Sign-On Lösung mit IIS als Alternative zu
Kerberos/Apache verwendet werden.
REALM
Administrationsbereich eines Kerberos-Servers. Typischerweise der
Domainname in Grossbuchstaben, z.B. INTRANET.TLD
Service principal
Bezeichnung zur eindeutigen Identifikation eines Kerberos Dienstes,
z.B.: HTTP/[email protected]
Service Ticket
siehe Kerberos Ticket
12. Juni 2013 / Seite 21 von 24
Single Sign-On
Verfahren, damit ein Benutzer nach einmaliger Anmeldung alle
Dienste, für die er berechtigt ist, nutzen kann.
SPNEGO
Simple and Protected GSSAPI Negotiation Mechanism. Das SPNEGOProtokoll erlaubt eine Vereinbarung zwischen dem Client (Browser) und
dem Server in Bezug auf das zu verwendende
Authentifizierungsverfahren.
12. Juni 2013 / Seite 22 von 24
7 Links
7.1
Kerberos
Using mod_auth_kerb and Windows 2000/2003 as KDC:
http://www.grolmsnet.de/kerbtut/
HTTP-Based Cross-Platform Authentication via the Negotiate Protocol:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsecure/html/http-sso-1.asp
7.2
LDAP
LDAP Filter:
http://www.tools4ever.com/resources/manual/usermanagement6/LDAP_search__LDAP_Filter.htm
LDAP Query Basics:
http://technet.microsoft.com/de-ch/library/aa996205.aspx
8 Tools
8.1
Kerberos
Apache Modul "mod_auth_kerb":
http://modauthkerb.sourceforge.net/
Tray-Applikation zum Anzeigen von Kerberos Tickets (Windows):
http://www.microsoft.com/downloads/details.aspx?FamilyID=4e3a58be-29f6-49f6-85bee866af8e7a88&displaylang=en
8.2
LDAP
LDAP Browser für (Windows):
http://www.ldapbrowser.com
8.3
Diverses
Network Protocol Analyzer "Wireshark" (Windows, Mac, Linux):
http://www.wireshark.org
12. Juni 2013 / Seite 23 von 24
9 Konditionen Support
9.1



Consulting
Unterstützung per E-Mail, Telefon oder Skype
Support mit Remote-Viewer Tool (Übertragung des Bildschirminhalts; in beide Richtungen
möglich)
Kleinste Verrechnungseinheit pro Anfrage: ½h
Pro Stunde: 180.- CHF
9.2




TYPO3 Extensions
Für die Realisierung wurden ausschliesslich die bestehenden, im TER verfügbaren LDAP
Extensions verwendet
In drei der vier Extensions wurden geringfügige Bugfixes und Anpassungen/Erweiterungen
vorgenommen bzw. eine Funktion für die SSO-Authentifizierung implementiert
Da die Extensions dem GPL Lizenzierungsmodell unterliegen, verlangen wir entsprechend
der Philosophie der GPL nichts für unsere Anpassungen an den Extensions. Wir
verrechnen lediglich einen kleinen Betrag für die Dokumentation der Änderungen.
Lieferung der LDAP Extensions als .t3x Dateien inkl. Änderungsdokumentation
Pauschal: 400.- CHF
9.3
-
9.4
-
9.5
-
Spesenansätze
Reisezeit nach Aufwand
Kilometerentschädigung für Anfahrt pro km
120.00
0.85
Zahlungsbedingungen
Die kleinste Verrechnungseinheit beträgt ½ Stunde. Wir bitten Sie, kleinere
Anfragen zusammen zu fassen
Alle Preise in CHF exkl. 7.6% MwSt.
Allgemeines
Die Allgemeinen Geschäftsbedingungen der internezzo ag bilden einen integrierenden
Vertragsbestandteil. Die aktuelle Version der Allgemeinen Geschäftsbedingungen kann
von unserer Website unter www.internezzo.ch heruntergeladen und/oder unter 041 748
02 48 angefordert werden.
12. Juni 2013 / Seite 24 von 24

Konzept Single-Sign-On

Transcription

Similar documents

Internationale Bauprüfung am Fuchs für Erdhunde

Spesenreglement

Jeux Dramatique - Humanwissenschaftliche Fakultät

Spielplan Profis - HypoVereinsbank