Nachdem Sie die Einstellungen für die Zwei-Faktor-Authentifizierung in der Gateway-Konfiguration eines Horizon Cloud-Pods festgelegt haben, müssen Sie auch das entsprechende Zwei-Faktor-Authentifizierungssystem konfigurieren, um Authentifizierungsanforderungen zuzulassen, die von bestimmten Gateway-bezogenen IP-Adressen übermittelt werden.

Die Unified Access Gateway-Instanzen des Gateways werden versuchen, von bestimmten IP-Adressen aus mit Ihrem Zwei-Faktor-Authentifizierungsserver zu kommunizieren. Ihr Netzwerkadministrator bestimmt die Netzwerksichtbarkeit des Zwei-Faktor-Authentifizierungsservers für das virtuelle Azure-Netzwerk (VNet) und die Subnetze des Pods. Die Kombination aus dieser Netzwerksichtbarkeit und dem Pod-Gateway-Typ (extern oder intern) bestimmt die spezifischen Gateway-bezogenen IP-Adressen, die Sie in Ihrer Zwei-Faktor-Authentifizierungsserverkonfiguration konfigurieren müssen, damit diese Kommunikation akzeptiert werden kann.

Wichtig:

Sie müssen der Dokumentation folgen, die für Ihr Zwei-Faktor-Authentifizierungssystem geeignet ist.

Ein RADIUS-Zwei-Faktor-Authentifizierungssystem verwendet das Konzept der zulässigen RADIUS-Clients. Beispiel: Wie im FreeRADIUS-Wiki für die FreeRADIUS-Client-Konfiguration beschrieben, enthält die /etc/raddb/clients.conf-Datei die Definitionen der RADIUS-Clients wie folgt:
client NAME {
  ipaddr = IPADDRESS
  secret = SECRET
}

Ein RSA SecurID-Zwei-Faktor-Authentifizierungssystem verwendet das Konzept der Authentifizierungsagenten, die für die Kommunikation mit RSA Authentication Manager registriert sind. Beispiel: Wie in der SecurID Authentication Manager-Dokumentation – Hinzufügen eines Authentifizierungsagenten beschrieben, verwenden Sie die Sicherheitskonsole von RSA Authentication Manager, um der internen Datenbank die erforderlichen IP-Adressen hinzuzufügen.

In diesem Thema werden die Informationen aus Ihrem Horizon Cloud-Pod beschrieben, die Sie in Ihrem Zwei-Faktor-Authentifizierungsserver verwenden müssen, um die Kommunikation mit dem Pod-Gateway zu ermöglichen und auch die Stabilität dieser Kommunikation nach jeder Pod-Aktualisierung aufrechtzuerhalten.

Zum Akzeptieren der Kommunikation aus den Unified Access Gateway-Instanzen der Gateway-Konfiguration müssen Zwei-Faktor-Authentifizierungsserver die Kommunikation von den entsprechenden IP-Adressen zulassen.

In der Regel legt Ihr Netzwerkadministrator fest, welche Netzwerkzugriffe der Zwei-Faktor-Authentifizierungsserver auf das VNet und die Subnetze hat, die mit dem bereitgestellten Pod verbunden sind. Die spezifischen Quell-IPs, die von den Unified Access Gateway-Instanzen beim Kontaktieren des Zwei-Faktor-Authentifizierungsservers verwendet werden, sind abhängig von folgenden Faktoren:

  • Ob Sie einen RADIUS- oder RSA SecurID-Typ in der Gateway-Konfiguration konfiguriert haben.
  • Ob die Gateway-Konfiguration intern oder extern ist
  • Ob Ihr Netzwerkadministrator den Zwei-Faktor-Authentifizierungsserver so konfiguriert hat, dass er von innerhalb des Pods-VNet aus erreichbar ist, oder ob er sich außerhalb des VNet befindet
  • Über welches Subnetz des Pods in diesem VNet Ihr Netzwerkadministrator den Zugang zum Zwei-Faktor-Authentifizierungsserver konfiguriert hat, wenn der Zwei-Faktor-Authentifizierungsserver über das Pod-VNet erreichbar ist
RSA SecurID – Externe und interne Gateway-Konfigurationen
Der RSA Authentication Manager-Server sieht die Kommunikation von den Netzwerkkarten auf den einzelnen Unified Access Gateway-Instanzen. Registrieren Sie in der RSA Authentication Manager-Konfiguration die folgenden NIC-IP-Adressen als Authentifizierungs-Agents:
  • Bei einem externen Gateway die vier Netzwerkkarten im dmz-Subnetz des Gateways
  • Bei einem internen Gateway die vier Netzwerkkarten im tenant-Subnetz des Gateways.
RADIUS – Interne Gateway-Konfiguration
Die für eine interne Gateway-Konfiguration bereitgestellten Unified Access Gateway-Instanzen verwenden die privaten IP-Adressen Ihrer Netzwerkkarten, um diesen Zwei-Faktor-Authentifizierungsserver zu kontaktieren. Der Zwei-Faktor-Authentifizierungsserver sieht die Anforderungen von Quell-IP-Adressen, die den privaten IP-Adressen der Netzwerkkarten entsprechen. Ihr Netzwerkadministrator hat konfiguriert, ob über den Pod-Verwaltungs-IP-Adressbereich oder den Mandanten-Subnetz-IP-Bereich auf diesen Server zugegriffen werden kann. Die Ressourcengruppe des internen Gateways in Microsoft Azure verfügt über vier (4) Netzwerkkarten, die diesem Subnetz entsprechen: zwei, die derzeit für die beiden Unified Access Gateway-Instanzen aktiv sind, und zwei Netzwerkkarten, die sich im Leerlauf befinden und aktiv werden, nachdem der Pod eine Aktualisierung durchlaufen hat. Um die Kommunikationskonnektivität zwischen dem Gateway und dem Zwei-Faktor-Authentifizierungsserver sowohl für laufende Pod-Vorgänge als auch nach jeder Pod-Aktualisierung beizubehalten, müssen Sie diesen Server so konfigurieren, dass Clientverbindungen von den IP-Adressen der vier Netzwerkkarten in der Ressourcengruppe des internen Gateways in Microsoft Azure zugelassen werden, die dem Subnetz entsprechen, das für diesen Server sichtbar ist. Weitere Informationen finden Sie im folgenden Abschnitt Zulassen der Kommunikation von den IP-Adressen der Pod-Gateway-Netzwerkkarten.
Hinweis: Fügen Sie für einen auf dem internen Gateway konfigurierten RSA SecurID-Typ die NIC-IP-Adressen für die vier Netzwerkkarten im Mandantensubnetz hinzu.
RADIUS – Externe Gateway-Konfiguration und der Zwei-Faktor-Authentifizierungsserver ist innerhalb des VNet des Pods zugänglich
Wenn Ihr Netzwerkadministrator den Zwei-Faktor-Authentifizierungsserver so konfiguriert hat, dass er auf demselben VNet wie der Pod verfügbar ist, verwenden die Unified Access Gateway-Instanzen die privaten IP-Adressen Ihrer Netzwerkkarten, um diesen Server zu kontaktieren. Der Zwei-Faktor-Authentifizierungsserver sieht die Anforderungen von Quell-IP-Adressen, die den privaten IP-Adressen der Netzwerkkarten entsprechen. Ihr Netzwerkadministrator hat konfiguriert, ob über den Pod-Verwaltungs-IP-Adressbereich, den Mandanten-Subnetz-IP-Bereich oder den DMZ-Subnetz-IP-Bereich auf den Server zugegriffen werden kann. Die Ressourcengruppe des externen Gateways in Microsoft Azure verfügt über vier (4) Netzwerkkarten, die diesem Subnetz entsprechen: zwei, die derzeit für die beiden Unified Access Gateway-Instanzen aktiv sind, und zwei, die sich im Leerlauf befinden und aktiv werden, nachdem der Pod eine Aktualisierung durchlaufen hat. Um die Kommunikationskonnektivität zwischen dem Gateway und dem Zwei-Faktor-Authentifizierungsserver sowohl für laufende Pod-Vorgänge als auch nach jeder Pod-Aktualisierung beizubehalten, müssen Sie diesen Server so konfigurieren, dass Clientverbindungen von den IP-Adressen der vier Netzwerkkarten in der Ressourcengruppe des externen Gateways in Microsoft Azure zugelassen werden, die dem Subnetz entsprechen, das für diesen Server sichtbar ist. Weitere Informationen finden Sie im folgenden Abschnitt Zulassen der Kommunikation von den IP-Adressen der Pod-Gateway-Netzwerkkarten.
RADIUS – Externe Gateway-Konfiguration und der Zwei-Faktor-Authentifizierungsserver ist außerhalb des VNet des Pods zugänglich
Wenn Ihr Netzwerkadministrator den Zwei-Faktor-Authentifizierungsserver außerhalb des VNet des Pods konfiguriert hat, verwenden die Unified Access Gateway-Instanzen der externen Gateway-Konfiguration die IP-Adresse der Azure-Lastausgleichsdienstressource des externen Gateways, um diesen Server zu kontaktieren. Sie müssen diesen Server so konfigurieren, dass Clientverbindungen von der IP-Adresse des externen Gateways der Lastausgleichsdienstressource zugelassen werden. Weitere Informationen finden Sie im folgenden Abschnitt Zulassen der Kommunikation vom Lastausgleichsdienst des externen Gateways.

Zulassen der Kommunikation von den IP-Adressen der Pod-Gateway-Netzwerkkarten

Wenn der Pod bereitgestellt wird, erstellt der Pod-Bereitsteller einen Satz von Netzwerkkarten in der Ressourcengruppe des Gateways in Ihrem Microsoft Azure-Abonnement. Die folgenden Screenshots zeigen Beispiele für die Netzwerkkarten für den internen Gateway-Typ und den externen Gateway-Typ. Auch wenn die Pod-ID in diesen Screenshots verpixelt ist, können Sie das Muster sehen, nach dem der Bereitsteller die Netzwerkkarten mit den Namen -management, -tenant und -dmz benennt. Die Namen der Ressourcengruppen des Pods finden Sie unter First-Gen-Mandanten – Für einen in Microsoft Azure bereitgestellten Pod erstellte Ressourcengruppen.


Screenshot der Netzwerkkarten und VMs, die der Pod-Bereitsteller für eine interne Gateway-Konfiguration erstellt.


Screenshot der Netzwerkkarten und VMs, die der Pod-Bereitsteller für eine externe Gateway-Konfiguration erstellt.

Sie müssen die IP-Adressen der Netzwerkkarten für die Gateway-Konfiguration abrufen, auf der Sie die Zwei-Faktor-Authentifizierungseinstellungen aktiviert haben, die dem Subnetz entspricht, das über Netzwerksichtbarkeit für den Zwei-Faktor-Authentifizierungsserver verfügt, und diese IP-Adressen als zugelassene Clients in der Konfiguration Ihres Zwei-Faktor-Authentifizierungsservers angeben.

Wichtig: Um eine Unterbrechung der Konnektivität zwischen Ihrem Zwei-Faktor-Authentifizierungsserver und dem Pod nach einer Aktualisierung zu vermeiden, müssen Sie für jedes Gateway, das Sie mit Zwei-Faktor-Authentifizierunseinstellungen konfiguriert haben, sicherstellen, dass die IP-Adressen der unten beschriebenen vier (4) Netzwerkkarten als zugelassene Clients in der Konfiguration Ihres Zwei-Faktor-Authentifizierungsservers angegeben sind. Es ist zwar nur die Hälfte der Netzwerkkarten während der laufenden Pod-Vorgänge aktiv, aber diese werden gewechselt, wenn der Pod aktualisiert wird. Nach einer Pod-Aktualisierung wird die andere Hälfte der Netzwerkkarten aktiv, und die vor der Aktualisierung aktiven Netzwerkkarten werden bis zur nächsten Pod-Aktualisierung inaktiv. Dann wird erneut gewechselt. Wenn Sie nicht alle Netzwerkkarten-IP-Adressen, also die aktiven sowie auch die inaktiven, zu der Konfiguration Ihres Zwei-Faktor-Authentifizierungsservers hinzugefügt haben, lehnt der Zwei-Faktor-Authentifizierungsserver Verbindungsanforderungen aus der aktuell aktiven Gruppe von Netzwerkkarten nach der Pod-Aktualisierung ab, und der Anmeldevorgang für Endbenutzer, die dieses Gateway verwenden, wird unterbrochen.

So rufen Sie die Netzwerkkarten-IP-Adressen des Gateways ab, die zur Konfiguration des Zwei-Faktor-Authentifizierungsservers hinzugefügt werden sollen:

  1. Holen Sie von Ihrem Netzwerkadministrator die Informationen darüber ein, welche der Subnetze des Pods über Netzwerksichtbarkeit zum Zwei-Faktor-Authentifizierungsserver (Verwaltung, Mandant oder DMZ) verfügen.
  2. Melden Sie sich beim Microsoft Azure-Portal für Ihr Abonnement an und suchen Sie die Ressourcengruppe des Gateways.
  3. Für die Netzwerkkarten, die dem Subnetz entsprechen, das laut Ihrem Netzwerkadministrator über Sichtbarkeit für den Zwei-Faktor-Authentifizierungsserver verfügt, klicken Sie auf die einzelnen Netzwerkkarten und kopieren Sie deren IP-Adresse.
  4. Beachten Sie die Dokumentation für Ihr Zwei-Faktor-Authentifizierungssystem, um diese IP-Adressen hinzuzufügen, damit der Zwei-Faktor-Authentifizierungsserver die Kommunikation von diesen Netzwerkkarten akzeptiert.
Beispiel für das Hinzufügen der IP-Adressen der Netzwerkkarten des Gateways bei Verwendung eines RADIUS-Zwei-Faktor-Authentifizierungsservers
Der folgende Codeblock veranschaulicht einen Teil der Client-Konfigurationszeilen für die Netzwerkkarten mit IP-Adressen im Mandanten-Subnetz des Pods für ein internes Gateway, bei dem der Netzwerkadministrator den RADIUS-Server im selben VNet wie der Pod und Zugriff über das Mandanten-Subnetz des Pods konfiguriert hat. Das Mandanten-Subnetz des Pods wurde als 192.168.25.0/22 konfiguriert, als dieser Pod bereitgestellt wurde. Wenn der Pod anfänglich bereitgestellt wird, sind NIC1 und NIC2 aktiv und NIC3 und NIC4 inaktiv. Allerdings werden alle vier Netzwerkkarten zur RADIUS-Serverkonfiguration hinzugefügt, um sicherzustellen, dass der RADIUS-Server nach der Pod-Aktualisierung, wenn NIC3 und NIC4 aktiv und NIC1 und NIC2 inaktiv werden, weiterhin Verbindungen von diesem Gateway akzeptiert. Beachten Sie, dass Sie die für Ihren RADIUS-Server geeignete Syntax verwenden müssen.
client UAGTENANTNIC1 {
  ipaddr = 192.168.25.5
  secret = myradiussecret
}
client UAGTENANTNIC2 {
  ipaddr = 192.168.25.6
  secret = myradiussecret
}
client UAGTENANTNIC3 {
  ipaddr = 192.168.25.7
  secret = myradiussecret
}
client UAGTENANTNIC4 {
  ipaddr = 192.168.25.8
  secret = myradiussecret
}

RADIUS-Zwei-Faktor-Authentifizierung – Zulassen der Kommunikation vom Lastausgleichsdienst des externen Gateways

Wenn sich der Zwei-Faktor-Authentifizierungsserver außerhalb des VNet des Pods befindet, müssen Sie für das externe Gateway, auf dem Sie diesen Server angegeben haben, die öffentliche IP-Adresse der Azure-Lastausgleichsdienstressource des externen Gateways als zulässigen Client in der Konfiguration dieses Zwei-Faktor-Authentifizierungsservers hinzufügen. Sie können die IP-Adresse des Lastausgleichs mithilfe des Microsoft Azure-Portals abrufen und die Lastausgleich-Ressource in der Ressourcengruppe des Gateways suchen.

  1. Melden Sie sich beim Microsoft Azure-Portal für Ihr Abonnement an und suchen Sie die Ressourcengruppe des Gateways.
  2. Klicken Sie in der Ressourcengruppe des Gateways auf die Lastausgleich-Ressource. Ihr Name entspricht dem Muster vmw-hcs-podID-uag-lb. Ihre IP-Adresse wird in den Übersichtsinformationen aufgeführt.
  3. Beachten Sie die Dokumentation für Ihren Typ des Zwei-Faktor-Authentifizierungssystems, um die IP-Adresse des Gateways für den Lastausgleichsdienst hinzuzufügen, damit der Zwei-Faktor-Authentifizierungsserver Kommunikationen von dieser IP-Adresse akzeptiert.
Beispiel für das Hinzufügen der IP-Adresse des externen Gateways für den Lastausgleichsdienst bei Verwendung eines RADIUS-Zwei-Faktor-Authentifizierungsservers
Der folgende Codeblock ist ein Beispiel zur Veranschaulichung. Beachten Sie, dass Sie die für Ihren RADIUS-Server geeignete Syntax verwenden müssen.
client MYPODUAGEXTLBIP {
  ipaddr = 52.191.236.223
  secret = myradiussecret
}