GroupNotFoundException

Openfire Openfire Support
1

Our company recently switched from one Active Directory (AD) domain to a new, larger global AD domain. We’ve been using Openfire 3.3.1 connected to the older domain for quite some time now with zero problems. We love the tool.

I just upgraded our Openfire server from 3.3.1 to 3.6.3 as part of the switch to migrating off the new domain and I’m having trouble tracking down an error. This error is repeating so fast that it’s filling up the 1.0MB error.log file every 1-2 minutes.

2009.02.04 19:26:14 [org.jivesoftware.openfire.ldap.LdapGroupProvider.getGroup(LdapGroupProvider.java:91)] org.jivesoftware.openfire.group.GroupNotFoundException: Groupname Content Services not found
        at org.jivesoftware.openfire.ldap.LdapManager.findGroupDN(LdapManager.java:855)
        at org.jivesoftware.openfire.ldap.LdapManager.findGroupDN(LdapManager.java:782)
        at org.jivesoftware.openfire.ldap.LdapGroupProvider.getGroup(LdapGroupProvider.java:83)
        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(GroupCollection.java:103)
        at org.jivesoftware.openfire.group.GroupCollection$UserIterator.hasNext(GroupCollection.java:66)
        at org.jivesoftware.openfire.roster.RosterManager.getSharedGroups(RosterManager.java:162)
        at org.jivesoftware.openfire.roster.Roster.<init>(Roster.java:105)
        at org.jivesoftware.openfire.roster.RosterManager.getRoster(RosterManager.java:86)
        at org.jivesoftware.openfire.handler.IQLastActivityHandler.handleIQ(IQLastActivityHandler.java:52)
        at org.jivesoftware.openfire.handler.IQHandler.process(IQHandler.java:49)
        at org.jivesoftware.openfire.IQRouter.handle(IQRouter.java:351)
        at org.jivesoftware.openfire.IQRouter.route(IQRouter.java:101)
        at org.jivesoftware.openfire.spi.PacketRouterImpl.route(PacketRouterImpl.java:68)
        at org.jivesoftware.openfire.net.StanzaHandler.processIQ(StanzaHandler.java:319)
        at org.jivesoftware.openfire.net.ClientStanzaHandler.processIQ(ClientStanzaHandler.java:79)
        at org.jivesoftware.openfire.net.StanzaHandler.process(StanzaHandler.java:284)
        at org.jivesoftware.openfire.net.StanzaHandler.process(StanzaHandler.java:176)
        at org.jivesoftware.openfire.nio.ConnectionHandler.messageReceived(ConnectionHandler.java:133)
        at org.apache.mina.common.support.AbstractIoFilterChain$TailFilter.messageReceived(AbstractIoFilterChain.java:570)
        at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(AbstractIoFilterChain.java:299)
        at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilterChain.java:53)
        at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceived(AbstractIoFilterChain.java:648)
        at org.apache.mina.common.IoFilterAdapter.messageReceived(IoFilterAdapter.java:80)
        at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(AbstractIoFilterChain.java:299)
        at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilterChain.java:53)
        at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceived(AbstractIoFilterChain.java:648)
        at org.apache.mina.filter.codec.support.SimpleProtocolDecoderOutput.flush(SimpleProtocolDecoderOutput.java:58)
        at org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecFilter.java:185)
        at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(AbstractIoFilterChain.java:299)
        at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilterChain.java:53)
        at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceived(AbstractIoFilterChain.java:648)
        at org.apache.mina.filter.executor.ExecutorFilter.processEvent(ExecutorFilter.java:239)
        at org.apache.mina.filter.executor.ExecutorFilter$ProcessEventsRunnable.run(ExecutorFilter.java:283)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
        at java.lang.Thread.run(Thread.java:619)

This error is for group “Content Services” but each error typically has a different group in it.

Most of the groups don’t actually appear to exist in either the new AD nor the old AD. But there was a lot of data mashed together as part of the consolidation into a larger global AD, I wouldn’t be surprised if some of the user objects reference groups that don’t exist. But that’s just a wild guess.

From the stack trace and message above I’m having a really hard time tracking where this is coming from, and how to make it stop.

Here’s another snippet from the more verbose debug.log:

2009.02.04 19:30:44 LdapManager: Trying to find a groups's DN based on it's groupname. cn: Content Services, Base DN: DC="removed",DC="removed",DC="removed"...
2009.02.04 19:30:44 LdapManager: Creating a DirContext in LdapManager.getContext()...
2009.02.04 19:30:44 LdapManager: Created hashtable with context values, attempting to create context...
2009.02.04 19:30:44 LdapManager: ... context created successfully, returning.
2009.02.04 19:30:44 LdapManager: Starting LDAP search...
2009.02.04 19:30:44 LdapManager: ... search finished
2009.02.04 19:30:44 LdapManager: Group DN based on groupname 'Content Services' not found.
2009.02.04 19:30:44 LdapManager: Exception thrown when searching for groupDN based on groupname 'Content Services'

Any ideas?

2

The interesting thing is that I actually recognize almost all of the group names… but I can’t find them anywhere in our AD anymore, so I know they once existed. It wouldn’t surprise me to hear that they had been deleted accidentally from AD during the migration.

I think we even had group sharing rules setup for these “missing” groups at one point.

3

I started poking through the database and looking at the following three tables:

ofGroup
ofGroupProp
ofGroupUser

It looks like “ofGroup” contains all the locally created groups back before we were using AD for groups. And “ofGroupUser” contains the users in those groups. “ofGroupProp” appears to contain the group sharing information for both AD groups and local groups.

Is it safe to nuke “ofGroup” and “ofGroupUser” and delete all the groups from “ofGroupProp” for which we no longer have matching groups in AD?

Thank you for your time!

4

I ended up winging this and completely wiping out the ofGroup and ofGroupUser tables and selectively nuking the rows of ofGroupProp to remove any references to non-existant groups. In a couple cases I also had to adjust the propValue to remove references to shared groups that no longer exist as well.

All the error messages have dissapeared and things feel faster now that it’s not spending time on failed lookups.

p.s. I am ‘aholtz2’ my primary account was disabled for some unknown reason, but I got it back.

5

I have a similar problem but its always the same group. The group is called “individuals.” There is no such group in our AD but i believe it is a gateway group. I checked the three tables you mentioned and there is no reference to any group called “individuals.” I also checked some of the gateway tables and cannot find any reference to individuals. The debug log shows a gateway account that has contacts in a group called “individuals.” The LDAP search then searches for this group. Dont understand why the ldap search is looking in ldap for a gateway group.

6

I’ll have to agree that it seems that OpenFire is not removing the group from it’s DB even if it is removed from Active Directory. I noticed the same errors when I “cleaned up” some extraneous groups that were floating around under my IM OU, where all my IM groups live. I noticed these errors flying out of the error.log not to mention a significant slowdown in responce time and I lost access to the search functionality of Spark. I put these groups back and those error messages stopped showing up. Maybe if I had disabled my LDAP debuging I wouldn’t have had any server slowdown, but that is the reason I have it enabled, so I can see when something is wrong. I, unfortunately, chose to use the embedded DB when I setup OpenFire so I can’t quite remove those ofGroup* entries easily. I’ll just live with the clutter for now, but it might be worth looking into as it feels like a bug, but it could also just be me.

7

I know this post is really old by now, however, the same problem persists now in 2020 that did in 2009. The way I’ve been able to complete remove any reference to an Active Directory group is by copying the $OPENFIRE_HOME/embedded-db/openfire.script to a working directory. Editing that file and removing all references to the name of the AD group. Stopping the openfire service, replacing the script file, and starting the openfire service. Hope someone finds this helpful.