Pgina 1 de 49

SEGURIDAD SAP R/3

Pgina 2 de 49

Tabla de Contenidos

0-OBJETIVO ............................................................................................................................................. 3

1-ALCANCE ............................................................................................................................................... 3

1.1-A QUIEN VA DIRIGIDO? ........................................................................................................................ 3

2-INTRODUCCIN ................................................................................................................................. 4

2.1-GRUPO DE ACTIVIDAD .......................................................................................................................... 4 2.2-GRUPO DE ACTIVIDAD DERIVADO ......................................................................................................... 4 2.2-ROL .................................................................................................................................................... 5 2.2-ROL COMPUESTO ................................................................................................................................. 5

3-INTERACTUANDO CON EL SISTEMA ........................................................................................... 6

3.1-PFCG ................................................................................................................................................. 7 3.1.1 Nomenclatura de GA .............................................................................................................. 8 3.1.2 GA - Simple............................................................................................................................. 9 3.1.3 Solapa MENU ....................................................................................................................... 10

3.1.3.1 Asignacin de transaccin Modo estndar .......................................................... 11 3.1.3.2 Asignacin de transaccin Desde el men de SAP ............................................... 12 3.1.3.3 Asignacin de transaccin Desde un GA ............................................................. 14 3.1.3.4 Asignacin de transaccin Desde un archivo TXT ............................................... 19

3.1.4 Solapa AUTORIZATIONS .................................................................................................... 20 3.1.5 Niveles Organizacionales ..................................................................................................... 22 3.1.6 Solapa USERS ...................................................................................................................... 28

3.1.6.1 Asignacin de usuario ............................................................................................. 28 3.1.6.2 Desafectar usuario de un GA .................................................................................. 30 3.1.6.3 Desafectar usuarios de un GA en modo masivo ...................................................... 31 3.1.6.4 Datos bsicos de usuario ......................................................................................... 32

3.1.7 GA - Derivado ...................................................................................................................... 33 3.1.7.1 Modificacin de un GAD ......................................................................................... 35 3.1.7.2 Autorizaciones distribuidas ..................................................................................... 37 3.1.7.3 Problemas en las Autorizaciones ............................................................................ 41 3.1.7.4 Otras funciones ........................................................................................................ 44

3.2-SU53 ............................................................................................................................................... 46 3.2.1 Ejecutando SU53 para transacciones................................................................................... 46 3.2.2 Ejecutando SU53 para autorizaciones ................................................................................. 48

Pgina 3 de 49

0-Objetivo

Demostrar el funcionamiento de la herramienta para entender en que sitio del

sistema impactan los cambios que se desarrollan en los grupos de actividad asociados

a los usuarios.

Medir el impacto de las autorizaciones y entender los conceptos de segregacin

de funciones.

1-Alcance

Este curso pretende llegar a la mnima granularidad en lo que respecta a la

seguridad de SAP R/3, pasando por las herramientas estndar de creacin de grupos de actividad, informes de auditoria de seguridad, tablas de seguridad y funcionales, parmetros bsicos de usuarios, creacin de usuarios, definicin de roles, etc.

1.1-A quien va dirigido? Este curso va dirigido aquellas personas que se estn iniciando en la seguridad

de SAP R/3 y, en una segunda etapa, aquellos administradores con conocimientos

bsicos de las herramientas estndar del sistema.

Pgina 4 de 49

2-Introduccin

En principio veamos algunos conceptos bsicos que demos tener en cuenta

sobre la teora de seguridad en SAP R/3. Estos conceptos nos sern de gran ayuda a

lo largo del curso, ya que con estos conceptos daremos la totalidad del curso.

A continuacin, abarcaremos los conceptos de Grupo de Actividad, Grupo de

Actividad Derivado, Rol, y Rol compuesto. Para ello daremos la definicin de cada uno

de ellos con el fin de tengamos bien en claro como es realmente cada uno de estos.

2.1-Grupo de actividad El grupo de actividad, tambin denominado errneamente ROL, nos es ms que un sub.-conjunto de un rol. El mismo, posee una pequea porcin de las funciones

que desempeara un recursos o puesto de trabajo (Varios recursos).

Entonces cuando hablamos de un GA (Grupo de Actividad), podemos

relacionarlo con el string de caracteres que cargamos en la transaccin PFCG para

realizar un alta, baja o modificacin del mismo. La transaccin PFCG ser explicada

en captulos posteriores

2.2-Grupo de actividad derivado El grupo de actividad derivado, es, jerrquicamente hablando, sbdito del GA

(Grupo de actividad). El mismo, posee las autorizaciones en funcin del GA padre,

vale decir, que si el GA padre posee diez (10) transacciones, el GA derivado poseer

los objetos de autorizacin chequeados por la transacciones del GA padre.

En un esquema ordenado, la autorizaciones debern estar en los GA derivados

y la transacciones en los GA padre. El GA padre nunca deber poseer autorizaciones

salvo una excepcin que es cuando se quiere limitar por niveles organizacionales.

Un ejemplo de GAD puede ser: ZAR_E_CO:FI:GRTE_GRAL

Pgina 5 de 49

2.2-Rol Un Rol, es un conjunto de GADs agrupados para desempear una funcin

preestablecida. Esta funcin nace de un anlisis funcional y de proceso que no

abarcaremos en este curso.

Un ejemplo de Rol puede ser: GERENTE

2.2-Rol compuesto Un rol compuesto, es un conjunto de Roles o GAD para realizar una tarea

CROSS o abarcativa de varios puestos de trabajo. Los Roles compuestos son muy

difciles de mantener dado que se crean con un propsito especifico y terminan siendo

alterados por el desconocimiento del proceso, o por directrices mal gestionadas.

Pgina 6 de 49

3-Interactuando con el sistema

En esta seccin vamos a ver las distintas transacciones que involucran a la

seguridad en SAP R/3. Algunas de ellas son de impacto directo, mientras que otras

son de investigacin en forma indirecta a la seguridad.

Las transacciones a utilizar sern las siguientes:

1. PFCG (Profile Generador)

2. SU01 (Gestin de usuarios)

3. SU10 (Gestin de usuarios en masa)

4. SU53 (Datos de autorizacin para usuario)

5. SU56 (Autorizaciones en el buffer del usuario)

6. SU24 (Chequeo de objetos para transaccin)

7. SE10 (Liberacin de ordenes de transporte)

8. SE16 (Browser de tablas)

9. SE37 (Programas del sistema)

10. STMS (Sistema de transportes)

Las tablas que utilizaremos sern las siguientes:

1. ADCP (Datos de usuario)

2. ADRP (Datos de usuario)

3. AGR_DEFINE (Definicin de GA)

4. AGR_USERS (Usuarios por GA)

5. AGR_TCODES (Transacciones por GA)

6. AGR_1016 (Autorizaciones por GA)

7. AGR_1251 (Datos de autorizaciones)

8. AGR_1252 (Niveles organizacionales en autorizaciones)

9. AGR_AGRS (Jerarqua de GA (Roles Compuestos))

10. TACT (Descripcin de actividades)

11. TOBJ (Objetos del sistema)

12. TSTCA (Transacciones con valores estndar por objeto)

13. TSTCT (Descripcin de transacciones)

14. USR02 (Usuarios del sistema)

15. USR05 (Parmetros de usuarios del sistema)

Pgina 7 de 49

16. USR21(Datos de usuario)

17. USOBT (Objetos chequeados por transacciones (Standard))

18. USOBT_C (Idem anterior (Copia))

3.1-PFCG La transaccin PFCG (Profile Generador), es utilizada generalmente para la

creacin de GA, asignacin de autorizaciones y eventualmente asignacin de usuarios

al GA creado o modificado. Tambin se utiliza para remover usuarios de los GA

indicados por personal jerrquico.

Dicha transaccin, tiene muchas mas funcionalidades que sern vistas a los

largo de este punto.

En la figura 1 observaremos la pantalla de inicio de la transaccin.

Figura 1

Como podemos observar, en la pantalla principal de la transaccin, adems de

tener mltiples opciones, podemos crear, modificar, visualizar o borrar un grupo de

actividad.

Pgina 8 de 49

3.1.1 Nomenclatura de GA

Tanto para la creacin de nuevos GA, como transacciones, objetos de

autorizacin, etc., SAP, deja a disposicin de los usuarios las letras Y y Z para el

comienzo de la denominacin de algunas de las actividades antes mencionadas.

De esta manera, es muy simple detectar lo que no es estndar de SAP, y en

funcin de ello, poder realizar el anlisis correspondiente ante cualquier situacin. No

olvidemos, que los desarrollos estndar de SAP NUNCA comenzaran con las letras anteriormente descriptas.

Igualmente, no hay una regla de oro para la nomenclatura que utilicemos, para

este caso preciso, utilizaremos la denominacin PRUEBA, cuya inicial no es Y ni Z.

En los casos prcticos (Servidores DEV QUA - PRD) inexorablemente debern

comenzar con las consonantes antes mencionadas.

En el caso de que los mismo no comiencen con las consonantes que

mencionamos anteriormente, los mismo funcionaran y no habr ningn tipo de

problemas en cuanto a la funcionalidad de los mismos. Pero hay que destacar, que se

esta saliendo del estndar y ello puede traer consecuencias para los futuros

administradores del sistema.

Pgina 9 de 49

3.1.2 GA - Simple

En la figura 2 observaremos la creacin de un GA. Para ello, debemos ingresar

el nombre del GA en el campo ROLE y luego presionar el botn que se encuentra a la

derecha denominado ROLE .

Figura 2

Podemos observar que una vez creado el GA, pasamos a ver una serie de

solapas en donde podemos definir el Menu del usuario, las Autorizaciones para las

transacciones que posee en el men y la asignacin a el/los usuarios que harn uso

del GA creado. Veamos paso por paso como se construye un grupo de actividad.

Pgina 10 de 49

En la solapa Descripcin, daremos detalle de que se trata el GA para futuros

cambios a los que pueda ser sometido el GA. A continuacin, en la figura 3 y 4

veremos los dos primeros pasos descriptos anteriormente.

Figura 3

Como podemos ver, la descripcin queda a la entrada al GA, vale decir, que de

ahora en mas cuando queramos modificar el GA, lo primero que nos aparecer en

pantalla es la pantalla de la figura 3.

3.1.3 Solapa MENU

Haciendo un clic en la solapa Menu, nos encontraremos con la pantalla de la

figura 4, donde podremos hacer mltiples configuraciones, yendo desde la mas bsica

(Manual) hasta copias del menu de otros GAs.

Pgina 11 de 49

Figura 4

El paso a seguir, es incorporarle transacciones al nuevo GA, dado que la

configuracin actual no nos es de mucha utilidad.

3.1.3.1 Asignacin de transaccin Modo estndar

Para agregar una transaccin, haremos un clic en el botn ,

donde nos aparecer a modo POP-UP la pantalla de la figura 5.

Figura 5

Pgina 12 de 49

En los espacios en blanco, definiremos las transacciones que queremos que

formen parte del grupo de actividad, en este caso, solo hemos incorporado la

transaccin SM37.

Para que la transaccin sea confirmada en el GA, debemos hacer un clic en el

botn Asignar Transaccin . A partir de ese momento, la

transaccin empieza a formar parte del GA lo que no quiere decir que la misma se

encuentre operativa para su uso. Mas adelante configuraremos la puesta en marcha

de las transacciones asignadas.

3.1.3.2 Asignacin de transaccin Desde el men de SAP

Ahora, vamos a incorporar una transaccin desde el men sap. Para ello,

debemos hacer clic en el botn From the SAP menu . Ante

este evento, nos aparecer una pantalla a modo POP-UP como se ve en la figura 6.

Figura 6

Pgina 13 de 49

En esta pantalla podremos seleccionar las transacciones a partir del men

SAP. Las mismas, estn ordenadas en carpetas y bajo ese mismo esquema es como

las importara. Veamos un ejemplo en la figuras 7 y 8.

Figura 7

Como vemos en la figura 7, hemos seleccionado la transaccin SM02 a travs del

men estndar de SAP. Para que la misma comience a formar parte del GA, debemos hacer

un clic en el botn Transfer .

Como mencionbamos anteriormente, en la figura 8 veremos la incorporaron de las

transacciones seleccionadas por los dos primeros mtodos.

A continuacin veremos los mtodos restantes.

Pgina 14 de 49

Figura 8

Ahora veamos los tres mtodos restantes que son de gran utilidad a la hora de

simplificar trabajo en el diseo de GAs. Comnmente, estos mtodos no son

utilizados ya que los mantenimientos se realizan en forma manual. Lo ideal seria

mantener el esquema propuesto por SAP, ya que de esta manera, los GA se

convertiran en estndares.

3.1.3.3 Asignacin de transaccin Desde un GA

El siguiente mtodo que vamos a investigar es el de tomar transacciones desde

otro GA que conozcamos. Como todos sabemos, SAP en la instalacin, deja GAs

genricos creados para su utilizacin. Estos GAs son los que propone para la

utilizacin del sistema, dado que los mismos estn normalizados y las funciones se

encuentran correctamente segregadas.

En la figura 9, vamos a trabajar con el men de un GA estndar de SAP.

Cuando apreciemos la pantalla, podremos observar que prcticamente no difiere en

relacin al mtodo From the SAP men.

Para comenzar con este mtodo, debemos hacer un clic en el botn from other

role . En ese instante, nos aparecer una pantalla a modo

de POP-UP tal como vemos a continuacin.

Pgina 15 de 49

Figura 9

En esta pantalla, podremos optar por seleccionar entre Single Roles o

Composite Roles. En nuestro caso vamos a continuar tal cual nos aparece la

pantalla.

En el campo Single Role debemos colocar el nombre del GA que queremos

utilizar como referencia para el men. Si desconocemos este, debemos hacer un clic

en el botn . Como nosotros no tenemos conocimiento del GA a utilizar,

procederemos a tomar la accin antes descripta. En ese momento, el sistema arrojara

una pantalla como muestra la figura 10

Figura 10

Pgina 16 de 49

En la figura 10 observamos gran parte de los grupos de actividad creados en el

sistema. Ah, seleccionamos el GA al que deseamos para heredar el men y luego

hacemos clic en el botn . En nuestro caso, hemos seleccionado el GA

SAP_ACH_ADMIN.

En la figura 11, observamos una pantalla muy similar a la de la figura 6.

Figura 11

Si comparamos con detenimiento las figuras 6 y 11, vemos que la diferencia es

perceptible dado que en la cabecera de una pantalla y otra, lo nico que vara es SAP

estndar Menu por SAP_ACH_ADMIN. El resto, salvando las distancias de las

transacciones asignadas, es prcticamente similar.

Pgina 17 de 49

Una vez seleccionada la transaccin que se adecuaba a nuestro GA, haremos

clic en el botn Add .

Antes de ver como quedo plasmada la transaccin en el GA, veamos los

ltimos dos mtodos que nos quedan. El mtodo que a continuacin veremos, es el de

incorporar un rea del men. Difcilmente utilicemos esta opcin, aunque es muy util

en las reingenieras de seguridad ya que podremos decir con exactitud los procesos

de cada rea siempre que el dueo de los datos este de acuerdo con el mtodo a

emplear.

Para comenzar, debemos pulsar el botn From area menu

.

En la figura 12 veremos un pop-up que solicitara algunos datos.

Figura 12

Muy probablemente, las reas de men lo las conozcamos en demasa, con lo

cual pulsaremos el botn para que el sistema no de un resumen de todas las

reas creadas hasta el momento.

La pantalla arrojada por el sistema es como la que podemos observar en la

figura 13.

Pgina 18 de 49

Figura 13

Seleccionaremos la primera rea de men y veremos la pantalla tal como

muestra la figura 14.

Figura 14

Esta pantalla, que como vemos es similar a la de la figura 6 y 11, y la

operatoria es exactamente igual a las dos anteriores. Lo nico que difiere es la

asignacin del rea en cuanto a que no es una transaccin, si no que es un rea de

Pgina 19 de 49

transacciones. Esto es exclusivamente as cuando seleccionamos toda el rea como lo

haremos nosotros.

3.1.3.4 Asignacin de transaccin Desde un archivo TXT

Por ultimo, resta ver como armar el men de transacciones desde un archivo

de texto. Cabe destacar, que esta opcin no tiene una frecuente utilizacin. El caso

donde se aplica con frecuencia esta modalidad, es en la recopilacin de roles tanto en

reingenieras como puestas en marcha.

La aplicacin que genera la salida del archivo TXT podra ser una macro en

Excel, o bien, un desarrollo propio.

A continuacin, veremos el esqueleto del archivo TXT, con el fin de poder

tomarlo como template para futuras implementaciones. Los ejemplos a mostrar son

para la implantacin de transacciones con y sin carpeta.

Esqueleto de archivo TXT con transaccin en carpeta:

FORMAT 1.2B

NODE 000030000100001FOLDER

TEXT 00003ENAdministration of role

NODE 000060000300003TRANSACTION PFCG

TEXT 00006ENProfile Generator

El archivo esta compuesto en este caso, por cinco (5) lneas. La primera de

ellas, cumple la funcin de cabecera del archivo. Algo que no nos aporta mucho, pero

que el sistema interpreta.

La segunda lnea, denominada NODE, cumple la funcin tal como su

denominacin lo dice NODO, pasndole cuatro parmetros. El primero, es el ID por

el cual va a tener nombre la carpeta, el segundo y tercero indica el nodo predecesor, y

el cuarto indica que tipo de nodo ser. Veamos como funciona:

NODE 00003 00001 00001 FOLDER - Esta linea marca los cuatro parmetros que comentaba anteriormente.

Pgina 20 de 49

El primero de ellos (00003) es el ID con el que llamara a la etiqueta TEXT.

Luego, aparecen dos grupos de parmetros (00001 00001) donde nos muestra la hoja

o el nodo padre, en este caso: FORMAT 1.2B.

El cuarto parmetro denominado FOLDER, nos indica que el nodo ser una

carpeta que contendr una o un grupo de transacciones.

TEXT 00003 EN Administration of role indica que se trata de una etiqueta 00003 es el ID de la etiqueta, llamada desde el nodo FOLDER, EN indica el idioma

con el que estamos trabajando (podra contener mltiples lneas con el mismo ID pero

diferente identificador de idioma), y Administration of role, indica el nombre de la

carpeta.

NODE 00006 00003 00003 TRANSACTION PFCG indica un nuevo nodo que tiene como padre al 00003. Vale decir, que este nodo estar por debajo del nodo

FOLDER con una jerarqua menor. Pero este nodo es del tipo TRANSACTION, con lo

que deberemos indicarle un nuevo parmetro, que en nuestro caso es PFCG. Si lo pasamos en limpio, tendremos una transaccin (PFCG) dentro de la carpeta ADMINISTRATION OF ROLE. Lo nico que resta es la etiqueta TEXT para

identificar la transaccin. Se los dejo para que lo hagan ustedes. Procuren no copiarse

del ejemplo anterior.

En la figura 15 veremos el proceso de finalizado.

Figura 15

3.1.4 Solapa AUTORIZATIONS

Pgina 21 de 49

Ahora, siguiendo en la transaccin PFCG, veamos la solapa

AUTHORIZATIONS.

En esta solapa vamos a configurar las autorizaciones que tendr el usuario o el

grupo de usuarios para las transacciones que existen en el men. En primera

instancia, observaremos como se compone la solapa y luego iremos a la configuracin

propiamente dicha. En la figura 16 tenemos una visin de la misma.

Figura 16

Como podemos apreciar, esta pantalla nos es mas que informativa. Tenemos

datos como:

1. Creador de la autorizacin (No del GA)

2. Ultimo usuario que ha realizado un cambio

3. Nombre del perfil

4. Status (Generado, Necesita Ajuste, etc.)

5. Botn de modificacin de autorizaciones.

Configuremos las autorizaciones. En las siguientes figuras veremos la

configuracin de las autorizaciones, pasando por los niveles organizacionales, estados

de los objetos y significado de las actividades ms relevantes.

Pgina 22 de 49

3.1.5 Niveles Organizacionales

Los niveles organizacionales componen una parte fundamental del sistema

SAP. Los mismos, son parametrizados post instalacin del sistema acorde a los

mdulos solicitados.

Estos valores son permanentes en el sistema, y como decamos anteriormente,

se definen a media de que se parametriza el modulo, que no quiere decir que en el

futuro no puedas ser agregados, modificados o borrados.

El sistema viene con niveles organizacionales por defecto, que si bien nunca

son utilizados, para este curso nos servirn de ejemplo. En la siguiente pantalla,

veremos que los niveles organizacionales aun no fueron configurados. En este tipo de

situaciones, el sistema arroja la siguiente pantalla como ilustra la figura 17.

Figura 17

El smbolo , significa MATCH CODE, si lo pulsamos, no traer todos los

datos relacionados con el campo a completar. En este caso, el campo a desplegar es

el de COMPANY CODE, tal como ilustra la figura 18.

Pgina 23 de 49

Figura 18

En esta pantalla, seleccionaremos aquellas compaas o sociedades que

debemos asignar al GA.

En la figura 19, observaremos los distintos estados de los objetos de

autorizacin. Esta nomenclatura es fundamental tenerla presente a la hora de trabajar

con GAs dado que el status nos indica a primera vista, que datos nos estn faltando.

Figura 19

Si observamos con detenimiento, el semforo general se encuentra en ROJO,

y los que estn en el rbol poseen dos estados, ROJO y AMARILLO. Vemos de qu

se tratan estos estados.

- Significa que estn faltando valores ORGANIZACIONALES (Figura 17)

Pgina 24 de 49

- Significa que estn faltando valores NO ORGANIZACIONALES, tales como por ejemplo: ACTIVIDAD.

- Significa que los valores para el objeto estn completos.

Ahora pasemos a ver los objetos desplegados. En ellos encontraremos una

serie de valores a cargar segn las tares que se hayan definido para el grupo de

actividad (GA). En la figura 20, veremos lo explicado en detalle.

Figura 20

Observemos que los desplegados son los que estn en AMARILLO y uno

VERDE. Cada uno de estos objetos esta faltante de datos, pero es como SAP

presenta de forma Standard. Si nos remitimos a la figura 19 podremos ver lo

antedicho.

Cuando se realiza la modificacin de un objeto, el mismo cambiara este status,

ya que se estara violando el Standard SAP. El nuevo status del objeto y grupo de

objetos para a ser MAINTAINED. Veamos la figura 21.

Pgina 25 de 49

Figura 21

Si observan con detenimiento, el primer grupo de objetos figura en

MAINTAINED dado que en el interior del mismo, se ha modificado un objeto. En la

figura 22 vemos este grupo de objetos desplegado.

Figura 22

En algunos casos, los objetos de autorizacin que figuran en nuestro GA, no

son suficientes para que la transaccin ejecutada cumpla con el espectro funcional

que se desea. En estos casos, se debern incorporar de forma manual, aquellos

objetos solicitados por el sistema, tanto por un reporte SU53 o en su defecto, a travs

de un trace (ST01).

Cuando insertamos un nuevo objeto manualmente, el mismo presenta el status

MANUALLY. Esto quiere decir que debido a un incidente o por anlisis surgi que el

objeto debera estar en el GA que estamos modificando.

En la figura 23 veremos como se ve el grupo de objetos al que le hemos

agregado un objeto.

Pgina 26 de 49

Figura 23

En la figura 24 veremos el grupo de objeto FI desplegado para ver que objeto

fue incorporado al GA.

Figura 24

Como vemos, el objeto agregado manualmente figura como tal, pero el grupo

de objetos figura igual. Esto es muy interesante ya que a primera vista podremos

observar si alguien hizo modificaciones manuales. Este status no es ms que una

insercin de un objeto y el mismo, no ocasiona ningn problema. Lo unico que

debemos tener en cuenta, es que el objeto a insertar, no genere conflictos funcionales

o por contraposicin de funciones.

Un ejemplo muy utilizado es el objeto F_BKPF_BUP, o los objetos de

generacin de ordenes de compra con los de liberacin de la misma.

Una vez cargado todos los datos de autorizacin, los semforos se

posicionaran en color verde. Esto conlleva a generar la autorizacin y a posteriori,

asignarlo al usuario correspondiente. En la figura 25 vemos el grupo de objetos

cargados.

Pgina 27 de 49

Figura 25

En la figura 25, vemos todos los grupos de objetos con sus datos cargados, lo

que restara, es generar el GA. En la cabecera de la imagen, el Status del GA es

CHANGED, luego de seleccionar el botn . En la figura 26, vemos el cambio en el

status cuando se ha seleccionado el botn GENERAR.

Figura 26

Si nos remitimos a la pantalla superior, veremos que el semforo de

autorizacin figura en verde, tal como lo ilustra la figura 27.

Figura 27

Pgina 28 de 49

3.1.6 Solapa USERS

3.1.6.1 Asignacin de usuario

En la siguiente pantalla, asignaremos el GA construido al usuario que

corresponda. Para ello, solo bastara con insertar un usuario ya conocido, o

seleccionarlo desde el Match Code. En la figura 28, vemos el front end de la misma.

Figura 28

Cuando desconocemos al usuario, debemos seleccionar el botn del Match

Code para seleccionar el usuario al que deseamos incorporar el nuevo GA. En la

figura 29 vemos el resultado de la bsqueda.

Figura 29

En este caso, al tratarse de un sistema recientemente instalado, solo contamos

con dos usuarios, uno de los cuales es para los transportes entre sistemas.

Pgina 29 de 49

En la pantalla de la figura 29, seleccionaremos el usuario HROSSI, y luego

aceptaremos con el botn .

En la figura 30 veremos los resultados de transaccin. Prestar atencin al

botn y al semforo de la solapa . Estos

indicadores nos hacen ver que el maestro de usuarios esta desajustado. Para que el

mismo quede en verde, debemos presionar el botn antes mencionado. Veamos en la

figura 31 el resultado de la accin.

Figura 30

El usuario quedo ajustado, y el GA esta listo para ser utilizado.

Si observamos con detenimiento, los usuarios que son asignados a un GA

tienen fecha de inicio y vencimiento del mismo. SAP por defecto, pone como fecha

limite el 31.12.9999. Esta fecha puede ser modificada a los fines procedimentales.

Cuando se hace una modificacin en el vencimiento de un GA, el maestro de

usuarios queda inconsistente, y el mismo deber ser ajustado nuevamente para que el

mismo este operacional.

En la figura 31, vemos el cambio de vencimiento del usuario HROSSI para el

GA PRUEBA.

Pgina 30 de 49

Figura 31

3.1.6.2 Desafectar usuario de un GA

En este punto, veremos como desasignar un usuario del GA prueba. En la figura

32, seleccionaremos el usuario HROSSI para su posterior remocin del GA.

Figura 32

En el paso 1, seleccionamos el usuario que queremos eliminar, luego

procedemos al punto 2, para la efectivizacion de la eliminacin. Luego, como ilustra la

figura 33, veremos que el maestro de usuarios queda desajustado. El procedimiento

de ajuste lo hemos visto anteriormente.

Pgina 31 de 49

Figura 33

3.1.6.3 Desafectar usuarios de un GA en modo masivo

Este procedimiento es similar al anterior, con la salvedad de que se hace un

borrado masivo de usuarios del GA.

Para ello, seguiremos una serie de pasos que veremos en la figura 34.

Figura 34

El paso 1, se seleccionan todas las filas en un solo paso, luego en el paso 2, el

procedimiento es similar al punto anterior.

Pgina 32 de 49

3.1.6.4 Datos bsicos de usuario

En la solapa USER, existe un botn poco utilizado, pero que en algunas

oportunidades suele ser til para verificar los datos del usuario tratado. En este caso,

el botn en cuestin es , donde con el mismo, con previa seleccin de un usuario

(Figura 32), podremos ver los datos bsicos del mismo. En la figura 35, se ilustra una

pantalla modelo.

Figura 35

Esta pantalla como podemos ver, solo es de modo informativa, sin poder

realizar modificaciones sobre ella.

Pgina 33 de 49

3.1.7 GA - Derivado

En esta seccin del documento, veremos como, a partir de un GA SIMPLE,

construiremos un GA derivado.

Para que sirve derivar? La respuesta es sencilla. Si nos remitimos al principio

de la teora de objetos (POO), el mismo tiene entre varias caractersticas, la de

reutilizacin. Vale decir, que si creamos un GA padre con X transacciones, luego

podremos derivar al mismo por el valor de autorizacin que consideremos critico o

indispensable. Un ejemplo muy utilizado, es el de derivar por CENTRO, DIVISION,

SOCIEDAD, etc.

Como vimos anteriormente, los GAD solo contendrn las autorizaciones, vale

decir, que el GA padre, tendr todas las transacciones que constituirn el GA

completo.

Vayamos a la construccin de uno de ellos a partir del GA PRUEBA creado

anteriormente. En la figura 37, veremos una nueva funcionalidad para crear los GAD.

Figura 37

Prestemos mucha atencin a:

Pgina 34 de 49

1. El GAD se lo denomino PRUEBA_GRAL.

2. No tiene transacciones ni autorizaciones.

3. Aun no fue asignado a ningn usuario.

Veamos que en la figura 37, hay un campo denominado DERIVE FROM ROLE,

donde el mismo esta claramente marcado con un ovalo rojo. En este campo, debemos

indicar el GA padre que ser el que sedera las transacciones. En la figura 38, vemos lo

que estamos describiendo.

Figura 38

En la figura 39, veamos que las transacciones son heredadas del GA padre.

Las misma no pueden ser eliminadas ni modificadas ya que el owner de las misma, es

el GA padre.

Pgina 35 de 49

Figura 39

En las solapas AUTHORIZATIONS y USER, el procedimiento es igual al

explicado en los puntos 3.1.3 y 3.1.5.

3.1.7.1 Modificacin de un GAD

Cuando realizamos la modificacin de un GA, el GAD sufre un desajuste de

autorizaciones ya que las modificaciones siempre impactan en orden jerrquico. Estas

modificaciones contemplan, Altas y Bajas de transacciones. En la figura 40, veremos

el GAD con todas sus solapas en verde, luego, en la figura 41, modificaremos el GA

PRUEBA sacando una transaccin (VA02). En la figura 42, volveremos al GAD

PRUEBA_GRAL, y veremos el desajuste que mencionamos anteriormente, donde la

solapa AUTHORIZATIONS aparecer en rojo y la USER en AMARILLO.

Estos estados se dan de la siguiente forma, AUTHORIZATIONS en ROJO

significa que el perfil deber ser generado nuevamente, y USER en AMARILLO que el

maestro de usuarios esta desajustado. El procedimiento de generacin y ajuste de

maestro de usuarios los vimos anteriormente.

Pgina 36 de 49

Figura 40

Figura 41

Pgina 37 de 49

Figura 42

3.1.7.2 Autorizaciones distribuidas

Como anteriormente vimos, las autorizaciones solo deban estar en el GAD,

pero existe una alternativa a la hora de crear GAD cuyos valores de autorizacin que

no sean organizacionales no varen.

Este caso se presenta especialmente cuando creamos GAD, cuya limitacin se

presenta a la hora de fijar el marco de trabajo a uno o varios valores organizacionales.

Este caso lo podemos relacionar rpidamente si les pusiera como ejemplo que el GA

es PRUEBA y los GAD son PRUEBA_0001, PRUEBA_0002, etc. Donde

XXXXXX_0001 es la ORGANIZACIN DE COMPRAS.

Veamos un caso prctico, donde los GAD ya estn creados y solo resta

configurar las autorizaciones. En las figuras 42 y 43 veremos los GAD con variante en

la ORGANIZACIN DE COMPRAS.

Pgina 38 de 49

Figura 42

Figura 43

Noten, que la diferencia entre la figura 42 y 43 es el nombre del GAD. Ahora,

trabajaremos en las autorizaciones del GA PRUEBA, figura 44.

Pgina 39 de 49

Figura 44

Como podemos ver, los semforos verdes indican que los valores solicitados

fueron cargados, mientras que los que estn en rojo indican que los niveles

organizacionales no fueron ingresados. Estos ltimos, sern ingresados en los GAD.

Primero, debemos pasar las autorizaciones configuradas en el GA a los GAD,

para ello, debemos utilizar una herramienta a la cual no hemos hecho referencia aun.

En la figura 45 realizamos dicha configuracin. El botn que realiza esta operacin es

Figura 45

Pgina 40 de 49

Como indica el crculo rojo de la figura 45, el botn hereda las autorizaciones

(SOLO LAS NO ORGANIZACIONALES) del GA al GAD. Ahora, veamos por ejemplo a

GAD PRUEBA_0001 en la figura 46.

Figura 46

Veamos, que el GAD sin que los hayamos configurado, ya posee

autorizaciones. Las misma vienen derivadas del GA padre quien posee las

autorizaciones NO ORGANIZACIONALES. Lo que restara ahora, es configurar la

variante para este GAD (Niveles Organizacionales). En la figura 47 veremos el

resultado de la configuracin.

Figura 47

Pgina 41 de 49

Observemos, que las autorizaciones organizacionales han completado la

totalidad de las configuraciones del GAD. Ahora, el GAD PRUEBA_0001 ser limitado

a la organizacin de compras 0001, este es el concepto puro de una variante.

3.1.7.3 Problemas en las Autorizaciones

En algunos casos, cuando se realizan mantenimientos en los GA, es posible

que los objetos se dupliquen generando grandes problemas. Uno de ellos puede ser el

de sumar actividades que no sean requeridas en el GA, o que valores estndar del

objeto agregado, traiga consecuencias inimaginables en la operatoria de los usuarios.

Un caso muy comn, es el duplicado del objeto que administra jobs, el mismo trae el

Y en el nico campo que tiene para completar. Esta Y trae como consecuencia que

los usuarios puedan administrar los jobs del sistema.

En las figuras 48 y 49, veremos los casos de los objetos duplicados.

Figura 48

En la figura 48, lo nico que podemos identificar, es que hay objetos nuevos en

el GAD, ahora, si observamos bien, hay objetos nuevos que figuran como

MAINTAINED. Esto, en condiciones normales, suena muy extrao, que por ser nuevo

no debera estar mantenido. Veamos la figura 49, donde este status se aclarara.

Pgina 42 de 49

Figura 49

Si observamos, los objetos F_BKPK_BED y F_BKPF_BEK, estn duplicados,

quedando en este caso en amarillo. El ID que figura a la derecha del objeto (T-

DV300), se refiere a la autorizacin asignada al objeto. Veamos, que tanto el BEK

como el BED terminan en 700 y 701. Esto quiere decir, que se ha sumado uno al

existente (700).

Veamos entonces como resolver este problema, ya que de ninguna manera

puede quedar duplicado, salvo raras excepciones. En la figura 50, se resolver este

problema. El mismo, ser atendido con el botn .

Figura 50

Pgina 43 de 49

Veamos que los objetos inhabilitados son los que aparecen en la parte superior

en la jerarqua de objetos. Siempre debe ser de esta manera, ya que, cuando SAP

quiere insertar un nuevo objeto, chequea que el mismo este activo, de lo contrario

omite el agregado del mismo.

Cuando un nuevo objeto se agrega al grupo de objetos, los mismos se

identifican como NEW (NUEVO). En la figura 51, veremos un caso prctico de esta

situacin.

Figura 51

Veamos, que tanto el grupo de objetos como el objeto propiamente dicho,

figuran como NEW. En el grupo de objetos, si bien hay objetos OLD, lo que pretende

es advertir de la incorporacin que hay nuevos elementos que debern ser revisados.

Pgina 44 de 49

3.1.7.4 Otras funciones

La transaccin PFCG posee innumerables funciones para realizar operatorias

de apoyo, no obstante, no remitiremos a las funciones mas usadas dentro de las que

no hemos visto. A continuacin, iremos listando los controles a los que haremos

mencin de su funcionabilidad.

Este botn tiene como funcin mostrar todos los objetos del

sistema agrupados por su categora. De aqu, seleccionaremos el objeto que

deseamos y luego ser aadido al GA en modificacin. Veamos un ejemplo en la

figura 52.

Figura 52

Los grupos de objetos estn sealizados con el signo (+), mientras que cuando

los desplegamos quedan con el signo (-). Luego, vemos a los objetos con un

smbolo , esto quiere decir que el mismo no fue seleccionado aun. En el caso de que

lo seleccionemos, el mismo quedara con el smbolo , lo que indica que este objeto

ser aadido al GA en modificacin.

Esta funcin se utiliza cuando no tenemos forma de encontrar un error, para

solucionar el mismo, debemos acudir a este men y aplicar lgica procedimental.

Pgina 45 de 49

Este botn tiene como funcin, el agregado de objetos de forma manual.

Para utilizar dicha funcin, debemos tener bien en claro, que objeto se debe agregar o

por medio de un reporte, que nos dar la informacin precisa del objeto a aadir.

Estos botones cumplen similares

funciones, pero como su nombre dice, OPEN, despliega todos los nodos de las

autorizaciones, NEW, despliega el grupo de objetos (NEW), CHANGED, despliega el

grupo de objetos modificado, MAINTAINED, despliega el grupo de objetos cuyos

valores de autorizacin fueron cargados en los niveles organizacionales.

Pgina 46 de 49

3.2-SU53

La transaccin SU53, es de suma utilidad a la hora de investigar los problemas

de seguridad de los usuarios. El mismo, genera un reporte con el ltimo evento

generado por el usuario, vale decir, que si un usuario ejecuta una transaccin que no

tiene asignada, el sistema arrojara un mensaje de error informando que no posee

autorizacin para ejecutar dicha transaccin.

3.2.1 Ejecutando SU53 para transacciones

Lo primero que debemos hacer antes que nada, es generar un error para ver

como el sistema genera el reporte. Para ello, ejecutaremos una transaccin que no

esta asignada al GAD que tiene el usuario. En la figura 53 veremos este

procedimiento.

Figura 53

Pgina 47 de 49

Como vemos en la figura 53, la transaccin que se ejecuto y a la que no tuvo

acceso en la MK01. Este, seria el caso ms sencillo dentro de los errores de

autorizacin. En la figura 54, veremos el reporte que genera la transaccin SU53, para

ello, debemos ejecutar la misma inmediatamente que el sistema arroja el error. En

este caso, podemos ejecutarla directamente, pero en el caso de que estemos dentro

de una transaccin y ocurra un error de autorizacin, a la misma se deber anteponer

el cdigo /N /O.

Figura 54

En la primer seccin del reporte, nos indica que autorizacin esta haciendo

falta. En este caso, solicita para la clase de objeto AAAB, el objeto S_TCODE, el valor

MK01.

Pgina 48 de 49

En este caso, el valor MK01, no debe ser cargado a mano en el objeto ya que

en los mismos se contemplan variables. Si llegramos a modificar manualmente este

campo, cada vez que agreguemos una transaccin por men, la misma, no ser

cargada en el campo del objeto S_TCODE. Lo mismo sucede, si lo que estamos

modificando manualmente es un Nivel Organizacional. Mas adelante veremos este

caso.

3.2.2 Ejecutando SU53 para autorizaciones

Como vimos anteriormente, el concepto de autorizacin va de la mano de las

transacciones que tenga el o los GADs asignados a un usuario. Ahora, simularemos

un error de autorizacin dentro de una transaccin. En la figura 55, veremos el

mensaje de error dentro de una transaccin.

Figura 55

Pgina 49 de 49

En la figura 56 veremos el reporte que genera la transaccin SU53 respecto de

este error.

Figura 56

Este error, debe ser tratado desde los niveles organizacionales del GA

asignado al usuario, ya que el CODIGO de COMPAA esta sujeto a una variable

igual que el campo de la S_TCODE. En este caso, el objeto que esta solicitando el

valor 0001 es el F_BKPK_BUK, cuya actividad es correcta, pero el campo restante

solo tiene seteado AR01 faltando 0001.