We have a have a Novell tree with three containers based on our geographic areas. Each container holds the accounts for each of our three locations. I currently have the base dn set to the parent tree so that ldap can search any of the three containers. This seems to work fine except on accounts that have aliases. Unfortunately, our infrastructure used the old Novell SLP method for authentication. Since we have users that travel between locations, those users had alias created so that they could login from any site without having to fully qualify their usernames or specifying contexts. It seems that it is hit or miss when we attempt to view a profile or add a user who has an alias. Is there a configuration in Openfire 3.4.5 to account the existence of aliases or would we simply have to remove the aliases for all users that would be using the Openfire server? Since we use LDAP for authencation in our Novell clients now, I’m not sure that it would be a problem to remove the aliases, but I would like to know if there is a workaround for this.
Thanks
To follow up on my own question, I do believe this is an issue with the LDAP function dereferencing the aliases. This would explain why the filters don’t help. There is a post here http://www.igniterealtime.org/community/message/111533#111533 that seems to confirm my issue. The question is how is the easiest way to fix it? I didn’t really want to get into modifying code directly, but I do not think that this property can be edited directly by default.
The Java “dereference aliases” behavior is described here:
http://java.sun.com/products/jndi/tutorial/ldap/misc/aliases.html
I checked the debug logs and had error messages Search for userDN based on username ‘xxx’ found multiple responses, throwing exception. for any accounts that had aliases. Is there any easy way to disable dereferencing of aliases? If not, what is the official procedure for modifying the code to do this. At any rate, this should be an enhancement request so that the option can be set through the web console, or at a minimum active the property so that it can be changed via the property editor. My only other option at this point is to delete the aliases which I’m not sure if we are going to be able to do.
I think there’s an option for that actually. =) Edit your LDAP profile settings, and on the connection settings page (first screen):
Under Advanced, there’s the Follow Referrals option that I think is the same thing. I may be wrong but if you don’t mind, give it a shot? (make sure it’s turned off that is)
Thanks for the response but I’m not sure that referrals is the same setting which seems to be confirmed by this thread http://www.igniterealtime.org/community/message/164833#164833 If this is the setting that controls dereferencing, it isn’t changing the behavior for me. I’m still getting the same errors in the debug logs. I had already set this to “no”, but just as a test, I set it to “yes” with the same result, users who have aliases are basically nonexistent. If you look at the attached screenshot, you can see that the users who have aliases appear as where as working users who do not have aliases appear just as user.
The issue appears to be limited to Openfire though as we have other web applications such as Citrix Web Interface and Groupwise Web Email that allow logins for users who have aliases. I still think that the issue is specific to the way the Java LDAP request is constructed.
Huh, you are quite right. If I had read the page I would have seen:
Note also that the “dereference links” flag in the SearchControls(in the API reference documentation) class is not related to aliases.
To at least experiment and see if this’ll work, try adding to your jvm flags:
-Djava.naming.ldap.derefAliases=never
I don’t know what OS you are on, so I don’t have a good way of suggesting how to set those flags.
I am on Windows 2003 Server. Would this help you tell me where I could set that flag? According to the post here, http://www.igniterealtime.org/community/message/111533#111533 this flag was not active until the administrator modified the source code so that it would acknowledge that the setting was changed.
Thanks for your help with this. Admittedly, I’m not a developer so I don’t have in-depth knowledge when it comes to code changes.
Well, unfortunately, I misread and you can’t set it like that anyway. I’ll add an option for it in a moment here. It’s easy to add. =)
JM-1283
That means it’ll show up in whatever the next release is after 3.5.0. You can “beta test” it if you’d like. Ping me via private messages if you want details.
Hi,
Just downloaded Beta1 to test the ldap alias derefence but alas it still does not work as intended…lest i did it incorrectly. The record in MySQL is set to true for ldap.autoFollowAliasReferrals and my openldap (from zimbra) has an entry with the objectClass alias pointing to various TLDs.
Patrick
