Seamos realistas, una implementación de SSO no es una tarea fácil. A pesar de que los pasos son claros para nosotros como consultores de BI, siempre hay la posibilidad de que algo falta o que necesitamos aplicar cambios a las configuraciones debido a las diferencias entre el entorno real y el manual. También es muy común no detectar tales diferencias, ya que hay varios tipos de entornos y múltiples configuraciones que pueden diferir de las guías.
El propósito de este post no es proporcionar otra guía para la implementación de AD + SSO, sino más bien ofrecer una lista de comprobación que se puede seguir cuando la implementación no tiene éxito y el SSO con AD no funciona como se desea. Esta lista también puede ser útil cuando se realiza la tarea, ya que es altamente recomendable probar todos los pasos durante el procedimiento.
Los pasos 1 a 4 son validaciones comunes que le permitirán corregir errores que pueden ser difíciles de detectar. Están relacionados con las tareas de Active Directory Server y es probable que se revisen dos veces, ya que normalmente son realizadas por otras personas (por ejemplo, el equipo de mantenimiento de AD). La mejor práctica sugiere que usted debe planificar para comprobar cada tarea, especialmente los que no son realizados por usted o su equipo.
- Probar la cuenta de servicio para la delegación Kerberos -> compruebe que la contraseña de la cuenta está establecida en "La contraseña nunca caduca".
- Cifrado a utilizar para la cuenta -> RC4 se utiliza cuando DES no está seleccionado. Para las implementaciones de SAP BusinessObjects que están bajo XI 3 .x, se prefiere RC4 ya que viene con la versión JDK 1.5. En versiones anteriores (es decir, XIR2 con java SDK 1.4. 2), RC4 puede no funcionar sin actualizar el JDK a 1.5.
- Verifique la creación del SPN predeterminado -> ejecute un "setspn -l" en la cuenta de servicio y compruebe la salida. Setspn -l debería ser algo como esto:
- Compruebe que la delegación está habilitada en la cuenta SSO de Vintela -> Busque una casilla de verificación "Confíe en este usuario para la delegación a cualquier servicio (sólo Kerberos)".
- En el servidor de BusinessObjects, revise dos veces los archivos web.xml y server.xml -> Revise las líneas agregadas o modificadas y, si es posible, vuelva a hacerlo manteniendo una copia de las originales. Algunas de las validaciones son: a) Server.xml -> Aumente el encabezado HTTP predeterminado. Normalmente, se establece en 16384, pero si su AD contiene usuarios que son miembros de muchos grupos (50 o más), puede que tenga que aumentar el. B) Web.xml -> Cambie el valor predeterminado de autenticación a secWinAD cuando utilice SSO. A continuación, recuerde que siteminder debe establecerse en false y vintela a true. Elimine los comentarios del filtro de autenticación. Después de eso, establezca el idm.realm a su REALM predeterminado (debe estar en mayúsculas). Y también establece tu idm.princ con el SPN predeterminado. Estos tres últimos pasos, se muestran de la siguiente manera:
- Compruebe que el filtro vintela se ha cargado correctamente -> para hacer eso, quite todos los registros en la carpeta Tomcat después de detener el servicio y reiniciarlo de nuevo. A continuación, busque en el archivo stdout las credenciales obtenidas. Si se obtienen las credenciales, el filtro vintela se está cargando correctamente. Si las credenciales no se obtienen, puede ejecutar el kinit y comprobar la salida como muestra la siguiente imagen:
Si has resuelto tus problemas siguiendo los puntos de este post, felicitaciones! Si no, no te rindas, sigue buscando en diferentes foros, traza tomcat (hay varias configuraciones que puedes agregar a la consola), escanea paquetes de los clientes relacionados con problemas de SSO o pide orientación. En el peor de los casos, puede que tenga que rehacer la implementación desde cero. Cualquiera que sea el caso, ¡estamos seguros de que al final tendrás éxito!