Specific permissions required to run exchange 2010 powershell commands - powershell

The helpdesk will be using a script I wrote to set out of office replies and to modify folder permissions but are running into permission issues using them. Is there any resource that would indicate what permissions each powershell command in the exchange cmdlet takes to be able to be ran? Failing that does anyone know the specific permissions needed to set OoO and modify folder permissions?
I did find this that gives specific roles needed to do various things but it's not quite what I'm looking for. These roles give access to far more than what we need.
EDIT: The Auto Reply role is all that is required to set allow use of the Set-MailboxAutoReplyConfiguration. Looking into the others still.

That seems to be as granular as the roles get.
If you want to restrict them further, you can set up one or more remote sessions they can connect to that use a delegated account that is an Exchange role member, and constrain the session to just being able to run your script.

Related

Powershell - automated connection to Power BI service without hardcoding password

We have a PowerShell script to pull Power BI activity data (using Get-PowerBIActivityEvent), and I have been trying to automate it so that it can pull this data daily using an unattended account. The problem is the script must necessarily use the Connect-PowerBIServiceAccount cmdlet, which requires a credential. I don't want to have the passwords hard-coded anywhere (obviously) and ideally don't want to be passing it into the script as a plaintext parameter in case of memory leaks.
I've tried using SSIS as a scheduling mechanism since it allows for encrypted parameters in script tasks, but can't call the PS script with a SecureString parameter since the System.Management.Automation namespace isn't in the GAC (a commandline call wouldn't be possible).
I don't believe task scheduler would offer the functionality needed.
Does anyone know of any elegant ways to connect to the power BI service using encrypted credentials?
In the docs of Connect-PowerBIServiceAccount there are 2 options for unattended sign-in:
Using -Credential, where you pass AAD client ID as username and application secret key as password
Using -CertificateThumbprint and -ApplicationId
For both options you need to configure service pricipal and add proper permissions. I'm not going into details how to configure that, but most probably you'd need (at least) the following application permissions:
I'm not really sure what functionalities you need in the script, but in my experience, majority of the cases can be covered by scheduled task, so the explanation below will apply to that solution.
How you can secure the credentials?
There are variuos possible solutions, depending on your preferences. I'd consider certificate-based authentication as more secure (certificate is available only to current user/all users of the machine).
What's important in certificate-based authentication - make sure that the certificate is available for the account running the script (in many cases it's service account, not your user account).
How can I secure more?
If you want, you can store application ID as secure string (I don't have SSIS to test, so I'm not sure if there's any workaround to make it working in there) or use Export-CliXml. They use Windows Data Protection API (DPAPI), so the file can be decrypted only by the account which was used to encrypt.
To add one more level of security (I'm not even mentioning setting correct access rights to the files as it's obvious) you might put the file in the folder encrypted (you might already have a solution for disk encryption, so use it if you wish).
There are probably some solutions to secure the keys even better, but these ones should do the job. I'm using other Microsoft 365 modules with similar approach (Outlook, SharePoint PnP) and it works quite well.
NOTE: If you need to use user account, instead of service principal, make sure that you have MultiFactor Authentication disabled on that account for that specific application.
The relevant documentation to this (https://learn.microsoft.com/en-us/power-bi/developer/embedded/embed-service-principal) states that admin APIs (i.e. those served via Get-PowerBiActivityEvent) do not currently support service principals. This means it's not currently possible to use a registered app to run these cmdlets unattended.
There is a feature request open to provide this at the moment: https://ideas.powerbi.com/forums/265200-power-bi-ideas/suggestions/39641572-need-service-principle-support-for-admin-api

Is there a way to use a non-login user to run Rundeck jobs?

So my goal is to create a Rundeck job that runs on a schedule and isn't run as my personal user, or any "regular" user, but rather a bot user. Ideally this bot user wouldn't have login access and restricted permissions for security reasons, but would be able to run certain jobs. I've tried searching, but the only information I'm finding is about how to create a "regular" user in Rundeck. Even if I go down that route of creating the bot user as a "regular" user, to use it, you need to pass in either the login credentials or an API token. An API token would be fine, if it could be generated and pulled in on the fly. However, that is not the case, the API has an expiration itself. If there is something I'm missing, please let me know. I'd love to get this working.
Rundeck Version: Rundeck 3.2.1-20200113
Rundeck Cli Version: 1.1.7
You can set the following configuration in your rundeck-config.properties file (usually at /etc/rundeck/ directory):
rundeck.api.tokens.duration.max=0
This will disable your maximum period, you can see this in the official documentation here.
With that, your "bot user" can do it through API / RD CLI as you wrote.
Try using webhooks https://docs.rundeck.com/docs/manual/12-webhooks.html
You can trigger a job by making a http-request
The way I've implemented bots is as a user who is a member of a 'bot' user group, with ACLs that lock down that group as required. Any passwords required for the scheduled job are loaded into the key storage of the bot user.
With this approach you still need someone who knows the bot credentials to login as them and set passwords/SSH keys, but that's a one-off. Is that what you're trying to avoid?
The one annoying thing I've found is that a scheduled job always seems to run as the last user to edit the job - so I grant edit access to bot users and make sure to set/reset the schedule after any edit by a normal user. Hoping to address this through https://github.com/rundeck/rundeck/issues/1603, you might want to give it a 👍.

Find computers with a specific user in local admin group

I need to check if a specific domain user is a member of a local administrators group.
I prefer to use Powershell, but the problem is that we are not allowing WinRM so I can't use PSRemoting, so I can't run Get-LocalGroupMember or something.
Thanks alot for your help.
I recommend you to have a look on PowerView. Get-NetLocalGroup queries the information via WinNT provider or on demand via WinAPI.
Refer to harmj0y's blog for more information.

Get Azure subscription details of client

I want to get details of Azure Subscription of my client. But I do not want to ask for special permission from client.
What I need is the bare minimum things from my client so that I can login from powershell or rest api and read status of runbook jobs.
If i login from admin account of the subscription than I can easily get those details. But you understand it is not possible to have admin account credential of my client.
Please suggest some workaround.
What you need to do is create a user in Azure Active Directory and grant that user specific rights using either the Azure Portal or PowerShell\Cli\SDK.
Say read all, or read properties of desired automation account. If you would want like a super minumim, you would need to create a custom role first.
https://azure.microsoft.com/en-us/documentation/articles/role-based-access-control-custom-roles/
If your client placed specific resources within a Resource Group, they may grant you permissions on just that Resource Group (including read-only permissions). This would allow you to have access to needed resources, without having access to other areas of their subscription.

Programmatically raise user privileges

I have been maintaining an installation for a while but I am not really an expert. now I've been asked to come up with a solution for this:
Our software is always sold together with a computer as it has to be run in a very controlled environment. The installer needs administrative privileges to be executed. So far we had two different users, one with administrative rights and other one without. Our custumer service login as Administrator, install the software and restart the machine so that the user can access as a normal user.
Now we want the user to be able to install the software themselves but we don't want them to have access as an administrator because they can modify things it shouldn't be modified.
So, is there any way to programmatically raise the user privileges during the installation and afterwards lower them back? The installer is made using InstallShield but we use vbscript to check some pre-requisites.
Check out CPAU. It allows you to create an encrypted command that will run the installation as administrator.
EDIT: This is a more comprehensive list of like tools.
If you are looking for a toolkit to do this kind of thing, well, Microsofts MSI technology has this built in: Administrator access is required to install the initial MSI file, additional patches (MSPs I think) are digitally signed by the original MSI and are thus deemed safe - users can install them without requiring administrator elevation.
You can do the same thing: As part of your administrative install, install a service. The service can create a named pipe - that you explicitly give user ACLs to - or even just a socket or monitor a drop off folder that allows the user level code to communicate with the service code (running with SYSTEM or configured access). The service can then use its SERVICE or configured account level permissions to either impersonate an administrator, or do other tasks on the behalf of the user without EVER giving the user any kind of elevated permission - even temporarily.