RFE - Remove Remaining Secure Data Limitations

The introduction of client mailboxing a few years ago has facilitated the ability to securely encrypt secrets and passwords on the basis of specific and existing computers. The current process is unable to target groups of computers or computers that do not yet exist.

I propose the ability to eliminate those limitations by having secure data repositories ‘Secure Sites’ that are similar to custom sites. A ‘Secure Site’ would contain at least one, but possibly multiple secured bits of data. Those items would be created and saved into the ‘Secure Site’ much like one creates a fixlet and saves it into a custom site. Computers could be subscribed to the ‘Secure Site’ via a group membership or relevance. Subscription to the ‘Secure Site’ mailbox would facilitate the transmission of secure data to members of a group.

‘Secure Site’ would support multiple types of data beyond simply passwords to also include keys, secure strings, certificates (common formats), or other sensitive business data.

Allow items values stored in ‘Secure Sites’ to be referenced like a variable in other tasks, fixlets, baselines, and WebUI.

Organizations could set up multiple ‘Secure Sites’ so that secure content could be protected by permissions of operators. Perhaps add ‘permission to view secure value’. Allow users to be able to action or reference as a variable without knowing or having access to the underlying secure data.

There are many use cases for secure data such as password updates, domain joins, key/certificate distributions and more. The ability to target dynamic groups inclusive of yet-to-be-created computers is key.

If you support this idea, please vote for my RFE.

Here are prior forum threads for updating OS passwords and secure domain join that are use cases.

1 Like

Thank you to all who voted! The RFE is now ‘under consideration’.

If you support the concept and haven’t yet voted, please review and vote for it here.