In the first part article I explained the current infrastructure and the requirements the organization had for the new environment, while I started describing the project using the biggest discussion points in the second article and third article. In this fourth and last article I will describe the latest discussion points (SSL Gateway and Outbound Connections) and the experiences so far.
Discussion Point 4: SSL Gateway
As stated in the first article both current environments used another method to access the current Citrix environment. In the first environment all connections we used for both internal as external access a Citrix Access Gateway, while the second environment used plain Web Interface internal and the Citrix Secure Gateway external. As a team we agreed pretty quick that using a SSL Gateway for both internal as external was the best method, this causes less much firewall changes at all those other divisions and also extending the environment was not dependent anymore of changes in firewalls, which were not managed by our division/department. However the discussion of which product/component to create the SSL Gateway was not that easy. Still many Citrix administrators have a preference for using the Citrix Secure Gateway (CSG). Although the product does where it is built for, Citrix is not developing the product for several years now. Till now only updates are provided so newer Citrix XenApp versions can still be connected to the CSG. Within the project team the choice for the Citrix Access Gateway (CAG) was not the biggest issue.
However getting the CAG in the datacenter was “a bit more” difficult. We used the virtual appliance and logically this should be imported into the hypervisor infrastructure. As you already expect this should be done by the data center team as we don’t have the option to do that. When requested they start asking questions about this virtual appliance and after explaining they mentioned that they already have Junipers in place, which could provide an SSL connection to Citrix environments. A discussion followed about offered functionalities between the two devices and standard services we should use (see the requirements in part 1 of this article series). To support current requirement to do check on the client machines arranged that the CAG appliance were accepted, but will only be supported on best effort by the data center team.
In the same time frame the first contacts were set-up with the team that should administrator the environment. When we talked through the design they stated that their standard was a Secure Gateway and would like to stick to that. We argued a lot about licensing as they didn’t know about the licensing changes made by Citrix when launching the Access Gateway version 5. Finally they also agreed that the Access Gateway was the best solution for this environment, if we could get them updated on the CAG.
Discussion Point 5: Outbound Connections
The last discussion point was a real important one, arranging the outbound connection security. As already stated in part 1 the environment should proof that only allowed users could access the specific network/systems of the customer. Besides we should also be possible to report which user at which time access the customer network (even if he/she was allowed to access the environment). Both current platforms used another technique (RES Workspace Manager versus Microsoft ISA). Both methodologies have their advantages and disadvantages. To limit the amount of products (and we already have lot of experiences with the product) we preferred RES Workspace Manager (RES WM) as this product was already in focus for implementing. Also using RES WM does not require additional server (capacity) and additional knowledge of MS ISA in the maintenance teams.
However RES WM could not provide the report of users which accessed a network/system which they were allowed to access. By default RES WM only logs (when using white listing) which user tried to access a network/system, while they were not allowed to. If RES WM could provide this, there was not an argument anymore that preferred ISA over RES WM. We discussed this with RES and they came up with a kind of workaround. To fully understand this part you need to have some knowledge of RES, but I will try to explain it as easy as possible. Within RES WM you have the option to use a so called learning mode. In learning mode the “violation” with the rules is logged, but at the end-user the action is not blocked. So if I configure that user 1 is not allowed to access 192.168.21.1 in learning made and the user access this IP address it is logged, but the user can still access it.
RES came up with a work around within the current possibilities within the product to achieve the requirement we have. What RES thought up was to use blacklisting as the started point. By adding all networks as blocking in the blacklisting list, users cannot access any networks. The allowed networks will be added to the blacklist but in learning mode. This arranges that the access will be logged, but the user can access the system/network. The will achieve the goal, but it will take more effort to administrator it. Also the report possibilities are not that in nice format currently, which is suitable for management reports.
In a real early stage the Firewall Layer 3 security came up, but we counterattacked that one easy with a cost perspective of having a lot Citrix XenApp server, with just a few users per XenApp server. All parties saw the cost reduction using a Layer 7 solution, so that part was not a big argument.
Experiences so far
As you have already read through the article you have read that the whole IaaS (infrastructure as a Service) / PaaS (Platform as a Service) was a difficult track. Of course this situation is not comparable with real IaaS/PaaS providers, but it should be taken into account that it is not that easy to arrange your infrastructure as you do it at your own data center. We encountered too much us against them situations, while we are actually working for the same company.
As the teams are already supporting users while using client not in scope of the teams, we have lots of experiences with Bring Your Own Device consequences. The teams are still supporting lots of Citrix ICA/Receiver issues on clients, while it’s out of their scopes. I think the same situation will occur with a real Bring Your Own Device concept, at the end the Citrix team still needs to support the clients.
Also the experiences with Electronic Software Distribution are not as I expected. Creating a complete variables based roll-out is really difficult to accomplish. I’m sure it is possible to achieve that, but it is not included a standard option. I think this should be included in an ESD to make the environment as variable as possible.
Final Thoughts
It was a challenging project with lots of frustrations and irritations from all sides. As an external consultant I could let it go a bit more than the internal guys in the team. It was really difficult to team up with the data center team, while they are not in the cooperation mode (because of several logical reasons, what was happening within the company). However this caused lots of noise and delay during the project. Also services mentioned in the list, which are actually not in place caused a lot of confusing and it is still causing that not all components are delivered.
I wrote down these experiences to give an insight in how such large and complex project are happening and for you to use lessons learned and encountered challenges in your projects in an early stage, so you don’t have the same discussions and arguments as we had during this project.