External Credential Store - Is it possible this approach for LDAP, POP3, etc.?

antonioferrari · ‎09-25-2017

Hi everybody,

we've implemented integration with Thycotic Secret Server according to this article: How to implement Thycotic Secret Server as an External Credential Store

How to implement Thycotic Secret Server as an External Credential Store

We have an Istanbul release with Discovery and External Credential Store active.

Now our Customer requires that all critical credentials (LDAP, POP3, SMTP, REST API, etc.) haven't to be stored in the cloud, but must must be retrieved in a manner similar to External Credential Store in Discovery. So they'd like to introduce an "External Credentials" flag in POP3 and SMTP records under System Mailboxes --> Email accounts; when this flag is set, a Credential ID value (an integer value) must be specified in place of username/password as for Discovery --> Credentials. In this manner, when a call to SMTP or POP3 server is done, ServiceNow would have to retrieve username and password at run time making a Call to Thycotic Secret Server passing the Credential ID (corresponding to the Secret ID).

I don't know if that integration is possible. I imagine to scenarios:

1) The username and password don't transitate between MidServer and ServiceNow but are kept inside the MidServer. Maybe this is possible if possible if we configure LDAP trough MidServer, but I'm not sure.

2) Everytime ServiceNow makes a call to LDAP that requires authentication, we could pass the Credential ID into ECC Queue (as JavascriptProbe) obtaining the credentials in input (possibly crypted) but in this manner they would pass into the cloud even temporarely.

Now I have some questions:

A) Have anyone ever implemented such and integration for LDAP, POP3, SMTP, etc.?

B) According to point 2: is it possible to find ALL the points inside ServiceNow where a call for LDAP authentication happenes? Is it possible also for POP3, SMTP, etc. to do the same? In this manner maybe I could do a dynamic call vs SecretServer passing from MidServer.

C) When Discovery --> Credentials uses External Credential Store, calls to CredentialResolver.jar (deployed in MidServer) is done. In particular a call to com.snc.discovery.resolve(...) is done. Where could I find the calls to resolve method inside my istance?

D) I'm trying to understand how External Credentials work in Discovery. I've done a "Test Credentials" using a Credential marked as external. In ECC Queue I've found only this payload in output:

<automation_pipeline>

<automation_pipeline_commandcredential_data="SNC_ENC_VAL:<base64_string>"port="22" source="10.3.3.164" type="TestCredentialCommand">

<automation_pipeline_filters/>

<automation_pipeline_parsers/>

<automation_pipeline_transformers/>

</automation_pipeline_command>

</automation_pipeline>

</parameters>

(I've substitued base64 code with <base64_string> for security reasons).

and this payload in input:

<output>success</output>

</result>

</parameters>

</results>

So according to point D), where is Credential ID passwed?

I would appreciate any help.

Best regards,

Antonio Ferrari

Dave Ainsworth · ‎09-25-2017

Hi Antonio,

As in the docs, the external credential storage is for Discovery, Service Mapping and Orchestration:

https://docs.servicenow.com/bundle/jakarta-it-operations-management/page/product/discovery/concept/c...

I don't think there would be any way to modify this for any other credentials.

For questions C) and D).

C) The code is in the MID server. See the following for the architecture:

https://docs.servicenow.com/bundle/jakarta-it-operations-management/page/product/discovery/reference...

The MID will automatically call the Credential Resolver when it requires a credential marked as external.

D) When a MID server starts or a new credential is added, the MID server requests the credentials from the instance. It then retrieves the credentials which includes the sys_id. However the instance will not tell the MID server which credential to use but it can suggest a credential if it has an 'affinity'. So if discovery is discovering a Unix server for the first time, it will find all the SSH credentials it has downloaded and try them in order. If the instance has an affinity to the IP address (i.e. a credential has successfully been used on this IP using this MID server), you will see the following in the payload:

The 'value' will be the sys_id of the credential and so the MID server will then try this credential first. If this fails, it will fallback to trying the other credentials it has.

Regards,

Dave

antonioferrari · ‎09-25-2017

Hi David,

so if I've understood well there is no way to adapt the functionality provided by External Credential Storage to other integrations since it has been thought for Discovery.

Anyway it's possible to deploy custom Jar in MidServer and call it from JavaScript code. I've modified resolve(...) method in Credential Resolver in order to retrieve username and password from Secret Server putting them for example into a JSON string "{"username":"usr1","password":"pwd1"}"

var js = new JavascriptProbe('MidServer_Svil');

js.setName('Get Credentials from Secret Server');

js.setJavascript("var cl = new Packages.com.snc.discovery.CredentialResolver(); cl.resolve('1');");

js.addParameter('skip_sensor', true);

js.create();

And I could use the code by James Andersen to fetch data in ECC Queue to retrieve the response: http://www.john-james-andersen.com/blog/service-now/getting-a-servicenow-ecc-queue-response.html

Possibly I could implement encryption for better security even if https already protects on its own the communication between MidServer and SN.

At the moment I have only two ideas to apply this mechamism:

1) find all the points where ( let's for example for LDAP ) SeriviceNow reads username and password and substitute standard calls with some custom scripts that implement the passages described above for ECC Queue. Could it be possible to find alla these calls inside SN?

2) use a Business Rule before-queue on "sys_email_account" that stores temporarely username/password taken from Secret Server and then a Business Rule after-queue on "sys_email_account" that erases the values. My idea is: populate before they can be read; erase after the values have been read. Apart from possible drawbacks how could this solution being implemented? Any ideas?

Best regards,

Antonio Ferrari

Dave Ainsworth · ‎09-25-2017

Hi Antonio.

Even if you could retrieve this way and implement encryption, would this be any more preferable to directly storing in the instance? When the response is received in the ECC Queue, the ECC queue record will be stored in the instance and therefore you are effectively storing the credentials in the instance?

Regards,

Dave

antonioferrari · ‎09-26-2017

Hi,

I know that it's the same thing, but the Customer has asked us to analyze all possible solutions ... Anyway maybe Security Department will pass the solution OOTB (credentials stored in the Cloud) but we have to provide detailed informations to the Customer about what kind of Encryption SN uses to store the password.

I've read that LDAP password (for example) is put into a 2-way encrypted field. Does it mean that I could write a decrypt function inside the instance and decrypt those field? What kind of encryption algorithm is used?

Best regards,

Antonio