IBM Cloud Docs
Abilitazione della gestione utenti per IBM Spectrum Symphony utilizzando Windows Active Directory

Abilitazione della gestione utenti per IBM Spectrum Symphony utilizzando Windows Active Directory

Introduzione

È possibile configurare IBM Spectrum Symphony per utilizzare il server Active Directory (AD) come servizio di directory primario per l'autenticazione degli utenti. Il documento illustra le procedure passo-passo per l'installazione e la configurazione di Active Directory e DNS Server su Windows Server 2019 utilizzando PowerShell. Inoltre, viene illustrato il processo di connessione del nodo Symphony Cluster basato sul sistema operativo RHEL 8.4 direttamente ad AD utilizzando Samba Winbind, per garantire la compatibilità della crittografia, e unendolo a un dominio Active Directory.

Lo scopo di questa documentazione è di consentire agli amministratori di sistema di configurare senza problemi IBM Spectrum Symphony con Active Directory per l'autenticazione degli utenti, consentendo una gestione efficiente degli utenti e il controllo degli accessi.

Prerequisiti generali

Prima di continuare con il processo di configurazione, assicurarsi che i prerequisiti siano soddisfatti:

  1. Per l'installazione e la configurazione di Active Directory e del server DNS:
    • Una macchina Windows Server 2019 con privilegi amministrativi.
    • Conoscenza di base dei comandi PowerShell e della gestione di Windows Server.
  2. Per la connessione dei sistemi RHEL direttamente ad AD utilizzando Samba Winbind:
    • Un sistema RHEL in grado di eseguire Samba Winbind.
    • Familiarità con l'interfaccia della riga comandi RHEL e la configurazione del sistema.
    • Accedere al dominio Active Directory e alle autorizzazioni appropriate per unirsi al dominio.

Prerequisiti di rete

Prima di continuare con la configurazione di IBM Storage Scale per utilizzare Active Directory e connettere i sistemi RHEL ad AD, assicurarsi che siano soddisfatti i seguenti requisiti di rete:

  1. Connettività di rete: hai bisogno di una connettività di rete stabile e affidabile tra la macchina Windows Server 2019 (dove sono installati Active Directory e DNS) e i sistemi RHEL che sono uniti al dominio. Verificare che non siano impostati problemi di comunicazione di rete o firewall che bloccano le porte essenziali.

  2. Regole del firewall: esaminare e aggiornare le regole del firewall per consentire la comunicazione necessaria tra la macchina Windows Server 2019, i sistemi RHEL e i controller di dominio. Le porte chiave utilizzate per le comunicazioni AD includono TCP/UDP 53 (DNS), TCP/UDP 88 (Kerberos), TCP 135 (RPC), TCP/UDP 389 (LDAP), TCP/UDP 445 (SMB) e TCP/UDP 636 (LDAPS).

  3. Raggiungibilità del controller di dominio: confermare che i sistemi RHEL possono raggiungere i controller di dominio Active Directory senza problemi di connettività. Utilizzare strumenti come "ping" o "nslookup" per verificare la capacità di risolvere il nome host e l'indirizzo IP del controller di dominio dai sistemi RHEL.

  4. Sincronizzazione dell'ora: verificare che tutti i sistemi che partecipano al dominio Active Directory, inclusi la macchina Windows Server 2019 e i sistemi RHEL, abbiano gli orologi sincronizzati con un'origine dell'ora affidabile. La sincronizzazione temporale è fondamentale per l'autenticazione corretta e la convalida del ticket Kerberos.

  5. Configurazione DNS dominio: il dominio Active Directory deve avere impostazioni DNS configurate correttamente. L'indirizzo IP del controller di dominio deve essere impostato come server DNS primario su tutti i sistemi (inclusi i sistemi Windows Server 2019 e RHEL) che fanno parte del dominio AD.

  6. Risoluzione DNS: verificare che le risoluzioni DNS di inoltro e di inversione funzionino correttamente. Il nome host del controller di dominio deve essere risolvibile dalla macchina Windows Server 2019 e dai sistemi RHEL e il nome host della macchina Windows Server 2019 deve essere risolvibile dai sistemi RHEL.

  7. Nome dominio DNS Assicurarsi che il nome dominio DNS di Active Directory corrisponda al nome dominio utilizzato durante il processo di configurazione. In questo caso, il nome dominio "POCDOMAIN.LOCAL" utilizzato per Active Directory deve essere congruente in tutta la configurazione.

  8. Account utente di Active Directory con privilegi amministrativi: verificare che sia disponibile un account utente di Active Directory con privilegi amministrativi da utilizzare durante il processo di configurazione. Questo account viene utilizzato per promuovere la macchina Windows Server 2019 come controller di dominio e per unire i sistemi RHEL al dominio AD.

Windows Server e Powershell

Per questa procedura è necessario:

  • Una macchina Windows Server 2019 con privilegi amministrativi.
  • Conoscenza di base dei comandi PowerShell e della gestione di Windows Server.

Passo 1 - Installazione e configurazione di Active Directory e DNS Server su Windows Server 2019 utilizzando PowerShell

  1. Aprire PowerShell con privilegi amministrativi:

    a. Premere i tasti "Windows + X" sulla tastiera per accedere al menu Power User.

    b. Dall'elenco, scegliere "Windows PowerShell (Admin.)" per avviare una sessione PowerShell elevata con privilegi amministrativi.

  2. Installare il ruolo dei servizi di dominio di Active Directory e il ruolo del server DNS eseguendo questi comandi PowerShell:

    powershell code
    # Install the Active Directory Domain Services Role and DNS Server Role
     Install-WindowsFeature -Name AD-Domain-Services, DNS -IncludeManagementTools
    
  3. Promuovere il Server ad un controller di dominio con DNS integrato eseguendo i comandi PowerShell:

    powershell code
    # Set the required parameters
    $DomainName = "POCDOMAIN.LOCAL"
    $SafeModePassword = ConvertTo-SecureString -AsPlainText "MySecureDSRMpwd2023!" -Force
    
    # Configure and promote the server as a domain controller with integrated DNS
    Install-ADDSForest -DomainName $DomainName -SafeModeAdministratorPassword  $SafeModePassword -DomainMode Win2019 -ForestMode Win2019 -InstallDNS
    

    Valori di esempio:

    • Nome dominio: POCDOMAIN.LOCAL
    • Password DSRM: MySecureDSRMpwd2023!

    Quando si eseguono i comandi PowerShell, i ruoli dei servizi di dominio di Active Directory e del server DNS vengono installati e configurati sul server.

    Il server viene riavviato automaticamente per completare il processo di promozione del controller di dominio.

  4. Una volta riavviato il server, accedere utilizzando l'account di amministratore del dominio creato durante il processo di promozione per verificare Active Directory e la configurazione DNS.

Verificare Active Directory e la configurazione DNS

Verificare che Active Directory e DNS siano configurati correttamente controllando:

  1. Verificare la gestione di Active Directory

    Aprire "Server Manager" e nel "Dashboard", confermare che "Active Directory Users and Computers" e "DNS" sono elencati in "Tools", che indica una corretta installazione di Active Directory e degli strumenti di gestione DNS.

  2. Avviare Active Directory Utenti e computer per gestire gli account utente, i gruppi e le unità organizzative (OU) all'interno del dominio.

  3. Accedere a Gestione DNS per gestire le zone DNS e i record per il dominio.

  4. Su una macchina client all'interno della stessa rete, configurare le impostazioni DNS in modo che puntino all'indirizzo IP del controller di dominio appena promosso.

  5. Tentativo di unire la macchina del client a "POCDOMAIN.LOCAL". Una connessione riuscita conferma la corretta risoluzione DNS e i servizi di dominio funzionali di Active Directory.

Passo 2 - Creazione di un gruppo utenti e di utenti in Active Directory per gli utenti che accedono al cluster Symphony

Creare un gruppo di utenti denominato "Symphony-group" e un utente denominato "Symphonyuser01" nel dominio Active Directory "pocdomain.local" utilizzando lo strumento di gestione ADUC ( Active Directory Users and Computers) su Windows Server:

La creazione di gruppi di utenti e utenti nel dominio "pocdomain.local" Active Directory richiede privilegi amministrativi all'interno di tale dominio. Assicurarsi di disporre delle autorizzazioni necessarie per creare gruppi e utenti. Inoltre, impostare sempre password complesse e seguire le procedure ottimali di sicurezza quando si creano account utente e gruppi in Active Directory per mantenere un ambiente di rete sicuro.

  1. Aprire Active Directory Utenti e computer:

    a. Accedere al server Windows con privilegi amministrativi.

    b. Fare clic su Avvia e cercare "Utenti e computerActive Directory ".

    c. Avviare la console di gestione "Active Directory Users and Computers".

  2. Creare un gruppo di utenti Gruppo Sinfonia:

    a. Nella console ADUC, passare all'unità organizzativa (OU) all'interno del dominio "pocdomain.local" in cui si desidera creare il gruppo di utenti.

    b. Fare clic con il pulsante destro del mouse sulla OU e selezionare Nuovo, quindi Gruppo.

    c. Nella finestra di dialogo Nuovo oggetto - Gruppo, immettere Gruppo Symphony come nome gruppo.

    d. Scegliere l'ambito del gruppo (ad esempio, Globale) e il tipo di gruppo (ad esempio, Sicurezza).

    e. Fare clic su OK per creare il gruppo utenti Symphony - group.

  3. Creare un utente Symphonyuser01:

    a. Nella console ADUC, passa alla stessa o a una OU (Organizational Unit) differente all'interno del dominio "pocdomain.local" in cui vuoi creare l'utente "Symphonyuser01."

    b. Fare clic con il pulsante destro del mouse sulla OU e selezionare Nuovo e quindi Utente.

    c. Nella finestra Nuovo oggetto - Utente, immettere le informazioni richieste per il nuovo utente *symphonyuser01:

    • Nome completo: immettere il nome completo dell'utente (ad esempio, utente LSF 01).

    • Nome di accesso utente: immettere il nome di accesso dell'utente (ad esempio, Symphonyser01).

    • UPN (User Principal Name): l'UPN viene generato automaticamente in base al nome di accesso utente e al nome dominio (ad esempio, Symphonyuser01@pocdomain.local).

    • Password: impostare una password protetta per l'account utente e scegliere se l'utente deve modificare la password al primo accesso.

    • L'utente non può modificare la password: selezionare questa opzione se si desidera impedire all'utente di modificare la password.

    • La password non scade mai: selezionare questa opzione se si desidera che la password dell'utente non scada mai.

    • L'account è disabilitato: per impostazione predefinita, l'account è abilitato. Se si desidera creare l'account utente in uno stato disabilitato, deselezionare questa opzione.

    d. Fare clic su Avanti per continuare con i passi aggiuntivi della procedura guidata.

    e. Esaminare le informazioni immesse e fare clic su Fine per creare il nuovo utente "Symphonyuser01."

  4. Aggiungere "Symphonyuser01" al gruppo utenti "Symphony-group":

    a. Nella console ADUC, individuare il gruppo utenti Symphony - group creato in precedenza.

    b. Fare clic con il pulsante destro del mouse sul gruppo utenti Symphony - group e selezionare Proprietà. c. Nella casella di dialogo Proprietà, andare alla scheda Membri.

    d. Fare clic su Aggiungi e quindi immettere Symphonyuser01 nel campo Immettere i nomi oggetto da selezionare.

    e. Fare clic su Verifica nomi per confermare il nome utente.

    f. Fare clic su OK per aggiungere "Symphonyuser01" al gruppo utenti "Symphony-group".

    es. Fare clic sul pulsante Applica e quindi su OK per salvare le modifiche.

Passo 3 - Integrazione del cluster Symphony in esecuzione su sistemi basati su RHEL 8.4 direttamente ad AD utilizzando Samba Winbind

Panoramica dell'integrazione diretta mediante Samba Winbind

Per connettere un sistema RHEL a Active Directory (AD), sono necessari due componenti: Samba Winbind e realmd. Samba Winbind interagisce con l'identità AD e l'origine di autenticazione, mentre realmd rileva i domini disponibili e configura i servizi di sistema RHEL sottostanti.

Piattaforme Windows e sistemi operativi supportati per l'integrazione diretta

L'integrazione diretta con le foreste AD è compatibile con i seguenti livelli funzionali di foresta e dominio:

  • Intervallo di livelli funzionali di Forest: Windows Server 2008 - Windows Server 2016
  • Intervallo di livello funzionale del dominio: Windows Server 2008 - Windows Server 2016

I sistemi operativi supportati per l'integrazione diretta includono:

  • Windows Server 2022 (RHEL 8.7 e successive)
  • Windows Server 2019
  • Windows Server 2016
  • Windows Server 2012 R2

Windows Server 2019 e Windows Server 2022 non introducono nuovi livelli funzionali e utilizzano il livello funzionale più alto di Windows Server 2016.

Garanzia del supporto per i tipi di crittografia comuni in AD e RHEL

Samba Winbind supporta i tipi di codifica RC4, AES-128e AES-256 Kerberos per impostazione predefinita. Tuttavia, la codifica RC4 è obsoleta e disabilitata per impostazione predefinita a causa di considerazioni sulla sicurezza. Le credenziali dell'utente AD e i trust possono ancora fare affidamento sulla crittografia RC4, causando problemi di autenticazione.

Per garantire la compatibilità, sono disponibili due opzioni:

  • Abilitare il supporto di codifica AES in Active Directory.
  • Abilitare il supporto RC4 in RHEL.

Per abilitare il supporto RC4 in RHEL, i passaggi variano a seconda della versione RHEL. Si consiglia di fare riferimento alla documentazione ufficiale per istruzioni dettagliate.

Unione del cluster Symphony con il nodo cluster Symphony

Samba Winbind è un'alternativa a System Security Services Daemon (SSSD) per la connessione di un sistema Red Hat Enterprise Linux (RHEL) con Active Directory (AD). Questa sezione descrive come unire un sistema RHEL a un dominio AD utilizzando realmd per configurare Samba Winbind.

Unire un nodo Symphony Cluster che si trova su RHEL 8.4 OS a un dominio AD utilizzando Samba Winbind e realmd:

  1. Installare e aggiornare i seguenti package:

    # yum install realmd oddjob-mkhomedir oddjob samba-winbind-clients \
    samba-winbind samba-common-tools samba-winbind-krb5-locator
    
    #yum update
    
  2. Aggiornamento di /etc/hosts con l'aggiunta di nome e IP del dominio AD. Ad esempio:

    [root@amit-rhel84 ~]# cat /etc/hosts
    127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
    ::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
    10.243.0.41 addc1.POCDomain.local
    

    addc1.POCDomain.local è il nome FQDN del server AD

  3. Aggiornare le voci DNS nel file /etc/resolv.conf utilizzando:

    sudo nmcli connection modify "System eth0" ipv4.dns "10.243.0.41" ipv4.ignore-auto-dns yes
    

    Questo comando non solo aggiorna le voci DNS nel file /etc/resolv.conf, ma garantisce anche che le voci DNS non vengano aggiornate automaticamente sui server DNS basati sul cloud

  4. Confermare le modifiche nel file DNS:

    [root@amit-rhel84 ~]# cat /etc/resolv.conf
    # Generated by NetworkManager
    nameserver 10.243.0.41
    [root@amit-rhel84 ~]#
    

    Oltre alla conferma, eseguire il ping del controller di dominio con il nome: - Ping POCDOMAIN.LOCAL:

    [root@amit-rhel84 ~]# ping POCDOMAIN.LOCAL
    PING POCDOMAIN.LOCAL (10.243.0.41) 56(84) bytes of data.
    64 bytes from addc1.POCDomain.local (10.243.0.41): icmp_seq=1 ttl=128 time=0.365 ms
    64 bytes from addc1.POCDomain.local (10.243.0.41): icmp_seq=2 ttl=128 time=0.722 ms
    64 bytes from addc1.POCDomain.local (10.243.0.41): icmp_seq=3 ttl=128 time=0.581 ms
    64 bytes from addc1.POCDomain.local (10.243.0.41): icmp_seq=4 ttl=128 time=0.525 ms
    
  5. Utilizzare nslookup per assicurarsi che il dominio AD sia risolvibile:

    [root@amit-rhel84 ~]#  nslookup pocdomain.local
    Server:         10.243.0.41
    Address:        10.243.0.41#53
    
    Name:   pocdomain.local
    Address: 10.243.0.41
    
  6. Se Active Directory richiede il tipo di crittografia RC4 obsoleto per l'autenticazione Kerberos, abilitare il supporto per queste cifrature in RHEL:

    # update-crypto-policies --set DEFAULT:AD-SUPPORT

    Dopo aver eseguito questo comando, vengono aggiornate le politiche di crittografia e viene richiesto di riavviare la macchina.

  7. Eseguire il backup del file di configurazione /etc/samba/smb.conf Samba esistente:

    # mv /etc/samba/smb.conf /etc/samba/smb.conf.bak

  8. Unire l'host RHEL 8.x al dominio Active Directory. Come indicato nell'esempio, per unire un dominio denominato POCDOMAIN.LOCAL:

    # realm join --membership-software=samba --client-software=winbind POCDOMAIN.LOCAL

    Quando si utilizza questo comando, il programma di utilità realm automaticamente:

    • Crea un file /etc/samba/smb.conf per un'appartenenza nel dominio pocdomain.local.
    • Aggiunge il modulo winbind per le ricerche di utenti e gruppi al file /etc/nsswitch.conf.
    • Aggiorna i file di configurazione PAM (Pluggable Authentication Module) nella directory /etc/pam.d/.
    • Avvia il servizio winbind e abilita il servizio all'avvio del sistema.
  9. (Facoltativo) Impostare un back-end di associazione ID alternativo o le impostazioni di associazione ID personalizzate nel file /etc/samba/smb.conf. Per ulteriori informazioni, consultare Understanding and configure Samba ID mapping.

  10. Modificare il file /etc/krb5.conf e aggiungere questa sezione:

[plugins]
localauth = {
module = winbind:/usr/lib64/samba/krb5/winbind_krb5_localauth.so
enable_only = winbind
}
  1. Verificare che il servizio winbind sia in esecuzione. Ad esempio:
#systemctl status winbind
[root@amit-rhel84 ~]# systemctl status winbind
winbind.service - Samba Winbind Daemon
Loaded: loaded (/usr/lib/systemd/system/winbind.service; enabled; vendor preset: disabled)
Active: active (running) since Wed 2023-08-09 08:16:16 EDT; 1h 42min ago
Docs: man:winbindd(8)
  man:samba(7)
  man:smb.conf(5)
Main PID: 4889 (winbindd)
Status: "winbindd: ready to serve connections..."
Tasks: 5 (limit: 49264)
Memory: 10.9M
CGroup: /system.slice/winbind.service
       ├─4889 /usr/sbin/winbindd --foreground --no-process-group
       ├─4893 /usr/sbin/winbindd --foreground --no-process-group
       ├─4894 /usr/sbin/winbindd --foreground --no-process-group
       ├─4924 /usr/sbin/winbindd --foreground --no-process-group
       └─5997 /usr/sbin/winbindd --foreground --no-process-group

Per consentire a Samba di interrogare le informazioni su utenti e gruppi del dominio, il servizio winbind deve essere in esecuzione prima di avviare smb.

Se è stato installato il pacchetto samba per condividere directory e stampanti, abilitare e avviare il servizio smb:

# systemctl enable --now smb

Passi di verifica

  1. Visualizza i dettagli degli utenti AD, come l'account amministratore AD nel dominio AD. Ad esempio:

    # getent passwd " POCDOMAIN\administrator"
    POCDOMAIN\administrator:*:2000500:2000513::/home/administrator@POCDOMAIN:/bin/bash
    
  2. Interrogare i membri del gruppo di utenti del dominio nel dominio AD:

    # getent group " POCDOMAIN\Domain Users"
    POCDOMAIN\domain users:x:2000513:
    
  3. (Facoltativo) Verificare che sia possibile utilizzare utenti e gruppi di domini quando si impostano le autorizzazioni su file e directory. Ad esempio, per impostare il proprietario del file /srv/samba/example.txt su AD\administrator e il gruppo su AD\Domain Users:

    # sudo chown "POCDOMAIN\administrator":"POCDOMAIN\Domain Users" example.txt
    
  4. Verificare che l'autenticazione Kerberos funzioni come previsto. Sul membro del dominio AD, ottenere un ticket per l'amministratore administrator@POCDOMAIN.LOCAL LOCALE:

    # kinit administrator@POCDOMAIN.LOCAL
    
  5. Visualizzare il ticket Kerberos memorizzato nella cache:

    # klist
    Ticket cache: KCM:0
    Default principal: Administrator@POCDOMAIN.LOCAL
    
    Valid starting       Expires              Service principal
    12/11/2023 08:26:47  12/11/2023 18:26:47  krbtgt/POCDOMAIN.LOCAL@POCDOMAIN.LOCAL
    	renew until 12/18/2023 08:26:23
    
    
  6. Visualizza i domini disponibili:

    #realm list
    pocdomain.local
      type: kerberos
      realm-name: POCDOMAIN.LOCAL
      domain-name: pocdomain.local
      configured: kerberos-member
      server-software: active-directory
      client-software: winbind
      required-package: oddjob-mkhomedir
      required-package: oddjob
      required-package: samba-winbind-clients
      required-package: samba-winbind
      required-package: samba-common-tools
      login-formats: POCDOMAIN\%U
      login-policy: allow-any-login
    #wbinfo --all-domains
    BUILTIN
    AD-CLIENT
    POCDOMAIN
    

Risorse aggiuntive- se non si desidera utilizzare le cifrature RC4 obsolete, è possibile attivare il tipo di cifratura AES in AD.

Per fornire le autorizzazioni utente root agli utenti di Active Directory (AD)

Per fornire le autorizzazioni utente root agli utenti AD di "POCDOMAIN.LOCAL" su una macchina Linux:

  1. Aprire un terminale o connettersi alla macchina Linux.

  2. Modificare il file sudoers utilizzando il comando visudo: sudo visudo

  3. Individuare la sezione nel file sudoers che configura i privilegi utente:

    # Allow root to run any commands anywhere root ALL=(ALL) ALL

  4. Aggiungere la seguente riga sotto la voce utente root per consentire agli utenti AD del gruppo "POCDOMAIN\Domain Administrators" di eseguire comandi con privilegi root: %POCDOMAIN\\Domain\ Administrators ALL=(ALL) ALL

    Questa riga concede i privilegi utente root a tutti gli utenti AD nel gruppo "POCDOMAIN\Domain Users". Le doppie barre retroverse ("") vengono utilizzati per eseguire l'escape dei caratteri speciali.

  5. Salvare le modifiche al file sudoers e uscire dall'editor. Gli utenti AD che sono membri del gruppo "POCDOMAIN\Domain Users" possono ora eseguire i comandi con privilegi root utilizzando il comando sudo. Ad esempio: sudo command_to_execute_as_root

    Quando richiesto, l'utente AD deve immettere la propria password per autenticarsi ed eseguire il comando con privilegi elevati.

Prestare attenzione quando si concedono le autorizzazioni utente root agli utenti AD. È importante concedere questi privilegi solo a persone affidabili che li richiedono per attività specifiche. Rivedere regolarmente i privilegi utente e seguire le procedure ottimali di sicurezza aiuta a mantenere un ambiente di sistema sicuro.

Passo 4 - Configurazione dell'impostazione sul lato cluster Symphony

Di seguito sono riportati i passaggi per configurare l'autenticazione Kerberos su host Linux per IBM Spectrum Symphony l'integrazione con Active Directory:

  1. Arresta il cluster

    Accedere a qualsiasi host di gestione nel cluster utilizzando le credenziali di amministratore del cluster.

    #Example
    egosh user logon –u Admin –x Admin
    

    Eseguire i seguenti comandi per arrestare correttamente il cluster:

    #Example
    soamcontrol app disable all
    egosh service stop all
    egosh ego shutdown all
    
  2. Modificare la configurazione della sicurezza sugli host di gestione: Su ciascun host di gestione, modificare il file $EGO_CONFDIR/ego.conf.

    Impostare EGO_SEC_PLUGIN su "sec_ego_gsskrb."

    #Example
    EGO_SEC_PLUGIN=sec_ego_gsskrb
    

    Impostare EGO_SEC_CONF per specificare la configurazione del plug - in:

    #Example
    EGO_SEC_CONF="/EGOShare/kernel/conf,600,ERROR,/opt/EGO/kernel/log"
    

    Impostare EGO_SEC_KRB_SERVICENAME sul principal Kerberos per il server di autenticazione:

    #Example
    EGO_SEC_KRB_SERVICENAME=symphonyuser03
    

    Creare o modificare il file $EGO_CONFDIR/sec_ego_gsskrb.conf con i parametri forniti:

    #Example
    REALM=POCDomain.local
    KRB5_KTNAME=/etc/krb5.keytab
    KERBEROS_ADMIN=egoadmin
    

    KRB5_KTNAME=/etc/krb5.keytab Il parametro KRB5_KTNAME indica il percorso assoluto del file keytab. Questo file contiene le chiavi per il principal del servizio utilizzato nell'autenticazione Kerberos. Qui, il percorso è impostato su "/etc/krb5.keytab," assicurando che le chiavi necessarie vengano richiamate per l'autenticazione.

    KERBEROS_ADMIN=egoadmin Il parametro KERBEROS_ADMIN specifica il principal Kerberos che si associa al nome utente dell'amministratore del cluster integrato (Admin). In questa configurazione, è impostato su "hpcegoadmin". Questo principale è importante per le attività amministrative all'interno del cluster IBM Spectrum Symphony ed è usato per autenticarsi come amministratore del cluster.

  3. Applica configurazione a host di calcolo e client.

    Ripetere i passi di modifica sugli host di calcolo e client, modificando le configurazioni nei rispettivi file $EGO_CONFDIR/ego.conf e $EGO_CONFDIR/sec_ego_gsskrb.conf.

  4. Avviare il Cluster e abilitare le applicazioni.

    Una volta applicate le configurazioni tra gli host, avviare il cluster e abilitare le applicazioni utilizzando i seguenti comandi:

    #Example
    egosh ego start
    soamcontrol app enable appName
    
  5. Accedere all'host di gestione cluster.

    Da un host di gestione nel realm POCDomain.local, accedere come utente Admin utilizzando la riga comandi egosh. Immettere la parola d'ordine del principal Kerberos definito nel parametro KERBEROS_ADMIN.

    #Example
    egosh user logon –u Admin –x passwordegoadmin
    
  6. Aggiungi utenti AD (se richiesto)

    Se il parametro ENABLE_AD_USERS_MANAGE nel file $EGO_CONFDIR/sec_ego_gsskrb.conf sugli host di gestione Linux è stato impostato su 'N', utilizzare il comando egosh user add per aggiungere utenti AD a IBM Spectrum Symphony. Fornire qualsiasi stringa casuale come password; non verrà utilizzata per l'accesso dell'utente.

    #Example egosh user add –u ad1tester –x 111
    
  7. Assegna ruoli agli utenti

    Assegnare i ruoli agli account utente utilizzando il comando egosh user assignrole. Ad esempio, per assegnare il ruolo consumer admin a ad1tester e ad2tester:

    #Example
    egosh user assignrole –u ad1tester –r CONSUMER_ADMIN –p /SymTesting/Symping73.2
    
  8. Accedi come utente AD

    Accedere come utente AD utilizzando la riga comandi egosh. Ad esempio, per accedere come ad1tester:

    #Example
    egosh user logon –u ad1tester –x passwordad1tester
    

Conclusione

Questa guida è una risorsa fondamentale per gli amministratori di sistema che desiderano integrare perfettamente IBM Spectrum Symphony con Active Directory all'interno dell'ambiente IBM Cloud. Affrontando i prerequisiti e fornendo istruzioni passo-passo, garantisce la prontezza sia per Active Directory che per i sistemi RHEL distribuiti su IBM Virtual Servers. Dall'installazione di Active Directory su Windows Server 2019 alla configurazione dell'autenticazione Kerberos, la guida fornisce agli amministratori un riferimento affidabile per ottenere una gestione efficiente degli utenti e il controllo degli accessi per IBM Spectrum Symphony all'interno dell'infrastruttura IBM Cloud.