Archive for access

VDI Gateway Federation with BIG-IP

Posted in f5, big-ip, authentication, vdi, devcentral, access by psilva on November 14th, 2017

Today let’s look at how F5 BIGIP APM can consolidate, secure and federate all the core VDI gateways technology. For instance, if an organization decides move from one VDI technology to another or if you’re consolidating VDI technologies, BIG-IP can help.

On the BIG-IP we’ve set up three VDI environments. Microsoft RDS/RDP with a broker authentication server, VMware Horizon and Citrix ZenApp. With only a corporate account, a user can authenticate to all of them as needed and access all available desktop content.

In this example, we connect to the BIG-IP APM. This is the default view.

vdi1.png

 

And here we’ve put some advanced security fields like OTP or multifactor authentication for instance.

otp.png

 

So here we’d use our username and password and for additional security we'll choose a secondary grid. By default, a grid is not generally available from any of the VDI vendors. When we select grid, BIG-IP APM will present a grid for a PIN entry. This is provided through a partnership with Gemalto. BIG-IP is connecting to Gemalto servers to present the grid to the user. We then enter our confidential PIN.

vdi34.png

 

Upon auth, we’re presented with our BIG-IP APM Webtop and BIG-IP did the necessary single sign on for all the VDI technologies and environments assigned to us.

vdi6.jpg

 

With a single, multifactor authentication we’re able to gain access to our federated BIG-IP Webtop and select the specific VDI resource we need.

From an administrative view, here is the full Visual Policy Editor (VPE) for the overall solution. This also shows where the OTP/Grid is if you follow the Host FQDN path.

fullvpe.png

 

And here are the specific inspections and criteria for the VDI scenario. You can see a path for each VDI vendor along with specific inspections and actions depending on the situation.

vdivpe.png

Special thanks to F5 Sr. Security SE Matthieu Dierick for the explanation and you can watch the demo video.

ps

 

 

 

 

 

 

 

 

 




Legacy Application SSO with BIG-IP and Okta

Posted in security, f5, big-ip, silva, authentication, kerberos, devcentral, saml, access by psilva on October 10th, 2017

IT organizations have a simple goal: make it easy for workers to access all their work applications from any device. But that simple goal becomes complicated when new apps and old, legacy applications do not authenticate in the same way.

Today we’ll take you through BIG-IP APM’s integration with Okta, a cloud-based identity-as-a-service provider.

The primary use case for this scenario is providing the user authentication through Okta and then Okta providing BIG-IP APM a SAML assertion so that BIG-IP can perform legacy SSO using either Kerberos Constrained Delegation (KCD) or Header Authentication. BIG-IP is the Service Provider (SP) in this SAML transaction.

As we log on to a BIG-IP, you’ll see that we have two policies/application examples.

ok1.jpg

Let’s click on the Edit button under Access Policy for app1-saml-sp-okta. This takes us to the Visual Policy Editor (VPE) for the first application. As the chart flows, BIG-IP is consuming the SAML authentication, then storing the SSO credentials and doing a Variable Assign so we know who the user is.

ok2.jpg

The next entry, app3-saml-sp-okta, looks very similar.

ok3.jpg

One of the things that is different however is for Header Authentication, we’re using a Per Request Policy. You can view/configure this by going to Access Policy>Per Request Policy.

ok45.jpg

We click Edit (under Access Policy) and here via the flow, the user enters and on every request, we’re going to remove the Okta header name, which is arbitrary and doesn’t need to be that value – could be any value you choose. But we want to make sure that no one is able to pad that header into a request. So, we’ll remove it and insert the variables BIG-IP receives from Okta. This way the application can consume it and we know who that user is.

ok67.jpg

So, what does it look like.

First, we’ll log into Okta and in the portal, we see two applications – the Header Auth and Kerberos Auth.

ok89.jpg

We’ll test the Header authentication first and see that we’re logged into App1 using Header authentication. Tuser@f5demo.com was the account we logged into with Okta and we see the application has been single-signed into using that credential.

ok9a.jpg

Now let’s hit that Kerberos auth application. Here again, we’ve been SSO’d into the application. You may notice that the user looks a bit different here as F5DEMO user since this time we used Kerberos Constrained Delegation. So, we’ve obtained a Kerberos ticket from the domain controller for F5DEMO as the user to use. So the username can look a little different but it’s mainly about formatting.

ok9b.jpg

BIG-IP is able to consume that SAML assertion from Okta and then use SSO capabilities via Header or Kerberos for legacy applications. Watch Cody Green’s excellent demo of this integration.




Lightboard Lessons: What is BIG-IP APM?

Posted in security, f5, big-ip, silva, video, lightboard, access, policy by psilva on July 26th, 2017

In this Lightboard, I light up some lessons on BIG-IP Access Policy Manager. BIG-IP APM provides granular access controls to discreet applications and networks supporting 2FA and federated identity management. You can also check out Chase's written article What is BIG-IP APM?

ps

 

Watch Now:



Device Discovery on BIG-IQ 5.1

Posted in f5, big-ip, cloud computing, adc, application delivery, devcentral, aws, azure, access, big-iq by psilva on May 23rd, 2017

The first step in using a BIG-IQ to manage BIG-IP devices

BIG-IQ enables administrators to centrally manage BIG-IP infrastructure across the IT landscape.  BIG-IQ discovers, tracks, manages, and monitors physical and virtual BIG-IP devices - in the cloud, on premise, or co-located at your preferred datacenter.

Let’s look at how to get BIG-IQ 5.1 to gather the information needed to start managing a BIG-IP device. This gathering process is called Device Discovery.

To get started, the first thing is to logon to the BIG-IQ

iq2.jpg

Once in, the first thing you do is let the BIG-IQ know about the BIG-IP device that you want to manage. Here, in Device Management>Inventory>BIG-IP Devices, we’ll click Add Device.

iq3.jpg

Here we’ll need the IP address, user name and password of the device you want to manage. If the device you want to manage is part of a BIG-IP Device Service Cluster (DSC), you’ll probably want to manage that part of its configuration by adding it to a DSC group on the BIG-IQ. After selecting a DSC, tell the BIG-IQ how to handle synchronization when you deploy configuration changes so that when you deploy changes to one device, the other DSC members get the same changes. Best practice is to let BIG-IQ do the sync.

iq5.jpg

Next click Add at the bottom of the page to start the discovery process.

iq6.jpg

Once the device recognizes your credentials, it’ll prompt you to choose the services that you want to manage. You always select LTM, even if you only mange other services because the other services depend on LTM. To finish the device discovery task, click Discover.

iq7.jpg

The BIG-IQ gathers the information it needs for each of the services you requested. This first step takes only a few moments while the BIG-IQ discovers your devices. You are done with discovery once the status update reads, Complete import tasks.

iq8.jpg

Now, we need to import the service configurations that the BIG-IQ needs before we can start managing that BIG-IP device. Click the link that says, Complete import tasks.

Next, you’ll begin the process of importing the BIG-IP LTM services for this device. Just like the discovery task, you’ll import LTM first.

Click Import.

iq9.jpg

This could take a little time depending on how many LTM objects are defined on this BIG-IP device. When the import finishes, BIG-IQ will display the date and time of when the operation was completed.

iq91.jpg

Now, we repeat the process for the second service provisioned on this device.

iq92.jpg

Importing an access device like BIG-IP APM is slightly different. Part of the import task is to identify the Access Group that this device uses to share its configuration. Whether you’re adding to an existing or creating a new access group, when you’re done entering the name of the group, click Add to start the import process. Here again, the time to process depends on how many BIG-IP APM configuration objects are defined on the device.

iq93.jpg

When the BIG-IP APM services import finishes and the time completed displays, you can simply click Close to complete the task.

iq94.jpg

You can now see that the device has been added to BIG-IQ.

iq95.jpg

That’s it! Now you can start managing the BIG-IP LTM and APM object on this device. For this article, we only imported LTM and APM objects but the process is the same for all services you manage.

Thanks to our TechPubs group and watch the video demo here.

ps

Related:

What is BIG-IQ




Deploy BIG-IP VE in Microsoft Azure Using an ARM Template

Posted in f5, big-ip, cloud, application delivery, devcentral, azure, access by psilva on April 12th, 2017

arm_logo1.jpgAzure Resource Manager (ARM) templates allow you to repeatedly deploy applications with confidence. The resources are deployed in a consistent state and you can easily manage and visualize resources for your application.

ARM templates take the guesswork out of creating repeatable applications and environments. Deploy and deploy again, consistently.

Let’s walk through how to deploy a simple, single-NIC configuration of BIG-IP VE in Microsoft Azure using an ARM template.

First, go to the F5 Networks Github site where we keep our supported templates. There are other community-based templates at www.github.com/f5devcentral if needed but for F5 supported templates, go to the F5 Networks site.

ave1.jpg

To view Azure templates, click f5-azure-arm-templates. In that folder you’ll see experimental and right under that is supported (the one you want).

ave2.jpg

Then click on the standalone folder and then the 1nic folder, which is the simplest deployment.

ave34.jpg

And as you scroll through and review the ‘Read Me,’ you’ll see the Deploy to Azure button under Installation. Select either Bring Your Own License (BYOL) or Pay As You Go (PAYG), depending on your situation.

ave5.jpg

This will launch the Azure Portal and the only thing you’ll really need is a license key if you chose BYOL. Then simply fill out the template.

In this case, we’re going to use an existing resource group that already contains an application.

ave7.jpg

Important: In the Settings section under Admin UN/PW, enter the credentials you want to use to log in to BIG-IP VE. The DNS Label (where you see REQUIRED) will be used to access your BIG-IP VE, for example, if you enter mybigip, the address will be something like  ‘mybigip.westus.cloudapp.azure.com.’ Give the Instance Name something familiar for easy finding.

ave9.jpg

There are different Azure Instance Types, which determine CPU and memory for your VM, and F5 licensing (Good/Better/Best), which determines the BIG-IP modules you can deploy. Then, if needed, enter your BYOL license key.

In addition, to be more secure, you should enter a range of IP addresses on your network in the Restricted Src Addresses field so it’s locked to your address range. This setting determines who gets access to the BIG-IP instance in Azure, so you’ll want to lock it down.

After the tag values, agree to the terms and conditions and click Purchase.

ave91.jpg

Next, you can monitor progress on the deploy status. Keep hitting refresh and you’ll start seeing resources getting populated along with the top blue ‘Deploying’ indicator. When the Deploying bar disappears, you know you’re done.

ave93.jpg

Once complete, you get the notification that the BIG-IP VE was deployed successfully. Next, we’ll navigate to the resource group we selected at the top and then the security group for the BIG-IP.

ave96.jpg

You can see that within the security rules we’ve allowed ports 443 (HTTPS) and 22 (SSH). 22 allows access to the management port; this is the way we’d connect to the BIG-IP to configure and administer.

ave97.jpg

Going back to the resources, the BIG-IP VE itself is listed at the top.

ave98.jpg

When we click on the Virtual BIG-IP we can get the IP address and using a browser through port 443, we can connect either with the DNS name or the IP address to the config utility.

ave97.jpg

Here you would enter the Azure credentials you specified in the template.

ave991.jpg

And that’s all there is to it. Now you can configure your virtual servers, pool, profiles and anything you’d normally do on BIG-IP VE for your unique requirements. Thanks to Suzanne Selhorn for the basis of this article and catch a video demo here.

ps

Related:

 

 




What is Virtual Desktop Infrastructure (VDI)

Posted in security, big-ip, cloud computing, mobile, vdi, devcentral, infrastructure, access by psilva on March 8th, 2017

devcentral_basics_article_banner.png

What is VDI?

vdicon.jpgImagine not having to carry around a laptop or be sitting in a cubicle to access your work desktop applications. Virtual desktop infrastructure (VDI) is appealing to many different constituencies because it combines the benefits of anywhere access with desktop support improvements.

Employees typically use a wide range of mobile devices from laptops to tablets and from desktops to smartphones are being used. The diversity of these mobile devices and the sheer number of them in the workplace can overwhelm IT and strain your resources.

Desktop Virtualization centralizes sets of desktops, usually in a data center or cloud environment, and then provide access to your employees whether they are in the office, at home or mobile.  VDI deployments virtualize user desktops by delivering them to distinctive endpoint devices over the network from a central location. There are many reasons why organizations deploy VDI solutions – it’s easier for IT to manage, it can reduce capital expenditures, improve security and helps companies run a ‘greener’ business.

Since users’ primary work tools are now located in a data center rather than on their own local machines, VDI can strain network resources, and the user experience can be negatively affected. Desktop virtualization is a bit more complex than server virtualization since it requires more network infrastructure, servers, server administrators, authentication systems, and storage. VDI’s effect on the network is significant; it may necessitate infrastructure changes to accommodate the large volume of client information that will be traversing the network. When a user’s desktop moves from a physical machine under the desk to the data center, the user experience becomes paramount; a poor VDI deployment will result in IT being flooded with “My desktop is too slow” calls.

DIAG-ARCH-AVAIL-16553-vdi_1_.png

Why VDI?

Mobile devices and bring your own computing are popular drivers for VDI deployments.  It enables employees to work from anywhere and simplifies/unifies desktop management, especially updating operating systems and applications.  It can lower costs, provide flexible remote access; improve security and compliance along with potentially offering organizations disaster recovery options.  It also enables employee flexibility and reduced IT risk of employee owned devices. VDI allows employees work with a wide range of devices from laptops to tablets to smartphones.  Employees can sign on from wherever they are, whenever they like and with whichever device they choose.

Deploying virtual desktops can also increase IT efficiency and reduce IT workload since the desktops are centralized.  It also benefits IT with greater access and compliance control, while at the same time, allowing employees the freedom to use their mobile device of choice. IT departments can remove obsolete versions of application software or perhaps enhance the security policy. Either way, the employee always has the most up to date desktop image.

Things to Consider

Desktop virtualization is no longer about the desktop, it’s about allowing employees desktop access from wherever they are. So things like availability, access, security, DR, authentication, storage, network latency and SSO are all areas to keep in mind when deploying a VDI solution.

VDI Providers

Some VDI solutions include VMware View, Citrix XenDesktop, and Microsoft RDS.

Next Steps

If you'd like to learn more or dig deeper into VDI, here are some additional resources:

Also, here are some other articles from the #Basics Series.

 

 

 

 




What to Expect in 2017: Mobile Device Security

Posted in security, big-ip, mobile, byod, access, 2017 by psilva on February 21st, 2017

mobile_locks.jpgIf the last 10 years wasn’t warning enough, 2017 will be a huge year for mobile…again. Every year, it seems, new security opportunities, challenges and questions surround the mobile landscape. And now it encompasses more than just the device that causes phantom vibration syndrome, it now involves the dizzying array of sensors, devices and automatons in our households, offices and municipalities. Mobile has infiltrated our society and our bodies along with it.

So the security stakes are high.

The more we become one with our mobile devices, the more they become targets. It holds our most precious secrets which can be very valuable. We need to use care when operating such a device since, in many ways, our lives depend on it. And with the increased automation, digitization and data gathering, there are always security concerns.

So how do we stay safe?

The consumerization of IT technologies has made us all administrators of our personal infrastructure of connected devices. Our digital self has become a life of its own. As individuals we need to stay vigilant about clicking suspicious links, updating software, changing passwords, backing up data, watching financial accounts, having AV/FW and generally locking down devices like we do the doors to our home. Even then, the smartphone enabled deadbolt can be a risk. And we haven’t even touched on mobile payment systems, IoT botnets or the untested, insecure apps on the mobile phone itself.

iot.jpgCybersecurity is a social issue that impacts us all and we all need to be accountable.

For enterprises, mobile devices carry an increased risk, especially personal devices connecting to an internal network. From regulatory compliance to the disgruntled employee, keeping sensitive information secret is top concern. BYOD policies and MDM solutions help as does segmenting those devices away from critical info. And the issue isn’t so much seeing restricted information, especially if your job requires it, it is more about unauthorized access if the device is compromised or lost. Many organizations have policies in place to combat this, including a total device wipe…which may also blast your personal keepsakes. The endpoint security market is maturing but won’t fill the ever-present security gaps.

From your workforce to your customers, your mobile web applications are also a target. The Anti-Phishing Working Group (APWG) reports a 250 percent jump in the number of detected phishing websites between October 2015 and March 2016. Around 230,000 unique phishing campaigns a month, many aimed at mobile devices arriving as worrisome text messages. Late 2016 saw mobile browsing overtake desktop for the first time and Google now favors mobile-friendly websites for its mobile search results. A double compatibility and SEO whammy.

And those two might not be the biggest risk to an organization since weakest link in the security ecosystem might be third-party vendors and suppliers.

On the industrial side, tractors, weather sensors, street lights, HVAC systems, your car and other critical infrastructure are now mobile devices with their own unique security implications. The Industrial Internet of Things (IIoT) focuses on industrial control systems, device to network access and all the other connective sensor capabilities. These attacks are less frequent, at least today, but the consequences can be huge – taking out industrial plants, buildings, farms, and even entire cities.

The Digital Dress Code has emerged and with 5G on the way, mobile device security takes on a whole new meaning.

ps

 




Shared Authentication Domains on BIG-IP APM

Posted in security, f5, big-ip, application delivery, authentication, AAA, devcentral, access by psilva on February 14th, 2017

How to share an APM session across multiple access profiles.

A common question for someone new to BIG-IP Access Policy Manager (APM) is how do I configure BIG-IP APM so the user only logs in once.

By default, BIG-IP APM requires authentication for each access profile.

domain_value.jpg

 

This can easily be changed by sending the domain cookie variable is the access profile’s SSO authentication domain menu.

Let’s walk through how to configure App1 and App2 to only require authentication once.

We’ll start with App1’s Access Profile.

dv1.jpg

 

Once you click through to App1’s settings, in the Top menu, select SSO/Auth Domains.

dv2.jpg

 

We’re prompted for authentication and enter our credentials and luckily, we have a successful login.

dv4.jpg

 

And then we’ll try to login to App2. And when we click it, we’re not prompted again for authentication information and gain access without prompts.

dv5.jpg

Granted this was a single login request for two simple applications but it can be scaled for hundreds of applications. If you‘d like to see a working demo of this, check it out here.

ps

 

 

 

 

 

 

 

 

 

 




Deploy BIG-IP VE in AWS

Posted in Uncategorized, f5, big-ip, cloud, cloud computing, devcentral, aws, access by psilva on January 23rd, 2017

aws_logo.jpgCloud is all the rage these days as it has matured into a bona fide, viable option to deploy your applications. While attractive, you may also want to apply, mimic or sync your traditional data center policies like high availability, scalability and predictability in the cloud.

 




Blog Roll 2016

Posted in security, f5, big-ip, cloud computing, silva, application delivery, devcentral, infrastructure, access, iot by psilva on December 20th, 2016

dc-logo.jpgIt’s that time of year when we gift and re-gift, just like this text from last year. And the perfect opportunity to re-post, re-purpose and re-use all my 2016 entries.

After 12 years at F5, I had a bit of a transition in 2016, joining the amazing DevCentral team in February as a Sr. Solution Developer. You may have noticed a much more technical bent since then…hopefully. We completed our 101 Certification Exam this year and will be shooting for the 201 next quarter. We started highlighting our community with Featured Member spotlight articles and I finally started contributing to the awesome LightBoard Lessons series. I also had ACDF surgery this year, which is why November is so light. Thanks to the team for all their support this year. You guys are the best!

If you missed any of the 53 attempts including 7 videos, here they are wrapped in one simple entry. I read somewhere that lists in articles are good. I broke it out by month to see what was happening at the time and let's be honest, pure self-promotion. I truly appreciate the reading and watching throughout 2016.

Have a Safe and Happy New Year!

 

January

February

March

April

May

June

July

August

September

October

November

December

 

And a couple special holiday themed entries from years past.

ps

Related

 





« Older episodes ·