Bug 1758404

Summary: KRA authentication fails when IPA CA has custom Subject DN
Product: Red Hat Enterprise Linux 8 Reporter: Fraser Tweedale <ftweedal>
Component: ipaAssignee: Thomas Woerner <twoerner>
Status: CLOSED ERRATA QA Contact: ipa-qe <ipa-qe>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 8.0CC: frenaud, ksiddiqu, myusuf, pasik, pcech, rcritten, tscherf
Target Milestone: rc   
Target Release: 8.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1758406 (view as bug list) Environment:
Last Closed: 2020-04-28 15:43:29 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1758406    

Description Fraser Tweedale 2019-10-04 03:59:46 UTC 
Clone of: https://pagure.io/freeipa/issue/8084


Issue

When IPA CA has a custom subject DN (i.e. not CN=Certificate Authority,{subject-base}),
KRA authentication always fails, because the description attribute of the uid=ipakra people entry is not set up correctly.
Steps to Reproduce

1.    Install IPA with custom subject DN, e.g. CN=IPA CA 201910021714,DC=redhat,DC=com
2.    Install KRA
3.    Attempt any operation that contacts KRA (e.g. ipa vault-add).

Actual behavior

Communication with KRA fails.

Expected behavior

Communication with KRA succeeds.

Version/Release/Distribution

4.8 and possibly every version of IPA ever (since we supported custom subject DN).

Additional info:

The probably is clearly seen in the following ldapsearch output:

% ldapsearch -LLL -D cn=directory\ manager -w4me2Test -b o=ipaca '(|(uid=ipara)(uid=ipakra))' description |less
dn: uid=ipara,ou=people,o=ipaca
description: 2;7;CN=IPA CA 201910021714,DC=redhat,DC=com;CN=IPA RA,O=IPA.LOCAL

dn: uid=ipakra,ou=people,o=kra,o=ipaca
description: 2;7;CN=Certificate Authority,O=IPA.LOCAL;CN=IPA RA,O=IPA.LOCAL

The probably may be improper initialisation of the KRAInstance object during installation.
See discussion from mailing list:

> This looks like actual IPA RA subject is fixed in the code in                                                      
> ipaserver/install/krainstance.py:                                                                                  
>                                                                                                                    
> class KRAInstance(DogtagInstance):                                                                                 
> .....                                                                                                              
>    def __create_kra_agent(self):                                                                                   
> .....                                                                                                              
>        # create ipakra user with RA agent certificate                                                              
>        user_dn = DN(('uid', "ipakra"), ('ou', 'people'), self.basedn)                                              
>        entry = conn.make_entry(                                                                                    
>            user_dn,                                                                                                
>            objectClass=['top', 'person', 'organizationalPerson',                                                   
>                         'inetOrgPerson', 'cmsuser'],                                                               
>            uid=["ipakra"],                                                                                         
>            sn=["IPA KRA User"],                                                                                    
>            cn=["IPA KRA User"],                                                                                    
>            usertype=["undefined"],                                                                                 
>            userCertificate=[cert],                                                                                 
>            description=['2;%s;%s;%s' % (                                                                           
>                cert.serial_number,                                                                                 
>                DN(self.subject),                                                                                   
>                DN(('CN', 'IPA RA'), self.subject_base))])                                                          
>        conn.add_entry(entry)                                                                                       
>                                                                                                                    
> I think it should be picked up from the cert. Time for a ticket?                                                   
>                                                                                                                    
Time for a ticket, yes.  But the above code looks ok.  The problem                                                   
is 'self.subject' (the issuer DN) contains the wrong value.  I'll                                                    
follow the reproducer steps to see what's going on.  I suspect                                                       
KRAInstance instance is not initialised properly for some operation.
Comment 2 Fraser Tweedale 2019-10-04 05:06:38 UTC 
How to verify:

1. Create IPA server with custom CA subject DN, and KRA, e.g.

    ipa-server-install --ca-subject "CN=IPA CA 201910041439,DC=redhat,DC=com" --setup-kra


2. Confirm uid=ipakra user entry 'description' attribute contains correct value:

% ldapsearch -LLL -D cn=directory\ manager -w "$DM_PASSWORD" -b o=ipaca '(|(uid=ipara)(uid=ipakra))' description |less
dn: uid=ipara,ou=people,o=ipaca
description: 2;7;CN=IPA CA 201910041418,DC=redhat,DC=com;CN=IPA RA,O=IPA.LOCAL

dn: uid=ipakra,ou=people,o=kra,o=ipaca
description: 2;7;CN=IPA CA 201910041418,DC=redhat,DC=com;CN=IPA RA,O=IPA.LOCAL

uid=ipakra 'description' attribute should contain the --ca-subject and should match the uid=ipara 'description' attribute.


3. Confirm KRA operations succeed, e.g. "ipa vault-add foo --password Secret.123"
Comment 3 Fraser Tweedale 2019-10-04 05:06:57 UTC 
PR: https://github.com/freeipa/freeipa/pull/3764
Comment 4 Florence Blanc-Renaud 2019-10-08 11:34:43 UTC 
Workaround: fix the "description" attribute of the entry uid=ipakra,ou=people,o=kra,o=ipaca
The value can be taken from the "description" attribute of the entry uid=ipara,ou=people,o=ipaca:

$ kinit admin
$ ldapsearch -LLL -o ldif-wrap=no -Y GSSAPI -b uid=ipara,ou=people,o=ipaca description
SASL/GSSAPI authentication started
SASL username: admin
SASL SSF: 256
SASL data security layer installed.
dn: uid=ipara,ou=people,o=ipaca
description: 2;7;CN=Certificate Authority,O=DOMAIN.COM;CN=IPA RA,O=DOMAIN.COM

^^ note the value from this command

$ ldapmodify -D cn=directory\ manager -W
Enter LDAP Password: 
dn: uid=ipakra,ou=people,o=kra,o=ipaca
changetype: modify
replace: description
description: <paste the value from the prev output>

modifying entry "uid=ipakra,ou=people,o=kra,o=ipaca"
Comment 5 Florence Blanc-Renaud 2019-10-17 06:22:24 UTC 
Fixed upstream
master:
https://pagure.io/freeipa/c/326d417d98b092e175623cd28e46586df00e60a2
https://pagure.io/freeipa/c/7ea50ff76d2ee5367b75d999c2baa2a7a480f34a
https://pagure.io/freeipa/c/e767386e7120be3515d6a34529b51ae658248038

The last commit adds a test in ipatests/test_integration/test_ca_custom_sdn.py (this is a new file, downstream metadata needs to be created to trigger the test).
Comment 6 Florence Blanc-Renaud 2019-10-17 06:44:06 UTC 
Upstream ticket:
https://pagure.io/freeipa/issue/8084
Comment 7 Thomas Woerner 2019-12-02 19:05:36 UTC 
ipa-4-8:
https://pagure.io/freeipa/c/09c6db7
https://pagure.io/freeipa/c/23f4e00
https://pagure.io/freeipa/c/5d68d04
Comment 12 Mohammad Rizwan 2020-01-20 10:48:12 UTC 
Based on the above logs, marking the bug as verified.
Comment 14 errata-xmlrpc 2020-04-28 15:43:29 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/RHEA-2020:1640