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.

Anmerkung: Dieser Artikel referenziert eine oder mehrere Protokolldateien des Anwendungsservers. Alternativ dazu wird empfohlen, den Server so zu konfigurieren, dass er die HPEL-Protokoll- und -Traceinfrastruktur (High Performance Extensible Logging) verwendet und nicht die Dateien SystemOut.log , SystemErr.log, trace.log und activity.log auf verteilten oder IBM® i-Systemen. Sie können HPEL auch in Verbindung mit Ihren nativen z/OS-Protokolleinrichtungen verwenden. Wenn Sie HPEL verwenden, können Sie mit dem Befehlszeilentool LogViewer im Verzeichnis "bin" des Serverprofils auf alle Ihre Protokoll- und Tracedaten zugreifen. Weitere Informationen zur Verwendung von HPEL finden Sie in der Dokumentation zum Einsatz von HPEL für die Fehlerbehebung in Anwendungen.

[IBM i]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.

[IBM i]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.

[AIX Solaris HP-UX Linux Windows]Lightweight Directory Access Protocol (LDAP) ist eine zentrale Registry. Die meisten Registrys des lokalen Betriebssystems sind keine zentralen Registrys.

[AIX Solaris HP-UX Linux Windows]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]
Anmerkung: Für Active Directory (Domänencontroller) sind die drei Gruppenbereiche Domain Local Group, Global Group und Universal Group und die beiden Gruppentypen Security und Distribution.
Wenn eine Gruppe erstellt wird, ist der Standardwert "Global" und der Standardtyp "Security". Mit der Unterstützung der Windows NT-Domänenregistry für Windows-2003-Domänencontrller unterstützt WebSphere Application Server nur globale Gruppen des Typs "Security". Es wird empfohlen, die Unterstützung der Active Directory-Registry anstelle einer Windows-NT-Domänenregistry zu verwenden, wenn Sie Windows-2003-Domänencontroller verwenden, weil Active Directory alle Gruppenebenen und -typen unterstützt. Active Directory unterstützt im Gegensatz zur Windows-NT-Domänenregistry auch verschachtelte Gruppen. Active Directory ist eine zentrale Steuerungsregistry.
Anmerkung: WebSphere Application Server muss das Member der Domäne nicht installieren, weil es auf jeder Maschine auf jeder Plattform installiert sein kann. Der native Aufruf für die Windows-NT-Domäne gibt die Unterstützungsgruppe nur zurück, wenn kein Fehler vorliegt.

[AIX Solaris HP-UX Linux Windows][IBM i]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.

[AIX Solaris HP-UX Linux Windows]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.

[AIX Solaris HP-UX Linux Windows][IBM i]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.

[AIX Solaris HP-UX Linux Windows][IBM i]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][IBM i]Obwohl die Java-Clientzertifikate ordnungsgemäß funktionieren, wird in der Datei SystemOut.log folgender Fehler angezeigt:

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.

[z/OS]Eine Registry des lokalen Betriebssystems ist eine zentrale Registry in einem Systemkomplex.

[z/OS]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.

[z/OS]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]

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.
Falls der Benutzer, der den Server ausführt, nicht die erforderlichen Berechtigungen besitzt, können in den Protokolldateien folgende Ausnahmenachrichten angezeigt werden:
  • A required privilege is not held by the client.
  • Access is denied.
Fehler vermeiden Fehler vermeiden: Der Anwendungsserver muss mit Administratorberechtigungen gestartet werden, wenn Sie eine Eingabeaufforderung verwenden. Starten Sie den Anwendungsserver über ein Fenster mit Eingabeaufforderung, das wie folgt aufgerufen wird:
  • Klicken Sie mit der rechten Maustaste auf einen Direktaufruf für eine Eingabeaufforderung.
  • Klicken Sie auf Als Administrator ausführen.

    Wenn Sie das Fenster mit Eingabeaufforderung als Administrator öffnen, erscheint ein Betriebssystemdialog, in dem Sie gefragt werden, ob Sie die Verarbeitung fortsetzen möchten. Klicken Sie auf Weiter.

gotcha
[AIX Solaris HP-UX Linux Windows]

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]

Domänenbenutzerregistry und Registry des lokalen Betriebssystems verwenden

Standardmäßig werden die lokale Benutzerregistry und die Domänenbenutzerregistry verwendet, wenn die Maschine, auf der der WebSphere Application Server-Prozess ausgeführt wird, zu einer Domäne gehört. Der folgende Abschnitt enthält weiterführende Informationen zu diesem Thema und praktische Hinweise, die Ihnen dabei helfen, unterwünschte Folgen zu vermeiden.
Anmerkung: Obwohl dieser Abschnitt keine direkten Hinweise für z/OS enthält, müssen Sie beachten, dass alle Sicherheitsoperationen davon abhängen, wie gut Sie diese Registrys einrichten.
  • 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.
  • Beispiele
    Die Maschine MeineMaschine gehört zur Domäne MeineDomäne. MeineMaschine enthält die folgenden Benutzer und Gruppen:
    • MeineMaschine\Benutzer2
    • MeineMaschine\Benutzer3
    • MeineMaschine\Gruppe2
    Die Domäne MeineDomäne enthält die folgenden Benutzer und Gruppen:
    • 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:
    1. 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.
    2. 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.
    3. 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.
    4. 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.
    5. 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.

Fehler vermeiden Fehler vermeiden: Vor diesem Fixpack konnte die lokale Benutzerregistry des Betriebssystems auf UNIX-Systemen eventuell keine Gruppennamen finden, wenn die Registry eine große Anzahl von Gruppen enthielt. Dieses Problem bestand aufgrund einer Speichereinschränkung und trat normalerweise dann auf, wenn die Registry mehrere hundert Gruppen enthielt. Beginnend mit diesem Fixpack kann die Puffergröße eine größere Anzahl von Gruppen enthalten.gotcha
[AIX Solaris HP-UX Linux Windows][IBM i]

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.

Setzen Sie diese Eigenschaft, indem Sie die folgenden Schritte ausführen, um auf die Anzeige Angepasste Eigenschaften in der Administrationskonsole zuzugreifen:
  1. Klicken Sie auf Sicherheit > Globale Sicherheit.
  2. 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.
  3. Klicken Sie unter "Weitere Eigenschaften" auf Angepasste Eigenschaften.
Sie können diese Eigenschaft auch mit wsadmin konfigurieren. Wenn die Eigenschaft gesetzt ist, ändern sich die Berechtigungsanforderungen für den Benutzer, der den Produktprozess ausführt, nicht. Ist die Eigenschaft beispielsweise auf local gesetzt, benötigt der Benutzer, der den Prozess ausführt, dieselbe Berechtigung, als wäre die Eigenschaft nicht gesetzt.
[AIX Solaris HP-UX Linux Windows]

Systembenutzerregistrys verwenden

Die folgenden Hinweise sind zu beachten, wenn Systembenutzerregistrys verwendet werden:
  • [AIX][HP-UX][Linux][Solaris]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.
  • [AIX][HP-UX][Linux][Solaris]Es wird nur die Benutzerregistry der lokalen Maschine verwendet. NIS (Network Information Service, Yellow Pages) wird nicht unterstützt.
  • [HP-UX]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.
  • [Linux][Solaris]

    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.


Symbol, das den Typ des Artikels anzeigt. Konzeptartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=csec_localos
Dateiname:csec_localos.html