Hello,
Is there a way to manage four-eyes approvals through a PowerShell session? I have not been able to locate a cmdlet that supports this specific action.
BR,
Albin
-
- Lurker
- Posts: 2
- Liked: never
- Joined: Aug 23, 2024 11:18 am
- Full Name: Albin Novak
- Contact:
-
- Veeam Software
- Posts: 2751
- Liked: 631 times
- Joined: Jun 28, 2016 12:12 pm
- Contact:
Re: Four-eyes powershell authorization
Hi Albin, welcome to the forums.
At this time no, there is not an endpoint for approving/disapproving Four-eyes authorization requests via Powershell.
May I ask the use case? The actions requiring Four-Eyes authorization should be reviewed before approving, and I'm just not sure I understand the workflow you would be using with Powershell automation, especially since any script would potentially be a vector for malicious activity, so just hoping you can elaborate on your intended workflow.
With console features like Multi-Factor authentication ( MFA ) would help with protecting against malicious actors being able to just log in and authorize their own deletions, so I'm just not sure I'm understanding how a safe workflow would look for this, but perhaps you can explain your idea a bit more on how you'd envision your powershell script working if it could approve Four-Eyes authorization events.
Thanks!
At this time no, there is not an endpoint for approving/disapproving Four-eyes authorization requests via Powershell.
May I ask the use case? The actions requiring Four-Eyes authorization should be reviewed before approving, and I'm just not sure I understand the workflow you would be using with Powershell automation, especially since any script would potentially be a vector for malicious activity, so just hoping you can elaborate on your intended workflow.
With console features like Multi-Factor authentication ( MFA ) would help with protecting against malicious actors being able to just log in and authorize their own deletions, so I'm just not sure I'm understanding how a safe workflow would look for this, but perhaps you can explain your idea a bit more on how you'd envision your powershell script working if it could approve Four-Eyes authorization events.
Thanks!
David Domask | Product Management: Principal Analyst
-
- Lurker
- Posts: 2
- Liked: never
- Joined: Aug 23, 2024 11:18 am
- Full Name: Albin Novak
- Contact:
Re: Four-eyes powershell authorization
Hi David,
thanks for your reply. My use case is related to VSPC, which at this point doesn't support four-eyes authorization workflow. But it does support remote »PowerShell Session« where you basically connect to VBR server itself and can run all cmdlets the same way as local logged user. So powershell could serve as a convenient workaround for my use case.
BR,
Albin
thanks for your reply. My use case is related to VSPC, which at this point doesn't support four-eyes authorization workflow. But it does support remote »PowerShell Session« where you basically connect to VBR server itself and can run all cmdlets the same way as local logged user. So powershell could serve as a convenient workaround for my use case.
BR,
Albin
-
- Veeam Software
- Posts: 2021
- Liked: 673 times
- Joined: Sep 25, 2019 10:32 am
- Full Name: Oleg Feoktistov
- Contact:
Re: Four-eyes powershell authorization
Hi Albin,
I'm with David on this. At this point we agreed that the first iteration of four-eyes authorization feature won't be supported in the APIs for security reasons - having such functionality exposed through an API provides an additional point of failure. Also, it kind of defies the whole point of the feature - being accountable for a manual informed approval when four-eyes is enabled. Further on, if we agree internally on the security workflow that would function also for an API in this case and wouldn't contradict the concept of the feature, we will definitely consider covering it.
Best regards,
Oleg
I'm with David on this. At this point we agreed that the first iteration of four-eyes authorization feature won't be supported in the APIs for security reasons - having such functionality exposed through an API provides an additional point of failure. Also, it kind of defies the whole point of the feature - being accountable for a manual informed approval when four-eyes is enabled. Further on, if we agree internally on the security workflow that would function also for an API in this case and wouldn't contradict the concept of the feature, we will definitely consider covering it.
Best regards,
Oleg
Who is online
Users browsing this forum: No registered users and 7 guests