Bug 1020087 - gss_display_name() failed: A required input parameter could not be read: An invalid name was supplied (, Unknown error)
gss_display_name() failed: A required input parameter could not be read: An i...
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: mod_auth_kerb (Show other bugs)
6.4
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Web Stack Team
BaseOS QE Security Team
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-16 21:52 EDT by Jan Pazdziora
Modified: 2017-10-18 03:53 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-10-18 03:53:31 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jan Pazdziora 2013-10-16 21:52:51 EDT
Description of problem:

In domain .company.com, there is company-wide configured Kerberos infrastructure with realm COMPANY.COM. Furthermore, for testing purposes I've set up an IPA server ipa.dom1.company.com with realm EXAMPLE.COM and http server www.dom2.company.com, configured with mod_auth_kerb with keytab for service principal HTTP/www.dom2.company.com@EXAMPLE.COM.

When I kinit as user@EXAMPLE.COM, authentication works. When however I kdestroy -A and kinit with just user@COMPANY.COM (and no ticket @EXAMPLE.COM), access from Firefox 24 (Fedora 19) to the protected location of http server www.dom2.company.com yields 500 Internal Server Error and message

gss_display_name() failed: A required input parameter could not be read: An in
valid name was supplied (, Unknown error)

in the error_log.

Version-Release number of selected component (if applicable):

# rpm -q httpd mod_auth_kerb
httpd-2.2.15-26.el6.x86_64
mod_auth_kerb-5.4-9.el6.x86_64

How reproducible:

Deterministic on RHEL 6 and Fedora 19.

Steps to Reproduce:
1. Install the http server and mod_auth_kerb:
# yum install -y mod_auth_kerb
2. Get keytab for the service principal -- on IPA-enrolled client, something like:
# ipa-getkeytab -s ipa.example.com -k /etc/http.keytab -p HTTP/$( hostname )
# chown apache /etc/http.keytab
# chmod 600 /etc/http.keytab
3. Configure the mod_auth_kerb (in file like /etc/httpd/conf.d/auth_kerb.conf):
 <Location /private>
 AuthType Kerberos
 AuthName "Kerberos Login"
 KrbMethodNegotiate On
 KrbMethodK5Passwd Off
 KrbAuthRealms EXAMPLE.COM
 Krb5KeyTab /etc/http.keytab
 KrbLocalUserMapping On
 require valid-user
 </Location>
4. Create the protected content:
# echo OK > /var/www/html/private
5. Start the httpd server:
# service httpd restart
7. On a client machine, make sure Firefox is configured allow SPNEGO with the http server -- in about:config, network.negotiate-auth.trusted-uris should have .company.com if the server is in .company.com domain.
6. On a client machine, clear any tickets:
$ kdestroy -A
7. Try that protection works -- access http://<the-httpd-fqdn>/private URL from Firefox on the client machine -- expect to get 401 Unauthorized.
8. Obtain correct ticket:
$ kinit user@EXAMPLE.COM
7. Try that authentication works -- access http://<the-httpd-fqdn>/private URL from Firefox on the client machine -- expect to get 200 and see "OK".
9. Purge tickets:
$ kdestroy -A
10. Get ticket from different realm:
$ kinit user@COMPANY.COM
11. Access http://<the-httpd-fqdn>/private URL from Firefox on the client machine.

Actual results:

500 Internal Server Error and in the error_log on the server

gss_display_name() failed: A required input parameter could not be read: An in
valid name was supplied (, Unknown error)

Expected results:

401 Unauthorized or some other status except 500.

Additional info:

Please note that you have to use Firefox to reproduce the issue as the 500 is a result of second HTTP request that Firefox does after the initial 401 response. Neither curl nor LWP do the retry so they cannot be used to test the problem.

Simo suggests

  this could be the IAKERB module trying to get a ticket through
  the server. mod_auth_kerb should intercept this error and return an
  unauthorized header rather than a 500

and

  It's an error condition that is not being properly handled in
  any case, whether the client is right or wrong in what it is doing
  mod_auth_kerb shouldn't throw up like that, it should just log and
  return a 400.
Comment 2 RHEL Product and Program Management 2013-10-16 22:09:35 EDT
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unable to address this
request at this time.

Red Hat invites you to ask your support representative to
propose this request, if appropriate, in the next release of
Red Hat Enterprise Linux.
Comment 3 Jan Kaluža 2013-12-05 07:36:54 EST
I think this is the same bug as Bug 981248. I'm closing this one as DUPLICATE. If you think this is not the same bug, please say so and reopen this one.

*** This bug has been marked as a duplicate of bug 981248 ***
Comment 4 Jan Pazdziora 2014-11-21 02:30:46 EST
Reopening. I see the issue still present with mod_auth_kerb-5.4-13.el6.x86_64 while bug 981248 has Fixed In Version set to mod_auth_kerb-5.4-11.el6.
Comment 5 Jan Pazdziora 2014-11-21 03:07:43 EST
(In reply to Jan Pazdziora from comment #4)
> Reopening. I see the issue still present with
> mod_auth_kerb-5.4-13.el6.x86_64 while bug 981248 has Fixed In Version set to
> mod_auth_kerb-5.4-11.el6.

More specifically, the ISE is no longer there but I see error message

gss_accept_sec_context() failed: Unspecified GSS failure.  Minor code may provide more information (, )

in the ssl_error_log.
Comment 6 Jan Kaluža 2014-11-21 04:37:00 EST
This is different code path than in the original issue and I think it's questionable. In this case, gss_accept_sec_context(...) returns GSS_S_FAILURE instead of GSS_S_CONTINUE_NEEDED. GSS_S_FAILURE is really an error and therefore the error message is showed.

If you are able to reproduce it, could you do it it with "LogLevel Debug"? It should generate following message in error_log: "GSS-API major_status:%8.8x, minor_status:%8.8x", so I would see what's the particular error leading to the GSS_S_FAILURE being returned.
Comment 7 Jan Pazdziora 2014-11-21 08:49:19 EST
Fully acknowledging that this might be completely different case.

The Debug-level info (sanitized) is below:

[debug] src/mod_auth_kerb.c(1944): [client 10.11.12.13] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos, referer: https://...
[debug] src/mod_auth_kerb.c(1279): [client 10.11.12.13] Acquiring creds for HTTP@www.example.com, referer: https://...
[debug] src/mod_auth_kerb.c(1698): [client 10.11.12.13] Verifying client data using KRB5 GSS-API , referer: https://...
[debug] src/mod_auth_kerb.c(1714): [client 10.11.12.13] Client didn't delegate us their credential, referer: https://...
[debug] src/mod_auth_kerb.c(1733): [client 10.11.12.13] GSS-API token of length 9 bytes will be sent back, referer: https://...
[debug] src/mod_auth_kerb.c(1139): [client 10.11.12.13] GSS-API major_status:000d0000, minor_status:000186a5, referer: https://...
[error] [client 10.11.12.13] gss_accept_sec_context() failed: Unspecified GSS failure.  Minor code may provide more information (, ), referer: https://...
Comment 14 Jan Pazdziora 2017-10-18 03:53:19 EDT
Closing.
Comment 15 Jan Pazdziora 2017-10-18 03:53:31 EDT
Closing.

Note You need to log in before you can comment on or make changes to this bug.