Exchange 2007 Bug - Incorrect broadcasts malformed Kerberos auth tokens for POP3/IMAP access
Hi i am having major problems connecting my PHP scripts to my exchange 2007 server. I know POP3 access is ok as i can access via Outlook Express and all works well. However when connecting via PHP the connection attempt bombs as the PHP client drops the connection fearing a security breach: http://forums.kayako.com/f56/supportsuite-pop3-exchange-2007-a-11337/index4.html "The fundamental problem here is that Exchange 2007 has a bug wherein it incorrectly broadcasts malformed Kerberos auth tokens, even if Kerberos is completely disabled. PHP's IMAP driver is unable to understand what it sees, because it makes a good faith attempt to interpret the Kerberos tags, and shuts down the stream when it fails, fearing security breach.Ruby on Rails' driver should do the same thing, but does not. There are two ways to fix this, and there is one step that we believe should be taken by any customer undergoing these problems.1) You can fix this by running a not-broken mail transfer agent. Other versions of Exchange do not have this defect, nor do MTAs like QMail, Postfix, Exim, et cetera. Unfortunately, Exchange has a lot of heavily used business logic, and so retreating even to a prior, correctly functioning version is frequently unrealistic for certain businesses. 2) You can fix this by recompiling PHP's IMAP driver without Kerberos support. When the IMAP driver doesn't know about Kerberos, it discards the auth tags, and begins to treat the stream as a normal stream (in the way that Ruby's driver does, but shouldn't.) This process is platform specific, and sometimes involves minor adjustments to your SSL configuration. Instructions on such a recompile can be found here:PHP: IMAP - Manual" Can someone from Microsoft please investigate this purported bug as a matter of urgency... it certainly seems a real bug to me. Many thanks, Chris
October 11th, 2008 12:42pm
Was there ever an update or a solution to this? I'm having the same problem... and is it possible to have someone from Microsoft respond to this?
December 30th, 2008 7:28pm
Bump Bump. Me too.--joshman
March 24th, 2009 7:44am
I am also having this problem and it is a major setback. We are also using the Kayako SupportSuite. One solution is to re-compile php and disable kerberos on the php server side of things, but that isn't possible for us (hosted environment).Can we please get a reply from someone at Microsoft about this problem, because it doesn't exist in Exchange 2003.
June 15th, 2009 1:03pm
I confirm the issue is present in Exchange 2007 only. Ruby, PHP and other imap libraries with kerberos support can't communicate with Exchange 2007. As workaround, you may build them without kerberos support. Though, Exchange 2007 should offer a normal authentication when kerberos failed.
June 23rd, 2009 12:07pm
This is a major issue for me too. I see that Micro$oft is doing it's usual, and treating it's customers with utter contempt. Microsoft! Please fix this BUG or at least respond!!! Nick
August 28th, 2009 6:42pm
any update to this? I too have the problem.
October 21st, 2009 8:13am
THERE is NO fix for this. The only way I could work around it was to install PHP 5.3 on the Linux box. That has it built in to force POP without SASL or other authentication mechanisms that the exchange server does not have, the otehr option may be to install a valid (not self signed) secure certifiacte on exchange. Here is the WHOLE story: Background: we use eSupport for ticket management, so it needs to POP form the exchange server. This broke after the exchange 2003 -> 2007 upgrade so we moved the mailboxes to the Linux box until I could figure it out. Below is what I did to figure it out: What a nightmare. but 4 hours later i figured it out. Phase 1 - attempt to get Linux box to accept SSL authentication from SETH server (out exchange server) - even though Seth has a SLL self-assigned SSL cert Reconfigure firewall 1) create POP3-SSL service - port 995 2) add to firewall rule edit system files 1) hosts file 10.10.131.3 seth remote.digitalfoundation.net SETH.DF-HQ.local 2) /etc/sysconfig/iptables -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --source 10.10.131.3 -j ACCEPT 3) iptables restart Export from IIS: 1) choose export - export as pfx file note password used 2) copy to linux box Determine openssl default directory: 1) openssl version -d 2) note this path Reference: http://www.madboa.com/geek/openssl/ Convert: # Export the private key file from the pfx file openssl pkcs12 -in /usr/backups/sbs.pfx -nocerts -out /usr/backups/sbs-key.pem enter password used in Export from IIS step create & note PEM passphrase # Export the certificate file from the pfx file openssl pkcs12 -in /usr/backups/sbs.pfx -clcerts -nokeys -out /usr/backups/sbs-cert.pem # This removes the passphrase from the private key so Apache won't # prompt you for your passphase when it starts openssl rsa -in /usr/backups/sbs-key.pem -out /usr/backups/sbs-server.key References: http://www.petefreitag.com/item/16.cfm Verify: openssl x509 -noout -fingerprint -in /usr/backups/sbs-cert.pem Copy: 1) cp /usr/backups/sbs-cert.pem /etc/pki/tls/certs Note: copy to the CERTS directory of the OpenSSL default directory Hash: 1) openssl x509 -noout -hash -in /etc/pki/tls/certs/sbs-cert.pem 2) note hash value Link: 1) cd /etc/tls/pki 2) ln -s certs/sbs-cert.pem <hash value>.0 test: openssl verify -purpose sslclient -CApath /etc/pki/tls/certs sbs-cert.pem openssl verify -CApath /etc/pki/tls/certs sbs-cert.pem TEST 1) fetchmail seth.df-hq.local -u support FAIL!!! I can get fetchmail to work if I specify the cert to use but how do I get the PHP app to specify what cert to use?!?!? Phase II - check for ways around the Kerberos incompatibiilty I found a fix for this in PHP 5.3 Newer must be better right? Upgrade PHP from 5.1 to 5.3 from: http://www.webtatic.com/blog/2009/06/php-530-on-centos-5/ eSupport is down! Must Upgrade Zend Optimizer FAIL! Zend does not have a build for PHP 5.3 even though PHP 5.3 is almost a year old! Switch esupport to IonCube This works! Change all the email accounts to POP from exchange again! So the REAL benefit is taht we can easily monitor the support mailboxes to ensure the queue does not get stuck. In addition I hope we can drag and drop emails into the queue again! --joshman
December 14th, 2010 12:17pm