Troubleshooting

On this Troubleshooting page you can find possible solutions to problems you encounter within Authorization Box.

Architecture

Authorization Box works via a WCF relay. This means that a “conduit” (the Authorization Box Connector) will be installed at your environment that communicates via a service bus (message box) in Azure with our cloud solution. For more information see Security Authorization Box on Azure. This is a best practice way to link on-premises environments to a cloud environment. With this architecture there is no inbound traffic that needs to be allowed, only outbound.

Error message in Authorization box:

The endpoint was not found. Endpoint does not exist. TrackingId: abe449c6-3021-4490-a730-9e01e32b3dea_G0, SystemTracker: box-sb-prod.servicebus.windows.net: eL7bN623.AuthorizationBox.Connector, Timestamp: 2020-11-05T12: 45: 17. Please ensure that you can connect to the internet using HTTP port 80 and TCP port 9350.

Cause:

Possible causes are:

1. The connector (windows service) has not been started;

2. The outbound traffic to the Azure service bus is blocked;

3. The outbound traffic works via a proxy.

Solution for cause 1:

Search under your apps on your PC for “Services”. This opens an overview of all your local services. You need to search for Authorization Box Multi Connector in this list. The status must be “Running”. If this is not the case, you must enable it with the play button.

Solution for cause 2:

To solve this problem, the following 2 things need to be arranged to allow the outbound traffic to the Azure service bus:

1. Azure Relay port settings: you need to open it to the ports described in the following article https://docs.microsoft.com/en-us/azure/azure-relay/relay-port-settings#wcf-relays. This article includes a table that describes the required configuration for port values for Azure Relay.docs.microsoft.com. Note: this is only necessary for outbound;
2. IP/Host whitelisting: Authorization Box is hosted on Azure. As a result, Authorization Box does not have a fixed IP address, but changes daily or more often. Therefore, a range of IP addresses must be added in the firewall (if applicable). See: https://blogs.msdn.microsoft.com/servicebus/2017/01/13/azure-wcf-relay-dns-support/. You should test whether you can whitelist with DNS. You can try whitelisting: box-sb-prod.servicebus.windows.net as the hostname. If this does not work, the following PowerShell script can be used to find IP addresses to whitelist: https://github.com/Azure/azure-relay-dotnet/blob/master/tools/GetNamespaceInfo.ps1 . This returns a list of all IP addresses associated with our service bus. It is possible that this is a large number of addresses.

Solution for cause 3:

Add the proxy address in the config file of the connector. You can do this at the bottom of the config file, before the line with configuration:

You must enter the following code here:

<system.net>

<defaultProxy>

<proxy usesystemdefault = “false” proxyaddress=“http://address:port” bypassonlocal=“false”/>

</defaultProxy>

</system.net>

The correct address must be entered in address: port.

Permission sets and users are fetched from NAV without caching / sync. However, the list remains empty or does not provide complete data.

• A possible solution is to turn off use web services on the Database connection, save and turn on again.
• The problem here is that “old” (default NAV) web services pages are still activated.

• Turn on full sync and try again when it is done
• Set read directly on customer card instead of use of synchronized data

Is this correct:

• URL web service (in page web services NAV)
• Correct domain + credentials of account entering NAV + SUPER Permissions
• Checkmark NTLM on / off
• Type of connector