Das ist so wichtig, dass ich der Meinung bin, dass ich das hier für alle posten muss, falls jemand das auch mal lösen muss.
Nach vielen Tests und viel Kommunikation mit Graphisoft haben wir endlich eine stabile Lösung für das Problem der Authentifizierung von Benutzern gegen einen LDAP bzw. ein Active Directory gefunden. Ausserdem werde ich darlegen, wie man die BIMCloud (die kostenlose und die nicht-kostenlose Variante) mittels eines Reverse Proxy auf https bekommt.
Zunächst: hier gibt es die Anleitung von GS zu diesem Thema. Leider ist sie inhaltlich sehr oberflächlich, stellenweise falsch übersetzt und hat auch an einer Stelle einen gravierenden Fehler auf den ich ausführlich eingehen werde.
https://help.graphisoft.com/BC/22/GER/_ ... ger-73.htm
Wer das Original lesen mag:
https://help.graphisoft.com/BC/INT/_BIM ... ger-82.htm
Die bimcloud hat gegenüber der Basis-Variante erhebliche Vorteile:
1.) zentrale Verwaltung der einzelnen bimcloud-Versionen
2.) Benutzerabgleich mit der internen Benutzerverwaltung der eigenen Domäne
3.) Backup/Restore des gesamten Servers
Zur eingesetzten Infrastruktur:
SAMBA/Kerberos-Domäne auf Debian-Linux-Basis (einmal "pur" und einmal als UCS-System, https://www.univention.de/ ) mit Active Directory-Erweiterung, d.h. der Server agiert wie ein Active Directory Domänen Controller.
Jede bimcloud läuft auf einer VM, ebenso der bimcloud-manager. Als OS kommen macos bzw. Windows 10 zum Einsatz - je nach Kunde. Da der Einsatz von macos in einer vm ein paar kleine technische Klimmzüge benötigt, trommle ich so vehement dafür, dass GS endlich die Linux-Version der bimcloud frei gibt. Und Windows als Server - naja. Als VM-OS benutzen wir entweder vmware oder debian/qemu.
Zum Eingemachten:
Um zu verstehen, wie das Gespann lokales Archicad <-> bimcloud-Manager funktioniert, lohnt ein Blick nach hier:
https://help.graphisoft.com/BC/22/GER/_ ... view-2.htm
Man erkennt dort auch auf einer Abbildung, dass der Manager explizit auf einen LDAP-Server zugreift, um die Nutzer zu replizieren. Dass die Nutzer repliziert werden (und die Anmeldedaten nicht einfach nur durchgeleitet werden), wird in dem Text ebenfalls hervorgehoben.
Damit kommen wir zu Problem Nr. 1: der Zugriff auf den LDAP. Grundsätzlich ist es so, dass die Liste der Benutzer aus einem LDAP ohne weitere Authentifizierung abrufbar ist. Dieser Vorgang nennt sich anonymous bind und ist so von den Entwicklern gewollt.
https://ldapwiki.com/wiki/Anonymous%20bind
Bei diesem Vorgang werden keine Passworte etc. übertragen sondern nur eine Verbindung zum LDAP hergestellt um Abfragen durchführen zu können (z.B. nenne mir alle Benutzer die einer bestimmten Gruppe angehören). Ist der LDAP korrekt konfiguriert, können keine Passworte abgefragt werden.
In der oben genannten Dokumentation zur LDAP-Authentifizierung wird daher richtigerweise auf die optionale Möglichkeit einer Authentifizierung hingewiesen:
Allerdings hat sich gezeigt, dass dies falsch ist. Und inzwischen hat dies uns der GS-Support auch bestätigt.
Daher: die in der Dokumentation mit (optional) gekennzeichneten Felder müssen ausgefüllt werden. Was uns zu Problem Nr. 2 bringt: das richtige Ausfüllen.
Nehmen wir an die interne Bürodomäne heißt architektur.buero
Und der Server ist unter server.architektur.buero bzw. der internen IP 192.168.10.1 erreichbar. Weiterhin gibt es einen Domänenadministrator mit dem Benutzernamen Administrator. Dann sieht die korrekte Anmeldung so aus:
Allein herauszufinden, dass der Anmeldename kein normaler Loginname ist, sondern eine LDAP-Abfrage darstellt hat mich WOCHEN gekostet. Und ganz ehrlich: erst über die LDAP-Konfiguration unserer Nextcloud bin ich auf den Trichter gekommen! An dieser Stelle schweigt sich die Dokumenation ebenfalls aus.
OK, also bis hierhin können wir uns Verbinden. Jetzt kommt der leichte Teil, die Gestaltung der LDAP-Abfragen für die Nutzer und Gruppen. Und ja, es müssen BEIDE abgefragt werden.
Man klapp also das Feld Parameter Mapping auf, löscht alles was drin steht und gibt die folgenden Dinge ein:
Unter Nutzerabfrage: (&(objectclass=person)(memberof=cn=bimclouduserLDAP,cn=groups,dc=architektur,dc=buero))
Die Gruppe bimclouduserLDAP ist eine Gruppe, die wir im LDAP selbst angelegt haben um die User leichter zu finden. Man kann dort auch jede andere Gruppe angeben, aber dann bekommt man auch alle entsprechenden Mitglieder angezeigt. Zum Testen kann man z.B. auch DomainUsers nehmen.
Unter Gruppenabfrage: (&(objectclass=posixGroup)(cn=bimclouduserLDAP))
Damit wird nochmal ganz explizit die Gruppe bimclouduserLDAP abgefragt.
Und damit der bimcloud manager auch weiß was was ist, kommt hier dann noch die Zuordnung:
Die 3 geschweiften Klammern beim Feld Voller Name sind superwichtig.
Jetzt sollte die Vorschau korrekt funktionieren, d.h. man sollte die Benutzer und die entsprechende Gruppe sehen und hinter der Gruppe die korrekte Anzahl der Mitglieder. Wenn alles funktioniert auf Sichern klicken und mit der Synchronisation unter Nutzer filtern weiter machen. Dort die Gruppe und/oder Nutzer anklicken, die man haben möchte, sichern und synchronisieren.
OK, soweit, sogut. Was soll jetzt noch schief gehen? Naja, obwohl der bind funktioniert und die Benutzer etc. richtig angezeigt werden, synchronisiert der Manager nicht. Oder nur teilweise. Und gibt keine vernünftige Fehlermeldung aus!
An dieser Stelle sind wir sehr tief in die Kommunikation des Managers mit dem LDAP eingestiegen und haben Netzwerkverkehr mitgeschnitten, analysiert und an den GS Support geschickt. An dieser Stelle ein ernst gemeinter Dank an den Support in München und ausdrücklich kein Dank an den Support im GS HQ. Mehr sag ich dazu nicht!
Wir haben das, was jetzt folgt, in verschiedenen Architekturbüros in verschiedenen Konfigurationen getestet. Das Ergebnis ist jedes mal gleich: läuft der Manager in einer VM gibt es Timing-Probleme in der Synchronisation mit dem LDAP. Egal ob Mac oder Windows oder ob die Netzwerkkarte durchgereicht wird oder virtualisiert ist. Nur beim Einsatz echter Hardware funktioniert der Manager tadellos.
Puh. In dieses Ergebnis sind von drei Leuten dutzende von Stunden reingelaufen, Gigabyte-weise Logdateien an GS HQ geschickt worden und tausende Euro versenkt worden. Und das Problem mit den Timings in der VM ist immer noch nicht gelöst. In den letzten Versionen ist es zwar besser geworden - aber ich bekomme nachvollziebar immer noch Fehler. Daher werde ich jetzt den Manager auf einen neuen Server umziehen und hoffen, dass es sich damit erledigt. Auch wenn alle anderen Dienste auf dem alten Server die ebenfalls den LDAP abfragen (Mail, Filesharing, Nextcloud, Kalender, Adressen, zentrales Login, Zeiterfassung, ...) tadellos funktionieren ...
Also, wer Fragen hat, darf mir gerne eine pm schicken.
Nach vielen Tests und viel Kommunikation mit Graphisoft haben wir endlich eine stabile Lösung für das Problem der Authentifizierung von Benutzern gegen einen LDAP bzw. ein Active Directory gefunden. Ausserdem werde ich darlegen, wie man die BIMCloud (die kostenlose und die nicht-kostenlose Variante) mittels eines Reverse Proxy auf https bekommt.
Zunächst: hier gibt es die Anleitung von GS zu diesem Thema. Leider ist sie inhaltlich sehr oberflächlich, stellenweise falsch übersetzt und hat auch an einer Stelle einen gravierenden Fehler auf den ich ausführlich eingehen werde.
https://help.graphisoft.com/BC/22/GER/_ ... ger-73.htm
Wer das Original lesen mag:
https://help.graphisoft.com/BC/INT/_BIM ... ger-82.htm
Die bimcloud hat gegenüber der Basis-Variante erhebliche Vorteile:
1.) zentrale Verwaltung der einzelnen bimcloud-Versionen
2.) Benutzerabgleich mit der internen Benutzerverwaltung der eigenen Domäne
3.) Backup/Restore des gesamten Servers
Zur eingesetzten Infrastruktur:
SAMBA/Kerberos-Domäne auf Debian-Linux-Basis (einmal "pur" und einmal als UCS-System, https://www.univention.de/ ) mit Active Directory-Erweiterung, d.h. der Server agiert wie ein Active Directory Domänen Controller.
Jede bimcloud läuft auf einer VM, ebenso der bimcloud-manager. Als OS kommen macos bzw. Windows 10 zum Einsatz - je nach Kunde. Da der Einsatz von macos in einer vm ein paar kleine technische Klimmzüge benötigt, trommle ich so vehement dafür, dass GS endlich die Linux-Version der bimcloud frei gibt. Und Windows als Server - naja. Als VM-OS benutzen wir entweder vmware oder debian/qemu.
Zum Eingemachten:
Um zu verstehen, wie das Gespann lokales Archicad <-> bimcloud-Manager funktioniert, lohnt ein Blick nach hier:
https://help.graphisoft.com/BC/22/GER/_ ... view-2.htm
Man erkennt dort auch auf einer Abbildung, dass der Manager explizit auf einen LDAP-Server zugreift, um die Nutzer zu replizieren. Dass die Nutzer repliziert werden (und die Anmeldedaten nicht einfach nur durchgeleitet werden), wird in dem Text ebenfalls hervorgehoben.
Damit kommen wir zu Problem Nr. 1: der Zugriff auf den LDAP. Grundsätzlich ist es so, dass die Liste der Benutzer aus einem LDAP ohne weitere Authentifizierung abrufbar ist. Dieser Vorgang nennt sich anonymous bind und ist so von den Entwicklern gewollt.
https://ldapwiki.com/wiki/Anonymous%20bind
Bei diesem Vorgang werden keine Passworte etc. übertragen sondern nur eine Verbindung zum LDAP hergestellt um Abfragen durchführen zu können (z.B. nenne mir alle Benutzer die einer bestimmten Gruppe angehören). Ist der LDAP korrekt konfiguriert, können keine Passworte abgefragt werden.
In der oben genannten Dokumentation zur LDAP-Authentifizierung wird daher richtigerweise auf die optionale Möglichkeit einer Authentifizierung hingewiesen:
Allerdings hat sich gezeigt, dass dies falsch ist. Und inzwischen hat dies uns der GS-Support auch bestätigt.
Daher: die in der Dokumentation mit (optional) gekennzeichneten Felder müssen ausgefüllt werden. Was uns zu Problem Nr. 2 bringt: das richtige Ausfüllen.
Nehmen wir an die interne Bürodomäne heißt architektur.buero
Und der Server ist unter server.architektur.buero bzw. der internen IP 192.168.10.1 erreichbar. Weiterhin gibt es einen Domänenadministrator mit dem Benutzernamen Administrator. Dann sieht die korrekte Anmeldung so aus:
Allein herauszufinden, dass der Anmeldename kein normaler Loginname ist, sondern eine LDAP-Abfrage darstellt hat mich WOCHEN gekostet. Und ganz ehrlich: erst über die LDAP-Konfiguration unserer Nextcloud bin ich auf den Trichter gekommen! An dieser Stelle schweigt sich die Dokumenation ebenfalls aus.
OK, also bis hierhin können wir uns Verbinden. Jetzt kommt der leichte Teil, die Gestaltung der LDAP-Abfragen für die Nutzer und Gruppen. Und ja, es müssen BEIDE abgefragt werden.
Man klapp also das Feld Parameter Mapping auf, löscht alles was drin steht und gibt die folgenden Dinge ein:
Unter Nutzerabfrage: (&(objectclass=person)(memberof=cn=bimclouduserLDAP,cn=groups,dc=architektur,dc=buero))
Die Gruppe bimclouduserLDAP ist eine Gruppe, die wir im LDAP selbst angelegt haben um die User leichter zu finden. Man kann dort auch jede andere Gruppe angeben, aber dann bekommt man auch alle entsprechenden Mitglieder angezeigt. Zum Testen kann man z.B. auch DomainUsers nehmen.
Unter Gruppenabfrage: (&(objectclass=posixGroup)(cn=bimclouduserLDAP))
Damit wird nochmal ganz explizit die Gruppe bimclouduserLDAP abgefragt.
Und damit der bimcloud manager auch weiß was was ist, kommt hier dann noch die Zuordnung:
Die 3 geschweiften Klammern beim Feld Voller Name sind superwichtig.
Jetzt sollte die Vorschau korrekt funktionieren, d.h. man sollte die Benutzer und die entsprechende Gruppe sehen und hinter der Gruppe die korrekte Anzahl der Mitglieder. Wenn alles funktioniert auf Sichern klicken und mit der Synchronisation unter Nutzer filtern weiter machen. Dort die Gruppe und/oder Nutzer anklicken, die man haben möchte, sichern und synchronisieren.
OK, soweit, sogut. Was soll jetzt noch schief gehen? Naja, obwohl der bind funktioniert und die Benutzer etc. richtig angezeigt werden, synchronisiert der Manager nicht. Oder nur teilweise. Und gibt keine vernünftige Fehlermeldung aus!
An dieser Stelle sind wir sehr tief in die Kommunikation des Managers mit dem LDAP eingestiegen und haben Netzwerkverkehr mitgeschnitten, analysiert und an den GS Support geschickt. An dieser Stelle ein ernst gemeinter Dank an den Support in München und ausdrücklich kein Dank an den Support im GS HQ. Mehr sag ich dazu nicht!
Wir haben das, was jetzt folgt, in verschiedenen Architekturbüros in verschiedenen Konfigurationen getestet. Das Ergebnis ist jedes mal gleich: läuft der Manager in einer VM gibt es Timing-Probleme in der Synchronisation mit dem LDAP. Egal ob Mac oder Windows oder ob die Netzwerkkarte durchgereicht wird oder virtualisiert ist. Nur beim Einsatz echter Hardware funktioniert der Manager tadellos.
Puh. In dieses Ergebnis sind von drei Leuten dutzende von Stunden reingelaufen, Gigabyte-weise Logdateien an GS HQ geschickt worden und tausende Euro versenkt worden. Und das Problem mit den Timings in der VM ist immer noch nicht gelöst. In den letzten Versionen ist es zwar besser geworden - aber ich bekomme nachvollziebar immer noch Fehler. Daher werde ich jetzt den Manager auf einen neuen Server umziehen und hoffen, dass es sich damit erledigt. Auch wenn alle anderen Dienste auf dem alten Server die ebenfalls den LDAP abfragen (Mail, Filesharing, Nextcloud, Kalender, Adressen, zentrales Login, Zeiterfassung, ...) tadellos funktionieren ...
Also, wer Fragen hat, darf mir gerne eine pm schicken.
Keine Antwort gefunden?
Andere Beiträge
im Board ansehen
Zurück zum Board
Neueste Lösungen durchsuchen
Akzeptierte Lösungen zeigenEine neue Diskussion starten!
Neues Thema erstellen