From the console select Authentication Instance Id PinDirEnrollment with authType value as SslclientAuth, its not doing client auth as expected.
Steps to Reproduce:
Executed following test case from the test plan: set-up a ldap ssl/tls instance for user authentication. goto the ca's admin console, configuration tab, authentication and enable the authentication plugin UidPwdPinDirAuth and set the following attrs removepin - don't select pinAttr - pin dnpattern - UID=$attr.uid, OU=$dn.ou, O=$dn.o, ldapStringAttributes : mail ldapconnhost: localhost ldapconnport: <LDAPS port> secureconn : YES binddn: cn=directory manager password: netscape clientcertnickname: agentcert make sure that this certificate cannot access LDAP authtype : sslClientAuth basedn: o=example run setpin utility and set the pin for user uid=testuser1,ou=people,dc=setpin-test-ssl note down the pin printed by the setpin utility goto the ca's admin console and create a new profile that uses the above created pinBased Authentication plugin # cat /var/lib/pki/pki-master/ca/conf/CS.cfg | grep PinDirEnrollment auths.instance.PinDirEnrollment.dnpattern=UID=$attr.uid, OU=$dn.ou auths.instance.PinDirEnrollment.ldap.basedn=ou=people,dc=setpin-test-ssl auths.instance.PinDirEnrollment.ldap.ldapauth.authtype=SslClientAuth auths.instance.PinDirEnrollment.ldap.ldapauth.bindDN= auths.instance.PinDirEnrollment.ldap.ldapauth.bindPWPrompt=Rule PinDirEnrollment auths.instance.PinDirEnrollment.ldap.ldapauth.clientCertNickname=agentcert auths.instance.PinDirEnrollment.ldap.ldapconn.host=XXXXXX auths.instance.PinDirEnrollment.ldap.ldapconn.port=1699 auths.instance.PinDirEnrollment.ldap.ldapconn.secureConn=true auths.instance.PinDirEnrollment.ldap.ldapconn.version=3 auths.instance.PinDirEnrollment.ldap.maxConns= auths.instance.PinDirEnrollment.ldap.minConns= auths.instance.PinDirEnrollment.ldapByteAttributes= auths.instance.PinDirEnrollment.ldapStringAttributes=mail auths.instance.PinDirEnrollment.pinAttr=pin auths.instance.PinDirEnrollment.pluginName=UidPwdPinDirAuth auths.instance.PinDirEnrollment.removePin=false goto the eeSSL page and and select enrollment with the new profile created in the last step fill in the ldap user id, password and the pin
Actual results:
enrollment is successful.
Expected results:
enrollment should FAIL.
Additional info:
Created attachment 1065063 in associated bug Debug log for PinDirEnrollment with authType value as SslclientAuth.
Per decision made on 08/31/2015 - 10.3.
Per PKI Bug Council of 06/23/2016: 10.3.5
See comment #4 in bug.
NOTE: Asha to verify whether or not this ticket and associated bug are valid, and close both as invalid if it is found to be invalid; otherwise, this ticket needs to be moved to 10.3.6.
commit e5ef4374eae5219a8b5e9a216c1c2ed77fb3e709 Author: Jack Magne jmagne@dhcp-16-206.sjc.redhat.com Date: Tue Aug 16 16:58:49 2016 -0700
Authentication Instance Id PinDirEnrollment with authType value as SslclientAuth is not working. Ticket #1578 The fixing of this problem required the following: 1. Hook up a java callback that is designed to allow the selection of a candidate client auth cert to be sent to Ldap in the LdapSSLSocket factory object. Previously we simply manually set the desired client auth cert nickname, which is provided by the console interface when cofiguring the "removePin" portion of the UidPinDir Authentication method. Doing it this way has the benefit of giving us some logging to show when the actual client auth cert is being requested by the server. We get to see the list of candidate certs and when we match one of those with the requested cert name, established by the console. This client auth problem applies ONLY to the connection pool that is used to remove the pin attribute from an external authentication directory. 2. Previously the code, when setting up client auth for "removePin", would make one single call to create the SSL socket to connect to ldap over client auth. Now, based on some code I saw in the JSS test suite, the socket is constructed in two steps. Doing this causes things to work. Further investigation down the line could figure out what is going on at the lower level. 3. Was able to test this to work with the reported problem directory server provided by QE. Note: for pin removal to work, we must also make sure that the user we authenticating to (through client auth) has the power to actually remove the pin attribute from various users.
Authentication Instance Id PinDirEnrollment with authType value as SslclientAuth is not working.
Pushed to master, closing ticket #1578
On August 23, jmagne pushed the following to master:
commit a4d726098458225a0605faca9f11ebaa4dab036f Author: Jack Magne <jmagne@dhcp-16-206.sjc.redhat.com> Date: Tue Aug 16 16:58:49 2016 -0700 Authentication Instance Id PinDirEnrollment with authType value as SslclientAuth is not working. Ticket #1578 The fixing of this problem required the following: 1. Hook up a java callback that is designed to allow the selection of a candidate client auth cert to be sent to Ldap in the LdapSSLSocket factory object. Previously we simply manually set the desired client auth cert nickname, which is provided by the console interface when cofiguring the "removePin" portion of the UidPinDir Authentication method. Doing it this way has the benefit of giving us some logging to show when the actual client auth cert is being requested by the server. We get to see the list of candidate certs and when we match one of those with the requested cert name, established by the console. This client auth problem applies ONLY to the connection pool that is used to remove the pin attribute from an external authentication directory. 2. Previously the code, when setting up client auth for "removePin", would make one single call to create the SSL socket to connect to ldap over client auth. Now, based on some code I saw in the JSS test suite, the socket is constructed in two steps. Doing this causes things to work. Further investigation down the line could figure out what is going on at the lower level. 3. Was able to test this to work with the reported problem directory server provided by QE. Note: for pin removal to work, we must also make sure that the user we authenticating to (through client auth) has the power to actually remove the pin attribute from various users.
This commit must still be cherry-picked to DOGTAG_10_3_BRANCH.
Cherry-picked in to DOGTAG_10_3_BRANCH:
commit ab570231ef3f63712cf7404ca2171cbea0ae0f92 Author: Jack Magne <jmagne@dhcp-16-206.sjc.redhat.com> Date: Tue Aug 16 16:58:49 2016 -0700 Authentication Instance Id PinDirEnrollment with authType value as SslclientAuth is not working. Ticket #1578 The fixing of this problem required the following: 1. Hook up a java callback that is designed to allow the selection of a candidate client auth cert to be sent to Ldap in the LdapSSLSocket factory object. Previously we simply manually set the desired client auth cert nickname, which is provided by the console interface when cofiguring the "removePin" portion of the UidPinDir Authentication method. Doing it this way has the benefit of giving us some logging to show when the actual client auth cert is being requested by the server. We get to see the list of candidate certs and when we match one of those with the requested cert name, established by the console. This client auth problem applies ONLY to the connection pool that is used to remove the pin attribute from an external authentication directory. 2. Previously the code, when setting up client auth for "removePin", would make one single call to create the SSL socket to connect to ldap over client auth. Now, based on some code I saw in the JSS test suite, the socket is constructed in two steps. Doing this causes things to work. Further investigation down the line could figure out what is going on at the lower level. 3. Was able to test this to work with the reported problem directory server provided by QE. Note: for pin removal to work, we must also make sure that the user we authenticating to (through client auth) has the power to actually remove the pin attribute from various users. (cherry picked from commit a4d726098458225a0605faca9f11ebaa4dab036f)
Metadata Update from @aakkiang: - Issue assigned to jmagne - Issue set to the milestone: 10.3.6
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/2137
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.
Login to comment on this ticket.