Jabber 2.6.1 on Centos 7.4 Our jabber instance is set to authenticate custom clients to a postgresql table in a web app. This works fine right now. We have discovered during a failure of our main authentication servers, that all our linux servers connect and authenticate to via kerberos, that every jabber c2s connection seems to be attempting to authenticate there first. More troubling is that when this failure on our authentication servers failed, no jabber clients could connect even though none of their accounts reside there, they only reside in the postgres database, and these should be completely separate.
I can see the kerberos attempts happening via strace of the c2s process. Is there a way to completely disable or prioritize the postgres auth? Thanks. Below is the authreg section of our c2s.xml file. <!-- Authentication/registration database configuration --> <authreg> <!-- Dynamic authreg modules path --> <path>/usr/lib64/jabberd</path> <!-- Backend module to use --> <module>pgsql</module> <!-- Available authentication mechanisms --> <mechanisms> <!-- These are the traditional Jabber authentication mechanisms. Comment out any that you don't want to be offered to clients. Note that if the auth/reg module does not support one of these mechanisms, then it will not be offered regardless of whether or not it is enabled here. --> <traditional> <plain/> <!-- <digest/> --> </traditional> <!-- SASL authentication mechanisms. Comment out any that you don't want to be offered to clients. Again, if the auth/reg module does not support one of these mechanisms, then it will not be offered. --> <sasl> <plain/> <!-- <digest-md5/> --> <!-- <anonymous/> <gssapi/> --> </sasl> </mechanisms> <!-- Additional mechanisms that are also available when the connection is encrypted. Ie. when START-TLS had been negotiated, or user connected on SSL-wrapped port. --> <ssl-mechanisms> <!-- it's advisable that you disable plain in the above <mechanisms/> section --> <traditional> <plain/> </traditional> <sasl> <plain/> </sasl> </ssl-mechanisms> <!-- SQLite driver configuration <sqlite> Database name <dbname>/var/lib/jabberd/db/sqlite.db</dbname> Transacation support. If this is commented out, transactions will be disabled. This might make database accesses faster, but data may be lost if jabberd crashes. <transactions/> SQLite busy-timeout in milliseconds. <busy-timeout>2000</busy-timeout> </sqlite> MySQL module configuration <mysql> Database server host and port <host>localhost</host> <port>3306</port> Database name <dbname>jabberd2</dbname> Database username and password <user>jabberd2</user> <pass></pass> Passwords in DB may be stored in plain or hashed format NOTE: If you are using hashed passwords, the only auth method that will work is PLAIN. Make sure that you disabled others in 'mechanisms' sections of the config file. <password_type> only one may be enabled here <plaintext/> use crypt(3)ed passwords <crypt/> </password_type> </mysql> --> <!-- PostgreSQL module configuration --> <pgsql> <!-- PostgreSQL connection info. For the rest of the options see http://www.postgresql.org/docs/8.0/interactive/libpq.html <conninfo>dbname=jabberd2 user=jabberd2 password=secret</conninfo>--> <!-- Alternatively you may set connection settings separately. These are used only in absence of 'conninfo' --> <!-- Database server host and port --> <host>{{ AUTHDBHOST }}</host> <port>5432</port> <!-- Database name --> <dbname>{{ AUTHDBNAME }}</dbname> <!-- Database table --> <table>{{ AUTHDBTABLE }}</table> <field> <username>username</username> <password>password</password> <password_hash>password</password_hash> <realm>realm</realm> </field> <!-- Database username and password --> <user>{{ AUTHDBUSER }}</user> <pass>{{ AUTHDBPASS }}</pass> <password_type> <bcrypt cost='10'/> </password_type> </pgsql> <!-- Oracle driver configuration <oracle> Database server host and port. <host>localhost</host> <port>1521</port> Database name <dbname>jabberd2</dbname> Database username and password <user>jabberd2</user> <pass></pass> </oracle> Berkeley DB module configuration <db> Directory to store database files under <path>/var/lib/jabberd/db</path> Synchronize the database to disk after each write. If you disable this, database accesses may be faster, but data may be lost if jabberd crashes. <sync/> </db> --> <!-- LDAPFULL module configuration --> <ldapfull> <!-- LDAP server host and port (default: 389) --> <uri>ldap://localhost/ ldaps://ldap.example.com/</uri> <!-- DN to bind as for searches. If unspecified, the searches will be done anonymously. --> <!-- <binddn>cn=Directory Manager</binddn> <bindpw>secret</bindpw> --> <!-- Type of LDAP server. Currently "ad" for active directory and "ldap" for other ldap servers. If not specified, then it is ldap. --> <!-- <type>ad</type> --> <!-- LDAP attribute that holds the user ID (default: uid) --> <uidattr>uid</uidattr> <objectclass>posixAccount</objectclass> <!-- LDAP attribute that holds the cleartext or hashed password (not needed when pwscheme is set to 'bind') --> <pwattr>userPassword</pwattr> <!-- if you use included jabberd.schema use this: <uidattr>jid</uidattr> <objectclass>jabberUser</objectclass> <pwattr>jabberPassword</pwattr> --> <!-- Attribute that holds jabber account status. Must be TRUE for AD, and 1 for other LDAP server. If not specified, then it will not be used. --> <!-- <validattr>valid</validattr> --> <fulluid/> <!-- If pwscheme is not defined, then passwords are stored in clear text and digest authentication may be done. If passwords are hashed, then you cannot use digest authentication and should use plain text authentication. Any of sha, ssha, crypt, bind and clear may be specified. 'sha' specifies that the attribute in pwattr holds a base-64 encoded SHA-1 hashed password beginning with the string {SHA}. 'ssha' specifies that the attribute in pwattr holds a base-64 SHA-1 hashed password appended with 32 bits of salt and beginning with the string {SSHA}. 'crypt' specifies that the attribute in pwattr holds a UNIX-style crypt(3) hashed password. 'bind' specifies that the password is not stored in an attribute but is authenticated directly by the LDAP server by binding using the user's DN. This should be compatible with the widest variety of LDAP servers. --> <!-- <pwscheme>bind</pwscheme> --> <!-- base DN of the tree. You should specify a DN for each authentication realm declared in the <local/> section above, by using the realm attribute. --> <basedn realm='company'>o=Company.com</basedn> <basedn>o=Example Corp.</basedn> </ldapfull> <!-- LDAP module configuration --> <!-- Remember that you need to use PLAIN auth with LDAP backend --> <ldap> <!-- LDAP server host and port (default: 389) --> <host>ldap.example.com</host> <port>389</port> <!-- Use LDAP v3 if possible. If disabled, v2 will be used. Encryption options are only available if v3 is enabled. --> <!-- <v3/> --> <!-- Encryption. If enabled, this will create an encrypted channel to the LDAP server using the LDAP STARTTLS mechanism. --> <!-- <starttls/> --> <!-- Encryption. If enabled, this will create an encrypted channel to the server using the old-style "ldaps://" mechanism. It is recommended that you use <starttls/> instead of this. --> <!-- <ssl/> --> <!-- DN to bind as for searches. If unspecified, the searches will be done anonymously. --> <!-- <binddn>cn=Directory Manager</binddn> <bindpw>secret</bindpw> --> <!-- LDAP attribute that holds the user ID (default: uid) --> <uidattr>uid</uidattr> <!-- Enable the append-realm element if you want to append realm value (usernam@realm) to the uidattr value <append-realm/> --> <!-- Alternatively to <uidattr/> and <append-realm/> you may specify full LDAP search <query/> that will be used to get user objects from directory. The following replacements take place: %u is replaced by user login name %r is replaced by user login realm When <query/> is specified, <uidattr/> and <append-realm/> are unused and take no effect. --> <!-- <query>(&(mail=%u@%r)(objectClass=inetOrgPerson))</query> --> <!-- base DN of the tree. You should specify a DN for each authentication realm declared in the <local/> section above, by using the realm attribute. --> <basedn realm='company'>o=Company.com</basedn> <basedn>o=Example Corp.</basedn> </ldap> <!-- if you want to configure more than one LDAP server create ldap1, ldap2 etc. sections <ldap1> </ldap1> --> <!-- Pipe module configuration --> <pipe> <!-- Program to execute --> <exec>/usr/bin/pipe-auth.pl</exec> </pipe> </authreg>