test

Sun Java System Access Manager 7 2005Q4 Versionshinweise

Dokumentationsprobleme

Access Manager kann nicht vom Realm-Modus in den Legacy-Modus wechseln (6508473)

Wenn Sie Access Manager 7 2005Q4 im Realm-Modus installieren, können Sie nicht in den Legacy-Modus wechseln.

Wenn Sie Access Manager 7 2005Q4 jedoch im Legacy-Modus installieren, können Sie mit dem Befehl amadmin und der Option -M in den Realm-Modus wechseln. Beispiel:

amadmin -u cn=amAdmin,ou=People,dc=example,dc=com -w amadmin-password -M dc=example,dc=com

Weitere Informationen zum Deaktivieren von persistenten Suchabfragen (6486927)

Access Manager verwendet persistente Suchabfragen, um Informationen zu geänderten Sun Java System Directory Server-Einträgen abzurufen. Access Manager erstellt beim Serverstart standardmäßig die folgenden persistenten Suchverbindungen:

aci - Änderungen des Attributs aci, wobei bei der Suche der LDAP-Filter (aci=*) angewendet wird.

sm - Änderungen des Access Manager-Informationsbaums (oder des Dienstverwaltungskontens), der Objekte mit der Markerobjektklasse sunService oder sunServiceComponent enthält. Sie können beispielsweise eine Richtlinie erstellen, um Zugriffsberechtigungen für eine geschützte Ressource festzulegen, oder die Regeln, Subjekte, Bedingungen oder Antwortanbieter für eine bestehende Richtlinie ändern.

um - Änderungen des Benutzerverzeichnisses (oder des Benutzerverwaltungsknotens). Sie können beispielsweise den Namen oder die Adresse eines Benutzers ändern.

Achtung – Achtung –

Das Deaktivieren von persistenten Suchabfragen für eine dieser Komponenten wird nicht empfohlen, da bei deaktivierter persistenter Suche keine Benachrichtigungen vom Directory Server empfangen werden. Folglich würde der Cache der jeweiligen Komponenten nicht über die in Directory Server vorgenommenen Änderungen der Komponente benachrichtigt werden und der Cache würde veralten.

Wenn Sie beispielsweise die persistenten Suchabfragen für Änderungen des Benutzerverzeichnisses (um) deaktivieren, erhält der Access Manager-Server keine Benachrichtigungen vom Directory Server. Der Agent erhält folglich keine Benachrichtigungen von Access Manager für die Aktualisierung seines lokalen Benutzer-Caches mit den neuen Werten des Benutzerattributs. Wenn nun eine Anwendung die Benutzerattribute vom Agenten abfragt, erhält die Anwendung unter Umständen den alten Wert für das Attribut.

Verwenden Sie diese Eigenschaft nur in Ausnahmefällen, in denen die Eigenschaft unbedingt erforderlich ist. Wenn beispielsweise keine Dienstkonfigurationsänderungen (keine Änderung von Werten eines Dienstes, z. B. des Sitzungs- oder Authentifizierungsdienstes) in der Produktionsumgebung stattfinden, kann die persistente Suche für die Dienstverwaltungskomponente (sm) deaktiviert werden. Wenn jedoch eine Änderung in einem der Dienste auftritt, ist ein Neustart des Servers erforderlich. Dies gilt auch für andere persistente Suchabfragen, die von den Werten aci und um angegeben werden.

Weitere Informationen finden Sie unter Neue Eigenschaft zum Deaktivieren persistenter Suchabfragen zur Anwendung in Ausnahmefällen (6363157).

Von Access Manager unterstützte und nicht unterstützte Berechtigungen (2143066)

Mit Berechtigungen werden die Zugriffsrechte für Administratoren festgelegt, die Mitglieder von Rollen oder Gruppen sind, die innerhalb eines Bereichs bestehen. Access Manager ermöglicht die Konfiguration der Berechtigungen für folgende Administratortypen:

Die folgenden Berechtigungen werden unterstützt:

Cookie-basiertes "Sticky Request Routing" (6476922)

Wenn Access Manager-Server hinter einem Load Balancer bereitgestellt werden, verhindert das Cookie-basierte so genannte "Sticky Request Routing" (zähe Anforderungsweiterleitung), dass Client-Anfragen an einen falschen Access Manager-Server weitergeleitet werden (d. h., auf einen Server, der nicht der Host der Sitzung ist). Diese Funktion wurde in Access Manager 7 2005Q4-Patch 3 implementiert.

Das frühere Verhalten, ohne Cookie-basiertes Sticky Request Routing, führte häufig dazu, dass Anforderungen von nicht browserbasierten Clients (z. B. Richtlinienagenten und Clients, die das Remote-Access Manager Client SDK verwenden) fälschlicherweise an einen Access Manager, der nicht Host der Sitzung ist, weitergeleitet wurden. Um die Anforderung an den richtigen Server zu senden, musste der Access Manager-Server die Sitzung durch Kommunikation über einen Rückkanal überprüfen, was in den meisten Fällen zu Leistungseinbußen führte. Durch den Einsatz von Cookie-basiertem Sticky Request Routing wird diese Rückkanal-Kommunikation nicht benötigt und dadurch die Leistung von Access Manager verbessert.

Um Cookie-basiertes Request Routing zu implementieren, muss die Access Manager-Bereitstellung als Site konfiguriert sein. Weitere Informationen finden Sie unter Configuring an Access Manager Deployment as a Site in Sun Java System Access Manager 7 2005Q4 Deployment Planning Guide.

So konfigurieren Sie Cookie-basiertes Sticky Request Routing

  1. Um einen Cookie-Namen anzugeben, legen Sie die Eigenschaft com.iplanet.am.lbcookie.name in der Datei AMConfig.properties fest. Access Manager erzeugt anschließend unter Verwendung der 2-Byte-Server-ID (z. B. 01, 02 oder 03) den Cookie-Wert für den Load Balancer. Wenn Sie keinen Cookie-Namen angeben, erzeugt Access Manager das Cookie für den Load Balancer mit dem Standardnamen amlbcookie und der 2-Byte-Server-ID.

    Wenn Sie den Cookie-Namen auf dem Access Manager-Server festlegen, müssen Sie denselben Namen in der Datei AMAgent.properties für einen Richtlinienagenten verwenden. Ebenso müssen Sie denselben Cookie-Namen wie den vom Access Manager-Server verwendeten Namen verwenden, wenn Sie das Access Manager Client-SDK verwenden.

    Hinweis: Legen Sie nicht die Eigenschaft com.iplanet.am.lbcookie.value fest, da Access Manager den Cookie-Wert unter Verwendung der 2-Byte-Server-ID festlegt.

  2. Konfigurieren Sie Ihren Load Balancer mit dem Cookie-Namen aus Schritt 1. Mit der Access Manager-Bereitstellung kann ein Hardware- oder Software-Lastenausgleichssystem verwendet werden.

  3. Wenn Sitzungs-Failover implementiert ist, aktivieren Sie die Eigenschaft com.sun.identity.session.resetLBCookie für beide Richtlinienagenten und für den Access Manager-Server.

    • Fügen Sie für den Richtlinienagenten die Eigenschaft der Datei AMAgents.properties hinzu und aktivieren Sie sie.

    • Fügen Sie für Access Manager-Server die Eigenschaft der Datei AMConfig.properties hinzu und aktivieren Sie sie.

    Beispiel:

    com.sun.identity.session.resetLBCookie='true'

    Tritt eine Failover-Situation auf, wird die Sitzung an einen sekundären Access Manager-Server weitergeleitet und der Cookie-Wert des Load Balancer unter Verwendung der Server-ID des sekundären Access Manager-Servers festgelegt. Alle nachfolgenden Anforderungen für die Sitzung werden an den sekundären Access Manager-Server weitergeleitet.

Windows Desktop SSO-Konfiguration für Windows 2003 (6487361)

Um Windows Desktop SSO auf Windows 2003 zu konfigurieren (wie unter Configuring Windows Desktop SSO in Sun Java System Access Manager 7 2005Q4 Administration Guide beschrieben), verwenden Sie folgenden ktpass-Befehl:

ktpass /out filename /mapuser username 
/princ HTTP/hostname.domainname /crypto encryptiontype /rndpass 
/ptype principaltype /target domainname

Beispiel:

ktpass /out demo.HTTP.keytab 
/mapuser http /princ HTTP/demo.identity.sun.com@IDENTITY.SUN.COM 
/crypto RC4-HMAC-NT /rndpass /ptype KRB5_NT_PRINCIPAL /target IDENTITY.SUN.COM

Syntaxdefinitionen finden Sie auf folgender Website:

http://technet2.microsoft.com/WindowsServer/en/library/64042138-9a5a-4981-84e9-d576a8db0d051033.mspx?mfr=true

Schrittanleitung für das Einrichten von Passwörtern für einen Server mit Verteilter Authentifizierungsbenutzeroberfläche (6510859)

Das folgende Verfahren beschreibt, wie Sie die verschlüsselten Passwörter für einen Server mit Verteilter Authentifizierungsbenutzeroberfläche einrichten, der mit einem Access Manager-Server kommuniziert.

So richten Sie die Passwörter für einen Server mit Verteilter Authentifizierungsbenutzeroberfläche ein

  1. Führen Sie folgende Schritte auf dem Access Manager-Server durch:

    1. Verwenden Sie das Dienstprogramm ampassword -e, um das amadmin-Passwort zu verschlüsseln. Beispielsweise auf Solaris-Systemen:

      # cd /opt/SUNWam/bin 
# ./ampassword -e amadmin-password 
AQIC0K3omEozd544XEJIg25GT2wi1D7UAQLX

      Speichern Sie den verschlüsselten Wert.

    2. Kopieren und speichern Sie die Eigenschaft am.encryption.pwd aus der Access Manager-Serverdatei AMConfig.properties. Beispiel:

      am.encryption.pwd=ydV8JXhJF2J35vpxjZRiGt7SH/7mUr+Y

  2. Nehmen Sie auf dem Server mit Verteilter Authentifizierungsbenutzeroberfläche folgende Änderungen der Datei AMConfig.properties vor:

    1. Kommentieren Sie die Eigenschaft com.iplanet.am.service.password aus.

    2. Legen Sie die Eigenschaft com.iplanet.am.service.secret auf das in Schritt 1a verschlüsselte amadmin-Passwort fest.

    3. Fügen Sie am.encryption.pwd und den in Schritt 1b verschlüsselten Wert hinzu. Beispiel:

      com.sun.identity.agents.app.username=username 
#com.iplanet.am.service.password=password 
com.iplanet.am.service.secret=AQIC0K3omEozd544XEJIg25GT2wi1D7UAQLX 
am.encryption.pwd=ydV8JXhJF2J35vpxjZRiGt7SH/7mUr+Y

  3. Starten Sie den Server mit Verteilter Authentifizierungsbenutzeroberfläche neu.

Fehlender Schritt in Onlinehilfe unter ?So erstellen Sie einen neuen Site-Namen“ (2144543)

In der Onlinehilfe der Access Manager-Konsole fehlt unter ?So erstellen Sie einen neuen Site-Namen“ in ?Konfiguration>Systemeingenschaften>Plattform“ der Schritt mit der Anweisung zum Speichern. Wenn Sie nach dem Hinzufügen einer neuen Site nicht auf ?Speichern“ und anschließend einen Instanznamen hinzufügen möchten, schlägt der Vorgang fehl. Klicken Sie daher nach dem Hinzufügen eines Site-Namens immer auf ?Speichern“ und fügen Sie anschließend den Instanznamen hinzu.

Konfigurationsparameter für Administrator-Passwort lautet auf Windows-Systemen ADMIN_PASSWD (6470793)

Auf Solaris- und Linux-Systemen lautet der in der Datei amsamplesilent enthaltene Konfigurationsparameter für das Passwort des Access Manager-Administrators (amadmin ) ADMINPASSWD. Auf Windows-Systemen lautet der Parameter in der Datei AMConfigurator.properties jedoch ADMIN_PASSWD.

Wenn Sie amconfig.bat auf einem Windows-System ausführen, legen Sie das amadmin-Passwort in der Datei AMConfigurator.properties mit dem Parameter ADMIN_PASSWORD und nicht mit ADMINPASSWD fest.

Versionshinweise enthalten falsche Lösung für ein bekanntes Problem (6422907)

Schritt 3 der Lösung für Ausführen des Webdienstes gibt Fehler "Ressourcenangebot nicht gefunden" zurück (6359900) wurde korrigiert.

Dokument com.iplanet.am.session.protectedPropertiesList in AMConfig.properties (6351192)

Der com.iplanet.am.session.protectedPropertiesList-Parameter ermöglicht es Ihnen, bestimmte Eigenschaften von Kernsitzungen bzw. internen Sitzungen vor Remote-Aktualisierungen per SetProperty-Methode des Sitzungs-Dienstes zu schützen. Durch Festlegen dieses "versteckten" Schlüsselsicherheitsparameters können Sie Sitzungsattribute anpassen, um bei der Autorisierung sowie bei anderen Access Manager-Funktionen teilzunehmen. So verwenden Sie diesen Parameter:

  1. Fügen Sie den parameter mit einem Texteditor zur AMConfig.properties -Datei hinzu.

  2. Stellen Sie den Parameter für die Sitzungseigenschaften ein, die Sie schützen möchten. Beispiel:

    com.iplanet.am.session.protectedPropertiesList = 
PropertyName1,PropertyName2,PropertyName3

  3. Starten Sie den Access Manager-Webcontainer neu, damit die Werte in Kraft treten.

Beschreibung der Unterstützung für Rollen und gefilterte Rolle für das LDAPv3-Plugin (6365196)

Nach Anwendung des entsprechenden Patches können Sie Rollen und gefilterte Rollen für das LDAPv3-Plugin konfigurieren, wenn die Daten in Sun Java System Directory Server gespeichert sind (behebt Problem 6349959). Geben Sie auf der Access Manager 7 2005Q4 Administrator Console für die LDAPv3-Konfiguration in das Feld "LDAPc3-Plugin: Unterstützte Typen und Vorgänge" die Werte wie folgt ein:

role: read,edit,create,delete
filteredrole: read,edit,create,delete

Sie können einen oder beide der oben genannten Einträge eingeben, je nachdem, welche Rollen und gefilterte Rollen Sie in Ihrer LDAPv3-Konfiguration verwenden möchten.

Beschreibung nicht verwendeter Eigenschaften in der Datei AMConfig.properties (6344530)

Die folgenden Eigenschaften in der Datei AMConfig.properties werden nicht verwendet: 

com.iplanet.am.directory.host
com.iplanet.am.directory.port

com.iplanet.am.session.client.polling.enable auf Serverseite darf nicht true sein (6320475)

Die com.iplanet.am.session.client.polling.enable-Eigenschaft in der AMConfig.properties-Datei darf auf Serverseite niemals auf true festgelegt werden.

Umgehung: Diese Eigenschaft wird standardmäßig auf false festgelegt und sollte niemals erneut auf true festgelegt werden.

Der Standarderfolgs-URL ist in der Konsolenonlinehilfe fehlerhaft (6296751)

Der Standarderfolgs-URL ist in der Onlinehilfedatei service.scserviceprofile.iplanetamauthservice.html fehlerhaft. Das Feld "Default Success URL" akzeptiert eine Liste mit mehreren Werten, die den URL angeben, an den die Benutzer nach einer erfolgreichen Authentifizierung geleitet werden. Das Format dieses Attributs lautet clientType|URL, obwohl Sie nur den Wert des URL angeben können, der einen HTML-Standardtyp annimmt.

Der Standardwert “/amconsole” ist fehlerhaft.

Umgehung: Der richtige Standardwert lautet “/amserver/console”.

Beschreibung der Aktivierung der XML-Verschlüsselung (6275563)

Um die XML-Verschlüsselung für Access Manager oder Federation Manager unter Verwendung der Bouncy Castle-JAR-Datei für das Generieren eines Transportschlüssels zu aktivieren, gehen Sie wie folgt vor:

  1. Wenn Sie eine ältere JDK-Version als JDK 1.5 verwenden, laden Sie den Bouncy Castle-JCE-Anbieter von der Bouncy Castle-Website (http://www.bouncycastle.org/) herunter. Wenn Sie beispielsweise JDK 1.4 verwenden, laden Sie die Datei bcprov-jdk14-131.jar herunter.

  2. Wenn Sie im vorherigen Schritt eine JAR-Datei heruntergeladen haben, kopieren Sie die Datei in das Verzeichnis jdk_root/jre/lib/ext.

  3. Laden Sie für die verwendete Version des JDK die JCE Unlimited Strength Jurisdiction Policy Files von der Sun-Website (http://java.sun.com) für Ihre JDK-Version herunter. Laden Sie für IBM WebSphere die erforderlichen Dateien von der IMB-Website herunter.

  4. Kopieren Sie die heruntergeladenen Dateien US_export_policy.jar und local_policy.jar in das Verzeichnis jdk_root/jre/lib/security .

  5. Wenn Sie eine ältere JDK-Version als JDK 1.5 verwenden, bearbeiten Sie die Datei jdk_root/jre/lib/security/java.security und fügen Sie Bouncy Castle als einen der Anbieter hinzu. Beispiel:

    security.provider.6=org.bouncycastle.jce.provider.BouncyCastleProvider

  6. Legen Sie in der Datei AMConfig.properties die folgende Eigenschaft als true fest:

    com.sun.identity.jss.donotInstallAtHighestPriority=true

  7. Starten Sie den Access Manager-Webcontainer neu.

Weitere Informationen erhalten Sie unter der Problemnummer 5110285 (XML-Verschlüsselung erfordert Bouncy Castle-JAR-Datei).