UserInterface installieren (Windows)

Ablauf der Installation

Online-Dokumentation installieren

---

Einrichten von Single Sign-On

In folgendem Dokument finden Sie die detaillierte Anleitung, um Single Sign-On (SSO) für das Automation Engine-System einzurichten. Mit Single Sign-On ist es möglich, eine Anmeldung durchzuführen, ohne dabei Login-Daten eingeben zu müssen.

Für Single Sign-On wird Kerberos KDC (Key Distribution Center) verwendet. Ist Single Sign-On korrekt konfiguriert, so ist die Anmeldung (UserInterface, Enterprise Control Center) am Automation Engine-System möglich, ohne die Login-Daten (Benutzer, Abteilung und Passwort) eingeben zu müssen. Für die Authentifizierung wird der Betriebssystem-Benutzer verwendet, unter welchem beispielsweise das UserInterface gestartet wurde.

Die Installationsanleitung gilt für Windows und UNIX.

Allgemeine Voraussetzungen

• JWP:
  Es muss mindestens ein JWP (Java-basierter Arbeitsprozess) aktiv sein.
• Zeitunterschiede
  Uhrzeit von Client- (UserInterface, Java API) und Server-Rechner (JWP) dürfen sich nicht stark unterscheiden. Je nach Einstellung ist eine Differenz von 5 bis 10 Minuten erlaubt. Andernfalls kann es bei der Anmeldung zum Fehler "Clock skew too great" kommen.
• Zugriff auf KDC
  UserInterface und JWP benötigen Zugriff auf das KDC (z. B.: Active Directory bei Windows). Es reicht daher nicht, dass das UserInterface beispielsweise nur Zugriff auf den CP hat.
• Unterstützte JVM
  Derzeit wird nur Oracle Java für Single Sign-On unterstützt. Läuft eine Komponente (JWP, UserInterface, Java API) unter IBM Java, wird die Anmeldung abbrechen.

Installationsschritte für UserInterface und Automation Engine

	1.	Registry Key für TGT-Zugriff

Dieser Schritt ist nur notwendig, wenn das UserInterface unter Windows läuft.

Dieser Registry Key ist notwendig, damit die Kerberos Java-Implementierung ein bestehendes TGT (Ticket Granting Ticket) verwenden darf. Das TGT wird durch die Anmeldung am Betriebssystem erzeugt.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters]
"allowtgtsessionkey"=dword:00000001

	2.	Installation der Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy

Die JCE Unlimited Strength Jurisdiction Policy muss auf den Computern installiert werden, auf denen:

• die UserInterface und/oder das ECC läuft;
• die Automation Engine (JWP) läuft.

Download unter Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy

Die Readme-Datei enthält die Installationsanleitung. Gibt es mehrere Java-Installationen auf demselben Rechner, wird empfohlen, die policy-Datei für alle Installationen einzurichten.

	3.	Kerberos-Konfigurationsdatei

Dieser Schritt kann ausgelassen werden, wenn das UserInterface unter Windows mit Java Version 1.7 läuft. Mit Java 1.7 unter Windows werden die Einstellungen automatisch erkannt.

In allen anderen Fällen sollte die Datei krb5.conf angelegt werden. Der Ort für die Konfigurationsdatei ist <java-home>/lib/security.

Die genaue Suchreihenfolge ist unter http://download.java.net/jdk8/docs/technotes/guides/security/jgss/tutorials/KerberosReq.html im Punkt "Locating the krb5.conf Configuration File" beschrieben. Der Aufbau dieser Datei ist in der Kerberos-Dokumentation beschrieben.

Beispiel:

[libdefaults]
default_realm = DOMAIN.SAMPLE
[domain_realm]
.domain.sample = DOMAIN.SAMPLE

[realms]
DOMAIN.SAMPLE = {
kdc = servername.domain.sample
admin_server = servername.domain.sample
}

	4)	Einschalten von KDC in den systemweiten Einstellungen der AE

Setzen Sie KDC in der Datei UC_SYSTEM_SETTINGS auf Y, um die Kerberos Distribution Center (KDC)-Authentifizierung für ein ganzes System zu aktivieren.

Installationsschritte für den JWP

Erzeugen der Keytab-Datei

Folgende Schritte sind vom KDC-Administrator durchzuführen (pro CP-Host).

	1.	Anlegen eines Service-Benutzers am KDC

Erstellen Sie einen neuen Service-Benutzer am KDC (bei Windows beispieslweise am Active Directory), der für die Authentifizierung verwendet werden soll. Das Passwort des Benutzers sollte nicht ablaufen.

	2.	Anlegen der Service Principal Names (SPN)

Anschließend sind Service Principal Names (SPN) mit folgender Bezeichnung anzulegen:
<AE System-Name>/<CP Host Name>[@<Realm>]
<AE System-Name>/<Vollqualifizierter Domain-Name des CP Host>[@<Realm>]

Es wird empfohlen, bei SPNs pro CP-Host anzulegen (einen SPN mit dem Hostnamen und einen mit dem vollqualifizierten Domain-Namen).

Achten Sie bei der Erstellung der SPNs auf Groß- und Kleinschreibung. Ansonsten wird der Name eventuell nicht in der Kerberos-Datenbank gefunden.

Der Realm ist optional. Wird dieser nicht angegeben, so wird der Standardwert aus der Konfigurationsdatei krb5.conf verwendet. Unter Windows entspricht <Realm> immer dem Domain-Namen (DNS-Suffix) in Großbuchstaben (z. B.: DOMAIN.SAMPLE)

Siehe auch: Detaillierte Beschreibung von Kerberos Principals.

Beispiel:
AEServer01/winhost01.domain.sample@DOMAIN.SAMPLE

Die SPNs sind dabei dem zuvor angelegten KDC Service-Benutzer zuzuweisen.

Beim Active Directory von Microsoft kann der Befehl "setspn" verwendet werden, um die SPNs anzulegen. Wie oben erwähnt, wird empfohlen, einen Eintrag für den Hostnamen und einen für den vollqualifizierten Domainnamen anzulegen.
Beispiel:

setspn -s AEServer01/winhost01.sample.host@SAMPLE.DOMAIN ServiceAccount01
setspn -s AEServer01/winhost01@DOMAIN.SAMPLE ServiceAccount01

	3.	Erzeugen der keytab Datei

In diesem Schritt ist eine keytab-Datei zu erzeugen.

Beim Microsoft Active Directory kann dazu der Befehl "ktpass" verwendet werden. Dabei sind SPN, KDC-Benutzer, dessen Passwort und Pfad/Dateiname der Keytab-Datei anzugeben.

Beispiel:

ktpass /princ AEServer01/winhost01.domain.sample@DOMAIN.SAMPLE /mapuser ServiceAccount01@DOMAIN.SAMPLE /pass UXTY5rdx+!1245.qw /mapop set /crypto all /out c:\temp\ae.keytab -ptype krb5_nt_principal

Dadurch wird die Keytab-Datei C:\temp\ae.keytab erstellt.

Details zur Syntax des Befehls "ktpass": http://technet.microsoft.com/en-us/library/cc753771.aspx

Wenn Sie bei der Generierung der .keytab-Datei eine Fehlermeldung erhalten, sollten Sie im oben genannten Beispiel den folgenden zusätzlichen Switch verwenden:

-ptype KRB5_NT_PRINCIPAL

Der Grund für die angezeigte Fehlermeldung liegt vermutlich darin, dass der SPN keinem Principal zugeordnet wurde. KRB5_NT_PRINCIPAL ist der von Microsoft dokumentierte und empfohlene allgemeine Principal-Typ.

Mehrere CPs auf unterschiedlichen Hosts

Laufen die Kommunikationsprozesse des Automation Engine-Systems auf unterschiedlichen Hosts, dann müssen die Schritte für die Erzeugung der Keytab-Datei (Schritt 2 und 3) für jeden Hostnamen ausgeführt werden.

Dadurch entstehen zusätzliche Keytab-Dateien. Der JWP benötigt jedoch nur genau eine Datei, wodurch die Einträge zu einer Datei zusammengefügt werden müssen.

Dazu kann das Programm 'ktutil' auf Unix mit folgenden Befehlen verwendet werden:

ktutil

rkt keytab1.keytab

rkt keytab2.keytab

wkt merged.keytab

Hierdurch wird eine neue Datei namens "merged.keytab" erstellt, die Einträge von keytab1 und keytab2 enthält.

Da Oracle Java den 'merge' Parameter nicht kennt, ist die einfachste Lösung, die Dateien unter UNIX zu 'mergen' und dann zu Ihrer Windows Installation zu transferieren.

	4.	Angabe der Keytab-Datei

Nun sind Pfad und Dateiname der erzeugten Keytab-Datei im Variablen-Objekt UC_KDC_SETTINGS einzutragen, welches sich im Mandant 0 befindet.

In der Key-Spalte des Variablen-Objektes ist der Wert "KEYTAB" anzugeben, in der Spalte "Wert 1" die Keytab-Datei.

Nach Änderung der Variable muss der JWP neu gestartet werden.

Sind mehrere JWPs auf unterschiedlichen Hosts ,dann muss die Keytab-Datei auf allen Hosts im gleichen Verzeichnis vorhanden sein. Fehlt die Datei auf einem oder mehreren Hosts, dann wird die Anmeldung sporadisch nicht funktionieren.

	5.	SSO-Konfiguration für Webanwendungen

Um das Single Sign-On für Webanwendungen (wie Enterprise Control Center oder Automic Release Automation) duchführen zu können, wird eine Keytab-Datei mit HTTP als Service-Principal-Name benötigt.

Beispiel:
HTTP/winhost01.domain.sample

winhost01 ist in diesem Beispiel der Host, auf welchem beispielsweise das Enterprise Control Center (Tomcat) installiert ist.

Der Name des SPN muss zusätzlich in der Variable UC_KDC_SETTINGS mit dem Key "HTTP" eingetragen werden. Sind mehrere ECC/ARA-Installationen für ein Automation Engine-System vorhanden, dann können weitere Namen mit Strichpunkt getrennt hinzugefügt werden.

Beispiel:
HTTP/winhost01.domain.sample;HTTP/winhost02.domain.sample

Benutzer für die Authentifizierung

Nach erfolgreichem Abschluss der Konfiguration sind entsprechende Benutzer in den Mandanten des Automation Engine-Systems anzulegen.

Die Namen der Benutzer müssen jenen der Betriebssystem-Benutzer entsprechen, denen Zugriff über Single Sign-On gewährt werden soll.

Die Abteilung spielt keine Rolle, solange der Benutzername pro Mandant eindeutig ist. Existieren zwei oder mehrere Benutzer mit selbem Namen, aber einer unterschiedlichen Abteilung, so ist jede dieser Abteilungen in der Variable UC_KDC_SETTINGS einer Domäne zuzuordnen.

Die Single Sign-On-Anmeldung wird fehlschlagen, wenn im ausgewählten Mandanten kein Benutzer-Objekt existiert, welches denselben Namen wie der Betriebssystem-Benutzer aufweist, unter welchem beispielsweise das UserInterface gestartet wurde.

Beispiel:

UserInterface wird unter Windows unter dem Benutzer "test\local" gestartet.
AE-System TEST, Mandant: 100

Existiert im Mandant 100 kein Benutzer-Objekt mit dem Namen "TEST\*" (Abteilung spielt keine Rolle), ist die Single Sign-On-Anmeldung nicht möglich.

Gibt es mehrere Benutzer im Mandant 100 mit dem Namen "TEST\*" (beispielsweise "TEST\DEV" und "TEST|LOCAL"), sind die Abteilungen (wie oben beschrieben) den Domänen der Betriebssystem-Benutzer zuzuordnen. Fehlt die Zuordnung, wird die Anmeldung ebenfalls fehlschlagen.