HfWU - LDAP Anbindung

Aus Wikizone
Version vom 5. Juli 2007, 16:17 Uhr von 193.196.133.66 (Diskussion)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Wechseln zu: Navigation, Suche

Die LDAP - Anbindung erfolgt mit Hilfe der Extension LDAP Integration

Zuständigkeiten[Bearbeiten]

Nürtingen: Dieter Lehmann Geislingen: Lang / Fellner-Lang

Konfiguration[Bearbeiten]

Server: 193.196.132.44
Port: 389
LDAP-Version: 2
Basis DN: dc=fh-nuertingen,dc=de
Art des LDAP Server: OpenLDAP
Filter: (&(objectclass=posixAccount)(uid=<search>))
Benutzer: uid=Manager,ou=People,dc=fh-nuertingen,dc=de
Pass: sagichnich
Attribut für Benutzername: uid
Attribut für Email: mail
Standard verwenden, um Benutzer zu Gruppen zuzuordnen - person:memberOf (AD) / person:groupMembership (NDS) / posixGroup:memberUid 
Importiere/aktualisiere authentifizierte Benutzer automatisch (dadurch wird versucht mit dem Server zu binden und anschließend die Nutzerdaten zu laden
Gruppen aus LDAP importieren


Arbeitsweise[Bearbeiten]

der Import funktioniert jetzt gut mit folgendem Filter:

(&(objectclass=posixAccount)(uid=<search>))

wobei <search> bei der Authentifizierung durch den Usernamen ersetzt wird, und beim Import nicht berücksichtigt wird.

Beim Import meldet sich das Skript mit den Hinterlegten Userdaten an und greift je nach Berechtigung auf alle Datensätze zu.

Bei der automatischen Authentifizierung macht das Skript einen Bind mit den Userdaten und versucht danach den eigenen Userdatensatz auszulesen. Das Auslesen funktioniert aber nicht. Erlaubt der Server bei Anmeldung mit anderen Daten als dem Manager, grundsätzlich keinen Lesezugriff ?

Folgende Lösungen sehe ich: 1. Authentifizierung anhand des geglückten Binds (evtl unsicher weil das Skript bei einem Server der anonyme Binds erlaubt den Zugriff für jeden User erlaubt)

2. Kann man den Lesezugriff auf die eigenen Daten erlauben. Finde ich am Besten. Dann könnte man das Skript so gestalten, daß man keinen Manager zum Importieren aller Daten braucht, d.h. mehr Sicherheit. Die Benutzer werden dann automatisch im Typo angelegt, wenn sie sich das erste mal anmelden und der Bestand wächst dann nach und nach.


Probleme[Bearbeiten]

Speicherüberlauf beim Import der User[Bearbeiten]

Probleme macht die Funktion:convertArray in der Datei class.tx_eulap_div.php Sie dient zur umwandlung des Zeichensatzes der Benutzerdaten. Dazu bedient Sie sich eines rekursiven Aufrufs, der bei großen Datenmengen zu einem Speicherüberlauf führt. Da der HfWU LDAP Server und Typo3 beide utf-8 benutzen, konnte das Problem durch eine kleine Erweiterung behoben werden. Vor dem rekursiven aufruf wird geprüft ob die Charsets gleich sind. Wenn dies der Fall ist wird das Array unverändert zurückgegeben.

Original:

	function convertArray($arr, $char1, $char2) {
		while (list($k, $val) = each($arr)) {
			if (is_array($val)) {
				$arr[$k] = tx_euldap_div::convertArray($val, $char1, $char2);
			} else {
				$arr[$k] = $this->csObj->conv($val, $char1, $char2);
			}
		}
		return $arr;
	}

Modifizierte Version:

	function convertArray($arr, $char1, $char2) {
	   if($char1 != $char2){
		while (list($k, $val) = each($arr)) {
			if (is_array($val)) {
				$arr[$k] = tx_euldap_div::convertArray($val, $char1, $char2);
			} else {
				$arr[$k] = $this->csObj->conv($val, $char1, $char2);
			}
		}
	   }
		return $arr;
	}

gelöschte Usergruppen werden nicht wieder hergestellt[Bearbeiten]

Gruppen die in der Datenbank zwar vorhanden, aber als gelöscht markiert sind werden nicht wiederhergestellt wenn ein Benutzer zu dieser Gruppe gehört. Lösung: Eine erweiterung der Funktionen (assignGroups oder insertSingleUser o.ä.) müßte möglich sein.