Guía del administrador - IBMpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4684-00/es... ·...

306
IBM Tivoli Access Manager Base Guía del administrador Versión 3.9 GC10-3838-00

Transcript of Guía del administrador - IBMpublib.boulder.ibm.com/tividd/td/ITAME/GC23-4684-00/es... ·...

IBM Tivoli Access Manager Base

Guía del administradorVersión 3.9

GC10-3838-00

IBM Tivoli Access Manager Base

Guía del administradorVersión 3.9

GC10-3838-00

NotaAntes de utilizar esta información y el producto al que da soporte, lea la información del Apéndice H, “Avisos” en lapágina 273.

Primera edición (abril de 2002)

Este manual es la traducción del original inglés IBM Tivoli Access Manager Base Administrator’s Guide Version 3.9 ,GC23-4684-00.

©Copyright Sun Microsystems, Inc. 1999

© Copyright International Business Machines Corporation 2002. Reservados todos los derechos. Nota sobre derechosrestringidos para los usuarios del Gobierno de Estados Unidos: la utilización, duplicación o divulgación quedanrestringidos por el GSA ADP Schedule Contract con IBM Corp.

Contenido

Prefacio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiA quién va dirigido este manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiContenido de este manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiPublicaciones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii

IBM Tivoli Access Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiiPublicaciones relacionadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvAcceso a las publicaciones en línea . . . . . . . . . . . . . . . . . . . . . . . . . . xviSolicitud de publicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviiComentarios sobre las publicaciones . . . . . . . . . . . . . . . . . . . . . . . . . xvii

Accesibilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviiiCómo ponerse en contacto con el soporte al cliente . . . . . . . . . . . . . . . . . . . . . xviiiConvenios utilizados en este manual . . . . . . . . . . . . . . . . . . . . . . . . . . xviii

Convenios tipográficos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviii

Capítulo 1. Visión general de Access Manager . . . . . . . . . . . . . . . . . . . 1Seguridad de la red empresarial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Seguridad en la red — aspectos comunes . . . . . . . . . . . . . . . . . . . . . . . . . 2Conceptos básicos de Access Manager . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Access Manager — tecnología básica . . . . . . . . . . . . . . . . . . . . . . . . . . . 3Autenticación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3Autorización . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4Calidad de protección (de datos). . . . . . . . . . . . . . . . . . . . . . . . . . . . 4Escalabilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4Responsabilidad de gestión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Gestión centralizada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Conceptos de autorización: modelo conceptual . . . . . . . . . . . . . . . . . . . . . . . . 5Las ventajas de un servicio de autorizaciones estándar . . . . . . . . . . . . . . . . . . . . 6Conceptos básicos del servicio de autorizaciones de Access Manager . . . . . . . . . . . . . . . 7

El servicio de autorizaciones de Access Manager . . . . . . . . . . . . . . . . . . . . . . . 8Componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Interfaces del servicio de autorizaciones . . . . . . . . . . . . . . . . . . . . . . . . . 9Réplica de escalabilidad y rendimiento . . . . . . . . . . . . . . . . . . . . . . . . . 10

Implementación de una política de seguridad de red . . . . . . . . . . . . . . . . . . . . . 11Definición de la política de seguridad de la red . . . . . . . . . . . . . . . . . . . . . . 12El espacio de objetos protegidos . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Definición y aplicación de políticas de ACL y POP . . . . . . . . . . . . . . . . . . . . . 13Administración de políticas: Web Portal Manager. . . . . . . . . . . . . . . . . . . . . . 15El proceso de autorización: paso a paso . . . . . . . . . . . . . . . . . . . . . . . . . 16

La API de autorización de Access Manager . . . . . . . . . . . . . . . . . . . . . . . . . 17Dos ejemplos de utilización de la API de autorización . . . . . . . . . . . . . . . . . . . . 18API de autorización: modalidad de caché remota . . . . . . . . . . . . . . . . . . . . . . 19API de autorización: modalidad de caché local . . . . . . . . . . . . . . . . . . . . . . 20

Posibilidad de autorización externa . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Ampliación del servicio de autorizaciones . . . . . . . . . . . . . . . . . . . . . . . . 21Imposición de condiciones en peticiones de recursos. . . . . . . . . . . . . . . . . . . . . 22El proceso de evaluación de autorización . . . . . . . . . . . . . . . . . . . . . . . . 22Implementación de un servicio de autorizaciones externo . . . . . . . . . . . . . . . . . . . 24Estrategias de despliegue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Gestión de certificados y contraseñas de Access Manager Base . . . . . . . . . . . . . . . . . . 25Configuración inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Información sobre la renovación del archivo de base de datos de conjunto de claves y del archivo stash . . . 27Determinación de confianza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Revocación de certificados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Consideraciones adicionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

iii

Capítulo 2. Gestión del espacio de objetos protegidos . . . . . . . . . . . . . . . 31Conceptos del espacio de objetos protegidos . . . . . . . . . . . . . . . . . . . . . . . . 31

Elementos del espacio de objetos protegidos . . . . . . . . . . . . . . . . . . . . . . . 31Jerarquía de espacio de objetos protegidos . . . . . . . . . . . . . . . . . . . . . . . . 32Espacio de objetos definidos por el usuario para aplicaciones de terceros . . . . . . . . . . . . . . 33

Definición de un espacio de objetos de base de datos . . . . . . . . . . . . . . . . . . . . . 34Creación de un objeto contenedor nuevo definido por el usuario . . . . . . . . . . . . . . . . 34Creación y supresión de objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Capítulo 3. Utilización de políticas de control de accesos . . . . . . . . . . . . . . 37Conceptos básicos de la política de ACL. . . . . . . . . . . . . . . . . . . . . . . . . . 37

Entradas de política de ACL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Creación y gestión de políticas de ACL . . . . . . . . . . . . . . . . . . . . . . . . . 38

Sintaxis de entrada de ACL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39Atributo de tipo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39Atributo de ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Atributo de permisos (acciones) . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Permisos (acciones) de Access Manager predeterminados . . . . . . . . . . . . . . . . . . . 41

Cómo el servicio de autorizaciones utiliza políticas de ACL . . . . . . . . . . . . . . . . . . . 41Realización de operaciones en un objeto . . . . . . . . . . . . . . . . . . . . . . . . . 42Requisitos para permisos personalizados . . . . . . . . . . . . . . . . . . . . . . . . 42Ejemplo de acción personalizada . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Evaluación de una ACL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43Evaluación de peticiones autenticadas . . . . . . . . . . . . . . . . . . . . . . . . . 43Evaluación de peticiones no autenticadas . . . . . . . . . . . . . . . . . . . . . . . . 44Ejemplo de entradas de ACL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Modelo de ACL esparcida: herencia de ACL . . . . . . . . . . . . . . . . . . . . . . . . 44Conceptos del modelo de ACL esparcida . . . . . . . . . . . . . . . . . . . . . . . . 44La política de ACL raíz predeterminada . . . . . . . . . . . . . . . . . . . . . . . . . 45Permiso traverse. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Resolución de una petición de acceso . . . . . . . . . . . . . . . . . . . . . . . . . . 46Aplicación de políticas de ACL en diferentes tipos de objeto . . . . . . . . . . . . . . . . . . 47Ejemplo de herencia de política de ACL . . . . . . . . . . . . . . . . . . . . . . . . . 48Directrices para un espacio de objetos seguros . . . . . . . . . . . . . . . . . . . . . . . 48

Creación de acciones y grupos de acciones de ACL ampliados . . . . . . . . . . . . . . . . . . 49Creación de un grupo de acciones nuevo . . . . . . . . . . . . . . . . . . . . . . . . 50Creación de acciones nuevas en un grupo de acciones . . . . . . . . . . . . . . . . . . . . 50Especificación de acciones personalizadas en entradas de ACL . . . . . . . . . . . . . . . . . 51

Políticas de ACL y espacio de objetos protegidos . . . . . . . . . . . . . . . . . . . . . . . 52Objeto contenedor raíz ( / ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52El permiso traverse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Permisos WebSEAL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52/WebSEAL/host. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53/WebSEAL/host/file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53Permisos WebSEAL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Permisos de gestión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53Permisos /Management/ACL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54Permisos /Management/Action . . . . . . . . . . . . . . . . . . . . . . . . . . . 55Permisos /Management/POP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55Permisos /Management/Server . . . . . . . . . . . . . . . . . . . . . . . . . . . 56Permisos /Management/Config . . . . . . . . . . . . . . . . . . . . . . . . . . . 56Permisos /Management/Policy. . . . . . . . . . . . . . . . . . . . . . . . . . . . 57Permisos /Management/Replica . . . . . . . . . . . . . . . . . . . . . . . . . . . 57Permisos /Management/Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58Permisos /Management/Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . 58Permisos /Management/GSO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Permisos de objeto y espacio de objetos . . . . . . . . . . . . . . . . . . . . . . . . . . 60Políticas de ACL de administración predeterminadas . . . . . . . . . . . . . . . . . . . . . 60

Política de ACL raíz predeterminada . . . . . . . . . . . . . . . . . . . . . . . . . . 60Política de ACL de /WebSEAL predeterminada . . . . . . . . . . . . . . . . . . . . . . 61Política de ACL de /Management predeterminada . . . . . . . . . . . . . . . . . . . . . 61

iv IBM Tivoli Access Manager Base: Guía del administrador

Política de ACL de /Replica predeterminada . . . . . . . . . . . . . . . . . . . . . . . 61Política de ACL de /Config predeterminada . . . . . . . . . . . . . . . . . . . . . . . 61Política de ACL de /GSO predeterminada . . . . . . . . . . . . . . . . . . . . . . . . 61Política de ACL de /Policy predeterminada . . . . . . . . . . . . . . . . . . . . . . . 62

Capítulo 4. Utilización de políticas de objetos protegidos . . . . . . . . . . . . . . 63Conceptos básicos de la política de objetos protegidos (POP) . . . . . . . . . . . . . . . . . . . 63

Notas de POP: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64Creación y supresión de políticas de objetos protegidos. . . . . . . . . . . . . . . . . . . . 64Aplicación de atributos de POP a objetos protegidos. . . . . . . . . . . . . . . . . . . . . 65

Configuración de atributos de POP . . . . . . . . . . . . . . . . . . . . . . . . . . . 66Atributo de modalidad de aviso . . . . . . . . . . . . . . . . . . . . . . . . . . . 66Atributo de nivel de auditoría . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66Atributo de hora del día . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Política POP de intensidad de la autenticación (incremental) . . . . . . . . . . . . . . . . . . . 67Configuración de niveles de autenticación incremental . . . . . . . . . . . . . . . . . . . . 68Aplicación de una política de autenticación incremental . . . . . . . . . . . . . . . . . . . 69Algoritmo de autenticación incremental . . . . . . . . . . . . . . . . . . . . . . . . . 69Cómo distinguir la autenticación incremental de la autenticación de varios factores . . . . . . . . . . 70

Política POP de autenticación basada en la red . . . . . . . . . . . . . . . . . . . . . . . 71Especificación de direcciones y rangos IP . . . . . . . . . . . . . . . . . . . . . . . . 71Inhabilitación de la autenticación incremental por dirección IP . . . . . . . . . . . . . . . . . 72Algoritmo de autenticación basado en la red . . . . . . . . . . . . . . . . . . . . . . . 72Notas y limitaciones de la autenticación basada en la red . . . . . . . . . . . . . . . . . . . 72

Política POP de calidad de protección . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Capítulo 5. Utilización de Web Portal Manager . . . . . . . . . . . . . . . . . . . 75Delegación de administración mediante Web Portal Manager . . . . . . . . . . . . . . . . . . . 75

Delegación de la administración de roles . . . . . . . . . . . . . . . . . . . . . . . . 77Ejemplo de registro automático . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Capítulo 6. Delegación de tareas de administración . . . . . . . . . . . . . . . . 81Delegación de la gestión del espacio de objetos . . . . . . . . . . . . . . . . . . . . . . . 81

Estructuración del espacio de objetos para la delegación de la gestión . . . . . . . . . . . . . . . 81Usuarios y grupos de administración predeterminados . . . . . . . . . . . . . . . . . . . . 82Creación de usuarios de administración . . . . . . . . . . . . . . . . . . . . . . . . . 83Ejemplo de plantillas de ACL de administración . . . . . . . . . . . . . . . . . . . . . . 84Ejemplo de delegación de la gestión . . . . . . . . . . . . . . . . . . . . . . . . . . 84

Delegación de la gestión de grupos . . . . . . . . . . . . . . . . . . . . . . . . . . . 85Creación de objetos contenedor de grupos . . . . . . . . . . . . . . . . . . . . . . . . 86Creación de grupos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87Políticas de ACL que afectan a la gestión de grupos . . . . . . . . . . . . . . . . . . . . . 88Políticas de ACL que afectan a la gestión de usuarios . . . . . . . . . . . . . . . . . . . . 89

Gestión de política de administración delegada . . . . . . . . . . . . . . . . . . . . . . . 90

Capítulo 7. Gestión de servidores de Access Manager . . . . . . . . . . . . . . . 93Conceptos básicos de los servidores de Access Manager . . . . . . . . . . . . . . . . . . . . 93

Condiciones de servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93Conceptos básicos de las herramientas de administración del servidor . . . . . . . . . . . . . . . 94Archivos de configuración del servidor . . . . . . . . . . . . . . . . . . . . . . . . . 101

Inicio y detención de servidores de Access Manager . . . . . . . . . . . . . . . . . . . . . 102Inicio y detención de servidores en sistemas UNIX . . . . . . . . . . . . . . . . . . . . . 102Inicio y detención de servidores en sistemas Windows . . . . . . . . . . . . . . . . . . . 103

Inicio automático del servidor durante el reinicio . . . . . . . . . . . . . . . . . . . . . . 104Policy Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104Authorization Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

Administración de Policy Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104Réplica de la base de datos de autorizaciones . . . . . . . . . . . . . . . . . . . . . . 105Establecimiento del número de threads del notificador de actualización . . . . . . . . . . . . . . 106Establecimiento del tiempo de espera de la notificación . . . . . . . . . . . . . . . . . . . 107

Contenido v

Capítulo 8. Utilización del registro LDAP . . . . . . . . . . . . . . . . . . . . 109Visión general de LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

LDAP: Un protocolo para servicios de directorio . . . . . . . . . . . . . . . . . . . . . 110Directorios de LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110El modelo de información de LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . 111Características de LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

Configuración de la migración tras error de LDAP . . . . . . . . . . . . . . . . . . . . . . 112El modelo de réplica de maestro-esclavo . . . . . . . . . . . . . . . . . . . . . . . . 113Posibilidad de migración tras error de Access Manager en servidores LDAP . . . . . . . . . . . . 113Configuración del servidor maestro . . . . . . . . . . . . . . . . . . . . . . . . . . 113Configuración del servidor replicado . . . . . . . . . . . . . . . . . . . . . . . . . 114Definición de valores de preferencia para servidores replicados LDAP . . . . . . . . . . . . . . 115Sondeo del servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

Aplicación de ACL de Access Manager a sufijos nuevos de LDAP . . . . . . . . . . . . . . . . . 116Procedimientos en el servidor IBM SecureWay Directory . . . . . . . . . . . . . . . . . . . 117Procedimientos en iPlanet Directory Server . . . . . . . . . . . . . . . . . . . . . . . 119

Capítulo 9. Registro y auditoría de la actividad del servidor . . . . . . . . . . . . 123Conceptos básicos de registro y auditoría . . . . . . . . . . . . . . . . . . . . . . . . . 123

Archivos de seguimiento de auditoría . . . . . . . . . . . . . . . . . . . . . . . . . 123Convenio de documentación: ruta_acceso_instalación . . . . . . . . . . . . . . . . . . . . 123

Registro de mensajes de servicio de Base . . . . . . . . . . . . . . . . . . . . . . . . . 124Archivos de seguimiento de auditoría de Access Manager . . . . . . . . . . . . . . . . . . . 125

Habilitación e inhabilitación de la auditoría . . . . . . . . . . . . . . . . . . . . . . . 126Especificación de la ubicación del archivo de registro . . . . . . . . . . . . . . . . . . . . 126Especificación de umbrales de creación de archivos de auditoría . . . . . . . . . . . . . . . . 127Especificación de la frecuencia para vaciar los búferes de los archivos de auditoría . . . . . . . . . . 127Especificación de eventos de auditoría . . . . . . . . . . . . . . . . . . . . . . . . . 127

Formato del archivo de seguimiento de auditoría . . . . . . . . . . . . . . . . . . . . . . 128Atributo de estado del campo de salida . . . . . . . . . . . . . . . . . . . . . . . . 129Atributo de recurso del campo destino . . . . . . . . . . . . . . . . . . . . . . . . . 130

Contenido del archivo de seguimiento de auditoría. . . . . . . . . . . . . . . . . . . . . . 130Registros de auditoría de autorización . . . . . . . . . . . . . . . . . . . . . . . . . 130Registros de auditoría de autenticación . . . . . . . . . . . . . . . . . . . . . . . . . 131Registros de auditoría de WebSEAL . . . . . . . . . . . . . . . . . . . . . . . . . . 131Registros de auditoría de gestión . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

Capítulo 10. Utilización del registro de eventos . . . . . . . . . . . . . . . . . . 137Concepto de eventos de Access Manager . . . . . . . . . . . . . . . . . . . . . . . . . 137Configuración del registro de eventos . . . . . . . . . . . . . . . . . . . . . . . . . . 138

Configuración de la cola de propagación de eventos central . . . . . . . . . . . . . . . . . . 140Especificación del número máximo de eventos en cola en la memoria . . . . . . . . . . . . . . 140Especificación de la marca de límite superior de la cola de eventos . . . . . . . . . . . . . . . 141Especificación de la frecuencia para vaciar los búferes de los archivos de registro . . . . . . . . . . 141

Registro en consola . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141Registro en archivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

Especificación de la ubicación del archivo de registro . . . . . . . . . . . . . . . . . . . . 142Especificación del ID del archivo de registro . . . . . . . . . . . . . . . . . . . . . . . 142Especificación del tamaño máximo del archivo de registro . . . . . . . . . . . . . . . . . . 143Especificación del tamaño máximo del búfer . . . . . . . . . . . . . . . . . . . . . . . 144Especificación del número máximo de eventos en cola en la memoria . . . . . . . . . . . . . . 144Especificación de la marca de límite superior de la cola de eventos . . . . . . . . . . . . . . . 145Especificación de la frecuencia para vaciar los búferes de los archivos de registro . . . . . . . . . . 145Especificación de la modalidad de archivo. . . . . . . . . . . . . . . . . . . . . . . . 145

Registro en canalización . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146Especificación del programa que se ha de ejecutar . . . . . . . . . . . . . . . . . . . . . 146Especificación del perfil de cola de eventos . . . . . . . . . . . . . . . . . . . . . . . 146

Registro remoto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146Especificación del tamaño máximo del búfer . . . . . . . . . . . . . . . . . . . . . . . 147Especificación de la frecuencia para vaciar el búfer de consolidación . . . . . . . . . . . . . . . 147

vi IBM Tivoli Access Manager Base: Guía del administrador

Especificación de tamaños de cola . . . . . . . . . . . . . . . . . . . . . . . . . . 148Especificación de compresión de mensajes . . . . . . . . . . . . . . . . . . . . . . . . 148Especificación del tiempo de espera de reintento por error . . . . . . . . . . . . . . . . . . 148Especificación de la ubicación del archivo de caché . . . . . . . . . . . . . . . . . . . . . 148Especificación del tiempo de espera de intentos de reenlace . . . . . . . . . . . . . . . . . . 149Especificación del servidor remoto . . . . . . . . . . . . . . . . . . . . . . . . . . 149Especificación del puerto del servidor remoto . . . . . . . . . . . . . . . . . . . . . . 149Especificación del nombre distinguido del servidor remoto . . . . . . . . . . . . . . . . . . 149

Soporte de configuración heredada y otros valores predeterminados . . . . . . . . . . . . . . . . 149Compatibilidad con la configuración de la API de autorización. . . . . . . . . . . . . . . . . 150Registros de peticiones HTTP de WebSEAL . . . . . . . . . . . . . . . . . . . . . . . 150

Búsqueda de las categorías de eventos existentes . . . . . . . . . . . . . . . . . . . . . . 151Supervisión del rendimiento de la cola de registros. . . . . . . . . . . . . . . . . . . . . . 151

Apéndice A. Comandos pdadmin . . . . . . . . . . . . . . . . . . . . . . . . 153Conceptos básicos del programa de utilidad pdadmin . . . . . . . . . . . . . . . . . . . . . 153

Inicio del programa de utilidad pdadmin (comando login) . . . . . . . . . . . . . . . . . . 153Información de ayuda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154Salida del programa de utilidad pdadmin . . . . . . . . . . . . . . . . . . . . . . . . 154Caracteres especiales no permitidos en comandos de GSO . . . . . . . . . . . . . . . . . . 154

Sintaxis de comandos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155acl attach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156acl create . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157acl delete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158acl detach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159acl find . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160acl list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161acl list attribute. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162acl modify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163acl show . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166acl show attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167action create . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168action delete. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169action group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170action list. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171admin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172errtext . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173exit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174group create . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175group delete. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176group import . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177group list. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178group modify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179group show . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182logout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183object create . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184object delete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185object list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186object list attribute. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187object listandshow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188object modify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189object show . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190object show attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191objectspace create . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192objectspace delete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193objectspace list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194policy get . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195policy set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197pop attach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

Contenido vii

pop create . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200pop delete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201pop detach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202pop find . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203pop list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204pop list attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205pop modify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206pop show . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208pop show attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209quit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210rsrc create . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211rsrc delete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212rsrc list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213rsrc show. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214rsrccred create . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215rsrccred delete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216rsrccred list user . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217rsrccred modify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218rsrccred show . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219rsrcgroup create . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220rsrcgroup delete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221rsrcgroup list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222rsrcgroup modify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223rsrcgroup show. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224server list. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225server listtasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226server replicate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227server show . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228server task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229user create . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230user delete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231user import . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232user list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233user modify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234user show . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235

Apéndice B. Información de consulta de wivmgrd.conf . . . . . . . . . . . . . . 237

Apéndice C. Información de consulta de ivacld.conf . . . . . . . . . . . . . . . 241

Apéndice D. Información de consulta de ldap.conf . . . . . . . . . . . . . . . . 245

Apéndice E. Información de consulta de pd.conf . . . . . . . . . . . . . . . . . 247

Apéndice F. Comandos de configuración de SSL . . . . . . . . . . . . . . . . . 249Sintaxis de comandos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249bassslcfg –chgpwd. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250bassslcfg –config . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251bassslcfg –getcacert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252bassslcfg –modify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253bassslcfg –ping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254mgrsslcfg –chgcert. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255mgrsslcfg –chgpwd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256mgrsslcfg –config . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257mgrsslcfg –modify. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258svrsslcfg –add_replica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259svrsslcfg –chg_replica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260svrsslcfg –chgcert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261svrsslcfg –chgport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262svrsslcfg –chgpwd. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263

viii IBM Tivoli Access Manager Base: Guía del administrador

svrsslcfg –config . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264svrsslcfg –modify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266svrsslcfg –rmv_replica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267svrsslcfg –unconfig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268

Apéndice G. Diferencias entre registros de usuarios . . . . . . . . . . . . . . . 269

Apéndice H. Avisos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273Marcas registradas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275

Glosario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277

Índice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281

Contenido ix

x IBM Tivoli Access Manager Base: Guía del administrador

Prefacio

IBM® Tivoli® Access Manager (Access Manager) es el software básico necesariopara ejecutar aplicaciones en la suite de productos. Permite la integración deaplicaciones de Access Manager que proporcionan un amplio rango de solucionesde autorización y gestión. Comercializados como una solución integrada, estosproductos proporcionan una solución de gestión de control de accesos quecentraliza la política de seguridad de redes y aplicaciones para aplicaciones dee-business.

Nota: IBM Tivoli Access Manager es el nuevo nombre del software previamentecomercializado con el nombre de Tivoli SecureWay® Policy Director.Además, para los usuarios familiarizados con el software Tivoli SecureWayPolicy Director y su documentación, el término Management Server ahora hapasado a denominarse Policy Server.

Esta publicación, IBM Tivoli Access Manager Base Guía del administrador, proporcionaun amplio conjunto de procedimientos e información de consulta para gestionarservidores y recursos de Access Manager. También incluye información general yespecífica sobre la gran variedad de funciones de Access.

A quién va dirigido este manualEsta guía está pensada para administradores responsables del despliegue yadministración del software básico de Access Manager.

Los lectores deberían estar familiarizados con:v Sistemas operativos de PC y UNIX®

v Arquitectura y conceptos de base de datosv Gestión de seguridadv Protocolos de Internet, incluidos HTTP, TCP/IP, Protocolo de Transferencia de

Archivos (FTP) y Telnetv Lightweight Directory Access Protocol (LDAP) y servicios de directoriov Autenticación y autorización

Contenido de este manualEsta guía contiene los capítulos siguientes:v Capítulo 1, “Visión general de Access Manager” en la página 1

Muestra conceptos y funciones importantes de Access Manager, como:tecnologías y componentes esenciales de Access Manager, el modelo del serviciode autorizaciones y cómo implementar una política de seguridad.

v Capítulo 2, “Gestión del espacio de objetos protegidos” en la página 31Trata sobre cómo Access Manager utiliza una representación virtual de recursosen un espacio de objetos protegidos. Hay dos tipos de espacios de objetossoportados: archivo plano y base de datos.

v Capítulo 3, “Utilización de políticas de control de accesos” en la página 37Proporciona información completa de consulta sobre las políticas de lista decontrol de accesos (ACL).

xi

v Capítulo 4, “Utilización de políticas de objetos protegidos” en la página 63Proporciona información completa de consulta sobre las políticas de objetosprotegidos (POP).

v Capítulo 5, “Utilización de Web Portal Manager” en la página 75Proporciona información complementaria sobre las tareas proporcionadas en elsistema de ayuda en línea, incluida la delegación de administración y registroautomático. Esta interfaz de usuario web se envía por separado en el CD de IBMTivoli Access Manager Web Portal Manager para plataformas AIX, Solaris yWindows.

v Capítulo 6, “Delegación de tareas de administración” en la página 81Explica cómo Access Manager soporta la gestión delegada del espacio de objetosy la gestión de grupos.

v Capítulo 7, “Gestión de servidores de Access Manager” en la página 93Proporciona información de consulta técnica sombre cómo gestionar ypersonalizar la operación de los servidores de Access Manager.

v Capítulo 8, “Utilización del registro LDAP” en la página 109Muestra el protocolo / directorio de LDAP y proporciona información detalladasobre cómo configurar la migración tras error de LDAP.

v Capítulo 9, “Registro y auditoría de la actividad del servidor” en la página 123Proporciona información completa de consulta sobre las posibilidades de registroy auditoría de Access Manager.

v Apéndice A, “Comandos pdadmin” en la página 153v Apéndice B, “Información de consulta de wivmgrd.conf” en la página 237v Apéndice C, “Información de consulta de ivacld.conf” en la página 241v Apéndice D, “Información de consulta de ldap.conf” en la página 245v Apéndice E, “Información de consulta de pd.conf” en la página 247

PublicacionesEste apartado contiene una lista de publicaciones de la biblioteca de AccessManager y otros documentos relacionados. También describe cómo acceder a laspublicaciones de Tivoli en línea, cómo solicitar publicaciones de Tivoli y cómorealizar comentarios de las publicaciones de Tivoli.

IBM Tivoli Access ManagerLa biblioteca de Access Manager está organizada en las siguientes categorías:v Información del releasev Información de Basev Información de WebSEALv Información de seguridad webv Información de consulta para desarrolladoresv Información técnica complementaria

Las publicaciones de la biblioteca del producto están incluidas en formato PDF(Portable Document Format) en el CD del producto. Para acceder a estaspublicaciones utilizando un navegador web, abra el archivo infocenter.html, quese encuentra en el directorio /doc del CD del producto.

Para obtener fuentes de información adicionales sobre Access Manager y temasrelacionados, visite los siguientes sitios web:

xii IBM Tivoli Access Manager Base: Guía del administrador

http://www.ibm.com/redbookshttps://www.tivoli.com/secure/support/documents/fieldguides

Información del releasev IBM Tivoli Access Manager for e-business Read Me First

GI11-0918 (am39_readme.pdf)Proporciona información sobre la instalación e iniciación al uso de AccessManager.

v IBM Tivoli Access Manager for e-business Release Notes

GI11-0919 (am39_relnotes.pdf)Proporciona información de última hora, como limitaciones de software,soluciones temporales y actualizaciones de la documentación.

Información de Basev IBM Tivoli Access Manager Base Installation Guide

GC32-0844 (am39_install.pdf)Proporciona instrucciones para la instalación, configuración y actualización delsoftware básico de Access Manager, incluida la interfaz de Web Portal Manager.

v IBM Tivoli Access Manager Base Guía del administrador

GC10-3838 (am39_admin.pdf)Describe los conceptos y procedimientos para la utilización de los servicios deAccess Manager. Proporciona instrucciones para realizar tareas desde la interfazde Web Portal Manager y mediante el comando pdadmin.

v IBM Tivoli Access Manager Base for Linux on zSeries™ Installation Guide

GC23-4796 (am39_zinstall.pdf)Describe cómo instalar y configurar Access Manager Base para Linux en laplataforma zSeries.

Información de WebSEALv IBM Tivoli Access Manager WebSEAL Installation Guide

GC32-0848 (amweb39_install.pdf)Proporciona instrucciones para la instalación, configuración y actualización delservidor WebSEAL y del kit de desarrollo de aplicaciones de WebSEAL.

v IBM Tivoli Access Manager WebSEAL Guía del administrador

GC10-3839 (amweb39_admin.pdf)Proporciona material de referencia, procedimientos de administración einformación técnica de consulta sobre la utilización de WebSEAL para gestionarlos recursos de su dominio web seguro.

v IBM Tivoli Access Manager WebSEAL Developer’s Reference

GC23-4683 (amweb39_devref.pdf)Proporciona información de administración y programación para CDAS(Cross-domain Authentication Service), CDMF (Cross-domain MappingFramework) y para el Módulo de intensidad de contraseñas.

v IBM Tivoli Access Manager WebSEAL for Linux on zSeries Installation Guide

GC23-4797 (amweb39_zinstall.pdf)Proporciona instrucciones de instalación, configuración y eliminación delservidor WebSEAL y del kit de desarrollo de aplicaciones WebSEAL para Linuxen la plataforma zSeries.

Prefacio xiii

Información de seguridad webv IBM Tivoli Access Manager for WebSphere Application Server Guía del usuario

GC10-3840 (amwas39_user.pdf)Proporciona instrucciones para la instalación, configuración y administración deAccess Manager para IBM WebSphere® Application Server.

v IBM Tivoli Access Manager for WebLogic Server User’s Guide

GC32-0851 (amwls39_user.pdf)Proporciona instrucciones para la instalación, configuración y administración deAccess Manager para BEA WebLogic Server.

v IBM Tivoli Access Manager Plug-in for Edge Server User’s Guide

GC23-4685 (amedge39_user.pdf)Proporciona instrucciones para la instalación, configuración y administración dela aplicación Plug-in for Edge Server.

v IBM Tivoli Access Manager Plug-in for Web Servers User’s Guide

GC23-4686 (amws39_user.pdf)Proporciona instrucciones para la instalación, configuración y administración delsistema de seguridad del dominio web utilizando la aplicación Plug-in for WebServers.

Material de consulta para desarrolladoresv IBM Tivoli Access Manager Authorization C API Developer’s Reference

GC32-0849 (am39_authC_devref.pdf)Proporciona material de consulta que describe cómo utilizar la API C deautorización de Access Manager y la interfaz de plug-in de servicio de AccessManager para agregar la seguridad de Access Manager a aplicaciones.

v IBM Tivoli Access Manager Authorization Java Classes Developer’s Reference

GC23-4688 (am39_authJ_devref.pdf)Proporciona información de consulta sobre la utilización de la implementaciónen lenguaje Java™ de la API de autorización para permitir que una aplicaciónutilice la seguridad de Access Manager.

v IBM Tivoli Access Manager Administration C API Developer’s Reference

GC32-0843 (am39_adminC_devref.pdf)Proporciona información de consulta sobre la utilización de la API deadministración para permitir que una aplicación pueda realizar tareas deadministración de Access Manager. Este documento describe la implementaciónde C de la API de administración.

v IBM Tivoli Access Manager Administration Java Classes Developer’s Reference

SC32-0842 (am39_adminJ_devref.pdf)Proporciona información de consulta sobre la utilización de la implementaciónen lenguaje Java de la API de administración para permitir que una aplicaciónpueda realizar tareas de administración de Access Manager.

v IBM Tivoli Access Manager WebSEAL Developer’s Reference

GC23-4683 (amweb39_devref.pdf)Proporciona información de administración y programación para CDAS(Cross-domain Authentication Service), CDMF (Cross-domain MappingFramework) y para el Módulo de intensidad de contraseñas.

xiv IBM Tivoli Access Manager Base: Guía del administrador

Información técnica complementariav IBM Tivoli Access Manager Performance Tuning Guide

GC43-0846 (am39_perftune.pdf)Proporciona información de ajuste del rendimiento para un entorno compuestopor Access Manager con IBM SecureWay Directory definido como el registro deusuarios.

v IBM Tivoli Access Manager Capacity Planning Guide

GC32-0847 (am39_capplan.pdf)Proporciona asistencia a los responsables de planificación para determinar elnúmero de servidores web, WebSEAL y LDAP de fondo necesarios paraconseguir la carga de trabajo deseada.

v IBM Tivoli Access Manager Error Message Reference

SC32-0845 (am39_error_ref.pdf)Proporciona explicaciones y acciones recomendadas para los mensajes generadospor Access Manager.

La publicación Tivoli Glossary incluye definiciones de muchos de los términostécnicos relacionados con el software de Tivoli. La publicación Tivoli Glossary estádisponible, sólo en inglés, en el siguiente sitio web:

http://www.tivoli.com/support/documents/glossary/termsm03.htm

Publicaciones relacionadasEste apartado contiene una lista de las publicaciones relacionadas con la bibliotecade Access Manager.

IBM DB2® Universal Database ™

IBM DB2 Universal Database es necesario al instalar los servidores IBM SecureWayDirectory, z/OS™ y OS/390® SecureWay LDAP. La información de DB2 estádisponible en el siguiente sitio web:

http://www.ibm.com/software/data/db2/

IBM Global Security ToolkitAccess Manager permite cifrar datos utilizando IBM Global Security Toolkit(GSKit). GSKit se incluye en el CD de IBM Tivoli Access Manager Base para suplataforma específica.

El paquete GSKit instala el programa de utilidad de gestión de claves iKeyman(gsk5ikm), que le permite crear bases de datos de claves, pares de claves públicasy claves privadas y peticiones de certificados. El siguiente documento estádisponible en el directorio /doc/GSKit:v SSL Introduction and iKeyman User’s Guide (gskikm5c.pdf)

Proporciona información para administradores de red o administradores deseguridad de sistemas que tienen planificado habilitar la comunicación SSL en eldominio seguro de Access Manager.

IBM SecureWay DirectoryIBM SecureWay Directory, Versión 3.2.2, se incluye en el CD de IBM Tivoli AccessManager Base para su plataforma específica. Si tiene pensado instalar el servidorde IBM SecureWay Directory como el registro de usuarios, los siguientesdocumentos están disponibles en la ruta de acceso /doc/Directory del CD de IBMTivoli Access Manager Base para su plataforma específica:

Prefacio xv

v IBM SecureWay Directory Installation and Configuration Guide

(aparent.pdf, lparent.pdf, sparent.pdf, wparent.pdf)Proporciona información de instalación, configuración y migración para loscomponentes de IBM SecureWay Directory en los sistemas operativos AIX®,Linux, Solaris y Microsoft® Windows®.

v IBM SecureWay Directory Release Notes

(relnote.pdf)Contiene información complementaria a la documentación del producto IBMSecureWay Directory, Versión 3.2.2, y describe las características y funciones queestán disponibles en este release.

v IBM SecureWay Directory Readme Addendum

(addendum322.pdf)Proporciona información sobre los cambios y arreglos realizados después de latraducción de la documentación de IBM SecureWay Directory. Este archivo estádisponible sólo en inglés.

v IBM SecureWay Directory Server Readme

(server.pdf)Proporciona una descripción de IBM SecureWay Directory Server, Versión 3.2.2.

v IBM SecureWay Directory Client Readme

(client.pdf)Proporciona una descripción de IBM SecureWay Directory Client, Versión 3.2.2.Este kit de desarrollo de software (SDK) proporciona soporte para el desarrollode aplicaciones LDAP.

v IBM SecureWay Directory Configuration Schema

(scparent.pdf)Describe el árbol de información de directorios (DIT) y los atributos utilizadospara configurar el archivo slapd32.conf. En IBM SecureWay Directory Versión3.2, los valores de directorios se almacenan en formato LDIF (LDAP DirectoryInterchange Format) en el archivo slapd32.conf.

v IBM SecureWay Directory Tuning Guide

(tuning.pdf)Proporciona información de ajuste del rendimiento para IBM SecureWayDirectory. Incluye consideraciones sobre los ajustes del tamaño de los directoriosque tienen desde varios miles de entradas hasta millones de entradas, cuandoproceda.

Para obtener más información sobre IBM SecureWay Directory, visite el siguientesitio web:

http://www.software.ibm.com/network/directory/library/

IBM WebSphere Application ServerIBM WebSphere Application Server, Advanced Single Server Edition 4.0.2, seinstala con la interfaz de Web Portal Manager. Para obtener información sobre IBMWebSphere Application Server, visite el siguiente sitio web:

http://www.ibm.com/software/webservers/appserv/infocenter.html

Acceso a las publicaciones en líneaLas publicaciones de la biblioteca del producto están incluidas en formato PDF(Portable Document Format) en el CD del producto. Para acceder a estas

xvi IBM Tivoli Access Manager Base: Guía del administrador

publicaciones utilizando un navegador web, abra el archivo infocenter.html, quese encuentra en el directorio /doc del CD del producto.

Cuando IBM publica una versión actualizada de una o más publicaciones impresaso en línea, se envían a Tivoli Information Center. Tivoli Information Centercontiene las versiones más recientes de las publicaciones de la biblioteca delproducto en formato PDF o HTML, o en ambos. También están disponiblesdocumentos traducidos de algunos productos.

Puede acceder a Tivoli Information Center y a otras fuentes de información técnicadesde el siguiente sitio web:

http://www.tivoli.com/support/documents/

La información está organizada por producto e incluye las notas del release, guíasde instalación, guías del usuario, guías del administrador y material de consultapara desarrolladores.

Nota: Si desea imprimir documentos PDF en un papel que no sea de tamaño carta,seleccione la casilla de verificación Ajustar a página en el diálogo deimpresión de Adobe Acrobat (que está disponible al hacer clic en Archivo →Imprimir) para asegurarse de que se imprima todo el contenido de lapágina en tamaño carta en el papel que esté utilizando.

Solicitud de publicacionesPuede realizar pedidos de muchas publicaciones de Tivoli en línea en el siguientesitio web:

http://www.elink.ibmlink.ibm.com/public/applications/publications/cgibin/pbi.cgi

También puede realizar pedidos por teléfono llamando a uno de estos números:v En Estados Unidos: 800-879-2755v En España: 901-100-000v Para obtener una lista de números de teléfono de otros países, visite el siguiente

sitio web:http://www.tivoli.com/inside/store/lit_order.html

Comentarios sobre las publicacionesNos interesa conocer su opinión acerca de los productos y la documentación deTivoli, y agradeceremos cualquier sugerencia para aplicar mejoras. Si tienecomentarios o sugerencias sobre nuestros productos y la documentación, póngaseen contacto con nosotros utilizando uno de los procedimientos siguientes:v Envíe un mensaje de correo electrónico a [email protected] Rellene la encuesta de opinión del cliente en el siguiente sitio web:

http://www.tivoli.com/support/survey/

Prefacio xvii

AccesibilidadLas características de accesibilidad ayudan a los usuarios que tienen unadiscapacidad física, como movilidad restringida o visión limitada, a utilizar losproductos de software sin problemas. En este producto, puede utilizar tecnologíasde asistencia para tener acceso acústico a la interfaz y navegar por ella. Tambiénpuede utilizar el teclado en lugar del ratón para realizar todas las funciones de lainterfaz gráfica de usuario.

Cómo ponerse en contacto con el soporte al clienteSi tiene algún problema con cualquier producto de Tivoli, puede ponerse encontacto con el soporte al cliente de Tivoli. Consulte el manual Tivoli CustomerSupport Handbook en el siguiente sitio web:

http://www.tivoli.com/support/handbook/

En el manual se proporciona información sobre cómo ponerse en contacto con elsoporte al cliente de Tivoli, según la gravedad del problema, y la siguienteinformación:v Registro y elegibilidadv Números de teléfono y direcciones de correo electrónico, según el país donde se

encuentrev Información que debe recopilar antes de ponerse en contacto con el servicio de

soporte al cliente

Convenios utilizados en este manualEsta guía utiliza varios convenios para algunos términos y acciones especiales,comandos y rutas de acceso del sistema operativo, y gráficos de margen.

Convenios tipográficosEn este manual se utilizan los siguientes convenios tipográficos:

Negrita Los nombres de comandos y opciones, las palabras clave y otrainformación que debe utilizarse literalmente aparecen en negrita.

Cursiva Las variables, opciones de comandos y valores que el usuario debeproporcionar aparecen en cursiva. Los títulos de publicaciones y laspalabras o frases especiales que están enfatizadas también aparecenen cursiva.

Monoespaciado Los ejemplos de código, las líneas de comandos, la salida enpantalla, los nombres de archivo y de directorio, y los mensajes delsistema aparecen en el tipo de letra monoespaciada.

xviii IBM Tivoli Access Manager Base: Guía del administrador

Capítulo 1. Visión general de Access Manager

Access Manager es una completa solución de autorización para aplicaciones web,de cliente/servidor, de IBM Tivoli Access Manager y heredadas (ya existentes). Laautorización de Access Manager permite a una organización controlar de manerasegura el acceso de usuarios a información y recursos protegidos. Al proporcionaruna solución de control de accesos centralizada, versátil y escalable, AccessManager le permite construir aplicaciones basadas en la red muy seguras y biengestionadas e infraestructura de e-business.

Este capítulo contiene los apartados siguientes:v “Seguridad de la red empresarial” en la página 1v “Access Manager — tecnología básica” en la página 3v “Conceptos de autorización: modelo conceptual” en la página 5v “El servicio de autorizaciones de Access Manager” en la página 8v “Implementación de una política de seguridad de red” en la página 11v “La API de autorización de Access Manager” en la página 17v “Posibilidad de autorización externa” en la página 21v “Gestión de certificados y contraseñas de Access Manager Base” en la página 25

Seguridad de la red empresarialActualmente, muchas organizaciones valoran tanto la red pública Internet como lasintranets privadas como medios eficaces y vitales para la comunicación global. Elcomercio electrónico, o e-business, se ha convertido rápidamente en uncomponente esencial de muchas estrategias de marketing comercial. Los centros deenseñanza utilizan las prestaciones de Internet para el aprendizaje a distancia. Losservicios en línea permiten a las personas enviar correo electrónico y usar la vastaenciclopedia de recursos de la web. Las aplicaciones habituales, como TELNET yPOP3, siguen siendo importantes servicios de red.

Los agentes comerciales se están dando cuenta que pueden utilizar tecnologíaInternet para mejorar las relaciones de la cadena de suministro, simplificar lacolaboración con business partners y aumentar la conectividad con el cliente,siempre que puedan garantizar un elevado grado de seguridad para los recursoscorporativos. Los agentes comerciales desean utilizar Internet como un vehículoglobal de comercio y distribución, pero se muestran reticentes debido a la falta desistemas de gestión y mecanismos de políticas de seguridad fiables.

Access Manager es una solución para la gestión de políticas de información queproporciona a las organizaciones servicios de seguridad de red centralizados, enlos que se puede implementar y mantener de manera coherente una política deseguridad corporativa.

Access Manager proporciona los tres requisitos principales para una solución deseguridad equilibrada:v Proporciona diferentes soluciones para crear un entorno de red muy segurov Proporciona herramientas de gestión de fácil utilización e intuitivas para llevar a

cabo tareas de administración centralizadas seguras

1

v Proporciona mecanismos de seguridad que no obstruyen la actividad en la redde clientes autorizados

Seguridad en la red — aspectos comunesTanto la red pública Internet como las intranets privadas permiten la conexión consistemas, aplicaciones y redes de distinto tipo. Esta combinación de hardware ysoftware diferente suele afectar a la red de la manera siguiente:v No hay un control de seguridad centralizado para las aplicacionesv No hay un convenio de denominación de ubicación de recursosv No hay un soporte común para que las aplicaciones puedan utilizarse en

cualquier momentov No hay un soporte común para el crecimiento escalable

Los nuevos modelos comerciales requieren que los recursos de información de lasorganizaciones se sometan previamente a un grado inconcebible de riesgo. Losagentes comerciales han de saber que es posible controlar el acceso a estos recursosde manera segura.

La gestión de políticas y usuarios a través de redes distribuidas es complicada paralos gestores de la Tecnología de la información (IT), sobre todo porque losproveedores individuales de aplicaciones y sistemas implementan la autorizaciónde manera particular.

Las empresas consideran que el desarrollo de nuevos servicios de autorizacionespara cada aplicación empresarial es un proceso caro que conduce a unainfraestructura de difícil gestión. Un servicio de autorizaciones centralizado al quelos desarrolladores pudieran acceder a través de una API estándar proporcionaríauna posición ventajosa en el mercado y reduciría el coste total de propiedad.

Un sistema de gestión de seguridad de red centralizada debe satisfacer losrequisitos siguientes:v Coexistir con arquitecturas de cortafuegos y autenticación existentes y/o

aprovecharlasv Integrar infraestructuras de gestión de redes y aplicaciones o coexistir con ellasv No depender de ninguna aplicación

Conceptos básicos de Access ManagerAccess Manager es una completa solución para la gestión de políticas deautorización y seguridad en la red que proporciona a los recursos protección totalinviolable en intranets y extranets ubicadas en distintos puntos geográficos.

Además de su característica de gestión de políticas de seguridad avanzada, AccessManager da soporte a funciones de autenticación, autorización, seguridad de datosy gestión de recursos. Access Manager puede utilizarse junto con aplicacionesestándar basadas en Internet para construir intranets muy seguras y biengestionadas.

Básicamente, Access Manager proporciona:v Infraestructura de autenticación

Access Manager proporciona un amplio rango de autenticadores incorporados ysoporta autenticadores externos.

v Infraestructura de autorización

2 IBM Tivoli Access Manager Base: Guía del administrador

El servicio de autorizaciones de Access Manager, al que se accede a través deuna API de autorización estándar, permite tomar decisiones para permitir ydenegar peticiones de acceso para servidores de Access Manager nativos yaplicaciones de terceros.

Con Access Manager, los agentes comerciales pueden gestionar de manera segurael acceso a recursos basados en redes internas y hacer que la conectividad con lared pública Internet sea más eficaz y de fácil utilización. Access Manager, junto conun sistema de cortafuegos corporativo, puede proteger totalmente una intranetempresarial contra la intromisión y el acceso no autorizado.

La API de servicio de autorizaciones estándarLos servicios de autorizaciones son una parte importante de la arquitectura deseguridad de una aplicación. Cuando un usuario pasa el proceso de autenticación,los servicios de autorizaciones aplican la política comercial determinando a quéservicios e información puede acceder dicho usuario.

Por ejemplo, un usuario que accediera a un fondo de pensiones basado en la webpodría ver información sobre su cuenta personal después de que AuthorizationServer verificara su identidad, sus credenciales y sus atributos de privilegio.

La API de autorización basada en estándares permite a las aplicaciones efectuarllamadas al servicio de autorizaciones centralizado, lo cual evita a losdesarrolladores tener que escribir código de autorización para cada aplicaciónnueva.

La API de autorización permite a los agentes comerciales estandarizar todas lasaplicaciones en una infraestructura de autorización de confianza. Con la API deautorización, los agentes comerciales pueden proporcionar más control paraacceder a recursos en sus redes.

Access Manager — tecnología básicaLa solución de gestión de seguridad de red de Access Manager proporciona ysoporta la tecnología básica siguiente:v Autenticaciónv Autorizaciónv Calidad de protecciónv Escalabilidadv Responsabilidad de gestiónv Gestión centralizada

AutenticaciónLa autenticación es el primer paso que un cliente debe realizar al efectuar unapetición de un recurso desde una red protegida con Access Manager. El proceso deautenticación suele depender de los requisitos específicos de la aplicación queproporciona el servicio. Access Manager permite un enfoque muy versátil de laautenticación mediante la API de autorización.

Access Manager Base proporciona soporte incorporado de autenticación de nombrede usuario y contraseña mediante la API de autorización. Los desarrolladorespueden construir cualquier mecanismo de autenticación personalizado que utilicela API de autorización.

Capítulo 1. Visión general de Access Manager 3

Autorizaciónv Servicio de autorizaciones de Access Managerv Políticas de ACL y POP para control de accesos estrictov API de autorización basada en estándaresv Posibilidad de servicio de autorizaciones externo

Calidad de protección (de datos)La Calidad de protección es el grado con que Access Manager protege cualquierinformación transmitida entre cliente y servidor. La Calidad de protección ladetermina el efecto combinado de los estándares de cifrado y los algoritmos dedetección de modificación.

Los niveles de Calidad de protección incluyen:v Comunicación TCP estándar (sin protección)v Integridad de datos – impide que los mensajes (secuencia de datos) puedan

modificarse durante la comunicación en la redv Privacidad de datos – impide que los mensajes puedan modificarse o leerse

durante la comunicación en la red

Estándares de cifrado soportadosAccess Manager soporta los siguientes estándares de cifrado en SSL:v RC2 de 40 bitsv RC2 de 128 bitsv RC4 de 40 bitsv RC4 de 128 bitsv DES de 40 bitsv DES de 56 bitsv DES triple de 168 bits

Comunicación seguraAccess Manager soporta la integridad y la privacidad de datos que proporciona elprotocolo de comunicaciones Secure Socket Layer.

El protocolo de reconocimiento SSL (Secure Socket Layer) lo desarrolló NetscapeCommunications Corporation para proporcionar seguridad y privacidad enInternet. SSL funciona mediante clave pública para la autenticación y clave secretapara cifrar datos transferidos durante la conexión SSL.

Access Manager soporta la versión 2 y 3 de SSL.

EscalabilidadLa escalabilidad es la capacidad de responder a un número creciente de usuariosque acceden a recursos del dominio seguro. Access Manager utiliza los siguientesprocedimientos para proporcionar escalabilidad:v Réplica de servicios

– Autenticación de servicios– Servicios de autorizaciones– Políticas de seguridad– Servicios de cifrado de datos– Servicios de auditoría

4 IBM Tivoli Access Manager Base: Guía del administrador

v Servidores frontales replicados (WebSEAL)– Recursos reflejados para mayor disponibilidad– Peticiones de equilibrio de carga por parte del cliente

v Servidores de fondo replicados (WebSEAL)– Los servidores de fondo pueden ser WebSEAL o de aplicaciones de terceros– Recursos reflejados (espacio de objetos unificado) para mayor disponibilidad– Contenido y recursos adicionales– Equilibrio de carga de peticiones de entrada a través de conexiones (junctions)

v Rendimiento optimizado al permitir la descarga de servicios de autenticación yautorización en servidores distintos.

v Despliegue escalado de servicios sin aumentar la actividad de la gestión

Responsabilidad de gestiónAccess Manager proporciona una serie de prestaciones de registro y auditoría.Existen archivos de registro que capturan cualquier mensaje de error y de avisogenerados por servidores Access Manager. También existen archivos deseguimiento de auditoría que supervisan la actividad del servidor Access Manager.

Archivos de registro:v Archivos de registro del servidor Access Managerv Mensajes de serviciov Archivos de registro HTTP estándares

Archivos de seguimiento de auditoría:v Archivos de seguimiento de auditoría del servidor Access Manager

Gestión centralizadav Web Portal Managerv Programa de utilidad de línea de comandos pdadmin

Conceptos de autorización: modelo conceptualCuando un servidor aplica la seguridad en un dominio seguro, cada cliente debeidentificarse. A su vez, la política de seguridad determina si a ese cliente se lepermite efectuar una operación en un recurso solicitado. Puesto que el acceso acada recurso de un dominio seguro lo controla un servidor, las exigencias delservidor respecto a la autenticación y la autorización pueden proporcionar unaseguridad de red muy exhaustiva.

En sistemas de seguridad, la autenticación es distinta de la autorización. Laautorización determina si un cliente autenticado tiene el derecho de efectuar unaoperación en un recurso específico de un dominio seguro. La autenticación aseguraque el individuo es quien dice ser, pero no dice nada acerca de la posibilidad dellevar a cabo operaciones en un recurso protegido.

En el modelo de autorización de Access Manager, la política de autorización seimplementa independientemente del mecanismo utilizado para la autenticación delusuario. Los usuarios pueden autenticar su identidad mediante clavepública/privada, clave secreta o mecanismos definidos por el cliente.

Capítulo 1. Visión general de Access Manager 5

Parte del proceso de autenticación conlleva la creación de una credencial quedescribe la identidad del cliente. Las decisiones de autorización efectuadas por unservicio de autorizaciones se basan en credenciales del usuario.

Los recursos de un dominio seguro reciben un nivel de protección tal como indicala política de seguridad para el dominio. La política de seguridad define losparticipantes legítimos del dominio seguro y el grado de protección para cadarecurso que la requiere.

Los componentes básicos del proceso de autorización, tal como se muestra en laFigura 1, incluyen:v Un gestor de recursos responsable de implementar la operación solicitada

cuando se garantiza la autorización.Un componente del gestor de recursos es un aplicador de políticas que dirige lapetición al servicio de autorizaciones para procesarlo.

v Un servicio de autorizaciones que efectúa la acción de toma de decisionesrespecto a una petición.

Las aplicaciones habituales empaquetan el aplicador de políticas y el gestor derecursos en un proceso. Ejemplos de esta estructura son WebSEAL de AccessManager y aplicaciones de terceros.

Las funciones independientes de estos componentes de autorización permitenmayor versatilidad en el diseño de la estrategia de imposición de seguridad.

Por ejemplo, dicha independencia permite al administrador de seguridad controlar:v Dónde se encuentran los procesosv Quién escribe el código para los procesosv Cómo los procesos efectúan sus tareas

Las ventajas de un servicio de autorizaciones estándarLa autorización en la mayoría de sistemas, tanto heredados como nuevos, estáfirmemente relacionada con aplicaciones concretas. Generalmente, las empresasconstruyen aplicaciones según sus necesidades comerciales. La mayoría de estasaplicaciones requieren alguna forma específica de autorización.

Figura 1. Modelo de autorización general

6 IBM Tivoli Access Manager Base: Guía del administrador

El resultado suele ser un amplio rango de aplicaciones con implementaciones deautorización diferentes. Estas implementaciones de autorización de propietariorequieren una administración aparte, son de difícil integración y tienen costes depropiedad elevados.

Un servicio de autorizaciones distribuido puede proporcionar estas aplicacionesindependientes con un mecanismo de toma de decisiones de autorización estándar.Las ventajas de este servicio de autorizaciones estándar son:v Menor coste de desarrollo y gestión de acceso a aplicacionesv Menor coste total de propiedad y de gestión de sistemas de autorización

distintosv Mayor eficacia de la infraestructura de seguridad existentev Permitir a los nuevos agentes comerciales efectuar aperturas de manera más

segurav Habilitar tipos de aplicaciones nuevos y diferentesv Permitir ciclos de desarrollo más cortosv Compartir información de manera más segura

Conceptos básicos del servicio de autorizaciones de AccessManager

Access Manager se integra en infraestructuras heredadas existentes einfraestructuras emergentes y proporciona posibilidades de gestión de políticascentralizada y segura. El servicio de autorizaciones de Access Manager —junto conlos gestores de recursos (como WebSEAL)— proporciona un mecanismo deautorización estándar para sistemas de red comerciales.

Las aplicaciones existentes pueden beneficiarse del servicio de autorizaciones. Lapolítica de autorización se basa en roles de usuario o grupo y puede aplicarse aservidores de red, transacciones individuales o peticiones de base de datos,información específica basada en la web, actividades de gestión y objetos definidospor el usuario.

La API de autorización (consulte el apartado “La API de autorización de AccessManager” en la página 17) permite a las aplicaciones existentes efectuar llamadas alservicio de autorizaciones que, a su vez, toma decisiones basadas en la política deseguridad corporativa.

El servicio de autorizaciones de Access Manager también es ampliable y puedeconfigurarse para llamar a otros servicios de autorizaciones a efectos de completarun proceso utilizando la interfaz del plugin de servicio de autorizaciones externo.

Ventajas del servicio de autorizaciones de Access ManagerEl servicio de autorizaciones proporciona las ventajas siguientes:v El servicio no depende de ninguna aplicación.v El servicio utiliza un estilo de codificación de autorización estándar

independiente del lenguaje (la API de autorización).v El servicio se gestiona de manera centralizada y, por lo tanto, es de fácil

administración— por ejemplo, para agregar un nuevo empleado es precisomodificar la base de datos de privilegios en una ubicación central, en lugar deen varios sistemas.

v El servicio dirige la aplicación de servicios de seguridad en un entorno deplataformas cruzadas heterogéneo.

Capítulo 1. Visión general de Access Manager 7

v El servicio integra sistemas de autorización no Access Manager existentesmediante la posibilidad de servicio de autorizaciones externo.

v El servicio tiene una arquitectura escalable y versátil que puede integrarse demanera simple con una infraestructura existente.

v El servicio habilita la autorización de varios niveles — puede pasarse unpaquete de credenciales a través de las distintas capas de un proceso deaplicación o de una transacción.

v El servicio utiliza un modelo de auditoría común y eficaz.v El servicio es independiente de cualquier mecanismo de autenticación.

El servicio de autorizaciones de Access ManagerLa función del servicio de autorizaciones de Access Manager es realizar el procesode toma de decisiones de autorización que permite aplicar una política deseguridad de red. Las decisiones de autorización efectuadas por el servicio deautorizaciones aprueban o deniegan las peticiones de cliente para efectuaroperaciones en recursos protegidos del dominio seguro.

ComponentesEl servicio de autorizaciones está formado por tres componentes básicos:v Base de datos maestra de políticas de autorizaciónv Policy Serverv El evaluador de toma de decisiones de autorización

Base de datos maestra de políticas de autorizaciónLa base de datos maestra de políticas de seguridad contiene la información depolítica de seguridad para todos los recursos del dominio seguro. La base de datostambién contiene toda la información de credenciales necesaria asociada con losparticipantes del dominio seguro.

Utilice Web Portal Manager para entrar y modificar el contenido de esta base dedatos.

Policy Server (pdmgrd)Policy Server mantiene la base de datos maestra de políticas de autorización,replica la información de esta política a través del dominio seguro y actualiza lasréplicas siempre que se hace un cambio en la base de datos maestra.

Policy Server también mantiene información de ubicación de los otros servidoresAccess Manager y no Access Manager que operan en el dominio seguro.

Nota: Sólo debe haber una instancia de Policy Server en cualquier dominio seguro.

Evaluador de autorizacionesEl evaluador de autorizaciones es el proceso de toma de decisiones que determinala posibilidad que tiene un cliente de acceder a un recurso protegido según lapolítica de seguridad. El evaluador comunica su recomendación al gestor derecursos que, a su vez, le responde consecuentemente.

Para cada evaluador pueden configurarse parámetros de réplica de base de datosde registro.

8 IBM Tivoli Access Manager Base: Guía del administrador

La Figura 2 muestra los componentes principales del servicio de autorizaciones:

Interfaces del servicio de autorizacionesEl servicio de autorizaciones tiene dos interfaces en las que tiene lugar interacción:v Interfaz de gestión — El administrador de seguridad gestiona la política de

seguridad de la red utilizando Web Portal Manager (y/o el programa de utilidadpdadmin) para aplicar reglas de política (plantillas) en recursos de la red yregistrar las credenciales de participantes en el dominio seguro.Web Portal Manager aplica estos datos de política de seguridad en la base dedatos maestra de políticas de autorización a través de Policy Server.Esta interfaz es compleja y requiere el conocimiento preciso del espacio deobjetos, de plantillas de política y de credenciales.

v API de autorización — La API de autorización pasa peticiones de decisiones deautorización del gestor de recursos al evaluador de autorizaciones que, a su vez,pasa una recomendación. La publicación Access Manager Authorization ADKDeveloper Reference contiene los detalles de esta API.

Figura 2. Componentes del servicio de autorizaciones

Capítulo 1. Visión general de Access Manager 9

Réplica de escalabilidad y rendimientoLos componentes del servicio de autorizaciones pueden replicarse para aumentarla disponibilidad en un entorno de mucha demanda.

Puede configurar la base de datos maestra de políticas de autorización, quecontiene reglas de política e información de credenciales, para que se repliqueautomáticamente. Las aplicaciones que llaman al servicio de autorizaciones tienendos opciones para hacer referencia a esta información de base de datos:v La aplicación —cuando está configurada para funcionar sin fisuras con el

evaluador de autorizaciones— utiliza una caché local de la base de datos.La base de datos se replica para cada aplicación que utiliza el servicio deautorizaciones en modalidad de caché local.

v La aplicación utiliza una réplica compartida que el componente AuthorizationServer remoto almacena en la caché.La base de datos se replica para cada instancia de Authorization Server. Lamayoría de aplicaciones pueden acceder a un solo Authorization Server.

Actualizar la notificación de Policy Server (siempre que se ha hecho un cambio enla base de datos maestra de políticas de autorización) activa el proceso dealmacenamiento en caché para actualizar todas las réplicas.

Figura 3. Servicio de autorizaciones: interfaces

10 IBM Tivoli Access Manager Base: Guía del administrador

Notas sobre el rendimientov Además de actualizar notificaciones directamente desde Policy Server, los

servidores de aplicaciones también comprueban la versión de la base de datosmaestra de políticas de autorización cada vez que transcurren varios minutospara asegurarse de que no se han olvidado de ninguna notificación deactualización.Si una notificación de actualización no llega a un servidor, se crea una entradade registro. En ambos casos, un procedimiento de reintento garantiza que laactualización tendrá lugar más adelante.

v La información de política de autorización almacenada en la caché mejora elrendimiento del sistema. Por ejemplo, cuando WebSEAL realiza unacomprobación de autorización, comprueba la plantilla de políticas en su propiaversión de base de datos almacenada en la caché. WebSEAL no tiene que accedera la red para obtener esta información de la base de datos maestra. Comoconsecuencia se obtienen tiempos de respuesta muy rápidos (rendimiento) paracomprobaciones de autorización.

v El servidor de aplicaciones de llamada no almacena en caché el resultado de unaautorización individual.

Implementación de una política de seguridad de redLa política de seguridad para un dominio seguro se determina controlando laparticipación de usuarios y grupos en el dominio y aplicando reglas, conocidascomo políticas de lista de control de accesos (ACL) y políticas de objetosprotegidos (POP), en recursos que requieren protección. El servicio deautorizaciones aplica estas políticas emparejando las credenciales de un usuariocon los permisos de la política asignada al recurso solicitado. La recomendaciónresultante se pasa al gestor de recursos que completa la respuesta a la peticiónoriginal.

Figura 4. Componentes del servicio de autorizaciones replicados

Capítulo 1. Visión general de Access Manager 11

Definición de la política de seguridad de la redEl servicio de autorizaciones utiliza una base de datos central que lista todos losrecursos del dominio seguro y las políticas de ACL y POP asignadas a cadarecurso. Esta base de datos maestra de políticas de autorización y el registro deusuarios (que contiene cuentas de usuarios y de grupos) son los componentes claveque permiten definir una política de seguridad de red.

Para resumir, un política de seguridad de red controla:1. Usuarios y grupos a los que se les permite participar en el dominio seguro

El registro de usuarios mantiene esta información.2. El nivel de protección en todos los objetos del dominio seguro

La base de datos maestra de política de autorización mantiene esta información.

El espacio de objetos protegidosEl espacio de objetos protegidos es una representación jerárquica de recursos quepertenecen a un dominio seguro. Los objetos que aparecen en el espacio de objetosjerárquico representan los recursos reales de la red.v Recurso del sistema — el archivo o la aplicación físicos reales.v Objeto protegido — la representación lógica de un recurso real del sistema

utilizado por el servicio de autorizaciones, Web Portal Manager y otrosprogramas de utilidad de gestión de Access Manager.

Las plantillas de políticas pueden asociarse a objetos en el espacio de objetos paraproporcionar protección al recurso. El servicio de autorizaciones toma decisionesde autorización a partir de estas plantillas.

Access Manager utiliza las siguientes categorías de espacio de objetos:v Objetos web

Estos objetos representan cualquier elemento que puede dirigirse mediante unadirección URL HTTP como, por ejemplo, páginas web estáticas y direccionesURL dinámicas que se han convertido en consultas de base de datos u otro tipode aplicación.

v Objetos de gestión de Access Manager

Estos objetos representan las actividades de gestión que pueden efectuarsemediante Web Portal Manager. También representan las tareas necesarias paradefinir usuarios y establecer una política de seguridad. Access Manager soportala delegación de actividades de gestión y puede restringir la capacidad deladministrador de establecer una política de seguridad para un subconjunto delespacio de objetos.

v Objetos definidos por el usuario

Estos objetos representan tareas definidas por el cliente o recursos de redprotegidos por aplicaciones que utilizan el servicio de autorizaciones mediante laAPI de autorización.

12 IBM Tivoli Access Manager Base: Guía del administrador

Definición y aplicación de políticas de ACL y POPLos administradores de seguridad protegen los recursos del sistema definiendoreglas, conocidas como políticas de ACL y POP, y aplicando estas políticas a lasrepresentaciones de objetos de estos recursos en el espacio de objetos.

El servicio de autorizaciones toma decisiones de autorización a partir de laspolíticas aplicadas a estos objetos. Cuando se permite una operación solicitada enun objeto protegido, la aplicación responsable del recurso implementa estaoperación.

Una política puede determinar los parámetros de protección de muchos objetos.Cualquier cambio en la regla afecta a todos los objetos a los que la plantilla estáasociada.

Política explícita y heredadaUna política puede aplicarse explícitamente o heredarse. El espacio de objetosprotegidos de Access Manager soporta la herencia de atributos de ACL y POP. Esuna característica importante que el administrador de seguridad que gestiona elespacio de objetos debe tener en cuenta. El administrador sólo tiene que aplicarpolíticas explícitas en puntos de la jerarquía en los que las reglas deben cambiar.

Figura 5. Espacio de objetos protegidos de Access Manager

Capítulo 1. Visión general de Access Manager 13

Estos son algunos ejemplos de tipos de política:v Reglas codificadas por máquinav Posibilidad de autorización externav Etiquetaje seguro especialv Listas de control de accesos (ACL)

La lista de control de accesos (ACL)Una política de lista de control de accesos, o de ACL, es el conjunto de controles(permisos) que especifica las condiciones necesarias para efectuar determinadasoperaciones en un recurso. Las definiciones de políticas de ACL son componentesimportantes de la política de seguridad establecida para el dominio seguro. Laspolíticas de ACL, al igual que todas las políticas, se utilizan para identificar losestándares de seguridad de una organización en los recursos representados en elespacio de objetos protegidos.

Una política de ACL controla específicamente lo siguiente:1. Qué operaciones pueden efectuarse en el recurso2. Quién puede efectuar estas operaciones

Una política de ACL se compone de una o más entradas que incluyendesignaciones de usuarios y grupos y sus permisos o derechos específicos.

Políticas de objetos protegidos (POP)Las políticas de ACL proporcionan el servicio de autorizaciones con informaciónpara emitir una respuesta (yes o no) a una petición para acceder a un objetoprotegido y efectuar operaciones en ese objeto.

Figura 6. Políticas explícitas y heredadas

Figura 7. Política de ACL

14 IBM Tivoli Access Manager Base: Guía del administrador

Las políticas POP contienen condiciones adicionales para la petición que se hanpasado a Access Manager Base y al gestor de recursos (como WebSEAL) junto conla decisión yes de la política de ACL del servicio de autorizaciones. Esresponsabilidad de Access Manager y del gestor de recursos aplicar las condicionesde POP.

A continuación se listan los atributos disponibles para una POP:

Aplicado por Access Manager Base

Atributo POP Descripción

Nombre Nombre de la política. Se convierte en nombre_pop en loscomandos pdadmin pop.

Descripción Texto descriptivo de la política. Se muestra en elcomando pop show.

Modalidad de aviso Proporciona a los administradores un medio para probarpolíticas de ACL y POP.

Nivel de auditoría Especifica el tipo de auditoría: todas, ninguna, accesosatisfactorio, acceso denegado, errores.

Acceso según la hora del día Restricciones de día y hora para el acceso satisfactorio alobjeto protegido.

Aplicado por el gestor de recursos (como WebSEAL)

Atributo POP Descripción

Calidad de protección Especifica el grado de protección de datos: ninguna,integridad, privacidad.

Política de métodos deautenticación de punto final deIP

Especifica los requisitos de autenticación para accederdesde miembros de redes externas.

Administración de políticas: Web Portal ManagerWeb Portal Manager es una aplicación gráfica basada en la web que se utiliza paragestionar la política de seguridad en un dominio seguro. El programa de utilidadde línea de comandos pdadmin proporciona las mismas posibilidades deadministración de usuarios y grupos que Web Portal Manager, además de muchoscomandos no soportados por Web Portal Manager.

Desde Web Portal Manager (o pdadmin), puede gestionar el registro de usuarios,la base de datos maestra de políticas de autorización y los servidores de AccessManager. También puede agregar y suprimir usuarios / grupos y aplicar políticasde ACL y POP a los objetos de red.

Capítulo 1. Visión general de Access Manager 15

El proceso de autorización: paso a pasoLa Figura 9 muestra el proceso de autorización completo:

1. La petición de un recurso por parte de un cliente autenticado se dirige alservidor del gestor de recursos y es interceptada por el proceso de imposiciónde políticas.El gestor de recursos puede ser WebSEAL (para acceso HTTP, HTTPS) o unaaplicación de terceros.

Figura 8. Web Portal Manager: Administración de la política de seguridad

Figura 9. El proceso de autorización de Access Manager

16 IBM Tivoli Access Manager Base: Guía del administrador

2. El proceso de imposición de políticas utiliza la API de autorización (consulte elapartado “La API de autorización de Access Manager”) para llamar al serviciode autorizaciones y solicitar una decisión de autorización.

3. El servicio de autorizaciones efectúa una comprobación de autorización en elrecurso, representado como un objeto en el espacio de objetos protegidos. Laspolíticas POP básicas se comprueban en primer lugar. A continuación, secomprueba la política de ACL asociada al objeto con las credenciales del cliente.Después se comprueban las políticas POP aplicadas por el gestor de recursos.

4. La decisión de aceptar o denegar la petición se devuelve como unarecomendación al gestor de recursos (mediante el aplicador de políticas).

5. Si la petición se aprueba finalmente, el gestor de recursos pasa la petición a laaplicación responsable del recurso.

6. El cliente recibe el resultado de la operación solicitada.

La API de autorización de Access ManagerLa API (Interfaz de programación de aplicaciones) de autorización de AccessManager permite a las aplicaciones de Access Manager y a las de terceros consultarel servicio de autorizaciones para tomar decisiones de autorización.

La API de autorización es la interfaz entre el gestor de recursos (que solicita lacomprobación de autorización) y el servicio de autorizaciones. Asimismo, permite ala aplicación que aplica la política pedir una decisión de autorización, pero laprotege de la complejidad del proceso real de toma de decisiones.

La API de autorización proporciona un modelo de programación estándar paracodificar peticiones y decisiones de autorización. También le permite efectuarllamadas estandarizadas desde cualquier aplicación heredada o desarrolladarecientemente al servicio de autorizaciones gestionado de manera centralizada.

La API de autorización puede utilizarse siguiendo una de estas dos modalidades:v Modalidad de caché remota

En esta modalidad, la API se inicializa para llamar a Authorization Server(pdacld) remoto a fin de tomar decisiones de autorización en nombre de laaplicación. Authorization Server mantiene su propia caché de la base de datosde réplica de política de autorización. Esta modalidad es la recomendada paramanejar peticiones de autorización desde clientes de aplicación.(Consulte el apartado “API de autorización: modalidad de caché remota” en lapágina 19)

v Modalidad de caché local

En esta modalidad, la API se inicializa para descargar y mantener un réplicalocal de la base de datos de autorizaciones para la aplicación. La modalidad decaché local proporciona mayor rendimiento porque la aplicación toma todas lasdecisiones de autorización localmente en lugar de hacerlo a través de una red.Sin embargo, la actividad de réplica de base de datos y el factor de seguridadque aporta esta modalidad, la hacen la más adecuada para ser utilizada porservidores de aplicaciones de confianza, como WebSEAL.(Consulte el apartado “API de autorización: modalidad de caché local” en lapágina 20)

Una de las ventajas principales de la API de autorización es la posibilidad deproteger al usuario de la complejidad del mecanismo del servicio de

Capítulo 1. Visión general de Access Manager 17

autorizaciones. La API de autorización cubre aspectos, tales como gestión,almacenamiento, almacenamiento en caché, réplica, formatos de credenciales ymétodos de autenticación.

También es independiente de la infraestructura de seguridad subyacente, delformato de credenciales y del mecanismo de evaluación. Permite solicitar unacomprobación de autorización y obtener una recomendación simple yes o no. Elusuario no ve los detalles del procedimiento de comprobación de autorización.

Dos ejemplos de utilización de la API de autorizaciónLas aplicaciones de terceros pueden utilizar la API de autorización para efectuarcontrol de acceso o procesos muy específicos.

Ejemplo 1:

Puede designarse una interfaz gráfica de usuario para mostrar de manera dinámicabotones de tareas activos o inactivos, de acuerdo con los resultados de lacomprobación de autorización.

Ejemplo 2:

En la figura siguiente se muestra otra manera de utilizar la API de autorización;dicha figura muestra una petición de una transacción CGI por parte de unaaplicación web.

El nivel inferior de autorización, tal como se muestra en la figura A de la Figura 10en la página 19 implica un control de acceso de “todo o nada” en la dirección

URL. Este nivel flexible de autorización sólo determina si el cliente puede ejecutarel programa CGI. Si se permite acceso a la aplicación CGI, no habrá más controldisponible para recursos manipulados por la aplicación CGI.

Tal como se muestra en la figura B de la Figura 10 en la página 19, se hanestablecido controles de acceso en recursos que el programa CGI manipula. Laaplicación web está configurada para utilizar la API de autorización. Ahora, elprograma CGI puede llamar al servicio de autorizaciones para tomar decisiones deautorización respecto a los recursos que manipula — según la identidad del clienteque efectúa la solicitud.

18 IBM Tivoli Access Manager Base: Guía del administrador

API de autorización: modalidad de caché remotaEn la modalidad de caché remota, las aplicaciones utilizan las llamadas de funciónsuministradas por la API de autorización para comunicarse con AuthorizationServer (pdacld) remoto. Authorization Server funciona como el evaluador de tomade decisiones y mantiene su propia base de datos de réplica de política deautorización.

Authorization Server toma la decisión y devuelve una recomendación a laaplicación mediante la API. También puede escribir un registro de auditoría quecontiene los detalles de la petición de decisión de autorización.

Authorization Server debe estar ejecutándose en algún lugar del dominio seguro.Authorization Server puede residir en la misma máquina que la aplicación o enotra máquina. También puede instalar Authorization Server en más de unamáquina en un dominio seguro para que esté más disponible. Cuando se produceun error en un Authorization Server concreto, la API de autorización efectuará unamigración tras error de manera transparente.

Figura 10. Ejemplo de utilización de la API de autorización

Capítulo 1. Visión general de Access Manager 19

API de autorización: modalidad de caché localEn la modalidad de caché local, la API descarga y mantiene una réplica de la basede datos de políticas de autorización en el sistema de archivos local de laaplicación. Toma todas las decisiones de autorización en la memoria, lo queaumenta el rendimiento y la fiabilidad.

Se debe registrar manualmente cualquier aplicación utilizando la API deautorización en la modalidad de caché local con el servicio de autorizaciones.Policy Server debe conocer la ubicación de cualquier aplicación de API deautorización en modalidad de caché local para que pueda actualizar la base dedatos de réplica de política de autorización asociada a él.

La réplica local se mantiene en sucesivas invocaciones de la aplicación. Cuando laAPI se inicia en modalidad de réplica, comprueba si se han producidoactualizaciones en la base de datos maestra de políticas de autorización desde quese creó la réplica local.

Figura 11. API de autorización: modalidad de caché remota

20 IBM Tivoli Access Manager Base: Guía del administrador

Posibilidad de autorización externaEn algunos casos, es posible que las implementaciones de políticas de AccessManager estándar —Listas de control de accesos y Políticas de objetos protegidos—no puedan expresar todas las reglas de autorización que necesita la política deseguridad de una organización. Access Manager proporciona posibilidad deautorización externa opcional para ajustarse a cualquier requisito de autorizaciónadicional.

El servicio de autorizaciones externo le permite imponer controles de autorizaciónadicionales y condiciones establecidas por un módulo de servicio de autorizaciones(externo) separado.

Ampliación del servicio de autorizacionesLa posibilidad de autorización externa se crea automáticamente en el servicio deautorizaciones de Access Manager. Si configura un servicio de autorizacionesexterno, el servicio de autorizaciones de Access Manager simplemente incorporalas rutas de decisión de acceso a su proceso de evaluación.

Las aplicaciones que utilizan el servicio de autorizaciones —como WebSEAL ycualquier aplicación que utiliza la API de autorización— se benefician de lacontribución adicional, pero sin fisuras, de un servicio de autorizaciones externoconfigurado. Cualquier adición a la política de seguridad mediante un servicio deautorizaciones externo es transparente a estas aplicaciones y no requiere que éstasse modifiquen.

La arquitectura del servicio de autorizaciones externo permite la completaintegración del servicio de seguridad existente de una organización. Los servicios

Figura 12. API de autorización: modalidad de caché local

Capítulo 1. Visión general de Access Manager 21

de autorizaciones externos mantienen la inversión inicial de la empresa enprocedimientos de seguridad al permitir que los servidores heredados se puedanincorporar en el proceso de toma de decisiones de autorización de Access Manager.

Imposición de condiciones en peticiones de recursosSe puede utilizar un servicio de autorizaciones externo para imponer condicionesmás específicas o efectos específicos del sistema en un intento de accesosatisfactorio o no satisfactorio.

Estos son algunos ejemplos de estas condiciones:v Ocasionar un procedimiento de auditoría externa para registrar el intento de

acceso satisfactorio o no satisfactoriov Supervisar activamente el intento de acceso y ocasionar una alerta o alarma

siempre que se detecte un funcionamiento inaceptablev Facturación / transacciones de pagos de pequeñas cantidadesv Imponer cuotas de acceso en un recurso protegido

El proceso de evaluación de autorizaciónUna decisión de autorización que incorpora un Authorization Server externo tienelugar de la manera siguiente:1. Si se produce una condición desencadenante durante el curso de una decisión

de acceso, se llama uno a uno a los servicios de autorizaciones externos que sehan configurado para esa condición a fin de evaluar sus propias restriccionesde autorización externa.La invocación del servicio de autorizaciones externo se produceindependientemente de si el servicio de autorizaciones de Access Managerconcede o no el permiso necesario para el usuario.

2. Cada servicio de autorizaciones externo devuelve una decisión de permitido,denegado o indiferente.Cuando se devuelve “indiferente”, significa que el servicio de autorizacionesexterno ha determinado que no es necesario para el proceso de decisión y queno participa.

3. Cada decisión del servicio de autorizaciones externo se evalúa de acuerdo alnivel de importancia que tiene en el proceso.La evaluación de servicios de autorizaciones externos individuales se configuracuando se carga el plugin del servicio.

4. Todos los resultados de la decisión de autorización se suman y combinan con ladecisión efectuada por el servicio de autorizaciones de Access Manager. Ladecisión resultante se devuelve al emisor de la llamada.

EjemploLa Figura 13 en la página 23 muestra una decisión de autorización en la queintervienen un servidor WebSEAL y un servicio de autorizaciones externo.

22 IBM Tivoli Access Manager Base: Guía del administrador

En este ejemplo, el propósito del servicio de autorizaciones externo es imponer unarestricción de cuota en la frecuencia con que se puede acceder a la impresora decalidad fotográfica.

La implementación del servicio impone un límite en el número de trabajos quecualquier persona puede enviar a esta impresora en una semana. Al recurso deimpresora fotográfica se ha asociado una condición desencadenante del servicio deautorizaciones externo para que éste se invoque siempre que se acceda a laimpresora.

El servicio de autorizaciones externo se ha cargado con la evaluación de decisiónpredeterminada de 101, que prevalece sobre cualquier decisión tomada por elservicio de autorizaciones de Access Manager, en caso de que sea necesario.1. El servidor WebSEAL recibe una petición de un cliente para acceder a un

recurso de impresión fotográfica en línea. El cliente es miembro del grupoGraphicArtists por lo que habitualmente se le permite enviar trabajos a laimpresora.

2. El servidor WebSEAL consulta en primer lugar el servicio de autorizaciones deAccess Manager para determinar si el usuario que efectúa la petición tienepermiso para enviar trabajos a la impresora.

3. El servicio de autorizaciones comprueba los permisos de acceso en el objetosolicitado de destino y los compara con la capacidad del usuario que efectúa lapetición:grupo GraphicArtists rx

En la ACL del recurso de impresora, el permiso x concede a cualquier usuariodel grupo GraphicArtists acceso al recurso. Por lo tanto, el servicio deautorizaciones concede al usuario permiso para enviar el trabajo.

Figura 13. Servicio de autorizaciones externo con WebSEAL

Capítulo 1. Visión general de Access Manager 23

4. Puesto que se está accediendo al recurso de impresora fotográfica y se haasociado a este objeto una condición desencadenante del servicio deautorizaciones externo, también se efectúa una petición al servicio deautorizaciones externo configurado para esa condición desencadenante.El servicio de autorizaciones externo recibe toda la Información de decisión deacceso (ADI) que WebSEAL pasó con la comprobación de decisión de accesooriginal.

5. El servicio de autorizaciones externo consulta el registro de accesos anterioresefectuados por este usuario. Si el usuario que efectúa la solicitud no haexcedido su cuota semanal, devuelve una decisión de acceso de “indiferente”.Esto implica que el servicio de autorizaciones externo es indiferente a lapetición y no tiene intención de participar en la decisión de acceso porque nose han reunido sus condiciones para denegar el acceso.Sin embargo, si el usuario ha excedido su cuota, el servicio de autorizacionesexterno devuelve una decisión de “acceso denegado”.En este ejemplo, se presupone que el usuario que efectúa la solicitud haexcedido su cuota y que el servicio de autorizaciones externo detecta estasituación y devuelve una decisión de “acceso denegado”.

6. El servicio de autorizaciones de Access Manager recibe el resultado de “accesodenegado” del servicio de autorizaciones externo. Por consiguiente, toma estadecisión y la evalúa con el valor 101 de evaluación del servicio deautorizaciones externo.Los resultados de la decisión del servicio de autorizaciones externo y ladecisión tomada por el servicio de autorizaciones de Access Manager secombinan. El resultado es “acceso denegado” porque el resultado del serviciode autorizaciones externo (-101) sobrepasa el del servicio de autorizaciones deAccess Manager (100).

7. El servidor WebSEAL rechaza el envío de trabajos al recurso de impresorafotográfica.

8. El servidor WebSEAL devuelve una respuesta al emisor de la llamada paraindicar que se ha rechazado el trabajo.

Implementación de un servicio de autorizaciones externoPara establecer un servicio de autorizaciones externo es preciso llevar a cabo dospasos generales:1. Escribir un módulo de plugin del servicio de autorizaciones externo con una

interfaz de autorización al que se pueda hacer referencia durante decisiones deautorización.

2. Registrar el servicio de autorizaciones externo con Access Manager, de maneraque los clientes de autorización de Access Manager puedan cargar el serviciode plugin durante la inicialización.

Al registrar el servicio se establece una condición desencadenante para lainvocación del servicio de autorizaciones externo. Cuando se encuentra lacondición desencadenante durante una comprobación de autorización, la interfazdel servicio de autorizaciones externo se invoca para crear una decisión deautorización adicional.

Consulte la publicación Access Manager Authorization API Developer Reference paraobtener información detallada sobre cómo implementar un servicio deautorizaciones externo.

24 IBM Tivoli Access Manager Base: Guía del administrador

Estrategias de despliegueAccess Manager le permite implementar un servicio de autorizaciones externo devarias maneras:v Se puede agregar cualquier número de Authorization Servers externos al

dominio del recurso para efectuar diferentes evaluaciones de autorización. Cadaservicio de autorizaciones externo se carga en la aplicación de cliente individualde la API de autorización en modalidad local. Algunas aplicaciones que puedencargar servicios de autorizaciones externos son WebSEAL (webseald),Authorization Server (PDAcld), otros servidores de Access Manager y cualquieraplicación de autorización escrita por el cliente.

v Los clientes de API de autorización en modalidad remota, que efectúanpeticiones a Authorization Server para que se tomen decisiones de autorización,utilizan automáticamente cualquiera de los servicios de autorizaciones externosque Authorization Server ha cargado.

v Para una sola condición desencadenante se puede llamar a más de un serviciode autorizaciones externo. En este caso, el resultado de cada servicio deautorizaciones externo se evalúa consecuentemente y se combina con elresultado del servicio de autorizaciones de Access Manager.

v Las condiciones desencadenantes se pueden establecer para objetos mediante undesencadenante de Política de objetos protegidos (POP), de manera quecualquier petición a un objeto, independientemente de la operación que se estésolicitando, activa una llamada a los servicios de autorizaciones externos que sehan configurado para el desencadenante.

v Las condiciones desencadenantes también se pueden establecer para operacionesque el usuario ha solicitado. Por ejemplo, un servicio de autorizaciones externopuede activarse de manera específica cuando una usuario solicita una operaciónde escritura para un recurso protegido, pero no para otra operación. Acontinuación, es posible desarrollar conjuntos de operaciones para los que uno omás servicios de autorizaciones externos combinados se activan de acuerdo conel conjunto de operaciones solicitadas.

v Los servicios de autorizaciones externos se implementan como módulos debiblioteca cargable dinámicamente (DLL). Esto simplifica de manera considerableel desarrollo del servicio de autorizaciones externo. No existe ningún requisitopara efectuar peticiones remotas al servicio de autorizaciones externo y laactividad de crear la llamada es equivalente a la de una llamada de función.

v La combinación de la API de autorización con un servicio de autorizacionesexterno proporciona una solución significativamente ampliable y versátil paraimplementar una política de seguridad compleja.

Gestión de certificados y contraseñas de Access Manager BaseLos componentes de Access Manager Base utilizan SSL para cifrado, autenticacióndel sistema y autenticación de aplicación. SSL utiliza certificados para la operación.En el entorno seguro, pdmgrd actúa como la autoridad de certificación (CA) y esresponsable de crear y renovar certificados. El tiempo de ejecución de AccessManager (pdrte) sólo confía en la autenticación de servidor de SSL y por lo tanto,no requiere un certificado de cliente. Sin embargo, todos los servidores de AccessManager, tales como pdmgrd, pdacld y aznAPI (al igual que WebSEAL) confían encertificados de cliente.

Los servidores utilizan certificados para autenticarse a ellos mismos. Por ejemplo,cuando pdacld se comunica con pdmgrd, presenta su certificado de cliente. En esteejemplo, pdmgrd puede considerarse el servidor y pdacld el cliente. El servidorpdmgrd verifica que el certificado sea válido y esté firmado por un componente de

Capítulo 1. Visión general de Access Manager 25

confianza (en este caso pdmgrd mismo, utilizando el certificado PDCA). Elservidor pdacld hace lo mismo en relación con el certificado presentado porpdmgrd. Como parte de la autenticación de aplicación de Access Manager, encuanto pdmgrd determina que el certificado de pdacld es válido, intentacorrelacionarlo con un principal de Access Manager. Si la autenticación essatisfactoria, los servidores pueden empezar a comunicarse.

Los certificados que Access Manager utiliza se mantienen en archivos de base dedatos de conjunto de claves (que tienen la extensión .kdb). Estos archivos debenestar protegidos por los controles más estrictos posibles del sistema operativo yaque contienen las claves privadas para los certificados en cuestión. Por ejemplo, elarchivo de base de datos de conjunto de claves para pdmgrd es ivmgrd.kdb y, deforma predeterminada, sólo lo pueden leer y escribir el usuario ivmgr y el grupoivmgr.

Además, para simplificar la operación desatendida del servidor, hay archivos quecontienen una versión deliberadamente confusa (no cifrada) de la contraseña paraacceder a los archivos de base de datos de conjunto de claves. Estos archivosreciben el nombre de archivos stash y se identifican mediante la extensión .sth.Estos archivos también deben protegerse utilizando procedimientos del sistemaoperativo. Para pdmgrd, el archivo stash es ivmgrd.sth y sus permisos son losmismos que los de ivmgrd.kdb.

Por motivos de seguridad, tanto los certificados como las contraseñas del archivode base de datos de conjunto de claves pueden establecerse para expirar despuésde un periodo de tiempo configurable. La duración predeterminada para uncertificado es 365 días. La duración predeterminada de una contraseña de archivode base de datos de conjunto de claves es 183 días. La duración establecida para elcertificado PDCA es 20 años. También de forma predeterminada, los componentesde Access Manager efectúan autoprotección; es decir, renuevan los certificados ylas contraseñas automáticamente mientras están en ejecución.

Sin embargo, si lo servidores no se ejecutan en un periodo de tiempo especificado,sus certificados o contraseñas pueden expirar. En tal caso, es preciso realizar unarenovación manual. Además, si un certificado, una contraseña o todo el archivo debase de datos de conjunto de claves están dañados, para que el dominio de AccessManager siga siendo seguro, también se garantiza una renovación manual.

Configuración inicialLos certificados utilizados por los componentes de Access Manager se crean comoparte de sus configuraciones iniciales. En una instalación de Access Managernueva, el servidor pdmgrd es el primer servidor configurado. Durante laconfiguración, se crea el certificado PDCA y éste crea y firma un certificadopersonal que pdmgrd utiliza. Ambos certificados residen en el archivo de base dedatos de conjunto de claves ivmgrd.kdb. Asimismo, durante la configuración depdmgrd se crea el archivo de base de datos de conjunto de claves, pd.kdb, y elcertificado PDCA se inserta en él como un certificado de confianza.

Cuando se agregan sistemas nuevos al dominio de Access Manager, pdrte seconfigura en primer lugar. También durante la configuración se crean los archivospd.kdb y pd.sth del sistema, y se incluye el certificado PDCA en el archivo de basede datos de conjunto de claves como un certificado de confianza.

Cuando se configuran servidores aznAPI nuevos (como pdacld o WebSEAL),ejecutan el comando svrsslcfg. Esta herramienta crea un archivo de base de datos

26 IBM Tivoli Access Manager Base: Guía del administrador

de conjunto de claves (como pdacld.kdb) y coloca en él un certificado personalpara el servidor. También inserta el certificado PDCA como un certificado deconfianza en el archivo de base de datos de conjunto de claves. Estos doscertificados se obtienen de pdmgrd y se transportan a la máquina cliente medianteSSL utilizando el archivo de base de datos de conjunto de claves de tiempo deejecución.

Información sobre la renovación del archivo de base de datosde conjunto de claves y del archivo stash

La tabla siguiente lista los componentes y sus archivos de conjunto de claves ystash asociados. También describe cómo se crean y renuevan.

Componente Archivo deconjunto declaves/stash

Cómo se crea Procesos queactualizanautomáticamenteel archivo deconjunto declaves y/o lacontraseña

Herramientapara laactualizaciónmanual

pdrte pd.kdb pd.sth(no contiene uncertificado decliente)

Durante laconfiguración depdrte

Invocaciones depdadmin1

bassslcfg-chgpwd

pdmgrd ivmgrd.kdbivmgrd.sth

Durante laconfiguración depdmgrd

Ejecución depdmgrd1,2

mgrsslcfg-chgpwd3ymgrsslcfg-chgcert3

pdacld ivacld.kdbivacld.sth

Durante laconfiguración depdacld

Ejecución depdacld1

svrsslcfg-chgpwd4 ysvrsslcfg-chgcert5

Servidor aznAPI(comoWebSEAL)

aznAPI.kdbaznAPI.sth (elnombre esconfigurable)

Ejecución desvrsslcfg -config

Ejecución de lainstancia delservidoraznAPI1

svrsslcfg-chgpwd6ysvrsslcfg-chgcert7

Notas:v 1 - La renovación automática del certificado y la contraseña puede desactivarse

estableciendo el atributo [ssl], ssl-auto-refresh en no en el correspondiente archivode configuración (.conf).

v 2 - Puesto que pdmgrd también actúa como la CA para el dominio seguro, debereciclarse después de una renovación. Sigue operando normalmente hasta que serecicla, excepto si no puede emitir o renovar certificados para otros servidoreshasta que se recicla. El archivo pdmgrd.log contiene un mensaje que indicacuándo el servidor tiene que reiniciarse.

v 3 - Antes de ejecutar este comando, debe detenerse el servidor pdmgrd.v 4 - Antes de ejecutar este comando, debe detenerse el servidor pdacld.v 5 - Antes de ejecutar este comando, el servidor pdmgrd debe estar en ejecución y

debe detenerse el servidor pdacld.v 6 - Antes de ejecutar este comando, debe detenerse el servidor aznAPI.v 7 - Antes de ejecutar este comando, el servidor pdmgrd debe estar en ejecución y

debe detenerse el servidor aznAPI.

Capítulo 1. Visión general de Access Manager 27

Determinación de confianzaCada uno de los archivos de base de datos de conjunto de claves también contieneuna lista de CA de confianza. En Access Manager, todos los archivos de base dedatos de conjunto de claves (excepto ivmgrd.kdb) tienen el certificado PDCA comouna CA de confianza. La CA es el certificado que se utiliza para firmar los demáscertificados de Access Manager. Esta CA se crea durante la configuración depdmgrd y se coloca en el archivo ivmgrd.kdb. Es muy importante proteger elarchivo ivmgrd.kdb para que no se comprometa la clave privada del certificadoPDCA. Si se compromete, debe volver a generarse. Si esto ocurre, todos losarchivos de base de datos de conjunto de claves y todos los certificados deldominio seguro tienen que volver a generarse. Los pasos para efectuar esta acciónson:1. Volver a generar el certificado PDCA (y el certificado del servidor pdmgrd)

generando un archivo ivmgrd.kdb nuevo mediante mgrsslcfg -unconfig ymgrsslcfg -config (debe detenerse pdmgrd).

2. Volver a generar todos los tiempos de ejecución pdrte del dominio ejecutandobassslcfg -unconfig en primer lugar. A continuación, obtenga el certificado deCA. Si la descarga automática del certificado CA está activada y pdmgrd estáen ejecución, el certificado CA se obtiene ejecutando bassslcfg -getcacert -hnombrehost pdmgrd -c nombre de archivo de certificado. Si la descarga automáticaestá desactivada, la versión codificada base-64 DER del certificado PDCA debecopiarse manualmente en la máquina. Este archivo se almacena comopdcacert.b64 en la máquina pdmgrd. Finalmente, ejecute bassslcfg -configpara completar la configuración de pdrte.

3. Vuelva a generar todos los archivos de conjunto de claves de pdacld deldominio ejecutando svrsslcfg -chgpwd y svrsslcfg -chgcert (pdmgrd debe estaren ejecución). Estos comandos actualizan tanto el certificado del servidor parapdacld como su certificado de confianza (el certificado PDCA nuevo).

4. Vuelva a generar cualquier archivo de conjunto de claves del servidor aznAPIdel dominio ejecutando svrsslcfg -chgpwd y svrsslcfg -chgcert (pdmgrd debeestar en ejecución). Estos comandos actualizan tanto el certificado del servidorpara el servidor como su certificado de confianza (el certificado PDCA nuevo).

Revocación de certificadosSi se comprometen un archivo de base de datos de conjunto de claves del servidoro un certificado, pueden revocarse ejecutando el comando chgcert adecuado. Estogenera un certificado nuevo y hace que el antiguo no sea válido. Por ejemplo, si seha comprometido el certificado de pdacld, ejecutar svrsslcfg -chgcert generará uncertificado nuevo para ese archivo y hará que el certificado comprometido no seaválido. Asimismo, al ejecutar el comando sslcfg -unconfig adecuado, ningúncertificado se autenticará con Access Manager.

Consideraciones adicionalesLas consideraciones adicionales para la renovación del archivo de base de datos deconjunto de claves y del archivo stash son las siguientes:v Si un certificado y la contraseña del archivo de base de datos de conjunto de

claves que contiene ese certificado han caducado, la contraseña debe renovarseen primer lugar. Por ejemplo, para pdacld, ejecute svrsslcfg -chgpwd y, acontinuación, svrsslcfg -chgcert. Esto es necesario porque se necesita unacontraseña válida para abrir el archivo de base de datos de conjunto de claves afin de obtener el certificado.

v El valor de la duración de un certificado se controla mediante el valor delatributo ivmgrd.conf, [ssl], ssl-cert-life cuando se inicia pdmgrd. Todos los

28 IBM Tivoli Access Manager Base: Guía del administrador

certificados emitidos o renovados utilizan este valor. Para aumentar o disminuireste valor, cambie el valor y reinicie pdmgrd. El valor nuevo sólo entra en vigorpara certificados emitidos o renovados a partir de ese punto.

v Para renovar la contraseña automáticamente, el valor de la duración de unacontraseña se controla mediante el valor del atributo [ssl], ssl-pwd-life que entraen vigor cuando se inicia el servidor. Para renovar la contraseña manualmente,el valor de la duración lo indica el valor suministrado en el comando chgpwd.Ese valor también está escrito en el archivo de configuración adecuado.

v Los servidores de Access Manager también pueden comunicarse con LDAPmediante SSL. En la configuración estándar, esta comunicación sólo utilizaautenticación de servidor. Por lo tanto, el servidor de Access Manager sólonecesita el certificado CA que firmó el certificado del servidor LDAP o elcertificado del servidor LDAP mismo. Access Manager no maneja la caducidad ygestión de estos certificados. Sin embargo, es posible incluir el certificado LDAPen el archivo de base de datos de conjunto de claves para un servidor aznAPIejecutando svrsslcfg -config y utilizando la opción -C.

v Después de ejecutar bassslcfg -config, puede que sea necesario cambiar lospermisos de pd.kdb y pd.sth.

v Generalmente, los archivos de configuración mencionados se encuentran en eldirectorio directorio-instalación-pd/etc. Por ejemplo, en AIX los archivos deconfiguración pdmgrd, pdacld y runtime se encuentran en/opt/PolicyDirector/etc/ivmgrd.conf, /opt/PolicyDirector/etc/ivacld.conf y/opt/PolicyDirector/etc/pd.conf respectivamente. De la misma manera, losarchivos de base de datos de conjunto de claves y los archivos stash seencuentran en el directorio directorio-instalación-pd/keytabs.

Capítulo 1. Visión general de Access Manager 29

30 IBM Tivoli Access Manager Base: Guía del administrador

Capítulo 2. Gestión del espacio de objetos protegidos

Un dominio seguro contiene recursos físicos que suelen necesitar algún nivel deprotección. Los recursos pueden ser archivos, directorios y servicios de impresora.Access Manager utiliza una representación virtual de estos recursos que recibe elnombre de espacio de objetos protegidos.

Los recursos pueden protegerse asociando políticas de ACL y POP a lasrepresentaciones de objetos de esos recursos. Este capítulo trata del espacio deobjetos protegidos y de cómo se pueden crear ampliaciones del espacio de objetospara soportar requisitos de aplicaciones del cliente.

Este capítulo contiene los apartados siguientes:v “Conceptos del espacio de objetos protegidos” en la página 31v “Definición de un espacio de objetos de base de datos” en la página 34

Conceptos del espacio de objetos protegidosEl modelo de seguridad de Access Manager depende de las políticas de ACL yPOP para proporcionar protección estricta a estos recursos. Las políticas deseguridad corporativas se implementan aplicando de manera estratégica políticasde ACL y POP del cliente en aquellos recursos que requieren protección. El serviciode autorizaciones de Access Manager toma decisiones para permitir o denegar elacceso a los recursos según las credenciales del usuario y las condiciones y lospermisos específicos establecidos en las políticas de ACL y POP.

A fin de aplicar políticas de ACL y POP y permitir al servicio de autorizacionesefectuar sus comprobaciones de seguridad, Access Manager utiliza unarepresentación de objetos virtual de recursos del dominio seguro que recibe elnombre de espacio de objetos protegidos.

Si actúa como administrador de seguridad de Access Manager, puede utilizar WebPortal Manager o el programa de utilidad pdadmin para asociar políticas de ACLy POP a los objetos lógicos del espacio de objetos.

Elementos del espacio de objetos protegidosEl espacio de objetos protegidos de Access Manager es una representaciónjerárquica de recursos que pertenecen a un dominio seguro. Los objetos queaparecen en el espacio de objetos jerárquico representan los recursos físicos realesde la red.v Recurso del sistema – el archivo, el servicio de red o la aplicación físicos reales.v Objeto protegido – la representación lógica de un recurso real del sistema

utilizado por el servicio de autorizaciones, Web Portal Manager y otrosprogramas de utilidad de gestión de Access Manager.

El espacio de objetos protegidos utiliza dos tipos de objetos:v Objetos contenedor

Los objetos contenedor son designaciones estructurales que le permitenorganizar el espacio de objetos jerárquicamente en zonas de funcionamientodistintas. Los objetos contenedor contienen objetos de recurso.

31

v Objetos de recurso

Los objetos de recursos son las representaciones de recursos de red reales (comoservicios, archivos y programas) del dominio seguro.

Jerarquía de espacio de objetos protegidosLa parte superior de la estructura, o el comienzo, del espacio de objetos protegidoses el objeto contenedor root. El símbolo de root es la barra inclinada ( / ).

Al objeto root le siguen las siguientes categorías de espacio de objetos:v Objetos web (contenedor /WebSEAL)

El objeto contenedor WebSEAL es la raíz del espacio web lógico del dominioseguro. Todas las operaciones HTTP están autorizadas para algunos objetos deeste subárbol.Los objetos web representan cualquier elemento que una dirección URL puededirigir como, por ejemplo, páginas web estáticas y direcciones URL dinámicasque se han convertido en consultas de base de datos u otro tipo de invocaciónde aplicación mediante un gateway de web a aplicación.

v Objetos de gestión de Access Manager (contenedor /Management)

El objeto contenedor de gestión es la raíz del espacio lógico que controla todaslas operaciones de gestión de Access Manager. Los objetos de gestiónrepresentan los servicios necesarios para definir usuarios y grupos y establecerpolíticas de seguridad. Estas tareas pueden llevarse a cabo utilizando Web PortalManager o el programa de utilidad pdadmin.Las subdivisiones de la región /Management son:– Gestión de usuarios (/Users)– Gestión de grupos (/Groups)– Gestión de GSO (/GSO)– Gestión de servidores (/Server)– Política de ACL (/ACL)– POP (/POP)– Control de autorización de configuración (/Config)– Control de autorización de terceros (/Action)– Control de réplica de base de datos de autorizaciones (/Replica)

Access Manager soporta la delegación de determinadas actividades de gestión ypuede restringir la capacidad de un administrador para establecer la política deseguridad en un subconjunto del espacio de objetos.

Figura 14. Espacio de objetos protegidos de Access Manager

32 IBM Tivoli Access Manager Base: Guía del administrador

v Objetos definidos por el usuario

Estos objetos representan tareas definidas por el cliente o recursos de redprotegidos por aplicaciones de terceros que utilizan la API de autorización paraefectuar llamadas al servicio de autorizaciones de Access Manager.

Espacio de objetos definidos por el usuario para aplicacionesde terceros

Access Manager puede proporcionar servicios de autorizaciones a cualquier objetode aplicación de terceros definido por el espacio de objetos protegidos.

Es preciso definir una región del espacio de objetos para cada aplicación queutiliza Access Manager. Por ejemplo, WebSEAL, tiene su propio espacio de objetos(/WebSEAL). Access Manager almacena objetos de gestión en el espacio de objetos/Management.

Estos objetos aparecen en un comando pdadmin objectspace list:pdadmin> objectspace list

/WebSEAL/Management

Access Manager y las aplicaciones de terceros efectúan llamadas al servicio deautorizaciones a través de la API de autorización. Es preciso llevar a cabo dospasos para integrar una aplicación de terceros en el servicio de autorizaciones:v Describir el espacio de objetos de la aplicación de terceros.v Aplicar permisos en cualquier objeto que requiera protección.

Los contenedores de “objetos definidos por el usuario” opcionales son regiones delespacio de objetos protegidos en los que se pueden crear objetos para unaaplicación de terceros. Para poder agregar nuevos objetos, debe definir uncontenedor de espacio de objetos nuevo.

Figura 15. Regiones del espacio de objetos protegidos de Access Manager

Capítulo 2. Gestión del espacio de objetos protegidos 33

Definición de un espacio de objetos de base de datosAccess Manager le permite ampliar sus servicios de autorizaciones a objetos quepertenecen a un espacio de objetos de terceros definidos por el usuario. Es precisollevar a cabo dos pasos para integrar un espacio de objetos de terceros con AccessManager:v Describir el espacio de objetos de la aplicación de terceros para Access Manager.v Aplicar políticas de ACL y POP en cualquier objeto que requiera protección.

Los comandos pdadmin objectspace le permiten crear de manera simple regionesde espacio de objetos definidos por el usuario y gestionar los objetos contenidos enestos espacios. Los espacios de objetos definidos por el usuario creados con estoscomandos son dinámicos porque pueden actualizarse mientras se está ejecutandoAccess Manager.

Creación de un objeto contenedor nuevo definido por elusuario

Utilice los comandos pdadmin objectspace y object para gestionar espacios deobjetos definidos por el usuario. El comando objectspace crea un objeto de tipocontenedor.

Nota: Los espacios de objetos de Access Manager predeterminados (/WebSEAL y/Management) no pueden controlarse mediante los comandos pdadminobjectspace.

Sintaxis:pdadmin> objectspace create nombre descripción tipo

El nombre del espacio de objetos debe empezar con una barra inclinada (/).

La descripción aparece en Web Portal Manager.

El tipo puede ser una de las categorías siguientes:

Tipos de objeto

0 – desconocido1 – dominio seguro2 – archivo3 – programa ejecutable4 – directorio5 – conexión (junction)6 – servidor WebSEAL7 – no utilizado8 – no utilizado

9 – servidor HTTP10 – objeto no existente11 – objeto contenedor12 – objeto hoja13 – puerto14 – objeto contenedor de aplicaciones15 – objeto hoja de aplicación16 – objeto de gestión17 – no utilizado

La categoría del tipo sólo la utiliza Web Portal Manager para mostrar un iconoadecuado para el objeto.

Cuando se crea un objeto, debe especificarse un tipo. Puede seleccionar unacategoría adecuada o utilizar el tipo 0 para “desconocido”.

Por ejemplo:

34 IBM Tivoli Access Manager Base: Guía del administrador

pdadmin> objectspace create /Test-Space “New Object Space” 14pdadmin> objectspace list

/WebSEAL/Management/Management/Users/Management/Groups/Test-Space

Notas de administración:v Es mejor crear un espacio de objetos aparte para cada aplicación de terceros.v Debe definir el espacio de objetos nuevo antes de agregar objetos.v El atributo ispolicyattachable se establece automáticamente en la raíz del

espacio de objetos —que se crea al mismo tiempo que se define el espacio deobjetos—.

Creación y supresión de objetosUna vez se ha creado un espacio de objetos, puede rellenarlo con objetos.

Utilice los comandos pdadmin objects para gestionar objetos definidos por elusuario.pdadmin> object create nombre descripción tipo ispolicyattachable {yes|no}

Un objeto tiene los campos siguientes:

Argumento Descripción

Nombre Es la ubicación completa del objeto en el espacio de objetos,empezando por un nombre de espacio de objetos existente.

Descripción La descripción del texto del objeto.

Tipo El tipo del objeto que se ha de crear. Web Portal Manager loutiliza para mostrar un icono adecuado.

ispolicyattachable Indica si se puede asociar un POP al objeto. Si se establece en“no”, el objeto hereda la política desde arriba. Se utiliza parahacer que objetos hijo utilicen la misma política que el padre.

Por ejemplo:pdadmin> object create /Test-Space/folder1 “Folder 1” 14ispolicyattachable yes

pdadmin> object list /Test-Spacefolder1

pdadmin> object show /Test-Space/folder1Nombre: /Test-Space/folder1

Descripción: Folder 1Tipo: (Objeto contenedor de aplicaciones): 14La política se puede asociar: yes

pdadmin> object create /Test-Space/folder2 “Folder 2” 14ispolicyattachable no

pdadmin> object listandshow /Test-SpaceNombre: folder1

Descripción: Folder 1Tipo: (Objeto contenedor de aplicaciones): 14La política se puede asociar: yes

Nombre: folder2Descripción: Folder 2Tipo: (Objeto contenedor de aplicaciones): 14

Capítulo 2. Gestión del espacio de objetos protegidos 35

La política se puede asociar: no

pdadmin> object delete /Test-Space/folder1pdadmin> object list /Test-Space

folder2

Notas de administración:v Los objetos hijo no cambian de lugar cuando cambia el nombre de un objeto

padre. Por lo tanto, los objetos hijo pueden dejarse sin objetos padre. Cuandocambia el nombre de un objeto padre, debe cambiar de lugar todos los objetoshijo.

v Si no se completa el campo ispolicyattachable en el comando pdadmin objectcreate, el programa de utilidad presupone que tenía pensado utilizar el comandoobjectspace create. En lugar de un objeto se creará un espacio de objetos.

36 IBM Tivoli Access Manager Base: Guía del administrador

Capítulo 3. Utilización de políticas de control de accesos

Access Manager utiliza una representación virtual de los recursos del dominioseguro—denominada espacio de objetos protegidos. Los recursos puedenprotegerse definiendo políticas de seguridad especiales (reglas) y asociando talespolíticas a la representación de objeto de este recurso en el espacio de objetosprotegidos.

El tipo de política que define quién tiene acceso a un objeto, y que operacionespueden efectuarse en relación con el mismo, recibe el nombre de política de listade controles de accesos o política ACL. Las políticas ACL se utilizan paraidentificar la política de seguridad de una organización en los recursos quepertenecen al dominio seguro.

Este capítulo contiene los apartados siguientes:v “Conceptos básicos de la política de ACL” en la página 37v “Sintaxis de entrada de ACL” en la página 39v “Cómo el servicio de autorizaciones utiliza políticas de ACL” en la página 41v “Evaluación de una ACL” en la página 43v “Modelo de ACL esparcida: herencia de ACL” en la página 44v “Creación de acciones y grupos de acciones de ACL ampliados” en la página 49v “Políticas de ACL y espacio de objetos protegidos” en la página 52v “Permisos WebSEAL” en la página 52v “Permisos de gestión” en la página 53v “Permisos de objeto y espacio de objetos” en la página 60v “Políticas de ACL de administración predeterminadas” en la página 60

Conceptos básicos de la política de ACLUna política de lista de control de accesos (ACL) es un método que AccessManager utiliza para proporcionar protección estricta a recursos en el dominioseguro.

Una política de ACL es un conjunto de reglas, o permisos, que especifican lascondiciones necesarias para efectuar una operación en un objeto protegido. Unapolítica de ACL identifica las operaciones permitidas en un objeto protegido y listalas identidades (usuarios y grupos) que pueden efectuar estas operaciones.v Las identidades de usuarios y grupos están definidas en el registro de Access

Manager.v El espacio de objetos protegidos y las políticas de ACL están definidas en la base

de datos maestra de autorización.

Cada política de ACL tiene un nombre o una etiqueta exclusivos. Cada política deACL puede aplicarse a uno o más objetos.

Una política de ACL se compone de una o más entradas que incluyendesignaciones de usuarios y grupos y sus permisos específicos.

37

Entradas de política de ACLUna política de ACL se compone de una o más entradas que describen:v Los nombres de usuarios y grupos cuyo acceso al objeto se controla de manera

explícitav Las operaciones permitidas específicas para cada usuario, grupo o rolv Las operaciones permitidas específicas para las categorías de usuario cualquier

otro y no autenticado

Un usuario representa cualquier identidad de Access Manager autenticada.Generalmente, los usuarios representan usuarios de la red o servidores deaplicaciones.

Un grupo es una colección de uno o más usuarios. Un administrador de red puedeutilizar entradas de ACL de grupo para asignar de manera simple los mismospermisos a varios usuarios. Los usuarios nuevos del dominio seguro puedenacceder a objetos al convertirse en miembros de grupos adecuados. De esta manerano es necesario crear nuevas entradas de ACL para cada usuario nuevo. Losgrupos pueden representar divisiones o departamentos organizativos en undominio seguro. Los grupos también se utilizan para definir roles o asociacionesfuncionales

Los usuarios y grupos reciben el nombre genérico de entidades.

Las entradas de usuario y grupos en ACL se almacenan realmente utilizando unidentificador exclusivo (UUID). El UUID proporciona seguridad adicional en casode que se suprima un usuario o un grupo del dominio y se vuelva a crear, acontinuación, con el mismo nombre. Por ejemplo, aunque un usuario nuevo tengael mismo nombre que el usuario suprimido, Access Manager asigna un UUIDnuevo a dicho usuario. Puesto que el UUID es nuevo, cualquier ACL existente quehaga referencia al nombre de usuario antiguo no concede ningún derecho alusuario nuevo. Server Policy (pdmgrd) elimina los UUID antiguos de las ACL (deusuarios y grupos suprimidos) de manera silenciosa.

Se puede utilizar el programa de utilidad pdadmin o Web Portal Manager paracrear, modificar y suprimir entradas de ACL.

Creación y gestión de políticas de ACLSe puede utilizar Web Portal Manager o el comando pdadmin acl create para crearuna política de ACL única y guardarla con un nombre. A continuación, se puedeaplicar una política de seguridad asociando la ACL a objetos en el espacio deobjetos protegidos.

Figura 16. Lista de control de accesos para un objeto de página web

38 IBM Tivoli Access Manager Base: Guía del administrador

La ACL pasa a ser una política fuente simple (como una fórmula o una receta) quecontiene las entradas específicas que proporcionan el nivel de protección correcto atodos los objetos asociados con ella. Si cambian los requisitos de seguridad, sólotiene que editar la ACL simple. La nueva definición de seguridad se implementa alinstante para todos los objetos afectados por esta ACL.

Sintaxis de entrada de ACLUna entrada de ACL contiene dos o tres atributos, dependiendo del tipo deentrada de ACL y aparece en el formato siguiente:

v Tipo – la categoría de entidad (usuario o grupo) para la que se creó la ACLv ID (Identidad) – el identificador exclusivo(nombre) de la entidad

El atributo de ID no es necesario para los tipos de entrada de ACL cualquierotro y no autenticado

v Permisos (o acciones) – el conjunto de operaciones que este usuario o grupopermite en el objeto

La mayoría de permisos indican la posibilidad del cliente de efectuar unaoperación específica en el recurso.

En el ejemplo anterior, el usuario adam (tipo = usuario, ID = adam) tiene permisopara leer (ver) el objeto que esta política de ACL protege. El permiso r permite laoperación de lectura. El permiso T fuerza la regla de atravesar.

Atributo de tipoUn tipo de entrada de ACL identifica el usuario, el grupo o la entidad especialpara una entrada de ACL específica. Existen cuatro tipos de entrada de ACL.

Tipo Descripción

usuario Establece permisos para un usuario específico en el dominio seguro. El usuario debeser un miembro del dominio seguro con una cuenta en el registro. El tipo de entradade usuario requiere un nombre de usuario (ID). El formato de entrada es: usuario IDpermisos

Por ejemplo:

usuario anthony -------T-----r-

grupo Establece permisos para todos los miembros de un grupo específico en el dominioseguro. El tipo de entrada de grupo requiere un nombre de grupo (ID). El formato deentrada es: grupo ID permisos

Por ejemplo:

grupo ingeniería -------T-----r-

Figura 17. Atributos de entrada de ACL

Capítulo 3. Utilización de políticas de control de accesos 39

Tipo Descripción

cualquier otro(también conocido comocualquier autenticado)

Establece permisos para todos los usuarios autenticados. No se requiere que seespecifique el ID. El formato de entrada es: cualquier otro permisos

Por ejemplo:

cualquier otro -------T-----r-

no autenticado Establece permisos para aquellos usuarios que el servidor de seguridad no haautenticado. No se requiere que se especifique el ID. El formato de entrada es: noautenticado permisos

Por ejemplo:

no autenticado -------T-----r-

Esta entrada de ACL es una máscara (una operación “and” a nivel de bit) contra laentrada de ACL cualquier otro para determinar el conjunto de permisos. Sólo seconcede un permiso para no autenticado si éste aparece también en la entradacualquier otro. Por ejemplo, la entrada de ACL no autenticado siguiente:

no autenticado -------------rw

para la que se ha creado una máscara contra esta entrada de ACL cualquier otro:

cualquier otro -------T-----r-

proporciona estos permisos:

-------------r- (sólo lectura).

Atributo de IDEl ID de entrada de ACL es el identificador o nombre exclusivo para un tipo deentrada de usuario o grupo. Los ID deben representar usuarios y/o grupos válidoscreados para el dominio seguro y almacenados en la base de datos de registro.

Ejemplos:usuario michael

usuario anthony

grupo ingeniería

grupo documentación

grupo contabilidad

Nota: El atributo de ID no se utiliza para los tipos de entrada de ACL cualquierotro y no autenticado.

Atributo de permisos (acciones)Cada entrada de ACL contiene un conjunto de permisos (o acciones) que describenlas operaciones específicas permitidas en el objeto para el usuario o grupo.

Las políticas de ACL controlan recursos protegidos de las maneras siguientes:v La capacidad de un usuario para efectuar operaciones en objetos protegidosv La capacidad de un administrador para cambiar reglas de control de acceso en el

objeto y en cualquier subobjetov La capacidad de Access Manager para delegar credenciales del usuario

40 IBM Tivoli Access Manager Base: Guía del administrador

Nota: Los permisos de ACL son sensibles al contexto — el funcionamiento dedeterminados permisos varía según la región del espacio de objetosprotegidos en la que se aplican. Por ejemplo, el permiso m tiene unsignificado diferente en un objeto WebSEAL que en un objeto de gestión.

Permisos (acciones) de Access Manager predeterminadosAccess Manager define diecisiete permisos (acciones) predeterminados. Web PortalManager divide estos permisos en tres categorías.

Base Genérica WebSEALa A b B c g N t T W d m s v l r x

Bit de acción Descripción Categoría

a Asociar Base

A Agregar Base

b Examinar Base

B Ignorar hora del día Base

c Controlar Base

d Suprimir Genérica

g Delegación Base

l Listar directorio WebSEAL

m Modificar Genérica

N Crear Base

r Leer WebSEAL

s Administración de servidor Genérica

t Rastrear Base

T Atravesar Base

v Ver Genérica

W Contraseña Base

x Ejecutar WebSEAL

Access Manager proporciona la posibilidad de definir muchos más permisos(acciones) adicionales para aplicaciones de terceros. Consulte el apartado “Creaciónde acciones y grupos de acciones de ACL ampliados” en la página 49.

Cómo el servicio de autorizaciones utiliza políticas de ACLAccess Manager se basa en políticas de ACL para especificar las condicionesnecesarias para efectuar una operación en un objeto protegido.

Cuando una ACL se asocia a un objeto, las entradas de la ACL especifican quéoperaciones están permitidas en este objeto y quién puede realizarlas.

Access Manager utiliza un conjunto de permisos predeterminado para un ampliorango de operaciones. Los permisos se representan mediante caracteres ASCIIsimples que pueden imprimirse (a-z, A-Z). Cada permiso se muestra (mediantepdadmin o Web Portal Manager) con una etiqueta que describe la operación que

Capítulo 3. Utilización de políticas de control de accesos 41

lleva a cabo. Además, Web Portal Manager agrupa las ACL de acuerdo a cómo seutilizan en una parte concreta del espacio de objetos (WebSEAL) o en todo elespacio de objetos (Base, Genérica).

Realización de operaciones en un objetoEl software de aplicaciones suele contener una o más operaciones que se llevan acabo en objetos protegidos. Access Manager necesita estas aplicaciones paraefectuar llamadas al servicio de autorizaciones antes de que a la operaciónsolicitada se le permita continuar. Estas llamadas se llevan a cabo a través de laAPI tanto para servicios de Access Manager (por ejemplo, WebSEAL) como paraaplicaciones de terceros.

El servicio de autorizaciones utiliza la información contenida en la ACL para crearuna respuesta yes o no simple a la pregunta: ¿Tiene este usuario (grupo) elpermiso r (por ejemplo) para ‘ver’ el objeto solicitado

Es importante tener presente que el servicio de autorizaciones no sabe nada acercade la operación que requiere el permiso r. Lo único que tiene en cuenta es lapresencia, o no, del permiso r en la entrada de ACL del usuario o gruposolicitante.

Esta es realmente de una característica importante del servicio de autorizaciones. Elservicio es completamente independiente de las operaciones que se estánsolicitando. Este es el motivo por el que es fácil trasladar las ventajas del serviciode autorizaciones a aplicaciones de terceros.

Requisitos para permisos personalizadosLos permisos (acciones) de Access Manager predeterminados están disponiblespara aplicaciones de terceros. Si una aplicación de terceros utiliza un permiso deAccess Manager predeterminado, la operación asociada debe ser similar a laoperación real que Access Manager realiza de manera habitual. Por ejemplo, r sólodebe utilizarlo una operación que requiere un acceso de solo lectura en un objetoprotegido.

Nota: Una aplicación de terceros puede utilizar, por supuesto, un permiso deAccess Manager predeterminado para una operación no relacionada, ya queal servicio de autorizaciones no le afecta dicha operación. Sin embargo, estasituación ocasionaría cierta dificultad a un administrador que tuviera quedistinguir dos maneras diferentes de utilizar el mismo permiso.

Si una aplicación de terceros utiliza una operación que no está bien representadapor ninguno de los permisos predeterminados, Access Manager le permite definirun permiso (acción) nuevo que esta aplicación puede utilizar y que el servicio deautorizaciones puede reconocer.

Consulte el apartado “Creación de acciones y grupos de acciones de ACLampliados” en la página 49.

Ejemplo de acción personalizadaEn este ejemplo, se requiere proteger un determinado dispositivo de impresióncontra el uso no autorizado. El servicio de cola de impresión de terceros estáescrito con la API de autorización, de manera que puede llamar al servicio deautorizaciones para efectuar comprobaciones de ACL a partir de peticionesefectuadas a la impresora.

42 IBM Tivoli Access Manager Base: Guía del administrador

Los permisos de Access Manager estándar no incluyen un permiso específico paraproteger impresoras. Sin embargo, se puede proteger la impresora mediante unpermiso creado recientemente (p en este ejemplo).

Una política de ACL está asociada al objeto de impresora. Si un usuario solicita lautilización de la impresora protegida, dicho usuario debe tener una entrada deACL que contenga el permiso p. El servicio de autorizaciones devuelve unarespuesta favorable si el permiso p está presente, por lo que la operación deimpresión seguirá su curso. Si el servicio de autorizaciones detecta que no existeningún permiso p para este usuario, no se permitirá que la operación de impresiónsiga su curso.

Evaluación de una ACLAccess Manager sigue un proceso de evaluación específico para determinar lospermisos que una ACL concede a un usuario concreto. Cuando entienda esteproceso, podrá determinar la manera más adecuada de impedir a ciertos usuariosacceder a recursos.

Evaluación de peticiones autenticadasAccess Manager evalúa una petición de usuario autenticado siguiendo este orden:1. Busca la coincidencia del ID de usuario con las entradas de usuario de la ACL.

Los permisos concedidos son los de la entrada coincidente.Coincidencia satisfactoria: la evaluación se detiene aquí. Coincidencia no satisfactoria:siga con el paso siguiente.

2. Determina el grupo o los grupos al que pertenece el usuario y busca quecoincidan con las entradas de grupo de la ACL:Si la coincidencia tiene lugar en más de un grupo, los permisos resultantes sonun “or” lógico (el más permisivo) de los permisos que concede cada entradacoincidente.Coincidencia satisfactoria: la evaluación se detiene aquí. Coincidencia no satisfactoria:siga con el paso siguiente.

3. Concede los permisos de la entrada cualquier otro (si existe).Coincidencia satisfactoria: la evaluación se detiene aquí. Coincidencia no satisfactoria:siga con el paso siguiente.

4. Existe una entidad cualquier otro implícita cuando no hay ninguna entrada deACL cualquier otro. Esta entrada implícita no concede permisos.Coincidencia satisfactoria: no se ha concedido ningún permiso. Fin del proceso deevaluación.

Figura 18. Acción de cola de impresión personalizada

Capítulo 3. Utilización de políticas de control de accesos 43

Evaluación de peticiones no autenticadasAccess Manager evalúa un usuario no autenticado concediendo los permisos de laentrada no autenticado de la ACL.

La entrada no autenticado es una máscara (una operación “and” a nivel de bit)contra la entrada cualquier otro cuando se han determinado permisos. Sólo seconcede un permiso para no autenticado si el permiso también aparece en laentrada cualquier otro.

Puesto que no autenticado depende de cualquier otro, no tiene sentido que unaACL contenga no autenticado sin cualquier otro. Si una ACL contiene noautenticado sin cualquier otro, la respuesta predeterminada es no conceder ningúnpermiso a no autenticado.

Ejemplo de entradas de ACLLos permisos para usuarios y grupos específicos se establecen especificando el tipode entrada de ACL adecuado. En el ejemplo siguiente, el grupo documentacióntiene todos los privilegios de acceso:grupo documentación --bcg--Tdmsv--lrx

Puede restringir el acceso a otros usuarios no autenticados en el dominio seguro(que no pertenecen al grupo documentación) utilizando el tipo de entradacualquier otro:cualquier otro -------T-------rx

Más adelante puede restringir el acceso al tipo de entrada no autenticado ausuarios que no son miembros del dominio seguro.no autenticado -------T-------r-

Nota: Sin una entrada de ACL no autenticado, los usuarios no autenticados nopueden acceder a ningún documento seguro del dominio seguro.

Modelo de ACL esparcida: herencia de ACLPara proteger recursos de red en un espacio de objetos protegidos, cada objetodebe estar protegido por una política de lista de control de accesos (ACL).

Puede asignar una política de ACL a un objeto de una de estas dos maneras:v Asociar una política de ACL explícita al objeto.v Permitir al objeto heredar su política de ACL de un objeto contenedor que le

preceda en la jerarquía.

Aplicar un esquema de ACL heredada puede reducir de manera significativa lastareas de administración en un dominio seguro. Este apartado trata sobre losconceptos de ACL heredadas y esparcidas.

Conceptos del modelo de ACL esparcidaLa potencia de la funcionalidad de herencia de ACL se basa en los dos principiossiguientes: cualquier objeto sin una política de ACL asociada explícitamente heredala política de su objeto contenedor más cercano con una ACL establecidaexplícitamente. Es decir, todos los objetos sin una ACL asociada explícitamente la

44 IBM Tivoli Access Manager Base: Guía del administrador

heredan de objetos contenedor con una ACL asociada explícitamente. Cuandoasocia una ACL explícita a un objeto se interrumpe una cadena de herenciaconcreta.

La herencia de ACL simplifica la tarea de establecer y mantener controles de accesoen un espacio de objetos protegidos de gran tamaño. En un espacio de objetoshabitual, sólo necesita asociar unas cuantas ACL en ubicaciones clave para protegertodo el espacio de objetos; en esta caso se aplica un modelo de ACL esparcida.

Un espacio de objetos habitual empieza con una sola ACL explícita asociada alobjeto contenedor raíz. La ACL raíz debe existir siempre y no puede eliminarsenunca. Normalmente, se trata de una ACL con muy pocas restricciones. Todos losobjetos situados en el espacio de objetos inferior heredan esta ACL.

Cuando una región o un subárbol del espacio de objetos requiera restricciones decontrol de acceso diferentes, asocie una ACL explícita en la raíz de este subárbol.Esto interrumpe el flujo de ACL heredadas de la raíz del espacio de objetosprimarios a este subárbol. Una nueva cadena de herencia empieza a partir de estaACL explícita creada recientemente.

La política de ACL raíz predeterminadaAccess Manager comprueba la herencia que empieza con la raíz del espacio deobjetos protegidos. Si no establece las ACL de manera explícita en cualquier otroobjeto del árbol, el árbol entero hereda esta ACL raíz.

Siempre hay una política de ACL establecida en la raíz del espacio de objetosprotegidos. Un administrador puede sustituir esta ACL por otra que contengaentradas y valores de permisos diferentes. Sin embargo, la ACL raíz no puedeeliminarse nunca completamente.

La política de ACL raíz se establece explícitamente durante la instalación yconfiguración inicial de Access Manager.

Las entradas esenciales para la ACL raíz predeterminada —default-root—incluyen:Grupo iv-admin TcmdbvaCualquier otro TNo autenticado T

Permiso traverseEl control de accesos de Access Manager depende de dos condiciones.1. La ACL que controla el objeto solicitado debe contener permisos de acceso

adecuados para el usuario que efectúa la solicitud.2. El usuario que efectúa la solicitud debe poder acceder al objeto solicitado.

La posibilidad de acceder a objetos protegidos se controla mediante el permisotraverse (T).

El permiso traverse sólo se aplica a objetos contenedor en el espacio de objetosprotegidos. El permiso traverse especifica que un usuario, grupo, cualquier otro ono autenticado identificados en la entrada de ACL tiene permiso para pasar através de este objeto contenedor para acceder a un objeto de recurso protegidoinferior en la jerarquía.

Capítulo 3. Utilización de políticas de control de accesos 45

Un peticionario puede acceder a un objeto protegido si tiene el permiso traverse encada ACL asociada a objetos contenedor superiores al recurso solicitado en la rutade acceso al directorio raíz, incluido éste.

En el ejemplo siguiente se muestra cómo funciona el permiso traverse. En lacorporación ACME, existe un objeto contenedor Engineering (directorio), quetambién contiene un objeto contenedor TechPubs (subdirectorio). El usuario kate,un miembro del departamento de ventas, solicita el permiso traverse para accederal directorio Engineering/TechPubs al objeto de revisar un archivo de notas delrelease. El administrador proporciona traverse para cualquier otro en la raíz. Eladministrador proporciona traverse para grupo sales en el directorio Engineering.El directorio TechPubs hereda la ACL del directorio Engineering. Aunque Kate notiene otros permisos en estos dos directorios, puede pasar a través (traverse) deellos para acceder al archivo nota_release. Puesto que este archivo tiene permisode lectura para usuario kate, Kate puede ver el archivo.

Puede restringir el acceso a la jerarquía inferior a un objeto contenedordeterminado — sin restablecer permisos individuales en este objeto. Tan solo ha deeliminar el permiso traverse de la entrada de ACL adecuada. Eliminar el permisotraverse en un objeto de directorio protege todos los objetos inferiores de lajerarquía, incluso si contienen otras ACL menos restrictivas.

Por ejemplo, si el grupo sales no tuviera el permiso traverse en el directorioEngineering, Kate no podría acceder al archivo de nota de release aunque tuvierapermiso de lectura para dicho archivo.

Resolución de una petición de accesoLa herencia empieza con la ACL raíz y afecta a todos los objetos del espacio deobjetos hasta que alcanza un objeto con una ACL explícita. Una nueva cadena deherencia empieza a partir de este momento.

Figura 19. Permiso traverse

46 IBM Tivoli Access Manager Base: Guía del administrador

Los objetos inferiores en una ACL establecida explícitamente heredan los nuevoscontroles de acceso. Si suprime una ACL explícita, el control de acceso para todoslos objetos revierte en el objeto contenedor o directorio más cercano con una ACLestablecida explícitamente.

Cuando un usuario intenta acceder a un objeto seguro (como un documento web),Access Manager comprueba si el usuario tiene los permisos para acceder a dichoobjeto. Esto lo hace comprobando todos los objetos que hay junto a la jerarquía deobjetos para los permisos heredados o establecidos explícitamente adecuados.

A un usuario se le deniega acceso a un objeto si cualquier objeto contenedor odirectorio de la jerarquía superior no incluye el permiso traverse para este usuario.También se le deniega el acceso si el objeto destino no contiene permisossuficientes para efectuar la operación solicitada.

Para que una comprobación de acceso sea satisfactoria, el peticionario debe tener:1. Permiso traverse para la ruta de acceso al objeto solicitado.2. Permisos adecuados para el objeto solicitado.

El ejemplo siguiente muestra el proceso de determinar si un usuario puede leer(ver) un objeto:/acme/engineering/project_Y/current/report.html

Access Manager comprueba los siguiente:1. Permiso traverse en la ACL raíz (/) establecida explícitamente.2. Permiso traverse en cualquier ACL explícita asociada a los directorios: acme,

engineering, proyect_Y y current.3. Permiso de lectura para el archivo mismo (report.html).

Al usuario se le deniega acceso si la comprobación de acceso no es satisfactoria encualquiera de estos puntos de la jerarquía de objetos.

Aplicación de políticas de ACL en diferentes tipos de objetoEn una política de ACL se pueden establecer permisos para varias operaciones.Sólo un subconjunto de estas posibles operaciones puede ser relevante para unobjeto específico al que la ACL está asociada.

Esto se debe en parte a las dos características de Access Manager que estándiseñadas para simplificar la administración:v Políticas de ACLv Herencia de ACL

Las políticas de ACL le permiten asociar las misma definición de ACL a variosobjetos en el espacio de objetos protegidos. La definición de ACL tiene las entradassuficientes para reunir los requisitos de todos los objetos para los que se aplica laACL; sin embargo, a cada uno de los objetos sólo podría afectarle unas pocasentradas.

En el modelo de herencia de ACL, cualquier objeto sin una política de ACLexplícita asociada “hereda” las definiciones de política de la ACL más cercanaaplicadas a un objeto superior en la jerarquía.

En resumen, una política de ACL tiene que describir los permisos necesarios paratodos los tipos de objetos a los que se aplica; no sólo el objeto al que está asociado.

Capítulo 3. Utilización de políticas de control de accesos 47

Ejemplo de herencia de política de ACLLa figura siguiente muestra cómo afecta la combinación de ACL heredadas yexplícitas en un espacio de objetos corporativo.

Un espacio de objetos corporativo tiene un conjunto de políticas de seguridadgeneral en el objeto raíz. Raíz va seguido del objeto contenedor /WebSEAL y desubárboles de departamento controlados.

En este ejemplo, al grupo sales se le proporciona la propiedad de su subárbol dedepartamento. Tenga en cuenta que la ACL de este subárbol ya no reconoce lasentradas de tipo no autenticado o cualquier otro.

El archivo de ventas del año hasta la fecha (ytd.html) tiene una ACL explícita queconcede permiso de lectura a miembros del grupo sales-vp (que también sonmiembros del grupo sales).

Nota: No es necesario modificar este esquema de ACL con la adición o supresiónde usuarios en el dominio seguro. Los usuarios nuevos se agregansimplemente al grupo o grupos adecuados. De la misma manera, se puedeneliminar usuarios de dichos grupos.

Directrices para un espacio de objetos segurosv Establezca una política de seguridad de alto nivel para objetos contenedor en la

parte superior del espacio de objetos. Establezca excepciones a esta política conuna ACL explícita para objetos inferiores en la jerarquía.

v Organice el espacio de objetos protegidos de manera que la mayoría de objetosestén protegidos por ACL heredadas en lugar de por ACL explícitas.Las ACL heredadas simplifican el mantenimiento del árbol porque reducen elnúmero de ACL que se deben mantener. Este mantenimiento de nivel inferiorreduce el riesgo de errores que podrían comprometer la red.

Figura 20. Ejemplo de herencia de ACL

48 IBM Tivoli Access Manager Base: Guía del administrador

v Coloque objetos nuevos en el árbol en el que heredan los permisos adecuados.Disponga el árbol de objetos en un conjunto de subárboles, en el que cadasubárbol esté controlado por una política de acceso específica. Determine lapolítica de acceso para un subárbol completo estableciendo una ACL explícita enla raíz del subárbol.

v Cree un conjunto de políticas de ACL esencial y vuelva a utilizar estas ACLcuando sea necesario.Puesto que una política de ACL es una definición de una sola fuente, cualquiermodificación a la política afectará a todos los objetos asociados a esta ACL.

v Controle el acceso de usuarios utilizando grupos.Puede que una ACL sólo se componga de entradas de grupos. El acceso a unobjeto por usuarios individuales puede controlarse de manera eficaz agregandoo eliminando usuarios de estos grupos.

Creación de acciones y grupos de acciones de ACL ampliadosEn este apartado, la palabra “acción” tiene el mismo significado que la palabra“permisos,” utilizada en los apartados anteriores.

Cada permiso de Access Manager se define como una acción. Hay diecisieteacciones predefinidas que pueden utilizarse para obtener una funcionalidadinmediata (consulte el apartado “Permisos (acciones) de Access Managerpredeterminados” en la página 41). También se pueden definir acciones nuevaspara aplicaciones de terceros.

En este apartado se describe cómo definir grupos de acciones que actúan comocontenedores para un conjunto de acciones personalizadas ampliado:v Cada grupo de acciones puede mantener hasta 32 bits de acción.v Un bit de acción se compone de una letra: a-z, A-Z.v Cada carácter de bit de acción sólo puede utilizarse una vez en un grupo de

acciones.v Se puede volver a utilizar el mismo bit de acción en otros grupos de acciones.v Las acciones de Access Manager predeterminadas se almacenan en un grupo de

acciones predefinido llamado “primario”.

Access Manager soporta 32 grupos de acciones (incluido el grupo de accionesprimario) para 1.024 acciones concretas.

Figura 21. Grupo de acciones primario

Capítulo 3. Utilización de políticas de control de accesos 49

Creación de un grupo de acciones nuevoUtilice el comando pdadmin action group create para crear un grupo de accionesnuevo:pdadmin> action group create test-grouppdadmin> action group list

primarytest-group

pdadmin> action group delete test-grouppdadmin> action group list primary

El grupo de acciones primario siempre aparece en una lista de grupos y no puedesuprimirse.

Debe tener una entrada en una ACL en el objeto /Management/ACL con el permisomodify (m) para crear grupos de acciones y el permiso delete (d) para suprimirgrupos de acciones.

Creación de acciones nuevas en un grupo de accionesUtilice el comando pdadmin action create para crear una acción nueva en ungrupo de acciones.pdadmin> action create nombre_acción etiqueta_acción tipo_acción nombre_grupo_acciones

Opción Descripción

nombre_acción Letra que representa la acción (permiso).

etiqueta_acción Etiqueta descriptiva para esta acción. Aparece en un comandopdadmin action list y en Web Portal Manager.

tipo_acción Categoría de acción (que Web Portal Manager utiliza paraagrupar bits de acción comunes). Base, Genérica y WebSEALson categorías predeterminadas.

nombre_grupo_acciones El grupo de acciones al que pertenece esta acción nueva. Si nose especifica este argumento, la acción se asigna al grupo deacciones “primario”.

Por ejemplo:pdadmin> action create P Test-Action Special test-grouppdadmin> action list test-group P Test-Action Specialpdadmin> action delete P test-grouppdadmin> action list test-grouppdadmin>

Figura 22. Grupos de acciones múltiples

50 IBM Tivoli Access Manager Base: Guía del administrador

Especificación de acciones personalizadas en entradas deACL

Tal como se dijo en “Sintaxis de entrada de ACL” en la página 39, las entradas deACL contienen un tipo de entrada, un ID de tipo (para tipos de usuario y degrupo) y el conjunto de bits de acción permitidos.

Debe utilizar una sintaxis especial para identificar bits de acción personalizadosque pertenecen a grupos de acciones distintos al grupo de acciones “primario”. Lascadenas de acción que representan los bits de acción de varios grupos de accionesaparecen el formato siguiente:<acción>...<acción>[<grupo-acciones>]<acción>...<acción>,,,

Por ejemplo:

abgTr[grupoA]Pq[grupoB]Rsy[grupoC]abv El primer conjunto de bits de acción (abgTr) representa permisos del grupo de

acciones “primario” (el predeterminado de Access Manager).v El grupo de acciones A contiene las acciones P y q.v El grupo de acciones B contiene las acciones R, s e y.v El grupo de acciones C contiene las acciones a y b.v Tenga en cuenta que el grupo de acciones C contiene los bits de acción que

utilizan las mismas letras que los bits de acción del grupo “primario”.Puesto que los bits de acción están asociados a un grupo de acciones específico(C), los bits de acción a y b tienen identidades exclusivas y pueden representar amuchos permisos diferentes de los bits de acción a y b en el grupo de acciones“primario”.

EjemploMostrar grupos de accionespdadmin>pdadmin> action group list

primarytest-group

Listar acciones en el grupo de acciones “test-group”pdadmin> action list test-group

P Test-Action SpecialS Test-Action2 Special

Listar políticas de ACLpdadmin> acl list

default-websealdefault-roottestdefault-replicadefault-management

Mostrar detalles de la ACL “test”pdadmin> acl show test

Nombre de ACL: testDescripción:Entradas:

Usuario sec_master TcmdbvaGrupo ivmgrd-servers TlCualquier otro r

Capítulo 3. Utilización de políticas de control de accesos 51

Agregar una entrada de ACL para el usuario Kate que contiene acciones de losgrupos de acciones “primario” y “test-group”pdadmin> acl modify test set user kathy brT[test-group]PSpdadmin> acl show test

Nombre de ACL: testDescripción:Entradas:Usuario sec_master TcmdbvaGrupo ivmgrd-servers TlCualquier otro rUsuario kathy Tbr[test-group]PS

Políticas de ACL y espacio de objetos protegidosLos objetos contenedor representan regiones específicas del espacio de objetosprotegidos y cumplen dos funciones de seguridad importantes:1. Se puede utilizar la ACL del objeto contenedor para definir políticas de alto

nivel para todos los subobjetos de la región cuando no se aplica ninguna otraACL explícita.

2. Puede denegar acceso de manera rápida a todos los objetos de una regióneliminando el permiso traverse de la ACL del objeto contenedor.

Objeto contenedor raí z ( / )Para el objeto raíz se aplican las siguientes consideraciones de seguridad:v El objeto raíz empieza la cadena de herencia de ACL para todo el espacio de

objetos protegidos.v Si no aplica ninguna otra ACL explícita, el objeto raíz define (a través de la

herencia) la política de seguridad para todo el espacio de objetos.v El permiso traverse es necesario para acceder a cualquier objeto inferior a raíz.

El permiso traverseEl permiso traverse es un permiso genérico que se aplica en el espacio de objetosprotegidos.

Operación Descripción

T traverse Cuando se aplica a un objeto contenedor, permite alpeticionario pasar de manera jerárquica a través del objetocontenedor hacia el objeto de recurso solicitado. No permiteningún otro tipo de acceso al objeto contenedor. Traverse noes necesario en el objeto de recurso solicitado en sí.

Permisos WebSEALPara el contenedor /WebSEAL del espacio de objetos protegidos se aplican lassiguientes consideraciones de seguridad:v El objeto WebSEAL empieza la cadena de herencia de ACL para la región

WebSEAL del espacio de objetos.v Si no aplica ninguna otra ACL explícita, este objeto define (a través de la

herencia) la política de seguridad para todo el espacio web.v El permiso traverse es necesario para acceder a este objeto y a cualquier otro

objeto inferior a este punto.

52 IBM Tivoli Access Manager Base: Guía del administrador

/WebSEAL/hostEste subárbol contiene el espacio web de un servidor WebSEAL concreto. Lassiguientes consideraciones de seguridad se aplican a este objeto:v El permiso traverse es necesario para el acceso a cualquier objeto a partir de este

puntov Si no aplica ninguna otra ACL explícita, este objeto define (a través de la

herencia) la política de seguridad para todo el espacio de objetos de estamáquina

/WebSEAL/host/fileSe trata del objeto de recurso seleccionado para el acceso HTTP. Los permisosseleccionados dependerán de la operación que se solicite.

Permisos WebSEALLa tabla siguiente describe los permisos ACL aplicables para la región WebSEALdel espacio de objetos:

Operación Descripción

r read Permite ver el objeto web.

x execute Ejecuta el programa CGI.

d delete Elimina el objeto web del espacio web.

m modify Realiza la transferencia (PUT) de un objeto HTTP. (Colocar -publicar - un objeto HTTP en el espacio de objetos deWebSEAL.)

l list Lo necesita Policy Server para generar una lista automáticade directorios del espacio web.

g delegation Concede fiabilidad a un servidor WebSEAL para que actúeen nombre de un cliente y pase esta petición a un servidorWebSEAL con conexión (junction).

Permisos de gestiónLa región de gestión del espacio de objetos protegidos contiene varios objetoscontenedor de subgestión que requieren conjuntos de permisos específicos:v “Permisos /Management/ACL” en la página 54v “Permisos /Management/Action” en la página 55v “Permisos /Management/POP” en la página 55v “Permisos /Management/Server” en la página 56v “Permisos /Management/Config” en la página 56v “Permisos /Management/Policy” en la página 57v “Permisos /Management/Replica” en la página 57v “Permisos /Management/Users” en la página 58v “Permisos /Management/Groups” en la página 58v “Permisos /Management/GSO” en la página 59

Para la región /Management del espacio de objetos protegidos se aplican lassiguientes consideraciones de seguridad:v El objeto de gestión empieza la cadena de herencia de ACL para toda la región

del espacio de objetos.

Capítulo 3. Utilización de políticas de control de accesos 53

v Si no aplica ninguna otra ACL explícita, este objeto define (a través de laherencia) la política de seguridad para todo el espacio de objetos de gestión.

v El permiso traverse es necesario para acceder a /Management.

Permisos /Management/ACLEste objeto permite a los usuarios de administración efectuar tareas de gestión deACL de alto nivel que pueden afectar a la política de seguridad del dominioseguro.

Operación Descripción

a attach Asocia políticas de ACL a objetos y elimina políticas de ACLde objetos.

acl attachacl detach

c control Propiedad de la política de ACL; permite crear, suprimir ymodificar entradas para esta ACL.

acl modify

d delete Suprime una política de ACL existente. La entrada de ACLpara este usuario también debe contener el permiso control(c).

acl delete

m modify Crea una política de ACL nueva.

acl create

v view Busca y lista ACL y muestra sus detalles. Este permiso debeestar en una entrada de una ACL asociada a/Management/ACL.

acl findacl listacl show

Debe crear entradas de administrador de ACL en la política de ACLpredeterminada para el objeto /Management/ACL. La entrada de ACL deladministrador puede contener cualquiera de los permisos anteriores. Estospermisos permiten al administrador crear políticas de ACL nuevas, asociar ACL aobjetos y suprimir políticas de ACL.

Un administrador de ACL no puede modificar una ACL existente a menos quehaya una entrada en esta ACL para el administrador que contenga el permisocontrol (c). Sólo el propietario de una ACL puede modificar sus entradas.

Tenga en cuenta que el creador de una política de ACL nueva (m en/Management/ACL) pasa a ser la primera entrada de esta ACL —con los permisos

TcmdbsvaBlNWA establecidos de forma predeterminada.

Por ejemplo, si sec_master es una entrada de administrador en la ACLdefault-management, con el permiso m, sec_master puede crear una política deACL nueva. El usuario sec_master se convierte en la primera entrada de la ACLnueva, con permisos TcmdbsvaBlNWA.

El permiso control (c) proporciona a sec_master la propiedad de la ACL y permitea sec_master modificar la ACL. A continuación, el usuario sec_master podríaconceder permisos de administración a otras entradas de usuario en esta ACL.

54 IBM Tivoli Access Manager Base: Guía del administrador

La propiedad de la ACL de default-management se proporciona tanto al usuariosec_master como al grupo iv-admin de forma predeterminada.

El permiso control (c)El permiso control es un potente permiso que le proporciona la propiedad de unapolítica de ACL. Control le permite modificar las entradas de la ACL. Esto significaque puede crear y suprimir entradas y conceder y denegar permisos.

Si un administrador quiere suprimir una ACL de la lista de políticas de ACL debetener una entrada en esta ACL y el permiso control establecido en dicha entrada.

El permiso control le permite conceder funciones de administrador a otro usuario,como la posibilidad de asociar (a) esta ACL a objetos. Debe actuar con muchaprecaución a la hora de utilizar el permiso control debido a sus potentescaracterísticas de propiedad.

El permiso control sólo es importante en el espacio /Management/ACL.

Permisos /Management/ActionEste objeto permite a los usuarios de administración gestionar acciones y gruposde acciones personalizadas. Las tareas de acción y los permisos asociados son:

Operación Descripción

d delete Suprime una acción o un grupo de acciones existente.

action deleteaction group delete

m modify Crea una acción o un grupo de acciones nuevo.

action createaction group create

Nota: Los comandos siguientes no requieren permisos especiales:v action list

v action group list

Access Manager proporciona servicios de autorizaciones a aplicaciones. Lasaplicaciones que forman parte de la familia Access Manager incluyen, por ejemplo,WebSEAL (para aplicaciones web) y Access Manager for Business Integration (paraaplicaciones de envío de mensajes).

Las aplicaciones de terceros pueden efectuar llamadas al servicio de autorizacionesa través de la API de autorización. Es necesario llevar a cabo dos pasos paraintegrar una aplicación de terceros con el servicio de autorizaciones:v Definir el espacio de objetos de la aplicaciónv Aplicar permisos en objetos (recursos) que necesitan protección

El administrador del espacio de objetos de una aplicación de terceros puedeutilizar el programa de utilidad pdadmin para definir acciones y permisos nuevos.El administrador debe tener los permisos m y d de Management/Action para crear ysuprimir estos permisos y acciones.

Permisos /Management/POPEste objeto permite a los usuarios de administración gestionar políticas de objetosprotegidos. Todos los permisos deben aparecer en entradas de ACL en

Capítulo 3. Utilización de políticas de control de accesos 55

/Management/POP. Las tareas de acción y los permisos asociados son:

Operación Descripción

a attach Asocia una POP a un objeto.

pop attachpop detach

d delete Suprime una POP.

pop delete

m modify Crea POP y modifica atributos de POP.

pop createpop modify

v view Busca y lista POP y muestra sus detalles.

pop findpop listpop show

B Bypass TOD Altera temporalmente el atributo de hora del día de POP enun objeto.

Permisos /Management/ServerEl objeto contenedor de /Management/Server del espacio de objetos protegidospermite al administrador efectuar tareas de gestión de servidor (cuando se hanestablecido los permisos adecuados).

Los controles de gestión de servidor se utilizan para determinar si un usuario tienepermiso para crear, modificar o suprimir una definición de servidor. Lasdefiniciones de servidor contienen información que permite a otros servidores deAccess Manager, particularmente a Policy Server (pdmgrd), localizar y establecercomunicación con este servidor.

Las definiciones de servidor se crean para un gestor de recursos concreto (comoWebSEAL) o Authorization Server (pdacld) como parte del proceso de instalación.La definición de un servidor también se suprime cuando se desinstala el servidor.

Operación Descripción

s server Replica la base de datos de autorizaciones.

server replicate

v view Lista servidores registrados y muestra propiedades delservidor.

server listserver show

t trace Habilita el rastreo dinámico o la administración deestadísticas.

server task nombre_servidor traceserver task nombre_servidor stats

Permisos /Management/ConfigEl objeto contenedor /Management/Config del espacio de objetos protegidos permitea los administradores efectuar tareas de gestión de configuración (cuando se hanestablecido los permisos adecuados).

56 IBM Tivoli Access Manager Base: Guía del administrador

La creación y supresión de definiciones de servidor ocurre automáticamente— eladministrador de instalación no tiene que efectuar ningún paso especial para crearuna definición. Sin embargo, al administrador se le debe haber concedido elpermiso modify (m) en el objeto /Management/Config a fin de crear la definicióndurante la instalación.

Además, el administrador debe tener el permiso delete (d) en el objeto/Management/Config para poder suprimir la definición durante la desinstalación.

Operación Descripción

m modify Configuración en un dominio seguro.

svrsslcfg -configsvrsslcfg -modify

d delete Desconfiguración.

svrsslcfg -unconfig

Permisos /Management/PolicyEl objeto contenedor /Management/Policy del espacio de objetos protegidos permitea los administradores autorizar los comandos policy get y policy set (cuando sehan establecido los permisos adecuados).

Operación Descripción

v view Necesario para operaciones policy get.

m modify Necesario para operaciones policy set.

Permisos /Management/ReplicaEl objeto contenedor de /Management/Replica del espacio de objetos protegidoscontrola la réplica de la base de datos de autorizaciones. Los controles de alto nivelde este objeto afectan al funcionamiento de Policy Server y al gestor o gestores deseguridad del dominio seguro.

Los controles de gestión de réplica se utilizan para determinar qué procesos estánpermitidos para leer o actualizar la base de datos maestra de política deautorización para que la réplica tenga lugar adecuadamente.

Los controles y los permisos asociados son:

Operación Descripción

v view Lee la base de datos maestra de autorización.

m modify Autoriza la modificación de la base o las bases de datos deréplica.

A todos los servidores de Access Manager que mantienen una réplica local de labase de datos de autorizaciones —lo que incluye a todos los gestores de recursos yAuthorization Servers— se les debe haber concedido el permiso view (v) en elobjeto /Management/Replica. El proceso de réplica requiere que a estos procesos seles permita ver y acceder a entradas que no están en la base de datos maestra depolítica de autorización. La instalación de Access Manager concede el permiso readautomáticamente a cualquier servidor que requiera acceso a la base de datos depolíticas de autorización.

Capítulo 3. Utilización de políticas de control de accesos 57

Access Manager no utiliza el permiso modify (m) actualmente. La única manera demodificar la base de datos maestra de política de autorización es mediante WebPortal Manager o el programa de utilidad pdadmin. Estas herramientas estánsujetas a otras comprobaciones más estrictas. El permiso modify está pensado paraser utilizado en el futuro, cuando sea posible replicar Server Policy.

Permisos /Management/UsersEste objeto permite a los usuarios de administración gestionar cuentas de usuario.Las tareas de acción y los permisos asociados son:

Operación Descripción

d delete Suprime una cuenta de usuario.

user delete

m modify Modifica detalles de cuenta de usuario.

user modify authentication-mechanismuser modify account-validuser modify gsouseruser modify description

N create Crea un usuario nuevo y, opcionalmente, lo asigna a uno omás grupos. Importa datos de grupos del registro deusuarios.

user createuser import

v view Lista cuentas de usuario y muestra sus detalles.

user listuser list-dnuser list-gsouseruser showuser show-dnuser show-groups

W password Restablece y valida una contraseña de usuario.

user modify passworduser modify password-valid

El permiso W permite restablecer la contraseña y hace que los administradores desoporte puedan ayudar a los usuarios que han olvidado su contraseña. Estepermiso permite al administrador restablecer la contraseña olvidada y utilizar, acontinuación, el comando user modify password-valid para establecer un valor de“no”. Esta acción permite al usuario registrarse y le obliga a aplicarinmediatamente una contraseña nueva.

El acceso concedido por el objeto /Management/Users altera temporalmentecualquier restricción de acceso que las ACL de política de “administracióndelegada” imponen bajo /Management/Groups/nombre_grupo.

Permisos /Management/GroupsEste objeto permite a los usuarios de administración gestionar grupos y miembrosde grupos. Las tareas de acción y los permisos asociados son:

Permiso Operación Descripción

d delete Suprime un grupo.

group delete

58 IBM Tivoli Access Manager Base: Guía del administrador

Permiso Operación Descripción

m modify Modifica la descripción de un grupo. Elimina uno omás usuarios miembros de un grupo.

group modify descriptiongroup modify remove

N create Crea un grupo nuevo. Importa datos de grupos delregistro de usuarios.

group creategroup import

v view Lista grupos y muestra sus detalles.

group listgroup list-dngroup showgroup show-dngroup show-members

A add Agrega uno o más usuarios a un grupo.

group modify add

El permiso A es necesario en la entrada de la ACL en un grupo para poder agregarusuarios existentes al grupo. Utilice el comando user create (que requiere elpermiso N) para crear usuarios nuevos y, opcionalmente, colocarlos en uno o másgrupos existentes.

La posibilidad de agregar usuarios existentes al grupo resulta muy eficaz porque elpropietario de un grupo tiene el control sobre todos los usuarios miembros delgrupo. Si como propietario del grupo también tiene el permiso delete (d), puedesuprimir este usuario de todo el dominio seguro.

Permisos /Management/GSOEl objeto contenedor /Management/GSO del espacio de objetos protegidos permite alos administradores efectuar tareas de gestión de Global Sign-On (GSO) cuando sehan establecido los permisos adecuados.

Operación Descripción

m modify rsrcgroup modifyrsrccred modify

v view rsrc listrsrcgroup listrsrccred listrsrc showrsrcgroup showrsrccred show

N create rsrc creatersrcgroup creatersrccred create(todos los comandos anteriores también requieren m)

d delete rsrc deletersrcgroup deletersrccred delete(todos los comandos anteriores también requieren m)

Capítulo 3. Utilización de políticas de control de accesos 59

Permisos de objeto y espacio de objetosEstos comandos permiten a los usuarios de administración gestionar objetos yespacios de objetos nuevos. Las tareas de acción y los permisos asociados son:

Operación Descripción

b browse objectspace listobjectspace writefileobject listobject listandshow(adicionalmente requiere v)

d delete objectspace deleteobject deleteobject modify set name(adicionalmente requiere m)

m modify objectspace createobjectspace readfileobject createobject modify

v view object listandshow(adicionalmente requiere b)object show

Políticas de ACL de administración predeterminadasLas siguientes políticas de ACL de administración predeterminadas son puntos departida sugeridos para proteger regiones específicas del dominio seguro.

Puede agregar entradas para usuarios, grupos, cualquier otro (cualquierautenticado) y no autenticado para proporcionar un amplio rango de control yreunir de manera más óptima los requisitos del espacio de objetos protegidos.

Tenga presente los usuarios o grupos de cada ACL que contienen el permisocontrol (c). Los usuarios y grupos que contienen el permiso control son los“propietarios” de la ACL y tienen la capacidad de modificar las entradas de ACL.

Política de ACL raíz predeterminadaLas entradas esenciales para la ACL raíz predeterminada, default-root, incluyen:Group iv-admin TcmdbvaCualquier otro TNo autenticado T

La ACL raíz es básica —con ella se puede pasar por el espacio de objetos, pero nopermite efectuar ninguna otra acción. Generalmente, no tendrá que modificarla. Sinembargo, una función de la ACL raíz es denegar acceso de manera rápida a todo elespacio de objetos para un usuario o un grupo concreto.

Considere la entrada siguiente en la ACL raíz:usuario john -----------------

Esta entrada (sin permisos) hace que usuario john no pueda pasar por el objetocontenedor raíz. Este usuario no puede acceder a todo el espacio de objetosprotegidos, independientemente de cualquier permiso concedido inferior en elárbol.

60 IBM Tivoli Access Manager Base: Guía del administrador

Este enfoque puede aplicarse al espacio de objetos WebSEAL. Por ejemplo, si tomael permiso traverse de un usuario concreto en los objetos contenedor /WebSEAL, esteusuario no podrá tener una entrada en el espacio de objetos WebSEAL,independientemente de cualquier permiso concedido para los objetos de estasregiones.

Política de ACL de /WebSEAL predeterminadaLas entradas esenciales de ACL de WebSEAL, default-webseal, son:Grupo iv-admin TcmdbsvarxlGrupo webseal-servers TgmdbsrxlUsuario sec_master TcmdbsvarxlCualquier otro TrxNo autenticado T

Durante la instalación, esta ACL se asocia con el objeto contenedor /WebSEAL en elespacio de objetos.

El grupo, webseal-servers, contiene una entrada para cada servidor WebSEAL enel dominio seguro. Los permisos predeterminados permiten a los servidoresresponder a las peticiones del navegador.

El permiso traverse permite la ampliación del espacio web, tal y como serepresenta en Web Portal Manager. El permiso list permite a Web Portal Managermostrar el contenido del espacio web.

Política de ACL de /Management predeterminadaLas entradas esenciales de la ACL de gestión, default-management, son:Grupo iv-admin TcmdbsvatNWAGrupo ivmgrd-servers TsCualquier otro Tv

Durante la instalación, esta ACL se asocia al objeto contenedor /Management en elespacio de objetos.

Política de ACL de /Replica predeterminadaLas entradas esenciales de la ACL de gestión de réplica, default-replica, son:Grupo iv-admin TcbvaGrupo ivmgrd-servers mGrupo secmgrd-servers mdvGrupo ivacld-servers mdv

Política de ACL de /Config predeterminadaLas entradas esenciales de la ACL de gestión de configuración, default-config, son:Grupo iv-admin TcmdbsvaNCualquier otro TvNo autenticado Tv

Política de ACL de /GSO predeterminadaLas entradas esenciales de la ACL de gestión de GSO, default-gso, son:Grupo iv-admin TcmdbvaNCualquier otro TvNo autenticado Tv

Capítulo 3. Utilización de políticas de control de accesos 61

Política de ACL de /Policy predeterminadaLas entradas esenciales de la ACL de gestión de política, default-policy, son:Grupo iv-admin TcmdbvaNCualquier otro TvNo autenticado Tv

62 IBM Tivoli Access Manager Base: Guía del administrador

Capítulo 4. Utilización de políticas de objetos protegidos

El servicio de autorizaciones de Access Manager toma decisiones con respecto apeticiones para acceder a objetos protegidos en el dominio seguro. Estas decisionesse pueden basar en dos tipos de políticas:v Políticas de lista de control de accesos (ACL)v Políticas de objetos protegidos (POP)

La finalidad de una POP es imponer condiciones adicionales en la operación que lapolítica de ACL ha permitido.

Ejemplos de condiciones de acceso:v Escribir un registro de informe para el servicio de auditoríav Restringir el acceso a un período de tiempo específico

Este capítulo trata sobre la configuración de políticas de objetos protegidos y suaplicación a objetos.

Este capítulo contiene los apartados siguientes:v “Conceptos básicos de la política de objetos protegidos (POP)” en la página 63v “Configuración de atributos de POP” en la página 66v “Política POP de intensidad de la autenticación (incremental)” en la página 67v “Política POP de autenticación basada en la red” en la página 71v “Política POP de calidad de protección” en la página 73

Conceptos básicos de la política de objetos protegidos (POP)Las políticas de ACL proporcionan al servicio de autorizaciones información pararesponder yes o no a una petición para acceder a un objeto protegido y efectuaroperaciones en dicho objeto.

Las políticas POP contienen condiciones adicionales para la petición que se hanpasado al gestor de recursos (como WebSEAL) junto con la decisión yes de lapolítica de ACL del servicio de autorizaciones. Es responsabilidad del gestor derecursos aplicar las condiciones de POP.

En la tabla siguiente se muestran los atributos disponibles para una POP de AccessManager:

Aplicado por Access Manager Base

Atributo POP Descripción Comandos pdadmin pop

Nombre Nombre de la política. Se convierte ennombre_pop en los comandos pdadminpop.

createdelete

Descripción Texto descriptivo de la política. Semuestra en el comando pop show.

modify set description

Modalidad de aviso Proporciona a los administradores unmedio para probar políticas de ACL yPOP.

modify set warning

63

Aplicado por Access Manager Base

Atributo POP Descripción Comandos pdadmin pop

Nivel de auditoría Especifica el tipo de auditoría: todas,ninguna, acceso satisfactorio, accesodenegado, errores.

modify set audit-level

Acceso según la hora deldía

Restricciones de día y hora para elacceso satisfactorio al objeto protegido.

modify set tod-access

Atributos ampliados Especifica campos de datossuplementarios.

modify set attributemodify delete attributelist attributeshow attribute

Aplicado por el gestor de recursos (como WebSEAL)

Atributo POP Descripción Comandos pdadmin pop

Calidad de protección Especifica el grado de protección dedatos: ninguna, integridad, privacidad.

modify set qop

Política de métodos deautenticación de puntofinal de IP

Especifica los requisitos deautenticación para acceder desdemiembros de redes externas.

modify set ipauth addmodify set ipauth removemodify set ipauth anyotherw

Notas de POP:v El acceso de hora del día y el acceso de método de autenticación de punto final

de IP imponen restricciones en el acceso al objeto.v El nivel de auditoría y la calidad de protección informan al servicio de

autorizaciones que se necesitan servicios adicionales cuando se permite acceso alobjeto.

v La modalidad de aviso proporciona una manera de probar políticas de ACL yPOP antes de que se activen.

Nota: Las reglas de calidad de protección y de auditoría especificadas por lospermisos P, I y A en versiones de Access Manager anteriores se especificanahora en políticas POP.

Creación y supresión de políticas de objetos protegidosLas políticas de objetos protegidos (POP) funcionan de manera similar a laspolíticas de ACL —se crea y se configura una POP y, a continuación, se asocia aobjetos del espacio de objetos protegidos.

Las políticas POP se heredan de la misma manera que las políticas de ACL. Tantounas como otras se encuentran en la base de datos maestra de autorización quePolicy Server controla.

Crear y listar una POPpdadmin> pop create nombre_pop

Por ejemplo:pdadmin> pop create testpdadmin> pop list test

La POP nueva contiene los valores predeterminados siguientes:

64 IBM Tivoli Access Manager Base: Guía del administrador

pdadmin> pop show testPolítica de objetos protegidos: testDescripción:Aviso: noNivel de auditoría: noneCalidad de protección: noneAcceso según hora del día: sun, mon, tue, wed, thu, fri, sat:

anytime:localPolítica de métodos de autenticación de punto final de IP

Cualquier otra red 0

Suprimir una POPpdadmin> pop delete nombre_pop

Por ejemplo:pdadmin> pop delete testpdadmin> pop listpdadmin>

Modificar y mostrar una descripción de POPpdadmin> pop modify nombre_pop set description descripción

Nota: Cuando utilice más de una palabra ponga comillas dobles al principio y alfinal de la descripción.

Por ejemplo:pdadmin> pop modify test set description “Test POP”pdadmin> pop show test

Política de objetos protegidos: testDescripción: Test POPAviso: noNivel de auditoría: noneCalidad de protección: noneAcceso según hora del día: sun, mon, tue, wed, thu, fri, sat:

anytime:localPolítica de métodos de autenticación de punto final de IP

Cualquier otra red 0

Aplicación de atributos de POP a objetos protegidosLas políticas POP se aplican a objetos de la misma manera que las políticas deACL.

Asociar una POP a un objetoLa sintaxis para asociar una POP a un objeto es:pdadmin> pop attach nombre_objeto nombre_pop

Por ejemplo:pdadmin> pop attach /WebSEAL/serverA/index.html test

Buscar dónde está asociada una POPpdadmin> pop find test /WebSEAL/serverA/index.html

Suprimir una POPLa sintaxis para desasociar una POP de un objeto es:pdadmin> pop detach nombre_objeto

Por ejemplo:pdadmin> pop detach /WebSEAL/serverA/index.html

Capítulo 4. Utilización de políticas de objetos protegidos 65

Configuración de atributos de POPv Atributo de modalidad de avisov Atributo de nivel de auditoríav Atributo de hora del día

Atributo de modalidad de avisoLa finalidad del atributo de aviso es permitir a un administrador de seguridaddepurar o resolver problemas relativos a la precisión del conjunto de políticas deautorización en el espacio de objetos protegidos.

Cuando establece el atributo de aviso en yes, cualquier usuario puede efectuarcualquier acción en el objeto al que la POP está asociada. Está permitido el accesoa un objeto incluso si la política de ACL asociada al objeto se ha establecido paradenegar el acceso.

Se generan registros de auditoría que capturan el resultado de todas las políticasde ACL con la modalidad de aviso establecida en el espacio de objetos. El registrode auditoría muestra el resultado de una decisión de autorización que seproduciría si el atributo de aviso estuviera establecido en “no”. Por lo tanto, eladministrador puede determinar si se ha establecido la política y aplicarlacorrectamente.pdadmin> pop modify nombre_pop set warning {yes|no}

Por ejemplo:pdadmin> pop modify test set warning yes

Atributo de nivel de auditoríaEl atributo POP de nivel de auditoría sustituye al permiso A de ACL que activabala auditoría en versiones anteriores de Access Manager. Con el nivel de auditoríade POP se puede especificar un nivel de auditoría más amplio.

Por ejemplo, si se establece la auditoría para registrar eventos no satisfactorios,puede utilizar los resultados para detectar un número inusual de intentos deacceso anómalos en un recurso concreto.

Los registros de auditoría se escriben en formato XML estándar que permiteefectuar análisis simples para extraer cualquier información necesaria.

Consulte el apartado “Archivos de seguimiento de auditoría” en la página 123.pdadmin> pop modify nombre_pop set audit-level {all|none|lista_niveles_auditoría}

Lista de niveles de auditoría

Valor Descripción

permit Efectúa la auditoría de todas las peticiones de acceso a un objetoprotegido que han resultado satisfactorias.

deny Efectúa la auditoría de todas las peticiones de acceso a un objetoprotegido que han sido denegadas.

error Efectúa una auditoría de todos los mensajes de error generados demanera interna como consecuencia de denegar el acceso al objetoprotegido.

66 IBM Tivoli Access Manager Base: Guía del administrador

Se puede aplicar cualquier combinación de estos tres valores. Utilice una comacomo carácter separador cuando especifique más de un valor.

Por ejemplo:pdadmin> pop modify test set audit-level permit, deny

Atributo de hora del díaEl atributo de hora del día (TOD) de POP le permite establecer condicionesespecíficas de día y hora para el acceso a un objeto protegido. Este tipo decondición podría permitirle limitar el acceso a información que regularmenterequiere periodos de inactividad para efectuar modificaciones y actualizaciones.

Existe un permiso de política de ACL (B) que altera temporalmente las condicionesde hora del día de un objeto. Este permiso sólo debe utilizarlo un administradorexperimentado que pueda acceder sin ninguna restricción al espacio de objetosprotegidos en cualquier momento.pop modify nombre_pop set tod-access cadena_hora_del_día

El argumento de cadena de hora del día incluye un rango de días y un rango dehoras y utiliza el formato siguiente:<{anyday|weekday|lista_días}>:<{anytime|espec_hora-espec_hora}>[:{utc|local}]

La variable day-list puede ser una combinación de lo siguiente:mon, tue, wed, thu, fri, sat, sun

La variable de rangos time-spec puede especificarse (utilizando un formato horariode 24 horas) como:hhmm-hhmm

Por ejemplo:0700-1945

La zona horaria opcional para el servidor (no el cliente) es local de formapredeterminada.

Por ejemplo:pdadmin> pop modify test set tod-access mon,tue,fri:1315-1730

Política POP de intensidad de la autenticación (incremental)Se pueden utilizar políticas de objetos protegidos (POP) para aplicar determinadascondiciones de acceso en recursos específicos. La política POP de intensidad de laautenticación hace posible el control del acceso a objetos según el método deautenticación.

Puede utilizar estas funciones, conocidas a veces como autenticación incremental,para garantizar que los usuarios que acceden a recursos más confidenciales utilicenun mecanismo de autenticación más potente. Esta condición es recomendabledebido a la importante amenaza que supone el acceso inadecuado a determinadosrecursos.

Capítulo 4. Utilización de políticas de objetos protegidos 67

Por ejemplo, puede proporcionar una mayor seguridad a una región con conexión(junction) del espacio de objetos protegidos aplicando una política POP incrementalque requiera un nivel mayor de autenticación del que ha utilizado el cliente alentrar inicialmente en el dominio seguro.

La política de intensidad de la autenticación está establecida en el atributo Métodode autenticación de punto final de IP de una política POP.

Configuración de niveles de autenticación incrementalEl primer paso al configurar el acceso específico de la autenticación es configurarlos métodos de autenticación soportados y determinar el orden de importancia deestos métodos de autenticación.

Cualquier cliente que accede a un gestor de recursos tiene un nivel deautenticación, como “no autenticado” o “contraseña”, que indica el métodoutilizado por el cliente la última vez que se autenticó con el gestor de recursos.

Es posible que en algunas situaciones sea necesario aplicar los niveles mínimos de“seguridad” de la autenticación necesarios para acceder a algunos recursos. Porejemplo, es posible que en un entorno se considere que la autenticación mediantecódigo de paso de señal es más segura que la autenticación mediante nombre deusuario y contraseña. Otro entorno puede requerir estándares distintos.

En lugar de forzar a los clientes a reiniciar sus sesiones con el gestor de recursoscuando no cumplen el nivel requerido de autenticación, el mecanismo deautenticación incremental les ofrece una segunda oportunidad de volver aautenticarse utilizando el método (nivel) necesario.

La autenticación incremental permite a los gestores de recursos controlar el métodocon el que los usuarios acceden a un recurso protegido. Si se precisa autenticaciónincremental porque el usuario no se ha autenticado con el método adecuado, ladecisión de acceso la sigue tomando el motor de autorizaciones, pero al gestor derecursos se le muestra un ″nivel de autenticación″ necesario como resultado de ladecisión de autorización. A continuación, el gestor de recursos puede decidir cómoseguir autenticando al usuario de manera que éste obtenga el nivel deautenticación necesario para acceder al objeto.

La aplicación del gestor de recursos determina todo el proceso de cómo un métodode autenticación concreto se correlaciona con un nivel de autenticación. En todoslos casos, el método de autenticación mínimamente aceptable debe establecersecomo el nivel 0 con más métodos seguros que se correlacionen con númerosenteros en orden ascendente (1.x) a partir de aquí. En la implementación deautenticación incremental que efectúa WebSEAL, el nivel 0 se correlaciona con unusuario no autenticado. Otros métodos de autenticación de WebSEAL sonautenticación por contraseña y autenticación por tarjeta de señal. En el archivo deconfiguración de WebSEAL se configura la manera con que estos métodos deautenticación se correlacionan con un nivel de autenticación.

En la publicación IBM Tivoli Access Manager for e-business Release Notes encontraráinformación acerca de cómo desarrollar un gestor de recursos habilitado para lapolítica de autenticación incremental.

68 IBM Tivoli Access Manager Base: Guía del administrador

Aplicación de una política de autenticación incrementalLa autenticación incremental se implementa mediante una política POP asociadacon los objetos que requieren una autorización sensible a la autenticación. Utilice elatributo Método de autenticación de punto final de IP de una política POP.

El comando pdadmin pop modify set ipauth especifica las redes permitidas y elnivel de autenticación necesario en el atributo Método de autenticación de puntofinal de IP.

Los niveles de autenticación configurados se pueden vincular a rangos dedirecciones IP. Este método se ha concebido para proporcionar una flexibilidad degestión. Si el filtro de usuarios por dirección IP no es un aspecto prioritario, puedeestablecer una sola entrada para anyothernw (cualquier otra red). Este valorafectará a todos los usuarios que accedan, independientemente de la dirección IP, yles solicitará que se autentiquen en el nivel especificado. Es el método más habitualpara implementar la autenticación incremental.

Sintaxis:pdadmin> pop modify nombre-pop set ipauth anyothernw índice-nivel

La entrada anyothernw se utiliza como rango de red que coincidirá con cualquierred que no esté especificada en la POP. Este método se utiliza para crear unaentrada predeterminada que puede rechazar todas las direcciones IP nocoincidentes o permitir el acceso a cualquiera que cumpla el requisito de nivel deautenticación.

anyothernw aparece de forma predeterminada en una POP con el índice de nivelde autenticación 0. La entrada aparece como “Cualquier otra red” en el comandopop show:pdadmin> pop show test

Política de objetos protegidos: testDescripción: Test POPAviso: noNivel de auditoría: noneCalidad de protección: noneAcceso según hora del día: sun, mon, tue, wed, thu, fri, sat:

anytime:localPolítica de métodos de autenticación de punto final de IP

Cualquier otra red 0

El gestor de recursos ha definido los siguientes niveles de autenticación y suscorrespondientes métodos de autenticación:v nivel de autenticación 0 = no autenticadov nivel de autenticación 1 = nombre de usuario/contraseñav nivel de autenticación 2 = nombre de usuario/código de pase de señal

Algoritmo de autenticación incrementalWebSEAL utiliza el siguiente algoritmo para procesar las condiciones de una POP:1. Comprueba la política de método de autenticación de punto final de IP de la

POP.2. Comprueba los permisos de ACL.3. Comprueba la política de acceso según la hora del día de la POP.4. Comprueba la política de nivel de auditoría de la POP.

Capítulo 4. Utilización de políticas de objetos protegidos 69

Cómo distinguir la autenticación incremental de laautenticación de varios factores

La autenticación incremental y la autenticación de varios factores de AccessManager son dos mecanismos distintos para controlar el acceso a recursos. AccessManager sólo proporciona autenticación incremental, tal como se ha descrito eneste capítulo.

La autenticación de varios factores fuerza a un usuario a utilizar dos o más nivelesde autenticación. Por ejemplo, el control de acceso en un recurso protegido puederequerir que el usuario se autentique tanto con nombre de usuario/contraseñacomo con nombre de usuario/código de pase de señal.

La autenticación incremental de Access Manager se basa en una jerarquía deniveles de autenticación preconfigurada y aplica un nivel específico deautenticación de acuerdo con la política establecida en un recurso. La autenticaciónincremental no fuerza al usuario a autenticarse utilizando varios niveles deautenticación para acceder a un recurso determinado. En su lugar, la autenticaciónincremental requiere al usuario que se autentique en un nivel que sea por lo menosel que precisa la política que protege el recurso.

Ejemplo de autenticación incremental:

Niveles de autenticación configurados:v nivel de autenticación 1 = nombre de usuario/contraseñav nivel de autenticación 2 = nombre de usuario/código de pase de señal

El objeto siguiente está protegido por una POP que requiere nivel de autenticación1:/WebSEAL/hostA/junction

El objeto siguiente está protegido por una POP que requiere nivel de autenticación2:/WebSEAL/hostA/junction/applicationA

En la autenticación incremental, se precisa la autenticación por nombre deusuario/contraseña (nivel 1) para acceder a /WebSEAL/hostA/junction.

Sin embargo, se precisa la autenticación por nombre de usuario/código de pase deseñal (nivel 2) para acceder a /WebSEAL/hostA/junction/applicationA. Si el usuarioha iniciado una sesión actualmente con un nombre de usuario y una contraseña,aparecerá un indicador que solicita información de nombre de usuario y de códigode pase de señal (incremental). Sin embargo, si el usuario inicia una sesión enWebSEAL utilizando nombre de usuario y código de pase de señal, el acceso aapplicationA es inmediato (presuponiendo que la comprobación de ACL ha sidopositiva).

La autenticación de varios factores requiere tanto el nivel de autenticación 1 comoel nivel de autenticación 2 para acceder a applicationA

70 IBM Tivoli Access Manager Base: Guía del administrador

Política POP de autenticación basada en la redLa política POP de autenticación basada en la red hace posible el control del accesoa objetos en función de la dirección IP del usuario. Puede utilizar esta función paraevitar que direcciones IP específicas (o rangos de direcciones IP) accedan acualquier recurso del dominio seguro.

También puede aplicar la configuración de la autenticación incremental a estapolítica y solicitar un método de autenticación específico para cada rango dedirecciones IP especificado.

La política de autenticación basada en la red está establecida en el atributo Métodode autenticación de punto final de IP de una política POP. Debe especificar dosrequisitos en este atributo:v Niveles de autenticación

Para obtener más información sobre niveles de autenticación, consulte elapartado “Política POP de intensidad de la autenticación (incremental)” en lapágina 67

v Redes permitidas

Especificación de direcciones y rangos IPEspecifique las direcciones IP y los rangos de direcciones IP permitidos por estapolítica POP.

El comando pdadmin pop modify set ipauth add especifica tanto la red (o rangode redes) como el nivel de autenticación requerido en el atributo Método deautenticación de punto final de IP.

Sintaxis:pdadmin> pop modify nombre-pop set ipauth add red máscara-red índice-nivel

Los niveles de autenticación configurados están vinculados a los rangos dedirecciones IP. Este método se ha concebido para proporcionar flexibilidad. Si elfiltro de usuarios por dirección IP no es un aspecto prioritario, puede estableceruna sola entrada para anyothernw (cualquier otra red). Este valor afectará a todoslos usuarios que accedan, independientemente de la dirección IP, y les solicitaráque se autentiquen en el nivel especificado.

Sintaxis:pdadmin> pop modify nombre-pop set ipauth anyothernw índice-nivel

De lo contrario, si desea ignorar el nivel de autenticación y permitir o denegar elacceso sólo según la dirección IP, puede utilizar el nivel 0 para los rangos quedesee permitir y “forbidden” (prohibido) para los rangos que desee rechazar.

La entrada anyothernw se utiliza como rango de red que coincide con cualquierred que no esté especificada en la POP. Este método se utiliza para crear unaentrada predeterminada que puede rechazar todas las direcciones IP nocoincidentes o permitir el acceso a cualquiera que cumpla el requisito de nivel deautenticación.

anyothernw aparece de forma predeterminada en una POP con el índice de nivelde autenticación 0. La entrada aparece como “Cualquier otra red” en el comandopop show:

Capítulo 4. Utilización de políticas de objetos protegidos 71

pdadmin> pop show testPolítica de objetos protegidos: testDescripción: Test POPAviso: noNivel de auditoría: noneCalidad de protección: noneAcceso según hora del día: sun, mon, tue, wed, thu, fri, sat:

anytime:localPolítica de métodos de autenticación de punto final de IP

Cualquier otra red 0

EjemplosPara solicitar a los usuarios del rango de direcciones IP 9.0.0.0 y máscara de red255.0.0.0 la utilización del nivel de autenticación 1 (el valor predeterminado es“password”):pdadmin> pop modify test set ipauth add 9.0.0.0 255.0.0.0 1

Para solicitar a un usuario específico la utilización del nivel de autenticación 0:pdadmin> pop modify test set ipauth add 9.1.2.3 255.255.255.255 0

Para evitar que todos los usuarios (distintos de los especificados en los ejemplosanteriores) tengan acceso al objeto:pdadmin> pop modify test set ipauth anyothernw forbidden

Inhabilitación de la autenticación incremental por dirección IPSintaxis:pdadmin> pop modify nombre-pop set ipauth remove red máscara-red

Por ejemplo:pdadmin> pop modify test set ipauth remove 9.0.0.0 255.0.0.0

Algoritmo de autenticación basado en la redEl motor de autorización utiliza el algoritmo siguiente para procesar lascondiciones en una POP:1. Comprobar la política de método de autenticación de punto final de IP de la

POP.2. Comprobar los permisos ACL.3. Comprobar la política de acceso según la hora del día de la POP.4. Comprobar la política de nivel de auditoría de la POP.

Notas y limitaciones de la autenticación basada en la redLa dirección IP que utiliza el gestor de recursos para aplicar la política deautenticación basada en la red debe ser la del originador de la conexión. Si latopología de la red utiliza proxies, la dirección que le aparece al gestor de recursospodría ser la dirección IP del servidor proxy.

En tal caso, el gestor de recursos no puede identificar de forma definitiva ladirección IP verdadera del cliente. Debe actuar con precaución al configurar unapolítica de autenticación basada en la red para que los clientes de la red puedanconectarse directamente con el gestor de recursos.

72 IBM Tivoli Access Manager Base: Guía del administrador

Política POP de calidad de protecciónEl atributo POP de calidad de protección le permite especificar el nivel deprotección de datos necesario al realizar una operación en un objeto.

El atributo POP de calidad de protección sustituye a los bits de permiso de ACL“P” e “I” que activaban los requisitos de privacidad e integridad en las versionesanteriores de Access Manager. Esta implementación anterior de la calidad deprotección no era eficaz y minaba el rendimiento del sistema.

El atributo POP de calidad de protección permite una sola transacción donde larespuesta “yes” a la decisión de ACL incluye también el nivel de calidad deprotección requerido. Si el gestor de recursos (como WebSEAL) no puedegarantizar el nivel de protección requerido, se rechaza la petición.pdadmin> pop modify nombre-pop set qop {none|integrity|privacy}

Nivel de QOP Descripción

Privacy(Privacidad)

Es necesario el cifrado de datos (SSL).

Integrity(Integridad)

Utilizar algún mecanismo para garantizar que no han cambiado losdatos.

Por ejemplo:pdadmin> pop modify test set qop privacy

Capítulo 4. Utilización de políticas de objetos protegidos 73

74 IBM Tivoli Access Manager Base: Guía del administrador

Capítulo 5. Utilización de Web Portal Manager

Web Portal Manager es una interfaz basada en la web que se utiliza para gestionarla política de seguridad en un dominio seguro. Web Portal Manager proporcionagestión y administración de usuarios, grupos, roles, permisos, políticas y provisiónde acceso a aplicaciones. Las tareas que pueden completarse utilizando Web PortalManager están documentadas en el sistema de ayuda en línea. Utilice el sistema deayuda en línea como la referencia principal cuando busque información basada entareas de Web Portal Manager. Las características descritas en este capítuloincluyen delegación de administración y registro automático.

Este capítulo contiene los apartados siguientes:v “Delegación de administración mediante Web Portal Manager”v “Delegación de la administración de roles” en la página 77v “Ejemplo de registro automático” en la página 79

Delegación de administración mediante Web Portal ManagerUna de las funciones más eficaces de Web Portal Manager es un amplio conjuntode servicios de gestión delegada que permite a una empresa delegar laadministración de usuarios, de grupos y roles, de seguridad y la provisión deacceso a aplicaciones a los participantes (subdominios) del sistema empresarial.Estos subdominios pueden delegar la gestión y administración a subdominios deconfianza que están bajo su control, soportando de esta manera una jerarquía dedelegación y gestión de varios niveles basada en roles.

La delegación de administración mediante Web Portal Manager proporciona a unadministrador de Access Manager la posibilidad de crear dominios de usuariosdelegados, crear nuevos usuarios, agregar usuarios existentes a dominiosadicionales y asignar varios tipos de administradores a los dominios. Acontinuación, estos administradores delegados pueden efectuar un subconjunto defunciones de administración, dependiendo del tipo, para los usuarios de sudominio asignado. Este concepto de delegación de administración de usuariospuede aplicarse a todos los usuarios de Access Manager de manera que se formauna jerarquía de dominios de usuario. En esta organización jerárquica, cadausuario de Access Manager sólo puede estar gestionado por los administradoresdel dominio del que el usuario es miembro o por los administradores de lossuperdominios (lo cual se explica más adelante en este capítulo). Las funcionesreales que los administradores pueden efectuar dependen del tipo deadministrador asignado.

Un administrador de Access Manager, como sec_master, puede crear una serie dedominios empresariales y asignar uno o varios tipos de administradores a cadadominio empresarial. El administrador de un dominio empresarial puede crearnuevos usuarios en el dominio y agregar usuarios existentes de Access Manager aldominio.

Además de esta función relacionada con el usuario, los administradores de AccessManager pueden crear nuevos dominios debajo del nivel de dominio empresarial(subdominios) y asignar a usuarios el rol de administrador de estos nuevosdominios (administradores del dominio). A continuación, los administradores delos nuevos dominios pueden crear nuevos usuarios en su propio dominio.

75

El administrador de Access Manager para el dominio empresarial (el superdominiodel dominio) también tiene autorización para administrar el dominio. Losadministradores de Access Manager pueden crear y gestionar bajo su autorizacióntantos dominios como sean necesarios para satisfacer sus necesidades comerciales.

Nota: Un dominio empresarial es básicamente el dominio de nivel superior, ycualquier dominio creado debajo de un nivel de dominio empresarial recibeel nombre de domino.

Teniendo en cuenta el ejemplo de la Figura 23, que muestra este tipo deadministración de dominio múltiple, un administrador de Access Manager puedecrear los dominios empresariales A y B y asignar un administrador a cadadominio. El administrador del dominio empresarial B puede crear los nuevosusuarios P y Q. Un administrador de Access Manager puede crear los dominios Cy D bajo los dominios empresariales A y B, y asignar administradores del dominioa C y D. A continuación, el administrador de Access Manager puede crear eldominio E debajo del dominio D, y asignar un administrador del dominio a E. Eladministrador del dominio E puede crear entonces los nuevos usuarios X, Y y Z enel dominio E. Puesto que un administrador del dominio también puedeadministrar esos subdominios del dominio, tanto los administradores del dominioD como el administrador del dominio empresarial B pueden crear usuarios (oefectuar otras funciones administrativas) en el dominio E.

A cada dominio de usuario delegado (incluido el dominio empresarial), se puedenasignar tipos de administradores predefinidos. A continuación, se muestran losdistintos tipos de administradores y el conjunto de funciones administrativas quepueden efectuar los administradores asignados a cada uno de estos tipos:v Administrador de Access Manager. El administrador de Access Manager es un

miembro del grupo iv-admin. El administrador de Access Manager puedeefectuar todas las funciones de delegación de administración.

Figura 23. Delegación de administradores

76 IBM Tivoli Access Manager Base: Guía del administrador

v Administrador del dominio. El administrador del dominio puede efectuarfunciones administrativas para los usuarios en sus dominios. Losadministradores del dominio pueden crear nuevos usuarios y administradoresen su propio dominio, y asignar a usuarios existentes del dominio el rol deadministrador (de cualquier tipo excepto del dominio).

v Administrador senior. Un administrador senior tiene la misma autorización queun administrador del dominio, con la excepción de que no puede asignaradministradores adicionales.

v Administrador. Un administrador tiene la misma autorización que unadministrador senior, con la excepción de que no puede crear nuevos usuariosdel dominio. Un administrador puede modificar las propiedades de un usuarioexistente.

v Administrador de soporte. El rol de un administrador de soporte es ayudar alusuario y puede ver propiedades de usuarios, cambiar contraseñas de usuarios ymodificar los indicadores Contraseña válida para usuarios.

La herramienta de delegación de administración de usuario aplica las funcionesadministrativas que pueden efectuarse con cada tipo de administrador. Cuando unadministrador inicia una sesión, las funciones administrativas pasan a estardisponibles de acuerdo con el tipo de administrador de usuario.

Delegación de la administración de rolesOtra parte del sistema de delegación de administración de Web Portal Manager esla administración de roles. Para desplegar Access Manager de manera satisfactoria,debe definirse una política de seguridad que regule el acceso a objetos y lasacciones que pueden efectuarse en ellos. Ejecutar esta política suele ser complicadopuesto que la política de seguridad suelen definirla miembros experimentados deuna organización que hace hincapié en aspectos de seguridad general. Esta políticadeben llevarla a cabo miembros locales de la organización, que se centran en losdetalles secundarios y en la implementación. A menudo, estos dos grupos tienenobjetivos parecidos en cuanto a la seguridad general de una organización, perointerconectar estos dos puntos de vista diferentes es un reto. La administraciónbasada en el rol hace que la seguridad de una organización pueda cumplir demanera óptima los complejos requisitos de seguridad actuales en cuanto aescalabilidad, simplicidad y versatilidad.

Para entender qué es la administración de roles, el primer concepto que debedefinirse es el de rol. Un rol se compone de un número de tareas,responsabilidades o conocimientos necesarios para realizar un trabajo específico.Cuando esta definición se compara con el modelo de lista de control de accesos(ACL) de Access Manager, un rol se convierte en una lista de una o más parejas deobjetos y uno más permisos de acceso que se aplican al objeto. Por ejemplo:v objeto 1: permiso 1v objeto 2: permisos 2, 3 y 4v objeto 3: permiso 5

Para que un rol se pueda utilizar, debe estar activado. Un rol está activado cuandoun administrador de Access Manager habilita su definición en el espacio denombres de Access Manager. Cuando el rol está activado y se le asigna un usuario,éste tiene el permiso 1 para el objeto 1, los permisos 2, 3 y 4 para el objeto 2, y elpermiso 5 para el objeto 3. Los permisos de acceso para estos objetos permiten alusuario acceder a los objetos y, por lo tanto, efectuar la responsabilidad de trabajodefinida por el rol. Por ejemplo, puede definirse un “rol de contable” que secomponga de estas dos parejas de objetos y permisos:

Capítulo 5. Utilización de Web Portal Manager 77

v objeto de cheque de nómina: crear/modificar/suprimirv objeto de solicitud de reembolso: aprobar

Cuando este rol está activado y se le asigna un empleado del departamento decontabilidad, este empleado puede crear, modificar o suprimir un cheque denómina y aprobar una solicitud de reembolso, realizando así el trabajo propio deun contable.

Para administrar roles de manera satisfactoria, un administrador debe poderefectuar tres tipos de tareas :v Creación de rolesv Asignación de rolesv Activación de roles

La creación de roles conlleva la definición de un rol de manera que tenga una listade una o más parejas de objetos y permisos de Access Manager que puedanaplicarse a los objetos. Cuando se crea un rol en Web Portal Manager, se crea ungrupo de Access Manager que representa al rol. También se crea el objeto de grupocorrespondiente en el espacio de objetos de gestión. La información de la parejaobjeto/permiso para el rol se almacena en los atributos ampliados asociados alobjeto de grupo. Sólo un administrador de Access Manager puede crear un rol.

La asignación de roles consiste en asignar un usuario a un rol que ya ha sido creado.La finalidad de asignar usuarios a roles es hacer que estos usuarios tengan lospermisos de acceso para los objetos definidos en el rol. Esta función reduce lacarga de trabajo que supone el mantenimiento de la relación usuario-permiso-objeto, puesto que la asignación de roles es un proceso que se realiza aparte de lagestión de objeto/permiso de acceso. Cuando se asigna un usuario a un rol en WebPortal Manager, se agrega el usuario como un miembro del grupo que representael rol. Los administradores del dominio, los administradores senior y losadministradores de un dominio pueden asignar usuarios a un rol en sus dominios.

La activación de roles hace que un rol creado recientemente entre en funcionamiento.Cuando se ha creado un rol y se le ha asignado un usuario, éste no tiene permisosde acceso para los objetos definidos en el rol hasta que se activa dicho rol. Cuandoun rol está activado en Web Portal Manager, una entrada de ACL que contiene elgrupo que representa el rol y los permisos de acceso definidos en el rol se agregana la ACL para cada objeto definido en el rol. Puesto que se ha agregado un usuarioal grupo cuando se ha asignado el usuario al rol, este usuario sólo tendrá permisopara acceder a los objetos después de que el rol esté activado. Sólo unadministrador de Access Manager puede activar un rol.

Al igual que sucede con un usuario, un rol es una entidad que puede delegarse yadministrarse asignándolo a un dominio. Cuando se crea un rol, puede asignarse aun dominio empresarial. Los administradores del dominio pueden, a su vez,asignar cualquiera de los roles de ese dominio a cualquier subdominio. Una vezasignado un rol a un subdominio, un administrador de ese subdominio puedeasignar cualquier usuario del subdominio a ese rol. Este proceso de asignación deroles a subdominios puede repetirse según sea necesario para que los roles puedanestar disponibles para los usuarios adecuados. Sólo el administrador de AccessManager puede llevar a cabo la asignación de roles a un dominio empresarial. Losadministradores del dominio pueden asignar un rol a sus dominios.

78 IBM Tivoli Access Manager Base: Guía del administrador

Ejemplo de registro automáticoSe puede personalizar Web Portal Manager para permitir a los usuarios finalesefectuar un registro automático. El registro automático es el proceso por el que unusuario puede entrar datos necesarios y convertirse en un usuario registrado deAccess Manager, sin la intervención del administrador. Un ejemplo deimplementación de registro automático es cuando un usuario utiliza un navegadorweb para ver una página web de registro automático. En esta página web, elusuario entra información de identificación específica (bien específica de laempresa o bien específica del usuario) utilizando un ID de usuario y unacontraseña de Access Manager. A continuación, se valida la información deidentificación que el usuario ha proporcionado y se crea el usuario en el registro deAccess Manager.

Access Manager proporciona un ejemplo de registro automático para mostrar cómofunciona. Tenga en cuenta que este ejemplo sólo está soportado en un registroLDAP, no de Domino o de Active Directory.

Para instalar y utilizar el registro automático de ejemplo, siga estos pasos:

Nota: Sólo se le pedirá que lleve a cabo los pasos de configuración una vez.1. Instale Access Manager Java Runtime Environment (JRE) para la plataforma

que esté utilizando. En la publicación IBM Tivoli Access Manager Base InstallationGuide encontrará instrucciones de instalación.

2. Utilice el programa de utilidad pdjrtecfg para configurar JRE. Entre lo siguienteen una línea de comandos: (este comando se muestra en formato Windows)cd pd_home\sbin

.\pdjrtecfg -action config -java_home ruta_acceso_inicio_java

donde ruta_acceso_inicio_java es el Kit del desarrollador de Java utilizadopor WebSphere. Por ejemplo, en un sistema Windows esta ruta de acceso es lasiguiente:C:\WebSphere\AppServer\java\jre

3. Para preparar información de configuración para utilizar Access Manager JavaRuntime Environment, utilice el programa de utilidad SvrSslCfg de Java talcomo se muestra:

Nota: Para obtener más información sobre el programa de utilidad SvrSslCfgde Java, consulte la publicación IBM Tivoli Access Manager AuthorizationJava Classes Developer’s Reference.

java com.tivoli.mts.SvrSslCfg\pdjrteuser\contraseña_sec_master\

host_pdmgrd\host_pdacld\puerto_pdmgrd\puerto_pdacld\

URL_archivo_config\URL_archivo_almacén_claves\replace

donde:

pdjrteuser Indica que es un nombre de usuario abreviado de AccessManager exclusivo creado por el usuario.

contraseña_sec_masterIdentifica la contraseña de sec_master.

pdmgrd_host Identifica el sistema host de Access Manager Policy Server.

pdacld_host Identifica la máquina host de Access Manager AuthorizationServer.

Capítulo 5. Utilización de Web Portal Manager 79

pdmgrd_port Identifica el puerto de Access Manager Policy Server.

pdacld_port Identifica el puerto de Access Manager Authorization Server.

URL_archivo_configIdentifica la ubicación de la dirección URL del archivo deconfiguración. La ubicación predeterminada de la direcciónURL del archivo de configuración es la siguiente:

directorio_temporal/pdjrte/pdjrte.properties

La ubicación predeterminada de la dirección URL del archivode configuración está especificada en el archivo pdwpm.conf,que se encuentra en el directorio etc de Access Manager.

Nota: Debe editar el archivo pdwpm.conf para cambiar ladirección URL del archivo de configuración y reiniciarWebSphere Application Server.

URL_archivo_almacén_clavesIdentifica la ubicación de la dirección URL del archivo dealmacenamiento de claves. La ubicación predeterminada de ladirección URL del archivo de almacenamiento de claves es lasiguiente:

directorio_temporal/pdjrte/pdjrte.ks4. Se puede acceder al ejemplo de registro automático desde la dirección URL

siguiente:https://hostlocal/registerdonde hostlocal es la máquina en la que se ejecuta IBM HTTP Server yWebSphere.

80 IBM Tivoli Access Manager Base: Guía del administrador

Capítulo 6. Delegación de tareas de administración

Access Manager permite a administradores experimentados delegarresponsabilidades de gestión del dominio seguro a administradores menosexperimentados. Esta posibilidad es vital para gestionar de manera satisfactoriadominios muy grandes que se componen de muchos departamentos y, por lo tanto,de numerosos grupos, usuarios y recursos.

Access Manager soporta dos tipos de administración delegada:v Gestión delegada de recursos en subregiones del espacio de objetos

Las posibilidades de administración están limitadas a una parte del espacio deobjetos.

v Gestión delegada de grupos y usuariosLas posibilidades de administración están limitadas a una parte de los usuarios.

Este capítulo contiene los apartados siguientes:v “Delegación de la gestión del espacio de objetos”v “Delegación de la gestión de grupos” en la página 85v “Gestión de política de administración delegada” en la página 90

Delegación de la gestión del espacio de objetosLa distribución de las responsabilidades de administración en un dominio segurorecibe el nombre de delegación de la gestión. Generalmente, la necesidad dedelegar tareas de gestión se debe a la creciente demanda de un sitio de grantamaño que contenga muchos departamentos o divisiones de recursos diferentes.

Generalmente, un espacio de objetos de gran tamaño puede organizarse enregiones que representan estos departamentos o estas divisiones. Cada una de lasdiferentes regiones del dominio suele estar mejor organizada y mantenida por ungestor que está más familiarizado con los aspectos y necesidades de esa rama delespacio de objetos.

En un dominio seguro, la cuenta sec_master para LDAP es, al principio, la únicacuenta con permiso de administración. Como sec_master, puede crear cuentas degestión y asignarles controles adecuados para regiones específicas del espacio deobjetos.

Estructuración del espacio de objetos para la delegación de lagestión

Estructure el espacio de objetos para que contenga diferentes regiones, o ramas, enlas que puedan llevarse a cabo responsabilidades de subgestión específicas de esarama.

En el ejemplo siguiente, tanto la región Engineering como la región Publicationsdel espacio de objetos requieren un control de gestión diferente. El control de estasregiones empieza en la raíz de cada región y se amplía a todos los objetosinferiores.

81

Usuarios y grupos de administración predeterminadosDurante la instalación, Access Manager proporciona varios grupos deadministración importantes. De forma predeterminada, a estos usuarios y gruposse les proporciona permisos especiales para controlar y gestionar todas lasoperaciones del dominio seguro. (Las ACL creadas durante la instalación definenesta política de seguridad predeterminada).

En los apartados siguientes se muestra detalladamente los roles específicosasignados a cada unos de estos usuarios y grupos durante la instalación. Eladministrador puede personalizar estos privilegios más adelante para ajustarpolíticas de gestión que presentan cambios.

usuario sec_master (LDAP)Este usuario representa el administrador del dominio seguro al que se le concedentodos los derechos para todas las operaciones del dominio seguro.

Esta política puede modificarse a medida que el espacio de objetos aumenta detamaño delegando permisos de gestión a otros usuarios y posiblemente revocandoalgunos permisos (o todos) de sec_master.

grupo iv-adminEste grupo representa el grupo del administrador. Al igual que sec_master, a todoslos miembros de este grupo se les considera administradores del dominio seguromediante la política predeterminada. Todas las ACL predeterminadas conceden alusuario sec_master y al grupo iv-admin exactamente los mismos permisos.

Es fácil hacer que un usuario tenga un rol de administrador; para ello, agréguelo algrupo iv-admin. El peligro de este procedimiento es que en cuanto un usuario seconvierte en miembro de este grupo (con las ACL predeterminadas), tiene todos losderechos para hacer lo que desee en cualquier objeto de todo el espacio denombres.

La política predeterminada para este grupo puede modificarse delegando permisosde gestión a otros usuarios y revocando algunos o todos los permisos de gestióndel grupo iv-admin.

Figura 24. Estructuración del espacio de objetos para la delegación de la gestión

82 IBM Tivoli Access Manager Base: Guía del administrador

grupo ivmgrd-serversEste grupo contiene Policy Server. Access Manager requiere que tan sólo PolicyServer exista en el dominio seguro. Por lo tanto, este grupo sólo contiene esa únicaentrada.

Puesto que la mayoría de peticiones de gestión efectuadas por la consola seejecutan a través de Policy Server al servidor destino, Policy Server debe tenerpermiso para efectuar la petición en el servidor destino. Por este motivo, a estegrupo se le concede el permiso de administración de servidor (s) en la ACL degestión predeterminada y permiso de lista (l) en todo el espacio web.

grupo webseal-serversEste grupo contiene todos los servidores WebSEAL del dominio seguro. La ACL deWebSEAL predeterminada concede a estos servidores el conjunto completo depermisos específicos de HTTP y el permiso de delegación. Esta política permite atodos los servidores de WebSEAL conectarse (junction) con los demás servidores deWebSEAL. Si se modifica esta política se podrían conceder estos permisos servidora servidor.

Creación de usuarios de administraciónSe pueden crear cuentas de administración con diferentes grados deresponsabilidad. La responsabilidad se delega a los administradores a través deACL de administración situadas de manera estratégica. La lista siguiente muestraposibles roles de administración:v Responsabilidades de administración de ACL

El administrador de ACL puede controlar toda la región del espacio de nombresde objetos protegidos, o parte de ella, dependiendo del lugar en el que seencuentra la ACL de administración. La entrada de ACL del administradorpuede contener los permisos b, a y T, además de cualquier otro permisoadecuado para operaciones en objetos de esa región.El administrador puede utilizar Web Portal Manager para asociar (a) ACL aobjetos del espacio de nombres designado utilizando el conjunto de plantillas deACL existente. Este administrador no tiene permisos para crear, modificar osuprimir plantillas de ACL.

v Responsabilidades de política de ACL

El administrador de la política de ACL debe ser el responsable de controlar lacreación y modificación de todas las plantillas de ACL utilizadas en el dominioseguro. También se le deben conceder los permisos d, b, m y v en los objetos/Management o /Management/ACL.Asimismo, puede crear plantillas de ACL nuevas (m). Al ser el creador de unaplantilla nueva, el administrador se convierte, de forma predeterminada, en laprimara entrada de la plantilla de ACL nueva, con permisos abcT. El permisocontrol (c) proporciona realmente al administrador la propiedad de la ACL y, porlo tanto, la capacidad de modificarla.Al ser el propietario de la ACL, el administrador puede utilizar el permisodelete (d), concedido en la ACL de gestión, para eliminar la ACL de la lista deplantillas. No se puede suprimir una plantilla de ACL a menos que se sea elpropietario de dicha ACL.

v Responsabilidades de gestión de servidor

A este administrador se le han concedido los permisos d, m, s y v en el objeto/Management/Server. Este administrador puede realizar operaciones que afectana los servidores de Access Manager.

v Responsabilidades de acción de autorización

Capítulo 6. Delegación de tareas de administración 83

A este administrador se le han concedido los permisos d y m en el objeto/Management/Action. Este administrador puede crear o suprimir todos lospermisos creados para aplicaciones de terceros.

Ejemplo de plantillas de ACL de administraciónEl ejemplo siguiente muestra cómo un usuario obtiene derechos de administración.v La ACL siguiente de /WebSEAL proporciona derechos de administración al

usuario adam:

usuario sec_master abcTdmlrxgrupo iv-admin abcTdmlrxgrupo webseal-servers gTdmlrxgrupo ivmgrd-servers Tlusuario adam abcTdmlrxcualquier otro Trxno autenticado Trx

Ejemplo de delegación de la gestiónUn espacio de objetos de gran tamaño podría necesitar muchos usuarios deadministración para gestionar varias subramas. En este ejemplo, las ACL para losdirectorios de la ruta de acceso a cada una de estas ramas deben contener entradaspara cada cuenta, con el permiso traverse. En el caso de un sitio con muchosusuarios de administración, estas ACL podrían contener una extensa lista deentradas que representan todas estas cuentas de administración.

El procedimiento siguiente resuelve el problema de la existencia de muchasentradas de ACL para los administradores:1. Cree una cuenta de grupo de administración.2. Agregue todos los nuevos usuarios de administración a este grupo.3. Agregue este grupo como una entrada de ACL (con traverse) a los directorios

de cada subrama que requiera delegación de la gestión.4. En la ACL raíz de cada rama, agregue la entrada de usuario administrador

adecuado(con los permisos b, c, T y cualquiera que sea adecuado).5. El administrador puede eliminar ahora la entrada de ACL del grupo de

administración (y cualquier otra entrada) de la raíz.Ahora, sólo ese usuario tiene el control sobre la raíz y todos los objetos queestán debajo de ella.

En el ejemplo siguiente, el grupo iv-admin contiene todos los usuarios deadministración. El usuario pub-manager es un miembro de este grupo y, por lotanto, tiene el permiso traverse necesario para navegar al directorio Publications.

El directorio Publications incluye la entrada de usuario pub-manager en su ACL.Puesto que pub-manager es el administrador delegado de esta rama (con lospermisos adecuados),pub-manager puede eliminar la cuenta del grupo iv-admin (ycualquier otra entrada de ACL) de la ACL de Publications para obtener el controlabsoluto de esa rama del espacio web.

84 IBM Tivoli Access Manager Base: Guía del administrador

Delegación de la gestión de gruposAccess Manager permite a administradores experimentados delegarresponsabilidades de gestión del dominio seguro a administradores menosexperimentados. Esta posibilidad es vital para gestionar de manera satisfactoriadominios muy grandes que se componen de muchos departamentos que contienennumerosos grupos, usuarios y recursos.

Al objeto de gestionar un conjunto de usuarios de gran tamaño o complejo, puededelegar la gestión de grupos de usuarios específicos a administradores menosexperimentados. Cuando a un administrador se le proporciona el control de lagestión de la política de un grupo, tiene el control sobre los usuarios miembros deese grupo.

La gestión de grupos delegada define:v Quién tiene responsabilidades de administración para un grupo específico(y los

usuarios miembros de ese grupo)v El nivel del control de grupos y usuarios proporcionado a este administrador

En este contexto, el término “administrador” hace referencia a lasresponsabilidades y controles concedidos a otro usuario habitual. Un administradorde responsabilidades delegadas es un usuario normal con más capacidad paraefectuar determinadas tareas de gestión.

Para establecer la gestión de grupos delegada se requieren las condicionessiguientes:1. Determinar una jerarquía lógica y práctica de los usuarios y tipos de usuarios

que son miembros del dominio seguro.2. Crear objetos contenedor de grupos que muestren esta jerarquía.

Figura 25. Ejemplo de delegación de la gestión

Capítulo 6. Delegación de tareas de administración 85

3. Crear grupos adecuados en esos objetos contenedor.4. Asociar estratégicamente políticas de ACL que incluyan la entrada de

administrador-usuario.5. Asignar a esta entrada de administrador-usuario los permisos específicos para

efectuar las tareas necesarias.

Creación de objetos contenedor de gruposDe forma predeterminada, la región /Management del espacio de objetos de AccessManager tiene un objeto contenedor de grupos que puede utilizar para organizarla jerarquía de grupos en el dominio seguro.

Los objetos contenedor son designaciones estructurales que le permiten organizarel espacio de objetos jerárquicamente en zonas de funcionamiento distintas. Losobjetos contenedor de grupos le permiten definir diferentes categorías de tipos degrupos. Debe crear grupos reales en cada objeto contenedor de grupos específico.

Utilice el comando pdadmin object create para crear un objeto contenedor degrupos nuevo:pdadmin> object create nombre-objeto descripción tipo ispolicyattachable {yes|no}

Argumento Descripción

nombre-obj Ruta de acceso y nombre completos del objeto contenedor de gruposnuevo. La ruta de acceso debe empezar con /Management/Groups.

descripción Cadena de texto que describe el objeto. Esta operación aparece en elcomando object show.

tipo Identifica el icono gráfico específico asociado a este objeto ymostrado por Web Portal Manager. El rango de tipos es 0 a 17 (vea

la tabla siguiente). El tipo 14 es el adecuado para los objetoscontenedor.

ispolicyattachable

Determina si puede asociar una política de ACL a este objeto.

Tipos de objetos

0 – desconocido1 – dominio seguro2 – archivo3 – programa ejecutable4 – directorio5 – conexión (junction)6 – servidor WebSEAL7 – no utilizado8 – no utilizado

9 – servidor HTTP10 – objeto no existente11 – objeto contenedor12 – objeto hoja13 – puerto14 – objeto contenedor de aplicaciones15 – objeto hoja de aplicación16 – objeto de gestión17 – no utilizado

Por ejemplo:pdadmin> object create /Management/Groups/Travel “TravelContainer Object” 14 ispolicyattachable yes

86 IBM Tivoli Access Manager Base: Guía del administrador

También puede crear el comando pdadmin group create para crear un objetocontenedor de grupos. Consulte el apartado “Creación de grupos”.

Creación de gruposUtilice el comando pdadmin group create para crear un grupo nuevo y,opcionalmente, agregarlo a un objeto contenedor de grupos. Si el objeto contenedorno existe actualmente, se crea automáticamente:pdadmin> group create nombre_grupo dn cn [contenedor_grupos]

Argumento Descripción

nombre_grupo Nombre del objeto de grupo nuevo.

dn Nombre distinguido del grupo nuevo.

cn Nombre común para el grupo nuevo.

contenedor_grupos Nombre de ruta de acceso relativo del objeto contenedor de grupos enel que debe encontrarse este grupo nuevo. Si no se especifica ningúnobjeto contenedor de grupos, el grupo se coloca en /Management/Groups.

v Todos los objetos contenedor de grupos que cree aparecerán en el contenedor/Management/Groups predeterminado. Para crear un contenedor en otro subnivel,utilice un nombre de ruta de acceso relativo para la variable contenedor_grupos.

v El comando group create no le permite crear un objeto contenedor sin un grupo.v Para agregar un grupo nuevo al espacio de objetos, el administrador debe tener

el permiso create (N) en la ACL que controla el objeto contenedor de gruposasociado.Si no se especifica ningún objeto contenedor de grupos, debe especificarse laentrada de ACL del administrador (con el permiso create) en la ACL quecontrola el contenedor /Management/Groups.Durante la instalación, una sola ACL predeterminada (default-management)—asociada a /Management— define los permisos en todos los grupos ycontenedores de grupos. Para personalizar este control debe agregar las ACLexplícitas adecuadas.

v Puede agregar varios grupos a un solo contenedor de grupos.La ACL del objeto contenedor de grupos controla (a través de la herencia) todoslos grupos que residen en el objeto contenedor. El objeto contenedor y susgrupos son ahora el dominio del administrador con las responsabilidadesdelegadas.

v La colocación de un grupo nuevo en el espacio de objetos se establece cuando secrea.Una vez se ha creado un grupo, sólo puede cambiarlo de posición suprimiendoel grupo del espacio de objetos (pero no LDAP) e importándolo a la nuevaubicación (los usuarios del grupo se mantienen).

+

/Management

/Management/Groups

/Management/Groups/Travel

Figura 26. Objeto contenedor de grupos

Capítulo 6. Delegación de tareas de administración 87

Por ejemplo:pdadmin> group create group1 “cn=travel,c=us” Group1 Travel

pdadmin> group create group2 “cn=travel,c=us” Group2 Travel

Políticas de ACL que afectan a la gestión de gruposLa autorización para controlar un grupo de usuarios se obtiene asociando una ACLadecuada al objeto de grupo o al objeto contenedor de grupos.

La ACL, construida y asociada por un administrador experimentado, debecontener los permisos adecuados para las acciones que el administrador delegadode ese grupo o grupos debe efectuar.

Si el grupo reside en la sección /Management/Groups del espacio de objetos, la ACLdebe asociarse a /Management/Groups o al grupo mismo.

Si el grupo reside en un objeto contenedor de grupos, la ACL debe asociarse alobjeto contenedor de grupos o al grupo mismo. Si asocia la ACL al objetocontenedor /Management/Groups, la ACL debería afectar a los demás objetoscontenedor de grupos situados debajo del espacio de objetos.

La ACL asociada a una de estas ubicaciones (o heredada de ubicaciones superiores)determina:v Quién controla el objeto de grupo y los usuarios del grupov Qué acciones pueden realizarse en el grupo y en sus usuarios

Por ejemplo, en la Figura 27 una ACL en /Management/Groups/Travel definepermisos para controlar tanto group1 como group2.

Las operaciones y los permisos de ACL siguientes son los adecuados para lagestión de grupos:

Operación Permiso

crear (un grupo nuevo) importar (datos de un grupo delregistro de usuarios)

N (create)

suprimir (un grupo) d (delete)

mostrar (detalles de un grupo) v (view)

modificar (descripción de un grupo) m (modify)

agregar (un usuario existente a un grupo) A (add)

/Management

/Management/Groups

/Management/Groups/Travel

+ /Management/Groups/Travel/group1

+ /Management/Groups/Travel/group2

Figura 27. Creación de grupos nuevos en un contenedor de grupos específico

88 IBM Tivoli Access Manager Base: Guía del administrador

Operación Permiso

eliminar (un usuario miembro del grupo) A (add)

Para efectuar estas operaciones puede utilizar los comandos adecuados delprograma de utilidad pdadmin o Web Portal Manager.

Notas:v El permiso create (N) reside en una ACL que está asociada a

/Management/Groups o en un objeto contenedor de grupos.v Los demás permisos de la lista pueden residir en una ACL asociada a

/Management/Groups, en un objeto contenedor de grupos o en el objeto de gruposmismo.

v El permiso add (A) es muy eficaz porque le permite agregar cualquier usuarioexistente a los grupos.Si se coloca un usuario externo en un grupo, el administrador del grupo tiene elcontrol de ese usuario (y podría compartir el control con administradores deotros grupos de los que el usuario es miembro).Es aconsejable que este permiso se conceda sólo a administradoresexperimentados responsables de la organización de usuarios y grupos y depolíticas corporativas.

Políticas de ACL que afectan a la gestión de usuariosEl administrador de grupos puede efectuar una acción para un usuario si tiene elpermiso adecuado definido en cualquiera de los grupos de los que ese usuario esmiembro.

Las operaciones y los permisos de ACL siguientes son los adecuados para lagestión de usuarios:

Operación Permiso

crear (un usuario nuevo en uno o más gruposespecificados) importar (datos de un usuario delregistro de usuarios)

N (create)

suprimir (un usuario) d (delete)

mostrar (detalles de un usuario) v (view)

modificar (descripción de un usuario) m (modify)

cuenta válida m (modify)

restablecer contraseña W (password)

contraseña válida W (password)

Para efectuar estas operaciones puede utilizar los comandos adecuados delprograma de utilidad pdadmin o Web Portal Manager.

Notas:v El permiso create (N) (en la ACL del grupo o en la ACL del contenedor de

grupos) le permite crear o importar un usuario y colocar ese usuario en losgrupos que controla.user create user1 “cn=user1,c=us” user1 user1 adcde group1user import user2 “cn=user2,c=us” group1

Capítulo 6. Delegación de tareas de administración 89

v También puede crear un usuario sin designar un grupo. En tal caso, el permisocreate (N) debe residir en una ACL del objeto contenedor /Management/Users.La ACL asociada a /Management/Users define los permisos de todos los usuarios(tanto si son o no miembros de un grupo).

v Un administrador de grupos puede efectuar una operación para un usuario sitiene el permiso adecuado definido en cualquiera de los grupos de los que eseusuario es miembro.

v Si un usuario no es miembro de ningún grupo, el administrador debe tener lospermisos adecuados de una ACL de /Management/Users para efectuaroperaciones para ese usuario.

v El permiso password (W) es adecuado para operadores de soporte que debenayudar a usuarios que han olvidado sus contraseñas.El operador puede restablecer la contraseña olvidada en un valor conocido y, acontinuación, establecer user modify password-valid (pdadmin) en “no”. Estaacción debería forzar al usuario a cambiar la contraseña cuando vuelve a iniciaruna sesión.

v El permiso view (v) se utiliza para controlar la salida de los comandos user list,user list-dn, user show groups, group list y group list-dn. El permiso view seutiliza para filtrar la salida de estos comandos. Si el usuario no tiene el permisoview en un grupo o usuario que el comando devuelve, dicho grupo o usuario sefiltra a partir de la salida.

Gestión de política de administración delegadaEn los dos apartados anteriores se describía por separado cómo delegar laadministración de una política de seguridad para proteger recursos en el dominioseguro y cómo delegar la gestión de los usuarios que acceden a esos recursos.Estos dos aspectos concretos de administración delegada suelen tener quecombinarse para establecer una política de seguridad de administración delegadacompleta.

Sin embargo, al hacer esto debe actuar con mucha precaución. En concreto, debeponer mucha atención en qué permisos, combinados con otros, concede.

Por ejemplo, el permiso A no debe concederse nunca junto con los permisos m oW, excepto si los administradores son eficaces y de confianza (y no en todos loscasos). La consecuencia de conceder tanto A como W a un administrador es queéste puede agregar cualquier usuario al grupo para el que tiene estos permisos ycambiar, a continuación, la contraseña de ese usuario. Cualquier usuario, como unadministrador senior o sec_master, puede ser objeto de esta acción. De estemanera, un administrador malintencionado podría tener acceso completo alsistema iniciando una sesión como usuario senior, por ejemplo.

La consecuencia de conceder los permisos A y m juntos es similar, con la excepciónde que un administrador con ambos permisos sólo puede utilizar esta combinaciónpara inhabilitar una cuenta.

Al definir una política de administración delegada completa, estas restriccionesimplican que los grupos de usuarios tengan una estructura específica y se utilizande una manera determinada.

Debe establecer grupos que utilice para delegar tareas de gestión de usuarios—como crear nuevos usuarios, suprimir usuarios y restablecer contraseñas deusuarios. Los administradores que efectúan tareas de administración de usuarios

90 IBM Tivoli Access Manager Base: Guía del administrador

debe tener los permisos N, d, m, W y v para crear, suprimir, modificar (inhabilitaro cambiar una descripción), restablecer o invalidar contraseñas y ver usuarios decuya gestión son responsables. Estos grupos se utilizan sólo para delegar gestiónde usuarios y no deben utilizarse para proteger otros recursos en el dominioseguro.

También debe establecer grupos que utilice para delegar la gestión de la política deseguridad para recursos protegidos en el dominio seguro. Los administradores quecontrolan la política de seguridad para estos grupos deben tener los permisos A yv, pero no los permisos N, d, m ni W. Estos grupos se utilizan para controlar elacceso a los recursos reales que necesitan protección.

Ejemplo:

Presuponga que tiene un espacio web al que se puede acceder en Internet con lossiguientes recursos:v accesible públicamentev accesible sólo para clientes y empleadosv accesible sólo para empleados

Este espacio podría estar estructurado de esta manera:/WebSEAL/

www.company_xyz.com/customers/sales/

Una ACL en la raíz del espacio web de www.company_xyz.com permite accesopúblico a todo el espacio web. Una ACL en customers permite acceso a clientes ypersonal de ventas y otra ACL en sales sólo permite acceso a personal de ventas.Estas ACL podrían tener el aspecto siguiente:public-access

usuario sec_master -abc---Tdm----lrxcualquier otro -------T------lrxno autenticado -------T------lrx

customer-accessusuario sec_master -abc---Tdm----lrxgrupo customers -------T------lrxgrupo sales -------T------lrxcualquier otro -----------------no autenticado -----------------

sales-accessusuario sec_master -abc---Tdm----lrxgrupo sales -------T------lrxcualquier otro -----------------no autenticado -----------------

Estas ACL deberían estar asociadas respectivamente a:/WebSEAL/www.compan_xyz.com/WebSEAL/www.company_xyz.com/customers/WebSEAL/www.company_xyz.com/sales

Presuponga que tiene la siguiente política de administración de usuarios delegada.Al personal de ventas (miembros del grupo “sales”) se le permite crear cuentasnuevas para clientes y concederles acceso a la parte customers del espacio web.Sólo a los administradores (miembros del grupo “sales-admin”) se les permitegestionar cuentas del nuevo personal de ventas.

La siguiente estructura de grupos implementa esta política:

Capítulo 6. Delegación de tareas de administración 91

/Management/Groups/

sales <- ACL sales-adminsales-users <- ACL sales-users-admincustomers <- ACL customers-admincustomers-users <- ACL customers-users-admin

La ACL sales-admin se utiliza para administrar miembros del grupo sales que, asu vez, se utiliza para controlar el acceso a la parte de sólo personal de ventas delespacio web. El único permiso necesario es para que el grupo “sales-admin” puedaagregar y eliminar usuarios de este grupo. El permiso view (v) también lo utilizanlos administradores para poder ver los miembros y los usuarios del grupo.sales-admin

grupo super-admin Tabcgrupo admin TAv

La ACL sales-users-admin, asociada al grupo sales-users, controla quién puedegestionar usuarios miembros del grupo sales-users (el grupo “sales-admin” denuevo).sales-users-admin

grupo super-admin Tabcgrupo admin TNWdmv

De la misma manera, la ACL customers-admin se utiliza para administrarmiembros del grupo customers que, a su vez, se utiliza para controlar el acceso ala parte de sólo clientes del espacio web.customers-admin

grupo super-admin Tabcgrupo sales TAv

La ACL customers-users-admin, asociada al grupo customers-users, controla quiénpuede gestionar los miembros del grupo customers-users (el grupo sales otra vez).También se permite a los miembros del grupo “sales-admin” gestionar clientes.customers-users-admin

grupo super-admin Tabcgrupo sales TNWdmvgrupo admin TNWdmv

Tenga presente que en cada ACL a una entrada del grupo super-admin se leconceden los permisos attach, browse y control. La administración de estas ACL esresponsabilidad de miembros del grupo super-admin.

92 IBM Tivoli Access Manager Base: Guía del administrador

Capítulo 7. Gestión de servidores de Access Manager

Este capítulo proporciona información detallada para efectuar tareas generales deadministración y configuración en servidores de Access Manager. También se hablade los archivos de configuración que soportan cada servidor.

Este capítulo contiene los apartados siguientes:v “Conceptos básicos de los servidores de Access Manager” en la página 93v “Inicio y detención de servidores de Access Manager” en la página 102v “Inicio y detención de servidores en sistemas Windows” en la página 103v “Inicio automático del servidor durante el reinicio” en la página 104v “Administración de Policy Server” en la página 104

Conceptos básicos de los servidores de Access ManagerAccess Manager se compone de los siguientes procesos de servidor (daemons):v Policy Server (pdmgrd)v Authorization Server (pdacld)v WebSEAL (webseald)

Policy Server (pdmgrd) gestiona la base de datos maestra de autorización (ACL) ymantiene información de la ubicación de otros servidores Access Manager en undominio seguro. Generalmente, Policy Server requiere muy pocas tareas deadministración o configuración.

Authorization Server (pdacld) permite a aplicaciones de terceros efectuar llamadasde autorización (a través de la API de autorización) al servicio de seguridad deAccess Manager. Generalmente, Authorization Server requiere muy pocas tareas deadministración o configuración.

WebSEAL (webseald) es un servidor web de alto rendimiento y varios threads queaplica una política de seguridad estricta al espacio de objetos protegidos web.WebSEAL puede proporcionar soluciones de inicio de sesión e incorporar recursosde servidores de aplicaciones web de fondo en su política de seguridad.

Condiciones de servidorEl servidor de Access Manager presenta las siguientes condiciones importantes:v En cualquier seguro dominio sólo puede haber una instancia de Policy Server y

la base de datos maestra de autorización (ACL).v Policy Server replica la base de datos de autorizaciones a todos los servidores de

Access Manager en el dominio seguro.v Cada gestor de recursos (por ejemplo, WebSEAL y Authorization Server) aplica

una política de control de acceso basada en información de la base de datos deautorizaciones replicada.

93

Conceptos básicos de las herramientas de administración delservidor

Para efectuar determinadas tareas de administración están disponibles lasinterfaces siguientes:v “Utilización del programa de utilidad pd_start para iniciar y detener servidores”v “Utilización del programa de utilidad pdacld_dump para volcar el contenido del

archivo”v “Utilización del programa de utilidad pdinfo para crear un informe sobre el

sistema” en la página 96v “Utilización del programa de utilidad de rastreo para capturar acciones de Base”

en la página 99

Para la resolución de problemas, estos programas de utilidad de línea decomandos pueden proporcionar información del estado y control de servidoresconcretos.

Utilización del programa de utilidad pd_start para iniciar ydetener servidoresUn administrador puede utilizar el programa de utilidad pd_start para detener,iniciar y reiniciar servidores manualmente y mostrar el estado del servidor. Paraobtener más información, consulte el apartado “Inicio y detención de servidores deAccess Manager” en la página 102.

Utilización del programa de utilidad pdacld_dump para volcar elcontenido del archivopdacld_dump le permite volcar el contenido de un archivo de base de datos depolíticas (master_authzn.db para pdmgrd y pdacld.db para pdacld). Mientras estávolcando el archivo de base de datos, pdacld_dump examina el contenido e intentaasegurarse de que la base de datos es válida. Después de examinar la base dedatos, este programa de utilidad muestra un breve resumen del archivo de base dedatos.

Figura 28. Componentes del servidor de Access Manager

94 IBM Tivoli Access Manager Base: Guía del administrador

El programa de utilidad pdacld_dump también puede utilizarse para copiar yconstruir un archivo de base de datos nuevo. Mientras está examinando elcontenido del archivo de base de datos, pdacld_dump puede construir un archivode base de datos nuevo, haciendo caso omiso de las entradas de base de datos queconsidere dañadas o no válidas. Esto puede permitir restaurar un entorno con unabase de datos dañada.

Nota: El nombre pdacld_dump es inapropiado. No guarda ninguna relación conPDAcld Authorization Server excepto que puede volcar el contenido de unarchivo de base de datos pdacld.

Ejecución del programa de utilidad pdacld_dump: El programa de utilidadpdacld_dump se encuentra en el siguiente directorio de instalación de AccessManager Base:

UNIX:/opt/PolicyDirector/sbin/

Windows:C:\Archivos de programa\Tivoli\Policy Director\sbin\

Debe encontrarse en este directorio para ejecutar el programa de utilidadpdacld_dump.

Sintaxis básica del comando pdacld_dump: El programa de utilidadpdacld_dump le permite efectuar las tareas siguientes:pdacld_dump comando

pdacld_dump[–v]

Devuelve la versión del programa de utilidad

pdacld_dump[–f]

Produce la salida nombrearchivo_bd

pdacld_dump[–s]

Sólo muestra el resumen que incluye el número de secuencia de la basede datos

pdacld_dump[–r]

Construye una base de datos nueva con la ruta_acceso y elnombrearchivo_bd que contienen entradas válidas de la base de datosfuente (especificada por la opción –f)

pdacld_dump[–l]

Especifica el nivel de comprobación de validación de manera quenúmero_nivel_validación es 1 ó 2, siendo 2 el valor predeterminado y elnivel de validación superior.

pdacld_dump[–t]

Muestra objetos de tipo_ID (utilizados con la opción –s)

Ejemplos:

v Para devolver la versión del programa de utilidad pdacld_dump, entre elcomando siguiente:pdacld_dump -v

Este comando devuelve lo siguiente:Policy Director ACL Database Viewer v3.9.0 (Build 020311)Copyright (C) IBM Corporation 1994-2002. All Rights Reserved.

v Para mostrar el archivo master_authzn.db, entre el comando siguiente:pdacld_dump -f /var/PolicyDirector/db/master_authzn.db

Capítulo 7. Gestión de servidores de Access Manager 95

Utilización del programa de utilidad pdinfo para crear un informesobre el sistemaLa finalidad del programa de utilidad pdinfo es recopilar y almacenar informaciónactual sobre el sistema Access Manager. Si tiene un problema, puede enviar elarchivo tar resultante al servicio técnico para que puedan ayudarle a resolverlo. Elprograma de utilidad pdinfo opera en un entorno de Access Manager en lasplataformas siguientes: HP-UX, Solaris, AIX, Linux y Windows NT/2000.

El programa de utilidad pdinfo forma parte de la instalación de Access ManagerBase (PDRTE). Otros componentes de Access Manager, como WebSEAL, contienenscripts Perl incorporados que se ejecutan automáticamente cuando se ejecuta elprograma de utilidad pdinfo y proporcionan la información del sistema apropiadapara ese componente.

El archivo de configuración pdinfo.cfg le permite personalizar el funcionamientodel programa de utilidad pdinfo.

Ejecución del programa de utilidad pdinfo: El programa de utilidad pdinfo seencuentra en el siguiente directorio de instalación de Access Manager Base:

UNIX:/opt/PolicyDirector/sbin/

Windows:C:\Archivos de programa\Tivoli\Policy Director\sbin\

Debe encontrarse en este directorio para ejecutar el programa de utilidad pdinfo outilizar una ruta de acceso completa alternativa. Cuando ejecuta el programa deutilidad pdinfo, se le pide que especifique la ruta de acceso completa para elarchivo de salida de información del sistema. Por ejemplo (UNIX):# cd /opt/PolicyDirector/sbin# ./pdinfoPlease enter the name (full path) of the desired output fileeg. /tmp/output.tar.gz:

Notas técnicas:

v En un entorno UNIX, debe haber iniciado la sesión como root para ejecutar elprograma de utilidad pdinfo satisfactoriamente.

v El directorio que contiene el archivo de salida debe tener acceso de escritura.v Asegúrese de haya suficiente espacio de disco duro.v En un entorno Windows, una limitación del programa de utilidad pdinfo no

permite una expresión de ruta de acceso completa para el archivo de salida.Debe indicar un nombre de archivo solamente. Este archivo se ubica en eldirectorio actual en el que ejecuta el programa de utilidad pdinfo.

v En un entorno Windows, el archivo de salida de ejemplo que aparece en elindicador de pdinfo es:eg. /tmp/output.tar

Contenido del archivo tar: El archivo tar que se obtiene del programa deutilidad pdinfo contiene los archivos siguientes:v Archivo de salida de información del sistema

Este nombre de archivo de salida está especificado en el archivo deconfiguración pdinfo.cfg.

v Archivo de registro de errores

96 IBM Tivoli Access Manager Base: Guía del administrador

Este archivo registra los errores que se producen cuando se ejecuta el programade utilidad pdinfo. El programa de utilidad pdinfo invoca otros comandos desistema para recopilar información. Este archivo colecciona todos los errores quese producen al ejecutar estos comandos del sistema.

v Archivos de configuración, auditoría y registro de Access ManagerTodos los archivos de configuración, auditoría y registro de Access Manager secoleccionan en el archivo tar.

v Vuelcos esenciales del servidor de Access ManagerLa tarea final del programa de utilidad pdinfo es desactivar los servidores deAccess Manager (excepto PDRTE) y registrar los archivos de vuelco esencialesresultantes. Para obtener más información, consulte $EXECUTE_BLADES, que semuestra más adelante.

Nota: No debe ejecutar el programa de utilidad pdinfo en un entorno deproducción. De forma predeterminada, el programa de utilidad pdinfodesactiva todos los servidores de Access Manager para registrar archivosde vuelco esenciales. Para obtener más información, consulte$EXECUTE_BLADES, que se muestra más adelante.

Utilización del archivo de configuración pdinfo.cfg: Puede personalizar lainformación recopilada por el programa de utilidad pdinfo utilizando el archivo deconfiguración pdinfo.cfg.

El archivo de configuración pdinfo.cfg se halla en el directorio siguiente:

UNIX:/opt/PolicyDirector/etc/pdinfo/

Windows:C:\Archivos de programa\Tivoli\Policy Director\etc\pdinfo\

El archivo de configuración contiene la información siguiente:

Nombres de los archivos de salida y de errores: Puede especificar los nombrespredeterminados del archivo de salida de información del sistema y del archivo deerrores específico de pdinfo. Estos nombres de archivo predeterminados son:$OUTPUT_FILE = "systeminfo.txt";$ERROR_FILE = "error.log";

Scripts de creación de informes de componentes de Access Manager: En este apartado seespecifica la ubicación de scripts de creación de informes de otros componentes deAccess Manager:$PDMGR_BLADE = "etc/pdinfo_pdmgr_blade.pl";$PDACLD_BLADE = "etc/pdinfo_pdacld_blade.pl";$PDWEB_BLADE = "etc/pdinfo_pdweb_blade.pl";

Nota: La versión actual de la herramienta pdinfo ejecuta automáticamente todoslos scripts de creación de informes adicionales (escritos en Perl 5.6) que seencuentran en el directorio /etc/pdinfo/ de cualquier componente deAccess Manager (“blade”). El programa de utilidad ya no utiliza losparámetros descritos anteriormente.

Tipos de información: Puede especificar el tipo de información recopilada por elprograma de utilidad pdinfo. Para habilitar la recopilación de informaciónespecífica, establezca el parámetro apropiado en “1”. Para habilitar la recopilación

Capítulo 7. Gestión de servidores de Access Manager 97

de información específica, establezca el parámetro apropiado en “0” o incluya uncarácter de comentario en la línea de parámetro.

Por ejemplo:$GATHER_MACHINE_INFO = 1;$GATHER_NETWORK_INFO = 1;$GATHER_PROCESS_INFO = 1;$GATHER_INSTALLED_INFO = 1;$GATHER_PD_INFO = 1;$EXECUTE_BLADES = 1;

Descripción de parámetros:

v La información de máquina ($GATHER_MACHINE_INFO) recopila el nombrede la máquina, la versión del sistema operativo, la arquitectura del sistema, losprocesadores, la RAM, las estadísticas de memoria virtual y el espacio de disco.

v La información de la red ($GATHER_NETWORK_INFO) recopila informaciónsobre interfaces, caché de ARP, direccionamiento y sockets de apertura.

v La información de los procesos actuales ($GATHER_PROCESS_INFO) recopilainformación sobre los procesos actuales que se ejecutan en el sistema.

v La información del software instalado ($GATHER_INSTALLED_INFO) recopilainformación sobre el software instalado actualmente en el sistema.

v La información de Access Manager ($GATHER_PD_INFO) recopila informaciónsobre el estado actual de Access Manager Base.

v La información de componentes de Access Manager ($EXECUTE_BLADES)ejecuta los scripts de creación de informes para otros componentes de AccessManager configurados.Esta es la sección del programa de utilidad pdinfo en la que los servidores deAccess Manager se desactivan para registrar los archivos de vuelco esencialesresultantes. La operación de desactivación tiene lugar en el script Perl para cadaservidor/”blade”. Por lo tanto, puede controlar la operación de desactivaciónservidor a servidor modificando el script adecuado para cada servidor.Si lo desea puede inhabilitar la ejecución de todos los scripts Perl estableciendo$EXECUTE_BLADES=0.

Ejemplo de archivo de configuración:#### Constant definitions$OUTPUT_FILE = "systeminfo.txt";$ERROR_FILE = "error.log";

$PDMGR_BLADE = "etc/pdinfo_pdmgr_blade.pl";$PDACLD_BLADE = "etc/pdinfo_pdacld_blade.pl";$PDWEB_BLADE = "etc/pdinfo_pdweb_blade.pl";

### CHANGE VARIABLES HERE TO DETERMINE WHAT INFORMATION IS GATHERED### BY DEFAULT ALL INFORMATION IS GATHERED - TO PREVENT INFORMATION BEINGGATHERED, COMMENT OUT THE APPROPRIATE VARIABLE, OR SET IT TO 0

### MACHINE INFORMATION: Machine Name, O/S Version, System Architecture,Processors, RAM, VM Stats, Disk Space$GATHER_MACHINE_INFO = 1;

### NETWORK INFORMATION: interfaces, arp cache, routing, open sockets$GATHER_NETWORK_INFO = 1;

### CURRENT PROCESSES: Current processes running on the system$GATHER_PROCESS_INFO = 1;

### INSTALLED SOFTWARE: Current installed software on the system

98 IBM Tivoli Access Manager Base: Guía del administrador

$GATHER_INSTALLED_INFO = 1;

### PD INFORMATION: information regarding the current state of PD$GATHER_PD_INFO = 1;

### EXECUTE PDWEB, ACLD, MGR, AND OTHER BLADES$EXECUTE_BLADES = 1;

Utilización del programa de utilidad de rastreo para capturaracciones de BaseEl programa de utilidad trace le permite capturar información sobre el flujo decontrol de programas y condiciones de error en Access Manager Base. Estainformación se almacena en un archivo y se utiliza a efectos de depuración. Elprograma de utilidad trace se proporciona principalmente para ayudar al personalde soporte a diagnosticar problemas que se producen en el funcionamiento delsoftware de Access Manager.

Como usuario, tal vez desee utilizar algunos componentes de rastreo de Base. Sinembargo, la mayor parte de componentes proporcionan muy pocas ventajas a noser que diagnostique problemas complejos con la ayuda del servicio técnico.

Nota: Utilice trace con precaución. Es una herramienta que se debe utilizar bajo ladirección del servicio técnico. A veces, los mensajes de trace son crípticos, noestán traducidos y pueden disminuir considerablemente el rendimiento delsistema.

Sintaxis básica del comando trace:pdadmin> server task webseald-instancia trace comando

El comando pdadmin trace le permite efectuar las tareas siguientes:

trace set Habilita el nivel de rastreo y rastrea el destino de mensajes para uncomponente y sus subordinados

trace show Muestra el nombre y el nivel de todos los componentes de rastreohabilitados o del componente especificado

trace list Lista todos los componentes de rastreo disponibles

Habilitar rastreo: Utilice el comando pdadmin trace set para habilitar larecopilación de información de rastreo para el componente y el nivel especificados.trace set componente nivel [agente-registro]

Argumento Descripción

componente El nombre del componente de rastreo. Necesario. Los componentesespecíficos de WebSEAL llevan el prefijo “pdweb”.

nivel Nivel de creación de informes. Necesario. Especifica la cantidad deinformación detallada recopilada por el programa de utilidad trace. Elrango es 1 a 9. El nivel 1 especifica la salida más detallada y el 9 lamenos detallada.

agenteregistro Opcionalmente especifica un destino para la información de rastreorecopilada para el componente especificado. Consulte el capítulo“Utilización del registro de eventos” de esta publicación para obtenerinformación detallada sobre la configuración.

Capítulo 7. Gestión de servidores de Access Manager 99

Mostrar componentes de rastreo habilitados: Lista todos los componentes de rastreohabilitados o un componente habilitado específico. Si un componente específico noestá habilitado, no se muestra ninguna salida.trace show [componente]

Ejemplo:pdadmin> server task webseald-instancia trace set pdweb.debug 2pdadmin> server task webseald-instancia trace showpdweb.debug 2

Lista todos los componentes de rastreo disponibles: Lista el componente especificado otodos los componentes disponibles para recopilar información del rastreo y crearun informe con dicha información.trace list [componente]

Componentes de rastreo de WebSEAL:

pdweb.debug: Nota: El componente pdweb.debug sólo funciona en el nivel 2.

El siguiente comando invoca el programa de utilidad trace para el componentepdweb.debug en el nivel 2 y dirige la salida a un archivo, utilizando elprocedimiento de registro de eventos para especificar un agente de registro dearchivos.pdadmin> server task webseald-<instancia> trace set pdweb.debug 2 \file path=/opt/pdweb/log/debug.log

A continuación se muestra la salida de este comando tal como aparece en elarchivo debug.log:/src/wand/wand/log.c:277: -------------- Browser ===> PD --------------Thread_ID:17GET /test/index.html HTTP/1.1Host: bevanUser-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4)Gecko/20011128 Netscape6/6.2.1Accept: text/xml, application/xml, application/xhtml+xml, text/html;q=0.9,image/png, image/jpeg, image/gif;q=0.2, text/plain;q=0.8, text/css,*/*;q=0.1Accept-Language: en-usAccept-Encoding: gzip, deflate, compress;q=0.9Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66Keep-Alive: 300Connection: keep-alive---------------------------------------------------

/src/wand/wand/log.c:277: -------------- PD ===> BackEnd --------------Thread_ID:17GET /index.html HTTP/1.1via: HTTP/1.1 bevan:443host: mokum.santacruz.na.tivoli.comuser-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4)Gecko/20011128 Netscape6/6.2.1accept: text/xml, application/xml, application/xhtml+xml, text/html;q=0.9,image/png, image/jpeg, image/gif;q=0.2, text/plain;q=0.8, text/css,*/*;q=0.1accept-language: en-usaccept-charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66accept-encoding: gzip, deflate, compress;q=0.9keep-alive: 300connection: close---------------------------------------------------

100 IBM Tivoli Access Manager Base: Guía del administrador

/src/wand/wand/log.c:277: -------------- PD <=== BackEnd --------------Thread_ID:17content-type: text/htmldate: Mon, 25 Mar 2002 19:48:32 GMTcontent-length: 7017etag: "0-1b69-3b688e48"last-modified: Thu, 02 Aug 2001 00:18:32 GMTserver: IBM_HTTP_SERVER/1.3.19 Apache/1.3.20 (Win32)connection: closeaccept-ranges: bytes---------------------------------------------------

/src/wand/wand/log.c:277: -------------- Browser <=== PD --------------Thread_ID:17HTTP/1.1 200 Document followscontent-type: text/htmldate: Mon, 25 Mar 2002 19:48:32 GMTcontent-length: 7017etag: "0-1b69-3b688e48"last-modified: Thu, 02 Aug 2001 00:18:32 GMTserver: IBM_HTTP_SERVER/1.3.19 Apache/1.3.20 (Win32)connection: closeaccept-ranges: bytes---------------------------------------------------

Archivos de configuración del servidorPuede utilizar los archivos de configuración del servidor para personalizar laoperación de cada servidor de Access Manager:

Nombre de servidor Archivo deconfiguración

Ubicación del archivo de configuración

Policy Server ivmgrd.conf UNIX: ruta_acceso_instalación/etc/ivmgrd.confWindows: ruta_acceso_instalación\etc\ivmgrd.conf

Authorization Server ivacld.conf UNIX: ruta_acceso_instalación/etc/ivacld.confWindows: ruta_acceso_instalación\etc\ivacld.conf

WebSEAL webseald.conf UNIX: /opt/pdweb/etc/webseald.confWindows: C:\Archivos de programa\Tivoli\PDWeb\etc\webseald.conf

Los archivos de programa de Access Manager Base están instalados en losdirectorios predeterminados siguientes:

UNIX: /opt/PolicyDirector/Windows: C:\Archivos de programa\Tivoli\Policy Director\

Esta guía utiliza la variable ruta_acceso_instalación para representar este directorioraíz. Todos los nombres de ruta de acceso relativos expresados en el archivo deconfiguración de Access Manager son relativos a este directorio raíz.

Los archivos de configuración se basan en texto ASCII y pueden editarseutilizando un editor de texto común. Los archivos de configuración contienenentradas de parámetros en el formato siguiente:parámetro=valor

Capítulo 7. Gestión de servidores de Access Manager 101

La instalación inicial de Access Manager establece valores predeterminados para lamayoría de parámetros. Algunos parámetros son estáticos y no cambian nunca;otros pueden modificarse para personalizar las funciones y el rendimiento delservidor.

Nota: Después de editar un archivo de configuración, debe detener y reiniciar elservidor de Access Manager para que los cambios entren en vigor.

Cada archivo contiene secciones, o stanzas, que contienen uno o más parámetrospara una categoría de configuración particular. Los niveles de stanza se muestranentre corchetes [nombre-stanza].

Por ejemplo, la stanza [ssl] de ivmgrd.conf define los valores de configuración deSSL para Policy Server. La stanza [ldap] define la configuración que Policy Servernecesita para comunicarse con el servidor de registro LDAP.

Los archivos contienen comentarios que explican la utilización de cada parámetro.

Si por algún motivo debe cambiar algún valor de configuración, edite los archivoscon precaución para mantener su integridad.

Inicio y detención de servidores de Access Manager

Inicio y detención de servidores en sistemas UNIXNormalmente, los procesos de un servidor se habilitan e inhabilitanautomáticamente mediante scripts que se ejecutan al iniciar y cerrar el sistema.

En un entorno UNIX, también puede utilizar el script pd_start para iniciar ydetener manualmente los procesos de servidor. Este procedimiento resultasatisfactorio cuando necesita personalizar una instalación o efectuar tareas deresolución de problemas. Los scripts sólo se pueden ejecutar en la máquina local.Utilice Web Portal Manager para detener e iniciar servidores de manera remota.

La sintaxis general para pd_start es la siguiente:# pd_start {start|restart|stop|status}

Puede ejecutar el programa de utilidad pd_start desde cualquier directorio. Elscript reside en el directorio siguiente:/opt/PolicyDirector/bin/

Iniciar los servidores de Access Manager mediante el programade utilidad pd_startUtilice el programa de utilidad pd_start para iniciar todos los servidores de AccessManager que no estén ejecutándose actualmente en una máquina particular:# pd_start start

Antes de devolver el indicador, este script espera a que todos los servidores sehayan iniciado.

Iniciar servidores individuales manualmentePuede iniciar los servidores individualmente ejecutando el servidor directamente.

Debe efectuar los comandos de inicio como un usuario administrador; por ejemplo,como root.

102 IBM Tivoli Access Manager Base: Guía del administrador

Inicie los servidores de Access Manager en el orden siguiente:1. Para Policy Server (pdmgrd), entre lo siguiente:

ruta_acceso_instalación/bin/pdmgrd

2. Para Authorization Server (pdacld), entre lo siguiente:ruta_acceso_instalación/bin/pdacld

Reiniciar los servidores de Access Manager mediante elprograma de utilidad pd_startUtilice el programa de utilidad pd_start para detener todos los servidores deAccess Manager en una máquina concreta y reiniciar, a continuación, losservidores:pd_start restart

Antes de devolver el indicador, este script espera a que todos los servidores sehayan iniciado.

Detener los servidores de Access Manager mediante el programade utilidad pd_startUtilice el programa de utilidad pd_start para detener todos los servidores deAccess Manager en una máquina concreta de manera ordenada:pd_start stop

Antes de devolver el indicador, este script espera a que todos los servidores sehayan detenido.

Mostrar el estado del servidor mediante el programa de utilidadpd_startUtilice el comando pd_start para mostrar el estado del servidor:pd_start status

Servidores de Access Manager:Servidor Activado En ejecución

pdmgrd sí síwebseald no nopdacld sí no

Inicio y detención de servidores en sistemas WindowsUtilice el Panel de control de servicios de Windows NT para iniciar y detener losprocesos del servidor manualmente. Esto puede proporcionarle algunas ventajas alpersonalizar una instalación o durante la resolución de problemas. Para usar esteprograma de utilidad se necesitan privilegios de administración.

Puede iniciar y detener los servidores de Access Manager todos a la vez o uno auno. Generalmente, deben detenerse e iniciarse siguiendo el orden correcto.

Utilización del Panel de control de servicios para detener einiciar servidoresEl Servicio de inicio automático inicia cada uno de los servidores de AccessManager siempre que la configuración de Inicio se haya establecido en“Automático”. Una vez iniciado el servidor, el Servicio de inicio automático sedesactiva.

También puede utilizar el Panel de control de servicios para iniciar y detenermanualmente cada uno de los servidores:1. Abra el Panel de control de Windows.

Capítulo 7. Gestión de servidores de Access Manager 103

2. Hada doble clic en el icono Servicios.Aparece el cuadro de diálogo Servicios.

3. En el cuadro de lista, seleccione los servidores de Access Manager según lasecuencia indicada en los pasos 4 y 5.

4. Detenga los servidores de Access Manager por este orden:v Authorization Serverv Policy Server

5. Inicie los servidores de Access Manager por este orden:v Policy Serverv Authorization Server

6. Haga clic en el botón de opción de control adecuado (Iniciar, Detener, Sistema)en el lado derecho del cuadro.

7. Para impedir que el Servicio de inicio automático inicie automáticamente unservidor de Access Manager, utilice el botón Iniciar... para establecer eseservidor en Deshabilitado.

Inicio automático del servidor durante el reinicioLos parámetros para que el servidor se inicie de manera automática se encuentranen la stanza [pdrte] del archivo de configuración pd.conf.

Policy ServerSi el paquete PDMgr está instalado, Policy Server se inicia automáticamente unavez reiniciado cada sistema:[pdrte]boot-start-ivmgrd = yes

Para impedir que pdmgrd se inicie automáticamente, establezca:boot-start-ivmgrd = no

Nota: Cada dominio seguro sólo debe contener uno. No instale ni ejecute pdmgrden más de un servidor por dominio seguro.

Authorization ServerSi el paquete PDAcld está instalado, el daemon de Authorization Server se iniciaautomáticamente una vez reiniciado cada sistema:[pdrte]boot-start-ivacld = yes

Para impedir que pdacld se inicie automáticamente, establezca:boot-start-ivacld = no

Administración de Policy ServerPolicy Server gestiona la base de datos maestra de políticas de autorización ymantiene la información de ubicación sobre otros servidores de Access Manager enel dominio seguro. Generalmente, Policy Server requiere muy pocas tareas deadministración o configuración. En este apartado se describen las tareas deconfiguración disponibles para el administrador.v “Réplica de la base de datos de autorizaciones” en la página 105

104 IBM Tivoli Access Manager Base: Guía del administrador

v “Establecimiento del número de threads del notificador de actualización” en lapágina 106

v “Establecimiento del tiempo de espera de la notificación” en la página 107

Réplica de la base de datos de autorizacionesUn administrador de Access Manager puede realizar cambios en la política deseguridad en el dominio seguro en cualquier momento. Una de lasresponsabilidades principales de Policy Server es efectuar los ajustes necesarios enla base de datos maestra de autorizaciones para reflejar estos cambios.

Cuando Policy Server realiza un cambio en la base de datos maestra deautorizaciones, puede enviar una notificación de este cambio a todos losAuthorization Servers (con bases de datos de réplica). A continuación, cadaAuthorization Server debe solicitar una actualización de la base de datos a la basede datos maestra de autorizaciones.

Nota: Adicionalmente, los servidores cliente pueden comprobar si hayactualizaciones de base de datos sondeando Policy Server a intervalosregulares. La configuración del sondeo para un cliente de WebSEAL, porejemplo, se explica en la publicación IBM Tivoli Access Manager WebSEALGuía del administrador.

Access Manager le permite configurar notificaciones de actualización desde PolicyServer para que sea un proceso automático o una tarea controlada manualmente.El parámetro auto-database-update-notify se encuentra en la stanza[ivmgrd] delarchivo de configuración ivmgrd.conf. De forma predeterminada, el parámetro estáestablecido en yes (Policy Server efectúa automáticamente la notificación deactualización):[ivmgrd]auto-database-update-notify = yes

Esta configuración automática es adecuada para entornos en los que se hacenpocos cambios en la base de datos y esporádicamente. Cuando configura lanotificación de actualización para que sea automática, también debe configurarcorrectamente los parámetros max-notifier-threads y notifier-wait-time. Consultelos apartados “Establecimiento del número de threads del notificador deactualización” en la página 106 y “Establecimiento del tiempo de espera de lanotificación” en la página 107.

Cuando configura la notificación de actualización para que sea manual, laaplicación manual del comando pdadmin server replicate controla este evento.[ivmgrd]auto-database-update-notify = no

Esta configuración manual es adecuada para entornos en los que se hacenbastantes cambios en la base de datos y de manera frecuente. En algunos casos,varias modificaciones en la base de datos pueden generar muchas notificaciones deactualización, que pasan a ser obsoletas debido a los cambios continuos en la basede datos maestra. Estas notificaciones obsoletas ocasionan una tráfico de redinnecesario.

El control manual de notificaciones de actualización le permite completar elproceso de modificar la base de datos maestra de autorizaciones antes de que seenvíen las notificaciones de actualización a Authorization Servers con réplicas debase de datos.

Capítulo 7. Gestión de servidores de Access Manager 105

En modalidad manual, la notificación de actualización utiliza la agrupación dethreads del notificador (tal como lo hace en modalidad automática). Por lo tanto, elvalor del parámetro max-notifier-threads afecta a la configuración de la modalidadmanual. Consulte el apartado “Establecimiento del número de threads delnotificador de actualización” en la página 106.

Utilización del comando pdadmin server replicateCuando configura la notificación de actualización para que sea manual, laaplicación manual del comando pdadmin server replicate controla este evento.Este comando tiene la sintaxis siguiente:pdadmin> server replicate [-server <nombre-servidor>]

Si se especifica el argumento nombre-servidor opcional, sólo a ese servidor se lenotifican los cambios efectuados en la base de datos maestra de autorizaciones. Sedevuelve una respuesta que indica si la notificación y la réplica han sidosatisfactorias o no.

Si no se especifica el argumento nombre-servidor, todos los Authorization Serversconfigurados reciben notificaciones de actualización. Una respuesta satisfactoriasólo indica que Policy Server ha empezado a enviar notificaciones de actualización.La respuesta no indica si los procesos de notificación y réplica reales han sidosatisfactorios o no.

La autorización necesaria para ejecutar este comando es “s” en el objeto/Management/Server.

Establecimiento del número de threads del notificador deactualización

Policy Server es responsable de sincronizar todas las réplicas de base de datos enel dominio seguro. Cuando se efectúa un cambio en la base de datos maestra, losthreads de notificación anuncian este cambio a todas las réplicas. A continuación,cada réplica tiene que bajar la nueva información de la base de datos maestra.

El archivo de configuración de Policy Server, ivmgrd.conf, contiene un parámetropara establecer el número máximo de threads del notificador de actualización. Estaagrupación de threads permite la notificación simultánea (paralela).

Por ejemplo, para notificar 30 réplicas de un cambio en la base de datos a la vez, laagrupación de threads debe establecerse en 30 por lo menos. Si hay más de 30réplicas, tiene lugar otra ronda de notificaciones (en este caso, 30 a la vez).Independientemente del valor de este parámetro, existe la seguridad de que senotifican todas las réplicas.

El objetivo del valor de los threads del notificador de actualización es notificar uncambio en la base de datos lo antes posible. Generalmente, el valor debe estableceren un número igual al de las réplicas existentes. Esto mejora el rendimiento altener una sola agrupación de threads que realizan rápidamente la tarea de notificara todas las réplicas a la vez.

La agrupación de threads del notificador de eventos predeterminada se haestablecido en:[ivmgrd]max-notifier-threads = 10

106 IBM Tivoli Access Manager Base: Guía del administrador

Consulte también el apartado “Establecimiento del tiempo de espera de lanotificación”.

Establecimiento del tiempo de espera de la notificaciónCuando a Policy Server se le indica que haga un cambio en la base de datosmaestra de autorizaciones, espera un periodo de tiempo predeterminado antes deenviar notificaciones a las réplicas de la base de datos. El tiempo de esperapredeterminado está establecido en 15 segundos. Este tiempo de espera serestablece cada vez que se hace un cambio en la base de datos.

La finalidad del tiempo de espera es impedir que Policy Server envíe notificacionesde réplica individuales por cada una de las series de cambios efectuados en la basede datos. El tiempo de espera mejora el rendimiento del sistema Access Manager.

Esta característica de rendimiento es particularmente importante para entornos enlos que se hacen cambios por lote en la base de datos de autorizaciones. No resultaeficaz para Policy Server que los cambios se envíen a réplicas de base de datoshasta que se hayan hecho tales cambios.

Puede alterar temporalmente este tiempo de retardo de notificaciónpredeterminada cambiando el valor del parámetro notifier-wait-time (ensegundos), que se encuentra en la stanza[ivmgrd] del archivo de configuraciónivmgrd.conf. Por ejemplo:[ivmgrd]notifier-wait-time = 20

De forma predeterminada, este valor está establecido en 15 segundos.

Capítulo 7. Gestión de servidores de Access Manager 107

108 IBM Tivoli Access Manager Base: Guía del administrador

Capítulo 8. Utilización del registro LDAP

LDAP es un protocolo que se ejecuta en TCP/IP. El protocolo LDAP estándarincluye definiciones de protocolo de red de bajo nivel y funciones derepresentación y manejo de datos. Los directorios a los que se puede acceder através de LDAP son conocidos comúnmente como directorios de LDAP.

La instalación predeterminada de Access Manager utiliza el directorio de LDAPpara almacenar información del usuario. La implementación de LDAP por parte deIBM recibe el nombre de IBM SecureWay Directory. La implementación de LDAPpor parte de iPlanet recibe el nombre de iPlanet Directory Server. Este capítulotrata de las características de configuración del registro LDAP de Access Manager.

Este capítulo contiene los apartados siguientes:v “Visión general de LDAP” en la página 109v “Configuración de la migración tras error de LDAP” en la página 112v “Aplicación de ACL de Access Manager a sufijos nuevos de LDAP” en la página

116

Visión general de LDAPEn 1988, la CCITT (Consultative International Telephonique et Telegraphique, queen la actualidad es la ITU-T, International Telecommunications Union-Telecommunication Standardization Sector) creó un estándar para servicios dedirectorio conocidos como x.500. Dos años después, el servicio de directorio X.500se convirtió en el estándar ISO 9594 (Data Communications Network Directory,Recommendations X.500-X.521).

Al conjunto de estándares ISO se le sigue haciendo referencia comúnmente comox.500. X.500 define un directorio que se puede utilizar universalmente para unagran cantidad de datos. Hoy en día, los directorios X.500 los utilizan las compañíastelefónicas nacionales para directorios de teléfonos en línea de gran tamaño.

Para acceder a un directorio X.500, el cliente utiliza Directory Access Protocol(DAP) que se definió junto con el estándar X.500. Desafortunadamente, DAP es unprotocolo complejo que no puede soportarse con facilidad en clientes reducidos,como los sistemas de sobremesa.

Por lo tanto, X.500 se utiliza en sistemas grandes e implementaciones a gran escala.Sin embargo, los requisitos para acceder a directorios centralizados desde clientesfinos son cada vez más importantes para soportar la obvia rentabilidad de losdirectorios centralizados.

Los trabajos realizados en la Universidad de Michigan y en NetscapeCommunications Corporation han dado como resultado una versión de DAPsimplificada, llamada Lightweight Directory Access Protocol (LDAP). LDAPsoporta la mayor parte de las características de DAP, pero carece de algunasfunciones complejas y raramente utilizadas. La implementación de LDAP esrelativamente simple y puede ser utilizada por aplicaciones de sistemas desobremesa.

109

LDAP: Un protocolo para servicios de directorioLDAP es un protocolo que se ejecuta en TCP/IP. El protocolo LDAP estándarincluye definiciones de protocolo de red de bajo nivel y funciones derepresentación y manejo de datos. Los directorios a los que se puede acceder através de LDAP son conocidos comúnmente como directorios de LDAP.

Nota: El LDAP estándar no define cómo se almacenan los datos en el directorio.

Al principio, LDAP se diseñó para que los clientes reducidos pudieran acceder aun directorio de X.500 a través de un servidor gateway que efectuaba la conversiónentre LDAP y DAP.

No se tardó en desarrollar directorios que pudieran manejar el protocolo LDAPnativo en lugar de tener que efectuar la conversión entre LDAP y DAP.

La implementación de un directorio LDAP por parte de IBM es SecureWayDirectory, que está disponible en AIX, Windows NT, Sun Solaris, OS/400 yOS/390.

Un directorio LDAP puede utilizar cualquier implementación de almacenamientopara los datos de directorio. Mientras la mayoría de las implementaciones utilizanbases de datos de archivos planos, IBM SecureWay Directory utiliza la base dedatos relacional DB2, de gran rendimiento y muy escalable, como suimplementación de almacenamiento.

Directorios de LDAPCasi todos los directorios almacenan información siguiendo una estructura similara la de un listín telefónico impreso. Las entradas suelen organizarse de manerajerárquica, lo que permite gestionarlas y buscarlas de manera eficaz y versátil.

Figura 29. Acceso de LDAP a X.500

Figura 30. Servidor LDAP autónomo

110 IBM Tivoli Access Manager Base: Guía del administrador

Los directorios LDAP ofrecen muchas más prestaciones y no se limitan a entradasde nombre, número de teléfono y dirección. De hecho, un directorio LDAP puedealmacenar (y posteriormente recuperar) casi cualquier tipo de datos. El tipo dedatos puede almacenarse en un directorio LDAP definido mediante el esquema dedirectorios, que puede ampliarse y adaptarse para satisfacer los requisitos delcliente.

La tarea de definir un esquema de directorios y el árbol jerárquico de informaciónde directorios puede compararse con la de diseñar una base datos relacional.Mediante el análisis de requisitos de aplicaciones, estándares corporativos ydefiniciones de datos es necesario diseñar un esquema de directorios y el árbol deinformación de directorios (DIT).

Los productos del servidor LDAP, como IBM SecureWay Directory, proporcionanun vasto esquema que puede utilizar, a menos que se requieran modificacionesespecíficas.

IBM soporta estándares y propuestas actuales y en desarrollo para definiciones dedatos participando activamente en los procesos estándar e implementando losresultados en IBM SecureWay Directory. El cuerpo de estándares más importantepara LDAP es Internet Engineering Task Force (IETF), en el que los representantesde IBM y otras industrias líder soportan activamente estas actividades.

Todas las organizaciones utilizan directorios. Por ejemplo, la mayoría de lossistemas operativos actuales, como UNIX o Windows 9x/NT, almacenaninformación de cuenta de usuario bien localmente o bien en servidores dedepartamento. Los sistemas operativos de red, como NetWare (Novell), tambiénnecesitan bases de datos de usuarios. En un departamento se puede mantener unabase de datos de empleados, mientras que en una empresa existen bases de datosde recursos humanos de mayor tamaño. Además, los sistemas operativosalmacenan una gran cantidad de datos sobre la configuración del sistema y otrosrecursos de la red, como impresoras y servidores.

La información suele almacenarse en múltiples ubicaciones, lo que hace que suadministración y mantenimiento sean innecesariamente complejos. Una de lasrazones principales por la que LDAP ha despertado rápidamente tanto interés eslas posibilidades que ofrece en cuanto a información distribuida a un solodirectorio basado en estándares.

El modelo de información de LDAPEl modelo de información de LDAP se basa en un subconjunto del modelo deinformación X.500. Los datos de un directorio LDAP se almacenan en entradas quecontienen atributos. La forma de los atributos es:tipo = valor

donde el tipo lo define un identificador de objeto (OID) y el valor tiene unasintaxis definida. Los atributos pueden ser de valor único (por ejemplo, unapersona sólo puede tener una fecha de nacimiento) o de varios valores (unapersona pueden tener varios números de teléfono).

Cada entrada de un directorio LDAP tiene un nombre distinguido (DN) único. Elesquema de directorios define reglas para DN y los atributos que una entrada debecontener. Para organizar la información almacenada en entradas de directorio, elesquema define clases de objeto. Una clase de objeto se compone de atributosobligatorios y opcionales.

Capítulo 8. Utilización del registro LDAP 111

Las clases de objeto pueden heredarse de otras clases de objeto, lo que proporcionaun método para ampliarlas de manera simple (por ejemplo, se pueden definirclases de objeto nuevas tan sólo agregando atributos nuevos a clases de objetoexistentes).

Características de LDAP

EscalabilidadLos directorios LDAP, particularmente cuando una base de datos relacional haceuna copia de seguridad de ellos, como en IBM SecureWay Directory, son muyescalables. El rendimiento de los directorios de gran tamaño con millones deentradas es excelente.

Debido a la base estándar común, otro factor de escalabilidad es la posibilidad deconfigurar de manera simple hardware y software de mayores prestaciones. LDAPno se basa en un sistema operativo específico y es independiente del proveedor.

DisponibilidadLDAP soporta la réplica y división de espacios de nombres. La réplica permite avarios servidores LDAP almacenar el contenido del mismo directorio. Esto permitea los clientes disponer de estos servidores adicionales cuando uno presentaanomalías.

La división permite almacenar las secciones de todo el directorio en diferentesubicaciones de servidores distintos. Esto no sólo aumenta la disponibilidad (ni unasola anomalía) si no que simplifica la gestión distribuida.

SeguridadLDAP soporta características de seguridad que impiden el acceso no autorizado adatos. Los protocolos de comunicación segura, como SSL y procedimientos deautenticación, junto con las políticas de listas de control de accesos (ACL) paraentradas de datos, garantizan el máximo nivel de seguridad.

GestionabilidadLas versiones actuales de LDAP, como IBM SecureWay Directory, proporcionan unainterfaz gráfica de usuario tanto para la administración de sistemas como para laadministración de datos de directorio. Su esquema ampliable dinámicamente lepermite ampliar el esquema de directorios sin interrumpir el servicio.

EstandarizaciónEl protocolo LDAP —junto con la mayoría de prestaciones de cliente/servidorrelacionadas, las interfaces de programación de aplicaciones (API) y lasdefiniciones de datos— están definidos por estándares oficiales o los RFC (solicitudde comentarios) correspondientes.

Por ejemplo, Lightweight Directory Access Protocol (v3), RFC 2251, define elprotocolo LDAP básico. En borradores de Internet hay definidas otrascaracterísticas, ampliamente aceptadas e implementadas. Gran parte de este trabajolo llevan a cabo IETF (Internet Engineering Task Force) y DMTF (DistributedManagement Task Force).

Configuración de la migración tras error de LDAPLightweight Directory Access Protocol (LDAP) define un método estándar paraacceder y actualizar información en un directorio. A los directorios se accedehabitualmente mediante el modelo de comunicación de cliente/servidor. Cualquierservidor que implementa el protocolo LDAP es un servidor de directorios LDAP.

112 IBM Tivoli Access Manager Base: Guía del administrador

La arquitectura distribuida de LDAP soporta servicios de directorio escalables conprestaciones de réplica de servidor. La réplica de servidor mejora la disponibilidadde un servicio de directorio. La réplica de IBM SecureWay Directory se basa en unmodelo de maestro-esclavo. La réplica de iPlanet Directory Server se basa en unmodelo de suministrador/consumidor. Sin embargo, Access Manager trata estemodelo como una relación maestro/esclavo.

La combinación de un servidor maestro y varios servidores replicados hace que losdatos de un directorio estén siempre disponibles cuando se necesitan. Si unservidor presenta anomalías, el servicio del directorio sigue estando disponible enotro servidor replicado. Access Manager soporta esta posibilidad de réplica.

El modelo de réplica de maestro-esclavoEn la réplica intervienen dos tipos de directorios: maestro y replicado. LDAP hacereferencia al maestro como servidor maestro y al replicado como servidorreplicado. Todas las actualizaciones se llevan a cabo en el servidor maestro y sepropagan posteriormente a los servidores replicados. La base de datos de cadaservidor replicado contiene una copia exacta de los datos del directorio delservidor maestro.

Los cambios al directorio sólo pueden hacerse en el servidor maestro, que siemprese utiliza para operaciones de escritura en el directorio. El servidor maestro o losservidores replicados pueden utilizarse para operaciones de lectura. Si el servidormaestro original deja de funcionar durante un periodo de tiempo largo, unservidor replicado puede sustituirle para permitir operaciones de escritura en eldirectorio.

Posibilidad de migración tras error de Access Manager enservidores LDAP

Access Manager establece conexión con el servidor maestro LDAP cuando se inicia.Si el servidor maestro LDAP está desactivado por algún motivo, el servidor deAccess Manager debe poder conectarse con un servidor replicado LDAP pararealizar operaciones de lectura.

La mayoría de las operaciones, sobre todo las de los usuarios habituales, son delectura. Estas operaciones incluyen la autenticación de usuario y el inicio de sesiónen servidores web de fondo conectados (junction). Después de una configuraciónadecuada, Access Manager efectuará una migración tras error en un servidorreplicado si no puede conectarse con el servidor maestro.

Encontrará los parámetros de configuración para efectuar una migración tras errorde LDAP en la stanza [ldap] del archivo de configuración ldap.conf:

UNIX: /opt/PolicyDirector/etc/ldap.confWindows: ruta_acceso_instalación\etc\ldap.conf

Configuración del servidor maestroIBM SecureWay Directory (LDAP) soporta la existencia de un solo servidormaestro de lectura-escritura LDAP. iPlanet Directory Server soporta variosservidores de lectura-escritura LDAP. Access Manager trata el servidor“suministrador” de iPlanet como el servidor maestro a efectos de configuración.

Capítulo 8. Utilización del registro LDAP 113

Las líneas de configuración activas en el archivo ldap.conf representan losparámetros y valores para este servidor maestro LDAP. Estos valores debendeterminarse durante la configuración de Access Manager. Por ejemplo:[ldap]enabled = yeshost = outbackport = 389ssl-port = 636max-search-size = 2048

Parámetro Descripción

enabled Access Manager utiliza un registro de usuarios LDAP. Losvalores son “yes” y “no”.

host El nombre de la red de la máquina donde se encuentra elservidor maestro LDAP.

port El puerto de escucha de TCP del servidor maestro LDAP.

ssl-port El puerto de escucha de SSL del servidor maestro LDAP.

max-search-size El límite de Access Manager que un cliente LDAP puede utilizarpara buscar elementos de base de datos - como una petición aWeb Portal Manager para que liste usuarios de la base de datosLDAP.

Si efectúa un cambio en la base de datos LDAP, como agregar una nueva cuenta deusuario mediante Web Portal Manager, Access Manager siempre utiliza el servidorde lectura-escritura (maestro) LDAP.

Configuración del servidor replicadoIBM SecureWay Directory (LDAP) soporta la existencia de uno o más servidoresreplicados de sólo lectura LDAP. iPlanet SecureWay Directory (LDAP) soporta laexistencia de uno o más servidores replicaods de sólo lectura LDAP, a los que sehace referencia como “consumidores”.

Debe agregar líneas a la stanza [ldap] que identifica todos los servidores replicadosdisponibles para Access Manager. Utilice la sintaxis siguiente para cada réplica:replica = servidor_ldap,puerto,tipo,preferencia

Parámetro Descripción

servidor-ldap El nombre de la red del servidor replicado LDAP.

puerto El puerto en el que este servidor escucha. Generalmente, utilizael 389 o el 636.

tipo La función del servidor replicado - “sólo lectura” o“lectura-escritura”. Generalmente, se utiliza “sólo lectura”. Untipo de “lectura-escritura” representaría un servidor maestro.

preferencia Un número del 1 al 10. Para conexiones LDAP se elige elservidor con el valor de preferencia más alto. Consulte elapartado “Definición de valores de preferencia para servidoresreplicados LDAP” en la página 115.

Ejemplo:replica = replica1.ldap.tivoli.com,389,readonly,5replica = replica2.ldap.tivoli.com,389,readonly,5

114 IBM Tivoli Access Manager Base: Guía del administrador

Los cambios efectuados en el archivo ldap.conf no entran en vigor hasta quereinicia Access Manager.

Definición de valores de preferencia para servidoresreplicados LDAP

Cada servidor replicado LDAP debe tener un valor de preferencia (1 a 10) quedetermina su prioridad para ser seleccionado como:v El servidor de acceso de sólo lectura primariov Un servidor de sólo lectura de seguridad durante una migración tras error

Cuanto más alto es el número, más alta es la prioridad. Si el servidor de sólolectura primario presenta anomalías por algún motivo, se utiliza el servidor cuyovalor de preferencia es el inmediatamente superior. Si dos o más servidores tienenel mismo valor de preferencia, un algoritmo de balance de carga del menosocupado determina cuál se selecciona.

Recuerde que el servidor maestro LDAP puede funcionar como servidor de sólolectura y como de lectura-escritura. Para acceso de sólo lectura, el servidor maestrotiene el valor predeterminado incorporado de preferencia de 5. Esto le permiteestablecer servidores en valores más altos o bajos que los del maestro para obtenerel rendimiento necesario. Por ejemplo, con los valores de preferencia adecuados,podría impedir que el servidor maestro manejara cada día operaciones de lectura.

Puede establecer valores de preferencia jerárquicamente para permitir el acceso aun solo servidor LDAP (con migración tras error para los otros servidores) oestablecer las mismas preferencias para todos los servidores y permitir que elbalance de carga indique qué servidor debe seleccionarse.

Las tabla siguiente muestra algunos casos de posibles preferencias. “M” hacereferencia al servidor maestro (sólo lectura/lectura-escritura) LDAP; “R1, R2, R3”hace referencia a servidores replicados (sólo lectura) LDAP.

M R1 R2 R3 Preferencia de migración tras error

5 5 5 5 Todos los servidores tienen el mismo valor depreferencia. El balance de carga determina quéservidor se selecciona para cada operación de acceso.

5 6 6 6 Los tres servidores replicados tienen el mismo valorde preferencia. El valor es más alto que el delservidor maestro. El balance de carga determina quéservidor, de entre los tres replicados, se selecciona. Elmaestro sólo se utiliza si ninguno de los tresreplicados está disponible.

5 6 7 8 El servidor 3 (con el valor de preferencia más alto) seconvierte en el servidor primario. Si el servidor 3presenta anomalías, el servidor 2 se convierte en elservidor primario porque tiene el valor de preferenciainmediatamente superior.

Los valores de preferencia sólo afectan al acceso de sólo lectura a la base de datosLDAP. Access Manager siempre utiliza el servidor maestro (lectura-escritura)cuando necesita efectuar un cambio en la base de datos LDAP.

Tenga presente que algunos daemons de Access Manager (como Policy Server)alteran temporalmente los valores de preferencia en sus archivos de configuración

Capítulo 8. Utilización del registro LDAP 115

para indicar que se prefiere el servidor de lectura-escritura. Esto ocurre porqueestos daemons suelen realizar operaciones de actualización que deberían ir alservidor maestro LDAP.

Sondeo del servidorSi un servidor LDAP presenta anomalías, Access Manager sondea continuamente elservidor para comprobar si vuelve a su actividad normal. El tiempo de sondeo es10 segundos.

Aplicación de ACL de Access Manager a sufijos nuevos de LDAP

Nota: La información siguiente se aplica tanto a IBM SecureWay Directory como aiPlanet Directory Server.

Cuando un administrador LDAP agrega sufijos de LDAP después de laconfiguración inicial de Access Manager, debe aplicar las ACL adecuadas para queAccess Manager gestione usuarios y grupos definidos es estos sufijos nuevos.

En IBM SecureWay Directory, utilice Directory Management Tool para aplicar lasACL. En el servidor LDAP de Netscape, utilice iPlanet Console 5.0.

Utilice la interfaz de administración de LDAP adecuada para aplicar las ACLsiguientes a todos los sufijos de Access Manager nuevos:

Grupo LDAP Control de accesos

cn=SecurityGroup,secAuthority=Default

v acceso completo

cn=ivacld-servers,cn=SecurityGroups,secAuthority=Default

v lectura

v búsqueda

v comparación

cn=remote-acl-users,cn=SecurityGroups,secAuthority=Default

v lectura

v búsqueda

v comparación

Estos controles se aplican cuando el administrador ha seleccionado LDAP para elregistro de usuarios de Access Manager y se ha creado un sufijo de LDAP nuevouna vez configurado Access Manager. Se presupone que es el administrador deAccess Manager y que está familiarizado tanto con Access Manager como conLDAP. También se presupone que, como administrador, tiene la autorizaciónadecuada para actualizar el árbol de información de directorios de LDAP.

Cuando Access Manager está configurado, intenta aplicar las ACL adecuadas atodos los sufijos de LDAP que existen en ese momento en el servidor LDAP. Estecontrol de acceso permite a Access Manager crear y gestionar información deusuarios y grupos en estos sufijos de LDAP.

Sin embargo, si se crea un sufijo después de que Access Manager se hayaconfigurado, y Access Manager tiene que crear y gestionar más adelanteinformación de usuarios y grupos en este sufijo nuevo, los controles de accesos

116 IBM Tivoli Access Manager Base: Guía del administrador

adecuados tendrán que aplicarse manualmente. Sin estos controles de accesos,Access Manager no tiene el permiso de LDAP adecuado para crear y gestionar lainformación de usuarios y grupos especificada para que esté en este sufijo nuevo.

Para aplicar los controles de accesos adecuados al sufijo de LDAP creadorecientemente, efectúe los pasos siguientes para IBM SecureWay Directory o iPlanetDirectory Server, dependiendo de qué tipo de servidor LDAP esté utilizando.

Tenga presente que los procedimientos presuponen que el sufijo creadorecientemente recibe el nombre de “o=neworg,c=us”. Debe sustituir este valor porel sufijo real creado recientemente en las descripciones siguientes.

Procedimientos en el servidor IBM SecureWay DirectoryLos pasos siguientes describen cómo aplicar los controles de accesos de AccessManager adecuados al sufijo creado recientemente en el servidor IBM SecureWayDirectory.

1. Inicie Directory Management Tool (DMT) de LDAP con uno de los comandossiguientes:En sistemas Windows: Inicio →Programas → IBM SecureWay Directory →Directory Management Tool

En sistemas UNIX:# /usr/bin/dmt

2. Podría aparecer el aviso siguiente:Warning: Entry o=neworg,c=us does not contain any data.

Haga caso omiso de este aviso. En el paso 8, tendrá que efectuar unarellamada si se le ha mostrado este aviso.

3. Haga clic en el botón Add Server del panel izquierdo. Aparece la ventanaAdd Server.

4. Entre estos valores para cada uno de los campos siguientes:

Campo Valor Comentario

Nombre de servidor: ldap://nombrehost Por ejemplo, ibm007.ibm.com

Puerto: 389 389 es el puerto predeterminado

DN de usuario: cn=root DN del administrador de LDAP

Contraseña de usuario: abc123 Contraseña del administradorLDAP

5. Haga clic en OK. Aparecerá la página de Directory Management Tool.6. Verifique que el nombre del servidor está en la parte superior del marco

izquierdo. Por ejemplo, ldap://ibm007.ibm.com:3897. En la estructura de árbol de la izquierda, seleccione Directory Tree → Browse

Tree. Podría aparecer el aviso siguiente:Warning: Entry o=neworg,c=us does not contain any data.

8. Vaya al paso 9 en la página 118 si no se le mostrado el mensaje siguiente:Warning: Entry o=neworg,c=us does not contain any data.

En caso contrario, debe crear una entrada para el sufijo. El control de accesosno puede aplicarse al sufijo hasta que exista una entrada. Siga estos pasospara crear una entrada:

Capítulo 8. Utilización del registro LDAP 117

a. Haga clic en el botón Add del panel derecho. Se mostrará el cuadro dediálogo Add an LDAP Entry.

b. Establezca el tipo de entrada en Organization. Establezca el DN padre enc=us. Establezca en DN de entrada en o=neworg. Haga clic en OK. Semostrará la página de entrada para la organización dentro del cuadro Addan LDAP.

c. Entre el nombre de organización (neworg) en la sección Attributes de laetiqueta o:.

d. Haga clic en Add. Se mostrará la página Browse Directory Tree.9. Haga clic en Directory Tree → Refresh Tree del panel izquierdo.

10. Resalte el sufijo creado recientemente en el panel Browse Tree de la derecha.11. Haga clic en el botón ACL del panel derecho. Se mostrarán los valores de la

lista de control de accesos actual para el sufijo en la ventana Edit an LDAPACL.

12. En el área Subject de la ventana Edit an LDAP ACL, entre el nombredistinguido siguiente:cn=SecurityGroup,secAuthority=Default

Compruebe el tipo de grupo y haga clic en Add.13. Cuando se muestre la ventana, seleccione lo siguiente:

v En el cuadro DN entry, seleccione Descendant directory tree entries inheritfrom this entry.

v En el cuadro Rights, para las entradas Add child y Delete entry, seleccioneGrant.

v En el cuadro Security class, para cada clase de seguridad (Normal,Sensitive y Critical), seleccione Grant para cada permiso (Read, Write,Search y Compare).

Haga clic en OK.14. Resalte el sufijo creado recientemente en el panel Browse Tree de la derecha.15. Haga clic en el botón ACL del panel derecho. Verifique que el grupo

cn=SecurityGroup,secAuthority=Default aparezca en la lista y que susvalores sean correctos. Los nombres de los grupos no son sensibles amayúsculas y minúsculas.

16. En el área Subject de la ventana Edit an LDAP ACL, entre el nombredistinguido siguiente:cn=ivacld-servers,cn=SecurityGroups,secAuthority=Default

Seleccione el grupo Type y haga clic en Add.17. Cuando se muestre la ventana, seleccione lo siguiente:

v En el cuadro DN entry, seleccione Descendant directory tree entries inheritfrom this entry.

v En el cuadro Rights, para las entradas Add child y Delete entry, seleccioneUnspecified.

v En el cuadro Security class, para la clase de seguridad Normal, seleccioneGrant para los permisos Read, Search y Compare.

v En el cuadro Security class, para la clase de seguridad Normal, seleccioneUnspecified para el permiso Write.

v En el cuadro Security class, para las clases de seguridad Sensitive yCritical, seleccione Unspecified para todos los permisos.

Haga clic en OK.

118 IBM Tivoli Access Manager Base: Guía del administrador

18. Resalte el sufijo creado recientemente en el panel Browse Tree de la derecha.Haga clic en el botón ACL del panel derecho. Verifique que el grupocn=ivacld-servers,cn=SecurityGroups,secAuthority=Default aparezca en lalista y que sus valores sean correctos. Los nombres de los grupos no sonsensibles a mayúsculas y minúsculas.

19. En el área Subject de la ventana Edit an LDAP ACL, entre el nombredistinguido siguiente:cn=remote-acl-users,cn=SecurityGroups,secAuthority=Default

Seleccione el grupo Type y haga clic en Add.20. Cuando se muestre la ventana, seleccione lo siguiente:

v En el cuadro DN entry, seleccione Descendant directory tree entries inheritfrom this entry.

v En el cuadro Rights, para las entradas Add child y Delete entry, seleccioneUnspecified.

v En el cuadro Security class, para la clase de seguridad Normal, seleccioneGrant para los permisos Read, Search y Compare.

v En el cuadro Security class, para la clase de seguridad Normal, seleccioneUnspecified para el permiso Write.

v En el cuadro Security class, para las clases de seguridad Sensitive yCritical, seleccione Unspecified para cada permiso (Read, Write, Search yCompare).

Haga clic en OK.21. Haga clic en Exit para cerrar Directory Management Tool.

Procedimientos en iPlanet Directory ServerTenga en cuenta que estos procedimientos describen la creación de ACL parasufijos que utilizan iPlanet Console 5.0.

1. Inicie iPlanet Console 5.0 con uno de los comandos siguientes:v En sistemas UNIX, entre lo siguiente en el directorio de instalación de

iPlanet Directory Server:# ./startconsole

v En sistemas Windows, haga clic en Inicio → Programas → iPlanet ServerProducts → iPlanet Console 5.0

2. Entre el ID de usuario para el administrador LDAP. Suele ser cn=DirectoryManager. Entre la contraseña y la dirección URL de administrador. Haga clicen OK.

3. Seleccione el dominio que Access Manager va a utilizar.4. Expanda el nombre del servidor y Server Group.5. Seleccione la entrada etiquetada Directory Server. Se mostrará información de

configuración de iPlanet Directory Server.6. Haga clic en el botón Open. Accederá a iPlanet Directory Server.7. Haga clic en la ficha Directory. Si el sufijo creado recientemente se muestra en

el panel izquierdo, vaya al paso 8 en la página 120Si el sufijo creado recientemente no aparece en el panel izquierdo, debe crearuna entrada para el nuevo sufijo antes de aplicarle controles de acceso. Sigaestos pasos para crear la entrada:a. Resalte el nombre del servidor de la parte superior del árbol de

directorios. Haga clic en Object → New Root Object. Se muestra una listade sufijos raíz.

Capítulo 8. Utilización del registro LDAP 119

b. Seleccione o=neworg,c=us en la lista de sufijos raíz. Se muestra la ventanade selección New Object.

c. En la ventana de selección New Object, desplácese y seleccioneOrganization como el tipo de entrada de nuevo objeto.

d. Haga clic en OK. Se mostrará la ventana Property Editor.e. En el campo Organization especifique neworg y haga clic en OK.

Nota: En estas instrucciones se presupone que el sufijo es de ejemplo. Creeel tipo de entrada y el nombre que corresponde al sufijo real.

f. Haga clic en View → Refresh. La entrada del nuevo sufijo aparece en elpanel izquierdo.

8. Resalte la entrada neworg en el panel izquierdo. Haga clic en Object → SetAccess Permissions. Se mostrará la ventana Manage Access Control foro=neworg,c=us.

9. Haga clic en New para mostrar la ventana Edit ACI for o=neworg, c=us.10. Especifique el nombre como SECURITY GROUP - ALLOW ALL.11. Resalte el nombre de All Users y haga clic en Remove.12. Haga clic en Edit Manually. Se mostrará la ventana Edit ACI for

o=neworg,c=us.13. Sustituya el texto de ACI predeterminado por lo siguiente:

(target="ldap:///o=neworg,c=us")(targetattr="*")(version 3.0; acl "SECURITY GROUP - ALLOW ALL";allow (all)groupdn = "ldap:///cn=SecurityGroup,secAuthority=Default";)

Haga clic en Check Syntax para asegurarse de que ha entrado el textocorrectamente. Efectúe comprobaciones de sintaxis y corrija errores hasta queno haya ninguno.

14. Haga clic en OK. Se mostrará la ventana Manage Access Control foro=neworg,c=us.

15. Haga clic en New. EspecifiquePD Servers GROUP - ALLOW READ

para el nombre de ACI.16. Resalte el nombre de All Users y haga clic en Remove.17. Haga clic en Edit Manually. Se mostrará la ventana Edit ACI for

o=neworg,c=us.18. Sustituya el texto de ACI predeterminado por lo siguiente:

(target="ldap:///o=neworg,c=us")(targetattr="*")(version 3.0; acl "SECURITY GROUP - ALLOW READ";allow(read, search, compare)groupdn = "ldap:///cn=ivacld-servers,cn=SecurityGroups,secAuthority=Default";)

Haga clic en Check Syntax para asegurarse de que ha entrado el textocorrectamente. Efectúe comprobaciones de sintaxis y corrija errores hasta queno haya ninguno.

19. Haga clic en OK. Se mostrará la ventana Manage Access Control foro=neworg,c=us.

20. Haga clic en New. Especifique PD Remote ACL Users GROUP -ALLOW READ parael nombre de ACI.

21. Resalte el nombre de All Users y haga clic en Remove.

120 IBM Tivoli Access Manager Base: Guía del administrador

22. Haga clic en Edit Manually. Se mostrará la ventana Edit ACI foro=neworg,c=us.

23. Sustituya el texto de ACI predeterminado por lo siguiente:(target="ldap:///o=neworg,c=us")(targetattr="*")(version 3.0; acl "SECURITY GROUP - ALLOW READ";allow (read, search, compare)groupdn = "ldap:///cn=remote-acl-users,cn=SecurityGroups,secAuthority=Default";)

Haga clic en Check Syntax para asegurarse de que ha entrado el textocorrectamente. Efectúe comprobaciones de sintaxis y corrija errores hasta queno haya ninguno.

24. Haga clic en OK. Se mostrará la ventana Manage Access Control foro=neworg,c=us.

25. Haga clic en New. Especifique PD Deny-Others1 para el nombre de ACI.26. Resalte el nombre de All Users y haga clic en Remove.27. Haga clic en Edit Manually. Se mostrará la ventana Edit ACI for

o=neworg,c=us.28. Sustituya el texto de ACI predeterminado por lo siguiente:

(targetfilter="(|(objectclass=secUser)(objectclass=secGroup))")(version 3.0; acl "PD Deny-Others"; deny(all)groupdn != "ldap:///cn=SecurityGroup,secAuthority=Default ||ldap:///cn=remote-acl-users,cn=SecurityGroups,secAuthority=Default ||ldap:///cn=ivacld-servers,cn=SecurityGroups,secAuthority=Default";)

Haga clic en Check Syntax para asegurarse de que ha entrado el textocorrectamente. Efectúe comprobaciones de sintaxis y corrija errores hasta queno haya ningún error de sintaxis.

29. Haga clic en OK. Se mostrará la ventana Manage Access Control foro=neworg,c=us.

30. Haga clic en New. Especifique PD Deny-Others2 para el nombre de ACI.31. Resalte el nombre de All Users y haga clic en Remove.32. Haga clic en Edit Manually. Se mostrará la ventana Edit ACI for

o=neworg,c=us.33. Sustituya el texto de ACI predeterminado por lo siguiente:

(targetfilter="(|(objectclass=secPolicyData)(objectclass=secPolicy))")(version 3.0; acl "PD Deny-Others"; deny(all)groupdn != "ldap:///cn=SecurityGroup,secAuthority=Default ||ldap:///cn=remote-acl-users,cn=SecurityGroups,secAuthority=Default ||ldap:///cn=ivacld-servers,cn=SecurityGroups,secAuthority=Default";)

Haga clic en Check Syntax para asegurarse de que ha entrado el textocorrectamente. Efectúe comprobaciones de sintaxis y corrija errores hasta queno haya ninguno.

34. Haga clic en OK. Se mostrará la ventana Manage Access Control foro=neworg,c=us.

35. Haga clic en OK para cerrar la ventana Manage Access Control foro=neworg,c=us.

36. Haga clic en Console → Exit para salir de la consola.

Capítulo 8. Utilización del registro LDAP 121

122 IBM Tivoli Access Manager Base: Guía del administrador

Capítulo 9. Registro y auditoría de la actividad del servidor

Access Manager proporciona una serie de prestaciones de registro y auditoría. Losarchivos de registro pueden capturar cualquier error y mensajes de avisogenerados por los servidores de Access Manager. Los archivos de seguimiento deauditoría pueden capturar eventos de autorización, autenticación, gestión y HTTPque tienen lugar en los servidores de Access Manager.

Este capítulo contiene los apartados siguientes:v “Conceptos básicos de registro y auditoría” en la página 123v “Archivos de seguimiento de auditoría”v “Registro de mensajes de servicio de Base” en la página 124v “Archivos de seguimiento de auditoría de Access Manager” en la página 125v “Formato del archivo de seguimiento de auditoría” en la página 128v “Contenido del archivo de seguimiento de auditoría” en la página 130

Conceptos básicos de registro y auditoríaEl contenido de los archivos de registro y seguimiento de auditoría puedeutilizarse como fuente de información al supervisar y resolver problemas de laactividad de los servidores de Access Manager.

Archivos de seguimiento de auditoríaLos servidores de Access Manager utilizan los archivos de seguimiento deauditoría para almacenar registros de la actividad del servidor. La salida de unevento de servidor específico recibe el nombre de registro. Un seguimiento deauditoría es una colección de múltiples registros que proporcionan información dela actividad del servidor. Todos los archivos de seguimiento de auditoría de AccessManager están en formato ASCII.

Los archivos de seguimiento de auditoría de Access Manager registran eventos delos servidores siguientes:v Policy Server (pdmgrd)v Authorization Server (pdacld)v WebSEAL (webseald)

Consulte el apartado “Archivos de seguimiento de auditoría de Access Manager”en la página 125.

Consulte el apartado “Formato del archivo de seguimiento de auditoría” en lapágina 128.

Consulte el apartado “Contenido del archivo de seguimiento de auditoría” en lapágina 130.

Convenio de documentación: ruta_acceso_instalaciónLa variable ruta_acceso_instalación utilizada a lo largo de este capítulo tiene lassiguientes interpretaciones, según la plataforma de sistema operativo:

123

UNIX: /opt/PolicyDirector/Windows: \Archivos de programa\Tivoli\Policy Director

Esta ruta de acceso se establece en UNIX y no puede modificarse.

La plataforma Windows le permite definir la ruta_acceso_instalación durante lainstalación del software de Access Manager.

Registro de mensajes de servicio de BaseLos mensajes de servicio de Access Manager Base los controla el archivo dedireccionamiento de Access Manager Base. El archivo de direccionamiento seencuentra en el directorio siguiente:

UNIX:/opt/PolicyDirector/etc/

Windows:C:\Archivos de programa\Tivoli\Policy Director\etc\

El archivo de direccionamiento es un archivo ASCII que contiene documentaciónadicional en forma de líneas de comentario. Las entradas de este archivo deconfiguración determinan los tipos de mensajes de servicio que están registrados.Para habilitar una entrada se debe eliminar el carácter de comentario (#). Elarchivo de direccionamiento incluye las entradas predeterminadas siguientes:

UNIX:FATAL:STDOUT:-;FILE:/var/PolicyDirector/log/fatal.logERROR:STDOUT:-;FILE:/var/PolicyDirector/log/error.logWARNING:STDOUT:-;FILE:/var/PolicyDirector/log/warning.logNOTICE:FILE.10.100:/var/PolicyDirector/log/notice.log#NOTICE_VERBOSE:STDOUT:-;FILE:/var/PolicyDirector/log/verbose.log

Windows:FATAL:STDERR:-;FILE:%PDDIR%/log/fatal.logERROR:STDERR:-;FILE:%PDDIR%/log/error.logWARNING:STDERR:-;FILE:%PDDIR%/log/warning.logNOTICE:FILE.10.100:%PDDIR%/log/notice.log

Nota: En un sistema Windows, la variable de entorno especial PDDIR se establecedurante el tiempo de ejecución en el directorio de instalación de AccessManager.

De forma predeterminada, cuando Access Manager Base se ejecuta en primerplano, los mensajes se manejan así:1. Los mensajes se envían a la pantalla (STDOUT, STDERR).2. Los mensajes se envían a las correspondientes entradas de archivo de registro

configuradas del directorio log (fatal.log, error.log, warning.log ynotice.log).

De forma predeterminada, cuando Access Manager Base se ejecuta en segundoplano, los mensajes se manejan así:1. Los mensajes se redireccionan de STDOUT y STDERR y se envían al archivo de

registro de servidor adecuado tal como se ha definido en la stanza [logging]del archivo de configuración de servidor adecuado.

124 IBM Tivoli Access Manager Base: Guía del administrador

Servidor Archivo deconfiguración

Ubicación del archivo de registro

Policy Server

(pdmgrd)

ivmgrd.conf UNIX:[logging]log-file=/var/PolicyDirector/log/ivmgrd.log

Windows:[logging]log-file=ruta_acceso_instalación\log\ivmgrd.log

Authorization Server

(pdacld)

ivacld.conf UNIX:[logging]log-file=/var/PolicyDirector/log/ivacld.log

Windows:[logging]log-file=ruta_acceso_instalación\log\ivacld.log

2. Los mensajes también se envían a las correspondientes entradas de archivo deregistro configuradas del directorio log (fatal.log, error.log, warning.log ynotice.log).

Para habilitar verbose.log, elimine el carácter de comentario de la líneaNOTICE_VERBOSE.

La sintaxis FILE del mensaje NOTICE controla la creación de nuevos registros y losnuevos ciclos del archivo:FILE.archivos_máx.registros_máx

El valor de archivos_máx especifica el número de archivos que se han utilizado.

El valor de registros_máx especifica el número máximo de entradas por archivo.

En el ejemplo anterior, FILE.10.100 significa que se han creado 10 archivos, cadauno con 100 entradas como máximo. Los archivos se llaman:notice.log.1notice.log.2...notice.log.10

Los mensajes se “acomodan” en el primer archivo después de que el últimoarchivo haya alcanzado su límite o cuando el servidor se detiene y reinicia.Cuando se vuelve a utilizar un archivo de registro, se escribe encima de losregistros existentes (se borran).

Archivos de seguimiento de auditoría de Access ManagerLa auditoría es la colección de datos sobre actividades del sistema que puedenafectar al funcionamiento seguro del proceso de autorización de Access Manager.Cada servidor de Access Manager puede capturar eventos de auditoría siempreque se produce una actividad que puede auditarse relacionada con la seguridad.

Los eventos de auditoría se guardan como registros de auditoría que documentanla actividad específica de ese servidor. Cada actividad auditada recibe el nombre

Capítulo 9. Registro y auditoría de la actividad del servidor 125

de evento de auditoría. Una colección de registros de eventos de auditoríaalmacenados en un archivo recibe el nombre de seguimiento de auditoría.

Cada servidor de Access Manager mantiene su archivo de auditoría propio. Losservidores de Access Manager incluyen:v Policy Server (pdmgrd)v Authorization Server (pdacld)v WebSEAL (webseald)v Aplicaciones desarrolladas por el usuario que utilizan Authorization ADK

(Consulte la publicación Access Manager Authorization ADK Developer Reference)

Los parámetros para configurar los archivos de seguimiento de auditoría delservidor Access Manager se encuentran en la stanza [aznapi-configuration] decada uno de los archivos <nombre-servidor>.conf.

Servidor nombre-servidor Archivo de configuración

Policy Server pdmgrd ivmgrd.conf

Authorization Server pdacld ivacld.conf

WebSEAL webseald webseald.conf

Habilitación e inhabilitación de la auditoríaEl registro de seguimiento de auditoría se habilita servidor a servidor; para ello, seestablece el valor logaudit en la stanza [aznapi-configuration] del archivo deconfiguración del servidor específico.

De forma predeterminada, la auditoría está inhabilitada:[aznapi-configuration]logaudit = no

El valor yes habilita la auditoría para ese servidor. Por ejemplo:[aznapi-configuration]logaudit = yes

Especificación de la ubicación del archivo de registroDe forma predeterminada, el archivo de seguimiento de auditoría para cadaservidor recibe el nombre de audit.log y se mantiene en el directorio del registrodel servidor específico. El parámetro auditlog del archivo de configuración de cadaservidor especifica la ubicación del archivo de seguimiento de comprobación.

Servidor Ubicación del archivo de registro

Policy Server

(pdmgrd)

UNIX:auditlog=/var/PolicyDirector/audit/pdmgrd.log

Windows:auditlog=C:\pd\audit\pdmgrd.log

Authorization Server

(pdacld)

UNIX:auditlog=/var/PolicyDirector/audit/pdacld.log

Windows:auditlog=C:\pd\audit\pdacld.log

126 IBM Tivoli Access Manager Base: Guía del administrador

Especificación de umbrales de creación de archivos deauditoría

El parámetro logsize especifica el tamaño máximo que puede alcanzar cada uno delos archivos de seguimiento de auditoría y tiene el siguiente valor predeterminado(en bytes):[aznapi-configuration]logsize = 2000000

Cuando un archivo de seguimiento de auditoría alcanza el valor especificado—conocido como umbral de creación— se realiza una copia de seguridad delarchivo existente en un archivo con el mismo nombre y con la indicación anexadade fecha y hora. A continuación, se inicia un nuevo archivo de seguimiento deauditoría.

Los diferentes valores posibles de logsize se interpretan de la manera siguiente:v Si el valor de logsize es menor que cero (< 0), se crea un nuevo archivo de

seguimiento de auditoría cada vez que se invoca el proceso de auditoría y cada24 horas a partir de esa instancia.

v Si el valor de logsize es igual a cero (= 0), no se crea ningún nuevo archivo deseguimiento de auditoría y el que ya existe crece indefinidamente. Si ya existeun archivo de seguimiento de auditoría, los datos nuevos se agregan en éste.

v Si el valor de logsize es mayor que cero (> 0), se crea un nuevo archivo deseguimiento de auditoría cuando uno existente alcanza el valor de umbralconfigurado. Si ya existe un archivo de seguimiento de auditoría durante elinicio, los datos nuevos se agregan en éste.

Especificación de la frecuencia para vaciar los búferes de losarchivos de auditoría

Los archivos de seguimiento de auditoría se escriben en secuencias de datos conbúfer. Si supervisa los archivos de seguimiento de auditoría en tiempo real, puedealterar la frecuencia con la cual el servidor fuerza un vaciado de los búferes delarchivo de seguimiento de auditoría.

De forma predeterminada, los archivos de seguimiento de auditoría se vacían cada20 segundos:[aznapi-configuration]logflush = 20

Si especifica un valor negativo, se forzará un vaciado cada vez que se escriba unregistro.

Especificación de eventos de auditoríaLos eventos de auditoría se dividen en categorías según la función del servidorque los genera. Algunas funciones son comunes en los servidores de AccessManager, mientras que otras son específicas de cada servidor. Cada tipo de funciónde servidor está asociado a un indicador de auditoría:

Indicador de auditoría Función del servidor

authn Auditoría de autenticación de obtención de credenciales

azn Auditoría de eventos de autorización

mgmt Auditoría de comandos de gestión

http Auditoría de peticiones HTTP de Webseal

Capítulo 9. Registro y auditoría de la actividad del servidor 127

Puede configurar cada servidor de Access Manager para capturar de maneraselectiva eventos de auditoría categoría a categoría. Por ejemplo, la siguienteconfiguración captura sólo eventos de autenticación e inhabilita la captura de losdemás eventos, incluida la alteración temporal de cualquier auditoría deautorización habilitada en valores de POP.[aznapi-configuration]auditcfg = authn

Los valores siguientes habilitan la auditoría de autorización y peticiones HTTP deWebSEAL, pero inhabilitan las demás categorías de auditoría para el servidorWebSEAL:[aznapi-configuration]auditcfg = httpauditcfg = authn

De forma predeterminada, cuando una auditoría está habilitada para un procesocon indicadores de auditoría configurados, se capturan todos los eventosauditables.

La tabla siguiente indica los eventos de auditoría (indicados mediante el indicadorde auditoría) que pueden capturarse para cada servidor de Access Managerespecífico.

Indicador deauditoría

webseald pdmgrd pdacld authadk

authn X X X X

azn X X X X

mgmt X

http X

Formato del archivo de seguimiento de auditoríaLos eventos de auditoría se capturan durante el seguimiento de auditoría en unformato estándar que utiliza indicadores de estilo XML. Aunque XML sólo es unpaso intermedio para proporcionar una vista de presentación de los datos, elarchivo XML está en formato ASCII y puede leerse directamente o pasarse a otrasmáquinas que efectúan un análisis más detallado.

Un seguimiento de auditoría entero no representa un único documento XML. Cadaevento de auditoría del archivo se escribe como un bloque de datos XML aislado.Cada bloque de datos se ajusta a las reglas de sintaxis de XML estándar.

Como administrador de auditoría, puede seleccionar y extraer eventos según sucriterio. Esto podría incluir volver a formatear cada evento aplicando una DTD(definición de tipo de documento) o esquema adecuados en la herramienta deanálisis que utilice. La DTD es un formato intermedio que proporciona unadescripción de los datos que pueden capturarse.

A continuación se muestra una DTD sugerida.<!--audit_event.dtd --><!ELEMENT event (date, outcome, originator, accessor, target, data*)><!ATTLIST event

rev CDATA "1.1"

128 IBM Tivoli Access Manager Base: Guía del administrador

link CDATA #IMPLIED ><!ELEMENT date (#PCDATA)><!ELEMENT outcome (#PCDATA)><!ATTLIST outcome

status CDATA #IMPLIED><!ELEMENT originator (component, event, location)><!ATTLIST originator

blade CDATA #REQUIRED><!ELEMENT component rev CDATA “1.0”><!ELEMENT action (#PCDATA)><!ELEMENT location (#PCDATA)><!ELEMENT accessor (principal*)><!ATTLIST accessor

name CDATA #REQUIRED><!ELEMENT principal (#PCDATA)><!ATTLIST principal

auth CDATA #REQUIRED><!ELEMENT target (object, process?, azn?)><!ATTLIST target

resource CDATA #REQUIRED><!ELEMENT object (#PCDATA)><!ELEMENT process (pid, rid, eid, uid, gid)><!ATTLIST process

architecture (unix | nt) ’unix’><!ELEMENT pid #PCDATA><!ELEMENT rid #PCDATA><!ELEMENT eid #PCDATA><!ELEMENT uid #PCDATA><!ELEMENT gid #PCDATA><!ELEMENT azn (perm, result, qualifier)><!ELEMENT perm #PCDATA><!ELEMENT result #PCDATA><!ELEMENT qualifier #PCDATA><!ELEMENT data #PCDATA><!ATTLIST data

tag CDATA #REQUIRED>

Puesto que la auditoría de Access Manager utiliza un formato de registro estándar,no todos los campos son importantes para cada evento registrado. Generalmente,cada evento captura el resultado de una acción que un principal intenta en unobjeto destino.

La información sobre la acción, las credenciales del principal, el objeto destino y lasalida se capturan en una cabecera con formato común del registro de auditoría.Los campos que no son importantes para un evento concreto pueden contener unvalor predeterminado. La información adicional específica del evento tambiénpuede registrarse en un área de datos sin formato al final del registro.

Para decodificar el significado de determinados valores de datos en los registros,podría necesitarse un conocimiento avanzado del código y la arquitectura deAccess Manager.

Atributo de estado del campo de salidaEl campo outcome siempre incluye un código de status de Access Manager y unvalor de salida. Los posibles valores de salida incluyen:0 = SUCCESS1 = FAILURE2 = PENDING3 = UNKNOWN

Puede utilizar el comando pdadmin errtext para proporcionar una interpretacióndel código de estado de Policy Director (412668954 en el ejemplo siguiente).

Capítulo 9. Registro y auditoría de la actividad del servidor 129

<outcome status=”412668954”>1</outcome>

Atributo de recurso del campo destinoEl atributo resource del campo target representa una extensa clasificación porcategorías del objeto destino:0 = AUTHORISATION1 = PROCESS2 = TCB3 = CREDENTIAL5 = GENERAL

Contenido del archivo de seguimiento de auditoría

Registros de auditoría de autorizaciónLa autorización es la función principal de los servidores de Access Manager. Losregistros de auditoría de autorización pueden capturarse cuando un objeto destinode la base de datos de políticas de autorización de Access Manager (espacio deobjetos protegidos) tiene una POP asociada que habilita la función de auditoría.

Consulte el apartado Capítulo 4, “Utilización de políticas de objetos protegidos” enla página 63.

Puede configurar la auditoría para un servidor concreto agregando “azn” a la listade configuraciones de auditoría en la stanza [aznapi-configuration] del archivo deconfiguración del servidor:[aznapi-configuration]auditcfg = azn

A continuación se muestra un ejemplo de registro de auditoría para el eventosiguiente:pdadmin> pop modify pop1 set audit-level all

<event rev="1.1"><date>2001-08-05-16:25:08.341+00:00I-----</date><outcome status="0">0</outcome><originator blade="pdmgrd"><component rev=”1.1”>mgmt</component><action>13702</action><location>phaedrus</location></originator><accessor name=""><principal auth="IV_LDAP_V3.0">sec_master</principal></accessor><target resource="5"><object></object></target><data>“13702”“pop1”“pop1”“false”“15”“0”“““0”“0”“0”“127”“1”“0”

130 IBM Tivoli Access Manager Base: Guía del administrador

“0”“0”</data></event>

Registros de auditoría de autenticaciónLa autenticación de un principal se lleva a cabo fuera de Access Manager durantela obtención de credenciales. Access Manager puede capturar registros de auditoríapara registrar si los intentos de autenticación han sido satisfactorios o no.

Puede configurar la auditoría de intentos de autenticación agregando “authn” a lalista de configuraciones de auditoría en la stanza [aznapi-configuration] delarchivo de configuración del servidor:[aznapi-configuration]auditcfg = authn

A continuación se muestra un evento de autenticación registrado en WebSEAL paraun usuario no autenticado.<event rev="1.1"><date>2001-08-05-23:04:26.630+00:00I-----</date><outcome status="0">0</outcome><originator blade="webseald"><component>authn</component><event rev="1">0</event><location>location not specified</location></originator><accessor name="unknown"><principal auth="invalid"></principal></accessor><target resource="5"><object></object></target><data></data></event>

Registros de auditoría de WebSEALLa actividad del servidor web puede registrarse opcionalmente en el archivo deseguimiento de auditoría como adición o sustitución de los archivos de formato deregistro común HTTP estándar descritos en la publicación IBM Tivoli AccessManager WebSEAL Guía del administrador.

Puede configurar la auditoría de la actividad de WebSEAL agregando “http” a lalista de configuraciones de auditoría en la stanza [aznapi-configuration] delarchivo de configuración del servidor WebSEAL:[aznapi-configuration]auditcfg = http

A continuación se muestra un ejemplo de registro de auditoría de acceso HTTP:<event rev="1.1"><date>2001-08-05-23:04:26.931+00:00I-----</date><outcome status="412668954">1</outcome><originator blade="webseald"><component>http</component><event rev="1">2</event><location>146.84.251.70</location></originator><accessor name="user not specified"><principal auth="IV_DCE_V3.0">cell_admin</principal></accessor><target resource="5"><object>/pics/pd30.gif</object></target><data></data></event>

Capítulo 9. Registro y auditoría de la actividad del servidor 131

Registros de auditoría de gestiónUna de las funciones de Policy Server es mantener la base de datos maestra depolíticas de autorización. Esta base de datos incluye la descripción del espacio deobjetos protegidos para el dominio seguro, políticas de ACL y POP y el lugar enque las ACL y las POP se asocian a objetos.

Puede configurar la auditoría de la actividad de Policy Server agregando “mgmt” ala lista de configuraciones de auditoría en la stanza [aznapi-configuration] delarchivo de configuración de Policy Server:[aznapi-configuration]auditcfg = mgmt

A continuación se muestra un ejemplo de registros de eventos del comandopdadmin:pdadmin> pop modify pop1 set audit-level all<event rev="1.1"><date>2001-08-05-23:01:37.078+00:00I-----</date><outcome status="0">0</outcome><originator blade="ivmgrd"><component>mgmt</component><event rev="1">3702</event><location>location not specified</location></originator><accessor name="user not specified"><principal auth="IV_DCE_V3.0">cell_admin</principal></accessor><target resource="5"><object></object></target><data>"2019""1002""pop1""0"""</data></event>

Códigos de ID de campo de evento para comandos de gestiónLos registros de auditoría para comandos de gestión contienen un código de ID deevento que identifica uno de los comandos (pdadmin) de gestión de AccessManager. Los argumentos de los comandos se listan en la sección data del registrode eventos en su formato interno.

Tenga en cuenta que los comandos que no producen un cambio de estado efectivode la base de datos (como list y show) no se capturan nunca.

Comandos de gestión de ACL

ACL_LIST 13000

ACL_GET 13001

ACL_SET 13002

ACL_DELETE 13003

ACL_FIND 13005

ACTION_LIST 13006

ACTION_SET 13007

ACTION_DELETE 13008

ACTION_GROUPLIST 13009

ACTION_GROUPCREATE 13010

132 IBM Tivoli Access Manager Base: Guía del administrador

ACTION_GROUPDELETE 13011

ACTION_LISTGROUP 13012

ACTION_CREATEGROUP 13013

ACTION_DELETEGROUP 13014

Comandos de gestión de objetos

OBJSPC_CREATE 13103

OBJSPC_DELETE 13104

OBJSPC_LIST 13105

OBJ_CREATE 13106

OBJ_DELETE 13107

OBJ_MOD_SET_NAME 13110

OBJ_MOD_SET_DESC 13111

OBJ_MOD_SET_TYPE 13112

OBJ_MOD_SET_ISLF 13113

OBJ_MOD_SET_ISPOL 13114

OBJ_MOD_SET_ATTR 13115

OBJ_MOD_DEL_ATTR 13116

OBJ_MOD_DEL_ATTRVAL 13117

OBJ_SHOW_ATTR 13118

OBJ_LIST_ATTR 13119

ACL_ATTACH 13120

ACL_DETACH 13121

ACL_MOD_SET_ATTR 13123

ACL_MOD_DEL_ATTR 13124

ACL_MOD_DEL_ATTRVAL 13125

ACL_SHOW_ATTR 13126

ACL_LIST_ATTR 13127

POP_MOD_SET_ATTR 13128

POP_MOD_DEL_ATTR 13129

POP_MOD_DEL_ATTRVAL 13130

POP_SHOW_ATTR 13131

POP_LIST_ATTR 13132

OBJ_SHOW_ATTRS 13133

ACL_SHOW_ATTRS 13134

POP_SHOW_ATTRS 13135

OBJ_SHOW 13136

OBJ_LIST 13137

OBJ_LISTANDSHOW 13138

Comandos de gestión de servidor

SERVER_GET 13200

SERVER_LIST 13203

SERVER_PERFORMTASK 13204

Capítulo 9. Registro y auditoría de la actividad del servidor 133

SERVER_GETTASKLIST 13205

SERVER_REPLICATE 13206

Comandos de gestión de administradores, usuarios y grupos

ADMIN_SHOWCONF 13400

USER_CREATE 13401

USER_IMPORT 13402

USER_MODDESC 13403

USER_MODPWD 13404

USER_MODAUTHMECH 13405

USER_MODACCVALID 13406

USER_MODPWDVALID 13407

USER_DELETE 13408

USER_SHOWGROUPS 13409

USER_SHOW 13410

USER_SHOWDN 13411

USER_LIST 13412

USER_LISTDN 13413

GROUP_CREATE 13414

GROUP_IMPORT 13415

GROUP_MODDESC 13416

GROUP_MODADD 13417

GROUP_MODREMOVE 13418

GROUP_DELETE 13419

GROUP_SHOW 13420

GROUP_SHOWDN 13421

GROUP_LIST 13422

GROUP_LISTDN 13423

GROUP_SHOWMEMB 13424

USER_MODGSOUSER 13425

USER_SET 13426

GROUP_SET 13427

13500 →13599 son utilizados por GSO

GSO_RESOURCE_CREATE 13500

GSO_RESOURCE_DELETE 13501

GSO_RESOURCE_LIST 13502

GSO_RESOURCE_SHOW 13503

Comandos de credenciales de recursos de GSO

GSO_RESOURCE_CRED_CREATE 13504

GSO_RESOURCE_CRED_DELETE 13505

GSO_RESOURCE_CRED_MODIFY 13506

GSO_RESOURCE_CRED_LIST 13507

GSO_RESOURCE_CRED_SHOW 13508

134 IBM Tivoli Access Manager Base: Guía del administrador

Comandos de grupos de recursos de GSO

GSO_RESOURCE_GROUP_CREATE 13509

GSO_RESOURCE_GROUP_DELETE 13510

GSO_RESOURCE_GROUP_ADD 13511

GSO_RESOURCE_GROUP_REMOVE 13512

GSO_RESOURCE_GROUP_LIST 13513

GSO_RESOURCE_GROUP_SHOW 13514

Comandos de políticas

POLICY_SET_MAX_LOGIN_FAILURES 13600

POLICY_GET_MAX_LOGIN_FAILURES 13601

POLICY_SET_DISABLE_TIME_INTERVAL 13602

POLICY_GET_DISABLE_TIME_INTERVAL 13603

POLICY_SET_MAX_ACCOUNT_AGE 13604

POLICY_GET_MAX_ACCOUNT_AGE 13605

POLICY_SET_ACCOUNT_EXPIRY_DATE 13606

POLICY_GET_ACCOUNT_EXPIRY_DATE 13607

POLICY_SET_MAX_INACTIVITY_TIME 13608

POLICY_GET_MAX_INACTIVITY_TIME 13609

POLICY_GET_ACCOUNT_CREATION_DATE 13610

POLICY_GET_LAST_LOGIN_ATTEMPT_DATE 13611

POLICY_SET_MAX_PASSWORD_AGE 13612

POLICY_GET_MAX_PASSWORD_AGE 13613

POLICY_SET_MIN_PASSWORD_AGE 13614

POLICY_GET_MIN_PASSWORD_AGE 13615

POLICY_SET_MAX_PASSWORD_REPEATED_CHARS 13616

POLICY_GET_MAX_PASSWORD_REPEATED_CHARS 13617

POLICY_SET_MIN_PASSWORD_ALPHAS 13618

POLICY_GET_MIN_PASSWORD_ALPHAS 13619

POLICY_SET_MIN_PASSWORD_NON_ALPHAS 13620

POLICY_GET_MIN_PASSWORD_NON_ALPHAS 13621

POLICY_SET_MIN_PASSWORD_DIFFERENT_CHARS 13622

POLICY_GET_MIN_PASSWORD_DIFFERENT_CHARS 13623

POLICY_SET_PASSWORD_SPACES 13624

POLICY_GET_PASSWORD_SPACES 13625

POLICY_SET_MIN_PASSWORD_LENGTH 13626

POLICY_GET_MIN_PASSWORD_LENGTH 13627

POLICY_SET_MIN_PASSWORD_REUSE_TIME 13628

POLICY_GET_MIN_PASSWORD_REUSE_TIME 13629

POLICY_GET_PASSWORD_FAILURES 13630

POLICY_GET_LAST_PASSWORD_CHANGE_DATE 13631

POLICY_SET_NUMBER_WARN_DAYS 13632

POLICY_GET_NUMBER_WARN_DAYS 13633

Capítulo 9. Registro y auditoría de la actividad del servidor 135

POLICY_SET_PASSWORD_REUSE_NUM 13634

POLICY_GET_PASSWORD_REUSE_NUM 13635

POLICY_SET_TOD_ACCESS 13636

POLICY_GET_TOD_ACCESS 13637

Comandos de POP

POP_CREATE 13700

POP_DELETE 13701

POP_MODIFY 13702

POP_SHOW 13703

POP_LIST 13704

POP_ATTACH 13705

POP_DETACH 13706

POP_FIND 13707

Comandos de configuración (13800 → 13899)

CFG_CONFIG 13800

CFG_UNCONFIG 13801

CFG_REBNEWCERT 13802

CFG_CHGPORT 13803

136 IBM Tivoli Access Manager Base: Guía del administrador

Capítulo 10. Utilización del registro de eventos

En este capítulo se describen las mejoras para la operación de registro en archivosde registro de Access Manager. Las versiones anteriores de Access Managerregistraban eventos en varios archivos de registro no relacionados de manera quecada archivo tenía un método diferente de configurar la captura de información endisco.

En la versión actual, el concepto de la información que se ha de capturar esindependiente de la acción de registrar esa información en un archivo. La finalidadde esto es soportar la colección y el registro de seguimientos de auditoríacentralizados. Esta nueva función también ofrece más versatilidad para laconfiguración y captura de otros datos de eventos de Access Manager.

Concepto de eventos de Access ManagerAparte de algunos mensajes producidos al iniciar un programa, todos los mensajesgenerados por Access Manager a efectos de auditoría y otros servicios se crean enuna jerarquía estructurada de eventos de Access Manager.

La clasificación ordenada de eventos en categorías dentro de esta jerarquía permiteefectuar asociaciones de tiempo de ejecución entre clases de eventos y los agentesde registro que se han de utilizar para registrar tales eventos. El concepto deagente de registro también se ha ampliado para incluir el registro de eventos aotros destinos distintos del sistema de archivos local. La jerarquía de eventos seconstruye dinámicamente durante la ejecución de programas. Mientras algunascategorías conocidas están presentes al ejecutar un programa de Access Manager,otras son específicas del programa y otras pueden ser transitorias.

La finalidad de este capítulo es describir cómo se pueden asociar agentes deregistro de la jerarquía de agrupación de eventos con eventos de registro. Estecapítulo no proporciona una descripción de las características de todos los posibleseventos dentro de la jerarquía. Para obtener la descripción de eventos conocidos,como los generados para auditoría, consulte la documentación específica delproducto adecuado.

137

Generalmente, la jerarquía de agrupación de eventos tiene este aspecto:

Una categoría de eventos específica se identifica por una lista de nombresseparados por puntos. El primer nivel de un nombre en la categoría tiene unsignificado especial. Este nombre también podría corresponder a eventos asociadospreviamente con archivos de registro heredados, descritos en releases anteriores deAccess Manager.

Por ejemplo, presuponga que el nombre de categoría de eventos se construye deesta manera:categoría_dominio.sub_categoría.sub_categoría...

Los dominios de eventos de auditoría, http y mensaje correspondenrespectivamente a los eventos registrados para Tivoli SecureWay Policy DirectorVersión 3.7 en el seguimiento de auditoría, a los registros de peticiones http deWebSEAL y a los registros de mensajes de servicio del Entorno de SistemasDistribuidos (DCE). En la versión 3.8 se incluyeron algunos dominios de eventosnuevos, como rastreo, estadísticas y remotos. Los eventos de rastreo y estadísticasrecopilan información de servicio sobre la ejecución de programas. Los eventosremotos implementan la colección y el registro centralizados de archivos deregistro.

Nota sobre la implementación: A efectos de eficacia, un evento no suele crearse sino hay agentes de registro suscritos para registrar eventos de esa categoría. En elcaso de que se genere un evento y no haya agentes de registro suscritos pararegistrarlo, el evento se descarta.

Configuración del registro de eventosAdemás del método de configuración de archivos de registro, compatible conversiones anteriores, puede especificar elementos de línea en la stanza[aznapi-configuration] de un archivo de configuración del programa (.conf)para configurar la captura de eventos de Access Manager.

Figura 31. Jerarquía de agrupación de eventos

138 IBM Tivoli Access Manager Base: Guía del administrador

Para habilitar el registro de eventos de Access Manager utilizando la nuevainterfaz, debe asociar un destino de registro a una categoría de eventos en laagrupación de eventos. Actualmente, hay cuatro tipos de destinos soportados parala captura de eventos:v Agente de registro de consolav Agente de registro de archivov Agente de registro de canalizaciónv Agente de registro remoto

El formato de una línea de configuración del agente de registro es el siguiente:logcfg =<categoría>:{stdout|stderr|file|pipe|remote} \[[<parámetro>[=<valor>]][<parámetro>[=<valor>]]]

Las opciones de estos tipos de agentes de registro pueden especificarse encualquier orden y suelen ser opcionales. A continuación, se describen las opcionespara cada tipo de agente de registro. En una entrada de configuración, los nombresde opciones no son sensibles a mayúsculas y minúsculas y pueden abreviarse enrelación con la longitud del nombre de opción completo, que sigue siendo único.

Por ejemplo, considere la siguiente forma simplificada:logcfg = <categoría>:<agente-registro>

El nombre categoría puede apuntar a cualquier nodo de la jerarquía de agrupaciónde eventos. La captura de eventos de una categoría se aplica a todos lossubcomponentes de la jerarquía. Es decir, el evento foo.bar.fred también se capturaen la categoría foo.bar.

Puede asociar varios agentes de registro en la misma categoría. Por ejemplo, lasiguiente configuración copia eventos de auditoría de autorización en un archivo ylos envía a un programa de escucha en una canalización:logcfg = audit.azn:file path=/var/PolicyDirector/log/audit.aznlogcfg = audit.azn:pipe path=/bin/analyse.exe

El diagrama siguiente muestra la relación que guardan los pasos del proceso deregistro. La parte superior del diagrama representa el código de un servidor deAccess Manager. El programador ha agregado puntos de prueba en el código en elque podrían generarse tipos de eventos específicos. A continuación, los eventosgenerados se envían a la agrupación de eventos de servidor para su posibleregistro mediante un punto de captura (el ″sumidero″), que define la categoría deeventos.

Durante el tiempo de ejecución, un usuario puede suscribir un agente de registroen cualquier punto de la jerarquía de eventos para registrar de manera selectivaeventos generados en los puntos de prueba de los programas. Esto se muestra enparte central del diagrama.

El agente de registro que puede suscribir para capturar eventos es el cliente deregistro remoto. Este cliente envía los eventos seleccionados a un servidor pdacldremoto. La parte inferior del diagrama muestra este servidor remoto. Observe quela parte final del diagrama es básicamente la misma que la superior, pero con loseventos enviados situados en puntos de prueba remotos de pdacld de la

Capítulo 10. Utilización del registro de eventos 139

agrupación de eventos.

Configuración de la cola de propagación de eventos centralLos eventos se pasan a agentes de registro suscritos de manera sincronizada conlas peticiones de nivel de aplicación que construyen los eventos de registro. Loseventos pasan a través de una cola de propagación común antes de serdistribuidos a los diferentes agentes de registro suscritos.

El perfil de servicio de esta cola de propagación es configurable. Para configurar lacola de propagación, debe especificar una entrada logcfg con formato abreviado.La entrada de configuración abreviada utiliza EventPool como el nombre decategoría y especifica opciones de cola sin proporcionar un tipo de destino deregistro. Por ejemplo:logcfg = EventPool:queue_size=número,hi_water=número,flush_interval=número

Especificación del número máximo de eventos en cola en lamemoria

Para controlar la cantidad de memoria que los eventos pueden utilizar en la colade propagación, puede establecer el tamaño máximo que desea que tenga la cola.

140 IBM Tivoli Access Manager Base: Guía del administrador

Si se alcanza el tamaño máximo cuando se genera un evento nuevo, el thread queintenta ponerse en cola se bloquea hasta que haya espacio disponible en la cola.Esto disminuye el rendimiento del thread que produce el evento a la velocidad delos threads de registro, si no puede mantenerse.

El valor predeterminado de queue_size es 0. Este valor indica que no se aplicaningún límite al tamaño de la cola de eventos. Recuerde que utilizar el valorpredeterminado puede hacer que el tamaño de la cola de eventos no procesadosaumente tanto que su gestión sea imposible cuando los eventos se producen a unavelocidad más rápida que la que utilizan los agentes de registro para borrarlos.

Especificación de la marca de límite superior de la cola deeventos

El proceso de la cola de eventos se planifica habitualmente en el intervalo devaciado configurado. Esto también se activa de manera asíncrona cuando eltamaño de la cola alcanza la marca de límite superior.

El valor predeterminado de hi_water es 1024. Si especifica un valor de queue_size,pero no especifica ninguno para hi_water, el valor predeterminado de hi_water esdos tercios del tamaño máximo de cola configurado. Si el tamaño máximo de lacola es 0, la marca de límite superior se establece en 100 de forma predeterminada.

Si la marca de límite superior de la cola de eventos se establece en 1, todos loseventos de la cola se envían a todos los agentes de registro suscritos lo antesposible. Tenga presente que establecer un valor bajo para hi_water puede producirun efecto adverso en el rendimiento general.

Especificación de la frecuencia para vaciar los búferes de losarchivos de registro

Utilice la opción flush_interval para especificar el límite de tiempo que un eventoha de esperar en la cola de propagación antes de ser enviado a los agentes deregistro. Si los eventos se han generado a una velocidad tan baja que no permitemanejarlos al alcanzar la marca de límite superior en un periodo de tiempo, seeliminan de la cola de propagación con esta frecuencia.flush_interval=<segundos>

El valor predeterminado de flush_interval es 10 segundos. No se permite queflush_interval sea 0. Si se especifica un valor 0, la cola se vaciará cada 600segundos.

Registro en consolaEl registro en la consola es la opción cuya configuración es más simple. Tan sólo hade asociar un destino de salida estándar y de error estándar a la categoría deeventos de la agrupación de eventos que se ha de capturar:logcfg = <categoría>:{stdout|stderr}

A continuación se muestran algunas configuraciones de ejemplo:v Para capturar toda la salida de auditoría en salida estándar, especifique lo

siguiente:logcfg = audit:stdout

v Para capturar sólo los eventos de auditoría de autorización en error estándar,especifique lo siguiente:

Capítulo 10. Utilización del registro de eventos 141

logcfg = audit.azn:stderr

El registro en la consola no conlleva la colocación en cola. Los eventos se escribenen la consola a medida que se reciben de la cola de propagación. Sin embargo, loseventos podrían estar en espera en la cola de propagación dependiendo de susvalores de cola.

Si utiliza salida de consola y ejecuta un servidor en primer plano a efectos dedepuración, tal vez tenga que establecer los valores de cola de propagaciónadecuadamente. Por ejemplo, establezca la opción hi_water en un valor bajo.

Registro en archivoPara registrar eventos en un archivo, especifique una configuración de archivo deregistro tal como se muestra:logcfg = category:file path=ruta_acceso_archivo, \flush_interval=segundos, \rollover_size=número, \log_id=idregistro, \queue_size=número, \hi_water=número, \buffer_size=número, \mode={text|binary}

Un archivo sólo se abre una vez. Si existen varias entradas de configuración paracapturar eventos de manera selectiva en diferentes puntos de la jerarquía deagrupación de eventos en el mismo archivo, el archivo se abre de acuerdo a lasopciones que se encuentran en la primera entrada de configuración que se procesa.

Una vez se ha abierto un archivo, las siguientes configuraciones de archivo puedenutilizar tan sólo la notación estándar:logcfg = <categoría>:file log_id=<idregistro>

para registrar eventos en el mismo archivo.

Puesto que la escritura en un archivo puede ser una operación lenta en relacióncon las tareas que generan eventos, éstos se envían a un agente de registro dearchivo a través de un segundo nivel de colocación en cola. Este segundo nivel decolocación en cola de eventos está configurado igual que la cola de propagacióncentral, pero tiene valores predeterminados distintos.

Especificación de la ubicación del archivo de registroUtilice la opción path para especificar la ubicación de un archivo de registro. Noexiste ningún valor predeterminado para la ruta de acceso al archivo porque elvalor de log_id tiene preferencia. A continuación se muestra un ejemplo de valorde ruta de acceso al archivo de seguimiento de auditoría de WebSEAL en UNIX:path=/var/pdweb/log/audit.log

Debe existir la parte del directorio de esta ruta de acceso. Si al archivo de registrono existe, se crea.

Especificación del ID del archivo de registroUn archivo de registro abierto está asociado a un identificador de nombreabreviado para simplificar el registro de eventos desde categorías diferentes almismo archivo.

142 IBM Tivoli Access Manager Base: Guía del administrador

Utilice la opción log_id para establecer el ID de archivo de registro de maneraexplícita; de lo contrario, se le proporciona un valor predeterminado. Si seespecifica la opción path, el valor predeterminado es la ruta de acceso configurada.Si no se especifica la ruta de acceso, el ID de registro utiliza de formapredeterminada el componente de dominio de la categoría de eventos que se estácapturando. Por ejemplo:logcfg = audit.azn:file

implicalog_id=audit.

Para capturar eventos en un archivo común, establezca el ID de archivo de registroen un valor adecuado en una configuración de archivo con todas las opciones.Posteriormente, utilice la variante de configuración abreviada para capturareventos de categorías adicionales, tal como se muestra:logcfg = audit.azn:file path=/opt/PolicyDirector/log/audit.log, \rollover_size=-1,flush=20,log_id=audit

logcfg = audit.authn:file log_id=audit

Debido a las reglas de valor predeterminado, esta configuración también esequivalente a la especificación siguiente:logcfg = audit.azn:file \path=/opt/PolicyDirector/log/audit.log,rollover_size=-1

logcfg = audit.authn:file

Si construye una configuración en la que el valor log_id no coincide con ningúnarchivo de registro abierto, no se captura ningún evento. Por ejemplo, la siguienteconfiguración no registra ningún evento porque la línea de configuración queinicializa el archivo de registro tiene un carácter de comentario:#logcfg = audit.azn:file path=/tmp/azn.log,log_id=aznlogcfg = audit.authn:file log_id=azn

Especificación del tamaño máximo del archivo de registroUtilice la opción rollover_size para especificar el tamaño máximo que puede tenerun archivo de registro. El valor predeterminado (en bytes) de esta opción es elsiguiente:rollover_size=2000000

Cuando el tamaño de un archivo de registro alcanza el valor especificado(conocido como umbral de creación), se realiza una copia de seguridad del archivoexistente en un archivo con el mismo nombre y con la indicación anexada de fechay hora. A continuación, se inicia un archivo de registro nuevo.

Los distintos valores posibles de rollover_size se interpretan de la siguiente forma:v Si el valor de rollover_size es menor de cero (< 0), se crea un archivo de registro

nuevo cada vez que se invoca el proceso y cada 24 horas desde esa instancia.v Si el valor de rollover_size es igual a cero (= 0), no se crea ningún nuevo

registro y el archivo de registro crece indefinidamente. Si ya existe un archivo deregistro, los datos nuevos se agregan en éste.

v Si el valor de rollover_size es mayor que (> 0), se crea un nuevo registro cuandoel archivo de registro alcanza el valor de umbral configurado. Si ya existe unarchivo de registro en el inicio, los datos nuevos se agregan en éste.

Capítulo 10. Utilización del registro de eventos 143

Especificación del tamaño máximo del búferPara reducir la fragmentación de memoria y mejorar el rendimiento de la escrituraen archivo, en lugar de colocar en cola muchos eventos pequeños de maneraindividual para el agente de registro de archivo, se pueden colocar en el búfer enbloques de un tamaño determinado antes de enviarlos a la cola para escribirlos. Laopción buffer_size especifica el mensaje de tamaño máximo que el programaintenta construir combinado eventos pequeños en un búfer de gran tamaño.

Los búferes sólo se componen de un número entero de eventos; éstos no se dividenen los búferes. Si un evento concreto excede el tamaño máximo configurado, seregistra en un búfer propio, mayor que el valor configurado.buffer_size=número_de_bytes

El tamaño de búfer predeterminado para operaciones de registro en archivo es 0bytes. Este valor impide la colocación en búfer y cada evento se manejaindividualmente.

Si se especifica un valor para buffer_size, los eventos se empaquetan en búferes deese tamaño antes de colocarlos en cola para el agente de registro de archivo.

Por ejemplo, si el valor de buffer_size se establece en 2 KB y se presupone que loseventos van a ocupar unos 256 bytes, unos 10 se empaquetan en cada búfer escritoen el archivo. Esto reduce el número de E/S de disco efectuadas durante el registroun 10% de las que se efectuarían en el caso de que no se utilizara el búfer.

Tenga en cuenta que un tamaño de cola predeterminado de 200 con un valor debuffer_size de 2 KB también utiliza unas 10 veces más memoria que la de unaconfiguración predeterminada en la que no se utiliza el búfer (presuponiendo untamaño de eventos de unos 200 bytes). Esto se debe a que el valor del tamañomáximo de la cola no se ha modificado, pero el tamaño de los eventos que se estáncolocando en cola ha aumentado diez veces.

Especificación del número máximo de eventos en cola en lamemoria

Se produce un tiempo de espera entre los eventos que se están colocando en lacola y el agente de registro de archivo que los elimina. La opción queue_sizeespecifica el tamaño máximo que puede tener la cola. Si se alcanza el tamañomáximo cuando un evento nuevo está listo para ser colocado en la cola, el threadsolicitante se bloquea hasta que haya espacio disponible en la cola. Esto disminuyeel rendimiento del thread de propagación de eventos a la velocidad del thread deregistro de archivo, si no puede mantenerse.

El valor predeterminado de queue_size es 0. Este valor indica que no se aplicaningún límite al tamaño de la cola de eventos no procesados. Por consiguiente, elthread de propagación de eventos no sufre ninguna restricción por parte de lavelocidad del thread de registro. Recuerde que utilizar el valor predeterminadopuede hacer que la cola de eventos no registrados alcance un tamaño que nopermita manejarla, si los eventos se generan a una velocidad superior a la quepueden registrarse en el archivo.

144 IBM Tivoli Access Manager Base: Guía del administrador

Especificación de la marca de límite superior de la cola deeventos

El proceso de la cola de eventos se planifica habitualmente en el intervalo devaciado configurado. Esto también se activa de manera asíncrona cuando eltamaño de la cola alcanza la marca de límite superior en la cola de eventos.

El valor predeterminado de hi_water es dos tercios el del tamaño máximo de colaconfigurado. Si el tamaño máximo de la cola es cero, la marca de límite superior seestablece en 100 de forma predeterminada.

Las velocidades de transacción y los valores de estas opciones determinan lacantidad de memoria máxima que se utiliza al habilitar el registro de eventos enarchivo.

Si la marca de límite superior de la cola de eventos se establece en 1, todos loseventos de la cola se envían al agente de registro lo antes posible. No esaconsejable utilizar este valor, aunque puede que desee utilizarlo si quiere loseventos vayan al disco lo más rápido posible a expensas del rendimiento general.

Especificación de la frecuencia para vaciar los búferes de losarchivos de registro

La opción flush_interval puede utilizarse de varias maneras.

La opción flush_interval de registro en archivo tiene el siguiente valorpredeterminado en segundos.flush_interval=20

No se permite que el valor de intervalo de vaciado sea 0. Si se especifica un valor0, dicho valor será 600.

Los archivos de registro se escriben en secuencias de datos con búfer. Para tener lacerteza de que los búferes de secuencia de datos se vacían al disco regularmente, lafrecuencia con que el servidor fuerza asíncronamente un vaciado de la secuenciade datos al disco puede configurarse con esta opción.

Si especifica un valor negativo, se utiliza el valor absoluto como la frecuencia devaciado asíncrono, pero también se fuerza un vaciado de secuencia síncronodespués de que se escriba cada registro.

Si los eventos se consolidan en búferes de gran tamaño especificando la opciónbuffer_size, el parámetro flush_interval también podría afectar al tamaño delbúfer escrito. Si hay un búfer que no está lleno en la memoria cuando se planificaun vaciado, también se coloca en la cola a efectos de escritura antes de que se llenecompletamente.

Finalmente, la cola de eventos se activa para procesarse con la velocidad deintervalo de vaciado. De esta manera, los eventos no tienen que esperar a serprocesados más tiempo que el establecido para el vaciado planificado cuando no sealcanza la marca de límite superior de cola entre vaciados planificados.

Especificación de la modalidad de archivoUtilice la opción mode para abrir un archivo en modalidad de texto o enmodalidad binaria. Por ejemplo:

Capítulo 10. Utilización del registro de eventos 145

mode={text|binary}

La modalidad de texto se desecha en plataformas UNIX y no surte efecto alguno.En plataformas WIN32, abrir un archivo en modalidad de texto habilita laconversión del carácter de fin de línea en el archivo de registro. La modalidadbinaria en plataformas Windows escribe el archivo de registro en un formatocompatible con UNIX.

Registro en canalizaciónUtilice la opción pipe para escribir salida en la entrada estándar de otro programa.Por ejemplo:logcfg=<categoría>:pipe path=<ruta_acceso_programa>, \queue_size=<número>, \hi_water=<número>, \flush_interval=<número>

El programa especificado debe existir y ser ejecutable. El administrador esresponsable de garantizar la seguridad del programa que se va a ejecutar.

Cada aparición de un agente de canalización en el archivo de configuración invocauna nueva copia del programa de canalización. A diferencia del registro en archivo,a los eventos de canalización no están multiplexados desde diferentes puntos decaptura de categoría a una sola copia del programa.

Especificación del programa que se ha de ejecutarUtilice la opción path para especificar la ubicación del programa, que recibe lasalida de registro en entrada estándar. Por ejemplo:path=/opt/risk_analyser/bin/my_log_watcher

Tenga en cuenta que no hay ningún valor predeterminado para la ruta de acceso.

Especificación del perfil de cola de eventosLa gestión del registro en canalización de la cola de eventos debe configurarse dela misma manera que el registro en archivo. La función de las opcionesqueue_size, hi_water y flush_interval es igual a las de las opciones descritas parael registro en archivo.

Registro remotoUtilice la opción remote para enviar eventos a un servidor remoto para que losregistre. Por ejemplo:logcfg = categoría:remote \buffer_size=tamaño, \compress={yes|no}, \error_retry=tiempo de espera, \path=nombre, \flush_interval=número, \rebind_retry=tiempo de espera, \server=nombre de host, \port=número, \dn=identidad, \queue_size=número,hi_water=número

Las peticiones para registrar un evento remotamente sólo se aceptan en casosextremos. Si el servidor remoto no está disponible, los eventos capturados se

146 IBM Tivoli Access Manager Base: Guía del administrador

almacenan en la caché localmente y se envían más adelante sólo cuando elservidor remoto vuelve a estar disponible.

Sólo se establece una conexión de registro remoto en un servidor remoto. Si seefectúa una o varias entradas de configuración para capturar eventos de maneraselectiva en puntos diferentes de la jerarquía de agrupación de eventos en elmismo servidor remoto, se establece la conexión remota según las opciones de laprimera entrada de configuración remota que se ha procesado. Se puedenconfigurar varias conexiones remotas para realizar operaciones de registro endiferentes servidores remotos.

Los eventos recibidos en los servidores remotos se colocan en la agrupación deeventos de estos servidores en una ubicación distinta de la ubicación en la quefueron capturados en el sistema cliente. Todos los eventos que entran en un host através del servicio de registro remoto se colocan en una categoría construida de lamanera siguiente:remote.<cliente-categoría-dominio>.<nombrehost>.<programa>

Por ejemplo, todos los eventos de auditoría registrados remotamente del programapdmgrd en el host amazon aparecen en el servidor de registro remoto bajo laagrupación remote.audit.amazon.pdmgrd. Esto permite al servidor remotoregistrar eventos de manera selectiva en diferentes destinos utilizandoconfiguraciones estándar. Por ejemplo, todos los eventos de auditoría del hostamazon pueden registrarse centralizadamente en el host timelord mediante unaconfiguración como esta:

En el host amazon para enviar eventos remotamente:logcfg = audit:remote buffer=2000,compress=y,error=2, \path=/opt/PolicyDirector/log/remote.cache,rebind=600,server=timelord,port=7136

En el host timelord para registrar eventos en archivo:logcfg = remote.audit:file path=consolidated_audit.log

logcfg = remote.audit.amazon.pdmgrd:file path=amazon_pdmgrd_audit.log

Especificación del tamaño máximo del búferPara reducir el tráfico en la red, los eventos se almacenan en bloques del tamañoespecificado antes de ser enviados al servidor remoto. La opción buffer_sizeespecifica el mensaje de tamaño máximo que el programa local intenta construircombinando eventos pequeños en un búfer de gran tamaño. Los búferes sólo secomponen de un número entero de eventos; éstos no se dividen en los búferes. Siun evento concreto excede el tamaño máximo configurado, se registra en un búferpropio, mayor que el valor configurado.buffer_size=número_de_bytes

El tamaño de búfer predeterminado es 1024 bytes.

Especificación de la frecuencia para vaciar el búfer deconsolidación

Si los eventos se consolidan en búferes muy grandes y no hay mucha actividad deregistro, pueden permanecer en la memoria durante un largo periodo de tiempoantes de ser reenviados al servidor remoto o escritos en el archivo de caché. Laopción flush_interval limita el tiempo que un proceso espera a llenar un búfer deconsolidación. Por ejemplo:

Capítulo 10. Utilización del registro de eventos 147

flush_interval=<segundos>

El intervalo de vaciado predeterminado es 20 segundos. No se permite que el valorde intervalo de vaciado sea 0. Si se especifica un valor 0, la cola se vaciará cada600 segundos.

Especificación de tamaños de colaLos valores de queue_size y hi_water de una conexión de registro remoto soniguales a los especificados para el registro en archivo. Los valores predeterminadosson los siguientes:queue_size=0hi_water=100

Especificación de compresión de mensajesLos eventos de Access Manager son, en gran parte, mensajes de texto. Para reducirel tráfico en la red utilice la opción de compresión para comprimir búferes antes dela transmisión y expándalos después de la recepción. Por ejemplo:compress={yes|no}

El valor de compresión predeterminado es no.

Especificación del tiempo de espera de reintento por errorSi se produce un error al efectuar una operación de envío a un servicio remoto, sereintenta después de un tiempo de espera en segundos. Si el reintento tampocoresulta satisfactorio, se marca el enlace y tanto este evento como los futuros seguardan en el archivo de caché de eventos local hasta que se pueda volver aenlazar con el servicio remoto.error=segundos

El tiempo de espera de reintento por error predeterminado es 2 segundos.

Especificación de la ubicación del archivo de cachéLa opción path especifica la ubicación de un archivo de caché en el host local. Deforma predeterminada, el nombre del archivo de caché es ./servidor.cache, dondeservidor es el nombre del servidor remoto en el que se está efectuando el registro.

Si el proceso de ejecución no puede establecer comunicación con el servidorremoto, o el enlace falla durante la operación, el registro de eventos conmuta aalmacenamiento de eventos en el archivo especificado hasta que el servidor vuelvea estar disponible. Cuando el servidor está disponible, se vacía de eventos la cachéde disco y se envían al servidor remoto.

Por ejemplo, presuponga que el valor de ruta de acceso para pdmgrd en UNIX esel siguiente:path=/var/PolicyDirector/log/pdmgrd_remote.cache

Debe existir la parte del directorio de esta ruta de acceso. Si al archivo de registrono existe, se crea. El tamaño de este archivo no está enlazado y no tieneposibilidades de creación de un nuevo archivo. Si no se puede acceder a unservidor remoto durante un tiempo determinado, podría quedarse sin espacio dedisco.

148 IBM Tivoli Access Manager Base: Guía del administrador

Especificación del tiempo de espera de intentos de reenlaceSi el servidor remoto no está disponible, el agente de registro intenta reenlazar conel servidor cada 300 segundos (valor predeterminado).rebind_interval=60

Especificación del servidor remotoEl programa pdacld ofrece servicios de registro remoto. El registro remotoincorpora los certificados establecidos para el servicio de autorizaciones cuando seinicializa mediante una llamada a azn_initialize(). Esta opción indica qué procesospdacld de hosts se enlazarán para el registro de eventos.server=<nombrehost>

Especificación del puerto del servidor remotoUtilice la opción port para especificar el puerto en el que el pdacld remotoescuchará las peticiones de registro remoto.port=<número>

El valor predeterminado es 7136.

Especificación del nombre distinguido del servidor remotoPara establecer la autenticación mutua del servidor remoto, debe configurarse unnombre distinguido (DN) que pueda compararse con el nombre devuelto en elcertificado de servidores remotos. El valor predeterminado para el DN es unacadena de nulos.

El DN debe especificarse como una cadena entre comillas dobles. Utilizar el valorpredeterminado o especificar de manera explícita una cadena vacía permite alcliente de registro establecer de manera insistente una conexión con el servidorremoto. Especificar un valor para el DN limita la conexión satisfactoria con unservidor específico:dn="cn=ivacld/timelord.testnet.tivoli.com,o=policy director,c=us"

Soporte de configuración heredada y otros valores predeterminadosLas entradas de configuración de Tivoli SecureWay Policy Director Versión 3.7están reconocidas para la configuración del registro de seguimiento de auditoría.

Un archivo de registro de auditoría establecido mediante las entradas deconfiguración logaudit y auditlog de la versión 3.7, puede registrarse desde unaconfiguración de archivo utilizando la sintaxis de registro de archivo abreviada,especificando audit como el ID de registro. Por ejemplo:logaudit = yesauditlog = /var/PolicyDircetor/pdmgrd/log/audit.loglogcfg = audit.azn:file log_id=audit

La ubicación predeterminada para registrar eventos depende del componentedominio del nombre de la categoría de eventos. Los eventos para el dominio auditse registran de forma predeterminada en el seguimiento de auditoría. Teniendo encuenta el ejemplo anterior, también pueden escribirse de la manera siguiente:logaudit = yesauditlog = /var/PolicyDircetor/pdmgrd/log/audit.loglogcfg = audit.azn

Capítulo 10. Utilización del registro de eventos 149

La ubicación del registro predeterminado para otros componentes es stderr en laconsola.

Compatibilidad con la configuración de la API de autorizaciónTivoli SecureWay Policy Director Versión 3.7 permitía efectuar la captura enarchivo de eventos de auditoría de actividades de autorización agregando entradasen la stanza [aznapi-configuration] del archivo de configuración o cargando lalista de atributos de inicialización azn correspondientes.

La lista siguiente muestra un resumen de las entradas y los atributos del archivode configuración de la API de autorización y su correspondiente soporte en esterelease de Access Manager:

Entrada de archivo deconfiguración

Entrada de lista de atributos Soporte de V3.9

logclientid azn_init_logging_client ignorado

logaudit n/a reconocido

auditlog azn_init_audit_file reconocido

auditcfg azn_init_auditcfg reconocido

logdebug n/a ignorado

debuglog azn_init_debug_file ignorado

debugcfg azn_init_debugcfg ignorado

logsize azn_init_log_size reconocido

logflush azn_init_log_flush_interval reconocido

Registros de peticiones HTTP de WebSEALLas configuraciones de logcfg que corresponden a los agentes de registrohabilitados utilizando las configuraciones de registro de WebSEALpredeterminadas que se describen en la plantilla del archivo de configuraciónwebseald.conf son las siguientes:

Registro de peticiones de formato de registro común:logcfg = http.clf:file path=archivo_peticiones,flush=tiempo_vaciado, \rollover=tamaño_máximo,log=clf,buffer_size=8192,queue_size=48

Registro de referente:logcfg = http.ref:file path=archivo_referentes,flush=tiempo_vaciado, \rollover=tamaño_máximo,log=ref,buffer_size=8192,queue_size=48

Registro de agente de usuario:logcfg = http.agent:file path=archivo_agentes,flush=tiempo_vaciado, \rollover=tamaño_máximo,log=agent,buffer_size=8192,queue_size=48

También se puede registrar el registro de peticiones en formato NCSA combinadocapturando eventos enviados a la agrupación http.cof. El formato NCSAcombinado agrega las cadenas referer y agent entre comillas al registro de formatode registro común estándar.

150 IBM Tivoli Access Manager Base: Guía del administrador

Búsqueda de las categorías de eventos existentesEl nombre de cada categoría de eventos se escribe en un evento trace cuando secrea una instancia de él. Para ver los registros de rastreo, habilite trace durante elinicio agregando la línea siguiente al archivo de direccionamiento:*:*.9:TEXTFILE:/var/PolicyDirector/log/%ld.trace.log 3.9

Supervisión del rendimiento de la cola de registrosLos perfiles de cola configurados para la cola de propagación principal y para cadaagente de registro en archivo, remoto y canalización se utilizan para la operaciónde supervisión mediante la interfaz statistics.

Cada cola se implementa creando una instancia de un objeto EventQueue que seregistra a sí mismo con el subsistema de estadísticas utilizando un nombre decategoría construido a partir del tipo de agente de registro y de la cadena pd.log.

Las estadísticas de las colas de eventos pueden consultarse utilizando comandospdadmin server task. Para establecer qué colas se implementan en un servidor,emita el comando server task nombre_servidor stats list. Se devuelve un informesimilar al siguiente:pdadmin> server task ivacld-barra.surf.ap.tivoli.com stats listpd.ras.stats.monitorpd.log.EventPool.queue // Cola de propagación de eventos principalpd.log.file.audit // Cola de registro de auditoríapdadmin

Para examinar las estadísticas para una cola, entre el comando stats get tal como semuestra:pdadmin> server task ivacld-barra.surf.ap.tivoli.com \

stats get pd.log.EventPool.queue

Se muestra un informe similar al siguiente:dispatcher wakes on timeout(20) : 3617dispatcher wakes by notify : 0

notifies above highwater (100) : 0notifies below highwater : 0spurious notifies : 0

total events processed : 24average number of events handled per activation : 1greatest number of events handled per activation : 7blocks in queue requests : 0pdadmin>

La frecuencia de vaciado de colas se lista entre paréntesis después de la palabratimeout. El valor de la marca de límite superior de la cola se lista entre paréntesisdespués de la palabra highwater.

Los valores elegidos para las distintas opciones de configuración de la cola debenintentar compensar la cantidad máxima de memoria utilizada cada vez que seactiva la cola con la velocidad con que un agente de registro concreto puedeutilizar eventos.

Para obtener un resultado óptimo, debería establecer la marca de límite superior dela cola de manera que el número de eventos procesados durante una activaciónocupen una parte del tiempo de proceso. Así se evitan operaciones de conmutaciónde contexto de thread innecesarias. Sin embargo, tenga en cuenta que es

Capítulo 10. Utilización del registro de eventos 151

improbable que establecer estas opciones en valores altos resulte ventajoso ya queel proceso de registro de eventos debe efectuarse en el algún punto y no puedepostergarse indefinidamente. Utilizar una gran cantidad de memoria tambiénpresenta inconvenientes.

152 IBM Tivoli Access Manager Base: Guía del administrador

Apéndice A. Comandos pdadmin

El programa de utilidad pdadmin es un programa de utilidad de línea decomandos que le permite efectuar la mayoría de tareas de administración deusuarios y grupos de Access Manager. Web Portal Manager proporciona la mayoríade estos comandos mediante su interfaz gráfica de usuario. Este apéndice contieneuna lista ordenada alfabéticamente de los comandos disponibles desde el indicadorde comandos de pdadmin.

Conceptos básicos del programa de utilidad pdadminEl programa de utilidad pdadmin es un programa de utilidad de línea decomandos que le permite efectuar la mayoría de tareas de administración deusuarios y grupos de Access Manager. Web Portal Manager duplica la mayoría decomandos pdadmin. Sin embargo, pdadmin proporciona diferentes funciones degestión avanzada que no están disponibles mediante Web Portal Manager.

Se pueden automatizar algunas funciones de gestión escribiendo scripts queutilizan pdadmin. La comunicación entre el programa de utilidad pdadmin yPolicy Server (pdmgrd) es segura a través de SSL. El programa de utilidad seinstala al instalar el paquete Access Manager Runtime.

Inicio del programa de utilidad pdadmin (comando login)v Modalidad interactivav Modalidad de línea de comando únicov Ejecución de varios comandos

Modalidad interactivaPara iniciar pdadmin en modalidad interactiva, debe entrar el comando pdadminseguido de un comando login con las opciones y argumentos de nombre deusuario (administrador) y contraseña. El usuario-admin debe ser un usuarioregistrado en un registro LDAP.

UNIX:# pdadmin# login –a usuario-admin –p <contraseña>pdadmin>

Windows:MSDOS> pdadminMSDOS> login –a usuario-admin –p contraseñapdadmin>

En el indicador de pdadmin, entre los comandos, las opciones y los argumentosadecuados. Vaya a las tablas de consulta de comandos de este apéndice.

Modalidad de línea de comando únicoDesde el indicador de comandos del sistema operativo se puede ejecutar un solocomando pdadmin:

UNIX:# pdadmin [–a usuario-admin] [–p contraseña] [comando]

153

Windows:MSDOS> pdadmin [–a usuario-admin] [–p contraseña] [comando]

v Si especifica el usuario-admin (–a) y una contraseña(–p), inicia una sesión comoese usuario.

v Si no especifica el usuario-admin (–a), inicia una sesión como un usuarioautenticado.

v Si especifica el usuario-admin (–a),pero no una contraseña (–p), se le solicitaráuna.

El argumento de comando opcional le permite ejecutar comandos una sola vez. Porejemplo, si escribe el comando siguiente se crea el usuario “test”:pdadmin –a sec_master –p pwd user create testcn=test,ou=austin,o=ibm,c=us test test test1234

Ejecución de varios comandosPuede crear un archivo especial que contenga varios comandos pdadmin quejuntos efectúen una o varias tareas completas. El programa de utilidad pdadminacepta un argumento de nombre de archivo que identifica la ubicación de unarchivo.

UNIX:# pdadmin [–a usuario-admin] [–p contraseña] ruta-acceso-archivo

Windows:MSDOS> pdadmin [–a usuario-admin] [–p contraseña] ruta-acceso-archivo

Información de ayudaPara obtener una lista de comandos disponibles por categoría, entre:pdadmin> help categoría

Un comando puede tener las categorías siguientes: acl, action, object, server, rsrc,rsrccred, rsrcgroup, admin, login, user, group, policy, pop, errtext.

Para obtener información sobre la sintaxis específica de un comando, entre:pdadmin> help comando

Salida del programa de utilidad pdadminPara salir de pdadmin y volver al indicador de comandos, entre el comando exit oquit. Por ejemplo:pdadmin> exit

Caracteres especiales no permitidos en comandos de GSOPara crear un nombre de usuario de GSO, un nombre de recurso de GSO o unnombre de grupo de recursos de GSO, no puede utilizar los caracteres siguientes:!”#&()*+,;:<>=@\|

Aunque se pueden utilizar la mayoría de estos caracteres en otros datos de AccessManager relacionados con LDAP (como el CN, DN y SN de un usuario), tienen unsignificado especial en filtros y sintaxis de DN de LDAP. Antes de utilizarcualquiera de estos caracteres en nombres de usuario y de grupo de AccessManager, consulte la documentación del servidor LDAP para determinar cómoafectan los caracteres especiales en LDAP.

154 IBM Tivoli Access Manager Base: Guía del administrador

Sintaxis de comandosLos comandos en este apéndice utilizan los siguientes caracteres especiales paradefinir sintaxis de comandos:

[ ] Identifica elementos opcionales. Los que no están entre corchetes sonnecesarios.

... Indica que puede especificar múltiples valores para el elemento anterior. Amenos que la información del comando indique lo contrario, separe estosvalores con un espacio.

Si la elipsis de un elemento figura a continuación de un corchete final,utilice la sintaxis que hay entre los corchetes para especificar múltiplesvalores. Por ejemplo, para especificar dos administradores para la opción[–a admin]..., utilice –a admin1 –a admin2.

Si la elipsis de un elemento está dentro de los corchetes, utilice la sintaxisdel último elemento para especificar múltiples valores. Por ejemplo, paraespecificar dos hosts para la opción [–h host...], use –h host1 host2.

| Indica información que se excluye mutuamente. Puede utilizar el elementoque está en la izquierda o en la derecha de la barra vertical.

{ } Delimita un conjunto de elementos que se excluyen mutuamente cuandouno de ellos es necesario. Si los elementos son opcionales, aparecen entrecorchetes ([ ]).

Además de los caracteres especiales, se utilizan los convenios tipográficos, que sedescriben en el apartado “Convenios tipográficos” en la página xviii.

Apéndice A. Comandos pdadmin 155

acl attach

PropósitoAsocia la lista de control de accesos (ACL) especificada al objeto protegidoespecificado.

Sintaxisacl attach nombre_objeto nombre_acl

Opcionesnombre_objeto Indica el objeto al que aplicar la política de ACL especificada.

nombre_acl Indica la política de ACL que se aplicará al objeto especificado.

DescripciónAsocia la lista de control de accesos especificada al objeto protegido especificado.Si el objeto protegido especificado ya tiene asociada una ACL, esta funciónsustituye esta ACL por la nueva. Sólo se puede asociar una ACL como máximo aun objeto protegido determinado. Esa misma ACL se puede asociar a múltiplesobjetos protegidos. Antes de utilizar esta función, debe entender cómo funcionanlas ACL.

156 IBM Tivoli Access Manager Base: Guía del administrador

acl create

PropósitoCrea una lista de control de accesos (ACL) nueva.

Sintaxisacl create nombre_acl

Opcionesnombre_acl Especifica el nombre de la política de ACL que se está creando.

Tenga en cuenta que este comando no crea las entradas de ACLespecíficas.

DescripciónCrea una lista de control de accesos nueva. Esta función crea una política de ACLnueva en la base de datos de ACL. No crea las entradas de ACL específicas.

Apéndice A. Comandos pdadmin 157

acl delete

PropósitoSuprime la lista de control de accesos (ACL) especificada.

Sintaxisacl delete nombre_acl

Opcionesnombre_acl Especifica el nombre de la política de ACL que se está suprimiendo

de la base de datos de ACL.

DescripciónSuprime la lista de control de accesos especificada.

158 IBM Tivoli Access Manager Base: Guía del administrador

acl detach

PropósitoDesasocia la lista de control de accesos (ACL) especificada del objeto protegidoespecificado.

Sintaxisacl detach nombre_objeto

Opcionesnombre_objeto

Especifica el objeto del que la política de ACL actual se estáeliminando. Tenga en cuenta que este comando no suprime lapolítica de ACL de la base de datos de ACL.

DescripciónDesasocia la lista de control de accesos del objeto protegido especificado. Puestoque sólo se puede asociar una lista de control de accesos a un objeto a la vez, lalista de control de accesos actual se desasocia. Antes de utilizar esta función, debeentender cómo funcionan las ACL.

Apéndice A. Comandos pdadmin 159

acl find

PropósitoDevuelve una lista de objetos protegidos que tienen asociada la lista de control deaccesos (ACL) especificada.

Sintaxisacl find nombre_acl

Opcionesnombre_acl Especifica la política de ACL en la que se ha de efectuar la

búsqueda.

DescripciónDevuelve una lista de objetos protegidos que tienen asociada la lista de control deaccesos especificada.

160 IBM Tivoli Access Manager Base: Guía del administrador

acl list

PropósitoDevuelve los nombres de todas las listas de control de accesos definidas.

Sintaxisacl list

OpcionesNinguna.

DescripciónDevuelve los nombres de todas las listas de control de accesos definidas.

Apéndice A. Comandos pdadmin 161

acl list attribute

PropósitoProporciona una lista de las claves de atributo ampliado asociadas a la lista decontrol de accesos (ACL) especificada.

Sintaxisacl list nombre_acl atributo

Opcionesnombre_acl Especifica la política de ACL para la que se ha de proporcionar una

lista de atributos.

DescripciónProporciona una lista de las claves de atributo ampliado asociadas a la lista decontrol de accesos especificada.

162 IBM Tivoli Access Manager Base: Guía del administrador

acl modify

PropósitoModifica políticas de lista de control de accesos (ACL).

Sintaxisacl modify nombre_acl delete attribute nombre_atributo

acl modify nombre_acl delete attribute nombre_atributo valor_atributo

acl modify nombre_acl description descripción

acl modify nombre_acl remove any-other

acl modify nombre_acl remove group nombre_grupo

acl modify nombre_acl remove unauthenticated

acl modify nombre_acl remove user nombre_usuario

acl modify nombre_acl set any-other

acl modify nombre_acl set any-other permisos

acl modify nombre_acl set attribute nombre_atributo valor_atributo

acl modify nombre_acl set description descripción

acl modify nombre_acl set group nombre_grupo

acl modify nombre_acl set group nombre_grupo permisos

acl modify nombre_acl set unauthenticated

acl modify nombre_acl set unauthenticated permisos

acl modify nombre_acl set user nombre_usuario

acl modify nombre_acl set user nombre_usuario permisos

Opcionesnombre_acl Especifica la política de ACL que se ha de modificar.

delete attribute nombre_atributoSuprime la clave de atributo ampliado de la lista de control deaccesos especificada.

delete attribute nombre_atributo valor_atributoSuprime el valor indicado de la clave de atributo ampliadoespecificada en la lista de control de accesos indicada.

description descripciónEstablece o modifica la descripción de la lista de control de accesosespecificada.

Apéndice A. Comandos pdadmin 163

remove any-otherElimina la entrada de la lista de control de accesos correspondienteal usuario cualquier otro de la lista de control de accesosespecificada.

remove group nombre_grupoElimina la entrada de la lista de control de accesos correspondienteal grupo especificado de la lista de control de accesos especificada.

remove unauthenticatedElimina la entrada de la lista de control de accesos correspondienteal usuario no autenticado de la lista de control de accesosespecificada.

remove user nombre_usuarioElimina la entrada de la lista de control de accesos correspondienteal usuario especificado de la lista de control de accesosespecificada.

set any-other Establece o modifica la entrada de la lista de control de accesoscorrespondiente al usuario cualquier otro en la lista de control deaccesos especificada.

set any-other permisosEstablece o modifica la entrada de la lista de control de accesoscorrespondiente al usuario cualquier otro en la lista de control deaccesos especificada.

set attribute nombre_atributo valor_atributoEstablece el valor de atributo ampliado para la clave de atributoampliado especificada en la lista de control de accesos indicada. Siel atributo ya existe, su valor se agrega como un valor adicionalcuando no existe el mismo valor para este atributo. Si existe elmismo valor para este atributo, no se vuelve a agregar (no sepermiten valores duplicados) y no se devuelve ningún error.

set description descripciónEstablece o modifica la descripción de la lista de control de accesosespecificada.

set group nombre_grupoEstablece o modifica la entrada de la lista de control de accesos(ACL) correspondiente al grupo especificado de la lista de controlde accesos especificada. Para que pueda llamar a esta función a finde agregar una entrada del grupo a una ACL, el registro deusuarios debe contener una entrada para el grupo especificado.

set group permisos nombre_grupoEstablece o modifica la entrada de la lista de control de accesos(ACL) correspondiente al grupo especificado de la lista de controlde accesos especificada. Para que pueda llamar a esta función a finde agregar una entrada del grupo especificado a una ACL, elregistro de usuarios debe contener una entrada para dicho grupo.

set unauthenticatedEstablece o modifica la entrada de la lista de control de accesoscorrespondiente al usuario no autenticado en la lista de control deaccesos especificada.

164 IBM Tivoli Access Manager Base: Guía del administrador

set unauthenticated permisosEstablece o modifica la entrada de la lista de control de accesoscorrespondiente al usuario no autenticado en la lista de control deaccesos especificada.

set user nombre_usuarioLlame a esta función para especificar los permisos que al usuariose le permite efectuar. Para que pueda utilizar esta función a fin deagregar una entrada del usuario especificado a una ACL, el registrode usuarios debe contener una entrada para dicho usuario.

set user nombre_usuario permisosLlame a esta función para especificar los permisos que al usuariose le permite efectuar. Para que pueda utilizar esta función a fin deagregar una entrada del usuario especificado a una ACL, el registrode usuarios debe contener una entrada para dicho usuario.

Ejemplos1. En el ejemplo siguiente se establece la entrada de ACL ″cualquier otro″ en la

definición de política de ACL indicada y se definen permisos.pdadmin> acl modify pubs set any-other r

2. En el ejemplo siguiente se establece una entrada de ACL de grupo en ladefinición de política de ACL indicada y se definen permisos.pdadmin> acl modify pubs set group sales Tr

3. En el ejemplo siguiente se establece la entrada de ACL ″no autenticado″ en ladefinición de política de ACL indicada y se definen permisos.pdadmin> acl modify docs set unauthenticated r

4. En el ejemplo siguiente se establece una entrada de ACL de usuario en ladefinición de política de ACL indicada y se definen permisos.pdadmin> acl modify pubs set user peter Tr

Apéndice A. Comandos pdadmin 165

acl show

PropósitoDevuelve la lista de control de accesos (ACL) especificada.

Sintaxisacl show nombre_acl

Opcionesnombre_acl Especifica la política de ACL que se ha de mostrar.

DescripciónDevuelve la lista de control de accesos especificada.

166 IBM Tivoli Access Manager Base: Guía del administrador

acl show attribute

PropósitoObtiene los valores de atributo ampliado para la clave de atributo ampliadoespecificada en la lista de control de accesos indicada.

Sintaxisacl show nombre_acl attribute nombre_atributo

Opcionesnombre_acl Especifica la lista de control de accesos para la que se van a

mostrar valores de atributo ampliado.

nombre_atributoEspecifica el nombre del atributo ampliado cuyos valores van amostrarse.

DescripciónObtiene los valores de atributo ampliado para la clave de atributo ampliadoespecificada en la lista de control de accesos indicada.

Apéndice A. Comandos pdadmin 167

action create

PropósitoDefine un nuevo código de acción (permiso) en un grupo de acciones.

Sintaxisaction create nombre_acción etiqueta_acción tipo_acción

action create nombre_acción etiqueta_acción tipo_acción nombre_grupo_acciones

Opcionesnombre_grupo_acciones

Define un nuevo código de acción (permiso) en el grupo deacciones especificado. Llame a esta función para agregar un códigode acción a un grupo de acciones ampliado definido por elusuario.

etiqueta_acción Especifica la etiqueta o la descripción para la acción.

nombre_acción Especifica el nuevo permiso de un solo carácter que se estácreando.

tipo_acción Especifica la categoría organizativa para esta acción en un grupode acciones determinado.

DescripciónDefine un nuevo código de acción (permiso) en un grupo de acciones.

Los códigos de acción se componen de un carácter alfabético (a–z o A–Z) y sonsensibles a las mayúsculas y minúsculas. Cada código de acción sólo se puedeutilizar una vez en un grupo de acciones. Asegúrese de que no intenta redefinir loscódigos de acción predeterminados cuando agrega códigos nuevos al grupoprimario.

Ejemplos1. En el ejemplo siguiente se crea un nuevo carácter de permiso para la

etiqueta_acción y el tipo_acción especificados.pdadmin> action create k time Ext-Authzn

168 IBM Tivoli Access Manager Base: Guía del administrador

action delete

PropósitoSuprime un código de acción (permiso) de un grupo de acciones. Se puede definirun grupo de acciones específico del que suprimir una acción utilizando la opciónnombre_grupo_acciones.

Sintaxisaction delete nombre_acción

action delete nombre_acción nombre_grupo_acciones

Opcionesnombre_acción Especifica el nombre de la acción que se ha de suprimir.

nombre_grupo_accionesEspecifica el nombre del grupo de acciones del que tiene quesuprimir la acción especificada.

Ejemplos1. El comando siguiente suprime la acción ″k″ del grupo de acciones primario.

pdadmin> action delete k

2. El comando siguiente suprime la acción ″z″ del grupo de acciones ″agz″pdadmin> action delete z agz

Apéndice A. Comandos pdadmin 169

action group

PropósitoLos comandos siguientes se utilizan para crear, suprimir o mostrar grupos deacciones.

Sintaxisaction group create nombre_grupo_acciones

action group delete nombre_grupo_acciones

action group list

Opcionesnombre_grupo_acciones

Especifica el nombre del grupo de acciones que se tiene que crear osuprimir.

DescripciónCon el comando create crea un grupo de acciones nuevo con el nombreespecificado. Soporta 32 grupos de acciones como máximo.

Con el comando delete, suprime el grupo de acciones especificado y todas lasacciones que pertenecen al grupo especificado.

Con el comando list, lista todos los nombres de los grupos de acciones definidos.

170 IBM Tivoli Access Manager Base: Guía del administrador

action list

PropósitoProporciona una lista de todos los códigos de acción (permiso) definidos de ungrupo de acciones. Se puede definir un grupo de acciones específico del quemostrar una acción utilizando la opción nombre_grupo_acciones.

Sintaxisaction list

action list nombre_grupo_acciones

Opcionesnombre_grupo_acciones

Especifica el nombre del grupo de acciones del que se mostrarántodas las acciones. Si se omite este parámetro, se mostraránacciones definidas en el grupo de acciones primario.

Ejemplos1. En el ejemplo siguiente se muestran todas las acciones que existen en el grupo

de acciones primario:pdadmin> action list

r read WebSEAL...

2. En el ejemplo siguiente se muestra el resultado del comando action listnombre_grupo_acciones después de la creación de un grupo de acciones:pdadmin> action group create agzpdadmin> action create z actionz type1 agzpdadmin> action list agz

z actionz type1

Apéndice A. Comandos pdadmin 171

admin

PropósitoMuestra la información de configuración del servidor actual.

Sintaxisadmin show configuration

OpcionesNinguna.

DescripciónMuestra información de configuración del servidor actual, como:v El tipo de registro de usuarios (LDAP, Active Directory, Active Directory

Multidomain o Domino)v Si se han habilitado o no las posibilidades de Global Signon (GSO)

Ejemplos1. En el ejemplo siguiente se muestra la información de configuración del servidor

actual:pdadmin> admin show configuration

La salida es similar a:LDAP: TRUESECAUTHORITY: DefaultGSO: TRUE

172 IBM Tivoli Access Manager Base: Guía del administrador

errtext

PropósitoMuestra el mensaje de error correspondiente a un número de errorpredeterminado.

Sintaxiserrtext número_error

Opcionesnúmero_error Especifica el número del error para el que se ha de generar el texto

de error.

DescripciónMuestra el mensaje de error correspondiente a un número de errorpredeterminado. El número de error puede estar en formato decimal ohexadecimal.

Ejemplos1. A continuación, se muestra un ejemplo del comando errtext:

pdadmin> errtext 0x132120c8

Inicio de sesión incorrecto. Ha especificado un nombre de usuario,una contraseña o un certificado de cliente incorrecto.

Apéndice A. Comandos pdadmin 173

exit

PropósitoSale de la modalidad de línea de comandos de pdadmin.

Sintaxisexit

OpcionesNinguna.

174 IBM Tivoli Access Manager Base: Guía del administrador

group create

PropósitoCrea un grupo.

Sintaxisgroup create nombregrupo dn cn

group create nombregrupo dn cn contenedor_grupos

Opcionesnombregrupo Especifica el nombre del grupo que se está creando. Este nombre

debe ser exclusivo.

dn Especifica el identificador de registro asignado al grupo que se estácreando.

cn Especifica el nombre común asignado al grupo que se está creando.

contenedor_gruposEspecifica el objeto del contenedor de grupos asignado al grupoque se está creando. Si no utiliza este argumento, el grupo secoloca de forma predeterminada en el espacio de objetos debajo de/Management/Groups.

DescripciónSi se utiliza sin la opción contenedor_grupos, crea un grupo nuevo creando un gruponuevo en el registro de usuarios con el nombre, el identificador de registro y elnombre común especificados.

Ejemplos1. En el ejemplo siguiente se crea un grupo en el registro de usuarios.

pdadmin> group create credit “cn=credit,ou=Austin,o=Wesley Inc,c=US” Credit

Apéndice A. Comandos pdadmin 175

group delete

PropósitoSuprime el grupo especificado.

Sintaxisgroup delete [-registry] nombregrupo

Opciones[-registry] Suprime el contenido del registro de usuarios.

nombregrupo Especifica el nombre del grupo que se ha de suprimir.

DescripciónSuprime el grupo especificado. Suprime toda la información sobre el grupo, yopcionalmente, el contenido del registro de usuarios.

Ejemplos1. En el ejemplo siguiente se suprime el grupo especificado existente.

pdadmin> group delete engineering

176 IBM Tivoli Access Manager Base: Guía del administrador

group import

PropósitoCrea un grupo importando un grupo que ya existe en el registro de usuarios.

Sintaxisgroup import nombregrupo dn

group import nombregrupo dn contenedor_grupos

Opcionesnombregrupo El nombre del grupo que se ha de crear.

dn El identificador de registro del grupo que se ha de importar.

contenedor_gruposEspecifica el objeto del contenedor de grupos asignado al grupoque se está creando. Si no utiliza este argumento, el grupo secoloca de forma predeterminada en el espacio de objetos debajo de/Management/Groups.

Ejemplos1. En el ejemplo siguiente se crea un grupo importando un grupo que ya existe en

el registro de usuarios:pdadmin> group import engineering “cn=engineering,ou=Austin,o=Wesley Inc,c=US”

Apéndice A. Comandos pdadmin 177

group list

PropósitoProporciona una lista de grupos ordenada por nombres de grupo.

Sintaxisgroup list patrón máx_devueltas group list-dn patrón máx_devueltas

Opcionespatrón Especifica el patrón del nombre de grupo para el que se ha de

efectuar la búsqueda. El patrón puede incluir una combinación decaracteres comodín y constantes de cadena, y es sensible a lasmayúsculas y minúsculas (por ejemplo, *austin*).

máx_devueltas Especifica el límite de entradas que deben devolverse en una solapetición (por ejemplo, 2). Tenga en cuenta que el número devueltotambién depende de la configuración del servidor (que especifica elnúmero máximo de resultados que pueden devolverse como partede una operación de búsqueda). El número máximo real deentradas devueltas es el mínimo de máx_devueltas y el valorconfigurado en el servidor.

list-dn patrón máx_devueltasDevuelve la lista de identificadores de registro de usuario cuyoatributo de nombre común de registro de usuario coincide con elpatrón especificado. La lista devuelta son grupos que estándefinidos en el registro de usuarios pero no necesariamente gruposde Access Manager. Los grupos que no son de Access Managerpueden importarse a Access Manager utilizando el comando groupimport.

DescripciónProporciona una lista de grupos ordenada por nombres de grupo. El orden en quese devuelven es el orden en que se han creado.

Ejemplos1. En el ejemplo siguiente se muestra una lista de grupos que coinciden con el

patrón especificado:pdadmin> group list *a* 3

La salida debería ser similar a:salesmarketingAlex

2. En el ejemplo siguiente se muestra información de grupo que coincide con elpatrón de atributo de nombre común especificado:pdadmin> group list-dn *t* 2

La salida debería ser similar a:cn=credit,ou=Austin,o=Wesley Inc,c=US salescn=marketing,ou=Boston,o=Austin Sale,c=US marketing

178 IBM Tivoli Access Manager Base: Guía del administrador

group modify

PropósitoModifica un grupo existente agregando una descripción, o agregando o eliminandouna lista de usuarios.

Sintaxisgroup modify nombregrupo add lista_usuarios

group modify nombregrupo description descripción

group modify nombregrupo remove lista_usuarios

Opcionesnombregrupo Especifica el nombre del grupo que se ha de modificar.

add lista_usuariosAgrega los usuarios especificados al grupo indicado. El formato dela lista de usuarios es una lista entre paréntesis de nombres deusuario separados por espacios.

description descripciónCambia la descripción del grupo especificado.

remove lista_usuariosElimina los usuarios especificados del grupo especificado. Elformato de la lista de usuarios es una lista entre paréntesis denombres de usuario separados por espacios.

Ejemplos1. El ejemplo siguiente agrega un usuario nuevo al grupo especificado.

pdadmin> group modify engineering add dlucas

2. En el ejemplo siguiente se suprimen usuarios existentes del grupo especificado.pdadmin> group modify engineering remove (user1 "john doe" user2 user3)

3. En el ejemplo siguiente se cambia la descripción del grupo especificado.pdadmin> group modify credit description "Credit, Dept HCUS"

Apéndice A. Comandos pdadmin 179

group show

PropósitoMuestra las propiedades del grupo especificado.

Sintaxisgroup show nombregrupo

group show-dn dn

group show-members nombregrupo

Opcionesnombregrupo Especifica el nombre del grupo que se ha de mostrar.

show-dn dn Muestra el grupo especificado por el identificador del grupo delregistro de usuarios. El grupo devuelto está definido en el registrode usuarios pero no es necesariamente un grupo de AccessManager. Los grupos que no son de Access Manager puedenimportarse a Access Manager utilizando el comando group import.

show-members nombregrupoMuestra los nombres de usuario de los miembros del grupoespecificado.

Ejemplos1. En el ejemplo siguiente se muestran propiedades del grupo especificado:

pdadmin> group show credit

La salida debería ser similar a:ID de grupo: creditDN de LDAP: cn=credit,ou=Austin,o=Wesley Inc,c=USDescripción: Credit, Dept HCUSCN de LDAP: creditEs SecGroup: true

2. En el ejemplo siguiente se muestran propiedades especificadas por elidentificador del grupo del registro de usuarios.pdadmin> group show-dn cn=credit,ou=Austin,o=Wesley Inc,c=US

La salida debería ser similar a:ID de grupo: creditDN de LDAP: cn=credit,ou=Austin,o=Wesley Inc,c=USDescripción: Credit, Dept HCUSCN de LDAP: creditEs SecGroup: true

3. En el ejemplo siguiente se proporciona una lista de los nombres de usuario delos miembros del grupo especificado.pdadmin> group show-members credit

La salida debería ser similar a:dlucasmlucaser

180 IBM Tivoli Access Manager Base: Guía del administrador

help

PropósitoProporciona ayuda del sistema para los comandos y opciones de pdadmin.

Sintaxishelp tema

help comando

Opcionestema Especifica el tema de comando general para el que se necesita

ayuda.

comando Especifica el comando concreto para el que se necesita ayuda.

Ejemplos1. En el ejemplo siguiente se muestra una lista de comandos especificados por el

tema:help action

La salida debería ser similar a:action createaction deleteaction group list...

2. En el ejemplo siguiente se muestra una lista de opciones disponibles para elcomando especificado:help action create

La salida debería ser similar a:action create nombre_acción etiqueta_acción tipo_acciónaction create nombre_acción etiqueta_acción tipo_acción nombre_grupo_acciones...

Apéndice A. Comandos pdadmin 181

login

PropósitoDefine credenciales de autenticación que se utilizan cuando se establececomunicación con Policy Server.

Sintaxislogin [-a id_admin [-p contraseña]]

Opciones[-a id_admin] Especifica el ID del administrador. Si esta es la única opción que se

especifica, al usuario se le solicitará la contraseña.

[-p contraseña] Especifica la contraseña.

DescripciónDefine credenciales de autenticación que se utilizan cuando se establececomunicación con Policy Server. Estas credenciales se utilizan para determinarprivilegios de acceso de un usuario en relación con datos de Policy Server.

Las credenciales no se ″apilan″. Es decir, una operación de login sustituirácompletamente todas las credenciales existentes.

182 IBM Tivoli Access Manager Base: Guía del administrador

logout

PropósitoDescarta todas las credenciales de autenticación en vigor.

Sintaxislogout

OpcionesNinguna.

DescripciónDescarta todas las credenciales de autenticación en vigor.

Al salir del programa de utilidad de línea de comandos pdadmin se descartaránlas credenciales.

Apéndice A. Comandos pdadmin 183

object create

PropósitoCrea un objeto protegido nuevo.

Sintaxisobject create nombre_objeto descripción tipo ispolicyattachable {yes|no}

Opcionesnombre_objeto Especifica el nombre del objeto que se está creando. Este nombre

debe ser exclusivo.

descripción Cadena de texto que describe el objeto que se está creando.

tipo Especifica el icono gráfico asociado a este objeto y mostrado porWeb Portal Manager. El rango de tipos es 0 a 13. Por ejemplo, lostipos 10 y 13 son los adecuados para objetos de contenedor.

ispolicyattachable {yes|no}Especifica si una ACL o una política de objetos protegidos puedeasociarse a este objeto.

184 IBM Tivoli Access Manager Base: Guía del administrador

object delete

PropósitoSuprime el objeto protegido especificado.

Sintaxisobject delete nombre_objeto

Opcionesnombre_objeto Especifica el objeto protegido que se ha de suprimir.

DescripciónSuprime el objeto protegido especificado.

Apéndice A. Comandos pdadmin 185

object list

PropósitoMuestra una lista de todos los objetos agrupados bajo el objeto protegidoespecificado.

Sintaxisobject list nombre_objeto

Opcionesnombre_objeto Especifica el objeto protegido.

DescripciónMuestra una lista de todos los objetos agrupados bajo el objeto protegidoespecificado.

186 IBM Tivoli Access Manager Base: Guía del administrador

object list attribute

PropósitoMuestra una lista de todos los atributos ampliados asociados al objeto protegidoespecificado.

Sintaxisobject list nombre_objeto atributo

Opcionesnombre_objeto Especifica el objeto protegido.

DescripciónMuestra una lista de todos los atributos ampliados asociados al objeto protegidoespecificado.

Apéndice A. Comandos pdadmin 187

object listandshow

PropósitoProporciona una lista de todos los objetos hijo agrupados bajo el objeto protegidoespecificado y muestra todos los valores asociados a cada uno de estos objetos.

Sintaxisobject listandshow nombre_objeto

Opcionesnombre_objeto Especifica el objeto protegido para el que se han de mostrar los

objetos hijo y valores asociados.

188 IBM Tivoli Access Manager Base: Guía del administrador

object modify

PropósitoModifica un objeto existente.

Sintaxisobject modify nombre_objeto delete attribute nombre_atributo

object modify nombre_objeto delete attribute nombre_atributo valor_atributo

object modify nombre_objeto set attribute nombre_atributo valor_atributo

object modify nombre_objeto set description descripción

object modify nombre_objeto set ispolicyattachable {yes|no}

object modify nombre_objeto set name nombre_objeto_nuevo

object modify nombre_objeto set type tipo

Opcionesnombre_objeto Especifica el objeto protegido que se ha de modificar.delete attribute nombre_atributo

Suprime el atributo ampliado especificado (nombre y valor) delobjeto protegido especificado.

delete attribute nombre_atributo valor_atributoSuprime el valor indicado de la clave de atributo ampliadoespecificada en el objeto protegido especificado.

set attribute nombre_atributo valor_atributoCrea un atributo ampliado, con el nombre y el valor especificados,y lo agrega al objeto protegido especificado. Si el atributo ya existe,su valor se agrega como un valor adicional cuando no existe elmismo valor para este atributo. Si existe el mismo valor para esteatributo, no se vuelve a agregar (no se permiten valoresduplicados) y no se devuelve ningún error.

set description descripciónEstablece el campo de la descripción del objeto protegidoespecificado.

set ispolicyattachable {yes|no}Establece el atributo isPolicyAttachable del objeto protegidoespecificado.

set name nombre_objeto_nuevoEstablece el nombre del objeto protegido especificado.

set type tipo Establece el campo del tipo del objeto protegido especificado.

Ejemplos1. El ejemplo siguiente, que se muestra en una línea, establece la opción

ispolicyattachable.pdadmin> object create /Management/Groups/Travel "Travel Container Object" \14 ispolicyattachable yes

Apéndice A. Comandos pdadmin 189

object show

PropósitoDevuelve el objeto protegido especificado.

Sintaxisobject show nombre_objeto

Opcionesnombre_objeto Devuelve el objeto protegido especificado.

DescripciónDevuelve el objeto protegido especificado.

190 IBM Tivoli Access Manager Base: Guía del administrador

object show attribute

PropósitoDevuelve el valor asociado al atributo ampliado especificado para el objetoprotegido indicado.

Sintaxisobject show nombre_objeto attribute nombre_atributo

Opcionesnombre_objeto Devuelve el objeto protegido especificado.

nombre_atributoEspecifica el nombre del atributo ampliado cuyos valores van amostrarse.

DescripciónDevuelve el valor asociado al atributo ampliado especificado para el objetoprotegido indicado.

Apéndice A. Comandos pdadmin 191

objectspace create

PropósitoCrea un espacio de objetos protegidos.

Sintaxisobjectspace create nombre_espacio_objetos descripción tipo

Opcionesnombre_espacio_objetos

Especifica el nombre del espacio de objetos que se ha de crear.

descripción Especifica la descripción del espacio de objetos nuevo.

tipo Especifica el tipo del espacio de objetos que se ha de crear.

DescripciónCrea un espacio de objetos protegidos.

Como parámetro de entrada debe especificar tipo, que es el tipo de espacio deobjetos para cada espacio de objetos nuevo. Web Portal Manager lo utiliza paramostrar un icono adecuado para el objeto.

Nota: En el directorio raíz del espacio de objetos protegidos nuevo se estableceautomáticamente el atributo ispolicyattachable en true.

192 IBM Tivoli Access Manager Base: Guía del administrador

objectspace delete

PropósitoSuprime el espacio de objetos protegidos especificado.

Sintaxisobjectspace delete nombre_espacio_objetos

Opcionesnombre_espacio_objetos

Especifica el nombre del espacio de objetos que se ha de suprimir.

DescripciónSuprime el espacio de objetos protegidos especificado.

Apéndice A. Comandos pdadmin 193

objectspace list

PropósitoMuestra una lista de todos los espacios de objetos protegidos.

Sintaxisobjectspace list

OpcionesNinguna.

DescripciónMuestra una lista de todos los espacios de objetos protegidos.

194 IBM Tivoli Access Manager Base: Guía del administrador

policy get

PropósitoLos comandos policy get son un conjunto de comandos de gestión que muestranreglas y condiciones de las contraseñas y cuentas de un usuario.

Sintaxispolicy get account-expiry-date [-user nombre_usuario]

policy get disable-time-interval [-user nombre_usuario]

policy get max-login-failures [-user nombre_usuario]

policy get max-password-age [-user nombre_usuario]

policy get max-password-repeated-chars [-user nombre_usuario]

policy get min-password-alphas [-user nombre_usuario]

policy get min-password-length [-user nombre_usuario]

policy get min-password-non-alphas [-user nombre_usuario]

policy get password-spaces [-user nombre_usuario]

policy get tod-access [-user nombre_usuario]

Opciones[-user nombre_usuario]

Especifica el usuario cuya información de política se ha de mostrar.Si no se especifica esta opción, se muestra la política general. Enrelación con una política determinada, si a un usuario se le haaplicado una política específica, ésta tiene preferencia sobrecualquier política general que también podría estar definida. Lapreferencia se aplica independientemente de si la política específicaes más o menos restrictiva que la política general.

account-expiry-dateMuestra la fecha de caducidad de todas las cuentas de usuario.

disable-time-intervalMuestra el tiempo en que se inhabilitarán cuentas de usuariocuando se exceda el número máximo de inicios de sesiónincorrectos. Este valor se aplica a todas las cuentas de usuario.

max-login-failuresMuestra el número máximo de inicios de sesión incorrectospermitidos para cada cuenta de usuario.

max-password-ageMuestra el tiempo máximo en que una contraseña será válida paracuentas de usuario.

max-password-repeated-charsMuestra el número máximo de caracteres repetidos permitidos enuna contraseña para cada cuenta de usuario.

Apéndice A. Comandos pdadmin 195

min-password-alphasMuestra el número mínimo de caracteres alfabéticos necesarios enuna contraseña para cada cuenta de usuario.

min-password-lengthMuestra la longitud mínima de contraseña para todas las cuentasde usuario.

min-password-non-alphasMuestra el número mínimo de caracteres no alfabéticos necesariosen una contraseña para cada cuenta de usuario.

password-spacesMuestra si se permiten espacios en contraseñas para todas lascuentas de usuario.

tod-access Muestra la política de acceso global según la hora del día.

Ejemplos1. En el ejemplo siguiente se devolverá la fecha de caducidad de cuenta para el

usuario especificado:pdadmin> policy get account-expiry-date –user dlucas

2. En el ejemplo siguiente se devolverá el tiempo máximo de validez de unacontraseña para el usuario especificado:pdadmin> policy get max-password-age –user dlucas

196 IBM Tivoli Access Manager Base: Guía del administrador

policy set

PropósitoLos comandos policy set son un conjunto de comandos de gestión que establecenreglas y condiciones de las contraseñas y cuentas de un usuario.

Sintaxispolicy set account-expiry-date {unlimited|tiempo_absoluto|unset} [-usernombre_usuario]

policy set disable-time-interval {número|unset|disable} [-user nombre_usuario]

policy set max-login-failures número|unset [-user nombre_usuario]

policy set max-password-age {unset|tiempo_relativo} [-user nombre_usuario]

policy set max-password-repeated-chars número|unset [-user nombre_usuario]

policy set min-password-alphas {unset|número} [-user nombre_usuario]

policy set min-password-length {unset|número} [-user nombre_usuario]

policy set min-password-non-alphas {unset|número} [-user nombre_usuario]

policy set password-spaces {yes|no|unset} [-user nombre_usuario]

policy set tod-access {{anyday|weekday|lista_días}:{espec_hora-espec_hora}[:{utc|local}]|unset} [-user nombre_usuario]

Opciones[-user nombre_usuario]

Especifica el usuario cuya información de política se ha deestablecer. Si no se especifica esta opción, se establece la políticageneral. En relación con una política determinada, si a un usuariose le ha aplicado una política específica, ésta tiene preferencia sobrecualquier política general que también podría estar definida. Lapreferencia se aplica independientemente de si la política específicaes más o menos restrictiva que la política general.

account-expiry-date {unlimited|tiempo_absoluto|unset}Establece la fecha de caducidad de todas las cuentas de usuario.

disable-time-interval {número|unset|disable}Establece el tiempo en que se inhabilitarán cuentas de usuariocuando se exceda el número máximo de inicios de sesiónincorrectos. El valor predeterminado es 180.

max-login-failures número|unsetEstablece el número máximo de inicios de sesión incorrectospermitidos para cada cuenta de usuario. El valor predeterminadoes 10.

max-password-age {unset|tiempo_relativo}Establece la duración máxima de la contraseña para todas las

Apéndice A. Comandos pdadmin 197

cuentas de usuario. La opción tiempo_relativo hace referencia a laúltima vez que se modificó la contraseña.

max-password-repeated-chars número|unsetEstablece el número máximo de caracteres repetidos permitidos enuna contraseña para cada cuenta de usuario. El valorpredeterminado es 2.

min-password-alphas {unset|número}Establece el número mínimo de caracteres alfabéticos necesarios enuna contraseña para cada cuenta de usuario. El valorpredeterminado es 4.

min-password-length {unset|número}Establece la longitud mínima de contraseña para todas las cuentasde usuario. El valor predeterminado es 8.

min-password-non-alphas {unset|número}Establece el número mínimo de caracteres no alfabéticos necesariosen una contraseña para cada cuenta de usuario. El valorpredeterminado es 1.

password-spaces {yes|no|unset}Establece si se permiten espacios en contraseñas para todas lascuentas de usuario. El valor predeterminado es unset(desactivado).

tod-access {{anyday|weekday|lista_días}:{espec_hora-espec_hora}[:{utc|local}]|unset}Establece la política de acceso global según la hora del día. Deforma predeterminada, el huso horario opcional es local. (Nota:utc=GMT)

Ejemplos1. En el ejemplo siguiente se establece la fecha de caducidad del usuario

especificado:pdadmin> policy set account-expiry-date 1999-12-30-23:30:00 –user dlucas

2. En el ejemplo siguiente se establece la duración máxima de la contraseña paratodas las cuentas de usuario.pdadmin> policy set max-password-age 031-08:30:00 –user dlucas

198 IBM Tivoli Access Manager Base: Guía del administrador

pop attach

PropósitoAsocia una política de objetos protegidos (POP) al objeto protegido especificado.

Sintaxispop attach nombre_objeto nombre_pop

Opcionesnombre_objeto Especifica el nombre del objeto protegido para el que se asociará la

política de objetos protegidos.

nombre_pop Especifica el nombre de la política de objetos protegidos que se hade asociar.

DescripciónAsocia una política de objetos protegidos al objeto protegido especificado. Sólo sepuede asociar una POP como máximo a un objeto protegido determinado. Si elobjeto ya tiene una POP asociada, la POP especificada sustituye a la existente. Esamisma POP se puede asociar a múltiples objetos protegidos. Antes de intentarasociar una POP a un objeto protegido, asegúrese de que éste existe en el espaciode objetos protegidos.

Apéndice A. Comandos pdadmin 199

pop create

PropósitoCrea un objeto de la política de objetos protegidos.

Sintaxispop create nombre_pop

Opcionesnombre_pop Especifica el nombre de la política de objetos protegidos que se ha

de crear.

DescripciónCrea un objeto de la política de objetos protegidos.

200 IBM Tivoli Access Manager Base: Guía del administrador

pop delete

PropósitoSuprime la política de objetos protegidos especificada.

Sintaxispop delete nombre_pop

Opcionesnombre_pop Especifica el nombre de la política de objetos protegidos que se ha

de suprimir.

DescripciónSuprime la política de objetos protegidos especificada.

Apéndice A. Comandos pdadmin 201

pop detach

PropósitoDesasocia una política de objetos protegidos del objeto protegido especificado.

Sintaxispop detach nombre_objeto

Opcionesnombre_objeto Especifica el objeto protegido del que se ha de suprimir la política

de objetos protegidos.

DescripciónDesasocia una política de objetos protegidos del objeto protegido especificado.

202 IBM Tivoli Access Manager Base: Guía del administrador

pop find

PropósitoBusca y lista todos los objetos protegidos que tienen asociada la política de objetosprotegidos especificada.

Sintaxispop find nombre_pop

Opcionesnombre_pop Especifica el nombre de la política de objetos protegidos en la que

se ha de efectuar la búsqueda.

DescripciónBusca y lista todos los objetos protegidos que tienen asociada la política de objetosprotegidos especificada.

Apéndice A. Comandos pdadmin 203

pop list

PropósitoMuestra una lista de todos los objetos de la política de objetos protegidos.

Sintaxispop list

OpcionesNinguna.

DescripciónMuestra una lista de todos los objetos de la política de objetos protegidos.

204 IBM Tivoli Access Manager Base: Guía del administrador

pop list attribute

PropósitoMuestra una lista de todos los atributos ampliados asociados a una política deobjetos protegidos (POP).

Sintaxispop list nombre_pop attribute

Opcionesnombre_pop Especifica la POP para la que se ha de proporcionar una lista de

atributos.

DescripciónMuestra una lista de todos los atributos ampliados asociados a una política deobjetos protegidos.

Apéndice A. Comandos pdadmin 205

pop modify

PropósitoModifica políticas de objetos protegidos.

Sintaxispop modify nombre_pop delete attribute nombre_atributo

pop modify nombre_pop delete attribute nombre_atributo valor_atributo

pop modify nombre_pop set attribute nombre_atributo valor_atributo

pop modify nombre_pop set audit-level{all|none|permit|deny|lista_nivel_auditoría}

pop modify nombre_pop set description descripción

pop modify nombre_pop set ipauth add red máscara_red nivel_autorización

pop modify nombre_pop set ipauth anyothernw nivel_autorización

pop modify nombre_pop set ipauth remove red máscara_red

pop modify nombre_pop set qop {none|integrity|privacy}

pop modify nombre_pop set tod-access{anyday|weekday|lista_días}:{anytime|espec_hora-espec_hora}[:{utc|local}]

pop modify nombre_pop set warning {yes|no}

Opcionesnombre_pop Especifica el nombre de la política de objetos protegidos que se ha

de modificar.

delete attribute nombre_atributoSuprime el atributo ampliado indicado de la política de objetosprotegidos especificada.

delete attribute nombre_atributo valor_atributoSuprime el valor indicado de la clave de atributo ampliadoespecificada en la política de objetos protegidos especificada.

set attribute nombre_atributo valor_atributoEstablece o modifica el valor indicado de la clave de atributoampliado especificada en la política de objetos protegidosespecificada. Si el atributo ya existe, su valor se agrega como unvalor adicional cuando no existe el mismo valor para este atributo.Si existe el mismo valor para este atributo, no se vuelve a agregar(no se permiten valores duplicados) y no se devuelve ningún error.

set audit-level {all|none|permit|deny|lista_nivel_auditoría}Establece el nivel de auditoría para la política de objetos protegidosespecificada.

206 IBM Tivoli Access Manager Base: Guía del administrador

set description descripciónEstablece la descripción de la política de objetos protegidosespecificada.

set ipauth add red máscara_red nivel_autorizaciónEstablece los valores de autenticación de punto final de IP en lapolítica de objetos protegidos especificada.

set ipauth anyothernw nivel_autorizaciónEstablece el valor de anyothernw, o de cualquier otra red, para elnivel de autenticación de la política de objetos protegidosespecificada (POP). Si el control del acceso mediante la dirección IPno es un factor prioritario, utilice el valor de anyothernw paraestablecer el nivel de autenticación para todas la direcciones IP yrangos de direcciones IP que no figuren explícitamente en la POP.

set ipauth remove red máscara_redElimina los valores de autenticación de punto final de IP de lapolítica de objetos protegidos especificada.

set qop {none|integrity|privacy}

Establece el nivel de calidad de protección para la política deobjetos protegidos especificada. Los siguientes valores de cadenaestán soportados:v nonev integrityv privacy

set tod-access {anyday|weekday|lista_días}:{anytime|espec_hora-espec_hora}[:{utc|local}]

Establece el rango de horas del día para la política de objetosprotegidos especificada. De forma predeterminada, el huso horarioopcional es local.

set warning {yes|no}Establece la modalidad de aviso para la política de objetosprotegidos especificada.

Apéndice A. Comandos pdadmin 207

pop show

PropósitoMuestra detalles de la política de objetos protegidos (POP).

Sintaxispop show nombre_pop

Opcionesnombre_pop Especifica la POP que se ha de mostrar.

DescripciónMuestra detalles de la política de objetos protegidos.

208 IBM Tivoli Access Manager Base: Guía del administrador

pop show attribute

PropósitoMuestra los valores del atributo ampliado indicado de la política de objetosprotegidos (POP) especificada.

Sintaxispop show nombre_pop attribute nombre_atributo

Opcionesnombre_pop Especifica la POP cuyo atributo que se ha de mostrar.

nombre_atributoEspecifica el nombre del atributo ampliado cuyos valores se han demostrar.

DescripciónMuestra los valores del atributo ampliado indicado de la política de objetosprotegidos especificada.

Apéndice A. Comandos pdadmin 209

quit

PropósitoSale de la modalidad de línea de comandos de pdadmin.

Sintaxisquit

OpcionesNinguna.

210 IBM Tivoli Access Manager Base: Guía del administrador

rsrc create

PropósitoCrea un recurso web de inicio de sesión único.

Sintaxisrsrc create nombre_recurso [–desc descripción]

Opcionesnombre_recurso Especifica el nombre del recurso que se ha de crear.

[–desc descripción]Especifica una descripción para el recurso. Las descripciones quecontienen un espacio deben figurar entre comillas dobles.

DescripciónCrea un recurso web de inicio de sesión único. Un recurso web es un servidor webque actúa como servidor de fondo de una conexión (junction) de WebSEAL.

Ejemplos1. En el ejemplo siguiente, que se ha entrado en una línea, se crea y se

proporciona un nombre a un recurso web con una descripción asociada:pdadmin> rsrc create engwebs01 –desc \“Engineering Web server – Room 4807”

Apéndice A. Comandos pdadmin 211

rsrc delete

PropósitoSuprime el recurso web de inicio de sesión único especificado.

Sintaxisrsrc delete nombre_recurso

Opcionesnombre_recurso Especifica el nombre del recurso que se ha de suprimir. Si el

recurso no existe, se muestra un error.

DescripciónSuprime el recurso web de inicio de sesión único especificado.

Ejemplos1. En el ejemplo siguiente se suprime el recurso especificado y su descripción

asociada:pdadmin> rsrc delete engwebs01

212 IBM Tivoli Access Manager Base: Guía del administrador

rsrc list

PropósitoDevuelve una lista de todos los nombres de recurso web de inicio de sesión único.

Sintaxisrsrc list

OpcionesNinguna.

DescripciónDevuelve una lista de todos los nombres de recurso web de inicio de sesión único.

Ejemplos1. En el ejemplo siguiente se devuelve una lista de todos los nombres de recurso

web de inicio de sesión único.pdadmin> rsrc list

La salida es similar a:engwebs01engwebs02engwebs03

Apéndice A. Comandos pdadmin 213

rsrc show

PropósitoDevuelve información del recurso web de inicio de sesión único especificado.

Sintaxisrsrc show nombre_recurso

Opcionesnombre_recurso Especifica el nombre del recurso del que se mostrará información.

Si el recurso no existe, se muestra un error.

DescripciónDevuelve información del recurso web de inicio de sesión único especificado.

Ejemplos1. En el ejemplo siguiente se devuelve información para el recurso especificado:

pdadmin> rsrc show engwebs01

La salida debería ser similar a:Nombre de recurso web: engwebs01Descripción: Engineering Web server - Room 4807

214 IBM Tivoli Access Manager Base: Guía del administrador

rsrccred create

PropósitoCrea una credencial de inicio de sesión único.

Sintaxisrsrccred create nombre_recurso rsrcuser idusuario_recurso rsrcpwd contraseña_recursorsrctype {web|group} user nombreusuario

Opcionesnombre_recurso Especifica el nombre asignado al recurso cuando éste se creó. Para

crear la credencial de un recurso, debe existir el recurso (o el grupode recursos). Si el recurso (o el grupo de recursos) no existe o no seha especificado, se muestra un mensaje de error.

rsrcuser idusuario_recursoEspecifica la identificación de usuario exclusiva (ID de usuario) delusuario en el servidor web.

rsrcpwd contraseña_recursoEspecifica la contraseña de un usuario en el servidor web.

rsrctype {web|group}Especifica si el tipo de recurso es web o grupo.

user nombreusuarioEspecifica el nombre del usuario al que se aplica la información decredencial de recurso. Si el usuario no existe o no se haespecificado, se muestra un mensaje de error.

DescripciónCrea una credencial de inicio de sesión único.

Ejemplos1. En el ejemplo siguiente, que se ha entrado en una línea, se crea la credencial de

recurso para el usuario proporcionado:pdadmin> rsrccred create engwebs01 rsrcuser \4807ws01 rsrcpwd resrcpwd rsrctype web user dlucas

Apéndice A. Comandos pdadmin 215

rsrccred delete

PropósitoSuprime una credencial de inicio de sesión único.

Sintaxisrsrccred delete nombre_recurso rsrctype {web|group} user nombreusuario

Opcionesnombre_recurso Especifica el nombre asignado al recurso cuando éste se creó.

rsrctype {web|group}Especifica el tipo de recurso. El tipo de recurso debe coincidir conel tipo de recurso asignado cuando se creó por primera vez.

user nombreusuarioEspecifica el nombre del usuario al que se aplica la información decredencial de recurso.

DescripciónSuprime una credencial de inicio de sesión único.

Ejemplos1. En el ejemplo siguiente se suprime la información de credencial de recurso del

recurso, tipo de recurso o nombre de usuario determinados:pdadmin> rsrccred delete engwebs01 rsrctype web user dlucas

216 IBM Tivoli Access Manager Base: Guía del administrador

rsrccred list user

PropósitoDevuelve una lista de credenciales de inicio de sesión único del usuarioespecificado.

Sintaxisrsrccred list user nombreusuario

Opcionesnombreusuario Especifica el nombre del usuario al que se aplica la información de

credencial de recurso.

DescripciónDevuelve una lista de credenciales de inicio de sesión único del usuarioespecificado.

Ejemplos1. En el ejemplo siguiente, se devuelve una lista de credenciales de inicio de

sesión único del usuario especificado:pdadmin> rsrccred list user dlucas

La salida debería ser similar a:Nombre de recurso: engwebs01Tipo de recurso: groupNombre de recurso: engwebs02Tipo de recurso: web

Apéndice A. Comandos pdadmin 217

rsrccred modify

PropósitoCrea o modifica una credencial de inicio de sesión único.

Sintaxisrsrccred modify nombre_recurso rsrctype {web|group} set [–rsrcuseridusuario_recurso] [– rsrcpwd contraseña_recurso] user nombreusuario

Opcionesnombre_recurso Especifica el nombre asignado al recurso cuando éste se creó.

rsrctype {web|group}Especifica el tipo de recurso. El tipo de recurso debe coincidir conel tipo de recurso asignado cuando se creó por primera vez.

[–rsrcuser idusuario_recurso]Especifica la identificación de usuario exclusiva (ID de usuario) delusuario en el servidor web. Para cambiar o restablecer el ID deusuario de recurso del usuario o información de la contraseña,estos comandos opcionales deben ir precedidos por una raya (–).

[– rsrcpwd contraseña_recurso]Especifica la contraseña de un usuario en el servidor web. Si seespecifica este parámetro sin especificar el parámetro -rsrcuser, seborrará tanto el ID de usuario de recurso como la contraseña derecurso. Para establecer la contraseña de recurso de manera simple,debe especificar tanto el ID de usuario de recurso como lacontraseña de recurso.

user nombreusuarioEspecifica el nombre del usuario al que se aplica la información decredencial de recurso.

DescripciónCrea o modifica una credencial de inicio de sesión único.

Ejemplos1. En el ejemplo siguiente, que se ha entrado en una línea, se modifica el recurso

especificado:pdadmin> rsrccred modify engwebs01 rsrctype web \set –rsrcuser 4807ws01 –rsrcpwd newrsrpw user dlucas

218 IBM Tivoli Access Manager Base: Guía del administrador

rsrccred show

PropósitoDevuelve la credencial de inicio de sesión único especificada. El identificador de lacredencial se compone de un nombre de recurso, un tipo de recurso y un nombrede usuario.

Sintaxisrsrccred show nombre_recurso rsrctype {web|group} user nombreusuario

Opcionesnombre_recurso Especifica el nombre del recurso de inicio de sesión único asociado

a la credencial.

rsrctype {web|group}Especifica el tipo del recurso de inicio de sesión único asociado a lacredencial.

user nombreusuarioEspecifica el nombre del usuario asociado a esta credencial.

DescripciónDevuelve la credencial de inicio de sesión único especificada por el recurso, tipo derecurso y usuario determinados.

Ejemplos1. En el ejemplo siguiente se devuelve la credencial de inicio de sesión único

especificada:pdadmin> rsrccred show webs4807 rsrctype group user dlucas

La salida debería ser similar a:Nombre de recurso: engwebs01Tipo de recurso: groupID de usuario de recurso: dlucas

Apéndice A. Comandos pdadmin 219

rsrcgroup create

PropósitoCrea un recurso de grupo de inicio de sesión único.

Sintaxisrsrcgroup create nombre_grupo_recursos [–desc descripción]

Opcionesnombre_grupo_recursos

Especifica el nombre del grupo de recursos.

[–desc descripción]El argumento descripción es una descripción opcional que puedeagregarse para identificar este grupo de recursos. El parámetro–desc opcional debe ir precedido de una raya( – ). Lasdescripciones que contienen espacios deben figurar entre comillasdobles.

DescripciónCrea un recurso de grupo de inicio de sesión único.

Ejemplos1. En el ejemplo siguiente se crea y se asigna un nombre a un recurso de grupo

web y se proporciona una descripción para este recurso:pdadmin> rsrcgroup create webs4807 –desc “Web servers, Room 4807”

220 IBM Tivoli Access Manager Base: Guía del administrador

rsrcgroup delete

PropósitoSuprime un recurso de grupo de inicio de sesión único.

Sintaxisrsrcgroup delete nombre_grupo_recursos

Opcionesnombre_grupo_recursos

Especifica el nombre del grupo de recursos. El grupo de recursostiene que existir.

DescripciónSuprime un recurso de grupo de inicio de sesión único, incluida cualquierinformación de la descripción.

Ejemplos1. En el ejemplo siguiente se suprime el grupo de recursos especificado y su

descripción asociada:pdadmin> rsrcgroup delete webs4807

Apéndice A. Comandos pdadmin 221

rsrcgroup list

PropósitoDevuelve una lista de todos los nombres de recurso de grupo de inicio de sesiónúnico.

Sintaxisrsrcgroup list

OpcionesNinguna.

DescripciónDevuelve una lista de todos los nombres de recurso de grupo de inicio de sesiónúnico.

Ejemplos1. En el ejemplo siguiente se devuelve una lista de todos los nombres de recurso

de grupo de inicio de sesión único.pdadmin> rsrcgroup list

La salida debería ser similar a:webs4807websbld3

222 IBM Tivoli Access Manager Base: Guía del administrador

rsrcgroup modify

PropósitoAgrega o elimina un recurso de inicio de sesión único en un grupo de recursos deinicio de sesión único.

Sintaxisrsrcgroup modify nombre_grupo_recursos add rsrcname nombre_recurso

rsrcgroup modify nombre_grupo_recursos remove rsrcname nombre_recurso

Opcionesnombre_grupo_recursos

Especifica el nombre del grupo de recursos que se ha de modificar.

add rsrcname nombre_recursoAgrega un recurso de inicio de sesión único al grupo de recursosde inicio de sesión único especificado.

remove rsrcname nombre_recursoElimina un recurso de inicio de sesión único del grupo de recursosde inicio de sesión único especificado.

DescripciónAgrega o elimina un recurso de inicio de sesión único en un grupo de recursos deinicio de sesión único.

Ejemplos1. En el ejemplo siguiente se agrega el recurso especificado al grupo de recursos

web existente:pdadmin> rsrcgroup modify webs4807 add rsrcname engwebs02

2. En el ejemplo siguiente se suprime el recurso especificado del grupo derecursos web existente:pdadmin> rsrcgroup modify webs4807 remove rsrcname engwebs02

Apéndice A. Comandos pdadmin 223

rsrcgroup show

PropósitoDevuelve el recurso de grupo de inicio de sesión único especificado.

Sintaxisrsrcgroup show nombre_grupo_recursos

Opcionesnombre_grupo_recursos

Especifica el nombre del grupo de recursos. Si el recurso no existe,se muestra un mensaje de error.

DescripciónDevuelve el recurso de grupo de inicio de sesión único especificado. Se muestra elnombre del grupo de recursos, la descripción del grupo de recursos y una lista delos nombres de los miembros del grupo de recursos. Los miembros del grupo derecursos son los recursos web individuales (servidores).

Ejemplos1. En el ejemplo siguiente se devuelve el recurso de grupo de inicio de sesión

único especificado:pdadmin> rsrcgroup show webs4807

La salida debería ser similar a:Nombre de grupo de recurso: webs4807Descripción: Web servers, Room 4807Miembros de recurso:engwebs01engwebs02engwebs03

224 IBM Tivoli Access Manager Base: Guía del administrador

server list

PropósitoMuestra una lista de todos los servidores registrados.

Sintaxisserver list

OpcionesNinguna.

DescripciónMuestra una lista de todos los servidores registrados. Tenga en cuenta que elformato del nombre del servidor que este comando muestra debe utilizarse para elargumento nombre_servidor en los otros comandos de servidor de pdadmin.

Ejemplos1. En el ejemplo siguiente se muestra una lista de todos los servidores registrados:

pdadmin> server list

La salida debería ser similar a:ivacld-topserverivacld-server2ivacld-server3ivacld-server4

Apéndice A. Comandos pdadmin 225

server listtasks

PropósitoMuestra una lista de las tareas disponibles en el servidor.

Sintaxisserver listtasks nombre_servidor

Opcionesnombre_servidor

Especifica el nombre del servidor para el que se mostrarán tareasdisponibles (comandos).

DescripciónMuestra una lista de las tareas disponibles en el servidor.

Ejemplos1. En el ejemplo siguiente se muestra una lista de las tareas disponibles en el

servidor.pdadmin> server listtasks ivacld-mogman.admogman.com

La salida debería ser similar a:trace set nivel de componente [file path=archivo|config-otro-agente-registro]trace show [componente]trace list [componente]stats show [componente]stats liststats on [componente] [intervalo] [cuenta] [file path= archivo|config-otro-agente-registro]stats off [componente]stats reset [componente]stats get [componente]

226 IBM Tivoli Access Manager Base: Guía del administrador

server replicate

PropósitoNotifica a servidores de autorización que van a recibir actualizaciones de base dedatos.

Sintaxisserver replicate [–server nombre_servidor]

Opciones[–server nombre_servidor]

Especifica el nombre del servidor que va a recibir actualizacionesde base de datos. Si no se especifica esta opción, se notifica a todoslos servidores configurados para recibir actualizaciones.

DescripciónNotifica a servidores de autorización que van a recibir actualizaciones de base dedatos. Si se ha especificado un nombre de servidor, pero no está configurado pararecibir actualizaciones de base de datos, se mostrará un mensaje de error. Si no seha especificado ningún nombre de servidor, se inicia el proceso de notificación detodos los servidores configurados, pero no se mostrarán mensajes de error paraservidores individuales.

Ejemplos1. A continuación, se muestra un ejemplo de este comando cuando se especifica el

nombre_servidor:pdadmin> server replicate -server ivacld-topserver

Apéndice A. Comandos pdadmin 227

server show

PropósitoMuestra las propiedades del servidor especificado.

Sintaxisserver show nombre_servidor

Opcionesnombre_servidor

Especifica el nombre del servidor cuyas propiedades van amostrarse.

DescripciónMuestra las propiedades del servidor especificado.

Ejemplos1. En el ejemplo siguiente se muestran las propiedades del servidor especificado:

pdadmin> server show ivacld-topserver

La salida debería ser similar a:ivacld-topserver

Descripción: ivacld/topserverNombre de host: topserverPrincipal: ivacld/topserverPuerto: 7137Realizando la escucha de notificaciones de actualizaciónde base de datos de autorizaciones: yesServicios de administración de AZN:

AZN_ADMIN_SVC_TRACE

228 IBM Tivoli Access Manager Base: Guía del administrador

server task

PropósitoEnvía un comando a Authorization Server.

Sintaxisserver task nombre_servidor tarea_servidor

Opcionesnombre_servidor

Especifica el nombre del servidor al que se enviara la tarea_servidor.

tarea_servidor Especifica la tarea que se está enviando (comando).

DescripciónEnvía un comando a Authorization Server.

Ejemplos1. A continuación, se muestra un ejemplo de la salida resultante de enviar la tarea

stats list a Authorization Server:pdadmin> server task ivacld-mogman.admogman.com stats list

pd.ras.stats.monitorpd.log.EventPool.queue

Apéndice A. Comandos pdadmin 229

user create

PropósitoCrea un usuario en el registro de usuarios utilizado por Policy Server einicialmente asocia ese usuario a uno o más grupos.

Sintaxisuser create [–gsouser] [–no-password-policy] nombreusuario dn cn sn contraseña

user create [–gsouser] [–no-password-policy] nombreusuario dn cn sn contraseña[grupos]

Opciones[–gsouser] Cuando se especifica este argumento opcional, se habilitan las

posibilidades de Global Signon (GSO) del usuario.[–no-password-policy]

Aplica la política de contraseñas en todos los casos. La excepción aesta regla es que la opción –no-password-policy sólo seproporciona para crear un usuario con una contraseña inicial. Serecomienda modificar la contraseña inicial.

nombreusuario Especifica el nombre del usuario que se está creando. Este nombredebe ser exclusivo.

dn Especifica el identificador de registro asignado al usuario que seestá creando. Para poder crear una cuenta de usuario nueva debeconocerse el identificador de registro. El identificador de registrodebe ser único en el registro de usuarios.

cn Especifica el nombre común asignado al usuario que se estácreando.

sn Especifica el sobrenombre del usuario que se está creando.contraseña Especifica la contraseña establecida para el nuevo usuario. Las

contraseñas deben cumplir los requisitos de las políticas decontraseña establecidas por el administrador.

[grupos] Este argumento opcional especifica una lista de grupos a los que seha asignado al nuevo usuario. El formato de la lista de grupos esuna lista entre paréntesis de nombres de grupo separados porespacios.

DescripciónCrea un usuario en el registro de usuarios utilizado por Policy Server einicialmente asocia ese usuario a uno o más grupos. De forma predeterminada, lascuentas no son válidas cuando se crean.

Ejemplos1. En el ejemplo siguiente, que se ha entrado en una línea, se crea un nuevo

usuario:pdadmin> user create –gsouser dlucas “cn=Diana \Lucas,ou=Austin,o=Wesley Inc,c=US” “Diana Lucas” Lucas mi_contraseña

Para hacer que la cuenta del usuario sea válida, debe utilizar el comando usermodify para establecer el indicador account-valid en yes.

230 IBM Tivoli Access Manager Base: Guía del administrador

user delete

PropósitoSuprime el usuario y, opcionalmente, lo suprime del registro de usuarios.

Sintaxisuser delete [–registry] nombreusuario

Opciones[–registry] Esta opción hace que todo el objeto de usuario se suprima del

registro de usuarios.

nombreusuario Especifica el nombre de la cuenta que se ha de suprimir. Todas lascredenciales de recursos asociadas a una cuenta de usuario seeliminan automáticamente a la vez que se suprime la cuenta delusuario.

DescripciónSuprime la información del usuario del registro de usuarios. El parámetro -registryhace que todo el objeto de usuario se suprima del registro de usuarios. Si no seutiliza el parámetro -registry, la información del usuario que figura en el registropuede utilizarse para crear un usuario mediante el comando user import.

Ejemplos1. En el ejemplo siguiente se suprime la cuenta del usuario especificado:

pdadmin> user delete dlucas

Apéndice A. Comandos pdadmin 231

user import

PropósitoCrea un usuario importando uno existente del registro de usuarios.

Sintaxisuser import [–gsouser] nombreusuario dn

user import [–gsouser] nombreusuario dn [nombre_grupo]

Opciones[–gsouser] Cuando se especifica este argumento opcional, el usuario también

se convierte en un usuario de GSO (gsoUser).

nombreusuario Un nombre de usuario exclusivo. Este usuario se creará a partir deinformación que ya existe en el registro de usuarios.

dn El identificador de registro del usuario que se está importando.Este identificador debe existir en el registro de usuarios y no debeestar asociado a un usuario existente.

[nombre_grupo] Especifica el grupo al que se está asignando el usuario importado.

DescripciónCrea un usuario importando uno existente del registro de usuarios. De formapredeterminada, las cuentas de usuarios importados no son válidas cuando secrean. Para hacer que la cuenta del usuario sea válida, debe utilizar el comandouser modify para establecer el indicador account-valid en yes.

Ejemplos1. En el ejemplo siguiente, que se han entrado en una línea, se crea el usuario

″mlucas″ importando la información de usuario ″cn=MikeLucaser,ou=Austin,o=Wesley Inc, c=US″ que figura en el registro:pdadmin> user import –gsouser mlucaser “cn=Mike \Lucaser,ou=Austin,o=Wesley Inc,c=US”

232 IBM Tivoli Access Manager Base: Guía del administrador

user list

PropósitoProporciona una lista de usuarios ordenada por nombres de usuario.

Sintaxisuser list patrón máx_devueltas

user list-dn patrón máx_devueltas

Opcioneslist-dn Especifica el patrón para el nombre de principal. El patrón puede

incluir una combinación de caracteres comodín y constantes decadena, y es sensible a las mayúsculas y minúsculas (por ejemplo,*luca*). La lista devuelta son usuarios que están definidos en elregistro de usuarios pero no necesariamente usuarios de AccessManager. Los usuarios que no son de Access Manager puedenimportarse a Access Manager utilizando el comando user import.

patrón Especifica el patrón para el nombre de principal. El patrón puedeincluir una combinación de caracteres comodín y constantes decadena, y es sensible a las mayúsculas y minúsculas (por ejemplo,*luca*). Cuando se utiliza con el comando list-dn, el argumentoespecifica el patrón para la parte de nombre común (CN) delidentificador de registro del usuario (con la exclusión delcomponente ″cn=″).

máx_devueltas Especifica el número máximo de entradas que se han encontrado yse han devuelto en relación con una sola petición. Tenga en cuentaque el número devuelto también depende de la configuración delservidor (que especifica el número máximo de resultados quepueden devolverse como parte de una operación de búsqueda). Elnúmero máximo real de entradas devueltas es el mínimo demáx_devueltas y el valor configurado en el servidor.

DescripciónProporciona una lista de usuarios ordenada por nombres de usuario.

Ejemplos1. En el ejemplo siguiente se muestra una lista de usuarios que coinciden con el

patrón especificado:pdadmin> user list *luca* 2

La salida debería ser similar a:dlucasmlucaser

2. En el ejemplo siguiente se muestra una lista de usuarios que coinciden con elidentificador de registro especificado:pdadmin> user list-dn *luca* 2

La salida debería ser similar a:cn=Diana Lucas,ou=Austin,o=Wesley, Inc,c=UScn=Mike Lucaser,ou=Austin,o=Wesley, Inc,c=US

Apéndice A. Comandos pdadmin 233

user modify

PropósitoModifica distintos parámetros de la cuenta de usuario.

Sintaxisuser modify nombreusuario account-valid {yes|no}

user modify nombreusuario description descripción

user modify nombreusuario gsouser {yes|no}

user modify nombreusuario password contraseña

user modify nombreusuario password-valid {yes|no}

Opcionesnombreusuario Especifica el nombre de la cuenta que se ha de modificar.

account-valid {yes|no}Habilita o inhabilita la cuenta de usuario especificada.

description descripciónModifica la descripción del usuario.

gsouser {yes|no}Habilita o inhabilita las posibilidades de inicio de sesión único deun usuario.

password contraseñaModifica la contraseña del usuario. La nueva contraseña debecumplir los requisitos de las políticas de contraseña en vigor.

password-valid {yes|no}Valida o invalida la contraseña de la cuenta del usuario. Si seestablece el indicador password-valid en no se fuerza al usuario amodificar la contraseña en el siguiente intento de login.

Ejemplos1. En el ejemplo siguiente se habilita la cuenta de usuario especificada:

pdadmin> user modify dlucas account-valid yes

2. En el ejemplo siguiente se modifica la descripción de una cuenta de usuario:pdadmin> user modify dlucas description “Diana Lucas, Credit Dept HCUS”

3. En el ejemplo siguiente se elimina un usuario como usuario de GSO.pdadmin> user modify dlucas gsouser no

4. En el ejemplo siguiente se modifica la contraseña para una cuenta de usuario:pdadmin> user modify dlucas password newpasswd

5. En el ejemplo siguiente se inactiva la contraseña de un usuario, con lo que se lefuerza a modificarla cuando vuelva a efectuar un inicio de sesión.pdadmin> user modify dlucas password-valid no

234 IBM Tivoli Access Manager Base: Guía del administrador

user show

PropósitoMuestra las propiedades del usuario especificado.

Sintaxisuser show nombreusuario

user show-groups nombreusuario

user show-dn dn

Opcionesnombreusuario Especifica el nombre del usuario que se ha de mostrar.

show-groups nombreusuarioMuestra los grupos de los que el usuario especificado es miembro.

show-dn dn Muestra el usuario especificado por el identificador del usuario delregistro de usuarios. El usuario devuelto está definido en elregistro de usuarios pero no es necesariamente un usuario deAccess Manager. Los usuarios que no son de Access Managerpueden importarse a Access Manager utilizando el comando userimport.

Ejemplos1. En el ejemplo siguiente se muestra la información de cuenta de usuario para el

usuario especificado:pdadmin> user show dlucas

La salida debería ser similar a:ID de inicio de sesión: dlucasDN de LDAP: cn=Diana Lucas,ou=Austin,o=Wesley Inc,c=USCN de LDAP: Diana LucasSN de LDAP: LucasDescripción: Diana Lucas, Credit Dept HCUSEs SecUser: trueEs usuario de GSO: falseCuenta válida: trueContraseña válida: trueMecanismo de autenticación: Default:LDAP

2. En el ejemplo siguiente se muestra los grupos de los que el usuarioespecificado es miembro.pdadmin> user show-groups dlucas

La salida debería ser similar a:salescreditengineering

3. En el ejemplo siguiente se proporciona información adicional sobre el usuariocuando se especifica el identificador de registro:pdadmin> user show-dn “cn=Diana Lucas,ou=Austin,o=Wesley Inc,c=US”

Apéndice A. Comandos pdadmin 235

La salida debería ser similar a:ID de inicio de sesión: dlucasDN de LDAP: cn=Diana Lucas,ou=Austin,o=WesleyInc,c=USCN de LDAP: Diana LucasSN de LDAP: LucasDescripción: Diana Lucas, Credit Dept HCUSEs SecUser: trueEs usuario de GSO: falseCuenta válida: trueContraseña válida: trueMecanismo de autenticación: Default:LDAP

236 IBM Tivoli Access Manager Base: Guía del administrador

Apéndice B. Información de consulta de wivmgrd.conf

Archivo de configuración ivmgrd.conf para Policy Server (pdmgrd).

Stanzas:v [ivmgrd]

v [ldap]

v [ssl]

v [authentication-mechanisms]

v [object-spaces]

v [aznapi-configuration]

v [aznapi-entitlement-services]

v [aznapi-pac-services]

v [aznapi-cred-modification-services]

v [aznapi-external-authzn-services]

v [delegated-admin]

Parámetro Descripción

Stanza [ivmrgd]

unix-user Cuenta de usuario de UNIX para este servidor.

unix-group Cuenta de grupo de UNIX para este servidor.

database-path Ubicación de la base de datos maestra deautorizaciones.

tcp-req-port Puerto de escucha para las peticiones de entrada.

max-notifier-threads Número máximo de threads de notificador de eventos.

auto-database-update-notify Habilita la notificación de actualización automática omanual para las réplicas de base de datos deautorizaciones.

notifier-wait-time Tiempo (en segundos) que la base de datos de políticasde autorización está desocupada antes de que se envíeuna notificación a las réplicas.

pid-file Ubicación del archivo PID.

log-file Ubicación del archivo de registro.

ca-cert-download-enabled Permite a clientes descargar el certificado raíz de CA.

Stanza [ldap]

ldap-server-config Ubicación del archivo de configuración ldap.conf.

prefer-readwrite-server Habilita e inhabilita la opción que permite al clienteconsultar el servidor LDAP de lectura/escritura antesde consultar cualquier servidor de sólo lectura deréplicas configurado en el dominio.

bind-dn El DN de usuario de LDAP utilizado cuando se efectúaun enlace con el servidor LDAP.

bind-pwd La contraseña de usuario de LDAP.

ssl-enabled Habilita e inhabilita la comunicación SSL con elservidor LDAP.

237

Parámetro Descripción

ssl-keyfile Ubicación del archivo de claves SSL utilizado paramanejar certificados utilizados en la comunicaciónLDAP.

ssl-keyfile-dn Etiqueta de certificado del archivo de claves SSL.

ssl-keyfile-pwd Contraseña del archivo de claves SSL.

auth-using-compare Determine si se utiliza ldap_compare() en lugar de lallamada ldap_bind() para autenticar usuarios de LDAP.

Stanza [ssl]

ssl-keyfile Ubicación del archivo de claves SSL.

ssl-keyfile-pwd Contraseña utilizada para proteger claves privadas enel archivo de claves.

ssl-keyfile-stash Ubicación del archivo stash de contraseñas SSL.

ssl-keyfile-label Etiqueta de clave que se ha de utilizar en lugar de lapredeterminada.

ssl-v3-timeout Tiempo de espera de la sesión para las conexiones v3de SSL.

ssl-listening-port Puerto de escucha TCP para peticiones MTS deentrada.

ssl-io-inactivity-timeout La duración (en segundos) que una conexión de SSLespera una respuesta antes de que se exceda el tiempode espera.

ssl-maximum-worker-threads Número máximo de threads creados por el servidorpara manejar peticiones de entrada.

ssl-pwd-life Duración, en días, de la contraseña SSL.

ssl-cert-life Duración, en días, del certificado SSL.

ssl-auto-refresh Habilita e inhabilita la renovación automática delcertificado SSL y la contraseña del archivo de base dedatos de claves. Si este parámetro está habilitado, elcertificado y la contraseña se vuelven a generar cuandoestán a punto de caducar.

Stanza [authentication-mechanisms]

passwd-uraf Biblioteca que se ha de utilizar para tareas deautenticación.

cert-uraf Biblioteca que se ha de utilizar para tareas deautenticación.

passwd-ldap Biblioteca que se ha de utilizar para tareas deautenticación.

cert-ldap Biblioteca que se ha de utilizar para tareas deautenticación.

Stanza [aznapi-configuration]

logsize Umbral de creación de un nuevo archivo de registropara registros de auditoría.

logflush Frecuencia de vaciado de los búferes de archivos deregistro para registros de auditoría.

logaudit Habilita e inhabilita la realización de auditorías.

auditlog Ubicación del archivo de seguimiento de auditoría.

auditcfg = azn Captura eventos de autorización.

238 IBM Tivoli Access Manager Base: Guía del administrador

Parámetro Descripción

auditcfg = authn Captura eventos de autenticación.

auditcfg = mgmt Captura eventos de autenticación.

Stanza [aznapi-entitlement-services]

Stanza [aznapi-pac-services]

Stanza [aznapi-cred-modification-services]

Stanza [aznapi-external-authzn-services]

Stanza [delegated-admin]

authorize-group-list Habilita e inhabilita comprobaciones de autorización enlos comandos group list y group list-dn.

Apéndice B. Información de consulta de wivmgrd.conf 239

240 IBM Tivoli Access Manager Base: Guía del administrador

Apéndice C. Información de consulta de ivacld.conf

Archivo de configuración ivacld.conf para Authorization Server (pdacld).

Stanzas:v [ivacld]v [ldap]v [ssl]v [manager]v [authentication-mechanisms]v [aznapi-configuration]v [aznapi-entitlement-services]v [aznapi-pac-services]v [aznapi-cred-modification-services]v [aznapi-admin-services]

Parámetro Descripción

Stanza [ivacld]

tcp-req-port Puerto de escucha TCP para las peticiones de entrada.

pid-file Ubicación del archivo PID.

log-file Ubicación del archivo de registro.

unix-user Cuenta de usuario de UNIX para este servidor.

unix-group Cuenta de grupo de UNIX para este servidor.

permit-unauth-remote-caller Especifica si Authorization Server debe autorizar a clientesAPI de autorización antes de que se procesen suspeticiones.

Stanza [ldap]

enabled Habilita e inhabilita el soporte de registro de usuario deLDAP.

host Nombre de host del servidor LDAP.

port El puerto IP utilizado cuando se efectúa un enlace con elservidor LDAP.

bind-dn El DN de usuario de LDAP utilizado cuando se efectúa unenlace con el servidor LDAP.

bind-pwd La contraseña de usuario de LDAP.

cache-enabled Habilita e inhabilita el almacenamiento en caché de clienteLDAP para mejorar el rendimiento para consultas LDAPsimilares.

prefer-readwrite-server Habilita e inhabilita la opción que permite al clienteconsultar el servidor LDAP de lectura/escritura antes deconsultar cualquier servidor de sólo lectura de réplicasconfigurado en el dominio.

ssl-enabled Habilita e inhabilita la comunicación SSL con el servidorLDAP.

241

Parámetro Descripción

ssl-keyfile Ubicación del archivo de claves SSL utilizado para manejarcertificados utilizados en la comunicación LDAP.

ssl-keyfile-dn Etiqueta de certificado del archivo de claves SSL.

ssl-keyfile-pwd Contraseña del archivo de claves SSL.

max-search-size Tamaño máximo del búfer de búsqueda devuelto por elservidor LDAP en entradas.

ssl-port Puerto de escucha SSL en una comunicación LDAP.

auth-using-compare Determine si se utiliza ldap_compare() en lugar de lallamada ldap_bind() para autenticar usuarios de LDAP.

ldap-replica Define las réplicas de registro de usuario de LDAP en eldominio.

Stanza [ssl]

ssl-keyfile Ubicación del archivo de claves SSL.

ssl-keyfile-pwd Contraseña utilizada para proteger claves privadas en elarchivo de claves.

ssl-keyfile-stash Ubicación del archivo stash de contraseñas SSL.

ssl-keyfile-label Etiqueta de clave que se ha de utilizar en lugar de lapredeterminada.

ssl-v3-timeout Tiempo de espera de la sesión para las conexiones v3 deSSL.

ssl-listening-port Puerto de escucha TCP para peticiones MTS de entrada.

ssl-io-inactivity-timeout La duración (en segundos) que una conexión de SSL esperauna respuesta antes de que se exceda el tiempo de espera.

ssl-maximum-worker-threads Número máximo de threads creados por el servidor paramanejar peticiones de entrada.

ssl-pwd-life Duración, en días, de la contraseña SSL.

ssl-cert-life Duración, en días, del certificado SSL.

ssl-auto-refresh Habilita e inhabilita la renovación automática delcertificado SSL y la contraseña del archivo de base de datosde claves. Si este parámetro está habilitado, el certificado yla contraseña se vuelven a generar cuando están a punto decaducar.

ssl-authn-type Tipo de autenticación.

Stanza [manager]

manager-host Nombre del servidor MTS.

master-port El puerto TCP en el que el servidor escucha peticiones.

master-dn El nombre distinguido esperado del certificado presentadopor el servidor MTS.

Stanza [authentication-mechanisms]

passwd-uraf Biblioteca que se ha de utilizar para tareas de autenticación.

cert-uraf Biblioteca que se ha de utilizar para tareas de autenticación.

passwd-ldap Biblioteca que se ha de utilizar para tareas de autenticación.

cert-ldap Biblioteca que se ha de utilizar para tareas de autenticación.

Stanza [aznapi-configuration]

242 IBM Tivoli Access Manager Base: Guía del administrador

Parámetro Descripción

logsize Umbral de creación de un nuevo archivo de registro pararegistros de auditoría.

logflush Frecuencia de vaciado de los búferes de archivos de registropara registros de auditoría.

logaudit Habilita e inhabilita la realización de auditorías.

auditlog Ubicación del archivo de seguimiento de auditoría delcliente local.

auditcfg = azn Captura eventos de autorización.

auditcfg = authn Captura eventos de autenticación.

db-file Ubicación del archivo caché de base de datos de pdacld.

cache-refresh-interval Intervalo entre las comprobaciones de actualizaciones en elservidor maestro de autorizaciones.

permission-info-returned

max-handle-groups Número máximo de grupos para procesar que se han deasignar.

listen-flags Habilita e inhabilita la recepción de notificaciones deactualización de caché de políticas.

Stanza [aznapi-entitlement-services]

Define los servicios API de autorización.

Stanza [aznapi-pac-services]

AZN_V37CRED_SVC Servicio para efectuar conversiones entre credenciales deTivoli SecureWay Policy Director Versión 3.7 y de TivoliSecureWay Policy Director Versión 3.8. Soporta peticionesde autorización remota de aplicaciones API de autorizaciónde Tivoli SecureWay Policy Director Versión 3.7.

Stanza [aznapi-cred-modification-services]

AZN_MOD_SVC_RAD_2AB Servicio de modificación de credenciales que permite agrupos agregarse dinámicamente a una credencial existente.Esta acción puede proporcionar al propietario de lacredencial mayores posibilidades de autorización.

Stanza [aznapi-admin-services]

AZN_ADMIN_SVC_TRACE Habilita e inhabilita (utilizando pdadmin) la administraciónde rastreo para una aplicación API de autorización.

Apéndice C. Información de consulta de ivacld.conf 243

244 IBM Tivoli Access Manager Base: Guía del administrador

Apéndice D. Información de consulta de ldap.conf

Stanzas:v [ldap]

Parámetro Descripción

Stanza [ldap]

enabled Access Manager utiliza un registro de usuario LDAP. Los valores sonyes y no.

host El nombre de la red de la máquina donde se encuentra el servidormaestro LDAP.

port El puerto de escucha TCP del servidor maestro LDAP.

ssl-port El puerto de escucha SSL del servidor maestro LDAP.

max-search-size El límite de Access Manager que un cliente LDAP puede utilizar parabuscar elementos de base de datos -como una petición a Web PortalManager para que liste usuarios de la base de datos LDAP.

replica Entrada del servidor LDAP de réplicas.

245

246 IBM Tivoli Access Manager Base: Guía del administrador

Apéndice E. Información de consulta de pd.conf

Archivo de configuración pd.conf.

Stanzas:v [pdrte]v [ssl]v [manager]v [ldap-ext-cred-tags]

Parámetro Descripción

Stanza [pdrte]

configured Indica si se ha configurado el paquete Access ManagerRuntime.

user-reg-type Tipo de registro de usuarios. (Actualmente sólo se soportaLDAP).

user-reg-server Nombre del servidor de registro de usuarios.

user-reg-host Nombre del host de registro de usuarios.

user-reg-hostport Número de puerto del servidor de registro de usuarios.

boot-start-ivmgrd Inicia Policy Server (pdmgrd) al reiniciar el sistema.

boot-start-ivacld Inicia Authorization Server (pdacld) al reiniciar el sistema.

Stanza [ssl]

ssl-keyfile Ubicación del sistema local en el que se encuentra elarchivo de claves SSL.

ssl-keyfile-pwd Contraseña del archivo de claves.

ssl-keyfile-stash Ubicación del archivo stash de contraseñas SSL.

ssl-keyfile-label Nombre del certificado que se ha de utilizar en lugar delpredeterminado.

ssl-v3-timeout Tiempo de espera del ID de sesión para las conexiones v3de SSL.

ssl-pwd-life Duración, en días, de la contraseña SSL.

ssl-io-inactivity-timeout La duración (en segundos) que una conexión de SSL esperauna respuesta antes de que se exceda el tiempo de espera.

ssl-auto-refresh Habilita o inhabilita la renovación automática decertificados y contraseñas de la base de datos de claves.

Stanza [manager]

master-host Nombre del host del servidor MTS.

master-port Número de puerto TCP en el que el servidor escuchapeticiones.

replica Réplicas de Authorization Server.

Stanza [ldap-ext-cred-tags]

credential-field-name =ldap-inetOrgPerson-field

Mecanismo para agregar atributos ampliados a la credencialde Access Manager desde campos existentes en el objeto declase inetOrgPerson de LDAP.

247

248 IBM Tivoli Access Manager Base: Guía del administrador

Apéndice F. Comandos de configuración de SSL

Este apéndice contiene una lista ordenada alfabéticamente de los comandosrelacionados con la configuración de Secure Sockets Layer (SSL).

Los parámetros de los comandos dependen de la acción que se esté llevando acabo. Los parámetros pueden especificarse en cualquier orden.

Sintaxis de comandosLos comandos en este apéndice utilizan los siguientes caracteres especiales paradefinir sintaxis de comandos:

[ ] Identifica elementos opcionales. Los que no están entre corchetes sonnecesarios.

... Indica que puede especificar múltiples valores para el elemento anterior. Amenos que la información del comando indique lo contrario, separe estosvalores con un espacio.

Si la elipsis de un elemento figura a continuación de un corchete final,utilice la sintaxis que hay entre los corchetes para especificar múltiplesvalores. Por ejemplo, para especificar dos administradores para la opción[–a admin]..., utilice –a admin1 –a admin2.

Si la elipsis de un elemento está dentro de los corchetes, utilice la sintaxisdel último elemento para especificar múltiples valores. Por ejemplo, paraespecificar dos hosts para la opción [–h host...], use –h host1 host2.

| Indica información que se excluye mutuamente. Puede utilizar el elementoque está en la izquierda o en la derecha de la barra vertical.

{ } Delimita un conjunto de elementos que se excluyen mutuamente cuandouno de ellos es necesario. Si los elementos son opcionales, aparecen entrecorchetes ([ ]).

249

bassslcfg –chgpwd

FinalidadCambia la contraseña de la base de datos de claves. Se genera un nueva contraseñaaleatoria y se guarda en el archivo stash.

Sintaxisbassslcfg –chgpwd –e duración_contraseña

Opciones–e duración_contraseña

Establece la duración, en días, de la contraseña del archivo deconjunto de claves. Puede especificar un valor deduración_contraseña de 1 a 7200 (días). Para utilizar el valorconfigurado actualmente, especifique 0. Si no puede determinar elvalor configurado actualmente, especifique 183.

250 IBM Tivoli Access Manager Base: Guía del administrador

bassslcfg –config

FinalidadConfigura Access Manager Runtime de manera que el programa de utilidadpdadmin pueda establecer comunicación con Policy Server. También crea nuevosarchivos stash y de claves.

Sintaxisbassslcfg –config –c archivo_cert –h nombre_host [–p puerto_servidor] [–earchivo_contraseña] [–t tiempo_espera_ssl]

Opciones–c archivo_cert Especifica el nombre del certificado Policy Server firmado

automáticamente y codificado en base64.

–h nombre_host Especifica el nombre de host de TCP de Policy Server.

[–p puerto_servidor]Especifica el número de puerto de escucha de Policy Server. Elvalor predeterminado es 7135.

[–e duración_contraseña]Establece la duración, en días, de la contraseña del archivo deconjunto de claves. Puede especificar un valor deduración_contraseña de 1 a 7200 (días). El valor predeterminado es183. Para utilizar el valor configurado actualmente, especifique 0.

[–t tiempo_espera_ssl]Especifica el tiempo de espera, en segundos, de la sesión de SSL.Puede especificar un valor de tiempo_espera_ssl de1 a 86400(segundos). El valor predeterminado es 7200.

Apéndice F. Comandos de configuración de SSL 251

bassslcfg –getcacert

FinalidadDescarga el certificado raíz de CA en un archivo.

Sintaxisbassslcfg –getcacert –c archivo_cert –h nombre_host [–p puerto_servidor]

Opciones–c archivo_cert Especifica el nombre del certificado Policy Server firmado

automáticamente y codificado en base64.

–h nombre_host Especifica el nombre de host de TCP de Policy Server.

[–p puerto_servidor]Especifica el número de puerto de escucha de Policy Server. Elvalor predeterminado es 7135.

252 IBM Tivoli Access Manager Base: Guía del administrador

bassslcfg –modify

FinalidadModifica la configuración de Access Manager Policy Server.

Sintaxisbassslcfg –modify [–h nombre_host] [–e archivo_contraseña] [–p puerto_servidor] [–ttiempo_espera_ssl]

Opciones[–h nombre_host]

Especifica el nombre de host de TCP de Policy Server.

[–e duración_contraseña]Establece la duración, en días, de la contraseña del archivo deconjunto de claves. Puede especificar un valor deduración_contraseña de 1 a 7200 (días). El valor predeterminado es183. Para utilizar el valor configurado actualmente, especifique 0.

[–p puerto_servidor]Especifica el número de puerto de escucha de Policy Server.

[–t tiempo_espera_ssl]Especifica el tiempo de espera, en segundos, de la sesión de SSL.Puede especificar un valor de tiempo_espera_ssl de1 a 86400(segundos). El valor predeterminado es 7200.

Apéndice F. Comandos de configuración de SSL 253

bassslcfg –ping

FinalidadRealiza un ping al servidor de Access Manager.

Sintaxisbassslcfg –ping –h nombre_host [–p puerto_servidor]

Opciones–h nombre_host Especifica el nombre de host de TCP de Policy Server.

[–p puerto_servidor]Especifica el número de puerto de escucha del servidor de AccessManager al que desea realizar un ping. El valor predeterminado es7135.

254 IBM Tivoli Access Manager Base: Guía del administrador

mgrsslcfg –chgcert

FinalidadRenueva el certificado SSL del gestor. En la base de datos de claves se crea yalmacena un nuevo par de clave pública-clave privada y un certificado.

Sintaxismgrsslcfg –chgcert –l duración_cert

Opciones–l duración_cert

Establece la duración, en días, del certificado. Puede especificar unvalor de duración_cert de 1 a 7300 (días). El valor predeterminadoes 365. Para utilizar el valor configurado actualmente, especifique0.

Apéndice F. Comandos de configuración de SSL 255

mgrsslcfg –chgpwd

FinalidadCambia la contraseña de la base de datos de claves. Se genera un nueva contraseñaaleatoria y se guarda en el archivo stash.

Sintaxismgrsslcfg –chgpwd –e duración_contraseña

Opciones–e duración_contraseña

Establece la duración, en días, de la contraseña del archivo deconjunto de claves. Puede especificar un valor deduración_contraseña de 1 a 7200 (días). Para utilizar el valorconfigurado actualmente, especifique 0. Si no puede determinar elvalor configurado actualmente, especifique 183.

256 IBM Tivoli Access Manager Base: Guía del administrador

mgrsslcfg –config

FinalidadLleva a cabo una configuración completa, creando nuevos archivos stash y de clavey generando nuevos certificados.

Sintaxismgrsslcfg –config [–e duración_contraseña] [–l duración_cert] [–t tiempo_espera_ssl][–D {yes|no}]

Opciones[–e duración_contraseña]

Establece la duración, en días, de la contraseña del archivo deconjunto de claves. El valor de duración_contraseña puede ser de 1 a7200 (días). Para utilizar el valor configurado actualmente,especifique 0. Si no puede determinar el valor configuradoactualmente, especifique 183.

[–l duración_cert]Establece la duración, en días, del certificado. Puede especificar unvalor de duración_cert de 1 a 7300 (días). El valor predeterminadoes 365.

[–t tiempo_espera_ssl]Especifica el tiempo de espera, en segundos, de la sesión de SSL.Puede especificar un valor de tiempo_espera_ssl de1 a 86400(segundos). El valor predeterminado es 7200.

[–D {yes|no}] Especifique yes para habilitar la descarga del certificado CA deldominio seguro. Si especifica no, debe transferir manualmente elarchivo pdcacert.b64 a hosts subsiguientes para configurar AccessManager Runtime. El valor predeterminado es no.

Apéndice F. Comandos de configuración de SSL 257

mgrsslcfg –modify

FinalidadModifica la configuración actual.

Sintaxismgrsslcfg –modify [–e duración_contraseña] [–l duración_cert] [–t tiempo_espera_ssl][–D {yes|no}]

Opciones–e duración_contraseña

Establece la duración, en días, de la contraseña del archivo deconjunto de claves. El valor de duración_contraseña puede ser de 1 a7200 (días). Para utilizar el valor configurado actualmente,especifique 0. Si no puede determinar el valor configuradoactualmente, especifique 183.

[–l duración_cert]Establece la duración, en días, del certificado. Esta opción no esnecesaria con la acción –config y, si no se especifica, toma utiliza365 días de forma predeterminada.

[–t tiempo_espera_ssl]Especifica el tiempo de espera, en segundos, de la sesión de SSL. Elvalor tiempo_espera_ssl debe estar en el rango de 1– a 86400. Elvalor predeterminado es 7200.

[–D {yes|no}] Habilita la descarga del certificado CA del seguro dominio. Siespecifica no, debe transferir manualmente el archivo pdcacert.b64a hosts subsiguientes para configurar Access Manager Runtime enellos. En la configuración inicial, el valor predeterminado es no.

258 IBM Tivoli Access Manager Base: Guía del administrador

svrsslcfg –add_replica

FinalidadAgrega una réplica de base de datos.

Sintaxissvrsslcfg –add_replica –f archivo_config –h nombre_host [–p puerto_servidor] [–krango_réplica]

Opciones–f archivo_config

Especifica el nombre y la ruta de acceso del archivo deconfiguración.

–h nombre_host Especifica el nombre del host de TCP de un servidor replicadoivacld.

[–p puerto_servidor]Especifica el número del puerto de escucha del servidor replicadoivacld. Es el número de puerto en el que ivacld escucha peticiones.El valor predeterminado es 7136.

[–k rango_réplica]Especifica el orden de preferencia de una réplica entre otrasréplicas. El valor predeterminado es 10.

Apéndice F. Comandos de configuración de SSL 259

svrsslcfg –chg_replica

FinalidadCambia las opciones de réplica. El nombre de host de la réplica se utiliza paraidentificar la réplica y esta acción no puede modificarlo.

Sintaxissvrsslcfg –chg_replica –f archivo_config –h nombre_host [–p puerto_servidor] [–krango_réplica]

Opciones–f archivo_config

Especifica el nombre y la ruta de acceso del archivo deconfiguración.

–h nombre_host Especifica el nombre del host de TCP de un servidor replicadoivacld.

[–p puerto_servidor]Especifica el número del puerto de escucha del servidor replicadoivacld. Es el número de puerto en el que ivacld escucha peticiones.Si no se especifica en una acción –add_replica, se utiliza el valorpredeterminado 7136.

[–k rango_réplica]Especifica el orden de preferencia de una réplica entre otrasréplicas. El valor predeterminado es 10.

260 IBM Tivoli Access Manager Base: Guía del administrador

svrsslcfg –chgcert

FinalidadRenueva el certificado SSL del servidor.

Sintaxissvrsslcfg –chgcert –f archivo_config –n nombre_servidor [–P contraseña_admin] [–Aid_admin]

Opciones–f archivo_config

Especifica el nombre y la ruta de acceso del archivo deconfiguración.

–n nombre_servidorEspecifica el nombre del servidor. Puede especificarse comonombre_servidor/nombre de host o nombre_servidor, en cuyo casoel nombre de host local se agregará para formar nombre/nombrede host. Tenga en cuenta que los nombres ivacld, secmgrd, ivnet yivweb están reservados para servidores de Access Manager.

[–P contraseña_admin]Especifica la contraseña de administrador de Access Manager. Si nose especifica esta opción, la contraseña se lee de la entradaestándar.

[–A id_admin] Especifica el nombre de administrador de Access Manager. El valorpredeterminado es sec_master.

Apéndice F. Comandos de configuración de SSL 261

svrsslcfg –chgport

FinalidadCambia el número de puerto de escucha.

Sintaxissvrsslcfg –chgport –f archivo_config –r número_puerto

Opciones–f archivo_config

Especifica el nombre y la ruta de acceso del archivo deconfiguración.

–r número_puertoEstablece el número de puerto de escucha para el servidor. Puedeespecificarse el valor 0 sólo si la stanza [aznapi-admin-services]del archivo de configuración está vacía.

262 IBM Tivoli Access Manager Base: Guía del administrador

svrsslcfg –chgpwd

FinalidadCambia la contraseña del archivo de conjunto de claves.

Sintaxissvrsslcfg –chgpwd –f archivo_config –e duración_contraseña

Opciones–f archivo_config

Especifica el nombre y la ruta de acceso del archivo deconfiguración.

–e duración_contraseñaEstablece la duración, en días, de la contraseña del archivo deconjunto de claves. El valor de duración_contraseña puede ser de 1 a7200 (días). El valor predeterminado es 183. Para utilizar el valorconfigurado actualmente, especifique 0.

Apéndice F. Comandos de configuración de SSL 263

svrsslcfg –config

FinalidadCambia la contraseña del archivo de conjunto de claves.

Sintaxissvrsslcfg –config –f archivo_config –d dir_kdb –n nombre_servidor –s tipo_servidor –rnúmero_puerto –P contraseña_admin [–S contraseña_servidor] [–A id_admin] [–ttiempo_espera_ssl] [–e duración_contraseña] [–l modalidad_escucha] [–amodalidad_actualización] [–C archivo_cert] [–h nombre_host]

Opciones–f archivo_config

Especifica el nombre y la ruta de acceso del archivo deconfiguración.

–d dir_kdb Especifica el directorio que contiene los archivos de base de datosdel conjunto de claves para el servidor.

–n nombre_servidorEspecifica el nombre del servidor. Puede especificarse comonombre_servidor/nombre de host o nombre_servidor, en cuyo casoel nombre de host local se agregará para formar nombre/nombrede host. Tenga en cuenta que los nombres ivacld, secmgrd, ivnet yivweb están reservados para servidores de Access Manager.

–s tipo_servidor Especifica el tipo de servidor que se está configurando. El valorpuede ser local o remoto.

–r número_puertoEstablece el número de puerto de escucha para el servidor. Estaopción es necesaria. Puede especificarse el valor 0 sólo si la stanza[aznapi-admin-services] del archivo de configuración está vacía.

–P contraseña_adminEspecifica la contraseña de administrador de Access Manager. Estaopción es necesaria. Si no se especifica esta opción, la contraseña selee de la entrada estándar.

[–S contraseña_servidor]Especifica la contraseña del servidor. Esta opción es necesaria. Sinembargo, puede pedir al sistema que cree una contraseñaespecificando una raya (-) para la contraseña. Si se utiliza estaopción, el archivo de configuración se actualiza con la contraseñaque el sistema ha creado. Si el tipo de registro de usuario es LDAPy se especifica una contraseña, se guarda en el archivo deconfiguración. Si no se especifica esta opción, la contraseña se leede la entrada estándar.

[–A id_admin] Especifica el nombre de administrador de Access Manager. Si no seespecifica esta opción, se utiliza sec_master de formapredeterminada.

[–t tiempo_espera_ssl]Especifica el tiempo de espera, en segundos, de la sesión de SSL. Elvalor tiempo_espera_ssl debe estar en el rango de 1– a 86400. Elvalor predeterminado es 7200.

264 IBM Tivoli Access Manager Base: Guía del administrador

[–e duración_contraseña]Establece la duración, en días, de la contraseña del archivo deconjunto de claves. El valor de duración_contraseña puede ser de 1 a7200 (días). Para utilizar el valor configurado actualmente,especifique 0. Si no puede determinar el valor configuradoactualmente, especifique 183.

[–l modalidad_escucha]Establece el indicador de escucha habilitada en el archivo deconfiguración. El valor de esta opción debe ser yes o no. Si no seespecifica, el valor predeterminado es no. Cuando se utiliza con laacción –config, el valor yes requiere que la opción –r no sea cero.Cuando se utiliza con la acción –modify, el valor yes requiere queel número de puerto de escucha en el archivo de configuración nosea cero.

[–a modalidad_actualización]Establece el indicador de actualización automática habilitada parael certificado y la contraseña del archivo de conjunto de claves enel archivo de configuración. El valor de esta opción debe ser yes ono. Si no se especifica, el valor predeterminado es yes.

[–C archivo_cert]Especifica el nombre completo del archivo que contiene elcertificado SSL codificado en base-64 que se utiliza cuando elservidor autentica directamente con el registro de usuarios.

[–h nombre_host]Especifica el nombre de host de TCP de Policy Server. Cuando seutiliza con la acción –config, este nombre se guarda en el archivode configuración utilizando la clave azn-app-host. No se utilizapara objetos de servidor de nombres.

Apéndice F. Comandos de configuración de SSL 265

svrsslcfg –modify

FinalidadModifica la configuración actual.

Sintaxissvrsslcfg –config –f archivo_config [–t tiempo_espera_ssl] [–C archivo_cert] [–lmodalidad_escucha]

Opciones–f archivo_config

Especifica el nombre y la ruta de acceso del archivo deconfiguración.

[–t tiempo_espera_ssl]Especifica el tiempo de espera, en segundos, de la sesión de SSL. Elvalor tiempo_espera_ssl debe estar en el rango de 1– a 86400. Elvalor predeterminado es 7200.

[–C archivo_cert]Especifica el nombre completo del archivo que contiene elcertificado SSL codificado en base-64 que se utiliza cuando elservidor autentica directamente con el registro de usuarios.

[–l modalidad_escucha]Establece el indicador de escucha habilitada en el archivo deconfiguración. Los valores son yes y no. El valor predeterminadoes no. El valor yes requiere que el número de puerto de escucha enel archivo de configuración no sea cero.

266 IBM Tivoli Access Manager Base: Guía del administrador

svrsslcfg –rmv_replica

FinalidadElimina una configuración de réplica.

Sintaxissvrsslcfg –rmv_replica –f archivo_config –h nombre_host

Opciones–f archivo_config

Especifica el nombre y la ruta de acceso del archivo deconfiguración.

–h nombre_host Especifica el nombre del host de TCP de un servidor replicadoivacld.

Apéndice F. Comandos de configuración de SSL 267

svrsslcfg –unconfig

FinalidadDesconfigura el servidor. Se suprimen los archivos de conjunto de claves y seelimina el servidor del registro de usuarios y de la base de datos de AccessManager.

Sintaxissvrsslcfg –unconfig –f archivo_config –n nombre_servidor [–P contraseña_admin] [–Aid_admin]

Opciones–f archivo_config

Especifica el nombre y la ruta de acceso del archivo deconfiguración.

–n nombre_servidorEspecifica el nombre del servidor. Puede especificarse comonombre_servidor/nombre de host o nombre_servidor, en cuyo casoel nombre de host local se agregará para formar nombre/nombrede host. Tenga en cuenta que los nombres de servidor ivacld,secmgrd, ivnet y ivweb están reservados para servidores de AccessManager.

[–P contraseña_admin]Especifica la contraseña de administrador de Access Manager. Si nose especifica esta opción, la contraseña se lee de la entradaestándar (stdin).

[–A id_admin] Especifica el nombre de administrador de Access Manager. El valorpredeterminado es sec_master.

268 IBM Tivoli Access Manager Base: Guía del administrador

Apéndice G. Diferencias entre registros de usuarios

En esta versión de IBM Tivoli Access Manager (Access Manager) existen lassiguientes diferencias entre registros de usuarios.1. Los blancos iniciales y finales en nombres de usuario y de grupo no se tienen

en cuenta cuando se utiliza LDAP o Microsoft Active Directory como el registrode usuarios en un dominio seguro de Access Manager para e-business. Sinembargo, cuando se utiliza un servidor de Lotus Domino como el registro deusuarios, los blancos iniciales y finales son significativos. Para asegurarse deque el proceso sea coherente independientemente de qué registro de usuarios seesté utilizando, defina usuarios y grupos en el registro de usuarios cuyosnombres no contienen blancos iniciales y finales.

2. No debe utilizarse el carácter de barra inclinada (/) en nombres de usuario y degrupo definidos utilizando cadenas de nombres distinguidos. El carácter debarra inclinada no se utiliza de la misma manera en todos los registros deusuarios.

Servidor de Lotus DominoNo se pueden crear usuarios y grupos con nombres que utilizan unacadena de nombre distinguido que contiene un carácter de barrainclinada. Para evitar este problema, no utilice ningún carácter de barrainclinada o defina el usuario sin el nombre distinguido:pdadmin user create myuser username/locinfo test test testpwd

en lugar de:pdadmin user create myuser cn=username/o=locinfo test test testpwd

Microsoft Active DirectorySe pueden crear usuarios y grupos con nombres que utilizan unacadena de nombre distinguido que contiene un carácter de barrainclinada. Sin embargo, las siguientes operaciones en el objeto podríanser incorrectas ya que algunas funciones de Active Directory interpretanel carácter de barra inclinada como un separador entre el nombre delobjeto y el nombre del host. Para evitar este problema, no utiliceningún carácter de barra inclinada para definir el usuario.

3. Cuando se utiliza un registro de usuarios de Microsoft Active Directory demúltiples dominios, se pueden definir varios usuarios y grupos con el mismonombre abreviado siempre y cuando residan en dominios diferentes. Paraconsultar información asociada a un usuario o grupo específico, utilice elnombre completo, incluido el dominio, del usuario o del grupo para tener lacerteza de que obtiene la información correcta. Si omite la información deldominio, se devuelve la información sobre el usuario o el grupo definido en eldominio predeterminado, que podría no ser la correspondiente al usuario ogrupo que desea. Por el mismo motivo no debe utilizarse únicamente elnombre abreviado para identificar a un usuario o a un grupo.

4. Si se utiliza iPlanet Versión 5.0 como el registro de usuarios, un usuario que sehaya creado, agregado a un grupo y, a continuación, suprimido del registro deusuarios sigue siendo miembro del grupo. Si más adelante se crea un usuariocon el mismo nombre, este nuevo usuario hereda automáticamente lascaracterísticas de miembro del antiguo grupo y se le podrían conceder permisos

269

inadecuados. Se recomienda encarecidamente eliminar el usuario de todos losgrupos antes de suprimirlo. Este problema no se produce cuando se utilizan losotros registros de usuarios soportados.

5. El resultado de agregar un usuario duplicado a un grupo es diferente según elregistro de usuarios que se esté utilizando. La Tabla 1 muestra las diferencias.

Tabla 1. Diferencias entre registros de usuarios cuando se agrega un usuario duplicado aun grupo.

Operación LDAP Servidor de LotusDomino

Microsoft ActiveDirectory

Agregar un usuario yéste está duplicado

Se produce un error No se produce unerror

Se produce un error

Agregar variosusuarios y el primeroestá duplicado

Se produce un errorpara todos losusuarios

No se produce unerror

Se produce un errorpara todos losusuarios

Agregar variosusuarios y unusuario que no es elprimero estáduplicado.

Se produce un errorpara todos losusuarios

No se produce unerror

Mensaje definalización parcial

6. El resultado de eliminar un usuario de un grupo que no es miembro del grupoes diferente según el registro de usuarios que se esté utilizando. La Tabla 2muestra las diferencias.

Tabla 2. Diferencias entre registros de usuarios cuando se elimina un usuario de un grupoque no es miembro del grupo.

Operación LDAP Servidor de LotusDomino

Microsoft ActiveDirectory

Agregar un usuario yéste no está en elgrupo.

Se produce un error Se produce un error Se produce un error

Eliminar variosusuarios y el primerono está en el grupo.

Se produce un errorpara todos losusuarios

Se produce un error Se produce un errorpara todos losusuarios

Eliminar variosusuarios y unusuario que no es elprimero no está en elgrupo.

Se produce un errorpara todos losusuarios

Mensaje definalización parcial

Mensaje definalización parcial

7. La longitud máxima de los distintos nombres asociados a un usuario dependedel registro de usuarios que se esté utilizando. En la Tabla 3 se compara lalongitud máxima permitida y la longitud máxima recomendada para que todoslos registros de usuario que Access Manager para e-business soporta seancompatibles.

Tabla 3. Longitud máxima de nombres según el registro de usuarios

Longitudmáxima de:

LDAP Microsoft ActiveDirectory

Servidor deLotus Domino

Valor máximorecomendado

Nombre (CN deLDAP)

256 64 960 64

Inicial 128 64 65535 64

Apellidos 128 64 960 64

270 IBM Tivoli Access Manager Base: Guía del administrador

Tabla 3. Longitud máxima de nombres según el registro de usuarios (continuación)

Longitudmáxima de:

LDAP Microsoft ActiveDirectory

Servidor deLotus Domino

Valor máximorecomendado

UID de registro(DN de LDAP)

1024 2048 255 Este valor esespecífico del

registro deusuarios y debe

modificarsecuando se

modifica unregistro deusuarios.

Identidad deusuario deAccess Managerpara e-business

256 2048 - 1 -longitud_de_

nombre_dominio

200 - 4 -longitud_de_

nombre_dominio

Este valor esespecífico del

registro deusuarios y debe

modificarsecuando se

modifica unregistro deusuarios.

8. A los usuarios creados en un registro de usuarios del servidor Lotus Domino ode Microsoft Active Directory se les proporciona automáticamente laposibilidad de ser propietarios de credenciales de inicio de sesión único, la cualno puede eliminarse. Cuando se utiliza un registro de usuarios de LDAP, estaposibilidad debe concederse de manera explícita a un usuario y posteriormentepuede eliminarse.

9. Cuando Policy Server de Access Manager para e-business utiliza MicrosoftActive Directory o un servidor de Lotus Domino como su registro de usuarios,los clientes de Tivoli SecureWay Policy Director Versión 3.8 no puedenconectarse con Policy Server. Utilice un registro de usuarios distinto o actualicelos clientes para Access Manager para e-business.

Apéndice G. Diferencias entre registros de usuarios 271

272 IBM Tivoli Access Manager Base: Guía del administrador

Apéndice H. Avisos

Esta información se ha desarrollado para productos y servicios que se ofrecen enEstados Unidos. Es posible que en otros países IBM no ofrezca los productos, losservicios o las características que se describen en este documento. Póngase encontacto con el representante local de IBM para obtener información sobre losproductos y servicios disponibles actualmente en su área. Las referencias aprogramas, productos o servicios de IBM no pretenden indicar ni implicar que sólopuedan utilizarse los productos, programas o servicios de IBM. En su lugar, sepuede utilizar cualquier producto, programa o servicio funcionalmente equivalenteque no infrinja ninguno de los derechos de propiedad intelectual de IBM. Noobstante, es responsabilidad del usuario evaluar y comprobar el funcionamiento decualquier producto, programa o servicio que no sea de IBM.

IBM puede tener patentes o solicitudes de patentes en trámite que afecten a lostemas tratados en este documento. La posesión de este documento no otorga alusuario ninguna licencia sobre esas patentes. Puede enviar consultas sobrelicencias, por escrito, a:

IBM Director of LicensingIBM CorporationNorth Castle DriveArmonk, NY 10504-1785Estados Unidos

Para consultas sobre licencias en las que se solicite información sobre el juego decaracteres de doble byte (DBCS), póngase en contacto con el departamento depropiedad intelectual de IBM de su país o envíe directamente las consultas porescrito a:

IBM World Trade Asia CorporationLicensing2-31 Roppongi 3-chome, Minato-kuTokio 106, Japón

El siguiente párrafo no se aplica al Reino Unido ni a ningún otro país dondeestas disposiciones sean incompatibles con la legislación vigente:INTERNATIONAL BUSINESS MACHINES CORPORATION FACILITA ESTAPUBLICACIÓN ″TAL CUAL″, SIN GARANTÍAS DE NINGÚN TIPO, NIEXPLÍCITAS NI IMPLÍCITAS, INCLUYENDO, PERO SIN LIMITARSE A, LASGARANTÍAS IMPLÍCITAS DE NO INFRACCIÓN, COMERCIALIZACIÓN OADECUACIÓN A UN FIN CONCRETO. Algunos estados o países no permiten larenuncia a las garantías explícitas o implícitas en ciertas transacciones; por tanto, esposible que esta declaración no resulte aplicable a su caso.

Este documento puede contener imprecisiones técnicas o errores tipográficos.Periódicamente se efectúan cambios en la información aquí contenida; dichoscambios se incorporarán en nuevas ediciones de la publicación. IBM se reserva elderecho a realizar, si lo considera oportuno, cualquier modificación en losproductos o programas que se describen en esta información y sin notificarlopreviamente.

273

Las referencias en este documento a sitios web que no sean de IBM seproporcionan únicamente como ayuda y no se consideran en modo alguno sitiosweb aprobados por IBM. Los materiales de dichos sitios web no forman parte deeste producto de IBM y la utilización de los mismos será por cuenta y riesgo delusuario.

IBM puede utilizar o distribuir la información que se le suministre de cualquiermodo que considere adecuado sin incurrir por ello en ninguna obligación con elremitente.

Los titulares de licencias de este programa que deseen información sobre el mismocon el fin de permitir: (i) el intercambio de información entre programas creadosindependientemente y otros programas (incluido éste) y (ii) la utilización mutua dela información intercambiada, deben ponerse en contacto con:

IBM Corporation2Z4A/10111400 Burnet RoadAustin, TX 78758Estados Unidos

Dicha información puede estar disponible, sujeta a los términos y condicionesadecuados, incluido, en algunos casos, el pago de una tasa.

El programa bajo licencia que se describe en este documento, y todos losmateriales bajo licencia disponibles para el mismo, los proporciona IBM bajo lostérminos del Acuerdo con el Cliente IBM, del Acuerdo Internacional de Licenciaspara Programas IBM o de cualquier acuerdo equivalente entre el cliente e IBM.

La información relacionada con productos que no son de IBM se ha obtenido delos proveedores de dichos productos, sus anuncios publicados o de otras fuentesdisponibles públicamente. IBM no ha probado estos productos y no puedeconfirmar la precisión de su rendimiento, compatibilidad o cualquier otrareclamación relacionada con los productos que no son de IBM. Las preguntasrelacionadas con las posibilidades de los productos que no son de IBM se debendirigir a los proveedores de dichos productos.

Todas las declaraciones relacionadas con la orientación o los propósitos futuros deIBM se pueden cambiar o retirar sin previo aviso y únicamente representan metasy objetivos.

Esta información contiene ejemplos de datos e informes utilizados en operacionesempresariales diarias. Para ilustrarlos lo más claramente posible, los ejemplosincluyen nombres de individuos, empresas, marcas y productos. Todos estosnombres son ficticios y cualquier similitud con los nombres y direcciones utilizadosen empresas reales es coincidencia.

LICENCIA DE COPYRIGHT:

Esta información contiene programas de aplicación de ejemplo en lenguaje fuenteque ilustran técnicas de programación en diferentes plataformas operativas. Puedecopiar, modificar y distribuir estos programas de ejemplo en cualquier formato sinabonar ninguna cantidad a IBM con el propósito de desarrollo, uso,comercialización o distribución de dichos programas de aplicación en conformidadcon la interfaz de programación de aplicaciones que corresponde a la plataformaoperativa para la que se han escrito dichos programas de ejemplo. Éstos no han

274 IBM Tivoli Access Manager Base: Guía del administrador

sido probados en su totalidad en todas las situaciones posibles. IBM, por tanto, nopuede garantizar la fiabilidad, servicio o funcionalidad de estos programas. Puedecopiar, modificar y distribuir estos programas de ejemplo en cualquier formato sinabonar ninguna cantidad a IBM con el propósito de desarrollo, uso,comercialización o distribución de dichos programas de aplicación en conformidadcon las interfaces de programación de aplicaciones de IBM.

Cada copia o cualquier fragmento de estos programas de ejemplo o cualquiertrabajo que derive de ellos debe incluir un aviso de copyright como el siguiente:

© (el nombre de su empresa) (año). Partes de este código se derivan de Programasde ejemplo de IBM Corp. © Copyright IBM Corp. _escriba el año o años_.Reservados todos los derechos.

Si está visualizando esta información en copia software, es posible que lasfotografías e ilustraciones en color no aparezcan.

Marcas registradasLos siguientes términos son marcas registradas de International Business MachinesCorporation en Estados Unidos, en otros países o en ambos:

AIXDB2IBMLogotipo de IBMOS/390SecureWayTivoliLogotipo de TivoliUniversal DatabaseWebSpherezSeriesz/OS

Lotus y Domino son marcas registradas de International Business MachinesCorporation y Lotus Development Corporation en Estados Unidos, en otros paíseso en ambos.

Java y todos los logotipos y marcas registradas basados en Java son marcasregistradas de Sun Microsystems, Inc. en Estados Unidos y en otros países.

Microsoft y Windows son marcas registradas de Microsoft Corporation en EstadosUnidos, en otros países o en ambos. Java y todos los logotipos y marcas registradasbasadas en Java son marcas registradas de Sun Microsystems, Inc. en EstadosUnidos y en otros países.

UNIX es una marca registrada de The Open Group en Estados Unidos y en otrospaíses.

Otros nombres de empresas, productos o servicios pueden ser marcas registradas omarcas de servicios de terceros.

Apéndice H. Avisos 275

276 IBM Tivoli Access Manager Base: Guía del administrador

Glosario

Aacciones. Atributos de permiso de ACL.

ACL. Vea lista de control de accesos.

archivo de base de datos de claves. Vea conjunto declaves.

archivo de claves. Vea conjunto de claves.

archivo de respuesta. Un archivo que contiene unconjunto de respuestas predefinidas a preguntasformuladas por un programa y que se utiliza en lugardel diálogo de usuario.

autenticación. (1) En seguridad de sistemas, laverificación de la identidad de un usuario o lacapacidad de determinar qué usuario puede acceder aun objeto. (2) En seguridad de sistemas, la verificaciónde que un mensaje no se ha modificado ni dañado. (3)En seguridad de sistemas, un proceso utilizado paraverificar el usuario de un sistema de información orecursos protegidos.

autoridad de certificados. En e-commerce, unaorganización que emite certificados. La autoridad decertificados autentica la identidad del propietario delcertificado y el servicio que el propietario estáautorizado a utilizar, emite nuevos certificados, renuevacertificados existentes y revoca certificados quepertenecen a usuarios que ya no están autorizados autilizarlos.

autorización. (1) En seguridad de sistemas, el derechoconcedido a un usuario para establecer comunicacióncon un sistema o utilizarlo. (2) Un derecho de acceso.(3) El proceso de conceder a un usuario accesocompleto o restringido a un objeto, recurso o función.

Ccalidad de protección. El nivel de seguridad de losdatos, determinado por una combinación deautenticación, integridad y condiciones de privacidad.

certificado. En e-commerce, un documento digital queenlaza una clave pública con la identidad delpropietario de un certificado, habilitando así alpropietario del certificado para que pueda serautenticado. Los certificados los emite una autoridad decertificados.

cifrado. El proceso de transformar datos en un formaininteligible de manera que los datos originales no sepueden obtener o se pueden obtener sólo utilizando unproceso de descifrado.

clave. Una secuencia de símbolos que se utiliza con unalgoritmo criptográfico para cifrar o descifrar datos.Vea clave privada y clave pública.

clave privada. Una clave que sólo la conoce supropietario. Compare con clave pública.

clave pública. Una clave que cualquier persona puedeutilizar. Compare con clave privada.

conexión. (1) En comunicación de datos, unaasociación establecida entre unidades para latransmisión de información. (2) En TCP/IP, la ruta deacceso entre dos aplicaciones de protocolo queproporciona servicio de envío de secuencia de datosfiable. En Internet, una conexión se extiende de unaaplicación de TCP de un sistema a una aplicación deTCP de otro sistema. (3) En comunicación de sistemas,una línea sobre la que se pueden pasar datos entre dossistemas o entre un sistema y un dispositivo.

configuración. (1) La manera en que se organiza einterconecta el hardware y el software de un sistema deproceso de información. (2) Los dispositivos y losprogramas que componen un sistema, subsistema ored.

conjunto de claves. Un archivo que contiene clavespúblicas, claves privadas, roots fiables y certificados.

control de accesos. En seguridad de sistemas, elproceso de asegurar que a los recursos de un sistemasólo puedan acceder usuarios autorizados utilizandométodos autorizados.

credenciales. Información detallada, obtenida durantela autenticación, que describe a un usuario, cualquierasociación de grupos y otros atributos de identidadrelacionados con la seguridad. Cualquier servicio deAccess Manager que requiera información acerca de unusuario puede utilizar credenciales. Las credencialespermiten que Access Manager lleve a cabo de formasegura varios servicios como, por ejemplo, laautorización, auditoría y delegación. Por ejemplo, elservicio de autorizaciones de Access Manager utiliza lascredenciales de usuario para determinar si un usuarioestá autorizado a llevar a cabo operaciones específicasen un recurso protegido.

277

Ddaemon. Un programa que se ejecuta en modalidaddesatendida para efectuar un servicio estándar. Algunosdaemons se activan automáticamente para realizar sutarea; otros operan periódicamente.

datos cifrados. Datos cifrados que no se pueden leer ano ser que se conviertan en datos de texto plano(descifrado) utilizando una clave.

datos de política. Pueden ser datos de política deintensidad de contraseñas y datos de inicio de sesión.

DCE. Vea entorno de sistemas distribuidos.

Definiciones de clases de objeto. Todas las entradastienen un atributo objectClass que identifica el tipo deinformación que contienen. De hecho, la clase de objetoindica qué otros atributos pueden estar presentes enuna entrada. El esquema de directorio define los tiposde atributo válidos y las clases de objeto que puedenaparecer en el directorio. Las definiciones de tipos deatributo definen la longitud máxima y la sintaxis de susvalores. Las definiciones de clases de objeto especificanqué atributos deben estar presentes en un objeto de esaclase, así como los atributos que pueden estarpresentes.

DN. Vea nombre distinguido.

dominio. (1) Parte de una red de sistemas en que losrecursos del proceso de datos están bajo control común.(2) En una base de datos, todos los valores posibles deun atributo o un elemento de datos. (3) Vea nombre dedominio.

dominio seguro. El grupo de usuarios, sistemas yrecursos que comparten servicios comunes y suelentener una finalidad común.

Eenlazar. Relacionar un identificador con otro objeto enun programa; por ejemplo, relacionar un identificadorcon un valor, una dirección u otro identificador, oasociar parámetros formales y parámetros reales.

entorno de sistemas distribuidos (DCE). Laespecificación Open Software Foundation (o unproducto derivado de esta especificación) queproporciona ayuda cuando se utiliza la red. El entornode sistemas distribuidos proporciona diferentesfunciones, tales como autenticación, servicio dedirectorios y llamada a procedimientos remotos.

escalabilidad. La capacidad de un sistema de red deresponder a un número creciente de usuarios queacceden a recursos.

espacio de objetos protegidos. La representaciónvirtual de objetos de recursos del sistema reales que seutiliza para aplicar ACL y POP. También lo utiliza elservicio de autorizaciones.

esquema. El conjunto de sentencias, expresadas en unlenguaje de definición de datos, que describencompletamente la estructura de una base de datos.

esquema de directorio. Las entradas de un directoriose componen de una colección de atributos y de susvalores asociados. Los atributos pueden tener uno omás valores. Para identificar un valor concreto en unaentrada, el nombre de tipo de atributo se especificajunto con el valor, como en cn=John Doe. Esto recibe elnombre de par de atributo:valor. Todas las entradastienen un atributo objectClass que identifica el tipo deinformación que contienen. De hecho, la clase de objetoindica qué otros atributos pueden estar presentes enuna entrada. El esquema de directorio define los tiposde atributo válidos y las clases de objeto que puedenaparecer en el directorio. Las definiciones de tipos deatributo definen la longitud máxima y la sintaxis de susvalores. Las definiciones de clases de objeto especificanqué atributos deben estar presentes en un objeto de esaclase, así como los atributos que pueden estarpresentes.

Ffirma digital. Datos que se agregan a una unidad dedatos, o que son una transformación criptográfica de lamisma, y que permiten al receptor de dicha unidadverificar su fuente e integridad y detectar posiblesfalsificaciones.

Ggestión de seguridad. La disciplina de gestión quehace que una organización pueda controlar el acceso aaplicaciones y datos esenciales.

grupos de control de accesos. Grupos que se han deutilizar para el control de accesos. Cada grupo contieneun atributo de varios valores que se compone denombres distinguidos de miembros. Los grupos decontrol de accesos tienen una clase de objetoAccessGroup.

Hhost. Un sistema que está conectado a una red (comoInternet o una red SNA) y proporciona un punto deacceso a esa red. Dependiendo del entorno, el hostpuede proporcionar control centralizado a la red. Elhost puede ser un cliente, un servidor o un cliente y unservidor simultáneamente.

278 IBM Tivoli Access Manager Base: Guía del administrador

Iinstalación silenciosa. Una instalación que no envíamensajes a la consola, sino que almacena mensajes yerrores en archivos de registro. También puede indicarque la instalación utiliza archivos de respuesta en lugarde diálogos de usuario.

IP. Vea Protocolo Internet.

LLDAP. Vea Lightweight Directory Access Protocol.

ldif2db. Este programa se utiliza para cargar entradasespecificadas en texto LDIF (LDAP DirectoryInterchange Format) en un directorio de una base dedatos relacional. La base de datos ya debe existir.ldif2db puede utilizarse para agregar entradas en unbase de datos de directorios vacía o en una base dedatos que ya contiene entradas.

Lightweight Directory Access Protocol (LDAP). Unprotocolo abierto que (a) utiliza TCP/IP paraproporcionar acceso a directorios que soportan unmodelo X.500 y (b) no necesita satisfacer los requisitosde recurso del X.500 Directory Access Protocol (DAP),que es más complejo. Las aplicaciones que utilizanLDAP (conocidas como aplicaciones habilitadas paradirectorios) pueden utilizar un directorio como unalmacén de datos y para recuperar información sobrepersonas o servicios como, por ejemplo, direcciones decorreo electrónico, claves públicas o parámetros deconfiguración específicos de un servicio. LDAP seespecificó originalmente en RFC 1777. La versión 3 deLDAP está especificada en RFC 2251, y el IETF sepuede seguir utilizando en funciones estándaradicionales. Algunos de los esquemas de estándaresdefinidos en IETF para LDAP se encuentran en RFC2256.

lista de control de accesos. (1) En seguridad desistemas, una colección de todos los derechos de accesopara un objeto. (2) En seguridad de sistemas, una listaasociada a un objeto que identifica todos los asuntos alos que puede acceder el objeto y sus derechos deacceso; por ejemplo, una lista asociada a un archivoque identifica usuarios que pueden acceder al archivoasí como sus derechos de acceso para ese archivo.

Mmetadatos. Datos que describen las características dedatos almacenados; es decir, son datos descriptivos.

migración. La instalación de una versión o releasenuevos de un programa para sustituir a una versión orelease anterior.

nombre de dominio. En la suite de protocolos deInternet, un nombre de un host. Un nombre de

dominio se compone de una secuencia de subnombresseparados por un carácter delimitador. Por ejemplo, siel nombre de dominio completo (FQDN) de un host esralvm7.vnet.ibm.com, cada uno de los siguientescomponentes es un nombre de dominio:

v ralvm7.vnet.ibm.com

v vnet.ibm.com

v ibm.com

nombre distinguido (DN). Todas las entradas de undirectorio tienen un nombre distinguido. El nombredistinguido es el nombre que identifica exclusivamenteuna entrada en el directorio. Un nombre distinguido secompone de pares de atributo:valor, separados porcomas.

Ppar de claves. Una clave pública y una clave privada.Cuando el par de claves se utiliza para el cifrado demensajes, el remitente utiliza la clave pública paracifrarlos, y el destinatario la privada para descifrarlos.Cuando el par de claves se utiliza para la firma demensajes, el firmante utiliza la clave pública para cifraruna representación de los mismos, y el destinatario laprivada para descifrarla a efectos de verificar la firma.

permisos de acceso. Permisos que se aplican a todo elobjeto o permisos que se aplican a clases de acceso deatributo.

Policy Server. Mantiene la información de ubicaciónsobre otros servidores de Access Manager en eldominio seguro. Cuando los cambios en una políticaafectan a la base de datos maestra de autorizaciones,Policy Server se encarga de actualizar todas las réplicasde base de datos de autorizaciones del dominio.

política. Un conjunto de reglas que se aplican arecursos gestionados.

política de objetos protegidos (POP). Un tipo depolítica de seguridad de Access Manager que ponecondiciones adicionales para acceder a un recursoprotegido tras una comprobación satisfactoria depolítica de ACL. El acceso según la hora del día y elnivel de calidad de protección son ejemplos de POP.

POP. Vea política de objetos protegidos.

Protocolo de Transferencia de Archivos (FTP). En lasuite de protocolos de Internet, un protocolo de capasde aplicaciones que utiliza TCP y servicios de Telnetpara transformar archivos de datos generales entremáquinas o hosts.

Protocolo de Transferencia de Hipertexto (HTTP). Enla suite de protocolos de Internet, el protocolo que seutiliza para transferir y mostrar documentos dehipertexto.

Glosario 279

Protocolo Internet (IP). En la suite de protocolos deInternet, un protocolo sin conexiones que direccionadatos por una red o redes interconectadas y actúa comoun intermediario entre las capas de protocolo más altasy la red física.

Rregistro. (1) El almacén de datos que mantiene lainformación de las cuentas de usuarios y grupos quepueden participar en el dominio seguro. (2) Una basede datos que contiene información de configuración delsistema referente al usuario, al hardware y a lasaplicaciones y los programas instalados.

réplica. Una réplica es un servidor que ejecuta unacopia del directorio. Este servidor replicado puedemantener una copia de todo el directorio o sólo unárbol de ese directorio. Cualquier actualización a unservidor replicado se aplica al servidor maestro. Si elservidor maestro presenta anomalías, tiene una copiade los árboles de directorios en el servidor replicado. Elservidor replicado también mejora el tiempo derespuesta.

root fiable. En Secure Sockets Layer (SSL), la clavepública y el nombre distinguido asociado de unaautoridad de certificados.

RSA. Un sistema de criptografía de clave públicautilizado para el cifrado y la autenticación. Fueinventado por Ron Rivest, Adi Shamir y LeonardAdleman en 1977. La seguridad del sistema depende dela dificultad de descomponer el producto en factores dedos números primos grandes.

SSecure Sockets Layer (SSL). Un protocolo deseguridad que proporciona privacidad durante lacomunicación. SSL permite a las aplicaciones decliente/servidor comunicarse de manera que puedenimpedir que otras personas escuchen, manipulen ofalsifiquen mensajes. SSL fue desarrollado por NetscapeCommunications Corp. y RSA Data Security, Inc.

selector de transporte. Lo que en Open SystemsInterconnection (OSI) equivale a los números de puertoen TCP/IP. También recibe el nombre de número TSEL.

señal. (1) En una red de área local, el símbolo deautorización que se ha pasado satisfactoriamente deuna estación de datos a otra para indicar que laestación controla temporalmente el medio detransmisión. Cada estación de datos tiene la posibilidadde obtener y utilizar la señal para controlar el medio.Una señal es un mensaje concreto o un patrón de bitsque significa permiso para transmitir. (2) En redes deárea local (LAN), una secuencia de bits que se pasa de

un dispositivo a otro a través del medio detransmisión. Cuando la señal incluye datos, recibe elnombre de trama.

servicio. Trabajo realizado por un servidor. Puede serun trabajo simple, como atender a peticiones de envío oalmacenamiento de datos (como es el caso de losservidores de archivos, servidores HTTP, servidores decorreo electrónico y servidores finger); o más complejo,como el efectuado por los servidores de impresión o losde procesos.

servidor de gestión. Vea Policy Server.

SSL. Vea Secure Sockets Layer.

sufijos. Un sufijo es un nombre distinguido queidentifica la entrada superior en una jerarquía dedirectorios mantenidos localmente. Debido al esquemade denominación relativo utilizado en LightweightDirectory Access Protocol (LDAP), este nombredistinguido también es el sufijo de las demás entradasen esta jerarquía de directorios. Un servidor dedirectorios puede tener varios sufijos, cada uno de loscuales identifica una jerarquía de directoriosmantenidos localmente.

suite de protocolos de Internet. Un conjunto deprotocolos desarrollado para utilizarlo en Internet ypublicado como Requests for Comments (RFC) en laInternet Engineering Task Force (IETF).

Ttiempo de ejecución. El periodo de tiempo durante elcual se está ejecutando un programa del sistema. Unentorno de tiempo de ejecución es un entorno deejecución.

TSEL. Vea selector de transporte.

Uusuario. Persona, organización, proceso, dispositivo,programa, protocolo o sistema que utiliza un servicioque otros le proporcionan.

280 IBM Tivoli Access Manager Base: Guía del administrador

Índice

Aacción

especificar en entradas de ACL 51acción, crear nueva 50acciones 41acciones ampliadas 49ACL 14

acciones ampliadas 49aplicar a sufijos nuevos de LDAP 116atributo de ID 40atributo de permisos 40atributo de tipo 39crear 38ejemplo de permisos personalizados 42entradas 38evaluación 43grupos de acciones ampliados 49herencia 44operaciones en un objeto 42permiso control 55permisos de gestión 53permisos personalizados 42permisos WebSEAL 52políticas de administración predeterminadas 60raíz, predeterminada 60resolución de una petición 46sintaxis de entrada 39traverse 45, 52

ACL de configuración predeterminada 61ACL de gestión predeterminada 61ACL de GSO predeterminada 61ACL de política predeterminada 62ACL de réplica predeterminada 61ACL de WebSEAL predeterminada 61ACL explícita 44ACL heredada 44ACL raíz (predeterminada) 45, 60ACL raíz predeterminada 45, 60activación

roles 78administración

dominio empresarial 76dominios múltiples 76roles 77roles, delegación 77superdominio 76

administración delegadagestión de grupos y usuarios 85gestión de política 90gestión del espacio de objetos 81objetos contenedor de grupos 86permisos de ACL de grupo 88permisos de ACL de usuario 89usuarios y grupos de administración 82

administradordominios múltiples 76superdominio 76tareas 78

administrador delegado, ilustrado 76administradores

administrador 77

administradores (continuación)dominio 77dominio empresarial 76Policy Director 76predefinidos 76sec_master 75senior 77soporte 77tipos 76

API de autorización 17API de autorización estándar 3aplicador de políticas 6archivos de configuración 101archivos de seguimiento de auditoría 123, 125atributo POP

hora del día 67modalidad de aviso 66nivel de auditoría 66

auditcfg 127auditlog 126auditoría

visión general 123autenticación 3Authorization Server 93auto-database-update-notify 105autorización 4, 5

Bbase de datos de autorizaciones, réplica 105base de datos de políticas de autorización 8base de datos maestra de políticas de autorización 8boot-start-ivacld 104boot-start-ivmgrd 104

Ccalidad de protección 4cifrado

estándares soportados 4códigos de ID de campo 132códigos de ID de campo de evento 132comentarios sobre publicaciones xviiconfiguración de la migración tras error 112contacto por correo electrónico xviicontraseña

resolución de problemas 77creación

roles 78cualquier otro 40, 44

Ddominio

administradores 77empresarial 76múltiple 76subdominio, descrito 75superdominio 76

dominio empresarial 76

281

dominio múltiple 76ejemplo 76ilustrado 76

Eerror.log 124escalabilidad 4, 10espacio de objetos, definidos por el usuario 33

crear nuevo 34espacio de objetos definidos por el usuario 33

crear nuevo 34espacio de objetos protegidos 12, 31

directrices 48objeto protegido 12objetos de gestión 12objetos definidos por el usuario 12objetos web 12recurso del sistema 12

estado, servidor 103estado del servidor 103evaluación de una ACL 43evaluador de autorizaciones 8evento de auditoría 126

Ffatal.log 124

Ggestión centralizada 5gestor de recursos 6grupo 38grupo de acciones, crear nuevo 50grupo iv-admin 82grupo ivmgrd-servers 83grupo webseal-servers 83grupos de acciones ampliados 49

Hherencia 44

IIBM SecureWay Directory 112iPlanet 112

LLDAP

configuración de la migración tras error 112sufijos, nuevos 116visión general 109

ldap.conf 113libros

comentarios xiien línea xiisolicitar xii

lista de control de accesos (ACL) 14logaudit 126logflush 127logsize 127

Mmanuales

comentarios xiien línea xiisolicitar xii

max-notifier-threads 105, 106mensajes

error.log 124fatal.log 124notice.log 124warning.log 124

mensajes de servicioerror.log 124fatal.log 124notice.log 124warning.log 124

migración tras error de LDAPvalores de preferencia 115

modalidad de caché local 17, 20modalidad de caché remota 17, 19modelo de ACL esparcida 44modelo de autorización 5

Nno autenticado 44notice.log 124notifier-wait-time 105, 107

Oobjeto contenedor 31

definido por el usuario 33gestión 32WebSEAL 32

objeto de recurso 32objeto protegido 12, 31objetos, crear y suprimir 35objetos contenedor de grupos 86objetos de gestión 12objetos definidos por el usuario 12objetos web 12

Ppd_start 94pdacld 93pdadmin 94pdadmin server replicate 106pdmgrd 8, 93permiso control 55permiso traverse 45, 52permisos 41

personalizados 42personalizados, ejemplo 42roles 77

permisos de ACL 41permisos de espacio de objetos 60permisos de objeto 60permisos Management/ACL 54permisos Management/Action 55permisos Management/Config 56permisos Management/Groups 58permisos Management/GSO 59permisos Management/Policy 57

282 IBM Tivoli Access Manager Base: Guía del administrador

permisos Management/POP 55permisos Management/Replica 57permisos Management/Server 56permisos Management/Users 58Policy Director

administradores 76conceptos básicos 2seguridad de redes empresariales 1servicio de autorizaciones 7, 8tecnología básica 3

política de ACL explícita 13política de ACL heredada 13política de objetos protegidos (POP) 63

aplicar a objetos 65configurar atributos 66crear 64

políticas de ACL, definición 13políticas de administración (predeterminadas) 60políticas de administración predeterminadas 60políticas de objetos protegidos 14políticas POP, definición 13POP 14, 63

aplicar a objetos 65configurar atributos 66crear 64

proceso de autorización 16programa de utilidad de gestión de claves de iKeyman

descripción xvpublicaciones

comentarios xiien línea xiisolicitar xii

publicaciones en línea xvi

Rrecurso del sistema 12, 31registro

visión general 123registro de usuarios

diferencias 269réplica 10, 114réplica de base de datos de autorizaciones 105resolución de una petición de ACL 46responsabilidad de gestión 5roles

activación de roles 78asignación de roles 78

asignación 78creación de roles 78definidos 77delegación 77permisos 77

roles, delegaciónadministración 77

Ssec_master 75seguimiento de auditoría 126seguridad

aspectos comunes 2implementación de política 11política 77

seguridad de redes empresariales 1server replicate 106

servicio de autorizaciones 6, 7, 8API de autorización 9interfaz de gestión 9ventajas 7

servicio de autorizaciones externo 21servidor

inicio automático 104servidor de gestión 8, 93solicitud de publicaciones xviisoporte al cliente xviiisoporte al cliente de Tivoli xviiisubdominio 75superdominio 76

Ttareas

activación de roles 78administración de rol 78asignación de roles 78creación de roles 78roles 77tipos 78

threads del notificador de actualización 106tiempo de espera de la notificación 107tipos de objetos 34, 86traverse 52

Uumbral de creación 127usuario 38usuario sec_master 82usuarios

administrador, administrador 77administrador, dominio 77administrador, Policy Director 76administrador, sec_master 75administrador, senior 77administrador, soporte 77delegación 77

Vvalores de preferencia (migración tras error de LDAP) 115

Wwarning.log 124Web Portal Manager 15, 94

política de seguridad 77WebSEAL 93webseald 93

Índice 283

284 IBM Tivoli Access Manager Base: Guía del administrador

Printed in Denmark by IBM Danmark A/S

GC10-3838-00