Installieren von Linux Virtual Delivery Agent für Ubuntu

Mit den Schritten in diesem Artikel können Sie die Installation manuell durchführen, oder verwenden Sie Easy Install für die automatische Installation und Konfiguration. Easy Install spart Zeit und Arbeitskraft und ist weniger fehleranfällig als die manuelle Installation.

Hinweis:

Verwenden Sie Easy Install bei Neuinstallationen. Zum Aktualisieren von vorhandenen Installationen eignet Easy Install sich nicht.

Schritt 1: Vorbereiten von Ubuntu für die VDA-Installation

Schritt 1a: Überprüfen der Netzwerkkonfiguration

Stellen Sie sicher, dass das Netzwerk verbunden und richtig konfiguriert ist, bevor Sie fortfahren.

Schritt 1b: Festlegen des Hostnamens

Damit der Hostname der Maschine richtig gemeldet wird, ändern Sie die Datei /etc/hostname, sodass sie nur den Hostnamen der Maschine enthält.

hostname

Schritt 1c: Zuweisen einer Loopbackadresse für den Hostnamen

Damit der DNS-Domänenname und der vollqualifizierte Domänenname (FQDN) der Maschine richtig gemeldet werden, ändern Sie die folgende Zeile in der Datei /etc/hosts, sodass der FQDN und der Hostname die ersten zwei Einträge sind:

127.0.0.1 hostname-fqdn hostname localhost

Beispiel:

127.0.0.1 vda01.example.com vda01 localhost

Entfernen Sie alle anderen Verweise auf hostname-fqdn oder hostname aus anderen Einträgen in der Datei.

Hinweis:

Der Linux VDA unterstützt derzeit nicht das Abschneiden von NetBIOS-Namen. Der Name darf daher nicht länger als 15 Zeichen sein.

Tipp:

Verwenden Sie nur Buchstaben (a-z oder A-Z), Ziffern (0-9) und Bindestriche (-). Vermeiden Sie Unterstriche (_), Leerzeichen und andere Symbole. Hostnamen sollten nicht mit einer Zahl beginnen und nicht mit einem Bindestrich enden. Diese Regel gilt auch für Delivery Controller-Hostnamen.

Schritt 1d: Überprüfen des Hostnamens

Stellen Sie sicher, dass der Hostname richtig festgelegt ist:

hostname
<!--NeedCopy-->

Dieser Befehl gibt nur den Hostnamen der Maschine zurück und nicht den vollqualifizierten Domänennamen (FQDN).

Stellen Sie sicher, dass der FQDN richtig festgelegt ist:

hostname -f
<!--NeedCopy-->

Dieser Befehl gibt den FQDN der Maschine zurück.

Schritt 1e: Deaktivieren von Multicast-DNS

In den Standardeinstellungen ist Multicast-DNS (mDNS) aktiviert, was zu inkonsistenten Ergebnissen bei der Namensauflösung führen kann.

Um mDNS zu deaktivieren, bearbeiten Sie /etc/nsswitch.conf und ändern die Zeile:

hosts: files mdns_minimal [NOTFOUND=return] dns

In:

hosts: files dns

Schritt 1f: Überprüfen von Namensauflösung und Diensterreichbarkeit

Stellen Sie sicher, dass Sie den FQDN auflösen können und pingen Sie den Domänencontroller und den Delivery Controller:

nslookup domain-controller-fqdn

ping domain-controller-fqdn

nslookup delivery-controller-fqdn

ping delivery-controller-fqdn
<!--NeedCopy-->

Wenn Sie den FQDN nicht auflösen und eine der beiden Maschinen nicht pingen können, überprüfen Sie die vorherigen Schritte, bevor Sie fortfahren.

Schritt 1g: Konfigurieren der Uhrsynchronisierung (Chrony)

Es ist wichtig, dass die Uhrsynchronisierung zwischen den VDAs, den Delivery Controllern und den Domänencontrollern genau ist. Beim Hosten eines Linux VDAs als virtuelle Maschine kann es zu Zeitabweichungen kommen. Aus diesem Grund sollte die Zeit remote von einem Zeitdienst synchronisiert werden.

Installieren Sie chrony:

apt-get install chrony
<!--NeedCopy-->

Bearbeiten Sie als Root-Benutzer die Datei /etc/chrony/chrony.conf und fügen Sie pro Remote-Zeitserver einen Servereintrag hinzu:

server peer1-fqdn-or-ip-address iburst
server peer2-fqdn-or-ip-address iburst

In einer typischen Bereitstellung synchronisieren Sie die Zeit von den lokalen Domänencontrollern und nicht direkt von öffentlichen NTP-Poolservern. Fügen Sie pro Active Directory-Domänencontroller in der Domäne einen Servereintrag hinzu.

Entfernen Sie alle server- oder pool-Einträge, , einschließlich Einträge für Loopback-IP-Adressen, Localhost und öffentliche Servereinträge wie *.pool.ntp.org.

Speichern Sie die Änderungen und starten Sie den Chrony-Daemon neu:

sudo systemctl restart chrony
<!--NeedCopy-->

Schritt 1h: Installieren von OpenJDK

Der Linux VDA ist von OpenJDK abhängig. Üblicherweise wird die Laufzeitumgebung als Teil der Betriebssysteminstallation installiert. Überprüfen Sie, ob es installiert ist:

sudo apt-get install -y default-jdk
<!--NeedCopy-->

Schritt 1i: Installieren von PostgreSQL

Der Linux VDA erfordert PostgreSQL 9.x unter Ubuntu 16.04:

sudo apt-get install -y postgresql

sudo apt-get install -y libpostgresql-jdbc-java
<!--NeedCopy-->

Schritt 1j: Installieren von Motif

sudo apt-get install -y libxm4
<!--NeedCopy-->

Schritt 1k: Installieren weiterer Pakete

sudo apt-get install -y libsasl2-2

sudo apt-get install -y libsasl2-modules-gssapi-mit

sudo apt-get install -y libldap-2.4-2

sudo apt-get install -y krb5-user

sudo apt-get install -y cups
<!--NeedCopy-->

Schritt 2: Vorbereiten des Hypervisors

Wenn Sie den Linux VDA als virtuelle Maschine auf einem unterstützten Hypervisor ausführen, sind einige Änderungen erforderlich. Nehmen Sie entsprechend der verwendeten Hypervisorplattform die folgenden Änderungen vor. Wenn Sie die Linux-Maschine auf Bare-Metal-Hardware ausführen, sind keine Änderungen erforderlich.

Festlegen der Zeitsynchronisierung auf Citrix XenServer

Wenn das Zeitsynchronisierungsfeature auf XenServer aktiviert ist, treten auf den paravirtualisierten Linux-VMs Probleme auf, da NTP und XenServer gleichzeitig versuchen, die Systemuhr zu verwalten. Damit es nicht zu Zeitabweichungen zwischen der Uhr und den anderen Servern kommt, muss die Systemuhr aller Linux-Gäste mit dem NTP synchronisiert werden. In diesem Fall muss die Hostzeitsynchronisierung deaktiviert werden. Im HVM-Modus sind keine Änderungen erforderlich.

Auf einigen Linux-Distributionen, auf denen ein paravirtualisierter Linux-Kernel mit installierten XenServer Tools ausgeführt wird, können Sie direkt in der Linux-VM prüfen, ob das XenServer-Zeitsynchronisierungsfeature vorhanden und aktiviert ist:

su -

cat /proc/sys/xen/independent_wallclock
<!--NeedCopy-->

Dieser Befehl gibt 0 oder 1 zurück:

• 0: Das Zeitsynchronisierungsfeature ist aktiviert und muss deaktiviert werden.
• 1: Das Zeitsynchronisierungsfeature ist deaktiviert und keine weitere Aktion ist erforderlich.

Wenn die Datei /proc/sys/xen/indepent_wallclock nicht vorhanden ist, sind die folgenden Schritte nicht erforderlich.

Wenn das Zeitsynchronisierungsfeature aktiviert ist, deaktivieren Sie es, indem Sie 1 in die Datei eingeben:

sudo echo 1 > /proc/sys/xen/independent_wallclock
<!--NeedCopy-->

Damit die Änderung permanent wird und nach dem Neustart erhalten bleibt, fügen Sie in der Datei /etc/sysctl.conf die folgende Zeile hinzu:

xen.independent_wallclock = 1

Starten Sie das System neu, um die Änderungen zu überprüfen:

su -

cat /proc/sys/xen/independent_wallclock
<!--NeedCopy-->

Dieser Befehl gibt den Wert 1 zurück.

Festlegen der Zeitsynchronisierung auf Microsoft Hyper-V

Linux-VMs, auf denen Hyper-V Linux-Integrationsdienste installiert sind, können mit dem Hyper-V-Zeitsynchronisierungsfeature die Systemzeit des Hostbetriebssystems verwenden. Um sicherzustellen, dass die Betriebssystemzeit korrekt ist, muss das Feature zusätzlich zu den NTP-Diensten aktiviert sein.

Auf dem verwaltenden Betriebssystem:

1. Öffnen Sie die Hyper-V-Manager-Konsole.
2. Wählen Sie für die Einstellungen einer Linux-VM Integration Services aus.
3. Stellen Sie sicher, dass Time synchronization ausgewählt ist.

Hinweis:

Diese Methode unterscheidet sich von VMware und XenServer, wo die Hostzeitsynchronisierung deaktiviert ist, um Konflikte mit dem NTP zu vermeiden. Hyper-V-Zeitsynchronisierung kann gleichzeitig mit der NTP-Zeitsynchronisierung bestehen und sie ergänzen.

Festlegen der Zeitsynchronisierung auf ESX und ESXi

Wenn das VMware-Zeitsynchronisierungsfeature aktiviert ist, treten auf den paravirtualisierten Linux-VMs Probleme auf, da NTP und der Hypervisor gleichzeitig versuchen, die Systemuhr zu synchronisieren. Damit es nicht zu Zeitabweichungen zwischen der Uhr und den anderen Servern kommt, muss die Systemuhr aller Linux-Gäste mit dem NTP synchronisiert werden. In diesem Fall muss die Hostzeitsynchronisierung deaktiviert werden.

Wenn Sie einen paravirtualisierten Linux-Kernel ausführen und VMware-Tools installiert sind:

1. Öffnen Sie den vSphere-Client.
2. Bearbeiten Sie die Einstellungen für die Linux-VM.
3. Öffnen Sie im Dialogfeld Virtual Machine Properties die Registerkarte Options.
4. Wählen Sie VMware Tools.
5. Deaktivieren Sie im Feld Advanced das Kontrollkästchen Synchronize guest time with host.

Schritt 3: Hinzufügen der virtuellen Linux-Maschine zur Windows-Domäne

Der Linux VDA unterstützt mehrere Methoden zum Hinzufügen von Linux-Maschinen zur Active Directory-Domäne:

• Samba Winbind
• Quest Authentication Service
• Centrify DirectControl
• SSSD

Folgen Sie den Anweisungen für die von Ihnen gewählte Methode.

Samba Winbind

Installieren oder aktualisieren Sie die erforderlichen Pakete

sudo apt-get install winbind samba libnss-winbind libpam-winbind krb5-config krb5-locales krb5-user
<!--NeedCopy-->

Starten des Winbind-Daemon beim Booten

Der Winbind-Daemon muss beim Systemstart gestartet werden:

sudo systemctl enable winbind
<!--NeedCopy-->

Konfigurieren von Kerberos

Öffnen Sie als Root-Benutzer /etc/krb5.conf und nehmen Sie folgende Einstellungen vor:

[libdefaults]

default_realm = REALM

dns_lookup_kdc = false



[realms]

REALM = {

admin_server = domain-controller-fqdn

kdc = domain-controller-fqdn

}



[domain_realm]

domain-dns-name = REALM

.domain-dns-name = REALM
<!--NeedCopy-->

Die Eigenschaft domain-dns-name ist in diesem Kontext der DNS-Domänenname, z. B. example.com. REALM ist der Kerberos-Bereichsname in Großbuchstaben, z. B. EXAMPLE.COM.

Konfigurieren der Winbind-Authentifizierung

Führen Sie eine manuelle Konfiguration durch, denn Ubuntu verfügt nicht über Tools wie authconfig in RHEL und yast2 in SUSE.

Öffnen Sie /etc/samba/smb.conf und nehmen Sie folgende Einstellungen vor:

[global]

workgroup = WORKGROUP

security = ADS

realm = REALM

encrypt passwords = yes

idmap config *:range = 16777216-33554431

winbind trusted domains only = no

kerberos method = secrets and keytab

winbind refresh tickets = yes

template shell = /bin/bash
<!--NeedCopy-->

WORKGROUP ist das erste Feld in REALM und REALM ist der Kerberos-Bereichsname in Großbuchstaben.

Konfigurieren von nsswitch

Öffnen Sie /etc/nsswitch.conf und fügen Sie winbind in den folgenden Zeilen hinzu:

passwd: compat winbind
group: compat winbind

Beitreten zu einer Windows-Domäne

Es wird vorausgesetzt, dass der Domänencontroller erreichbar ist und dass Sie über ein Active Directory-Benutzerkonto mit Berechtigungen zum Hinzufügen von Computern zur Domäne verfügen:

sudo net ads join REALM -U user
<!--NeedCopy-->

REALM ist der Kerberos-Bereichsname in Großbuchstaben und user ist ein Domänenbenutzer mit Berechtigungen zum Hinzufügen von Computern zur Domäne.

Neustarten von winbind

sudo systemctl restart winbind
<!--NeedCopy-->

Konfigurieren von PAM für Winbind

Führen Sie den folgenden Befehl aus. Stellen Sie sicher, dass die Optionen Winbind NT/Active Directory authentication und Create home directory on login aktiviert sind:

sudo pam-auth-update
<!--NeedCopy-->

Tipp:

Der Winbind-Daemon wird nur weiterhin ausgeführt, wenn die Maschine zu einer Domäne gehört.

Überprüfen der Domäneneigentümerschaft

Für den Delivery Controller ist es erforderlich, dass alle VDA-Maschinen, Windows und Linux, ein Computerobjekt in Active Directory haben.

Führen Sie den Samba-Befehl net ads aus, um zu prüfen, ob die Maschine zu einer Domäne gehört:

sudo net ads testjoin
<!--NeedCopy-->

Führen Sie den folgenden Befehl aus, um zusätzliche Domänen- und Computerobjektinformationen zu überprüfen:

sudo net ads info
<!--NeedCopy-->

Überprüfen der Kerberos-Konfiguration

Überprüfen Sie, ob Kerberos zur Verwendung mit dem Linux VDA ordnungsgemäß konfiguriert ist, indem Sie sicherstellen, dass die Systemdatei für die Schlüsseltabelle erstellt wurde und gültige Schlüssel enthält:

sudo klist -ke
<!--NeedCopy-->

Mit diesem Befehl wird die Liste der Schlüssel angezeigt, die für die verschiedenen Kombinationen aus Prinzipalnamen und Verschlüsselungssammlungen verfügbar sind. Führen Sie den Kerberos-Befehl kinit aus, um die Maschine mit dem Domänencontroller mit diesen Schlüsseln zu authentifizieren:

sudo kinit -k MACHINE$@REALM
<!--NeedCopy-->

Maschinen- und Bereichsname müssen in Großbuchstaben angegeben werden. Das Dollarzeichen ($) muss durch einen umgekehrten Schrägstrich (\) geschützt werden, um das Ersetzen in der Shell zu verhindern. In einigen Umgebungen sind DNS-Domänenname und Kerberos-Bereichsname unterschiedlich. Stellen Sie sicher, dass der Bereichsname verwendet wird. Wenn dieser Befehl erfolgreich ist, wird keine Ausgabe angezeigt.

Stellen Sie mit folgendem Befehl sicher, dass das TGT-Ticket für das Maschinenkonto zwischengespeichert wurde:

sudo klist
<!--NeedCopy-->

Überprüfen Sie die Maschinenkontodetails mit folgendem Befehl:

sudo net ads status
<!--NeedCopy-->

Überprüfen der Benutzerauthentifizierung

Überprüfen Sie mit dem wbinfo-Tool, dass Domänenbenutzer sich bei der Domäne authentifizieren können:

wbinfo --krb5auth=domain\username%password
<!--NeedCopy-->

Die hier angegebene Domäne ist der AD-Domänenname und nicht der Kerberos-Bereichsname. Für die Bash-Shell muss der umgekehrte Schrägstrich (\) durch einen weiteren umgekehrten Schrägstrich geschützt werden. Bei diesem Befehl wird eine Erfolgs- oder Fehlermeldung zurückgegeben.

Um sich zu vergewissern, dass das Winbind-PAM-Modul fehlerfrei konfiguriert ist, melden Sie sich mit einem Domänenbenutzerkonto am Linux VDA an. Das Domänenbenutzerkonto wurde zuvor noch nicht verwendet.

ssh localhost -l domain\username

id -u
<!--NeedCopy-->

Vergewissern Sie sich, dass eine entsprechende Cachedatei mit Kerberos-Anmeldeinformationen für die mit dem Befehl id -u zurückgegebene UID erstellt wurde:

ls /tmp/krb5cc_uid
<!--NeedCopy-->

Stellen Sie sicher, dass die Tickets im Kerberos-Anmeldeinformationscache des Benutzers gültig und nicht abgelaufen sind:

klist
<!--NeedCopy-->

Beenden Sie die Sitzung.

exit
<!--NeedCopy-->

Ein ähnlicher Test kann ausgeführt werden, wenn Sie sich direkt an der Gnome- oder KDE-Konsole anmelden. Fahren Sie nach der Überprüfung des Domänenbeitritts mit Schritt 4: Installieren des Linux VDA fort.

Tipp:

Wenn die Benutzerauthentifizierung erfolgreich ist, aber der Desktop nach der Anmeldung mit einem Domänenkonto nicht angezeigt wird, starten Sie die Maschine neu und wiederholen Sie die Anmeldung.

Quest Authentication Service

Konfigurieren von Quest auf dem Domänencontroller

Es wird vorausgesetzt, dass Sie die Quest-Software auf den Active Directory-Domänencontrollern installiert und konfiguriert haben und über Administratorrechte zum Erstellen von Computerobjekten in Active Directory verfügen.

Domänenbenutzern die Anmeldung an Linux VDA-Maschinen ermöglichen

Führen Sie folgende Schritte aus, damit Domänenbenutzer HDX-Sitzungen auf einer Linux VDA-Maschine herstellen können:

1. Öffnen Sie in der Verwaltungskonsole für Active Directory-Benutzer und -Computer die Active Directory-Eigenschaften für das jeweilige Benutzerkonto.
2. Wählen Sie die Registerkarte Unix Account aus.
3. Aktivieren Sie das Kontrollkästchen Unix-enabled.
4. Legen Sie Primary GID Number auf die Gruppen-ID einer vorhandenen Domänenbenutzergruppe fest.

Hinweis:

Mit diesen Anleitungen können Domänenbenutzer für die Anmeldung mit der Konsole, RDP, SSH oder anderen Remotingprotokollen eingerichtet werden.

Konfigurieren von Quest auf Linux VDA

Workaround bei SELinux-Richtlinienerzwingung

In der RHEL-Standardumgebung wird SELinux vollständig erzwungen. Das beeinträchtigt die von Quest verwendeten IPC-Methoden der Unix-Domänensockets und verhindert, dass Domänenbenutzer sich anmelden.

Der bequeme Weg, dieses Problem zu umgehen, ist die Deaktivierung von SELinux. Bearbeiten Sie als Root-Benutzer die Datei /etc/selinux/config und ändern Sie die SELinux-Einstellung:

SELINUX=disabled

Diese Änderung erfordert einen Neustart der Maschine:

reboot
<!--NeedCopy-->

Wichtig:

Seien Sie vorsichtig beim Verwenden dieser Einstellung. Das erneute Aktivieren der SELinux-Richtlinienerzwingung nach ihrer Deaktivierung kann selbst für den Root-Benutzer und anderen lokale Benutzer zu einer vollständigen Sperrung führen.

Konfigurieren eines VAS-Daemons

Die automatische Erneuerung von Kerberos-Tickets muss aktiviert und getrennt sein. Authentifizierung (für Offlineanmeldung) muss deaktiviert sein.

sudo /opt/quest/bin/vastool configure vas vasd auto-ticket-renew-interval 32400

sudo /opt/quest/bin/vastool configure vas vas_auth allow-disconnected-auth false
<!--NeedCopy-->

Mit diesem Befehl wird das Verlängerungsintervall auf neun Stunden (32.400 Sekunden) festgelegt. Das ist eine Stunde weniger als die Standardgültigkeitsdauer (10 Stunden) eines Tickets. Bei Systemen mit einer kürzeren Ticketgültigkeitsdauer legen Sie diesen Parameter auf einen niedrigeren Wert fest.

Konfigurieren von PAM und NSS

Um die Domänenbenutzeranmeldung über HDX und andere Dienste wie su, ssh und RDP zu aktivieren, führen Sie die folgenden Befehle aus, um PAM und NSS manuell zu konfigurieren:

sudo /opt/quest/bin/vastool configure pam

sudo /opt/quest/bin/vastool configure nss
<!--NeedCopy-->

Beitreten zu einer Windows-Domäne

Machen Sie die Linux-Maschine mit dem Quest-Befehl vastool zu einem Mitglied der Active Directory-Domäne:

sudo /opt/quest/bin/vastool -u user join domain-name
<!--NeedCopy-->

Der Benutzer ist ein beliebiger Domänenbenutzer mit der Berechtigung, Computer zu Mitgliedern der Active Directory-Domäne zu machen. domain-name ist der DNS-Name der Domäne, z. B. example.com.

Überprüfen der Domäneneigentümerschaft

Für den Delivery Controller ist es erforderlich, dass alle VDA-Maschinen, Windows und Linux, ein Computerobjekt in Active Directory haben. Mit folgendem Befehl prüfen Sie, ob eine per Quest angemeldete Linux-Maschine zur Domäne gehört:

sudo /opt/quest/bin/vastool info domain
<!--NeedCopy-->

Wenn die Maschine zu einer Domäne gehört, wird mit diesem Befehl der Domänenname zurückgegeben. Wenn die Maschine zu keiner Domäne gehört, wird die folgende Fehlermeldung angezeigt:

ERROR: No domain could be found.
ERROR: VAS_ERR_CONFIG: at ctx.c:414 in _ctx_init_default_realm
default_realm not configured in vas.conf. Computer may not be joined to domain

Überprüfen der Benutzerauthentifizierung

Um sicherzustellen, dass Quest Domänenbenutzer mit PAM authentifizieren kann, melden Sie sich mit einem Domänenbenutzerkonto am Linux VDA an. Das Domänenbenutzerkonto wurde zuvor noch nicht verwendet.

ssh localhost -l domain\username

id -u
<!--NeedCopy-->

Vergewissern Sie sich, dass eine entsprechende Cachedatei mit Kerberos-Anmeldeinformationen für die mit dem Befehl id -u zurückgegebene UID erstellt wurde:

ls /tmp/krb5cc_uid
<!--NeedCopy-->

Stellen Sie sicher, dass die Tickets im Kerberos-Anmeldeinformationscache gültig und nicht abgelaufen sind:

/opt/quest/bin/vastool klist
<!--NeedCopy-->

Beenden Sie die Sitzung.

exit
<!--NeedCopy-->

Fahren Sie nach der Überprüfung des Domänenbeitritts mit Schritt 4: Installieren des Linux VDA fort.

Centrify DirectControl

Beitreten zu einer Windows-Domäne

Wenn der Centrify DirectControl Agent installiert ist, machen Sie die Linux-Maschine mit dem Centrify-Befehl adjoin zu einem Mitglied der Active Directory-Domäne:

su –

adjoin -w -V -u user domain-name
<!--NeedCopy-->

Der Parameter user ist ein Active Directory-Domänenbenutzer mit der Berechtigung, Computer zu Mitgliedern von Active Directory-Domänen zu machen. Der Parameter domain-name ist der Name der Domäne, der die Linux-Maschine beitritt.

Überprüfen der Domäneneigentümerschaft

Für den Delivery Controller ist es erforderlich, dass alle VDA-Maschinen, Windows und Linux, ein Computerobjekt in Active Directory haben. Mit folgendem Befehl prüfen Sie, ob eine per Centrify hinzugefügte Linux-Maschine Mitglied der Domäne ist:

su –

adinfo
<!--NeedCopy-->

Stellen Sie sicher, dass der Wert Joined to domain gültig ist und dass CentrifyDC mode den Wert connected zurückgibt. Wenn der Modus im Startzustand stecken bleibt, hat der Centrify-Client Serververbindungs- oder Authentifizierungsprobleme.

Umfassendere System- und Diagnoseinformationen sind mit folgenden Befehlen verfügbar:

adinfo --sysinfo all

adinfo --diag
<!--NeedCopy-->

Testen Sie die Verbindung mit den verschiedenen Active Directory- und Kerberos-Diensten.

adinfo --test
<!--NeedCopy-->

Fahren Sie nach der Überprüfung des Domänenbeitritts mit Schritt 4: Installieren des Linux VDA fort.

SSSD

Konfigurieren von Kerberos

Führen Sie zum Installieren von Kerberos den folgenden Befehl aus:

sudo apt-get install krb5-user
<!--NeedCopy-->

Zum Konfigurieren von Kerberos öffnen Sie als Root-Benutzer /etc/krb5.conf und nehmen folgende Einstellungen vor:

[libdefaults]

 default_realm = REALM

 dns_lookup_kdc = false

[realms]

 REALM = {

  admin_server = domain-controller-fqdn

  kdc = domain-controller-fqdn

 }

[domain_realm]

 domain-dns-name = REALM

 .domain-dns-name = REALM
<!--NeedCopy-->

Die Eigenschaft domain-dns-name ist in diesem Kontext der DNS-Domänenname, z. B. example.com. REALM ist der Kerberos-Bereichsname in Großbuchstaben, z. B. EXAMPLE.COM.

Beitreten zu einer Domäne

SSSD muss für die Verwendung von Active Directory als Identitätsanbieter und Kerberos zur Authentifizierung konfiguriert werden. SSSD bietet keine AD-Clientfunktionen für den Domänenbeitritt und die Verwaltung der Systemschlüsseltabelle. Sie können stattdessen adcli, realmd, oder Samba verwenden.

Hinweis:

Dieser Abschnitt enthält nur Informationen zu adcli und Samba.

Verwenden Sie adcli für den Beitritt zur Domäne:

Installieren Sie adcli:

Installieren Sie das erforderliche Paket:

sudo apt-get install adcli
<!--NeedCopy-->

Domänenbeitritt mit adcli:

Entfernen Sie die alte Systemdatei für die Schlüsseltabelle und treten Sie der Domäne mit folgenden Befehl bei:

su -

rm -rf /etc/krb5.keytab

adcli join domain-dns-name -U user -H hostname-fqdn
<!--NeedCopy-->

user ist ein Domänenbenutzer mit der Berechtigung zum Hinzufügen von Maschinen zur Domäne. hostname-fqdn ist der Hostname für die Maschine im FQDN-Format.

Die Option -H ist erforderlich, damit adcli SPN im folgenden, vom Linux VDA benötigten Format erstellen kann: host/hostname-fqdn@REALM.

Überprüfen der Systemschlüsseltabelle:

Die Möglichkeiten des adcli-Tools sind begrenzt und bieten keine Möglichkeit zu testen, ob eine Maschine mit der Domäne verbunden ist. Führen Sie als Alternative folgenden Befehl aus, um sicherzustellen, dass die Systemdatei für die Schlüsseltabelle erstellt wurde:

sudo klist -ket
<!--NeedCopy-->

Prüfen Sie, ob die Zeitstempel der einzelnen Schlüssel mit der Zeit übereinstimmen, zu der der Domänenbeitritt der Maschine erfolgte.

Verwenden von samba für den Domänenbeitritt:

Installieren Sie das Paket:

sudo apt-get install samba
<!--NeedCopy-->

Konfigurieren Sie samba:

Öffnen Sie /etc/samba/smb.conf und nehmen Sie folgende Einstellungen vor:

[global]

   workgroup = WORKGROUP

   security = ADS

   realm = REALM

   client signing = yes

   client use spnego = yes

   kerberos method = secrets and keytab
<!--NeedCopy-->

WORKGROUP ist das erste Feld in REALM und REALM ist der Kerberos-Bereichsname in Großbuchstaben.

Domänenbeitritt mit samba:

Es wird vorausgesetzt, dass der Domänencontroller erreichbar ist und dass Sie über ein Windows-Benutzerkonto mit Berechtigungen zum Hinzufügen von Computern zur Domäne verfügen.

sudo net ads join REALM -U user
<!--NeedCopy-->

REALM ist der Kerberos-Bereichsname in Großbuchstaben und user ist ein Domänenbenutzer mit Berechtigungen zum Hinzufügen von Computern zur Domäne.

Einrichten von SSSD

Installieren oder aktualisieren Sie die erforderlichen Pakete:

Installieren Sie ggf. die erforderlichen SSSD- und Konfigurationspakete:

sudo apt-get install sssd
<!--NeedCopy-->

Wenn die Pakete bereits installiert sind, wird die Aktualisierung empfohlen:

sudo apt-get update sssd
<!--NeedCopy-->

Hinweis:

Beim Installationsvorgang in Ubuntu werden nsswitch.conf und das PAM-Anmeldemodul automatisch konfiguriert.

Konfigurieren von SSSD

Vor dem Start des SSSD-Daemon sind SSSD-Konfigurationsänderungen erforderlich. Für einige Versionen von SSSD ist die Konfigurationsdatei /etc/sssd/sssd.conf nicht standardmäßig installiert und muss manuell erstellt werden. Öffnen oder erstellen Sie als Root-Benutzer /etc/sssd/sssd.conf und nehmen Sie folgende Einstellungen vor:

[sssd]

services = nss, pam

config_file_version = 2

domains = domain-dns-name

[domain/domain-dns-name]

id_provider = ad

access_provider = ad

auth_provider = krb5

krb5_realm = REALM

# Set krb5_renewable_lifetime higher if TGT renew lifetime is longer than 14 days

krb5_renewable_lifetime = 14d

# Set krb5_renew_interval to lower value if TGT ticket lifetime is shorter than 2 hours

krb5_renew_interval = 1h

krb5_ccachedir = /tmp

krb5_ccname_template = FILE:%d/krb5cc_%U

# This ldap_id_mapping setting is also the default value

ldap_id_mapping = true

override_homedir = /home/%d/%u

default_shell = /bin/bash

ad_gpo_map_remote_interactive = +ctxhdx
<!--NeedCopy-->

Hinweis:

ldap_id_mapping ist auf true festgelegt, sodass SSSD die Zuordnung von Windows SIDs zu Unix UIDs selbst vornimmt. Andernfalls muss Active Directory POSIX-Erweiterungen bereitstellen können. Der PAM-Dienst ctxhdx wird ad_gpo_map_remote_interactive hinzugefügt.

Die Eigenschaft domain-dns-name ist in diesem Kontext der DNS-Domänenname, z. B. example.com. REALM ist der Kerberos-Bereichsname in Großbuchstaben, z. B. EXAMPLE.COM. Die Konfiguration des NetBIOS-Domänennamens ist nicht erforderlich.

Tipp:

Weitere Informationen zu diesen Konfigurationseinstellungen finden Sie auf den Manpages über sssd.conf und sssd-ad.

Für den SSSD-Daemon muss die Konfigurationsdatei Besitzer-Leseberechtigung haben:

sudo chmod 0600 /etc/sssd/sssd.conf
<!--NeedCopy-->

Starten des SSSD-Daemon

Führen Sie die folgenden Befehle aus, um den SSSD-Daemon zu starten und den Daemon beim Systemstart der Maschine zu aktivieren:

sudo systemctl start sssd

sudo systemctl enable sssd
<!--NeedCopy-->

PAM-Konfiguration

Führen Sie den folgenden Befehl aus. Stellen Sie sicher, dass die Optionen SSS authentication und Create home directory on login aktiviert sind:

sudo pam-auth-update
<!--NeedCopy-->

Überprüfen der Domäneneigentümerschaft

Für den Delivery Controller ist es erforderlich, dass alle VDA-Maschinen(Windows und Linux VDAs) ein Computerobjekt in Active Directory haben.

Überprüfen Sie die Domänenmitgliedschaft mit adcli:

Zeigen Sie die Domäneninformationen an, indem Sie folgenden Befehl ausführen:

sudo adcli info domain-dns-name
<!--NeedCopy-->

Überprüfen Sie die Domänenmitgliedschaft mit samba:

Führen Sie den Samba-Befehl net ads aus, um zu prüfen, ob die Maschine zu einer Domäne gehört:

sudo net ads testjoin
<!--NeedCopy-->

Führen Sie den folgenden Befehl aus, um zusätzliche Domänen- und Computerobjektinformationen zu überprüfen:

sudo net ads info
<!--NeedCopy-->

Überprüfen der Kerberos-Konfiguration

Überprüfen Sie, ob Kerberos zur Verwendung mit dem Linux VDA ordnungsgemäß konfiguriert ist, indem Sie sicherstellen, dass die Systemdatei für die Schlüsseltabelle erstellt wurde und gültige Schlüssel enthält:

sudo klist -ke
<!--NeedCopy-->

Mit diesem Befehl wird die Liste der Schlüssel angezeigt, die für die verschiedenen Kombinationen aus Prinzipalnamen und Verschlüsselungssammlungen verfügbar sind. Führen Sie den Kerberos-Befehl kinit aus, um die Maschine mit dem Domänencontroller mit diesen Schlüsseln zu authentifizieren:

sudo kinit -k MACHINE$@REALM
<!--NeedCopy-->

Maschinen- und Bereichsname müssen in Großbuchstaben angegeben werden. Das Dollarzeichen ($) muss durch einen umgekehrten Schrägstrich (\) geschützt werden, um das Ersetzen in der Shell zu verhindern. In einigen Umgebungen sind DNS-Domänenname und Kerberos-Bereichsname unterschiedlich. Stellen Sie sicher, dass der Bereichsname verwendet wird. Wenn dieser Befehl erfolgreich ist, wird keine Ausgabe angezeigt.

Stellen Sie mit folgendem Befehl sicher, dass das TGT-Ticket für das Maschinenkonto zwischengespeichert wurde:

sudo klist
<!--NeedCopy-->

Überprüfen der Benutzerauthentifizierung

SSSD bietet kein Befehlszeilentool zum direkten Testen der Authentifizierung mit dem Daemon, daher kann der Test nur mit PAM ausgeführt werden.

Um sich zu vergewissern, dass das SSSD-PAM-Modul fehlerfrei konfiguriert wurde, melden Sie sich mit einem Domänenbenutzerkonto am Linux VDA an. Das Domänenbenutzerkonto wurde zuvor noch nicht verwendet.

ssh localhost -l domain\username

id -u

klist

exit
<!--NeedCopy-->

Stellen Sie sicher, dass die vom Befehl klist zurückgegebenen Kerberos-Tickets für den Benutzer richtig und nicht abgelaufen sind.

Überprüfen Sie als Root-Benutzer, dass eine entsprechende Ticketcachedatei für die mit dem Befehl id -u zurückgegebene UID erstellt wurde:

ls /tmp/krb5cc_uid
<!--NeedCopy-->

Ein ähnlicher Test kann ausgeführt werden, wenn Sie sich direkt am KDE- oder Gnome-Anzeigemanager anmelden. Fahren Sie nach der Überprüfung des Domänenbeitritts mit Schritt 4: Installieren des Linux VDA fort.

Schritt 4: Installieren des Linux VDA

Schritt 4a: Herunterladen des Linux VDA-Pakets

Rufen Sie die Citrix-Website auf und laden Sie das entsprechende Linux VDA-Paket herunter, je nach Linux-Distribution.

Schritt 4b: Installieren des Linux VDA

Installieren Sie die Linux VDA-Software mit dem Debian-Paketmanager:

sudo dpkg -i xendesktopvda_7.15.0.404-1.ubuntu16.04_amd64.deb
<!--NeedCopy-->

Debian-Abhängigkeitsliste für Ubuntu:

postgresql >= 9.5

libpostgresql-jdbc-java >= 9.2

default-jdk >= 2:1.8

imagemagick >= 8:6.8.9.9

ufw >= 0.35

ubuntu-desktop >= 1.361

libxrandr2 >= 2:1.5.0

libxtst6 >= 2:1.2.2

libxm4 >= 2.3.4

util-linux >= 2.27.1

bash >= 4.3

findutils >= 4.6.0

sed >= 4.2.2

cups >= 2.1

libldap-2.4-2 >= 2.4.42

libsasl2-modules-gssapi-mit >= 2.1.~

python-requests >= 2.9.1

libgoogle-perftools4 >= 2.4~
<!--NeedCopy-->

Schritt 4c: Konfigurieren des Linux VDA

Nach der Installation des Pakets müssen Sie den Linux VDA konfigurieren, indem Sie das Skript ctxsetup.sh ausführen. Das Skript überprüft die Umgebung und stellt sicher, dass alle Abhängigkeiten installiert sind. Führen Sie Änderungen erst danach durch. Sie können das Skript nach Bedarf jederzeit erneut ausführen, um Einstellungen zu ändern.

Sie können das Skript manuell unter Reaktion auf Aufforderungen oder automatisch mit vorkonfigurierten Antworten ausführen. Lesen Sie die Hilfe zum Skript durch, bevor Sie fortfahren:

sudo /opt/Citrix/VDA/sbin/ctxsetup.sh –help
<!--NeedCopy-->

Konfiguration mit Aufforderungen

Führen Sie eine manuelle Konfiguration mit Aufforderungen aus:

sudo /opt/Citrix/VDA/sbin/ctxsetup.sh
<!--NeedCopy-->

Automatische Konfiguration

Bei einer automatischen Installation können die für das Setupskript erforderlichen Optionen mit Umgebungsvariablen angegeben werden. Wenn alle erforderlichen Variablen vorhanden sind, fordert das Skript keine weiteren Informationen vom Benutzer und der Installationsvorgang wird per Skript ausgeführt.

Unterstützte Umgebungsvariablen umfassen u. a.:

• CTX_XDL_SUPPORT_DDC_AS_CNAME = Y | N – Der Linux VDA unterstützt die Angabe des Namens eines Delivery Controllers mit einem DNS CNAME-Datensatz. Die Standardeinstellung ist N.
• CTX_XDL_DDC_LIST = list-ddc-fqdns – Der Linux VDA erfordert eine durch Leerzeichen getrennte Liste vollqualifizierter Domänennamen (FQDNs) für die Registrierung bei einem Delivery Controller. Mindestens ein FQDN oder CNAME-Alias muss angegeben werden.
• CTX_XDL_VDA_PORT = port-number – Der Linux VDA kommuniziert mit Delivery Controllern über einen TCP/IP-Port. Dies ist standardmäßig Port 80.
• CTX_XDL_REGISTER_SERVICE = Y | N – Die Linux Virtual Desktop-Dienste werden nach dem Systemstart gestartet. Die Standardeinstellung ist Y.
• CTX_XDL_ADD_FIREWALL_RULES = Y | N – Für die Linux Virtual Desktop-Dienste muss die Systemfirewall eingehende Netzwerkverbindungen zulassen. Sie können die erforderlichen Ports (standardmäßig Port 80 und 1494) in der Systemfirewall automatisch für Linux Virtual Desktop öffnen. Die Standardeinstellung ist Y.
• CTX_XDL_AD_INTEGRATION = 1 | 2 | 3 | 4 – Der Linux VDA erfordert Kerberos-Konfigurationseinstellungen für die Authentifizierung bei den Delivery Controllern. Die Kerberos-Konfiguration wird durch das auf dem System installierte und konfigurierte Active Directory-Integrationstool bestimmt. Geben Sie die zu verwendende Active Directory-Integrationsmethode an:
  • 1 – Samba Winbind
  • 2 – Quest-Authentifizierungsdienst
  • 3 – Centrify DirectControl
  • 4 – SSSD
• CTX_XDL_HDX_3D_PRO = Y | N – Der Linux VDA unterstützt HDX 3D Pro – GPU-Beschleunigungstechnologien zum Optimieren der Virtualisierung reichhaltiger Grafikanwendungen. Wenn HDX 3D Pro aktiviert ist, muss der Virtual Delivery Agent für VDI-Desktopmodus (Einzelsitzungen) konfiguriert werden (d. h. CTX_XDL_VDI_MODE=Y).
• CTX_XDL_VDI_MODE = Y | N – Ermöglicht die Konfiguration der Maschine als dediziertes Desktopbereitstellungsmodell (VDI) oder als gehostetes, freigegebenes Desktopbereitstellungsmodell. Legen Sie dies bei Umgebungen mit HDX 3D Pro auf “Y” fest. Standardmäßig ist diese Variable auf N festgelegt.
• CTX_XDL_SITE_NAME = dns-name – Der Linux VDA ermittelt LDAP-Server über DNS. Geben Sie einen DNS-Sitenamen an, wenn Sie die Suchergebnisse auf eine lokale Site beschränken möchten. Die Standardeinstellung für diese Variable ist <none>.
• CTX_XDL_LDAP_LIST = list-ldap-servers – Der Linux VDA fragt DNS zur Erkennung von LDAP-Servern ab. Falls DNS keine LDAP-Diensteinträge bereitstellen kann, können Sie eine durch Leerzeichen getrennte Liste der FQDNs mit LDAP-Port angeben. Beispiel: ad1.mycompany.com:389. Die Standardeinstellung für diese Variable ist <none>.
• CTX_XDL_SEARCH_BASE = search-base-set – Die Suchbasis bei LDAP-Abfragen des Linux VDA ist das Stammverzeichnis der Active Directory-Domäne (z. B. DC=mycompany,DC=com). Zur Verbesserung der Suchleistung können Sie eine Suchbasis angeben (z. B. OU=VDI, DC=mycompany,DC=com). Die Standardeinstellung für diese Variable ist <none>.
• CTX_XDL_START_SERVICE = Y | N – Legt fest, ob die Linux VDA-Dienste gestartet werden, wenn die Linux VDA-Konfiguration abgeschlossen ist. Die Standardeinstellung ist Y.

Legen Sie die Umgebungsvariable fest und führen Sie das Konfigurationsskript aus:

export CTX_XDL_SUPPORT_DDC_AS_CNAME=Y|N

export CTX_XDL_DDC_LIST=list-ddc-fqdns

export CTX_XDL_VDA_PORT=port-number

export CTX_XDL_REGISTER_SERVICE=Y|N

export CTX_XDL_ADD_FIREWALL_RULES=Y|N

export CTX_XDL_AD_INTEGRATION=1|2|3|4

export CTX_XDL_HDX_3D_PRO=Y|N

export CTX_XDL_VDI_MODE=Y|N

export CTX_XDL_SITE_NAME=dns-name

export CTX_XDL_LDAP_LIST=list-ldap-servers

export CTX_XDL_SEARCH_BASE=search-base-set

export CTX_XDL_START_SERVICE=Y|N

sudo -E /opt/Citrix/VDA/sbin/ctxsetup.sh
<!--NeedCopy-->

Sie müssen die Option -E mit dem Befehl “sudo” angeben, damit die vorhandenen Umgebungsvariablen an die neu erstellte Shell weitergegeben werden. Citrix empfiehlt, dass Sie mit den oben aufgeführten Befehlen eine Shellskriptdatei erstellen, deren erste Zeile #!/bin/bash enthält.

Alternativ können Sie alle Parameter mit einem einzigen Befehl festlegen:

sudo CTX_XDL_SUPPORT_DDC_AS_CNAME=Y|N \

CTX_XDL_DDC_LIST=list-ddc-fqdns \

CTX_XDL_VDA_PORT=port-number \

CTX_XDL_REGISTER_SERVICE=Y|N \

CTX_XDL_ADD_FIREWALL_RULES=Y|N \

CTX_XDL_AD_INTEGRATION=1|2|3|4 \

CTX_XDL_HDX_3D_PRO=Y|N \

CTX_XDL_VDI_MODE=Y|N \

CTX_XDL_SITE_NAME=dns-name \

CTX_XDL_LDAP_LIST=list-ldap-servers \

CTX_XDL_SEARCH_BASE=search-base-set \

CTX_XDL_START_SERVICE=Y|N \

/opt/Citrix/VDA/sbin/ctxsetup.sh
<!--NeedCopy-->

Entfernen von Konfigurationsänderungen

In einigen Fällen müssen die vom Skript ctxsetup.sh vorgenommenen Konfigurationsänderungen entfernt werden, ohne das Linux VDA-Paket zu deinstallieren.

Lesen Sie die Hilfe zu diesem Skript durch, bevor Sie fortfahren:

sudo /opt/Citrix/VDA/sbin/ctxcleanup.sh --help
<!--NeedCopy-->

Entfernen von Konfigurationsänderungen:

sudo /opt/Citrix/VDA/sbin/ctxcleanup.sh
<!--NeedCopy-->

Wichtig:

Dieses Skript löscht alle Konfigurationsdaten aus der Datenbank, sodass der Linux VDA nicht funktionsfähig ist.

Konfigurationsprotokolle

Die Skripts ctxsetup.sh und ctxcleanup.sh zeigen Fehler auf der Konsole an und schreiben weitere Informationen in die Konfigurationsprotokolldatei /tmp/xdl.configure.log.

Starten Sie die Linux VDA-Dienste neu, damit die Änderungen wirksam werden.

Deinstallieren der Linux VDA-Software

Überprüfen, ob der Linux VDA installiert ist, und Anzeigen der Version des installierten Pakets:

dpkg -l xendesktopvda
<!--NeedCopy-->

Anzeigen weiterer Details:

apt-cache show xendesktopvda
<!--NeedCopy-->

Deinstallieren der Linux VDA-Software:

dpkg -r xendesktopvda
<!--NeedCopy-->

Hinweis:

Beim Deinstallieren der Linux VDA-Software werden die damit verknüpften PostgreSQL- und andere Konfigurationsdaten gelöscht. Das PostgreSQL-Paket und andere abhängige Pakete, die vor der Installation des Linux VDA eingerichtet wurden, werden nicht gelöscht.

Tipp:

Die Informationen in diesem Abschnitt beziehen sich nicht auf das Entfernen von abhängigen Paketen einschließlich PostgreSQL.

Schritt 5: Ausführen des Linux VDA

Wenn Sie den Linux VDA mit dem Skript ctxsetup.sh konfiguriert haben, können Sie den Linux VDA mit den folgenden Befehlen steuern.

Starten Sie den Linux VDA:

Starten der Linux VDA-Dienste:

sudo systemctl start ctxhdx

sudo systemctl start ctxvda
<!--NeedCopy-->

Halten Sie den Linux VDA an:

Anhalten der Linux VDA-Dienste:

sudo systemctl stop ctxvda

sudo systemctl stop ctxhdx
<!--NeedCopy-->

Starten Sie den Linux VDA neu:

Neustarten der Linux VDA-Dienste:

sudo systemctl stop ctxvda

sudo systemctl restart ctxhdx

sudo systemctl restart ctxvda
<!--NeedCopy-->

Überprüfen Sie den Linux VDA-Status:

Überprüfen des Ausführungsstatus der Linux VDA-Dienste:

sudo systemctl status ctxvda

sudo systemctl status ctxhdx
<!--NeedCopy-->

Schritt 6: Erstellen des Maschinenkatalogs in XenApp oder XenDesktop

Der Prozess zum Erstellen von Maschinenkatalogen und Hinzufügen von Linux VDA-Maschinen ähnelt der traditionellen Windows VDA-Methode. Umfassendere Informationen zu diesen Prozessen finden Sie unter Erstellen von Maschinenkatalogen und Verwalten von Maschinenkatalogen.

Beim Erstellen von Maschinenkatalogen mit Linux VDA-Maschinen gibt es einige Einschränkungen, durch die sich der Prozess von der Maschinenkatalogerstellung für Windows VDA-Maschinen unterscheidet:

• Auswahl des Betriebssystems:
  • Das Serverbetriebssystem für ein gehostetes, freigegebenes Desktopbereitstellungsmodell.
  • Das Desktopbetriebssystem für ein VDI-dediziertes Desktopbereitstellungsmodell.
• Stellen Sie sicher, dass für die Maschinen keine Energieverwaltung festgelegt ist.
• Da MCS für Linux VDAs nicht unterstützt wird, wählen Sie die Bereitstellungsmethode PVS oder Anderer Dienst oder andere Technologie (vorhandene Images).
• In einem Maschinenkatalog darf sich keine Mischung aus Linux und Windows VDA-Maschinen befinden.

Hinweis:

In früheren Citrix Studio-Versionen wurde Linux als Betriebssystem nicht unterstützt. Durch die Auswahl von Windows-Serverbetriebssystem oder Serverbetriebssystem wird jedoch ein äquivalentes gehostetes, freigegebenes Desktopbereitstellungsmodell bereitgestellt. Durch die Auswahl von Windows-Desktopbetriebssystem oder Desktopbetriebssystem wird ein Bereitstellungsmodell für Einzelbenutzermaschinen bereitgestellt.

Tipp:

Wenn Sie eine Maschine aus einer Active Directory-Domäne entfernen und sie ihr dann wieder hinzufügen, muss die Maschine auch aus dem Maschinenkatalog entfernt und ihm dann erneut hinzugefügt werden.

Schritt 7: Erstellen der Bereitstellungsgruppe in XenApp oder XenDesktop

Die Prozesse zum Erstellen einer Bereitstellungsgruppe und zum Hinzufügen von Maschinenkatalogen mit Linux VDA- bzw. Windows VDA-Maschinen sind fast identisch. Umfassendere Informationen zu diesen Prozessen finden Sie unter Erstellen von Bereitstellungsgruppen.

Beim Erstellen von Bereitstellungsgruppen mit Linux VDA-Maschinenkatalogen gelten die folgenden Einschränkungen:

• Wählen Sie als Bereitstellungstyp Desktops aus. Linux VDA für Ubuntu unterstützt keine Bereitstellung von Anwendungen.
• Stellen Sie sicher, dass die ausgewählten Active Directory-Benutzer und -Gruppen für die Anmeldung an Linux VDA-Maschinen richtig konfiguriert wurden.
• Lassen Sie nicht die Anmeldung nicht authentifizierter (anonymer) Benutzer zu.
• Die Bereitstellungsgruppe darf keine Maschinenkataloge mit Windows Maschinen enthalten.