Für weitere Informationen über Probleme mit OpenSSO Enterprise siehe:
https://opensso.dev.java.net/servlets/ProjectIssues
WebLogic Server StuckThreadMaxTime value is exceeded during configuration
4099: ID-WSF-Muster mit JDK 1.4 WAR führte zu Ausnahmefehlermeldung
4055: Beim Hinzufügen einer erweiterten Eigenschaft in der Konsole trat ein Fehler auf
3837: Fehlschlag der Konfiguration auf Oracle Application Server 10g
2222: Passwortzurücksetzungs- und Kontensperrungsdienst-Mitteilungsfehler
Fehlschlag der Konfiguration von OpenSSO Enterprise auf WebLogic Server, weil weblogic.jar eine ältere ldapjdk.jar-datei bündelt.
Sun bietet eine neue ldapjdk.jar-Datei an, die sicherheits- und leistungsbezogene Fixes enthält. Für WebLogic Server 9.2 und WebLogic Server 10 muss das folgende Workaround bereitgestellt werden.
Workaround. Die Sun ldapjdk.jar wie folgt vor der weblogic.jar in dem CLASSPATH, positionieren:
Die ldapjdk.jar von der opensso.war mit dem folgenden Befehl in ein temporäres Verzeichnis extrahieren:
jar xvf opensso.war WEB-INF/lib/ldapjdk.jar
Die oben extrahierte ldapjdk.jar in das WebLogic lib-Verzeichnis kopieren.
Beispiel für WebLogic Server 10 auf Solaris- oder Linux-Systemen: BEA_HOME /weblogic_10.0/server/lib
Oder für WebLogic Server 9.2 auf Windows:BEA_HOME\weblogic92\server\lib
Stellen Sie die Pfadangabe dieser ldapjdk.jar dem vorhandenen Klassenpfad als Präfix voran. indem Sie den zum Starten des WebLogic Servers verwendeten Startskript bearbeiten. In den folgenden Beispielen ist BEA_HOME der Installationsort des WebLogic Servers.
Bei WebLogic 9.2 auf Windows wie folgt bearbeiten:
BEA_HOME\weblogic92\samples\domains\wl_server\bin\startWebLogic.cmd
Verändern Sie eingestellten CLASSPATH=%CLASSPATH%;%MEDREC_WEBLOGIC_CLASSPATH% in:
set CLASSPATH=BEA_HOME\weblogic92\server\lib\ldapjdk.jar;%CLASSPATH%;%MEDREC_WEBLOGIC_CLASSPATH%
Bei WebLogic 10 auf Windows wie folgt bearbeiten:
BEA_HOME \wlserver_10.0\samples\domains\wl_server\bin\startWebLogic.cmd
Ändern Sie eingestellten CLASSPATH=%CLASSPATH%;%MEDREC_WEBLOGIC_CLASSPATH% in:
set CLASSPATH= BEA_HOME\wlserver_10.0\server\lib\ldapjdk.jar;%CLASSPATH%;%MEDREC_WEBLOGIC_CLASSPATH%
Bei WebLogic 9.2 MP2 auf Solaris oder Linux wie folgt bearbeiten:
/bea/weblogic92/samples/domains/wl_server/bin/ startWebLogic.sh
oder
/usr/local/bea/user_projects/domains/base_domain/bin/startWebLogic.sh
Ändern Sie CLASSPATH="${CLASSPATH}${CLASSPATHSEP}${MEDREC_WEBLOGIC_CLASSPATH}" in:
CLASSPATH= "BEA_HOME/weblogic92/server/lib/ldapjdk.jar${CLASSPATH}${CLASSPATHSEP}${MEDREC_WEBLOGIC_CLASSPATH}" |
Bei WebLogic 10 auf Solaris oder Linux wie folgt bearbeiten:
/bea/wlserver_10.0/samples/domains/wl_server/bin/startWebLogic.sh
oder
/bea/user_projects/domains/wl10_domain/bin/startWebLogic.sh
Ändern Sie CLASSPATH="${CLASSPATH}${CLASSPATHSEP}${MEDREC_WEBLOGIC_CLASSPATH}" in:
CLASSPATH= "BEA_HOME/wlserver_10.0/server/lib/ldapjdk.jar${CLASSPATH}${CLASSPATHSEP}${MEDREC_WEBLOGIC_CLASSPATH}"
Starten Sie den Server neu.
Konfiguration von OpenSSO Enterprise.
Wenn Sie WebLogic Server 9.2 MP2 oder 10 unter Verwendung des Konfigurators konfigurieren und länger als 600 Sekunden zur Fertigstellung der Konfiguration benötigen, wird der folgende Fehler an das Terminal und die WebLogic Server-Domäne und die Serverprotokolle gemeldet:
<Error> <WebLogicServer> <BEA-000337> <[STUCK] Exe cuteThread: '5' for queue: 'weblogic.kernel.Default (self-tuning)' has been busy for "681" seconds working on the request "Http Request: /opensso/setup/setSetup Progress", which is more than the configured time (StuckThreadMaxTime) of "600" seconds. Stack trace: ...
Dieser Fehler tritt auf, weil der WebLogic Server seinen “Stuck Thread Max Time:” Vorgabewert von 600 Sekunden überschritten hat.
Workaround. Wenn der Konfigurator nicht reagiert, diesen neu starten. Ziehen Sie auch in Betracht, den WebLogic Server “Stuck Thread Max Time”-Wert von seinen vorgegebenen 600 Sekunden auf einen größeren Wert wie z. B. 1200 Sekunden einzustellen. Verwenden Sie zur Änderung dieses Wertes ( base_domain > Umgebung > Server > Admin Server > Konfiguration/Tuning ) die WebLogic Console.
Auf dem WebLogic Server 8.1 führte die für ID-WSF konfigurierte opensso-client-jdk14.war auf der Suche nach Wartung zu einer Fehlermeldung.
Workaround. Fügen Sie die folgenden JAR-Dateien ein unter weblogic-home/jdk142_08/jre/lib/: jax-qname.jar, namespace.jar, relaxngDatatype.jar , xalan.jar und xsdlib.jar.
Die xalan.jar-Datei befindet sich im WEB-INF/lib-Verzeichnis in opensso.war. Die anderen Dateien befinden sich in dem WEB-INF/lib -Verzeichnis in opensso-client-jdk14.war.
Dieses Problem tritt auf, wenn die folgenden Bedingungen erfüllt sind:
Ihr Konfigurationsdatenspeicher ist der Sun Java System Directory Server.
Sie versuchen, eine Installation von mehreren Servern durchzuführen.
Ihr amadmin-Passwort unterscheidet sich von dem Server-Verbindungs-dn-Passwort.
Workaround. Dieses Workaround besteht aus zwei Teilen:
Stellen Sie sicher, dass Ihr Konfigurations-Server-Verbindungs-dn-Passwort dasselbe wie Ihr amadmin-Passwort ist.
Konfigurieren Sie den zweiten, und zusätzliche OpenSSO Enterprise-Server. Zur Durchführung der Installation des zweiten Servers und Hinweisen auf das Konfigurationsverzeichnis des ersten OpenSSO Enterprise-Servers greifen Sie einfach auf die Konfiguratorseite des zweiten OpenSSO Enterprise-Servers zu und geben das amadmin-Passwort, die Cookie-Domäne und weitere Details für Schritt 1 und Schritt 2 ein.
Bei Schritt 3 Folgendes nicht auswählen: Zu vorhandener Bereitstellung hinzufügen. Stattdessen die Option der ersten Instanz auswählen und denselben Directory Server-Namen, Port, DN, Passwort und Chiffrierschlüssel Ihres ersten Servers angeben. Dann wie gewöhnlich mit der Konfiguration fortfahren.
Das Hinzufügen einer erweiterten Eigenschaft in der Konsole veranlasste den OpenSSO Enterprise-Server zu einer Fehlermeldung. Dieses Problem kann nach dem Hinzufügen einer beliebigen erweiterten Konfigurationseigenschaft auftreten.
Workaround. Wenn Sie die standardmäßige Serverkonfiguration in Console ändern, ist ein Neustart des Webcontainers des OpenSSO Enterprise-Servers erforderlich.
Mit Oracle Application Server 10g Version 10.1.3.1 als Webcontainer schlug die OpenSSO Express-Konfiguration mit einem Ausnahmefehler fehl.
Workaround. Fügen Sie vor der Konfiguration von OpenSSO die folgende JVM-Option zu “Server Properties” für die Zielserverinstanz des Oracle Application Servers 10g hinzu:
-Doc4j.jmx.security.proxy.off=true
OpenSSO Enterprise übermittelt E-Mail-Benachrichtigungen unter Verwendung des nicht berechtigten Absendernamens Identity-Server, der Fehlermeldungen in die Protokolle einträgt.
Workaround. Ändern Sie den Absendernamen von Identity-Server in den folgenden Dateien in Identity-Server@hostname.domainname um:
Änderung in amPasswordResetModuleMsgs.propertiesvon fromAddress.label.
Änderung in amAuth.propertiesvon lockOutEmailFrom .
4102: TTL für die Konfiguration des Servicemanagements funktioniert nicht
4085: OpenSSO Enterprise kann die CRL nicht im LDAP-Verzeichnis speichern
3827: Replikationskonfiguration hängt in der zweiten Glassfish-Instanz
3350, 2867: LDAP Follows Referral sollte für Active Directory Data Store deaktiviert sein
Time to live (TTL) für die Konfiguration des Servicemanagements funktioniert nicht, weil die TTL-Eigenschaft nicht ordnungsgemäß initialisiert ist.
Nach dem Erhalt der Zertifikat-Widerrufliste (Certificate Revocation List) (CRL) von der CRL-Verteilungspunkterweiterung speichert OpenSSO Enterprise die CRL nicht im LDAP-Verzeichnis.
Bei diesem Szenario wird OpenSSO Enterprise auf zwei Glassfish- (oder Application Server 9.1)-Instanzen auf Windows Vista Server bereitgestellt. Während der Konfiguration der zweiten OpenSSO Enterprise-Instanz hängt der Wiederruf der Konfiguration unter Verwendung der Option “Zu vorhandener Bereitstellung hinzufügen".
Workaround. Dieses Problem tritt weiterhin bei Windows Vista-Systemen auf. Bei anderen Windows-Systemen außer Vista fügen Sie die folgende Glassfish (oder Application Server 9.1) JVM-Option hinzu:
-Dcom.sun.enterprise.server.ss.ASQuickStartup=false
Ein Active Directory-Datenspeicher führt manchmal zum Systemabsturz. Dieses Problem kann auch auftreten, wenn Sie einen neuen Active Directory-Datenspeicher erzeugen.
Workaround. In der OpenSSO Enterprise Admin Console LDAP Follows Referral für den Active Directory-Datenspeicher deaktivieren:
Klicken Sie auf Zugriffssteuerung, Top-Level-Bereich , Datenspeicher, ActiveDirectory-Datenspeichername.
Aktiviert für LDAP Follows Referral deaktivieren.
Änderungen speichern.
Wenn OpenSSO Enterprise mit dem AMSDK-Plug-In konfiguriert, und der Verzeichnisserver für MMR eingerichtet ist, tritt kein Failover ein, wenn eine Verzeichnisserverinstanz abstürzt.
4100: Zertifikatauthentifizierung mit CRL-Prüfung fehlgeschlagen
4054: amadmin-Authentifizierung mit URL-org-Parameter nicht möglich
1781: amadmin-Anmeldung auf Grund von nicht erfolgter Data Store-Authentifizierung fehlgeschlagen
Wenn Sie ein Windows Desktop SSO-Authentifizierungsmodul konfigurieren, um eine Kerberos-Authentifizierung von Internet Explorer 6.0 auf Windows Server 2003 auszuführen, wird die Fehlermeldung “Keine Konfiguration gefunden" ausgegeben.
Wenn Sie eine Zertifikatauthentifizierung konfigurieren und “Zertifikat mit CRL vergleichen" aktivieren, scheitert die Authentifizierung. Siehe auch das damit verwandte Problem 4085: OpenSSO Enterprise kann die CRL nicht im LDAP-Verzeichnis speichern.
Wenn der OpenSSO Enterprise Admin (amadmin) einen neuen Bereich (wie z. B. myorg) erzeugt und später versucht, sich wie folgt in dem neuen Bereich anzumelden:
http://host:port/opensso/UI/Login?org=myorg
Gibt OpenSSO Enterprise eine Fehlermeldung Authentifizierung fehlgeschlagen aus.
Workaround. Als amadmin können Sie sich nur in dem Root-Bereich anmelden (und nur bei Data Store- oder Application-Modulen).
Wenn Sie das Authentifizierungsmodul für den Root-Bereich auf etwas außer 0DataStoreändern, kann sich amadmin nicht in der Console anzumelden.
Workaround. Anmeldung unter Verwendung von http://host.domain/deployurl/UI/Login?module=DataStore .
Die index.html unter host: port/uri/samples zeigt Folgendes an:
1. Authentication Samples 2. ID-FF Sample 3. SAMLv2 Sample 4. Multi-Federation Protocols Sample
Die folgende Verknüpfung zu den Richtlinienmustern fehlt jedoch in index.html : host:port/ uri/samples/policy/policy-plugins.html
Workaround: Öffnen Sie die host:port/uri/samples/policy/policy-plugins.html -Datei in Ihrem Browser.
Zur Aktivierung der OCSP-Prüfung für einen OpenSSO-Webcontainer mit aktiviertem Java Security Manager die folgende Berechtigung zu der server.policy (oder gleichwertigen) Datei hinzufügen:
permission java.security.SecurityPermission "getProperty.ocsp.*";
Bei der Erzeugung eines Console Only Deployment ist die Erzeugung eines Fedlets unter Verwendung der Console Common Tasks mit einer Fehlermeldung fehlgeschlagen, dass keine solche Datei oder Verzeichnis für sp-extended.xml vorhanden war. Die com.iplanet.services.configpath -Eigenschaft wurde nicht durch den Nur-Konsolen-Konfigurator eingestellt.
Workaround. Die AMConfig.properties -Datei bearbeiten und die com.iplanet.services.configpath-Eigenschaft auf das Konfigurationsverzeichnis einstellen. Beispiel:
com.iplanet.services.configpath=/consoleonly
Access Manager Roles-Richtliniensubjekt wird nur mit Access Manager-Repository (AMSDK)-Datenspeicher unterstützt Dieses Subjekt ist in der Richtlinienkonfiguration standardmäßig deaktiviert. Deshalb das Access Manager Roles-Richtliniensubjekt nur aktivieren, wenn der Datenspeichertyp zur Verwendung mit dem AMSDK-Plug-In konfiguriert ist.
Für weitere Informationen siehe Kapitel 14, Enabling the Access Manager SDK (AMSDK) Identity Repository Plug-in in Sun OpenSSO Enterprise 8.0 Installation and Configuration Guide.
3910: setup.bat of ssoSessionTools.zip kann Tools nicht installieren
2827: Durch die Konfiguration einer Site wird der zweite Server nicht zu der Site hinzugefügt
Nach dem Entpacken von ssoSessionTools.zip, dem Ausführen der setup.bat kann das Skript die Sitzungsskripts nicht installieren und gibt folgende Fehlermeldung aus:
Keine die Spezifikation "1.4+" erfüllende JRE auffindbar
Workaround. In dem setup.bat -Skript -version:"1.4+" von dem java.exe-Befehl entfernen und das Skript erneut ausführen.
Sitzungs-Failover-Konfiguration fügt die zweite OpenSSO Enterprise-Instanz nicht zu der Liste der zugewiesenen Server hinzu.
Workaround. Die OpenSSO Enterprise Console oder das ssoadm-Dienstprogramm verwenden, um die zweite Serverinstanz manuell zu der Serverliste hinzuzufügen.
Manchmal schlägt der import-svc-cfg-Unterbefehl fehl, weil OpenSSO Enterprise Knoten im Service Manager-Datenspeicher nicht löschen kann. Dieses Problem kann durch die folgenden Szenarios verursacht werden:
OpenSSO Enterprise unter Verwendung eines entfernten Sun Java System Directory Servers als Konfigurationsdatenspeicher konfigurieren.
Exportieren Sie die Dienst-XML-Datei unter Verwendung des ssoadm export-svc-cfg -Befehls.
Reimportieren Sie die erhaltenen Dienst-XML-Daten in Schritt 2 unter Verwendung des ssoadm import-svc-cfg-Befehls.
Bei Aufforderung zum Löschen der vorhandenen Daten "Ja" auswählen.
Die folgende Fehlermeldung wird angezeigt: Unerwarteter LDAP-Ausnahmefehler.
Workaround. Den ssoadm import-svc-cfg-Befehl erneut ausführen, bis die Ausführung erfolgreich ist.
Sie können den ssoadm-Befehl mit get-realm auf Grund dieses Ausnahmefehlers nicht ausführen.
Logging configuration class "com.sun.identity.log.s1is.LogConfigReader" failed com.sun.identity.security.AMSecurityPropertiesException: AdminTokenAction: FATAL ERROR: Cannot obtain Application SSO token. Check AMConfig.properties for the following properties com.sun.identity.agents.app.username com.iplanet.am.service.password Logging configuration class "com.sun.identity.log.s1is.LogConfigReader" failed com.sun.identity.security.AMSecurityPropertiesException: AdminTokenAction: FATAL ERROR: Cannot obtain Application SSO token. Check AMConfig.properties for the following properties com.sun.identity.agents.app.username com.iplanet.am.service.password AdminTokenAction: FATAL ERROR: Cannot obtain Application SSO token. Check AMConfig.properties for the following properties com.sun.identity.agents.app.username com.iplanet.am.service.password
Prüfen, ob sich das amadmin-Passwort von dem Directory-Manager-Passwort für den Service Management-Datenspeicher unterscheidet. Wenn ja, das folgende Workaround anwenden.
Workaround. Die Serverkonfigurations-XML wie folgt ändern:
Bei OpenSSO Console als amadmin anmelden.
Verwenden Sie ssoadm.jsp get-svrcfg-xml, um die Serverkonfigurations-XML zu erhalten.
Verwenden Sie encode.jsp zur Codierung des amadmin-Passworts.
Setzen Sie das codierte Passwort in die zwei Orte ein, die durch amadmin-password im XML dargestellt werden. Beispiel:
<User name="User1" type="proxy"> <DirDN> cn=puser,ou=DSAME Users,dc=opensso,dc=java,dc=net </DirDN> <DirPassword> amadmin-password </DirPassword> </User> <User name="User2" type="admin"> <DirDN> cn=dsameuser,ou=DSAME Users,dc=opensso,dc=java,dc=net </DirDN> <DirPassword> amadmin-password </DirPassword> </User> <BaseDN> dc=opensso,dc=java,dc=net </BaseDN> </ServerGroup>
Verwenden Sie ssoadm.jsp get-svrcfg-xml, um die abgeänderte Serverkonfigurations-XML zu setzen.
Nach dem Ausführen des Setup-Skripts für das ssoadm-Dienstprogramm wird bei dem Versuch, ssoadm auszuführen, eine NoClassDefFoundError-Fehlermeldung angezeigt. Dieses Problem tritt bei einer aktualisierten OpenSSO Enterprise-Instanz auf.
Workaround. Zur Verwendung von JSS fügen Sie jss4.jar zu dem Klassenpfad hinzu und setzen Sie die LD_LIBRARY_PATH -Umgebungsvariable. (Bei Verwendung der standardmäßigen JCE muss sich die jss4.jar nicht im Klassenpfad befinden.)
Für eine Client SDK-Installation ist der Service Management Service (SMS)-Cache standardmäßig deaktiviert.
Workaround: Für Web Services Security (WSS)-Anwendungen com.sun.identity.sm.cache.enabled=false in der AMConfig.properties-Datei einstellen, da das Fix für Problem 3171 sonst nicht funktioniert.
Für alle weiteren SDK-Anwendungen com.sun.identity.sm.cache.enabled=true in der AMConfig.properties-Datei einstellen, um SMS-Zwischenspeicherung zu aktivieren, wodurch Leistungsprobleme vermieden werden können.
Der Client SDK-Konfigurator positioniert das falsche gemeinsame Geheimnis in der AMConfig.properties-Datei
Workaround. Kopieren Sie den gemeinsamen geheimen Wert und den Passwortverschlüsselungsschlüssel von dem OpenSSO Enterprise-Server zu der SDKAMConfig.properties-Datei in dem $HOME/OpenSSOCLient-Verzeichnis.
3065: Für alle Benutzer in den ID-FF-Protokolldatensätzen wird dieselbe Kontext-ID verwendet
2661: logout.jsp wurde auf dem WebSphere Application Server 6.1 nicht kompiliert
1977: SAMLv2 sample configure.jsp-Dateien auf WebSphere Application Server 6.1 fehlgeschlagen
Mit einem auf Oracle Application Server bereitgestellten OpenSSO Enterprise verursacht die Erzeugung einer Entity (IDP oder SP) in der Seite Allgemeine Konsolenaufgaben einen Ausnahmefehler.
Workaround. Bei Bereitstellung von opensso.war auf Oracle Application Server die Importoption für die oracle.xml-Datei in der Bereitstellungsplanansicht deaktivieren (Bereitstellen: Bereitstellungseinstellungen > Laden von Klassen konfigurieren > oracle.xml).
Alle ID-FF-Protokolldatensätze haben dieselbe Kontext- (oder Anmelde-) ID, auch wenn diese für verschiedene Benutzer sind.
Die logout.jsp-Datei erfordert JDK 1.5, doch die JDK-Quellenebene für JSP-Dateien ist auf dem IBM WebSphere Application Server 6.1 auf JDK 1.3 eingestellt.
Workaround. Siehe Workaround für 1977: SAMLv2 sample configure.jsp-Dateien auf WebSphere Application Server 6.1 fehlgeschlagen.
Auf einer WebSphere Application Server 6.1-Instanz ist bei den /sample/saml2/sp/configure.jsp und /sample/saml2/idp/configure.jsp-Dateien die Kompilierung fehlgeschlagen. Die logout.jsp-Dateien erfordern JDK 1.5, doch die JDK-Quellenebene für JSP-Dateien ist auf dem WebSphere Application Server 6.1 auf JDK 1.3 eingestellt.
Workaround: Die JSP-Engine-Konfigurationsparameter bearbeiten, um die JDK-Quellenebene auf 1.5 einzustellen:
Die WEB-INF/ibm-web-ext.xmi-Datei öffnen.
Die JSP-Engine-Konfigurationsparameter werden entweder im Konfigurationsverzeichnis eines Webmoduls oder in dem Binärdateienverzeichnis eines Webmoduls in der WEB-INF/ibm-web-ext.xmi-Datei gespeichert:
Konfigurationsverzeichnis. Beispiel:
{WAS_ROOT}/profiles/profilename/config/cells/cellname/applications/ enterpriseappname/deployments/deployedname/webmodulename/
Binärdateienverzeichnis, wenn eine Anwendung in dem WebSphere Application Server bereitgestellt wurde, und das Flag “Binärkonfiguration verwenden" auf true eingestellt war. Beispiel:
{WAS_ROOT}/profiles/profilename/installedApps/nodename/ enterpriseappname/webmodulename/
Den compileWithAssert-Parameter löschen, indem entweder die Anweisung aus der Datei gelöscht wird, oder durch Einschließen der Anweisung mit Comment Tags (<!— und –>).
Den jdkSourceLevel-Parameter mit dem Wert 15 hinzufügen. Beispiel:
<jspAttributes xmi:id="JSPAttribute_1" name="jdkSourceLevel" value="15"/>
Hinweis: Die Ganzzahl (_1) in JSPAttribute_1 muss innerhalb der Datei einmalig sein.
Die ibm-web-ext.xmi-Datei speichern.
Die Anwendung neu starten.
Für weitere Informationen über den jdkSourceLevel-Parameter sowie weitere JSP-Engine-Konfigurationsparameter siehe:
Wenn Sie das Proxy-Fallbeispiel auf der Grundlage der Loan-Musteranwendung für Web Services Security (WSS) einrichten und zwei Web Service Provider (WSP) mit anderen Profilnamen als wsp erzeugen, tritt ein Fehler auf.
Workaround. Für JAX-WS/Webanwendungen, die auf Webdiensten basieren, das statische Punktende als WSP-Namen zur Unterstützung mehrerer Webdienste verwenden. Für Webdienste auf EJB-Basis die standardmäßige WSP-Konfiguration verwenden.
3961: amadmin kann sich im Koexistenzmodus nicht bei OpenSSO Console anmelden
2348: Document Distributed Authentication UI-Serverunterstützung
Nach der Konfiguration von OpenSSO Enterprise entgegen dem vorhandenen Schema (DIT) können Sie sich nicht bei der Konsole anmelden, da der während der Konfiguration eingegebene Chiffrierschlüssel (derjenige von der alten Access Manager- oder Federation Manager-Instanz) nicht verwendet wird. Stattdessen wird ein neuer Chiffrierschlüssel erzeugt, der eine inkorrekte serverconfig.xml-Datei generiert.
Workaround.
Wechseln Sie in das config-Verzeichnis von OpenSSO Enterprise.
Ändern Sie den Chiffrierschlüssel in der AMConfig.properties-Datei mit dem korrekten Wert.
Kopieren Sie die Sicherungskopie von serverconfig.xml von der vorherigen Access Manager- oder Federation Manager-Instanz.
OpenSSO Enterprise-Server neu starten.
Wenn OpenSSO mit einem Access Manager 7.1 Directory Server-Schema (DIT) im Koexistenzmodus konfiguriert ist, und sich ein Nicht-Administrator-Benutzer an der OpenSSO Console anmeldet, wird der Benutzer zu einer ungültigen URL weitergeleitet. Beispiel:
http://ssohost.example.com:8080/amserver/..amserver/base/AMAdminFrame .
Workaround. URL wie folgt bearbeiten:
protocol://host. domain:port/deploy_uri/idm/EndUser
Beispiel:
http://ssohost.example.com:8080/amserver/idm/EndUser
Wenn OpenSSO mit einem Access Manager 7.1 Directory Server-Schema (DIT) im Koexistenzmodus konfiguriert ist, schlägt ein Anmeldeversuch als amadmin bei der Console unter Verwendung der LDAP-Authentifizierung fehl.
Workaround. Beim Anmelden als amadmin bei der OpenSSO Console im Koexistenzmodus fügen Sie den module=DataStore -Abfrageparameter hinzu. Beispiel:
protocol://host. domain:port/deploy_uri/UI/Login/?module=DataStore
Beispiel:
http://ssohost.example.com:8080/amserver/UI/Login/?module=DataStore
Die OpenSSO Enterprise Distributed Authentication UI-Serverkomponente funktioniert nur mit OpenSSO Enterprise. Die folgenden Szenarios werden nicht unterstützt:
Distributed Authentication UI-Server 7.0 oder 7.1 mit einem OpenSSO Enterprise-Server
OpenSSO Enterprise Distributed Authentication UI-Server mit einem Access Manager 7.0 oder 7.1 Server
Wenn Sie ein Upgrade von einer früheren Version von Access Manager oder Federation Manager auf OpenSSO Enterprise 8.0 durchführen, funktionieren ID-FF-Profile nur dann, wenn Sie auch ein Upgrade für das Access Manager- oder Federation Manager-Schema durchführen.
Workaround. Führen Sie vor dem Ausprobieren der ID-FF-Profile ein Upgrade des Access Manager- oder Federation Manager-Schemas durch. Für weitere Informationen über ein Upgrade des Schemas siehe Sun OpenSSO Enterprise 8.0 Upgrade Guide .
4090: Nicht-Englische Berechtigungen werden unkenntlich gemacht
4051: Multibyte-Name eines vertrauenswürdigen Partners wird in Console unkenntlich gemacht
3993: Endbenutzerseite zeigt Fragezeichen für CCK- und JA-locales
3976: Onlinehilfe “Tipps zur Suche” hat einen 404-Fehler an einem Nicht-Englischen locale zur Folge
3713: Passwort-Zurücksetzungsseite wird für CCJK-locales nicht lokalisiert
1793: Authentifizierung schlägt mit Multibyte-Zeichen für org oder Modul in Abfrageparameter fehl
Workaround: Verwenden Sie zum Anzeigen der lokalisierten Berechtigungen, die im .txt-Format vorliegen, einen Browser, wobei die die Verschlüsselung in dem Browser für jeden locale wie folgt angegeben ist:
Französisch (fr): ISO–8859-1
Spanisch (es): ISO–8859-1
Deutsch (de): ISO–8859-1
Vereinfachtes Chinesisch (zh_CN): UTF-8
Traditionelles Chinesisch (zh_TW): UTF-8
Koreanisch (ko): UTF-8
Japanisch (ja): EUC-JP
Wenn Sie in OpenSSO Console zu Federation > SAML1.x-Konfiguration gehen und dann einen neuen Trusted Partner mit einem Multibyte-Namen im Abschnitt Common Settings gehen, wird der Name des vertrauenswürdigen Partners unkenntlich gemacht.
Wenn Sie sich am Geronimo Webcontainer in CCK- und JA-locales als ein anderer Benutzer als amadmin anmelden, zeigen Access Control, realm, General, EndUser page (http:// host:port/deployuri/idm/EndUser ) Fragezeichen an.
Wenn Sie sich bei OpenSSO Console an einem Nicht-Englischen locale wie z. B. bei Französisch anmelden, auf Hilfe und dann auf “Tipps zur Suche” klicken, zeigt das rechte Hilfefeld eine 404-Fehlermeldung an.
Workaround. Zur Anzeige von “Tipps zur Suche” auf Englisch legen Sie als Browsersprache Englisch fest und aktualisieren Sie das Fenster der Onlinehilfe
Wenn Sie den Webcontainer am C-locale starten und in Ihrem Browser eine Sprache wie z. B. Französisch festlegen, werden nach Ihrer Anmeldung bei der Admin Console einige Zeichen unkenntlich gemacht.
Für CCJK-locales wird die Passwort-Rücksetzungsseite (http://host :port/deployuri/password ) nicht lokalisiert.
Die dounix_msgs.po-Dateien für das Unix-Authentifizierungsmodul wurden nicht übersetzt, da das Unix-Authentifizierungsmodul in einer zukünftigen OpenSSO Enterprise-Version nicht enthalten sein wird. Siehe Überarbeitungsmitteilungen und -ankündigungen
Wenn Sie versuchen, sich bei OpenSSO Console unter Verwendng der org oder Modul -Parameter mit Zeichen anzumelden, die nicht UTF-8 entsprechen, schlägt die Anmeldung fehl. Beispiel: http://host:port/ deployuri/UI/Login?module=Japanese-string&gx_charset=UTF-8
Workaround. Verwenden Sie UTF-8 URL-Verschlüsselungszeichen wie z. B. %E3%81%A6 anstatt nativer Zeichen.
4017: An spanischen locales wird “2.2 Agents” nur als Agentes in Console übersetzt
3971: An chinesischen (zh_CN) locales ist die Onlinehilfe auf Englisch
3802: Probleme im französischen Teil des Copyright-Hinweises
Wenn sich OpenSSO Console an einem spanischen locale befindet, fehlt 2.2 bei der Übersetzung von “2.2 Agents”.
Wenn sich OpenSSO Console an einem spanischen locale befindet, wird beim Klicken auf Konfiguration, Authentifizierung und dann Zertifikat eine Fehlermeldung angezeigt.
An dem chinesischen (zh_CN) locale. wird der Console-Onlinehilfetext auf Englisch, und nicht auf Chinesisch angezeigt. Wenn Sie als Ihre bevorzugte Browsersprache zh_CN festlegen, wird nur der Onlinehilfetext im linken Strukturbaum auf Englisch angezeigt. Wenn Sie als Ihre bevorzugte Browsersprache zh festlegen, wird der gesamte Onlinehilfetext auf Englisch angezeigt.
Workaround. Kopieren Sie die zh_CN Onlinehilfeinhalte in ein neues zh-Verzeichnis im webapps-Verzeichnis des Webcontainers und führen Sie einen Neustart des Webcontainers durch.
Kopieren Sie z. B. für Tomcat /Tomcat6.0.18/webapps/opensso/html/zh_CN/* in ein neues Verzeichnis mit der Bezeichnung /Tomcat6.0.18/webapps/opensso/html/zh/ . Und führen Sie dann einen Neustart des Tomcat-Containers durch.
Im französischen Teil des englischen Copyright-Hinweises fehlt bei “Etats-unis” ein Akzent, ein Leerzeichen fehlt nach dem Komma bei “armes nucléaires,des missiles”, und innerhalb von “Etats - Unis” sollte sich kein Leerzeichen befinden.