Question for Openfire LDAP Users

Hi folk!

Those of you that are using LDAP with Openfire… how do you feel about the general setup of LDAP with Openfire? Are there things that you wondered why it didn’t ask you that you wanted to be able to enter? Are these things in your LDAP setup that you weren’t able to make use of due to the way we permit configuration? Was everything just fine and easy to follow and no problems what-so-ever? I’d like to hear opinions of our setup, and suggestions for improvement, things that would have made it fit better in your environment, etc. Thanks!

Daniel

Hi, I’m using Openfire 3.4.5 with Novell eDirectory. The setup was relatively straightforward but I am having a problem with accounts that have aliases. I think the problem is caused by the Java LDAP calls dereferencing the aliases http://www.igniterealtime.org/community/thread/31661?tstart=0 Could you provide a setting in the front end GUI to control whether deferencing is enabled or disabled?

I use AD for LDAP and the Mappings provided in the setup wizard for the vCard do not match what Spark and other Clients want. Namely no specific fields for First Name, Last Name, or Middle Name if applicable in a particular LDAP. Beyond that it was quite simple. The other feature that may be of benefit is allowing Openfire and the clients to write back to LDAP. This of course would be dependent on the permissions of the account that is being yoused to bind to LDAP.

passmaster16 wrote:

Hi, I’m using Openfire 3.4.5 with Novell eDirectory. The setup was relatively straightforward but I am having a problem with accounts that have aliases. I think the problem is caused by the Java LDAP calls dereferencing the aliases Issue with Novell eDirectory Alias and LDAP - Openfire Support - Ignite Realtime Community Forums Could you provide a setting in the front end GUI to control whether deferencing is enabled or disabled?

Howdy! I posted a note about the dereferencing in that thread. I don’t know if it’s the same thing yet though, so we’ll have to see. =D Please check it out!

mtstravel wrote:

I use AD for LDAP and the Mappings provided in the setup wizard for the vCard do not match what Spark and other Clients want. Namely no specific fields for First Name, Last Name, or Middle Name if applicable in a particular LDAP. Beyond that it was quite simple. The other feature that may be of benefit is allowing Openfire and the clients to write back to LDAP. This of course would be dependent on the permissions of the account that is being yoused to bind to LDAP.

I actually believe the current settings are flat out wrong. =)

What would you be looking for for them to write back? Updates to the various fields in the VCard?

Yes we would like them to be able to change or update the various fields. If their job title changes due to promotions, or if the data is incomplete or wrong, etc. We are looking to deploy a web solution just for this purpose. Our LDAP info is incomplete at best, but that is a whole other rant.

It would be awesome if users ldap could write back to the directory. Users could then update thier own info…

OR

At the very least, if there is incomplete user data in the profiles, let users update it and have it saved in the DB. For instance, if the their home phone number is missing, let them enter it and save it to the DB… Then if that info is added to the ldap directory later by an admin or something, it would just overrule whatever was added by a user…

Another idea I have, and I don’t know who feasable it is, but it would be neat if there was some kind of graphical attribute browser built in, for easy discovery of attributes for mapping purposes. Something like an ldap browser that would let you see the attributes while you are setting up your mappings. I don’t know if that makes any sense or not!

Wayne

I’m against any write access to LDAP, I don’t see a need for it. I like tech447’s suggestion about being able to write to the DB, but it should be an option admins can turn on or off.

Writing back to LDAP can be restricted by the rights of the account used to bind to LDAP. If the user has read only then you can not write, and the converse would be true.

we are using AD for our ldap connection and it was very straightforward to get up and running. But when we needed to narrow the list of known users for openfire it became a little tricky and it wasn’t so straightforward to setup filters thru the web interface. with lots of trial and error and a little text editing I was able to get exactly what I wanted.

I also would like to be able to enter a backup ldap server so if the dc dies that openfire connects to it can roll over to the backup.

HAHA You’ve seen my posts…yes more capability with the LDAP config would be very good. Our AD setup was done before I got here and isn’t structured like anything i’ve seen, so to compinsate if I had more config options I might be able to setup what my employer wants.

What other config options are you looking for beyond the alias dereferencing?

jledhead wrote:

we are using AD for our ldap connection and it was very straightforward to get up and running. But when we needed to narrow the list of known users for openfire it became a little tricky and it wasn’t so straightforward to setup filters thru the web interface. with lots of trial and error and a little text editing I was able to get exactly what I wanted.

What wasn’t straightforward about it? Like what would you have liked to see?

I also would like to be able to enter a backup ldap server so if the dc dies that openfire connects to it can roll over to the backup.

There’s an open issue for this: JM-323 =)

I cannot speak for jledhead, but I know for me, encountering ldap filters for the first time was a real challenge. If someone hadn’t pointed me to a document that explained the formatting of the filters I would still be lost. A nice document that explains how the filters are formatted and some simple / moderate examples of how they are used I think would be very helpful to newbies that may not have ever encountered them before. (links to the docs in the admin portal including how to access and modify the xml file)

Just a thought…

Wayne

JM-964 talks about this a bit. I believe we could create a wizard/tool to help with this while leaving the text field there for folk who really know what they’re doing with LDAP filters.

tech447 wrote:

I cannot speak for jledhead, but I know for me, encountering ldap filters for the first time was a real challenge. If someone hadn’t pointed me to a document that explained the formatting of the filters I would still be lost. A nice document that explains how the filters are formatted and some simple / moderate examples of how they are used I think would be very helpful to newbies that may not have ever encountered them before. (links to the docs in the admin portal including how to access and modify the xml file)

Just a thought…

Wayne

That was my problem also. I guess technically not so much of an openfire problem but I wasn’t really sure of the information needed for proper filtering. A couple of documents and this free tool http://www.ldapadministrator.com/ and I was much better off. Things like AD delimeters and search fields I think were messing me up and to me at the time, it seemed like an openfire problem becuase I needed to know all this other stuff to get the filter working. But all in all, finding the information helped me, but most people may not have that kind of time on their hands.

We wanted to do the enterprise version but couldn’t pay for the 1000 users in our AD, so I had to get the filter working.

Thanks for your interest.

creating users?

im new to openfire, but not new to ldap and i would like to allow creating users directly from openfire.

openfire should detect if user has write rights and show a “Read Only” message in case it doesn’t.

If you could give me bigger option about setting VCard mapping and VCard fields that would be grat.

To explain, our AD got not standart association of fields. And also some little tool to set VCard settings to fit for your clientwould be grea (I use pandion and he is yuite different from lets say Spark).

I only have one complaint so far: Openfire ignores LDAP users’ primary group (specified in their gidNumber attribute). I already posted a thread about this: http://www.igniterealtime.org/community/message/168003

Currently when we make a change to the LDAP directory (for example add a new user, or change a user’s Display Name), the change won’t be visible in any user’s roster even after restarting the user’s Jabber clients (we use Pidgin). The only way I was able to make the LDAP directory update visible to everyone was to restart Openfire - but then of course all connections break, and I don’t think this is how it should be. Am I missing something?