Representing Shared IDs in the CMDB?

[K Cole]

Hello, we are reimplementing SN and a question keeps coming up about how to represent Shared IDs in CMDB. We don't see an OOB class. How have others approached this?

[Kieran Anson]

Hi, what's your definition of a shared ID? Some sort of user account? A service account?

[K Cole]

When we say "shared IDs" we are talking about accounts that apply permissions to access various services. These are IDs that are housed and managed within IIQ and allow cross-system talk. This is not precise because there are multiple usages. Some are interactive and some are not. 

I understand that ideally these things would be managed under a GRC umbrella, but we do not have that in a centralized manner currently (or in the near future). Hence we represent them in a custom class in our CMDB to try to establish the relationships for which services/CIs are leveraging them. 

One use-case is we have an outage for a service, we find that when a password expires for a given shared ID, it takes down multiple services and sometimes users of these IDs are unaware of the dependencies. 

I'm sorry if this isn't helpful.

[Kieran Anson]

Gotcha,

There isn't an OOB class. But you're free to extend the CMDB and create your own class. Likely from cmdb_ci itself.

You'll need to consider the attributes you want to store, and any relationships to other CIs. For example, the "shared ID" CI could be related to an application service record to show what app-stack is using the credential 

[jMarshal]

When it comes to Data Management & Governance...it doesn't HAVE TO be in the CMDB. For instance cmn_location and sys_user are integral base data tables, both of which are a big part of the CSDM, neither of which are "cmdb_ci" tables.

...what is your use case for putting this into the CMDB?...are they components of an Application Service that you already have defined through Service Mapping activities, perhaps?

If you are looking to track them in platform for the purpose of ownership/authority, when the password was last changed, etc...I would recommend using a different table/module than CMDB.

SN has built in credential stores...maybe you just want to use that instead?

I avoid custom/extended CMDB classes at all costs, personally...the use case has got to be REALLY good, to get into the CMDB as the CMDB has a lot more overhead than other modules/tables (as it should)...and you don't want to go creating overhead where none is needed, IMO.