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 1199636 - auth for ipa tools breaks after exporting keytabs
Summary: auth for ipa tools breaks after exporting keytabs
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: ipa
Version: 6.6
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: rc
: ---
Assignee: IPA Maintainers
QA Contact: Namita Soman
URL:
Whiteboard:
Depends On:
Blocks: 1199649
TreeView+ depends on / blocked
 
Reported: 2015-03-06 20:09 UTC by Martin Bukatovic
Modified: 2015-03-12 12:55 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-03-12 12:55:31 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
keytab setup script (4.58 KB, text/plain)
2015-03-06 20:12 UTC, Martin Bukatovic
no flags Details
example of host-principal-keytab-list.csv (4.97 KB, text/plain)
2015-03-06 20:14 UTC, Martin Bukatovic
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1199649 0 unspecified CLOSED rhs-hadoop kerberos issues tracker BZ 2021-02-22 00:41:40 UTC

Internal Links: 1199649

Description Martin Bukatovic 2015-03-06 20:09:31 UTC
Description of problem
======================

I wrote script automating kerberos keytab setup which uses ipa-getkeytab
tool to do the job. The problem is that after exporting several keytabs, this
script breaks authorization for ipa admin tools (so that it's no longer
possible to use eg. ipa user-show).

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

# rpm -qa | egrep '(^ipa|krb|sssd)'
krb5-libs-1.10.3-33.el6.x86_64
sssd-ad-1.11.6-30.el6_6.3.x86_64
sssd-proxy-1.11.6-30.el6_6.3.x86_64
sssd-1.11.6-30.el6_6.3.x86_64
python-krbV-1.0.90-3.el6.x86_64
sssd-client-1.11.6-30.el6_6.3.x86_64
krb5-server-1.10.3-33.el6.x86_64
sssd-common-1.11.6-30.el6_6.3.x86_64
sssd-common-pac-1.11.6-30.el6_6.3.x86_64
sssd-ipa-1.11.6-30.el6_6.3.x86_64
sssd-krb5-1.11.6-30.el6_6.3.x86_64
python-sssdconfig-1.11.6-30.el6_6.3.noarch
ipa-client-3.0.0-42.el6.x86_64
ipa-server-3.0.0-42.el6.x86_64
ipa-pki-common-theme-9.0.3-7.el6.noarch
ipa-pki-ca-theme-9.0.3-7.el6.noarch
pam_krb5-2.3.11-9.el6.x86_64
krb5-workstation-1.10.3-33.el6.x86_64
sssd-krb5-common-1.11.6-30.el6_6.3.x86_64
sssd-ldap-1.11.6-30.el6_6.3.x86_64
ipa-python-3.0.0-42.el6.x86_64
ipa-admintools-3.0.0-42.el6.x86_64
ipa-server-selinux-3.0.0-42.el6.x86_64

How reproducible
================

100% (for my cluster configuration - see below)

Steps to Reproduce
==================

The setup of the cluster is completelly automated and so I would be able to
provide access to broken cluster on request. Quick description including the
way we use ipa tools to make it clear how we use it follows:

1)    setup cluster with 3 nodes with IPA
1.1)  master is configured as ipa server
      code snipplet used to install ipa-server:

~~~
rlRun "ipa-server-install \
  --hostname=${GH_IPASERVER} \
  --ip-address=${ip} \
  --realm=${GH_IPA_REALM} \
  --domain=${GH_IPA_DOMAIN} \
  --ds-password=${GH_IPA_PASSWD} \
  --admin-password=${GH_IPA_PASSWD} \
  --unattended \
  --no-ntp"
~~~

1.2) two nodes are configured as ipa clients
     code snipplet:

~~~
rlRun "ipa-client-install \
  --server=${GH_IPASERVER} \
  --realm=${GH_IPA_REALM} \
  --domain=${GH_IPA_DOMAIN} \
  --principal=${GH_IPA_ADMIN} \
  --password=${GH_IPA_PASSWD} \
  --unattended \
  --mkhomedir"
~~~

1.3) create some users via ipa add-user (not sure if needed)
     code snipplet:

~~~
rlRun "ipa user-add ${name} --first ${name} --last ${name} \
  --homedir ${home} --shell ${shell} --noprivate \
  --uid ${uid} --gidnumber ${gid}"
~~~

2) run the keytab script on master machine (admin ticket is requred):

~~~
# kinit admin
# ipa-hadoop-service-setup.sh $HOSTNAME host-principal-keytab-list.csv
~~~

Where:

 * ipa-hadoop-service-setup.sh - script attached to this BZ, creates keytabs
 * $HOSTNAME should contain fqdn of master machine
 * host-principal-keytab-list.csv - contains descript of keytabs, attached as
   well

Note: To catch the moment when the problem happens, I added the following code
after every operation with keytabs:

~~~
ipa user-show ambari-qa
if [[ $? -ne 0 ]]; then
  echo "fail: IPA is broken!" >&2
  exit 22
fi
~~~

Actual results
==============

During the key export phase, IPA auth for cli admin tolls stops working
completelly.

~~~
# exporting keytab for hbase.COM on dhcp-lab-193.englab.brq.redhat.com
Keytab successfully retrieved and stored in: tmp.keytab
  User login: ambari-qa
  First name: ambari-qa
  Last name: ambari-qa
  Home directory: /home/ambari-qa
  Login shell: /bin/bash
  Email address: ambari-qa.redhat.com
  UID: 20507
  GID: 20400
  Account disabled: False
  Password: False
  Member of groups: ipausers
  Kerberos keys available: True
  User login: ambari-qa
  First name: ambari-qa
  Last name: ambari-qa
  Home directory: /home/ambari-qa
  Login shell: /bin/bash
  Email address: ambari-qa.redhat.com
  UID: 20507
  GID: 20400
  Account disabled: False
  Password: False
  Member of groups: ipausers
  Kerberos keys available: True
tmp.keytab                                                                           100%  290     0.3KB/s   00:00
  User login: ambari-qa
  First name: ambari-qa
  Last name: ambari-qa
  Home directory: /home/ambari-qa
  Login shell: /bin/bash
  Email address: ambari-qa.redhat.com
  UID: 20507
  GID: 20400
  Account disabled: False
  Password: False
  Member of groups: ipausers
  Kerberos keys available: True
# exporting keytab for HTTP/dhcp-lab-193.englab.brq.redhat.com.COM on dhcp-lab-193.englab.brq.redhat.com
Keytab successfully retrieved and stored in: tmp.keytab
ipa: ERROR: Insufficient access: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information (KDC returned error string: 2ND_TKT_SERVER)
fail: IPA is broken!
~~~

In this case, keytab was successfully exported for
hbase.COM, but the next export for
HTTP/dhcp-lab-193.englab.brq.redhat.com.COM fails (which is
13th keytab being created there).

Then I can try to reauthenticate, but this doesn't help:

~~~
# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: admin.COM

Valid starting     Expires            Service principal
03/06/15 19:32:02  03/07/15 19:31:56  krbtgt/RHSHADOOPQA.REDHAT.COM.COM
03/06/15 19:33:22  03/07/15 19:31:56  HTTP/dhcp-lab-193.englab.brq.redhat.com.COM
03/06/15 19:37:39  03/07/15 19:31:56  ldap/dhcp-lab-193.englab.brq.redhat.com.COM
03/06/15 19:37:42  03/07/15 19:31:56  host/dhcp-lab-171.englab.brq.redhat.com.COM
03/06/15 19:38:55  03/07/15 19:31:56  host/dhcp-lab-193.englab.brq.redhat.com.COM
# kdestroy
# klist
klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_0)
# kinit admin
Password for admin.COM:
# ipa user-show ambari-qa
ipa: ERROR: cannot connect to u'https://dhcp-lab-193.englab.brq.redhat.com/ipa/xml': Authorization Required
# keyctl list @s
1 key in keyring:
192158270: --alswrv     0    -1 keyring: _uid.0
#
~~~

Note that keyctl doesn't show auth cookie as expected for some reason.

Expected results
================

Authorization is not broken after running given script so that I'm still able
to use ipa admin tools as admin user.

Eg. this would still work as shown below:

~~~
# kinit admin
# ipa user-show ambari-qa
  User login: ambari-qa
  First name: ambari-qa
  Last name: ambari-qa
  Home directory: /home/ambari-qa
  Login shell: /bin/bash
  Email address: ambari-qa.redhat.com
  UID: 20507
  GID: 20400
  Account disabled: False
  Password: False
  Member of groups: ipausers
  Kerberos keys available: False
# keyctl list @s
2 keys in keyring:
192158270: --alswrv     0    -1 keyring: _uid.0
816027917: --alswrv     0     0 user: ipa_session_cookie:admin.COM
~~~

Additional info
===============

While it is possible that my keytab script is not optimal (comments welcome),
it should not break authorization for ipa tools.

Comment 1 Martin Bukatovic 2015-03-06 20:12:43 UTC
Created attachment 998995 [details]
keytab setup script

Comment 2 Martin Bukatovic 2015-03-06 20:14:21 UTC
Created attachment 998996 [details]
example of host-principal-keytab-list.csv

Comment 4 Petr Vobornik 2015-03-09 13:30:38 UTC
I think the problem is that with:

# exporting keytab for HTTP/dhcp-lab-193.englab.brq.redhat.com.COM on dhcp-lab-193.englab.brq.redhat.com
Keytab successfully retrieved and stored in: tmp.keytab

you created new keytab for HTTP service of IPA server, but httpd still uses the old keytab(at /etc/httpd/conf/ipa.keytab ) therefore the IPA API call, which is hosted there, fails:

# ipa user-show ambari-qa
ipa: ERROR: cannot connect to u'https://dhcp-lab-193.englab.brq.redhat.com/ipa/xml': Authorization Required

Comment 5 Petr Vobornik 2015-03-09 13:33:05 UTC
Also, you can use --retrive option of ipa-getkeytab to retrieve it instead of generating a new one.

Comment 6 Martin Bukatovic 2015-03-09 16:10:20 UTC
Thank you, I did check examples from documentation which uses exactly same
workflow (export keytab and copy it to the right place via scp)[1], but missed
that the key is being regenerated.

That said, the '--retrieve' option is not included in ipa-getkeytab from RHEL 6
(ipa-client-3.0.0-42.el6.x86_64). Is there any other clean way how to export
keytab without regeneration? Skimming through the RHEL 6 IPA docs doesn't seem
to provide any answer. If not, would krb5 tools usage be ok? Eg:

kadmin.local -q "xst -keytab tmp.keytab HTTP/dhcp-lab-193.englab.brq.redhat.com.COM"

[1] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/Installing_the_IPA_Client_on_Linux.html#client-basic-setup

Comment 7 Petr Vobornik 2015-03-09 18:00:43 UTC
kadmin.local -q "xst -keytab tmp.keytab HTTP/dhcp-lab-193.englab.brq.redhat.com.COM"

will randomize the keys as well. To avoid that, use -norandkey option:

kadmin.local -q "xst -norandkey -keytab tmp.keytab HTTP/dhcp-lab-193.englab.brq.redhat.com.COM"

But -norandkey works only with kadmin.local so you have to copy the keytab to the target machine which may be suboptimal.

I would recommend to use RHEL 7 if possible because this issue was fixed in bug 1007367.

Comment 8 Martin Bukatovic 2015-03-10 12:15:09 UTC
Thank you, I have cloned the bz asking for fixing rhel 6 as well - BZ 1200357,
since our usecase is running secure hadoop mode which is currently certified on
rhel 6 only.

Comment 9 Petr Vobornik 2015-03-12 12:55:31 UTC
Closing, works as expected.


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