Im trying to conect gitlab with ldap to centralize my authentication.
Im having a problem when i try to log in because gitlab blocks the users.
The base_dn where the users are is ou=People,dc=dominio,dc=com
When i try to log in all works fine until Gitlab make a sync and block the user because on the gitlab database the base_dn is saved in lowcase.
LDAP account "uid=user1,ou=people,dc=dominio,dc=com" does not exist anymore, blocking GitLab user "Usuario" (user1#dominio.com)
Gitlab is able to read all the info from the user in theLDAP and also create the user on the gitlab system(full name, email, etc).
User "Usuario" (user1#dominio.com) was created
But later block the user and im not able to log in, every time i unblock manually, the gitlab block again.
Here all the process:
User "Usuario" (user1#dominio.com) was created
(LDAP) saving user user1#dominio.com from login with admin => false, extern_uid => uid=user1,ou=people,dc=dominio,dc=com
LDAP account "uid=user1,ou=people,dc=dominio,dc=com" does not exist anymore, blocking GitLab user "Usuario" (user1#dominio.com)
When i check in the user profile they show this info:
LDAP uid: uid=user1,ou=people,dc=dominio,dc=com
In the LDAP the real path is:
uid=user1,ou=People,dc=dominio,dc=com
Some idea how i said to gitlab rescpect the upercase or not be case sensitive?
LDAP itself is case-insensitive, so in queries against LDAP it doesn't matter. GitLab tries to normalize all DNs to lowercase before comparing values on its side since GitLab itself is case-sensitive.
With that in mind, I'm not clear where you're running into problems. It sounds like it's probably a bug if it really is related to the case. It's also possible there's another issue causing the user sync to block your user(s).
If you have clear reproduction steps the best bet is probably to create an issue at https://gitlab.com/gitlab-org/gitlab-ce/issues. Tag the issue with ~ldap and ping me (#dblessing). Happy to try to reproduce.
Finally i found the solution.
the user_filter: i used have some issue, dont support omniauth-ldap's custom filter syntax.
I was using
user_filter: '(&(objectclass=*)(memberof=cn=gitlab,ou=Groups,dc=dominio,dc=com)(uid=%{username}))'
But i change for somnething simple as:
user_filter: '(memberof=cn=infra_gitlab,ou=Groups,dc=dominio,dc=com)'
And start to works...
Related
I am working for an IBM Business Partner and I am trying to complete a first PoC ICP installation. The basic installation has worked. I did not configure LDAP during the deployment but I am trying to add an LDAP connection in the console now, afterwards.
Unfortunately, I always fail. And there seem to be a number for limitations and/or bugs in the LDAP connection of ICP to the point of making it unuseable.
First, I would like to connect to an IBM Domino Directory as my LDAP server. Anyone who has worked with a Domino directory before knows that many Domino deployments have an O=Org suffix where Org is a company name containing spaces. For example, in our case it is "O=ARS GmbH". I would normally need to use this as the base DN (search base). However, ICP does not allow spaces in this field ... that need to be fixed! Any other LDAP client product I tried to connect to our Domino directory over many years was able to deal with spaces in the base DN.
Next, in a Domino directory usually the groups do have a different suffix (e.g. search base) than users. But ICP only offers ONE base DN field and not separate base DN fields for users and groups. Any other LDAP client ... DOES offer this. This needs to be fixed in ICP as well.
Next, the bind DN field does not allow some commonly used special characters which are often found in account names, such as the - character. This needs to be fixed as well (as it happens, the special user ID we have in our Domino directory which we use for LDAP binding is named dir-client ...).
Well, after hitting all those blocking problems, I finally tried to connect to our Microsoft Active Directory. This time I could successfully complete the LDAP connection. After doing so, I turned to "Users" and discovered I need to "Import group". However, no matter what I try to enter as (correct) values into the CN and OU fields, I only end up with an "internal server error".
Further more, after I could save the LDAP connection to Active Directory, I could no longer log in to the console with the builtin admin account! But since I could not import any users/groups, I could not assign that role to an LDAP account ... luckily, I had a VM snapshot of the master server and could thus revert to the state before.
This is really frustrating ...
I ran into identical issue when hooking up to an openldap server running in a docker container. It took me awhile to figure out the ICP pod and container where the log file is to get more information than "Internal Server Error".
Here is how to find the relevant ICP pod/container log:
Look for the "auth-idp" pods in the kube-system namespace. I use:
kubectl get pods --namespace=kube-system | grep auth-idp
If you are running an HA cluster, you will have a pod on each master node.
In my case I have 3 master nodes. If you are running only a single master, then you will have only one auth-idp pod.
Again, in an HA scenario, you need to figure out which is your current master node. (The easiest, crude way to do that is ssh to your master VIP and see which node you land on.)
Now figure out which pod is running on the current master node. On each pod I use:
kubectl describe pod auth-idp-vq5bl --namespace=kube-system | grep IP
or
kubectl get pod auth-idp-vq5bl --namespace=kube-system -o wide
The one on the IP that is the current master node is where the log of interest will be.
The container in the pod that has the log of interest is: platform-identity-mgmt
To actually see the log file use:
kubectl logs auth-idp-vq5bl --namespace=kube-system --container=platform-identity-mgmt
At that point you will be able to scroll through the log and see a more detailed error message.
In the case of my error the log indicated my search filter for the group was not working properly. I decided to mess with the user ID map and user filter so I used a user ID map of *:cn and a user filter of: (&(cn=%v)(objectclass=inetOrgPerson)) Once I changed those in the ICP LDAP configuration, the user import succeeded. However, later I realized the logins were not working because the login is based on a search on userid or uid. So I changed the user ID map back to *:uid and the user filter back to (&(uid=%v)(objectClass=inetOrgPerson)). That corrected the login issue. I added some users to my LDAP group and reimported the group and the import worked as well. At this point, I'm not sure what was going on with the original import not working until I messed with the user ID map and user filter. Go figure.
In my OpenLDAP directory instance my groups are all under ou=groups and each group member is listed as, e.g., cn=Peter Van Sickel,dc=ibm,dc=com. I had to edit the group member to get it using the full DN of an actual user.
My users are all directly under the root DN: dc=ibm,dc=com.
As to specific issues with other LDAPs, it is my experience that each has its own set of idiosyncrasies to get things working as desired.
I've forgotten my password for the apache of biz admin account , I've asked for an email to be sent however I don't know which account is associated with the ofbiz server so I can't view the email which changed the password , does anyone have any tips?
Thanks
if you can access database, you can make the change directly on the UserLogin table.
Otherwise if you have a remote access to the server, you can use the ant or gradle target - depending of your OFBiz revision - to create another admin acount :
gradlew loadAdminUserLogin -PuserLoginId=myadmin
or
ant create-admin-user-login
Also a possible solution in such case is to use the (eg) lmtadmin if you have access to it. This is what I do on the demo when someone screws the main admin pwd
I am unable to create project in open shift. I created a project previously and deleted it. Looks like a project exists but unable to access or delete it. Seems like i am stuck. Also logging into the console https://console.preview.openshift.com/console/ doesn't show any existing projects.
I ran the following oc commands from the terminal.
Any suggestions on how to resolve this issue?
Thanks
XX:~ XX$ oc new-project test
Error from server: projectrequests "test" is forbidden: user XX cannot create more than 1 project(s).
XX:~ XX$ oc delete project test
Error from server: User "XX" cannot delete projects in project "test"
XX:~ XX$ oc status
Error from server: User "XX" cannot get projects in project "default"
XX:~ XX$ oc get projects
You need to give privileges/policies to your user which will allow the actions you want to perform.
If you are just in a proof-of-concept environment I would recommend the make your user cluster-admin in the whole cluster. This will give all the possible privileges to your user. Of course this in't recommended for every user in a 'real' environment.
First you need to authenticate with the 'default admin' which is created after the installation. This default admin-user isn't working with the normal user/password authentication. It's using a client certificate.
oc login -u system:admin --config=/etc/origin/master/admin.kubeconfig
Now you will see a list of the available projects (default, openshift management, etc). Now you're able to give cluster-roles to other users.
Make your user cluster-admin over the whole cluster
oadm policy add-cluster-role-to-user cluster-admin (youruser)
Now you have the cluster-admin privileges inside the whole cluster. You are also able to give privileges for some user in a specific project and not in the whole cluster. Than you have to use:
oadm policy add-role-to-user <role> <username> (in the current project)
This will give the role to a user, but only inside the project from where you've performed this command.
For more information about the avaiable cluster roles and policies I will point to the official documentation.
I raised a defect with Openshift Team as pointed out in the Support Link.
https://docs.openshift.com/online/getting_started/devpreview_faq.html#devpreview-faq-support
Here is the response i received from Support Team.
It seems that you have issued a bug and followed up for this already:
https://bugzilla.redhat.com/show_bug.cgi?id=1368862
After the cause is investigated, our operations team will sure clean up the project manually for you to allow you continue working with the developer preview
Latest update:
The project has now been cleaned up and you should be able to create a new project.
I am able to create Project in Openshift now.
We want to run two Jenkins instaces on the same server.
To log in Jenkins (using version 1.595) web GUI we are using the LDAP plugin (version 1.11). "Project-based Matrix Authorization Strategy" is selected and my user is granted admin access here. So once I am able to login I have admin rights. The symbol to the left of the users added in the matirx shows a "little man" so the user seems to be found on LDAP.
CASE 1: If I type in my credentials CORRECT I get redirected
to the page that was open just before I clicked the "log in" button.
NOT good -> Without allowing anonymous user to administrate I have no chance of doing anything.
CASE 2: If I type in them WRONG Jenkins tells me "Invalid login information. Please try again."
good -> as expected.
Also tried "Anyone can do anything" as security setting. Using this I do not get redirected to the login form, but to the last visited page from where i called the "login".
It does't matter what type of Internet Explorer I use. The result is always the same (Chrome, Firefox and Internet explorer were tested).
I already discussed with the colleague responsible for the LDAP maintenance. The incoming information are handled correctly (-> LDAP settings within Jenkins must be correct). But this fact is clear since wrong login information leads to "Invalid login information page", but correct login information do not.
Also made sure that the firewall makes no problems.
Do you have any idea why this is not working? Or what the reasons could be?
Is it possible that there is kind of a "redirection link" for logins?
Hard to say from the information you've provided, but one thing to check is that the casing on your username exactly matches the name you have set up in matrix authentication. LDAP is not case sensitive but Jenkins is, which means that you can be authenticated successfully without having the administrative access you are expecting.
One way to proceed would be to add the 'authenticated' (case sensitive) user to your matrix with some limited permission set and see whether you are able to get past the login page.
I found one reason!
After deleting the environment variable JENKINS_HOME I was able to login into Jenkins... At least via localhost. Before even this login wasn't possible too. As we run two instaces of Jenkins on the same Server it seems like they want to use the variable both -> leads to failures. But if I try to login via network from another PC I still can't login (same as before). The variable JENKINS_HOME gets set (as before) within the jekins.xml in jenkins installation folder so the enironmentvariable is properbly not in need. I opend a new question, as this is now an Apache error.
I guess the reason why I can login via localhost, but not via network must be our Apache 2.2 server which is handling information wrong. By using localhost I can bypass Apache (-> works) but via network Apache gets used (-> don't work).
Link to the new question: Jenkins behind Apache Server / Can't log in Jenkins
I have uncommented the LDAP and UserMapper connectors in application.xml
I know my LDAP credentials (binddn, hostname, etc) are all working, because I use LDAP authentication and authorization for other apps on my server.
All I've done, is make the changes to application.xml and security.properties. Is there something else I'm supposed to do?
When I try to login with a user from LDAP, it is unsuccessful. Is there a log file I can check to see what's going wrong? I find the archiva documentation to be sparse and laconic.
Here is my security.properties file - some values have been altered, maybe someone can verify the structure is in-tact:
# LDAP
user.manager.impl=ldap
ldap.bind.authenticator.enabled=true
redback.default.admin=admin
security.policy.password.expiration.enabled=false
ldap.config.hostname=localhost
ldap.config.port=389
ldap.config.base.dn=domainName=mydomain.com,o=domains,dc=mydomain,dc=com
ldap.config.context.factory=com.sun.jndi.ldap.LdapCtxFactory
ldap.config.bind.dn=cn=Manager,dc=mydomain,dc=com
ldap.config.password=mypass
ldap.config.mapper.attribute.email=mail
ldap.config.mapper.attribute.fullname=displayName
ldap.config.mapper.attribute.password=userPassword
ldap.config.mapper.attribute.user.id=mail
ldap.config.mapper.attribute.user.base.dn=ou=Users
ldap.config.mapper.attribute.user.object.class=inetOrgPerson
ldap.config.mapper.attribute.user.filter=(objectclass=inetOrgPerson)
Also, the config.mapper.attribute.user.base.dn confuses me. The basedn of my users is here:
ou=Users,domainName=mydomain.com,o=domains,dc=mydomain,dc=com
So does that mean for base DN I put: domainName=scoresecret.com,o=domains,dc=scoresecret,dc=com
and for config.mapper.attribute.user.base.dn: ou=Users
Let me know if I'm doing something wrong, if I'm forgetting to do something to "switch LDAP on", and if I can find some logs to point me in the right direction. Thanks a ton
Make sure you have configured an admin user that exists in LDAP - at the moment there's no way to use an internal user for that.
redback.default.admin=admin
Replace admin with a role account in your LDAP server that can be used for this.
Here is a configuration template I use which should show the values you'd need to populate:
https://github.com/maestrodev/puppet-archiva/blob/master/templates/security.properties.erb
It seems the main difference could be the user filter being empty?
(See also thread on users#archiva.apache.org: http://s.apache.org/KDj)