Menu
The error 401 Unauthorized: Access is denied due to invalid credentials is a common issue when setting up Access Gateway. There’s a number of reasons why you might get this error, below I will explain them and the possible resolutions. First a little background info on what the Access Gateway is doing to produce this error.
Access Gateway Callback
During the authentication process the Access Gateway evaluates policies and sends the results to the Web Interface server. So that the Web Interface server can identify that the policy information it received is from a trusted source, Web Interface makes a “call back” to the CAG that it knows it should be talking to.
The call back is made to the Authentication URL that you specify in your Web Interface site configuration. The URL takes the form of https://yourcagurl.com/CitrixAuthService/AuthService.asmx
It’s important to remember the following things about the Authentication URL
It is case-sensitive
It must be an FQDN
The FQDN should resolve to the internal IP of the CAG
Required root and intermediate certificates must be installed on the Web Interface server
The Authentication URL is accessed by right clicking on your Access Gateway Web Interface site and selecting Authentication Method.
Certificate Mismatch
One of the most common reasons why the callback fails is due to a certificate mismatch. Because the Web Interface server makes the callback using https it must have the related Root and Intermediate certificates within its Trusted Certificate stores.
The best way to check if your certificate chain is OK is to open up Internet Explorer on your Web Interface server and enter the FQDN of your Access Gateway. If you can get to the logon page with no errors then chances are you don’t have any certificate issues.
If you do get a certificate error or the certificate icon to the right of the address bar is red, double-click it and see what is causing the issue. If the certificate chain is not complete you need to get the certificates that complete the chain (Root and Intermediates) from the Certificate Authority that provided you with the certificate for the Access Gateway.
Once you have the certificates complete the following steps to import them:
1. Start –>Run –>MMC
2. File –>Add/Remove Snap-in
3. Select Certificates and click Add
4. Select Computer account and click Next.
5. Select Local computer and click Finish
6. Click OK.
7. Expand Certificates (Local Computer) –>Trusted Root Certification Authorities –>Certificates
8. Right click Certificates –>All Tasks –> Import
9. Click Next. Browse to the location of your CA Trusted Root Certificate file.
10. Click Open, click Next and Finish.
11. Repeat these steps for the Intermediate Certification Authorities node using your CA Intermediate Certificate File
Proxy
If your Web Interface server is configured to go out via a Proxy Server this will also cause issues with the call back process. If the Web Interface server knows it has a proxy to talk to it will simply forward the authentication URL to the proxy rather than resolving the FQDN using the entry in the host file.
To get around the proxy issues you need to add an entry into the Web.config file of the Access Gateway Web Interface site.
The file is located in C:inetpubwwwrootCitrix)
Add the following text before the last line in the file:
<system.net>
<defaultProxy enabled=”false”/>
</system.net>
Troubleshooting
Check the Application log on the Web Interface server. This will normally give you some information about why the callback is failing.
The Event log message is: A communication error occurred while attempting to contact the Access Gateway authentication service at <authentication URL>, Check that the authentication service is running……..
The message reported by the underlying platform was: The remote server returned an error: (407) Proxy Authentication Required.
This indicates the Web Interface is trying to go out via a proxy that requires authentication. See Proxy above
The message reported by the underlying platform was: The operation has timed out.
This can idicate that a proxy is getting in the way. The Web Interface is not resolving the FQDN via its host file and is instead sending it out to a proxy and not getting back the response it requres. See Proxy above
The message reported by the underlying platform was: The remote name could not be resolved
This indicates that the Web Interface server cannot resolve the FQDN in the Authentication URL. Make sure you can ping the FQDN of your Access Gateway and it resolves to the internal VIP address. Note: Depeding on your firewall setup the ping might time out. The important thing is that it resolves to the VIP. You cannot use nslookup as it queries DNS.
The message reported by the underlying platform was: The request failed with the error message:– Lots of random text here
This indicates there is an error in the configured Authentication URL after the FQDN portion. Check that you have /CitrixAuthService/AuthService.asmx correctly after your Access Gateway FQDN
The message reported by the underlying platform was: Unable to connect to the remote server.
This can indicate that the Web Interface is not resolving the FQDN via the hostfile and is trying to go out to the public IP of your Access Gateway or that you have not entered the Authentication URL as https. Make sure you can ping the FQDN of your Access Gateway and it resolves to the internal VIP address and you are also using https.
The message reported by the underlying platform was: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.
This indicates a certificate issue. See Certificate Mismatch above.
Further troubleshooting
If you still haven’t found a resolution by this stage you will need to start digging into network traces. These can be run from the NetScaler System–>Diagnostics node or on the Web Interface server by installing Wireshark
Issues outside of the configuration of the Citrix components can be caused by firewall and routing issues.
Some of the Wireshark filters that you may want to use are
tcp.port==443 && ip.src==<WIServerIP>
for a trace taken from the NetScaler or
or ip.dst==<CAGVIP>
for a trace taken on the Web Interface server.
Try to verify that there is a conversation taking place between the Web Interface server and the CAG, specifically from the Web Interface server on port 443.
Take a look at my blog post on Access Gateway Enterprise Port Configuration for more information about ports and traffic flow.