What is the difference b/n memberOf attribute and groupMembership attribute when used in LDAP Authentication settings in Liferay?
The users are imported successfully.
The groups are also imported successfully.
But the users are not assigned to the groups automatically. And when I changed the group variable from 'groupMembership' to 'memberOf', several users are not able to login to Liferay.
What exactly are memberOf and groupMembership variables?
memberOf is not a "variable", it is an attribute, or more accurately, it is a virtual attribute, or a dynamic attribute generated on the fly by some directory servers, but not all. Some use memberOf to use in search filters or in the attribute list of a search request, some use isMemberOf for the same purpose, some support both or neither, and there are probably other idioms of which I am not aware.
Generally speaking, to determine group membership, issue a search request to the directory server and specify memberOf or isMemberOf to be returned in the attribute list. Here is an example using a modern ldapsearch command line tool:
ldapsearch --port 1389 --baseDn 'ou=people,dc=example,dc=com' \
--sizeLimit 3 --searchScope one --bindDn 'cn=directory manager' \
--bindPasswordFile ~/.pwdFile '(uid=user.0)' isMemberOf
dn: uid=user.0,ou=people,dc=example,dc=com
isMemberOf: cn=Dynamic Home Directories,ou=groups,dc=example,dc=com
isMemberOf: cn=bellevue,ou=groups,dc=example,dc=com
isMemberOf: cn=shadow entries,ou=groups,dc=example,dc=com
isMemberOf: cn=persons,ou=groups,dc=example,dc=com
This search response indicated that user.0 is a member of the listed groups.
To reverse the sense of the query, that is, to determine which entries are the member of a group, use the isMemberOf or memberOf with an assertion in the filter used in the search request:
ldapsearch --port 1389 --baseDn 'ou=people,dc=example,dc=com' \
--sizeLimit 3 --searchScope one --bindDn 'cn=directory manager' \
--bindPasswordFile ~/.pwdFile \
'(isMemberOf=cn=persons,ou=groups,dc=example,dc=com)' 1.1
dn: uid=terrygardner,ou=people,dc=example,dc=com
dn: uid=user.0,ou=people,dc=example,dc=com
dn: uid=user.1,ou=People,dc=example,dc=com
dn: uid=user.10,ou=People,dc=example,dc=com
This search response indicates that there are several member of the group whose distinguished name is cn=persons,ou=groups,dc=example,dc=com.
While not specific to LifeRay, the above is a general explanation of one way to deal with group membership and also of reverse group membership from an LDAP perspective.
Related
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 am trying to add a new attribute to the OpenLDAP schema
# cat /etc/ldap/pwdResetAttribAdd.ldif
dn: cn={3}inetorgperson,cn=schema,cn=config
add: olcAttributeTypes
##
## The new attribute type
##
olcAttributetypes: ( 1.3.6.1.4.1.42.2.27.8.1.22
NAME 'pwdReset'
DESC 'The indication that the password has been reset'
EQUALITY booleanMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
SINGLE-VALUE
USAGE directoryOperation )
The command I am using to add is as under
ldapmodify -D "cn=admin,dc=test" -w somePass -h localhost -p 389 -f /etc/ldap/pwdResetAttribAdd.ldif
However, it fails with below error
modifying entry "cn={3}inetorgperson,cn=schema,cn=config" ldap_modify: Other (e.g., implementation specific) error (80)
additional info: olcAttributeTypes: "1.3.6.1.4.1.42.2.27.8.1.22" is operational
Where am I wrong ?
You don't need to do this. Just add ppolicy.schema to the schemas being loaded, and the ppolicy overlay to the overlays, and all the appropriate ppolicy attributes will appear.
NB pwdReset and its friends that live in user entries are operational attributes and are commented out in this schema, but the ppolicy overlay causes them to be known anyway.
I cannot add uniqueMembers to a static group (objectClass: groupOfUniqueNames)
According to this documentation:
Modifying group entries: In order to add a member to a static group, add the user's distinguished name as an additional value for the member or uniqueMember attribute. Following is an example:
ldapmodify -h 127.0.0.1 -D "cn=admin" -w xxxx -f modStaticGrp.ldif
Where modStaticGrp.ldif contains:
dn: cn=group1, o=Your Company
changetype: modify
add: member
member: cn=jeff, cn=tim, o=Your Company
dn: cn=group2, o=Your Company
changetype: modify
add: uniqueMember
uniqueMember: cn=joe,o=Your Company
When I try to add a uniqueMember with ldapmodify with the following ldif file:
dn: cn=Private,o=My Company
changetype: modify
add: uniqueMember
uniqueMember: uid=1234567890,ou=My Company
I get the error:
ldapmodify: wrong attributeType at line 4, entry "cn=Private,o=My Companyā€¯
What am I missing? Any ideas?
uid=1234567890,ou=My Company
A uniqueMember value is a complete DN. Judging by the rest of your DNs this should be something like
uid=1234567890,o=My Company
although I woudl have expected to see something more like this:
uid=1234567890,ou=Users,o=My Company
actually, depending on exactly how you've designed your DIT. You shouldn't be adding user entries at its top level.
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.
I'm trying to setup an LDIF file which shall add a new attribute value to an existing node. The attribute is a mandatory attribute of custom objectclass.
Here is the contents of the LDIF file 'add.ldif':
dn: cn=hna,cn=Users,DC=lan,DC=test,DC=de
changetype: modify
add: objectclass
objectclass: MyCustomObjectClass
-
add: myCustomAttribute
myCustomAttribute: someValue
-
Problem: when I try add that to the LDAP server using
ldapmodify -h ... -D ... -w ... -x -f add.ldif
I get the error message
ldap_modify: Objectclass violation (65)
additional info: 00002014: objectclass_attrs: attribute 'myCustomAttribute'
on entry 'cn=hna,cn=Users,DC=lan,DC=test,DC=de' does not exist in the
specified objectclasses
When I leave out the 'add' of 'myCustomAtribute' then of course then I get:
ldap_modify: Objectclass violation (65)
additional info: 00002014: objectclass_attrs: at least one mandatory attribute
('myCustomAttribute') on entry 'cn=hna,cn=Users,DC=lan,DC=test,DC=de'
wasn't specified!
Any idea what is wrong with my approach?
ldapmodify is the one from OpenLDAP; the server is a Samba V4 LDAP.
This should work:
dn: cn=hna,cn=Users,DC=lan,DC=test,DC=de
changetype: modify
add: objectclass
objectclass: MyCustomObjectClass
add: myCustomAttribute
myCustomAttribute: someValue
There MUST be an empty line after the last line.
The "-" is only needed if you want to perform separate modify operations and have them be atomic. (ie all work or all fail).
As adding the objectclass requires MUST attributes must happen in the same modification.
By the way I have noticed that some ldapmodify programs do not handle these properly.
-jim