830338 – Change DS to purge ticket from krb cache in case of authentication error

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 830338 - Change DS to purge ticket from krb cache in case of authentication error

Summary: Change DS to purge ticket from krb cache in case of authentication error

Keywords:
Status:	CLOSED ERRATA
Alias:	None
Product:	Red Hat Enterprise Linux 6
Classification:	Red Hat
Component:	389-ds-base
Sub Component:
Version:	6.4
Hardware:	Unspecified
OS:	Unspecified
Priority:	medium
Severity:	unspecified
Target Milestone:	rc
Target Release:	---
Assignee:	Rich Megginson
QA Contact:	IDM QE LIST
Docs Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+	depends on / blocked

Reported:	2012-06-08 21:22 UTC by Nathan Kinder
Modified:	2020-09-13 20:10 UTC (History)
CC List:	4 users (show)
Fixed In Version:	389-ds-base-1.2.11.12-1.el6
Doc Type:	Bug Fix
Doc Text:	Cause: DS doesn't refresh its kerberos cache Consequence: If a new kerberos ticket was issused for a host that already authenticated against DS, it would be rejected by DS until it was restarted Fix: flush the kerberos cache on authentication failure Result: first attempt will fail, the cache will be flushed, and the second attempt will succeed.
Clone Of:
Environment:
Last Closed:	2013-02-21 08:17:33 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)

Links
System	ID	Private	Priority	Status	Summary	Last Updated
Github	389ds 389-ds-base issues 366	0	None	None	None	2020-09-13 20:10:56 UTC
Red Hat Product Errata	RHSA-2013:0503	0	normal	SHIPPED_LIVE	Moderate: 389-ds-base security, bug fix, and enhancement update	2013-02-21 08:18:44 UTC

Description Nathan Kinder 2012-06-08 21:22:10 UTC

This bug is created as a clone of upstream ticket:
https://fedorahosted.org/389/ticket/366

Cloning from https://fedorahosted.org/freeipa/ticket/2736

When a user wants to reinstall a replica it hits the problem that DS uses a memory ccache and keeps old tickets (against an old set of keys) in the belly until they expire. If a replica is removed and then recreated with the same name then DS will try to use the old ticket to perform GSSAPI auth during replication. This will fail because the ticket is no longer usable by the new replica.

DS should drop the ticket from the ccache (or drop the whole ccache, whichever is easier) when it gets an authentication error using GSSAPI on replication.

Comment 1 RHEL Program Management 2012-07-10 06:18:05 UTC

This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

Comment 2 RHEL Program Management 2012-07-10 23:00:27 UTC

This request was erroneously removed from consideration in Red Hat Enterprise Linux 6.4, which is currently under development.  This request will be evaluated for inclusion in Red Hat Enterprise Linux 6.4.

Comment 3 mreynolds 2012-08-23 18:48:33 UTC

Manual stesp to reproduce:

Manual steps to reproduce:

[1] yum install ipa-server bind-dyndb-ldap on two systems A & B
[2] on A: ipa-server-install --setup-dns (use Secret123 for passwords, and EXAMPLE.COM for realm)
[3] on A: ipa-replica-prepare <host name for B> --ip-address <IP address of host B>
[4] on A: kinit admin
[5] on A: scp /var/lib/ipa/replica-info-<hostname of B>.gpg root@<host B>:/var/lib/ipa
[6] on B: ipa-replica-install --setup-dns --no-forwarders /var/lib/ipa/replica-info-<hostname of B>.gpg
[7] on A: add a test entry:

    ldapmodify -D "cn=directory manager" -w Secret123 -a
    dn: cn=mytest,dc=example,dc=com
    objectclass: top
    objectclass: groupofnames
    objectclass: groupOfUniqueNames
    cn: mytest

[8] on B: search for the new entry to verify replication is working

    ldapsearch -D "cn=directory manager" -w Secret123 -b "dc=example,dc=com" -xLLL cn=mytest

[9] on A: ipa-replica-manage del <hostname of B>
[10] on B: service stop sssd
[11] on B: ipa-server-install --uninstall -U
[12] on A: ipa-replica-prepare <host name for B> --ip-address <IP address of host B>
[13] on A: scp /var/lib/ipa/replica-info-<hostname of B>.gpg root@<host B>:/var/lib/ipa
[14] on B: ipa-replica-install --setup-dns --no-forwarders /var/lib/ipa/replica-info-<hostname of B>.gpg
[15] on A: check the error log for GSSAPI authentication errors:


If the test passes you should see errors, but then replication should resume:

[27/Jun/2012:10:07:08 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error 49 (Invalid credentials) (SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context) errno 0 (Success)
[27/Jun/2012:10:07:08 -0400] slapi_ldap_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error 49 (Invalid credentials)
[27/Jun/2012:10:07:08 -0400] NSMMReplicationPlugin - agmt="cn=meToibm-ls22-04.rhts.eng.brq.redhat.com" (ibm-ls22-04:389): Replication bind with GSSAPI auth failed: LDAP error 49 (Invalid credentials) (SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context)

[27/Jun/2012:10:07:14 -0400] NSMMReplicationPlugin - agmt="cn=meToibm-ls22-04.rhts.eng.brq.redhat.com" (ibm-ls22-04:389): Replication bind with GSSAPI auth resumed

Comment 5 Scott Poore 2012-09-27 14:16:36 UTC

Verified.

Version ::

389-ds-base-1.2.11.14-1.el6.x86_64

Manual Verification ::

First uninstall and re-install on Replica:

[root@vm2 ~]# ipa-server-install --uninstall -U
Shutting down all IPA services
Removing IPA client configuration
Unconfiguring ntpd
Unconfiguring named
Unconfiguring web server
Unconfiguring krb5kdc
Unconfiguring kadmin
Unconfiguring directory server
Unconfiguring ipa_memcached

[root@vm2 ~]# ps -ef|grep sssd
root      5920  1308  0 09:05 pts/0    00:00:00 grep sssd

[root@vm2 ~]# ssh root.122.111 "ipa-replica-prepare -p PASSWORD --ip-address=192.168.122.112 vm2.testrelm.com"
Preparing replica for vm2.testrelm.com from vm1.testrelm.com
Creating SSL certificate for the Directory Server
Creating SSL certificate for the dogtag Directory Server
Creating SSL certificate for the Web Server
Exporting RA certificate
Copying additional files
Finalizing configuration
Packaging replica information into /var/lib/ipa/replica-info-vm2.testrelm.com.gpg
Adding DNS records for vm2.testrelm.com
Using reverse zone 122.168.192.in-addr.arpa.

[root@vm2 ~]# sftp root.122.111:/var/lib/ipa/replica-info-vm2.testrelm.com.gpg /dev/shm
Connecting to 192.168.122.111...
Fetching /var/lib/ipa/replica-info-vm2.testrelm.com.gpg to /dev/shm/replica-info-vm2.testrelm.com.gpg
/var/lib/ipa/replica-info-vm2.testrelm.com.gpg                       100%   28KB  28.3KB/s   00:00    

[root@vm2 ~]# date
Thu Sep 27 09:06:21 CDT 2012

[root@vm2 ~]# ipa-replica-install -U --setup-dns --forwarder=192.168.122.1 -w PASSWORD -p PASSWORD /dev/shm/replica-info-vm2.testrelm.com.gpg
Run connection check to master
Check connection from replica to remote master 'vm1.testrelm.com':
   Directory Service: Unsecure port (389): OK
   Directory Service: Secure port (636): OK
   Kerberos KDC: TCP (88): OK
   Kerberos Kpasswd: TCP (464): OK
   HTTP Server: Unsecure port (80): OK
   HTTP Server: Secure port (443): OK

The following list of ports use UDP protocol and would need to be
checked manually:
   Kerberos KDC: UDP (88): SKIPPED
   Kerberos Kpasswd: UDP (464): SKIPPED

Connection from replica to master is OK.
Start listening on required ports for remote master check
Get credentials to log in to remote master
Execute check on remote master
Check connection from master to remote replica 'vm2.testrelm.com':
   Directory Service: Unsecure port (389): OK
   Directory Service: Secure port (636): OK
   Kerberos KDC: TCP (88): OK
   Kerberos KDC: UDP (88): OK
   Kerberos Kpasswd: TCP (464): OK
   Kerberos Kpasswd: UDP (464): OK
   HTTP Server: Unsecure port (80): OK
   HTTP Server: Secure port (443): OK

Connection from master to replica is OK.

Connection check OK
Configuring ntpd
  [1/4]: stopping ntpd
  [2/4]: writing configuration
  [3/4]: configuring ntpd to start on boot
  [4/4]: starting ntpd
done configuring ntpd.
Configuring directory server: Estimated time 1 minute
  [1/30]: creating directory server user
  [2/30]: creating directory server instance
  [3/30]: adding default schema
  [4/30]: enabling memberof plugin
  [5/30]: enabling winsync plugin
  [6/30]: configuring replication version plugin
  [7/30]: enabling IPA enrollment plugin
  [8/30]: enabling ldapi
  [9/30]: configuring uniqueness plugin
  [10/30]: configuring uuid plugin
  [11/30]: configuring modrdn plugin
  [12/30]: enabling entryUSN plugin
  [13/30]: configuring lockout plugin
  [14/30]: creating indices
  [15/30]: enabling referential integrity plugin
  [16/30]: configuring ssl for ds instance
  [17/30]: configuring certmap.conf
  [18/30]: configure autobind for root
  [19/30]: configure new location for managed entries
  [20/30]: restarting directory server
  [21/30]: setting up initial replication
Starting replication, please wait until this has completed.
Update in progress
Update in progress
Update in progress
Update in progress
Update in progress
Update succeeded
  [22/30]: adding replication acis
  [23/30]: setting Auto Member configuration
  [24/30]: enabling S4U2Proxy delegation
  [25/30]: initializing group membership
  [26/30]: adding master entry
  [27/30]: configuring Posix uid/gid generation
  [28/30]: enabling compatibility plugin
  [29/30]: tuning directory server
  [30/30]: configuring directory to start on boot
done configuring dirsrv.
Configuring Kerberos KDC: Estimated time 30 seconds
  [1/9]: adding sasl mappings to the directory
  [2/9]: writing stash file from DS
  [3/9]: configuring KDC
  [4/9]: creating a keytab for the directory
  [5/9]: creating a keytab for the machine
  [6/9]: adding the password extension to the directory
  [7/9]: enable GSSAPI for replication
  [8/9]: starting the KDC
  [9/9]: configuring KDC to start on boot
done configuring krb5kdc.
Configuring kadmin
  [1/2]: starting kadmin 
  [2/2]: configuring kadmin to start on boot
done configuring kadmin.
Configuring ipa_memcached
  [1/2]: starting ipa_memcached 
  [2/2]: configuring ipa_memcached to start on boot
done configuring ipa_memcached.
Configuring the web interface: Estimated time 1 minute
  [1/13]: disabling mod_ssl in httpd
  [2/13]: setting mod_nss port to 443
  [3/13]: setting mod_nss password file
  [4/13]: enabling mod_nss renegotiate
  [5/13]: adding URL rewriting rules
  [6/13]: configuring httpd
  [7/13]: setting up ssl
  [8/13]: publish CA cert
  [9/13]: creating a keytab for httpd
  [10/13]: clean up any existing httpd ccache
  [11/13]: configuring SELinux for httpd
  [12/13]: restarting httpd
  [13/13]: configuring httpd to start on boot
done configuring httpd.
Applying LDAP updates
Restarting the directory server
Restarting the KDC
Using reverse zone 122.168.192.in-addr.arpa.
Configuring named:
  [1/8]: adding NS record to the zone
  [2/8]: setting up reverse zone
  [3/8]: setting up our own record
  [4/8]: setting up kerberos principal
  [5/8]: setting up named.conf
  [6/8]: restarting named
  [7/8]: configuring named to start on boot
  [8/8]: changing resolv.conf to point to ourselves
done configuring named.

Global DNS configuration in LDAP server is empty
You can use 'dnsconfig-mod' command to set global DNS options that
would override settings in local named.conf files

Restarting the web server

[root@vm2 ~]# ssh root.122.111 "ipa user-add testuser1 --first=f --last=l"
----------------------
Added user "testuser1"
----------------------
  User login: testuser1
  First name: f
  Last name: l
  Full name: f l
  Display name: f l
  Initials: fl
  Home directory: /home/testuser1
  GECOS field: f l
  Login shell: /bin/sh
  Kerberos principal: testuser1
  Email address: testuser1
  UID: 1769400001
  GID: 1769400001
  Password: False
  Kerberos keys available: False

[root@vm2 ~]# ldapsearch -xLLL -D "cn=Directory Manager" -w $ROOTDNPWD -b "dc=testrelm,dc=com" cn=testuser1

[root@vm2 ~]# ldapsearch -xLLL -D "cn=Directory Manager" -w $ROOTDNPWD -b "dc=testrelm,dc=com" cn=testuser1
dn: cn=testuser1,cn=groups,cn=compat,dc=testrelm,dc=com
objectClass: posixGroup
objectClass: top
gidNumber: 1769400001
cn: testuser1

dn: cn=testuser1,cn=groups,cn=accounts,dc=testrelm,dc=com
objectClass: posixgroup
objectClass: ipaobject
objectClass: mepManagedEntry
objectClass: top
cn: testuser1
gidNumber: 1769400001
description: User private group for testuser1
mepManagedBy: uid=testuser1,cn=users,cn=accounts,dc=testrelm,dc=com
ipaUniqueID: daade166-08ac-11e2-b691-525400243b75

Then check log on Master:

[27/Sep/2012:09:08:28 -0500] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error 49 (Invalid credentials) (SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context) errno 0 (Success)
[27/Sep/2012:09:08:28 -0500] slapi_ldap_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error 49 (Invalid credentials)
[27/Sep/2012:09:08:29 -0500] NSMMReplicationPlugin - agmt="cn=meTovm2.testrelm.com" (vm2:389): Replication bind with GSSAPI auth failed: LDAP error 49 (Invalid credentials) (SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context)
[27/Sep/2012:09:08:32 -0500] NSMMReplicationPlugin - agmt="cn=meTovm2.testrelm.com" (vm2:389): Replication bind with GSSAPI auth resumed


Automated test also implemented using ipa user-add/ldapsearch and checking log.

Comment 7 errata-xmlrpc 2013-02-21 08:17:33 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHSA-2013-0503.html

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