Bug 1446087 - services entries missing krbCanonicalName attribute.
Summary: services entries missing krbCanonicalName attribute.
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: ipa
Version: 7.4
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: fbarreto
QA Contact: Kaleem
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-04-27 08:56 UTC by German Parente
Modified: 2017-08-01 09:50 UTC (History)
9 users (show)

Fixed In Version: ipa-4.5.0-15.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-08-01 09:50:15 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2017:2304 normal SHIPPED_LIVE ipa bug fix and enhancement update 2017-08-01 12:41:35 UTC

Description German Parente 2017-04-27 08:56:30 UTC
Description of problem:

unfortunately I have not reproduced this locally. But I will describe what I see in customer environment.

- Customer has created a RHEL7 replica from a RHEL6 master.

- He tries to see the certificates associated to a service in the console. And the certificates cannot be found.

- We see the query that is done has this filter:
'(&(&(objectClass=krbprincipal)(objectClass=krbprincipalaux)(objectClass=krbticketpolicyaux)(objectClass=ipaobject)(objectClass=ipaservice)(objectClass=pkiuser))(krbCanonicalName=HTTP/<hostname>@<REALM>)(userCertificate=*))' usercertificate

but the entries have no krbCanonicalName attribute. So, some queries like the former one fails to find any information.


Version-Release number of selected component (if applicable): ipa-server-4.4.0-14.el7_3.6.x86_64

How reproducible: only customer for the moment.


Additional info:

The workaround to generate the attribute would be:

ipa service-add-principal HTTP/`hostname` HTTP/work.around

ipa service-remove-principal HTTP/`hostname` HTTP/work.around

Comment 7 Petr Vobornik 2017-05-05 15:39:07 UTC
Web UI doesn't use any LDAP search directly. It uses API commands to do its work. The API command is equivalent the the CLI command written by Pavel. 

By checking cert-find, I think that it is the probable culprit:

    def _ldap_search(self, all, raw, pkey_only, no_members, timelimit,
                     sizelimit, **options):
        ldap = self.api.Backend.ldap2

        filters = []
        for owner in self.obj._owners():
            for prefix, rule in (('', ldap.MATCH_ALL),
                                 ('no_', ldap.MATCH_NONE)):
                try:
                    value = options[prefix + owner.name]
                except KeyError:
                    continue

                filter = ldap.make_filter_from_attr(
                    'objectclass',
                    owner.object_class,
                    ldap.MATCH_ALL)
                if filter not in filters:
                    filters.append(filter)

                filter = ldap.make_filter_from_attr(
                    owner.primary_key.name,
                    value,
                    rule)
                filters.append(filter)

I.e. it uses primary key. And in service.py there is:
    takes_params = (
        Principal(
            'krbcanonicalname',
            validate_realm,
            cli_name='canonical_principal',
            label=_('Principal name'),
            doc=_('Service principal'),
            primary_key=True,
            normalizer=normalize_principal,
            require_service=True
        ),

So the questions are:
 Is it an issue that cert-find uses krbcanonicalname in search?
 Is it an issue that there are services without krbcanonicalname?
   If yes, is the issue that upgrader probably doesn't upgrade those services?

Comment 8 German Parente 2017-05-05 16:05:09 UTC
Hi,

the issue is that in console the certificates are not shown. From the logs, I have seen that search. But I could be wrong and that search is used by another command. The truth is that the certificates are not shown in the services display.

If the krbcanonicalname is updated by some particular command but not by upgrader, that would explain the root cause of this bug.

if any client app, or command uses krbcanonicalname, well, we must have this attribute created first, imho.

Comment 9 Martin Babinsky 2017-05-05 16:15:07 UTC
The client app should not use krbcanonicalname at all, that is an implementation detail used by KDC to canonicalize principal aliases in AS_REQ.

The decision to change the primary key of service principals to krbcanonicalname was necessary to allow for creation of principal aliases for them.

I would say that in this case the `cert-find` command should use API calls to retrieve the owner objects instead of raw LDAP searches, that would make it independent on the presence of krbcanonicalname attribute.

Comment 10 Petr Vobornik 2017-05-12 16:23:24 UTC
Upstream ticket:
https://pagure.io/freeipa/issue/6948

Comment 12 fbarreto 2017-05-22 17:21:04 UTC
Martin, 

could you, please, explain to me what you mean by "cert-find command should use API calls to retrieve the owner object"? Which should API calls be made?

Thanks

Comment 18 Kaleem 2017-06-09 10:23:30 UTC
Verified.

'Owner Service' field is part of cert-show 

  Owner service: HTTP/bkr-hv03-guest34.testrelm.test@TESTRELM.TEST

[root@bkr-hv03-guest34 ~]# rpm -q ipa-server
ipa-server-4.5.0-16.el7.x86_64
[root@bkr-hv03-guest34 ~]#

[root@bkr-hv03-guest34 ~]# ipa service-show HTTP/`hostname` 
  Principal name: HTTP/bkr-hv03-guest34.testrelm.test@TESTRELM.TEST
  Principal alias: HTTP/bkr-hv03-guest34.testrelm.test@TESTRELM.TEST
  Certificate: MIIDqzCCApOgAwIBAgIBEDANBgkqhkiG9w0BAQsFADA4MRYwFAYDVQQKEw1URVNUUkVMTS5URVNUMR4w
..
....
/qBT0oQPt9a6bRoYPat+dqGyaaFP8x2RkpEKF8bepU4Hyg7llrYo6OaERQ==
  Subject: CN=bkr-hv03-guest34.testrelm.test,O=TESTRELM.TEST
  Serial Number: 16
  Serial Number (hex): 0x10
  Issuer: CN=Certificate Authority,O=TESTRELM.TEST
  Not Before: Thu Jun 08 14:41:22 2017 UTC
  Not After: Sun Jun 09 14:41:22 2019 UTC
  Fingerprint (SHA1): ae:ab:da:14:16:bd:2e:e4:48:61:a6:03:71:4c:24:9d:ed:fb:43:a1
  Fingerprint (SHA256): 56:03:33:94:a4:f1:95:07:aa:40:4d:14:9e:6a:71:5d:0a:2b:e1:e1:2a:9e:99:26:91:ff:f5:0f:5b:46:ed:2d
  Keytab: True
  Managed by: bkr-hv03-guest34.testrelm.test
[root@bkr-hv03-guest34 ~]# ipa cert-show 16
  Issuing CA: ipa
  Certificate: MIIDqzCCApOgAwIBAgIBEDANBgkqhkiG9w0BAQsFADA4MRYwFAYDVQQKEw1URVNUUkVMTS5URVNUMR4w
..
...
....
/qBT0oQPt9a6bRoYPat+dqGyaaFP8x2RkpEKF8bepU4Hyg7llrYo6OaERQ==
  Subject: CN=bkr-hv03-guest34.testrelm.test,O=TESTRELM.TEST
  Issuer: CN=Certificate Authority,O=TESTRELM.TEST
  Not Before: Thu Jun 08 14:41:22 2017 UTC
  Not After: Sun Jun 09 14:41:22 2019 UTC
  Serial number: 16
  Serial number (hex): 0x10
  Revoked: False
  Owner service: HTTP/bkr-hv03-guest34.testrelm.test@TESTRELM.TEST
[root@bkr-hv03-guest34 ~]#

Comment 19 errata-xmlrpc 2017-08-01 09:50:15 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.

https://access.redhat.com/errata/RHBA-2017:2304


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