We use Jenkins with LDAP authentication. My question: is it possible to implement this rights scenario?
if not logged-in (anonymous) ==> read all
if logged in (via LDAP) but not a "special" user ==> full access to specified jobs only
if logged in (via LDAP) and also a "special" user ==> full admin access
My goal is to avoid having to manage large numbers of users explicitly.
There's a plugin "Role Strategy Plugin" that supports permissions for specified jobs, but it doesn't distinguish between anonymous and logged-in (via LDAP) users. It seems that the only way to grant access to specified jobs is to grant it user by user...which I want to avoid.
Can you use Active Directory? If so:
you can use groups for authentication, and therefore assign rights to the entire group.
you can use a project-based matrix, so specified jobs will only be visible to specific groups
If you cannot (only LDAP):
I think you can still do the above, but I think your LDAP configuration will require more work for groups. I am not sure of group support in the Jenkins LDAP API.
Related
Actually the authentication into our Jenkins is done through LDAP.
Some people in my team are not member of the LDAP.
Is there a way to use both LDAP and Jenkins user database?
This is not possible as described. The feature request is JENKINS-15063.
However, it is possible to approximate in a few ways (though the Jenkins user database still won't be usable).
For multiple LDAP realms you can set up a single proxy server that combines the forests.
Using PAM you can define multiple authentication sources and fallbacks in e.g. /etc/pam.d/jenkins
Yes that's possible and requires 2 steps:
Add a userNavigate to Jenkins -> Manage Jenkins -> Configure Global Security.
Under Authorization you need to configure who can do what. You can add LDAP groups and/or users and fine tune what they are allowed to do.
If you enabled Matrix-based or Project/Matrix-based authorization then you have a field to add new users/groups. You can add users that are known to LDAP or not known.
Add Credentials
If you added a user that is not known to LDAP you need to create the credentials in Jenkins (i.e. password).
Navigate to Jenkins -> Credentials -> System -> Global Credentials -> Add Credentials
Then add username and password.
Is it possible to grant access to individual users admin access to opscenter using LDAP (AD authentication) instead of a group.
If yes how can configure it ?? I am using Opscenter 5.2.4
When an LDAP user has been assigned LDAP roles, exactly one of those roles must also exist in OpsCenter, otherwise the user cannot log in to OpsCenter.
From http://docs.datastax.com/en/latest-opscenter/opsc/configure/createRoleForLDAPUser.html
Also see http://docs.datastax.com/en/latest-opscenter/opsc/configure/secOpscLdapOverview.html for general LDAP setup and troubleshooting.
I am trying to protect a Java servlet with OpenAM + J2EE tomcat agent. I got this part working by using embedded OpenDJ of OpenAM.
Now I am trying to authenticate against a LDAP server, so I added a LDAP module instance for OpenAM, but I get "User has no profile in this organization" when I am trying use uid/password of an user from that LDAP store.
I checked OpenAM administration guide on this the description is rather brief. I am wondering if it is even possible to do this without using the data store configured for OpenAM?
The login process in OpenAM is made of two stages:
Verifying credentials based on the authentication chain and individual authentication module configurations
User profile lookup
By configuring the LDAP authentication module you took care of the authentication part, however the profile lookup fails as you haven't configured the user data store (see data stores tab). Having a configured data store allows you to potentially expose additional user details across your deployment (e.g. include user attributes in SAML assertions or map them to HTTP headers with the agent), so in most of the scenarios having a data store configured is necessary.
In case you still don't want to configure a data store, then you can prevent the user profile lookup failure by going to Access Control -> <realm> -> Authentication -> All Core Settings -> User Profile Mode and set it to Ignore.
This is unrelated to authentication but it's related to authorization ... you have to configure appropriate policies ... see OpenAM docs.
Agents will enforce authorization, OpenAM determines if the user has the permission to access a protected resource.
As Bernhard has indicated authentication is only part of the process of granting access to a user. He is referring to using a Policy to control access.
Another method is to check if the authenticated user is a member of the desired group programmatically. This can be useful when you want access control over resources that OpenAM doesn't know about (e.g. specific data).
For example, lets say that you want different groups to have access to different rows in a table in a database. You can retrieve the group information associated with the user and add that to your database query, thus restricting the data returned.
I'm sure that you could do this with OpenAM as well using custom modules to allow the policy to use information in the database as resource, but I've found it is much simpler to perform this fine grained access control in your code, and is in all likelihood significantly faster.
I'm working with LDAP (ApacheDS) in Java, I was wondering if it's possible to impersonate a user using the system account.
More specifically, I have different groups in LDAP directory, and I need to allow users to modify entries under a group, but only the group this particular user belongs to. For example, if there is a following group:
o=acme
And an administrator of that group:
cn=admin,o=acme
I want to impersonate the admin user using the system account credentials, and allow them to only make changes in acme group.
I will elaborate since the above is not clear enough:
Lets say user A logs in. He is an administrator of ou=Group A. If, some time after logging in, he performs an action that require a connection to LDAP, it means that his credentials should be stored in session to allow him to connect. I want to avoid that, and impersonate user A using the system/some other admin account without needing user A password.
Thank you in advance.
Why? Just create your own admin-app account for use by the application, with the same privileges as the user admin account. Don't use the system account, that's for use by LDAP itself.
I would like to create a user similar to admin, but with restricted privs. The user would be able to create/read/delete objects under a certain DN in the directory, but not others.
Typically, the native server providing the LDAP service has an ACL model.
Within that system, you can create users with appropriate trustee rights/ACLs.
For example, in eDirectory, you would grant this new user object BCRDI rights to the container of interest, then have your LDAP app authenticate as that user.
In Active Directory you can do the same thing.
In Open LDAP you can do the same thing.
The specific details depend on the server providing the LDAP service. (I like others, hate saying LDAP server, since really they are not LDAP servers. They are offering an LDAP service on top of whatever database they store objects in.)