Hi all,
I’m currently piloting an Openfire installation, and one of our goals with this system is to deploy it in two different office locations, with two different domains, along with allowing users to chat between the two locations. In testing, I’ve been able to get this going without any problems. Except one.
In addition to allowing the users to be able to chat, we’d also like all users in both locations to see all users throughout the company. This is the problem. We’re using an LDAP backend for our user groups (filtering on objectClass=posixGroup), and this works fine in each location, with memberUids simply being a user name. However, when we want to throw users from another domain in that system (i.e., memberUid: "fullusername@domain.com"), Openfire does not pick up that user name. I can put any name I want in as a memberUid for a group, and as long as it’s a short user name (i.e., “fullusername”), they get added to the SRG, but as soon as I put a full user name in, it doesn’t work.
When setting up Openfire without LDAP, I can add a full user name from a different domain to a SRG, which leads me to believe this should be a one or few line change in the source, but I thought it’d be best to ask if there’s a legitimate reason for not doing this via LDAP, or if this could even be a bug.
If anyone has any ideas, that’d be appreciated. Thanks, in advance.
I was looking through the logs when I came across this:
2010.02.12 15:52:58 LdapManager: User DN based on username ‘testuser@test.example.com’ not found.
2010.02.12 15:52:58 LdapManager: Exception thrown when searching for userDN based on username 'testuser@test.example.com’
org.jivesoftware.openfire.user.UserNotFoundException: Username testuser@test.example.com not found
at org.jivesoftware.openfire.ldap.LdapManager.findUserDN(LdapManager.java:711)
at org.jivesoftware.openfire.ldap.LdapManager.findUserDN(LdapManager.java:637)
at org.jivesoftware.openfire.ldap.LdapUserProvider.loadUser(LdapUserProvider.java: 80)
at org.jivesoftware.openfire.user.UserManager.getUser(UserManager.java:213)
at org.jivesoftware.openfire.ldap.LdapGroupProvider.processGroup(LdapGroupProvider .java:381)
at org.jivesoftware.openfire.ldap.LdapGroupProvider.getGroup(LdapGroupProvider.jav a:95)
at org.jivesoftware.openfire.group.GroupManager.getGroup(GroupManager.java:278)
at org.jivesoftware.openfire.group.GroupManager.getGroup(GroupManager.java:257)
at org.jivesoftware.openfire.group.GroupCollection$UserIterator.getNextElement(Gro upCollection.java:103)
at org.jivesoftware.openfire.group.GroupCollection$UserIterator.hasNext(GroupColle ction.java:66)
at org.jivesoftware.openfire.admin.group_002dsummary_jsp._jspService(group_002dsum mary_jsp.java:211)
I took a look at the code, and other than just checking to see if the user’s DN exists, I don’t see any particular reason why this check needs to occur. Any downside to removing it, or altering it to allow this condition by any other means?
I think this has to do with the server setting “ldap.posixMode”.
-> If this is enabled, the groups’ members are short user names in Active Directory. So openfire won’t try to find the corresponding username again.
-> If this is not enabled, the groups’ members are Full DNs (instead of short user names). In this case, openfire tries to find the short username based on the Full DN (by extracting the user’s CN part etc.).
Is this setting enabled in your environment? If this is not enabled, could you try adding just short user names (instead of USER@DOMAIN) as members of Active directory groups? We just use single domain in our environment, so not really sure if that helps.
Thanks for the reply. We’re currently syncing with OpenLDAP instead of Active Directory, though I don’t think that would make any difference with this particular problem. As far as the difference between short names and long names go, I think the difference between short and long names is not the difference between “test” and "test@example.com", but rather “test” and “uid=test,ou=People,ou=Webapps,dc=example,dc=com”. That said, it’s mostly a difference in syntax rather than concept, so it may be quite beneficial to try out. Thanks for the helpful reply!
This worked better, but still did not have the desired effect. I could add memberUids using full DNs, but if I added a DN that was outside of the base DN set in Openfire, Openfire would still add that user to a SRG, and it would also assume that the user was in the local IM domain. So it’s one step forward in adding the user to a SRG, but one step backward in that it doesn’t acheive my objective, hah.
Any other thoughts? Comments on just not throwing an exception if a user cannot be found in LDAP?
Thanks, but that’s not quite what we’re looking for. Essentially, we want to have two separate servers, each running its own instance of Openfire with its own XMPP domain (each backed by LDAP), with server-to-server communications setup between them. This is easy enough to do, and I already have it setup in a test environment.
The tricky part comes with providing the ability for users of one domain to easily send IMs to users in the other domain, as well as providing presence notifications between domains. The Subscription plugin works well enough for allowing userABC@domain1.com to send a message to userDEF@domain2.com without requiring any “authorization” from userDEF@domain2.com, but presence data doesn’t work that way.
The one possible workaround I’ve found to this–which seems to work in my test environment–is to setup the two servers with the Subscription plugin, and then manually manipulate the ofRoster and ofRosterGroups table in the MySQL backend to add external users to the appropriate roster groups of the internal users. We’re expecting to have ~400 users in one location, and ~60 in another, so we’re looking at 24,000 entries in the ofRoster table alone in each location. It’s ugly (really ugly), but I don’t think it should be that big a deal, though I’m not sure of the impact it’ll have when all those users start signing on…
Thanks for the feedback so far, I appreciate it.
I think now I understand your requirement correctly. As far as I know, IM b/w the users of different XMPP domains should be possible - which is actually working in your case. But, I am not sure whether it’s possible to have users from different XMPP domains as part of shared roster groups. In short, I think developers may need to chime in.
Oh, it’s definitely possible to have IM users in one domain be a member of shared roster groups on an IM server of a different domain, it’s just that Openfire is making that process far more difficult than I’d like it to be.
In short, I think you’re right in that a developer’s word(s) might be tremendously helpful here. Barring that, I think I’ll evaluate using just one active IM server, with a backup ready to go against a replicated MySQL database and a replicated LDAP backend…
Hello!
This works fine in ejabberd project (http://www.ejabberd.im).
I have the same problem then migrate from ejabberd to openfire 
We’re looking to move away from ejabberd. As well as it seems to scale for some people, we have plenty of non-scaling-related issues that leave us wanting something (seemingly) substantially more polished (i.e., Openfire). We’re still trying to determine whether shared roster groups across multiple XMPP domains is a big deal for us, but I’m hoping we’ll be able to stick with Openfire.