Is it possible to allow a Console operator to create custom content (fixlets) while restricting them from deploying their content to certain servers (prod servers), but also allow them to deploy different content they didn’t develop (that is in a custom prod site) to the same prod servers?
We have a Dev group of servers and a Prod group of servers. We need Operators to write and test their own content on the Dev servers, but not be able to accidentally target Prod servers with their content, but also allow them to take action on read-only fixlets in the custom prod site. So far, the only way we can see doing this is by granting two operator accounts to the user (one for read only access to all servers, and one for write access to only the dev servers). But we aren’t allowed to grant two Operator accounts to a user, because we use PIV authentication.
Typically in this scenario we would issue two accounts to the user’s in question with their various access levels. You could also use a tool like Azure Automation or some other workflow tool and have actions to prod go through the workflow tool and become REST API actions instead of allowing operators to take ad-hoc actions via the console.
Yes I think the delegation model is somewhat lacking.
If you are only trying to prevent “oops”, the Prod servers should not execute Dev site content if they are not subscribed to the Dev site. But this does not prevent an operator from taking actions based on content in their Operator Site or using the “take custom action” dialog.
You could potentially leave the Prod servers in a Locked state. Then configure your Prod site to bypass the lock state - you can configure one, and only one, custom site in your deployment to bypass the computer locking state (we can pull more details if interested).
It’s also probably way more advanced, but you can tie a single PIV badge to multiple accounts. I use one badge with multiple accounts. There are at least a couple ways of doing it - printing multiple certs on the badge (not the way my org does it) or tying multiple Active Directory accounts to the same certificate and using Username Hints for login (how my org does it).
Your SAML authentication site would also need to support that option, or use the “Use Windows Credentials” option to auth to the console launched via Run As, with the disadvantage that you have to close the console to switch accounts (and console logon is slow).
I’m not yet using my PIV for console logon, and I don’t have the WebUI. Maybe WebUI eases some of the logoff/logon pain?
It works, but I believe it only allows a single site. I have a site configured to allow this behavior because we have a group that locks computers that connect to Lab Equipment to prevent an Action from rebooting any of the servers while the Lab Equipment is gathering data. Some of the samples they process are one of a kind, so data loss would be intolerable.
This should work for us. I will test it out. At the moment, we only need one site to be exempted from the lock state. But I need to test the ability to prevent non-master operators from unlocking, while still allowing mater operators to lock computers. I think this can be done with a role for the non-master ops.
Ah, I forgot about our BigFix Inventory processes. That external site needs to deploy the catalog fixlet every month to all endpoints. Since we can only exempt one site from the lock state, that means that we will require our BFI Console user to copy the catalog fixlet to the exempted site, and deploy the fixlet twice manually, rather than automatically from the BFI Console. It would definitely be nicer to be able to exempt more than one site.