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. Introduzione

In questo articolo imparerai come configurare un login tramite Secure Assertion Markup Language (SAML) in Checkmk.

Il SAML è un metodo standardizzato per comunicare ad applicazioni e servizi esterni che un utente è effettivamente chi dice di essere. Il SAML rende possibile la single sign-on (autenticazione unica) perché può essere utilizzato per autenticare un utente una sola volta e poi comunicare tale autenticazione a più applicazioni. Grazie alla connessione e alla comunicazione tra il cosiddetto "Service Provider" (SP) e il cosiddetto "Identity Provider" (IdP), i dipendenti possono quindi accedere a varie applicazioni web con un unico login. Nell'architettura SAML, il Service Provider rende disponibile l'applicazione e l'Identity Provider si occupa della gestione delle identità digitali degli utenti.

SAML è supportato nelle edizioni commerciali di Checkmk e può essere configurato direttamente nell'interfaccia web di Checkmk. Checkmk assume il ruolo di Service Provider. Ad esempio, come descritto nel capitolo sulla configurazione, Entra ID è un esempio di Identity Provider.

Tip

Microsoft Entra ID (in breve: Entra ID) è il nuovo nome di Azure Active Directory (Azure AD) dal 2023. Tuttavia, le schermate e i contenuti dei file di configurazione presenti in questo articolo utilizzano ancora il vecchio nome Azure AD.

CRE Fino alla versione 2.2.0 di Checkmk, in alternativa, SAML era supportato anche dal modulo Apache mod_auth_mellon, fornito come parte del software Checkmk. A partire dalla versione 2.3.0, mod_auth_mellon non è più incluso nel software Checkmk. Se desideri utilizzare SAML come utente della Comunità Checkmk CRE, devi quindi effettuare l'installazione di mod_auth_mellon autonomamente. La configurazione basata su questo è descritta nel capitolo dedicato alla Comunità Checkmk. Tuttavia, non è più supportata da noi.

Tip

Il tema completo della crittografia di trasporto (TLS/SSL) è incluso negli esempi solo in una semplice implementazione dimostrativa. Negli ambienti di produzione con una tua Autorità di Certificazione (CA) e una corretta gestione dei certificati, ci saranno alcune differenze che dipenderanno dalla tua infrastruttura.

2. Utilizzo di SAML in Checkmk

Una volta completati tutti i passaggi del processo di configurazione, l'utente potrà utilizzare il login SAML in Checkmk. Il testo del pulsante può essere personalizzato, come descritto di seguito.

Checkmk login with SAML button.

Qualsiasi utente autorizzato da SAML verrà creato automaticamente in Checkmk al primo accesso, a condizione che non esista già un utente con lo stesso ID. Se esiste già un utente con lo stesso ID, la creazione dell'utente corrente verrà rifiutata.

I dati dell'utente verranno sincronizzati ogni volta che l'utente accede a Checkmk.

Per il corretto funzionamento di SAML devono essere soddisfatti diversi prerequisiti:

  • L'interfaccia web deve essere protetta con HTTPS. Per motivi di sicurezza, gli indirizzi HTTP non sono accettati.

  • Gli endpoint SAML di Checkmk per ID/metadati e risposte (Assertion Consumer Service) devono essere stati registrati presso l’IdP. Di seguito ti mostreremo come farlo.

  • I messaggi inviati dall'IdP a Checkmk — risposte alle richieste di autenticazione (obbligatorie solo per l'assertion) e dichiarazioni di attributi — devono essere firmati con uno degli algoritmi supportati.

2.1. Algoritmi supportati

Checkmk accetta i seguenti algoritmi per la comunicazione con l'IdP:

  • RSA-SHA256

  • RSA-SHA384

  • RSA-SHA512

  • ECDSA-SHA256

  • ECDSA-SHA384

  • ECDSA-SHA512

Checkmk utilizza RSA-SHA256 per firmare le proprie richieste.

Se l'IdP non utilizza nessuno degli algoritmi sopra indicati per la sua risposta, questa verrà rifiutata da Checkmk.

3. Configurazione di SAML

Per poter utilizzare SAML nelle edizioni commerciali, è necessario prima configurare l'IdP. Nel nostro esempio si tratta di Entra ID (chiamato Azure Active Directory fino al 2023). Una volta fatto questo, all'SP, ovvero Checkmk, vengono fornite le informazioni necessarie.

3.1. Accesso a Entra ID

Registrazione del servizio SAML di Checkmk in Entra ID

Successivamente, registra il servizio SAML di Checkmk su Entra ID. Per farlo, vai su Enterprise applications > Create your own application.

Creating your own application in Entra ID.

Assegna un nome a tua scelta, preferibilmente significativo, ad esempio checkmk-saml. Ti consigliamo di non chiamare l'applicazione semplicemente checkmk per evitare confusione con l'agente Checkmk.

Seleziona l'opzione Integrate any other application you don’t find in the gallery (Non-gallery) e poi clicca sul pulsante Create.

Nella pagina panoramica di Entra ID avrai creato la seguente funzione: Single sign-on > SAML > Basic SAML Configuration:

Overview of application data in Entra ID.

A questo punto, Entra ID richiederà altre due informazioni:

  • l'Identifier (Entity ID) nel formato https://myserver.com/mysite/check_mk/saml_metadata.py e

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

Lascia tutte le altre opzioni invariate al loro valore predefinito o vuote. In particolare, l'Relay Statee in Basic SAML Configuration deve rimanere invariato, altrimenti SAML non funzionerà.

Ora chiama Edit > Signing Option > Sign SAML assertion per configurare un Entra ID per le risposte e le verifiche:

SAML access data in Entra ID.

Recupero delle informazioni SAML da Entra ID

Successivamente, vai su Entra ID per trovare le informazioni SAML necessarie per Checkmk.

Sono disponibili nella visualizzazione Enterprise applications | All applications > Browse Microsoft Entra Gallery > checkmk-saml | SAML-based Sign-On (vedi sopra):

  • Nella box "SAML Certificates", trova l'App Federation Metadata URL". Ne avrai bisogno nella sezione successiva per configurare SAML in Checkmk (Identity provider metadata).

  • La box "Attributes & Claims" ti porta a una visualizzazione degli attributi utente per Checkmk, ad esempio indirizzo e-mail, nome e cognome:

View of user attributes in Entra ID.

3.2. Attivazione di SAML nell'interfaccia web di Checkmk

Con le informazioni ottenute in precedenza, configura la connessione SAML sul lato Checkmk.

Se necessario, aggiungi il certificato TLS emesso dal tuo IdP ai certificati attendibili in Checkmk inserendolo in Setup > Global settings > Trusted certificate authorities for SSL.

Ora apri Setup > Users > SAML authentication. Utilizza Add connection per iniziare a configurare una nuova connessione:

The SAML connection in Checkmk.

Assegna un nome a "Connection ID" e un nome a "Name" per la nuova connessione. Il nome "Name" verrà utilizzato in seguito per denominare il pulsante di login a Checkmk.

Successivamente, nella box Security, specifica se desideri proteggere le connessioni di accesso con Checkmk o con i tuoi certificati:

Selecting the certificate for SAML.

Se utilizzi i tuoi certificati, devi specificare l'Private key e l'Certificate. I certificati personalizzati sono memorizzati nella directory dell'istanza sotto ~/etc/ssl/saml2/custom/.

Successivamente, nella box Connection, come Identity provider metadata inserisci l'URL (ad es. App Federation Metadata URL) che hai selezionato come descritto nella sezione precedente:

Entering connection data.

In alternativa, puoi effettuare lo scaricamento del file XML dei metadati direttamente da Entra ID e caricarlo nella finestra di dialogo sopra indicata utilizzando l'opzione Upload XML file nell'opzione Identity provider metadata. Questo è utile, ad esempio, se il tuo server Checkmk non ha accesso all'internet. Per l'Checkmk server URL obbligatorio, inserisci l'indirizzo che tu — non Entra ID — utilizzi normalmente per accedere a Checkmk, ad esempio https://myserver.com.

Ora dovrai inserire i dati dell'utente nella box Users:

Entering user information.

Devi ottenere queste informazioni come descritto nella sezione precedente. È importante notare che l'User ID attribute deve essere univoco, ad esempio l'ID utente. Checkmk richiede qui l'claim namee completo da Entra ID, ovvero l'indirizzo URL che inizia con http, per ogni voce, ad esempio, nell'esempio sopra, l'ID utente è http://schemas.xmlsoap.org/ws/2005/05/identity/claims/userID.

Per definire le responsabilità di tutti gli utenti che si autenticano con SAML in Checkmk, ogni utente può essere assegnato a uno o più gruppi di contatto. Hai diverse opzioni per definire la mappatura nell'Contact groups.

Puoi utilizzare l'Roles per assegnare agli utenti diversi ruoli, in modo da definire utenti normali, amministratori, ecc.

4. SAML in Comunità Checkmk

Important

La configurazione descritta in questo capitolo è rilevante solo per gli utenti della Comunità Checkmk che non possono utilizzare la connessione SAML integrata nelle edizioni commerciali di Checkmk. Il prerequisito è che tu abbia installato il modulo Apache mod_auth_mellon , che non è fornito con il software Checkmk, a livello di sistema secondo le istruzioni riportate nella pagina del progetto. La configurazione basata su questo modulo è descritta in questo capitolo. Tuttavia, non supportiamo più la connessione SAML tramite mod_auth_mellon.

Le sezioni seguenti descrivono solo la configurazione di mod_auth_mellon per eventuali IdP già in esecuzione, utilizzando come esempio Active Directory Federation Services (ADFS). La connessione in Checkmk stesso si limita all'ultimo passaggio delle istruzioni ADFS. Sul server Checkmk, mod_auth_mellon funge da fornitore di servizi per le autenticazioni.

4.1. Accesso con Active Directory Federation Services

Prerequisiti

Accedere a Checkmk utilizzando Active Directory è fondamentalmente relativamente semplice: Active Directory Federation Services (ADFS) funge da Identity Provider (IdP), Checkmk fornisce l'autenticazione SAML.

I prerequisiti per questo tutorial sono quindi:

  • Integrazione LDAP-AD funzionante

  • ADFS funzionante come IdP

  • Server Checkmk con SSL

  • Un sistema operativo supportato.

Il Setup si svolge in tre passaggi:

  1. Configurazione di Apache (risultato: file XML con metadati).

  2. Configurazione di ADFS: impostazione di un rapporto di fiducia con i metadati Mellon.

  3. Abilitazione del login direttamente in Checkmk.

Configurazione di Apache

Ovviamente si tratta di configurare il server Apache dell’istanza, quindi accedi prima lì:

root@linux# omd su mysite
Copia i comandi negli appunti
Comandi copiati con successo negli appunti!
L'accesso in scrittura agli appunti è stato negato!

Ora crea una directory per mod_auth_mellon e switcha a quella:

OMD[mysite]:~$ mkdir etc/apache/mellon
OMD[mysite]:~$ cd etc/apache/mellon
Copia i comandi negli appunti
Comandi copiati con successo negli appunti!
L'accesso in scrittura agli appunti è stato negato!

Ora esegui mellon_create_metadata specificando il tuo server e la tua istanza con il suffisso mellon:

OMD[mysite]:~/etc/apache/mellon$ mellon_create_metadata https://myserver "https://myserver/mysite/mellon"
Copia i comandi negli appunti
Comandi copiati con successo negli appunti!
L'accesso in scrittura agli appunti è stato negato!

Questo modulo genera tre file: certificato (.cert), chiave (.key) e metadati statici (.xml). Il file .xml non è necessario e può essere eliminato:

OMD[mysite]:~/etc/apache/mellon$ rm *.xml
Copia i comandi negli appunti
Comandi copiati con successo negli appunti!
L'accesso in scrittura agli appunti è stato negato!

Rinomina i file delle chiavi e dei certificati per semplicità:

OMD[mysite]:~/etc/apache/mellon$ mv .key mellon.key
OMD[mysite]:~/etc/apache/mellon$ mv .cert mellon.cert
Copia i comandi negli appunti
Comandi copiati con successo negli appunti!
L'accesso in scrittura agli appunti è stato negato!

Ora recupera i metadati richiesti direttamente dal tuo server ADFS (in questo caso myadfs) e salvali come idp-metadata.xml:

OMD[mysite]:~/etc/apache/mellon$ wget --no-check-certificate -O ./idp-metadata.xml https://myadfs/FederationMetadata/2007-06/FederationMetadata.xml
Copia i comandi negli appunti
Comandi copiati con successo negli appunti!
L'accesso in scrittura agli appunti è stato negato!

Ora ti serve il certificato pubblico per il server ADFS, che è memorizzato nel file 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
Copia i comandi negli appunti
Comandi copiati con successo negli appunti!
L'accesso in scrittura agli appunti è stato negato!

Nel caso ti stessi chiedendo cosa sia echo -n: Viene utilizzato per terminare la seguente sessione SSL.

Tip

Il certificato dovrebbe, o addirittura deve, essere caricato nell'archivio di fiducia se, ad esempio, il servizio IdP verifica la catena di certificati. Per ulteriori informazioni su questo tema, consulta l'articolo HTTPS.

Come passo finale, sostituisci il file di configurazione dell'autenticazione ~/etc/apache/conf.d/auth.conf con la seguente variante, specificando ovviamente il tuo server Checkmk (qui myserver) e la tua istanza (qui mysite). Nota nell'esempio di configurazione seguente che il percorso della directory di installazione nella riga che inizia con LoadModule può variare a seconda della distribuzione utilizzata:

~/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>
Copia il contenuto del file negli appunti
Contenuto del file copiato con successo negli appunti!
L'accesso in scrittura agli appunti è stato negato!

Quindi riavvia Apache:

OMD[mysite]:~/etc/apache/mellon$ omd restart apache
Copia i comandi negli appunti
Comandi copiati con successo negli appunti!
L'accesso in scrittura agli appunti è stato negato!

Infine, effettua lo scaricamento dei metadati Mellon creati dinamicamente come file XML, così potrai importarli subito in AD Management:

OMD[mysite]:~/etc/apache/mellon$ wget https://myserver/mysite/mellon/metadata -o metadata.xml
Copia i comandi negli appunti
Comandi copiati con successo negli appunti!
L'accesso in scrittura agli appunti è stato negato!

Configurazione di Active Directory

Per creare un rapporto di fiducia tra parti affidabili in ADFS, procedi come segue:

Avvia l'interfaccia ADFS:

saml adfs 01

Fai clic su "Add Relying Party Trust":

saml adfs 02

Lascia l'opzione impostata su "Claims aware" e procedi con il pulsante "Start":

saml adfs 03

Ora seleziona "Import data on the relying party from a file" e specifica il file XML che hai appena effettuato lo scaricamento:

saml adfs 04

Puoi tranquillamente ignorare l'avviso WARN relativo a "AD FS Management":

saml adfs 05

In "Specify Display Name" inserisci ora "Checkmk" come nome:

saml adfs 06

Quando assegni i permessi, a scopo di test, per l'Choose Access Control Policy puoi selezionare inizialmente il valore Permit everyone; in seguito dovrai cambiarlo in Permit specific group.

saml adfs 07

Conferma il riepilogo sotto "Ready to Add Trust":

saml adfs 08

Infine, conferma il dialogo "Finish" e mantieni il segno di spunta su "Configure claims issuance policy for this application":

saml adfs 09

Seleziona l'affidabilità della parte affidabile che hai appena creato e poi avvia l'editor con Edit Claim Issuance Policy…​:

saml adfs 10

Aggiungi una nuova regola nel dialogo seguente tramite "Add Rule…​":

saml adfs 11

Nel primo passaggio di "Select Rule Template" seleziona "Transform to Incoming Claim" e conferma:

saml adfs 12

Nel secondo passaggio di Configure Rule imposta i seguenti valori:

  • Incoming claim type: Windows account name

  • Outgoing claim type: Name ID

  • Outgoing name ID format: Transient Identifier

saml adfs 13

Questo passaggio completa anche la configurazione di ADFS. FS ora può ricavare l'autenticazione per Checkmk dall'autenticazione di Windows, che nel passaggio successivo istruirai ad autenticare gli utenti tramite richieste HTTP.

Configurazione di Checkmk

In Checkmk, alla voce Setup > General > Global Settings > User Interface > Authenticate users by incoming HTTP requests, in Current settings devi ora solo attivare l'opzione Activate HTTP header authentication.

saml adfs cmk

4.2. Informazioni aggiuntive per altri sistemi

Entra ID con mod_auth_mellon

Quando Entra ID (chiamato Azure Active Directory fino al 2023) funge da IdP, ci sono alcune differenze nella procedura di configurazione; ad esempio, il nome utente può essere specificato direttamente senza bisogno di essere riscritto.

Prerequisiti per la seguente configurazione di esempio:

  • Imposta UserPrincipalName nella connessione LDAP come identificatore (maggiori informazioni nella documentazione Microsoft).

  • App aziendale personalizzata in Entra ID con UserPrincipalName come attributo "name" (per ulteriori informazioni, consulta la documentazione Microsoft).

Nota che nella seguente configurazione di esempio il percorso della directory di installazione nella riga che inizia con LoadModule può variare a seconda della distribuzione utilizzata:

~/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>
Copia il contenuto del file negli appunti
Contenuto del file copiato con successo negli appunti!
L'accesso in scrittura agli appunti è stato negato!

NetIQ Access Manager per la gestione

Quando NetIQ Access Manager funge da IdP, ci sono alcune differenze nella procedura di configurazione; ad esempio, il nome utente può essere specificato direttamente senza bisogno di essere riscritto.

Nota che nell'esempio di configurazione seguente il percorso della directory di installazione nella riga che inizia con LoadModule può variare a seconda della distribuzione utilizzata:

~/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>
Copia il contenuto del file negli appunti
Contenuto del file copiato con successo negli appunti!
L'accesso in scrittura agli appunti è stato negato!

5. Migrazione degli utenti esistenti

Una volta abilitato SAML, puoi migrare gli utenti esistenti da una connessione basata su password alla connessione SAML. Per farlo, check gli account desiderati nella gestione utenti alla voce "Setup > Users > Users". Quindi avvia la migrazione tramite "Migrate selected users".

List of users marked for migration.

In una fase intermedia, puoi far cancellare qualsiasi attributo.

Dialog with user attributes that can be deleted.

Last modified: Mon, 08 Dec 2025 12:40:19 GMT via commit 40b37331d
In questa pagina