We have Jenkins installed and I'm wondering how to add an existing user to a Jenkins group.
I find how-to's for the case where in Configure Global Security the Security Realm is set to Jenkins' own user database. We have set this to Active Directory - but maybe this doesn't make a real difference to the problem.
In section Authorization we have set Matrix-based security and there are already four groups defined from a previous user, those groups have some custom rights set, and a bunch of AD users were added to those group somehow.
My problem: if I try to add a new user, I can add it to the matrix and give him the rights, but I don't see how to simply add the user to the group. I don't want a huge list of users who all have the same rights - I just want them bundled each into one of the four groups. But how can I add a user to a group? It was possible somehow before, as there are obviously users added to those groups.
Maybe a plugin was uninstalled by accident and is missing for this purpose? But I guess that in that case the Matrix-based security wouldn't even be displayed anymore!?
Any help? Thanks.
In this specific case the groups are AD groups and the users are added to those groups in the AD, not in Jenkins. So, if you have set the Security Realm to Active Directory you must add users to groups on the active directory level - not within Jenkins.
Related
My existing LDAP is being de-commissioned, and AD will take its place, please let me know how would the jenkins user groups be effected. I know this is a dry question, but I dont know how to proceed.
How do I copy the existing LDAP user groups to AD.....is there a way of doing it?
It's a question you should ask your IT Department. Ask them when the migration of LDAP groups to AD groups will be done.
If they are not planning to do so, ask them how to create new groups.
On jenkins side, you will need to configure the active directory plugin with the information your IT Department will share with you. Finally, you might need to delete the groups and enter them back in jenkins user permission page, apart from that there is no real difference between AD and LDAP groups on a jenkins admin point of view
I have been converting access to Team projects using Active Directory groups.
I am a project collection admin and we host around 40 odd team projects.
On all the other proects everything is fine, I have been able to add all the AD groups I needed to the Various TFS groups that exist in a Team Project (Contributors, Readers etc).
When I come to the problem project I can see the add button, and I am able to search for and select the AD group I want, but when I click save, I see a red banner message with the text:
Unable to add members to this group.
Failed to resolve the specified groups to join.
You do not have sufficient permissions to add members to the following groups:
[Team Project]\Build Administrators
I have looked at the oi and all I can see around the time of the issue are activities reporting a 200 response.
I am looking at the api and the database to see what I can do but not sure where to start. I thought I might be able to see something about security but it is asking for a guid that I am not sure how to get hold of.
Looking at the database I thought there might be a security table, but not sure where to start.
I'm going to keep looking at what to do, so I am going to keep this updated
update 2019-03-27
We have a support call open with Microsoft, I still have issues managing the teams, but I have been able to update the team via the Apis, I even found a useful little CLI tool to help with the tasks I needed to do.
In my case, I was trying to add someone to a group that I was in - which I don't need since I'm a Project Administrator. Once I took myself out of the group, I was able to add others again.
Got the answer and the fix worked.
After a lot of back and forth, sending files and running some tfssecurity queries, they were able to determine the problem.
What I had done was add the domain User AD containing our project collection admin account in as a project reader, as the security on tfs works on a least level principle it was then applying a deny permision on my Project collection admin account, by simply removing the AD group from the reader level, which I was able to do, the ablity to manage the securities came back.
I havent been able to find the specific group that I belonged to that then set the deny, but there is no denying that removing the AD group from the reader level fixed the issue.
Anyone know how to remove users in PlasticSCM when the server is configured to use Active Directory security?
The cm au/du commands are meant to activate or deactivate users.
But users are not 'added' to Plastic as such.
When a user does an operation in Plastic, it will be automatically added provided you have enough licences and the user has permissions to access the system (you've set the correct ACLs).
Suppose you just have a 20 users license:
You simply install the license (copy the plasticd.lic file)
Then the first user access the system, it will be 'activated'
Second user accesss, second 'activation', it happens automatically
Then suppose you already have 20 developers using Plastic and one of them leaves and a new one enters, then you have to deactivate the old one and activate the new one, but only then.
Hope it helps.
I am having a little difficulty understanding when a person should configure JIRA permissions using groups and when they should use project roles. I have read the online documentation, however, the difference between the two seems subtle.
A group seems simple enough. Group users into a named bucket. Assign the group to one or more permissions within a permission scheme to enable access to functionality for any users within the group. Assign the permission scheme to a project to apply the permissions to that project.
A project role seems very similar. It does all of the above except that you can also add groups to project roles. It seems that a project role also allows a project administrator to add their own users to a project instead of requiring a system administrator.
However, I am not sure how I can leverage this. Here is an example of what I want to achieve.
Have multiple projects created in JIRA.
All of our managers, developers, etc. have the same permissions across all projects.
Our clients have access only to their projects.
I think that the best way to accomplish this is to:
Create an employees group to which I add all of our employees.
Create one or more project roles to which I add the appropriate clients.
Assign permissions to the Default Permissions Scheme using the employees group.
Copy the Default Permission Scheme to a new project specific scheme, e.g., client-scheme
Assign the client-scheme to the client specific project.
However, it seems that I am not leveraging project role membership. How does this come into play?
What is the best practice for using JIRA groups and project roles? What is the different between the two?
We are advising to work with roles as it has a couple of advantages
a. You can setup the complete configuration based on roles.
For instance you might have a workflow transition 'validated' which can only be executed by someone who is a tester.
You have the choice to add a transition condition 'user is in group tester' or 'user has the role tester'.
If you are working in an organisation where users have different roles in different projects, choosing the first transition condition (user is in group tester) will not work (or you would need a new workflow for each project)
The same applies for notifications.
You can configure a notification on the 'issue resolved' event, specifying that the 'users in group tester' get notified or 'users who have the role tester'.
When using roles, adding someone to a project is very simple - just check what role the person has in the project, add them in the project configuration (view members) and you are done. He will have the right permissions, get the right notifications ...
b. Configuration
When you use roles for configuration, you don't need system administration rights to add someone to a project. The project lead will be able to add the user. No need to bother the system admin.
Looking at your description, I would have
A project role 'employee'
A project role 'customer'
A group 'employees'
configure the project role such that the group employees is a default member of the project role employee
This way you can use the same permission scheme for all projects. When adding a new project, you just need to add the client specific userid to the client role.
When a new employee start, you add him to the employees group.
The day that you have a specific, ultra secret project, where only a couple of employees need to have access, you can remove the group 'employees' from the role 'employee' and add the specific users to the role.
Hope this helps
Francis
Historically, JIRA had groups first. Then roles came along and are the recommended way to control authorization in most cases.
~Matt
Groups are global. Roles can be thought of as per-project (local) groups.
Roles are much better: else with a large number of projects you quickly end up with a proliferation of Groups and permission schemes (one per project).
You lose nothing by using role-based permission schemes, since you can add a Group to a role.
But you gain a lot of flexibility. Eg you'd currently have the Employee role be filled with your Employees group for every project, but as your company and complexity grows, you can have different Employees per project, without having to change the permission schemes
I am using symfony 1.31 with propel ORM and sfGuardPlugin
I am about to setup groups and permissions. AFAIK, permissions map unto Credentials, and permissions can be assigned to groups.
I have two questions
Suppose a user belongs to group A, and group A has credentials 'foobar'. When a user that belongs to group A logs in, does he 'automagically' get assigned credential 'foobar', or do I have to manually, add the credential to the user (by say looking up its group->permissions in the db) ?
Assuming the SF framework 'automagically' takes care of user credential depending on group membership, is the effect real time, or does a user have to logout/login before the changes are applied/in effect?
[Edit]
Regarding question 1, I would be grateful for a link to (preferrably the SF official documentation - failing that, any other doc), that states that this is indeed the case.
Regarding question 2, the sfSecurityUser has addCredentials method that stores credentials in the user session. Consequently, I suspect that any group membership changes are NOT real time, so I will either have to force use to logout/login or maybe use an event listener or something.. am I right (or wrong)?
EDIT:
sfGuard Plugin Page with HTML version of Readme
sfGuard Readme (txt) (should be included in your plugins installation dir)
If you set up sfGuard right then the crednetials will be automagic. In particular this requires you apps/$appname/lib/$userClass.class.php (typically MyUser.class.php) to extend sfGuardSecurityUser. Setting this up should be in the plugin readme.
As far as 2 goes, since the credentials have to be queried each request then it would happen immediately from the users perspective (unless of course youre using ajax to add a perm/crednetial).