Einer der Punkte bei der Kundenmigration zu Amazon Web Services war die Einbindung von SSO (Single Sign On) – eine sehr praktische Lösung. Nach einer schnellen Überprüfung unserer Fähigkeiten stellte sich heraus, dass wir ADFS verwenden können. Der Client hat ADFS bereits für andere Dienste verwendet, sodass wir die überzeugende Phase des Security Teams überspringen konnten. Nach mehreren Tagen voller Ping Federate Schwierigkeiten gelang es, SSO einzuschalten und eine schöne Umleitungsschleife durch das erwähnte ADFS zu machen. Zurückgegebene SAML hatte alles, was wir brauchen, und Windchill antwortete…“Fehler 500″. Eine eingehendere Lektüre der Dokumentation ergab, dass SSF mit ADFS natürlich von Windchill unterstützt wird, die Erstellung eines neuen Benutzers auf der Grundlage von SAML, der von ADFS erhalten wurde, jedoch nicht. Windchill benötigt zum Vergleichen eine Benutzerdatenbank. Am bequemsten ist es, einen Domänencontroller mit LDAP, vorzugsweise mit SSL, abzufragen.
Infrastruktur in AWS und Domänencontrollern in den Serverräumen des Clients
Es ist unwahrscheinlich, dass das Sicherheitsteam den Controller der Welt aussetzt, und wir müssen ihn irgendwie befragen. Man muss eine Verbindung zum VPN-Client und den Controllern über sichere LDAPs über den Tunnel herstellen. Das ist leider nicht so einfach. In AWS werden bereits mehrere Umgebungen ausgeführt, jede in einer anderen VPC und jede muss ihre Abfrage an AD senden.
Was tun, wie leben?
Es gab viele Varianten (dies sind nur einige):
- Transit Gateway zu verwenden und auf der Clientseite NAT durchzuführen
Leider stimmten die vorhandenen VPCs mit den Adressen des Clients in seinem Netzwerk überein. Natürlich könnte dies umgangen werden, aber die Zeit drängte, und der Spaß am Routing in einer globalen Organisation könnte Jahre dauern.
- Eine neue VPC mit einem Netzwerk hinzufügen, über das der Kunde noch nicht verfügt. Ein Routing durchzuführen, zwischen anderen VPCs zu blättern und dieser VPC ein VPN-Gateway hinzufügen.
Eine kurze Präsentation (die das Problem für den Kunden hervorhob) führte dazu, dass die Position entwickelt wurde, dass wir eine neue VPC erstellen, Routing durchführen, zwischen anderen VPCs blättern, VPN verbinden und den VPC AWS Directory Service darin einfügen.
Es war das gleiche, aber leider stellte sich heraus, dass die Einschränkungen des letzteren nicht wirklich eine LDAP-Abfrage über Objekte in der Domäne des Clients ermöglichen. Ja, ein kleiner Fehler. Ganz zu schweigen von der Einrichtung domänenübergreifender Trust Relationship.
In der Zwischenzeit haben wir, um die Entwicklung eines zusätzlichen Tools nicht zu blockieren, gewöhnliches Amazon Linux in VPC integriert und durch die Verwendung eines einfachen SSH-Tunnels mehrere Einschränkungen in Bezug auf das Fehlen von Transit-VPC in AWS umgangen.
Ein anderer Ansatz bestand darin, einen schreibgeschützten Clientdomänencontroller in AWS auszustellen. Diese Lösung ermöglichte den Zugriff auf die Anwendung auch bei Problemen mit VPN-Tunneln. Die Organisation des VPN verlief überraschend gut.
Wir dachten bereits, wir wären nah dran: ein schreibgeschützter Controller, der mit LDAP abgefragt werden konnte und alles war schön, aber nicht für den Security, die sich zuvor auf diese Option geeinigt hatte. Die Security weiß es und der öffentliche Schlüssel für die interne Zertifizierungsstelle wird uns nicht geben – ah, diese PKI…
Mit einer gewissen Emotion getragen, beschlossen wir, dass genug von diesem schönen Tanz. Schnelle Statusübersicht:
- VPC mit dem Client-Netzwerk verbunden – check
- Anmeldeinformationen für AD über LDAP – check
Was fehlt?
So etwas wie ein Active Directory LDAP-Proxy. Wir haben VPC mit VPN eingerichtet, LDAP-Abfragen in diesen Proxy geworfen, dann wurden wir reibungslos an das Client-AD weitergeleitet, und wir wussten, was los war!
Weitere 5 Stunden Test und TAADAAM – es funktioniert. OpenLDAP hat es geschafft. Überprüfung in Windchill und es ist vorbei. EC2 mit OpenLdap funktioniert und … im Grunde ist gelangweilt.
Hmm, wie wäre es, diesen Docker in einen Container zu stecken?
Hmm, vielleicht würde dieser Container in ECS laufen?
Hmm, alles in allem braucht persistenter Speicher das nicht, vielleicht Fargate?
Das Erstellen eines Containers mit LDAP-Proxy unter CentOS umfasst insgesamt einige Zeilen. Dann schnelles Hochladen zu ECR, Definition der Task und man kann eine Website erstellen.
Wie soll der Datenverkehr auf diese Site geleitet werden? Immerhin wird die IP jedes Mal anders sein. Vielleicht mit LoadBalancer? – nein.
Bei der Definition der Website kann man die Option „Service Discovery“ verwenden, mit der die Hosted Zone in Route53 erstellt und der „A“ -Datensatz aktualisiert wird, der zur Website führt – brillant. Jetzt muss man nur noch eine solche Hosted Zone an VPC mit Windchill anhängen und LDAPs-Abfragen an den dort registrierten Namen richten.
Um sich später nicht darum zu kümmern, genügt es, einen einfachen Healthcheck zu definieren, mit dem ECS den kaputten Container durch einen neuen ersetzt – in der Regel innerhalb einer Minute.
Wie hoch waren die Kosten?
- Option 1 mit AWS AD Service – ungefähr 90 USD / Monat
- Option 2 mit EC2, einem Domänencontroller im Read-Only Modus – ca. 80 USD / Monat
- Option 3 mit Container im Fargate-Startmodus – ca. 10 USD (0,25 CPU mit 1 GB RAM)
