After upgrading our internal Exchange organisation to Exchange Server 2007 (we have a single server implementation), I’ve found that Outlook Web Access no longer works through the Access Gateway Advanced Access Navigator interface. Instead of the user being presented with OWA they see this page:

No amount of attempting to log into OWA through this interface will result in a successful login. Looking at a packet capture of the initial logon attempt the Access Gateway sends the initial GET request and the Exchange server responds with a 401 and sends back the authentication options as you can see here:

- HTTP: Response, HTTP/1.1, Status Code = 401
ProtocolVersion: HTTP/1.1
StatusCode: 401, Unauthorized
Reason: Unauthorized
ContentLength: 1656
ContentType: text/html
Server: Microsoft-IIS/6.0
WWWAuthenticate: Negotiate
WWWAuthenticate: NTLM
WWWAuthenticate: Basic realm=”exchange.company.local”
X-Powered-By: ASP.NET
Date: Wed, 09 May 2007 05:10:18 GMT
HeaderEnd: CRLF

One glaring issue with this response is that realm used for Basic authentication is the name of the server, not the domain name as specified in the IIS configuration, but I think that’s another issue. AAC does attempt NTLM authentication in the next packet – this is the GET request (I’ve truncated the Authorisation field):

- HTTP: Request, GET /owa
Command: GET
+ URI: /owa
ProtocolVersion: HTTP/1.1
Connection: Keep-Alive
Via: 1.1 FW
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-ms-application, application/vnd.ms-xpsdocument, application/xaml+xml, application/x-ms-xbap, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint
Accept-Language: en-au
Cookie: LPNAME=/CitrixLogonPoint/navui/;
UA-CPU: x86
UserAgent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.0.04506; .NET CLR 1.1.4322; InfoPath.2)
Host: exchange.company.local
Cache-Control: no-cache
Pragma: no-cache
Authorization: Negotiate YIIKuAYGKwYBBQUCoIIKrDCCCqigJDAiBgkqhki..

The Exchange server again responds with HTTP 401 and this process then repeats for another round until the AAC gives up on authenticating and displays the page seen above. Unfortunately I can’t work out a reason for this behaviour and don’t have a solution, but it’s something you should be aware of before you start upgrading to Exchange Server 2007. Hopefully we’ll see a resolution from Citrix soon.

UPDATE: I haven’t had an opportunity to test this out yet, but check out this thread at the Citrix Forums for some information on getting the CAG and OWA 2007 working.

Access Gateway Advanced and Outlook Web Access 2007 is post from stealthpuppy.com. Except as noted otherwise, this work is © 2005-2012 Aaron Parker and is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

We run Access Gateway Advanced, so I needed to throw an Advanced Access Control upgrade into the mix. Rather than migrate directly from version 4.2, I started with a fresh server and built a new configuration from scratch. I did this because I wanted to go through the whole process again to make sure there wasn’t a better way of doing things. When I built the new AAC server, I used Windows Server 2003 Service Pack 2 and SQL Server 2005 Express Service Pack 2 (we have a small implementation internally, so a single server makes sense for us). I was a little worried about this because both service packs are new and Citrix don’t appear to have official word on either service pack.

The first issue I ran into was a problem with the Access Gateway COM server after installation of Advanced Access Control. The following errors were reported when attempting to start the COM server:

Event Type: Failure Audit
Event Source: MSSQL$CITRIXAAC
Event Category: (4)
Event ID: 18456
Date: 21/03/2007
Time: 4:08:45 PM
User: DOMAIN\serviceaccount
Computer: SERVER
Description:
Login failed for user ‘DOMAIN\serviceaccount’. [CLIENT: <local machine>]
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Data:
0000: 18 48 00 00 0e 00 00 00 .H……
0008: 13 00 00 00 43 00 4c 00 ….C.L.
0010: 41 00 41 00 47 00 45 00 A.A.G.E.
0018: 30 00 31 00 5c 00 43 00 0.1.\.C.
0020: 49 00 54 00 52 00 49 00 I.T.R.I.
0028: 58 00 41 00 41 00 43 00 X.A.A.C.
0030: 00 00 07 00 00 00 6d 00 ……m.
0038: 61 00 73 00 74 00 65 00 a.s.t.e.
0040: 72 00 00 00 r…

---

Event Type: Error
Event Source: COM+
Event Category: (98)
Event ID: 4833
Date: 21/03/2007
Time: 3:37:57 PM
User: N/A
Computer: SERVER
Description:
The initialization of the COM+ surrogate failed — the CApplication object failed to initialize.{666F1874-46B6-4149-BD55-8C317FB73CC0}
Server Application ID: {666F1874-46B6-4149-BD55-8C317FB73CC0}
Server Application Instance ID:
{0350A841-7287-44A2-A1A8-0E5161856650}
Server Application Name: Access Gateway Server
The serious nature of this error has caused the process to terminate.
Error Code = 0×80131600 :
COM+ Services Internals Information:
File: d:\nt\com\complus\src\comsvcs\srgtapi\csrgtserv.cpp, Line: 371
Comsvcs.dll file version: ENU 2001.12.4720.3959 shp
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

So this appeared to be an issue with the permissions on database access for the service account to SQL Server Express. No amount of adding or changing permissions helped so I rebuilt the box from scratch. Luckily I had a scripted installation, so this didn’t take long.

The second time around these errors were gone, however I found that when selecting SQL Server 2005 Express in the Server Configuration tool I was still having some database issues. I had installed SQL Server manually before the installation of AAC so I can only assume that was the cause. So instead of that I connected to the database instance just like it was full blown SQL Server and the Server Configuration tool completed successfully.

Now that I had AAC up and running, I configured a logon point, some resources and access policy and customised the awful, awful graphics Citrix have added to 4.5. Here’s what I whipped up:

Far more appealing don’t you think? A little ‘Microsofty’ I know, but much better. On graphics too, don’t forget that the Access Gateway only handles GIF files; don’t use PNGs like I did.

The upgrade of the Access Gateway appliance itself was very straightforward. I made a backup of the configuration and then uploaded the 4.5 upgrade. After a reboot, I uploaded the 4.5.1 hotfix and it looked good – just as expected. I then connected the Access Gateway to my new AAC farm and then thought that all was well until I ran into the dreaded ‘Protocol Driver Error‘.

What I’d missed was adding the Secure Ticket Authorities to the Access Gateway properties (through Gateway Appliances properties / Secure Ticket Authority option). Something so simple that cost me about ½ hour of my time chasing my tail. What have I learnt from this? 1. Blog about it so I won’t forget for next time and 2. Use a checklist when installing the Access Gateway.

Now all that I’m left with is a ’500 Internal Server Error’ when I restart the AAC services but that can wait for another time.

Adventures in Access Gateway 4.5 Upgrade is post from stealthpuppy.com. Except as noted otherwise, this work is © 2005-2012 Aaron Parker and is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

The problem with this scan is that it does not prove that the machine is actually a member of your internal domain; it only proves that it is a member of a domain that matches the NetBIOS name of your domain. I’ve actually tested this out by creating a domain (e.g. company.internal) on a test machine that matches the NetBIOS name (e.g. COMPANY) of our production network (e.g. company.local). Connecting to and logging into a logon point that requires membership of the domain (COMPANY), works from a client machine that is a member of any domain named COMPANY.

What this highlights is that scans should only be used to assist in confirming the configuration of a client machine. So what should you be implementing to make your Access Gateway access more secure?

1. Use more scans to determine the configuration of your client machines. Surely the more scans the better? The more you know about the client machine the better position you are in about deciding what level of access the user should receive. Check out epafactory.com for more scans.
2. Use client certificates from an internal certificate authority to prove the identity of and authenticate a client machine.
3. Use multi-factor authentication (e.g. RSA SecurID, SafeWord RemoteAccess etc). This is more important than anything else, usernames and passwords alone aren’t enough for authenticating users.

Citrix Access Gateway and Scans for Domain Membership is post from stealthpuppy.com. Except as noted otherwise, this work is © 2005-2012 Aaron Parker and is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

To change the font face you will need to edit one of the language files. In my case this was the English language file – common_strings.properties. At about line 374 you will find the following line which you modify to change the font:

FontFace=Verdana, Arial, Helvetica, sans-serif

The default location for the language file for Web Interface 4.5 is C:\Program Files\Citrix\Web Interface\4.5\languages.

Changing the Citrix Web Interface Font Face is post from stealthpuppy.com. Except as noted otherwise, this work is © 2005-2012 Aaron Parker and is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

Licensing

One of the biggest differences between these two solutions is licensing. CSG comes as a part of Presentation Server and does not require any additional licensing. You will have to pay for a Windows Server license on which to run CSG however. The CAG, on the other hand, uses concurrent user licenses that are purchased separately to your Presentation Server licenses. You will also have to purchase the CAG hardware as the license agreement prohibits you from running the CAG software on any device not purchased from Citrix.

Presentation Server Integration

Strictly speaking, Presentation Server is not integrated into either the CAG or the CSG, though they do both provide an SSL relay function to Presentation Server. User interface access to published applications is provided via Web Interface (WI) or Advanced Access Control (AAC, a component of Access Gateway Advanced Edition). What the CAG has over the CSG is integration with AAC. AAC makes it simple to control what users can do in their ICA sessions and what applications are available externally. In this sense, it’s easier to manage application access via AAC than it is via CAG and WI or CSG and WI alone.

Other Features

This is where the similarities between the two gateway solutions end. Secure Gateway does not offer any of the advanced features of the Access Gateway such as:

• SSL: this is essentially a Winsock redirector client that’s improves on an L2TP/IPSec or PPTP VPN by not relying on routes and using SSL only;
• Web Application Access: users can access internal web applications including integration with SharePoint Server;
• Web-based File Share Access: users are able access internal file shares via a web browser with access to features such as uploading files control depending on the access scenario. Word, Excel, PowerPoint, Visio and PDF files can also be viewed directly in the browser without the requirement for local applications;
• Web-based E-mail: provide users integrated access to Outlook Web Access or iNotes. Citrix also provides a custom interface which allows the administrator to define what users can do in their session such as downloading attachments.

Conclusion

If you are looking to implement remote access with either of the Citrix offerings, don’t listen to the hype – choose the option that best fits. Before you choose the Access Gateway (and I’m sure you’ll be happy you did) answer the question of user identity first. I recommend starting here for information on the Access Gateway.

Access Gateway vs. Secure Gateway Part 2: It’s In The Details is post from stealthpuppy.com. Except as noted otherwise, this work is © 2005-2012 Aaron Parker and is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

When you apply this hotfix, existing custom scans (scans other than those provided by Citrix) stop working and you must recreate them.

I found however, after installing the hotfix, I have had to reinstall all of the endpoint scans including the scans from Citrix. After installing the hotfix, the Access Suite Console reported the following error:

This scan package contains a client downloadable component and is not compatible with Access Gateway 4.2 hotfix 5. Please contact your scan provider for an update.

In the Access Suite console, the Endpoint Analysis scans groups and packages looked like this:

To fix this issue, you will have to remove the scan packages and scans from the tree, re-import the packages and recreate your scans – not a small job. Removing and re-importing the scan packages is a straight-forward process however it could take you some time depending on your configuration:

1. Remove any scans and rules created for endpoint analysis. This will require you to remove the scans from filters and logon points before deleting the scans and rules;
2. Uninstall each of the scan packages – select the package and click ‘Uninstall scan package’ from the task pane on the right. Unfortunately you will have to uninstall each scan package individually;
3. This should leave only the scan groups, you don’t have to recreate these. Re-import the scan packages from the file system. The default location will be: C:\Program Files\Citrix\Access Gateway\Bin\EPAPackages. This is a simple process – select a scan group and click ‘Import scan package’ from the pane on the right and browse to the EPAPackages folder. Select the applicable scan package and import. The scan packages are CAB files and the file names should make sense to you for import into the correct scan group.

One other important note in the readme, is that you will have to remove and redeploy each of the logon points to each of your AAC servers, so backup your customisations first.

Hotfix 5 for Advanced Access Control 4.2 is post from stealthpuppy.com. Except as noted otherwise, this work is © 2005-2012 Aaron Parker and is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

Now that we’ve got that out of the way – there’s a discussion I tend to have with sales or customers on a semi-regular basis that revolves around the idea that the Access Gateway is somehow more secure than the Secure Gateway – “if we implement the Access Gateway our remote access will be secure”. I don’t really understand how this thinking came about, but it is probably rooted in the fact that the Access Gateway is an appliance and Secure Gateway runs on a Windows Server. It also helps that the Access Gateway sells more licensing and sales loves anything that sells more licenses.

In some respects this thinking around security could be true, because the Access Gateway runs a cut-down Linux kernel and is pre-hardened for its’ role as a remote access device and therefore should have a smaller attack surface than a Windows Server running Secure Gateway. Although any attack on the operating system would only occur via a vulnerability in the Access Gateway or Secure Gateway/Web Interface code. However that’s not what an attacker is interested in. They’re interested in the soft and squishy inside of the corporate network and there are easier ways of getting in than compromising a box in the DMZ.

The decision on which Gateway product to implement should be solely based on feature set, but there is a far more important question that should be asked before your budget is committed to either: How do we prove the users’ identity?

By default the only method of authentication that the Access Gateway and Secure Gateway¹ offer is a combination of username and password. These alone cannot guarantee the identity of the user attempting to gain access. If username and password were compromised, how would the user know that they had been compromised and how could the administrator prove that the user accessing the system is the actual authorised person? As the administrator, we could attempt a couple of things:

1. Implement a strong password policy in the organisation;
2. Restrict which machines users access the system from.

Neither of these options will work, because the business generally requires that users have access from anywhere and as soon as we allow access from un-trusted or unmanaged machines (even users home machines), we have to contend with key loggers or shoulder surfing. Social engineering also provides an avenue for compromise – users don’t understand the value in keeping usernames and passwords secure and we don’t do a very good job of helping them understand. Now what if authentication relied on something that the user could physically hold in their hand, something that helped to identify the user and something the user will see the value in protecting? If they lose the device, they lose access to the system. Adding two-factor authentication by implementing a one-time password (OTP) solution that uses physical tokens, allows us to do just that.

Out of the box, the Access Gateway and Secure Gateway/Web Interface support OTP solutions from RSA (SecurID) and Secure Computing (SafeWord). The Access Gateway provides support for other solutions such as VeriSign Unified Authentication (VeriSign also provide integration into Web Interface) and Swivel PINSafe (this solution uses your mobile phone as the token). These products are not limited to integrating with Citrix products, we can also use them to authenticate users in other scenarios such as IPSec VPNs or Outlook Web Access. I recommend that identity and authentication take a front seat when considering any of these scenarios.

Citrix provides some great solutions for remote access, however if we don’t implement a way to identify users using strong authentication, we’re also providing the bad guy a great solution for remote access too.

¹Web Interface is actually handling the authentication request in a Secure Gateway scenario.

Access Gateway vs. Secure Gateway Part 1: A Case of Mistaken Identity is post from stealthpuppy.com. Except as noted otherwise, this work is © 2005-2012 Aaron Parker and is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

As many of you will by now know, Access Gateway and Access Gateway Advanced were released on Friday 13 October and can be downloaded from MyCitrix. We’ve set the Subscription Advantage date somewhat earlier than the release date (1 January 2006 if I recall correctly) which means that virtually everyone with an Access Gateway [Advanced] installation will be eligible to run this code. This is good because there’s a number of stability and scalability improvements that will be useful for all customers and it will allow us to focus our support resources on 4.5 (which is not to say that 4.2 will go unsupported, just that users will likely be encouraged to upgrade).

I don’t know how I missed this one, I think it’s been slipped in under the radar and I think Sam means 1 January 2007. I don’t seem to have access to it from the MyCitrix web site, but I no longer have access to the beta. So I’m yet to see the final 4.5 code.

There are quite a few changes in this version of the product with one of the most interesting is the removal of Access Centres. This means that there is no longer any of the Sequoia code in the product. I would recommend migrating away from Access Centres as soon as possible to the new Access Navigator interface.

Here’s a list of the feature changes in the Access Gateway and Advanced Access Control:

I hope to have some more information about the new features in a future post.

UPDATE: Silly me, you need to fullfill your Access Gateway licenses to get access to the 4.5 downloads.

Access Gateway 4.5 / Access Gateway Advanced 4.5 Released is post from stealthpuppy.com. Except as noted otherwise, this work is © 2005-2012 Aaron Parker and is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

1. Download and install the Microsoft Office Compatibility Pack for Word, Excel, and PowerPoint 2007 File Formats on your Advanced Access Control servers (You will already be required Office 2003 or XP installed on the AAC server). In some larger deployments only specific AAC servers in the farm may provide the web rendering features, so that is where these updates should be made.

2. Next we need to add support to AAC for the new file types. The Citrix Knowledge Center site lists the following support article for adding new files type support to AAC.

• CTX107543 – Customizing HTML Preview in Advanced Access Control

Because that document covers the process in detail, I’ll only list the registry changes required to add support for the new files types:

• Create the following registry key: HKEY_LOCAL_MACHINE\SOFTWARE\citrix\msam\activationservice\enginemanager\previewengine\caps
• Under this new registry key create a new String Value named: MSWordHandler
• Add the following data to this value: ":.doc:.ans:.mcw:.rtf:.docx:
• Restart the Citrix Activation Host and the Citrix Deployment Server services on the AAC server and you’re done.

Here is the full list of values to add to this new key:

The .docm, .xlsm and .pptm are the new document types that include macros. If you feel that it could be a security risk for your organisation to allow macro support through the HTML rendering in AAC, do not add these file types.

Also of note is that the HTML rendering feature does not support text files by default. To add support for text files add ‘.txt:’ (without quotes) to the MSWordHandler value.

How To: Add Office 2007 HTML Rendering Support in AAC is post from stealthpuppy.com. Except as noted otherwise, this work is © 2005-2012 Aaron Parker and is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

• Access Gateway with a single connected NIC in the Perimeter/DMZ network for relaying connections into the Internal network
• Advanced Access Control in the Internal network to control access to internal resources. This could be multiple or a single AAC server
• Applications published on a Presentation Server farm
• Active Directory domain controllers for domain authentication
• Strong authentication with a two-factor authentication solution
• Internal DNS servers to allow the Access Gateway to resolve names for internal hosts
• Certificate Revocation Lists (from internal or external CAs) to ensure all presented certificates are valid

These components form the most basic requirements for an Access Gateway implementation. What is missing from the diagram, however, is an extra ports that would be required to be open for use with an SSL VPN connection. These will vary for each implementation depending on what resources users requires access to.

In this particular diagram the network consists of a single, tri-homed firewall with the Perimeter/DMZ network using private IP addresses that are routed to the internal network. This configuration will keep firewall rules as simple as possible.

(click for full size)

Access Gateway Traffic Flow Diagram is post from stealthpuppy.com. Except as noted otherwise, this work is © 2005-2012 Aaron Parker and is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

1. Open BASEPAGE.ASPX in the target Logon Point: \INETPUB\WWWROOT\CitrixLogonPoint\<LogonPoint>\BASEPAGE.ASPX
2. At about line 61 you will find the following code: <form id=”pageForm” runat=”server”>
3. Change this to: <form id=”pageForm” runat=”server” autocomplete=”off”>
4. Save the changes and refresh the Logon Point in the Access Suite Console

Apparently this change will make it into “future releases of the product” – it’s not in the current beta of AAC 4.5. It’s great that Citrix is making this change, but should this not have already been the default configuration?

Turning Off AutoComplete on a Logon Point is post from stealthpuppy.com. Except as noted otherwise, this work is © 2005-2012 Aaron Parker and is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

The Citrix Access Gateway (CAG) has been known to have problems retrieving Certificate Revocation Lists (CRLs), which is an important stage in the SSL/TLS handshake (similar to having an accounts database but not checking the disabled flag). Currently the CAG only supports HTTP (LDAP is unsupported) but the built in user agent is fairly fussy about the server hosting the CRL. I had previously dealt with an issue where CRL retrieval would fail if the optional Content-Length HTTP header was not set (this was TT23747, which is set to appear in the next major release and which is available as a private from Citrix Technical Support in the mean time), and now a new one has been reported which relates to the HTTP version used. Specifically, the user agent is sending a GET request in HTTP/1.0 which lacks the HTTP Host: header. This is required for virtual hosting and is used by the web server to determine which content to serve. The fix is for us to send the Host: header and the workaround is to not require Host: headers in your web server configuration which may mean moving the CRL to the default site or dedicating an IP. This is being tracked as TT23822 and a private fix should be available soon.

Access Gateway and Certificate Revocation Lists

Access Gateway and Certificate Revocation Lists is post from stealthpuppy.com. Except as noted otherwise, this work is © 2005-2012 Aaron Parker and is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

1. Navigate to \Program Files\Citrix\Access Gateway\WebServicesCabContent.
2. Make a backup copy of LogonAgentApp.CAB – allow for roll back if anything fails.
3. Extract LogonAgentApp.CAB to a folder. For this example I’m using as C:\Temp\LogonAgentApp
4. Make all customisation to the Logon Point files. See here and here for information on customising the Logon Point.
5. Download CABSDK.EXE from Microsoft Cabinet Software Development Kit (Surely there’s a better tool around..)
6. Extract CABSDK.EXE and copy the files from \BIN to C:\Temp.
7. Run the following command-line to pack the Logon Point source files back into a .CAB file: CABARC.EXE -p -r -P Temp\ -P LogonAgentApp\ N LogonAgentApp.CAB LogonAgentApp\*.*
8. Copy the new .CAB file to \Program Files\Citrix\Access Gateway\WebServicesCabContent.
9. Deploy your Logon Points with customisations intact.

The CABSDK is quite old but it does the trick. Documentation for CABARC.EXE in included in Word format in CABSDK.EXE. A breakdown of the command line is like this:

-p CABARC will preserve the paths names for each file within the .CAB file

-r CABARC will add all subfolders and files (recurse) to the .CAB file

-P This command is used to script the \Temp and \LogonAgentApp folders from the paths. Otherwise the .CAB file will list the files with an additional path

N This command tells CABARC to create a new .CAB file. In this instance LogonAgentApp.CAB

NOTE: I doubt that this would be supported by Citrix, so make sure you keep a copy of the original .CAB file.

Customise Logon Point Source Files is post from stealthpuppy.com. Except as noted otherwise, this work is © 2005-2012 Aaron Parker and is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

Access Gateway Advanced Edition Session Viewer

Access Gateway Advanced Edition Session Viewer is post from stealthpuppy.com. Except as noted otherwise, this work is © 2005-2012 Aaron Parker and is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

1. Download a Linux Live CD such as Ubuntu or Knoppix. These instructions are based on Ubuntu.
2. Boot the Access Gateway from the CD and choose the Safe VGA option.
3. Once the machine has booted into the environment, open a Terminal window and enter a password for root:

sudo password root

1. Now sudo to give yourself root access

su

1. Create a directory in which to mount the Access Gateway filesystem:

mkdir /cag

1. Mount the filesystem. If this is successful you should be able to list the contents of the appliances’ filesystem:

mount /dev/sda1 /cag

1. To make changes to the system we need to change the root to /cag via:

chroot /cag

1. Run setup and change the firewall settings from ‘high’ to ‘disabled’.
2. Go to system services, deselect ‘iptables’, make sure sshd and xinetd are selected, and press quit to save changes.
3. Now run the SSH daemon to generate the key pairs:

/etc/init.d/sshd

1. Exit the chroot environment and then unmount the CAG file system:

umount /cag

1. Reboot the Access Gateway and use PuTTY to log into the applicance via SSH.

Now that SSH is enabled, we can schedule a reboot of the Access Gateway.

1. SSH into the Access Gateway enable a cron job via crontab

crontab -e

1. This will open the crontab file in vi. Insert a line by pressing ‘i’.
2. Enable a reboot by entering the following:

0<tab>0<tab>*<tab>*<tab>*<tab>reboot

The first 0 displays the minute the command is being executed (0-59), the second 0 is the hour the command is executed (0-23), the first * is the day of the month (1-31), the second * is the month (1-12), the third * is the day of the week (0-6, sunday=0). So in this case the Access Gateway will reboot at 2am everyday.

1. Press Esc to leave insert mode and then :wq and Enter to save the changes and quit.

Citrix have a hotfix available to enable SSH which should be supported. I will post more information once I can get a hold of this hotfix.

Scheduling Reboots for the Access Gateway is post from stealthpuppy.com. Except as noted otherwise, this work is © 2005-2012 Aaron Parker and is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

Congratulations! You are participating in the Citrix Access Gateway 4.5, Standard and Advanced Editions Beta Program. The Access Gateway product team is delighted that you agreed to be a beta tester. We genuinely look forward to working with you on this important project!

The Access Gateway product team considers our beta program to be the cornerstone of our testing process and key to the success and evolution of our Access Gateway product line. Furthermore, the program provides our customers and partners with the opportunity to preview the new capabilities in Access Gateway Standard and Advanced Editions. During this program, you can install and test these new capabilities within your own test environment.

During the beta testing process, please provide us with periodic feedback about the beta software. The feedback we receive from you helps us to serve you better and continue to provide you with world-class products that solve all of your access needs. Our commitment to you is to diligently respond to your questions and support you in your beta test effort. In return, we might want to ask you some questions and have you share your feedback on this release.

Citrix Access Gateway 4.5 Beta is post from stealthpuppy.com. Except as noted otherwise, this work is © 2005-2012 Aaron Parker and is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

Access Gateway/Advanced Access Control Implementation Prerequisites

Checklist: Access Gateway with Advanced Access Control is post from stealthpuppy.com. Except as noted otherwise, this work is © 2005-2012 Aaron Parker and is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

Many implementations of the Citrix Access Gateway appliance will be replacing existing installations of Citrix Secure Gateway usually running on a Windows server. To migrate the certificate from Windows to the appliance follow these steps:

1. Download the Win32 version of OpenSSL from SourceForge
2. Extract the package to a folder e.g. C:\OPENSSL
3. Export the certificate including the private key from the Windows server in PKCS12 format. This will require creating a password to protect the private key
4. Convert the certifcate to PEM format using OpenSLL with the following command:c:\openssl\bin\openssl pkcs12 -in <EXPORTED-CERTIFICATE>.pfx -out <NEWFORMAT-CERTIFICATE>.pem -nodes
5. You will be prompted for the password for the certificate
6. Enter the password and the certificate will be converted to PEM format
7. Upload the certificate to the Access Gateway

Either delete both certificate files or keep them in a secure location.

Also see the following Citrix article on this process:

Convert PFX Certificate to PEM Format for Use with Citrix Access Gateway

Migrate a certificate from Secure Gateway to Access Gateway is post from stealthpuppy.com. Except as noted otherwise, this work is © 2005-2012 Aaron Parker and is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.