RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1020087 - gss_display_name() failed: A required input parameter could not be read: An invalid name was supplied (, Unknown error)
Summary: gss_display_name() failed: A required input parameter could not be read: An i...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: mod_auth_kerb
Version: 6.4
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Luboš Uhliarik
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-10-17 01:52 UTC by Jan Pazdziora
Modified: 2021-03-11 14:12 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-10-18 07:53:31 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Jan Pazdziora 2013-10-17 01:52:51 UTC
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.

When I kinit as user, authentication works. When however I kdestroy -A and kinit with just user (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
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
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 Program Management 2013-10-17 02:09:35 UTC
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 12:36:54 UTC
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 07:30:46 UTC
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 08:07:43 UTC
(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 09:37:00 UTC
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 13:49:19 UTC
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.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 07:53:19 UTC
Closing.

Comment 15 Jan Pazdziora 2017-10-18 07:53:31 UTC
Closing.


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