Credential Affinity Problem

Bob D · ‎05-13-2019

[Kingston]

I have some IP firewalls that I Discover using SNMP. The devices appear to be Discovered properly, meaning the CIs are created/updated and when I review the ecc queue logs, I can see the progression through SNMP classification and SNMP identification working. I can see the OIDs returned in the XML payloads. It seems to be working. However - Discovery is attempting a Unix classification first since SSH classifier is prioritized over SNMP classifier. I have a lot of ssh credentials, so it tries all of them and fails ... every time ... before it gets to the SNMP credential. A credential affinity should prevent this from happening, but there is no affinity created for these firewall IPs. Any reason why this would be?

doug_schulze · ‎05-13-2019

Bob,

A couple of things here...

Your credential affinity does not affect the classification priority nor the IP affinity. While the Credential affinity will prioritize the credential order, when it gets to classifying the device its a different process. You'll want to do some modification to support and remedy your challenge.

First, enable the IP Service Affinity. This will use the last known protocol that was successful from the first discovery then use the same on the second, third, tenth discovery until it fails. Ultimately this will do what you had hoped it would do with the credential affinity from your question.

Secondly, before we had that and came across your problem, I would (and still do) change the classification priority on your port probes. Have SNMP go before SSH. What you will get from that is when we come across a router that does ssh and SNMP, we will try SNMP first and if successful never try SSH. This will help those brand new devices that we haven't come across before and that don't have your newly enabled IP Service Affinity.

Hope this helps.

View solution in original post

doug_schulze · ‎05-14-2019

Bob,

Think of it this way. In this concept, you have enabled IP Service Affinity and have NOT changed the classification priority and you have 3 SNMP read-only strings in your credential table.

On a net new discovery of a router that has ssh and SNMP ports open.

on the shazzam scan, we see port 22 open and 161 responsive.

We attempt an SSH (classify) connection and it fails

We then query with SNMP (classify) trying each credential 1,2,3 till we find cred3 is successful

On the 2nd, 3rd, 4th, 10th... discovery

on the shazzam scan, we see port 22 open and 161 responsive.

We then go right for the SNMP classify because we built the ip service affinity

We use cred3 because we built the credential affinity

Now in the NEW discovery if you had modified the classification priority then we would have never have attempted the SSH classify because SNMP would have gone first and with correct credentials and ACL configurations it would have discovered and built the affinities.

When it comes to any servers that might respond with SNMP, if you look at the SNMP classifiers you won't see any computers in that list, so nothing will match and it will move onto ssh, discover, build the IP service affinity, credential affinity and you know the rest.

Bob D · ‎05-14-2019

All makes sense, Doug. thanks again

Credential affinity has less scope than what I thought. But I understand how it is applied now.

Also - you're correct that since there are no snmp classifiers for my linux servers, Discovery would progress to ssh if I switched ssh probe to lower priority than snmp. I'll do some testing there.

and finally - I enabled IP Service Affinity and did a quick test - it worked as advertised.

ServiceNow Community comes through again!

Andrew Westerv4 · ‎05-13-2019

Adding to Doug's comments, you may also want to look at suppressing certain SSH banner types to not even attempt UNIX classification. Stephen has a very good example in the below article for disallowing SSH Discovery on HP iLO devices since they require SNMP access only.

https://community.servicenow.com/community?id=community_question&sys_id=550f7629db58dbc01dcaf3231f96...

Bob D · ‎05-14-2019

thank you Andrew