Bug 28103 - Möglichkeit für einen/den aktuellen Benutzer die LDAP-DN abzufragen
Möglichkeit für einen/den aktuellen Benutzer die LDAP-DN abzufragen
Status: RESOLVED WONTFIX
Product: UCS
Classification: Unclassified
Component: LDAP
UCS 3.0
Other Linux
: P5 enhancement (vote)
: ---
Assigned To: UCS maintainers
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-07-27 16:52 CEST by Janek Walkenhorst
Modified: 2018-04-14 13:43 CEST (History)
3 users (show)

See Also:
What kind of report is it?: ---
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional): Further conceptual development
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Janek Walkenhorst univentionstaff 2012-07-27 16:52:01 CEST
Seit das LDAP keinen anonymen Zugriff mehr gestattet braucht man um auf das LDAP zuzugreifen eine BindDN und das dazugehörige Passwort.

Um anhand des Benutzernames (UID) die BindDN zu ermitteln benötigt man zugriff auf das LDAP.

Dafür braucht man aber eine BindDN…


Diese Funktionialität sollte auch in {shell,python}-univention-lib bereitgestellt werden.
Comment 1 Arvid Requate univentionstaff 2012-07-30 13:30:46 CEST
Als Workaround wäre Authentifikation per Kerberos Ticket möglich:
 kinit $username; ldapsearch -Y GSSAPI uid=$username dn
Comment 2 Philipp Hahn univentionstaff 2012-07-30 20:58:05 CEST
Prinzipiell kann man SASL-Authentifizierung benutzen, allerdings sind dazu ein paar Anpassungen an der /etc/ldap/slapd.conf notwendig und das ganze erfordert Klartextpasswörter:

# Übersetzen der SASL-Anfrage auf einen Benutzer
authz-regexp
    uid=([^,]*),cn=[^,]*,cn=auth
    uid=$1,dc=pmhahn,dc=dev
#    ldap:///dc=pmhahn,dc=dev??sub?uid=$1

# Noch nicht authentifiziertem Benutzer erlauben, zwecks Authentifizierung aus die Attribute "entry", "objectClass" und "password" zugreifen zu dürfen
access to *
   ...
   by * auth

# SASL kann nicht mit {crypt}-Passwörtern umgehen, sondern benötigt das Klartextpasswort <http://www.openldap.org/lists/openldap-software/200707/msg00057.html>. Damit gehen dann auch direkt sichere Methoden wie CRAM-MD5.
password-hash {crypt} {cleartext}


Anschließend kann sich auf folgende Weise authentifizieren:
$ ldapwhoami -Y PLAIN -U test1 -ZZ
$ ldapwhoami -Y LOGIN -U test1 -ZZ
$ ldapwhoami -Y CRAM-MD5 -U test1

Das "-U $USER" ist hier nur als "root" notwendig, um sich als dieser Benutzer zu authentifizieren. Als Benutzer "test1" selber kann man natürlich darauf verzichten.
Auf das "-Y $MECH" kann man verzichten, wenn man MECH_LIST in /etc/ldap/ldap.conf bzw. die Umgebungsvariable LDAPSASL_MECH= entsprechend setzt. Siehe dazu auch Bug #20051.




PS: Die sasl-regexp in /etc/univention/templates/files/etc/ldap/slapd.conf.d/60univention-ldap-server_acl-master sieht seltsam aus. Laut Doku muß das eine lokale ldap:///-URI sein, vorallem die mehreren LDAP-Ports sehen kaputt aus.
Comment 3 Stefan Gohmann univentionstaff 2013-12-06 10:33:40 CET
Gibt es hierfür einen Anwendungszweck?
Comment 4 Philipp Hahn univentionstaff 2013-12-06 11:30:33 CET
(In reply to Stefan Gohmann from comment #3)
> Gibt es hierfür einen Anwendungszweck?

Ja: Damit man auch als nicht-root-Benutzer im LDAP suchen kann, aber dafür braucht man eben seine DN; vielleicht nicht der Standard-UCS-Benutzer, aber der Power-User, der weiß, dass man mit LDAP eben noch mehr machen kann. (Ich nutze es für das auslesen unserer KVM-Test-Server und den Aufbau der svnauthors-Datei für GIT).

Ein paar Argumente dafür, wo es mit persönlich immer wieder störend aufgefallen ist:

Administrator:~$ whoami 
Administrator
Administrator:~$ which univention-ldapsearch
/usr/bin/univention-ldapsearch
Administrator:~$ univention-ldapsearch uid=Administrator
/etc/machine.secret: Permission denied

Wenn ich univention-ldapsearch nicht als normaler Benutzer ausführen kann, warum liegt es dann in /bin/ und nicht in /sbin/? D.h. selbst der Wrapper funktioniert nicht für nicht-root-Benutzer, womit ich auch gleich ldapsearch direkt verwenden kann, aber dann brauche ich eben auch meine DN.

Administrator:~$ groups 
... DC Backup Hosts ...
Administrator:~$ ls -l /etc/ldap.secret 
-rw-r----- 1 root DC Backup Hosts 20 28. Nov 12:14 /etc/ldap.secret
Administrator:~$ /usr/sbin/udm users/user list | grep -c ^DN:
3

Ich kann mich (dunkel) an andere Projekte erinnern, wo wir auch andere Benutzer dem Gruppe "DC Backup Hosts" hinzugefügt haben, nur damit sie auf die secret-Datei zugreifen konnten. Dass man dadurch noch auf sehr viel mehr *schreibend* zugreifen kann, macht das in meinen Augen gefährlich oder ist zumindest schlechter Stil.

Noch besser wäre natürlich eine wieder funktionierende Singe-Sign-on-Variante per Kerberos wie an Bug #29482 beschrieben, denn dann muss man sich gar nicht mehr für seine DN interessieren.

Ob man dafür eine Bibliotheksfunktion braucht, weiß ich nicht. Zumindest ist die DN nicht einfach zu errechnen, weil mein Benutzer-Objekt im LDAP ja an jeder Stelle liegen kann; wir machen AFAIK eine globale Suche (relative zur OU?). Aber damit beißt sich die Katze dann in den Schwanz: Zum finden der eigenen DN muss man eine LDAP-Suche machen, wofür man sich mit seiner DN authentifizieren muss ...

Just my ¢2.
Comment 5 Stefan Gohmann univentionstaff 2013-12-09 07:20:44 CET
OK, ich sehe im Moment keinen wirklichen Bedarf für das Produkt.

Sollte die Anforderung kommen, dann kann der Bug gerne wieder geöffnet werden.

(In reply to Philipp Hahn from comment #4) 
> Ich kann mich (dunkel) an andere Projekte erinnern, wo wir auch andere
> Benutzer dem Gruppe "DC Backup Hosts" hinzugefügt haben, nur damit sie auf
> die secret-Datei zugreifen konnten. Dass man dadurch noch auf sehr viel mehr
> *schreibend* zugreifen kann, macht das in meinen Augen gefährlich oder ist
> zumindest schlechter Stil.

Die Berechtigung für die ldap.secret ist so, damit Backups die Datei lesen und kopieren können. Das hat nichts mit Administrator und mit diesem Bug eigentlich nichts zu tun.
Comment 6 Janek Walkenhorst univentionstaff 2014-01-06 12:29:53 CET
(In reply to Stefan Gohmann from comment #5)
> OK, ich sehe im Moment keinen wirklichen Bedarf für das Produkt.
> 
> Sollte die Anforderung kommen, dann kann der Bug gerne wieder geöffnet
> werden.
Das fiel afaik bei der Implementierung von u-bittorrent auf; Es ist eben nicht möglich die Usability soweit zu erhöhen dass der Benutzer nur sein Passwort eingeben muss - im Moment muss er auch seine DN angeben (und wissen).

War aber keine Anforderung, fiel nur nebenbei auf da dieses Usability-Problem auch andere Werkzeuge betreffen kann.