SEGURIDAD SAP R/3

Pgina 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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 15 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 16 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 17 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 18 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 19 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 20 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 21 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 22 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 23 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 24 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 25 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 26 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 27 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 28 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 29 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 30 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 31 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 32 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 33 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 34 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 35 de 49
 Figura 40

Figura 41

Pgina 36 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 37 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 38 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 39 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 40 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 41 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 42 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 43 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 44 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 45 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 46 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 47 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 48 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.

Pgina 49 de 49