Posts Tagged ‘Usuarios’

Tipos de Usuario en SAP

Thursday, May 7th, 2009

En todo sistema SAP tenemos 5 opciones para definir los tipos de usuario, con sus diferentes restricciones de acceso y condiciones a la hora de ingresar al sistema. Es importante establecer correctamente los tipos de usuario ya que no debería tener una configuración similar un usuario final, un usuario de interfaz, o uno de sistema, entre otras opciones.

Por eso pasamos a describir los 5 tipos de usuario distintos que podemos definir en SAP:

Usuarios de Diálogo – Dialog users (A)

Es el tipo de usuario con el que deben acceder normalmente los usuarios finales que necesitan interactuar con el sistema a través del SAP GUI. Todos los parámetros de logueo definidos son verificados al iniciar sesión, como así también las restricciones de loguins múltiples. Normalmente la mayoría de los usuarios de nuestra organización debieran estar encuadrados dentro de este tipo.

Usuarios de Sistema – System Users (B)

Los usuarios definidos bajo esta tipología son no interactivos, lo que significa que no pueden loguearse a través del SAP GUI al sistema. Comunmente son utilizados como usuarios de procesamiento por lotes, workflow, procesos ALE, etc. Su contraseña solo puede ser cambiada por el administrador del sistema y se permiten logueos múltiples. Uso interno dentro del mismo sistema.

Usuarios de Comunicación – Communication Users (C)

Utilizados para comunicación RFC entre sistemas, son los comunmente utilizados para las interfaces con otros sistemas. No es posible establecer logueos por parte de usuarios finales a través del SAP GUI.

Usuario de Servicio – Service User (S)

Es propicio para su utilización por parte de usuarios que requieren acceso anónimo. No respetan las normas de expiración de contraseña y la misma solo puede ser cambiada por el administrador del sistema. Las autorizaciones que se le otorguen al mismo deben ser mínimas y restringidas especificamente a la necesidad por la que se creo el usuario. Su uso no es recomendable salvo necesidad específica, ya que son logoneables mediante SAP GUI.

Usuario de Referencia – Reference User (L)

Este tipo de usuarios es poco utilizado en general. No admiten logons de diálogo y pueden ser utilizados para traspasar sus autorizaciones al usuario que lo tiene como referente.

Resumen

El esquema general de tipos de usuario es bastante simple, pero lo importante es aplicarlo correctamente restringiendo a los usuarios batch o de sistema para que no puedan tener logon directo al sistema, y a los usuarios de interfaz con su respectivo usuario de comunicación.

Esto es importante ya que muchas veces los permisos de estos usuarios son demasiado amplios (debieran restringirse, pero ese ya es otro tema), y sus contraseñas pueden estar comprometidas al tener que ser almacenadas en otros sistemas para su conexión.

VN:F [1.9.10_1130]
Rating: 3.5/5 (4 votes cast)
VN:F [1.9.10_1130]
Rating: 0 (from 0 votes)

Creación de un rol – ejemplo

Thursday, April 23rd, 2009

La idea en este post es entender un proceso simple de creación de un rol,  cómo asignar una transacción a un usuario, los objetos de autorización correspondientes, etc.

Para hacer esto vamos a crear un ejemplo simple en donde vamos a crear un rol con permisos para administrar usuarios en SAP R/3.

1- Lo primero… Darle un nombre, los nombres de todos lo objetos personalizados o creados por el usuario final en SAP comienzan con la letra Z de manera estándar, la realidad es que podemos utilizar cualquier letra pero agrupar todo tras la Z es una buena manera de identificar los roles propios en caso de tener que realizar un upgrade o por cualquier motivo diferenciarlos del resto, por eso en nuestro caso el rol se llamará Z:PRUEBA (podría haber sido por ejemplo ZUSERS o Z_ABM_USUARIOS, etc). Hacemos click en el botón de Rol Simple y pasamos a la siguiente pantalla:

image

2- Una vez en la próxima ventana podemos asignar una descripción al rol y proseguir a la pestaña de “Menú”, en donde haciendo click en el botón “Transacción” incorporaremos una transacción al Rol y por consiguiente a su menú:

image

3- Una vez hecho el click nos disponemos a escribir el nombre de la transacción que queremos incorporar, también podemos hacer esto desde las opciones de Tomar Menús las cuales incorporaran las transacciones desde los menús estándar de SAP, utilizando su estructura predefinida, pero eso se los dejo para que experimenten ustedes.

image

4- Una vez incorporada la transacción al menú podemos ir a la pestaña de autorizaciones:

image

5- Una vez en el menú de autorizaciones hacemos click en Modificar Autorizaciones, y accederemos a una nueva pantalla, nos preguntará si queremos grabar el rol, esta acción es necesaria para poder tratar los objetos de autorización del mismo con lo cual contestaremos que si. La otra alternativa sería utilizar el “diskette” que se encuentra en la barra superior para grabar nuestro trabaja hasta el momento.

image

6- Una vez estemos en la nueva pantalla (a veces demora),  podemos ver los objetos de autorización agrupados por tipo de objeto.

image

7- Una vez que hacemos click en el símbolo [+] podemos ver el nombre del objeto de autorización (en este caso el primero es S_TCODE) y una breve descripción del mismo. Haciendo otra vez click en el [+] podemos ver los campos y sus valores. En este caso vemos el campo TCD y el valor SU01 que es la transacción que anteriormente agregamos en el menú y con la que automáticamente SAP carga el objeto. Resumiendo las transacciones que agregamos en el menú automáticamente son incluidas dentro de los valores del objeto S_TCODE.

image

8-Debajo de este objeto podemos encontrar 3 grupos más con sus respectivos objetos. Estos objetos de autorización son los que la transacción SU01 verifica en tiempo de ejecución (son los definidos en la transacción SU24, puede que existan más o menos chequeos que los aquí establecidos).

image

9- Tenemos que definir todos los valores de los objetos de manera de hacerlos acorde a la funcionalidad a otorgar. Por ejemplo si queremos brindar solo la posibilidad de visualizar usuarios deberíamos concentrarnos en los objetos S_ADDRESS1 (poder visualizar datos de dirección del usuario) y S_USER_GRP (permisos por grupo de usuarios) definiéndolos con la actividad 03 (visualizar) y la definición del grupo correspondiente o “*” para todos los grupos y el tipo de dirección Bc01.

image

10- Una vez realizadas todas las modificaciones se deben grabar las modificaciones (icono de diskette en la barra superior) y generar los perfiles de autorización correspondientes (ícono generar al lado del tacho de basura)

image image

11- Los otros objetos de autorización no brindan permisos adicionales en el caso de solo querer visualizar los datos de un usuario, pueden hacer la prueba y efectivamente van a ser capaces de usar la transacción SU01, pero hay funcionalidades adicionales que solo pueden ser brindados por estos otros, por ejemplo ver los permisos del usuario (roles) con los objetos S_USER_AGR, S_USER_AUT, S_USER_PRO, etc.

12- Una vez creado el rol puede definirse los usuarios que tendrán asignado el mismo desde dentro de la misma transacción PFCG o el proceso inverso desde la transacción SU01 (ingresando desde el usuario y definiendo los roles para el mismo. Una vez realizada la modificación en la PFCG se debe ejecutar la comparación de usuarios (botón) para que se actualicen efectivamente los permisos en los buffers de usuarios.

image

13- Si fuera el caso de requerir la funcionalidad de bloquear/desbloquear usuarios, por ejemplo, se otorgaría en el mismo objeto S_USER_GRP la actividad 05 y automáticamente una vez generado de nuevo el rol (y en ocasiones una vez que se comparen los roles) el usuario tendría el permiso a realizar esa acción.

El presente actúa a modo de ejemplo y podría tener muchas modificaciones para ser un rol de utilidad, pero la idea es entender como es el proceso de creación de un rol, y que el mismo aplica a roles más complejos y transacciones tanto de Base como de Negocio.

VN:F [1.9.10_1130]
Rating: 4.3/5 (8 votes cast)
VN:F [1.9.10_1130]
Rating: +2 (from 2 votes)

Usuarios por defecto (SAP*, DDIC, EARLYWATCH, etc)

Wednesday, February 18th, 2009

Hoy vamos a hablar de los usuarios por defecto del sistema SAP. Habitualmente estos usuarios los podemos encontrar no solo en R/3 si no que, en principio, también están presentes en los otros sistemas (BW, PI, Solution Manager, etc)

Estos usuarios existen por diversos motivos, principalmente vinculados con el propio funcionamiento del sistema, la instalación o la configuración del mismo.

DDIC

Podemos encontrar en principio el usuario DDIC, el cual es el utilizado para la gestión del diccionario de datos, modificación de estructuras de datos, upgrades del sistema, etc. Por estos motivos el usuario no debe ser eliminado del sistema si no que por el contrario debe ser modificada su contraseña de origen la cual viene por defecto definida como 19920607, ya que dejar este usuario con la contraseño por defecto nos expondría a riesgos asociados con los permisos amplios del mismo para operar con el sistema.

EARLYWATCH

Este usuario si bien no posee permisos tan amplios como DDIC permite el acceso al sistema con una contraseña por defecto: SUPPORT. Este usuario es utilizado para el proceso de revisión periódica del sistema por parte de SAP, en donde revisa la performance del equipo de manera remota, las licencias, etc a través de un acceso por SAPRouter. Es recomendable cambiar la contraseña de este usuario en el mandante 066 (al que accede SAP para estas evaluaciones)

SAPCPIC

Usuario utilizado para los procesos de comunicación entre sistemas y el cual también posee permisos amplios, la política es similar a la del usuario DDIC y es de cambiar su contraseña por defecto ADMIN

SAP*

Un caso parecido a DDIC, y tal vez el más grave ocurre con el usuario SAP*, el cual es el usuario con el que por primera vez iniciaremos el sistema después de la instalación, y que posee amplios permisos sobre la aplicación. En versiones anteriores a las ECC 5 de SAP la contraseña por defecto era 06071992, pero a partir de la misma se pregunta durante la instalación la contraseña inicial. Este usuario tampoco debe ser eliminado ya que es de utilidad en determinadas ocasiones para aplicaciones de parches, updates, upgrades y algunas tareas en particular que lamentablemente tienen este usuario hardcodeado como el único que puede ejecutarlas.

Borrar el usuario SAP*

Las precauciones con el usuario SAP* deben extremarse ya que en caso de borrarse el usuario de sistema la aplicación tiene un BUG o mecanísmo de seguridad en donde se genera un nuevo usuario SAP* con contraseña por defecto PASS. De esta manera si borramos el usuario SAP* estaremos abriendo un agujero de seguridad aún más grande ya que no podría cambiarse la contraseña por defecto.

La solución a este problema viene dado por un parámetro seteable en la transacción RZ11 de nombre (login/no_automatic_user_sapstar) el cual para no permitir este agujero de seguridad debe estar definido con el valor 1. (Ver artículo sobre parámetros)

Preventivamente es recomendable bloquear al usuario SAP* y desbloquearlo solo en caso de necesidad explícita de uso.

Recomendaciones Finales:

Cualquier usuario creado por defecto por el sistema implica un riesgo, ya que a los mismos se les conocen habitualmente varias vulnerabilidades. Lo primordial: cambiar sus contraseñas por defecto y de ser posible bloquear los usuarios sin borrarlos (caso SAP*). Una buena forma de verificar preventivamente esto es ejecutar desde la transacción SA38 el report RSUSR003, el cual nos brindará la información sobre las contraseñas por defecto de estos usuarios.

VN:F [1.9.10_1130]
Rating: 4.0/5 (1 vote cast)
VN:F [1.9.10_1130]
Rating: 0 (from 0 votes)