powered by Jive Software

LDAP groups problem (dn used as username)

Hello!

I have a little problem with my Openfire installation.

It seems to be in 3.9.1 (3.9.3 too, but it unstable for me to use in production)

When at least one of my jabber groups contains **disabled **member with DN, that contains no spaces (CN is one word) - i see continous messages in error log:

2014.07.15 17:56:34 org.jivesoftware.openfire.roster.Roster - Groups ([jabber_m_vydacha]) include non-existent username (cn=mag48,ou=vydacha,ou=magazin,dc=pup,dc=local)

2014.07.15 17:56:34 org.jivesoftware.openfire.roster.Roster - Groups ([jabber_m_vydacha]) include non-existent username (cn=mag47,ou=vydacha,ou=magazin,dc=pup,dc=local)

My group search filter:

(&(objectClass=group)((cn=jabber__)))

My user search filter:

(&(sAMAccountName={0})(objectCategory=person)(objectClass=user)(!(userAccountCon trol:1.2.840.113556.1.4.803:=2))(memberOf:1.2.840.113556.1.4.1941:=CN=jabber_acc ess,OU=Global_groups,DC=pup,DC=local))

(all enabled users of group jabber_access including groups nesting)

That filter works perfectly in embedded ADUC query tool), no disabled users displayed.

When i add space to disabled user CN - error log message is gone.

When i enabled username account - error message is gone.

Some piece of debug log:

2014.07.08 12:12:48 org.jivesoftware.openfire.ldap.LdapManager - LdapManager: Trying to find a user’s DN based on their username. sAMAccountName: cn=mag47,ou=vydacha,ou=magazin,dc=pup,dc=local, Base DN: dc=“pup”,dc=“local”…

2014.07.08 12:12:48 org.jivesoftware.openfire.ldap.LdapManager - LdapManager: Creating a DirContext in LdapManager.getContext()…

2014.07.08 12:12:48 org.jivesoftware.openfire.ldap.LdapManager - LdapManager: Warning: Using unencrypted connection to LDAP service!

2014.07.08 12:12:48 org.jivesoftware.openfire.ldap.LdapManager - LdapManager: Created hashtable with context values, attempting to create context…

2014.07.08 12:12:48 org.jivesoftware.openfire.ldap.LdapManager - LdapManager: … context created successfully, returning.

2014.07.08 12:12:48 org.jivesoftware.openfire.ldap.LdapManager - LdapManager: Starting LDAP search…

2014.07.08 12:12:48 org.jivesoftware.openfire.ldap.LdapManager - LdapManager: … search finished

2014.07.08 12:12:48 org.jivesoftware.openfire.ldap.LdapManager - LdapManager: User DN based on username ‘cn=mag47,ou=vydacha,ou=magazin,dc=pup,dc=local’ not found.

2014.07.08 12:12:48 org.jivesoftware.openfire.ldap.LdapManager - LdapManager: Exception thrown when searching for userDN based on username ‘cn=mag47,ou=vydacha,ou=magazin,dc=pup,dc=local’

org.jivesoftware.openfire.user.UserNotFoundException: Username cn=mag47,ou=vydacha,ou=magazin,dc=pup,dc=local not found

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

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

at org.jivesoftware.openfire.ldap.LdapUserProvider.loadUser(LdapUserProvider.java: 106)

at org.jivesoftware.openfire.user.UserManager.getUser(UserManager.java:234)

at org.jivesoftware.openfire.user.UserNameManager.getUserName(UserNameManager.java :106)

at org.jivesoftware.openfire.user.UserNameManager.getUserName(UserNameManager.java :87)

at org.jivesoftware.openfire.roster.Roster.(Roster.java:190)

at org.jivesoftware.openfire.roster.RosterManager.getRoster(RosterManager.java:116 )

at org.jivesoftware.openfire.handler.PresenceUpdateHandler.broadcastUpdate(Presenc eUpdateHandler.java:305)

at org.jivesoftware.openfire.handler.PresenceUpdateHandler.process(PresenceUpdateH andler.java:147)

at org.jivesoftware.openfire.handler.PresenceUpdateHandler.process(PresenceUpdateH andler.java:135)

at org.jivesoftware.openfire.handler.PresenceUpdateHandler.process(PresenceUpdateH andler.java:199)

at org.jivesoftware.openfire.PresenceRouter.handle(PresenceRouter.java:148)

at org.jivesoftware.openfire.PresenceRouter.route(PresenceRouter.java:84)

at org.jivesoftware.openfire.spi.PacketRouterImpl.route(PacketRouterImpl.java:84)

at org.jivesoftware.openfire.net.StanzaHandler.processPresence(StanzaHandler.java: 355)

at org.jivesoftware.openfire.net.ClientStanzaHandler.processPresence(ClientStanzaH andler.java:100)

at org.jivesoftware.openfire.net.StanzaHandler.process(StanzaHandler.java:272)

at org.jivesoftware.openfire.net.StanzaHandler.process(StanzaHandler.java:194)

at org.jivesoftware.openfire.nio.ConnectionHandler.messageReceived(ConnectionHandl er.java:181)

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.CompressionFilter.messageReceived(CompressionFilter.java :161)

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)

What’s the problem? Why disabled users still appears as member of groups, depending on spaces in his CN?

My mistake in filters or Openfire bug?

Thanks for any help!

This is how I set up my groups. It works great.

Thanks, but my filter looks the same

You checks only objectclass attribute, my filter checks objectcategory attribute in additional.

at the bottom, I updated the post last month that includes the filter that leaves out disabled users.

Ok i see it.

Changed my filter to :

(&(sAMAccountName={0})(objectClass=organizationalPerson)(!(userAccountControl:1. 2.840.113556.1.4.803:=2))(|(memberOf:1.2.840.113556.1.4.1941:=CN=jabber_access,O U=Global_groups,DC=pup,DC=local)))

But error still in place**
**

you don’t need all that other stuff…follow my post and you’ll be fine. one very important thing you need to do, is make sure your master group is Domain Local and not a universal or global group.

And my filter works great too. No problems but this continous messages in syslog

What you mean “Other stuff”?

**sAMAccountName **filter?

My jabber_access group is Global security group, but why it can’t be global? Where i can find description of this limitation?

I’m not getting anything like that in my logs…but if its working for you and you’re happy with the results, than go with the “if its not broken, don’t fix it” motto.

So ok, i’ve tried:

  1. Change my user filter to:

(&(objectClass=organizationalPerson)(!(userAccountControl:1.2.840.113556.1.4.803 :=2))(memberOf:1.2.840.113556.1.4.1941:=CN=jabber_access,OU=Global_groups,DC=pup ,DC=local))

It’s not helped

  1. Changing my group type to domain local (not helped again)

Any ideas?

it lookes like you missed the “|”

try something like this

(&(objectclass=organizationalPerson)(|(memberOf:1.2.840.113556.1.4.1941:=CN=jabb er_access,OU=Global_groups,DC=pup,DC=local))(!(userAccountControl:1.2.840.113556 .1.4.803:=2)))

the main group “jabber_access” should be a domain local group to allow for nested groups.

I’ve tried with symbol “|” - same result.

This symbol just adds OR condition to 1 argument, so it does not make sense to put.

the main group “jabber_access” should be a domain local group to allow for nested groups.

  1. Changing my group type to domain local (not helped again)

And nested groups works perfectly with global group.

My problem with only a users, that doesn’t have spaces in CN and disabled.

My filters, your filters - all looks good, when i test it in ADUC (same results).

Seems to be a little bug in openfire code

So, no ideas what to do? It’s not a bug?

I’m unble to reproduce…so I don’t know what would be causing the issue. maybe try upgrading java/jre?

I’m using Java 6 u45. With Java 7, SSPI plugin doesn’t work correctly last time.

I’ll try to upgrade on this week, ok.

Try to purge the groups cache or restart Openfire.

Did you use LdapBrowser or something similar to verify that your filter works as expected?

I’ve restarted Openfire after each filter change.

I use ADUC console, it shows correct results, disabled users are filtered.

Also, i dont see those users in Openfire Users\Groups tab, they appear only in error log

I think the problem is here:

at org.jivesoftware.openfire.roster.Roster.(Roster.java:190)
at org.jivesoftware.openfire.net.StanzaHandler.processPresence(StanzaHandler.java: 355)

Some rosters still contain the disabled account and so Openfire would like to send a presence update. As it is an internal account it seems to check whether this user exists and then this problem is logged.