Este documento describe cómo verificar, resolver y resolver problemas de acceso remoto en un fabric de Cisco Application Centric Infrastructure (ACI). Abarca el acceso Secure Shell (SSH) y el protocolo de transferencia de hipertexto (HTTPS) a los APIC y los switches de fabric, la autenticación, autorización y administración de cuentas (AAA) remotas con Terminal Access Controller Access-Control System Plus (TACACS+), el servicio de usuario de acceso telefónico de autenticación remota (RADIUS), el protocolo ligero de acceso a directorios (LDAP) y la autorización de control de acceso basado en roles (RBAC). Para cada área se incluye un árbol de decisiones de clasificación y escenarios detallados de resolución de problemas.
El material de este documento se sintetizó a partir de la guía Troubleshooting ACI Management and Core Services — Pod Policies, la Guía de Configuración Básica de Cisco APIC, Release 6.1(x) — Management capítulo, y la Guía de Configuración de Seguridad de Cisco APIC — Access, Authentication, and Accounting capítulo.
El acceso remoto a un fabric de ACI implica tres capas distintas, cada una de las cuales debe funcionar para que un ingeniero inicie sesión y funcione correctamente:
Un fallo en cualquier capa produce síntomas diferentes. Una falla de transporte impide la conexión por completo. Un error de autenticación devuelve un error de credenciales. Un fallo de autorización permite el inicio de sesión, pero restringe la visibilidad o produce errores "403 Forbidden" (Prohibido) en la API.
La directiva de acceso a la administración (commPol) es el objeto central que controla qué protocolos de acceso remoto están habilitados en el fabric. Se encuentra en Fabric > Fabric Policies > Policies > Pod > Management Access > default. La directiva contiene objetos secundarios que configuran:
commSsh): estado administrativo, puerto, cifrados, algoritmos de intercambio de claves (KEX), códigos de autenticación de mensajes (MAC) y algoritmos de clave de host.commHttps): estado administrativo, puerto, versión de protocolo de seguridad de la capa de transporte (TLS), velocidad de aceleración y autenticación de certificado de cliente.commTelnet): estado administrativo y puerto. Telnet está deshabilitado de forma predeterminada y Cisco recomienda que permanezca deshabilitado.Los nodos ACI admiten dos rutas de acceso a la gestión:
mgmtRsOoBStNode. En el APIC, los contratos OOB se aplican mediante iptables reglas. Si se aplica un contrato OOB, solo el tráfico permitido explícitamente por el contrato puede alcanzar la interfaz de gestión APIC.ACI utiliza un modelo AAA de tres niveles:
aaaLoginDomain): agrupa los proveedores AAA bajo un rango con nombre. Los usuarios especifican el dominio de inicio de sesión en la pantalla de inicio de sesión (por ejemplo, apic:TACACS-Domain o a través del menú desplegable de la interfaz de usuario). Siempre existe un dominio de inicio de sesión de reserva especial y se asigna a la autenticación local.aaaTacacsPlusProviderGroup, aaaRadiusProviderGroup, aaaLdapProviderGroup): hace referencia a uno o más servidores AAA y define el orden en el que se prueban.aaaTacacsPlusProvider, aaaRadiusProvider, aaaLdapProvider): define la IP del servidor, el puerto, el secreto compartido (o DN de enlace para LDAP), el tiempo de espera, los reintentos, el EPG de administración y las credenciales de supervisión.El rango de autenticación predeterminado (aaaDefaultAuth) determina qué dominio de inicio de sesión se utiliza cuando el usuario no especifica uno al iniciar sesión. El rango de autenticación de la consola controla la autenticación para las sesiones de la consola.
Los eventos de autenticación AAA se registran en varios archivos tanto en el APIC como en los switches de fabric. Estos registros son la herramienta principal para validar los resultados de autenticación, identificar el rango y el grupo de proveedores que se está utilizando, y diagnosticar errores de asignación de roles.
| Archivo de registro | Ubicación (APIC) | Ubicación (switches) | Descripción |
|---|---|---|---|
| nginx.bin.log (APIC) nginx.log (switches) |
/var/log/dme/log/nginx.bin.log |
/var/sysmgr/tmp_logs/dme_logs/nginx.log |
Registro AAA principal. Contiene el flujo de autenticación completo: solicitud de PAM, selección de rango, búsqueda de proveedor, comunicación LDAP/TACACS+/RADIUS, análisis de pares AV, asignación de dominio y rol, y resultado de denegación o éxito. El nombre de archivo difiere entre las plataformas, pero el formato de contenido es el mismo. |
| access.log | /var/log/dme/log/access.log |
/var/log/dme/log/access.log |
Registro de solicitudes HTTP de NGINX. Una línea por solicitud de API. En el APIC, muestra las llamadas aaaLogin y aaaRefresh con códigos de estado HTTP (200 = correcto, 401 = denegado). En los switches, muestra las solicitudes de API DME internas y las llamadas aaaRefresh. |
| pam.module.log | /var/log/dme/log/pam.module.log |
/var/log/dme/log/pam.module.log |
registro del módulo PAM. Muestra el resultado de la autenticación para las sesiones SSH: usuario autenticado, IP de origen e ID de usuario de UNIX asignado. En los switches, esta es la manera más rápida de confirmar si un usuario fue autenticado o rechazado. |
Las entradas AAA en el registro nginx siguen este formato:
PID||TIMESTAMP||aaa||SEVERITY||CONTEXT||MESSAGE||SOURCE_FILE||LINE
Filtrar entradas de registro relacionadas con AAA para el flujo de autenticación de un usuario específico:
! 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
O vea todas las solicitudes de autenticación y resultados recientes:
! 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
Un flujo de autenticación exitoso típico muestra estos mensajes clave en orden:
Solicitud de autenticación de PAM recibida de nginx para el nombre de usuario: <user>: se recibió la solicitud de inicio de sesión.DefaultAuthMo especifica el rango <N>. Grupo de proveedores <name> ! — el rango fue seleccionado (0=fallback/local, 2=TACACS+, 3=LDAP).Se encontró UserDomain <domain> en el nombre de usuario remoto: <user>: la asignación de dominio de la respuesta AAA.Nombre de usuario encontrado admin con privilegios de escritura admin en UserDomain all (el usuario es un usuario admin): se ha superado la comprobación de rol.Registros de autenticación fallidos:
El usuario <user> fue denegado durante la autenticación AAAError <user> de usuario no autorizado: Autenticación de servidor AAA DENEGADA! 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'
ACI RBAC controla lo que un usuario autenticado puede ver y hacer. El modelo tiene tres componentes:
aaaDomain): un limitador de alcance que se asigna a objetos de ACI (arrendatarios, políticas de acceso, políticas de fabric). Los dominios integrados all, common y mgmt siempre están presentes. Los dominios personalizados restringen la visibilidad de un usuario a arrendatarios o áreas de políticas específicas.aaaRole): define un conjunto de privilegios. Los roles predefinidos incluyen admin, aaa, tenant-admin, tenant-ext-admin, read-all, access-admin, fabric-admin, ops y new-svc-admin.A una cuenta de usuario se le asignan uno o más pares de roles y dominios de seguridad. Para los usuarios remotos autenticados a través de TACACS+, RADIUS o LDAP, la asignación de roles se entrega a través de atributos específicos del proveedor en la respuesta AAA (por ejemplo, el cisco-av-pair atributo).
Utilice este árbol de decisiones cuando un usuario informe de que no puede acceder al fabric de ACI de forma remota:
Antes de resolver problemas de estado operativo, verifique que la cadena de configuración esté completa. La configuración incorrecta es la causa principal más común de los problemas de acceso remoto.
Vaya a Fabric > Fabric Policies > Policies > Pod > Management Access > default.


Confirme los siguientes parámetros de SSH:
Consulte el objeto administrado de SSH a través de la 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
Confirme la siguiente configuración de HTTPS:
apic1# moquery -c commHttps dn : uni/fabric/comm-default/https adminSt : enabled <--- must be enabled port : 443 sslProtocols : TLSv1.2 throttleSt : enabled throttleRate : 2
diffie-hellman-group14-sha1) pueden fallar en el intercambio de claves. El cliente SSH muestra "no se ha encontrado ninguna clave coincidente" o "no se ha encontrado ningún método de intercambio de claves coincidente".passwordAuth se establece en desactivada, sólo se permite la autenticación basada en clave SSH. Los usuarios que se conecten con contraseñas verán "Permiso denegado (clave pública)".ssh -p 2222 admin@10.1.1.1).Vaya a Arrendatarios > Administración > Direcciones de administración de nodos.
Confirme que cada APIC y nodo de switch tenga una dirección IP de administración OOB asignada con una gateway válida. Los nodos sin direcciones de administración no serán accesibles a través de la red de administración.
Consulte las asignaciones de nodos estáticos OOB a través de la 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
mgmtRsOoBStNode. El nodo no tendrá una IP de administración y no responderá a SSH o HTTPS en la interfaz OOB.Navegue hasta Arrendatarios > Administración > Contratos.
Si se aplica un contrato OOB al EPG de gestión OOB, solo el tráfico permitido explícitamente por dicho contrato alcanzará la interfaz de gestión APIC. En el APIC, los contratos OOB se aplican mediante iptables reglas.
Consulte los contratos proporcionados por OOB EPG:
apic1# moquery -c mgmtRsOoBProv -x 'query-target-filter=wcard(mgmtRsOoBProv.dn,"oob-default")'
Si la consulta devuelve resultados, se aplican los contratos. Verifique que los sujetos del contrato y los filtros permitan los protocolos requeridos:
iptables reglas del APIC descartan el tráfico en silencio.Vaya a Admin > AAA > Authentication > AAA.

Confirme lo siguiente:
Vaya a Admin > AAA > Authentication > Login Domains.
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
Verifique que el dominio de inicio de sesión utilizado para la autenticación esté presente y que haga referencia al grupo de proveedores correcto.
Vaya a Admin > AAA > Authentication > TACACS+ > TACACS+ Providers.
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
Vaya a Admin > AAA > Authentication > RADIUS > RADIUS Providers.
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
Vaya a Admin > AAA > Authentication > LDAP > LDAP Providers.
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
epgDn está vacío o apunta al EPG incorrecto (por ejemplo, en banda cuando el servidor está en la red OOB). El APIC no puede alcanzar el servidor.rootdn (DN de enlace) o basedn son incorrectos. La autenticación LDAP falla con un error de enlace incluso cuando las credenciales del usuario son correctas.sAMAccountName=$userid. Para OpenLDAP, utilice cn=$userid o uid=$userid.Navegue hasta Admin > AAA > Users para ver las cuentas de usuario local y sus asignaciones de dominio y rol de seguridad.
Consulte dominios de seguridad a través de la 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 usuario asignado al dominio all con el rol admin tiene acceso completo de lectura y escritura a todo el fabric. Un usuario asignado a un dominio de seguridad personalizado con el rol tenant-admin solo puede administrar arrendatarios asociados a ese dominio.
cisco-av-pair atributo que contiene shell:domains=all/admin/. El usuario se autentica correctamente pero no tiene funciones y no puede ver nada en el fabric.Si el APIC o la IP de administración del switch no es accesible en la red, resuelva el problema de la trayectoria de administración antes de investigar SSH, HTTPS o AAA.
Problema: La estación de administración no puede hacer ping a la dirección IP de administración OOB de APIC.
Pasos de verificación:
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
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
iptables reglas en el APIC. Puede ver las reglas guardadas desde el shell APIC:
apic1# cat /etc/sysconfig/iptables | grep -A 20 "filter"
Si la política INPUT es DROP y no existe una regla ACCEPT para el protocolo requerido, el contrato OOB está filtrando el tráfico.
Causa raíz: Falta la dirección de administración OOB o está mal configurada, el gateway es incorrecto o el tráfico de filtrado de contratos OOB es incorrecto.
Solución: Corrija la asignación de la dirección OOB, verifique la ruta de la red física o actualice el contrato OOB para permitir los protocolos requeridos.
Problema: La estación de administración puede alcanzar el APIC pero no puede alcanzar un switch mediante OOB.
Pasos de verificación:
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
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
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 raíz: Falta la asignación de la dirección OOB, el gateway es incorrecto o el puerto físico de administración del switch está inactivo.
Solución: Asigne la dirección OOB en Arrendatarios > Administración > Direcciones de administración de nodos. Verifique que el link de administración física esté activo.
Esta sección cubre escenarios donde la IP de administración es alcanzable (ping exitoso) pero la sesión SSH no puede establecer o autenticar.
Problema: El cliente SSH informa de "Conexión rechazada" cuando se conecta al APIC o al switch.
Pasos de verificación:
apic1# moquery -c commSsh -x 'query-target-filter=eq(commSsh.adminSt,"enabled")' dn : uni/fabric/comm-default/ssh adminSt : enabled port : 22
Si adminSt está inhabilitado, se rechazan las conexiones SSH.
$ ssh -p custom-port admin@10.1.1.1
Causa raíz: SSH desactivado en la política de acceso a la gestión, el puerto personalizado desconocido para el cliente o el filtrado de contratos OOB.
Solución: Habilite SSH en la política de acceso a la administración o utilice el puerto correcto.
Problema: El cliente SSH falla con "no se encontró código que coincida", "no se encontró método de intercambio de claves que coincida" o "no se encontró MAC que coincida".
Pasos de verificación:
$ 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
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
Causa raíz: No hay cifrado, algoritmo KEX o MAC común entre el cliente SSH y el APIC después de una actualización de ACI o endurecimiento de cifrado.
Solución: Actualice el cliente SSH para soportar algoritmos modernos, o vuelva a agregar el algoritmo heredado requerido a la política de acceso a la administración. La reincorporación de algoritmos heredados conlleva riesgos de seguridad y no se recomienda a largo plazo.
Problema: El protocolo de enlace SSH se ha establecido correctamente (aparece el mensaje de contraseña), pero la contraseña se rechaza para un usuario local.
Pasos de verificación:
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
apic1# moquery -c aaaUserEp dn : uni/userext pwdStrengthCheck : no
Verifique la política de bloqueo del dominio de inicio de sesión en Admin > AAA > Security Management > Lockout Policy.
apic:LOCAL\\username o apic:fallback\\username para forzar la autenticación local.nginx.bin.log el APIC para el evento de inicio de sesión:
apic1# grep '||aaa||' /var/log/dme/log/nginx.bin.log | grep -i 'admin' | tail -20
Busque el rango y el grupo de proveedores asignados al intento de inicio de sesión:
! 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
Si el rango no es 0 (reserva/local), el login fue enviado a un servidor AAA remoto en lugar de a la base de datos local. El usuario debe anteponer apic:fallback\\username o apic:LOCAL\\username para forzar la autenticación local.
Causa raíz: Se está enviando una contraseña incorrecta, una cuenta bloqueada o un intento de inicio de sesión a un servidor AAA remoto en lugar de a la base de datos local.
Solución: Restablezca la contraseña, desbloquee la cuenta o utilice el prefijo de dominio de inicio de sesión correcto.
En esta sección se tratan situaciones en las que la interfaz de usuario web de APIC o la interfaz de programación de aplicaciones (API) de transferencia de estado representacional (REST) no es accesible a través de HTTPS.
Problema: El navegador muestra "ERR_CONNECTION_TIMED_OUT" o la llamada API se bloquea al conectarse al APIC en el puerto 443.
Pasos de verificación:
apic1# moquery -c commHttps -x 'query-target-filter=eq(commHttps.adminSt,"enabled")' dn : uni/fabric/comm-default/https adminSt : enabled port : 443
apic1# ss -tlnp | grep 443
LISTEN 0 128 *:443 *:* users:(("nginx",pid=12345,fd=6))
Causa raíz: HTTPS deshabilitado, el filtrado de contratos OOB TCP 443 o el proceso nginx en el APIC se ha bloqueado.
Solución: Habilite HTTPS en la política de acceso a la gestión, actualice el contrato OOB o reinicie el servicio web en el APIC.
Problema: El navegador muestra "ERR_SSL_VERSION_OR_CIPHER_MISMATCH" o un error de TLS similar.
Pasos de verificación:
apic1# moquery -c commHttps sslProtocols : TLSv1.2
Causa raíz: El APIC solo ofrece TLSv1.2 (el valor predeterminado) y el navegador o el cliente de API solo admite versiones de TLS más antiguas.
Solución: Actualice el explorador o el cliente. Si debe admitir clientes más antiguos temporalmente, agregue TLSv1.1 a la directiva de acceso a la administración, pero esto supone un riesgo para la seguridad.
Problema: Las llamadas de API REST fallan intermitentemente con errores de HTTP 503 o la interfaz de usuario web se ralentiza durante una automatización intensa.
Pasos de verificación:
apic1# moquery -c commHttps throttleSt : enabled throttleRate : 2 <--- requests per second per user
Si la velocidad del acelerador es muy baja y los scripts de automatización envían muchas solicitudes por segundo, el APIC rechaza las solicitudes en exceso.
Causa raíz: La velocidad del acelerador por usuario es demasiado baja para la carga de trabajo de automatización.
Solución: Aumente la velocidad del acelerador según la política de acceso a la gestión u optimice los scripts de automatización para reducir la frecuencia de las solicitudes. Como alternativa, desactive la limitación si el fabric no está compartido.
Esta sección cubre los fallos de autenticación de TACACS+. El APIC se comunica con el servidor TACACS+ a través del puerto TCP 49.
Los switches ACI no admiten el test aaa comando disponible en NX-OS independiente. Para verificar el funcionamiento de TACACS+, utilice el APIC para comprobar el estado del proveedor, los fallos y el historial de sesiones de inicio de sesión.
Verifique si hay fallas activas en el proveedor TACACS+:
apic1# moquery -c faultInst -x 'query-target-filter=wcard(faultInst.dn,"tacacsplusprovider")'
Si no se devuelve ningún error, el APIC considera que el proveedor es accesible. Si hay errores, el resultado incluye códigos de error como F1773 (proveedor inalcanzable) o F1774 (error de autenticación).
Verifique la configuración del proveedor 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
Verifique el alcance básico de la red desde el APIC al servidor 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
Intente iniciar sesión en el APIC con el dominio de inicio de sesión TACACS+ y compruebe el resultado de la sesión:
apic1# moquery -c aaaSessionLR -x 'order-by=aaaSessionLR.created|desc' -x page-size=5
Mire el descr campo para determinar si la falla se debió al rechazo de la autenticación o a un problema de conectividad.
Valide el flujo de autenticación TACACS+ en los registros APIC. Filtro para el nombre de usuario en cuestión:
apic1# grep '||aaa||' /var/log/dme/log/nginx.bin.log | grep -i 'username' | tail -20
Los inicios de sesión de TACACS+ siguen el mismo flujo de nginx.bin.log autenticación que LDAP (consulte la sección Verificación operativa de LDAP para ver ejemplos completos de registros reales). Las diferencias clave para TACACS+ son:
DefaultAuthMo especifica el rango 2: el rango 2 indica TACACS+ (frente al rango 3 para LDAP).Agregar TacACSProvider <IP> a la lista — identifica el servidor TACACS+ con el que se está contactando (frente a LdapProvider para LDAP).TACACS+ Cisco-avpair (shell:domains=all/admin/): el par AV es devuelto directamente por el servidor TACACS+ (en lugar de ser convertido desde un mapa de grupo LDAP).Un inicio de sesión exitoso de TACACS+ muestra la misma progresión: Solicitud PAM → selección de rango → búsqueda de proveedor → análisis de pares AV → inyección de usuario → UserDomain y asignación de rol → privilegios de escritura de administrador.
Un inicio de sesión fallido de TACACS+ termina con Usuario <nombre de usuario> fue denegado durante la autenticación AAA y error Unauthorized ...: Autenticación de servidor AAA DENEGADA, el mismo patrón que una denegación LDAP.
Problema: El login falla con "Authentication Failed" cuando el usuario selecciona un dominio de login TACACS+.
Pasos de verificación:
apic1# moquery -c faultInst -x 'query-target-filter=wcard(faultInst.dn,"tacacsplusprovider")'
El error F1773 indica un problema de conectividad. El error F1774 indica un rechazo de autenticación.
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
apic1# moquery -c aaaSessionLR -x 'order-by=aaaSessionLR.created|desc' -x page-size=5
nginx.bin.log para obtener el flujo de autenticación completo. Filtre por el nombre de usuario en lugar de palabras clave específicas para que no se pierdan los mensajes intermedios:
apic1# grep '||aaa||' /var/log/dme/log/nginx.bin.log | grep -i 'tacuser1' | tail -20
Compare el resultado con los ejemplos de funcionamiento y de no funcionamiento de la sección Verificación operativa anterior. Indicadores clave:
fue denegado o DENEGADO: se alcanzó el servidor TACACS+ pero se rechazaron las credenciales. Compruebe que el usuario existe en el servidor y que la contraseña coincide.Agregar TacacsProvider: el servidor está inaccesible o con tiempo de espera agotado. Verifique la disponibilidad de la red y el EPG de administración.La inyección de usuario remoto... se completó seguida de líneas de comprobación de funciones: la autenticación se realizó correctamente, pero el problema puede estar relacionado con la asignación de funciones (consulte la sección de pares AV a continuación).Para los usuarios remotos autenticados a través de TACACS+, el servidor debe devolver el cisco-av-pair atributo en la respuesta de autorización. Este atributo asigna al usuario a los roles y dominios de seguridad de ACI.
Formato:
shell:domains=domain/role/
Examples:
shell:domains=all/admin/shell:domains=all/read-all/shell:domains=TenantA/tenant-admin/shell:domains=all/admin/,TenantA/tenant-admin/Si falta este atributo o está mal formado, el usuario se autentica correctamente pero no tiene funciones y no puede ver ningún objeto en la interfaz de usuario de APIC.
Valide el par AV recibido mediante la comprobación nginx.bin.log. Filtre por el nombre de usuario para ver el flujo de inyección de roles completo:
apic1# grep '||aaa||' /var/log/dme/log/nginx.bin.log | grep -i 'username' | tail -20
Para TACACS+, el par AV se registra como TACACS+ Cisco-avpair (shell:domains=...). Una inyección exitosa muestra Injection of remote user <username> was completed seguido de Found UserDomain y admin write privilege lines (vea la sección LDAP Operational Verification para obtener ejemplos completos de este flujo con salida de registro real).
Si el formato de par AV no es válido, el registro muestra Injection of remote user <username> data FAILED - error message is Invalid shell:domains string. Si el usuario se autentica con un rol no administrador, se deniega el SSH a los switches y se deniegan los inicios de sesión no administrativos en el switch.
Causa raíz: Discordancia de secreto compartido, servidor inaccesible desde la red de administración, usuario no existente en el servidor TACACS+ o el EPG de administración en el proveedor es incorrecto.
Solución: Corrija el secreto compartido, corrija la disponibilidad o cree el usuario en el servidor TACACS+.
En los switches de columna y hoja, los eventos de inicio de sesión SSH se registran en pam.module.log y nginx.log. El pam.module.log muestra el resultado de la autenticación de PAM (aceptar o rechazar). El nginx.log contiene el flujo AAA completo —selección de rango, búsqueda de proveedor, comunicación LDAP/TACACS+/RADIUS, análisis de pares AV y asignación de roles— idéntico al nginx.bin.log del APIC. Estos registros se aplican a todos los tipos de AAA remotos (TACACS+, RADIUS, LDAP).
Verifique pam.module.log el resultado de la autenticación:
leaf101# cat /var/sysmgr/tmp_logs/pam.module.log | tail -30
Funcionando — autenticación remota exitosa en el switch:
||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
El remote=1 indicador confirma que el usuario fue autenticado por un servidor AAA remoto.
No funciona: el usuario fue rechazado. SecurityMgrAG deniega al usuario y el switch intenta realizar una búsqueda de usuario local como reserva final:
||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
Si no aparece ninguna entrada de PAM para el usuario, es probable que la conexión SSH se haya rechazado antes de alcanzar la fase de PAM (por ejemplo, debido a una discordancia de cifrado o a que el usuario ha cancelado la conexión).
Para obtener una vista más detallada del flujo de autenticación en el switch, verifique nginx.log. Este registro contiene la cadena de decisión AAA completa, con el mismo formato y mensajes que nginx.bin.log en el APIC:
leaf101# grep '||aaa||' /var/sysmgr/tmp_logs/dme_logs/nginx.log | grep -i 'username' | tail -20
En funcionamiento — autenticación LDAP correcta en un switch (comparar con los ejemplos de LDAP APIC en la sección Verificación operativa de LDAP — los mensajes son los mismos):
||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
El switch nginx.log es particularmente útil cuando pam.module.log muestra un rechazo pero no explica por qué. El archivo nginx.log revela el rango AAA, el proveedor y la razón de falla específica (por ejemplo, la búsqueda LDAP devolvió vacío, el tiempo de espera TACACS+ o la inyección de par AV falló).
Esta sección trata sobre fallas de autenticación RADIUS. El APIC se comunica con el servidor RADIUS a través del puerto UDP 1812 (autenticación) y opcionalmente el puerto UDP 1813 (contabilidad).
Los switches ACI no admiten el test aaa comando disponible en NX-OS independiente. Utilice los métodos siguientes para verificar el funcionamiento de RADIUS.
Verifique la configuración del servidor RADIUS y las estadísticas de alcance desde un switch hoja:
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
Problema: El login falla cuando un usuario selecciona un dominio de login RADIUS.
Pasos de verificación:
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 conteo alto en solicitudes con tiempo de espera agotado indica que el servidor RADIUS es inalcanzable o que el secreto compartido no coincide (RADIUS descarta silenciosamente los paquetes en la discordancia del secreto compartido).
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
radiusd -X) muestra cada solicitud e indica si fue aceptada, rechazada o si tenía una discordancia secreta compartida.nginx.bin.log para el flujo de autenticación RADIUS. Filtrar por nombre de usuario:
apic1# grep '||aaa||' /var/log/dme/log/nginx.bin.log | grep -i 'username' | tail -20
Los inicios de sesión RADIUS siguen el mismo flujo de nginx.bin.log autenticación que LDAP y TACACS+ (consulte la sección Verificación operativa de LDAP para ver ejemplos completos de registros reales). Las diferencias clave para RADIUS son:
Agregar RadiusProvider <IP> a la lista: identifica el servidor RADIUS (frente a TacacsProvider o LdapProvider).Un inicio de sesión exitoso de RADIUS termina con Inyección de usuario remoto ... fue completado y privilegios de escritura de administrador.
Un login fallido de RADIUS termina con fue denegado durante la autenticación AAA y DENIED.
Si no aparece ningún mensaje específico de RADIUS después de la línea Adding RadiusProvider, el servidor ha agotado el tiempo de espera. A diferencia de TACACS+, que utiliza TCP e informa de fallos de conexión, RADIUS utiliza UDP y descarta paquetes de forma silenciosa cuando el secreto compartido no coincide. El único síntoma es un tiempo de espera seguido de una negación.
apic1# moquery -c faultInst -x 'query-target-filter=wcard(faultInst.dn,"radiusprovider")'
RADIUS utiliza el mismo cisco-av-pair atributo que TACACS+ para la asignación de roles RBAC. El servidor RADIUS debe devolver este atributo en la respuesta Access-Accept:
# FreeRADIUS users file entry:
labadmin Cleartext-Password := "password"
Cisco-AVPair = "shell:domains=all/admin/"
En FreeRADIUS, esto se configura en el users archivo o backend LDAP. Para ISE, se configura en el perfil de autorización como un atributo avanzado.
Causa raíz: Discordancia de secreto compartido (más común con RADIUS: provoca tiempos de espera silenciosos), servidor inalcanzable, puerto de autenticación incorrecto o cuenta de usuario faltante en el servidor RADIUS.
Solución: Corrija el secreto compartido, verifique la disponibilidad de UDP 1812 o configure el usuario en el servidor RADIUS.
Esta sección cubre los errores de autenticación LDAP. El APIC se conecta al servidor LDAP a través del puerto TCP 389 (LDAP) o el puerto TCP 636 (LDAP con SSL).
Los switches ACI no admiten el test aaa comando disponible en NX-OS independiente. Para verificar el funcionamiento de LDAP, verifique los fallos del proveedor y la configuración desde el APIC.
Verifique si hay fallas activas en el proveedor LDAP:
apic1# moquery -c faultInst -x 'query-target-filter=wcard(faultInst.dn,"ldapprovider")'
El error F1777 indica un problema de conectividad. El error F1778 indica una falla de autenticación o de enlace. Si no se devuelve ningún error, el APIC considera que el proveedor es accesible.
Verifique el alcance básico de la red al servidor 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
Para LDAP, verifique también la conectividad TCP con el puerto 389 (o 636 para LDAP). Si el APIC puede hacer ping al servidor pero persisten los fallos de LDAP, el problema suele ser un DN de enlace incorrecto, una contraseña incorrecta o un firewall que bloquea el puerto LDAP.
Valide el flujo de autenticación LDAP en los registros de APIC. Filtrar por nombre de usuario:
apic1# grep '||aaa||' /var/log/dme/log/nginx.bin.log | grep -i 'jsmith' | tail -20
En funcionamiento: un inicio de sesión LDAP correcto muestra el flujo completo de búsqueda, vinculación y asignación de roles:
||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
No funciona — usuario no encontrado en el directorio LDAP (la búsqueda devuelve un conjunto vacío):
||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
Problema: El inicio de sesión falla cuando un usuario selecciona un dominio de inicio de sesión LDAP.
Pasos de verificación:
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
apic1# moquery -c faultInst -x 'query-target-filter=wcard(faultInst.dn,"ldapprovider")'
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
sAMAccountName atributo del usuario debe coincidir con el nombre de usuario introducido al iniciar sesión. Para OpenLDAP, el atributo cn o debe coincidir con el uid atributo.SSLValidationLevel se establece en strict, el APIC rechazará la conexión si el certificado del servidor no es confiable o ha caducado.nginx.bin.log para el flujo de autenticación LDAP completo. Filtre por el nombre de usuario para que no se pierdan los mensajes intermedios:
apic1# grep '||aaa||' /var/log/dme/log/nginx.bin.log | grep -i 'jsmith' | tail -20
Compare el resultado con los ejemplos de funcionamiento y de no funcionamiento de la sección Verificación operativa anterior. Se pueden encontrar patrones de falla adicionales específicos de LDAP mediante una búsqueda amplia en el registro:
apic1# grep '||aaa||' /var/log/dme/log/nginx.bin.log | grep -i 'LDAP\|ldap' | tail -20
Patrones comunes de no funcionamiento (comparar con los ejemplos de verificación operativa anteriores para el flujo 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
Otros patrones de falla de LDAP a buscar:
error al buscar Ldap Search: código de retorno para ldap_search_ext_s: -5: Tiempo agotadoerror al buscar Ldap Search: código de retorno para ldap_search_ext_s: -1: No se puede establecer contacto con el servidor LDAPLDAP Record DN pero va seguido de un mensaje denegado sin enlace a UserDN... con éxito.LDAP utiliza mapas de grupo en lugar del cisco-av-pair atributo. El attribute campo del proveedor LDAP especifica qué atributo LDAP contiene la información del grupo. Para Active Directory, suele ser memberOf.
El APIC compara el DN de grupo devuelto con las Reglas de Mapa de Grupo LDAP (aaaLdapGroupMapRule) configuradas para asignar el dominio de seguridad y el rol apropiados. Si no coincide ninguna regla de asignación de grupo, el usuario se autentica pero no tiene funciones.
Alternativamente, puede configurar el attribute para CiscoAVPair y almacenar el shell:domains=all/admin/ valor directamente en los atributos LDAP del usuario, que sigue el mismo formato que TACACS+ y RADIUS.
Causa raíz: DN de enlace o contraseña incorrectos, el DN base no contiene el usuario, el filtro de búsqueda no coincide con el esquema de directorio, el error de validación del certificado LDAPS o las reglas de asignación de grupo que faltan.
Solución: Corrija la configuración del proveedor (DN de enlace, DN base, filtro, configuración de SSL). Para problemas de RBAC, verifique que las reglas de mapa de grupo coincidan con los grupos LDAP a los que pertenece el usuario.
En esta sección se tratan situaciones en las que el usuario se autentica correctamente pero no tiene el nivel de acceso esperado.
Problema: Un usuario remoto inicia sesión mediante TACACS+, RADIUS o LDAP. El inicio de sesión se ha realizado correctamente, pero el usuario no ve ningún arrendatario en la interfaz de usuario y las llamadas a la API devuelven resultados vacíos o "403 Forbidden".
Pasos de verificación:
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
El descr campo muestra el resultado del inicio de sesión. Si el usuario se autenticó correctamente pero no tiene roles RBAC, el servidor AAA no devolvió una coincidencia válida cisco-av-pair o de mapa de grupo LDAP.
nginx.bin.log para ver el par AV y la asignación de roles durante el inicio de sesión. Filtrar por nombre de usuario:
apic1# grep '||aaa||' /var/log/dme/log/nginx.bin.log | grep -i 'jsmith' | tail -20
Busque la inserción de roles y los mensajes de asignación de dominio:
Trabajando — Par AV convertido desde el mapa de grupo LDAP, el usuario obtiene el rol de administrador:
||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
No funciona: si no aparece una línea Cisco-avpair o Converted to CiscoAVPair en el flujo, el servidor AAA no devolvió el atributo y no coincidió ninguna regla de mapa de grupo LDAP. Busque Checking all UserDomains Found UserDomain sin líneas a continuación: el usuario se autenticó pero no tiene asignaciones de funciones. Si aparece un Injection ... data FAILED mensaje, el formato de cadena de par AV no es válido.
cisco-av-pair atributo (para TACACS+ o RADIUS) o la pertenencia al grupo LDAP correcta (para LDAP). Verifique la configuración del servidor AAA:
cisco-av-pair con el formato shell:domains=all/admin/.Cisco-AVPair = "shell:domains=all/admin/" en Access-Accept.aaaLdapGroupMapRule).apic1# moquery -c aaaDomain
Si el cisco-av-pair hace referencia a un dominio que no existe (por ejemplo, shell:domains=NonExistentDomain/admin/), la asignación de función falla de forma silenciosa.
Causa raíz: El servidor AAA no devuelve los atributos de asignación RBAC, el formato del atributo es incorrecto o el dominio de seguridad al que se hace referencia en el atributo no existe en el APIC.
Solución: Configure el servidor AAA para que devuelva la asignación de grupo cisco-av-pair o correcta. Verifique que el dominio de seguridad exista en el APIC.
Problema: Un usuario puede iniciar sesión y examinar objetos, pero recibe un error cuando intenta enviar los cambios.
Pasos de verificación:
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
writePriv. Los roles comunes con privilegios de escritura incluyen admin, tenant-admin, access-admin y fabric-admin.apic1# grep '||aaa||' /var/log/dme/log/nginx.bin.log | grep -i 'jsmith' | tail -20
Busque los mensajes de asignación de roles cerca del final del flujo de autenticación:
Trabajando: el usuario tiene el rol de escritura de administrador (desde un inicio de sesión LDAP real):
||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
No funciona: si el registro muestra UserRole no administrador con privilegios de lectura en lugar de privilegios de escritura de administrador, el usuario tiene un rol de sólo lectura y no puede modificar la configuración. Busque líneas como:
||aaa||DBG4||Found non-admin UserRole read-all (read privileges) under UserDomain all
Si el registro muestra solamente privilegios de lectura y ningún privilegio de escritura, actualice el rol del usuario o el par AV en el servidor AAA.
Causa raíz: El usuario tiene una función de sólo lectura (por ejemplo, read-all u ops) en lugar de una función con capacidad de escritura.
Solución: Actualice la asignación de rol del usuario en el APIC (para usuarios locales) o actualice el cisco-av-pair en el servidor AAA (para usuarios remotos) para incluir un rol con privilegios de escritura.
Problema: Un usuario puede ver y administrar un arrendatario pero no puede ver a otros arrendatarios, aunque necesiten acceso.
Pasos de verificación:
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
nginx.bin.log para la asignación de dominio al iniciar sesión. Filtrar por nombre de usuario:
apic1# grep '||aaa||' /var/log/dme/log/nginx.bin.log | grep -i 'jsmith' | tail -20
Trabajando: el usuario tiene el dominio all (visibilidad completa), desde un inicio de sesión LDAP real:
||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
No funciona: si el usuario sólo tiene un dominio de arrendatario, en los mensajes sólo aparecerá ese dominio en lugar de todos los Found UserDomainmensajes. Por ejemplo, Found UserDomain TenantA significa que el usuario sólo puede ver TenantA. El usuario necesita dominios adicionales agregados al par AV en el servidor AAA, o el dominio all para el acceso completo.
Causa raíz: El usuario está asignado a un dominio de seguridad restringido que solo cubre a arrendatarios específicos.
Solución: Agregue los dominios de seguridad necesarios a la configuración del usuario o utilice el dominio all para obtener acceso completo.
Si todas las cuentas de administrador están bloqueadas o el servidor AAA remoto es inalcanzable y el rango predeterminado ha sido cambiado, utilice uno de estos métodos de recuperación:
ACI proporciona un dominio de inicio de sesión de reserva integrado que siempre utiliza la autenticación local, independientemente del rango de autenticación predeterminado. Para utilizarlo:
apic:fallback\\admin (o apic#fallback\\admin dependiendo de la versión).Si el rango de autenticación de la consola se establece en local (valor predeterminado), siempre puede iniciar sesión a través del puerto de la consola APIC con credenciales locales. Si se desconoce la contraseña del administrador local, se puede restablecer mediante Cisco Integrated Management Controller (CIMC) (para APIC físicos) o la consola de hipervisor (para APIC virtuales).
Los siguientes fallos de ACI suelen estar asociados a problemas de AAA y acceso remoto:
Consulta de fallos AAA activos:
apic1# moquery -c faultInst -x 'query-target-filter=or(wcard(faultInst.dn,"tacacsplusprovider"),wcard(faultInst.dn,"radiusprovider"),wcard(faultInst.dn,"ldapprovider"))'
| Revisión | Fecha de publicación | Comentarios |
|---|---|---|
1.0 |
09-Apr-2026
|
Versión inicial |