Access Manager 7-Patch 5 (Überarbeitung 05) behebt eine Reihe von Problemen, die in der README-Datei zum Patch aufgeführt sind. Patch 5 enthält außerdem die folgenden neuen Funktionen, Problemlösungen und Dokumentationsaktualisierungen.
Neue Funktionen in Patch 5
Neues updateschema.sh-Skript zum Laden von LDIF- und XML-Dateien
Unterstützung für anwendungsspezifische Zeitüberschreitungswerte für Sitzungsleerlauf
Zertifikatsauthentifizierung kann UPN-Wert für Zuordnung von Benutzerprofilen verwenden
Verarbeitung der Abmeldung nach Authentifizierung in Umgebung mit mehreren Servern
Zweifache Authentifizierung des Benutzers in Authentifizierungskette nicht mehr erforderlich
Bekannte Probleme und Einschränkungen in Patch 5
Datei amsilent in Patch 5 kann auf Linux-Systemen von allen Benutzern gelesen werden (6523499)
LDAPv3-Repository-Plugin verarbeitet Alias-Suchattribut nicht immer korrekt (6515502)
Verteilte Authentifizierung erfordert expliziten goto-URL-Parameter (6507383 und 6507377)
LDAP JDK 4.18 verursacht Probleme in LDAP-Client/Directory Server (6402167)
Problem mit Eigenschaftseinstellung com.iplanet.am.session.purgedelay (6513653)
Globalisierungsprobleme (g11n)
Dokumentationsaktualisierungen
Access Manager kann nicht vom Realm-Modus in den Legacy-Modus wechseln (6508473)
Weitere Informationen zum Deaktivieren von persistenten Suchabfragen (6486927)
Von Access Manager unterstützte und nicht unterstützte Berechtigungen (2143066)
Windows Desktop SSO-Konfiguration für Windows 2003 (6487361)
Fehlender Schritt in Onlinehilfe unter ?So erstellen Sie einen neuen Site-Namen“ (2144543)
Patch 126371 bietet Unterstützung für HP-UX-Systeme. Weitere Informationen finden Sie hier:
Informationen zur Installation von HP-UX-Systemen finden Sie im Sun Java Enterprise System 2005Q4 Installationshandbuch für UNIX.
Patch 124296 bietet Unterstützung für Windows-Systeme. Weitere Informationen finden Sie hier:
Informationen zur Installation von Windows-Systemen finden Sie im Sun Java Enterprise System 2005Q4 Installation Guide for Microsoft Windows .
Patch 5 (und höher) enthält das Skript updateschema.sh, um folgende Dateien für die Aktualisierung des Directory Server-Dienstschemas zu laden:
AddLDAPFilterCondition.xml
amPolicyConfig_mod_ldfc.xml
accountLockoutData.xml
accountLockout.ldif
idRepoServiceAddAttrSchemaRequest_Cache.xml
wsf1.1_upgrade.xml
amAuth_mod.xml
amAuthCert_mod.xml
In vorherigen Access Manager-Patch-Versionen mussten diese Dateien manuell geladen werden.
So führen Sie das updateschema.sh-Skript aus
Melden Sie sich als Superuser (root) an.
Wechseln Sie in das Patch-Verzeichnis.
Führen Sie das Skript aus. Beispielsweise auf Solaris-Systemen:
# cd /120954-07 # ./updateschema.sh
Auf Windows-Systemen lautet das Skript updateschema.pl.
Machen Sie folgende Angaben, wenn Sie dazu aufgefordert werden:
Hostname und Portnummer für Directory Server
Admin-Benutzer-DN und Passwort für Directory Server
DN und Passwort für amadmin
Ihre Angaben werden überprüft und die Dateien geladen. Das Skript erstellt außerdem folgende Protokolldatei:
Solaris-Systeme: /var/opt/SUMWam/logs/AM70Patch.upgrade.schema. timestamp
Linux-Systeme: /var/opt/sun/identity/logs/AM70Patch.upgrade.schema. timestamp
Nach Ausführung des Skripts wird der Access Manager-Webcontainer neu gestartet.
Hinweis Wenn Sie die Patch 5-Installation rückgängig machen, werden die vom updateschema.sh-Skript vorgenommenen Schemaänderungen nicht aus Directory Server entfernt. Sie müssen diese Änderungen jedoch nicht manuell entfernen, da die Änderungen die Funktionalität und Bedienbarkeit von Access Manager nicht beeinträchtigen, nachdem das Patch entfernt wurde.
Patch 5 ermöglicht die Einstellung unterschiedlicher Zeitüberschreitungswerte für den Sitzungsleerlauf in den verschiedenen Anwendungen. In einem Unternehmen erfordern manche Anwendungen möglicherweise kleinere Zeitüberschreitungswerte für den Sitzungsleerlauf als den im Sitzungsdienst angegebenen Zeitüberschreitungswert für den Sitzungsleerlauf. Zum Beispiel: Im Sitzungsdienst ist der Zeitüberschreitungswert auf 30 Minuten festgelegt, in einer HR-Anwendung soll jedoch eine Zeitüberschreitung eintreten, wenn sich die Benutzersitzung länger als 10 Minuten im Leerlauf befindet.
Voraussetzungen für die Verwendung dieser Funktion:
Die zum Schutz der Anwendung eingesetzten Agenten müssen so konfiguriert sein, dass sie die URL-Richtlinienentscheidungen von Access Manager durchsetzen.
Agenten müssen für die Ausführung eigener Richtlinienentscheidungen im Cachemodus konfiguriert sein. Siehe folgende Eigenschaften:
Für Webagenten: com.sun.am.policy.am.fetch_from_root_resource
Für J2EE-Agenten: com.sun.identity.policy.client.cacheMode
In der Access Manager-Datei AMConfig.properties muss die Auswertungsreihenfolge für Richtlinienkomponenten so angegeben sein, dass die Bedingung (Condition) zuletzt ausgewertet wird. Siehe folgende Eigenschaft:
com.sun.identity.policy.Policy.policy_evaluation_weights
Der vom Agenten erlaubte Anwendungszugriff, der auf der im lokalen Cache enthaltenen Bedingung basiert, wird der Bedingung in Access Manager nicht bekannt gemacht. Daher liegt der tatsächliche Zeitüberschreitungswert zwischen dem Zeitüberschreitungswert der Anwendung und dem Zeitüberschreitungswert der Anwendung minus der Cachedauer.
So verwenden Sie diese Funktion
Fügen Sie den Richtlinien, die die Anwendung schützen und für die ein bestimmter Zeitüberschreitungswert für den Sitzungsleerlauf erforderlich ist, eine Bedingung für das Authentifizierungsschema (Authentication Scheme Condition) hinzu.
Geben Sie in der Bedingung für das Authentifizierungsschema einen Anwendungsnamen und einen Zeitüberschreitungswert an.
Verwenden Sie in allen Richtlinien, die auf die Ressourcen für die Anwendung angewendet werden, denselben Anwendungsnamen und Zeitüberschreitungswert.
Geben Sie den Zeitüberschreitungswert in Minuten an. Wenn der Wert 0 oder höher als der im Sitzungsdienst angegebene Zeitüberschreitungswert ist, wird der Wert ignoriert und der Zeitüberschreitungswert des Sitzungsdienstes angewendet.
Gehen Sie beispielsweise von einer Richtlinie http://host.sample.com/hr/* mit folgender Bedingung für das Authentifizierungsschema aus:
Authentifizierungsschema: LDAP
Anwendungsname: HR
Zeitüberschreitungswert: 10
Wenn mehrere Richtlinien zum Schutz der Ressourcen der HR-Anwendung festgelegt wurden, müssen Sie die Bedingung allen Richtlinien hinzufügen.
Wenn ein Benutzer in einer Sitzung auf die vom Access Manager-Agenten geschützte HR-Anwendung zugreifen möchte, wird der Benutzer zur Authentifizierung mit dem LDAP-Schema aufgefordert (falls der Benutzer nicht bereits authentifiziert ist).
Ist der Benutzer bereits mit dem LDAP-Schema authentifiziert, wird dem Benutzer nur dann Zugriff auf die Anwendung gewährt, wenn seit der letzten Authentifizierung weniger als 10 Minuten vergangen sind oder der Benutzer zuletzt vor weniger als 10 Minuten auf die HR-Anwendung zugegriffen hat. Anderenfalls wird der Benutzer zur erneuten Authentifizierung mit dem LDAP-Schema aufgefordert, um auf die Anwendung zugreifen zu können.
Das CDC-Servlet kann neben einem Server mit Verteilter Authentifizierungsoberfläche in der DMZ bestehen, um domänenübergreifendes Single Sign-On (Cross-Domain Single Sign-On, CDSSO) zu aktivieren. Access Manager kann hinter einer Firewall bereitgestellt werden und sämtlicher Zugriff auf Access Manager, der für CDSSO erforderlich ist, wird vom CDC-Servlet des Servers mit Verteilter Authentifzierungsbenutzeroberfläche verarbeitet. Um CDSSO zu aktivieren, lesen Sie in der Dokumentation zum Richtlinienagenten nach und führen Sie zusätzlich folgende Schritte durch:
Ändern Sie die Datei AMAgent.properties des Agenten so, dass diese auf das CDS-Servlet auf der Seite der Verteilten Authentifizierung (Client) zeigt. Ändern Sie für Webagenten beispielsweise die folgende Eigenschaft:
com.sun.am.policy.agents.config.cdcservlet.url= http://DAhost.DAdomain:DAport/DISTAUTH_DEPLOY_URI/cdcservlet
Geben Sie in Access Manager gegebenenfalls Richtlinien für Ressourcen an, die von dem Agenten geschützt werden sollen. Wenn der Agent beispielsweise an Port host.example.com:80 liegt, legen Sie als Richtlinie für die Ressource http://host.example.com:80/* fest.
Sie können nun einen Bereichsnamen für das CDC-Servlet angeben, sodass bei der Umleitung auf die Access Manager-Anmelde-URL der Bereichsname mit eingeschlossen wird und sich der Benutzer im angegebenen Bereich anmelden kann. Beispiel:
com.sun.am.policy.agents.config.cdcservlet.url= http://lb.example.com/amserver/cdcservlet?org=realm1
Bei der Zertifikatsauthentifzierung konnte bislang nur die dn-Komponente von subjectDN für die Zuordnung eines Benutzerprofils verwendet werden. Access Manager ermöglicht nun die Verwendung des Werts für den Benutzer-Principal-Namen (User Principal Name, UPN) im SubjectAltNameExt für die Profilzuordnung.
Die Verarbeitung nach der Authentifizierung findet nun statt, wenn sich ein Benutzer von einem anderen Server abmeldet, als dem Server, bei dem er sich ursprünglich in einer Umgebung mit mehreren Servern (mit oder ohne Sitzungsfailover-Konfiguration) angemeldet hat.
SAML unterstützt nun eine neue Dienstanbieterschnittstelle (Service Provider Interface, SPI) für Namensbezeichner, sodass eine Site den Namensbezeichner in der SAML-Assertion anpassen kann. Eine Site kann die neue NameIdentifierMapper-Schnittstelle implementieren, um ein Benutzerkonto einem Namensbezeichner im Subjekt einer SAML-Assertion zuzuordnen.
Die Siteüberwachungsfunktion von Access Manager enthält die folgenden neuen Eigenschaften, mit denen Sie das Verhalten der Sitestatusüberprüfung festlegen können.
Eigenschaft |
Beschreibung |
com.sun.identity.urlchecker.invalidate.interval |
Zeitintervall in Millisekunden für das Erkennen einer Site, die nicht verfügbar ist oder nicht antwortet. Standard: 70000 Millisekunden (70 Sekunden). |
com.sun.identity.urlchecker.sleep.interval |
Zeitintervall in Millisekunden, in dem die Sitestatusüberprüfung pausieren soll. Standard: 30000 Millisekunden (30 Sekunden). |
com.sun.identity.urlchecker.targeturl |
Andere Ziel-URL zum Überprüfen des Prozess-Status von Access Manager. Standard: "/amserver/namingservice". |
Der Patch fügt diese Eigenschaften der Datei AMConfig.properties nicht hinzu. So verwenden Sie diese neuen Eigenschaften mit anderen Werten als den Standardwerten
Fügen Sie die Eigenschaften und ihre Werte der Datei AMConfig.properties hinzu. Fügen Sie für Richtlinienagenten diese Eigenschaften der Datei AMAgents.properties hinzu.
Starten Sie den Access Manager-Webcontainer neu, damit die Werte in Kraft treten.
Bedenken Sie folgendes Szenario. Eine Site konfiguriert eine Authentifizierungskette mit drei LDAP-Modulen. Alle Module werden auf SUFFICIENT festgelegt und die Optionen iplanet-am-auth-shared-state-enabled und iplanet-am-auth-store-shared-state-enabled werden auf true gesetzt. Beispiel:
<AttributeValuePair> <Value>A-LDAP SUFFICIENT iplanet-am-auth-shared-state-enabled=true iplanet-am-auth-store-shared-state-enabled=true</Value> <Value>B-LDAP SUFFICIENT iplanet-am-auth-shared-state-enabled=true iplanet-am-auth-store-shared-state-enabled=true</Value> <Value>C-LDAP SUFFICIENT iplanet-am-auth-shared-state-enabled=true iplanet-am-auth-store-shared-state-enabled=true</Value> </AttributeValuePair>
Patch 5 fügt den Moduloptionen die neue Option iplanet-am-auth-shared-state-behavior-pattern mit zwei möglichen Werten hinzu: tryFirstPass (Standard) und useFirstPass.
Um zu verhindern, dass ein Benutzer seine Benutzer-ID und sein Passwort für die Authentifizierung zweimal eingeben muss (wie im obigen Szenario beschrieben), setzen Sie die Option für alle Module in der Kette auf useFirstPass. Zuvor musste ein Benutzer, der nur in der dritten LDAP-Instanz vorhanden war, seine Benutzer-ID und sein Passwort zweimal eingeben, um sich zu authentifizieren.
Patch 5 enthält folgende Änderungen der Skripten für die Leistungsoptimierung:
Das Optimierungsskript entfernt nicht benötigte ACIs aus Directory Server
Skript amtune-os optimiert sowohl Solaris OS als auch Linux OS
Optimierungsskripte in einer lokalen Solaris 10-Zone werden vollständig ausgeführt
Zu berücksichtigende Aspekte bei der Optimierung von Sun Fire T1000- und Sun Fire T2000-Server
Patch 5 ermöglicht die Angabe eines Passworts für die Optimierungsskripte in einer Textdatei. Zuvor konnten Passwörter nur als Befehlszeilenargument eingegeben werden, wodurch unter Umständen Sicherheitsprobleme aufgetreten sind. Um eine Passwortdatei zu verwenden, legen Sie die folgenden Variablen entsprechend Ihrer Anforderungen fest:
DS_ADMIN_PASSWORD=DirectoryServer-admin-password AS_ADMIN_PASSWORD=ApplicationServer8-admin-password
So optimieren Sie beispielsweise Application Server 8
# ./amtune-as8 password-file
wobei password-file die auf das Administratorpasswort von Application Server 8 festgelegte Variable AS_ADMIN_PASSWORD enthält.
Die Optimierungsskripte verwenden die Option -j password-file beim Aufrufen der Directory Server-Dienstprogramme ldapmodify, ldapsearch, db2index und dsconf.
Wenn Access Manager 7 2005Q4 im Realm-Modus installiert ist, werden für die Ermittlung der Zugriffsberechtigungen Übertragungsberechtigungen verwendet, sodass manche Directory Server-ACIs nicht benötigt werden. Access Manager 7 2005Q4-Patch 5 ermöglicht Ihnen, die nicht benötigten ACIs durch Ausführung des Skripts amtune-prepareDSTuner zu entfernen. Das Skript liest eine Liste mit ACIs in der Datei remacis.ldif und ruft anschließend das ldapmodify-Dienstprogramm auf, um die ACIs zu entfernen.
Sie können das Skript amtune-prepareDSTuner zum Entfernen nicht benötigter ACIs auf Solaris-, HP-UX- und Windows-Systemen ausführen. Weitere Informationen, unter anderem zur Ausführung des Skripts, finden Sie im Technical Note: Sun Java System Access Manager ACI Guide .
Nachdem Sie den Server mit Verteilter Authentifizierungsbenutzeroberfläche bereitgestellt haben, können Sie den Webcontainer optimieren, indem Sie die Access Manager-Optimierungsskripte ausführen. Die folgenden Optimierungsskripte legen die JVM-Option sowie weitere Optimierungsoptionen für den jeweiligen Webcontainer fest:
Tabelle 2 Access Manager-Optimierungsskripte für Webcontainer
Webcontainer |
Optimierungsskript |
---|---|
amtune-ws61 |
Web Server 6.1 |
amtune-as7 |
Application Server 7 |
amtune-as8 |
Application Server Enterprise Edition 8.1 |
So optimieren Sie den Webcontainer eines Servers mit Verteilter Authentifizierungsbenutzeroberfläche
Da der Access Manager-Server nicht auf dem System installiert ist, auf dem der Server mit Verteilter Authentifizierungsbenutzeroberfläche bereitgestellt wird, kopieren Sie das entsprechende Webcontainer-Optimierungsskript (siehe Tabelle oben), die Konfigurationsdatei amtune-env und das Skript amtune-utils aus einer Access Manager-Serverinstallation. Wenn Sie das Solaris- oder Linuxbetriebssystem optimieren möchten, kopieren Sie zusätzlich das Skript amtune-os.
Bearbeiten Sie die Parameter in der Konfigurationsdatei amtune-env, um den Webcontainer und die Optimierungsoptionen anzugeben. Um das Skript im REVIEW-Modus auszuführen, legen Sie AMTUNE_MODE=REVIEW in der Datei amtune-env fest.
Führen Sie das Webcontainer-Optimierungsskript im REVIEW-Modus aus. Im REVIEW-Modus schlägt das Skript basierend auf den Werten in der Datei amtune-env Änderungen für die Optimierung des Webcontainers vor, führt jedoch keine Änderungen an der Bereitstellung aus.
Überprüfen Sie die Optimierungsempfehlungen in der Debug-Protokolldatei. Ändern Sie die Datei amtune-env gegebenenfalls entsprechend der empfohlenen Änderungen.
Um Optimierungsänderungen vorzunehmen, legen Sie AMTUNE_MODE=CHANGE in der Datei amtune-env fest.
Führen Sie das Skript im CHANGE-Modus aus, um Optimierungsänderungen an der Bereitstellung vorzunehmen.
Weitere Informationen zur Ausführung des Optimierungsskripts für die Optimierung des Access Manager-Webcontainers finden Sie in Kapitel Kapitel 2, Access Manager Tuning Scripts in Sun Java System Access Manager 7 2005Q4 Performance Tuning Guide.
Patch 5 enthält das Skript amtune-os, das sowohl das Solaris OS als auch das Linux OS optimiert. Das Skript bestimmt das Betriebssystem mit dem Befehl uname -s. Zuvor wurden in Access Manager separate amtune-os-Skripte für die Optimierung des jeweiligen Betriebssystems bereitgestellt.
Wenn Access Manager in einer lokalen Solaris 10-Zone installiert ist, können alle Skripte, mit Ausnahme von amtune-os, in der lokalen Zone ausgeführt werden. In einer lokalen Zone zeigt das amtune-os-Skript eine Warnung an, führt die Optimierung des Betriebssystems jedoch nicht aus. Das Skript führt anschließend alle anderen von Ihnen angeforderten Optimierungsskripts aus. Zuvor wurde die Ausführung des amtune-os -Skripts in einer lokalen Zone abgebrochen und keines der nachfolgenden angeforderten Optimierungsskripte ausgeführt.
In einer globalen Solaris 10-Zone ruft das Skript amtune das Skript amtune-os aus, um das Betriebssystem zu optimieren, sowie alle übrigen zur Ausführung angeforderten Skripten.
Patch 5 enthält Optimierungsskripte für Windows-Systeme. Die Ausführung der Optimierungsskripte auf einem Windows-System entspricht mit Ausnahme der folgenden Unterschiede der Ausführung der Skripte auf einem Solaris- oder Linux-System:
Windows-Skripte sind in Perl geschrieben und erfordern die Ausführung von Active Perl 5.8.
Wenn Sie nach der Ausführung des Skripts amtune-prepareDSTuner.pl Directory Server optimieren, müssen Sie die Dateien amtune-utils.pl, amtune-directory.pl, remacis.ldif und amtune-samplepassordfile in das Directory Server-System kopieren, da das Skript diese Dateien nicht komprimieren kann.
Es steht kein Skript für die Optimierung des Windows-Betriebssystems zur Verfügung.
Zonen werden nicht unterstützt.
Bevor Sie ein Skript ausführen, müssen Sie den Parameter $BASEDIR in der Datei amtune-env.pl auf das Access Manager-Installationsverzeichnis setzen.
Wenn Access Manager auf einem Sun Fire T1000- oder Sun Fire T2000-Server installiert ist, setzen die Skripte für Web Server 6.1 und Application Server 8 den Parameter JVM GC ParallelGCThreads auf 8:
-XX:ParallelGCThreads=8
Dieser Parameter reduziert die Anzahl der Garbage Collection-Threads, die auf einem 32–Thread-fähigen System unnötig hoch sein kann. Wenn die Aktivitäten der vollständigen Garbage Collection dadurch reduziert werden, können Sie den Wert jedoch auf 16 bzw. im Fall eines virtuellen 32 CPU-Rechners (z. B. ein Sun Fire T1000- oder Sun Fire T2000-Server) auf 20 erhöhen.
Es wird außerdem empfohlen, auf Solaris SPARC-Systemen mit einem CMT-Prozessor unter Verwendung der CoolThreads-Technologie folgende Eigenschaft an das Ende der Datei /etc/opt/SUNWam/config/AMConfig.properties anzufügen:
com.sun.am.concurrencyRate=value
Der Standardwert für value ist 16. Sie können für diese Eigenschaft jedoch je nach Anzahl der Cores im Sun Fire T1000- bzw. Sun Fire T2000-Server einen kleineren Wert festlegen.
Um die Basisauthentifizierung in Microsoft Internet Information Services (IIS) 6.0 zu aktivieren, muss der Richtlinienagent den Namen und das Passwort des Benutzers erhalten. Patch 5 enthält die folgenden neuen Klassen, um diese Funktionalität unter Verwendung der DES-Verschlüsselung des Benutzerpassworts zu aktivieren:
DESGenKey.java generiert einen eindeutigen Schlüssel für die Ver- und Entschlüsselung des Benutzerpassworts.
ReplayPasswd.java liest den Wert des Verschlüsselungsschlüssels aus der Eigenschaft com.sun.am.replaypasswd.key in der Datei AMConfig.properties, verschlüsselt das Passwort und weist es der Sitzungseigenschaft sunIdentityUserPassword zu.
Um die Basisauthentifizierung in IIS 6.0 zu verwenden, müssen Sie sowohl in Access Manager (serverseitig) als auch im Richtlinienagent für IIS 6.0 folgende Schritte durchführen.
In Access Manager:
Führen Sie DESGenKey.java aus, um einen eindeutigen Verschlüsselungsschlüssel für die Ver- und Entschlüsselung des Passworts zu generieren. Auf Solaris-Systemen befindet sich die Datei DESGenKey.java im Verzeichnis com/sun/identity/common , das sich in der Datei am_sdk.jar im Verzeichnis /opt/SUNWam/lib befindet. Der folgende Befehl generiert beispielsweise einen Verschlüsselungsschlüssel:
# cd /opt/SUNWam/lib # java -cp am_sdk.jar com.sun.identity.common.DESGenKey
Weisen Sie den Wert des Verschlüsselungsschlüssels aus Schritt 1 der Eigenschaft com.sun.am.replaypasswd.key in der Datei AMConfig.properties zu.
Stellen Sie ReplayPasswd.java als ein der Authentifizierung nachgestelltes Plugin bereit. Verwenden Sie bei der Konfiguration des Plugins den vollständigen Klassennamen: com.sun.identity.authentication.spi.ReplayPasswd .
Im Richtlinienagent für IIS 6.0:
Weisen Sie den serverseitigen Verschlüsselungsschlüssel der Eigenschaft com.sun.am.replaypasswd.key in der Datei AMAgent.properties zu. Access Manager und der Richtlinienagent für IIS 6.0 müssen denselben Verschlüsselungsschlüssel verwenden.
Aktivieren Sie die Basisauthentifizierung in IIS 6.0 Manager.
Der Richtlinienagent für IIS 6.0 liest das verschlüsselte Passwort aus der Sitzungsantwort, entschlüsselt das Passwort aus der Eigenschaft com.sun.am.replaypasswd.key und legt die Authentifizierungs-Header fest, um die Basisauthentifizierung zuzulassen.
Informationen zum Richtlinienagenten für IIS 6.0 finden Sie im Sun Java System Access Manager Policy Agent 2.2 Guide for Microsoft Internet Information Services 6.0 .
Wenn das Konto eines Benutzer gesperrt wird, meldet Access Manager 7 2005Q4 Patch 5 errorCode = null statt errorCode = 107, wenn die maximale Anzahl an versuchten Passworteingaben überschritten wird.
Lösung. Keine.
Es wird empfohlen, vor der Ausführung des Optimierungsskripts amtune-identity die folgende Eigenschaft mit der Einstellung false der Datei AMConfig.properties hinzuzufügen:
com.sun.identity.log.resolveHostName=false
Mit false wird der Aufwand für das Auflösen von Hostnamen minimiert, wodurch die Leistung verbessert werden kann. Wenn jedoch der Hostname des Clientcomputers in das Protokoll amAuthentication.access geschrieben werden soll, setzen Sie den Wert auf true.
Wenn Sie Patch 5 aus einer vollständigen Access Manager-Serverinstallation entfernen, enthalten die Dateien amAuthLDAP.xml und amPolicyConfig.xml das Passwort für amldapuser in Klartext. Diese Dateien befinden sich je nach Plattform im folgenden Verzeichnis:
Solaris-Systeme: /etc/opt/SUNWam/config/xml
Linux- und HP-UX-Systeme: /etc/opt/sun/identity/config/xml
Umgehung: Bearbeiten Sie die Dateien amAuthLDAP.xml und amPolicyConfig.xml und löschen Sie das in Klartext enthaltene Passwort.
In Access Manager 7 2005Q4-Patches fügt das Access Manager-Konfigurationsskript für BEA WebLogic Server (amwl81config) die JAR-Dateien von JAX-RPC 1.1 dem classpath für die WebLogic-Instanz hinzu. Diese Änderung ist zwar für Produkte wie Sun Java System Portal Server vorteilhaft, eine vollständige auf einem WebLogic-Server bereitgestellte Serverinstallation (DEPLOY_LEVEL=1), kann jedoch nicht mit einer Client-SDK kommunizieren, sodass es zu Ausnahmefehlern kommt.
Wenn der Access Manager 7 2005Q4-Server auf einem BEA WebLogic-Server installiert ist, muss der CLASSPATH im Skript startWebLogic.sh auf den Speicherort der JAR-Dateien von JAX-RPC 1.0 JAR festgelegt werden, um mit dem Access Manager-Client-SDK kommunizieren zu können.
Umgehung: Legen Sie vor der Anwendung des Access Manager-Patches den CLASSPATH im Skript startWebLogic.sh so fest, dass die WebLogic-Serverinstanz die JAR-Dateien von JAX-RPC 1.0 und nicht die JAR-Dateien von JAX-RPC 1.1 verwendet:
Melden Sie sich beim Access Manager-Server als Superuser (root) an oder wechseln Sie zum Superuser.
Bearbeiten Sie das Skript startWebLogic.sh und ersetzen Sie den CLASSPATH, sodass die JAR-Dateien von JAX-RPC 1.0 verwendet werden. Beispiel:
Aktueller Wert:
CLASSPATH=/etc/opt/SUNWam/config: AccessManager-base/AccessManager-package-dir/lib/jax-qname.jar: AccessManager-base/AccessManager-package-dir/lib/namespace.jar: AccessManager-base/AccessManager-package-dir/lib/jaxrpc-api.jar: AccessManager-base/AccessManager-package-dir/lib/jaxrpc-spi.jar: AccessManager-base/AccessManager-package-dir/lib/jaxrpc-impl.jar:
Neuer Wert:
CLASSPATH=/etc/opt/SUNWam/config: AccessManager-base/AccessManager-package-dir/lib/jax-qname.jar: AccessManager-base/AccessManager-package-dir/lib/namespace.jar: AccessManager-base/AccessManager-package-dir/lib/jaxrpc_1.0/jaxrpc-api.jar: AccessManager-base/AccessManager-package-dir/lib/jaxrpc-ri.jar:
wobei AccessManager-base das Basisinstallationsverzeichnis ist. Auf Solaris-Systemen lautet der Standardwert /opt, auf Linux- und HP-UX-Systemen /opt/sun. AccessManager-package-dir ist das Access Manager-Paketverzeichnis.
5. Starten Sie die WebLogic-Serverinstanz neu.
Auf Linux-Systemen. Das Skript postpatch erstellt die Datei /opt/sun/identity/amsilent mit der Berechtigung 644, die allen Benutzern Lesezugriff gewährt.
Umgehung: Ändern Sie nach Ausführung des Skripts installpatch die Berechtigungen in der Datei amsilent, sodass nur der Eigentümer Lese- und Schreibzugriff erhält. Beispiel:
# chmod 600 /opt/sun/identity/amsilent
In diesem Bereitstellungsszenario werden zwei Access Manager-Instanzen auf demselben Hostserver bereitgestellt, wobei sich die Instanzen auf verschiedenen Webcontainer-Instanzen befinden. Führen Sie folgende Schritte aus:
Wenden Sie Patch 5 an.
Bearbeiten Sie die Datei amsilent und stellen Sie die erste Access Manager-Instanz erneut bereit.
Bearbeiten Sie die Datei amsilent erneut für die zweite Access Manager-Instanz und stellen Sie diese Instanz erneut bereit.
Wenn in der Datei amsilent die Eigenschaft NEW_INSTANCE=false festgelegt ist, wird die Datei serverconfig.xml der ersten Access Manager-Instanz mit den Informationen für die zweite Access Manager-Instanz überschrieben. Ein anschließender Neustart der ersten Access Manager-Instanz schlägt fehl. Die Datei serverconfig.xml befindet sich je nach Plattform im folgenden Verzeichnis:
Solaris-Systeme: /etc/opt/SUNWam/config
Linux-Systeme: /etc/opt/sun/identity/config
Umgehung: Legen Sie bei der Bereitstellung der zweiten Access Manager-Instanz in der Datei amsilent die Eigenschaft NEW_INSTANCE=true fest. Die Datei serverconfig.xml der zweiten Access Manager-Instanz wird so mit den richtigen Informationen aktualisiert, und die Datei serverconfig.xml der ersten Access Manager-Instanz wird nicht überschrieben.
Wenn Sie Patch 5 auf einem Rechner anwenden, der nur SDK enthält, werden die Beispiel-Makefiles überschrieben.
Umgehung: Bei der Anwendung von Patch 5 auf einen Rechner, der nur SDK enthält, ist keine Neukonfiguration erforderlich. Wenn Sie jedoch die Beispiel-Makefiles verwenden möchten, führen Sie folgende Schritte durch, um die LDIF- und Eigenschaftsdateien für die Beispiel-Makefiles zu aktualisieren (Tag-Swapping):
Führen Sie das Skript amconfig mit DEPLOY_LEVEL=14 aus, um das SDK zu deinstallieren und die Konfiguration des Webcontainers aufzuheben.
Führen Sie das Skript amconfig mit DEPLOY_LEVEL=4 aus, um das SDK erneut zu installieren und den Webcontainer erneut zu konfigurieren.
Für die Mehrzahl der Suchläufe wurde das Problem behoben. Bedenken Sie jedoch folgende Problematik beim Festlegen des Alias-Suchattributs. Der Wert des Alias-Suchattributs muss über die gesamte Organisation hinweg eindeutig sein. Wenn mehrere Alias-Suchattribute festgelegt werden, besteht die Möglichkeit, dass ein Eintrag im Datenspeicher mit einem Attribut übereinstimmt und ein anderer Eintrag mit dem anderen Attribut übereinstimmt. In diesem Fall gibt Access Manager folgenden Fehler aus:
An internal authentication error has occurred. Contact your system administrator.
Umgehung: Kein
Ein Server mit Verteilter Authentifizierungsbenutzeroberfläche und ein J2EE-Richtlinienagent können nicht zusammen ausgeführt werden, wenn diese im selben Webcontainer installiert sind.
Umgehung: Erstellen Sie eine zweite Webcontainer-Instanz und stellen Sie den Server mit Verteilter Authentifizierungsbenutzeroberfläche und den J2EE-Richtlinienagenten auf verschiedenen Instanzen des Containers bereit.
Wenn Access Manager auf einem Sun Java System Application Server auf einem Windows-System bereitgestellt wird und Sie im linken Bereich des Hilfebildschirms der Konsole im Realm-Modus auf die Hilfeschaltfläche klicken, wird ein Fehler ausgegeben.
Umgehung: Kopieren Sie die Datei javaes-install-dir\share\lib\jhall.jar in das Verzeichnis JAVA_HOME\jre\lib\ext, und starten Sie den Anwendungsserver neu.
Wenn kein expliziter goto-URL-Parameter angegeben ist, versucht ein Server mit verteilter Authentifizierungsbenutzeroberfläche auf den goto eines in Access Manager angegebenen Erfolgs-URLs (Success URL) umzuleiten. Diese Umleitung kann aus folgenden Gründen fehlschlagen:
Die URL ist relativ und es ist keine entsprechende Seite beim Server mit Verteilter Authentifizierungsbenutzeroberfläche verfügbar.
Die URL ist absolut und der Browser kann die URL nicht finden.
Umgehung: Geben Sie für einen Server mit Verteilter Authentifizierungsbenutzeroberfläche immer einen expliziten goto-URL-Parameter an.
Access Manager 7 2005Q4 wurde mit LDAP JDK 4.18 als Bestandteil der Java ES 2005Q4-Version ausgegeben, wodurch eine Reihe von Verbindungsproblemen mit Access Manager und Directory Server aufgetreten sind.
Umgehung: Wenden Sie nur eines der folgenden Sun Java System LDAP Java Development Kit-Patches an:
Solaris OS-, SPARC- und x86-Plattformen: 119725-04
Linux OS: 120834-02
Die Patches stehen unter SunSolve Online zur Verfügung.http://sunsolve.sun.com.
Auf Solaris-Systemen installiert Java ES die Datei Makefile.distAuthUI, README.distAuthUI und amauthdistui.war des Servers mit Verteilter Authentifizierungsbenutzeroberfläche im falschen Verzeichnis: /opt/SUNComm/SUNWam.
Umgehung: Kopieren Sie diese Dateien in das richtige Verzeichnis: /opt/SUNWam.
Hinweis: Alle in einem Patch behobenen Probleme bezüglich des Servers mit Verteilter Authentifizierungsbenutzeroberfläche werden in die Datei /opt/SUNComm/SUNWam/amauthdistui.war aufgenommen. Sie müssen daher diese Dateien auch jedes Mal dann in das Verzeichnis /opt/SUNWam kopieren, wenn Sie einen Patch auf den Access Manager-Server anwenden und anschließend die WAR-Datei neu erstellen und bereitstellen.
Wenn Access Manager auf einem Windows- oder HP-UX-System in einem Gebietsschema installiert ist, das Multibyte-Zeichen verwendet (z. B. Japanisch), schlägt die Suche in der Konsolen-Onlinehilfe fehl, wenn Schlüsselwörter in Multibyte-Zeichen eingegeben werden.
Umgehung: Kein
Patch 6-Aktualisierung: Access Manager 7 2005Q4 Patch 6 behebt dieses Problem auf Windows-Systemen. Auf HP-UX-Systemen besteht das Problem weiterhin.
Wenn Access Manager auf einem Windows-System in einem Gebietsschema installiert ist, das Multibyte-Zeichen verwendet (z. B. Japanisch oder Chinesisch), sind die während der Access Manager-Konfiguration im Terminal-Fenster angezeigten Ausgabemeldungen nicht lesbar.
Umgehung: Keine; dieses Problem hat jedoch keine Auswirkungen auf die Konfiguration selbst.
Wenn Sie Patch 5 (124296-05) auf einem Windows-System in einem nicht englischen Gebietsschema installieren, werden manche Zeichenfolgen in der Installationsanzeige als Eigenschaftsschlüssel anstelle von Meldungstext angezeigt. Beispiele der Eigenschaftsschlüssel: PRODUCT_NAME, JES_Patch_FinishPanel_Text1 und JES_Patch_FinishPanel_Text2.
Umgehung: Kein
Das Access Manager-Skript amtune legt die Eigenschaft com.iplanet.am.session.purgedelay auf 1 fest, um so viele Access Manager-Sitzungen wie möglich zuzulassen. Diese Eigenschaft gibt die Anzahl der Minuten an, um die die Bereinigung der Sitzung verzögert wird. Der Wert 1 ist jedoch für manche Clients (z. B. Sun Java System Portal Server) unter Umständen nicht ausreichend.
Umgehung: Setzen Sie die Eigenschaft com.iplanet.am.session.purgedelay nach der Ausführung des Skripts amtune zurück:
Legen Sie in der Datei AMConfig.properties den neuen Wert für die Eigenschaft fest. Beispiel:
com.iplanet.am.session.purgedelay=5
Starten Sie den Access Manager-Webcontainer neu, damit der neue Wert in Kraft tritt.