Why NETCONF Fails While SSH Works on a WLC

Describe NETCONF/YANG Implement the AP, WLC, and dashboard management access connections

Refer to the exhibit. exhibit An engineer is configuring Cisco Catalyst Center to monitor wireless clients using telemetry. When discovering the WLC, Cisco Catalyst Center, using TACACS+ credentials, can log in using SSH but NETCONF fails. Which configuration change must the engineer apply to allow the connection?

Configure the yang-interfaces commands to utilize the TACACS+ method lists.
Change the configuration on the vty lines to use the default method lists for NETCONF.
Change the default method lists because they are the only ones NETCONF can use. Correct Answer
Configure RADIUS method lists because TACACS+ is not supported with NETCONF.

Answer Correct answer: C — Add TACACS+ to the global default AAA method lists, because NETCONF over SSH can only use the default lists, not vty-bound named lists.

Community Insight

The question tests which AAA method list NETCONF actually consults; the trap is assuming the named TACACS+ list already working for SSH also covers NETCONF sessions.

On Cisco IOS XE WLCs, NETCONF/YANG management sessions are authenticated through the global default AAA method lists, not through named lists applied to the vty lines, which is why TACACS+ login succeeds over SSH yet NETCONF is rejected. The required fix is to add TACACS+ to the default AAA login/authorization lists, making option C the correct choice.

Most learners pick A, configuring 'yang-interfaces' to use the TACACS+ method lists, because Catalyst Center's telemetry onboarding seems like a YANG-specific setting — but IOS XE provides no per-YANG-interface AAA method-list binding, so the only supported change is editing the default lists (C).

Community Discussion (1 comments)

JS2025 👍 1 Selected: A

By default, programmable interfaces like NETCONF and RESTCONF on Cisco IOS XE rely on the global default AAA method lists (default) for login authentication and EXEC authorization. Since regular SSH logins often utilize custom or named AAA method lists applied specifically to the VTY lines (allowing TACACS+ to work for standard CLI access), NETCONF will fail if the global default list does not point to the same TACACS+ servers. To resolve this without altering the global device default AAA lists, Cisco introduced the "yang-interfaces aaa" configuration commands (available starting in Cisco IOS XE 17.9). This allows an engineer to explicitly bind custom, named TACACS+ authentication and authorization method lists directly to programmable interfaces (YANG interfaces). Option C is outdated; while it was historically true that NETCONF only used default lists, the yang-interfaces feature now allows named method lists.

Comments & Corrections

No comments yet — spotted an error or have a note? Share it below.

Expert Analysis

Why the Answer Is Correct

On IOS XE, a NETCONF-over-SSH session is authenticated and authorized by the global default AAA method lists (aaa authentication login default... / aaa authorization exec default group tacacs+ local), not by a named list bound to the vty lines. A named TACACS+ list applied to the vty lines governs only interactive CLI SSH, which is exactly why Catalyst Center can log in via SSH while NETCONF discovery fails. Because NETCONF has no configurable AAA method-list reference of its own, the only supported remediation is to place TACACS+ in the default lists — precisely what option C prescribes. Once the default list points at TACACS+ (with local as fallback), Catalyst Center can enable the NETCONF agent and consume wireless client telemetry.

Why the Other Options Are Wrong

Option A fails because IOS XE exposes no "yang-interfaces" AAA configuration that binds NETCONF or YANG interfaces to an arbitrary named method list; AAA for NETCONF is fixed to the default lists. Option B is the reverse of the needed change — the vty lines already authenticate successfully with the named TACACS+ list, and NETCONF never consults the vty configuration in the first place. Option D wrongly implies a protocol limitation: NETCONF is not RADIUS-only or TACACS+-incompatible, and swapping the whole authentication server type is unnecessary when simply correcting the default method lists solves the failure.

Community Comment Notes

JS2025's comment correctly explains that "programmable interfaces like NETCONF and RESTCONF on Cisco IOS XE rely on the global default AAA method lists" and that a custom list applied to the VTY lines lets standard CLI access work — reasoning that actually supports editing the default list (C), even though the poster selected A. The comment is truncated mid-sentence, but its core point stands: the global default list must be pointed at the TACACS+ server (with local fallback) for NETCONF to authenticate.

Official Reference

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_usr_aaa/configuration/15-mt/sec-usr-aaa-15-mt-book.html

Exam Strategy

Apply the IOS XE rule that NETCONF/RESTCONF authenticate through the global default AAA method lists, never a named list bound to the vty lines. When SSH works but NETCONF fails, choose the option that fixes the default list rather than one that rebinds vty or invents a YANG-specific AAA setting.

Frequently Asked Questions

Why does SSH authenticate with TACACS+ but NETCONF fails on the same WLC?

Interactive SSH uses the named AAA method list applied to the vty lines, while NETCONF over SSH authenticates via the global default method lists. If TACACS+ is only in the named list, NETCONF has no TACACS+ server to reach and is rejected.

What must be configured for Catalyst Center to use NETCONF telemetry?

Enable TACACS+ in the default AAA login and EXEC authorization lists, then enable the NETCONF agent (netconf / netconf agent ssh) with the required YANG models so Catalyst Center can subscribe to wireless client telemetry.

More 350-101 FAQ →

Related Analysis

← Back to 350-101 Study Guide