The following errors may arise during the installation of the GINA login agent, follow the solutions provided to resolve them:
-
'Remcom.exe' is not recognized as an internal or external command, operable program or batch file.
This error occurs if the Remcom.exe file, which is used to install the login agent in remote machines, has been flagged and deleted by the antivirus software. To resolve this issue:
- Check if the Remcom.exe file exists in the bin folder of ADSelfService Plus Installation directory (C:\ManageEngine\ADSelfService Plus\bin).
- If not, check if your antivirus software has removed the file. Configure your antivirus software to trust the Remcom.exe file.
-
Could not Install Client Software
This error occurs because of a network timeout while installing the client software. Make sure the network connection is re-established and try to install the software again.
-
Initiating Connection to Remote Service Failed
This error could occur if the target computer could not be contacted. To prevent this:
- Ensure if such a computer really exists. If so, ensure whether it is connected to the network.
- To check for connectivity, ping this computer from the server where ADSelfService Plus is installed.
- Make sure Remote Registry service is running in the client machine.
-
Couldn't connect to the machine, ADMIN$.Access is denied
This error may occur because admin share has not been enabled in the client computer. To resolve this issue:
- Configure Domain Settings (when run as console) or the Logon Tab (when run as service) with a different user account that has Domain Admin privileges.
- Enable admin share:
- In the client computer, go to Start > Run and type gpedit.msc and hit Enter.
- Expand the Administrative Templates > Network > Network Connections > Windows Firewall.
- Click Domain Profile and double click Windows Firewall: Allow inbound remote administration exception.
- Select Enabled and click OK.
-
Logon Failure: The target account name is incorrect.
This error message can occur if two computers have the same computer name. One computer is located in the child domain; the other computer is located in the parent domain.
-
Logon failure: unknown user name or bad password.
This error message occurs when admin share might not be enabled in the client computer. To resolve this issue:
- Configure Domain Settings (when run as console) or the Logon Tab (when run as service) with a different user account that has Domain Admin privileges.
- Enable admin share:
- In the client computer, go to Start > Run and type gpedit.msc and hit Enter.
- Expand the Administrative Templates > Network > Network Connections > Windows Firewall.
- Click Domain Profile and double click Windows Firewall: Allow inbound remote administration exception.
- Select Enabled and click OK.
-
Couldn't Start Remote Service. Overlapped I/O operation is in progress.
The Remote service couldn't be started either because the copy was blocked by antivirus or because the service couldn't be started automatically. To prevent this:
- In the client machine, go to the Services tab and check whether the Remote Registry and Server services have started. If not, enable these services.
-
Another version of this product is already installed.
This error occurs when another version of this login agent is already installed in the remote machine. To prevent this, uninstall the existing client software from this machine.
-
Another installation is already in progress.
This error occurs when another installation is already in progress. To prevent this, try to install the client software after a few minutes.
-
Could not connect to the machine.
This error could occur if the target computer could not be contacted. To prevent this:
- Ensure if such a computer really exists.
- If so, ensure it is connected to the network.
- To check for connectivity, ping this computer only from the server where ADSelfService Plus is installed.
-
Network path not found/Invalid Credential.
This error could occur if the target computer could not be contacted. To prevent this:
- Configure Domain Settings (when run as console) or the Logon Tab (when run as service) with a different user account that has Domain Admin privileges.
- Enable admin share:
- In the client computer, go to Start > Run and type gpedit.msc and hit Enter.
- Expand the Administrative Templates > Network > Network Connections > Windows Firewall.
- Click Domain Profile and double click Windows Firewall: Allow inbound remote administration exception.
- Select Enabled and click OK.
-
Couldn't copy ADSelfServicePlusClientSoftware.msi
This error occurs because the ADSelfService Plus server has insufficient privileges to access the client machine. To prevent this:
- Configure Domain Settings (when run as console) or the Logon Tab (when run as service) with a different user account that has Domain Admin privileges.
- Enable admin share:
- In the client computer, go to Start > Run and type gpedit.msc and hit Enter.
- Expand the Administrative Templates > Network > Network Connections > Windows Firewall.
- Click Domain Profile and double click Windows Firewall: Allow inbound remote administration exception.
- Select Enabled and click OK.
-
Multiple connections to a server or shared resource by the same user.
This error occurs when other applications or processes are using the same user account used by ADSelfService Plus to try and connect to the remote machine in which the login agent is to be installed. To resolve this issue:
- Disconnect all previous connections to the server or shared resource and try again.
- Configure Domain Settings (when run as console) or the Logon Tab (when run as service) with a different user account that has Domain Admin privileges.
-
Error in security-core.js. The user will encounter a pop-up that displays the script error message.
Probable causes:
- Cookies are not enabled in Internet Explorer for the system account.
- The ADSelfService Plus product URL is not added as a trusted site in Internet Explorer.
Solution:
- Follow the steps here to enable cookies.
- Follow the steps here to add the ADSelfService Plus product URL to the list of trusted sites in Internet Explorer.
-
A blank screen appears when the user tries to authenticate using Windows MFA or perform a self-service action such as password reset or account unlock.
Probable cause: Cookies are not enabled in Internet Explorer on the user's system.
Solution: Follow the steps here to enable cookies in Internet Explorer.
-
A blank screen appears during the endpoint MFA process.
Probable cause: The ADSelfService Plus product URL is not added as a trusted site in Internet Explorer.
Solution: Follow the steps here to add the ADSelfService Plus URL to the list of trusted sites in Internet Explorer.
-
When a user tries to log in to their machine, there is a delay in the loading of the GINA component.
Probable cause: The user is using a self-signed certificate.
Solution: Disable certification revocation, or the act of invalidating a TLS/SSL certificate before its scheduled expiration date. There are two ways to do this.
Method 1: Adding registry values
- Open the Run dialog box by pressing Windows + R on the machine where you have the GINA loading issue.
- Type regedit in the Run dialog box and open the Registry Editor.
- Navigate to Computer\HKEY_USERS\S-1-5-18\Software\Microsoft\Windows\CurrentVersion\Internet Settings.
- Right-click Internet Settings and select New → DWORD.
- Enter the registry value name as CertificateRevocation. Right-click this new registry value and select Modify. In the Edit Dword Value dialog box that appears, enter the value data as 0.
Method 2: Changing settings in Internet Explorer
- Download PsTools on the machine facing the issue.
- Press Windows + R to open the Run dialog box, and type cmd to open the Command Prompt.
- Type in the command psexec.exe -s -i "C:\Program Files (x86)\Internet Explorer\iexplore.exe.".
- The browser will open. Now go to Settings and select Internet options.
- In the Internet Options window, go to the Advanced tab and scroll down to the Security group in the list of Settings.
- Uncheck the checkboxes next to Check for publisher's certificate revocation and Check for server certificate revocation.
- Click OK to close the window.
Solution: Enabling cookies in Internet Explorer on the user's system
Verify if cookies are enabled in Internet Explorer on the user's system. If they’re not, enable cookies by following the steps below:
- Download PsTools on the machine facing the issue.
- Open the Command Prompt and run the command psexec.exe -s -i "C:\Program Files (x86)\Internet Explorer\iexplore.exe.".
- Internet Explorer will open. (Note: Internet Explorer is the only browser that opens for GINA-related errors in Windows, irrespective of other browsers installed on the user's system.)
- Go to Settings and select Internet options.
- In the Internet Options window, go to the Privacy tab. Under Settings, select the Advanced button.
- In the Advanced Privacy Settings window, select the Accept radio button under both First-party Cookies and Third-party Cookies.
- Select OK and close the Advanced Privacy Settings window.
- Click Sites under Settings in the Internet Options window.
- In the Per Site Privacy Actions window that opens, enter the ADSelfService Plus product URL in the Address of website field and click Allow.
- Press OK to close the Per Site Privacy Actions and Internet Options windows.
Solution: Adding the ADSelfService Plus URL to intranet/trusted sites
- Download PsTools on the machine facing the issue.
- Open the Command Prompt and run the command psexec.exe -s -i "C:\Program Files (x86)\Internet Explorer\iexplore.exe.".
- The browser will open. Now go to Settings and select Internet options.
- In the Internet Options window, go to the Security tab and select Trusted sites in the Select a zone to view or change security settings field.
- Click Sites below the Select a zone to view or change security settings field to open the Trusted sites window.
- In the Trusted sites window, type in the URL of the ADSelfService Plus application in the Add this website to the zone field, then click Add.
These steps should ensure that there are no further GINA loading issues.
-
Why is offline multi-factor authentication (offline MFA) not prompted for the user even when the feature is configured and the latest version of the GINA login agent is installed in the user machine?
The multiple reasons for this issue are listed below along with the solution:
- Probable cause 1: The user doesn't belong to the self-service policy with offline MFA enabled.
Solution: Make sure offline MFA has been enabled for the self-service policy the users belongs to. If the user belongs to multiple self-service policies, make sure the self-service policy with offline MFA enabled has the highest priority.
- Probable cause 2: The user has not enrolled their machine for offline MFA.
Solution: Ensure the user has enrolled their machine for offline MFA. Enrollment could even be enforced by enabling the Force user to enroll their device for offline MFA after successful online authentication setting for the self-service policy the user belongs to. The user and their enrolled machine will be listed in the Offline MFA Enrollment Report if successfully enrolled.
- Probable cause 3: MFA is not enabled for the scenarios that have to be secured by offline MFA.
Solution: Follow these steps to enable Machine-based MFA for logins and peripheral actions such as User Account Control (UAC) prompts, system unlocks, and RDP server-side authentication using these steps. After enabling MFA, run the customization scheduler to update these changes across all the user machines.
Reach out to our support team if this issue persists after implementing this solution.
-
Why is the time-based one-time-passcode (TOTP) generated during offline MFA by Google Authenticator, Microsoft Authenticator, Zoho OneAuth TOTP, or a custom TOTP authenticator marked invalid?
Probable cause: The OTP generated during the offline MFA process by the software or hardware TOTP authenticator is rendered invalid if the user machine and the mobile device generating the OTP don't have their times in sync.
Solution: Ensure the mobile device and the machine follow the correct time.
-
Why is the user prevented from logging in to their machine or performing peripheral actions like UAC authentication when not connected to ADSelfService Plus?
- Probable cause 1: MFA is enforced for the specific machine, but the user is neither connected to ADSelfService Plus, nor is their machine enrolled for Offline MFA, and so they're denied access since they cannot perform MFA.
Solution: Check the values of the Manage MFA drop-down (Configuration > Administrative Tools > GINA/Mac/Linux (Ctrl+Alt+Del) > GINA/Mac/Linux Installation > Installed Machines). If this setting is set to Enforce, access will be denied regardless of other settings.
Settings can be configured to require the user to complete online MFA, as well as to encourage or require enrollment of their machine for offline MFA.
- Probable cause 2: MFA is not configured to be bypassed when the ADSelfService Plus server is unreachable, and the user is not enrolled for offline MFA, and so they're denied access because MFA cannot be completed.
Solution: Check the value of the Skip MFA when the ADSelfService Plus server is down or unreachable setting (Configuration > Self-Service > Multi-Factor Authentication > Advanced Settings > Endpoint MFA > Machines Login MFA() If this setting is not enabled, access will be denied. Settings can be configured to require the user to complete online MFA, as well as encourage or require enroll their machine for offline MFA.
To change the outcome according to your requirements, set the value of these settings appropriately and run the customization scheduler to update the changes across all user machines. The scheduler will reflect changes only on login agents installed via the admin portal, or will have remote registry services enabled.
Reach out to our support team if this issue persists even after implementing this solution.
-
Why is the user able to perform offline MFA even after they have disenrolled their machine, or the admin has disenrolled it via the Offline MFA Enrollment Report?
Probable cause: The user is able to perform offline MFA until the disenrollment data is updated on the specific machine.
Solution: The disenrollment data will be updated during the next successful online MFA by any user in the specific machine.
-
Why does the user have to perform online MFA sometimes even after trusting their device or browser?
Probable causes:
- The Restrict users from performing offline MFA after _ days setting is enabled and the user has reached depleted their limit. To ensure the limit is reset and the user can perform offline MFA again, online MFA is initiated.
- The Force user to enroll their device for offline MFA after successful online authentication setting is enabled. To ensure that users complete authentication and are enrolled for offline MFA, the online MFA process is initiated once after offline MFA is enabled and is user is enforced to enroll for it.
-
Why is the display language set in the ADSelfService Plus portal not reflected during Offline MFA?
Probable cause: The display language set via the ADSelfService Plus portal is extended only to UI elements run by the server, and so only some parts of the login agent are dependent on this setting. The other parts, including features like offline MFA and Password Policy Enforcer are dependent on the welcome screen display language settings (Start > Settings > Time & Language > Administrative language settings > Welcome screen and new user accounts > Copy settings > Welcome screen display language).
Solution: Learn how to customize the display language for the offline MFA feature here.
-
Users attempting MFA for Windows logins, in some instances, were redirected back to the login screen inspite of successful MFA completion.
Cause: The built-in Windows login screen timeout period for authentication is shorter than the time required to complete MFA.
Solution: The Windows login screen timeout period can be changed in the registry settings. The default timing upon installation of login agent version 6.7 and above is 3,00,000 ms (5 min). If the timeout period is already set in the registry, installing the login agent won't modify the existing value. The admin can change the value manually using these steps:
- Go to the registry path HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI.
- Right click LogonUI and select DWORD.
- Name it IdleTimeOut. Double click it and change the Value Data to Decimal and specify the IdleTimeOut in milliseconds.
- Click OK.