Archive
How to check which #NetScaler policy that your #Citrix #Receiver or web browser hits?
Ok, this is a common issue that you’ll end up in when setting up Access Gateway access scenarios:
How do you know which policy that is hit when your different Receivers are logging in?
Well, there are a couple of nice commands that can help you troubleshooting your access scenario! I guess that most of you have a simple scenario where you have one domain to authenticate against and some simple PNA, CVPN and potentially SSL VPN policies and profiles to deal with, and they are all linked to the virtual server like something like this simple example:
But in more complex scenarios you may end up controlling which browser the user is accessing with (for giving nice error messages instead of Citrix default messages when users may use an unsupported browser etc.), or when you have multiple AD domains and AD groups to link different policies to etc. Then it may be complex and you have multiple policies and profiles for the same config with minor changes like the SSO domain name etc. So how do you then troubleshoot that easily?
First we have the must know command that hooks into the auth process of the NetScaler and gives you a view of the authentication process:
cat /tmp/aaad.debug
When you run that and you authenticate you’ll see the result of your auth process agains for instance LDAP and RADIUS sources like the result here when I logged in to our little environment:
At the top of the output you see all the AD groups that I’m a member of that needs to match the group that you like to use on the NetScaler side, and last you see that accept from AD for my authentication request.
Then you know that you’re authentication ok, but which of the session polices are we hitting? Then you need to have a look at this great command:
nsconmsg -d current -g pol_hits
This is the output when I access using my Receiver on OS X:
Designing a virtual desktop environment? – #XenDesktop, #Citrix
This is a good blog post by Niraj Patel.
Questions: How do you successfully design a virtual desktop solution for 1,000 users? How about 10,000 users? What about 50,000 users? What are the questions you should be asking? Most importantly, where do you start?
Answer: Hire Citrix Consulting for your next virtual desktop project! OK, that is one right answer, but not the only way to do it. The successful way to design a virtual desktop environment is to follow a modular approach using the 5 layers defined within the Citrix Virtual Desktop Handbook. Breaking apart a virtual desktop project into different layers provides a modular approach that reduces risks and increase chances for your project’s success no matter how larger you’re planned deployment is. What are the 5 layers and some examples of the decisions are defined within them?
- User Layer: Recommended end-points and the required user functionality.
- Access Layer: How the user will connect to their desktop hosted in the desktop layer. Decisions for local vs. remote access, firewalls and SSL-VPN communications are addressed within this layer.
- Desktop Layer: The desktop layer contains the user’s virtual desktop and is subdivided into three components; image, applications, and personalization. Decisions related to FlexCast model, application requirements, policy, and profile design are addressed in this layer.
- Control Layer: Within the control layer decisions surrounding the management and maintenance of the overall solution are addressed. The control layer is comprised of access controllers, desktop controllers and infrastructure controllers. Access controllers support the access layer, desktop controllers support the desktop layer, and infrastructure controllers provide the underlying support for each component within the architecture.
- Hardware Layer: The hardware layer contains the physical devices required to support the entire solution, and includes servers, processors, memory and storage devices.
Want to know how to get started? Try the Citrix Project Accelerator. Input criteria around your business requirements, technical expertise, end user requirements, applications, etc. to get started on your architecture based on the 5 layer model.
Lastly, don’t forget to come see SYN318…
Continue reading here!
//Richard
SSO to StoreFront not working in CVPN mode – #Citrix, #NetScaler, #StoreFront
Single Sign-On from Access Gateway to StoreFront not working in CVPN mode
There is yet another “thing” to have in mind when setting up Access Gateway and StoreFront in CVPN mode!
It’s been an interesting day (or days/weeks/months I must admit) with some “issues” with a NetScaler ADC, Access Gateway with CVPN profiles and StoreFront 1.2. And one thing that we have been struggling with was Single Sign-On to StoreFront when we had the AG configured for CVPN access. And it was just this environment where I’ve seen this issue!!
After a lot of troubleshooting the Citrix guys came up with an explanation on why SSO from AG doesn’t work in this specific environment! And it’s not an obvious one to find I must say… but I now understand why it doesn’t work!
So let’s explain the design reason for why it doesn’t work (so bear with me, solution at the end!!)…
The following picture tries to give a VERY rough picture of how it could look like, clients on the Internet on the left, then a NetScaler ADC with the Access Gateway feature enabled and a vServer configured. This AG vServer has session policies and profiles for ICA proxy (old traditional ICA proxy policy) and the little newer CVPN mode. And YES; I’ve left out a lot of stuff like AD etc. to simplify this picture A LOT…
The overall idea and config is that AG authenticates the user and then shall do SSO to StoreFront. The CVPN policy have been created according to all best practices etc. (Citrix CloudGateway Express 2.0 – Implementation Guide).
But SSO still doesn’t work!! If you login through a browser when having the CVPN policy linked to the vServer you’ll see that authentication works perfectly but then when it tries to passthrough the authentication to StoreFront it fails.
This picture just shows the login to the NetScaler ADC Access Gateway vServer:
Host checks/EPA scans are not for everyone – #Citrix, #NetScaler, #AccessGateway
This is an interesting blog post from Citrix… It captures a scenario that I know one of my previous customers was thinking of, so have a look at it!
The main thing that think of when reading this though is that EPA scans are NOT for everyone, I agree. And please also read my earlier posts on why it cannot be done with todays products from Citrix.
#Citrix #SmartAccess = A complete story or not? – #NetScaler #AGEE #EPA
Even though the latest Receiver Receivers changed some scenarios and enables host checks/EPA scans it still doesn’t provide the full picture. But I’ll be publishing a more detailed picture on why later, some late night I’ll be able to complete it! 😉
Here you have the blog post from Tobias Frigger:
A customer of one of my Citrix Consulting colleagues recently came up with an interesting request.
Like many others they are using Citrix NetScaler’s Access Gateway Enterprise Edition module to grant remote secure remote access to applications and desktops.
Additionally, they use a client management and software distribution solution to deploy the EPA plugin to client computers and therefore wanted to suppress Access Gateway offering the EPA scan plugin for download through the browser. This introduces some additional level of control over which client is entitled to connect through Access Gateway.
An approach restricting certain user groups from logging in by using group memberships is a more common scenario, but in this case the customer intended to restrict the end points and not the users. When end users lack administrative permissions to install custom software, preventing the download is indeed an effective measure.
A job for Citrix Consulting!
As you know, Access Gateway Enterprise Edition offers two ways of running Endpoint Analysis (EPA) scans – before and after authentication. Consequently, there are two procedures.
The formal requirements
- Remove the download button displayed when accessing the AGEE virtual server and the plugin is not detected by the browser or if the plugin is outdated
- Alter the message text such that it refers user to contact their system administrator if they think the plugin should be installed.
- When using a post-authentication EPA scan, add a “logout” button.
Backup
As a precaution, we want to make backup copies…
Continue reading here!
//Richard
#Citrix #SmartAccess = A complete story or not? – #NetScaler #AGEE #EPA
This little blog post is about Citrix SmartAccess. I’ve been a fan of SmartAccess for a long time, and it’s also something that Citrix has been talking a lot about in their story. The way that Citrix technology can provide applications, desktops and information to end-users on any device in a secure and controlled way.
But the purpose of this blog post is to give you my view of this story, and how true the SmartAccess story is. Remember that this is my personal view and that I’ve actually not tested all my theories below so parts of it is purely theoretical at this stage.
So a bit of background first to build my case…
Citrix has been going on about SmartAccess, and it’s been true that the Access Gateway capabilities once added to Web Interface and XenApp/XenDesktop where great in terms of adding another layer of functionality that the IT supplier could use to determine how the XenApp and XenDesktop environments where accessed, and from what type of device. The device detection/classification is done through host checks (Endpoint Analysis Scans, EPA) that the Access Gateway feature provided as a pre- or post-authentication scan. This scan then resulted that either the device met the policies or didn’t, and then this policy could be leveraged by the other internal components (XenApp/XenDesktop) to control/manage which apps, desktops and functionality (virtual channels like printing, drive mapping etc.) that the end-user should get for that specific session.
And this was/is working well for certain scenarios from a technical point of view. But is it really working for the whole story that Citrix and the whole IT-industry is driving now with BYOD etc.? Think about the message that is being pushed out there today, use any device, we can control and deliver according to security policies, we can provide access from anywhere, etc…
And this is where it becomes interesting. All of a sudden then you as an architect are to take this vision that your CIO or IT-board has and realise it into manageable IT services that combined deliver a fully fledged IT delivery of Windows, Internal Web, SaaS, Mobile and Data for this great set of use cases and scenarios. Wow… you’ve got yourself a challenge mate!
This text is from the Citrix homepage about SmartAccess;
SmartAccess allows you to control access to published applications and desktops on a server through the use of Access Gateway session policies. This permits the use of preauthentication and post-authentication checks as a condition for access to published resources, along with other factors. These include anything you can control with a XenApp or XenDesktop policy, such as printer bandwidth limits, client drive mapping, client clipboard, client audio, and client printer mapping. Any XenApp or XenDesktop policy can be applied based on whether or not users pass an Access Gateway check.
So let’s start of then with going back to the SmartAccess which is the topic of this blog!
The IT Melting Pot! 