Problem Definition

When you authenticate on Access Gateway Enterprise Edition portal page and are redirected to the Web Interface, you receive the following error message:

"Access Denied"

Environment

Windows 2003, Service Pack 2 with Web Interface 4.5.1
Presentation Server 4.5 with Hotfix Rollup Pack 01
Access Gateway Enterprise Edition version 8.0 build 49.2
Windows XP Service Pack 2 Home Edition

Troubleshooting Methodology

There could be several reasons for this error message. Refer to the following checklist as the first step to resolve this issue:

Ensure that the root Certificate Authority (CA) certificate for the server certificate on the SSL VPN server is present on all client computers. It is not present when using a self-signed or private certificate.
Ensure that the root CA certificate for the server certificate on the SSL VPN server is present on the Web Interface server. It is not present when using a self-signed or private certificate.
Ensure that the URL entered as the Authentication Service URL can be resolved to Access Gateway Enterprise Edition SSLVPN virtual server on the Web Interface server, and the logon page opens without any errors. Complete the following steps:
Note: It has to match the common name on the certificate.
Open the Access Management Console.
Click on the site.
Click Manage Access Method.
Copy just the URL and put it on the Web browser. The logon page should come up without any errors.

If you receive an error, ensure that the URL is resolved to the correct IP address. If it is, then ensure that the network is configured to allow the Web Interface server to talk to the virtual server over port 443.
The rule on the firewall has to allow the Mapped IP (MIP) or Subnet IP (SNIP) to communicate with the Web Interface over port 80 (or 443 depending on the setup) and it has to allow the Web Interface to communicate with the virtual IP address over 443.

Ensure that the SmartAccess NT Domain on the SSL VPN Global Settings is correct (should be the NetBIOS name for the domain).

Note: The global settings can be overwritten by a Session Policy.

To ensure that it is correct you could put the site in direct mode. Then log on to the portal page, authenticate, and you should be able to open the Web Interface logon page. Enter the same user name, password, and enter the SmartAccess NT Domain as the domain name. If it logs you on, then it is correct and you can place the site back with the authentication service URL.

Resolution

Check the Event Viewer on the Web Interface server. It always logs details about the error and reasons the connection failed.

You can get more details about the issue based on error message received in the Event Viewer of the Web Interface server.

Another way to continue troubleshooting is by using a network packet trace.

Before recording the network packet traces, it is important to understand how everything works. The following steps list the flow of events:

The client opens a Web browser and enters a URL.
The user enters credentials on the portal page and clicks Logon.
At this point the Access Gateway contacts the authentication entity on its configuration (this could be a LDAP server, RADIUS, TACACS, or other).
After the credentials are validated, session policies on the appliance are processed based on additional extra configurations on the appliance (such as group membership). In all scenarios, the global settings for the virtual server apply if a session policy is not used. At this point the gateway briefly displays a Web page notifying the users of a successful logon and that the users are redirected to the homepage.
At this point the user is proxied by the appliance to a Web Interface site. Therefore the client sends a GET request to the home page defined on the global SSL VPN settings, or a session profile. This communication is between the client and the virtual server.
The appliance then sends the GET request to the home page defined on the global SSL VPN settings, or session profile (MIP/SNIP > Web Interface). This GET request reaches the login.aspx. Because the site is configured with an authentication service URL, the Web Interface sends a 302 Found message with a redirect to agesso.aspx. This response first reaches the MIP and then it is sent from the virtual server to the client.
The client sends a GET request for agesso.aspx to the virtual server (client to virtual server). The appliance then sends a GET request for agesso.aspx (MIP/SNIP to Web Interface).
The Web Interface responds with a 401 Unauthorized message.
This response is very important. It should include a header named WWW-Authenticate which should have CitrixAGBasic password_required="yes" as its value as well as a ticket ID.

If for any reason it displays CitrixAGBasic password_required="no", look on the previous GET request for agesso.aspx. The cookie should not have authentication set to explicit. This sometimes is the case if the user is coming from a Web proxy or any other caching system. The following cookie is an example of the cookie value:

Cookie: WIClientInfo=Cookies_On=true&icaClientAvailable=true&icoLaunchPermitted=true&radeClientAvailable=false&radeLaunchPermitted=false
&icaClientVersion=10.100.55836&icaIsPassThrough=3&icaScreenResolution=1024x768&clientConnSecure=true; WIUser=NFuse_CurrentFolder=; WINGSession=icoLaunchPermitted=true&clientConnSecure=true&icaScreenResolution=1024x768&icaClientAvailable=true
&radeLaunchPermitted=false&NFuse_LogonType=AGEPassthrough&radeClientAvailable=false&icaClientVersion=10.100.55836
&icaIsPassThrough=3; WINGDevice=NFuse_ClientName=WI_fwdiEFoyrWK4FYlO_; NSC_USER=administrator; NSC_AAAC=0b51a63068db5062b14a909061d19533; ASP.NET_SessionId=f1wfcmznr2x5t5n2m2mq00eb

After receiving the 401 Unauthorized message, the appliance sends another GET request for agesso.aspx. This time this request includes an authorization header name Authorization. This header includes a hash value of the user name, domain, password, and session ID. The following is a sample header:

Authorization: CitrixAGBasic username="YWRtaW5pc3RyYXRvcg=="; domain="U0FNUEE="; password="bmVsc2luaG8="; AGESessionId="MjIyMDkzMGYyNTcwZmJmMzM1ZjZlNjI3YTQ5YWQ2YmE="
This now causes the Web Interface to send a POST request to the authentication service URL on its configuration. Sometimes the POST request is divided into two different packets. You should look for this information on either the POST request or on the second packet:

0000   3c 3f 78 6d 6c 20 76 65 72 73 69 6f 6e 3d 22 31  <?xml version="1
0010   2e 30 22 20 65 6e 63 6f 64 69 6e 67 3d 22 75 74  .0" encoding="ut
0020   66 2d 38 22 3f 3e 3c 73 6f 61 70 3a 45 6e 76 65  f-8"?><soap:Enve
0030   6c 6f 70 65 20 78 6d 6c 6e 73 3a 73 6f 61 70 3d  lope xmlns:soap=
0040   22 68 74 74 70 3a 2f 2f 73 63 68 65 6d 61 73 2e  "http://schemas.
0050   78 6d 6c 73 6f 61 70 2e 6f 72 67 2f 73 6f 61 70  xmlsoap.org/soap
0060   2f 65 6e 76 65 6c 6f 70 65 2f 22 20 78 6d 6c 6e  /envelope/" xmln
0070   73 3a 78 73 69 3d 22 68 74 74 70 3a 2f 2f 77 77  s:xsi="http://ww
0080   77 2e 77 33 2e 6f 72 67 2f 32 30 30 31 2f 58 4d  w.w3.org/2001/XM
0090   4c 53 63 68 65 6d 61 2d 69 6e 73 74 61 6e 63 65  LSchema-instance
00a0   22 20 78 6d 6c 6e 73 3a 78 73 64 3d 22 68 74 74  " xmlns:xsd="htt
00b0   70 3a 2f 2f 77 77 77 2e 77 33 2e 6f 72 67 2f 32  p://www.w3.org/2
00c0   30 30 31 2f 58 4d 4c 53 63 68 65 6d 61 22 3e 3c  001/XMLSchema"><
00d0   73 6f 61 70 3a 42 6f 64 79 3e 3c 47 65 74 41 63  soap:Body><GetAc
00e0   63 65 73 73 49 6e 66 6f 72 6d 61 74 69 6f 6e 20  cessInformation
00f0   78 6d 6c 6e 73 3d 22 68 74 74 70 3a 2f 2f 63 69  xmlns="http://ci
0100   74 72 69 78 2e 63 6f 6d 2f 53 65 63 75 72 65 41  trix.com/SecureA
0110   63 63 65 73 73 4d 61 6e 61 67 65 72 2f 41 75 74  ccessManager/Aut
0120   68 65 6e 74 69 63 61 74 69 6f 6e 53 65 72 76 69  henticationServi
0130   63 65 2f 56 33 2e 30 22 3e 3c 73 65 73 73 69 6f  ce/V3.0"><sessio
0140   6e 49 64 3e 32 32 32 30 39 33 30 66 32 35 37 30  nId>2220930f2570
0150   66 62 66 33 33 35 66 36 65 36 32 37 61 34 39 61  fbf335f6e627a49a
0160   64 36 62 61 3c 2f 73 65 73 73 69 6f 6e 49 64 3e  d6ba</sessionId>
0170   3c 75 73 65 72 6e 61 6d 65 3e 61 64 6d 69 6e 69  <username>admini
0180   73 74 72 61 74 6f 72 3c 2f 75 73 65 72 6e 61 6d  strator</usernam
0190   65 3e 3c 64 6f 6d 61 69 6e 3e 53 41 4d 50 41 3c  e><domain>SAMPA<
01a0   2f 64 6f 6d 61 69 6e 3e 3c 2f 47 65 74 41 63 63  /domain></GetAcc
01b0   65 73 73 49 6e 66 6f 72 6d 61 74 69 6f 6e 3e 3c  essInformation><
01c0   2f 73 6f 61 70 3a 42 6f 64 79 3e 3c 2f 73 6f 61  /soap:Body></soa
01d0   70 3a 45 6e 76 65 6c 6f 70 65 3e                 p:Envelope>

This step is very important because here the domain name is validated. If the SmartAccess NT Domain on the appliance is incorrect, then you will not receive the next HTTP 200 response.
If everything succeeded, then the appliance responds with a HTTP 200 message and a SOAP envelope containing the smart access farm name, client IP address, and a success status code.
Next a GET request is sent for default.aspx from the client (client to virtual server). The GET request has a Cookie header which contains an authentication ID. An example of the cookie value is as follows:

0000   43 6f 6f 6b 69 65 3a 20 57 49 55 73 65 72 3d 4e  Cookie: WIUser=N
0010   46 75 73 65 5f 43 75 72 72 65 6e 74 46 6f 6c 64  Fuse_CurrentFold
0020   65 72 3d 3b 20 57 49 4e 47 53 65 73 73 69 6f 6e  er=; WINGSession
0030   3d 69 63 61 53 63 72 65 65 6e 52 65 73 6f 6c 75  =icaScreenResolu
0040   74 69 6f 6e 3d 31 30 32 34 78 37 36 38 26 72 61  tion=1024x768&ra
0050   64 65 4c 61 75 6e 63 68 50 65 72 6d 69 74 74 65  deLaunchPermitte
0060   64 3d 66 61 6c 73 65 26 4e 46 75 73 65 5f 4c 6f  d=false&NFuse_Lo
0070   67 6f 6e 54 79 70 65 3d 41 47 45 50 61 73 73 74  gonType=AGEPasst
0080   68 72 6f 75 67 68 26 63 6c 69 65 6e 74 43 6f 6e  hrough&clientCon
0090   6e 53 65 63 75 72 65 3d 74 72 75 65 26 69 63 61  nSecure=true&ica
00a0   43 6c 69 65 6e 74 41 76 61 69 6c 61 62 6c 65 3d  ClientAvailable=
00b0   74 72 75 65 26 69 63 61 43 6c 69 65 6e 74 56 65  true&icaClientVe
00c0   72 73 69 6f 6e 3d 31 30 2e 31 30 30 2e 35 35 38  rsion=10.100.558
00d0   33 36 26 72 61 64 65 43 6c 69 65 6e 74 41 76 61  36&radeClientAva
00e0   69 6c 61 62 6c 65 3d 66 61 6c 73 65 26 69 63 61  ilable=false&ica
00f0   49 73 50 61 73 73 54 68 72 6f 75 67 68 3d 33 26  IsPassThrough=3&
0100   69 63 6f 4c 61 75 6e 63 68 50 65 72 6d 69 74 74  icoLaunchPermitt
0110   65 64 3d 74 72 75 65 3b 20 57 49 41 75 74 68 49  ed=true; WIAuthI
0120   64 3d 42 43 31 43 41 44 31 39 34 44 39 35 46 35  d=BC1CAD194D95F5
0130   38 32 30 42 32 36 38 45 46 45 35 34 33 42 44 36  820B268EFE543BD6
0140   45 33 3b 20 57 49 4e 47 44 65 76 69 63 65 3d 4e  E3; WINGDevice=N
0150   46 75 73 65 5f 43 6c 69 65 6e 74 4e 61 6d 65 3d  Fuse_ClientName=
0160   57 49 5f 66 77 64 69 45 46 6f 79 72 57 4b 34 46  WI_fwdiEFoyrWK4F
0170   59 6c 4f 5f 3b 20 4e 53 43 5f 55 53 45 52 3d 61  YlO_; NSC_USER=a
0180   64 6d 69 6e 69 73 74 72 61 74 6f 72 3b 20 4e 53  dministrator; NS
0190   43 5f 41 41 41 43 3d 30 62 35 31 61 36 33 30 36  C_AAAC=0b51a6306
01a0   38 64 62 35 30 36 32 62 31 34 61 39 30 39 30 36  8db5062b14a90906
01b0   31 64 31 39 35 33 33 3b 20 41 53 50 2e 4e 45 54  1d19533; ASP.NET
01c0   5f 53 65 73 73 69 6f 6e 49 64 3d 66 31 77 66 63  _SessionId=f1wfc
01d0   6d 7a 6e 72 32 78 35 74 35 6e 32 6d 32 6d 71 30  mznr2x5t5n2m2mq0
01e0   30 65 62 0d 0a                                   0eb..

This allows the appliance to send the same GET request to the Web Interface server but as it did before, it adds an Authorization header.
Note: There are always two sides to communication: Client to virtual server and MIP to Web Interface.
The Web Interface then responds with a 200 OK message to the MIP and a frame is displayed on the client browser where the applications enumerate.

More Information

To be able to collect all this information you must decrypt the traffic.