ldap_auth
Hatte auch die Komplette ldap_* schon in der Verwendung. Damit bekomm ich aber keine Usergruppen hin. :-(
ldap_auth
Hatte auch die Komplette ldap_* schon in der Verwendung. Damit bekomm ich aber keine Usergruppen hin. :-(
Also funktioniert bei der Userimport auch nicht richtig unter Verwendung der ganzen ldap_* Extensions? Also besser gesagt der Userimport inkl. Gruppen asu ldap?! Hast du im Hintergrund zusätzlich die eu_ldap am laufen gehabt?
Ich glaube nicht daß man eu_ldap mit den ldap_auth/server/sync/lib kombinieren kann.
Mit eu_ldap bekam ich immer einen WhiteScreen beim Import und konnte auch nicht gegen die W2K3-ADS authentifizieren, habe ich also wieder installiert.
Mit den ldap_auth-Extensions kam ich bislang am Weitesten:
Es wurden sogar die Usergruppen und Zuordnungen importiert, obwohl sich bei uns die FE-User und FE-Gruppen in unterschiedlichen OU befinden.
Allerdings werden die Passwörter nicht mit importiert und die LDAP-Authentifizierung schlägt fehl. Man kann nur manuell angelegte FE einloggen, bzw. wo ich danach manuell Kennwörter vergebe, was aber nicht Sinn der Sache sein kann.
Eventuell könnte es auch was mit der ext:kb_md5fepw zu tun haben, die bei mir installiert (Typo3 V4.1.1 PHP5 Linux mit YAML) ist und Passwörter verschlüsselt? Aber ohne diese ext geht überhaupt kein FE-Login mehr.
#angry#
Weis jemand mehr?
Für SingleSignOn, also ein Autologin via NTLM (IE oder FF mit Patch), benötigt man dann noch eine separate Extension, die dann entweder mit einem Apache-Modul mod_ntlm (sehr tricky, weil man bei einem 64bit-Linux den Modul-Code erst mal patchen muß um es zu kompilieren) verhandeln oder mit dem IIS.
Das mod_ntlm unter Apache2.2/Linux habe ich zwar zum Laufen aber zwischendrinn fehlt es mir jetzt noch: Typo3-LDAP-Authentifikation und die NTLM-Übergabe an den Browser
Da das alles sehr komplex und tricky ist und es keine vollständige Dokumentation gibt, wären alle Hinweise hilfreich.
Interesse an einer Erfahrungsgruppe?
Vielleicht wäre sogar ein eigener Forum-Bereich sinnvoll?
Währe an einer Erfahrungsgruppe sehr interesiert.
Soll ja nicht mein letztes projekt gewesen sein!
Ich wäre auch daran interessiert!
Hab gerade nochmal in der Doku nachgeschaut (Bereich "FAQ"):
How does the SSO integration work?
For single sign on the user's password is encrypted and cached, the key is stored in a cookie. Just tick the checkbox in the extension's settings.
Nachdem ich den Haken im Extension-Manager gesetzt habe, läuft es einwandfrei und ich melde mich über das AD an!
TYPO3-Version: 4.1.2
eu_ldap: 2.7.9
Die Hashes in der Datenbank sind übrigens nur sicherheitshalber dort (darüber habe ich mich erst gewundert):
For new users imported from the directory random passwords will be inserted!
Bei mir also ein klarer Fall von RTFM #paralyzed#
Aber eu_ldap hat in der Standard-Installation gar keinen Haken für SSO in den Extension-Settings. Welche SSO-Extension muß man denn dafür separat installieren? eu_sso_owa?
Weitere Frage: in den eu_ldap-Ext-Settings kann man den Logging-Level von 0 auf 1 oder 2 schalten. Aber wo tauchen diese Logs auf? Im Typo3-Backendlog ist nichts...
Ich verwende T3 V4.1.1 mit eu_ldap 2.7.9 unter OpenSuSE V10.2/64bit mit PHP 5.x.
Ich denke der Thread behandelt gerade zwei verschiedene Themen:
1. die einwandfreie Funktion einer LDAP-Extension (Benutzerimport, Authentifizierung nach Login im Browser, ..)
2. einen WIRKLICHEN Single Sign-On oder Autologin, also quasi "einmal an der Domäne angemeldet, wird der Benutzer AUTOMATISCH im Browser mit den gleichen Benutzerdaten an TYPO3 angemeldet", ohne vorherigen manuellen Login
Aber eu_ldap hat in der Standard-Installation gar keinen Haken für SSO in den Extension-Settings. Welche SSO-Extension muß man denn dafür separat installieren? eu_sso_owa?
Ich habe keine separate Extension installiert, da ich bei einem SSO von der Anmelderessource ausgegangen bin, und es mir gereicht hat, dass der Benutzer quasi nur einen Satz "Anmeldedaten" hat, der dann natürlich auch nur einmal im Active Directory gepflegt werden muß.
Folgendes war also für mich gleich SSO:
Enable authentication against LDAP ... [onlyLDAP]
Enable authentication against LDAP only. If checked, users not found in the directory may not log on.
Diese Meinung habe ich aber eben nach einer Recherche in der Wikipedia verworfen, denn laut Definition ist es ja ein "Autologin" wie du (SCHNEIKA) ihn meinst:
Single Sign-On (kurz SSO, mitunter als „Einmalanmeldung“ übersetzt) bedeutet, dass ein Benutzer nach einer einmaligen Authentifizierung auf alle Rechner und Dienste, für die er berechtigt ist, zugreifen kann, ohne sich jedes Mal neu anmelden zu müssen.
Zu der Authentifizierung steht ja in der Dokumentation ("eu_ldap") Folgendes:
When a user tries to log on the extension passes the credentials to the LDAP server(s) and verifies them. When a LDAP server can authenticate the user he is logged on.
Um das automatisch zu realisieren müßten ja die "credentials" der Domänenanmeldung irgendwie an den Browser weitergegeben werden, der dann wiederum eine automatische Anmeldung damit über TYPO3 am LDAP-Server durchführt wenn ich das richtig verstanden habe.
Wenn man jetzt meinetwegen per apache-Modul und Browser irgendwie die Daten zur Verfügung gestellt bekommt, stellt sich mir immer noch die Frage wie der Anmeldevorgang, am besten auch noch sicher, funktionieren soll.
Ich denke dafür sollte man wirklich (mindestens) einen eigenen Thread aufmachen.
Aber ich wäre, trotz eines für mich ja eigentlich neuen Themas, sehr interessiert! 😉
Cheers
Also dafür einen neuen Thread aufmachen? Ich denke nicht, da ja genau das mein Anliegen war. Einaml an der Domäne anmelden und sich dann in Typo3 nicht nocheinmal anmelden müssen.
Meine eu_ldap läuft einwandfrei, die User werden importiert mit Gruppen und Passwörtern.
Auch ohne
Enable authentication against LDAP ... [onlyLDAP]
Enable authentication against LDAP only. If checked, users not found in the directory may not log on.
Das bewirkt nur, dass man sich nur noch mit Usern, die gegen ldap authentifiziert wurden, anmelden kann... also die Lokal angelegten User funktionieren nicht mehr.
Habe jetzt schon an einigen stellen gelesen, das verschiedene Personen in ihrer eu_ldap einen Teil der Konfiguration haben, mit dem Header Netzwerk für Single-Sign-On leider konnte ich diesen Punkt bisher nicht finden.
Vielleicht sollte man ja gerade deswegen einen neuen Thread aufmachen 😉
Typo3 4.1.x
IIS 6 Windopws 2003 R2
Ich habe mit der Erweiterung wwsc_sso_intranet ein SSO Realisiert. Ich setze die Erweiterung newloginbox ein für die Benutzer für die das SSO Login nicht funktioniert.
Mit eu_ldap hole ich die AD User in die fe_users Tabelle.
Das A&O ist es im IIS die Windows Authentication zu verwenden und den Anonymen Zugriff auszuschalten.
Die SSO Lösung in Verbindung mit dem Login funktiert gut, wenn auch nicht 100% Rund. Der mit SSO angemeldete Benutzer kann sich nicht ausloggen, weil er sofort wieder eingeloggt wird.
Aus diesem Grund setze ich in der Klasse der Erweiterung wwsc_sso_intranet (Intranet SSO) eine PHP Umgebugnsvariable ganz Banal mit putenv(""myvariable=n") die ich in meiner Konfiguration in einer TS Kondition abfrage. Wenn der Wert mir zurückgibt, dass das SSO erfolgreich durchgeführt wurde binde ich die newloginbox ein templateFile ohne Abmelde Button ein. Fernziel ist aber, dass sich auch ein per SSO authentifizierter Benutzer abmelden kann, damit sich ein anderer Benutzer mit dessen Browser im Intranet einloggen kann (um ihm "was" zu zeigen).
wwsc_sso_intranet ist eine Erweiterung die als Typo3 Service installiert wird. Es gibt quasi nur einen Konfigurationsparemater: FE_fetchUserIfNoSession = 1
Für die Konfiguration sieht das so aus:
$GLOBALS['TYPO3_CONF_VARS']['SVCONF']['auth']['setup']['FE_fetchUserIfNoSession'] = 1; //1 oder 0
Vielleicht hat dazu jemand eine Idee: kann ich den Wert eines Konfigurationsparameters eines Typo3 Dienstes für eine User Session dynamisch ändern?
Also banal gesagt: wenn ein User den abmelde Button klickt wird FE_fetchUserIfNoSession = 0 gesetzt... weil dann greift nämlich das SSO nicht. Ich will aber ja nicht dass dann plötzlich alle anderen User nicht mehr per sso authentifiziert werden...
...das ist aber wahrscheinlich genau der Punkt wo der Hund begraben liegt weil der Paramater eines Diesnetes nur Global gilt...