Home› Asset Management

Password Manager for System Accounts

Amarjit_DhillonAmarjit_Dhillon Customer Adept IT Monkey ✭✭
edited November 2016 in Asset Management
Is there something that can be created in Asset Manager that can store an organisation's system accounts password? You could then link the system accounts/passwords to the servers in your asset database.

As it stands, organisations have to download third party tools to do this and in some extreme cases, use an excel spreadsheet to hold passwords.

Best Answer

Answers

  • Amarjit_DhillonAmarjit_Dhillon Customer Adept IT Monkey ✭✭
    edited November 2016
    The passwords could also be linked to the service teams so only the right people can get to their service account passwords.
  • Amarjit_DhillonAmarjit_Dhillon Customer Adept IT Monkey ✭✭
    Is there any thoughts about this?
  • Adam_DzyackyAdam_Dzyacky Product Owner Contributor Monkey ✭✭✭✭✭
    edited January 2017
    It's been my understanding that storing sensitive data (i.e. passwords, encryption keys, etc.) in SCSM via Cireson's Asset Management solution (or any 3rd party/self-devved) is not advised as you're somewhat shoving the data into a tool that would better be suited for something else like KeyVault.

    That said, I've always seen both sides of this (and truthfully I'm with you that I'd like to see it in SCSM for the sake of simplicity):
    • On one hand - I prefer to use tools as they are designed and meant for rather than making them work for an unintended purpose.
    • On the other hand - I genuinely want less tools in the environment as I want less to manage, less to control, and a single place to retrieve data. I have a CMDB so why wouldn't I use it for this?!

    My personal guess as to why no one has done this yet based off of my (albeit, somewhat limited) understanding of the SCOM/SCSM sdk is that were it to be created: there is probably no good way to protect the code that is responsible for creating the encryption which means from a security standpoint all it would take is someone decompiling an MP to determine the encryption mechanism. Which means, the last "line of defense" is getting whatever the private key is to perform the decryption which you could probably at least could be guided into retrieving from the encryption mechanism/code. In which case it feels like all of this would have to be part of the core code base/framework perhaps?

    Again, just my personal guess. @Conner_Wood seems to be rather intune with SDK stuff so I'd be interested to hear his thoughts on this topic and/or how reasonable my guess is.
Sign In or Register to comment.