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)".
- In the BusinessObjects server, double check files web.xml and server.xml -> Review lines added or modified and, if possible, redo it maintaining a copy of the original ones. Some of the validations are: a)Server.xml -> Increase the default HTTP Header. Normally it is set to 16384 but if your AD contains users that are members of a lot of groups (50 or more), you may need to increase the. b)Web.xml -> Change the authentication default to secWinAD when using SSO. Then remember that siteminder must be set to false and vintela to true. Remove the comments from the auth filter. After that, set the idm.realm to your default REALM (must be in capital letters). And also set your idm.princ to the default SPN. These three last steps, are shown as follows:
- 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!