Registros del sistema operativo local
Con la implementación del registro del sistema operativo local, el mecanismo de autenticación de WebSphere Application Server puede utilizar la base de datos de cuentas de usuarios del sistema operativo local.
Si desea utilizar el registro del sistema operativo local para
representar los principales que acceden a los recursos de WebSphere
Application Server, no tiene que realizar ningún paso de configuración
especial de registro de usuarios. El registro del sistema
operativo local se utiliza para la autenticación y la autorización de los
usuarios que acceden a los recursos de WebSphere Application Server, pero
no para los usuarios de WebSphere Application Server que acceden a los
recursos del sistema operativo. WebSphere Application
Server no se ejecuta con el perfil de usuario de sistema operativo Usuarios del
servidor de aplicaciones. En su lugar, WebSphere Application Server se ejecuta con
el perfil de sistema operativo configurado por el administrador del servidor de
aplicaciones.
Si desea autorizar un usuario para cualquier recurso de
WebSphere Application Server, debe existir un perfil de usuario para ese usuario en
el sistema operativo. Utilice el mandato Crear perfil de usuario (CRTUSRPRF) para
crear nuevos ID de usuario que se puedan utilizar en WebSphere Application Server
LDAP (Lightweight Directory Access Protocol) es un registro
centralizado. La mayoría de los registros del sistema operativo local no
son registros centralizados.
WebSphere Application
Server proporciona implementaciones para el registro de dominios y el registro de cuentas locales de Windows, así como implementaciones para los registros de cuentas de usuarios de Linux, Solaris y AIX. Se da soporte a Active Directory de Windows mediante
la implementación del registro de usuarios LDAP que se describe posteriormente.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
No utilice un registro del sistema operativo local en un
entorno de WebSphere Application Server en el que los servidores de
aplicaciones se distribuyen entre varias máquinas debido a que cada
máquina tiene su propio registro de usuarios.
El registro de dominio de Windows y NIS (Network
Information Services) son excepciones. El registro de dominio de Windows y
NIS (Network Information Services) son registros centralizados. WebSphere
Application Server da soporte al registro de dominio de Windows pero
no a NIS.
Como se ha mencionado
anteriormente, los ID de acceso que se obtienen del registro de usuarios se utilizan
durante las comprobaciones de autorización. Dado que generalmente estos ID son
identificadores exclusivos, varían de máquina a máquina, incluso si existen los
mismos usuarios y contraseñas en cada máquina.
La autenticación de
certificados de cliente Web no está soportada actualmente cuando se utiliza el
registro de usuarios del sistema operativo local. No obstante, la autenticación de
certificados de cliente Java™ funciona con un registro de usuarios de sistema
operativo local. La autenticación de certificados de cliente Java correlaciona el
primer atributo del nombre de dominio del certificado con el ID de usuario en el
registro de usuarios.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
CWSCJ0337E: El método mapCertificate no está soportado
El error está hace referencia a los certificados de cliente web; sin embargo, también aparece con los certificados de cliente Java. Ignore este error para los certificados de cliente Java.Un registro del sistema operativo local es un registro
centralizado dentro de un sysplex.
WebSphere Application Server utiliza las
interfaces SAF (System Authorization Facility). MVS define las interfaces SAF para habilitar las
aplicaciones para que utilicen servicios de autorización de sistemas o registros para controlar el acceso a recursos como, por ejemplo, los conjuntos de
datos y los mandatos MVS. SAF permite procesar las solicitudes de autorización de seguridad
directamente a través de RACF (Resource Access Control Facility) o de un
proveedor de seguridad para z/OS de terceros. Debe proporcionar una
correlación de una identidad de registro de usuarios con un ID de usuario
SAF a menos que seleccione el sistema operativo local como registro de
usuarios. Para obtener más información, consulte Módulos de correlación de SAF (System Authorization Facility) personalizados.
La autenticación de certificados de cliente Web está soportada
cuando se utiliza el registro de usuarios del sistema operativo local. Los clientes web y
Java pueden
correlacionar los certificados digitales con identidades
MVS cuando se selecciona el
sistema operativo local. Se puede utilizar un filtro de
nombres de certificados para simplificar la correlación.
Si utiliza RACF como
servidor de seguridad, el mandato RACDCERT MAP crea un perfil de recurso que
correlaciona varias identidades de usuario con un certificado digital para
simplificar la administración de certificados, conservar el espacio de
almacenamiento en la base de datos RACF, mantener la contabilidad o mantener la
granularidad del control de acceso.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
Privilegios necesarios
El usuario que está ejecutando el proceso de WebSphere Application Server necesita suficientes privilegios de sistema operativo para llamar a la interfaz de programas de aplicación (API) de sistemas Windows para autenticar y obtener información de usuario y grupo desde el sistema operativo Windows. Este usuario inicia la sesión en la máquina o, si se ejecuta como servicio, es el usuario Conectar como servicio. Dependiendo de la máquina y de si es autónoma, forma parte de un dominio o es el controlador del dominio, los requisitos de acceso varían.
- Para una máquina autónoma, el usuario:
- Es un miembro del grupo administrativo.
- Tiene el privilegio Actuar como parte del sistema operativo.
- Tiene el privilegio Iniciar sesión como servicio, si el servidor se ejecuta como un servicio.
- Para una máquina que es miembro de un dominio, sólo un usuario de dominio puede
iniciar el proceso de servidor y:
- Tiene el privilegio Actuar como parte del sistema operativo en la Directiva de seguridad de dominio en el controlador de dominio.
- Tiene el privilegio Actuar como parte del sistema operativo en la Directiva de seguridad local en la máquina local.
- Tiene el privilegio Iniciar sesión como servicio en la máquina local, si el
servidor se ejecuta como un servicio.
El usuario es un usuario de dominio y no un usuario local, lo que significa que cuando una máquina forma parte de un dominio, sólo puede iniciar el servidor un usuario de dominio.
- Para una máquina de controlador de dominio, el usuario:
- Es un miembro de los grupos administrativos del dominio en el controlador del dominio.
- Tiene el privilegio Actuar como parte del sistema operativo en la Directiva de seguridad de dominio en el controlador de dominio.
- Tiene el privilegio Iniciar sesión como servicio en el controlador de dominio, si el servidor se ejecuta como un servicio.
- El cliente no dispone de uno de los privilegios necesarios.
- Se ha denegado el acceso.

![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
Registros de usuarios local y de dominio
Cuando se inicia WebSphere Application Server, el proceso de inicialización de tiempo de ejecución de seguridad intenta dinámicamente determinar si la máquina local es miembro de un dominio Windows. Si la máquina forma parte de un dominio, por omisión se pueden utilizar los usuarios o grupos del registro local y los usuarios o grupos del registro de dominio en la autenticación y la autorización, aunque tiene prioridad el registro de dominio. La lista de usuarios y grupos que se presenta durante la correlación de roles de seguridad incluye usuarios y grupos del registro de usuarios local y del registro de usuarios de dominio. Los usuarios y los grupos se pueden distinguir por los nombres de host asociados.
WebSphere Application Server no da soporte a los dominios de confianza.
Si la máquina no es miembro de un dominio de sistema Windows, se utiliza el registro de usuarios que es local para esta máquina.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
Utilización del registro de usuarios de dominio y el registro del sistema operativo local
- Procedimientos recomendados
- En general, si el registro local y el registro de dominio no contienen usuarios o grupos comunes, la administración es más sencilla y desaparecen los efectos colaterales negativos. Siempre que sea posible, dé acceso a los usuarios y grupos a los roles de seguridad exclusivos, incluidos el ID de servidor y los roles administrativos. En este caso, seleccione los usuarios y grupos del registro de usuarios local o del registro de usuarios de dominio para correlacionar los roles.
- En los casos en los que existan los mismos usuarios o grupos en el registro de usuarios local y en el registro de usuarios de dominio, se recomienda que sean exclusivos al menos el ID de servidor y los usuarios y grupos que se correlacionan con los roles administrativos en los registros y que existan sólo en el dominio.
- Si existe un conjunto de usuarios comunes, establezca otra contraseña para asegurarse de que se autentica el usuario adecuado.
- Cómo funciona
- Cuando una máquina forma parte de un dominio, el registro de usuarios de dominio tiene prioridad sobre el registro de usuarios local. Por ejemplo, cuando el usuario inicia la sesión en el sistema, el registro de usuarios de dominio intenta autenticar primero al usuario. Si la autenticación no es satisfactoria, se utiliza el registro de usuarios local. Cuando se correlaciona un usuario o un grupo con un rol, la información del usuario y el grupo se obtiene primero del registro de usuarios de dominio. Si se produce algún error, se intenta con el registro de usuarios local.
- Sin embargo, cuando se correlaciona con un
rol un nombre de usuario o de grupo plenamente cualificado, con un nombre de dominio
o de host adjunto, sólo se utiliza ese registro de usuarios para
obtener la información. Utilice la consola administrativa o los scripts para obtener los
nombres de usuario y grupo plenamente cualificados; esta es la forma que se
recomienda para correlacionar usuarios y grupos con roles.Consejo: Por ejemplo, un usuario Bob en una máquina en el registro de usuarios de Local OS no es el mismo que el usuario Bob en otra máquina en el registro de usuarios de dominio, ya que el ID exclusivo Bob, que es el identificador de seguridad [SID] en este caso, es distinto en cada registro de usuarios.
- EjemplosLa máquina MiMáquina forma parte del dominio MiDominio. La máquina MiMáquina contiene los siguientes usuarios y grupos:
- MiMáquina\usuario2
- MiMáquina\usuario3
- MiMáquina\grupo2
- MiDominio\usuario1
- MiDominio\usuario2
- MiDominio\grupo1
- MiDominio\grupo2
A continuación se describen algunos casos a partir del conjunto anterior de usuarios y grupos:- Cuando usuario2 inicia la sesión en el sistema, se utiliza el registro de usuarios de dominio para la autenticación. Por ejemplo, si la autenticación falla porque la contraseña es diferente, se utiliza el registro de usuarios local.
- Si el usuario MiMáquina\usuario2 se correlaciona con un rol, sólo el usuario usuario2 en la máquina MiMáquina tiene acceso. Por lo tanto, si la contraseña del usuario2 es la misma en el registro de usuarios local y el registro de usuarios de dominio, el usuario usuario2 no puede acceder al recurso, ya que el usuario usuario2 siempre se autentica utilizando el registro de usuarios de dominio. Si los dos registros de usuarios tienen usuarios comunes, se recomienda tener contraseñas diferentes.
- Si el grupo grupo2 se correlaciona con un rol, sólo los usuarios que sean miembros del grupo MiDominio\grupo2 pueden acceder al recurso, ya que la información del grupo2 se obtiene primero del registro de usuarios de dominio.
- Si el grupo MiMáquina\grupo2 se correlaciona con un usuario, sólo los usuarios que sean miembros del grupo MiMáquina\grupo2 pueden acceder al recurso. Se correlaciona con el rol un grupo específico (MiMáquina\grupo2 en lugar de sólo el grupo2).
- Utilice el usuario usuario3 o el usuario MiMáquina\usuario3 para correlacionarlo con un rol, ya que el usuario usuario3 es exclusivo; sólo existe en un registro de usuarios.
Si se autoriza en primer lugar con el registro de usuarios del dominio pueden surgir problemas si hay un usuario en los registros de usuarios del dominio y local con la misma contraseña. En esta situación la autorización basada en roles puede ejecutarse incorrectamente debido a que el usuario se autentica en primer lugar en el registro de usuarios del dominio. Esta autenticación genera un ID de seguridad del dominio exclusivo que se utiliza en WebSphere Application Server durante la comprobación de autorización. No obstante, el registro de usuarios local se utiliza para la asignación de roles. El ID de seguridad del dominio no coincide con el ID de seguridad exclusivo asociado con el rol. Para evitar este problema, correlacione los roles de seguridad con los usuarios del dominio en lugar de con los usuarios locales.
Sólo se puede utilizar un repositorio centralizado si hay más de un nodo. Este uso significa que sólo se puede utilizar el registro de usuarios de dominio, ya que los ID exclusivos de usuario y grupo (SID) son distintos en varios nodos, tal como se ha descrito anteriormente.

![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
Utilización del registro de usuarios local o del registro de usuarios de dominio.
Si desea acceder a los usuarios y grupos desde el registro de usuarios local o desde el registro de usuarios de dominio, no desde ambos, establezca la propiedad com.ibm.websphere.registry.UseRegistry. Esta propiedad se puede establecer como local o domain. Cuando se establece esta propiedad como local (no importa mayúsculas/minúsculas), sólo se utiliza el registro de usuarios local. Cuando se establece esta propiedad como domain (no importa mayúsculas/minúsculas), sólo se utiliza el registro de usuarios de dominio.
- Pulse .
- En el repositorio de cuentas de usuario, seleccione la lista desplegable Definiciones del reino disponibles, seleccione Sistema operativo local y pulse Configurar.
- En Propiedades adicionales, pulse Propiedades personalizadas.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
Utilización de registros de usuario de sistema
Cuando se utilizan registros de usuario de sistema, el ID de proceso que ejecuta el proceso de WebSphere Application Server necesita la autorización de root para llamar a las API de sistema operativo local para autenticar y obtener información de usuario o grupo.
Sólo se utiliza el registro de usuario de máquina local. NIS (Network Information Service) (Yellow Pages) no está soportado.
Si no utiliza el registro de usuarios del sistema operativo local, HP-UX debe configurarse en modalidad no de confianza. La modalidad de confianza no está soportada si utiliza el registro de usuarios del sistema operativo local.
Para que funcione el registro del sistema operativo local de WebSphere Application Server en las plataformas Linux y Solaris, debe existir un archivo de contraseñas oculto. El archivo de contraseñas oculto se denomina shadow y se encuentra en el directorio /etc. Si el archivo de contraseñas oculto no existe, se produce un error después de habilitar la seguridad administrativa y configurar el registro como sistema operativo local.
Para crear el archivo oculto, ejecute el mandato pwconv (sin parámetros). Este mandato crea un archivo /etc/shadow a partir del archivo /etc/passwd. Después de crear el archivo oculto, podrá habilitar la seguridad del sistema operativo local.