Weg 1:
Der populäre Weg
Man verwendet eine LDAPS Policy für den LDAPS Server und gibt diesem die Ziel IP des Active Directory Servers, per TLS und mit dem Zielport 636.
Nachteile:
- Es herrscht keine Redundanz, weil kein Load-Balancing vorhanden ist, da der Server direkt angesprochen wird.
- Der NetScaler benutzt die Management-CPU für die TLS-Kommunikation. Das kann eine ziemliche Belastung darstellen, da die CPU nicht insgesamt dafür optimiert wurde. Ob dem so ist, lässt sich leicht überprüfen, indem man sich die Konfiguration der Kommunikation mit dem Backend ansieht. Läuft die SourceIP über NSIP statt über SNIP, ist die Management-CPU für die TLS-Berechnungen zuständig.
Workaround:
- Mehrere LDAPS-Policies hintereinander binden, um auf diese Weise eine Redundanz zu erreichen.
Nachteile Workaround:
- Wird ein Passwort falsch eingegeben, wird es gegen die seriell abgearbeiteten LDAPS-Server n-mal versucht zu validieren. Das Ergebnis ist ein um n * Anzahl LDAPS-Server erhöhter Fehlercount.
Weg 2:
Klassisches Load-Balancing
Die TLS-Verbindung an den LDAPS-vServer via SSL_TCP anbinden.
Vorteile:
- Redundanz, da Load-Balancing.
- SNIP als Source.
Nachteil:
- NetScaler nutzt die Management-CPU zur TLS-Kommunikation, was sie belastet und wofür sie insgesamt nicht optimiert wurde.
Weg 3:
Performance
Wir verlagern die rechenintensive Kommunikation per SSL_TCP auf die Paket-Engine des NetScalers und entlasten damit die Management-CPU, aber erkaufen uns auch einen Nachteil.
Kommunikation per Plaintext LDAP zum LoadBalancing vServer, der entsprechend per TCP konfiguriert ist. Die Services hingegen sind per SSL_TCP konfiguriert um transportverschlüsselt zwischen den ADCs und den Domain-Controllern zu kommunizieren.
Vorteil:
- Wiedererlangte Redundanz.
- Die Paket-Engine übernimmt die rechenintensive und verschlüsselte Kommunikation per SSL_TCP zu den Domain-Controllern.
- SNIP als Source.
Nachteil:
- NetScaler arbeitet intern ohne Verschlüsselung.
