How to read nested groups in OpenLdap connected to Keycloak - ldap

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

Related

Openfire LDAP configuration for groups

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.

Error on operational attribute creation in OpenLDAP

Actually, in my LDAP, I have a groups ou populated with groupOfNames objects and a roles ou populated with groupOfMembers objects.
I also configured the memberOf overlay to retrieve the groupOfMembers (ie roles) the user belong to in the memberof attribute.
My goal is to have also an attribute memberOfGroup with the list of groupOfNames (ie groups) the user belong to.
In order to do that I created an new schema with Attribute Type definition for memberOfGroup attribute :
cn={14}memberOfGroup,cn=schema,cn=config
objectClass: olcSchemaConfig
cn: {14}memberOfGroup
olcAttributeTypes: {0}( 1.3.6.1.4.1.51127.3.2.2.3
NAME 'memberOfGroup'
DESC 'The groups the user belong to'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
The problem I have is that when I try to set it as operational attribute is :
# ldapmodify -Y EXTERNAL -H ldapi:/// -f test.ldif
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "cn={14}memberOfGroup,cn=schema,cn=config"
ldap_modify: Other (e.g., implementation specific) error (80)
additional info: olcAttributeTypes: "1.3.6.1.4.1.51127.3.2.2.3" is operational
With test.ldif :
dn: cn={14}memberOfGroup,cn=schema,cn=config
changetype: modify
replace: olcAttributeTypes
olcAttributeTypes: ( 1.3.6.1.4.1.51127.3.2.2.3
NAME 'memberOfGroup'
DESC 'The groups the user belong to'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 NO-USER-MODIFICATION
USAGE DSAOperation )
In parallel, I also defined the second memberOf overlay.
The first for roles (work) :
dn: olcOverlay={0}memberof,olcDatabase={1}mdb,cn=config
objectClass: olcMemberOf
objectClass: olcOverlayConfig
objectClass: olcConfig
objectClass: top
olcOverlay: {0}memberof
olcMemberOfDangling: ignore
olcMemberOfRefInt: TRUE
olcMemberOfGroupOC: groupOfMembers
olcMemberOfMemberAD: member
olcMemberOfMemberOfAD: memberOf
The second for groups (not work) :
dn: olcOverlay={1}memberof,olcDatabase={1}mdb,cn=config
objectClass: olcMemberOf
objectClass: olcOverlayConfig
objectClass: olcConfig
objectClass: top
olcOverlay: {1}memberof
olcMemberOfDangling: ignore
olcMemberOfRefInt: TRUE
olcMemberOfGroupOC: groupOfNames
olcMemberOfMemberAD: member
olcMemberOfMemberOfAD: memberOfGroup
Can someone explain me what is wrong with the creation of operational attribute and the error I have ?
In ldif you have USAGE DSAOperation
Operational attributes can be used only by the directory itself, and can't be added or modified by a user. OpenLDAP module memberof creates it automatically when a user is added to some group(and also removes when user is removed).
If you want some custom attribute for group membership tracking, then you can create a simple attribute(not operational), but in this case ldap server won't update users' membership automatically.

How to integrate Ping Federate IDP with OpenLDAP?

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.

LDAP with Cloudera hue integration

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.

memberOf vs. groupMembership in LDAP (Liferay)

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.