Creación de un archivo de configuración de Kerberos
El archivo de configuración de Kerberos contiene información de configuración de cliente, incluidas las ubicaciones de los KDC (Centros de distribución de claves) para los reinos de interés, valores predeterminados para el reino Kerberos actual y correlaciones de nombres de host en reinos Kerberos. Utilice el programa de utilidad wsadmin para crear un archivo de configuración de Kerberos para WebSphere Application Server.
Acerca de esta tarea
Los valores de configuración de Kerberos, el nombre del centro de distribución de claves (KDC) de Kerberos, los valores de reino tanto para autenticación Web con SPNEGO (Simple and Protected GSS-API Negotiation Mechanism) como para autenticación con Kerberos se proporcionan en el archivo de configuración o a través de las propiedades del sistema de la máquina virtual Java™ java.security.krb5.kdc y java.security.krb5.realm.
La ubicación predeterminada es c:\winnt\krb5.ini.
Nota: Si el archivo krb5.ini no se encuentra en el directorio c:\winnt, es posible que se encuentre en el directorio c:\windows.La ubicación predeterminada es /etc/krb5.conf.
En otras plataformas Unix, la ubicación predeterminada es /etc/krb5/krb5.conf.
Procedimiento
- Inicie el programa de utilidad de la línea de mandatos ejecutando el mandato wsadmin desde el directorio raíz_servidor_apl.
- En el indicador de mandatos wsadmin, escriba el mandato siguiente:
$AdminTask help createKrbConfigFile
- Especifique los parámetros del mandato createKrbConfigFile.
Tabla 1. Parámetros del mandato createKrbConfigFile. Esta tabla lista los parámetros que puede utilizar con el mandato createKrbConfigFile:
Opción Descripción <krbPath> Necesario. Proporciona la ubicación en el sistema del archivo totalmente cualificado del archivo de configuración de Kerberos (el archivo krb5.ini o krb5.conf). <realm> Necesario. Proporciona el nombre de esfera de Kerberos. SPNEGO utiliza el valor de este atributo para formar el nombre principal del servicio Kerberos para cada uno de los hosts especificados con la propiedad com.ibm.ws.security.spnego.SPN<id>.hostName. <kdcHost> Necesario. Proporciona el nombre de host del centro de distribución de claves (KDC) Kerberos. <kdcPort> Opcional. Proporciona el número de puerto del centro de distribución de claves de Kerberos. Si este puerto se omite, el valor predeterminado es 88. <dns> Necesario. Es una lista de DNS (servicios de nombres de dominio) por omisión, separados por el carácter de barra vertical, que se utiliza para crear un nombre de host completo. El primero que aparece en la lista, es el servicio de nombres de dominio por omisión. <keytabPath> Necesario. Proporciona la ubicación de la vía de acceso de la tabla de claves Kerberos y el nombre de archivo en el sistema de archivos. <encryption> Opcional. Identifica la lista de tipos de cifrado soportados, separados por el carácter de barra vertical. El valor predeterminado es des-cbc-md5. - Especifique un tipo de cifrado. Se da soporte a los siguientes tipos de cifrado:
- des-cbc-md5
- des-cbc-crc
- des3-cbc-sha1
- rc4-hmac
- arcfour-hmac
- arcfour-hmac-md5
- aes128-cts-hmac-sha1-96
- aes256-cts-hmac-sha1-96
Atención: No todas las soluciones KDC disponibles admiten los tipos de cifrado listados anteriormente. Antes de elegir un tipo de cifrado, asegúrese de que su KDC soporta el tipo de cifrado que desea utilizar consultando la guía del usuario y del administrador Kerberos.Asegúrese de tener un tipo de cifrado común para el archivo de configuración de Kerberos, el archivo de tabla de claves de Kerberos, el nombre principal del servicio Kerberos y el cliente Kerberos. Por ejemplo, si el cliente Kerberos utiliza el tipo de cifrado RC4-HMAC, el servidor de destino también debe soportar también el tipo de cifrado RC4-HMAC y el archivo de configuración de Kerberos debe listar primero RC4-HMAC en default_tgt_enctypes y default_tkt_enctypes.
- Especifique los tipos de ubicación krbPath y krbKeytab. El código siguiente es un ejemplo del mandato createKrbConfigFile:
$AdminTask createKrbConfigFile {-krbPath c:/winnt/krb5.ini -realm WSSEC.AUSTIN.IBM.COM -kdcHost host1.austin.ibm.com -dns austin.ibm.com|raleigh.ibm.com -keytabPath c:/winnt/krb5.keytab}
Nota: Las variables WebSphere también se pueden utilizar para especificar las vías de acceso de ubicación de krbPath y krbKeytab para el mandato createKrbConfigFile.Utilice este ejemplo para crear el archivo c:/winnt/krb5.ini:[libdefaults] default_realm = WSSEC.AUSTIN.IBM.COM default_keytab_name = FILE:c:\winnt\krb5.keytab default_tkt_enctypes = rc4-hmac des-cbc-md5 default_tgs_enctypes = rc4-hmac des-cbc-md5 forwardable = true renewable = true noaddresses = true clockskew = 300 [realms] WSSEC.AUSTIN.IBM.COM = { kdc = host1.austin.ibm.com:88 default_domain = austin.ibm.com } [domain_realm] .austin.ibm.com = WSSEC.AUSTIN.IBM.COM .raleigh.ibm.com = WSSEC.AUSTIN.IBM.COM
El mandato createKrbConfigFile crea un archivo de configuración de Kerberos simple. Puede editar este archivo, según sea necesario, para especificar una preferencia TCP o UDP o si se tiene un entorno de reino cruzado o de confianza.
En la sección [libdefaults], especifique una preferencia de protocolo TCP o UDP. De forma predeterminada, la configuración Java de Kerberos utiliza el protocolo UDP. Sin embargo, Kerberos de Java da soporte a una configuración de protocolo TCP o UDP mediante el parámetro udp_preference_limit. Si necesita utilizar el protocolo TCP, especifique el parámetro udp_preference_limit con un valor de 1 para que se utilice siempre el protocolo TCP. Por ejemplo:
Si no especifica este parámetro, la biblioteca de Kerberos de Java utiliza el protocolo TCP sólo si se produce un error en la solicitud del ticket Kerberos mediante el protocolo UDP y el KDC devuelve el código de error KRB_ERR_RESPONSE_TOO_BIG.udp_preference_limit =1
Avoid trouble: Cuando el servidor de aplicaciones recibe una solicitud de cliente, la configuración de Kerberos en el servidor puede devolver una excepción de restablecimiento de conexión, IOException o una excepción de conducto roto si utiliza el protocolo TCP y el KDC devuelve un paquete incorrecto. El servidor de aplicaciones realiza tres intentos de capturar el paquete Kerberos correcto. Si se devuelve un paquete Kerberos correcto como resultado de uno de los tres intentos, la solicitud del cliente se procesa correctamente y puede ignorar estas excepciones. Si el servidor de aplicaciones no puede obtener el paquete Kerberos correcto después de tres intentos, la solicitud del cliente falla. En este punto, revise las configuraciones del KDC, de la red y del servidor de aplicaciones para determinar el problema.gotcha
- Complete la sección [domain_realm] del archivo de configuración de Kerberos para
un entorno de reino cruzado.
- [domain_realm]: Proporciona una conversión de un dominio de nombre o nombre de host
en un nombre de reino. El nombre de código
puede ser un nombre de host o un nombre de dominio. Los nombres de
dominio se indican mediante un prefijo o un punto ('.'). El valor de
la relación es el nombre de reino para el host o dominio en
cuestión. Los nombres de host y nombres de dominio deben escribirse en minúsculas.Si no se aplica ninguna entrada de conversión, el reino del host se considera como la parte del dominio del nombre de host convertida a mayúsculas. Por ejemplo, la siguiente sección [domain_realm] correlaciona tech.ibm.com con el reino TEST.AUSTIN.IBM.COM:
[domain_realm] .austin.ibm.com = WSSEC.AUSTIN.IBM.COM .raleigh.ibm.com = WSSEC.AUSTIN.IBM.COM
Todos los demás hosts de los dominios austin.ibm.com and .raleigh.ibm.com se correlacionan con WSSEC.AUSTIN.IBM.COM de manera predeterminada.
El siguiente ejemplo contiene más de un nombre de reino Kerberos:[domain_realm] .ibm.com =AUSTIN.IBM.COM ibm.com =AUSTIN.IBM.COM tech.ibm.com =TEST.AUSTIN.IBM.COM .fubar.org =FUBAR.ORG
Los demás hosts del dominio ibm.com se correlacionan por omisión con el reino AUSTIN.IBM.COM y todos los hosts del dominio fubar.org se correlacionan por omisión con el reino FUBAR.ORG.
Tenga en cuenta las entradas para los hosts, ibm.com y fubar.org. Sin estas entradas, estos hosts se correlacionan en los reinos COM y ORG, respectivamente.
Para la autenticación entre reinos de confianza de iguales, consulte la guía del usuario y del administrador Kerberos para obtener información sobre cómo configurar la autenticación entre reinos de confianza en el KDC.
- [domain_realm]: Proporciona una conversión de un dominio de nombre o nombre de host
en un nombre de reino. El nombre de código
puede ser un nombre de host o un nombre de dominio. Los nombres de
dominio se indican mediante un prefijo o un punto ('.'). El valor de
la relación es el nombre de reino para el host o dominio en
cuestión. Los nombres de host y nombres de dominio deben escribirse en minúsculas.
- Añada información sobre el reino foráneo a las secciones realms y domain_realm del
archivo de configuración de Kerberos:
[realms] AUSTIN.IBM.COM = { kdc = kdc.austin.ibm.com:88 default_domain = austin.ibm.com } FUBAR.ORG = { kdc = kdc.fubar.org:88 default_domain = fubar.org } [domain_realm] austin.ibm.com = AUSTIN.IBM.COM .austin.ibm.com = AUSTIN.IBM.COM fubar.org = FUBAR.ORG .fubar.org = FUBAR.ORG
En una confianza transitiva, dos reinos confían entre sí si confían en los reinos intermedios implicados en la otorgación de un ticket. Si cada reino implicado en la otorgación del ticket de servicio se encuentra en la vía de acceso de confianza, el ticket es de confianza. Consulte la guía del usuario y del administrador Kerberos para obtener información sobre cómo configurar la confianza transitiva en el KDC.
Para configurar una confianza transitiva, se deben definir distintos reinos con autenticación entre reinos entre A y B y entre B y C, pero no entre A y C. Con la confianza transitiva, REALMA y REALMC se pueden comunicar entre sí, pero sólo si lo hacen a través de REALMB.REALMA <-> REALMB <-> REALMC
- Añada datos a las stanzas. Añada una stanza [capaths]
a cada archivo krb5.conf.
Los archivos krb5.conf de todas las máquinas deben listar los tres reinos en la stanza [realms]. REALMA debe listarse a sí mismo y a REALMB y REALMC; REALMB debe listarse a sí mismo y a REALMA y REALMC; REALMC debe listarse a sí mismo y a REALMA y REALMB. En la stanza [domain_realm] de los archivos krb5.conf se listan los tres nombres de host y nombres de reino que pueden ejecutarse de REALMA a REALMC y de REALMC a REALMA.
[capaths] REALMA.AUSTIN.IBM.COM = { REALMB.AUSTIN.IBM.COM = . REALMC.AUSTIN.IBM.COM = REALMB.AUSTIN.IBM.COM } REALMB.AUSTIN.IBM.COM = { REALMC.AUSTIN.IBM.COM = . REALMA.AUSTIN.IBM.COM = . } REALMC.AUSTIN.IBM.COM = { REALMB.AUSTIN.IBM.COM = . REALMA.AUSTIN.IBM.COM = REALMB.AUSTIN.IBM.COM }
- Establezca el permiso del archivo krb5.conf en 644.
Esto significa que el archivo se puede leer y grabar. No obstante, los miembros del grupo al que pertenece el archivo y todos los demás usuarios sólo pueden leer el archivo.
Dado que la configuración de Kerberos y el archivo de tabla de claves se establecen mediante las propiedades del sistema JVM, java.security.krb5.conf y KRB5_KTNAME respectivamente, si la autenticación Web SPNEGO y la autenticación Kerberos están habilitadas, deberá utilizar la misma configuración de Kerberos y los mismos archivos de tabla de claves para ambas.
Resultados


http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tsec_kerb_create_conf
File name: tsec_kerb_create_conf.html