Help Diagnosing a LdapVCardProvider Error

I’ve been receiving the below error every day and sometimes two times a day. I think it has to do with a particular user’s account but I can’t find it. I have OpenFire working with my Active Directory with an OU named “IM” and using a group named “IM_Users” to populate the users and then other groups named “IM_” to organize those users into groups in Spark. Iv’e got about 60 users at the moment and I intent to start adding more (about 300+). I would like to diagnose this problem before I do that, though.

What I’ve done so far: I’ve already searched everywhere in Active Directory for the “receptionist” user and can’t find it but there is a group named “Receptionist” and I have an IM group named “IM_Receptionists”. I’ve double (and triple) checked all IM_Groups to see if I might have a user in them that shouldn’t be, but those are all clean. I am leaning toward the error being caused when a particular user logs in, but I can’t find evidence of that. I’ve just turned on the Debug log; so, that may lead me to my answer, but I figured I’d post the question to see if anyone has already resolved such an error.

2009.10.15 07:58:31 [org.jivesoftware.openfire.ldap.LdapVCardProvider.getLdapAttributes(LdapVCardPr ovider.java:183)

]

org.jivesoftware.openfire.user.UserNotFoundException: Username receptionist 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.LdapVCardProvider.getLdapAttributes(LdapVCardPro vider.java:156)

at org.jivesoftware.openfire.ldap.LdapVCardProvider.loadVCard(LdapVCardProvider.ja va:209)

at org.jivesoftware.openfire.vcard.VCardManager.getOrLoadVCard(VCardManager.java:2 22)

at org.jivesoftware.openfire.vcard.VCardManager.getVCard(VCardManager.java:215)

at org.jivesoftware.openfire.handler.IQvCardHandler.handleIQ(IQvCardHandler.java:1 08)

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(ConnectionHandl er.java:133)

at org.apache.mina.common.support.AbstractIoFilterChain$TailFilter.messageReceived (AbstractIoFilterChain.java:570)

at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(Ab stractIoFilterChain.java:299)

at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilt erChain.java:53)

at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceive d(AbstractIoFilterChain.java:648)

at org.apache.mina.common.IoFilterAdapter.messageReceived(IoFilterAdapter.java:80)

at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(Ab stractIoFilterChain.java:299)

at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilt erChain.java:53)

at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceive d(AbstractIoFilterChain.java:648)

at org.apache.mina.filter.codec.support.SimpleProtocolDecoderOutput.flush(SimplePr otocolDecoderOutput.java:58)

at org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecF ilter.java:185)

at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(Ab stractIoFilterChain.java:299)

at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilt erChain.java:53)

at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceive d(AbstractIoFilterChain.java:648)

at org.apache.mina.filter.executor.ExecutorFilter.processEvent(ExecutorFilter.java :239)

at org.apache.mina.filter.executor.ExecutorFilter$ProcessEventsRunnable.run(Execut orFilter.java:283)

at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)

at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:51)

at java.lang.Thread.run(Unknown Source)

2009.10.15 07:58:31 [org.jivesoftware.openfire.handler.IQHandler.process(IQHandler.java:69)

] Internal server error

java.lang.NullPointerException

if you have any users outside the BaseDN of openfire, but within a group found in the BaseDN it would cause this error. It could also be caused by adding groups as members of a group. Openfire only likes groups that have user only for members.

Well I’m not sure about the Group of a Group thing being the problem as none of the “IM_” groups have this, and I’m pretty certain that the BaseDN isn’t the problem. I’m still a little stumped, but I’ll double check those suggestions just to be sure. In any case, I got another error message this morning and then I traced it back to it’s debug log and this is what I found:

2009.10.16 08:02:00 LdapManager: Trying to find a user’s DN based on their username. sAMAccountName: receptionist, Base DN: DC=“DOMAIN”,DC=“LOCAL”…
2009.10.16 08:02:00 LdapManager: Creating a DirContext in LdapManager.getContext()…
2009.10.16 08:02:00 LdapManager: Created hashtable with context values, attempting to create context…
2009.10.16 08:02:00 LdapManager: … context created successfully, returning.
2009.10.16 08:02:00 LdapManager: Starting LDAP search…
2009.10.16 08:02:00 LdapManager: … search finished
2009.10.16 08:02:00 LdapManager: User DN based on username ‘receptionist’ not found.
2009.10.16 08:02:00 LdapManager: Exception thrown when searching for userDN based on username 'receptionist’
org.jivesoftware.openfire.user.UserNotFoundException: Username receptionist not found

at org.jivesoftware.openfire.ldap.LdapManager.findUserDN(LdapManager.java:711)

<-- the same error as above follows this line -->

I guess, technically, OpenFire is correct in returning that no user can be found as there isn’t one in AD BUT why it is causing an error? Does this mean that I’ve got something misconfigured? Should I just ignore this error?

Thanks in advance.

Somewhere in your AD structure that openfire is allowed to see there is a CN with receptionist as the name. The CN must have some sort of pathing error that openfire cannot follow. This only happens for the affore stated reasons that I am aware of.

OK I tried the same search that OpenFire uses and ran it with the ldp.exe tool and this is my result:

(I used the same BaseDN that OpenFire uses)

***Searching…
ldap_search_s(ld, “DC=DOMAIN,DC=LOCAL”, 2, “sAMAccountName=receptionist”, attrList, 0, &msg)
Result <0>: (null)
Matched DNs:
Getting 1 entries:

Dn: CN=Receptionist,OU=Groups,DC=DOMAIN,DC=LOCAL
2> objectClass: top; group;
1> cn: Receptionist;
1> distinguishedName: CN=Receptionist,OU=Groups,DC=DOMAIN,DC=LOCAL;
1> name: Receptionist;
1> canonicalName: DOMAIN.LOCAL/Groups/Receptionist;

Just to be sure I also ran a search where CN=receptionist on the same DN:

***Searching…
ldap_search_s(ld, “DC=DOMAIN,DC=LOCAL”, 2, “cn=receptionist”, attrList, 0, &msg)
Result <0>: (null)
Matched DNs:
Getting 1 entries:

Dn: CN=Receptionist,OU=Groups,DC=DOMAIN,DC=LOCAL
2> objectClass: top; group;
1> cn: Receptionist;
1> distinguishedName: CN=Receptionist,OU=Groups,DC=DOMAIN,DC=LOCAL;
1> name: Receptionist;
1> canonicalName: DOMAIN.LOCAL/Groups/Receptionist;

So it did find my group named Receptionist in both searches. Only users that are part of the group “IM_Users” are allowed to use Spark, though.

It seems a little strange to me. I can’t get rid of the group so I’ll just have to live with the error. As long as it won’t take down my server I’ll just ignore it.

Thanks for your help!

It won’t take down your server. But there is definitely something wrong with that group as far as Openfire is concerned.