Product Documentation

Erstellen eines einzelnen vollqualifizierten Domänennamens (FQDN) für den internen und externen Zugriff auf einen Store

Jul 07, 2016
Hinweis: Die folgenden Versionen sind erforderlich, damit Sie dieses Feature mit einem nativen Receiver für Desktop verwenden können.
  • Windows Receiver 4.2
  • MAC Receiver 11.9

Sie können Zugriff auf Ressourcen aus dem Unternehmensnetzwerk und aus dem Internet durch ein NetScaler Gateway ermöglichen und die Benutzererfahrung durch Erstellen eines einzelnen FQDN für interne und externen Roamingclients vereinfachen.

Ein einzelner FQDN ist nützlich für Benutzer, die eine systemeigene Receiver-Version verwenden. Sie müssen sich nur eine URL merken, unabhängig davon, ob sie mit einem internen oder öffentlichen Netzwerk verbunden sind.

StoreFront-Beacons für systemeigene Receiver-Versionen

Citrix Receiver versucht eine Kontaktaufnahme mit den Beacons und ermittelt anhand der Antworten, ob Benutzer mit lokalen oder öffentlichen Netzwerken verbunden sind. Wenn ein Benutzer auf einen Desktop oder eine Anwendung zugreift, werden die Standortinformationen an den Server mit der Ressource weitergegeben, sodass die entsprechenden Verbindungsinformationen an Citrix Receiver zurückgegeben werden können. Dadurch wird sichergestellt, dass Benutzer nicht aufgefordert werden, sich neu anmelden, wenn sie auf einen Desktop oder eine Anwendung zugreifen. Weitere Informationen zur Konfiguration von Beacons finden Sie unter Konfigurieren von Beacons.

Konfigurieren des virtuellen NetScaler Gateway-Servers und SSL-Zertifikats

Der gemeinsame FQDN wird entweder in die IP des Routers für die externe Firewall aufgelöst oder in die IP eines virtuellen NetScaler Gateway-Servers in der DMZ, wenn Clients versuchen, auf Ressourcen von außerhalb des Unternehmensnetzwerks zuzugreifen. Stellen Sie sicher, dass die Felder Common Name und Subject Alternative Name des SSL-Zertifikats den gemeinsamen FQDN für den externen Zugriff auf den Store enthalten. Bei Verwendung einer Drittanbieter-Stammzertifizierungsstelle (z. B. VeriSign) anstelle der unternehmenseigenen Zertifizierungsstelle zum Signieren des Gateway-Zertifikats vertrauen alle externen Clients automatisch dem an den virtuellen Gateway-Server gebundenen Zertifikat. Bei Verwendung einer Drittanbieter-Stammzertifizierungsstelle wie VeriSign müssen keine zusätzlichen Stammzertifizierungsstellen-Zertifikate auf externen Clients importiert werden.

Überlegen Sie beim Bereitstellen eines einzelnen Zertifikats mit dem Common Name des gemeinsamen FQDN für NetScaler Gateway und den StoreFront-Server, ob Sie Remotediscovery unterstützen möchten. Falls ja, muss das Zertifikat der Spezifikation für alternative Antragstellernamen entsprechen.

Beispiel für ein Zertifikat für den virtuellen NetScaler Gateway-Server: storefront.example.com
  1. Stellen Sie sicher, dass der gemeinsame FQDN, die Callback-URL und die Kontenalias-URL im DNS-Feld des Zertifikats als alternativer Antragstellername (Subject Alternative Name, SAN) enthalten ist.
  2. Stellen Sie sicher, dass der private Schlüssel exportierbar ist, sodass Zertifikat und Schlüssel in NetScaler Gateway importiert werden können.
  3. Stellen Sie sicher, dass "Default Authorization" auf "Allow" festgelegt ist.
  4. Signieren Sie das Zertifikat durch eine Drittanbieter-Zertifizierungsstelle wie etwa VeriSign oder eine Stammzertifizierungsstelle Ihres Unternehmens.

Beispiel-SANs für Servergruppen mit zwei Knoten:

storefront.example.com (erforderlich)

storefrontcb.example.com (erforderlich)

accounts.example.com (erforderlich)

storefrontserver1.example.com (optional)

storefrontserver2.example.com (optional)

Signieren Sie das SSL-Zertifikat des virtuellen NetScaler Gateway-Servers durch eine Zertifizierungsstelle.

Je nach Ihren Anforderungen haben Sie zwei Optionen zur Auswahl der Art des signierten Zertifikats.

  • 1. Von einer Drittanbieter-Zertifizierungsstelle signiertes Zertifikat: Wenn das an den virtuellen NetScaler Gateway-Server gebundene Zertifikat von einem vertrauenswürdigen Drittanbieter signiert wurde, muss auf externen Clients wahrscheinlich KEIN Stammzertifizierungsstellenzertifikat in den Speicher vertrauenswürdiger Stammzertifizierungsstellen kopiert werden. Auf Windows-Clients sind die Zertifikate der gängigen Stammzertifizierungsstellen vorinstalliert. Beispiele kommerzieller Drittanbieter-Zertifizierungsstellen, die verwendet werden können, sind DigiCert, Thawte und VeriSign. Auf mobile Geräte wie iPads, iPhones und Android-Tablets/-Telefone müssen Stammzertifizierungsstellenzertifikate jedoch möglicherweise kopiert werden, damit diese Geräte dem virtuellen NetScaler Gateway-Server vertrauen.
  • 2. Von einer Unternehmens-Stammzertifizierungsstelle signiertes Zertifikat: Wenn Sie diese Option wählen, muss das Zertifikat auf allen externen Clients in den Speicher vertrauenswürdiger Stammzertifizierungsstellen kopiert werden. Bei Verwendung mobiler Geräte mit systemeigener Receiver-Version (z. B. iPhones und iPads) erstellen Sie ein Sicherheitsprofil auf diesen Geräten.

Importieren des Stammzertifikats auf mobilen Geräten

  • Auf iOS-Geräten können CER x.509-Zertifikatdateien als E-Mail-Anlagen importiert werden, da der Zugriff auf den lokalen Speicher solcher Geräte normalerweise nicht möglich ist.
  • Android-Geräte erfordern das gleiche CER x.509-Format. Das Zertifikat kann aus dem lokalen Speicher des Geräts oder als E-Mail-Anlage importiert werden.

Externes DNS: storefront.example.com

Stellen Sie sicher, dass die DNS-Auflösung Ihres Internetdienstanbieters in die externe IP des Firewallrouters am äußeren Rand der DMZ bzw. in die virtuelle IP-Adresse des virtuellen NetScaler Gateway-Servers auflöst.

Split-View DNS

  • Wenn Split-View DNS richtig konfiguriert ist, sendet die Quelladresse der DNS-Anfrage den Client zum richtigen DNS Alias-Datensatz.
  • Wenn Clients zwischen öffentlichen Netzwerken und Unternehmensnetzwerken wechseln, sollte sich ihre IP ändern. Abhängig von dem Netzwerk, mit dem sie verbunden sind, sollten sie bei der Anfrage bei storefront.example.com den richtigen Alias-Datensatz erhalten.

Importieren von Zertifikaten von einer Windows-Zertifizierungsstelle in NetScaler Gateway

WinSCP ist ein nützliches und kostenloses Drittanbietertool zum Verschieben von Dateien von einer Windows-Maschine in ein NetScaler Gateway-Dateisystem. Kopieren Sie Zertifikate für den Import in den Ordner /nsconfig/ssl/ im NetScaler Gateway-Dateisystem. Sie können mit den OpenSSL-Tools in NetScaler Gateway das Zertifikat und den Schlüssel aus einer PKCS12/PFX-Datei extrahieren, um eine CER- und eine KEY X.509-Datei separat im PEM-Format zu erstellen, die von NetScaler Gateway verwendet werden können.

  1. Kopieren Sie die PFX-Datei in den Ordner /nsconfig/ssl auf dem NetScaler Gateway-Gerät in VPX.
  2. Öffnen Sie die NetScaler Gateway-Befehlszeilenschnittstelle.
  3. Zum Wechseln in die FreeBSD-Shell geben Sie Shell ein, um die NetScaler Gateway-Befehlszeilenschnittstelle zu verlassen.
  4. Geben Sie zum Wechseln des Verzeichnisses cd /nsconfig/ssl ein.
  5. Führen Sie openssl pkcs12 -in <imported cert file>.pfx -nokeys -out <certfilename>.cer aus und geben Sie bei entsprechender Aufforderung das PFX-Kennwort ein.
  6. Führen Sie openssl pkcs12 -in <imported cert file>.pfx -nocerts -out <keyfilename>.key aus.
  7. Geben Sie bei Aufforderung das PFX-Kennwort ein und legen Sie eine PEM- Passphrase für den privaten Schlüssel zum Schutz der KEY-Datei fest.
  8. Um sicherzustellen, dass die CER- und die KEY-Datei erfolgreich erstellt wurden, führen Sie in /nsconfig/ssl/ den Befehl ls –al aus.
  9. Geben Sie Exit ein, um zur NetScaler Gateway-Befehlszeilenschnittstelle zurückzukehren.

Native Gateway-Sitzungsrichtlinie für Receiver für Windows/Mac

REQ.HTTP.HEADER User-Agent CONTAINS CitrixReceiver && REQ.HTTP.HEADER X-Citrix-Gateway EXISTS

Sitzungsrichtlinie für Receiver für Web

REQ.HTTP.HEADER User-Agent NOTCONTAINS CitrixReceiver && REQ.HTTP.HEADER Referer EXISTS

CVPN- und SmartAccess-Einstellungen

Wenn Sie SmartAccess verwenden, aktivieren Sie den SmartAccess-Modus auf der Eigenschaftenseite des virtuellen NetScaler Gateway-Servers. Für jeden gleichzeitigen Benutzer, der auf Remoteressourcen zugreift, ist eine universelle Lizenz erforderlich.

Receiver-Profil

Konfigurieren Sie als Kontodienst-URL für das Sitzungsprofil https://accounts.example.com/Citrix/Roaming/Accounts und NICHT https://storefront.example.com/Citrix/Roaming/Accounts.

Fügen Sie diese URL zudem für <allowedAudiences> in den web.config-Dateien für Authentifizierung und Roaming auf dem StoreFront-Server hinzu. Weitere Informationen finden Sie unten im Abschnitt "Konfigurieren der Host-Basis-URL des StoreFront-Servers, des Gateways und des SSL-Zertifikats".

Receiver für Web-Profil

ICA-Proxy-Einstellung und Moduseinstellung "Basic"

Wenn Sie den ICA-Proxy verwenden, aktivieren Sie den Modus "Basic" auf der Eigenschaftenseite des virtuellen NetScaler Gateway-Servers. Es ist nur eine NetScaler-Plattformlizenz erforderlich.

Receiver-Profil

Receiver für Web-Profil

Konfigurieren der Host-Basis-URL des StoreFront-Servers, des Gateways und des SSL-Zertifikats

Wenn ein StoreFront-Cluster oder eine einzelne StoreFront-IP zum Hosten des Stores erstellt wurde, muss der gemeinsame FQDN, der in den virtuellen NetScaler Gateway-Server aufgelöst wird, auch direkt in den StoreFront-Load Balancer aufgelöst werden.

Internes DNS: Erstellen Sie drei DNS Alias-Datensätze.

  • storefront.example.com muss in den StoreFront-Load Balancer bzw. die IP des einzelnen StoreFront-Servers aufgelöst werden.
  • storefrontcb.example.com muss in die virtuelle IP-Adresse des virtuellen Gatewayservers aufgelöst werden. Treffen Sie daher entsprechende Vorkehrungen, wenn zwischen DMZ und lokalem Unternehmensnetzwerk eine Firewall sitzt.
  • accounts.example.com – erstellen Sie ein DNS-Alias für storefront.example.com. Dieses wird außerdem in die IP des Load Balancers für das StoreFront-Cluster bzw. die IP eines einzelnen StoreFront-Servers aufgelöst.

Beispielzertifikat für den StoreFront-Server: storefront.example.com

  1. Erstellen Sie ein geeignetes Zertifikat für den StoreFront-Server bzw. die StoreFront-Servergruppe, bevor Sie StoreFront installieren.
  2. Tragen Sie den gemeinsamen FQDN in die Felder "Common Name" und "DNS" ein. Dieser muss mit dem FQDN in dem zuvor erstellten, an den virtuellen NetScaler Gateway-Server gebundenen SSL-Zertifikat übereinstimmen oder verwenden Sie das gleiche an den virtuellen NetScaler Gateway-Server gebundene Zertifikat.
  3. Fügen Sie dem Zertifikat das Kontenalias (accounts.example.com) als weiteren SAN hinzu. Das Kontenalias im SAN ist das zuvor im NetScaler Gateway-Sitzungsprofil (s. Sitzungsrichtlinie und -profil für systemeigenes Receiver-Gateway) verwendete Alias.

  4. Stellen Sie sicher, dass der private Schlüssel exportierbar ist, damit das Zertifikat auf einen anderen Server oder auf StoreFront-Servergruppenknoten übertragen werden kann.

  5. Signieren Sie das Zertifikat durch eine Drittanbieter-Zertifizierungsstelle (z. B. VeriSign), eine Stammzertifizierungsstelle Ihres Unternehmens oder eine Zwischenzertifizierungsstelle.
  6. Exportieren Sie das Zertifikat im PFX-Format einschließlich des privaten Schlüssels.
  7. Importieren Sie das Zertifikat und den privaten Schlüssel auf den StoreFront-Server. Wenn Sie ein Windows-NLB-StoreFront-Cluster bereitstellen, importieren Sie das Zertifikat auf jeden Knoten. Wenn Sie einen anderen Load Balancer verwenden, z. B. einen virtuellen NetScaler-LB-Server, importieren Sie das Zertifikat auf diesen.
  8. Erstellen Sie auf dem StoreFront-Server eine HTTPS-Bindung in IIS und binden Sie das importierte SSL-Zertifikat an diese.

  9. Konfigurieren Sie die Host-Basis-URL auf dem StoreFront-Server entsprechend dem bereits gewählten gemeinsamen FQDN.
    Hinweis: StoreFront wählt immer automatisch den letzten alternativen Antragstellernamen in der SAN-Liste in dem Zertifikat. Dies ist lediglich eine empfohlene Host-Basis-URL zur Unterstützung von StoreFront-Administratoren und i. d. R. korrekt. Sie können sie manuell auf einen beliebigen HTTPS://<FQDN> festlegen, vorausgesetzt, dieser ist im Zertifikat als SAN eingetragen. Beispiel: https://storefront.example.com

Konfigurieren des Gateways auf dem StoreFront-Server: storefront.example.com

  1. Geben Sie den gemeinsamen FQDN im Dialogfeld zur Gateway-Konfiguration unter NetScaler Gateway URL ein.
  2. Geben Sie den Callback-FQDN im Dialogfeld zur Gateway-Konfiguration unter Callback-URL ein.

  3. Geben Sie eine Liste der Secure Ticket Authority-Server (STA) ein, die der Liste der im Store-Knoten bereits konfigurierten Delivery Controller entspricht.
  4. Aktivieren Sie den Remotezugriff für den Store.
  5. Legen Sie den internen Beacon manuell auf das Kontenalias (accounts.example.com) fest. Er darf nicht von außerhalb des Gateways auflösbar sein. Dieser FQDN muss sich von dem externen Beacon unterscheiden, der von der StoreFront-Host-Basis-URL und dem virtuellen NetScaler Gateway-Server (storefront.example.com) gemeinsam verwendet wird. Verwenden Sie NICHT den gemeinsam verwendeten FQDN, da hierdurch der interne und der externe Beacon identisch werden.

  6. Wenn Sie die Discovery mit FQDNs unterstützen möchten, führen Sie die nachfolgenden Schritte aus. Wenn die Provisioningdateikonfiguration genügt oder Sie nur Receiver für Web verwenden, überspringen Sie die folgenden Schritte.

    Fügen Sie in C:\inetpub\wwwroot\Citrix\Authentication\web.config einen zusätzlichen -Eintrag ein. Die web.config-Datei für die Authentifizierung hat zwei -Einträge. Nur der erste Authentication Token Producer-Eintrag in der Datei erfordert einen zusätzlichen -Eintrag.

  7. Suchen Sie nach der Zeichenfolge "". Suchen Sie den unten gezeigten Eintrag, fügen Sie die fett dargestellte Zeile hinzu, speichern und schließen Sie die Datei web.config.
     ………… …………                                                
  8. C:\inetpub\wwwroot\Citrix\Roaming\web.config: Suchen Sie den unten gezeigten Eintrag, fügen Sie die fett dargestellte Zeile hinzu, speichern und schließen Sie die Datei web.config.
                         …………    …………                                                                                

Alternativ können Sie die Receiver-eigene CR-Provisioningdatei für den Store exportieren. Dadurch wird die Erstverwendungs-Konfiguration in systemeigenen Receiver-Versionen überflüssig. Verteilen Sie diese Datei an alle Windows- und MAC-Receiver-Clients.

Wenn Receiver auf einem Client installiert wird, wird der CR-Dateityp erkannt und die Provisioningdatei durch einen Doppelklick automatisch importiert.