Konzeptpapier TYPO3 Single Sign-On mit Kerberos und LDAP unter Apache / IIS VERSION 1.0

Transkript

1 Konzeptpapier TYPO3 Single Sign-On mit Kerberos und LDAP unter Apache / IIS VERSION 1.0

2 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 TYPO marcel.burkhalter@internezzo.ch 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 Die Grundlagen sind noch dieselben, diverse Details im Konzept sind aber nicht mehr up-to-date. internezzo ag Juni 2013 / Seite 2 von 24

3 Inhaltsverzeichnis 1 Vorwort 5 2 Beschreibung der Lösung Ablauf für den Benutzer Technischer Ablauf Apache Internet Information Services Voraussetzungen Server & Client Webserver Linux Windows Active Directory Server Firewall / Ports Allgemein Browser Firefox Internet Explorer Umsetzung / Vorgehen Konfiguration Active Directory Benutzer für Kerberos (nur Apache) AD Kerberos Benutzers als Keytab exportieren (nur Apache) Benutzer für LDAP Active Directory Attribut dsheuristics Konfiguration Webserver Apache Kerberos-Schutz via.htaccess Kerberos-Schutz via httpd.conf Internet Information Services Konfiguration TYPO Extensions ldap_auth ldap_server Fehlersuche & Tests Authentifikation Apache (Kerberos) Kontrolle des Benutzernamens in der PHP $_SERVER Variable LDAP ldapsearch Beispielaufrufe Glossar und Abkürzungen 21 7 Links Kerberos LDAP Tools Kerberos LDAP Diverses internezzo ag Juni 2013 / Seite 3 von 24

4 9 Konditionen Support Consulting TYPO3 Extensions Spesenansätze Zahlungsbedingungen Allgemeines internezzo ag Juni 2013 / Seite 4 von 24

5 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. internezzo ag Juni 2013 / Seite 5 von 24

6 2 Beschreibung der Lösung 2.1 Ablauf für den Benutzer Der Benutzer meldet sich mit seinem Benutzernamen und Passwort an der Windows- Domä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 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 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 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, 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 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. internezzo ag Juni 2013 / Seite 6 von 24

7 3 Voraussetzungen Server & Client 3.1 Webserver 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" Windows Betriebssystem: Windows 2003 Server Webserver: Internet Information Services (Version >= 6.x) 3.2 Active Directory Server Active Directory mit Attribut "dsheuristics = " Konfiguration siehe Kapitel 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!) internezzo ag Juni 2013 / Seite 7 von 24

8 3.5 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 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 Windows- Authentifizierung aktivieren" gesetzt sein (normalerweise ist dies schon so) internezzo ag Juni 2013 / Seite 8 von 24

9 4 Umsetzung / Vorgehen 4.1 Konfiguration Active Directory 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 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 ) 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 ) Active Directory Attribut dsheuristics Gemäss Microsoft braucht es das Attribut "dsheuristics = ", 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: internezzo ag Juni 2013 / Seite 9 von 24

10 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: (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 " " in der Liste erscheinen (siehe Screenshot unten) Abbildung 1: Eigenschaften auf dem Ast "Directory Service" (Adsiedit.msc) Weitere Informationen von Microsoft: internezzo ag Juni 2013 / Seite 10 von 24

11 4.2 Konfiguration Webserver Apache 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 # KERBEROS AUTHENTIFICATION 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 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/"> # KERBEROS AUTHENTIFICATION --> Konfiguration wie bei.htaccess # KERBEROS AUTHENTIFICATION </Directory> internezzo ag Juni 2013 / Seite 11 von 24

12 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. internezzo ag Juni 2013 / Seite 12 von 24

13 4.3 Konfiguration TYPO 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 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 ). internezzo ag Juni 2013 / Seite 13 von 24

14 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 * array $data: usually empty array $conf: usually empty 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 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: 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 internezzo ag Juni 2013 / Seite 14 von 24

15 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 internezzo ag Juni 2013 / Seite 15 von 24

16 Beispielkonfiguration für Copy&Paste: Filter for persons: (&(objectclass=user)(objectclass=person)(!(objectclass=computer))(!(useracc ountcontrol: :=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 # = 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: :=2))) fields { username = MAP_OBJECT username.attribute = samaccountname username.userfunc = tx_ldapserver->getsinglevalue = MAP_OBJECT .attribute = mail .userfunc = tx_ldapserver->getsinglevalue name = MAP_OBJECT name.attribute = cn name.userfunc = tx_ldapserver->getsinglevalue internezzo ag Juni 2013 / Seite 16 von 24

17 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 internezzo ag Juni 2013 / Seite 17 von 24

18 } 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. internezzo ag Juni 2013 / Seite 18 von 24

19 5 Fehlersuche & Tests 5.1 Authentifikation 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" 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... internezzo ag Juni 2013 / Seite 19 von 24

20 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) 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 x.x -D "cn=username,ou=unit,dc=company" -b "ou=unit,dc=company" Anzeigen aller Benutzer (Filter: nur Personen, keine Computer): ldapsearch -x -w password -h x.x -D "cn=username,ou=unit,dc=company" -b "ou=unit,dc=company" '(&(objectclass=user)(objectclass=person)(!(objectclass=computer)))' Anzeigen aller aktiven Benutzer (Filter: nur nicht deaktivierte Personen, keine Computer): ldapsearch -x -w password -h x.x -D "cn=username,ou=unit,dc=company" -b "ou=unit,dc=company" '(&(objectclass=user)(objectclass=person)(!(objectclass=computer))(!(useraccountcon trol: :=2)))' Anzeigen eines bestimmten Benutzers (Filter: nur Personen, definierter Accountname): ldapsearch -x -w password -h x.x -D "cn=username,ou=unit,dc=company" -b "ou=unit,dc=company" '(&(objectclass=user)(objectclass=person)(!(objectclass=computer)) (samaccountname=username))' internezzo ag Juni 2013 / Seite 20 von 24

21 6 Glossar und Abkürzungen Dieses Glossar soll nur einen groben Überblick bieten. Die meisten Begriffe sind bei Wikipedia sehr gut beschrieben..htaccess File Active Directory AD HTTP Headers IIS Internet Information Services Kerberos Kerberos Ticket Keytab File LDAP NTLM REALM Service principal Service Ticket 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. Verzeichnisdienst von Microsoft mit welchem Benutzer, Computer und ähnliches verwaltet werden. siehe Active Directory Kopfdaten die beim Aufruf einer Webseite vor dem Inhalt übertragen werden. HTTP Header können u.a. Cookiedaten oder auch Informationen zur Authentifizierung enthalten. siehe Internet Information Services Webserver von Microsoft (beinhaltet weitere Dienste wie FTP, POP3 etc.). Netzwerk Authentifizierungsverfahren zur sicheren Authentifizierung in ungesicherten TCP/IP Netzwerken. Die Informationspakete, welche Kerberos zwischen Client und Server zur Authentifizierung austauscht, werden Ticket genannt. 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. Lightweight Directory Access Protocol. Mit diesem Protokoll kann auf das Active Directory zugegriffen werden. 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. Administrationsbereich eines Kerberos-Servers. Typischerweise der Domainname in Grossbuchstaben, z.b. INTRANET.TLD Bezeichnung zur eindeutigen Identifikation eines Kerberos Dienstes, z.b.: siehe Kerberos Ticket internezzo ag Juni 2013 / Seite 21 von 24

22 Single Sign-On SPNEGO Verfahren, damit ein Benutzer nach einmaliger Anmeldung alle Dienste, für die er berechtigt ist, nutzen kann. Simple and Protected GSSAPI Negotiation Mechanism. Das SPNEGO- Protokoll erlaubt eine Vereinbarung zwischen dem Client (Browser) und dem Server in Bezug auf das zu verwendende Authentifizierungsverfahren. internezzo ag Juni 2013 / Seite 22 von 24

23 7 Links 7.1 Kerberos Using mod_auth_kerb and Windows 2000/2003 as KDC: HTTP-Based Cross-Platform Authentication via the Negotiate Protocol: LDAP LDAP Filter: _LDAP_Filter.htm LDAP Query Basics: 8 Tools 8.1 Kerberos Apache Modul "mod_auth_kerb": Tray-Applikation zum Anzeigen von Kerberos Tickets (Windows): LDAP LDAP Browser für (Windows): Diverses Network Protocol Analyzer "Wireshark" (Windows, Mac, Linux): internezzo ag Juni 2013 / Seite 23 von 24

24 9 Konditionen Support 9.1 Consulting Unterstützung per , Telefon oder Skype Support mit Remote-Viewer Tool (Übertragung des Bildschirminhalts; in beide Richtungen möglich) Kleinste Verrechnungseinheit pro Anfrage: ½h Pro Stunde: 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: CHF 9.3 Spesenansätze - Reisezeit nach Aufwand Kilometerentschädigung für Anfahrt pro km Zahlungsbedingungen - Die kleinste Verrechnungseinheit beträgt ½ Stunde. Wir bitten Sie, kleinere Anfragen zusammen zu fassen - Alle Preise in CHF exkl. 7.6% MwSt. 9.5 Allgemeines - Die Allgemeinen Geschäftsbedingungen der internezzo ag bilden einen integrierenden Vertragsbestandteil. Die aktuelle Version der Allgemeinen Geschäftsbedingungen kann von unserer Website unter heruntergeladen und/oder unter angefordert werden. internezzo ag Juni 2013 / Seite 24 von 24