I have a request to create an orchestration that would receive notification from an application directing the BizTalk server to change state. State may be Live, Disaster Recovery, or Fail Over. When BizTalk would receive this notification, it would then enable and disabled receive locations.
We have looked into powershell scripts that work but need special permissions given to the process that executes these scripts.
Is there any internal mechanism to BizTalk which will provide me the functionality I want without having to look into managing my powershell script with a specified user? Is there a better way of handling this kind of situation?
No, there is no 'special' internal API to manage a BizTalk Group that bypasses the security layer.
Management of BizTalk is through (mostly) WMI and ExplorerOM and the permissions are granted through membership on one of the Administrative groups. A BizTalk host is subject to the same rules as you or me.
My recommendation would be to define a new service account that has BizTalk Operators membership for the Group. Create a new Host/Hose Instance that uses this service account.
That Host would run only your Admin Orchestrations, nothing else.
If you choose this route, I'd also recommend doing WMI directly in C#, no PowerShell. It's a cleaner experiance.
Related
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
I recently came across an interesting feature of Windows PowerShell JEA (Just Enough Administration) which by default makes use of Windows virtual accounts to run the remote end point in admin context. I also understand these virtual accounts are created ephemeral for that session and get destroyed when the session ends. This also by default has the local admin rights on the machine for that session while the user running the session is a standard user who can carry out privileged operations using that virtual admin account.
This got me into thinking - we have a few apps in our organisation which sadly need local admin rights to run. We are reluctantly granting admin rights for the users of those apps. So I was wondering if there is a way through PowerShell we can create this Virtual account for the duration of however long that application runs? What I am thinking is some sort of wrapper PowerShell which is targeted by the application shortcut which would internally first spin up this virtual account to run that app as? I am assuming we need to configure some sort of one-off constrained custom app-specific JEA endpoint during the installation of the application. Then again, if the app requires the launching user's context to access back-end database etc. I am not sure how that would be taken into account.
I was just wondering if you have any clever thoughts? Thanks, Steve
Goal: Give users an account (domain user or basic, doesn't matter) and have them use Get-DhcpServerv4Lease cmdlet to convert their DHCP leases to reservations via the powershell web access feature using a web browser.
Issue/problem: I already made my own AuthorizationRule by importing that specific cmdlet but I feel like its missing others modules in order to authenticate/login? I can login if I grant microsoft.powershell configurationrule but cant if I grant the custom one that I made.
Error received upon login with my own custom configuration:
The Windows PowerShell Web Access gateway cannot establish a connection to the destination computer. Contact the gateway administrator. The error at the gateway is: The WS-Management service cannot process the request. The service is configured to reject remote connection requests for this plugin.
Question: Is there some other module I need to add to my custom rule or maybe there is a way to know what permissions microsoft.powershell contains so that I could mirror/copy them into my own rule?
Thanks
The quick answer: Remote Powershell needs to be enabled on the target system!
You can use System names, IP addresses or the FQDN. All of them will work (Use a mix as well)
To keep your Rules simple: Use Groups! Here is a Gist that could help you a bit. I have just a few rules and use AD Groups to manage the access (Systems and Users)
Please execute this (in an elevated PowerShell): Enable-PSRemoting -Force
You have to do this on all systems that you would like to access via the Web Gateway.
You will find a lot more Info about this on TechNet.
We want to utilize TFS release management for our deployments. We have several environments (dev, qa, staging, prod). Each of them in separate AD forest. Build machine also resides in separate forest. No trust between them.
I set up target machines to accept CredSSP authentications for PS remoting. I was able to enter PS session on target machine from build machine. But no luck from TFS task 'Powershell on Target Machines'.
Here how my tasks looks in TFS:
TFS PS on Target Machines task
In logs:
2016-12-30T15:04:11.0279893Z System.Management.Automation.Remoting.PSRemotingTransportException: Connecting to remote server app.dev.local failed with the following error message : WinRM cannot process the request. The following error with errorcode 0x80090322 occurred while using Negotiate authentication: An unknown security error occurred.
Is there any way to make TFS run PS on target machines that resides outside of build machine AD domain?
AD trust doesn't look like an option. And without proper PS remoting it doesn't look like release management can provide much value for us.
TL;DR;
No, you have two options.
Setup one way trust between your primary domain ans all of your sub domains so that your production domain credentials can be used on all of your sub domains.
use shadow accounts to allow cross domain authentication. These are local accounts with the same username and password across machines that allows auth. This is the official MSFT work around for non trust domain auth.
The long answer
Other than that, since you are well off the supported happy path, you would need to implement your own custom tasks that facilitated the cross domain authentication that you want. Should be a fairly simple task to implement your own tasks in PowerShell.
https://www.visualstudio.com/en-us/docs/integrate/extensions/develop/add-build-task
The reality is that there are only a few limited senarios that you need a "test AD" environment and it is never correct to have domains for Dev, QA, or Staging. AD is not designed that way and I have never seen it work for the benefit of the organisation or the development efforts. It is a product of over paranoid sysadmins and it is a lost cause.
The only reason to have a permanent additional domain is for your sysadmins to test their domain changes and configurations.
For software development projects that actively change AD, or require specific setups for testing, you would dynamically create your test domain along with the test machines required. That is how you create valid and repeatable tests against a Domain.
I'm in the process of pulling a classic ASP app into Mvc2. I'll be deploying to an intranet and have been asked to enable support for Windows Authentication. The network I'll be deploying to has a few AD Domains and I'll only need to integrate with one in particular. Is it possible to use Windows Authentication and only allow authentication within a particular domain?
Along those same lines, it's not uncommon for a user to have an account in multiple domains (the account names themselves are typically different) - in the event a user logs in with an "unsupported" domain I'd like to kick them to a login form. Is this possible simply using Windows Auth or am I better off looking for an alternative?
Pro Tip:
Whatever you do don't implement Windows Authentication via IIS. Have a Forms Authentication page in your MVC app but use the LDAP authentication provider. This way you avoid the differences between how browsers implement Windows Authentication (only works well in IE and that's not a great reason).
The question "Is it possible to use Windows Authentication and only allow authentication within a particular domain?" has always has one and only one answer in my consulting experience: the answer is the permissions that you set for authenticated resources.
I've rarely found a deployment where there isn't some file, folder, server, COM+ object, SQL Role or database table that can't be "locked down" to only allow access by the subset of users you're targeting (e.g. "DOMAIN\Domain Users"):
Set permissions on the ASPX files (or the folder containing them, along with inheriting to the files) that are the "front door" (and optionally, all the others) so that they're only accessible to users in the "Domain Users" group for the allowed domain
restrict logon rights on the server that hosts the web site, so that only the Domain Users group have the appropriate rights - depending on the authentication provider used, this could be "allow logon locally" or "access this computer from the network"
set permissions at some layer of Component Services
restrict the SQL Server roles so that only "Domain Users" have the ability to read & execute the necessary database objects