Chat now with support
Chat with Support

Defender 6.2 - Administration Guide

Getting started Managing Defender objects in Active Directory Configuring security tokens Securing VPN access Securing Web sites Securing Windows-based computers Defender Management Portal (Web interface) Securing PAM-enabled services Delegating Defender roles, tasks, and functions Automating administrative tasks Administrative templates Integration with Active Roles Push Notifications Appendices
Appendix A: Enabling diagnostic logging Appendix B: Troubleshooting common authentication issues Appendix C: Troubleshooting DIGIPASS token issues Appendix D: Defender classes and attributes in Active Directory Appendix E: Defender Event Log messages Appendix F: Defender Client SDK Appendix G: Defender Web Service API

Push Notifications

A notification is a message that displays outside the contextual UI to provide the user with critical reminders or other information from a particular app on the mobile devices. Users can tap the notifications to open the app or take a predefined action directly from the notification. Push notifications for in-house applications allow users in your organization to receive important notification messages on their compatible mobile devices.

How the Defender Push Notification Works

The pushnotification feature is supported and configurable on both Android (version 8 or later) and iOS (iOS 10 or later) devices. The following sections describe the key Admin and User actions for using push notifications.

Admin

User actions

  • From Defender 6.2 onwards, the pushnotification is implicitly triggered when user initiates the login authentication process to Defender eliminating the need to enter keyword PUSH in token field in first login attempt. The existing functionality with type in keyword PUSH works if the first login attempts fails to authenticate or times out.

  • The notification seeks a user response in form of Approve or Deny for access to the resources. Based on the user's response, the respective action takes place and the notification cycle completes.

  • In case of a timeout, the user can also use can use "push" keyword/passcode/Gridsure PIP.

  • Users activate the newly created token from the 6.1.0 release.

User friendly UX

DDL Client Authentication Process (Applicable from Defender 6.2) 

  1. When user initiates the Login process, the page asks for credentials only (username and password) and no passcode.

  2. The DSS automatically identifies if the user has an Android or iOS Token configured. In such case, the application sends a push notification to Defender Soft Token App.

  3. If the user approves the push notification on Defender Soft Token App, they are prompted to next authentication login process to complete the cycle.

  4. If the user denies the push notification any time during the authentication process on Defender Soft Token App, the current login process gets canceled, and the user is redirected to the first Page to re-initiate the Login Process.

  5. If the user neither approves nor deny the push notification on Defender Soft Token App, then the notification times out for that request and user will be able to select one of the two options (if Authentication method is only Token of any policy) to continue with the authentication process as below:

    1. User can trigger the push notification again by clicking on SUBMIT button.

    2. Or user can enter "push" (without quotes, case insensitive) passcode/keyword in passcode field or use Gridsure PIP for authentication.

  6. When DSS identifies that a user does not have Android or iOS token configured, application will prompt the next authentication action (according to the token and Policy selected) on screen for user to complete the login process.

  7. If User has selected “Remember password option” under GINA settings, login screen will be prompted with pre-filled password in read only with enabled Submit button to continue the authentication process. Applicable only on the second login attempt, after denial/timeout of first login request.

EAP Client Authentication Process (Applicable from Defender 6.2) 

  1. When user initiates the Login process, the page asks for credentials only (username and password) under Networks in EAP client.

  2. The DSS automatically identifies if the user has an Android or iOS Token configured and sends a PUSH Notification to Defender Soft Token App while displaying a message confirming the notification sent process.

  3. If the user approves the push notification on Defender Soft Token App, they are prompted to next authentication login process to complete the cycle.

  4. If the user denies the push notification any time during the authentication process on Defender Soft Token App, the current login process gets canceled, and user has to re-initiate the login process.

  5. If the user neither approves nor deny the push notification on Defender Soft Token App, then the notification times out for that request. The user can now select one of the two options (if Authentication method is only Token for any policy) to continue with the authentication process as below:

    1. User can trigger the push notification again by clicking the RESEND button.

    2. Or user can enter "push" (without quotes, case insensitive) passcode/keyword in passcode field.

  6. If DSS identifies that a user does NOT have Android or iOS Token, application will prompt the next authentication action (according to the token and Policy selected) on screen for user to complete the login proces

  7. In case no response is received from the user on the Defender Soft Token App then the request times out and user can select between two options to continue the authentication process as below:

    1. User can trigger the push notification again by clicking on RESEND button.

    2. Or user can click the Sign in with another option button and enter "push" (without quotes, case insensitive) passcode/keyword in passcode field.

  8. GridSure Token is not supported with EAP Client.

ISAPI Client Authentication Process (Applicable from Defender 6.2) 

  1. When user initiates the login process, the page simply asks for ‘username’.

  2. If DSS identifies that a user has an Android or iOS token configured, the application will send a PUSH Notification to Defender Soft Token App.

  3. In the meantime, a waiting page is displayed on the ISAPI client with a message, "Defender needs to verify your identity. We sent a notification to your Defender Soft Token app. Please respond on your device to continue."

    NOTE:The waiting page also displays the ‘Sign in with another option’ button. The user can choose to sign in with token with out waiting for the push notification to be responded/timed-out.

  4. If the user approves the push notification on Defender Soft Token App, they are prompted to the next authentication login process to complete the cycle.

  5. If the user denies the push notification any time during the authentication process on Defender Soft Token App, the current login process gets canceled, and user is redirected to a page displaying a message regarding verification denial.

    NOTE:The Ok button on the verification denial page can be used to re-initiate the login process.

  6. In case no response is received from the user on the Defender Soft Token App then the request times out and user can select between two options to continue the authentication process as below:

    1. User can trigger the push notification again by clicking on RESEND button.

    2. Or user can click the Sign in with another option button and enter "push" (without quotes, case insensitive) passcode/keyword/Gridsure PIP in passcode field.

  7. If DSS identifies that a user does NOT have Android or iOS Token, application will prompt the next authentication action (according to the token and Policy selected) on screen for user to complete the login process.

Push notification timeout configurable

  • The Push Notification verification timeout is a configurable value.

  • On a computer where Defender Security Server is installed, use Registry Editor to create the following value at:

    HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\PassGo Technologies\Defender\DSS Active Directory Edition

    Value type: REG_DWORD

    Value name: NOTIFICATIONTIMEOUT

    Value data: XX

    NOTE:

    • The value can range between decimal 1 to 30. Any other value beyond this range is invalid and will set the default timeout to 30 seconds.

    • In case if the registry key for the timeout is not found (not added), then the default timeout of 30 seconds is set.

    • The server will wait till the timeout seconds before sending the response back to client.

Appendices

Appendix A: Enabling diagnostic logging

To gather additional information on various Defender components, you can enable diagnostic logging for each component.

To enable the logging for some Defender components, you need to edit the Registry.

 Caution: The following sections instruct you to modify the Registry. Note that incorrectly modifying the Registry may severely damage the system. Therefore, you should make the changes carefully. It is highly advisable to create a backup of the Registry before making changes to Registry data.

Administration Console

To enable diagnostic logging for Administration Console

  • On a computer where Administration Console is installed, use Registry Editor to create the following value in the HKLM\SOFTWARE\PassGo Technologies\Defender\Defender AD MMC registry key:

    Value type: REG_DWORD

    Value name: Diagnostics

    Value data: 1

The path to the log file is %ProgramData%\One Identity\Defender\Diagnostics\defender_ade_mmc.txt.

To disable diagnostic logging for Administration Console, delete the Diagnostics value from the Defender AD MMC registry key, or set the value data to 0.

Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating