Greetings,
We just upgraded our management nodes last week to new hardware and software (IBM x3550, CentOS 4.5 x86_64). We're running VAS 3.1.1-45. The latest mod_auth_vas appeared to compile and install cleanly, however, we are always prompted for login. Here is the entire request, with debug. Please note the two error lines at the end:
[Tue Aug 07 11:19:42 2007] [debug] mod_auth_vas.c(2109): [client IP_ADDRESS] auth_vas_check_user_id: auth_type=VAS
[Tue Aug 07 11:19:42 2007] [debug] mod_auth_vas.c(2140): [client IP_ADDRESS] sending initial negotiate headers
[Tue Aug 07 11:19:42 2007] [debug] mod_auth_vas.c(2109): [client IP_ADDRESS] auth_vas_check_user_id: auth_type=VAS
[Tue Aug 07 11:19:42 2007] [debug] mod_auth_vas.c(2157): [client IP_ADDRESS] Got: 'Authorization: Negotiate [...]'
[Tue Aug 07 11:19:42 2007] [debug] mod_auth_vas.c(1482): [client IP_ADDRESS] do_gss_spnego_accept: line='YIIHggYGKwYBBQUC...'
[Tue Aug 07 11:19:42 2007] [debug] mod_auth_vas.c(1404): [client IP_ADDRESS] rnote_get: creating rnote
[Tue Aug 07 11:19:42 2007] [debug] mod_auth_vas.c(1520): [client IP_ADDRESS] calling vas_gss_spnego_accept, base64 token_size=2568
[Tue Aug 07 11:19:42 2007] [error] [client IP_ADDRESS] vas_gss_spnego_accept: VAS_ERR_INTERNAL: First call to gss_accept_sec_context() failed, minor_status = -1765328353, result = 851968, display_status = Unknown error 851968
[Tue Aug 07 11:19:42 2007] [error] [client IP_ADDRESS] vas_gss_spnego_accept: VAS_ERR_INTERNAL: First call to gss_accept_sec_context() failed, minor_status = -1765328353, result = 851968, display_status = Unknown error 851968
[Tue Aug 07 11:19:42 2007] [debug] mod_auth_vas.c(1375): [client IP_ADDRESS] auth_vas_cleanup_request
I've gone through and double checked my configuration, aliases, etc. and everything seems to be set up properly. I've tested this with the latest release and trunk. Please let me know if there is anything else I can do to troubleshoot and/or fix this.
Also, I've noticed some discussion about REMOTE_USER not getting set properly for non-Unix enabled users. We too experience this behavior. Has this been fixed?
Thanks,
Brendon Colby
We just upgraded our management nodes last week to new hardware and software (IBM x3550, CentOS 4.5 x86_64). We're running VAS 3.1.1-45. The latest mod_auth_vas appeared to compile and install cleanly, however, we are always prompted for login. Here is the entire request, with debug. Please note the two error lines at the end:
[Tue Aug 07 11:19:42 2007] [debug] mod_auth_vas.c(2109): [client IP_ADDRESS] auth_vas_check_user_id: auth_type=VAS
[Tue Aug 07 11:19:42 2007] [debug] mod_auth_vas.c(2140): [client IP_ADDRESS] sending initial negotiate headers
[Tue Aug 07 11:19:42 2007] [debug] mod_auth_vas.c(2109): [client IP_ADDRESS] auth_vas_check_user_id: auth_type=VAS
[Tue Aug 07 11:19:42 2007] [debug] mod_auth_vas.c(2157): [client IP_ADDRESS] Got: 'Authorization: Negotiate [...]'
[Tue Aug 07 11:19:42 2007] [debug] mod_auth_vas.c(1482): [client IP_ADDRESS] do_gss_spnego_accept: line='YIIHggYGKwYBBQUC...'
[Tue Aug 07 11:19:42 2007] [debug] mod_auth_vas.c(1404): [client IP_ADDRESS] rnote_get: creating rnote
[Tue Aug 07 11:19:42 2007] [debug] mod_auth_vas.c(1520): [client IP_ADDRESS] calling vas_gss_spnego_accept, base64 token_size=2568
[Tue Aug 07 11:19:42 2007] [error] [client IP_ADDRESS] vas_gss_spnego_accept: VAS_ERR_INTERNAL: First call to gss_accept_sec_context() failed, minor_status = -1765328353, result = 851968, display_status = Unknown error 851968
[Tue Aug 07 11:19:42 2007] [error] [client IP_ADDRESS] vas_gss_spnego_accept: VAS_ERR_INTERNAL: First call to gss_accept_sec_context() failed, minor_status = -1765328353, result = 851968, display_status = Unknown error 851968
[Tue Aug 07 11:19:42 2007] [debug] mod_auth_vas.c(1375): [client IP_ADDRESS] auth_vas_cleanup_request
I've gone through and double checked my configuration, aliases, etc. and everything seems to be set up properly. I've tested this with the latest release and trunk. Please let me know if there is anything else I can do to troubleshoot and/or fix this.
Also, I've noticed some discussion about REMOTE_USER not getting set properly for non-Unix enabled users. We too experience this behavior. Has this been fixed?
Thanks,
Brendon Colby