Iscriviti al feed

Se gestisci host Windows con Red Hat Ansible Automation Platform, questo articolo è per te! Esamineremo il plugin inventario di Active Directory, che aiuta a utilizzare Active Directory come fonte di attendibilità per Ansible Automation Platform. Iniziamo facendo un passo indietro, per scoprire perché la gestione dell'inventario è così importante.

Ansible Automation Platform è uno strumento di automazione semplice, potente e agentless.

introducing microsoft active directory inventory plug ansible

L'architettura agentless offre ampie e variegate possibilità di automazione, poiché non limita la gestione dei dispositivi su cui possiamo installare gli agenti. In questo mondo agentless, la gestione dell'inventario diventa un elemento fondamentale per la riuscita delle nostre iniziative. In genere sono necessarie le informazioni seguenti:

  • Quali dispositivi dobbiamo gestire? Dove possiamo reperire un elenco aggiornato e accurato della nostra infrastruttura?
  • Come classifichiamo i nodi in modo da sapere che tipo di automazione avviare? Ad esempio, l'automazione che eseguiamo su un database server sarà diversa da quella di un web server.

I plugin di inventario forniscono una soluzione efficace a questi problemi. Nella loro forma più semplice, sono script che ci consentono di puntare a una fonte di attendibilità dalla quale acquisire un elenco di server e caratteristiche che possono aiutarci a capire come applicare l'automazione.

Active Directory è una fonte di attendibilità molto interessante per la gestione di un ambiente Microsoft Windows, poiché i server sono in genere registrati in un dominio. Grazie a Red Hat Ansible Certified Content Collection per Microsoft AD, abbiamo a disposizione una vasta gamma di moduli capaci di interagire con Microsoft Active Directory e un plugin inventario che  può utilizzare Active Directory come fonte di attendibilità. Il plugin inventario ci permette di filtrare e raggruppare gli host in base agli attributi di Active Directory e alle appartenenze ai gruppi.

Vediamo ora come si comporta il plugin in azione.

Dalla riga di comando

Iniziamo dalla riga di comando utilizzando Automation Content Navigator e Automation Execution Environment. Le istruzioni per l'installazione e la configurazione di Automation Content Navigator sono disponibili nella documentazione relativa alla creazione dei contenuti. L'ambiente di esecuzione supportato fornito con Ansible Automation Platform 2.4 e versioni successive include tutto il necessario per avviare l'integrazione con Microsoft Active Directory, tra cui la raccolta [ microsoft.ad e le dipendenze Python necessarie. Per le versioni precedenti, potrebbe essere necessario personalizzare l'ambiente di esecuzione in modo da includere questi prerequisiti.

Puoi utilizzare il modulo  debug_ldap_client per verificare le dipendenze Python necessarie e la configurazione di DNS e Kerberos. Eseguiamo Automation Execution Environment all'interno dell'immagine per verificare la presenza delle dipendenze necessarie per il plugin inventario. Possiamo ignorare gli errori di traceback perché ci interessa soltanto verificare la presenza delle dipendenze Python necessarie al nostro scenario di utilizzo.

$ ansible-navigator exec -- ansible localhost -m microsoft.ad.debug_ldap_client
  < Output Truncated >
"packages": {
    "dnspython": "2.3.0",
    "krb5": "0.5.0",
    "pyspnego": "0.9.0",
    "sansldap": "0.1.0"

Per creare una definizione di inventario con cui eseguire query nel server Active Directory, il file di inventario deve terminare con microsoft.ad.ldap.yml o microsoft.ad.ldap.yaml, quindi lo chiameremo semplicemente microsoft.ad.ldap.yml. Per l'esecuzione del test utilizzo la configurazione seguente. So bene che il nome utente e la password sono in chiaro, ma servono solo per eseguire alcuni test di connessione iniziali, così da poter familiarizzare con alcuni degli attributi che poi utilizzeremo. Correggeremo le credenziali in seguito.

plugin: microsoft.ad.ldap
server: ms-ad.demolab.local
username: svc-aap-ldap
password: Redhat123
tls_mode: ldaps

A questo punto possiamo avviare il test del plugin dalla riga di comando utilizzando il sottocomando "inventory" del navigatore di Ansible Automation Platform. Poiché utilizziamo ldaps, eseguiamo il mapping del trust store dell'autorità di certificazione dall'host RHEL all'ambiente di esecuzione tramite il percorso /etc/pki/ca-trust.

Dall'esame dell'output emerge il rilevamento di un host chiamato MS-AD, che è il nostro controller di dominio. 

$ ansible-navigator inventory -i microsoft.ad.ldap.yml --list -m stdout --eev /etc/pki/ca-trust:/etc/pki/ca-trust:O
{
"_meta": {
    "hostvars": {
        "MS-AD": {
            "ansible_host": "ms-ad.demolab.local",
            "microsoft_ad_distinguished_name": "CN=MS-AD,OU=Domain Controllers,DC=demolab,DC=local"
        }
    }
},
"all": {
    "children": [
        "ungrouped"
    ]
},
"ungrouped": {
    "hosts": [
        "MS-AD"
    ]
}
}

La connettività sembra buona, ma le informazioni ricevute non sono sufficienti e non consentono di aggiungere l'host a nessun gruppo. Ci sono molti parametri documentati che possiamo aggiungere al plugin inventario per personalizzarlo in base alle nostre esigenze.

Infatti, tutti gli attributi dell'oggetto Computer di Active Directory possono essere utilizzati per filtrare e impostare variabili o raggruppare host. Per visualizzare tutti gli attributi disponibili per il nostro host MS-AD, utilizziamo il comando PowerShell seguente su un host Windows nel quale è installato il modulo PowerShell di Active Directory.

Get-ADComputer -Identity "MS-AD" -Properties *

Includiamo alcuni parametri aggiuntivi e iniziamo a raggruppare gli host. Aggiorniamo il file di configurazione dell'inventario - microsoft.ad.ldap.yml in modo da includere alcuni attributi aggiuntivi che recupereremo da Active Directory. Nel nostro esempio aggiornato, otteniamo gli attributi di "OperatingSystem" e "location", oltre a un elenco di tutti i gruppi a cui appartiene il computer. Forse la riga regex_search può sembrare complessa, ma l'ho copiata e incollata dalla documentazione.

L'ultima sezione della configurazione definisce i gruppi di Ansible Automation Platform in modo da poter classificare i nodi. Tutte le macchine vengono automaticamente aggiunte a un gruppo chiamato "windows". Inoltre, aggiungiamo qualsiasi host membro di un gruppo di dominio "Production" al gruppo corrispondente denominato "production". Infine, aggiungiamo gli host ai gruppi in base al sistema operativo e agli attributi della posizione. Ed ecco il file di configurazione finale ottenuto:

plugin: microsoft.ad.ldap
server: ms-ad.demolab.local
username: svc-aap-ldap
password: Redhat123
tls_mode: ldaps
attributes:
  OperatingSystem:
operating_system:
  location:
  memberOf:
computer_membership: this | map("regex_search", '^CN=(?P<name>.+?)((?<!\\),)', '\g<name>') | flatten
groups:
  windows: true
  production: '"Production" in computer_membership'
keyed_groups:
- key: operating_system | lower
  prefix: os
  default_value: unknown
- key: location | lower
  default_value: unknown
  prefix: location

Eseguiamo un ultimo test dalla riga di comando. Esaminiamo gli attributi recuperati da Active Directory. Il valore "__ansible_unsafe" impedisce agli utenti di  utilizzare in modo improprio il modello jinja2.

$ ansible-navigator inventory -i microsoft.ad.ldap.yml -m stdout --host MS-AD --eev /etc/pki/ca-trust:/etc/pki/ca-trust:O
{
    "ansible_host": "ms-ad.demolab.local",
    "computer_membership": [
    {
        "__ansible_unsafe": "Production"
    }
    ],
    "location": {
    "__ansible_unsafe": "london-dc1"
    },
    "microsoft_ad_distinguished_name": "CN=MS-AD,OU=Domain Controllers,DC=demolab,DC=local",
    "operating_system": {
    "__ansible_unsafe": "Windows Server 2019 Standard Evaluation"
    }
}

Esaminiamo ora l'appartenenza al gruppo. Al momento, il nostro server è membro di quattro gruppi di Ansible Automation Platform che possiamo utilizzare per indirizzarlo come necessario.

$ ansible-navigator inventory -i microsoft.ad.ldap.yml -m stdout --graph --eev /etc/pki/ca-trust:/etc/pki/ca-trust:O
@all:
  |--@_london_dc1:
  |  |--MS-AD
  |--@os_windows_server_2019_standard_evaluation:
  |  |--MS-AD
  |--@production:
  |  |--MS-AD
  |--@windows:
  |  |--MS-AD

Abbiamo completato il test. Vediamo ora come utilizzarlo in un ambiente enterprise con Automation Controller.

Configurazione di Automation Controller

Automation Controller permette alle aziende di standardizzare le modalità di deployment, avvio, delega e audit dell'automazione. Eliminiamo ora le credenziali in chiaro e applichiamo alcuni controlli alla configurazione dell'inventario.

  1. Crea un tipo di credenziale. Automation Controller ci permette di definire tipi di credenziali personalizzate per interagire con vari sistemi mantenendo il livello di sicurezza previsto. In questo modo possiamo inserire le variabili di ambiente nella fase di runtime, invece di averle come testo normale. Dalla documentazione del plugin inventario sappiamo che il plugin accetta diverse variabili di ambiente per l'autenticazione. Utilizzeremo queste variabili con Automation Controller.

    Nell'interfaccia utente di Automation Controller, passa a "Credential Types" e seleziona "Add". Assegna un nome al tipo di credenziale, nel nostro caso "Microsoft AD Inventory". Possiamo utilizzare i campi di "Input configuration" per definire i campi previsti per il nostro nome utente, password e server di AD.

    fields:
      - id: MICROSOFT_AD_LDAP_USERNAME
    type: string
    label: Username
      - id: MICROSOFT_AD_LDAP_PASSWORD
    type: string
    label: Password
    secret: true
      - id: MICROSOFT_AD_LDAP_SERVER
    type: string
    label: AD Server
    required:
      - MICROSOFT_AD_LDAP_USERNAME
      - MICROSOFT_AD_LDAP_PASSWORD
      - MICROSOFT_AD_LDAP_SERVER

    "injector configuration" definisce le variabili da inserire nella sincronizzazione dell'inventario. Utilizza le seguenti:

    env:
      MICROSOFT_AD_LDAP_SERVER: '{{ MICROSOFT_AD_LDAP_SERVER }}'
      MICROSOFT_AD_LDAP_PASSWORD: '{{ MICROSOFT_AD_LDAP_PASSWORD }}'
      MICROSOFT_AD_LDAP_USERNAME: '{{ MICROSOFT_AD_LDAP_USERNAME }}'

 

  1. Crea una credenziale.  Una volta creato un nuovo tipo di credenziale, possiamo creare una credenziale corrispondente. Passa a "Credentials" e fai clic su "Add". Seleziona il nuovo tipo di credenziale "Microsoft AD Inventory" e compila i campi relativi a nome utente, password e server Active Directory come abbiamo fatto dalla riga di comando.

  1. Crea un progetto. Intendiamo gestire la configurazione dell'inventario di Active Directory con il controllo della sorgente, in modo che il flusso delle modifiche passi per le revisioni paritarie e le approvazioni pertinenti. Un progetto in Automation Controller consente di eseguire il mapping a un repository di controllo della sorgente. Ho utilizzato la configurazione scritta per la riga di comando e l'ho inviata a un repository GitHub - https://github.com/pharriso/ansible_microsoft_ad_inventory

    IMPORTANTE! - Nome utente, password o server Active Directory non sono stati inviati al controllo della sorgente, ma ora sono gestiti con la nostra credenziale in Automation Controller. Rimuovi questi parametri dalla configurazione dell'inventario.

    Nell'interfaccia utente di Automation Controller, passa a "Projects" e fai clic su "Add". Di seguito sono riportati i dettagli del nostro progetto con l'URL di controllo della sorgente appropriato. Puoi trovare ulteriori informazioni sugli altri campi del progetto nella documentazione.

  1. Crea un inventario.  È il momento di creare il nostro inventario. Passa a "Inventories", fai clic su "Add" quindi su "Add Inventory". Assegna un nome appropriato all'inventario.

    Dopo aver premuto "Save", saranno disponibili ulteriori opzioni per l'inventario. Seleziona "Sources" e fai clic su "Add". A questo punto, uniremo la nostra configurazione selezionando il file di configurazione dell'inventario e la credenziale. La nostra fonte di attendibilità per l'inventario è completa.

    NOTA: qui l'unico intoppo è che devi inserire manualmente il nome del file di inventario e premere Invio per compilare il campo.

Dopo aver fatto clic su "Save", nella parte inferiore dello schermo viene visualizzato il pulsante "Sync". Premendolo, il nostro plugin inventario viene eseguito. Per osservare il progresso del plugin, utilizza le voci di menu "Last job status" o "Jobs". Ci auguriamo di visualizzare il messaggio "Success"!

Per convalidare la configurazione del plugin passa a "Inventories", "Demolab AD Inventory" e seleziona la scheda "Host". I nostri host sono stati importati:

Facendo clic sull'host è possibile visualizzare anche le variabili (attributi) acquisite da Active Directory. Infine, facciamo clic sulla scheda "Groups" per verificare di aver raggruppato correttamente l'host.

 

Passaggi successivi

La gestione dell'inventario è fondamentale per un'automazione ottimizzata e scalabile con Ansible Automation Platform. Il plugin inventario di Microsoft AD è solo un altro esempio del livello di semplificazione che Ansible Automation Platform è in grado di offrire agli utenti come noi. L'utilizzo di Active Directory come fonte di attendibilità può accelerare il percorso verso l'automazione di Ansible Automation Platform per Windows.


Sull'autore

Pat Harrison works for Red Hat in the UK as an Associate Principal Specialist Solution Architect focused on Ansible automation. Prior to this, Pat worked as a Red Hat Consultant helping to deliver solutions across various Red Hat products.
Read full bio
UI_Icon-Red_Hat-Close-A-Black-RGB

Ricerca per canale

automation icon

Automazione

Novità sull'automazione IT di tecnologie, team e ambienti

AI icon

Intelligenza artificiale

Aggiornamenti sulle piattaforme che consentono alle aziende di eseguire carichi di lavoro IA ovunque

open hybrid cloud icon

Hybrid cloud open source

Scopri come affrontare il futuro in modo più agile grazie al cloud ibrido

security icon

Sicurezza

Le ultime novità sulle nostre soluzioni per ridurre i rischi nelle tecnologie e negli ambienti

edge icon

Edge computing

Aggiornamenti sulle piattaforme che semplificano l'operatività edge

Infrastructure icon

Infrastruttura

Le ultime novità sulla piattaforma Linux aziendale leader a livello mondiale

application development icon

Applicazioni

Approfondimenti sulle nostre soluzioni alle sfide applicative più difficili

Original series icon

Serie originali

Raccontiamo le interessanti storie di leader e creatori di tecnologie pensate per le aziende