Author: snp

In the ever-changing IT landscape, Citrix is pushing the limits of what’s possible for our customers and partners. It’s exciting how we’re helping them use our technologies, from moving workloads to the cloud, thinning down endpoints, and tweaking our ICA protocol to maximize graphics performance.

Take one of my Citrix Service Provider partners, Connecticut-based SNP Technologies. I worked with them throughout the first half of 2019 to create an offering in the cloud that they have brought to market successfully. SNP is an entirely cloud-focused CSP, and in this blog post, I’ll share their use case and the technology they used to accomplish their goals.

SNP Technologies came to the Citrix CSP team with one goal in mind — to verticalize and go to market targeting high-end architecture, design, and engineering firms. They wanted to tackle two pain points for this niche market:

• Minimize cost as endpoints with built-in graphics cards are expensive
• No central way to manage and maintain security on any of the data created on these endpoints

In partnership with SNP Technologies, Citrix devised a plan to tackle these issues, leveraging the latest technologies from both Citrix and Microsoft. How did we do it? Let’s take a look at the technology landscape:

Technology in Practice:

Architecture, design, and engineering firms use graphics-intensive applications such as AutoDesk and SolidWorks, which require more than the average amount of hardware resources to operate properly. As a 100 percent cloud-focused partner, SNP Technologies naturally leveraged the Citrix Cloud Virtual Apps and Desktops service which helped in the following ways:

• Saved on compute costs and the cost of deploying and maintaining a Citrix environment.
• Onboarding new customers is easier and seamless.
• SNP used GPU-enabled Azure N-Series VMs running Windows 10 to deliver the best user experience for their customers.
• Each end user gets a high-end Windows 10 desktop in the cloud, pre-installed with the applications they need to get their work done, all while keeping the data locked down and secured from one management location.

Taking a quick glance at the cost of compute on the Azure side for the N-Series VMs, one might think, “How is this solution viable from a cost perspective?” Citrix was able to help decrease the Azure compute cost dramatically for SNP Technologies by leveraging our Autoscale feature, exclusive to the Citrix Cloud Virtual Apps and Desktops service. Autoscale enables proactive power management of machines based on load, a schedule, or a combination of both. It also supports many VDA hosting platforms, including Microsoft Azure Resource Manager. Autoscale supports SNP Technology’s 100 percent cloud-first approach, doesn’t require on-prem installations, and is built in to the Virtual Apps and Desktops service at no additional cost.

Enabling an Optimal User Experience:

Citrix graphics policies were tweaked to enable an optimal user experience. One benefit of partnering with SNP and  Citrix is that we have a team dedicated to creating graphics policies for all types of deployments. After many testing cycles, here’s what we found to be optimal:

Optimize for 3D Graphics Workload

• This setting configures the appropriate default settings that best suit graphically intense workloads and should only be used when a GPU is available to the session.

Hardware Encoding for Video

• This setting allows the use of graphics hardware, if available, to compress screen elements with video (H.264) codec.

Setting the Video Codec for Compression for the entire screen

• This setting allows use of a video codec (H.264) to compress graphics when video decoding is available on the endpoint. Select “For the entire screen” to optimize for improved user experience and bandwidth, especially in cases with heavy use of server-rendered video and 3D graphics.

Setting the Target Frame Rate at the maximum of 60 Frames Per Second

• This setting specifies the maximum number of frames per second sent from the virtual desktop to the user device. Setting a high number of frames per second improves the user experience but requires more bandwidth. By default, the maximum is 30 frames per second.

Setting Visual Quality to high

• This setting specifies the desired visual quality for images displayed on the user device. We found that “high” worked best for our use case, and we recommend that if you require visually lossless image quality.

Graphics Status Indicator set to enabled

• This setting will configure the graphics status indicator to run in the user session. This will allow the user to see details on the graphics mode in use, including graphics provider, encoder, hardware encoding, image quality, progressive display status, and lossless text.

Please note, depending on the specific application and use case, policies will need to be tweaked. We recommend working with your SNP or Citrix engineer to determine what best fits your needs.

Finally, from a technology perspective, SNP Technologies leveraged the Citrix Gateway service, which is included in the Citrix Virtual Apps and Desktops license. Citrix Gateway has points of presence (PoPs) all over the world, enabling users to connect to the nearest location. SNP Technologies was able to include features like high availability and global server load balancing in their branded solution for their end customers without having to stand up or configure complicated networking architectures.

This deployment was exciting because we were able to break down barriers and show what’s possible with cloud, creating a solution that can be deployed in a matter of hours, which just wasn’t possible before. As a result, SNP Technologies’ onboarding of new customers has become seamless and almost effortless. The power of Citrix and Microsoft has reached new heights, and this deployment is proof that if you aren’t thinking about a cloud-first approach, you’re missing out and you’ll probably get left behind in this ever-changing market.

This blog is authored by Neir Benyamin, Partner Sales Engineer at Citrix and Co-authored by Raviteja Beeram, Cloud Solutions Architect at SNP Technologies. Read the complete blog here.

For more information on SNP’s graphic-intensive solutions on Citrix Cloud and Azure, contact us here.

Today, businesses are becoming a combination of on-premises and cloud applications. Users require access to those applications which are hosted both on-premises and in the cloud. Managing users both on-premises and in the cloud poses challenging scenarios.

Microsoft’s hybrid identity solutions span on-premises and cloud-based capabilities, creating a single user identity for authentication and authorization to all resources, regardless of location or device.

Azure AD Connect integrates any user who is present or being created in an on-premise Active Directory to Azure AD. This means you have a single user identity for accessing resources present on-premise, in Azure, O365 & your SaaS applications.

 

Business Benefits of Hybrid Identities:

• An increase in productivity by providing access anywhere, anytime
• Create and manage a single identity for each user across all your data center-based directories, keeping attributes in sync and providing self-service and SSO for users.
• Keep resources productive with self-service password reset and group management for both data center and cloud-based directories.
• Organizations have complete visibility and control over security and monitoring to help reduce inappropriate user activity and spot irregularities in user behaviors
• Enforce strong authentication to sensitive applications and information with conditional access policies and multi-factor authentication.
• Federate identities to maintain authentication against the data center-based directory.
• Provide SSO access to hundreds of cloud-based applications.

 

The Three Hybrid Authentication Solutions:

While hybrid identity may seem like a complex issue when it is up and running, it makes accessing data and services both internal and external while collaborating with partners and customers much simpler. To achieve hybrid identity with Azure AD, three authentication methods can be used:

 

1. Password Hash Synchronization (PHS):

Password hash sync is the simplest way to enable authentication for on-premise AD objects in Azure AD. Users can use their existing on-prem credentials for accessing cloud-based applications on Azure. Active Directory DS stores the password in a hash form which is synced to Azure AD. When a user tries to login to Azure AD, the password is run through a hashing process and the hashed value is matched with the hash value present on Azure AD. If the hash values match, the user is allowed access to the resources.

 

2. Pass-Through Authentication (PTA):

Azure Active Directory (Azure AD) Pass-through Authentication allows your users to sign in to both on-premises and cloud-based applications using the same password. While deploying the Pass-through Authentication solution, lightweight agents are installed on your existing servers. These agents should have access to the on-premise AD domain controllers and outbound access to the internet. Network traffic is encrypted which is limited to authentication requests only.

 

3. Federation Authentication (AD FS):

With the Federation authentication method, you can federate your on-premises environment with Azure AD and use this federation for authentication and authorization. This sign-in method ensures that all user authentication occurs on-premises. Azure AD redirects the users to Active Directory Federations Services (ADFS) as the authenticated domain configured as a federated domain. The ADFS server authenticates the user with on-premise AD and returns a security token to authenticate with Azure AD. The configuration of this solution is much complex as it would require one or more ADFS Proxy servers, one or more ADFS Servers and SSL certificates for implementations.

 

Why SNP?

At SNP, we help you choose and implement a hybrid identity solution which aligns with your information technology roadmap. For more information, contact us here.

Cloud developers and IT teams struggle to stay ahead of challenges protecting users, data, and applications from today’s cybersecurity attacks. With Azure Firewall, network security policies can be enforced while allowing companies to take advantage of the scale and simplicity of Azure.

 

Azure Firewall:

The Azure Firewall is fully integrated with the Azure platform, portal UI, and services. It offers fully native firewall capabilities for all your virtual network resources, and it includes built-in high availability that lets you scale your resources automatically. Azure’s Network Security Groups (NSG) are able to allow/deny and filter TCP/UDP traffic.

 

How it works:

IT administrators can create connectivity policies using application and network filtering rules and enforce the policies across multiple subscriptions and virtual networks. The new service is built to work with Azure’s existing security services to strengthen and enhance the entire security experience.

 

Azure Firewall offers advantages like:

• Built-in high availability: No additional load balancers are required, and there is nothing you need to configure.
• Unrestricted cloud scalability: Azure Firewall scales automatically to accommodate changing network traffic flows, so IT administrators never need to budget for peak traffic periods.
• Application FQDN filtering rules: Users can limit outbound HTTP/S traffic to a specified list of fully qualified domain names (FQDN), including wild cards. This feature does not require SSL termination.
• Network traffic filtering rules: Centrally create “allow” or “deny” network filtering rules by source and destination IP address, port, and protocol. Azure Firewall is fully stateful, which enables it to distinguish legitimate packets for different types of connections. Plus, rules are enforced and logged across multiple subscriptions and virtual networks.
• FQDN tags: FQDN tags make it easy to allow well known Azure service network traffic through the firewall.
• Outbound SNAT support: All outbound virtual network traffic IP addresses are translated to the Azure Firewall public IP address (Source Network Address Translation). The firewall can identify and allow traffic originating from a virtual network to remote Internet destinations.
• Inbound DNAT support: Inbound network traffic to firewall public IP address is translated (Destination Network Address Translation) and filtered to the private IP addresses on virtual networks.
• Azure Monitor logging: All events are integrated with Azure Monitor, allowing IT administrators to archive logs to a storage account, stream events to Event Hub, or send them to Log Analytics.

 

For more information on Azure Firewall, contact SNP Technologies here.

If you’ve been following developments at Microsoft during the tenure of CEO Satya Nadella, it is likely you have heard him say “Microsoft Loves Open Source!”

Here at SNP, we did not need to be convinced of the value open source tools bring to our customers. A case in point is Jenkins, an open source automation server that has been a leader in the DevOps tooling marketplace. For several years, Jenkins has been SNP’s go-to software for continuous integration and continuous delivery (CI/CD) pipelines.

For its part, Microsoft is also a Jenkins fan, having an entire section of its Azure documentation devoted to Jenkins on Azure. As well, there are tutorials to cover specific use cases in the Azure context, such as to deploy from GitHub to Azure Kubernetes Service (AKS) with Jenkins.

To get started with Jenkins in Azure, Microsoft provides a guide to creating a Jenkins server on an Azure Linux VM from the Azure portal. This is all well and good, but this requires love and attention to a virtual machine, and that may not be your cup of tea. Jenkins as a service may be more to your liking. For this one can deploy Jenkins on Azure Web App for Containers. (At this time, put on your finest British accent, and repeat after me, “Jenkins at your service on Azure, Madam”.)

In the open source spirit, SNP has contributed a Docker image solution on GitHub titled Jenkins on Azure Web App for Containers. You can fork the Git repo to use as the basis for your own container image.

 

What follows is a step by step guide to deploy Jenkins on Azure Web App for Containers.

Get the Git Repository

Visit Jenkins on Azure Web App for Containers to clone or fork the repo. Read the README.md file, of course, and review the files in the repository.

Build an Image, Push to a Container Registry

The following steps assume you have Docker installed in your development environment.

In your favorite terminal, e.g. Git Bash, switch to the directory in which you cloned the repository.

 

At the command link, enter the Docker build command, for example:

docker build -t mikesacr.azurecr.io/jenkinsonazure:v1 .

 

List images to verify the build:

docker images

 

Run the image locally, for example:

docker run -p 8080:8080 mikesacr.azurecr.io/jenkinsonazure:v1

 

Push the image to a container repository. For example, using Azure Container Registry:

docker login mikesacr.azurecr.io -u myusername docker push mikesacr.azurecr.io/jenkinsonazure:v1

 

Once complete, a sha256 value with a unique identifier for your image is displayed, for example:

 

This sha256 is also visible in the Azure Portal, for example:

Deploy your Container Image on Web App for Containers

The following steps assume you have an Azure Subscription and an App Service Plan.

Create a Web App for Containers Resource

In Azure Portal, click “Create a resource”, then search for “Web App for Containers”:

This will open a Web App for Containers resource information blade. Click on the “Create” button at the bottom of the blade:

Next, fill in values for the parameters required to create your resource.

1. Enter a unique App name
2. Select your Azure Subscription
3. Select a Resource Group. I recommend a new resource group because the life cycle of your Jenkins app will probably be independent of that of other applications.
4. Select “Linux” as your OS
5. Select an App Service plan/Location. If you have not already created a Service Plan, that’s OK. A new one can be created from here. The Service Plan should be in the same region as the Resource Group. Check this list of locations that support the Web App for Containers.
6. Configure container. Here we identify the container registry and container image to be deployed to the Web App. Click the “Apply” when done filling in this blade.
7. Click the “Create” button

Note: Alternatively, the preceding steps can be accomplished using the Azure CLI.

When the deployment completes, you should see your new Resource Group and new Web App resource in Azure Portal. Click on the Web App Resource. There are a few steps you need to complete before running your Jenkins application, as noted in the README.md file.

Web App Configuration Steps

1. Ensure that the WEBSITES_ENABLE_APP_SERVICE_STORAGE app setting to “true” in the Application settings blade of the Web App.
2. Manually create the jenkins_home directory in the Web App /home directory
   before you run the container and install Jenkins. This can be done from the Kudu Bash screen or from an FTPS session.

Run your Jenkins Container

From the Web App Overview blade, click on the URL to run your Jenkins instance. After a brief initialization period, you should be presented with the Unlock Jenkins screen.

You are on your own from here, but keep in mind the “Gotchas” we have documented in the repo’s README.md file.

In Closing

If you have questions and suggestions to improve the solution, we are happy to receive issues and pull requests. Contact SNP here.