SonarQube LDAP configuration & empty bindDN - ldap

My predecessor installed LDAP plug-in for SonarQube and added below configuration in sonar.properties file.
sonar.security.realm: LDAP
sonar.authenticator.createUsers: true
ldap.url: ldap://ldap.company.com:<port>
ldap.user.baseDn: DC=company,DC=com
ldap.bindDn:
ldap.bindPassword:
ldap.user.request: (&(objectClass=user)(memberof=CN=gpnet,OU=Groups,DC=company,DC=com)(SAMAccountName={0}))
He conifgured empty bindDN/bindPassword and when i looked at LDAP documentation in SonarQube under general configuration, it says
"Leave this blank for anonymous access to the LDAP directory."
What it means?
Any user who is part of ldap.url will be able to login? but as he/she is not part of gpnet group, so will not be able to login ?
As per my understanding, we should have service account credentials and set it in bindDN and bindPassword configuration.

It depends on other things in the configuration. It's possible to configure OpenLDAP to allow searches from an anonymous bind, which fits the usual pattern of searching for the use by some criterion such as email address, then attempting to bind as that user with his password as the actual login step.

Related

Keycloak - Issues syncing users with LDAP

I installed Openldap in server and after that added the user into the ldap,below screen show show the added user through Apache Active Directory
Now in keycloak i added user federation as a openLdap and its connecting to ldap without any issue,but when i am trying to sync the user i am getting message
Success! Sync of users finished successfully. 0 imported users, 0
updated users
So no user import from ldap to keycloak ,below is the related ldap connection information in keycloak .
Thanks to #EricLavault and one of company colleague at last Keycloak able to import the user successfully. Below changes i have done to fix the issue.
Change the User Object Classes=*
Created a new entry ou=People then created user under it
In Keycloak used Users DN = ou=user,ou=people,dc=suredev20
After this its start throwing below exception
ERROR [org.keycloak.storage.ldap.LDAPStorageProviderFactory] (default
task-1931) Failed during import user from LDAP:
org.keycloak.models.ModelException: User returned from LDAP has null
username! Check configuration of your LDAP mappings. Mapped username
LDAP attribute: uid, user DN:
cn=subodh123,ou=user,ou=People,dc=suredev20, attributes from LDAP:
{sn=[joshi123], cn=[subodh123], createTimestamp=[20191118180647Z],
modifyTimestamp=[20191118180647Z]}
Which is fixed by using Username LDAP attribute = cn as ldap username Attribute description in openldap case bydefault cn
User entries are not stored correctly in your directory. In fact you shouldn't use cn=root as a container as it's supposed to represent the directory manager and should be used for binding and other operations but not for structuring your directory.
Instead, you should use the default user container (at least for OpenLDAP and Apache DS) that is ou=people,dc=suredev20, ie. you need to move cn=subodh
from cn=subodh,ou=user,cn=root,dc=suredev
to cn=subodh,ou=people,dc=suredev20
Also, in Keycloack you need to set users dn accordingly : ou=people,dc=suredev20
(you can try with ou=user,cn=root,dc=suredev without moving subodh entry but not recommended).

ldap filter in omniauth ldap module not working in discourse

I currently try to configure Discourse to only allow users in a specific ldap group to log in. Discourse has a plugin called discourse-ldap auth ( https://github.com/jonmbake/discourse-ldap-auth ). This plugin uses the omniauth ldap module: https://github.com/omniauth/omniauth-ldap
My discourse plugin configuration (the configuration is actually used by the discourse plugin for the omniauth ldap module):
ldap enabled: true
ldap hostname: the hostname of my ldap server
ldap port: 389
ldap method: plain
ldap base: the base of my ldap server
ldap uid: userPrincipalName
ldap bind dn: Nothing
ldap password: Nothing
ldap filter: (&(userPrincipalName=%{username})(memberOf=cn=[the name of the required group],ou=....,[base]))
When using this configuration, nobody can log in to the forum. When I use the bind dn and password, everybody can log in.
I also tried this filter without success (copied from my ldap servers filter):
(&(&(&(userPrincipalName=%{username})(memberOf=[dn of the group]))))
What do I have to configure, to only allow users in that specific group to log in?
I didn't found any errors or indicators in the log. Please help!
Thanks fou your help and attention!
You do need the "ldap dn" and "ldap password". Those are the credentials used to authenticate to LDAP so you can lookup people's accounts. Usually, that is a service account only used by your application.
The filter should probably look something like this:
(&(sAMAccountName=%{username})(memberOf:1.2.840.113556.1.4.1941:=[dn of the group]))
Users will usually log in with the sAMAccountName, which is usually called just the "username". Whenever you see an account in the DOMAIN\username format, that username is the sAMAccountName.
The userPrincipalName is usually in the format of username#domain.com. It is sometimes the same as the email address, but it doesn't have to be.
The crazy number I put in that query tells Active Directory to search recursively through groups. So that would allow you to put groups into your authentication group, and members of that new group would be given access to your application too. Without that, only direct members of that group will have access.

Airflow LDAP superuser authentication

I am using Airflow v1.9.0 and am trying to setup groups using LDAP authentication.
I can get the basic LDAP authentication working that defaults all users to be superusers. However, I cannot get the AD to match against a specific group. For instance, I have user TommyLeeJones who I know is part of the user group MIB, but I can't get airflow to match this user against this group.
In my airflow.cfg file, I have set:
[webserver]
authenticate = True
auth_backend = airflow.contrib.auth.backends.ldap_auth
[ldap]
user_filter = objectClass=*
user_name_attr=sAMAccountName
In my webserver.env file, I have:
AIRFLOW__LDAP__URI=zartha.men.in.black:389
AIRFLOW__LDAP__BIND_USER=men\TommyLeeJones
AIRFLOW__LDAP__BIND_PASSWORD=APersonIsSmartPeopleAreDumb AIRFLOW__LDAP__SUPERUSER_FILTER=memberOf=CN=MIB,OU=UK,OU=Groups,DC=men,DC=in,DC=black
AIRFLOW__LDAP__DATA_PROFILER_FILTER=memberOf=CN=MIB,OU=UK,OU=Groups,DC=men,DC=in,DC=black
AIRFLOW__LDAP__BASEDN=DC=men,DC=in,DC=black
AIRFLOW__LDAP__SEARCH_SCOPE=SUBTREE
I can login, but not as a superuser which I should be able to.
When working with LDAP, I find that I'm usually misspelling my LDAP query.
Confirm that AIRFLOW__LDAP__SUPERUSER_FILTER is correct.
You can use ldap3 Python package and confirm from the command line this works.

Openldap and ActiveDirectory authentication

Is it possible to connect to an OpenLDAP server as the active directory with this form
" username#domain "
I have tested this form, it connects with active directory but with openLdap i have to put the full DN.
Does anyone has any idea how to modify my openLDAP to connect as AD if it's possible
Thanks.
If you wants to authenticate Openldap and AD users using same DN you need to add proxy to AD server from openldap server.
You need to use back_ldap module to make AD database as subordinate of Openldap database.
You can add custom attribute in openldap/ad for uniqueness of user mostly we find email attribute as common on both sides.
If you want to use alternative bind names like the userPrincipalName (username#realm) with openLDAP, you need the rewrite/remap overlay slapo-rwm coming with version 2.4.
A very simple example would be:
# Typed and not tested!
rwm-rewriteEngine on
rwm-rewriteContext addName
rwm-rewriteRule "(.*)" "userPrincipalName=$1" ":"
rwm-rewriteMap ldap upn2dn "ldap://host/dc=my,dc=org?dn?sub"
rwm-rewriteContext bindDN
rwm-rewriteRule ".*" "${upn2dn($0)}" ":#I"
EDIT
In reply to the question in your comment: LDAP as a protocol has no concept of uniqueness, it's a product feature. With OpenLDAP for example, you can use the unique overlay to enforce uniqueness for certain attribute types in suitable backends. With phpLDAPAdmin you can configure the attribute types that shall be tested for uniqueness by that client.

Not able to login into liferay portal using LDAP credentials

I have followed the steps that you have mentioned in this blog. For the base dn they have given something like 'Base DN - dc=,dc=', but I gave something like 'ecompany.local'. Since I am not the admin of the ldap, I gave the principal as the my ldap id and credentials my ldap password . When I clicked on test connection, I got the popup window that shows "Liferay has successfully connected to the LDAP server" .
Next, I followed the steps regarding Authentication Search Filter, Import search filter and User Mapping. But when I Clicked on test ldap users, popup window showed that there are no users currently(this might be because I do not have the ldap admin credentials. )
SAVED the configuration.
Went to control panel --> Authenticaion --> LDAP, checked enabled, import enabled and import on start up enabled.
Restarted the server.
Clicked on sign in. Fed in the ldap login credentials, and I am not able to login using the ldap credentials. But can login using Liferay's id and password. Why?
One thing to be sure is that the password encryption rule is setup right for your LDAP server.
In portal.properties you can read this:
#
# Set either bind or password-compare for the LDAP authentication method.
# Bind is preferred by most vendors so that you don't have to worry about
# encryption strategies.
#
ldap.auth.method=bind
#ldap.auth.method=password-compare
# Set the password encryption to use for comparing passwords during import
# and to use for encrypting passwords during export. Comparing passwords
# during import will only be used when the property "ldap.auth.method" is
# set to password-compare. If the encryption is set to NONE, which is the
# default value, passwords are considered as plain text. The SHA-512
# algorithm is currently unsupported.
#
#ldap.auth.password.encryption.algorithm=BCRYPT
#ldap.auth.password.encryption.algorithm=MD2
#ldap.auth.password.encryption.algorithm=MD5
ldap.auth.password.encryption.algorithm=NONE
#ldap.auth.password.encryption.algorithm=SHA
#ldap.auth.password.encryption.algorithm=SHA-256
#ldap.auth.password.encryption.algorithm=SHA-384
#ldap.auth.password.encryption.algorithm=SSHA
#ldap.auth.password.encryption.algorithm=UFC-CRYPT