cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
6069
Views
10
Helpful
4
Replies

DCNM and Device Authentication

randallh1974
Level 1
Level 1

My organization has recently started using DCNM, specifically the LAN portion. We have gotten the server installed and setup and are ready to discover our first device. The problem is we can't get it to authenticate to the device for SNMP/CLI with our SSH configuration. We use Cisco's Access Control System (ACS) for SSH authentication. We created a SNMP user called "test" on a Nexus 7k using SHA_AES with the role vdc-operator.

User               Auth    Priv (enforce)     Groups

test                  sha     aes-128(yes)     vdc-operator

When we use these credentials for LAN discovery using protocol options "SNMPv3/CLI" with algorithm "SHA_AES" it works just fine. We then create the same username/credentials in ACS to be used by DCNM-LAN as the default credentials under "DCNM Server Administration" --> "Devices and Credentials". When we do this, it connects and is immediately disconnected. The "test" SNMP user is changed on the Nexus 7k from SHA_AES to MD5_DES and the role is changed from vdc-operator to vdc-admin.

User               Auth    Priv (enforce)     Groups

test                 md5     des(yes)            vdc-admin

We then cannot connect anymore using the algorithm SHA_AES when doing LAN discovery. If we change SHA_AES to MD5_DES for LAN discovery everything works perfectly. The problem is, we can't use MD5_DES for an SNMP user on the Nexus devices. Our policies require us to use SHA_AES. Does anybody know what is causing the SNMP user on the Nexus 7k to be changed to MD5_DES and vdc-admin???

1 Accepted Solution

Accepted Solutions

The authentication method is likely being changed due to the CLI and SNMP user synchronization function of NX-OS.  When you login to an NX-OS device via telnet or ssh, it autocreates/syncs the snmpv3 authentication settings and password with the aaa server settings.  In some cases, the aaa server is handing back default authPriv settings or different authPriv settings which override the configuration on the switch due to the CLI and snmp synchronization feature.

As an additional test, create snmpv3 user with SHA AES as before.  SSH into the switch with the "test" user account.  Does the auth method change back to MD5 DES?

Follow-up Question:

What shell profile is ACS returning for the "test" user?

For TACACS, it should look something like,

cisco-av-pair*shell:roles=" network-admin"snmpv3: auth=SHA priv=AES

 

Reference Docs:

CLI and SNMP synchronization:

http://www.cisco.com/c/en/us/td/docs/switches/datacenter/sw/5_x/nx-os/system_management/configuration/guide/sm_nx_os_cg/sm_9snmp.html#wp1059936

Configuring user roles and snmpv3 parameters on a AAA server:

http://www.cisco.com/c/en/us/td/docs/switches/datacenter/sw/6_x/nx-os/security/configuration/guide/b_Cisco_Nexus_7000_NX-OS_Security_Configuration_Guide__Release_6-x/b_Cisco_Nexus_7000_NX-OS_Security_Configuration_Guide__Release_6-x_chapter_0100.html#con_1235794

 

View solution in original post

4 Replies 4

Eric Scott
Cisco Employee
Cisco Employee

DCNM requires the user account to be vdc-admin or network-admin for the discovery process to complete.  This is because DCNM will change the logging level of several features to meet its minimum requirements.  I tried this on my DCNM server by creating an snmpv3 user with SHA_AES and the vdc-operator role.  I initiated shallow discovery via the Web UI [Admin > Data Sources] and discovery completed.  The snmp user's authPriv settings stayed the same.  Next, I tried deep discovery via the LAN client and it failed.  I got the error message "UNMANAGED (insufficient user privileges for executing show commands or configuring required log levels)."  However, when the user role is changed to vdc-admin, discovery completes.

Another consideration is that vdc-operator privileges does not permit adding or changing snmp settings or to configure user accounts with the vdc-admin role.  So if DCNM is logging into the switch with the user test, then it wouldn't have the privilege to make these type of changes.

What version of DCNM is this?

Is the user "test" a local user account or does it only exist in ACS?

Has the 7k been discovered already with another set of credentials?

I'd try setting the role to vdc-admin before discovering the 7k and start discovery from the Web UI first, called shallow discovery.  After the 7k is shallow discovered, discover the 7k with the LAN client, called deep discovery, on [DCNM Server Administration > Device discovery] .

Eric -

Version is 6.3(1).

I used the name "test" in this post as I can't give the actual username we used. The "test" user was set up as an SNMP user on the 7k and the same credentials were created in ACS for the SSH authentication that would be needed to do the deep discovery. We've also tried just creating the user on the 7k locally and just creating the user in ACS. No matter how we attempt the discovery the user always shows up when running "show snmp user" with MD5 DES.

Even if we create the SNMP user with a role of vdc-admin when we try to do shallow discover the authentication method is changed from SHA AES to MD5 DES for some unknown reason. If I then try to do shallow discovery with MD5 DES everything works perfectly. It acts like DCNM doesn't work with SHA AES even though it is an option. Also, when the "test" user has its authentication method changed to MD5 DES we can't remove it. We can clear all of the lines from the configuration so that the user does not show up in the running config anymore but the user still shows up when running the command "show snmp user". We can't remove it at all but it eventually just disappears after about an hour. I just can't figure out why the "test" user's authentication method gets changed when we try the shallow discovery from the web client and why we can't get it to work with SHA AES.

The authentication method is likely being changed due to the CLI and SNMP user synchronization function of NX-OS.  When you login to an NX-OS device via telnet or ssh, it autocreates/syncs the snmpv3 authentication settings and password with the aaa server settings.  In some cases, the aaa server is handing back default authPriv settings or different authPriv settings which override the configuration on the switch due to the CLI and snmp synchronization feature.

As an additional test, create snmpv3 user with SHA AES as before.  SSH into the switch with the "test" user account.  Does the auth method change back to MD5 DES?

Follow-up Question:

What shell profile is ACS returning for the "test" user?

For TACACS, it should look something like,

cisco-av-pair*shell:roles=" network-admin"snmpv3: auth=SHA priv=AES

 

Reference Docs:

CLI and SNMP synchronization:

http://www.cisco.com/c/en/us/td/docs/switches/datacenter/sw/5_x/nx-os/system_management/configuration/guide/sm_nx_os_cg/sm_9snmp.html#wp1059936

Configuring user roles and snmpv3 parameters on a AAA server:

http://www.cisco.com/c/en/us/td/docs/switches/datacenter/sw/6_x/nx-os/security/configuration/guide/b_Cisco_Nexus_7000_NX-OS_Security_Configuration_Guide__Release_6-x/b_Cisco_Nexus_7000_NX-OS_Security_Configuration_Guide__Release_6-x_chapter_0100.html#con_1235794

 

Eric-

This is EXACTLY the information I needed. I was just having a hell of a time trying to find the right documentation and I never dreamed the thing I needed to change was ACS. I won't be able to test this for a couple of days but based on what you've posted and reading the docs you pointed me to I'm confident this will prove to be the answer to my issues. I'm still fairly new to the NX-OS so I really appreciate the help cause it is such a different monster from what I'm used to with IOS.

Thanks!!