Al final del año, todos están haciendo un balance lentamente.

Para mí, este año fue recordado por el proyecto de implementación de Single Sign On (SSO) entre SAP y Windows. En este artículo hablaré sobre la experiencia de implementación y gestión de proyectos, dificultades, hallazgos y conclusiones.

La compañía es una gran empresa de transporte en Bélgica, que combina metro, tranvía y autobús. Hay más de 10 mil empleados, de los cuales casi dos mil son backoffice, que utilizan muchas herramientas: sitio web corporativo, correo, servicio de aplicaciones, sharepoint, archivero y, por supuesto, SAP.

SAP está en todas partes: desde la contabilidad y los recursos humanos hasta el registro de movimiento de unidades de transporte, documentación de accidentes, análisis, adquisiciones, almacenamiento, etc.

Problema:

• SAP for PC user es una aplicación separada para la que necesita su contraseña para ingresar
• Primero debe solicitar una contraseña y luego recordar. El soporte técnico se ve obligado a recibir llamadas para crear y cambiar contraseñas.
• Desde el punto de vista del usuario, una contraseña adicional es una molestia adicional. Las personas almacenan contraseñas en papel o las hacen demasiado simples. Seguridad grita por graves violaciones.
• Los requisitos mínimos para una contraseña para una PC no coinciden con la configuración de contraseña en SAP. Si los lleva a un denominador común, es mejor implementar SSO de inmediato.

Objetivo: implementar un SSO entre Windows y SAP, de modo que al iniciar sesión en la cuenta de su PC, el usuario pueda iniciar sesión en SAP sin ingresar una contraseña.

Si no trata con SAP, le interesará este artículo desde el punto de vista de la gestión de proyectos, ya que se proporcionarán los detalles de esos detalles (entre paréntesis).

Debajo del corte:

1. Alcance
   1.1 Alcance de personas
   1.2 Sistemas de alcance
2. Componentes
   2.1 Cambio de parámetros del sistema
   2.2 Active Directory de Windows (AD)
   2.3 Cliente de inicio de sesión seguro (SLC) de SAP
   2.4 Vinculación de un usuario de SAP a su AD
   2.5 Modificación del archivo logon.ini de SAP
3. Prueba
4. SNC es un agujero de seguridad
5. Trabajo en equipo
6. Informacion comercial
7. Dificultades de traducción
8. Resumen y conclusiones

Introduccion

Mirando hacia el futuro, si no está ansioso por completar conos estándar, aquí hay una lista de preguntas que debe aclarar para usted al comienzo del proyecto:

• Alcance del proyecto (Sistemas, usuarios: en qué orden estamos implementando, dónde está la prioridad y qué se puede descartar si algo sale mal, qué usuarios deberían tener acceso, etc.)
• Los principales departamentos afectados por el proyecto (incluso si el proyecto es tangencial, es importante que todos estén informados por adelantado)
• Sus poderes (no es muy fácil escapar aquí, en una empresa europea todo se basa en el consentimiento y el deseo voluntario de ayudar. Si el departamento dice que no tienen recursos, entonces es casi imposible presionar y "forzar". Pero puede llamar a un consultor externo para obtener ayuda, por ejemplo)
• Tiempo (para todo el proyecto en su conjunto y para partes específicas)
• Procedimientos de aprobación (regulaciones burocráticas: en una gran empresa, esta no es la última pregunta)
• Posibles dificultades (Todas. Posibles. Dificultades.)

Hemos cambiado la membresía del proyecto varias veces: al principio solo era el departamento de autorización en SAP y el departamento de administradores (Componentes básicos). Luego se les unió el departamento encargado de la autorización en Windows (Active Directory, AD) y el departamento de implementación de actualizaciones (Empaquetado), luego el departamento de bases de datos y el departamento de aplicaciones móviles, etc.

Se invitó a un consultor externo para el aspecto técnico del asunto, y Project Manager (PM) se convirtió en mí, como una persona involucrada en la autorización en SAP (por lo tanto, habrá más detalles sobre la autorización en SAP en este artículo que en otros).

Una aclaración importante: todo el acceso que damos en SAP es personalizado. No utilizamos los roles estándar que ofrece el sistema, sino que creamos otros nuevos, por departamento, por posición, por función. Hasta la fecha, no tenemos sincronización entre los usuarios de SAP y Windows AD. Por ejemplo, si su usuario tiene derechos de administrador en la red local, esto no significa que él también sea administrador en SAP.

1. Alcance

1.1 Alcance de personas

Las personas en nuestra empresa usan SAP a través de una aplicación en una computadora personal (cliente ligero - SAP Logon GUI), pero no solo. ¿Cómo contar los usuarios que caen bajo distribución?

Tomamos como base a todos los que se conectan diariamente a través de SAP Logon (Diálogo de tipo de usuario de SAP) desde computadoras portátiles. En esta categoría, todo el backoffice: personal administrativo, bukhs, Ichars, desarrolladores, evaluadores, logística, etc.

Excluido

• aquellos que tienen una computadora de escritorio, no una computadora portátil
• 8 mil usuarios que nunca abren el inicio de sesión de SAP, pero usan SAP a través del sitio web y las aplicaciones (tipo de usuario de SAP Comunicación)
• todos los usuarios externos (no empleados, pero deben iniciar sesión en el sistema a través de VPN)

1.2 Sistemas de alcance

En nuestra empresa, SAP utiliza seis paisajes activos ( ECC, BI, SRM, Netweaver, PI, Solution manager ), sin contar los sandboxes. Cada uno de ellos tiene su propio DEV , ACC , PRD , es decir de hecho, es 6 * 3 = 18 sistemas.

Por voto vocal, se decidió tomar solo los primeros cuatro paisajes. PI y SM son utilizados por un círculo estrecho de administradores y requieren actualizar el sistema en sí (al menos actualizar el componente SAP_BASIS a la versión 740). De lo contrario, la transacción de sncwizard no es compatible, y hacerlo manualmente es demasiado problemático para 10-20 personas.

2. Componentes

Las personas interesadas en esos detalles encontrarán instrucciones paso a paso en el sitio web de SAP , así como los diversos métodos disponibles (elegimos SSO basado en Kerberos , pero esta no siempre es una opción obvia).

Desde un punto de vista muy simplificado (mío), SSO es un complemento en SAP que le permite iniciar sesión con su cuenta de Windows. Enciende la computadora, ingresa la contraseña y para iniciar sesión en SAP solo necesitas hacer doble clic.

Para que la magia funcione, necesitas 5 componentes:

2.1 Cambio de parámetros del sistema (instancias SAP)

En el sistema SAP ( ECC , BI , SRM , Netweaver ) necesita activar el parámetro snc / enable = 1. Esto se realiza a través de sncwizard e incluye la preparación, el reinicio del sistema y los pasos finales de activación.

Descubrimos los parámetros antes y después con la ayuda de esos consultores, asistencia de otros departamentos y prueba y error. Lo más difícil aquí fue reiniciar el sistema.

Siempre es difícil reiniciar el PRD en producción; el trabajo se realiza las 24 horas del día. Y en una empresa de transporte esto es doblemente más complicado: el transporte se mueve desde las cinco de la mañana hasta la una de la mañana, incluso los fines de semana. Cualquier dificultad con el PRD afecta no solo a los empleados de la empresa, sino a toda la ciudad y a decenas de miles de personas. En otras palabras, debe minimizar el tiempo cuando el sistema no está disponible y, si es posible, combinarlo con otras actualizaciones. Al mismo tiempo, no se debe subestimar la burocracia: el reinicio es una fecha, hora, duración (si los parámetros no se guardan la primera vez) y una notificación comercial.

Teníamos cuatro sistemas SAP PRD: ECC, Netweaver, SRM, BI, para reiniciar

El ECC es el más importante, todos los datos en tiempo real y el transporte principal están vinculados a él: autobuses, tranvías.

Los datos del sistema Netweaver (accidentes, aplicaciones móviles), así como los sistemas ECC, se usan incluso a las 3 a.m., si los tranvías no van, los equipos de reparación se van.

Sistema SRM : se utiliza principalmente para adquisiciones y estaba disponible cualquier día después de las 18:00.

Con BI, la dificultad es que los fines de semana los flujos de datos del ECC van al sistema, además, a veces la alta dirección utiliza los informes de BI fuera del horario comercial.

En total, tardó 2 semanas en reiniciar todos los PRD.
PS El reinicio de cada uno de los sistemas PRD fue precedido por reinicios de todos los DEV y ACC, que son más fáciles de coordinar, pero también requieren planificación.

2.2 Active Directory de Windows (AD)

Active Directory requiere la creación de un usuario técnico especial (SAP Kerberos). Este usuario se pondrá en contacto con Windows para obtener una copia del ticket de entrada para SAP. Uno de esos usuarios del servicio AD es suficiente para todos los sistemas SAP.

Esta parte fue realizada en su totalidad por nuestro consultor externo y el equipo de Active Directory, incluyó varias iteraciones para refinar los parámetros y configurar la biblioteca especial, pero para mí siguió siendo más como un "recuadro negro".

2.3 Instalación de SAP Secure Login Client (SLC) en la computadora de un usuario

Este programa por sí solo no hace nada. Lo necesita para almacenar un ticket de AD que confirme a su usuario cuando inicie sesión en una sesión de Windows y, si es necesario, envíe este ticket a SAP para su autorización. SLC se puede instalar para todos los usuarios inmediatamente al comienzo del proyecto; sin los otros componentes de SSO, no funcionará de todos modos.

2.4 Vinculación de un usuario de SAP a su usuario de AD

Como ya se mencionó, en nuestra empresa no existe una única administración de usuarios, el acceso a diferentes sistemas se obtiene de diferentes equipos. En este caso, el inicio de sesión del usuario en SAP es diferente del nombre de usuario en Windows, por ejemplo, el usuario # 45011 en AD es Ivan Ivanov o IVANOVI . Es este grupo el que debe completarse en SNC (a través de la transacción SU01, campo SNC, p: CN = ADname @ dominio).

Nuestra empresa no cuenta con SAP Identity Management. Por lo tanto, era necesario resolver dos problemas: crear nuevos usuarios y actualizar los parámetros de los existentes.

Crea nuevos usuarios
En el sistema principal (ECC) todos los días laborables se crean 4-6 nuevos inicios de sesión, esto es casi 1000 nuevos usuarios por año. El proceso está automatizado: al crear un usuario, el programa completa su dirección, nombre, configuración básica. Decidimos que el programa también debería completar el campo SNC en la etapa de creación de usuarios, independientemente de si la persona necesitará SSO en SAP posteriormente o no.

El problema es que para cada usuario debe completar un nombre propio único en AD, es decir, no es el mismo parámetro para todos, es decir Es necesario que el programa mismo busque el nombre de usuario en AD y lo complete en SAP.

El desarrollador actualizó rápidamente el programa. El código y las pruebas básicas demoraron 2 días, pero los datos para la verificación en ACC no nos convenían (AD no se actualizó), por lo que enviamos de inmediato los cambios a PRD. Resultó que todo es más complicado de lo que pensábamos. En el proceso de investigación, llegamos al siguiente esquema:

1. Primero, los usuarios se crean en el sistema de recursos humanos (en SAP se pueden ver en PA20 )
2. Luego se copian en la tabla Z, junto con datos sobre el departamento, posición, posición, si es el enlace principal, etc.
3. Luego, los datos del usuario se envían a AD y aquí el sistema crea un usuario en Windows, y le da un nombre en AD y correo
4. El flujo de PI en este diagrama es simplemente para entender que es un proceso de terceros del tercer sistema
5. Los datos se copian de nuevo a SAP (en la nueva tabla Z), esta vez solo los nombres de AD y las direcciones de correo
6. En la última etapa, se lanza el programa Z, que crea usuarios en SAP ( SU01 ). No todos los usuarios que se crean en el sistema de recursos humanos se crearán más tarde en SAP, hay muchos que finalmente no usan SAP

Se necesitaron casi dos semanas para buscar, coordinar cambios, acordar un cronograma para actualizar y cargar / descargar tablas. Fue una cuestión de sincronización: el programa de creación de usuarios (punto 6) debería iniciarse estrictamente después de que todos los demás programas ya hayan funcionado y los datos se copien en tablas. Como resultado, rastreamos durante dos semanas cuándo terminó el programa y a qué hora, y depuramos el esquema.

Cuando los usuarios se crean con el campo SNC lleno, pero sin los nombres de AD requeridos, en SU01 puede ver todos los desafortunados usuarios asociados asociados a un usuario de AD inexistente.

Actualización de la configuración de usuario existente
Precisamente porque nuestro inicio de sesión SAP y Windows no coinciden, no pudimos utilizar la solución estándar de SAP para el llenado masivo en el campo SNC ( RSUSR300 a través del programa SNC1 ).

Como resultado, actualicé los datos de 10 mil usuarios existentes utilizando un script improvisado ( SAP eCATT ), cargando manualmente los datos del usuario y creando una variante. Para tener éxito, tuve que abrir para cambiar los sistemas eCATT en PRD y ACC y prometer a los desarrolladores millones de cookies.

2.5 Modificación del archivo logon.ini de SAP

Técnicamente, esto es 1 minuto. Solo es necesario tener en cuenta en las propiedades del archivo que la conexión a través de SNC está disponible .

La dificultad es que este archivo se encuentra localmente en la PC del usuario y dos mil usuarios necesitan cambiarlo.

De hecho, para nosotros, la implementación final fue el momento de distribuir el nuevo archivo sap.logon.ini entre los usuarios, en lugar de cambiar los parámetros del PRD. Porque incluso si los primeros cuatro componentes ya están hechos, y el último quinto no, la magia no sucederá.

Con el último párrafo llegó un pequeño incidente. Informé a la gerencia que tenemos 2,000 usuarios que tendrán instalada la actualización, y cuando llegó el momento de implementarla, me enviaron un estado en el que había 3,500 de ellos. Eso es porque, por mi parte, solo vi usuarios activos de SAP, pero en realidad la actualización se envió a todas las computadoras portátiles personales, que están mucho más en la empresa. Gracias a Dios no surgieron errores técnicos.

3. Prueba

¿Cómo probar SSO? O funciona o no. Nuestro desarrollador resopló y dijo que no necesita probar nada, y tan pronto como todo funcione en la caja de arena, debe enviarlo a producción. Por supuesto Nadie dirá que escribe código con errores.

Necesitas verificar:

• ¿El inicio de sesión de SAP funciona con SSO justo después de reiniciar?
• ¿Pueden los usuarios usar SSO cuando están conectados con VPN?
• dificultades para los desarrolladores de otros sistemas para modificar el inicio de sesión de SAP

SSO no es un programa; es difícil implementarlo consistentemente DEV - ACC - PRD. Sin embargo, las pruebas iniciales son necesarias para detectar todo lo que podría salir mal. La prueba en este caso es la distribución del nuevo logon.ini de SAP cuando todos los componentes ya se están ejecutando. Probamos DEV y ACC con desarrolladores y el nuevo SAP logon.ini con PRD con una selección de usuarios comerciales.

Lo que encontraron:

• a veces (1 caso por 500) necesita reinstalar completamente el inicio de sesión de SAP o SLC
• usuarios clave que tienen derechos para cambiar a otros usuarios (más sobre eso en el siguiente párrafo)

4. SNC es un agujero de seguridad

¿Qué pasa con la modificación del campo SNC?
El hecho es que al cambiar el campo SNC de otro usuario (en SU01) al suyo, puede conectarse con la cuenta de otra persona sin siquiera cambiar la contraseña. El sistema simplemente le preguntará qué usuario elegir, el suyo o el de otra persona. Sin embargo, si hace esto, mañana nadie notará nada, porque la contraseña no ha cambiado.

En cualquier empresa hay personas que se dedican a la gestión de usuarios . Por lo general, estas personas supervisan la creación de usuarios ( SU01 ) y el acceso para ellos ( PFCG ), así como las actualizaciones de contraseña. Es lógico que también puedan completar el campo SNC .

El problema surge cuando la empresa necesita separar la administración de usuarios y solo los usuarios clave. Los administradores crean usuarios y los usuarios clave, si es necesario, cambian sus datos: parámetros de usuario, su idioma, su ubicación, etc.

En SAP, no hay un paso de control separado para cambiar el campo SNC. Todos los que tienen derechos para cambiar el usuario (objeto S_USER_GRP, ACTVT 02 ) también pueden cambiar el campo SNC (mientras que cambiar la contraseña requiere el mismo objeto, pero con ACTVT 05 ).

Puede haber varias soluciones:

• quitar los derechos de acceso a SU01 de los usuarios clave y, en respuesta, dar a todos SU2 y SU3, donde el usuario puede cambiar sus propios parámetros
• quitar los derechos de acceso a SU01 y, a cambio, dar una transacción z donde no se mostrará la pestaña SNC
• deje SU01, pero proteja el campo SNC con un control especial

Como resultado, elegimos la última opción al hacer un objeto de autorización personalizado y vincular el programa SU01. Sin embargo, como resultó más tarde, SAP tiene una solución similar: puede activar el mantenimiento extendido ( nota 1882254 ) para campos SU01 individuales.

5. Trabajo en equipo

Durante el proyecto, encontré todas las dificultades del trabajo en equipo y descubrí muchas verdades básicas:

• Nunca hay mucho tiempo El margen de tiempo es el mejor que puede proporcionar el PM.
• Debe haber un plan de proyecto básico , pero debe revisarse cada semana, dejando un amplio margen para la flexibilidad. En algún lugar nos movimos más rápido, en algún lugar pisoteado en el lugar.
• Los tíos adultos en el departamento de TI a veces no difieren en el comportamiento de las niñas en contabilidad : se niegan a trabajar entre sí, simplemente porque no les gusta la persona. Y una vez más, es necesario resolver los problemas de subordinación.
• A menudo, los departamentos obstaculizan la aprobación del proyecto , porque no está claro quién es responsable de la implementación y de qué presupuesto caen las horas adicionales. Es importante dejar que los gerentes discutan todo directamente.
• Surgen situaciones imprevistas de vez en cuando . Lo mejor que puede ser es una comunicación oportuna, una carta, una llamada, un SMS a todas las personas involucradas.
• No hay nada mejor que una reunión personal . Las preguntas se resuelven muchas veces más rápido que cuando se discuten por correo. Por otro lado, todos los arreglos personales deben ser seguidos inmediatamente por una carta posterior (para arreglar y no olvidar)
• El PM en un proyecto de TI solo puede confiar en las personas . De hecho, no tiene idea de cuánto tiempo llevará esta o aquella acción: por ejemplo, ¿crear un usuario en AD para Kerberos, 10 minutos o tres días? Y no hay forma de verificar si las pruebas realmente se detuvieron o si alguien estaba jugando. Solo queda confiar.

Además, mucho depende de la perseverancia del consultor. Alguien solo, o un consultor de desarrollo o PM, debe ser tan descarado como una bala y atravesar los muros de una burocracia. En este caso, tuve suerte en parte, nuestro consultor invitado era molesto y a veces insoportable (era difícil hacerle oír algo), pero conocía su negocio: informó cualquier problema y se detiene de inmediato y no se calmó hasta que se resolvió el problema.

6. Información para empresas

En una empresa grande, los cambios que afectan a los usuarios finales deben ser oportunos y anunciarse mejor por adelantado.

En nuestro caso, era necesario informar a todos los usuarios que ahora no necesitan una contraseña para ingresar a SAP. Además, fue necesario proporcionar documentación técnica para la primera línea de soporte con todos los posibles errores que puedan surgir después de la implementación.

Debo admitir que con la comunicación todo lo que pudo haber salido mal.

En primer lugar , anunciamos a los usuarios sobre SSO en el sitio web corporativo, y no por carta. ¿Con qué frecuencia lees un sitio web corporativo? SAP .

- , , , , , , , ( - ?) , .

- , Go Live, , ( 2 ), . .

7. fuck-up

5- SSO SAP, , .

: . , — . . 2- , 500 -. .

. “use a default language SAP logon” — , , ( SU01 , Defaults ). « SAP» .

, -, .

- .

8.

SSO — , . , 1-2 , 3- .

. . , , , .

Muchas cosas sobre SSO pueden haberse sabido durante mucho tiempo, al menos Google. Por ejemplo, sobre una solicitud de servidor a AD, o el campo SNC. Pero existe una falta eterna de tiempo. Como especialista, debe buscar en Google, y como gerente de proyectos (especialmente si no puede resolverlo en la primera media hora y no tiene una educación especializada), debe encontrar el camino más corto para una solución.

 ,     ,   . 

Sólidos:

• El tiempo principal en 3 meses se dedicó a la coordinación y coordinación de acciones.
• Los departamentos involucrados en este proyecto comenzaron a comprender mejor el trabajo de los demás.
• Durante las pruebas, debe presentarse en el lugar del usuario final: lo que le gustaría ver en el mensaje de información y en la configuración básica.
• Se implementa SSO para SAP. Los usuarios están contentos y ya se han olvidado de los momentos en que era necesario recordar la contraseña de SAP. Llame al soporte técnico con menos frecuencia, aplausos.