Troubleshooting

During initial configuration, enable event logs for MDM API calls. You can use these logs to verify proper configuration. After you have verified proper configuration, you can disable logging for these events. Then, enable only for troubleshooting.

To enable logging for MDM API calls:

1. Select System Log/Monitoring.

2. Click the Events tab.

3. Click the Settings tab to display the configuration page.

After you have completed the MDM server configuration, you can view system event logs to verify that the polling is occurring.

To display the Events log:

1. Select System Log/Monitoring.

2. Click the Events tab.

3. Click the Log tab.

Next, to verify user access, you can attempt to connect to a wireless access point with your smart phone, and then view the user access logs.

To display the User Access log:

1. Select System Log/Monitoring.

2. Click the User Access tab.

3. Click the Log tab.

After you have verified proper configuration, you are not likely to need to tune the authentication server configuration, the 802.1x framework, or the enforcement points. However, based on user experience, MDM capabilities, and security threats, there are a few configuration elements you might want to tune from time to time.

Table below describes these configuration elements.

Configuration Element	Tuning
Remediation	In a network access control solution, noncompliant endpoints are typically placed in a remediation VLAN that serves a Web page. The Web page explains the steps users can take to make their endpoints compliant so that they can access the network. Your reasons for denying access might change from time to time. For example, your initial policy might be based on compliance with an MDM policy, and you can give steps on how to bring a device into compliance. You want to set an expectation on how long it takes for the MDM to reassess compliance. You might want to factor in Ivanti Policy Secure device check interval to estimate how long until the device can access the network. When there are new threats that exploit vulnerabilities in specific mobile platforms, you might create rules on the fly that deny access from specific platforms. If events like this occur, you might want to update your remediation message so that users can understand why access is denied.
Realm – Device Check Interval	You might want to tune this setting as you learn how frequently the MDM updates device records, or if the standard practice of the MDM changes. If the MDM records are updated every four hours, it does not make sense to poll every 10 minutes. If the MDM records are updated in real time, it might make sense to poll every 10 minutes.
Roles and role mapping rules	As you learn about mobile security threats and vulnerabilities, you might make changes to roles and role mapping rules or create new classifications. In general, you list restrictive rules first and set the stop flag. For example, if a device is noncompliant and maps to a noncompliant role, you would list it near the top of the rules for the realm and set the stop flag. Classification based on device type or platform can be more complicated. When you initially role out your BYOD solution, you might want to use roles to merely classify the devices, and so the rule classifying it would not need to be near the top of the list and would not need to have a stop flag. In response to a threat, however, you might want to use the role and role mapping configuration to deny access from a specific device platform. If events like this occur, you can edit your rules to map the vulnerable platform to an appropriate role and set the stop flag so that permissive roles are not assigned.
RADIUS return attribute policy	Likewise, in response to threats and vulnerabilities, you can edit your rules to place formerly trusted device types into a remediation or guest VLAN instead of an employee VLAN; and then allow access again when you are no longer concerned with the threat.
Infranet Enforcer resource access policy	Likewise, in response to threats and vulnerabilities, you can edit your rules to deny access from formerly trusted device types; and then allow access again when you are no longer concerned with the threat.

Using the Debug Logs

The Ivanti Global Support Center might direct you to create a debug log to assist them in helping you debug an issue with the system. The debug log is used only by PSGSC.

To use debug logging:

1. Select Troubleshooting > Monitoring > Debug Log to display the configuration page. Complete the configuration as described in table below.

2. Click Save Changes. When you save changes with Debug Logging On selected, the system begins generating debug log entries.

3. Initiate the action you want to debug, such as a user sign in. You can reset the debug log file to restart debug logging if it takes you too long to initiate the action.

4. Click Save Debug Log to save the debug log to a file that you can send to PSGSC. You can clear the log after you have saved it to a file.

5. Clear the Debug Logging On check box and click Save Changes to turn off debug logging.

Settings	Guidelines
Current Log Size	Displays the size of the current log file. If it is large, use the controls to save, reset, or clear the log file.
Debug Logging On	Select to turn on debug logging.
Debug Log Size	Specify a maximum debug logfile size. The default is 2 MB. The maximum is 250 MB.
Debug Log Detail Level	Specify the debug log detail level. Obtain this from Ivanti Global Support Center.
Include logs	Select this option to include system logs in the debug log file. Recommended.
Process Names	Specify the process name. Obtain this from Ivanti Global Support Center.
Event Codes	Specify the event code. Obtain this from Ivanti Global Support Center. For MDM integration issues, Ivanti Global Support Center typically likes to collect debugging information for codes MDM, Auth, agentman, and Realm. The text is not case sensitive.