Hello all,
Today I faced some seriously daunting NTLM auth woes. I already discussed this with Piotras in #midgard, but he had only few pointers where to look at. So, here's the story.
The production server is already pretty out-dated running: -RedHat 7.3 -Apache 1.3.x -PHP 4.1.x -MySQL 3.26.x -Midgard 1.4.4 -Samba 3.0-alpha
Basically, this setup has been the first (and only) truely operational NTLM authenticated production environment we've had.
There's also a new environment coming up, which I used for testing. The new server runs: -RedHat Enterprise Linux 3 -Apache 1.3.33 -PHP 4.3.x -MySQL 4.0.x -Midgard 1.6.2-CVS-20041216 -Samba 3.0.x (distro defaults)
The current server is still operational, but now there's one user who is unable to access the company intranet due to failing NTLM authentication.
All other company services (requiring SSO) are working properly for the user. I'm also able to authenticate the user from the server command line (with wbinfo and kinit).
We've tried to rename the user account in Active Directory (and Midgard), after which the authentication is successfull!
So, the problem should be neither on the AD nor Midgard settings, but somewhere else. Looking at the Apache logs in the new server, I get the following in the Apache error log:
[Mon Fev 14 13:59:54 2005] [debug] midgard-apache1.c(118): [client 172.20.2.14]
Midgard: NTLM auth request for user \x84 sitegroup 1. NTLM sitegroup -1
[Mon Fev 14 13:59:54 2005] [debug] midgard-apache1.c(142): [client 172.20.2.14]
Midgard: no basic auth found, trying cookie auth
[2005/02/14 13:59:54, 1] libsmb/ntlmssp.c:ntlmssp_update(252)
got NTLMSSP command 1, expected 3
Looking at the production server logs, there's something like this (no debug statements there):
[2005/02/14 13:59:54, 1] libsmb/ntlmssp.c:ntlmssp_server_update(???) got NTLMSSP command 1, expected 3
What concerns me is that " \x84" part, that according to my knowledge means that the username is lost (an empty string) during the request => thus the failing NTLM auth.
Piotras suggested that the problem would be between DC and winbind. However, the authentication is successfull from the server CLI (wbinfo), which AFAIK uses winbind. Since the auth is successfull from here the DC should be working properly too...
So, I'm willing to take any leads where to start looking at. Also, if you've had similar SSO auth problems in AD environments let me know. The client's IT staff has already tried to re-create the user account several times without success...
Cheers!
//Henri
-- Henri Kaukola [EMAIL PROTECTED] Consultant Tel: +358-20-198 6037 Nemein Oy http://www.nemein.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
