Risoluzione dei problemi di accesso remoto in un'infrastruttura ACI

Aggiornato:9 aprile 2026
ID documento:225717

Linguaggio senza pregiudizi

La documentazione per questo prodotto è stata redatta cercando di utilizzare un linguaggio senza pregiudizi. Ai fini di questa documentazione, per linguaggio senza di pregiudizi si intende un linguaggio che non implica discriminazioni basate su età, disabilità, genere, identità razziale, identità etnica, orientamento sessuale, status socioeconomico e intersezionalità. Le eventuali eccezioni possono dipendere dal linguaggio codificato nelle interfacce utente del software del prodotto, dal linguaggio utilizzato nella documentazione RFP o dal linguaggio utilizzato in prodotti di terze parti a cui si fa riferimento. Scopri di più sul modo in cui Cisco utilizza il linguaggio inclusivo.

Informazioni su questa traduzione

Cisco ha tradotto questo documento utilizzando una combinazione di tecnologie automatiche e umane per offrire ai nostri utenti in tutto il mondo contenuti di supporto nella propria lingua. Si noti che anche la migliore traduzione automatica non sarà mai accurata come quella fornita da un traduttore professionista. Cisco Systems, Inc. non si assume alcuna responsabilità per l’accuratezza di queste traduzioni e consiglia di consultare sempre il documento originale in inglese (disponibile al link fornito).

    Introduzione

    In questo documento viene descritto come verificare, risolvere e risolvere i problemi di accesso remoto in un fabric Cisco ACI (Application Centric Infrastructure). Copre l'accesso Secure Shell (SSH) e il protocollo HTTPS (Hypertext Transfer Protocol Secure) alle interfacce APIC e agli switch fabric, l'autenticazione remota, l'autorizzazione e l'accounting (AAA) con il sistema di controllo di accesso TACACS+ (Terminal Access Control System Plus), il servizio RADIUS (Remote Authentication Dial-In User Service) e il protocollo LDAP (Lightweight Directory Access Protocol), nonché l'autorizzazione RBAC (Role-Based Access Control). Per ogni area sono inclusi un albero decisionale e scenari di risoluzione dei problemi dettagliati.

    Premesse

    Il materiale tratto da questo documento è stato sintetizzato dal capitolo Risoluzione dei problemi relativi alla gestione ACI e ai servizi di base — Pod Policies guide, Cisco APIC Basic Configuration Guide, versione 6.1(x) — Management, e dal capitolo Cisco APIC Security Configuration Guide — Access, Authentication, and Accounting.

    Panoramica

    L'accesso remoto a un fabric ACI comporta tre livelli distinti, ognuno dei quali deve essere in funzione per consentire al tecnico di accedere e operare correttamente:

    1. Trasporto: il percorso della rete di gestione (OOB o in-band) e il servizio del protocollo (SSH o HTTPS) devono essere raggiungibili e abilitati.
    2. Autenticazione: le credenziali dell'utente devono essere convalidate localmente sull'APIC o su un server AAA remoto (TACACS+, RADIUS o LDAP).
    3. Autorizzazione: all'utente autenticato devono essere assegnati i ruoli RBAC e i domini di sicurezza corretti per poter visualizzare e modificare gli oggetti ACI desiderati.

    Un guasto a qualsiasi livello produce sintomi diversi. Un errore di trasporto impedisce completamente la connessione. Un errore di autenticazione restituisce un errore di credenziali. Un errore di autorizzazione consente l'accesso ma limita la visibilità o produce 403 errori di tipo "Accesso negato" nell'API.

    Criteri di accesso alla gestione

    Il criterio di accesso alla gestione (commPol) è l'oggetto centrale che controlla quali protocolli di accesso remoto sono abilitati nell'infrastruttura. È disponibile in Fabric > Fabric Policies > Policies > Pod > Management Access > default (Fabric > Criteri fabric > Criteri > Pod > Accesso gestione > predefinito). Il criterio contiene oggetti figlio che consentono di configurare:

    • SSH (commSsh): stato amministrativo, porta, cifrari, algoritmi Key Exchange (KEX), codici MAC (Message Authentication Codes) e algoritmi a chiave host.
    • HTTPS (commHttps): stato amministrativo, porta, versione del protocollo TLS (Transport Layer Security), velocità e autenticazione del certificato client.
    • Telnet (commTelnet): stato amministrativo e porta. Telnet è disabilitato per impostazione predefinita e Cisco consiglia di conservarlo.

    Gestione fuori banda e in banda

    I nodi ACI supportano due percorsi di accesso per la gestione:

    • Fuori banda (OOB): utilizza la porta di gestione dedicata sull'APIC o sullo switch. Gli indirizzi di gestione OOB vengono allocati da un pool sotto il tenant mgmt e assegnati ai nodi tramite mgmtRsOoBStNode. Sull'APIC, i contratti OOB vengono fatti rispettare attraverso delle iptables regole. Se viene applicato un contratto OOB, solo il traffico esplicitamente autorizzato dal contratto può raggiungere l'interfaccia di gestione APIC.
    • In-Band (INB): utilizza il data plane fabric per il traffico di gestione. La gestione in-band richiede l'assegnazione di un dominio Bridge (BD), una subnet, un gruppo di endpoint (EPG), un contratto e un indirizzo di gestione dei nodi. Gli indirizzi IP in-band non sono raggiungibili dall'esterno dell'infrastruttura senza routing o configurazione dei criteri aggiuntivi.

    Nota: Gli IP di gestione OOB APIC vengono configurati durante la configurazione iniziale e l'APIC ottiene la connettività IP prima che la struttura venga rilevata completamente. OOB è il percorso di gestione principale ed è sempre disponibile se la rete di gestione fisica è connessa.

    Architettura AAA

    ACI utilizza un modello AAA a tre livelli:

    1. Dominio di accesso (aaaLoginDomain): raggruppa i provider AAA in un realm denominato. Gli utenti specificano il dominio di accesso nella schermata di accesso (ad esempio, apic:TACACS-Domain o tramite l'elenco a discesa nell'interfaccia utente). Un dominio di accesso di fallback speciale esiste sempre ed è mappato all'autenticazione locale.
    2. Gruppo di provider (aaaTacacsPlusProviderGroup, aaaRadiusProviderGroup, aaaLdapProviderGroup): fa riferimento a uno o più server AAA e definisce l'ordine in cui vengono utilizzati.
    3. Provider (aaaTacacsPlusProvider, aaaRadiusProvider, aaaLdapProvider): definisce l'IP, la porta, il segreto condiviso (o il DN di binding per LDAP) del server, il timeout, i tentativi, la gestione EPG e le credenziali di monitoraggio.

    Il Realm di autenticazione predefinito (aaaDefaultAuth) determina il dominio di accesso utilizzato quando l'utente non ne specifica uno al momento dell'accesso. Il realm di autenticazione della console controlla l'autenticazione per le sessioni della console.

    Nota: La modifica del realm di autenticazione predefinito in un server AAA remoto quando il server non è raggiungibile blocca l'utente all'esterno dell'infrastruttura. Verificare sempre la connettività del server AAA prima di modificare il realm. Il dominio di accesso di fallback (apic:fallback\\admin) può essere utilizzato per ignorare il realm predefinito e autenticarlo localmente.

    File di log AAA chiave

    Gli eventi di autenticazione AAA vengono registrati in diversi file su entrambi gli switch APIC e fabric. Questi registri sono lo strumento principale per la convalida dei risultati dell'autenticazione, l'identificazione del realm e del gruppo di provider in uso e la diagnosi degli errori di assegnazione dei ruoli.

    File di log Posizione (APIC) Posizione (Switch) Descrizione
    nginx.bin.log (APIC)
    nginx.log (switch)    		 /var/log/dme/log/nginx.bin.log /var/sysmgr/tmp_logs/dme_logs/nginx.log Registro AAA primario. Contiene il flusso di autenticazione completo: richiesta PAM, selezione del realm, ricerca del provider, comunicazione LDAP/TACACS+/RADIUS, analisi della coppia AV, assegnazione di domini e ruoli e esito positivo o negativo. Il nome del file varia a seconda della piattaforma, ma il formato del contenuto è lo stesso.
    file access.log /var/log/dme/log/access.log /var/log/dme/log/access.log Registro richieste HTTP NGINX. Una riga per richiesta API. Nell'interfaccia APIC, visualizza le chiamate aaaLogin e aaaRefresh con codici di stato HTTP (200 = operazione riuscita, 401 = operazione negata). Sugli switch, mostra le richieste API DME interne e le chiamate aaaRefresh.
    modulo.pam.log /var/log/dme/log/pam.module.log /var/log/dme/log/pam.module.log Registro del modulo PAM. Mostra il risultato dell'autenticazione per le sessioni SSH: utente autenticato, IP di origine e ID utente UNIX assegnato. Sugli switch, questo è il modo più rapido per confermare se un utente è stato autenticato o rifiutato.

    Nota: Il nome del file di registro AAA primario è diverso su ciascuna piattaforma. Nell'APIC, il valore è nginx.bin.log /var/log/dme/log/log. Sugli switch a foglia e sul dorso, è nginx.log in /var/sysmgr/tmp_logs/dme_logs/. Il formato del contenuto del log e i messaggi AAA sono gli stessi su entrambe le piattaforme.

    Le voci AAA nel registro Inginx hanno il seguente formato:

    PID||TIMESTAMP||aaa||SEVERITY||CONTEXT||MESSAGE||SOURCE_FILE||LINE

    Filtra le voci del log relative al server AAA per il flusso di autenticazione di un utente specifico:

    ! On the APIC:
apic1# grep '||aaa||' /var/log/dme/log/nginx.bin.log | grep -i 'username' | tail -20

! On a leaf or spine switch:
leaf101# grep '||aaa||' /var/sysmgr/tmp_logs/dme_logs/nginx.log | grep -i 'username' | tail -20

    Oppure visualizza tutte le richieste e i risultati di autenticazione recenti:

    ! On the APIC:
apic1# grep '||aaa||' /var/log/dme/log/nginx.bin.log | grep -i 'PAM authenticate\|was denied\|Unauthorized\|DENIED' | tail -20

! On a leaf or spine switch:
leaf101# grep '||aaa||' /var/sysmgr/tmp_logs/dme_logs/nginx.log | grep -i 'PAM authenticate\|was denied\|Unauthorized\|DENIED' | tail -20

    In genere, un flusso di autenticazione corretto visualizza questi messaggi chiave in ordine:

    1. Ricevuta richiesta di autenticazione PAM da nginx per il nome utente: <user>: la richiesta di accesso è stata ricevuta.
    2. DefaultAuthMo specifica il realm <N>. Gruppo di provider <nome> ! — il realm selezionato (0=fallback/local, 2=TACACS+, 3=LDAP).
    3. Messaggi specifici del provider (binding LDAP, ricerca del provider TACACS+ o richiesta RADIUS).
    4. Trovato UserDomain <dominio> sotto il nome utente remoto: <user>: l'assegnazione di dominio dalla risposta AAA.
    5. Nome utente trovato: admin con privilegi di scrittura admin in UserDomain all - l'utente è un utente admin - il controllo del ruolo è stato superato.

    Un log di autenticazione non riuscito:

    • Utente <user> negato durante l'autenticazione AAA
    • Errore <user> utente non autorizzato: Autenticazione server AAA NEGATA

    Nota: Il registro degli indici ruota frequentemente e le voci meno recenti vengono compresse in gzip con un suffisso numerico. Nell'APIC i log ruotati si trovano nella stessa directory (ad esempio, nginx.bin.log.22815.gz). Sugli switch, i log ruotati vengono memorizzati in /var/log/dme/oldlog/dme/nginx.log.*.gz (con i collegamenti simmetrici in /var/sysmgr/tmp_logs/dme_logs/). Per eseguire la ricerca nei log ruotati:

    ! On the APIC:
apic1# zegrep '||aaa||' /var/log/dme/log/nginx.bin.log.*.gz | grep 'PAM authenticate'

! On a leaf or spine switch:
leaf101# zegrep '||aaa||' /var/sysmgr/tmp_logs/dme_logs/nginx.log.*.gz | grep 'PAM authenticate'

    Modello RBAC

    ACI RBAC controlla ciò che un utente autenticato può vedere e fare. Il modello è costituito da tre componenti:

    • Security Domain (aaaDomain): un limitatore di ambito che esegue il mapping agli oggetti ACI (tenant, criteri di accesso, criteri di struttura). I domini predefiniti all, common, e mgmt sono sempre presenti. I domini personalizzati limitano la visibilità di un utente a tenant o aree di criteri specifici.
    • Ruolo (aaaRole) - definisce un insieme di privilegi. I ruoli predefiniti includono admin, aaa, tenant-admin, tenant-ext-admin, read-all, access-admin, fabric-admin, ops e nw-svc-admin.
    • Privilegio: ogni ruolo concede l'accesso in lettura o in scrittura (che implica l'accesso in lettura) a un'area funzionale specifica.

    A un account utente vengono assegnate una o più coppie di dominio di sicurezza e ruolo. Per gli utenti remoti autenticati tramite TACACS+, RADIUS o LDAP, la mappatura dei ruoli viene fornita tramite attributi specifici del fornitore nella risposta AAA (ad esempio, l'cisco-av-pairattributo).

    Struttura decisionale Triage

    Utilizzare questa struttura decisionale quando un utente segnala di non poter accedere all'infrastruttura ACI in remoto:

    1. È possibile eseguire il ping tra l'APIC e l'IP di gestione dello switch?
      • No → Risolvere i problemi relativi al percorso della rete di gestione. Fare riferimento alla sezione "Risoluzione dei problemi relativi alla gestione fuori banda e in banda".
      • Sì → Continua.
    2. È possibile stabilire una connessione SSH o HTTPS (la connessione è aperta)?
      • No → Il servizio del protocollo può essere disabilitato, la porta può essere filtrata o può essere presente una mancata corrispondenza della crittografia. Fare riferimento alle sezioni "Risoluzione dei problemi di accesso SSH" o "Risoluzione dei problemi di accesso HTTPS".
      • Sì → Continua.
    3. Viene visualizzata la schermata di accesso (HTTPS) o l'handshake SSH viene completato e richiede le credenziali?
      • No → Errore di scambio chiave SSH o handshake TLS. Per la crittografia e le mancate corrispondenze KEX, consultare la sezione "Risoluzione dei problemi di accesso SSH".
      • Sì → Continua.
    4. Le credenziali hanno esito negativo con "Autenticazione non riuscita" o simile?
      • Sì → Problema di autenticazione. Consultare le sezioni "Risoluzione dei problemi di autenticazione AAA" (TACACS+, RADIUS o LDAP a seconda del dominio di accesso in uso).
      • No → Continua.
    5. L'utente esegue l'accesso ma non visualizza gli oggetti previsti o riceve errori di tipo "403 Non consentito"?
      • Sì → Autorizzazione o problema RBAC. Fare riferimento alla sezione "Risoluzione dei problemi relativi a RBAC e privilegi utente".
      • No → Access funziona. Verificare il problema specifico riscontrato dall'utente.

    Verifica della configurazione

    Prima di risolvere i problemi relativi allo stato operativo, verificare che la catena di configurazione sia stata completata. La configurazione errata è la causa principale più comune dei problemi di accesso remoto.

    Verifica dei criteri di accesso alla gestione (SSH e HTTPS)

    Selezionare Fabric > Fabric Policies > Policies > Pod > Management Access > default (Fabric > Criteri fabric > Criteri > Pod > Accesso gestione > predefinito).

    mgmt_access_policy_console

    mgmt_access_policy_ssh

    Confermare le seguenti impostazioni SSH:

    • Stato amministratore — deve essere abilitato.
    • Porta: il valore predefinito è 22. Se viene modificato, il client SSH deve utilizzare la porta personalizzata.
    • Autenticazione password — abilitata (a meno che non sia prevista l'autenticazione solo certificato).
    • Cifre SSH: devono includere almeno una cifratura supportata dal client SSH.
    • Algoritmi KEX: devono includere almeno un algoritmo supportato dal client SSH.
    • MAC SSH: devono includere almeno un MAC supportato dal client SSH.

    Eseguire una query sull'oggetto gestito SSH tramite l'API:

    apic1# moquery -c commSsh
dn              : uni/fabric/comm-default/ssh
adminSt         : enabled                      <--- must be enabled
port            : 22
passwordAuth    : enabled
sshCiphers      : aes128-ctr,aes192-ctr,aes256-ctr,chacha20-poly1305@openssh.com
kexAlgos        : curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521
sshMacs         : hmac-sha2-256,hmac-sha2-256-etm@openssh.com,hmac-sha2-512
hostkeyAlgos    : rsa-sha2-256,rsa-sha2-512,ssh-ed25519

    Confermare le impostazioni HTTPS seguenti:

    • Stato amministratore — deve essere abilitato.
    • Port: valore predefinito, 443.
    • Protocolli SSL — TLSv1.2 (predefinito). Per i client meno recenti può essere necessario aggiungere esplicitamente TLSv1.1.
    • Stato velocità - se abilitato, la velocità limita le richieste al secondo per utente. Un valore molto basso può causare errori di timeout dell'API.
    apic1# moquery -c commHttps
dn              : uni/fabric/comm-default/https
adminSt         : enabled                      <--- must be enabled
port            : 443
sslProtocols    : TLSv1.2
throttleSt      : enabled
throttleRate    : 2

    Configurazioni errate comuni

    • I cifrari SSH sono stati limitati in modo troppo aggressivo — in ACI versione 5.2(1) e successive, i cifrari SSH predefiniti sono stati induriti. Lo scambio della chiave può avere esito negativo sui client SSH meno recenti (ad esempio, le versioni PuTTy prima della versione 0.75 o le versioni OpenSSH che offrono solo diffie-hellman-group14-sha1). Il client SSH visualizza "nessuna crittografia corrispondente trovata" o "nessun metodo di scambio chiave corrispondente trovato".
    • Autenticazione password disabilitata: se passwordAuth l'opzione è disabilitata, è consentita solo l'autenticazione basata su chiavi SSH. Gli utenti che si connettono con password vedranno "Autorizzazione negata (chiave pubblica)".
    • Porta SSH personalizzata senza il riconoscimento del client: se la porta SSH è stata modificata da 22, il client SSH deve specificare la nuova porta (ad esempio, ssh -p 2222 admin@10.1.1.1).

    Verifica indirizzi di gestione fuori banda

    Passare a Tenant > Gestione > Indirizzi di gestione dei nodi.

    Confermare che a ogni nodo APIC e di switch sia stato assegnato un indirizzo IP di gestione OOB con un gateway valido. I nodi senza indirizzi di gestione non saranno raggiungibili tramite la rete di gestione.

    Eseguire una query sulle assegnazioni dei nodi statici OOB tramite l'API:

    apic1# moquery -c mgmtRsOoBStNode
# Example output for one node:
dn      : uni/tn-mgmt/mgmtp-default/oob-default/rsooBStNode-[topology/pod-1/node-201]
addr    : 10.1.1.104/27                <--- OOB IP assigned
gw      : 10.1.1.97                    <--- gateway for the OOB subnet
tDn     : topology/pod-1/node-201      <--- target node

    Configurazioni errate comuni

    • Assegnazione indirizzo OOB mancante: per uno switch non è disponibile una voce in mgmtRsOoBStNode. Il nodo non avrà un IP di gestione e non risponderà a SSH o HTTPS sull'interfaccia OOB.
    • Gateway non corretto: l'indirizzo del gateway non corrisponde al gateway effettivo nella rete di gestione OOB. Il nodo può ricevere pacchetti ma non inviare traffico di ritorno.
    • Mancata corrispondenza della subnet mask: la subnet mask OOB non corrisponde alla rete di gestione fisica. In questo modo, il nodo potrebbe ritenere che la stazione di gestione si trovi su una subnet diversa e instradare il traffico attraverso un gateway inesistente o non corretto.

    Verifica contratti OOB

    Passare a Tenant > Gestione > Contratti.

    Se all'EPG di gestione OOB viene applicato un contratto OOB, solo il traffico esplicitamente autorizzato da tale contratto raggiungerà l'interfaccia di gestione APIC. Sull'APIC, i contratti OOB vengono fatti rispettare attraverso delle iptables regole.

    Eseguire una query sui contratti OOB forniti da EPG:

    apic1# moquery -c mgmtRsOoBProv -x 'query-target-filter=wcard(mgmtRsOoBProv.dn,"oob-default")'

    Se la query restituisce risultati, vengono applicati i contratti. Verificare che i soggetti del contratto e i filtri consentano i protocolli richiesti:

    • SSH: porta TCP 22 (o porta personalizzata)
    • HTTPS — porta TCP 443 (o porta personalizzata)
    • ICMP — per la verifica del ping

    Configurazioni errate comuni

    • Il contratto OOB non include SSH o HTTPS — il tecnico può eseguire il ping sull'APIC ma non può connettersi tramite SSH o HTTPS. Le iptables regole sull'APIC lasciano cadere il traffico in silenzio.
    • Restrizione IP di origine nel filtro del contratto OOB: il filtro del contratto limita l'accesso a subnet di origine specifiche. I tecnici esterni alla subnet non possono connettersi.

    Verifica della configurazione AAA

    Selezionare Admin > AAA > Authentication > AAA.

    aaa_authentication_default

    Confermare quanto segue:

    • Realm di autenticazione predefinito: identifica il dominio di accesso utilizzato quando l'utente non ne specifica uno. Se impostato su un dominio di accesso AAA remoto, il server corrispondente deve essere raggiungibile.
    • Realm di autenticazione console: controlla l'accesso alla console. Se impostato su local, l'accesso alla console utilizza sempre le credenziali locali (consigliato).

    Verifica domini di accesso

    Selezionare Admin > AAA > Authentication > Login Domains (Amministratore > AAA > Autenticazione > Domini di accesso).

    apic1# moquery -c aaaLoginDomain
# Example output:
dn    : uni/userext/logindomain-TACACS-Domain
name  : TACACS-Domain

dn    : uni/userext/logindomain-LOCAL
name  : LOCAL

dn    : uni/userext/logindomain-fallback
name  : fallback
descr : Special login domain to allow fallback to local authentication

    Verificare che il dominio di accesso utilizzato per l'autenticazione sia presente e che faccia riferimento al gruppo di provider corretto.

    Verifica provider TACACS+

    Selezionare Admin > AAA > Authentication > TACACS+ > TACACS+ Providers (Amministratore > AAA > Autenticazione > TACACS+ > Provider TACACS+).

    apic1# moquery -c aaaTacacsPlusProvider
dn              : uni/userext/tacacsext/tacacsplusprovider-10.1.1.50
name            : 10.1.1.50
authProtocol    : pap
port            : 49                          <--- default TACACS+ port
monitorServer   : disabled
epgDn           : uni/tn-mgmt/mgmtp-default/oob-default    <--- management EPG

    Verifica provider RADIUS

    Selezionare Admin > AAA > Authentication > RADIUS > RADIUS Providers (Amministratore > AAA > Autenticazione > RADIUS > Provider RADIUS).

    apic1# moquery -c aaaRadiusProvider
dn              : uni/userext/radiusext/radiusprovider-10.1.1.51
name            : 10.1.1.51
authPort        : 1812                        <--- default RADIUS auth port
authProtocol    : pap
retries         : 1
timeout         : 5
epgDn           : uni/tn-mgmt/mgmtp-default/oob-default    <--- management EPG

    Verifica provider LDAP

    Passare a Amministrazione > AAA > Autenticazione > LDAP > Provider LDAP.

    apic1# moquery -c aaaLdapProvider
dn              : uni/userext/ldapext/ldapprovider-10.1.1.52
name            : 10.1.1.52
port            : 389                         <--- 389 for LDAP, 636 for LDAPS
enableSSL       : no
rootdn          : CN=binduser,CN=Users,DC=example,DC=com
basedn          : CN=Users,DC=example,DC=com
filter          : sAMAccountName=$userid
attribute       : memberOf                    <--- attribute used for group map
epgDn           : uni/tn-mgmt/mgmtp-default/oob-default    <--- management EPG

    Configurazioni errate comuni AAA

    • Mancata corrispondenza del segreto condiviso: la chiave configurata sul provider ACI TACACS+ o RADIUS non corrisponde alla chiave sul server. L'autenticazione non riesce in modo invisibile all'utente.
    • EPG di gestione errato: il provider epgDn è vuoto o punta all'EPG errato (ad esempio, in-band quando il server si trova sulla rete OOB). L'APIC non riesce a raggiungere il server.
    • Mancata corrispondenza dell'area di autenticazione del dominio di accesso: il dominio di accesso è configurato come LDAP, ma l'utente si aspetta l'autenticazione TACACS+. I domini di accesso devono fare riferimento al tipo di gruppo di provider corretto.
    • DN di binding LDAP non corretto — il DN di rootdn (binding) o basedn sono errati. L'autenticazione LDAP ha esito negativo e genera un errore di binding anche quando le credenziali utente sono corrette.
    • Il filtro LDAP non corrisponde allo schema della directory. Per Active Directory, utilizzare sAMAccountName=$userid. Per OpenLDAP, utilizzare cn=$userid o uid=$userid.

    Verifica configurazione RBAC

    Passare a Amministrazione > AAA > Utenti per visualizzare gli account utente locali e le relative assegnazioni di domini di sicurezza e ruoli.

    Eseguire query sui domini di sicurezza tramite l'API:

    apic1# moquery -c aaaDomain
# Built-in domains:
dn      : uni/userext/domain-all
name    : all                              <--- full fabric access

dn      : uni/userext/domain-common
name    : common                           <--- access to tenant common

dn      : uni/userext/domain-mgmt
name    : mgmt                             <--- access to tenant mgmt

    Un utente assegnato al dominio all con ruolo admin dispone dell'accesso completo in lettura/scrittura all'intera struttura. Un utente assegnato a un dominio di sicurezza personalizzato con ruolo tenant-admin può gestire solo tenant associati a tale dominio.

    Configurazioni errate comuni di RBAC

    • Utente creato senza un dominio di sicurezza: l'utente può eseguire l'accesso ma non vede tenant e riceve "403 Vietato" sulle chiamate API. È necessario assegnare almeno un dominio di protezione.
    • Ruolo di sola lettura assegnato quando è necessario l'accesso in scrittura: l'utente può visualizzare gli oggetti ma non può inviare le modifiche. Verificare che il privilegio del ruolo sia impostato su writePriv.
    • Mapping dei ruoli utente remoti mancante dal server AAA — il server TACACS+ o RADIUS non restituisce l'cisco-av-pairattributo contenente shell:domains=all/admin/. L'utente esegue l'autenticazione, ma non dispone di ruoli e non può visualizzare alcun elemento nell'infrastruttura.

    Risoluzione dei problemi relativi alla gestione fuori banda e in banda

    Se l'IP di gestione dello switch o dell'APIC non è raggiungibile sulla rete, risolvere il problema sul percorso di gestione prima di usare il protocollo SSH, HTTPS o AAA.

    Scenario: Impossibile eseguire il ping dell'IP OOB APIC

    Problema: La stazione di gestione non è in grado di eseguire il ping dell'indirizzo IP di gestione OOB APIC.

    Fasi della verifica:

    1. Verificare che la porta di gestione APIC sia fisicamente connessa e che il collegamento sia attivo.
    2. Verificare che la stazione di gestione si trovi sullo stesso segmento L2 o che disponga di un percorso alla subnet OOB.
    3. Verificare che l'indirizzo IP di gestione OOB sia assegnato correttamente: 
      apic1# ifconfig oobmgmt
oobmgmt: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.1.1.1  netmask 255.255.255.224  broadcast 10.1.1.31
    4. Verificare che il gateway predefinito sia raggiungibile: 
      apic1# netstat -rn | grep oobmgmt
0.0.0.0         10.1.1.97       0.0.0.0         UG    0      0        0 oobmgmt
10.1.1.96       0.0.0.0         255.255.255.224  U     0      0        0 oobmgmt
    5. Se viene applicato un contratto OOB, verificare che consenta i protocolli richiesti. Eseguire una query sui contratti OOB forniti da EPG, come illustrato nella sezione "Verifica contratti OOB". I contratti OOB sono applicati come iptables regole sull'APIC. È possibile visualizzare le regole salvate dalla shell APIC: 
      apic1# cat /etc/sysconfig/iptables | grep -A 20 "filter"

      Se il criterio INPUT è DROP e non è presente alcuna regola ACCEPT per il protocollo richiesto, il contratto OOB filtra il traffico.

      Nota: Il iptables -L -n comando per visualizzare le regole del kernel in tempo reale richiede l'accesso alla radice e non è disponibile per le normali sessioni SSH di amministrazione.

    Causa principale: Indirizzo di gestione OOB mancante o non configurato correttamente, gateway non corretto o traffico di filtro del contratto OOB.

    Soluzione: Correggere l'assegnazione degli indirizzi OOB, verificare il percorso di rete fisico o aggiornare il contratto OOB per consentire i protocolli richiesti.

    Scenario: Impossibile raggiungere l'IP di gestione dello switch

    Problema: La stazione di gestione può raggiungere l'APIC ma non uno switch tramite OOB.

    Fasi della verifica:

    1. Verificare che allo switch sia stato assegnato un indirizzo OOB: 
      apic1# moquery -c mgmtRsOoBStNode -x 'query-target-filter=eq(mgmtRsOoBStNode.tDn,"topology/pod-1/node-101")'
dn      : uni/tn-mgmt/mgmtp-default/oob-default/rsooBStNode-[topology/pod-1/node-101]
addr    : 10.1.1.101/27
gw      : 10.1.1.97
    2. Verificare che all'interfaccia di gestione dello switch sia assegnato l'indirizzo IP: 
      leaf101# ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 20:db:ea:14:42:54
          inet addr:10.1.1.101  Bcast:10.1.1.127  Mask:255.255.255.224
          UP BROADCAST RUNNING MULTICAST  MTU:1500
    3. Verificare la route predefinita VRF di gestione: 
      leaf101# ip route show
default via 10.1.1.97 dev eth0
10.1.1.96/27 dev eth0 proto kernel scope link src 10.1.1.101

    Causa principale: Assegnazione dell'indirizzo OOB mancante, gateway non corretto o porta fisica di gestione dello switch inattiva.

    Soluzione: Assegnare l'indirizzo OOB in Tenant > mgmt > Indirizzi di gestione dei nodi. Verificare che il collegamento di gestione fisica sia attivo.

    Risoluzione dei problemi di accesso SSH

    In questa sezione vengono illustrati gli scenari in cui l'IP di gestione è raggiungibile (il ping ha esito positivo) ma la sessione SSH non viene stabilita o autenticata.

    Scenario: Connessione SSH rifiutata

    Problema: Il client SSH segnala "Connessione rifiutata" quando si effettua la connessione all'APIC o allo switch.

    Fasi della verifica:

    1. Verificare che SSH sia abilitato in Management Access Policy: 
      apic1# moquery -c commSsh -x 'query-target-filter=eq(commSsh.adminSt,"enabled")'
dn        : uni/fabric/comm-default/ssh
adminSt   : enabled
port      : 22

      Se adminSt il comando è disabilitato, le connessioni SSH vengono rifiutate.

    2. Verificare che venga utilizzata la porta corretta. Se la porta SSH è stata modificata da 22: 
      $ ssh -p custom-port admin@10.1.1.1
    3. Verificare che il contratto OOB consenta il protocollo TCP sulla porta SSH. Fare riferimento alla sezione "Verifica dei contratti OOB".

    Causa principale: SSH disabilitato nei criteri di accesso alla gestione, porta personalizzata sconosciuta al client o filtro del contratto OOB.

    Soluzione: Abilitare SSH nei criteri di accesso alla gestione o utilizzare la porta corretta.

    Scenario: Errore di scambio chiave SSH (crittografia o mancata corrispondenza KEX)

    Problema: Il client SSH non riesce con "nessuna crittografia corrispondente trovata", "nessun metodo di scambio chiave corrispondente trovato" o "nessun MAC corrispondente trovato".

    Fasi della verifica:

    1. Controllare l'output dettagliato del client SSH per identificare gli algoritmi offerti dal client: 
      $ ssh -vv admin@10.1.1.1
debug2: KEX algorithms: curve25519-sha256,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1
debug2: host key algorithms: ssh-ed25519,rsa-sha2-512,rsa-sha2-256
debug2: ciphers ctos: aes128-ctr,aes192-ctr,aes256-ctr
debug2: MACs ctos: hmac-sha2-256,hmac-sha1
    2. Confrontare gli algoritmi offerti dal client con gli algoritmi configurati da APIC: 
      apic1# moquery -c commSsh
sshCiphers   : aes128-ctr,aes192-ctr,aes256-ctr,chacha20-poly1305@openssh.com
kexAlgos     : curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521
sshMacs      : hmac-sha2-256,hmac-sha2-256-etm@openssh.com,hmac-sha2-512
hostkeyAlgos : rsa-sha2-256,rsa-sha2-512,ssh-ed25519
    3. Identificare l'intersezione. Se non esiste un algoritmo comune in una categoria, l'handshake ha esito negativo.

    Nota: In ACI versione 5.2(1) e successive, i cifrari SSH predefiniti e gli algoritmi KEX sono stati rinforzati. Gli algoritmi legacy quali diffie-hellman-group1-sha1, diffie-hellman-group14-sha1, aes128-cbc, e hmac-sha1 non sono più disponibili per impostazione predefinita. Se l'aggiornamento è stato eseguito di recente, verificare che i client SSH nell'ambiente in uso supportino le nuove impostazioni predefinite.

    Causa principale: Dopo un aggiornamento ACI o una protezione avanzata dalla cifratura, tra il client SSH e l'APIC non sono presenti cifrature, algoritmi KEX o MAC in comune.

    Soluzione: Aggiornare il client SSH per supportare gli algoritmi moderni o aggiungere nuovamente l'algoritmo legacy richiesto ai criteri di accesso alla gestione. La reaggiunta di algoritmi legacy comporta rischi per la sicurezza e non è consigliata a lungo termine.

    Scenario: SSH si connette ma l'autenticazione non riesce per gli utenti locali

    Problema: L'handshake SSH ha esito positivo (viene visualizzata la richiesta della password), ma la password viene rifiutata per un utente locale.

    Fasi della verifica:

    1. Verificare che l'utente esista localmente: 
      apic1# moquery -c aaaUser -x 'query-target-filter=eq(aaaUser.name,"admin")'
dn        : uni/userext/user-admin
name      : admin
accountStatus : active                 <--- must be active, not inactive or locked
    2. Verificare se l'account è bloccato a causa di un numero eccessivo di tentativi di accesso non riusciti: 
      apic1# moquery -c aaaUserEp
dn                 : uni/userext
pwdStrengthCheck   : no

      Controllare il criterio di blocco del dominio di accesso in Amministrazione > AAA > Gestione della sicurezza > Criterio di blocco.

    3. Verificare che l'utente stia eseguendo l'accesso con il dominio di accesso corretto. Se il realm di autenticazione predefinito è impostato su un dominio di accesso AAA remoto, l'utente deve anteporre apic:LOCAL\\username o apic:fallback\\username per forzare l'autenticazione locale.
    4. Convalidare il risultato dell'autenticazione nei registri. Controllare nginx.bin.log l'evento di accesso sull'APIC: 
      apic1# grep '||aaa||' /var/log/dme/log/nginx.bin.log | grep -i 'admin' | tail -20

      Cercare il realm e il gruppo di provider assegnati al tentativo di accesso:

      ! Working — Successful local authentication via the fallback domain (Realm 0 = fallback/local):
||aaa||INFO||Received PAM authenticate request from nginx for Username:  apic#fallback\\admin
||aaa||INFO||auth-domain realm = local, LocalUser admin
||aaa||DBG4||Decoded username string to Domain: fallback Username: admin Realm 0, PG
||aaa||DBG4||Found password for local Username: apic#fallback\\admin
||aaa||DBG4||Calling UpdateLastLogin method for user: apic#fallback\\admin

! Not Working — Login was sent to the LDAP realm because the Default Authentication Realm is set to LDAP.
! The admin user does not exist in the LDAP directory, so the LDAP search returns empty and the login is denied:
||aaa||INFO||Received PAM authenticate request from nginx for Username:  apic#LDAP-Domain\\admin
||aaa||DBG4||Decoded username string to Domain: LDAP-Domain Username: admin Realm 3, PG LDAP-Domain
||aaa||DBG4||Adding LdapProvider ldap-server.example.com to the list, order 1
||aaa||INFO||LDAP search to server ldap-server.example.com for baseDn CN=Users,DC=example,DC=com, filter sAMAccountName=admin
||aaa||INFO||LDAP search to server ldap-server.example.com for baseDn CN=Users,DC=example,DC=com, filter sAMAccountName=admin returned empty set
||aaa||INFO||User apic#LDAP-Domain\\admin was denied during AAA authentication
||aaa||DBG4||Setting error LDAP/AD Server Authentication DENIED
||aaa||ERROR||Unauthorized Username: admin error: LDAP/AD Server Authentication DENIED

      Se l'area di autenticazione non è 0 (fallback/local), l'accesso è stato inviato a un server AAA remoto anziché al database locale. L'utente deve anteporre apic:fallback\\username o apic:LOCAL\\username per imporre l'autenticazione locale.

    Causa principale: Password errata, account bloccato o tentativo di accesso inviato a un server AAA remoto anziché al database locale.

    Soluzione: Reimpostare la password, sbloccare l'account o utilizzare il prefisso del dominio di accesso corretto.

    Risoluzione dei problemi di accesso HTTPS

    In questa sezione vengono illustrati gli scenari in cui l'interfaccia API (Application Programming Interface) REST (Representative State Transfer) o l'interfaccia Web APIC non è raggiungibile tramite HTTPS.

    Scenario: Timeout connessione HTTPS

    Problema: Il browser mostra "ERR_CONNECTION_TIMED_OUT" oppure la chiamata API si blocca quando si effettua la connessione all'APIC sulla porta 443.

    Fasi della verifica:

    1. Verificare che HTTPS sia abilitato: 
      apic1# moquery -c commHttps -x 'query-target-filter=eq(commHttps.adminSt,"enabled")'
dn        : uni/fabric/comm-default/https
adminSt   : enabled
port      : 443
    2. Verificare che il contratto OOB consenta TCP 443. Fare riferimento alla sezione "Verifica contratti OOB".
    3. Eseguire il test dall'APIC per verificare che il processo HTTPS sia in ascolto: 
      apic1# ss -tlnp | grep 443
LISTEN  0  128  *:443  *:*  users:(("nginx",pid=12345,fd=6))

    Causa principale: HTTPS disabilitato, TCP 443 del filtro dei contratti OOB o arresto anomalo del processo Inginx sull'APIC.

    Soluzione: Abilitare HTTPS nei criteri di accesso di gestione, aggiornare il contratto OOB o riavviare il servizio Web sull'APIC.

    Scenario: Il browser mostra l'errore dell'handshake TLS

    Problema: Il browser visualizza "ERR_SSL_VERSION_OR_CIPHER_MISMATCH" o un errore TLS simile.

    Fasi della verifica:

    1. Controllare la versione del protocollo TLS configurata sull'APIC: 
      apic1# moquery -c commHttps
sslProtocols : TLSv1.2
    2. Verificare che il browser supporti TLSv1.2. I browser meno recenti, ad esempio Internet Explorer 10 e versioni precedenti, non supportano TLSv1.2 per impostazione predefinita.

    Causa principale: L'APIC offre solo TLSv1.2 (impostazione predefinita) e il browser o il client API supporta solo le versioni TLS precedenti.

    Soluzione: Aggiornare il browser o il client. Se è necessario supportare temporaneamente i client meno recenti, aggiungere TLSv1.1 ai criteri di accesso alla gestione, ma ciò comporta rischi per la sicurezza.

    Scenario: Limitazione velocità API

    Problema: Le chiamate all'API REST hanno esito negativo a intermittenza con errori HTTP 503 oppure l'interfaccia utente Web risulta lenta durante un'automazione intensiva.

    Fasi della verifica:

    apic1# moquery -c commHttps
throttleSt   : enabled
throttleRate : 2                       <--- requests per second per user

    Se la velocità è molto bassa e gli script di automazione inviano molte richieste al secondo, l'APIC rifiuta le richieste in eccesso.

    Causa principale: La velocità per utente è troppo bassa per il carico di lavoro di automazione.

    Soluzione: Aumentare la velocità in base ai criteri di accesso alla gestione o ottimizzare gli script di automazione per ridurre la frequenza delle richieste. In alternativa, disabilitare la limitazione se l'infrastruttura non è condivisa.

    Risoluzione dei problemi AAA — TACACS+

    In questa sezione vengono illustrati gli errori di autenticazione TACACS+. L'APIC comunica con il server TACACS+ sulla porta TCP 49.

    Verifica operativa

    Gli switch ACI non supportano il test aaa comando disponibile su NX-OS standalone. Per verificare il funzionamento di TACACS+, utilizzare l'APIC per controllare lo stato del provider, gli errori e la cronologia delle sessioni di accesso.

    Verificare la presenza di errori attivi sul provider TACACS+:

    apic1# moquery -c faultInst -x 'query-target-filter=wcard(faultInst.dn,"tacacsplusprovider")'

    Se non vengono restituiti errori, il provider viene considerato raggiungibile. Se sono presenti errori, l'output include codici di errore quali F1773 (provider irraggiungibile) o F1774 (errore di autenticazione).

    Verificare la configurazione del provider TACACS+:

    apic1# moquery -c aaaTacacsPlusProvider
dn              : uni/userext/tacacsext/tacacsplusprovider-10.1.1.50
name            : 10.1.1.50
authProtocol    : pap
port            : 49
epgDn           : uni/tn-mgmt/mgmtp-default/oob-default

    Verificare la raggiungibilità di base della rete dall'APIC al server TACACS+:

    apic1# ping 10.1.1.50
PING 10.1.1.50 (10.1.1.50): 56 data bytes
64 bytes from 10.1.1.50: icmp_seq=0 ttl=64 time=0.5 ms

    Tentare di effettuare l'accesso all'APIC con il dominio di accesso TACACS+ e controllare il risultato della sessione:

    apic1# moquery -c aaaSessionLR -x 'order-by=aaaSessionLR.created|desc' -x page-size=5

    Esaminare il descr campo per determinare se l'errore è stato causato da un rifiuto dell'autenticazione o da un problema di connettività.

    Convalidare il flusso di autenticazione TACACS+ nei log APIC. Filtro per il nome utente in questione:

    apic1# grep '||aaa||' /var/log/dme/log/nginx.bin.log | grep -i 'username' | tail -20

    Gli accessi TACACS+ seguono lo stesso flusso di nginx.bin.log autenticazione di LDAP (per esempi completi di log reali, vedere la sezione Verifica operativa di LDAP). Le differenze principali rispetto a TACACS+ sono:

    • DefaultAuthMo specifica l'area di autenticazione 2 — L'area di autenticazione 2 indica TACACS+ (rispetto all'area di autenticazione 3 per LDAP).
    • Aggiunta di TacacsProvider <IP> all'elenco — identifica il server TACACS+ contattato (a differenza di LdapProvider per LDAP).
    • TACACS+ Cisco-vpair (shell:domains=all/admin/): la coppia AV viene restituita direttamente dal server TACACS+ (anziché essere convertita da una mappa di gruppo LDAP).

    Se l'accesso a TACACS+ ha esito positivo, la progressione è la stessa: Richiesta PAM → selezione del realm → ricerca del provider → analisi della coppia AV → iniezione dell'utente → UserDomain e assegnazione dei ruoli → privilegi di scrittura dell'amministratore.

    Un accesso TACACS+ non riuscito termina con l'utente <nomeutente> è stato negato durante l'autenticazione AAA e Errore non autorizzato: Autenticazione server AAA NEGATA, stesso criterio di una negazione LDAP.

    Scenario: Autenticazione TACACS+ non riuscita

    Problema: L'accesso non riesce con "Autenticazione non riuscita" quando l'utente seleziona un dominio di accesso TACACS+.

    Fasi della verifica:

    1. Verificare la presenza di errori attivi sul provider TACACS+: 
      apic1# moquery -c faultInst -x 'query-target-filter=wcard(faultInst.dn,"tacacsplusprovider")'

      L'errore F1773 indica un problema di connettività. L'errore F1774 indica un rifiuto dell'autenticazione.

    2. Verificare la raggiungibilità della rete dall'APIC al server TACACS+: 
      apic1# ping 10.1.1.50
PING 10.1.1.50 (10.1.1.50): 56 data bytes
64 bytes from 10.1.1.50: icmp_seq=0 ttl=64 time=0.5 ms
    3. Se il ping ha esito positivo ma l'autenticazione ha esito negativo, verificare le corrispondenze del segreto condiviso sia nella configurazione del provider APIC che nella configurazione del server TACACS+.
    4. Controllare le sessioni di accesso più recenti per visualizzare i dettagli dell'errore: 
      apic1# moquery -c aaaSessionLR -x 'order-by=aaaSessionLR.created|desc' -x page-size=5
    5. Controllare i log del server TACACS+ per il tentativo di autenticazione. Un tentativo riuscito di accesso al server ma rifiutato indica un problema di configurazione utente sul lato server (ad esempio, mancata corrispondenza della password o account utente mancante).
    6. Controllare l'APIC nginx.bin.log per il flusso di autenticazione completo. Filtrare in base al nome utente anziché in base a parole chiave specifiche, in modo da non omettere i messaggi intermedi: 
      apic1# grep '||aaa||' /var/log/dme/log/nginx.bin.log | grep -i 'tacuser1' | tail -20

      Confrontare l'output con gli esempi funzionanti e non funzionanti nella sezione Verifica operativa riportata sopra. Indicatori chiave:

      • negato o NEGATO — il server TACACS+ è stato raggiunto ma le credenziali sono state rifiutate. Verificare che l'utente esista sul server e che la password corrisponda.
      • Nessun messaggio specifico del provider dopo l'aggiunta di TacacsProvider — il server non è raggiungibile o è scaduto. Verificare la raggiungibilità della rete e la gestione EPG.
      • Aggiunta dell'utente remoto... completata seguita da righe di controllo del ruolo. L'autenticazione è stata eseguita correttamente, ma il problema può essere dovuto all'assegnazione del ruolo (vedere la sezione sulla coppia AV più avanti).

    TACACS+ cisco-av-pair per RBAC

    Per gli utenti remoti autenticati tramite TACACS+, il server deve restituire l'cisco-av-pairattributo nella risposta di autorizzazione. Questo attributo mappa l'utente ai domini e ai ruoli di sicurezza ACI.

    Formato:

    shell:domains=domain/role/

    Esempi:

    • Amministratore completo: shell:domains=all/admin/
    • Read-only per tutti: shell:domains=all/read-all/
    • Amministratore tenant per un dominio specifico: shell:domains=TenantA/tenant-admin/
    • Più domini: shell:domains=all/admin/,TenantA/tenant-admin/

    Se l'attributo è mancante o non è valido, l'utente esegue l'autenticazione ma non dispone di ruoli e non può visualizzare alcun oggetto nell'interfaccia utente APIC.

    Nota: L'accesso SSH agli switch foglia e spine richiede il ruolo admin con privilegio di scrittura nel dominio di sicurezza all. La coppia AV minima per l'accesso SSH allo switch è shell:domains=all/admin/. Gli utenti con ruoli diversi da admin (ad esempio, read-all, tenant-admin, aaa) o gli utenti assegnati a un dominio di sicurezza diverso da all possono accedere all'APIC ma non possono accedere agli switch SSH. Il registro APIC indica che gli accessi non amministrativi allo switch sono stati negati per questi utenti.

    Convalidare la coppia AV ricevuta controllando nginx.bin.log. Filtrare in base al nome utente per visualizzare il flusso di aggiunta di ruolo completo:

    apic1# grep '||aaa||' /var/log/dme/log/nginx.bin.log | grep -i 'username' | tail -20

    Per TACACS+, la coppia AV viene registrata come TACACS+ Cisco-avpair (shell:domains=...). Un inserimento riuscito indica che l'inserimento dell'utente remoto <nomeutente> è stato completato seguito dalle righe dei privilegi di scrittura UserDomain e admin trovati (per esempi completi di questo flusso con output di log reale, vedere la sezione Verifica operativa LDAP).

    Se il formato della coppia AV non è valido, il registro mostra l'inserimento dei dati <nomeutente> dell'utente remoto non riuscito - il messaggio di errore è Invalid shell:domains string. Se l'utente esegue l'autenticazione con un ruolo non di amministrazione, il protocollo SSH sugli switch viene rifiutato e gli accessi non di amministrazione sullo switch vengono negati.

    Causa principale: Mancata corrispondenza del segreto condiviso, server non raggiungibile dalla rete di gestione, utente inesistente sul server TACACS+ o EPG di gestione sul provider non corretto.

    Soluzione: Correggere il segreto condiviso, correggere la raggiungibilità o creare l'utente sul server TACACS+.

    Convalida registri di autenticazione switch foglia

    pam.module.log Sugli switch foglia e dorso, gli eventi di accesso SSH sono registrati sia su che su nginx.log. Nella pam.module.log viene mostrato il risultato dell'autenticazione PAM (accettazione o rifiuto). Il file nginx.log contiene l'intero flusso AAA: selezione del realm, ricerca del provider, comunicazione LDAP/TACACS+/RADIUS, analisi della coppia AV e assegnazione di ruoli. Il flusso è identico a quello nginx.bin.log dell'APIC. Questi registri si applicano a tutti i tipi di server AAA remoti (TACACS+, RADIUS, LDAP).

    Controllare pam.module.log i risultati dell'autenticazione:

    leaf101# cat /var/sysmgr/tmp_logs/pam.module.log | tail -30

    Funzionante — autenticazione remota dello switch riuscita:

    ||pam||INFO||Received pamauth request for jsmith
||pam||INFO||User: jsmith, rhost: 10.1.1.50, tty: ssh
||pam||INFO||Connecting to default PAM socket path /var/run/mgmt/socket/pam
||pam||INFO||Securitymgr is ALIVE
||pam||INFO||Connection successful - attempting to authenticate user jsmith client ssh
||pam||INFO||Sent authentication credentials (total pkt len 58)
||pam||INFO||Received authentication response from PAM server
||pam||INFO||User jsmith from 10.1.1.50 authenticated by securitymgrAG with UNIX user id 16004
||pam||INFO||pam_putenv username=jsmith
||pam||INFO||pam_putenv remote=1
||pam||INFO||pam_putenv unix_user_id=16004
||pam||INFO||pam_putenv groupuid=15374
||pam||INFO||returning success

    Il remote=1 flag conferma che l'utente è stato autenticato da un server AAA remoto.

    Non funzionante: l'utente è stato rifiutato. securitymgrAG rifiuta l'utente e lo switch tenta di eseguire una ricerca dell'utente locale come fallback finale:

    ||pam||INFO||Received pamauth request for baduser
||pam||INFO||User: baduser, rhost: 10.1.1.50, tty: ssh
||pam||INFO||Connection successful - attempting to authenticate user baduser client ssh
||pam||INFO||ERROR: securitymgrAG rejected user baduser from 10.1.1.50
||pam||INFO||You entered user baduser ...attempting to match against local users
||pam||INFO||Username baduser is not a special local auth user

    Se non viene visualizzata alcuna voce PAM, la connessione SSH è stata probabilmente rifiutata prima di raggiungere la fase PAM (ad esempio, a causa di una mancata corrispondenza della crittografia o dell'annullamento della connessione da parte dell'utente).

    Per una visualizzazione più dettagliata del flusso di autenticazione sullo switch, selezionare nginx.log. Questo log contiene l'intera catena di decisioni AAA, lo stesso formato e gli stessi messaggi nginx.bin.log dell'APIC:

    leaf101# grep '||aaa||' /var/sysmgr/tmp_logs/dme_logs/nginx.log | grep -i 'username' | tail -20

    Funzionante — autenticazione LDAP riuscita su uno switch (confrontare con gli esempi LDAP APIC nella sezione Verifica operativa LDAP — i messaggi sono gli stessi):

    ||aaa||INFO||Received PAM authenticate request from nginx for Username:  jsmith
||aaa||DBG4||Decoded username string to Domain:  Username: jsmith Realm 3, PG LDAP-Domain
||aaa||DBG4||Username: jsmith does not exist locally
||aaa||DBG4||Initialized LdapAuthenticationBroker for lookup of jsmith (address 10.1.1.100, hostname ssh)
||aaa||INFO||LDAP search to server ldap-server.example.com for baseDn CN=Users,DC=example,DC=com, filter sAMAccountName=jsmith
||aaa||INFO||LDAP Record DN : CN=jsmith,CN=Users,DC=example,DC=com
||aaa||DBG4||Bind to UserDN CN=jsmith,CN=Users,DC=example,DC=com using user password successful
||aaa||INFO||User AAA authentication was successful
||aaa||DBG4||Injection of remote user jsmith was completed
||aaa||DBG4||Checking all UserDomains under remote Username: jsmith
||aaa||DBG4||Found UserDomain all under remote Username: jsmith
||aaa||DBG4||Found Username: admin with admin write privileges under UserDomain all - user is an admin user

    L'interruttore nginx.log è particolarmente utile quando pam.module.log viene mostrato un rifiuto, ma non ne spiega il motivo. Il file nginx.log indica il realm AAA, il provider e il motivo specifico dell'errore (ad esempio, la ricerca LDAP ha restituito un valore vuoto, il timeout TACACS+ o l'inserimento di una coppia AV non riuscito).

    Risoluzione dei problemi AAA — RADIUS

    In questa sezione vengono illustrati gli errori di autenticazione RADIUS. L'APIC comunica con il server RADIUS tramite la porta UDP 1812 (autenticazione) e, facoltativamente, tramite la porta UDP 1813 (accounting).

    Verifica operativa

    Gli switch ACI non supportano il test aaa comando disponibile su NX-OS standalone. Per verificare il funzionamento di RADIUS, attenersi alla procedura descritta di seguito.

    Verificare la configurazione del server RADIUS e le statistiche di raggiungibilità da uno switch foglia:

    leaf101# show radius-server
timeout value:5
retransmission count:3
deadtime value:0
source interface:any available
total number of servers:1

following RADIUS servers are configured:
        10.1.1.51:
                available for authentication on port: 1812
                Radius shared secret:********
                timeout:5
                retries:1

    Scenario: Autenticazione RADIUS non riuscita

    Problema: L'accesso non riesce quando un utente seleziona un dominio di accesso RADIUS.

    Fasi della verifica:

    1. Controllare le statistiche del server RADIUS da uno switch per individuare eventuali timeout o errori: 
      leaf101# show radius-server statistics 10.1.1.51
Authentication Statistics
	failed transactions: 0
	sucessfull transactions: 5
	requests sent: 5
	requests timed out: 0

      Un numero elevato in richieste scadute indica che il server RADIUS non è raggiungibile o che il segreto condiviso non corrisponde (RADIUS scarta automaticamente i pacchetti in caso di mancata corrispondenza del segreto condiviso).

    2. Verificare la raggiungibilità della rete al server RADIUS: 
      apic1# ping 10.1.1.51
PING 10.1.1.51 (10.1.1.51): 56 data bytes
64 bytes from 10.1.1.51: icmp_seq=0 ttl=64 time=0.5 ms
    3. Verificare le corrispondenze del segreto condiviso tra APIC e il server RADIUS. A differenza di TACACS+, che utilizza il protocollo TCP e segnala gli errori di connessione, RADIUS utilizza UDP e scarta automaticamente i pacchetti quando il segreto condiviso non corrisponde. L'unico sintomo è un timeout.
    4. Controllare i registri del server RADIUS. FreeRADIUS in modalità debug (radiusd -X) visualizza ogni richiesta e indica se è stata accettata, rifiutata o se presenta una mancata corrispondenza del segreto condiviso.
    5. Controllare il flusso nginx.bin.log di autenticazione RADIUS nell'APIC. Filtra in base al nome utente: 
      apic1# grep '||aaa||' /var/log/dme/log/nginx.bin.log | grep -i 'username' | tail -20

      Gli accessi RADIUS seguono lo stesso flusso di nginx.bin.log autenticazione di LDAP e TACACS+ (per esempi completi di log reali, vedere la sezione Verifica operativa di LDAP). Le differenze principali per RADIUS sono:

      • Aggiunta di RadiusProvider <IP> all'elenco — identifica il server RADIUS (rispetto a TacacsProvider o LdapProvider).
      • Il numero di realm per RADIUS varia in base alla configurazione.

      Un accesso RADIUS riuscito termina con Injection of remote user ... completato e privilegi di scrittura dell'amministratore.

      Un accesso RADIUS non riuscito termina con è stato negato durante l'autenticazione AAA e NEGATO.

      Se dopo la riga Aggiunta di RadiusProvider non vengono visualizzati messaggi specifici per RADIUS, si è verificato il timeout del server. A differenza di TACACS+, che utilizza il protocollo TCP e segnala gli errori di connessione, RADIUS utilizza UDP e scarta automaticamente i pacchetti quando il segreto condiviso non corrisponde. L'unico sintomo è un timeout seguito da un rifiuto.

    6. Verificare la presenza di errori attivi nel provider RADIUS: 
      apic1# moquery -c faultInst -x 'query-target-filter=wcard(faultInst.dn,"radiusprovider")'

    RADIUS cisco-av-pair per RBAC

    RADIUS utilizza lo stesso cisco-av-pair attributo di TACACS+ per il mapping dei ruoli RBAC. Il server RADIUS deve restituire questo attributo nella risposta Access-Accept:

    # FreeRADIUS users file entry:
labadmin  Cleartext-Password := "password"
          Cisco-AVPair = "shell:domains=all/admin/"

    In FreeRADIUS, questa è configurata nel users file o nel back-end LDAP. Per ISE, è configurato nel profilo di autorizzazione come attributo avanzato.

    Causa principale: Mancata corrispondenza del segreto condiviso (più comune con RADIUS, causa timeout di inattività), server non raggiungibile, porta di autenticazione non corretta o account utente mancante nel server RADIUS.

    Soluzione: Correggere il segreto condiviso, verificare la raggiungibilità di UDP 1812 o configurare l'utente sul server RADIUS.

    Risoluzione dei problemi relativi a AAA - LDAP

    In questa sezione vengono descritti gli errori di autenticazione LDAP. L'APIC si connette al server LDAP tramite la porta TCP 389 (LDAP) o la porta TCP 636 (LDAPS con SSL).

    Verifica operativa

    Gli switch ACI non supportano il test aaa comando disponibile su NX-OS standalone. Per verificare il funzionamento di LDAP, controllare gli errori del provider e la configurazione da APIC.

    Verificare la presenza di errori attivi nel provider LDAP:

    apic1# moquery -c faultInst -x 'query-target-filter=wcard(faultInst.dn,"ldapprovider")'

    L'errore F1777 indica un problema di connettività. L'errore F1778 indica un errore di autenticazione o di binding. Se non vengono restituiti errori, il provider viene considerato raggiungibile.

    Verificare la raggiungibilità di base della rete al server LDAP:

    apic1# ping 10.1.1.52
PING 10.1.1.52 (10.1.1.52): 56 data bytes
64 bytes from 10.1.1.52: icmp_seq=0 ttl=64 time=0.5 ms

    Per LDAP, verificare anche la connettività TCP alla porta 389 (o 636 per LDAPS). Se l'APIC è in grado di eseguire il ping del server ma gli errori LDAP persistono, il problema è in genere un'associazione DN errata, una password errata o un firewall che blocca la porta LDAP.

    Convalidare il flusso di autenticazione LDAP nei log APIC. Filtra in base al nome utente:

    apic1# grep '||aaa||' /var/log/dme/log/nginx.bin.log | grep -i 'jsmith' | tail -20

    Funzionante: un login LDAP riuscito mostra il flusso completo di ricerca, associazione e assegnazione dei ruoli:

    ||aaa||INFO||Received PAM authenticate request from nginx for Username:  jsmith
||aaa||DBG4||DefaultAuthMo specifies realm 3. Provider Group LDAP-Domain !
||aaa||DBG4||Decoded username string to Domain:  Username: jsmith Realm 3, PG LDAP-Domain
||aaa||DBG4||Username: jsmith does not exist locally
||aaa||DBG4||Initialized LdapAuthenticationBroker for lookup of jsmith (address 10.1.1.50, hostname ssh)
||aaa||INFO||LDAP search to server ldap-server.example.com for baseDn CN=Users,DC=example,DC=com, filter sAMAccountName=jsmith
||aaa||INFO||LDAP Record DN : CN=jsmith,CN=Users,DC=example,DC=com
||aaa||DBG4||Bind to UserDN CN=jsmith,CN=Users,DC=example,DC=com using user password successful
||aaa||DBG4||	Adding WriteRole: admin
||aaa||DBG4||Converted to CiscoAVPair string shell:domains = all/admin/
||aaa||DBG4||Injection of remote user jsmith was completed
||aaa||DBG4||Checking all UserDomains under remote Username: jsmith
||aaa||DBG4||Found UserDomain all under remote Username: jsmith
||aaa||DBG4||Found Username: admin with admin write privileges under UserDomain all - user is an admin user

    Non funzionante — l'utente non è stato trovato nella directory LDAP (la ricerca restituisce un insieme vuoto):

    ||aaa||INFO||Received PAM authenticate request from nginx for Username:  baduser
||aaa||DBG4||Decoded username string to Domain:  Username: baduser Realm 3, PG LDAP-Domain
||aaa||DBG4||Username: baduser does not exist locally
||aaa||DBG4||Initialized LdapAuthenticationBroker for lookup of baduser (address 10.1.1.50, hostname REST)
||aaa||INFO||LDAP search to server ldap-server.example.com for baseDn CN=Users,DC=example,DC=com, filter sAMAccountName=baduser
||aaa||INFO||LDAP search to server ldap-server.example.com for baseDn CN=Users,DC=example,DC=com, filter sAMAccountName=baduser returned empty set
||aaa||INFO||User baduser was denied during AAA authentication
||aaa||ERROR||Unauthorized Username: baduser error: LDAP/AD Server Authentication DENIED

    Scenario: Autenticazione LDAP non riuscita

    Problema: L'accesso non riesce quando un utente seleziona un dominio di accesso LDAP.

    Fasi della verifica:

    1. Verificare la raggiungibilità del server LDAP dall'APIC: 
      apic1# ping 10.1.1.52
PING 10.1.1.52 (10.1.1.52): 56 data bytes
64 bytes from 10.1.1.52: icmp_seq=0 ttl=64 time=0.5 ms
    2. Verificare la presenza di errori del provider LDAP attivo: 
      apic1# moquery -c faultInst -x 'query-target-filter=wcard(faultInst.dn,"ldapprovider")'
    3. Verificare la configurazione del provider LDAP: 
      apic1# moquery -c aaaLdapProvider -x 'query-target-filter=eq(aaaLdapProvider.name,"10.1.1.52")'
rootdn    : CN=binduser,CN=Users,DC=example,DC=com    <--- bind DN
basedn    : CN=Users,DC=example,DC=com                 <--- search base
filter    : sAMAccountName=$userid                      <--- search filter
attribute : memberOf                                    <--- group mapping attribute
enableSSL : no                                          <--- LDAP vs LDAPS
port      : 389
    4. Verificare che l'utente sia presente nella directory LDAP sotto il DN di base configurato e che corrisponda al filtro. Per Active Directory, l'sAMAccountNameattributo dell'utente deve corrispondere al nome utente immesso al momento dell'accesso. Per OpenLDAP, l'attributo cn o deve uid corrispondere.
    5. Se si utilizza LDAPS (porta 636), verificare la catena di certificati SSL. Se SSLValidationLevel è impostato su strict, l'APIC rifiuterà la connessione se il certificato del server non è attendibile o è scaduto.
    6. Controllare l'APIC nginx.bin.log per il flusso di autenticazione LDAP completo. Filtra in base al nome utente in modo da non omettere i messaggi intermedi: 
      apic1# grep '||aaa||' /var/log/dme/log/nginx.bin.log | grep -i 'jsmith' | tail -20

      Confrontare l'output con gli esempi funzionanti e non funzionanti nella sezione Verifica operativa riportata sopra. È possibile trovare ulteriori modelli di errore specifici di LDAP eseguendo una ricerca nel log in modo ampio:

      apic1# grep '||aaa||' /var/log/dme/log/nginx.bin.log | grep -i 'LDAP\|ldap' | tail -20

      Modelli comuni non lavorativi (confrontare con gli esempi di verifica operativa sopra riportati per il flusso completo):

      ! Not Working — User not found (wrong baseDn, wrong filter, or user does not exist).
! Real example — "baduser" does not exist in the LDAP directory:
||aaa||INFO||LDAP search to server ldap-server.example.com for baseDn CN=Users,DC=example,DC=com, filter sAMAccountName=baduser
||aaa||INFO||LDAP search to server ldap-server.example.com for baseDn CN=Users,DC=example,DC=com, filter sAMAccountName=baduser returned empty set
||aaa||INFO||User baduser was denied during AAA authentication
||aaa||ERROR||Unauthorized Username: baduser error: LDAP/AD Server Authentication DENIED

      Altri modelli di errore LDAP da cercare:

      • Timeout della ricerca LDAP (server non raggiungibile, lento o porta 389/636 che blocca il firewall). Ricerca di Ldap non riuscita: codice restituito per ldap_search_ext_s: -5: Timeout
      • Binding non riuscito (password di tipo root o bind non corretta o connessione rifiutata dal server). Ricerca di Ldap non riuscita: codice restituito per ldap_search_ext_s: -1: Impossibile contattare il server LDAP
      • Trovato utente ma password errata (binding con password utente non riuscito). Il log mostra la riga DN record LDAP ma è seguito da un messaggio negato senza associare a DN utente ... riga riuscita.

    Mappa gruppo LDAP per RBAC

    LDAP utilizza le mappe di gruppo anziché l'cisco-av-pairattributo. Il campo del attribute provider LDAP specifica quale attributo LDAP contiene le informazioni sul gruppo. Per Active Directory, si tratta in genere di memberOf.

    L'APIC confronta il DN del gruppo restituito con le regole di mapping del gruppo LDAP configurate (aaaLdapGroupMapRule) per assegnare il dominio di sicurezza e il ruolo appropriati. Se nessuna regola di mapping dei gruppi corrisponde, l'utente esegue l'autenticazione ma non dispone di ruoli.

    In alternativa, è possibile impostare il valore attribute su CiscoAVPair e memorizzarlo shell:domains=all/admin/ direttamente negli attributi LDAP dell'utente, che seguono lo stesso formato di TACACS+ e RADIUS.

    Causa principale: Nome distinto di binding o password errati, il nome distinto di base non contiene l'utente, il filtro di ricerca non corrisponde allo schema della directory, un errore di convalida del certificato LDAPS o regole di mapping dei gruppi mancanti.

    Soluzione: Correggere la configurazione del provider (binding DN, DN di base, filtro, impostazioni SSL). Per i problemi RBAC, verificare che le regole di mapping dei gruppi corrispondano ai gruppi LDAP a cui appartiene l'utente.

    Risoluzione dei problemi relativi a RBAC e privilegi utente

    In questa sezione vengono descritti gli scenari in cui l'utente esegue correttamente l'autenticazione ma non dispone del livello di accesso previsto.

    Scenario: L'Utente Ha Eseguito L'Accesso Ma Non Rileva Tenant

    Problema: Un utente remoto accede tramite TACACS+, RADIUS o LDAP. L'accesso ha esito positivo, ma l'utente non vede tenant nell'interfaccia utente e le chiamate API restituiscono risultati vuoti o "403 Non consentito".

    Fasi della verifica:

    1. Controllare la sessione dell'utente per verificare quali ruoli sono stati assegnati all'accesso: 
      apic1# moquery -c aaaSessionLR -x 'query-target-filter=wcard(aaaSessionLR.descr,"jsmith")' -x 'order-by=aaaSessionLR.created|desc' -x page-size=1
dn          : subj-[uni/userext/remoteuser-jsmith]/sess-123456789
descr       : [user jsmith] From-10.1.1.100-client-type-https-Success

      Il campo descr visualizza il risultato dell'accesso. Se l'utente è stato autenticato correttamente ma non dispone di ruoli RBAC, il server AAA non ha restituito una corrispondenza di mappa di gruppo LDAP cisco-av-pair o valida.

    2. Controllare l'APIC nginx.bin.log per vedere la coppia AV e l'assegnazione dei ruoli durante l'accesso. Filtra in base al nome utente: 
      apic1# grep '||aaa||' /var/log/dme/log/nginx.bin.log | grep -i 'jsmith' | tail -20

      Cercare i messaggi relativi all'aggiunta di ruoli e all'assegnazione di domini:

      Funzionante — Coppia AV convertita dalla mappa di gruppo LDAP, l'utente ottiene il ruolo di amministratore:

      ||aaa||DBG4||	Adding WriteRole: admin
||aaa||DBG4||Converted to CiscoAVPair string shell:domains = all/admin/
||aaa||DBG4||Injection of remote user jsmith was completed
||aaa||DBG4||Checking all UserDomains under remote Username: jsmith
||aaa||DBG4||Found UserDomain all under remote Username: jsmith
||aaa||DBG4||Found Username: admin with admin write privileges under UserDomain all - user is an admin user

      Non funzionante: se nel flusso non viene visualizzata una Cisco-avpair o una Converted to CiscoAVPair linea, il server AAA non ha restituito l'attributo e non è stata trovata una corrispondenza tra le regole della mappa del gruppo LDAP. Cercare Checking all UserDomains senza alcuna Found UserDomain riga dopo. L'utente è stato autenticato ma non ha assegnazioni di ruolo. Se viene visualizzato un Injection ... data FAILED messaggio, il formato della stringa della coppia AV non è valido.

    3. Verificare che il server AAA restituisca l'cisco-av-pairattributo (per TACACS+ o RADIUS) o l'appartenenza al gruppo LDAP corretta (per LDAP). Controllare la configurazione del server AAA:
      • TACACS+: Verificare che il profilo utente includa cisco-av-pair nel formato shell:domains=all/admin/.
      • RAGGIO: Verificare la restituzione del profilo utente Cisco-AVPair = "shell:domains=all/admin/" in Access-Accept.
      • LDAP: Verificare che l'utente sia membro di un gruppo LDAP che corrisponde a una regola di mappa del gruppo LDAP (aaaLdapGroupMapRule) configurata.
    4. Se l'attributo è presente ma l'utente non ha ancora accesso, verificare che il nome del dominio di sicurezza nell'attributo corrisponda a un dominio di sicurezza esistente nell'APIC: 
      apic1# moquery -c aaaDomain

      cisco-av-pair Se fa riferimento a un dominio che non esiste (ad esempio, shell:domains=NonExistentDomain/admin/), l'assegnazione del ruolo ha esito negativo in modo invisibile all'utente.

    Causa principale: Il server AAA non restituisce gli attributi di mapping RBAC, il formato dell'attributo non è corretto o il dominio di sicurezza a cui si fa riferimento nell'attributo non esiste nell'APIC.

    Soluzione: Configurare il server AAA in modo che restituisca il mapping corretto cisco-av-pair o di gruppo. Verificare che il dominio di sicurezza esista nell'APIC.

    Scenario: L'Utente Può Visualizzare Ma Non Modificare La Configurazione

    Problema: Un utente può accedere e sfogliare gli oggetti ma riceve un errore quando tenta di inviare le modifiche.

    Fasi della verifica:

    1. Verificare le assegnazioni di ruolo dell'utente: 
      apic1# moquery -c aaaUserRole -x 'query-target-filter=wcard(aaaUserRole.dn,"user-jsmith")'
dn        : uni/userext/user-jsmith/userdomain-all/role-read-all
name      : read-all
privType  : readPriv                   <--- read only, no write privilege
    2. Se l'utente necessita dell'accesso in scrittura, il ruolo deve concedere writePriv. I ruoli comuni con privilegi di scrittura includono admin, tenant-admin, access-admin e fabric-admin.
    3. Convalidare l'assegnazione di ruolo nei registri APIC. Filtra in base al nome utente: 
      apic1# grep '||aaa||' /var/log/dme/log/nginx.bin.log | grep -i 'jsmith' | tail -20

      Cercare i messaggi di assegnazione dei ruoli alla fine del flusso di autenticazione:

      Funzionante: l'utente dispone del ruolo di scrittura amministratore (da un accesso LDAP reale):

      ||aaa||DBG4||Checking all UserDomains under remote Username: jsmith
||aaa||DBG4||Found UserDomain all under remote Username: jsmith
||aaa||DBG4||Found Username: admin with admin write privileges under UserDomain all - user is an admin user

      Non funzionante: se nel log viene visualizzato UserRole non admin con privilegi di lettura anziché privilegi di scrittura admin, l'utente dispone di un ruolo di sola lettura e non può modificare la configurazione. Cerca righe come:

      ||aaa||DBG4||Found non-admin UserRole read-all (read privileges) under UserDomain all

      Se nel registro vengono visualizzati solo i privilegi di lettura e nessun privilegio di scrittura, aggiornare il ruolo dell'utente o la coppia AV sul server AAA.

    Causa principale: L'utente dispone di un ruolo di sola lettura (ad esempio, read-all o ops) anziché di un ruolo che supporta la scrittura.

    Soluzione: Aggiornare l'assegnazione del ruolo dell'utente sull'APIC (per gli utenti locali) o aggiornare l'cisco-av-pairassegnazione sul server AAA (per gli utenti remoti) in modo da includere un ruolo con privilegi di scrittura.

    Scenario: L'Utente Può Accedere Ad Alcuni Tenant Ma Non Ad Altri

    Problema: Un utente può visualizzare e gestire un tenant, ma non altri tenant, anche se necessitano di accesso.

    Fasi della verifica:

    1. Controllare l'assegnazione del dominio di protezione dell'utente: 
      apic1# moquery -c aaaUserDomain -x 'query-target-filter=wcard(aaaUserDomain.dn,"user-jsmith")'
dn    : uni/userext/user-jsmith/userdomain-TenantA
name  : TenantA                       <--- only has access to TenantA
    2. I domini di sicurezza eseguono il mapping ai tenant. Se l'utente ha bisogno di accedere a TenantB, deve anche essere assegnato al dominio di sicurezza associato a TenantB o al dominio all.
    3. Per gli utenti remoti, verificare che la coppia AV o la mappa del gruppo LDAP assegni i domini corretti. Controllare l'APIC nginx.bin.log per l'assegnazione del dominio al momento dell'accesso. Filtra in base al nome utente: 
      apic1# grep '||aaa||' /var/log/dme/log/nginx.bin.log | grep -i 'jsmith' | tail -20

      Funzionante: l'utente dispone del dominio all (visibilità completa), da un accesso LDAP reale:

      ||aaa||DBG4||Converted to CiscoAVPair string shell:domains = all/admin/
||aaa||DBG4||Injection of remote user jsmith was completed
||aaa||DBG4||Found UserDomain all under remote Username: jsmith
||aaa||DBG4||Found Username: admin with admin write privileges under UserDomain all - user is an admin user

      Non funzionante: se l'utente dispone di un solo dominio tenant, nei Found UserDomain messaggi viene visualizzato solo quel dominio anziché tutti. Ad esempio, Found UserDomain TenantA indica che l'utente può vedere solo TenantA. L'utente ha bisogno di domini aggiuntivi aggiunti alla coppia AV sul server AAA o del dominio all per l'accesso completo.

    Causa principale: L'utente è assegnato a un dominio di sicurezza con restrizioni che copre solo tenant specifici.

    Soluzione: Aggiungere i domini di sicurezza richiesti alla configurazione dell'utente oppure utilizzare il dominio all per l'accesso completo.

    Recupero password e accesso di emergenza

    Se tutti gli account di amministrazione sono bloccati o il server AAA remoto non è raggiungibile e il realm predefinito è stato modificato, utilizzare uno dei metodi di ripristino seguenti:

    Dominio di accesso fallback

    ACI fornisce un dominio di accesso di fallback incorporato che utilizza sempre l'autenticazione locale, indipendentemente dal realm di autenticazione predefinito. Per utilizzarlo:

    • SSH: Accedere come apic:fallback\\admin (o apic#fallback\\admin a seconda della versione).
    • GUI: Nell'elenco a discesa Dominio della schermata di accesso, selezionare fallback e utilizzare le credenziali locali.

    Accesso alla console

    Se il realm di autenticazione della console è impostato su local (impostazione predefinita), è sempre possibile eseguire l'accesso tramite la porta della console APIC con le credenziali locali. Se la password dell'amministratore locale è sconosciuta, è possibile reimpostarla tramite Cisco Integrated Management Controller (CIMC) (per gli APIC fisici) o tramite la console dell'hypervisor (per gli APIC virtuali).

    Nota: Se il realm di autenticazione della console è stato modificato in un server AAA remoto e tale server non è raggiungibile, anche l'accesso alla console avrà esito negativo. Si tratta di uno scenario comune di blocco. Mantenere sempre il realm di autenticazione della console impostato su locale.

    Riferimento a errori comuni

    I seguenti errori ACI sono in genere associati a problemi di accesso remoto e AAA:

    • F1773 — Problema di connettività del provider TACACS+. L'APIC non è in grado di raggiungere il server TACACS+.
    • F1774 - Errore di autenticazione TACACS+. Il server è raggiungibile ma ha rifiutato il tentativo di autenticazione.
    • F1775: problema di connettività del provider RADIUS.
    • F1776: errore di autenticazione RADIUS.
    • F1777: problema di connettività del provider LDAP.
    • F1778: errore di autenticazione LDAP.
    • F0532 — Subnet di gestione non configurata per un nodo.

    Errori AAA attivi query:

    apic1# moquery -c faultInst -x 'query-target-filter=or(wcard(faultInst.dn,"tacacsplusprovider"),wcard(faultInst.dn,"radiusprovider"),wcard(faultInst.dn,"ldapprovider"))'

    Riferimenti

    Cronologia delle revisioni

    Revisione Data di pubblicazione Commenti
    1.0
    09-Apr-2026
    Versione iniziale
    TAC Authored

    Contributo dei tecnici Cisco

    • Aggregato da contenuto TAC creato

    Questo documento ti è stato utile?

    FeedbackFeedback

    Contattaci

    Questo documento si applica a questi prodotti