abbrechen
Suchergebnisse werden angezeigt für 
Stattdessen suchen nach 
Meintest du: 
abbrechen
Suchergebnisse werden angezeigt für 
Stattdessen suchen nach 
Meintest du: 

Wir schätzen Ihren Input!
Bitte nehmen Sie an der Umfrage zu Archicad 28 Startbildschirm und Lerninhalte/Schnell-Tutorials teil

Teamwork & BIMcloud
Teamwork, BIMcloud, BIMcloud Basic, BIMcloud Software as a Service, Netzwerkeinstellungen, etc.

Gelöst (fast): BIMCloud und openLDAP/AD

torben_wadlinger
Virtuoso
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.
2 ANTWORTEN 2
Anonymous
Nicht anwendbar
Vielen Dank für die ausführlichen Erklärungen.

Virtualisierung schafft leider auch heute noch eine zusätzliche Komplexität. Von Containern fange ich gar nicht erst an. Meine persönliche Liste an Dingen, die bare metal laufen sollen sind: DC, Firewall, Storage, performante DBs. Bimserver kommt dank dir auch noch auf meine Liste.
torben_wadlinger
Virtuoso
Eine Sache hatte ich noch vergessen; den Reverse Proxy damit man die BIM Cloud via https erreicht.

Die BIM Cloud benutzt einen internen Webserver um den Dienst im internen Netzwerk zu nutzen. Dieser Webserver kommuniziert unverschlüsselt und das wäre eigentlich erstmal kein Problem, wenn es eine Möglichkeit gäbe innerhalb der BIM Cloud ein eigenes Zertifikat nachzurüsten. Diese Möglichkeit gibt es aber nicht.

Gehen wir mal davon aus, dass das eigene Netzwerk soweit sicher ist dass keine Netzwerkkommunikation belauscht werden kann, muss man sich trotzdem Gedanken machen, wie man z.B. aus dem home office oder in einer externen Besprechung auf die BIM Cloud von aussen sicher zugreifen kann.

Hier gibt es zwei Lösungen: VPN oder direkter Zugriff via Port-Weiterleitung. Beide Lösungen haben Stärken und Schwächen. Ich werde jetzt nicht erklären, wie man ein VPN oder eine Port-Weiterleitung herstellt, weil das hier über das Thema hinaus geht. Aber man sollte diese Dinge mit seinem Admin besprechen, denn das ist wichtig (auf vor dem Hintergrund der DSVGO und der generellen Sicherheit eines Netzwerks).

VPN (Virtuelles Privates Netzwerk)
Vorteil: sicherer Zugang zur gesamten Netzinfrastruktur, d.h. man arbeitet extern als wäre man intern.
Nachteil: die Verbindung muss dauerhaft sein. Kein Problem im home office, im Zug eher schwierig. Nach unserer Erfahrung ausserdem vergleichsweise langsam wenn mit großen Daten gearbeitet wird (trotz Ver- und Entschlüsselung über CPU-Crypto-Komponente).

HTTPS via Reverse Proxy
Vorteil: Schneller als VPN, bedient mehrere Dienste über den selben Port mit einem wildcard-Zertifikat
Nachteil: Erfordert einen Umbau des logischen Netzwerks, sofern noch kein Reverse Proxy eingesetzt wird, sowie profunde Kenntnisse in der IT-Administration allgemein.

Damit https überhaupt funktioniert, benötigt man ein entsprechendes Zertifikat. Diese Zertifikate kann man kaufen oder man kann sich bei letsencrypt ein solches kostenlos erstellen lassen. Persönlich empfehle ich den Einsatz eines kleinen Linux-Servers (z.B. innerhalb einer VM oder einen Raspi bzw. zwei davon, falls einer die Grätsche macht) und den Nginx Proxy Manager sowie den letsencrypt Certbot für das Zertifikat. Ich verlinke das weiter unten, damit man sich das nicht zusammen suchen muss. Aber um etwas Skripten kommt man nicht herum...

https://letsencrypt.org
https://certbot.eff.org/instructions
https://www.nginx.com