Skip to content

Troubleshooting

Check the issues below for common problems and suggested ways of handling them.

Users Cannot Log into the Website After First Installation

When installing File Access Manager for the first time, the Identity Sync task has to complete its operation in order to get a list of users who can log into the web application. You can follow the progress of this task on the Health Center in the administrative client. The task status is generally displayed in the web application which you cannot access before this task has completed.

3rd Party SSO Login Users Cannot Access the Website

If 3rd party SSO login users cannot access the website, follow these steps to troubleshoot the issue:

  1. Verify that the correct connectivity values were stored in the database.

    • Table: system_configuration_value
    • Record: WebSamlConfiguration

  2. The JSON should be similar to the sample below, depending on the SSO provider:

    • EntityId - The File Access Manager application created in the SSO provider
    • MetadataUrl - Generated in the process of creating the application above
      {
"EntityId": "FAM_SAML_LogIn",
"MetadataUrl": "https://dev-39214733.okta.com/app/exka5w2f1LvL5gpI05d6/sso/saml/metadata",
"SignatureAlgorithm": "http://www.w3.org/2001/04/xmldsig-more#rsa-sha256",
"CertificateValidationMode": "0",
"RevocationMode": "0"
}

  3. Verify that all the users from the SSO provider were added correctly to the File Access Manager database.

    The identity collector should upload the users listed in the data source into the following tables:

    • whiteops.ra_user
    • crowdSource.[user]

Connection Errors

Following a successful upgrade to version 8.3, services will only accept http2 connections (version 8.3 uses gRPC as the communication protocol, the requires http2).

Once fully upgraded, File Access Manager services should work seamlessly with http2. In instances where the customer upgrade halts after a successful Agent Configuration upgrade, one potential cause could be that the communication middleware (such as a load balancer) is not configured to work with http2.

The following error will be shown in the log of services trying to connect to the Agent Configuration manager:

  Unable to connect to test.domain.com with user_name Grpc.Core.RpcException: Status(StatusCode=Internal, Detail="Bad gRPC response. Response protocol downgraded to HTTP/1.0.")at Grpc.Net.Client.Internal.HttpClientCallInvoker.BlockingUnaryCall[TRequest,TResponse](Method`2 method, String host, CallOptions options, TRequest request)at Grpc.Core.Interceptors.InterceptingCallInvoker.<BlockingUnaryCall>b__3_0[TRequest,TResponse](TRequest req, ClientInterceptorContext`2 ctx)at Grpc.Core.ClientBase.ClientBaseConfiguration.ClientBaseConfigurationInterceptor.BlockingUnaryCall[TRequest,TResponse](TRequest request, ClientInterceptorContext`2 context, BlockingUnaryCallContinuation`2 continuation)at Grpc.Core.Interceptors.InterceptingCallInvoker.BlockingUnaryCall[TRequest,TResponse](Method`2 method, String host, CallOptions options, TRequest request)

If such errors appear in the log files, make sure all communication middleware components are configured to work over http/2, and the connection is not downgraded to http/1.

In case the error appears in a service that is still in version 8.1, the errors may be safely ignored. Once the service is fully upgraded the errors will stop showing in the log.

Firewall Verification

If an installation problem occurs when installing File Access Manager on multiple servers, verify the firewall is not blocking the installation process.

Access Denied to Business Website

If access is denied to the File Access Manager business website, it may be caused by not having proper configuration in IIS. .NET Trust Level in IIS needs to be set to Full to allow for consistent access.

Use the IIS Manager to set the .NET Trust Level to Full. This can be found by navigating to Default Web Site > .NET Trust Levels. Select Full (internal) from the dropdown. Select Apply.

Failed Installation of IIS

If File Access Manager did not install the IIS, verify the Request Filtering is turned off. If Request Filtering is on, the File Access Manager business website may fail to load.

Communication Issues Between Collectors or Activity Monitors and the Agent Configuration Manager

The Agent Configuration Manager and the Collectors or Activity Monitors might have trouble communicating with each other. This would result in no activities being collected or failed Crawl / Permission Collection / Data Classification tasks.

This could be caused by a registry value interfering with the SSL handshake that usually occurs between those services. This would introduce an extra criterion for the certificate to comply with that isn’t normally part of the procedure, preventing the service from properly identifying itself.

This registry value is called SendTrustedIssuerList and it’s located under the following path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL.

If this registry value exists and is set to 1 (true), set it to 0 (false).

If it doesn’t exist or is set to 0 (false), then this is not the cause of the issue.

More information about this registry value can be found here: https://learn.microsoft.com/en-us/windows-server/security/tls/what-s-new-in-tls-ssl-schannel-ssp-overview#BKMK_TrustedIssuers

Further Information

For further configuration, and installation of the File Access Manager website, see chapter File Access Manager Initial Configuration in the File Access Manager Administrator Guide.