Stupid Authentication Issues

**Martin Heiland** · 02-10-2008, 04:04 PM

Does a entry like

auth optional pam_mysql.so host=localhost user=openexchange passwd=<YOURPASSWORDFROMINSTALL> db=open-xchange-db [table=login2user LEFT JOIN user ON login2user.id=user.id AND login2user.cid=user.cid] [where=user.cid=1] usercolumn=login2user.uid passwdcolumn=user.userPassword crypt=1
account required pam_mysql.so host=localhost user=openexchange passwd=<YOURPASSWORDFROMINSTALL> db=open-xchange-db [table=login2user LEFT JOIN user ON login2user.id=user.id AND login2user.cid=user.cid] [where=user.cid=1] usercolumn=login2user.uid passwdcolumn=user.userPassword crypt=1

exist at /etc/pam.d/imap?

**phunyguy** · 02-10-2008, 05:45 PM

Code:

auth optional pam_mysql.so host=/var/run/mysqld/mysqld.sock user=openexchange passwd=************ db=open-xchange-db [table=login2user LEFT JOIN user ON login2user.id=user.id AND login2user.cid=user.cid] [where=user.cid=1] usercolumn=login2user.uid passwdcolumn=user.userPassword crypt=1

auth optional pam_mysql.so host=/var/run/mysqld/mysqld.sock user=openexchange passwd=************ db=open-xchange-db [table=login2user LEFT JOIN user ON login2user.id=user.id AND login2user.cid=user.cid] [where=user.cid=1] usercolumn=login2user.uid passwdcolumn=user.userPassword crypt=1

Yeah it's there, and I have host=/var/run/mysqld/mysqld.sock instead (tried both to no avail). I compared all the configs to the wiki, it all looks great! Only one quick question, I have another mailserver on my network that this one will replace, it uses sasl as well.. it has the same domain name and stuff... not sure if it's clashing, because I'm not sure if when it authenticates it broadcasts to the network or stays local. That's the only other thing I can think of. It is a Fedora 7 machine running Dovecot, mysql, and postfix.

**RBruce** · 02-12-2008, 07:21 AM

I would first want to know if the "openexchange" and "oxadmin" users made it into the SQL database. Near the end of the installer, the 'oxinstaller' script is called, which in turn calls 'createuser.' Your problematic output is from the oxinstaller script. I saw many similar issues on my Fedora installation until I learned to check for results at each step of the process. Are you able to poke around in the mysql database? If so, check the 'mysql' db for user "openexchange" and 'open-xchange-db' for user "oxadmin." It can be useful to rerun the oxinstaller script after changes (not necessarily the entire installation), but keep in mind that a second iteration CAN have "different" issues than the first on a clean system.

In my case, with output similar to yours, I learned...

The oxinstaller script needed some changes in some areas where login credentials were specified. Look to see if "oxadminmaster" can be found in oxinstaller. If so, then you have problems there. I was able to do less tweaking of the script if I used the same password in the script for both 'openexchange' and 'oxadmin.' After this and finding some redhat-specific issues with system groups, I was able to make it stop saying "cannot create user." The new problem was then "unable to create INBOX." Three things that happen during 'createuser" are...

1. /home/[username] gets created, and ownership set.
2. MySQL fields become populated with user values.
3. Cyrus internal mailbox gets created.

You can check for each of these results to help trace reasons for the problematic output. When you rerun oxinstaller after changes with a second (or more) attempt, #1 will cause the process to choke because the dir is already there (so remove it first), #2 will purge some things and start over (but whine about some data which are already there), and #3 (on my system) does not work at all. I was able to fix errors at #1 and either fix or ignore errors at #2. I could not trace #3 to it's cause, so I did this...

Add --dbonly to the createuser process in oxinstaller. This allows #1 and #2 to succeed without being reversed by the failure of #3. Then use cyradm to manually create the Cyrus internal mailbox (must be done in a specific way). The output from my oxinstaller "reruns" are now clean and after creating the Cyrus mailboxes, the users can login.

Again, I am on Fedora so some things will be different, but I read the Debian installer and the whole automated process there is quite similar to what I am doing manually on Fedora. I would start by finding out if missing SQL data is causing the authentication failures. I can do better with specifics, but not sure how much of this applies to your case, and it would be WAY too long if I try to put it all here.

Finally, I too am new (and no developer). I just fought for it and worked hard to find a way to trace things one at a time. If you want more specifics, let me know how much of this seems to make sense in your context. Developers, feel free to rebuff my understanding. I am also looking to validate what I THINK I know about how things work... Bruce

**phunyguy** · 02-12-2008, 12:51 PM

Awesome post man... however, the issue relies solely with the authentication. afaik everything else works. Any time something is compared to the mysql database for authentication, it doesn't work. I can manually put the authentication query in there, and it returns a user / password combo (encrypted of course).

Code:

ox1:/var/run/saslauthd# mysql -D open-xchange-db -u openexchange -p
Enter password:
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 1513
Server version: 5.0.32-Debian_7etch5-log Debian etch distribution

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> select l.uid, u.userPassword from login2user l LEFT JOIN user u on l.id=u.id and l.cid=u.cid;
+---------+---------------+
| uid     | userPassword  |
+---------+---------------+
| oxadmin | {cryptedpass} |
+---------+---------------+
1 row in set (0.00 sec

That tells me both openexchange and oxadmin are both there. In my previous post I gave you auth logs, which clearly showed a PAM issue. I just don't know how to fix, lol.

I can get into the admin website, the normal website, everything, but in the admin site I get an error message across the top of the page that is exactly the same as what i put in the first post.

**phunyguy** · 02-12-2008, 07:57 PM

OK, I came to a conclusion, it has to be something with either pam_mysql.so or mysqld.sock

I can query the database fine and see everything, but the specific issue is the db=open-xchange-db option. It doesn't like it. I moved the options around in /etc/pam.d/imap, and then it gave me a different issue in /var/log/auth.log. The issue was identical to a mysql permission denied when you try to log into the mysql program via command line. "permission denied for 'openexchange'@'localhost - using password (YES)" or whatever the heck it says. when i moved everything back to normal, it went to the db option required issue. is there any way to maybe use an older version of pam-mysql.so or anything?

**RBruce** · 02-13-2008, 01:13 AM

I remember having a similar problem. Again, I assumed my issue to be redhat-specific. I had to build pam-mysql from source, which installed pam-mysql.so in /usr/lib/security. I found that pam expected it to be in /lib/security instead. When I moved it, that problem went away for me. Yours may be OK if installed as Debian package. If not that, could it be related to libnss-mysql configuration? There are two files to configure. The first (libnss-mysql.cfg) carries a lot of SQL queries. The second (libnss-mysql-root.cfg) requires (again) your mysql login credentials (for openexchange user). SQL for me is listening TCP/IP (not .sock).

**RBruce** · 02-13-2008, 01:30 AM

Originally posted by phunyguy View Post

I can query the database fine and see everything, but the specific issue is the db=open-xchange-db option. It doesn't like it.

P.S. When I tried to talk to mysql manually about 'open-xchange-db,' it refused to talk to me about a db name with hyphens in it. Before I figured out why, I had moved on to a GUI tool that handled it for me (probably just syntax error on my part). I still have a suspicion that 'open-xchange-db' (with hyphens) is in some way fragile for some types of command input. It is working though, once I found the troubles which are elsewhere.

**phunyguy** · 02-13-2008, 03:39 AM

yeah, pam_mysql went in /lib/security like it was supposed to. (You could have just created a symlink in case something else expects it to be in /usr/lib/security). I was able to get in via normal SQL queries, so that isn't the issue. I will look at said nss config files and let you know how it turns out. Thanks!

EDIT:
Just found an interesting note in /etc/mysql/my.cnf

Code:

# It has been reported that passwords should be enclosed with ticks/quotes
# especially if they contain "#" chars...

My password has a few "#" in it. I will just blow away the whole thing again with a new password and let you know how it turns out.

**phunyguy** · 02-13-2008, 04:19 AM

THAT WAS IT!!!!! Don't use "#" in your passwords!!!! hahahaha... I own.

Stupid Authentication Issues

Stupid Authentication Issues

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment