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 1616412 - ipa certmap-match fails to find ipa user when altSecurityIdentities in mapping rule
Summary: ipa certmap-match fails to find ipa user when altSecurityIdentities in mappin...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: 389-ds-base
Version: 7.6
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: mreynolds
QA Contact: RHDS QE
Marc Muehlfeld
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-08-15 20:09 UTC by Scott Poore
Modified: 2018-10-30 10:16 UTC (History)
18 users (show)

Fixed In Version: 389-ds-base-1.3.8.4-12.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-10-30 10:15:00 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2018:3127 0 None None None 2018-10-30 10:16:12 UTC

Description Scott Poore 2018-08-15 20:09:02 UTC 
Description of problem:

On a system with Smart Card Authentication setup, if I create a certmap rule with the Mapping rule including altSecurityIdenities filter, the IPA user is not found.

Example:

ipa certmaprule-add maprule_9 \
--maprule='(|(userCertificate;binary={cert!bin})(ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500})(altSecurityIdentities=X509:<I>{issuer_dn!ad_x500}<S>{subject_dn!ad_x500}))' \
--matchrule='<ISSUER>CN=Certificate Authority,O=TESTRELM.TEST' \
--domain=testrelm.test --domain=ipaadcs12r2.test

[root@qe-blade-05 sssd]# ipa certmap-match /root/card.crt 
---------------
0 users matched
---------------
----------------------------
Number of entries returned 0
----------------------------

Version-Release number of selected component (if applicable):
sssd-1.16.2-12.el7.x86_64

How reproducible:
Seems to be always in my test env anyway.

Steps to Reproduce:
1.  Setup IPA Server and Client with Smart Card authentication setup using ipa-advise scripts.

2. Create IPA certmap rule including mapping for whole certificate, IPA certmapdate, and AD altSecurityIdentities data:

ipa certmaprule-add maprule_9 \
--maprule='(|(userCertificate;binary={cert!bin})(ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500})(altSecurityIdentities=X509:<I>{issuer_dn!ad_x500}<S>{subject_dn!ad_x500}))' \
--matchrule='<ISSUER>CN=Certificate Authority,O=TESTRELM.TEST' \
--domain=testrelm.test --domain=ipaadcs12r2.test


3. Add certmapdata to IPA user:

ipa user-add-certmapdata ipauser1 --certificate="$(cat /root/card.crt|sed '/CERT/d'|tr -d '\r\n')"

4. Search for user(s) matching the certificate

ipa certmap-match /root/card.crt 


Actual results:
Fails to find users as shown above.  Note that if altSecurityIdentities entries are set on AD users in a Trusted domain, it will find those.

Expected results:
Finds IPA users (and AD if set appropriately).

Additional info:

Note that if I remove the altSecurityIdentities entries from the mapping rule, it works:

[root@qe-blade-05 sssd]# ipa certmaprule-del maprule_9
-----------------------------------------------------
Deleted Certificate Identity Mapping Rule "maprule_9"
-----------------------------------------------------
[root@qe-blade-05 sssd]# ipa certmaprule-add maprule_9 --maprule='(|(userCertificate;binary={cert!bin})(ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500}))' --matchrule='<ISSUER>CN=Certificate Authority,O=TESTRELM.TEST' --domain=testrelm.test --domain=ipaadcs12r2.test
---------------------------------------------------
Added Certificate Identity Mapping Rule "maprule_9"
---------------------------------------------------
  Rule name: maprule_9
  Mapping rule: (|(userCertificate;binary={cert!bin})(ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500}))
  Matching rule: <ISSUER>CN=Certificate Authority,O=TESTRELM.TEST
  Domain name: testrelm.test, ipaadcs12r2.test
  Enabled: TRUE
[root@qe-blade-05 sssd]# systemctl stop sssd; rm -rf /var/lib/sss/{db,mc}/*; systemctl start sssd
[root@qe-blade-05 sssd]# ipa certmap-match /root/card.crt 
--------------
1 user matched
--------------
  Domain: TESTRELM.TEST
  User logins: ipauser1
----------------------------
Number of entries returned 1
Comment 3 Scott Poore 2018-08-15 20:12:02 UTC 
[root@qe-blade-05 sssd]# ipa certmaprule-del maprule_9
-----------------------------------------------------
Deleted Certificate Identity Mapping Rule "maprule_9"
-----------------------------------------------------


[root@qe-blade-05 sssd]# ipa certmaprule-add maprule_9 --maprule='(|(userCertificate;binary={cert!bin})(ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500}))' --matchrule='<ISSUER>CN=Certificate Authority,O=TESTRELM.TEST' --domain=testrelm.test --domain=ipaadcs12r2.test
---------------------------------------------------
Added Certificate Identity Mapping Rule "maprule_9"
---------------------------------------------------
  Rule name: maprule_9
  Mapping rule: (|(userCertificate;binary={cert!bin})(ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500}))
  Matching rule: <ISSUER>CN=Certificate Authority,O=TESTRELM.TEST
  Domain name: testrelm.test, ipaadcs12r2.test
  Enabled: TRUE


[root@qe-blade-05 sssd]# systemctl stop sssd; rm -rf /var/lib/sss/{db,mc}/*; systemctl start sssd


[root@qe-blade-05 sssd]# ipa certmap-match /root/card.crt 
--------------
1 user matched
--------------
  Domain: TESTRELM.TEST
  User logins: ipauser1
----------------------------
Number of entries returned 1
----------------------------


[root@qe-blade-05 sssd]# ipa certmaprule-del maprule_9
-----------------------------------------------------
Deleted Certificate Identity Mapping Rule "maprule_9"
-----------------------------------------------------


[root@qe-blade-05 sssd]# ipa certmaprule-add maprule_9 --maprule='(|(userCertificate;binary={cert!bin})(ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500})(altSecurityIdentities=X509:<I>{issuer_dn!ad_x500}<S>{subject_dn!ad_x500}))' --matchrule='<ISSUER>CN=Certificate Authority,O=TESTRELM.TEST' --domain=testrelm.test --domain=ipaadcs12r2.test
---------------------------------------------------
Added Certificate Identity Mapping Rule "maprule_9"
---------------------------------------------------
  Rule name: maprule_9
  Mapping rule: (|(userCertificate;binary={cert!bin})(ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500})(altSecurityIdentities=X509:<I>{issuer_dn!ad_x500}<S>{subject_dn!ad_x500}))
  Matching rule: <ISSUER>CN=Certificate Authority,O=TESTRELM.TEST
  Domain name: testrelm.test, ipaadcs12r2.test
  Enabled: TRUE


[root@qe-blade-05 sssd]# systemctl stop sssd; rm -rf /var/lib/sss/{db,mc}/*; systemctl start sssd


[root@qe-blade-05 sssd]# ipa certmap-match /root/card.crt 
---------------
0 users matched
---------------
----------------------------
Number of entries returned 0
----------------------------
Comment 5 Sumit Bose 2018-08-16 09:20:48 UTC 
Looks like there is not debug_level set in sssd.conf so the SSSD logs do not help. Nevertheless the dirsrv logs have:

$ grep -A1 -i ipacertmapdata *
access:[15/Aug/2018:15:57:58.120791775 -0400] conn=43 op=13 SRCH base="cn=accounts,dc=testrelm,dc=test" scope=2 filter="(&(|(usercertificate;binary=0\82\03\AD0\82\02\95\A0\03\02\01\02\02\01\130\0D\06\09\2A\86H\86\F7\0D\01\01\0B\05)(ipaCertMapData=X509:<I>O=TESTRELM.TEST,CN=Certificate Authority<S>O=TESTRELM.TEST,CN=ipauser1))(objectClass=posixAccount)(uid=*)(&(uidNumber=*)(!(uidNumber=0))))" attrs="objectClass uid userPassword uidNumber gidNumber gecos homeDirectory loginShell krbPrincipalName cn memberOf ipaUniqueID ipaNTSecurityIdentifier modifyTimestamp entryusn shadowLastChange shadowMin shadowMax shadowWarning shadowInactive shadowExpire shadowFlag krbLastPwdChange krbPasswordExpiration pwdattribute authorizedService accountexpires useraccountcontrol nsAccountLock host logindisabled loginexpirationtime loginallowedtimemap ipaSshPubKey ipaUserAuthType usercertificate;binary mail"
access-[15/Aug/2018:15:57:58.125531063 -0400] conn=43 op=13 RESULT err=0 tag=101 nentries=1 etime=0.0005041270 notes=U
--
access:[15/Aug/2018:15:58:23.951046083 -0400] conn=48 op=14 SRCH base="cn=accounts,dc=testrelm,dc=test" scope=2 filter="(&(|(usercertificate;binary=0\82\03\AD0\82\02\95\A0\03\02\01\02\02\01\130\0D\06\09\2A\86H\86\F7\0D\01\01\0B\05)(ipaCertMapData=X509:<I>O=TESTRELM.TEST,CN=Certificate Authority<S>O=TESTRELM.TEST,CN=ipauser1)(altsecurityidentities=X509:<I>O=TESTRELM.TEST,CN=Certificate Authority<S>O=TESTRELM.TEST,CN=ipauser1))(objectClass=posixAccount)(uid=*)(&(uidNumber=*)(!(uidNumber=0))))" attrs="objectClass uid userPassword uidNumber gidNumber gecos homeDirectory loginShell krbPrincipalName cn memberOf ipaUniqueID ipaNTSecurityIdentifier modifyTimestamp entryusn shadowLastChange shadowMin shadowMax shadowWarning shadowInactive shadowExpire shadowFlag krbLastPwdChange krbPasswordExpiration pwdattribute authorizedService accountexpires useraccountcontrol nsAccountLock host logindisabled loginexpirationtime loginallowedtimemap ipaSshPubKey ipaUserAuthType usercertificate;binary mail"
access-[15/Aug/2018:15:58:23.954057504 -0400] conn=48 op=14 RESULT err=0 tag=101 nentries=0 etime=0.0003320294 notes=U


which confirms your observation. The first search without altsecurityidentities in the search filter returns a result (nentries=1) while the second with altsecurityidentities does not find anything (nentries=0)

Which version of 389-ds-base is installed on your system? Maybe this is realted to https://pagure.io/389-ds-base/issue/48275 (ACI issue) or 389ds has issues handling an attribute name which is not defined in its own LDAP schemas?

Thierry, does this ring a bell?
Comment 6 Scott Poore 2018-08-16 13:30:07 UTC 
I thought I had debug_level = 9 set for all sections of sssd.conf. Unfortunately, my test environment was short lived and had to be rebuilt.  I have another setup now with a much longer reserve time.

This is the version of 389 on the latest IPA server:

389-ds-base-1.3.8.4-10.el7.x86_64

I can see that the problem is still there though in a new/fresh environment:

[root@qe-blade-05 ~]# ipa certmap-match /root/card.crt 
--------------
1 user matched
--------------
  Domain: ipaadcs12r2.test
  User logins: ipacertmultiuser1
----------------------------
Number of entries returned 1
----------------------------


I added a  altSecurityIdentities mapping to this AD user when I was trying to find a workaround.  you can see though that ipauser1 is not there.   If I remove the altSecurityIdentities from the maprule, I can see ipauser1 again (but not this AD user).
Comment 9 Scott Poore 2018-08-16 14:33:54 UTC 
Also, interestingly enough, if I manually run a similar ldapsearch, I find that user:

[root@qe-blade-05 log]# ldapsearch -Y GSSAPI -b "cn=accounts,dc=testrelm,dc=test" '(&(|(usercertificate;binary=0\82\03\AD0\82\02\95\A0\03\02\01\02\02\01\0F0\0D\06\09\2A\86H\86\F7\0D\01\01\0B\05)(ipaCertMapData=X509:<I>O=TESTRELM.TEST,CN=Certificate Authority<S>O=TESTRELM.TEST,CN=ipauser1)(altsecurityidentities=X509:<I>O=TESTRELM.TEST,CN=Certificate Authority<S>O=TESTRELM.TEST,CN=ipauser1))(objectClass=posixAccount)(uid=*)(&(uidNumber=*)(!(uidNumber=0))))' dn
SASL/GSSAPI authentication started
SASL username: admin
SASL SSF: 256
SASL data security layer installed.
# extended LDIF
#
# LDAPv3
# base <cn=accounts,dc=testrelm,dc=test> with scope subtree
# filter: (&(|(usercertificate;binary=0\82\03\AD0\82\02\95\A0\03\02\01\02\02\01\0F0\0D\06\09\2A\86H\86\F7\0D\01\01\0B\05)(ipaCertMapData=X509:<I>O=TESTRELM.TEST,CN=Certificate Authority<S>O=TESTRELM.TEST,CN=ipauser1)(altsecurityidentities=X509:<I>O=TESTRELM.TEST,CN=Certificate Authority<S>O=TESTRELM.TEST,CN=ipauser1))(objectClass=posixAccount)(uid=*)(&(uidNumber=*)(!(uidNumber=0))))
# requesting: dn 
#

# ipauser1, users, accounts, testrelm.test
dn: uid=ipauser1,cn=users,cn=accounts,dc=testrelm,dc=test

# search result
search: 4
result: 0 Success

# numResponses: 2
# numEntries: 1


But, I see in the log that it could not find the user:

[16/Aug/2018:09:47:42.040696012 -0400] conn=263 op=27 SRCH base="cn=accounts,dc=testrelm,dc=test" scope
=2 filter="(&(|(usercertificate;binary=0\82\03\AD0\82\02\95\A0\03\02\01\02\02\01\0F0\0D\06\09\2A\86H\86
\F7\0D\01\01\0B\05)(ipaCertMapData=X509:<I>O=TESTRELM.TEST,CN=Certificate Authority<S>O=TESTRELM.TEST,C
N=ipauser1)(altsecurityidentities=X509:<I>O=TESTRELM.TEST,CN=Certificate Authority<S>O=TESTRELM.TEST,CN
=ipauser1))(objectClass=posixAccount)(uid=*)(&(uidNumber=*)(!(uidNumber=0))))" attrs="objectClass uid u
serPassword uidNumber gidNumber gecos homeDirectory loginShell krbPrincipalName cn memberOf ipaUniqueID
 ipaNTSecurityIdentifier modifyTimestamp entryusn shadowLastChange shadowMin shadowMax shadowWarning sh
adowInactive shadowExpire shadowFlag krbLastPwdChange krbPasswordExpiration pwdattribute authorizedServ
ice accountexpires useraccountcontrol nsAccountLock host logindisabled loginexpirationtime loginallowed
timemap ipaSshPubKey ipaUserAuthType usercertificate;binary mail"


[16/Aug/2018:09:47:42.043726955 -0400] conn=263 op=27 RESULT err=0 tag=101 nentries=0 etime=0.0003327111 notes=U
Comment 10 Scott Poore 2018-08-16 14:55:30 UTC 
testing with host credentials from IPA server as requested:
 
[root@qe-blade-05 log]# kdestroy -A; kinit -k host/$(hostname)@TESTRELM.TEST


[root@qe-blade-05 log]# klist
Ticket cache: KEYRING:persistent:0:0
Default principal: host/hostname

Valid starting       Expires              Service principal
08/16/2018 10:52:36  08/17/2018 10:52:36  krbtgt/TESTRELM.TEST


[root@qe-blade-05 log]# ldapsearch -Y GSSAPI -b "cn=accounts,dc=testrelm,dc=test" '(&(|(usercertificate;binary=0\82\03\AD0\82\02\95\A0\03\02\01\02\02\01\0F0\0D\06\09\2A\86H\86\F7\0D\01\01\0B\05)(ipaCertMapData=X509:<I>O=TESTRELM.TEST,CN=Certificate Authority<S>O=TESTRELM.TEST,CN=ipauser1)(altsecurityidentities=X509:<I>O=TESTRELM.TEST,CN=Certificate Authority<S>O=TESTRELM.TEST,CN=ipauser1))(objectClass=posixAccount)(uid=*)(&(uidNumber=*)(!(uidNumber=0))))' dn
SASL/GSSAPI authentication started
SASL username: host/hostname
SASL SSF: 256
SASL data security layer installed.
# extended LDIF
#
# LDAPv3
# base <cn=accounts,dc=testrelm,dc=test> with scope subtree
# filter: (&(|(usercertificate;binary=0\82\03\AD0\82\02\95\A0\03\02\01\02\02\01\0F0\0D\06\09\2A\86H\86\F7\0D\01\01\0B\05)(ipaCertMapData=X509:<I>O=TESTRELM.TEST,CN=Certificate Authority<S>O=TESTRELM.TEST,CN=ipauser1)(altsecurityidentities=X509:<I>O=TESTRELM.TEST,CN=Certificate Authority<S>O=TESTRELM.TEST,CN=ipauser1))(objectClass=posixAccount)(uid=*)(&(uidNumber=*)(!(uidNumber=0))))
# requesting: dn 
#

# search result
search: 4
result: 0 Success

# numResponses: 1

So, ACI issue?
Comment 11 Scott Poore 2018-08-16 15:36:38 UTC 
Looking at the ACI messages in the new logs, I see this:

[16/Aug/2018:11:31:11.258795217 -0400] - DEBUG - NSACLPlugin - print_access_control_summary - conn=15 op=15 (main): Deny search on entry(uid=ipauser1,cn=users,cn=accounts,dc=testrelm,dc=test).attr(altsecurityide
ntities) to fqdn=hostname,cn=computers,cn=accounts,dc=testrelm,dc=test: no aci matched the subject by aci(21): aciname= "Admin can manage any entry", acidn="dc=testrelm,dc=test"

Could this be the issue?
Comment 13 Sumit Bose 2018-08-16 15:38:32 UTC 
The minimal reproducer I found so far is with a fresh installed RHEL-7.6 IPA server:

[root@kvm-02-guest25 ~]# kdestroy -A
[root@kvm-02-guest25 ~]# kinit -k
[root@kvm-02-guest25 ~]# ldapsearch -Y GSSAPI -H ldap://iparhel76test.ipa.test -b 'cn=accounts,dc=ipa,dc=test' '(&(|(uid=admin)(abc=def))(objectClass=posixAccount))' dn
SASL/GSSAPI authentication started
SASL username: host/iparhel76test.ipa.test
SASL SSF: 256
SASL data security layer installed.
# extended LDIF
#
# LDAPv3
# base <cn=accounts,dc=ipa,dc=test> with scope subtree
# filter: (&(|(uid=admin)(abc=def))(objectClass=posixAccount))
# requesting: dn 
#

# search result
search: 4
result: 0 Success

# numResponses: 1


Both removing the '&'

[root@kvm-02-guest25 ~]# ldapsearch -Y GSSAPI -H ldap://iparhel76test.ipa.test -b 'cn=accounts,dc=ipa,dc=test' '(|(uid=admin)(abc=def))' dn
SASL/GSSAPI authentication started
SASL username: host/iparhel76test.ipa.test
SASL SSF: 256
SASL data security layer installed.
# extended LDIF
#
# LDAPv3
# base <cn=accounts,dc=ipa,dc=test> with scope subtree
# filter: (|(uid=admin)(abc=def))
# requesting: dn 
#

# admin, users, accounts, ipa.test
dn: uid=admin,cn=users,cn=accounts,dc=ipa,dc=test

# search result
search: 4
result: 0 Success

# numResponses: 2
# numEntries: 1


or using a known attribute name instead of 'abc'

[root@kvm-02-guest25 ~]# ldapsearch -Y GSSAPI -H ldap://iparhel76test.ipa.test -b 'cn=accounts,dc=ipa,dc=test' '(&(|(uid=admin)(gecos=def))(objectClass=posixAccount))' dn
SASL/GSSAPI authentication started
SASL username: host/iparhel76test.ipa.test
SASL SSF: 256
SASL data security layer installed.
# extended LDIF
#
# LDAPv3
# base <cn=accounts,dc=ipa,dc=test> with scope subtree
# filter: (&(|(uid=admin)(gecos=def))(objectClass=posixAccount))
# requesting: dn 
#

# admin, users, accounts, ipa.test
dn: uid=admin,cn=users,cn=accounts,dc=ipa,dc=test

# search result
search: 4
result: 0 Success

# numResponses: 2
# numEntries: 1


will return the entry.

The corresponding DS access logs are:
[16/Aug/2018:17:32:47.007281467 +0200] conn=86 op=0 BIND dn="" method=sasl version=3 mech=GSSAPI
[16/Aug/2018:17:32:47.030333097 +0200] conn=86 op=0 RESULT err=14 tag=97 nentries=0 etime=0.0023520235, SASL bind in progress
[16/Aug/2018:17:32:47.031574967 +0200] conn=86 op=1 BIND dn="" method=sasl version=3 mech=GSSAPI
[16/Aug/2018:17:32:47.033330372 +0200] conn=86 op=1 RESULT err=14 tag=97 nentries=0 etime=0.0002043865, SASL bind in progress
[16/Aug/2018:17:32:47.034580806 +0200] conn=86 op=2 BIND dn="" method=sasl version=3 mech=GSSAPI
[16/Aug/2018:17:32:47.035671741 +0200] conn=86 op=2 RESULT err=0 tag=97 nentries=0 etime=0.0001669077 dn="fqdn=iparhel76test.ipa.test,cn=computers,cn=accounts,dc=ipa,dc=test"
[16/Aug/2018:17:32:47.036985552 +0200] conn=86 op=3 SRCH base="cn=accounts,dc=ipa,dc=test" scope=2 filter="(&(|(uid=admin)(abc=def))(objectClass=posixAccount))" attrs="distinguishedName"
[16/Aug/2018:17:32:47.037945220 +0200] conn=86 op=3 RESULT err=0 tag=101 nentries=0 etime=0.0001243670 notes=U
[16/Aug/2018:17:32:47.039846646 +0200] conn=86 op=4 UNBIND
[16/Aug/2018:17:32:47.039893160 +0200] conn=86 op=4 fd=108 closed - U1
[16/Aug/2018:17:33:43.281355690 +0200] conn=87 fd=108 slot=108 connection from 2620:52:0:2598:5054:ff:fe53:ea8b to 2620:52:0:2598:5054:ff:fe53:ea8b
[16/Aug/2018:17:33:43.292363300 +0200] conn=87 op=0 BIND dn="" method=sasl version=3 mech=GSSAPI
[16/Aug/2018:17:33:43.300099109 +0200] conn=87 op=0 RESULT err=14 tag=97 nentries=0 etime=0.0009471566, SASL bind in progress
[16/Aug/2018:17:33:43.301999324 +0200] conn=87 op=1 BIND dn="" method=sasl version=3 mech=GSSAPI
[16/Aug/2018:17:33:43.304445089 +0200] conn=87 op=1 RESULT err=14 tag=97 nentries=0 etime=0.0003209668, SASL bind in progress
[16/Aug/2018:17:33:43.305966562 +0200] conn=87 op=2 BIND dn="" method=sasl version=3 mech=GSSAPI
[16/Aug/2018:17:33:43.307340966 +0200] conn=87 op=2 RESULT err=0 tag=97 nentries=0 etime=0.0002094404 dn="fqdn=iparhel76test.ipa.test,cn=computers,cn=accounts,dc=ipa,dc=test"
[16/Aug/2018:17:33:43.309002922 +0200] conn=87 op=3 SRCH base="cn=accounts,dc=ipa,dc=test" scope=2 filter="(|(uid=admin)(abc=def))" attrs=ALL
[16/Aug/2018:17:33:43.315660300 +0200] conn=87 op=3 RESULT err=0 tag=101 nentries=1 etime=0.0007276968 notes=U
[16/Aug/2018:17:33:43.318036866 +0200] conn=87 op=4 UNBIND
[16/Aug/2018:17:33:43.318061572 +0200] conn=87 op=4 fd=108 closed - U1
[16/Aug/2018:17:33:46.670255865 +0200] conn=88 fd=108 slot=108 connection from 2620:52:0:2598:5054:ff:fe53:ea8b to 2620:52:0:2598:5054:ff:fe53:ea8b
[16/Aug/2018:17:33:46.681214544 +0200] conn=88 op=0 BIND dn="" method=sasl version=3 mech=GSSAPI
[16/Aug/2018:17:33:46.687905954 +0200] conn=88 op=0 RESULT err=14 tag=97 nentries=0 etime=0.0007952837, SASL bind in progress
[16/Aug/2018:17:33:46.688979538 +0200] conn=88 op=1 BIND dn="" method=sasl version=3 mech=GSSAPI
[16/Aug/2018:17:33:46.690581128 +0200] conn=88 op=1 RESULT err=14 tag=97 nentries=0 etime=0.0001893442, SASL bind in progress
[16/Aug/2018:17:33:46.691936479 +0200] conn=88 op=2 BIND dn="" method=sasl version=3 mech=GSSAPI
[16/Aug/2018:17:33:46.692880948 +0200] conn=88 op=2 RESULT err=0 tag=97 nentries=0 etime=0.0001745308 dn="fqdn=iparhel76test.ipa.test,cn=computers,cn=accounts,dc=ipa,dc=test"
[16/Aug/2018:17:33:46.694168324 +0200] conn=88 op=3 SRCH base="cn=accounts,dc=ipa,dc=test" scope=2 filter="(|(uid=admin)(abc=def))" attrs="distinguishedName"
[16/Aug/2018:17:33:46.697455252 +0200] conn=88 op=3 RESULT err=0 tag=101 nentries=1 etime=0.0003696252 notes=U
[16/Aug/2018:17:33:46.699181913 +0200] conn=88 op=4 UNBIND
[16/Aug/2018:17:33:46.699199207 +0200] conn=88 op=4 fd=108 closed - U1
[16/Aug/2018:17:34:41.577160409 +0200] conn=89 fd=108 slot=108 connection from 2620:52:0:2598:5054:ff:fe53:ea8b to 2620:52:0:2598:5054:ff:fe53:ea8b
[16/Aug/2018:17:34:41.588844080 +0200] conn=89 op=0 BIND dn="" method=sasl version=3 mech=GSSAPI
[16/Aug/2018:17:34:41.600425969 +0200] conn=89 op=0 RESULT err=14 tag=97 nentries=0 etime=0.0013794769, SASL bind in progress
[16/Aug/2018:17:34:41.601791986 +0200] conn=89 op=1 BIND dn="" method=sasl version=3 mech=GSSAPI
[16/Aug/2018:17:34:41.603933852 +0200] conn=89 op=1 RESULT err=14 tag=97 nentries=0 etime=0.0002436036, SASL bind in progress
[16/Aug/2018:17:34:41.605480935 +0200] conn=89 op=2 BIND dn="" method=sasl version=3 mech=GSSAPI
[16/Aug/2018:17:34:41.607046483 +0200] conn=89 op=2 RESULT err=0 tag=97 nentries=0 etime=0.0002281997 dn="fqdn=iparhel76test.ipa.test,cn=computers,cn=accounts,dc=ipa,dc=test"
[16/Aug/2018:17:34:41.608572101 +0200] conn=89 op=3 SRCH base="cn=accounts,dc=ipa,dc=test" scope=2 filter="(&(|(uid=admin)(gecos=def))(objectClass=posixAccount))" attrs="distinguishedName"
[16/Aug/2018:17:34:41.609571946 +0200] conn=89 op=3 RESULT err=0 tag=101 nentries=1 etime=0.0001539423 notes=U
[16/Aug/2018:17:34:41.611615459 +0200] conn=89 op=4 UNBIND
[16/Aug/2018:17:34:41.611647102 +0200] conn=89 op=4 fd=108 closed - U1



Please note the 'notes=U' for all searches although I'd expect that both uid and objectclass are indexed.
Comment 14 mreynolds 2018-08-16 20:36:02 UTC 
I see nothing wrong with what the server is doing.  The issue looks like you need to update an aci:

dn: cn=users,cn=accounts,dc=testrelm,dc=test
aci: (targetattr = "audio || businesscategory || carlicense || departmentnumbe
 r || destinationindicator || employeenumber || employeetype || facsimiletelep
 honenumber || homephone || homepostaladdress || inetuserhttpurl || inetuserst
 atus || internationalisdnnumber || ipacertmapdata || jpegphoto || l || labele
 duri || mail || mobile || o || ou || pager || photo || physicaldeliveryoffice
 name || postaladdress || postalcode || postofficebox || preferreddeliverymeth
 od || preferredlanguage || registeredaddress || roomnumber || secretary || se
 ealso || st || street || telephonenumber || teletexterminalidentifier || tele
 xnumber || usercertificate || usersmimecertificate || x121address || x500uniq
 ueidentifier")(targetfilter = "(objectclass=posixaccount)")(version 3.0;acl "
 permission:System: Read User Addressbook Attributes";allow (compare,read,sear
 ch) userdn = "ldap:///all";)


This aci should have "altsecurityidentities" in the targetattr.

I think this is a "regression" because of a security fix that was made in DS.  Now all the attributes in a search filter must be allowed(access granted) or else the entire search will fail.
Comment 15 mreynolds 2018-08-17 14:31:15 UTC 
Okay, found the problem.  It's two parts

[1]  altsecurityidentities needs to be in the aci:  "permission:System: Read User Addressbook Attributes" under cn=users,cn=accounts,dc=testrelm,dc=test

[2]  altsecurityidentities needs to be in the schema - otherwise the aci is completely skipped over.

So in my local testing I now see:


# ldapsearch -xLLL -D "fqdn=qe-blade-05.idmqe.lab.eng.bos.redhat.com,cn=computers,cn=accounts,dc=testrelm,dc=test" -w password -b "cn=accounts,dc=testrelm,dc=test" '(&(|(usercertificate;binary=0\82\03\AD0\82\02\95\A0\03\02\01\02\02\01\0F0\0D\06\09\2A\86H\86\F7\0D\01\01\0B\05)(ipacertmapdata=X509:<I>O=TESTRELM.TEST,CN=Certificate Authority<S>O=TESTRELM.TEST,CN=ipauser1)(altsecurityidentities=X509:<I>O=TESTRELM.TEST,CN=Certificate Authority<S>O=TESTRELM.TEST,CN=ipauser1))(objectClass=posixaccount)(uid=*)(&(uidnumber=*)(!(uidnumber=0))))' dn

dn: uid=ipauser1,cn=users,cn=accounts,dc=testrelm,dc=test
Comment 16 Sumit Bose 2018-08-20 15:15:15 UTC 
Hi Mark,

thank you for the details. I wonder if the current behavior can be relaxed a bit without lowering security as well?

The original idea for the search filter Scott used is to have a single search filter which can be used to search Windows users in the AD schema and IPA users in the IPA schema. Hence the search filter contains AD specific attributes (altsecurityidentities) and IPA specific attributes (ipacertmapdata) in an or-clause.

Depending on the certificates used by the customer also other attributes might be used in the search filter. E.g. the AD attributes samAccountName might be needed in some setups. Also here this attribute with be used in an or-clause with e.g. userPrincipalName to be able to search IPA users as well.

So I wonder if instead of adding attributes to  he schema and the ACIs which are only needed to make the searches work it might e.g. be possible to just ignore ignore unknown (not defined in the LDAP schema) attributes?

If this is not possible we have to solve this by adding different search filters for IPA and AD domains. Since the rules can be assigned to different domains this wouldn't be a problem, but I guess we have to highlight this change strongly in the Release Notes and the general documentation because we currently have examples with this kind of search filter in the documentation, see Example 23.4 in https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/linux_domain_identity_authentication_and_policy_guide/smart-cards#identity-mapping.
Comment 17 mreynolds 2018-08-20 19:34:17 UTC 
Well this is how the server has behaved for a very long time.  The access control plugin has always required that the aci's target attributes exist in schema, but I don't see a good reason why it needs to be strictly enforced (not that there isn't one).  But you MUST have that attribute listed in your ACI's somewhere - there is no getting around that.  

I would like to discuss removing the schema check from the ACI code with the rest of my team before I can say if its okay to remove this check.
Comment 18 Sumit Bose 2018-08-21 09:20:40 UTC 
(In reply to mreynolds from comment #17)
> Well this is how the server has behaved for a very long time.  The access
> control plugin has always required that the aci's target attributes exist in
> schema, but I don't see a good reason why it needs to be strictly enforced
> (not that there isn't one).  But you MUST have that attribute listed in your
> ACI's somewhere - there is no getting around that.  
> 
> I would like to discuss removing the schema check from the ACI code with the
> rest of my team before I can say if its okay to remove this check.

I see. Do I understand correctly that the attribute must be present in the ACIs because the extensibleObject objectclass allows you to add attributes with any name and you do not know before the search if there are any objects using this class before the search?
Comment 19 Sumit Bose 2018-08-21 09:24:25 UTC 
Scott, can you check that if you split the rule

ipa certmaprule-add maprule_9 \
--maprule='(|(userCertificate;binary={cert!bin})(ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500})(altSecurityIdentities=X509:<I>{issuer_dn!ad_x500}<S>{subject_dn!ad_x500}))' \
--matchrule='<ISSUER>CN=Certificate Authority,O=TESTRELM.TEST' \
--domain=testrelm.test --domain=ipaadcs12r2.test

into two:

ipa certmaprule-add maprule_9_ipa \
--maprule='(|(userCertificate;binary={cert!bin})(ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500}))' \
--matchrule='<ISSUER>CN=Certificate Authority,O=TESTRELM.TEST' \
--domain=testrelm.test

ipa certmaprule-add maprule_9_ad \
--maprule='(|(userCertificate;binary={cert!bin})(altSecurityIdentities=X509:<I>{issuer_dn!ad_x500}<S>{subject_dn!ad_x500}))' \
--matchrule='<ISSUER>CN=Certificate Authority,O=TESTRELM.TEST' \
--domain=ipaadcs12r2.test

your tests will show the same results as before?
Comment 20 thierry bordaz 2018-08-21 13:42:58 UTC 
(In reply to Sumit Bose from comment #18)
> (In reply to mreynolds from comment #17)
> > Well this is how the server has behaved for a very long time.  The access
> > control plugin has always required that the aci's target attributes exist in
> > schema, but I don't see a good reason why it needs to be strictly enforced
> > (not that there isn't one).  But you MUST have that attribute listed in your
> > ACI's somewhere - there is no getting around that.  
> > 
> > I would like to discuss removing the schema check from the ACI code with the
> > rest of my team before I can say if its okay to remove this check.
> 
> I see. Do I understand correctly that the attribute must be present in the
> ACIs because the extensibleObject objectclass allows you to add attributes
> with any name and you do not know before the search if there are any objects
> using this class before the search?

extensibleObject objectclass restricts schema checking on mandatory (MUST) attributes so it is a common way to add "dummy" attribute. 

To prevent attribute value guessing (https://pagure.io/389-ds-base/issue/48275), it is required that all attributes in the filter components have 'read' right. So you need an ACI allowing 'read' on altsecurityidentities

The requirement that 'altsecurityidentities' is in the schema comes from
https://bugzilla.redhat.com/show_bug.cgi?id=244229. It was done to help diagnostic of typo. I think this checking can be replaced with a simple warning in error log and let aci containing unknown attribute.
Comment 21 Sumit Bose 2018-08-21 16:43:11 UTC 
(In reply to Sumit Bose from comment #19)
> Scott, can you check that if you split the rule
> 
> ipa certmaprule-add maprule_9 \
> --maprule='(|(userCertificate;binary={cert!bin})(ipacertmapdata=X509:
> <I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500})(altSecurityIdentities=X509:
> <I>{issuer_dn!ad_x500}<S>{subject_dn!ad_x500}))' \
> --matchrule='<ISSUER>CN=Certificate Authority,O=TESTRELM.TEST' \
> --domain=testrelm.test --domain=ipaadcs12r2.test
> 
> into two:
> 
> ipa certmaprule-add maprule_9_ipa \
> --maprule='(|(userCertificate;binary={cert!bin})(ipacertmapdata=X509:
> <I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500}))' \
> --matchrule='<ISSUER>CN=Certificate Authority,O=TESTRELM.TEST' \
> --domain=testrelm.test
> 
> ipa certmaprule-add maprule_9_ad \
> --maprule='(|(userCertificate;binary={cert!bin})(altSecurityIdentities=X509:
> <I>{issuer_dn!ad_x500}<S>{subject_dn!ad_x500}))' \
> --matchrule='<ISSUER>CN=Certificate Authority,O=TESTRELM.TEST' \
> --domain=ipaadcs12r2.test
> 
> your tests will show the same results as before?

Scott, you were right being suspicious. This does not work because I didn't had a chance to fix https://bugzilla.redhat.com/show_bug.cgi?id=1447945 yet, and your original search filter is the work-around for this.

Nevertheless, even if https://bugzilla.redhat.com/show_bug.cgi?id=1447945 would have already been fixed we would run into the same issue because my planned fix is to add the search filters together with an or-clause so that we would end up with the same filter.

So I hope Thierry and Mark can find an easy solution for the DS side.
Comment 22 Sumit Bose 2018-08-22 13:16:59 UTC 
I did some more testing with unknown attributes and I wonder if the issue might be in the evaluation of more complex search filters.

To make sure I use host credentials I called:

    KRB5CCNAME=FILE:/tmp/host.ccache kinit -k

now a search with a single or-clause and an unknown attribute returned a result:

    # KRB5CCNAME=FILE:/tmp/host.ccache ldapsearch -Y GSSAPI -b 'cn=accounts,dc=testrelm,dc=test' '(|(uid=admin)(qwqwwq=fweewdqe))' dn objectClass
    SASL/GSSAPI authentication started
    SASL username: host/qe-blade-05.idmqe.lab.eng.bos.redhat.com
    SASL SSF: 256
    SASL data security layer installed.
    # extended LDIF
    #
    # LDAPv3
    # base <cn=accounts,dc=testrelm,dc=test> with scope subtree
    # filter: (|(uid=admin)(qwqwwq=fweewdqe))
    # requesting: dn objectClass
    #
 
    # admin, users, accounts, testrelm.test
    dn: uid=admin,cn=users,cn=accounts,dc=testrelm,dc=test
    objectClass: top
    objectClass: person
    objectClass: posixaccount
    objectClass: krbprincipalaux
    objectClass: krbticketpolicyaux
    objectClass: inetuser
    objectClass: ipaobject
    objectClass: ipasshuser
    objectClass: ipaSshGroupOfPubKeys
    objectClass: ipaNTUserAttrs
 
    # search result
    search: 4
    result: 0 Success
 
    # numResponses: 2
    # numEntries: 1'
 
So, 'qwqwwq' is clearly unknown and I would expect that '(qwqwwq=fweewdqe)' is evaluated as undefined either because 'qwqwwq' is not in the ACI or not in the schema. But since '(uid=admin)' is true the whole or-clause becomes true and the object is returned.

As can be seen the result has objectClass posixAccount, so adding this to the search filter with an and-clause should still return the result:

    # KRB5CCNAME=FILE:/tmp/host.ccache ldapsearch -Y GSSAPI -b 'cn=accounts,dc=testrelm,dc=test' '(&(objectClass=posixAccount)(|(uid=admin)(qwqwwq=fweewdqe)))' dn objectClass 
    SASL/GSSAPI authentication started
    SASL username: host/qe-blade-05.idmqe.lab.eng.bos.redhat.com
    SASL SSF: 256
    SASL data security layer installed.
    # extended LDIF
    #
    # LDAPv3
    # base <cn=accounts,dc=testrelm,dc=test> with scope subtree
    # filter: (&(objectClass=posixAccount)(|(uid=admin)(qwqwwq=fweewdqe)))
    # requesting: dn objectClass
    #
 
    # search result
    search: 4
    result: 0 Success
 
    # numResponses: 1
  
It look like the undefined state of '(qwqwwq=fweewdqe)' is used to evaluate the and-clause instead of evaluating the or-clause completely first.
Comment 24 thierry bordaz 2018-08-22 15:01:29 UTC 
A bit of concern as this BZ talk about different issues:

1 - IPA/SSSD :  altsecurityidentities needs to be in the aci:  "permission:System: Read User Addressbook Attributes".

2 - Relax schema checking for targetattr aci: https://pagure.io/389-ds-base/issue/49918. Linked to this 389-ds BZ

3 - inconsistent results when filter component contains non-readable attribute
    https://bugzilla.redhat.com/show_bug.cgi?id=1616412#c23.
    If valid we will open a 389-ds BZ/ticket

Sumit, regarding [1], am I correct than the ACI will be modified ? is it okay if we keep 1616412 linked to #49918 ?
Comment 25 Sumit Bose 2018-08-22 15:19:41 UTC 
(In reply to thierry bordaz from comment #24)
> A bit of concern as this BZ talk about different issues:
> 
> 1 - IPA/SSSD :  altsecurityidentities needs to be in the aci: 
> "permission:System: Read User Addressbook Attributes".
> 
> 2 - Relax schema checking for targetattr aci:
> https://pagure.io/389-ds-base/issue/49918. Linked to this 389-ds BZ
> 
> 3 - inconsistent results when filter component contains non-readable
> attribute
>     https://bugzilla.redhat.com/show_bug.cgi?id=1616412#c23.
>     If valid we will open a 389-ds BZ/ticket
> 
> Sumit, regarding [1], am I correct than the ACI will be modified ? is it
> okay if we keep 1616412 linked to #49918 ?

It depends a bit what the solution for [3] would be. If the result is that the '(&(objectClass=posixAccount)(|(uid=admin)(qwqwwq=fweewdqe)))' filter will return the LDAP object for the admin user then I would expect that the original issue Scott has with the filter containing 'altSecurityIdentities' would be solved as well. I used the original filter from the report and tried to simplify it as much as possible to have an easy reproducer.
Comment 26 Ludwig 2018-08-23 12:12:07 UTC 
Here are some comments:

1] I think it would be good to have a consistent set of acis and searches using them. If it was just missing the rights of altsecurityidentities by chance, I would suggest to add them independent of 3]

2] I am not sure I want to support the relaxing of aci parsing. It does not make much sense to define access to attributes which cannot even be added to the database because they are not defined in the schema (unless schema check of or use of extensibleObject class)

3] unfortunately this is a bug. There was a fix to ignore attributes without access in OR filters if it does not contribute to the result. But in combination with an AND it does not or no longer work. Will investigate.
Comment 27 Ludwig 2018-08-28 08:48:32 UTC 
I was using this setup to reproduce and investigate:
ACI:
dn: dc=example,dc=com
aci: (target ="ldap:///dc=example,dc=com")(targetattr = "cn || sn || uid || objectclass")(version 3.0;acl "Auth read-search access";allow (read, search, compare)(userdn = "ldap:///all");)

Search1:
"(&(objectclass=person)(|(objectclass=xx)(uid=elott)))"
Search2:
"(&(objectclass=person)(|(objectclass=xx)(roomnumber=306)(uid=elott)))"

search1 did return the entry and search2 with the unneeded roomnumber without access didn't. This should have been fixe in ticket #48275.

I was suspecting filter optimization to have introduced it. And today I noticed that the patch for #49372 has been backed out.
Rebuilding with current master now both searches return the entry. 

I think with the next builds for 1.3.7, 1.3.8 and master the issue should be resolved
Comment 28 mreynolds 2018-08-29 16:38:38 UTC 
Please try 389-ds-base-1.3.8.4-12.el7

I think you still need to do the ACI/schema changes, but the filter issue should be resolved in this build
Comment 30 Scott Poore 2018-08-29 21:57:59 UTC 
Verified.

Version ::

389-ds-base-1.3.8.4-12.el7.x86_64

Results ::

[root@qe-blade-05 ~]# ipa certmaprule-add maprule_9_ipa --maprule='(|(userCertificate;binary={cert!bin})(ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500})(altSecurityIdentities=X509:<I>{issuer_dn!ad_x500}<S>{subject_dn!ad_x500}))' --matchrule='<ISSUER>CN=Certificate Authority,O=TESTRELM.TEST' --domain=ipaadcs12r2.test --domain=testrelm.test
-------------------------------------------------------
Added Certificate Identity Mapping Rule "maprule_9_ipa"
-------------------------------------------------------
  Rule name: maprule_9_ipa
  Mapping rule: (|(userCertificate;binary={cert!bin})(ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500})(altSecurityIdentities=X509:<I>{issuer_dn!ad_x500}<S>{subject_dn!ad_x500}))
  Matching rule: <ISSUER>CN=Certificate Authority,O=TESTRELM.TEST
  Domain name: ipaadcs12r2.test, testrelm.test
  Enabled: TRUE

[root@qe-blade-05 ~]# systemctl stop sssd; rm -rf /var/lib/sss/{db,mc}/*; systemctl start sssd

[root@qe-blade-05 ~]# ipa certmap-match /root/ipauser1.crt
---------------
2 users matched
---------------
  Domain: TESTRELM.TEST
  User logins: ipauser1

  Domain: ipaadcs12r2.test
  User logins: ipacertmultiuser1
----------------------------
Number of entries returned 2
----------------------------


Also, as a simpler test, I ran one of the minimal tests from before:

[root@qe-blade-05 ~]# KRB5CCNAME=FILE:/tmp/host.ccache kinit -k

[root@qe-blade-05 ~]# KRB5CCNAME=FILE:/tmp/host.ccache ldapsearch -Y GSSAPI -b 'cn=accounts,dc=testrelm,dc=test' '(|(uid=admin)(qwqwwq=fweewdqe))' dn objectClass
SASL/GSSAPI authentication started
SASL username: host/qe-blade-05.fqdn.domain
SASL SSF: 256
SASL data security layer installed.
# extended LDIF
#
# LDAPv3
# base <cn=accounts,dc=testrelm,dc=test> with scope subtree
# filter: (|(uid=admin)(qwqwwq=fweewdqe))
# requesting: dn objectClass 
#

# admin, users, accounts, testrelm.test
dn: uid=admin,cn=users,cn=accounts,dc=testrelm,dc=test
objectClass: top
objectClass: person
objectClass: posixaccount
objectClass: krbprincipalaux
objectClass: krbticketpolicyaux
objectClass: inetuser
objectClass: ipaobject
objectClass: ipasshuser
objectClass: ipaSshGroupOfPubKeys
objectClass: ipaNTUserAttrs

# search result
search: 4
result: 0 Success

# numResponses: 2
# numEntries: 1
Comment 31 mreynolds 2018-08-29 22:01:29 UTC 
Scott, did you still have to edit the ACI's and add that attribute to the schema, or did it just work with the new build?
Comment 32 Scott Poore 2018-08-29 22:08:32 UTC 
It just worked with the new build.  I didn't get around to trying the ACI and attribute changes yet.  Saw the bug went to ON_QA and it was easy to test right away.

If there's concert about my test env, I can rebuild and run again easily.  Let me do that to be safe.  For now I'll leave in Verified unless something goes wrong tonight/tomorrow with the second test.
Comment 33 mreynolds 2018-08-29 22:16:23 UTC 
(In reply to Scott Poore from comment #32)
> It just worked with the new build.  I didn't get around to trying the ACI
> and attribute changes yet.  Saw the bug went to ON_QA and it was easy to
> test right away.
> 
> If there's concert about my test env, I can rebuild and run again easily. 
> Let me do that to be safe.  For now I'll leave in Verified unless something
> goes wrong tonight/tomorrow with the second test.

No concerns, I was just curious.  Thanks!
Comment 34 Scott Poore 2018-08-30 00:25:58 UTC 
No it was a good question since I tested in the same environment we were debugging on.

That test environment is not rebuilding as it should so I tried a different env to fully reproduce and verify.

[root@master ~]# openssl req -new -newkey rsa:2048 -keyout ipauser1.key -nodes -out ipauser1.csr -subj '/CN=ipauser1'
Generating a 2048 bit RSA private key
...+++
........................................+++
writing new private key to 'ipauser1.key'
-----

[root@master ~]# ipa cert-request ipauser1.csr --principal=ipauser1 --certificate-out=ipauser1.crt
  Issuing CA: ipa
  Certificate: MIIE...
  Subject: CN=ipauser1,O=TESTRELM.TEST
  Issuer: CN=Certificate Authority,O=TESTRELM.TEST
  Not Before: Thu Aug 30 00:10:02 2018 UTC
  Not After: Sun Aug 30 00:10:02 2020 UTC
  Serial number: 11
  Serial number (hex): 0xB

[root@master ~]# ipa user-add-certmapdata ipauser1 --certificate="MII..."
---------------------------------------------
Added certificate mappings to user "ipauser1"
---------------------------------------------
  User login: ipauser1
  Certificate mapping data: X509:<I>O=TESTRELM.TEST,CN=Certificate
                            Authority<S>O=TESTRELM.TEST,CN=ipauser1


[root@master ~]# ipa certmaprule-add maprule_9 --maprule='(|(userCertificate;binary={cert!bin})(ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500})(altSecurityIdentities=X509:<I>{issuer_dn!ad_x500}<S>{subject_dn!ad_x500}))' --matchrule='<ISSUER>CN=Certificate Authority,O=TESTRELM.TEST' --domain=testrelm.test
---------------------------------------------------
Added Certificate Identity Mapping Rule "maprule_9"
---------------------------------------------------
  Rule name: maprule_9
  Mapping rule: (|(userCertificate;binary={cert!bin})(ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500})(altSecurityIdentities=X509:<I>{issuer_dn!ad_x500}<S>{subject_dn!ad_x500}))
  Matching rule: <ISSUER>CN=Certificate Authority,O=TESTRELM.TEST
  Domain name: testrelm.test
  Enabled: TRUE

[root@master ~]# ipa user-mod ipauser1 --certificate=""
------------------------
Modified user "ipauser1"
------------------------
  User login: ipauser1
  First name: f
  Last name: l
  Home directory: /home/ipauser1
  Login shell: /bin/sh
  Principal name: ipauser1
  Principal alias: ipauser1
  Email address: ipauser1
  UID: 1200000001
  GID: 1200000001
  User authentication types: password
  Certificate mapping data: X509:<I>O=TESTRELM.TEST,CN=Certificate
                            Authority<S>O=TESTRELM.TEST,CN=ipauser1
  Account disabled: False
  Password: True
  Member of groups: ipausers
  Kerberos keys available: True

[root@master ~]# ipa certmap-match /root/ipauser1.crt
---------------
0 users matched
---------------
----------------------------
Number of entries returned 0
----------------------------

[root@master ~]# rpm -q 389-ds-base
389-ds-base-1.3.8.4-9.el7.x86_64

###
###
###

[root@master ~]# yum -y update 389-ds-base
...
Updated:
  389-ds-base.x86_64 0:1.3.8.4-12.el7                                                                  

Dependency Updated:
  389-ds-base-libs.x86_64 0:1.3.8.4-12.el7                                                             

Complete!

[root@master ~]# systemctl stop sssd; rm -rf /var/lib/sss/{db,mc}/*; systemctl start sssd

[root@master ~]# ipa certmap-match /root/ipauser1.crt
--------------
1 user matched
--------------
  Domain: TESTRELM.TEST
  User logins: ipauser1
----------------------------
Number of entries returned 1
----------------------------


So, I think we're good.  

Thanks!
Comment 35 Ludwig 2018-08-30 06:54:26 UTC 
(In reply to mreynolds from comment #31)
> Scott, did you still have to edit the ACI's and add that attribute to the
> schema, or did it just work with the new build?

the build should bring back the patch for 48275 and require no schema and aci changes.
and it looks like Scott confirmed it
Comment 39 errata-xmlrpc 2018-10-30 10:15:00 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/RHSA-2018:3127
Note You need to log in before you can comment on or make changes to this bug.