Benutzer verwalten

Durch das Definieren von Benutzern, Gruppen, Rollen und Berechtigungen können Sie steuern, wer Zugriff auf Ihre XenServer®-Hosts und -Pools hat und welche Aktionen diese ausführen können.

Wenn Sie XenServer zum ersten Mal installieren, wird automatisch ein Benutzerkonto zu XenServer hinzugefügt. Dieses Konto ist der lokale Superuser (LSU) oder Root, den XenServer lokal authentifiziert.

Der LSU oder Root ist ein spezielles Benutzerkonto, das für die Systemadministration vorgesehen ist und über alle Berechtigungen verfügt. In XenServer ist der LSU das Standardkonto bei der Installation. XenServer authentifiziert das LSU-Konto. LSU benötigt keinen externen Authentifizierungsdienst. Wenn ein externer Authentifizierungsdienst ausfällt, kann sich der LSU weiterhin anmelden und das System verwalten. Der LSU kann immer über SSH auf den physischen XenServer-Server zugreifen.

Sie können weitere Benutzer erstellen, indem Sie die Active Directory-Konten entweder über die Registerkarte „Benutzer“ von XenCenter oder die xe-CLI hinzufügen. Wenn Ihre Umgebung Active Directory nicht verwendet, sind Sie auf das LSU-Konto beschränkt.

Hinweis:

Wenn Sie Benutzer erstellen, weist XenServer neu erstellten Benutzerkonten nicht automatisch RBAC-Rollen zu. Daher haben diese Konten keinen Zugriff auf den XenServer-Pool, bis Sie ihnen eine Rolle zuweisen.

Diese Berechtigungen werden über Rollen erteilt, wie im Abschnitt Benutzer mit Active Directory (AD) authentifizieren beschrieben.

Benutzer mit Active Directory (AD) authentifizieren

Wenn Sie mehrere Benutzerkonten auf einem Host oder in einem Pool haben möchten, müssen Sie Active Directory-Benutzerkonten zur Authentifizierung verwenden. AD-Konten ermöglichen XenServer-Benutzern die Anmeldung an einem Pool mit ihren Windows-Domänenanmeldeinformationen.

Hinweis:

Sie können die LDAP-Kanalbindung und LDAP-Signierung auf Ihren AD-Domänencontrollern aktivieren. Weitere Informationen finden Sie unter Microsoft Security Advisory ADV190023.

Sie können unterschiedliche Zugriffsebenen für bestimmte Benutzer konfigurieren, indem Sie die Active Directory-Authentifizierung aktivieren, Benutzerkonten hinzufügen und diesen Konten Rollen zuweisen.

Active Directory-Benutzer können die xe-CLI verwenden (indem sie entsprechende -u- und -pw-Argumente übergeben) und sich auch über XenCenter mit dem Host verbinden. Die Authentifizierung erfolgt pro Ressourcenpool.

Subjekte steuern den Zugriff auf Benutzerkonten. Ein Subjekt in XenServer wird einer Entität auf Ihrem Active Directory-Server zugeordnet (entweder einem Benutzer oder einer Gruppe). Wenn Sie die externe Authentifizierung aktivieren, überprüft XenServer die zur Erstellung einer Sitzung verwendeten Anmeldeinformationen anhand der lokalen Root-Anmeldeinformationen und dann anhand der Subjektliste. Um den Zugriff zu ermöglichen, erstellen Sie einen Subjekteintrag für die Person oder Gruppe, der Sie Zugriff gewähren möchten. Sie können XenCenter oder die xe-CLI verwenden, um einen Subjekteintrag zu erstellen.

Wenn Sie mit XenCenter vertraut sind, beachten Sie, dass die xe CLI eine leicht abweichende Terminologie verwendet, um auf Active Directory- und Benutzerkontofunktionen zu verweisen:

Obwohl XenServer auf Linux basiert, können Sie mit XenServer Active Directory-Konten für XenServer-Benutzerkonten verwenden. Dazu werden die Active Directory-Anmeldeinformationen an den Active Directory-Domänencontroller übergeben.

Wenn Sie Active Directory zu XenServer hinzufügen, werden Active Directory-Benutzer und -Gruppen zu XenServer-Subjekten. Die Subjekte werden in XenCenter als Benutzer bezeichnet. Benutzer/Gruppen werden bei der Anmeldung über Active Directory authentifiziert, wenn Sie ein Subjekt bei XenServer registrieren. Benutzer und Gruppen müssen ihren Benutzernamen nicht durch einen Domänennamen qualifizieren.

Um sich bei einem XenServer-Host anzumelden, müssen Active Directory-Benutzer auf Domänenebene die Berechtigung haben, sich bei dem Computer anzumelden, der das Maschinenkonto von XenServer hostet. Standardmäßig dürfen in einer Windows Server 2019-Domäne alle Benutzer sich bei jedem Computer in der Domäne anmelden. Wenn Sie diese Einstellung jedoch geändert haben, stellen Sie sicher, dass die Benutzer, die Zugriff auf einen XenServer-Host haben sollen, auf Domänenebene zur Anmeldung berechtigt sind.

Um einen Benutzernamen zu qualifizieren, müssen Sie den Benutzernamen im Down-Level-Anmeldenamenformat eingeben, zum Beispiel mydomain\myuser.

Hinweis:

Standardmäßig versucht XenCenter, Benutzer bei AD-Authentifizierungsservern anzumelden, die die Domäne verwenden, der es beigetreten ist, wenn Sie den Benutzernamen nicht qualifiziert haben. Die Ausnahme bildet das LSU-Konto, das XenCenter immer zuerst lokal (d. h. auf dem XenServer) authentifiziert.

Der externe Authentifizierungsprozess funktioniert wie folgt:

1. Die beim Verbinden mit einem Host bereitgestellten Anmeldeinformationen werden zur Authentifizierung an den Active Directory-Domänencontroller übergeben.

2. Der Domänencontroller überprüft die Anmeldeinformationen. Sind diese ungültig, schlägt die Authentifizierung sofort fehl.

3. Sind die Anmeldeinformationen gültig, wird der Active Directory-Controller abgefragt, um die Subjekt-ID und die Gruppenmitgliedschaft zu erhalten, die mit den Anmeldeinformationen verknüpft sind.

4. Stimmt der Subjektbezeichner mit dem im XenServer gespeicherten überein, ist die Authentifizierung erfolgreich.

Wenn Sie einer Domäne beitreten, aktivieren Sie die Active Directory-Authentifizierung für den Pool. Wenn ein Pool jedoch einer Domäne beitritt, können nur Benutzer in dieser Domäne (oder einer Domäne, mit der Vertrauensstellungen bestehen) eine Verbindung zum Pool herstellen.

Hinweis:

Das manuelle Aktualisieren der DNS-Konfiguration einer DHCP-konfigurierten Netzwerk-PIF wird nicht unterstützt und kann dazu führen, dass die AD-Integration und damit die Benutzerauthentifizierung fehlschlägt oder nicht mehr funktioniert.

Active Directory-Authentifizierung konfigurieren

XenServer unterstützt Active Directory-Server, die unter Windows Server 2016 oder höher ausgeführt werden. Um die Verbindung zu Ihren Domänencontrollern zu sichern, können Sie LDAPS konfigurieren, wie unter Sicheres LDAP (LDAPS) beschrieben.

Hinweis:

XenServer 9 unterstützt keine älteren AD-Ciphersuites wie RC4_HMAC_MD5, DES_CBC_MD5 und DES_CBC_CRC. Sie sollten sicherstellen, dass Ihr AD-Server mindestens eine der Ciphersuites AES128_HMAC_SHA1 oder AES256_HMAC_SHA1 unterstützt.

Um Active Directory für XenServer-Hosts zu authentifizieren, müssen Sie denselben DNS-Server sowohl für den Active Directory-Server (konfiguriert, um Interoperabilität zu ermöglichen) als auch für den XenServer-Host verwenden. In einigen Konfigurationen kann der Active Directory-Server den DNS selbst bereitstellen. Dies kann entweder durch die Verwendung von DHCP zur Bereitstellung der IP-Adresse und einer Liste von DNS-Servern für den XenServer-Host erreicht werden. Alternativ können Sie die Werte in den PIF-Objekten festlegen oder den Installer verwenden, wenn eine manuelle statische Konfiguration verwendet wird.

Wir empfehlen, DHCP für die Zuweisung von Hostnamen zu aktivieren. Weisen Sie den Hosts nicht die Hostnamen localhost oder linux zu.

Warnung:

XenServer-Hostnamen müssen in der gesamten XenServer-Bereitstellung eindeutig sein.

Beachten Sie Folgendes:

• XenServer kennzeichnet seinen AD-Eintrag in der AD-Datenbank mit seinem Hostnamen. Wenn zwei XenServer-Hosts mit demselben Hostnamen derselben AD-Domäne beitreten, überschreibt der zweite XenServer den AD-Eintrag des ersten XenServers. Das Überschreiben erfolgt unabhängig davon, ob die Hosts zum selben oder zu verschiedenen Pools gehören. Dies kann dazu führen, dass die AD-Authentifizierung auf dem ersten XenServer nicht mehr funktioniert.

  Sie können denselben Hostnamen für zwei XenServer-Hosts verwenden, solange diese verschiedenen AD-Domänen beitreten.

• Die XenServer-Hosts können sich in verschiedenen Zeitzonen befinden, da die UTC-Zeit verglichen wird. Um eine korrekte Synchronisierung zu gewährleisten, können Sie dieselben NTP-Server für Ihren XenServer-Pool und den Active Directory-Server verwenden.

• Pools mit gemischter Authentifizierung werden nicht unterstützt. Sie können keinen Pool haben, bei dem einige Hosts im Pool für die Verwendung von Active Directory konfiguriert sind und andere nicht.

• Die XenServer Active Directory-Integration verwendet das Kerberos-Protokoll zur Kommunikation mit den Active Directory-Servern. Daher unterstützt XenServer keine Kommunikation mit Active Directory-Servern, die Kerberos nicht verwenden.

• Damit die externe Authentifizierung über Active Directory erfolgreich ist, müssen die Uhren Ihrer XenServer-Hosts mit den Uhren Ihres Active Directory-Servers synchronisiert sein. Wenn XenServer der Active Directory-Domäne beitritt, wird die Synchronisierung überprüft, und die Authentifizierung schlägt fehl, wenn die Zeitverschiebung zwischen den Servern zu groß ist.

Warnung:

Hostnamen dürfen nicht rein numerisch sein. Da XenServer sich im Active Directory unter Verwendung des NetBIOS-Namens des Hosts registriert, sollte der Hostname nicht länger als 15 Zeichen sein (alphanumerische Zeichen und Bindestriche, die nicht mit einem Bindestrich beginnen oder enden).

Eine Einschränkung in neueren SSH-Clients bedeutet, dass SSH für Benutzernamen, die eines der folgenden Zeichen enthalten, nicht funktioniert: {}[]|&. Stellen Sie sicher, dass Ihre Benutzernamen und Active Directory-Servernamen keines dieser Zeichen enthalten.

Wenn Sie einen Host zu einem Pool hinzufügen, nachdem Sie die Active Directory-Authentifizierung aktiviert haben, werden Sie aufgefordert, Active Directory auf dem beitretenden Host zu konfigurieren. Wenn Sie auf dem beitretenden Host zur Eingabe von Anmeldeinformationen aufgefordert werden, geben Sie Active Directory-Anmeldeinformationen mit ausreichenden Berechtigungen ein, um Hosts zu dieser Domäne hinzuzufügen.

Active Directory-Integration

Stellen Sie sicher, dass die folgenden Ports für ausgehende Verbindungen von XenServer zu den Active Directory-Domänencontrollern geöffnet sind.

Weitere Informationen finden Sie unter Von XenServer verwendete Kommunikationsports.

Hinweis:

Wenn Benutzer aus einer vertrauenswürdigen Domäne sich bei XenServer anmelden müssen, stellen Sie sicher, dass die vorhergehenden Ports auch für ausgehende Verbindungen von XenServer zu den Domänencontrollern der vertrauenswürdigen Domäne geöffnet sind.

Winbind

XenServer verwendet Winbind zur Authentifizierung von Active Directory (AD)-Benutzern mit dem AD-Server und zur Verschlüsselung der Kommunikation mit dem AD-Server.

Winbind unterstützt die folgenden Szenarien nicht:

• Leerzeichen am Anfang oder Ende eines Domänenbenutzer- oder Domänengruppennamens.
• Domänenbenutzernamen, die 64 oder mehr Zeichen enthalten.
• Domänenbenutzernamen, die eines der Sonderzeichen +<>”=/%@:,;\` enthalten.
• Domänengruppennamen, die eines der Sonderzeichen ,;\` enthalten.

Winbind konfigurieren

Konfigurieren Sie das Winbind-Verhalten mit den folgenden Konfigurationsoptionen, die in der Datei /etc/xapi.conf enthalten sein können:

• winbind_machine_pwd_timeout: Der Wert dieser Option definiert, wie oft (in Sekunden) das Maschinenpasswort für diesen XenServer-Host rotiert wird. Definieren Sie einen Wert als ganze Zahl.

  Der Standardwert beträgt 1209600 Sekunden (14 Tage). Wir empfehlen, den Standardwert beizubehalten oder den Wert nicht unter den Standardwert zu senken, um genügend Zeit für die Synchronisierung des neuen Passworts zwischen den Domänencontrollern zu gewährleisten.

• winbind_kerberos_encryption_type: Die Werte für diese Option sind strong, legacy und all. Der Standardwert ist strong.

  • Der Wert all erlaubt die folgenden Cipher Suites: aes256-cts-hmac-sha1-96, aes128-cts-hmac-sha1-96 und arcfour-hmac-md5

  • Der Wert strong erlaubt die folgenden Cipher Suites: aes256-cts-hmac-sha1-96 und aes128-cts-hmac-sha1-96

  • Der Wert legacy erlaubt die folgende Cipher Suite: arcfour-hmac-md5

    Die Legacy-Option ist unsicher, und wir empfehlen, sie nur zur Fehlerbehebung zu verwenden.

  Für eine verbesserte Sicherheit empfehlen wir, die AES-Verschlüsselung zu erzwingen. Gehen Sie dazu wie folgt vor:

  1. Stellen Sie sicher, dass der Domänencontroller aes256-cts-hmac-sha1-96 und aes128-cts-hmacsha1-96 unterstützt.

  2. Konfigurieren Sie den Domänencontroller so, dass Die andere Domäne unterstützt Kerberos AES-Verschlüsselung im Domänenvertrauen aktiviert ist.

     Weitere Informationen finden Sie unter Methode 3: Konfigurieren des Vertrauens zur Unterstützung von AES128- und AES256-Verschlüsselung anstelle von RC4-Verschlüsselung in der Microsoft-Dokumentation.

  3. Aktualisieren Sie die Option winbind_kerberos_encryption_type, um den Wert strong zu verwenden.

  4. Starten Sie den Toolstack neu.

     Starten Sie den Toolstack nicht neu, während HA aktiviert ist. Deaktivieren Sie HA, wenn möglich, vorübergehend, bevor Sie den Toolstack neu starten.

  Hinweis:

  Auf Windows Server 2016 ist das msDS-SupportedEncryptionTypes Attribut standardmäßig nur auf RC4 eingestellt. Legen Sie die AES-Verschlüsselungstypen für alle vorhandenen Benutzer fest und setzen Sie deren Passwörter zurück, damit der Domänencontroller die Kerberos-AES-Schlüssel neu generiert.

• winbind_set_machine_account_kerberos_encryption_type: Die Werte für diese Option sind true und false. Der Standardwert ist false.

  • Der Wert true setzt msDS-SupportedEncryptionTypes auf strong für das Active Directory-Computerobjekt des XenServer-Hosts.

  • Der Wert false konfiguriert msDS-SupportedEncryptionTypes nicht auf dem Active Directory-Computerobjekt für den XenServer-Host.

• winbind_cache_time: Winbind speichert einige Domäneninformationen lokal im Cache. Der Wert dieser Option definiert die Anzahl der Sekunden zwischen jeder Cache-Aktualisierung. Der Standardwert ist 60 Sekunden.

Nachdem Sie eine dieser Konfigurationsoptionen aktualisiert haben, starten Sie den Toolstack neu.

Wie verwaltet XenServer das Computerkontopasswort für die AD-Integration?

Ähnlich wie bei Windows-Clientcomputern aktualisiert Winbind das Computerkontopasswort automatisch. Winbind aktualisiert das Computerkontopasswort alle 14 Tage oder wie durch die Konfigurationsoption winbind_machine_pwd_timeout angegeben.

Externe Authentifizierung in einem Pool aktivieren

Die externe Authentifizierung mit Active Directory kann entweder mit XenCenter oder über die CLI mit dem folgenden Befehl konfiguriert werden.

xe pool-enable-external-auth auth-type=AD \
  service-name=fully-qualified-domain \
  config:user=username \
  config:pass=password
<!--NeedCopy-->

Der angegebene Benutzer muss über das Add/remove computer objects or workstations Privileg verfügen, was der Standard für Domänenadministratoren ist.

Wenn Sie DHCP nicht in dem von Active Directory und Ihren XenServer-Hosts verwendeten Netzwerk verwenden, nutzen Sie die folgenden Ansätze, um Ihr DNS einzurichten:

1. Richten Sie Ihre DNS-Suffix-Suchreihenfolge für die Auflösung von Nicht-FQDN-Einträgen ein:

   xe pif-param-set uuid=pif_uuid_in_the_dns_subnetwork \
      "other-config:domain=suffix1.com suffix2.com suffix3.com"
   <!--NeedCopy-->
   

2. Konfigurieren Sie den auf Ihren XenServer-Hosts zu verwendenden DNS-Server:

   xe pif-reconfigure-ip mode=static dns=dnshost ip=ip \
     gateway=gateway netmask=netmask uuid=uuid
   <!--NeedCopy-->
   

3. Stellen Sie die Verwaltungsschnittstelle manuell so ein, dass sie eine PIF verwendet, die sich im selben Netzwerk wie Ihr DNS-Server befindet:

   xe host-management-reconfigure pif-uuid=pif_in_the_dns_subnetwork
   <!--NeedCopy-->
   

Hinweis:

Die externe Authentifizierung ist eine Eigenschaft pro Host. Wir empfehlen jedoch, die externe Authentifizierung pro Pool zu aktivieren und zu deaktivieren. Eine Einstellung pro Pool ermöglicht es XenServer, Fehler zu behandeln, die beim Aktivieren der Authentifizierung auf einem bestimmten Host auftreten. XenServer macht auch alle erforderlichen Änderungen rückgängig, um eine konsistente Konfiguration im gesamten Pool sicherzustellen. Verwenden Sie den Befehl host-param-list, um die Eigenschaften eines Hosts zu überprüfen und den Status der externen Authentifizierung durch Überprüfung der Werte der relevanten Felder zu ermitteln.

Verwenden Sie XenCenter, um die Active Directory-Authentifizierung zu deaktivieren, oder den folgenden xe-Befehl:

xe pool-disable-external-auth
<!--NeedCopy-->

AD-Authentifizierungs-Caching aktivieren

Die Windows AD-Infrastruktur weist intrinsische Verzögerungen bei der Replikation von Informationen über Benutzer auf, z. B. gesperrt/entsperrt, Kennwort und andere Felder während der Replikation über verschiedene AD-Standorte hinweg. Dies kann dazu führen, dass die AD-Authentifizierung sehr lange dauert, insbesondere bei der Skalierung in globalen AD-Bereitstellungen. Das Aktivieren des Authentifizierungs-Cachings ermöglicht es dem System, Authentifizierungsentscheidungen für eine begrenzte Zeit zu speichern, was dazu beiträgt, die Anmeldung zu beschleunigen, wenn die externe Active Directory (AD)-Authentifizierung langsam ist. Diese Funktion ist standardmäßig deaktiviert.

So aktivieren Sie das AD-Authentifizierungs-Caching:

xe pool-param-set uuid=<pool-uuid> ext-auth-cache-enabled=true
<!--NeedCopy-->

Standardmäßig werden Authentifizierungsentscheidungen 300 Sekunden lang gespeichert. Dies kann angepasst werden:

xe pool-param-set uuid=<pool-uuid> ext-auth-cache-expiry=<seconds>
<!--NeedCopy-->

So deaktivieren Sie das AD-Authentifizierungs-Caching:

xe pool-param-set uuid=<pool-uuid> ext-auth-cache-enabled=false
<!--NeedCopy-->

Sicheres LDAP (LDAPS)

Standardmäßig sichert XenServer die Verbindung zu Ihren Active Directory-Domänencontrollern durch Signieren und Versiegeln des LDAP-Datenverkehrs. Sie können diesen Datenverkehr zusätzlich mit LDAPS (LDAP über SSL/TLS, auf Port 636) schützen, das den Verzeichnisdatenverkehr in einem TLS-Tunnel kapselt. XenServer validiert den Tunnel anhand vertrauenswürdiger CA-Zertifikate, die Sie in den Pool importieren.

Hinweis:

XenServer validiert die Zertifikatskette des Domänencontrollers nur anhand importierter CA-Zertifikate. Blatt- oder selbstsignierte (Nicht-CA-)Zertifikate werden für LDAPS nicht unterstützt. Sie müssen mindestens ein CA-Zertifikat importieren, bevor Sie LDAPS aktivieren, andernfalls schlägt die Aktivierung der externen Authentifizierung fehl.

CA-Zertifikat vorbereiten

LDAPS muss auf Ihren Domänencontrollern aktiviert sein, und Sie müssen das CA-Zertifikat bereitstellen, das die Zertifikate der Domänencontroller signiert hat. Informationen zur Vorbereitung der Zertifikate finden Sie in der folgenden Microsoft-Dokumentation:

• (Optional) Wenn Sie noch keine öffentliche oder Unternehmens-Zertifizierungsstelle verwenden, können Sie eine einrichten. Weitere Informationen finden Sie unter Installieren der Zertifizierungsstelle.
• Um LDAPS auf dem Domänencontroller zu aktivieren, siehe Zertifikate für LDAP über SSL konfigurieren und Lightweight Directory Access Protocol (LDAP) über Secure Sockets Layer (SSL) aktivieren.
• Um das öffentliche CA-Zertifikat (ohne privaten Schlüssel) im PEM (Base-64)-Format zu exportieren, siehe certutil oder Export-Certificate. Die exportierte Datei muss die Erweiterung .pem haben, um in XenServer importiert werden zu können.

CA-Zertifikat importieren

Importieren Sie das CA-Zertifikat, das das Serverzertifikat des Domänencontrollers für LDAPS signiert hat, und kennzeichnen Sie es für LDAPS:

xe pool-install-trusted-certificate uuid=<pool-uuid> purpose=ldaps ca=true filename=<path-to-ca.pem>
<!--NeedCopy-->

Wobei:

• purpose=ldaps kennzeichnet das Zertifikat für LDAPS.
• ca=true zeigt an, dass es sich um ein CA-Zertifikat handelt, das eine Kette verifiziert, und nicht um ein angeheftetes Blattzertifikat.
• filename ist der Pfad zum CA-Zertifikat im PEM-Format auf dem Computer, auf dem der Befehl xe ausgeführt wird.

Wenn die Zertifikate der Domänencontroller über eine Zwischen-CA ausgestellt wurden, importieren Sie stattdessen die Zwischen-CA (das Stammzertifikat ist gut zu haben).

LDAPS aktivieren oder deaktivieren

Um LDAPS zu aktivieren, wenn Sie die externe Authentifizierung aktivieren, fügen Sie config:ldaps=true zum Befehl pool-enable-external-auth hinzu:

xe pool-enable-external-auth auth-type=AD \
  service-name=fully-qualified-domain \
  config:user=username \
  config:pass=password \
  config:ldaps=true
<!--NeedCopy-->

Um LDAPS in einem Pool, der der Domäne bereits beigetreten ist, ein- oder auszuschalten, verwenden Sie den Befehl pool-external-auth-set-ldaps:

xe pool-external-auth-set-ldaps uuid=<pool-uuid> ldaps=true
<!--NeedCopy-->

xe pool-external-auth-set-ldaps uuid=<pool-uuid> ldaps=false
<!--NeedCopy-->

Die Änderung wird auf jeden Host im Pool angewendet und mit der Domäne überprüft. Schlägt dies fehl, wird die Änderung auf allen Hosts automatisch rückgängig gemacht.

Um die für LDAPS gekennzeichneten Zertifikate aufzulisten:

xe certificate-list purpose=ldaps
<!--NeedCopy-->

Verwenden Sie eine CA-Kette für mehrere Domänencontroller

Wenn sich ein Pool über LDAPS authentifiziert, kann XenServer eine Verbindung zu jedem der Domänencontroller der Domäne herstellen, und der von ihm verwendete Domänencontroller kann zwischen den Vorgängen variieren. Jeder Domänencontroller präsentiert sein eigenes Serverzertifikat für LDAPS, das XenServer anhand der von Ihnen importierten CA-Zertifikate validiert. Wenn das Zertifikat eines Domänencontrollers von einer CA signiert wurde, die Sie nicht importiert haben, kann XenServer intermittierende Fehler aufweisen.

Beachten Sie diese Empfehlungen:

• Stellen Sie das Serverzertifikat jedes Domänencontrollers für LDAPS von derselben Stamm-CA aus und importieren Sie die Stammzertifikate mit purpose=ldaps als vertrauenswürdiges Zertifikat in XenServer.
• Wenn Ihre Umgebung eine Beitrittsdomäne und eine vertrauenswürdige Domäne verwendet, die von verschiedenen CAs signiert sind, importieren Sie alle CA-Zertifikate für alle diese Domänen.

Benutzerauthentifizierung

Um einem Benutzer Zugriff auf Ihren XenServer-Host zu gewähren, müssen Sie ein Subjekt für diesen Benutzer oder eine Gruppe, der er angehört, hinzufügen. (Transitive Gruppenmitgliedschaften werden ebenfalls auf normale Weise überprüft. Zum Beispiel würde das Hinzufügen eines Subjekts für die Gruppe A, wobei die Gruppe A die Gruppe B enthält und user 1 Mitglied der Gruppe B ist, den Zugriff auf user 1 ermöglichen.) Wenn Sie Benutzerberechtigungen in Active Directory verwalten möchten, können Sie eine einzelne Gruppe erstellen, der Sie dann Benutzer hinzufügen und von der Sie Benutzer entfernen. Alternativ können Sie einzelne Benutzer von XenServer hinzufügen und entfernen oder eine Kombination aus Benutzern und Gruppen, je nach Ihren Authentifizierungsanforderungen. Sie können die Subjektliste von XenCenter oder über die CLI verwalten, wie im folgenden Abschnitt beschrieben.

Bei der Authentifizierung eines Benutzers werden die Anmeldeinformationen zuerst mit dem lokalen Root-Konto überprüft, sodass Sie ein System wiederherstellen können, dessen AD-Server ausgefallen ist. Wenn die Anmeldeinformationen (Benutzername und Kennwort) nicht übereinstimmen, wird eine Authentifizierungsanforderung an den AD-Server gesendet. Wenn die Authentifizierung erfolgreich ist, werden die Benutzerinformationen abgerufen und mit der lokalen Subjektliste validiert. Der Zugriff wird verweigert, wenn die Authentifizierung fehlschlägt. Die Validierung anhand der Subjektliste ist erfolgreich, wenn der Benutzer oder eine Gruppe in der transitiven Gruppenmitgliedschaft des Benutzers in der Subjektliste enthalten ist.

Hinweis:

Bei Verwendung von Active Directory-Gruppen, um Pool-Administrator-Benutzern, die Host-SSH-Zugriff benötigen, Zugriff zu gewähren, darf die Größe der AD-Gruppe 500 Benutzer nicht überschreiten.

So fügen Sie ein AD-Subjekt zu XenServer hinzu:

xe subject-add subject-name=entity_name
<!--NeedCopy-->

Der entity_name ist der Name des Benutzers oder der Gruppe, dem Sie Zugriff gewähren möchten. Sie können die Domäne der Entität angeben (z. B. ‘xendt\user1’ im Gegensatz zu ‘user1’), obwohl das Verhalten dasselbe ist, es sei denn, eine Disambiguierung ist erforderlich.

Suchen Sie den Subjektbezeichner des Benutzers. Der Bezeichner ist der Benutzer oder die Gruppe, die den Benutzer enthält. Das Entfernen einer Gruppe entzieht allen Benutzern in dieser Gruppe den Zugriff, sofern sie nicht auch in der Subjektliste angegeben sind. Verwenden Sie den Befehl subject list, um den Subjektbezeichner des Benutzers zu finden. :

xe subject-list
<!--NeedCopy-->

Dieser Befehl gibt eine Liste aller Benutzer zurück.

Um einen Filter auf die Liste anzuwenden, zum Beispiel um den Subjektbezeichner für einen Benutzer user1 in der Domäne testad zu finden, verwenden Sie den folgenden Befehl:

xe subject-list other-config:subject-name='testad\user1'
<!--NeedCopy-->

Entfernen Sie den Benutzer mit dem Befehl subject-remove und übergeben Sie dabei den Subjektbezeichner, den Sie im vorherigen Schritt ermittelt haben:

xe subject-remove subject-uuid=subject_uuid
<!--NeedCopy-->

Sie können jede aktuelle Sitzung beenden, die dieser Benutzer bereits authentifiziert hat. Weitere Informationen finden Sie unter Alle authentifizierten Sitzungen mit xe beenden und Einzelne Benutzersitzungen mit xe beenden im folgenden Abschnitt. Wenn Sie die Sitzungen nicht beenden, können Benutzer mit widerrufenen Berechtigungen weiterhin auf das System zugreifen, bis sie sich abmelden.

Führen Sie den folgenden Befehl aus, um die Liste der Benutzer und Gruppen zu identifizieren, die Zugriff auf Ihren XenServer-Host oder -Pool haben:

xe subject-list
<!--NeedCopy-->

Zugriff für einen Benutzer entfernen

Wenn ein Benutzer authentifiziert ist, kann er auf den Host zugreifen, bis er seine Sitzung beendet oder ein anderer Benutzer seine Sitzung beendet. Das Entfernen eines Benutzers aus der Subjektliste oder das Entfernen aus einer Gruppe in der Subjektliste widerruft nicht automatisch bereits authentifizierte Sitzungen, die der Benutzer hat. Benutzer können weiterhin über XenCenter oder andere API-Sitzungen, die sie bereits erstellt haben, auf den Pool zugreifen. XenCenter und die CLI bieten Funktionen, um einzelne Sitzungen oder alle aktiven Sitzungen zwangsweise zu beenden. Informationen zu Verfahren mit XenCenter finden Sie in der XenCenter-Dokumentation, oder im folgenden Abschnitt für Verfahren mit der CLI.

Alle authentifizierten Sitzungen mit xe beenden

Führen Sie den folgenden CLI-Befehl aus, um alle authentifizierten Sitzungen mit xe zu beenden:

xe session-subject-identifier-logout-all
<!--NeedCopy-->

Einzelne Benutzersitzungen mit xe beenden

1. Bestimmen Sie den Subjektbezeichner, dessen Sitzung Sie abmelden möchten. Verwenden Sie entweder die xe-Befehle session-subject-identifier-list oder subject-list, um den Subjektbezeichner zu finden. Der erste Befehl zeigt Benutzer an, die Sitzungen haben. Der zweite Befehl zeigt alle Benutzer an, kann aber gefiltert werden. Zum Beispiel mit einem Befehl wie xe subject-list other-config:subject-name=xendt\\user1. Je nach Shell benötigen Sie möglicherweise einen doppelten Backslash, wie gezeigt).

2. Verwenden Sie den Befehl session-subject-logout und übergeben Sie den im vorherigen Schritt ermittelten Subjektbezeichner als Parameter, zum Beispiel:

   xe session-subject-identifier-logout subject-identifier=subject_id
   <!--NeedCopy-->
   

Eine AD-Domäne verlassen

Warnung:

Wenn Sie die Domäne verlassen, werden alle Benutzer, die sich mit Active Directory-Anmeldeinformationen am Pool oder Host authentifiziert haben, getrennt.

Verwenden Sie XenCenter, um eine AD-Domäne zu verlassen. Weitere Informationen finden Sie in der XenCenter-Dokumentation. Alternativ führen Sie den Befehl pool-disable-external-auth aus und geben Sie bei Bedarf die Pool-UUID an.

Hinweis:

Das Verlassen der Domäne löscht die Hostobjekte nicht aus der AD-Datenbank. Informationen zum Erkennen und Entfernen Ihrer deaktivierten Host-Einträge finden Sie in der Active Directory-Dokumentation.