Management of local credentials for Server Discovery

[Matthew_Connoll]

Hi,

We're running discovery across a large organisation and for the most part we can use domain level service accounts to cover the majority of our infrastructure.

Our problem is that around 800 devices that are not integrated with AD and as such require local credentials to be deployed.

Our security team would ideally like to have each local account configured with a different password to reduce the risk of these accounts being compromised.

I feel that if we created separate credentials for each host of this type it would not just be unmanageable, it would also negatively impact the performance of discovery.

ie imagine discovery running on a /16 network and having to cycle through 800 credentials for each host.

As it stands, we're pushing out the same password for different segments so that we only need a handful of local credential passwords rather than hundreds.

Are there any other companies out there that have encountered similar issues or have similar experiences?

Regards,
Matthew

[tim_broberg]

Well, here's every crazy idea that comes into my head about this. Maybe one will work for you:

1. Use an external credential provider like CyberArk. There is an API to hook ServiceNow up, and a version exists for CyberArk out of the box. You can configure the credential provider to have a separate credential per IP address. Really, this is the "proper" answer.
2. You can prioritize the wacky credentials down below the normal ones that actually get used, then create affinities (dscy_credentials_affinity table) associating the relevant credential ID with the correct IP and mid server. As long as authentication is successful, it will always try that credential first. I don't like the tendency for it to suddenly stop working by surprise when auth fails once, but you could build a business rule to forbid affinity updates for certain IPs or for credentials with certain names, or whatever.
3. You could tag each of the odd credentials with a unique tag, and then have a business rule fill in the credential_tag with the appropriate name. This would strictly filter the list of credentials to the ones you want. It would be robust against auth failures and would never try any credentials that are not tagged with your tag.
4. You could write your own external credential provider, and keep a table of weird IP addresses and the relevant credentials, store them any way you like, and override the standard credential provider for those IPs. This is a significant amount of work, and has significant opportunities to create security vulnerabilities, but gives you ultimate flexibility to solve the problems any way you like, and keep the credentials in a store that you control, completely isolated from the cloud.

I do hope it gives you some useful ideas, Matthew.
    - Tim.

[Matthew_Connoll]

Hey Tim,

Thanks for the info.

Yup, we actually do have CyberArk set up and configured but as i see it, it doesn't resolve the issue of having a crazy amount of credentials in ServiceNow.

It seems that there's no way to group hosts to have the same username/password in CyberArk, which to be fair, is understandable.

In theory we could set up each host in CyberArk and have the passwords maintained automatically, but then this translates to 1 credential per host of this type and you would end up with an unmanageable number in ServiceNow.

I like the other ideas but I would have to argue the case for any sort of customisation so trying to have a number of options available.

Cheers,

Matthew

[tim_broberg]

I sure wish i could remember how I saw that done, but I don't, Matthew.

I thought they had a single credential that pointed to CyberArk which then did the lookup by IP, but you would almost certainly know better than I. It's been a few years, and I was just a guest in somebody else's instance there.

[Bruno21 · Accepted solution]

Hi,

" Yup, we actually do have CyberArk set up and configured, but as i see it, it doesn't resolve the issue of having a crazy amount of credentials in ServiceNow."

Yes it does !

Because you have to only configure one credential (type external storage) for your CyberArk vault, follow the ServiceNow documentation, and it's your CyberArk team which will have to manage the passwords for your 800 devices !!! Of course CyberArk provide features to generate temp passwords etc .. to not have to create 800 "by hands".

So, if your company is already using CyberArk go there, https://docs.servicenow.com/bundle/newyork-servicenow-platform/page/product/discovery/concept/c_Cybe..., and use it in your instance !