Möglicher LDAP Bug in PVE 7.4

[ITKR]

Hallo,

ich habe heute ein merkwürdiges Verhalten festgestellt, als ich eine Änderung in der LDAP Konfiguration gemacht habe.
Der "Base Domain Name" wurde in eine andere OU geändert, also:

ou=peng,dc=bla,dc=blub

geändert in

ou=tralla,dc=bla,dc=blub

Wie sich herausstellte konnte Proxmox einige der Benutzer im neuen Baum nicht finden. Statt aber jetzt die Anmeldung zu verweigern, konnte man sich mit jedem beliebigen Password anmelden. Einzige Voraussetzung: Der Benutzer muss im PVE existieren.

Jemand eine Idee?

 

[dcsapak]

was sagt denn das journal/syslog zu dem zeitpunk? ich kann das hier nicht so nachvollziehen, ein user der im pve existiert aber nicht im ldap wird abgelehnt im log mit:

Jun 12 15:07:41 pve pvedaemon[3646086]: authentication failure; rhost=::ffff:192.168.xx.xx user=notexisting@ldap msg=Invalid credentials at /usr/share/perl5/PVE/LDAP.pm line 83.

 

[ITKR]

Im Logfile steht für Benutzer die im PVE existieren und im LDAP gefunden werden bei falscher Passwordeingabe:

pvedaemon[1573]: authentication failure; rhost=::ffff:xx.xx.xx.xx user=xxxx@xxxx msg=80090308: LdapErr: DSID-0C090434, comment: AcceptSecurityContext error, data 52e, v4f7c#000 at /usr/share/perl5/PVE/LDAP.pm line 83.

Für Benutzer die im PVE existieren und im LDAP NICHT gefunden werden immer

<root@pam> successful auth for user 'xxx@xxx'

 

[fweber]

Hi, könntest du den Inhalt von /etc/pve/domains.cfg posten (die konkreten Domain-Names kannst du gern zensieren)?

Um was für einen Server handelt es sich denn? Ist das ein Active Directory?

 

[ITKR]

Hi, könntest du den Inhalt von /etc/pve/domains.cfg posten (die konkreten Domain-Names kannst du gern zensieren)?

Um was für einen Server handelt es sich denn? Ist das ein Active Directory?

Gern:

pve: pve
        comment Proxmox VE authentication server

pam: pam
        comment Linux PAM standard authentication

ldap: xxx.xxx
        comment AD Anmeldung %C3%BCber xxx.xxx
        base_dn DC=xxx,DC=xxx
        server1 xxx.xxx.xxx
        user_attr sAMAccountName
        bind_dn CN=xxx,OU=xxx,OU=xxx,DC=xxx,DC=xxx
        default 1
        group_name_attr memberOf
        port 636
        secure 1
        sync-defaults-options enable-new=0,scope=users
        sync_attributes email=mail

Ja, es handelt sich im Ende um eine AD
Die base_dn ist jetzt allerdings auf die oberste Ebene gesetzt, so dass alle Benutzer gefunden werden, war während des Fehlers "ou=xxx,dc=xxx,dc=xxx"

 

[ITKR]

Hallo,

ich habe das nochmal an unserem Testsystem nachvollzogen.
Folgende Schritte sind notwendig um das Problem zu provozieren:

1. LDAP Realm konfigurieren:

Base Domain Name muss existieren, aber Benutzer darf darin nicht gefunden werden.

2. Benutzer anlegen:

Der Benutzer kann jeden beliebigen Phantasienamen haben

3. Anmelden

Hier funktioniert jetzt jedes beliebige Password, der Benutzer muss nicht mal in der AD existieren.

 

[fweber]

Hi, danke für die Informationen! Wir werden uns das mal anschauen und melden uns anschließend.

 

[fweber]

Hallo, vielen Dank für deinen detaillierten Report! Der Bug wurde gefixt [1] und der Fix ist in libpve-common-perl >= 7.4-2 enthalten. Diese Paketversion ist seit ca. einer Stunde im no-subscription-Repository verfügbar. Falls du den Fix testen möchtest, gib gern kurz Rückmeldung, ob das Problem nach dem Paketupdate auch bei dir gelöst ist.

[1] https://git.proxmox.com/?p=pve-common.git;a=commit;h=519150773d2378d470d4cca8463d40e83945c00a

 

[ITKR]

Hallo, vielen Dank für deinen detaillierten Report! Der Bug wurde gefixt [1] und der Fix ist in libpve-common-perl >= 7.4-2 enthalten. Diese Paketversion ist seit ca. einer Stunde im no-subscription-Repository verfügbar. Falls du den Fix testen möchtest, gib gern kurz Rückmeldung, ob das Problem nach dem Paketupdate auch bei dir gelöst ist.

[1] https://git.proxmox.com/?p=pve-common.git;a=commit;h=519150773d2378d470d4cca8463d40e83945c00a

Besten Dank für die schnelle Reaktion habe den Fix eingespielt und kann das Problem nicht mehr reproduzieren, scheint also zu funktionieren.