Password Store in SCSM
As more and more applications move to the cloud, the desire to use Azure AD(sorry Entra ID) Authentication gets bigger and bigger.
The problem is, that our Service Accounts are not synced to Azure, and therefor directly authenticating is not possible. Because of that we have to sign in via Username Password most of the time, which is suboptimal, as writing the user/password combo inside the script is a NoGo. Right now we use the SCO variable store to save passwords to it and read these passwords via SQL, which is suboptimal as well.
I know we can create user accounts in the runas User section, but when a user is Azure only, which is the case if it is a Azure Serviceaccounrt, this doesn't work. So my question is (to the Cireson Developers): would it be possible to create some sort of Password store in SCSM as a custom app? Where the passwords are stored encrypted like in the SCO database and only accounts with database access can decrypt and use it? So it would be possible to save the passwords in this store. It would also be needed to add such a password to a PSA or Cloud Activity.
is something like that on the roadmap already?
Answers
It's not on the roadmap, it is something that was brought up awhile ago, and something I no less commented on back then :)
I suppose the question I have here is if this is an Azure only account, what is the use case of it executing PSA/Cloud Activity within SCSM?
@Adam_Dzyacky ups, should've used the search function first, sorry.
As we do not want one serviceaccount (which has to be an Azure account as well) to have write access to all azure groups, they are managed in Administrative groups. This Azure only account is then needed to authenticate to the tenant. We then authenticate to Azure (or Graph API) with this Azure Only account to do certain tasks, e.g. managing group memberships of groups inside this AU. Do you need more info?
@Simon_Zeinhofer
I'm not 100% understanding the requirement but would an Azure Key vault work?
I like your idea of using SCSM but i don't think it was ever designed to store encrypted data so maybe isn't the best fit.
@Geoff_Ross as our workflow service account is not synced into Azure, I guess it wouldn't be possible to authenticate to the azure vault. But maybe your hint is using a run as account for the script, which is synced to azure as well and has the permission to access the Azure vault? If that's it I guess for us that won't work as our Powershell Activities don't run as soon as we use a run as account :(
Yeh I just thought, as Orchestrator has this functionality as well, by using SQL Encryption, maybe it would be an option to use it in SCSM as well.
Right now we go back to SCO when we need to connect to Azure and use the encrypted variables for storing passwords.