Plain-text passwords

[tristanm]

It's a big security risk storing passwords in plain text. In fact, my workplace forbids it, and rightly so.

Is it possible already to write a configuration which prompts for passwords? If not, I think this is an important feature which needs to be included.

The first step might be to use Get-Credential to prompt for missing passwords, or on some configuration flag, e.g. "PromptForPassword": true.

I'm led to believe that PSCredential objects will compile as into plain text in .MOF files unless there's a certificate on the target machine which the local machine has the public key for. So, the second step might be automating/documenting that process.

Happy to help contribute where I can.

[pfoppe]

I agree!!

For now, we have been scrubbing our .json files after execution. Our passwords have to be updated/changed every 60 days, so leaving them behind in the .json files brings little value to us due to our organization policies. Then, we have to manually add them back in before we complete an upgrade (and scrub again after complete). And... I really don't like the idea of leaving behind clear text passwords in any files after the execution is complete.

We even dabbled with adding a pre/post-processing steps by: 1) trying to read in the .json file $config = Get-Content -Raw -Path myfile.json | ConvertFrom-JSON

2) fetch passwords from our password management system and plug those values into the password fields. EX:

$psa='mycoolpassword'
$config.ConfigData.Credentials.PrimarySiteAdmin.Password = $psa

3) write a new temporary .json file with the passwords embedded $config | ConvertTo-Json -depth 100 | Out-File "temp.json"

4) then... run the Configure-ArcGIS command using the temp.json file.
Configure-ArcGIS temp.json InstallLicenseConfigure

5) Then... remove the temp.json file rm temp.json

Although, we ran into some issues with the powershell ConvertTo-Json encoding certain characters and gave up. We were not interested in adding another solution to resolve this issue (like python). And... it seems that powershell added a new EscapeHandling parameter that might help with this - https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/convertfrom-json?view=powershell-7#parameters

However... we are still on Powershell v5 (and this was introduced at 6.2). Something to look into again

… back to topic...

I'm interested in a more secure capability to better protect these credentials. Ideally something that is compatible with other 3rd party password management solutions.

Prompting for a password (and cleaning up any temporary files on the back-end that logged the credentials) is 1 big step forward, but may not be fully compatible with other 3rd party solutions.

I realize we cannot support all (or ANY) 3rd party password management solutions, but maybe having the option for generic integration would be best. Something like:

a) PSDSC reading from an environment variable This would be another good step forward - if the environment variable can be set (outside of the PSDSC execution), and PSDSC can read it, then we are no longer 'storing clear text passwords in a file', but we are still storing them in a session environment variable. I'm assuming that closing down the powershell session would purge all this information?

b) taking passwords in as command line arguments to the PSDSC execution this could be a little hairy with the amount of credentials that may be needed.

c) Still taking a clear text password in the .json file, but then encrypting that content after execution This is similar to how some of the REST API functions work.
See WEBGISDR - https://enterprise.arcgis.com/en/portal/latest/administer/windows/create-web-gis-backup.htm

PORTAL_ADMIN_PASSWORD = Specify the password of the portal administrator account.

PORTAL_ADMIN_PASSWORD_ENCRYPTED = <true | false> Set this option to false the first time you populate the file with your administrator password. When you save the file, your password is encrypted and the value for PORTAL_ADMIN_PASSWORD_ENCRYPTED is set to true to indicate the password has been encrypted. If you need to change the password in the future, set PORTAL_ADMIN_PASSWORD_ENCRYPTED = false, provide your new administrator password, and save the file.

And Server/Portal identity store configurations REF1 - https://developers.arcgis.com/rest/enterprise-administration/server/updateidentitystore.htm REF2 - https://developers.arcgis.com/rest/enterprise-administration/server/userstore.htm

d) Other options not laid out here?!?!

Thanks for the consideration

[cameronkroeker]

Hello @tristanm and @pfoppe,

We now support the use of Encrypted Password Files and Encrypted MOF Files in the latest release, v3.0.0.

V3. Password Files and Encrypted Deployments: https://github.com/Esri/arcgis-powershell-dsc/wiki/V3.-Password-Files-and-Encrypted-Deployments

[tristanm]

@cameronkroeker, this is fantastic news!

For the curious, it would seem that the string generated using Read-Host -AsSecureString | ConvertFrom-SecureString is only decryptable by the same user on the same machine, which is pleasing.

It would be good to also document when the process for generating a certificate for encrypting MOFs is actually necessary. In PS >= 5.0 with DSC in push mode it would appear is it not. Looking at a MOF file on a target node, it is indeed encrypted. That said, I don't know how Invoke-ArcGISConfiguration behaves in v3.1.0 with encrypting MOFs on the local machine when PasswordFilePath is being used. Anyone able to confirm this behaviour?

[cameronkroeker]

@cameronkroeker, this is fantastic news!

For the curious, it would seem that the string generated using Read-Host -AsSecureString | ConvertFrom-SecureString is only decryptable by the same user on the same machine, which is pleasing.

It would be good to also document when the process for generating a certificate for encrypting MOFs is actually necessary. In PS >= 5.0 with DSC in push mode it would appear is it not. Looking at a MOF file on a target node, it is indeed encrypted. That said, I don't know how Invoke-ArcGISConfiguration behaves in v3.1.0 with encrypting MOFs on the local machine when PasswordFilePath is being used. Anyone able to confirm this behaviour?

Hi @tristanm ,

The password file path is encrypted independently of the MOF files, as the Invoke-ArcGISConfiguration won't encrypt the password file. Once you have generated the encrypted password file, you can provide the path to password file which is local to the target machine. I will look into clarifying this within the wiki page.

Thanks, Cameron K.

[tristanm]

Hi @cameronkroeker, sorry, I should have been clearer with my comment (it was approaching midnight at the time). I've answered by own question since then:

What I meant to say was, I understood from this doc that MOFs were always encrypted when they were sent to the target node, if they were sent in push mode (as opposed to from a pull server), and I had verified this. Given this fact, I thought that the process of setting up certificates is perhaps not necessary for all situations where password encryption is required, but I wasn't sure if MOFs on the authoring node were encrypted because they get deleted before they can be inspected.

Since then, I've tested this for myself by preventing the authoring node's MOFs from being deleted. I can confirm that neither the MOFs nor the passwords within them are encrypted if a certificate is not used, so yes, certificates are very much required.

Additionally, MOFs on target nodes are themselves encrypted, not just the passwords within. This is not the case with MOFs on the authoring node where just the passwords are encrypted.

All sorted now 👍