Sicherheitsfailover bei mehreren LDAP-Servern

Die Sicherheitsfunktion in WebSphere Application Server kann in der Weise konfiguriert werden, dass bei mehreren LDAP-Hosts ein Failover versucht wird.

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.

Falls der zurzeit aktive LDAP-Server nicht verfügbar ist, versucht die Sicherheitsfunktion von WebSphere Application Server ein Failover mit dem ersten verfügbaren LDAP-Host in der angegebenen Hostliste. Die LDAP-Server können Replikate desselben Master-LDAP-Servers oder beliebige LDAP-Hosts mit demselben Schema sein, die Daten enthalten, die aus derselben LDAP-LDIF-Datei (LDAP Data Interchange Format) importiert wurden.

Bei jedem Failover verwendet die Sicherheitsfunktion von WebSphere Application Server den ersten verfügbaren LDAP-Server aus der angegebenen Hostliste. Wenn beispielsweise vier LDAP-Server in der Reihenfolge L1, L2, L3 und L4 konfiguriert sind, wird L1 als primärer LDAP-Server betrachtet. Die Rangliste der Verbindungen beginnt bei L1 und endet bei L4. Ist die Sicherheitsfunktion von WebSphere Application Server beispielsweise gerade mit L4 verbunden, wenn ein Failover oder eine Verbindungswiederholung erforderlich wird, versucht die Sicherheitsfunktion von WebSphere Application Server zuerst, eine Verbindung zu L1 herzustellen, danach zu L2 und dann zu L3, bis der Verbindungsversuch erfolgreich ist.

Der aktuelle LDAP-Hostname ist in der Nachricht SECJ0419I der Protokolldatei SystemOut.log von WebSphere Application Server protokolliert. Falls Sie die Verbindung zum primären LDAP-Host wiederherstellen möchten, führen Sie die MBean-Methode "resetLDAPBindInfo" von WebSphere Application Server mit null,null als Eingabe aus.

Zum Konfigurieren des LDAP-Failover für mehrere LDAP-Hosts müssen Sie mit wsadmin oder ConfigService den Backup-LDAP-Host aufnehmen, für den keine zahlenmäßige Beschränkung gilt. In der Administrationskonsole wird der primäre LDAP-Host angezeigt, der auch als erster in der LDAP-Hostliste in der Datei security.xml aufgeführt ist.

Als Name des Sicherheitsrealms von WebSphere Application Server wird standardmäßig der in der Administrationskonsole angezeigte Name des primären LDAP-Hosts verwendet. Der Name endet mit einem Doppelpunkt und ggf. einer Portnummer. Der Standardname des Sicherheitsrealms kann jedoch durch das Hinzufügen der angepassten Eigenschaft "com.ibm.websphere.security.ldap.logicRealm" außer Kraft gesetzt werden. Konfigurieren Sie mit dem logicRealm-Namen jede Zelle so, dass sie einen eigenen LDAP-Host hat. Auf diese Weise sind Interoperabilität und Abwärtskompatibilität gewährleistet. Außerdem kann der LDAP-Host dynamisch hinzugefügt und entfernt werden. Wenn Sie eine Migration von einer früheren Installation durchführen, wird der neue logicRealm-Name erst wirksam, wenn die Verwaltungssicherheit erneut aktiviert wird. Aus Gründen der Kompatibilität mit einem früheren Release, das keinen logischen Realm unterstützt, muss der logicRealm-Name mit dem in der früheren Installation verwendeten Namen (auf Doppelpunkt und Portnummer endender Name des LDAP-Hosts) übereinstimmen.

Wenn das LDAP-Failover durch Zuordnung eines einzelnen Hostnamens zu mehreren IP-Adressen über eine Lastausgleichsfunktion (die diese Umsetzung für WebSphere Application Server transparent durchführt) konfiguriert wird, kann die Eingabe eines ungültigen Kennworts zu mehreren LDAP-Bindungsversuchen führen. WebSphere Application Server führt die Wiederholungen durch, und die Lastausgleichsfunktion leitet Anforderungen an mehrere Replikate weiter. Bei Verwendung der Standardeinstellungen ist die Anzahl der LDAP-Bindungsversucht mit der Anzahl zugeordneter IP-Adresse plus 1 identisch. Das bedeutet, dass ein einziger ungültiger Anmeldeversuch zum Sperren des LDAP-Accounts führen kann. Wenn die angepasste Eigenschaft "com.ibm.websphere.security.registry.ldap.singleLDAP" auf false gesetzt ist, werden LDAP-Bindungsaufrufe nicht wiederholt.

Wenn LDAP-Failover durch die Registrierung der Hostnamen von Back-End-LDAP-Servern mit dem wsadmin-Befehl konfiguriert wurde, setzen Sie die Eigenschaft "com.ibm.websphere.security.ldap.retryBind" auf "false".

Das folgende Jacl-Beispiel veranschaulicht, wie Sie mit wsadmin einen LDAP-Sicherungshost für das Failover hinzufügen können:
#---------------------------------------------------------------
# Main
#  This is a bi-modal script: it can be included in the wsadmin
#  command invocation like this:
#     wsadmin -f LDAPAdd.jacl ldaphost 800
#
#  or the script can be sourced from the wsadmin command line:
#     wsadmin> source LDAPAdd.jacl
#     wsadmin> LDAPAdd ldaphost 800
#
#  The script expects some parameters:
#      arg1 - LDAP Server host name
#      arg2 - LDAP Server port number
#---------------------------------------------------------------
if { !($argc == 2)} {
   puts ""
   puts "LDAPAdd: This script requires 2 parameters: LDAP server host name and LDAP server port number"
   puts "For example: LDAPAdd ldaphost 389"
   puts ""
   return;
}
else {
   set ldapServer        [lindex $argv 0]
   set ldapPort          [lindex $argv 1]
   LDAPAdd $ldapServer $ldapPort
   return;
}
proc LDAPAdd {ldapServer ldapPort args} {
   	global AdminConfig AdminControl ldapServer ldapPort 
   set ldapServer  lindex $args 0
   set ldapPort  lindex $args 1
   global ldapUserRegistryId
   # Get the LDAP user registry object from the security configuration
   if { catch {$AdminConfig list LDAPUserRegistry} result } {
      		puts stdout "\$AdminConfig list LDAPUserRegistry caught an exception $result\n"
      return
   } 
   else {
      if {$result != {}} {
         set ldapUserRegistryId  lindex $result 0
      } 
      else {
         		puts stdout "\$AdminConfig list LDAPUserRegistry caught an exception $result\n"
         return;
      }
   }
   # Set the host and port values in Attrs2 
   set Attrs2  list  list hosts  list  list  list host
   $ldapServer
   list port $ldapPort
   
   # Modify the LDAP configuration host object
   $AdminConfig modify $ldapUserRegistryId $Attrs2
   $AdminConfig save   
}
Das folgende Jython-Beispiel veranschaulicht, wie Sie mit wsadmin einen LDAP-Sicherungshost für das Failover hinzufügen können:
#---------------------------------------------------------------
# Add ldap hostname and port
#     wsadmin -f LDAPAdd.py arg1 arg2
#
#  The script expects some parameters:
#      arg1 - LDAP Server hostname
#      arg2 - LDAP Server portnumber
#---------------------------------------------------------------
import  java

#-------------------------------------------------------
# get the line separator and use to do the parsing 
# since the line separator on different platform are different
lineSeparator = java.lang.System.getProperty('line.separator')

#-------------------------------------------------------------------------------
# add LDAP host
#-------------------------------------------------------------------------------
def LDAPAdd (ldapServer, ldapPort):
    global AdminConfig, lineSeparator, ldapUserRegistryId
    try:
        ldapObject = AdminConfig.list("LDAPUserRegistry")
        if len(ldapObject) == 0:
            print "LDAPUserRegistry ConfigId was not found\n"
            return

        ldapUserRegistryId = ldapObject.split(lineSeparator)[0]
        print "Got LDAPUserRegistry ConfigId is " + ldapUserRegistryId + "\n"
    except:
        print "AdminConfig.list('LDAPUserRegistry') caught an exception\n"

    try:
        secMbeans = AdminControl.queryNames('WebSphere:type=SecurityAdmin,*')
        if len(secMbeans) == 0:
            print "Security Mbean was not found\n"
            return

        secMbean = secMbeans.split(lineSeparator)[0]
        print "Got Security Mbean is " + secMbean + "\n"
    except:
        print "AdminControl.queryNames('WebSphere:type=SecurityAdmin,*') caught an exception\n"


    attrs2 = [["hosts", [[["host", ldapServer], ["port", ldapPort]]]]]
    try:
        AdminConfig.modify(ldapUserRegistryId, attrs2)
        try:
            AdminConfig.save()
            print "Done setting up attributes values for LDAP User Registry"
            print "Updated was saved successfully\n"
        except:
            print "AdminConfig.save() caught an exception\n"
    except:
        print "AdminConfig.modify(" + ldapUserRegistryId + ", " + attrs2 + ") caught an exception\n"
    return

#-------------------------------------------------------------------------------
# Main entry point
#-------------------------------------------------------------------------------
if len(sys.argv) < 2 or len(sys.argv) > 3:
        print("LDAPAdd: this script requires 2 parameters: LDAP server hostname and LDAP server port number\n")
        print("e.g.: LDAPAdd ldaphost 389\n")
        sys.exit(1)
else:
        ldapServer = sys.argv[0]
        ldapPort = sys.argv[1]
        LDAPAdd(ldapServer, ldapPort)
        sys.exit(0)

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_secfailover_ldap
Dateiname:csec_secfailover_ldap.html