THE INFORMATION IN THIS ARTICLE APPLIES TO:

EFT Server Enterprise version 6.4.3 and later

DISCUSSION

EFT Server provides extensive logging for CAC authentication attempts in EFT.log in the EFT Server installation folder. If you have users unable to connect using their CAC cards, turn on TRACE logging in logging.cfg in the EFT Server installation folder. View the EFT.log to troubleshoot. Don’t forget to comment out the various loggers after you’ve finished troubleshooting.

To turn on TRACE logging to log CAC connection errors

Open logging.cfg and add the following line:

log4cplus.logger.AuthManager =TRACE

Re-attempt the CAC connection and observe log results.
The tables below describe possible error messages, their meanings, and how to troubleshoot the errors.

Log Message	Meaning
Couldn't get certificate info	A certificate wasn’t provided by the client over the SSL session.
Troubleshoot: Has this user authenticated to the computer using their CAC card? If authenticated, are they using a supported browser that can interact with their CAC middleware? For example, IE8 or greater? Was the user prompted to select a certificate? This happens if more than one certificate is present. If so, did they select the correct certificate? If unsure then try again and select an alternate certificate.

Log Message	Meaning
Couldn't find proper SAN field in certificate	The certificated provided didn’t contain a Principal Name (PN) under the Subject Alternative Name (SAN) that contained a well formed EDIPI, for examples 0123456789@mil.
Troubleshoot: Was the user who attempted to log on prompted to select a certificate? This happens if more than one certificate is present. If so, did they select the correct certificate? If unsure, then try again and select an alternate certificate; users must select a certificate that contains the SAN Principal Name that matches the format 0123456789@mil.

Log Message	Meaning
User [name] not found:	Was unable to find a matching user in the directory server using the EDIPI value that was found on the client’s certificate (e.g. 0123456789@mil).
Troubleshoot: What LDAP query does the EFT.log show it is attempting under “Starting ldap search”? Does the value after userPrincipalName match the EDIPI format 01234567899@mil? Look at the list of users in EFT Server. Do they match the format 0123456789@mil? If not then perhaps the EDIPI is not being stored under the UPN field in AD. Sometimes customers will store the EDIPI in an alternate field, such as the pre2000 field. Either adjust EFT Server’s LDAP auth manager query "Attribute" to match what you are using in AD to store the EDIPI, or copy or move the EDIPI value over to the userPrincipalName, which is what EFT Server uses by default for the user Attribute in its LDAP query.

Log Message	Meaning
Failed to obtain certificate from LDAP server for:	Found a matching user but no certificate was found for this user in Active Directory.
Troubleshoot: Does the user have one or more certificates in Active Directory under the user’s Published Certificates tab (must have Advanced Features on to see this tab). This is NOT the same as the list of certificates that appears when you right-click on a user in AD and select Name Mappings. (Rare case) Is it possible that there are multiple matches for this UPN? Run the query in LDAP Browser or similar tool and make sure there is only a SINGLE matching entry. If more than one, then only the first match is used, which may be why the correct user’s certificate isn’t being retrieved.

Log Message	Meaning
Certificates doesn’t match or Certificates don't match for:	A certificate (or more than one) associated with this user (EDIPI) did not match the one provided by the user; i.e., the fingerprints did not match.
Troubleshoot: You MUST ensure that at least one of the certificates in Published Certificates matches the one on their CAC card. Check EFT Server’s log and compare the Thumbprint in the “Incoming certificate info” entry to the Thumbprint of the certificate that was obtained as a result of the LDAP query. If there is a mismatch (the cause for this error) then it is proof positive that the certificates are not the same. It may be possible that the certificate in AD has been updated but the CAC card has not (obtain new CAC card). It may be possible that the wrong certificate was added in AD under Published Certs. Verify the correct certificate (provided by DEERS) is associated with the user that matches the certificate for that corresponding user’s CAC card.

General Issues

After logging off and closing my browser, reopening the browser shows I’m still logged on.
This is the nature of single sign on and integrated authentication. You are not still logged on, but rather the browser is re-authenticating using the CAC cert each time.

I’m being prompted TWICE for my certificate. Once when I navigate to the site and a second time while loading the WTC.
This occurs because Java has no knowledge of certificate selection you made earlier when authenticating. Therefore it must prompt again for you to choose a certificate prior to loading the applet. One way to avoid this is to remove all personal certs from the local cert store except for the CAC one. Also ensure that “Don’t prompt for client certificate selection when no certificates or only one exists” is selected under Java Control Panel > Advanced > Security > General toggles.

I’m being prompted TWICE for my certificate. Once when I navigate to the site and a second time while loading the WTC.

This occurs because Java has no knowledge of certificate selection you made earlier when authenticating. Therefore it must prompt again for you to choose a certificate prior to loading the applet. One way to avoid this is to remove all personal certs from the local cert store except for the CAC one. Also ensure that “Don’t prompt for client certificate selection when no certificates or only one exists” is selected under Java Control Panel > Advanced > Security > General toggles.

Troubleshooting CAC Connections