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.
Related
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.
I am trying to do this example with an email field :
https://coderwall.com/p/c0w6-q/create-ldap-aliases-in-openldap
This is the .ldif that should create both :
# this is the user
dn: uid=aka,c=VN,ou=users,ou=school,o=vdm,dc=domain,dc=com
objectclass: top
objectClass: extensibleObject
objectclass: posixAccount
objectclass: inetOrgPerson
cn: Alexander Fake
employeetype: developer
gecos: Alexander Fake
gidnumber: 14564103
homedirectory: /home/aka
loginshell: /bin/bash
mail: alexander.fake#domain.com
sn: Fake
uid: aka
uidnumber: 14583105
userpassword: {SSHA}SgmdndrPR5UVLOAmDs5JOJvqr3WmPYob
# this is the alias
dn: mail=alexander.Fake#domain.com,dc=mailAccount,dc=domain.com,dc=mail,dc=domain,dc=com
changetype: add
objectClass: alias
objectClass: top
objectClass: extensibleObject
objectclass: inetOrgPerson
uid: aka
aliasedObjectName: uid=aka,c=VN,ou=users,ou=school,o=vdm,dc=domain,dc=com
I can only import/export ldif, I use phpldapadmin for administration.
When the aliases is craeted it produce the following error :
This update has been or will be cancelled, it would result in an attribute value not being unique. You might like to search the LDAP server for the offending entry.
Does anyone know how to create aliases on openldap and phpldapadmin ?
This is basically correct. Just:
Remove the uid=aka attribute from the aliasedObject. It doesn't need it. It refers to another object which has that UID value.
Also remove inetOrgPerson from the alias. It isn't a person, it's an alias for a person.
The objectClass attribute only needs to contain top and alias; and extensibleObject so you can provide a cn or whatever attribute you like as part of the DN, if you want to do that: it doesn't seem to be necessary judging by my DIT.
Poor quality source material. Don't rely on arbitrary Internet junk. Use the official documentation.
I'm newbie on LDAP and I'd like to create my first schema using an LDIF file. Here is the first part of the LDIF file:
dn: dc=demo,dc=com
objectclass: top
objectclass: domain
dc: demo
dn: ou=Users,dc=demo,dc=com
objectClass: organizationalUnit
objectClass: top
ou: Users
description: demo.Com Users
dn: uid=bob,ou=Users,dc=demo,dc=com
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top
cn: User Test
sn: Test
displayName: User Test
givenName: User
mail: bob#demo.com
ou: Users
uid: bob
userPassword:: e1NTSEF9MGhuUjhnWkFNZFpKVUNwZXFwcFEzeUQ2YkJNOTVQUVo4WU9JSUE9P
Q==
Even if the LDIF declares the top domain "demo.com" the following error is raised:
"Entry
dn[n]: dc=demo,dc=com
objectclass: top
objectclass: domain
dc: demo : ERR_268 Cannot find a partition for dc=demo,dc=com]"
On the other hand, creating the partition "demo.com" manually with ApacheDS studio UI (and removing the first dn block) it works. I'm a bit confused! Any help to sort out the problem?
Importing your LDIF file into ApacheDS will just create the entries not the partition. Since all your entries have to be stored in a partition you get the below error when the partition doesn't exist:
ERR_268 Cannot find a partition for dc=demo,dc=com
Every partition has a suffix or base DN associated with it which will act as the parent entry for all the other entries stored in the same partition. In your case the suffix will be:
dc=demo,dc=com
Notice that the suffix is also an entry (just like any other entry in your directory).
Creating a new DIT (Directory Information Tree) involves the following steps:
Create a new partition.
Create suffix entry.
Create additional entries.
Some utilities (like Apache Studio) will create the suffix entry automatically when you create the partition (I think that's what's confusing you) but in reality they are two different operations.
You can read more about ApacheDS partitions here.
I am using openldap to create a simple user and simple group.
dn: cn=User2 Engineer,ou=users,dc=example,dc=net
cn: User2 Engineer
gidnumber: 501
givenname: User2
homedirectory: /home/users/u2engineer
loginshell: /bin/sh
objectclass: inetOrgPerson
objectclass: posixAccount
objectclass: top
sn: Engineer
uid: u2engineer
uidnumber: 1002
userpassword: {MD5}xxxxxxx
# Entry 1: cn=network engineers,ou=groups,dc=example,dc=net
dn: cn=network engineers,ou=groups,dc=example,dc=net
cn: network engineers
gidnumber: 501
memberuid: user1ene
memberuid: u2engineer
objectclass: posixGroup
objectclass: top
I would like to relate the user to the group by adding memberof attribute to user entry.
it mean i need to add groupOfNames objectclass to user, groupOfNames is in core.schema
but it can add that objectclass to user neither via phpldapadmin nor ldapmodify.
i got error:
LDAP said: Object class violation
Error number: 0x41 (LDAP_OBJECT_CLASS_VIOLATION)
I am sure that core.schema has been imported to openldap successfully.
What is the possible cause?
How can I add memberof attribute to users?
Thanks!
-SG-
You can't. The memberOf attribute is an operational attribute maintained automatically by the memberof overlay. You can't set it yourself.
Adding the groupOfNames object class to the user entry doesn't make sense either. That object class is for, err, groups of names, such as roles, and it has a member attribute to which you add the DN of the user. Then the memberOf attribute of the user is automatically updated to include the DN of the group.
You're doing this all back to front.
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.