Dive Into Discovery Credentials...

[SlightlyLoony]

What exactly are the Discovery Credentials, and how do they work? Are they safe? These are questions we hear a lot! They're good questions, too, because credentials are important security tools...

First, what are Discovery Credentials? Today, Discovery uses two basic kinds of credentials: SSH and SNMP (we'll likely add more in the future). Windows security works in a completely different fashion, which I'll cover in another post. Windows access does not require any Discovery Credentials.

For SSH, there are two kinds of credentials — the familiar user name and password, or public/private key files; you can use either one. For SNMP, the credential is the password (aka the "community string"). Navigate to Discovery -> Credentials, and you'll see a list of all the credentials that your Discovery currently knows about. You won't be able to read the passwords, though — these are hidden on the screen and encrypted in the database, to keep them safe from prying eyes.

What credentials does Discovery need? For SSH, Discovery needs credentials for each Unix or Linux system that you want it to find and explore. In most organizations, there is some way to provision users and passwords (or public/private keys) on every such system. This might be LDAP, or Marimba, or any of dozens of other products or open source packages. So typically our customers will create a "discovery" user (or some other user dedicated to this purpose) and push that out to all of the Unix or Linux systems. A variation on that approach is to create such a user, but with different credentials, for groups of systems. These groups might be geographical, or they might be functional. The rights needed by a Unix or Linux user created for discovery purposes will be the subject of another post, but for now I'll just say that the rights needed are normal user rights, with a couple of exceptions we handle with sudo. SNMP credentials are typically much more difficult to provision, so organizations tend to have either a single organization-wide pair of SNMP credentials — one for read-only access, one for read-write access. Discovery only needs read-only access to SNMP. Occasionally we run into organizations with multiple SNMP credentials, perhaps for different geographies, or for different kinds of equipment (one for network gear, another for printers, etc.). Many SNMP devices default their read-only community string to "public" — this is so common that we automatically include the public credential — there's no need for you to enter that one.

I'm going to make up an example to use in explaining how Discovery handles these situations. My example company is Mooseburgers, Inc., with locations in Mattawumkeag, Maine, and Hope, Idaho. Each location has a group of Linux servers hosting the company's key applications (especially the all-important moose meat inventory and moose grinder systems). The Mattawumkeag servers have a discovery user with password x, the Hope servers have a findit user with password y. In both locations the network gear has a community string of m, and the network printers a community string of n.

So what credentials does Mooseburgers, Inc. need to enter into their Discovery Credentials list? They'll need two SSH credentials (one for Mattawumkeag servers, one for Hope servers) and two SNMP credentials (one for network gear, and one for network printers). How does Discovery know which credentials to use for which system? It doesn't, actually. How this part works is kind of interesting, in a geekly way...

When you enter credentials into Discovery, those credentials don't simply get stored in the database — they also get transmitted to all the MID servers your organization is running (over an encrypted connection, of course). Behind the scenes, your Service-now instance also keeps track of all the successful uses of each credential. When a MID server starts to execute a probe to a particular system, it first gets a list containing all of the right kind of credentials (SSH, SNMP, etc.). Then it checks to see whether the system being queried has ever successfully used any credential. If the answer is "yes", then that credential is moved to the beginning of the list. Finally, the MID server starts trying to query the system, starting with the credential at the beginning of the list; if a credential fails, it abandons that one and tries the next one on the list. This mechanism is very efficient — once the MID server has successfully logged into a system, it will try the correct credential first from then on. If you change the credentials on a system, it will still work, though the MID server may try one or more incorrect credentials first. Once it finds the correct credential, that new credential is remembered so that future logins are right on the first try.

Phew - that was a long post! But hopefully now you'll understand a little better what those Discovery Credentials are, and how they work...