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.
Related
RE: https://jfrog.com/knowledge-base/when-do-the-groups-associated-with-an-ldap-user-get-updated-in-artifactory/
The Knowledge Base article above says:
"LDAP user authentication requests using Encrypted password or plain text password will update the LDAP group association changes from the LDAP server."
We've added a user to a group, but that user still can't see the artifacts governed by that group even after he has logged in. How can we cause Artifactory to update its group membership cache?
Please ask the user to logout and log back in after being added to the groups. Artifactory will try to reach to the LDAP server for validating the creds and then get the groups associated with the user which is returned from the LDAP server.
There is a chance that LDAP cache as mentioned in here https://www.jfrog.com/confluence/display/JFROG/LDAP#LDAP-Non-UIAuthenticationCache might take effect the groups to be associated if the user session is not hitting the LDAP server.
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).
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.
I have set the proper LDAP configuration in Sonar 5.6.6 LTS (ldap plugin v2.2.0.608) and I see in logs that the connection is established.
When I first try to login with my LDAP-login, I am able to do so, but my user has of course no permissions - that is okay.
The problem occurs, when I want to first add my user and give him i.e. sonar-administrators group. When it is set and I try to login, Sonar authenticates me not against the external system (LDAP) but uses his own data base.
I am sure it worked with Sonar 4.5 but now I cannot configure it properly.
The problem was that creation of new users adds them by default to the local database of SonarQube. To change this default behavior I found out that the REST API endpoint to create users contains the flag 'local' which defines whether the user should be considered as a local user added to the local database or he should be added as an external user authenticated again an external system like LDAP.
So final answer is to use the following REST API endpoint:
private final String CREATE_USER_API = "/api/users/create?login={login}&name={name}&local=false"
Please note the following property: local=false at the end of the string.
I am able to authenticate radius users using radius server+pam+ssh with creating local user with blank password in linux.
Is it possible to authenticate radius users without creating users in local machine with blank password?
/etc/pam.d/ssh file as below
#%PAM-1.0
auth sufficient pam_radius_auth.so debug
auth sufficient pam_unix.so use_first_pass
auth required pam_auth_status.so
account sufficient pam_unix.so
account required pam_auth_status.so
session required pam_unix.so
You can authenticate the user without creating an entry for him in /etc/passwd and /etc/shadow files. But now , the user is not associated with any shell in '/etc/passwd' , so it can be of no use.
Do you want to launch a shell after authentication or you want the user just to be authenticated?
I found two nss libraries that could help in this case:
libnss-mapuser from Cumulus Linux.
libnss-ato
The general process is that these will map unknown (but authenticated) user to a single user template. Each user will get his/her own /home folder though but both libs have in common that the user id will be the same.
These packages are mainly targeted at network devices where there is no ldap setup done. Cumulus describes the setup nicely.
I recommend reading https://serverfault.com/questions/538383/understand-pam-and-nss to understand what is happening there.