Unauthorized user on snmpv3

[CheckYourFax]

Hi,

I'm having issues getting SNMPv3 to work from DCE v8.2.0 to NMC2 v7.1.6 (SmartUPS 500) when using SHA1 and AES128

I've verified all auth and ip settings are correct and the SNMPv3 packets are arriving at the NMC2.

SNMPv3 works when using no auth no priv and a device scan using the DCE client works fine then.

I succesfilly tested the SNMPv3 SHA1 and AES128 account itself using snmpwalk and the NMC2 SNMPv3 configuration is correct but once I add it to DCE the NMC2 log file receives "unauthorized user request from <DCE server IP>" so something is wrong with the SNMPv3 request from DCE.

[Teken]

You may want to try SNMP v2 to see if the behaviour is different.

You can also try using MD5 / DES when using SNMP v3 to see how the service reacts and behaves.

Let me know the results of both. 👍

[CheckYourFax]

We tested this to no avail.

SNMPv2. is not available on our software versions.

What I think is that DCE is sending a wrong request that is being denied by the NMCv2. Could be something like some whitespace being sent instead of the correct hashed username/password

[Teken]

Have you checked to ensure this isn’t a special character password issue too?!?

[CheckYourFax]

We tried with username test and password test. Same issue: when trying to discover I get "Unauthorized user tried to connect from <DCE server IP>" on the NMP2 network card.

When trying to do snmpwalk after changing NMS ip to a test linux console IP address the snmpwalk is successful and we get a list of information from the UPS.

[Teken]

Has the Access Control in the NMC SNMP v3 being correctly defined: IP / FQDN?!?

[CheckYourFax]

Yes, it has been.

These are current conclusions:

1) The username & password is correct. snmpwalk using same details works correctly.

2) The access control IP is exactly the same IP as the NMC2 identified where the SNMPv3 packets comes from. The IP header contains the same source IP address as is set in Access Control.

We also tried setting it to 0.0.0.0 to no avail.

Our suspected cause is that DCE is sending a faulty packet containing the wrong hashed information or something is wrong with AES encryption. Why?

> No password and no privacy works.

> password SHA1 and no privacy DOESN'T work

> password and privacy SHA1/AES128 DOESN'T work.

We suspect the SHA1 hashed password sent is faulty and thus denied by NMCv2.

This is just an educated guess as NMCv2 gives no information as to why access is denied.

[Teken]

Please do submit a service request with APC Technical Support. Very interested to learn what the root cause is.

Appreciate all the testing and feedback! 👍