Red Hat Bugzilla – Bug 1616412
ipa certmap-match fails to find ipa user when altSecurityIdentities in mapping rule
Last modified: 2018-10-30 06:16:13 EDT
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
[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 ----------------------------
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?
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).
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@TESTRELM.TEST 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
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@TESTRELM.TEST Valid starting Expires Service principal 08/16/2018 10:52:36 08/17/2018 10:52:36 krbtgt/TESTRELM.TEST@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@TESTRELM.TEST 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?
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?
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@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@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@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.
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.
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
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.
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.
(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?
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?
(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.
(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.
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@TESTRELM.TEST 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@TESTRELM.TEST 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.
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 ?
(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.
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.
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
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
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@TESTRELM.TEST 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
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?
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.
(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!
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@TESTRELM.TEST Principal alias: ipauser1@TESTRELM.TEST Email address: ipauser1@testrelm.test 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!
(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
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