Maybe an easy question for someone who knows Powershell and O365 well. Is there a way to configure it so when a command is run for example to pull all access to a shared mailbox, that either a service account is permissioned each time to pull that information or the user who is running the script? I looked at connecting an SA to the script but it would have too much access to 0365 to give it the specific permissions. So the account is not permissioned for the access by default but every time the script/command is ran its permissioned for that inquiry which it shows then it won't have access until the next time its called.
Looking to add this type of function to a script which we only want the helpdesk people to see the information when they run the script and the specific command in the script.
Hopefully explained clear enough :)
Thanks all.
I don't think there is a way to do that natively. You could fiddle something with Azure PIM but that's more for one-off operations than minute action that are done often.
You could however circumvent that by making some sort of web interface that triggers commands on another server using a privileged SA and returns the output through the web interface. You can just make it so that the interface can only request one specific command to be run, and the only thing you have to worry about is sanitizing your parameters well to avoid unwanted injection.
Alternatively, what are you trying to protect against by restricting access so much ? Isn't it something that could be done more easily using a read-only account and some clearly defined policy ? If your helpdesk people overstep their allowed scope, that's a management/HR problem as much as a technical one.
Related
I am using PowerShell to manage Autodesk installs, many of which depend on .NET, and some of which install services, which they then try to start, and if the required .NET isn't available that install stalls with a dialog that requires user action, despite the fact that the install was run silently. Because Autodesk are morons.
That said, I CAN install .NET 4.8 with PowerShell, but because PowerShell is dependent on .NET, that will complete with exit code 3010, Reboot Required.
So that leaves me with the option of either managing .NET separately, or triggering that reboot and continuing the Autodesk installs in a state that will actually succeed.
The former has always been a viable option in office environments, where I can use Group Policy or SCCM or the like, then use my tool for the Autodesk stuff that is not well handled by other approaches. But that falls apart when you need to support the Work From Home scenario, which is becoming a major part of AEC practice. Not to mention the fact that many/most even large AEC firms don't have internal GP or SCCM expertise, and more and more firm management is choosing to outsource IT support, all to often to low cost glorified help desk outfits with even less GP/SCCM knowledge. So, I am looking for a solution that fits these criteria.
1: Needs to be secure.
2: Needs to support access to network resources where the install assets are located, which have limited permissions and thus require credentials to access.
3: Needs to support remote initiation of some sort, PowerShell remote jobs, PowerShell remoting to create a scheduled task, etc.
I know you can trigger a script to run at boot in System context, but my understanding is that because system context isn't an actual user you don't have access to network resources in that case. And that would only really be viable if I could easily change the logon screen to make VERY clear to users that installs are underway and to not logon until they are complete and the logon screen is back to normal. Which I think is really not easily doable because Microsoft makes it near impossible to make temporary changes/messaging on the logon screen.
I also know I can do a one time request for credentials on the machine, and save those credentials as a secure file. From then on I can access those credentials so long as I am logged in as the same user. But that then suggests rebooting with automatic logon as a specific user. And so far as I can tell, doing that requires a clear text password in the registry. Once I have credentials as a secure file, is there any way to trigger a reboot and one time automatic logon using those secure credentials? Or is any automatic reboot and logon always a less than secure option?
EDIT: I did just find this that seems to suggest a way to use HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon without using a plain text DefaultPassword. The challenge is figuring out how to do this in PowerShell when you don't know C#. Hopefully someone can verify this is a viable approach before I invest too much time in trying to implement it for testing. :)
And, on a related note, everything I have read about remote PowerShell jobs and the Second Hop Problem suggests the only "real" solution is to use CredSSP, which is itself innately insecure. But it is also a lot of old information, predating Windows 10 for the most part, and I wonder if that is STILL true? Or perhaps was never true, since none of the authors claiming CredSSP to be insecure explained in detail WHY it was insecure, which is to me a red flag that maybe someone is just complaining to get views.
I'm unsure if what I'm trying to do is possible. I have a PowerShell script that takes three arguments. In a perfect world, I'd collect the necessary information in a web form and pass it to the script, which would then run.
I don't know if this is even possible, but I can't find anything that definitively tells me no. I'd need it to be cross-browser capable (we have some Macs) so I can't just do an IE-only fix.
This is also internal only, so I'm less concerned about some security risks. It will be behind our firewall.
Thanks.
Not sure to understand the question, but for collecting the necessary information in a web form and pass it to the script, which would then run I user PowerShell Web Server (tag : poshserver in stackoverflow). Sources are available, so I even implements Jobs for long scripts.
I'm a novice with AS/400. I have a bit of coding experience and know that there's always an access to the backend if you're clever enough. But developers in my organisation said that it's hard to communicate with the server and make it run things remotely.
So I'm wondering if you anyone's got any ideas how I can schedule a simple task. I login to the "Personal Communication", which is the client app. Then I go to a certain menu, ie I543, enter a parameter "1". And Press "ENTER" to run a report which have a file output.
I know there is that "Macro" function within Personal Communication. But that relies on send keys which does not work on a locked screen, nor do I want to activate it manually, which really defies the point of automation.
I was hoping I can schedule a simple call command somehow to activate some kind of procedure. Just need to know if possible and where to start looking? Thanks.
Last millennium's AS/400 and today's IBM i both have a basic job scheduler built in.
From a command line WRKJOBSCDE.
You need to find out what happens when you select menu I543 option 1. Assuming it's a simple CALL MYRPT or SBMJOB CMD(CALL MYRPT) then adding a scheduled job to run the report is easy.
However, you probably don't have the authority to do so. Nor should your developers necessarily be able to do so. Your system administrator is the right person. In a small shop, that might be the guy doing development. In a large one, it's another person or team.
But your developers should have at least pointed you toward the admin and the job scheduler.
I want to provide some administrative services that will be implemented against the Office365 PowerShell, but I don't want to store decryptable administrators credentials - is there any option for authenticating without direct usage of the credentials? I am thinking about something like OAuth or another application key system.
Not 100% clear from the question but since you don't want to store creds I assume that this will be running on client computers rather than on systems that are directly under your control. I can think of two options but they both add considerably to the complexity of a script like this.
Option 1
Split your script into 2 pieces, one set up as a web listener on a server that is running with elevated privileges and the other running on the system where you want the script to be placed that makes REST calls to your web listener, this lets you only expose the functions that you actually want the lower-privileged script to have access to without having to deal with storing the creds. This is more complex to set up but doesn't require anything third-party to be in place.
Option 2
Use a privledged identity management system(I'm most familiar with CyberArk but any of them should be ok for this purpose) to store the creds, You would then sign your script with a certificate and set the identity manager to only allow a process signed with that cert and connecting from a known valid IP to access the credential, again using a web call. This is easier to do once you get the PIM installed but that can be a massive headache to do properly, not to mention expensive.
Hope I understood the problem correctly and that one of these methonds helps you.
We are using perforce in my company and heavily rely on it. I need some suggestion for the following scenario:
Our Depot structure is something like this:
//depot
/product1
/component1
/component2
.
.
/componentN
/*.java
/*.xml
/product2
/component1
/component2
.
.
/componentN
/*.java
/*.xml
Every product has multiple components and every component consist of java or xml or some other program file. Every component has a manager/owner associated with it.
Right now, we have blocked the write permissions for every user and only when it is approved by the manager/owner after code review, we open the write permission for that user for any file/folder to check in. This process becomes a little untidy because the manager/developer have to wait for perforce admin to allow permissions (update protections table of perforce). Also, we give them a window of only 24 hrs to check in (due to agile, which i dont understand much :)), after which we are supposed to block the write access again for that user.
What I am looking for is a mechanism where perforce admins can delegate this responsibility to respective managers/owners without giving them super user or admin access and which automatically disables the write permission after 24 hrs.
Any suggestions ?
Thanks in advance.
There's nothing to do this out of the box, per se.
The closest thing I can think of is if the mainline version of these components were permissioned by a group with an owner. The owner of the group is allowed to add and remove members from the group, thus delegating the permissioning to the "gatekeeper" rather than the admins, themselves.
Let me know if you require further clarification about this.
One common solution is to build a simple tool which reads and writes the protections table, the group memberships, etc., to implement the policies that you desire.
The protections and groups data are not complex in format, and you can easily write a little bit of text-processing code that writes and re-writes these specs according to your needs.
Then install your tool on the server machine in a secure fashion, granting the tool the rights to update the protections table, and have your component administrators use the tool to manage the permissions.
For example, I've seen this done by writing a small web application, in Java or Perl for example, installing that on a web server on a secure machine, and letting the component admins operate that tool through a web interface.
All your tool has to provide is (a) a simple login/logout mechanism for your component admins (the web server may already do this for you), (b) a command that takes a user name and a folder name and grants permission, and (c) a command (or a timer) that removes that permissions subsequently.