Enrollment with externalReg enabled is successful when a wrong auth is specified in CS.cfg
Steps to Reproduce:
1. externalReg is enabled 2. the following is the only auth instance in CS.cfg auths.instance.ldap1.authCredName=uid auths.instance.ldap1.dnpattern= auths.instance.ldap1.externalReg.certs.recoverAttributeName=certsToAdd auths.instance.ldap1.externalReg.cuidAttributeName=tokenCUID auths.instance.ldap1.externalReg.tokenTypeAttributeName=tokenType auths.instance.ldap1.ldap.basedn=ou=People,dc=pki-tps1 auths.instance.ldap1.ldap.ldapauth.authtype=BasicAuth auths.instance.ldap1.ldap.ldapauth.bindDN= auths.instance.ldap1.ldap.ldapauth.bindPWPrompt=ldap1 auths.instance.ldap1.ldap.ldapauth.clientCertNickname=subsystemCert cert-pki-tps-rpattath-Sep30-2016 auths.instance.ldap1.ldap.ldapconn.host=nocp4.idm.lab.eng.rdu2.redhat.com auths.instance.ldap1.ldap.ldapconn.port=9389 auths.instance.ldap1.ldap.ldapconn.secureConn=False auths.instance.ldap1.ldap.ldapconn.version=3 auths.instance.ldap1.ldap.maxConns=15 auths.instance.ldap1.ldap.minConns=3 auths.instance.ldap1.ldapByteAttributes= auths.instance.ldap1.ldapStringAttributes=mail,cn,uid,edipi,pcc,firstname,lastn ame,exec-edipi,exec-pcc,exec-mail,certsToAdd,tokenCUID,tokenType auths.instance.ldap1.ldapStringAttributes._000=################################ # auths.instance.ldap1.ldapStringAttributes._001=# For isExternalReg auths.instance.ldap1.ldapStringAttributes._002=# attributes will be available as auths.instance.ldap1.ldapStringAttributes._003=# $<attribute>$ auths.instance.ldap1.ldapStringAttributes._004=# attributes example: auths.instance.ldap1.ldapStringAttributes._005=#mail,cn,uid,edipi,pcc,firstname ,lastname,exec-edipi,exec-pcc,exec-mail,certsToAdd,tokenCUID,tokenType auths.instance.ldap1.ldapStringAttributes._006=################################ # auths.instance.ldap1.pluginName=UidPwdDirAuth auths.instance.ldap1.ui.description.en=This authenticates user against the LDAP directory. auths.instance.ldap1.ui.id.PASSWORD.credMap.authCred=pwd auths.instance.ldap1.ui.id.PASSWORD.credMap.msgCred.extlogin=PASSWORD auths.instance.ldap1.ui.id.PASSWORD.credMap.msgCred.login=password auths.instance.ldap1.ui.id.PASSWORD.description.en=LDAP Password auths.instance.ldap1.ui.id.PASSWORD.name.en=LDAP Password auths.instance.ldap1.ui.id.UID.credMap.authCred=uid auths.instance.ldap1.ui.id.UID.credMap.msgCred.extlogin=UID auths.instance.ldap1.ui.id.UID.credMap.msgCred.login=screen_name auths.instance.ldap1.ui.id.UID.description.en=LDAP User ID auths.instance.ldap1.ui.id.UID.name.en=LDAP User ID auths.instance.ldap1.ui.retries=3 auths.instance.ldap1.ui.title.en=LDAP Authentication 3. op.enroll.externalRegAddToToken.auth.id=ldap2 4. enroll a token to recover certs
Actual results:
Enrollment is successful
Expected results:
Enrollment should fail
Investigation result: For ExternalReg, the auth.id resides with: externalReg.authId= instead of the profile (op.enroll.externalRegAddToToken.auth.id). Reson being that for externalReg gets its profile from the ldap user record, so you authenticate before you get to the record.
This is by design, so is not a bug. If anything at all, perhaps we could remove the auth related params from the externalReg profiles so it will be less confusing.
Replying to [comment:2 cfu]:
Investigation result: For ExternalReg, the auth.id resides with: externalReg.authId= instead of the profile (op.enroll.externalRegAddToToken.auth.id). Reson being that for externalReg gets its profile from the ldap user record, so you authenticate before you get to the record. This is by design, so is not a bug. If anything at all, perhaps we could remove the auth related params from the externalReg profiles so it will be less confusing.
Renaming ticket and moving it to 10.4.
Metadata Update from @rpattath: - Issue set to the milestone: UNTRIAGED
Metadata Update from @mharmsen: - Custom field feature adjusted to '' - Custom field proposedmilestone adjusted to '' - Custom field proposedpriority adjusted to '' - Custom field reviewer adjusted to '' - Custom field version adjusted to '' - Issue close_status updated to: None - Issue set to the milestone: 10.4 (was: UNTRIAGED)
Per CS/DS Meeting of August 7, 2017, it was determined to move this issue from 10.4 ==> FUTURE.
Metadata Update from @mharmsen: - Issue set to the milestone: FUTURE (was: 10.4)
Dogtag PKI is moving from Pagure issues to GitHub issues. This means that existing or new issues will be reported and tracked through Dogtag PKI's GitHub Issue tracker.
This issue has been cloned to GitHub and is available here: https://github.com/dogtagpki/pki/issues/2626
If you want to receive further updates on the issue, please navigate to the GitHub issue and click on Subscribe button.
Subscribe
Thank you for understanding, and we apologize for any inconvenience.
Metadata Update from @dmoluguw: - Issue close_status updated to: migrated - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.