Troubleshooting the CA IM GINA and Credential Provider
search cancel

Troubleshooting the CA IM GINA and Credential Provider

book

Article ID: 36221

calendar_today

Updated On:

Products

CA Identity Manager CA Identity Governance CA Identity Portal

Issue/Introduction

 

 

Introduction/Summary: 

CA Identity Manager includes a GINA and Credential Provider component which you may at times need to troubleshoot.

Background:  

Older versions of Windows used to use GINA in its logon architecture. This was replaced by Credential Provider starting with Windows Vista, Windows 8, Windows 2008/2012.

The GINA/Credential Provider DLL gets loaded by the OS and runs inside of the LogonUI.exe so the bit version of the GINA/Credential Provider DLL must match the bit version of the OS.

Clicking on the hyperlinks in the GINA/Credential Provider will cause the LogonUI.exe which is running as LocalSystem to fork the cube.exe process which will launch a secure browser component in which the target URL will be rendered.

 

 

 

 

Environment

Environment:  

Windows

Resolution

Instructions: 

For GINA,

The configuration utility can be started by running C:\Program Files\CA\Identity Manager\Provisioning GINA\ginaconfig.exe

Registry settings are stored under HKEY\SOFTWARE\ComputerAssociates\GINAUNLOCK

Logging can be configured by setting HKEY\SOFTWARE\ComputerAssociates\GINAUNLOCK\debug to a file location such as c:\gina_debug.log

 

For GINA’s CUBE Secured Browser,

Registry settings are stored under HKEY\SOFTWARE\ComputerAssociates\Cube

Logging can be configured by setting HKEY\SOFTWARE\ComputerAssociates\Cube\debug to a file location such as c:\cube_debug.log

 

For Credential Provider,

The configuration utility can be started by running C:\Program Files\CA\Identity Manager\Credential Provider\CAIMCredProvConfig.exe

Registry settings are stored under HKEY\SOFTWARE\CA\CAIMCredentialProvider

Logging can be configured by setting HKEY\SOFTWARE\CA\CAIMCredentialProvider \debug to a file location such as c:\caimcp_debug.log

 

For Credential Provider’s CUBE Secured Browser,

Registry settings are stored under HKEY\SOFTWARE\CA\Cube

Logging can be configured by setting HKEY\SOFTWARE\CA\Cube\debug to a file location such as c:\cube_debug.log

 

Additional Information

Additional Information:

Problem: No links appear in the GINA/Credential Provider.

Make sure that URLs are set via the configuration utility since the links will not appear if no target URL is set.

Check if the ginaunlock.dll or CAIMCredProv.dll are loaded into the logonui.exe or not with a tool such as Microsoft Process Explorer. If it is not loaded then no links will appear. Remember that the bit version of the DLL (i.e. 32bit vs 64bit) must match the bit version of the OS. Make sure that LocalSystem has not had file directory and registry access restricted. We have also seen that if other GINA/Credential Providers are installed it could also interfere with proper loading of our DLLs.

 

Problem: Unable to load target URL in the Cube Secured Browser after clicking on the links in the GINA/Credential Provider.

Can the machine where the GINA or Credential Provider is installed access the same target URL from a web browser when logged into the machine (i.e. under logged-in user context)? Remember that the GINA and Credential Provider are executing under the LocalSystem context and so is the forked cube.exe so the problem might only be happening under the LocalSystem context which might not have the same browser proxy settings.

You can use a tool such as PXEXEC to help test for this.

Manually launch cube.exe via command line as the logged-in context:

Cube.exe “<URL>” –noprivdrop

Then also use PSEXEC to first launch a command prompt as the LocalSystem context and then run the above command from within this new cmd prompt instead:

Psexec.exe –s –i cmd.exe

Note 1: the easiest way to check/compare/set the browser proxy settings between the logged-in user context and the LocalSystem context is to launch Internet Explorer both as the logged-in user as well as from the LocalSystem context cmd.exe as shown above.

Note 2: If there is an Apache Reverse Proxy involved then check the forwarding configs to make sure all traffic is properly being forwarded.