subversion + neon + windows + mod_kerb = InitializeSecurityContext SEC_E_INTERNAL_ERROR
alon.barlev at gmail.com
Sun Oct 2 19:40:12 EDT 2011
OK, one full work day for this.
I proved the problem is not in the domain settings or the way I join
machines to the domains.
Same client is working with CentOS configuration is working while Gentoo is not.
The difference between relevant packages are:
dev-libs/openssl-1.0.0e -> also downgraded to openssl-0.9.8f
www-apache/mod_auth_kerb-5.4 -> also downgraded to mod_auth_kerb-5.1
Unfortunately I could not downgrade openssl to 0.9.8e as it segfaults.
The only component I suspect is openssl and the renegotiation modification
that was modified in 0.9.8f.
We had one machine with old TortoiseSVN which complained that it
cannot establish SSL session, so I guess the CentOS openssl is not
patched for the CVE-2007-4995.
Is this sounds familiar to anyone?
On Sun, Oct 2, 2011 at 9:31 PM, Alon Bar-Lev <alon.barlev at gmail.com> wrote:
> More information, I am getting this message once after reboot, found
> no reference for this in the Internet.
> Event Type: Warning
> Event Source: LSASRV
> Event Category: SPNEGO (Negotiator)
> Event ID: 40962
> Date: 10/2/2011
> Time: 9:21:58 PM
> User: N/A
> Computer: VALON
> The Security System was unable to authenticate to the server
> HTTP/correlux-gentoo.correlsense.com because the server has completed
> the authentication, but the client authentication protocol Kerberos
> has not.
> I also created spn using ktpass so I have:
> Keytab name: WRFILE:/etc/alon1.keytab
> KVNO Principal
> ---- --------------------------------------------------------------------------
> 3 HTTP/correlux-gentoo.correlsense.com at CORRELSENSE.COM (arcfour-hmac)
> Just in cast the DC does not accept DES anymore.
> I can see this at setspn -l.
> All other tools are working except of neon...
> On Sun, Oct 2, 2011 at 4:48 PM, Alon Bar-Lev <alon.barlev at gmail.com> wrote:
>> Forgot to mention that when running on the same windows workstation
>> Internet Explorer and Firefox do succeed in authenticating without any
>> problem to the same location.
>> XP and Windows 7 - same behavior.
>> On Sun, Oct 2, 2011 at 4:45 PM, Alon Bar-Lev <alon.barlev at gmail.com> wrote:
>>> On Linux works perfectly!
>>> Configuration is Windows 2003 AD, apache2+mod_auth_kerb-5.4
>>> At server side I don't see any error, but on client side I see
>>> InitializeSecurityContext returning an error.
>>> I see in kerbtray that a valid ticket was acquired at windows side.
>>> Running both as:
>>> TortoiseSVN 1.6.16, Build 21511 - 32 Bit , 2011/06/01 19:00:35
>>> Subversion 1.6.17,
>>> apr 1.3.12
>>> apr-utils 1.3.12
>>> neon 0.29.6
>>> OpenSSL 1.0.0d 8 Feb 2011
>>> zlib 1.2.5
>>> svn, version 1.6.17-SlikSvn-tag-1.6.17 at 1130896-WIN32 (SlikSvn/1.6.17) WIN32
>>> compiled Jun 3 2011, 07:33:44
>>> Neon Log
>>> Running post_send hooks
>>> ah_post_send (#1), code is 201 (want 401), WWW-Authenticate is
>>> Negotiate oYGfMIGcoAMKAQChCwYJKoZIhvcSAQICooGHBIGEYIGBBgkqhkiG9xIBAgICAG9yMHCgAwIBBaEDAgEPomQwYqADAgEXolsEWeZpnkhcM6L/46+tUax3WtI15nBHJ63lGFL3ohcnJUb5qddhrMDQssCL6fYbOtjrUxpGPMplfIlXDxl089lYbUyqcE++7eBFwDDY9l5dT6FJeAvQfKZ8pUfB
>>> auth: SSPI challenge.
>>> InitializeSecurityContext [fail] .
>>> sspi: initializeSecurityContext [failed] .
>>> Request ends, status 201 class 2xx, error line:
>>> 201 Created
>>> Running destroy hooks.
>>> Request ends.
>>> svn: Commit failed (details follow):
>>> svn: MKACTIVITY of '/svn/Test/!svn/act/6694f132-323c-334e-a863-5f6b6ca1d8d9': 20
>>> 1 Created (https://correlux-gentoo.correlsense.com)
>>> httpd Log
>>> Sun Oct 02 16:32:31 2011] [debug] src/mod_auth_kerb.c(1628): [client
>>> 10.10.49.56] kerb_authenticate_user entered with user (NULL) and
>>> auth_type Kerberos
>>> [Sun Oct 02 16:32:31 2011] [debug] src/mod_auth_kerb.c(1240): [client
>>> 10.10.49.56] Acquiring creds for HTTP at correlux-gentoo.correlsense.com
>>> [Sun Oct 02 16:32:31 2011] [debug] src/mod_auth_kerb.c(1385): [client
>>> 10.10.49.56] Verifying client data using KRB5 GSS-API with our SPNEGO
>>> [Sun Oct 02 16:32:31 2011] [debug] src/mod_auth_kerb.c(1401): [client
>>> 10.10.49.56] Client didn't delegate us their credential
>>> [Sun Oct 02 16:32:31 2011] [debug] src/mod_auth_kerb.c(1420): [client
>>> 10.10.49.56] GSS-API token of length 162 bytes will be sent back
>>> I see same httpd messages in working linux client setup.
>>> Has anyone had this? Any clue how to debug this farther?
More information about the neon