I have configured LDAP server in my ubuntu 12.04 in the same server Cloudera core hadoop service installed . Here i want to integrate cloudera hue with LDAP server.
Following is my LDAP users
root#ip-10-81-160-152:/home/ubuntu# ldapsearch -x -b "dc=gmps,dc=com"
# extended LDIF
#
# LDAPv3
# base <dc=gmps,dc=com> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
# gmps.com
dn: dc=gmps,dc=com
objectClass: top
objectClass: dcObject
objectClass: organization
o: gmps
dc: gmps
# admin, gmps.com
dn: cn=admin,dc=gmps,dc=com
cn: admin
description: LDAP administrator
objectClass: simpleSecurityObject
objectClass: organizationalRole
objectClass: uidObject
uid: admin
ou: admin
# aaryan aditya, students, users, gmps.com
dn: cn=aaryan aditya,cn=students,ou=users,dc=gmps,dc=com
cn: aaryan aditya
givenName: aaryan
gidNumber: 500
homeDirectory: /home/users/aditya
sn: aditya
loginShell: /bin/sh
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: top
uidNumber: 1000
uid: aditya
i use phpldapadmin to login my LDAP server which was working fine ..
My Login DN: cn=admin,dc=gmps,dc=com
I have configured this ldap server in Hue cloudera as
ldap_url : ldap://75.101.250.10
LDAP Username Pattern : "uid=admin,ou=admin,dc=greycampus,dc=com"
user_name_attr: admin
After this i restarted HUE and i just logged into HUE web UI there if click on
Hue ---> Manage Users ---> Sync LDAP users and groups --> Sync
i am not getting any users syced from LDAP server ..
if i click Add/Sync LDAP user .. then enter username and ok .. i am getting
There was an error when communicating with LDAP
{'info': 'invalid DN', 'desc': 'Invalid DN syntax'}
i dont know where i did wrong .. and its still confusing where i have supply my LDAP password .. and how hue communicate with LDAP without password .. kindly any one please help
I can't understand neither your LDAP configuration nor your Hue configuration.
firstly you define your LDAP root, dc=gmps,dc=com, ok.
Next, you define an admin role, which is definitly not a user, just a role.
dn: cn=admin,dc=gmps,dc=com
Finally you define a user, which doesn't seem to be linked to the admin role.
If you don't have any relation defined between a user and a role, it'll be difficult for hue to grant something to your user.
Next, about yourr Hue configuration:
The user should be a parameter of the pattern.
If a user DN is dn: cn=aaryan aditya,cn=students,ou=users,dc=gmps,dc=com, your pattern should be at least something like cn=
Hue webapp substitute by the typed login and make a first request to validate the authentification of your user (aka username/password against the LDAP user information).
To perform the search, you need to define the LDAP base search (dc=gmps,dc=com) and a bind user, authorized user DN to look into your LDAP (for instance, cn=aaryan aditya,cn=students,ou=users,dc=gmps,dc=com)
If you want to limit the global access to just a portion of your LDAP, you can specify an additional filter. When you'll define a relation between users and roles, you'll can restrict the access to the users by their roles.
You have to specify what's the attribute you're considerating to identify the user (in your case, it seems to be cn, so user_name_attr = cn)
To do the mapping between LDAP and Hue permissions, you have to tell Hue which roles are considerated, throw the group_filter. Next you have to specify the attribute of the role which allow to identify the role (in your case, it seems to be cn)
Finally, you have to tell to hue which attribute allows you to link a role to a user (which doesn't seem to be undefined in your configuration)
Next, restarting your cluster, everything should be ok. Syncing your users/group will load users and roles from your LDAP to Hue, next step will be configure each role in HUE to give it the expected permissions.
Related
I am trying to integrate LDAP authentication to rundeck.
I can query the users using ldapsearch successfully like below
ldapsearch -v -x -D "some_address#myorg.lan" -b "dc=myorg,dc=lan" -H ldap://ldaphost.myorg.lan -w **** "uid=user_1"
which returns:
ldap_initialize( ldap://ldaphost.myorg.lan:389/??base )
filter: uid=user_1
requesting: All userApplication attributes
# extended LDIF
#
# LDAPv3
# base <dc=myorg,dc=lan> with scope subtree
# filter: uid=user_1
# requesting: ALL
#
# user_1#myorg.lan, Users, myorg, Zones, Circular, warehouse, myorg
.lan
dn: CN=user_1#myorg.lan,CN=Users,CN=myorg,CN=Zones,OU=Circular,OU=warehouse,DC=myorg,DC=lan
objectClass: top
objectClass: posixAccount
objectClass: leaf
objectClass: connectionPoint
objectClass: serviceConnectionPoint
cn: user_1#myorg.lan
distinguishedName: CN=user_1#myorg.lan,CN=Users,CN=myorg,CN=Zones,OU=Circular,OU=warehouse,DC=myorg,DC=lan
instanceType: 4
whenCreated: 20190128081317.0Z
whenChanged: 20200128081329.0Z
displayName: $CimsUserVersion5
uSNCreated: 221081209
uSNChanged: 221081209
showInAdvancedViewOnly: TRUE
name: user_1#myorg.lan
objectGUID:: XG234o3+m0iVYGHHJKODVQ==
keywords: parentLink:S-1-5-21-******-*****-*****-1***3
objectCategory: CN=Service-Connection-Point,CN=Schema,CN=Configuration,DC=myorg,DC=lan
dSCorePropagationData: 20210805091319.0Z
dSCorePropagationData: 20210805084748.0Z
dSCorePropagationData: 20210921114113.0Z
dSCorePropagationData: 20210405111238.0Z
dSCorePropagationData: 16020914223649.0Z
uid: user_1
unixHomeDirectory: %{home}/%{user}
uidNumber: 763534041
gecos: %{u:displayName}
loginShell: /bin/bash
gidNumber: 20003
# search reference
ref: ldap://myorg.lan/CN=Configuration,DC=myorg,DC=lan
# search reference
ref: ldap://ForestDnsZones.myorg.lan/DC=ForestDnsZones,DC=myorg,DC=lan
# search reference
ref: ldap://DomainDnsZones.myorg.lan/DC=DomainDnsZones,DC=myorg,DC=lan
# search result
search: 2
result: 0 Success
# numResponses: 5
# numEntries: 1
# numReferences: 3
However, now I am confused which information maps to which parameter in Rundeck's JettyCachingLdapLoginModule. e.g. whether distinguishedName: CN=user_1#myorg.lan,CN=Users,CN=myorg,CN=Zones,OU=Circular,OU=warehouse,DC=myorg,DC=lan is a bindDn, userBaseDn or roleBaseDn?
I don't have direct access to the LDAP server, so only way to retrieve information is through ldapsearch.
It looks like the user name to access the LDAP binDn.
Here you can see all attributes explained.
bindDn: is optional. If not using "binding" authentication, set this to the root DN that should bind, e.g. "cn=Manager,dc=example,dc=com".
userBaseDn: is the base DN to search for users, example: "ou=People,dc=test1,dc=example,dc=com".
roleBaseDN: is the Base DN for role membership search, e.g. "ou=Groups,dc=test1,dc=example,dc=com".
Another great tool to check your LDAP server is Apache Directory Studio.
I'm new to LDAP and for a school project I have an access to part of my school LDAP. I can bind with users that are in a Organizational Unit.
When I bind, I am able to see my password and not any other passwords from other users (That's normal I guess for security reasons).
So I have exported the LDIF of this LDAP and imported it on my own LDAP server for leaning purposes.
ldapsearch commands works well and I retrieve all entries (excepted password and that's normal).
So now, I try to bind with any user, I've added password by Apache Directory Studio in each LDAP Users (inetorgPerson under the ou where I usually search).
However, I can't bind.
I guess that it is due to wrong access rights.
I know that I must use ldapmodify command and that I need to forge a directive like access to * by * read (with less rights than * but it could be great to begin with).
However, I cant find how to use this directive with ldapmodify.
I think that I must create an LDIF file to modify config but I don't understand which entry I should update.
Can anyone give me tips in order to modify the proper entry?
Thanks
Here id part of my config (Domain edited to domain.fr):
dn: olcDatabase={-1}frontend,cn=config
objectClass: olcDatabaseConfig
objectClass: olcFrontendConfig
olcDatabase: {-1}frontend
olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by * break
olcAccess: {1}to dn.exact="" by * read
olcAccess: {2}to dn.base="cn=Subschema" by * read
olcSizeLimit: 500
dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcAccess: {0}to * by * write
dn: olcDatabase={1}mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: {1}mdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=domain,dc=fr
olcAccess: {0}to attrs=userPassword by self write by anonymous auth by * none
olcAccess: {1}to attrs=shadowLastChange by self write by * read
olcAccess: {2}to * by * read
olcLastMod: TRUE
olcRoot
dn: cn=admin,dc=domain,dc=fr
olcRootPW: {SSHA}YNGbI0zpbUoVLZggbKeZqFIlVdq+0ZJP
olcDbCheckpoint: 512 30
olcDbIndex: objectClass eq
olcDbIndex: cn,uid eq
olcDbIndex: uidNumber,gidNumber eq
olcDbIndex: member,memberUid eq
olcDbMaxSize: 1073741824
search: 2
• Since, you have imported the LDIF file in the new AD, all the users in the original AD are created afresh in your AD environment. Thus, you would need to create a DNS naming service identical to the original one in your environment as the suffix to which you want to add the entry should exist in the database. Also, the domain admin credentials used in the original LDAP directory will be required to bind with the credentials of a user in imported LDIF file.
To do this, you would need to modify the domain admin credentials using the following commands. Below shown script is a sample on how to modify the domain admin credentials and then try to bind the user using those credentials.
Create a new LDIF file with the following contents: -
‘ dn: uid=XYZ,ou=Domain Administrators,dc=example,dc=com
cn: XYZ
sn: XYZ
givenName: XYZ
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
ou: Accounting
ou: People
l: Santa Clara
uid: XYZ
mail: XYZ#example.com
roomnumber: 5484
userpassword: Pass#123 ’
Then, add the entry using ‘ldapmodify’ with the ‘—defaultAdd’ option
‘ ldapmodify --hostname localhost --port 389 --bindDN "cn=Directory Manager" \
--bindPassword password --defaultAdd --filename /tmp/new.ldif ‘
With these commands, you would be able to modify the domain administrator credentials and then be able to bind the user in LDAP for sure. Just change the ldif file name with the one you have and change the entries in the ldif file with the actual ones from the original directory. Please find this link below for your reference: -
https://docs.oracle.com/cd/E22289_01/html/821-1273/adding-modifying-and-deleting-directory-data.html
I have a Keycloak with an openLDAP User Federation. In the LDAP, I have a user 'someUser' that belongs to multiple groups, namely:
dn: cn=developers,ou=groups,dc=example,dc=com
changetype: add
objectclass: groupOfNames
member: cn=architects,ou=groups,dc=example,dc=com
dn: cn=architects,ou=groups,dc=example,dc=com
changetype: add
objectclass: groupOfNames
member: uid=someUser,ou=People,dc=example,dc=com
On my Keycloak, for the LDAP I have created an LDAP Mapper for the roles, like the following
Mapper Type : role-ldap-mapper
LDAP Roles DN : ou=groups,dc=example,dc=com
Role Name LDAP Attribute : cn
Role Object Classes: groupOfNames
Membership LDAP Attribute: member Membership
Attribute Type : DN Membership
User LDAP Attribute : uid
LDAP Filter:
MODE : READ_ONLY
User Roles Retrieve Strategy: LOAD_ROLES_BY_MEMBER_ATTRIBUTE
Member-Of LDAP Attribute : memberOf
Use Realm Roles Mapping : ON
The problem is that when I try to get a token on behalf of the user 'someUser' only the role 'architects' appears on the token. Based on the LDAP nesting grouping, I expected that both 'architects' and 'developer' roles would have appear on the token.
Based on other answers on similar topics I try to add to the LDAP filter the following:
memberOf:1.2.840.113556.1.4.1941
But this seams to only work with Microsoft Active Directory.
My question is, what do I have to do in order to have both roles 'architects' and 'developer' in token? ( besides having to hardcoding them).
Try replacing member and objectclass in:
dn: cn=developers,ou=groups,dc=example,dc=com
changetype: add
objectclass: groupOfURLs
memberURL: ldap:///cn=architects,ou=groups,dc=example,dc=com?sub?(objectclass=*)
This kind of group defining is called dynamic groups, you should try ldapsearch in your openldap to see if the directory send the correct objects, for example:
./ldapsearch -h localhost--port 1389 -D "cn=Directory Manager" -w "password" -b "uid=someUser,ou=People,dc=example,dc=com" -s sub "(objectclass=*)" member
For more info: https://www.zytrax.com/books/ldap/ch11/dynamic.html
I've got LDAP working with OpenFire, at least for users and authentication, but I'm having some trouble getting it to see my group's members.
A sample group in our LDAP schema (which is IPA-based) looks like:
dn: cn=infrastructure,cn=groups,cn=accounts,dc=our,dc=net
member: uid=bretw,cn=users,cn=accounts,dc=our,dc=net
member: uid=bobs,cn=users,cn=accounts,dc=our,dc=net
:
objectClass: top
objectClass: groupofnames
objectClass: nestedgroup
objectClass: ipausergroup
objectClass: ipaobject
objectClass: posixgroup
cn: infrastructure
description: Infrastructure group
ipaUniqueId: <blah>
gidNumber: 9590000048
My group settings are default, except that I added a group filter of "(objectClass=ipausergroup)" to catch the actual groups and screen out the ones that are just for individual users. I'm using "cn=accounts,dc=our,dc=net" as our base DN.
What should I be doing to ensure that OpenFire 4.5.1 can see into our groups? It finds them, but says each has 0 members, which we know to not be true.
Turns out using anonymous logins don't work for filling out groups. Once I set an administrator DN, groups populated properly.
I have configured OpenLDAP to store user information.
In Ping Federate, I have given the OpenLDAP connection information. LDAP connection has been established. I am using HTTP Basic adapter on the PF IDP side.
How to give search filter?I have given something like:
cn=$username.
The following is the User information in OpenLDAP directory server.
dn: cn=John Smith,ou=people,dc=highroads,dc=com
objectclass: inetOrgPerson
cn: John Smith
cn: John J Smith
sn: Smith
uid: jsmith
userpassword: jSmitH
ou: Sales
On single sign-on authentication, I gave:
Username : uid
Password : userpassword
from the user information in OpenLDAP directory. But I am not able to access SP resource.
Please let me know about the configuration information I should provide on the Ping Federate side.
Thanks,
Aswini J
You would manage this in your Password Credential Validator that you have assigned to the HTTP Basic Adapter. If the user is providing the attribute value stored in the "uid" attribute, then you would typically specify "uid=${username}" as the Search Filter and "dc=highroads,dc=com" as the Search Base for the PCV. You can make this more complex/specific as needed to ensure you only get a single user identity returned from your LDAP.