Checkmk
to checkmk.com
Important

This is a machine translation based on the English version of the article. It might or might not have already been subject to text preparation. If you find errors, please file a GitHub issue that states the paragraph that has to be improved.

1. Introducción

En este artículo aprenderás a configurar un inicio de sesión mediante el lenguaje de marcado de aserción segura (SAML) en Checkmk.

SAML es un método estandarizado para informar a aplicaciones y servicios externos de que un usuario es realmente quien dice ser. SAML hace posible el single sign-on, ya que permite autenticar a un usuario una sola vez y luego comunicar esa autenticación a múltiples aplicaciones. Gracias a la conexión y la comunicación entre el denominado «proveedor de servicios» (SP) y el denominado «proveedor de identidades» (IdP), los empleados pueden acceder a diversas aplicaciones web con un único inicio de sesión. En la arquitectura SAML, el proveedor de servicios pone a disposición la aplicación y el proveedor de identidades gestiona las identidades digitales de los usuarios.

SAML es compatible con las ediciones comerciales de Checkmk y se puede configurar directamente en la interfaz web de Checkmk. Checkmk asume el papel de proveedor de servicios. Por ejemplo, tal y como se describe en el capítulo de configuración, Entra ID es un ejemplo de proveedor de identidad.

Tip

Microsoft Entra ID (abreviado: Entra ID) es el nuevo nombre de Azure Active Directory (Azure AD) desde 2023. Sin embargo, las capturas de pantalla y el contenido de los archivos de configuración que aparecen en este artículo siguen utilizando el nombre antiguo, Azure AD.

CRE Hasta la versión 2.2.0 de Checkmk, como alternativa, SAML también era compatible con el módulo Apache mod_auth_mellon, que se suministraba como parte del software de Checkmk. A partir de la versión 2.3.0, mod_auth_mellon ya no se incluye en el software de Checkmk. Si quieres utilizar SAML como usuario de Checkmk Community CRE, debes instalar mod_auth_mellon por tu cuenta. La configuración basada en esto se describe en el capítulo de Checkmk Community. Sin embargo, ya no es compatible con nuestro soporte.

Tip

Todo el tema del cifrado de transporte (TLS/SSL) solo se incluye en los ejemplos en una implementación sencilla y de demostración. En entornos de producción con tu propia autoridad de certificación (CA) y el manejo adecuado de los certificados, habrá algunas diferencias que dependerán de tu propia infraestructura.

2. Uso de SAML en Checkmk

Una vez que hayas completado todos los pasos del proceso de configuración, el usuario podrá utilizar el inicio de sesión SAML en Checkmk. El texto del botón se puede personalizar, tal y como se describe a continuación.

Checkmk login with SAML button.

Cualquier usuario autorizado por SAML se creará automáticamente en Checkmk la primera vez que inicie sesión allí, siempre que no exista ya un usuario con el mismo ID. Si ya existe un usuario con el mismo ID, se rechazará la creación del usuario actual.

Los datos del usuario se sincronizarán cada vez que el usuario inicie sesión en Checkmk.

Para que SAML funcione, deben cumplirse varios requisitos previos:

  • La interfaz web debe estar protegida con HTTPS. Por motivos de seguridad, no se aceptan direcciones HTTP.

  • Los endpoints SAML de Checkmk para ID/metadatos y respuestas (Assertion Consumer Service) deben haberse registrado en el IdP. A continuación te mostramos cómo hacerlo.

  • Los mensajes que el IdP envía a Checkmk —respuestas a solicitudes de autenticación (obligatorias solo para la aserción) y declaraciones de atributos— deben estar firmados con uno de los algoritmos compatibles.

2.1. Algoritmos compatibles

Checkmk acepta los siguientes algoritmos para comunicarse con el IdP:

  • RSA-SHA256

  • RSA-SHA384

  • RSA-SHA512

  • ECDSA-SHA256

  • ECDSA-SHA384

  • ECDSA-SHA512

Checkmk utiliza RSA-SHA256 para firmar sus solicitudes.

Si el IdP no usa ninguno de los algoritmos anteriores para su respuesta, Checkmk la rechazará.

3. Configuración de SAML

Para poder usar SAML en las ediciones comerciales, primero hay que configurar el IdP. En nuestro ejemplo, se trata de Entra ID (llamado Azure Active Directory hasta 2023). Una vez hecho esto, se le proporciona al SP, es decir, a Checkmk, la información necesaria.

3.1. Iniciar sesión en Entra ID

Registrar el servicio SAML de Checkmk en Entra ID

A continuación, registra el servicio SAML de Checkmk en Entra ID. Para ello, ve a Enterprise applications > Create your own application.

Creating your own application in Entra ID.

Asigna un nombre arbitrario, preferiblemente significativo, por ejemplo, checkmk-saml. Recomendamos no nombrar la aplicación simplemente checkmk para evitar confusiones con el agente Checkmk.

Selecciona la opción Integrate any other application you don’t find in the gallery (Non-gallery) y, a continuación, haz clic en el botón Create.

En la página de vista general de Entra ID habrás creado la siguiente función: Single sign-on > SAML > Basic SAML Configuration:

Overview of application data in Entra ID.

En este punto, Entra ID te pedirá dos datos más:

  • el Identifier (Entity ID) en el formato https://myserver.com/mysite/check_mk/saml_metadata.py, y

  • el Reply URL (Assertion Consumer Service URL) en el formato https://myserver.com/mysite/check_mk/saml_acs.py?acs.

Deja todas las demás opciones sin cambiar, con su valor por defecto o vacías. En particular, el Relay State en Basic SAML Configuration debe permanecer sin cambios; de lo contrario, SAML no funcionará.

Ahora llama a Edit > Signing Option > Sign SAML assertion para configurar un Entra ID para las respuestas y verificaciones:

SAML access data in Entra ID.

Recuperación de la información SAML de Entra ID

A continuación, ve a Entra ID para encontrar la información SAML que necesitas para Checkmk.

Esto está disponible en la vista de tabla «Enterprise applications | All applications > Browse Microsoft Entra Gallery > checkmk-saml | SAML-based Sign-On» (ver arriba):

  • En la caja «SAML Certificates», busca el «App Federation Metadata URL». Lo necesitarás en la siguiente sección para configurar SAML en Checkmk (Identity provider metadata).

  • La caja «Attributes & Claims» te lleva a una vista de tabla de los atributos de usuario de Checkmk, por ejemplo, la dirección de correo electrónico, el nombre y los apellidos:

View of user attributes in Entra ID.

3.2. Activación de SAML en la interfaz web de Checkmk

Con la información obtenida anteriormente, configura la conexión SAML en el lado de Checkmk.

Si es necesario, añade el certificado TLS emitido por tu IdP a los certificados de confianza en Checkmk introduciéndolo en Setup > Global settings > Trusted certificate authorities for SSL.

Ahora abre Setup > Users > SAML authentication. Utiliza Add connection allí para empezar a configurar una nueva conexión:

The SAML connection in Checkmk.

Asigna un «Connection ID» y un «Name» a la nueva conexión. El «Name» se utilizará posteriormente para nombrar el botón de inicio de sesión de Checkmk.

A continuación, en la caja «Security», especifica si quieres proteger las conexiones de acceso con Checkmk o con tus propios certificados:

Selecting the certificate for SAML.

Si utilizas tus propios certificados, debes especificar el Private key y el Certificate. Los certificados personalizados se almacenan en el directorio del site bajo ~/etc/ssl/saml2/custom/.

A continuación, en la caja «Connection», introduce como «Identity provider metadata» la URL (por ejemplo, la URL de metadatos de App Federation) que seleccionaste tal y como se describe en la sección anterior:

Entering connection data.

También puedes descargar el archivo XML de metadatos directamente desde Entra ID y subirlo en el diálogo anterior con la opción «Upload XML file» en «Identity provider metadata». Esto resulta útil, por ejemplo, si tu servidor Checkmk no tiene acceso a internet. En el campo obligatorio «Checkmk server URL», introduce la dirección que tú —no Entra ID— utilizas normalmente para acceder a Checkmk, p. ej., https://myserver.com.

Ahora tendrás que introducir los datos de usuario en la caja Users:

Entering user information.

También debes obtener esta información tal y como se describe en la sección anterior. Es importante tener en cuenta que el User ID attribute debe ser único, por ejemplo, el ID de usuario. Checkmk requiere aquí el claim name completo de Entra ID, es decir, la dirección URL que empieza por http, para cada entrada; por ejemplo, en el ejemplo anterior, el ID de usuario es http://schemas.xmlsoap.org/ws/2005/05/identity/claims/userID.

Para definir las responsabilidades de todos los usuarios que se autentican con SAML en Checkmk, se puede asignar a cada usuario a uno o varios grupos de contacto. Tienes varias opciones para definir el mapeo en Contact groups.

Puedes usar el Roles para asignar usuarios a diferentes roles con el fin de definir usuarios normales, administradores, etc.

4. SAML en Checkmk Community

Important

La configuración que se describe en este capítulo solo es relevante para los usuarios de Checkmk Community que no pueden utilizar la conexión SAML integrada en las ediciones comerciales de Checkmk. El requisito previo es que hayas instalado el módulo de Apache mod_auth_mellon, que no se incluye con el software de Checkmk, en todo el sistema siguiendo las instrucciones de la página del proyecto. En este capítulo se describe la configuración basada en esto. Sin embargo, ya no ofrecemos soporte para la conexión SAML a través de mod_auth_mellon.

Las siguientes secciones solo describen la configuración de mod_auth_mellon para cualquier IdP que ya esté en funcionamiento, utilizando Active Directory Federation Services (ADFS) como ejemplo. La conexión en el propio Checkmk se limita al último paso de las instrucciones de ADFS. En el servidor Checkmk, mod_auth_mellon actúa como proveedor de servicios para las autenticaciones.

4.1. Iniciar sesión con los Servicios de federación de Active Directory

Requisitos previos

Iniciar sesión en Checkmk usando Active Directory es, básicamente, relativamente sencillo: Active Directory Federation Services (ADFS) actúa como proveedor de identidad (IdP), mientras que Checkmk proporciona la autenticación SAML.

Los requisitos previos para este tutorial son, por lo tanto:

  • Integración LDAP-AD en funcionamiento

  • ADFS operativo como IdP

  • Servidor Checkmk con SSL

  • Un sistema operativo compatible.

La configuración se realiza en tres pasos:

  1. Configuración de Apache (resultado: archivo XML con metadatos).

  2. Configuración de ADFS: establecer una relación de confianza con los metadatos de Mellon.

  3. Habilitación del inicio de sesión en el propio Checkmk.

Configuración de Apache

Por supuesto, se trata de configurar el servidor Apache del propio sitio, así que inicia sesión allí primero:

root@linux# omd su mysite
Copiar comando(s) al portapapeles
¡Comandos copiados correctamente al portapapeles!
¡Se ha denegado el acceso de escritura al portapapeles!

Ahora crea un directorio para mod_auth_mellon y switch a él:

OMD[mysite]:~$ mkdir etc/apache/mellon
OMD[mysite]:~$ cd etc/apache/mellon
Copiar comando(s) al portapapeles
¡Comandos copiados correctamente al portapapeles!
¡Se ha denegado el acceso de escritura al portapapeles!

Ahora ejecuta mellon_create_metadata especificando tu servidor y tu site con el sufijo mellon:

OMD[mysite]:~/etc/apache/mellon$ mellon_create_metadata https://myserver "https://myserver/mysite/mellon"
Copiar comando(s) al portapapeles
¡Comandos copiados correctamente al portapapeles!
¡Se ha denegado el acceso de escritura al portapapeles!

Este módulo genera tres archivos: certificado (.cert), clave (.key) y metadatos estáticos (.xml). El archivo .xml no es necesario y se puede eliminar:

OMD[mysite]:~/etc/apache/mellon$ rm *.xml
Copiar comando(s) al portapapeles
¡Comandos copiados correctamente al portapapeles!
¡Se ha denegado el acceso de escritura al portapapeles!

Cambia el nombre de los archivos de clave y certificado para simplificar:

OMD[mysite]:~/etc/apache/mellon$ mv .key mellon.key
OMD[mysite]:~/etc/apache/mellon$ mv .cert mellon.cert
Copiar comando(s) al portapapeles
¡Comandos copiados correctamente al portapapeles!
¡Se ha denegado el acceso de escritura al portapapeles!

Ahora obtén los metadatos necesarios directamente de tu servidor ADFS (aquí myadfs) y guárdalos como idp-metadata.xml:

OMD[mysite]:~/etc/apache/mellon$ wget --no-check-certificate -O ./idp-metadata.xml https://myadfs/FederationMetadata/2007-06/FederationMetadata.xml
Copiar comando(s) al portapapeles
¡Comandos copiados correctamente al portapapeles!
¡Se ha denegado el acceso de escritura al portapapeles!

Ahora necesitas el certificado público del servidor ADFS, que está almacenado en el archivo idp-public-key.pem:

OMD[mysite]:~/etc/apache/mellon$ echo -n | openssl s_client -connect myadfs:443 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | openssl x509 -pubkey -noout > idp-public-key.pem
Copiar comando(s) al portapapeles
¡Comandos copiados correctamente al portapapeles!
¡Se ha denegado el acceso de escritura al portapapeles!

Por si te estás preguntando qué es echo -n: Se utiliza para finalizar la siguiente sesión SSL.

Tip

El certificado debería, o incluso debe, cargarse en el almacén de confianza si, por ejemplo, el servicio IdP checkea la cadena de certificados. Para obtener más información sobre este tema, consulta el artículo sobre HTTPS.

Como paso final, sustituye el archivo de configuración de autenticación ~/etc/apache/conf.d/auth.conf por la siguiente variante, especificando, por supuesto, tu servidor Checkmk (aquí myserver) y tu site (aquí mysite). Ten en cuenta en el siguiente ejemplo de configuración que la ruta del directorio de instalación en la línea que comienza por LoadModule puede variar dependiendo de la distribución utilizada:

~/etc/apache/conf.d/auth.conf
# Set this to the Name of your {CMK} site, e.g.
#Define SITE
Define SITE mysite

# ServerName from listen-ports.conf needs to be overwritten here
# and being set to the URL of the real server. auth_mellon uses this
# to generate the needed URLs in the metadata
ServerName https://myserver

# Load the module.
<IfModule !mod_auth_mellon.c>

	LoadModule auth_mellon_module /usr/lib/apache2/modules/mod_auth_mellon.so

</IfModule>

# Only enable this for debugging purposes
#MellonDiagnosticsFile /opt/omd/sites/${SITE}/tmp/mellon_diagnostics.txt
#MellonDiagnosticsEnable On

<Location /${SITE}>

	# Use SAML auth only in case there is no {CMK} authentication
	# cookie provided by the user and whitelist also some other required URLs
	<If "! %{HTTP_COOKIE} =~ /^(.*;)?auth_${SITE}/ && \
		! %{REQUEST_URI} = '/${SITE}/check_mk/register_agent.py' && \
		! %{REQUEST_URI} = '/${SITE}/check_mk/deploy_agent.py' && \
		! %{REQUEST_URI} = '/${SITE}/check_mk/run_cron.py' && \
		! %{REQUEST_URI} = '/${SITE}/check_mk/restapi.py' && \
		! %{REQUEST_URI} = '/${SITE}/check_mk/automation.py' && \
		! %{REQUEST_URI} -strmatch '/${SITE}/check_mk/api/*' && \
		! %{REQUEST_URI} = '/${SITE}check_mk/ajax_graph_images.py' && \
		! %{QUERY_STRING} =~ /(_secret=|auth_|register_agent)/ && \
		! %{REQUEST_URI} =~ m#^/${SITE}/(omd/|check_mk/((images|themes)/.*\.(png|svg)|login\.py|.*\.(css|js)))# ">

		MellonIdPMetadataFile /opt/omd/sites/${SITE}/etc/apache/mellon/idp-metadata.xml
		MellonIdPPublicKeyFile /opt/omd/sites/${SITE}/etc/apache/mellon/idp-public-key.pem
		MellonSPCertFile /opt/omd/sites/${SITE}/etc/apache/mellon/mellon.cert
		MellonSPPrivateKeyFile /opt/omd/sites/${SITE}/etc/apache/mellon/mellon.key
		MellonEndpointPath "/${SITE}/mellon"
		MellonDefaultLoginPath "/${SITE}/check_mk/"

		Order allow,deny
		Allow from all

		MellonSecureCookie On
		MellonCookieSameSite None

		AuthType Mellon
		AuthName "{CMK} SAML Login"
		MellonEnable auth
		Require valid-user

		# Get Username
		# ADFS sends username as DOMAIN\username pair.
		# {CMK} just wants the username.
		RewriteEngine on
		RequestHeader set X-Remote-User "expr=%{REMOTE_USER}"
		RequestHeader edit X-Remote-User "^.*\\\(.*)$" "$1"

		# When SAML auth fails, show the login page to the user. This should only happen,
		# if e.g. the mellon cookie is lost/rejected or if the IDP is misconfigured.
		# A failed login at the IDP will not return you here at all.

    ErrorDocument 401 '<html> \
      <head> \
        <meta http-equiv="refresh" content="1; URL=/${SITE}/check_mk/login.py"> \
      </head> \
      <body> \
        SAML authentication failed, redirecting to login page. \
        <a href="/${SITE}/check_mk/login.py">Click here</a>. \
      </body> \
    </html>'

	</If>

	# This header is also needed after authentication (outside of the If clause)
	RequestHeader set X-Remote-User "expr=%{REMOTE_USER}"
	RequestHeader edit X-Remote-User "^.*\\\(.*)$" "$1"

</Location>
Copiar el contenido del archivo al portapapeles
¡Contenido del archivo copiado correctamente al portapapeles!
¡Se ha denegado el acceso de escritura al portapapeles!

A continuación, reinicia Apache:

OMD[mysite]:~/etc/apache/mellon$ omd restart apache
Copiar comando(s) al portapapeles
¡Comandos copiados correctamente al portapapeles!
¡Se ha denegado el acceso de escritura al portapapeles!

Por último, pero no menos importante, ahora descargas los metadatos de Mellon creados dinámicamente como un archivo XML para que puedas importarlos a AD Management de inmediato:

OMD[mysite]:~/etc/apache/mellon$ wget https://myserver/mysite/mellon/metadata -o metadata.xml
Copiar comando(s) al portapapeles
¡Comandos copiados correctamente al portapapeles!
¡Se ha denegado el acceso de escritura al portapapeles!

Configuración del directorio Active Directory

Para crear una relación de confianza de parte confiable en ADFS, haz lo siguiente:

Inicia la interfaz de ADFS:

saml adfs 01

Haz clic en «Add Relying Party Trust»:

saml adfs 02

Deja la opción en «Claims aware» y continúa con el botón «Start»:

saml adfs 03

Ahora selecciona «Import data on the relying party from a file» y especifica el archivo XML que acabas de descargar:

saml adfs 04

Puedes ignorar tranquilamente la advertencia WARN de «AD FS Management»:

saml adfs 05

En «Specify Display Name», introduce ahora «Checkmk» como nombre:

saml adfs 06

Al asignar permisos, con fines de prueba, para el Choose Access Control Policy puedes seleccionar primero el valor Permit everyone; más adelante deberás cambiarlo por Permit specific group.

saml adfs 07

Confirma el resumen en «Ready to Add Trust»:

saml adfs 08

Por último, confirma el diálogo «Finish» y mantén la checkmark en «Configure claims issuance policy for this application»:

saml adfs 09

Selecciona la confianza de la parte confiable que acabas de crear y, a continuación, inicia el editor con «Edit Claim Issuance Policy…​»:

saml adfs 10

Añade una nueva regla en el siguiente diálogo a través de «Add Rule…​»:

saml adfs 11

En el primer paso de «Select Rule Template», selecciona «Transform to Incoming Claim» y confirma:

saml adfs 12

En el segundo paso de Configure Rule, configura los siguientes valores:

  • Incoming claim type: Windows account name

  • Outgoing claim type: Name ID

  • Outgoing name ID format: Transient Identifier

saml adfs 13

Este paso también completa la configuración de ADFS. Ahora FS puede derivar la autenticación para Checkmk a partir de la autenticación de Windows, a la que le indicas que autentifique a los usuarios mediante solicitudes HTTP en el siguiente paso.

Configuración de Checkmk

En Checkmk, en Setup > General > Global Settings > User Interface > Authenticate users by incoming HTTP requests, en el Current settings, ahora solo tienes que activar la opción Activate HTTP header authentication.

saml adfs cmk

4.2. Información adicional para otros sistemas

Entra ID con mod_auth_mellon

Cuando Entra ID (llamado Azure Active Directory hasta 2023) actúa como IdP, hay algunas diferencias en el procedimiento de configuración; por ejemplo, el nombre de usuario se puede especificar directamente sin necesidad de reescribirlo.

Requisitos previos para la siguiente configuración de ejemplo:

  • Configura UserPrincipalName en la conexión LDAP como identificador (más información en la documentación de Microsoft).

  • Aplicación empresarial personalizada en Entra ID con UserPrincipalName como atributo «name» (para más información, consulta la documentación de Microsoft).

Ten en cuenta en la siguiente configuración de ejemplo que la ruta del directorio de instalación en la línea que empieza por LoadModule puede variar dependiendo de la distribución que uses:

~/etc/apache/conf.d/auth.conf
#Set this to the Name of your {CMK} site, e.g.
# Define SITE mysite
Define SITE mysite

# ServerName from listen-ports.conf needs to be overwritten here
# and being set to the URL of the real server.
# auth_mellon uses this to generate the needed URLs in the metadata.
ServerName https://myserver

# Load the module.
<IfModule !mod_auth_mellon.c>

	LoadModule auth_mellon_module /usr/lib/apache2/modules/mod_auth_mellon.so

</IfModule>

# Only enable this for debugging purposes
# MellonDiagnosticsFile /opt/omd/sites/${SITE}/tmp/mellon_diagnostics.log
# MellonDiagnosticsEnable On

<Location /${SITE}>

	# Use SAML auth only in case there is no {CMK} authentication
	# cookie provided by the user and whitelist also some other required URLs.
   <If "! %{HTTP_COOKIE} =~ /^auth_${SITE}/ && \
        ! %{REQUEST_URI} = '/${SITE}/check_mk/register_agent.py' && \
        ! %{REQUEST_URI} = '/${SITE}/check_mk/restapi.py' && \
        ! %{REQUEST_URI} = '/${SITE}/check_mk/run_cron.py' && \
	! %{REQUEST_URI} = '/${SITE}/check_mk/automation.py' && \
        ! %{REQUEST_URI} -strmatch '/${SITE}/check_mk/api/*' && \
        ! %{REQUEST_URI} = '/${SITE}/check_mk/deploy_agent.py' && \
		! %{REQUEST_URI} = '/${SITE}check_mk/ajax_graph_images.py' && \
        ! %{QUERY_STRING} =~ /(_secret=|auth_|register_agent)/ && \
		! %{REQUEST_URI} =~ m#^/${SITE}/(omd/|check_mk/((images|themes)/.*\.(png|svg)|login\.py|.*\.(css|js)))# ">

        RequestHeader unset X-Remote-User
        MellonIdPMetadataFile /opt/omd/sites/${SITE}/etc/apache/mellon/idp-metadata.xml
        # Azure-AD-specific: Not needed because in metadata:
        #MellonIdPPublicKeyFile /opt/omd/sites/${SITE}/etc/apache/mellon/idp-public-key.pem
        MellonSPCertFile /opt/omd/sites/${SITE}/etc/apache/mellon/mellon.cert
        MellonSPPrivateKeyFile /opt/omd/sites/${SITE}/etc/apache/mellon/mellon.key
        MellonEndpointPath "/${SITE}/mellon"
        MellonDefaultLoginPath "/${SITE}/check_mk/"

		Order allow,deny
		Allow from all

		MellonSecureCookie On
		MellonCookieSameSite None

		AuthType Mellon
		MellonEnable auth
		require valid-user

        # Azure-AD-specific:
        # Get Username
        # If your assertion offers the username for {CMK} in an attribute you can set it directly as the remote user (REMOTE_USER):
        MellonUser "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"
        RequestHeader set X-Remote-User "%{MELLON_http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name}e" env=MELLON_http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name

        # When SAML auth fails, show the login page to the user. This should only happen, if e.g. the mellon cookie is lost/rejected or if the IDP is misconfigured.
        # A failed login at the IDP will not return you here at all.
        ErrorDocument 401 '<html> \
          <head> \
            <meta http-equiv="refresh" content="1; URL=/${SITE}/check_mk/login.py"> \
          </head> \
          <body> \
            SAML authentication failed, redirecting to login page. \
            <a href="/${SITE}/check_mk/login.py">Click here</a>. \
          </body> \
        </html>'

	</If>

	# Azure-AD-specific:
	# This header is also needed after authentication (outside of the If clause)
	RequestHeader set X-Remote-User "%{MELLON_http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name}e" env=MELLON_http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name

</Location>
Copiar el contenido del archivo al portapapeles
¡Contenido del archivo copiado correctamente al portapapeles!
¡Se ha denegado el acceso de escritura al portapapeles!

NetIQ Access Manager

Cuando NetIQ Access Manager actúa como IdP, hay algunas diferencias en el procedimiento de configuración; por ejemplo, el nombre de usuario se puede especificar directamente sin necesidad de reescribirlo.

Ten en cuenta en el siguiente ejemplo de configuración que la ruta del directorio de instalación en la línea que empieza por LoadModule puede variar según la distribución que uses:

~/etc/apache/conf.d/auth.conf

# Set this to the Name of your {CMK} site, e.g.# Define SITE mysite
# Define SITE mysite
Define SITE mysite

# ServerName from listen-ports.conf needs to be overwritten here
# and being set to the URL of the real server. auth_mellon uses this to generate the needed URLs in the metadata.

ServerName https://myserver.mydomain.tld

# Load the module.
<IfModule !mod_auth_mellon.c>

	LoadModule auth_mellon_module /usr/lib/apache2/modules/mod_auth_mellon.so

</IfModule>

# Only enable this for debugging purposes
#MellonDiagnosticsFile /opt/omd/sites/${SITE}/tmp/mellon_diagnostics.log
#MellonDiagnosticsEnable On

<Location /${SITE}>

	# Use SAML auth only in case there is no {CMK} authentication
	# Cookie provided by the user and whitelist also some other required URLs.

    <If "! %{HTTP_COOKIE} =~ /^auth_${SITE}/ && \
        ! %{REQUEST_URI} = '/${SITE}/check_mk/register_agent.py' && \
        ! %{REQUEST_URI} = '/${SITE}/check_mk/run_cron.py' && \
        ! %{REQUEST_URI} = '/${SITE}/check_mk/deploy_agent.py' && \
        ! %{REQUEST_URI} = '/${SITE}/check_mk/restapi.py' && \
        ! %{REQUEST_URI} -strmatch '/${SITE}/check_mk/api/*' && \
		! %{REQUEST_URI} = '/${SITE}check_mk/ajax_graph_images.py' && \
        ! %{QUERY_STRING} =~ /(_secret=|auth_|register_agent)/ && \
		! %{REQUEST_URI} =~ m#^/${SITE}/(omd/|check_mk/((images|themes)/.*\.(png|svg)|login\.py|.*\.(css|js)))# ">

        MellonIdPMetadataFile /opt/omd/sites/${SITE}/etc/apache/mellon/idp-metadata.xml
        # NetIQ-specific: Not needed because in metadata:
        #MellonIdPPublicKeyFile /opt/omd/sites/${SITE}/etc/apache/mellon/idp-public-key.pem
        MellonSPCertFile /opt/omd/sites/${SITE}/etc/apache/mellon/mellon.cert
        MellonSPPrivateKeyFile /opt/omd/sites/${SITE}/etc/apache/mellon/mellon.key
        MellonEndpointPath "/${SITE}/mellon"
        MellonDefaultLoginPath "/${SITE}/check_mk/"

		Order allow,deny
		Allow from all

		MellonSecureCookie On
		MellonCookieSameSite None

		AuthType Mellon
		MellonEnable auth
		require valid-user


        # NetIQ-specific:
        # Even though it is set as 'optional' in https://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf
        # a NetIQ Access Manager requires it to be set.
        # Specified in oasis link above - line 396
        MellonOrganizationName "<countrycode>" "<your organisation name>"
        # Specified in oasis link above - line 443 / 452
        MellonOrganizationURL  "<countrycode>" "<your organisation url>"
        # Specified in oasis link above - line 454
        MellonOrganizationDisplayName "<countrycode>" "<your organisation display name>"

        # NetIQ-specific:
        # If your assertion offers the username for {CMK} in an attribute you can set it directly as the remote user (REMOTE_USER)
        MellonUser "myusername"

        # NetIQ-specific:
        # If the assertion does contain the username (and was set to MellonUser) then you can set the header directly.
        RequestHeader set X-Remote-User "expr=%{REMOTE_USER}"

    # When SAML auth fails, show the login page to the user. This should only happen,
    # if e.g. the mellon cookie is lost/rejected or if the IDP is misconfigured.
    # A failed login at the IDP will not return you here at all.
        ErrorDocument 401 '<html> \
          <head> \
            <meta http-equiv="refresh" content="1; URL=/${SITE}/check_mk/login.py"> \
          </head> \
          <body> \
            SAML authentication failed, redirecting to login page. \
            <a href="/${SITE}/check_mk/login.py">Click here</a>. \
          </body> \
        </html>'

# This header is also needed after authentication (outside of the If clause)
RequestHeader set X-Remote-User "expr=%{REMOTE_USER}"

</Location>
Copiar el contenido del archivo al portapapeles
¡Contenido del archivo copiado correctamente al portapapeles!
¡Se ha denegado el acceso de escritura al portapapeles!

5. Migrar usuarios existentes

Una vez que hayas habilitado SAML, puedes migrar a los usuarios existentes de una conexión basada en contraseña a la conexión SAML. Para ello, check las cuentas que quieras en la gestión de usuarios, en «Setup > Users > Users». A continuación, inicia la migración a través de «Migrate selected users».

List of users marked for migration.

En un paso intermedio, puedes eliminar cualquier atributo.

Dialog with user attributes that can be deleted.

Last modified: Mon, 08 Dec 2025 12:40:19 GMT via commit 40b37331d
En esta página