Authorizing a user with tigase.db.ldap.LdapAuthProvider
This is Tigase-5.2.0-b3447/48635d0a (2014-02-12/17:29:15) and the client is using pidgin-2.10.9 (Linux/OpenSuSE 13.1 for both). The site is very small, a family business. All users known to LDAP are supposed to be able to use XMPP. I'm using --auth-db = tigase.db.ldap.LdapAuthProvider.
The administrator account can log in and seems to be using Tigase normally.
A user (testacct) has not used Tigase before, but has used the previous XMPP server, DJabberd, and so has an account saved by Pidgin. After thrashing around trying to deal with the problem reported here, he deletes this account, and creates a new one (identical), and marks the checkbox "Create this new account on the server", and hits Save. Pidgin pops the form that Tigase sends back (username password email) and the user fills it out and sends it back. Tigase replies: error code='500' internal-server-error.
Ignoring minor details, the user enables the account, is asked for and gives his password, and is accepted. He can do IM to other users and vice versa, but cannot become a buddy.
The console message (shown below) says that LdapAuthProvider refused to add this user, and on roster requests the user is told that his session is not yet authorized. It's understood that Tigase would never be given write access to LDAP so as to "add" a user, but how can this user become authorized as seen by Tigase? The ideal would be to implicitly "provision" any user whose password matched the one known to LDAP.
These messages from /var/log/tigase/tigase-console.log were collected in not quite the order described, hence the non-monotonic timestamps.
User tries to register and gets error code 500:
2014-06-16 22:40:10.878 [jabber:iq:register Queue Worker 0] RepositoryAccess.register() SEVERE: Repository access exception.
tigase.db.TigaseDBException: Not available
at tigase.db.ldap.LdapAuthProvider.addUser(LdapAuthProvider.java:133) at tigase.db.AuthRepositoryMDImpl.addUser(AuthRepositoryMDImpl.java:81) at tigase.xmpp.RepositoryAccess.register(RepositoryAccess.java:473) at tigase.xmpp.impl.JabberIqRegister.process(JabberIqRegister.java:234) at tigase.server.xmppsession.SessionManager$ProcessorWorkerThread.process(SessionManager.java:2681) at tigase.util.WorkerThread.run(WorkerThread.java:132)
User authenticates and doesn't get his roster or vCard:
2014-06-16 17:53:41.150 [vcard-temp Queue Worker 1] VCardTemp.processFromUserToServerPacket() WARNING: Received vCard request but user session is not authorized yet: firstname.lastname@example.org/2001:470:1f05:844:0:0:0:3_5222_2001:470:1f05:844:201:c0ff:fe12:4a2a_45556, email@example.com, DATA=, SIZE=125, XMLNS=jabber:client, PRIORITY=NORMAL, PERMISSION=NONE, TYPE=get
2014-06-16 17:53:41.226 [jabber:iq:roster Queue Worker 3] JabberIqRoster.process() WARNING: Received roster request but user session is not authorized yet: firstname.lastname@example.org/2001:470:1f05:844:0:0:0:3_5222_2001:470:1f05:844:201:c0ff:fe12:4a2a_45556, email@example.com, DATA=, SIZE=131, XMLNS=jabber:client, PRIORITY=NORMAL, PERMISSION=NONE, TYPE=get
My init.properties file: (TLS is actually being used.)
Generated by Tigase's installer, then edited by jimc, 2014-06-15
Name of virtual host(s)
--virt-hosts = jfcarter.net
- No anonymous logins allowed:
--vhost-anonymous-enabled = false
- Should TLS be required? Default=false. Turn on when debugging is finished.
--vhost-tls-required = false
- TLS has SNI (Server Name Indication); with SSL use this host cert:
--ssl-def-cert-domain = jfcarter.net
--user-db-uri = jdbc:derby:/var/lib/tigase
--user-db = derby
--admins = firstname.lastname@example.org
- Authentication, host integrated with LDAP
--auth-db = tigase.db.ldap.LdapAuthProvider
--auth-db-uri = ldap://localhost:389
basic-conf/auth-repo-params/user-dn-pattern = uid=%1$s,ou=people,dc=cft,dc=ca,dc=us
Logging (see "Debugging Tigase" in admin guide)
What to debug, comma separated list
--debug = server
- Size of log file before rotation (with --debug=server, produces over 10Mb/day)
- Number of log files to keep
--comp-name-3 = proxy
config-type = --gen-config-def
--comp-name-2 = pubsub
--comp-name-1 = muc
--cluster-mode = false
--sm-plugins = -message-archive-xep-0136,+jabber:iq:auth,+urn:ietf:params:xml:ns:xmpp-sasl,+urn:ietf:params:xml:ns:xmpp-bind,+urn:ietf:params:xml:ns:xmpp-session,+jabber:iq:register,+jabber:iq:roster,+presence,+jabber:iq:privacy,+jabber:iq:version,+http://jabber.org/protocol/stats,+starttls,+msgoffline,+vcard-temp,+http://jabber.org/protocol/commands,+jabber:iq:private,+urn:xmpp:ping,+basic-filter,+domain-filter,+pep,-zlib
--comp-class-3 = tigase.socks5.Socks5ProxyComponent
--comp-class-2 = tigase.pubsub.PubSubComponent
--comp-class-1 = tigase.muc.MUCComponent
Added by Artur Hefczyc over 4 years ago
Hm, this is interesting and quite unexpected. Maybe the user credentials were left in memory cache after registration attempt, hence the user can login but once the Tigase is restarted he may no longer be able to login? Another possibility is that the user credentials are still in LDAP and it just happened that the user provided the same login details as for he old account, so Tigase allows the user to login.
The problem with become buddy comes from the fact that the user might be in LDAP (Auth repository) but he might be not in the Derby DB (all XMPP data repository). This often happens when there is a separate database for auth and other data that these 2 are out of sync.
You can force Tigase to keep user DB in sync by adding following parameter to the --user-db-uri property:
So the entire line should look like this:
--user-db-uri = jdbc:derby:/var/lib/tigase;autoCreateUser=true
Added by Jim Carter over 4 years ago
@Artur, thank you very much, this is exactly what I need. I set it up per the example, and now the testacct user can become a buddy, can see other users' presence, and can edit his own vCard. In other words, what I described as "implicit provisioning" is now working. Thank you again.
Plus, the whole thing is happening over IPv6, which I need to use for other services.
On my net the user's UNIX account (shell, IMAP e-mail, etc.) is created first, so LDAP knows about him. Then, the configurations of the various servers determine what services he receives, if any. For XMPP, all users are supposed to be able to use it, and now that's working.