Registrys des lokalen Betriebssystems
Mit der Registry-Implementierung für das lokale Betriebssystem kann das Authentifizierungsverfahren von WebSphere Application Server die Datenbank mit den Benutzerkonten des lokalen Betriebssystems verwenden.
Wenn Sie die Registry des lokalen Betriebssystems verwenden möchten, um die Principals darzustellen,
die auf die Ressourcen von
WebSphere Application Server
zugreifen, müssen Sie keine speziellen Schritte für die Konfiguration der
Benutzerregistry ausführen. Die Registry des lokalen Betriebssystems wird für die Authentifizierung und
Berechtigung der Benutzer verwendet, die auf die Ressourcen von
WebSphere Application Server
zugreifen, aber nicht für die Benutzer von WebSphere
Application Server, die auf die Betriebssystemressourcen zugreifen. WebSphere
Application Server wird nicht unter dem Betriebssystemprofil der Application-Server-Benutzer ausgeführt,
sondern unter dem Betriebssystemprofil, das vom Application Server-Administrator konfiguriert wird.
Wenn Sie einen Benutzer für eine Ressource von
WebSphere Application
Server berechtigen möchten, muss im Betriebssystem ein Benutzerprofil für diesen Benutzer vorhanden sein.
Verwenden Sie den Befehl Create User Profile (CRTUSRPRF), um neue Benutzer-IDs zu erstellen, die von
WebSphere Application Server verwendet werden können.
Lightweight
Directory Access Protocol (LDAP) ist eine zentrale Registry. Die meisten Registrys des lokalen Betriebssystems
sind keine zentralen Registrys.
WebSphere
Application Server stellt Implementierungen für die lokale Benutzerkontenregistry und Domänenregistry von
Windows sowie
Implementierungen für die Benutzerkontenregistrys von Linux,
Solaris und AIX bereit.
Windows Active Directory
wird durch die Implementierung der LDAP-Benutzerregistry unterstützt wird. Diese
Implementierung wird später beschrieben.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
Eine Registry des lokalen Betriebssystems
sollte in einer Umgebung mit WebSphere
Application Server, in der
Anwendungsserver auf mehrere Maschinen verteilt sind, nicht verwendet werden, weil jede Maschine ihre eigene
Benutzerregistry hat.
Die
Windows-Domänenregistry und Network Information Services
(NIS) sind Ausnahmen. Sowohl die
Windows-Domänenregistry als auch Network Information
Services (NIS) sind zentrale Registrys. Die
Windows-Domänenregistry wird von
WebSphere Application Server unterstützt, NIS nicht.
Außerdem werden die
der Benutzerregistry entnommenen Zugriffs-IDs, wie bereits erwähnt, für die Berechtigungsprüfungen
verwendet.
Da diese IDs normalerweise eindeutige Kennungen sind, unterscheiden sie sich von Maschine zu Maschine, auch wenn genau dieselben Benutzer und Kennworte auf jeder Maschine existieren.
Die Authentifizierung anhand von Web-Client-Zertifikaten wird derzeit
nicht unterstützt, wenn die LocalOS-Benutzerregistry verwendet wird.
Allerdings funktioniert die Authentifizierung anhand von Java™-Clientzertifikaten bei Verwendung der LocalOS-Benutzerregistry. Bei
der Authentifizierung anhand von
Java-Clientzertifikaten
wird das erste Attribut des Namens der Zertifikatsdomäne der Benutzer-ID in der Benutzerregistry zugeordnet.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
CWSCJ0337E: Die Methode mapCertificate wird nicht unterstützt.
Der Fehler bezieht sich eigentlich auf die Web-Client-Zertifikate, wird aber auch für die Java-Clientzertifikate angezeigt. Sie können diesen Fehler für Java-Clientzertifikate ignorieren.Eine Registry des lokalen Betriebssystems ist eine zentrale Registry in
einem Systemkomplex.
WebSphere
Application Server verwendet SAF-Schnittstellen (System Authorization Facility). Die SAF-Schnittstellen werden von
MVS definiert und ermöglichen Anwendungen die Verwendung
von Systemberechtigungsservices und Benutzerregistrys für die Steuerung des Zugriffs auf Ressourcen wie
Dateien und MVS-Befehle. Mit SAF können Anforderungen
für Sicherheitsberechtigungen
direkt über Resource Access Control Facility (RACF)
oder einen Sicherheitsprovider eines anderen
z/OS-Anbieters verarbeitet werden.
Sofern Sie das lokale Betriebssystem nicht als Benutzerregistry auswählen, müssen Sie
eine Zuordnung von Identitäten aus einer Benutzerregistry zu SAF-Benutzer-IDs bereitstellen. Weitere Informationen
finden Sie im Artikel Angepasste SAF-Zuordnungsmodule.
Die Authentifizierung anhand von Web-Client-Zertifikaten wird unterstützt, wenn die
LocalOS-Benutzerregistry verwendet wird. Web- und
Java-Clients können digitale Zertifikate
MVS-Identitäten zuordnen, wenn LocalOS ausgewählt wird. Für eine
einfachere Zuordnung können Filter für Zertifikatnamen verwendet werden. Wenn Sie
RACF als Sicherheitsserver verwenden,
erstellt der Befehl RACDCERT MAP ein Ressourcenprofil, das mehrere
Benutzeridentitäten einem digitalen Zertifikat zuordnet, um die Verwaltung der Zertifikate zu vereinfachen,
Speicherplatz in der RACF-Datenbank zu sparen,
die Abrechenbarkeit zu gewährleisten oder die Granularität bei der Zugriffssteuerung zu verwalten.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
Erforderliche Berechtigungen
Der Benutzer, der den WebSphere Application Server-Prozess ausgeführt, muss die erforderlichen Berechtigungen besitzen, um die API des Windows-Systems für die Authentifizierung aufrufen und Benutzer- oder Gruppendaten vom Windows-Betriebssystem abrufen zu können. Diese ID gehört in der Regel dem Benutzer, der sich an der Maschine anmeldet. Wenn WAS als Dienst ausgeführt wird, handelt es sich um das Anmeldekonto. Je nach Maschine (eine eigenständige Maschine oder eine Maschine, die zu einer Domäne gehört, oder der Domänencontroller selbst) variieren die Zugriffsanforderungen.
- Für eine eigenständige Maschine muss der Benutzer folgende Voraussetzungen erfüllen:
- Er muss Member der Administratorgruppe sein.
- Er muss die Berechtigung Einsetzen als Teil des Betriebssystems haben.
- Er muss die Berechtigung Als Dienst anmelden haben, wenn der Server als Dienst ausgeführt wird.
- Für eine Maschine, die Member einer Domäne ist, kann nur ein Domänenbenutzer
den Serverprozess starten. Der Benutzer muss folgende Voraussetzungen erfüllen:
- Er muss die Berechtigung Einsetzen als Teil des Betriebssystems in der Domänensicherheitsrichtlinie des Domänencontrollers haben.
- Er muss die Berechtigung Einsetzen als Teil des Betriebssystems in der lokalen Sicherheitsrichtlinie auf der lokalen Maschine haben.
- Er muss die Berechtigung Als Dienst anmelden auf der lokalen Maschine haben, wenn der Server als Dienst ausgeführt wird.
Der Benutzer ist ein Domänenbenutzer und kein lokaler Benutzer. Dies impliziert, dass nur ein Domänenbenutzer den Server starten kann, wenn eine Maschine Teil einer Domäne ist.
- Für einen Domänencontroller muss der Benutzer folgende Voraussetzungen erfüllen:
- Er muss Member der Domänenadministratorgruppe im Domänencontroller sein.
- Er muss die Berechtigung Einsetzen als Teil des Betriebssystems in der Domänensicherheitsrichtlinie des Domänencontrollers haben.
- Er muss die Berechtigung Als Dienst anmelden im Domänencontroller haben, wenn der Server als Dienst ausgeführt wird.
- A required privilege is not held by the client.
- Access is denied.

![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
Domänenregistrys und lokale Registrys
Wenn WebSphere Application Server gestartet wird, versucht der Laufzeitinitialisierungsprozess für Sicherheit dynamisch zu ermitteln, ob die lokale Maschine ein Member einer Windows-Domäne ist. Falls die Maschine zu einer Domäne gehört, können standardmäßig die Benutzer und Gruppen der lokalen Registry und der Domänenregistry für die Authentifizierung und Berechtigung verwendet werden. Die Domänenregistry hat jedoch Vorrang. Die Liste der Benutzer und Gruppen, die während der Zuordnung der Sicherheitsrollen angezeigt wird, enthält dann Benutzer und Gruppen aus beiden Registrys. Die Benutzer und Gruppen können anhand der ihnen zugeordneten Hostnamen unterschieden werden.
WebSphere Application Server bietet keine Unterstützung für vertrauenswürdige Domänen.
Falls die Maschine nicht zu einer Windows-Domäne gehört, wird die lokale Benutzerregistry der Maschine verwendet.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
Domänenbenutzerregistry und Registry des lokalen Betriebssystems verwenden
- Empfohlene Methoden
- Wenn die lokale Registry und die Domänenregistry keine gemeinsamen Benutzer oder Gruppen enthalten, lassen die Registrys sich einfacher verwalten. Unerwünschte Nebeneffekte sind damit ebenfalls ausgeschlossen. Erteilen Sie, sofern möglich, Benutzern und Gruppen Zugriff auf eindeutige Sicherheitsrollen, darunter Server-ID und administrative Rollen. In diesem Fall wählen Sie die Benutzer und Gruppen entweder aus der lokalen Benutzerregistry oder aus der Domänenbenutzerregistry aus, um sie den Rollen zuzuordnen.
- In den Fällen, in denen Benutzer oder Gruppen in beiden Benutzerregistrys vorhanden sind, wird empfohlen, dass wenigstens die Server-ID und die Benutzer und Gruppen, denen Rollen der Administration zugeordnet werden, in den Benutzerregistrys eindeutig sind (nur in der Domäne vorhanden sind).
- Falls Benutzer in den beiden Registrys identisch sind, setzen Sie andere Kennwörter, um sicherzustellen, dass der richtige Benutzer authentifiziert wird.
- Vorgehensweise
- Wenn eine Maschine zu einer Domäne gehört, hat die Benutzerregistry der Domäne Vorrang vor der lokalen Benutzerregistry. Beispiel: Wenn sich ein Benutzer am System anmeldet, versucht zuerst die Domänenbenutzerregistry, den Benutzer zu authentifizieren. Sollte die Authentifizierung fehlschlagen, wird die lokale Benutzerregistry verwendet. Dieselbe Reihenfolge gilt, wenn ein Benutzer oder eine Gruppe einer Rolle zugeordnet wird. Zuerst wird versucht, die Benutzer/Gruppendaten aus der Domänenbenutzerregistry abzurufen. Sollte dies nicht gelingen, wird die lokale Benutzerregistry verwendet.
- Wenn jedoch ein vollständig qualifizierter Benutzer- oder Gruppenname, ein Name, der einen Domänen- oder Hostnamen enthält, einer Rolle zugeordnet wird,
wird nur diese Benutzerregistry für den Abruf der Daten verwendet. Verwenden Sie die Administrationskonsole oder Scripts, um die vollständig qualifizierten
Benutzer- und Gruppennamen abzurufen. Dies ist die empfohlene Vorgehensweise für die Zuordnung von Benutzern
und Gruppen zu Rollen. Tipp: Beispielsweise ist ein Benutzer Bob auf einer Maschine in der LocalOS-Benutzerregistry nicht identisch mit dem Benutzer Bob auf einer anderen Maschine in der Domänenbenutzerregistry, weil die eindeutige ID Bob, die in diesem Fall der Sicherheits-ID [SID] entspricht, in den beiden Benutzerregistrys unterschiedlich ist.
- BeispieleDie Maschine MeineMaschine gehört zur Domäne MeineDomäne. MeineMaschine enthält die folgenden Benutzer und Gruppen:
- MeineMaschine\Benutzer2
- MeineMaschine\Benutzer3
- MeineMaschine\Gruppe2
- MeineDomäne\Benutzer1
- MeineDomäne\Benutzer2
- MeineDomäne\Gruppe1
- MeineDomäne\Gruppe2
Im Folgenden werden einige Szenarien mit den oben aufgeführten Benutzern und Gruppen beschriebe:- Wenn sich Benutzer2 am System anmeldet, wird die Domänenbenutzerregistry für die Authentifizierung verwendet. Wenn die Authentifizierung fehlschlägt, weil beispielsweise das Kennwort nicht gültig ist, wird die lokale Benutzerregistry verwendet.
- Wenn der Benutzer MeineMaschine\Benutzer2 einer Rolle zugeordnet ist, kann nur Benutzer2 auf MeineMaschine darauf zugreifen. Ist das Kennwort von Benutzer2 in der lokalen Benutzerregistry und der Domänenbenutzerregistry identisch ist, kann Benutzer2 nicht auf die Ressource zugreifen, weil Benutzer2 immer mit der Domänenbenutzerregistry authentifiziert wird. Sind in den Benutzerregistrys identische Benutzer enthalten, wird empfohlen, unterschiedliche Kennwörter zu verwenden.
- Wenn die Gruppe2 einer Rolle zugeordnet wird, können nur die Benutzer, die Member von MeineDomäne\Gruppe2 sind, auf die Ressource zugreifen, weil die Informationen für Gruppe2 zuerst aus der Domänenbenutzerregistry abgerufen werden.
- Falls die Gruppe MeineMaschine\Gruppe2 einer Rolle zugeordnet ist, können nur die Benutzer, die zu der MeineMaschine\Gruppe2 gehören, auf die Ressource zugreifen. Der Grund dafür ist, dass eine bestimmte Gruppe (nämlich MeineMaschine\Gruppe2 und nicht nur Gruppe2) der Rolle zugeordnet ist.
- Verwenden Sie Benutzer Benutzer3 oder Benutzer MeineMaschine\Benutzer3 für die Zuordnung einer Rolle, weil Benutzer3 eindeutig ist, da er nur in einer Benutzerregistry enthalten ist.
Wenn Sie die Authentifizierung zuerst über die Benutzerregistry der Domäne durchführen, können Fehler auftreten, wenn ein Benutzer mit demselben Kennwort in der Benutzerregistry der Domäne und der lokalen Benutzerregistry vorhanden ist. Die rollenbasierte Berechtigung kann in dieser Situation fehlschlagen, da der Benutzer zuerst in der Benutzerregistry der Domäne authentifiziert wird. Bei dieser Authentifizierung entsteht eine eindeutige Domänensicherheits-ID, die in WebSphere Application Server während der Berechtigungsprüfung verwendet wird. Die lokale Benutzerregistry wird jedoch für die Zuordnung von Rollen verwendet. Die Domänensicherheits-ID passt nicht zu der eindeutigen Sicherheits-ID, die der Rolle zugeordnet ist. Um dieses Problem zu vermeiden, sollten Sie Sicherheitsrollen den Domänenbenutzern statt den lokalen Benutzern zuordnen.
Es kann nur ein zentrales Repository verwendet werden, wenn mehrere Knoten beteiligt sind. Das heißt, es kann nur die Domänenbenutzerregistry verwendet werden, weil die eindeutigen Benutzer- und Gruppen-IDs (SIDs), wie bereits erwähnt, auf den Knoten unterschiedlich sein können.

![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
Lokale Benutzerregistry oder Domänenbenutzerregistry verwenden
Wenn Sie auf Benutzer und Gruppen in der lokalen Benutzerregistry oder Domänenbenutzerregistry (aber nicht in beiden) zugreifen möchten, setzen Sie die Eigenschaft "com.ibm.websphere.registry.UseRegistry". Gültige Werte für diese Eigenschaft sind local und domain. Wenn diese Eigenschaft auf local (Groß-/Kleinschreibung beachten) gesetzt ist, wird nur die lokale Benutzerregistry verwendet. Wenn diese Eigenschaft auf domain (Groß-/Kleinschreibung beachten) gesetzt ist, wird nur die Domänenbenutzerregistry verwendet.
- Klicken Sie auf .
- Klicken Sie unter "Repository für Benutzeraccounts" auf die Dropdown-Liste Verfügbare Realmdefinitionen, wählen Sie Lokales Betriebssystem aus, und klicken Sie auf Konfigurieren.
- Klicken Sie unter "Weitere Eigenschaften" auf Angepasste Eigenschaften.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
Systembenutzerregistrys verwenden
Wenn Sie Systembenutzerregistrys verwenden, sollte die Prozess-ID, die den WebSphere Application Server-Prozess ausführt, die Root-Berechtigung haben, um die APIs des lokalen Betriebssystems für die Authentifizierung und den Abruf von Benutzer- und Gruppeninformationen aufrufen zu können.
Es wird nur die Benutzerregistry der lokalen Maschine verwendet. NIS (Network Information Service, Yellow Pages) wird nicht unterstützt.
Wenn Sie die Benutzerregistry des lokalen Betriebssystems verwenden, muss HP-UX im nicht gesicherten Modus konfiguriert werden. Der gesicherte Modus wird nicht unterstützt, wenn die Benutzerregistry des lokalen Betriebssystems verwendet wird.
Damit die WebSphere Application Server-Registry "LocalOS" auf Linux- und Solaris-Plattformen funktioniert, muss eine Spiegelkennwortdatei vorhanden sein. Die Spiegelkennwortdatei hat den Namen shadow und ist im Verzeichnis "/etc" gespeichert. Falls die Kennwortdatei "shadow" nicht vorhanden ist, tritt nach dem Aktivieren der Verwaltungssicherheit und nach dem Konfigurieren der Registry des lokalen Betriebssystems ein Fehler auf.
Führen Sie zum Erstellen der Datei "shadow" den Befehl pwconv (ohne Parameter) aus. Dieser Befehl erstellt aus der Datei /etc/passwd eine Datei /etc/shadow. Nachdem Sie die Datei "shadow" erstellt haben, können Sie die Sicherheit des lokalen Betriebssystems problemlos aktivieren.