We are creating reports and try to deliver them using a shared folder adding a subscription for that, but when we created it as for user credentials and we can add them for test proposes but the environment on prod, for security reasons we cannot put the credentials on it because IT uses all with windows authentication for security reasons.
Is it any way to set a windows user to deliver the file on the shared folder without add it when is configured?
The parameters for the database and the database server can be set in the data source as an expression, however you eiteher need to define a "ReportAdmin" user to always publish the reports with. The publisher should know the credentials prior to deployment. Other than that the data source will balk and inform that it needs credentials to run the operations :(
Related
As the Azure DevOps admin at my organization I want to automate our standards for Service Connection security--but I'm at a standstill because I can't seem to make straight forward changes to Project level Service Connection security manually via the ADO web portal.
Specifically, if I go to an ADO Project, go to Service Connections under Project Settings, and open up the Security page for it, I see a number of "Assigned" groups, each of which I can change and save the Role of (i.e. to Administrator, Creator, Reader, or User). All's fine and dandy there. However, if I "+Add" a user/group, it defaults to "Inherited" Access and when I change and save to a role other than the original one I added it with, the changes don't take. Likewise, there's no way to remove any user/group that's been added.
Has anyone else run into this issue? And if so what's the solution? And why are new users at the project level being marked as "inherited" and if they're inheriting from somewhere, from where?
Tried adding a new user at the ADO Project Service Connection Security level. Tried changing user Role. Changes don't take. Can't remove user.
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've checked that the TeamCity user has access to the network share in question.
All packages from the public NuGet feed are found correctly while packages available on the network share are not.
We use the network share when building via Visual Studio with the exact same path without a problem.
I've tried using "file://ratchet/NuGetRepository" but that doesn't make a difference.
TeamCity log entries and screenshot of the build step configuration shown below:
NuGet command: E:\BuildAgent01\plugins\nuget-agent\bin\JetBrains.TeamCity.NuGetRunner.exe E:\BuildAgent01\tools\NuGet.CommandLine.DEFAULT.nupkg\tools\NuGet.exe restore E:\BuildAgent01\work\95323b7041b60513\MySolution.sln -Source https://nuget.org/api/v2/ -Source \\ratchet\NuGetRepository\
Was able to solve this by specifying the fully qualified name of the network share, e.g. \\ratchet.hq.local\NuGetRepository.
Since the accepted answer did not provide a solution for my setup, I'd like to post what did allow TeamCity to access my network share.
First, a very important note: TeamCity Build Agent may either run as a Windows service or directly in command prompt. For my machine, this had the following consequences:
When run as a Windows service, the build agent was logged in as LocalSystem. For our network share, my machine's credentials were not given permissions.
Note: while this SO thread indicates that the network share can be configured to allow the machine's LocalSystem account to have permission, this was NOT an option for me.
When run in command prompt, the build agent will use the security context of whoever runs it (for me, it was my domain user). Again, for our network share, all domain users are given permissions.
The quick solution was to simply run the build agent in command prompt and call it a day; however, I did really want to run the build agent as a Windows service, since I think it is a cleaner approach.
Here's my solution:
First, I needed to grant my domain user the privilege to log on as a service. This is needed to run the service with my domain user's security context. I navigated to User Rights Assignment within Local Security Policy:
Control Panel -> Administrative Tools -> Local Security Policy -> Local Policies -> User Rights Assignment
Next, I added my domain user to the Log on as a servcie setting. For this, I made sure to include the domain with my user name.
Now that my domain user's security context can be used when starting a service, I navigated to Services (services.msc), located TeamCity Build Agent, and edit its properties:
Now, when relaunching the TeamCity Build Agent Windows service, it would be able to access the network share since it was using the security context of my domain user. I can now access the Nuget repository on our shared drive and keep the build agent running in the background.
You can include the package sources in NuGet.targets file. Just find the commented lines and add your path.
<PackageSource Include="https://nuget.org/api/v2/" />
<PackageSource Include="\\ratchet\NuGetRepository\" />
I'm trying to run Powershell scripts in my Team City build steps.
The scripts use WebClient to connect to Team City's REST API; currently, I have to login to Team City and hardcode a username and password as arguments in my Powershell build step.
I'm wondering if anyone knows a way to pass the credentials I am currently using to authenticate to Team City in my Powershell scripts without hardcoding any passwords
If you only need read access in the REST api (ie you don't want to do POST/PUT/DELETE, only GET) then use the teamcity generated user name and password.
This username/password pair is generated per each build and valid only during the build run. This is how you can access them in your powershell script:
read the $env:TEAMCITY_BUILD_PROPERTIES_FILE environment variable which holds the full path to the build properties file that are generated/valid for this build
this file is a simple key=value java prop file. You need to parse out the values for teamcity.auth.userId and teamcity.auth.password properties. Or better yet, parse all the props always in your script init phase and put them into a hash table in your powershell script.
If you need write access to the REST api, you can't use this uid/pwd pair. For this I am using a keychain on osx and a keepass db on windows. Keepass has a nice .net api that you can access from powershell. Create an new keepass db, make it unlockable with a key, not with a password, make sure your user running the build agent has access to this key and no one else, then use keepass api to unlock the db, read out your teamcity admin account and password who can do POST/PUT/DELETE in the rest api.
Thanks for the answer but we wound up providing the username and password as build parameters.
TeamCity's built in password protection helped us out here.
In this way, we're using one account to run our powershell scripts but we can still see who kicked off the build from the credentials they used to login to the web UI.
So we maintained traceable responsibility and stopped the constant entering of username and passwords.
More info: confluence.jetbrains.com/display/TCD7/Typed+Parameters
My build agents are not starting after I change the properties credentials to the domain account from the network service. I done this because the network service account cannot write to my drop folder.
Each time I add the network service to the drop folder share, it appears then disappears.
http://msdn.microsoft.com/en-us/library/bb778394.aspx I followed this but some steps are different, i have xp and it doesn't show the share tab so i go through security tab
So I guess I'm asking two questions here;
Agents are not starting after changing credentials.
Network service not able to write to the drop folder.
Thanks in advance
Yes, Network Service won't have permissions to write to a drop location. That's pretty standard. You need to be using a domain account.
The TFS Build Service will need to run as a domain user so it can write to the drop location.
The domain account for the build agent will need to be in the TFS Project Collection group for build service accounts (internal to TFS). I can't remember what it's actually called but you need to be a collection administrator to update it.
The domain account will also need some login as batch/service permissions but that should be done automatically when you reconfigure the service. Do you use the TFS Admin console to reconfigure the agent or did you just set the credentials on the service? (You should use the TFS Admin console).