We are using a Jenkins Master and Slave (both Linux) type setup. Recently upgraded to LTS version and for some reason Slaves connects to Master only when Anonymous is given Admin privileges.
I have read the posts about providing Anonymous slave connect privileges but I receive a 403 request forbidden error when I try that.
The only way around for this is to provide Anonymous Admin privileges (which is risky) save it and then go back to Manage Jenkins > Configure Security > Remove Anonymous Admin > Add Slave connect privileges.
The issue in doing this workaround is, I get the same 403 error when slave restarts until I give Anonymous admin privileges.
I have tried laying down a new slave.jar that didn’t help.
We are using a LDAP Bind account, is there an easy fix to this 403 issue without having to enter the bind password again (which we recently did after the Jenkins upgrade)
Nothing like an answer 1.5 years later but I just ran across this!
The way I handled this is with the Role-Based Strategy plugin.
Summary
The basics are:
Add and enable the Role-Based Strategy plugin
Create a global group swarmclient
Grant the swarmclient group the slave privileges only
I currently allow the Anonymous group to be in the swarmclient group.
In the future I will probably deny swarmclient privileges for the Anonymous group and will instead create accounts in the swarmclient group.
Details
In Manage Jenkins > Configure Global Security > Authorization, enable Role-Based strategy.
In Manage Jenkins > Manage Roles > Manage and Define Roles I added "swarmclient" to the global roles. Give this group Create permissions in the slave section of the global settings:
In newer versions of Jenkins the term "Slave" is replaced by "Agents"
Then in Manage Jenkins > Manage Roles > Assign Roles you add the Anonymous group to the swarmclient group:
And finally, as mentioned above, if you want some restrictions on the machines that can connect as a swarm client, just:
create user(s) for the swarm
add them to the swarmclient group
remove swarmclient permissions (on the Assign Roles) page from the Anonymous group.
Related
We have an Azure Devops Project with several repositories.
However we only want to give access to a couple of repos to another team.
I've setup a group called Outsource (oddly it doesn't show under Project Settings > General > Teams) and within the Project Settings > Repos > Repositories section i've given the group permissions.
However they can't access theses repos from My Org > Repos (red icon).
Also they can't clone the repos either.
The one user in the 'Outsource' group is setup as a basic user.
Can anyone tell if I'm missing a setting? It doesn't seem like providing permission against a repo does anything?
I also gave them access to a different project and they can access that fine.
Stakeholder user cannot access private project repo.
The permission group Outsource is collection level group, we recommend that you open the project settings and create a project level permission group and add these users.
Configure permission
Open project settings-> Repositories->click one repo-> select the repositories which you want to give access to another team->add the permission group and set the permission Read to Allow. Then the group users can access these repositories.
Select the repositories which you do not want to give access to another team->add the permission group and set the permission Read to Deny. Then the group users cannot access these repositories.
I am attempting to use dcpromo on a Windows 2008 R2 server. The command produces a warning and an error in the event log. Below are the print outs of those entries:
-Warning-
Ownership of the following FSMO role is set to a server which is deleted or does not exist.
Operations which require contacting a FSMO operation master will fail until this condition is corrected.
FSMO Role: CN=Infrastructure,DC=DomainDnsZones,DC=XXX,DC=XXXX
FSMO Server DN: CN=NTDS Settings\0ADEL:xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx,CN=XXX-PDC01\0ADEL:xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=XXX,DC=XXXX
User Action:
Determine which server should hold the role in question.
Configuration view may be out of date. If the server in question has been promoted recently, verify that the Configuration partition has replicated from the new server recently. If the server in question has been demoted recently and the role transferred, verify that this server has replicated the partition (containing the latest role ownership) lately.
Determine whether the role is set properly on the FSMO role holder server. If the role is not set, utilize NTDSUTIL.EXE to transfer or seize the role. This may be done using the steps provided in KB articles 255504 and 324801 on http://support.microsoft.com.
Verify that replication of the FSMO partition between the FSMO role holder server and this server is occurring successfully.
The following operations may be impacted:
Schema: You will no longer be able to modify the schema for this forest.
Domain Naming: You will no longer be able to add or remove domains from this forest.
PDC: You will no longer be able to perform primary domain controller operations, such as Group Policy updates and password resets for non-Active Directory Domain Services accounts.
RID: You will not be able to allocation new security identifiers for new user accounts, computer accounts or security groups.
Infrastructure: Cross-domain name references, such as universal group memberships, will not be updated properly if their target object is moved or renamed.
-Error-
The operations master roles held by this directory server could not transfer to the following remote directory server.
Remote directory server:
\XXX-AWSDC2.CSI.local
This is preventing removal of this directory server.
User Action
Investigate why the remote directory server might be unable to accept the operations master roles, or manually transfer all the roles that are held by this directory server to the remote directory server. Then, try to remove this directory server again.
Additional Data
Error value:
5005 The directory service is missing mandatory configuration information, and is unable to determine the ownership of floating single-master operation roles.
Extended error value:
0
Internal ID:
52498782
The following roles have been successfully transferred to the XXX-awsdc2 server
Schema master
Domain naming master
PDC
RID pool manager
Infrastructure master
How do I remove the CN=CSI-PDC01 object using ADSI? It looks like the XXX-PDC01 held the FSMO Server role at one point and then was removed from the domain with out being demoted properly. I've been unable to find any reference to the XXX-PDC01 server anywhere in the DNS, AD or ADSI.
I've also attempted to delete all the AD metadata. As a last resort, I could always use the dcpromo /forceremoval command but I'd prefer to work through the error and demote this domain controller using the dcpromo command without the forceremoval flag.
Thanks!
What are the roles required for the following
Start/Stop the VM
Connect to VM using Remote Desktop.I tried connecting with the IP the owner provided but i cannot connect.I have also tried viewing the Public IP but can't see anything in the Public IP field nor there i can see details under networking tab.
1: You could use the builtin role: VM Contributor, or if you want to scope it down even farther by making a custom role. *
2: There can be multiple reasons: Firewall blocks you, there is no public IP attached to the NIC, or perhaps the permissions are incorrect. So for your permissions you might need to be added as contributor (default role) on the resource group, or it can even be scoped down to just contirbutor on the VM itself.
In custom roles you can add as many resource provider operations as you want. These operations will define your permissions on the resources in Azure: https://learn.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations
Have a look at for example: Microsoft.Compute/virtualMachines
You will see many operations, including PowerOff/action
usually people tend to use the default roles, but I prefer making custom role templates to prevent possible security concerns.
I have a problem when i try to configure the agent on another server.
I have installed the Server RM in one machine and i use the user with name: usr_deploy.
(This machine has an domain called: mydomain.local)
I have another server that i need map to submit files for deploy. What i do? I installed the Agent RM, using the same account and password, but when i try to configure i have the error:
(This machine has an domain called: anotherdomain.local)
(Because i´m a new user i cant post image. I found the same image in Url: http://i.stack.imgur.com/vrkpQ.jpg)
All users i used with the name usr_deploy have local account on each server.
I need to use the same account but all the accounts needs to be a domain account ?
I have very difficultily to find on the web articles or steps to make the correctly configuration.
My scenario is 1 server with the RM Server and 3 servers to make a deploy.
Anyone can help me ?
Tks!
If you don't have a trust relationship between your domains, you'll have to use shadow accounts.
MSDN:
Follow these steps to configure the Release Management Server and the
Deployment Agent on machines that run in different domains that do not
have a two-way trust relationship.
On each computer where you will install the RM Server or Deployment Agent, create a local user account that is a member of the
Administrators group. Use the same account and password on each
machine (i.e. Shadow Account).
Add the RM Server’s Shadow Account to RM and grant both “Service User” and “Release Manager” permissions.
Add the Deployment Agent’s Shadow Account to RM and grant “Service User” permission.
Use the Shadow Account as the service account when you install and configure the Deployment Agent.
Note: When you add the local accounts to Release Management, include
the name of the local machine where the account resides. For example,
add the user account as \ or
When you are configuring the shadow account as the service account in deployment agent, make sure that you logged in using the same shadow account.
write it down as
Correct way:- http://(server):(port)
Incorrect way:- http://(server):(port)/ReleaseManagement
Do not write "/ReleaseManagement/" or any other URL segments after . This will solve your problem.
for e.g. :
http://sunnyserver:1000
I’m trying to use web deploy to deploy my dacpac package, which comes to executing some sql scripts.
I have local windows account called .\DeploymentService, which is in local Administrators group, which I want to own the database and execute scripts.
For that - I configure delegation accordingly - In Management Service Delegation I set "Specific User" for dbDacFx rule = .\DeploymentService providing password
I create according serveradmin login in SQL Server. My WMSvc executed under LOCAL SERVICE account.
I use the following command line parameters for deployment:
msdeploy.exe
-verb:sync
-source:dbDacFx="C:\Main\Src\Community.DB\bin\Debug\Community.DB.dacpac"
-dest:dbDacFx="Data Source=.;Database=CommunityInt; Integrated Security=true",computername=”https://Community02:8172/msdeploy.axd?site=Default
Web Site”,username=.\DeploymentService,password=*************,authType=basic
-allowuntrusted
I execute it on my PC, where destination is different PC.
However this fails with error “Invalid Handle” or “Class name not found” depending on do I have “Local service” login with public role in my SQL Server created.
Expected behavior:
When I set user name in Management Service Delegation to specific account, I expect MSDeploy to be executed under the account I specified.
Actual behavior:
I traced using SQL profiler in target environment and I found out that WMSvc executes msdeploy under its process account (LOCAL SERVICE) instead of .\DeploymentService, and that’s why script execution fails. If in SQL server I have LOCAL SERVICE account mapped to serveradmin role, then it works fine. If I execute WMSvc under .\DeploymentService account, it also works fine.
So basically there is NO WAY TO USE "User Name" in Management Service Delegation - It just does not matter what you set up there - it gives no effect.
Does any one know how to make that work?
Keywords: WebDeploy, WMSvc, dbDacFx, Impersonation, Delegation
Hey guys I'm sorry to hear that you are running into this issue. I wanted to let you know that we have a bug in the dbDacFx provider/MSDeploy which is preventing SQL Auth to work when used with the dbDacFx provider in WMSvc scenarios.
We have not yet received enough feedback regarding this to warrant servicing MSDeploy in order to unblock this. If you are impacted by this the best thing to do is to create an entry at http://aspnet.uservoice.com and vote it up. If we get enough votes then we can consider shipping an update to unblock this. Sorry for the bad news.