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.

Nota: En este tema se hace referencia a uno o más de los archivos de registro del servidor de aplicaciones. Como alternativa recomendada, puede configurar el servidor para utilizar la infraestructura de registro y rastreo HPEL en lugar de utilizar los archivos SystemOut.log , SystemErr.log, trace.log y activity.log en sistemas distribuidos y de IBM® i. Puede también utilizar HPEL junto con sus recursos de registro nativos de z/OS. Si utiliza HPEL, puede acceder a toda la información de registro y rastreo utilizando la herramienta de línea de mandatos LogViewer desde el directorio bin de perfil de servidor. Consulte la información sobre la utilización de HPEL para resolver problemas de aplicaciones para obtener más información sobre la utilización de HPEL.

[IBM i]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.

[IBM i]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

[AIX Solaris HP-UX Linux Windows]LDAP (Lightweight Directory Access Protocol) es un registro centralizado. La mayoría de los registros del sistema operativo local no son registros centralizados.

[AIX Solaris HP-UX Linux Windows]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]
Nota: Para un directorio activo (controlador de dominio), los tres ámbitos del grupo son Grupo local de dominio, Grupo global y Grupo universal. Para un directorio activo (controlador de dominio), los dos tipos de grupo son Seguridad y Distribución.
Cuando se crea un grupo, el valor predeterminado es Global y el tipo por omisión es Seguridad. Con el soporte de registros de dominio de Windows NT de los controladores de dominio de Windows 2003, WebSphere Application Server sólo da soporte a los grupos globales que sean del tipo Seguridad. Se recomienda utilizar el soporte de registro de Active Directory en lugar de un registro de dominio de Windows NT si utiliza los controladores de dominio de Windows 2003, ya que Active Directory da soporte a todos los ámbitos y tipos de grupo. Active Directory también da soporte a un grupo anidado que no está soportado por el registro de dominio de Windows NT. Active Directory es un registro de control centralizado.
Nota: WebSphere Application Server no tiene que instalar el miembro del dominio, ya que se puede instalar en cualquier máquina con cualquier plataforma. Tenga en cuenta que la llamada nativa del dominio de Windows NT sólo devuelve el grupo de soporte sin un error.

[AIX Solaris HP-UX Linux Windows][IBM i]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.

[AIX Solaris HP-UX Linux Windows]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.

[AIX Solaris HP-UX Linux Windows][IBM i]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.

[AIX Solaris HP-UX Linux Windows][IBM i]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][IBM i]Aunque los certificados de cliente Java funcionan correctamente, aparece el siguiente error en el archivo SystemOut.log:

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.

[z/OS]Un registro del sistema operativo local es un registro centralizado dentro de un sysplex.

[z/OS]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.

[z/OS]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]

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.
Si el usuario que ejecuta el servidor no tiene el privilegio necesario aparecerá uno de los siguientes mensajes de excepción en los archivos de registro cronológico:
  • El cliente no dispone de uno de los privilegios necesarios.
  • Se ha denegado el acceso.
Avoid trouble Avoid trouble: El servidor de aplicaciones debe iniciarse con privilegios de administrador si utiliza un indicador de mandatos. Inicie el servidor de aplicaciones desde una ventana de indicador de mandatos que se inicia realizando las acciones siguientes:
  • Pulse con el botón derecho del ratón sobre un acceso directo de indicador de mandatos.
  • Pulse Ejecutar como administrador.

    Cuando se abre la ventana indicador de mandatos como administrador, aparece un diálogo de sistema operativo que le pregunte si desea continuar. Pulse Continuar para continuar.

gotcha
[AIX Solaris HP-UX Linux Windows]

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]

Utilización del registro de usuarios de dominio y el registro del sistema operativo local

Cuando la máquina que alberga el proceso de WebSphere Application Server es miembro de un dominio, se utilizan por omisión el registro de usuarios local y el registro de usuarios de dominio. En el siguiente apartado se incluye más información sobre este tema y se recomiendan algunos procedimientos para evitar consecuencias negativas.
Nota: Aunque en esta sección no se describen directamente las consideraciones para z/OS, tenga en cuenta que las operaciones de seguridad general dependen de cómo configure estos registros.
  • 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.
  • Ejemplos
    La 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
    El dominio MiDominio contiene los siguientes usuarios y grupos:
    • MiDominio\usuario1
    • MiDominio\usuario2
    • MiDominio\grupo1
    • MiDominio\grupo2
    A continuación se describen algunos casos a partir del conjunto anterior de usuarios y grupos:
    1. 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.
    2. 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.
    3. 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.
    4. 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).
    5. 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.

Avoid trouble Avoid trouble: Antes de este fixpack, es posible que el registro de usuarios del sistema operativo local en sistemas UNIX no encuentre nombres de grupo si el registro contiene un gran número de grupos. Este problema surge de una limitación de memoria y normalmente se produce cuando el registro contiene varios cientos de grupos. A partir de este fixpack, el tamaño del almacenamiento intermedio puede alojar un número mayor de grupos. gotcha
[AIX Solaris HP-UX Linux Windows][IBM i]

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.

Establezca esta propiedad completando los siguientes pasos para acceder al panel Propiedades personalizadas en la consola administrativa:
  1. Pulse Seguridad > Seguridad global.
  2. En el repositorio de cuentas de usuario, seleccione la lista desplegable Definiciones del reino disponibles, seleccione Sistema operativo local y pulse Configurar.
  3. En Propiedades adicionales, pulse Propiedades personalizadas.
También puede utilizar wsadmin para configurar esta propiedad. Cuando se establece la propiedad, los requisitos de privilegio del usuario que ejecuta el proceso del producto no cambian. Por ejemplo, si la propiedad se establece como local, el usuario que ejecuta el proceso necesita el mismo privilegio que si no se hubiera establecido la propiedad.
[AIX Solaris HP-UX Linux Windows]

Utilización de registros de usuario de sistema

Cuando se utilizan registros de usuario de sistema se aplican las notas siguientes:
  • [AIX][HP-UX][Linux][Solaris]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.
  • [AIX][HP-UX][Linux][Solaris]Sólo se utiliza el registro de usuario de máquina local. NIS (Network Information Service) (Yellow Pages) no está soportado.
  • [HP-UX]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.
  • [Linux][Solaris]

    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.


Icon that indicates the type of topic Concept topic



Timestamp icon Last updated: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=csec_localos
File name: csec_localos.html