In Visual Studio Team Services I tried to define permissions to allow a certain group permissions to manage release definitions.
I therefore added the Active Directory group to the Release Administrators group in the team project. If a user from the specific group logs into Visual Studio Team Services and tries to create a release definition (or does some other managing operation) he receives the following error:
Access denied. UserX needs Use permissions for queue Default to perform this action. For more information, contact the Team Foundation Server administrator
It seems like the user generally has permissions to create a release definition, but lacks permission on the release queue. How can I give a certain Active Directory group Use permissions to an agent queue?
If I add the Active Directory group also to the Project Collection Build Administrators group on the Default Collection level, managing release definitions work. But this will also give them permissions to build definitions, which they don't require.
You should add the AD group to Agent Queue Users group or Agent Queue Administrator group as per your requirement. To do that, go to the Agent Queues tab in the settings at Collection/Account level
Related
When I create a brand new CodeBuild project, it allows me to select an IAM Service Role, and when I check the box "Allow AWS CodeBuild to modify this service role so it can be used with this build project", AWS modifies that Service Role with a custom policy that's specific to this role.
But If after creating that CodeBuild project I want to attach a different service role to it, I keep getting the below message saying "The policy was not attached ot role [x]"
I'm pretty sure I'm missing a permission somewhere, but I'm not sure where.
Edit with more troubleshooting data:
If I uncheck the box "Allow aws [...]" It allows me to update the CodeBuild project configuration, but all subsequent builds fail at startup. This is expected.
If I try to re-add the original service role I added to this project when I created it, it lets me add it without any problems.
I had the similar issue when I tried creating a more generic role that can be used by all of my CodeBuild projects. The way I got around it is I unchecked the "Allow AWS CodeBuild to modify this service role so it can be used with this build project" checkbox
I had to ensure that the role I'm attaching had all the necessary IAM permissions for my subsequent builds to keep running
I had the same issue and noticed that the previous role that was assigned to the CodeBuild project also had a Managed policy attached that had been added when the project was originally created. This role was named similar to this:
CodeBuildBasePolicy-project-name-us-west-2
I attached this policy to the new Role and detached it from the old role.
After this I was able to select "Update environment" and did not receive the error message.
After a long time spent on this issue, I discovered the problem!
I modified my CodeBuildServiceRole-projectName base policy instead of creating a new policy and attaching it to the CodeBuildServiceRole-projectName role. You should never edit the inline policy that was created by CodePipeline! Only create and add new policies to a role.
As AWS obscurely states in their documentation:
Modifying a policy statement or attaching another policy to the role can prevent your pipelines from functioning. Be sure that you understand the implications before you modify the service role for CodePipeline in any way. Make sure you test your pipelines after you make any change to the service role.
If you delete a CodeBuild project, the policies that CodeBuild created remain attached to the existing role. When you create a new project with the same name as the deleted one - this error will occur.
My solution was to delete all of the roles and policies that were referenced in the pipeline and rebuild those roles and policies. Then rebuild the pipeline.
I have set up TFS Security using Active Directory groups and in source control explorer through Visual Studio, users only see Team Projects that they have access to. However if they go to Team Explorer and click on the drop down menu they see almost all the team projects. If they go to web Tfs as well, the behaviour is exactly the same.
How do i restrict them to only see projects in dropdown that they have access to?
Project Collection Valid Users Group - Permissions
Project Collection Test Service Accounts - Permissions
Project Collection Service Accounts - Permissions
Project Collection Proxy Service Accounts - Permissions
Project Collection Build Service Accounts - Permissions
Project Collection Build Administrators - Permissions
--At Project Level--
All Project Valid Users group at Project Level are members of Project Collection Valid Users group
User Access From Collection Level:
You need to add the user/groups to the specific team project but not in Collection level. Thus , the restricted user/groups can only see the specific team projects which they have permissions under the collection.
In Team Explorer you can select the projects which you want to connect/display.
Update:
Add the group under specific team project (Set permissions in
Project level)
Add the same group under the specific collection
Under the collection security set "View Collection Level
Information" to "Deny" for the group (Set permissions in Collection
level)
Then the users in the group will can only access TFS with project permissions.
SonarQube v5.2
I am trying to create a technical user (one that is authenticated locally and not against our LDAP). I have added a user name to the conf/sonar.properties file and restarted SonarQube. But, when I log in (as an administrator), the new user doesn't show up in the Administration | Security | Users list. We have two previously defined technical users (including admin) which do show up.
The admin guide doesn't say much http://docs.sonarqube.org/display/SONARQUBE52/Authentication.
Is there another step needed to create a technical user?
You need to manually create the user in SonarQube, it won't be automatically at startup.
Note that the SonarQube version you're using is no more supported, you should migrate to the latest LTS version 5.6.X => local users (previously known as technical users) are better managed :
- No more need to update sonar.properties
- You just have to create a user from the web server, this user will automatically be considered as a local user.
I've updated http://docs.sonarqube.org/display/SONAR/Authentication in order to remove the "Technical" word.
In my organization we are deploying our components using Microsoft TFS. The NServiceBus components are deployed as Windows Service by the BuildPortal.It typically creates the automated MSI packages and deploys it on the target servers. To deploy the MSI packages, the build portal uses the Service account (the Administrator/SuperUser). The NServiceBusHost will not run with the same service account, either it will use the System account or different Service account, which has restricted permission on the server and the account will not be part of the Administrator group.
In short, the Host /install command runs with different account than the actual NServiceBusHost execution. During the install, all the required queues are created by the installer (by using NServiceBus.Integration profile). Now, the problem is, since the queue created by different account than the original service account, it throws the following error.
Message:Could not create queue error#xxxxxxx01 or check its existence. Processing will still continue.
NServiceBus.Utils.MsmqUtilities.CreateQueueIfNecessary(:0)
System.Messaging.MessageQueueException (0x80004005): Access to Message Queuing system is denied.
at System.Messaging.MessageQueue.SetPermissions(AccessControlList dacl)
at NServiceBus.Utils.MsmqUtilities.SetPermissionsForQueue(String queue, String account)
at NServiceBus.Utils.MsmqUtilities.CreateQueueIfNecessary(Address address, String account)
To resolve the above error, we tried to use the INeedToInstallSomething. But, there are no proper documentation/sample on how to use or what to use inside the Install() method. When we call the Configure.Instance.ForInstallationOn().Install() the installer is not creating the queues as expected. All we wanted is, to get the list of dependent queues of current installer & set the permission something like this >> messageQueue.SetPermissions(serviceAccount, MessageQueueAccessRights.FullControl)
Is this possible to get all the dependent queues for the current Host and assign the permission during the Host install only.
NOTE:
We dont want to move this logic outside of the host for now. Yes,
having a simple PSS may help to reslove this issue.
We have to use the restricted account to run the Host which can't be a Administrator.
I would try either INeedToInstallInfrastructure<T> and set the permissions there, or this may be like the perf counters which uses IWantToRunBeforeConfigurationIsFinalized. You may need the latter and I'm not sure what order if any is used for INeedToInstallInfrastructure<T>.
I have created a report and subscriptions but when I go to SQL Server 2008 R2 Management Studio and connect to Report Server I do not see anything under Jobs folder. When I right-click I do not see an option to create a Job. How do I make a job so that it shows under this folder?
There are a couple of things you can check
Is SQLAgent currently turned on?
Is SQL Agent set to auto-start?
Under what permissions (i.e. user account or proxy account) is SQLAgent set to run?
What type of subscription did you create? scheduled? data-driven? (the latter is an enterprise-edition only feature)
What delivery method for the subscriptions? to a folder? via email? If to a folder, does the SQLAgent account have the appropriate permissions to read/write on that shared folder? If via email, have you configured the SMTP settings in SSRS configuration tool?
I am assuming that SSRS is installed in native (not SharePoint integrated mode) - is this correct? There are different set of troubleshooting steps if the latter
For completeness, here's an MSDN reference (step-by-step) on how to create a subscription. Also I assume that your user account has the appropriate permissions to create other types (that is, non-SSRS subscription jobs) of new jobs on your SQL Server instance via SSMS.