I have configured RTC with LDAP OpenDJ.
Now I am trying to import users but it is not giving any user list after search with * i.e. for all users.
However I am able to login to RTC using LDAP user itself.
I have given below filters in WAS LDAP user registry settings:
User filter: (&(uid=%v)(objectclass=inetOrgPerson))
Group filter:(&(cn=%v)(|(objectclass=groupOfNames)(objectclass=posixGroup)))
User ID map: *:cn
Group ID map: *:cn
Group member ID map:
ibm-allGroups:member;ibm-allGroups:uniqueMember
With Base DN cn=JazzGroups,sc=ibm,dc=rtc,dc=com
Mapping in ccm_war,jts_war and rm_war is done,
I am able to map groups, users.
Is there any problem with OpenDJ?
Please help out in importing users.
I'm sorry I have no experience with RTC (not even sure what it stands out for) but OpenDJ is fully compliant with LDAPv3 and thus should work nicely with any client that has proper support of LDAP.
You might not be able to import users due to missing schema, lack of permissions for the user, or trying to add users with an already hashed password...
Please check OpenDJ access logs for details of failures. Usually the message in case of an error is pretty explicit.
I am able to import users now :-
I corrected few advanced properties Base DN, find user, etc in RTC admin GUI.
BTW thanks for your comment Ludovic Poitou.
Related
So I have the users in a table and I know my login system works because I use it for other workspaces. However across all the applications in this particular workspace I am having an error where users roles are not being recognized in particular I can't even get the admin page to work for me and I am a developer. If anyone has any clue on how to fix this it would be greatly appreciated.
If that first image is the default Admin pages, then wouldn't that mean you have access since you can see that page?
(which by default, if you let APEX create it for you through New Page > Features > Access Control) has Administration Rights set as the Authorization scheme
You have two places to check to find the issue:
Shared Components > Security > Authorization Scheme
Go to or Click your Administation Rights, under Authorization Scheme, you need to make sure you are using Is in Role or Group IF that is the requirement and you are to use the created roles. Make sure the role, Administrator (if default roles exist) is listed.
if validation is once per session, and you're still in the same session. log out and log back in. The problem should go away
Shared Components > Security > Application Access Control
Check under Role Assignments if your username is there.
Click Administrator under Roles, and make sure Administration Rights under Associated Authorization Schemes has the Is in Role or Group as the scheme type
If there is a different Authorization scheme (not Is in Role or Group) or you have different roles, then I would suggest post a new question with more details on your setup.
I installed a vault and configured OIDC with gsuite, that was already an adventure in itself as the documentation is limited and even wrong at more than one place.
Finally I have a working authentication with my google accounts and I began to create roles, and there I saw a huge issue. How do you restrict google users from using a role. Let's say I create a gsuite-admin role that has access to all of vault administration, any user entering the role before login can assume it.
I tried to use the different claims but those seems to be only for vault created groups or other things.
Does anyone has a solution for that?
Thank you in advance.
EDIT:
The configuration I'm using whith group claims:
{
“allowed_redirect_uris”: “https://URL/ui/vault/auth/oidc/oidc/callback,http://localhost:8250/oidc/callback”,
“user_claim”: “sub”,
“policies”: “vault_admin”,
“ttl”: “24h”,
“groups_claim”: “devops”,
“oidc_scopes”: “profile”,
“bound_claims”: {
“group”: [“devops”]
}
}
That configuration only provides a lock of the role that can't be used anymore by anyone. From what I could see the JWT doesn't have any informations and that is why we used the config with the fetchgroup option in the oidc configuration.
I found a solution for this problem. Firstly, we need to ensure that a user is part of a G Suite group. Then mapping the G Suite group with Vault group (that has a policy assigned) ensures that the user is bound to the Vault policy.
This article contains some example steps and might be helpful.
I want to auto-assign a few of the Projects to the user who is logging in using the LDAP credentials. Currently, if LDAP user logs in, I have to go in Report Portal using super admin credentials and assign Member Role and Projects to that specific member.
I have recently tried this LDAP feature and facing this issue of the new user gets creating and assigning projects and members to each one of them. I wan some auto-assignment (like can we passed while setting LDAP setting in Report Portal)
Below is my LDAP user nperiwal with which I logged in Report Portal. But as you see this got created a new user and no project got assigned to it automatically. I want some process or code or settings which can fulfil my requirement.
FYI, see the below snapshot where I manually assigned projects and admin role.
Please help.
Simple way:
It can be done via scripting, see which requests are send to server in browser Network tab and put the same into the bash/shell script. Parametrize according to username and required access.
Long way: wait until our team will implement it within ReportPortal as feature, based on regular priority
Best way: request payed support from our team, and we will implement this capabilities for your company with highest priority. Drop mail at support#reportportal.io
I guess this question basically boils down to some misunderstanding that I have about how the SonarQube LDAP plugin works in general. We have integrated the LDAP plugin and our users are authenticating against our corporate LDAP server. When we we want to create a new group and add users to that group for a new project, we have assumed that the users themselves must authenticate into SonarQube first so they get added as a user to SonarQube. After that, then we are able to put them into the appropriate groups that they belong to. This is a pain for our administrators since the people that need to be added are logging in at differing times or forgetting to log in at all. What we would like is something that Nexus provides where we can do a lookup of that user's account id, then add them and place them into the appropriate group(s). In that way, the user is not bothered by having to login first and then the administrator has to give the privileges and then the user logs out and logs back in. Is this a misunderstanding on my part? I ask because when I go to the users page and click on 'Create New User' it not only asks for the user's id but also the user's password which I obviously don't know so this is telling me that this will be a local account.
By default SonarQube's LDAP plugin works like you think it does. You can configure LDAP group mapping so that when the user enrolls, he/she is automatically added to the appropriate group.
In other words, create the group for the project in SonarQube, and then create the same group in LDAP and add users to it. Then when users login for the first time they will be in the appropriate group, and on each subsequent login any group changes will be reflected in SonarQube.
This, in my opinion, is infact better than adding users manually.
I don't want to import the groups from LDAP into Jira, while importing the users from LDAP in Jira.
I am not familiar to LDAP, but I want to import only users in Jira.
Is there anything that can be done at Jira level to restrict importing groups?
If you fill out your directory settings with the correct, but set the 'Group Object Filter" to an LDAP filter that will match nothing, you will not import any groups.
An example of a globally non-matching LDAP filter would be (1=2)
If you are using this technique, the other group LDAP settings become redundant, so you can set them as you please.
I don't know that there is a way to tell LDAP not to return the groups (in JIRA or otherwise), but you can tell JIRA not to use the groups to create JIRA groups. In my experience, JIRA will not automatically create JIRA groups to match LDAP groups if you use the setting "Read Only, with Local Groups".
I can't test that right now, I don't have my test server running. But I think that is the way it works. So if that is what you are trying to accomplish, then that should work for you.
You can specify what you want out of LDAP with extreme precision, certainly including whether you get users, groups, organizations, etc. Look up the LDAP search filter syntax. You will also need to know which LDAP schema is in use at the server, at least for users.