We’ve all been in the situation where we need to install a driver, vib file, or check “esxtop”. Many advanced administration tasks on ESXi need to be performed via shell access, and to do this you either need a console on the physical ESXi host, an SSH session, or use the Remote vCLI.
In this blog post, I’m going to be providing a quick “How to” enable SSH on an ESXi host in your VMware Infrastructure using the vCenter flash-based web administration interface. This will allow you to perform the tasks above, as well as use the “esxcli” command which is frequently needed.
This method should work on all vCenter versions up to 6.7, and ESXi versions up to 6.7.
How to Enable SSH on an ESXi Host Server
Log on to your vCenter server.
On the left hand “Navigator” pane, select the ESXi host.
On the right hand pane, select the “Configure” tab, then “Security Profile” under “System.
Scroll down and look for “Services” further to the right and select “Edit”.
In the “Edit Security Profile” window, select and highlight “SSH” and then click “Start”.
Click “Ok”.
This method can also be used to stop, restart, and change the startup policy to enable or disable SSH starting on boot.
Congratulations, you can now SSH in to your ESXi host!
VMware Horizon is great at providing an end user computing solution for your business, a byproduct of which is an amazing remote access system. With any type of access, especially remote, comes numerous security challenges. DUO Security’s MFA solution is great at provided multi-factor authentication for your environment, and fully supports VMware Horizon View.
In this guide, I’ll be providing a quick how to guide on how to get setup and configured with DUO MFA on your Horizon Server to authenticate View clients.
If you are looking to only implement DUO 2FA on the VMware Unified Access Gateway (and not the connection server), head over to my colleague’s post here: https://securedpackets.com/?p=424
Here’s a video of DUO on VMware Horizon View in action! Scroll down for instructions on how to set it up!
Video Demonstration of DUO MFA 2FA on VMware Horizon View
Enabling DUO MFA on VMWare View will require further authentication from your users via one of the following means:
DUO Push (Push auth request to mobile app)
Phone call (On user’s pre-configured phone number)
SMS Passcode (Texted to users pre-configured phone number)
VMware Horizon View Connection Server (Configured and working)
VMware View Client (for testing)
DUO Authentication Proxy installed, configured, and running (integrated with Active Directory)
Completed DUO Auth Proxy config along with “[ad_client]” as primary authentication.
Please Note: For this guide, we’re going to assume that you already have a Duo Authentication Proxy installed and fully configured on your network. The authentication proxy server acts as a RADIUS server that your VMware Horizon View Connection Server will use to authenticate users against.
Instructions
The instructions will be performed in multiple steps. This includes adding the application to your DUO account, configuring the DUO Authentication Proxy, and finally configuring the VMware View Connection Server.
Add the application to your DUO account
Log on to your DUO account, on the left pane, select “Applications”.
Click on the Blue button “Protect an Application”.
Using the search, look for “VMware View”, and then select “Protect this Application”.
Record the 3 fields labelled “Integration key”, “Security key”, and “API hostname”. You’ll need these later on your authentication proxy.
Feel free to modify the Global Policy to the settings you require. You can always change and modify these later.
Under Settings, we’ll give it a friendly name, choose “Simple” for “Username normalization”, and optionally configure the “Permitted Groups”. Select “Save”.
Configure the DUO Authentication Proxy
Log on to the server that is running your DUO Authentication Proxy.
Open the file explorer and navigate to the following directory.
Before any changes I always make a backup of the existing config file. Copy and paste the “authproxy.cfg” file and rename the copy to “authproxy.cfg.bak”.
Using the values from the “Protect an Application”, replace the “ikey” with your “integration key”, “skey” with your “secret key”, and “api_host” with the API hostname that was provided. Additionally “radius_ip_1” should be set to your View Connection Server IP, and “radius_secret_1” is a secret passphrase shared only by DUO and the View connection server.
Save the file.
Restart the DUO Authentication Proxy either using Services (services.msc), or run the following from a command prompt:
net stop DuoAuthProxy & net start DuoAuthProxy
Configure the VMware View Connection Server
Log on to your server that runs your VMware View Connection Server.
Open the VMware Horizon 7 Administrator web interface and log on.
On the left hand side, under “Inventory”, expand “View Configuration” and select “Servers”.
On the right hand side in the “Servers” pane, click on the “Connection Servers” tab, then select your server, and click “Edit”.
On the “Edit Connection Server Settings” window, click on the “Authentication” tab.
Scroll down to the “Advanced Authentication” section, and change the “2-factor authentication” drop down, to “RADIUS”. Check both check boxes for “Enforce 2-factor and Windows user name matching”, and “Use the same user name and password for RADIUS and Windows Authentication”.
Below the check boxes you will see “Authenticator”. Open the drop down, and select “Create New Authenticator”.
In the “Add RADIUS Authenticator” window, give it a friendly name, friendly description, and populate the fields as specified in the screenshot below. You’ll be using the shared RADIUS/DUO secret we created above in the config file for the proxy auth. Please Note that I changed the default RADIUS port in my config to 1813.
Click “Ok”, then make sure the newly created authenticator is select in the drop down. Proceed to click “Ok” on the remaining windows, and close out of the web interface.
That’s it!
You have now completely implemented DUO MFA on your Horizon deployment. Now when users attempt to log on to your VMware View Connection server, after entering their credentials they will be prompted for a second factor of authentication as pictured below.
In the many years I’ve been providing IT Services, I’ve noticed that whenever taking over a customer from a competitor, or providing consulting services for a company that has IT staff, that I don’t see DHCP reservations being used all that frequently.
I wanted to write a post and create a video to discuss the comparison, when each should be used and the various case scenarios. I’m hoping my readers may provide their own input in the comments.
See below for the video, or read on for the blog post!
As an example: When a customer was purchasing a VoIP PBX, the PBX vendor get angry when I requested that it be configured for DHCP so that a DHCP reservation could be used, I advised I’d prefer this method so I could change the IP when needed for maintenance or network restructuring. They tried to convince me the IP will change on a DHCP Server and the port forwarding will stop working, because they simply had no idea of what a DHCP reservation was. Ultimately when the day came where I had to change the IP and firewall rules for the PBX, I had to log a support call with the vendor since I couldn’t change the IP myself (which resulted in delays, and costs). If we were using DHCP reservations, I could have simply modified the firewall rules, modified the IP address on the reservation, and restarted the device using the buttons on the front panel (I didn’t have any other access to the device).
Just to state the obvious:
A static IP address is an IP address that’s manually set on a NIC (Network Interface Card).
A DHCP Reservation is a pre-set IP that’s provided by a DHCP Server, and given to a NIC when a NIC calls out to a DHCP server for an IP address.
Static IP Addresses
It’s in my opinion that for server, network, core, and all top level infrastructure, all of these devices and services should be configured with Static IP addresses.
These devices which are almost always running, and have other services that rely on them, require a set static IP that should and will not change. Typically, these IP addresses will never change, even when major changes are being made to the core infrastructure.
These addresses should always be logged, documented, and added to network topology maps.
An example of devices commonly seen with Static IPS:
Computers/Workstations using special services (or requiring firewall exceptions)
DHCP Reservations
DHCP stands for Dynamic Host Configuration Protocol, and was created to dynamically configure hosts networking configuration on the fly for easy deployment.
In it’s most simplest explanation, when a computer (or device) that is configured to use DHCP reaches out to the network, the DHCP server will assign and provide an IP address for the computer to use.
In home networks, pretty much every computer and device will get it’s IP address from the DHCP server running on the router.
In business networks, pretty much every computer and device that isn’t hosting services will get it’s IP address from the DHCP server running on one of their servers or routers.
DHCP Servers support something called a “DHCP Reservation”, which essentially allows you to provide a pre-set IP address to a specific client based on it’s physical MAC address. This means that the device will always get the same IP address and it will never change (whereas they typically do on occasion).
I’m surprised I don’t see these used more often, as they can become quite the powerful tool on the IT tool belt when used properly. I’ve listed some pros and cons below.
The Pros:
Manage IP addresses (IP reservations) from a single console
Ability to change IP addresses on the fly easily from a single console without having to log in to the device.
Manage network topology for ROBO (Remote Office, Branch Office) remotely, easily, and efficiently.
Manage IP addresses for 3rd party devices that you don’t normally have access to modify (tell the vendor to set to DHCP), reducing support calls for external services.
Ability to create different PXE boot environments as each reservation can have it’s own PXE boot options assigned.
The Cons:
Device must support DHCP Configuration.
The device MUST RELY on a DHCP Server once set to use DHCP. If the DHCP Server is down, so is the device.
If rogue DHCP servers appear on your network, it may disrupt communication (this can also happen with static IPs and conflicts).
So with the list above, DHCP reservations look pretty powerful. The next question, is where do we use DHCP reservations. Let’s finish off with the devices we’d use them on, and what use case scenarios apply.
Devices:
Wireless Access Points
Printers
2nd Level (non core) Routers and Gateways
IoT Devices
IP Phones
IP PBX Systems (VoIP, Traditional with IP Management, etc).
Thin Clients and Zero Clients
Use Cases:
Remote Offices (remote sites with limited access)
Remote Support environments
Branch Offices
IP Phone Networks
Wireless LAN Access Point VLANs
DHCP Reservation Use Cases
I use DHCP reservations frequently with customers that have remote or branch offices in remote geographical areas. When supporting these users and troubleshooting issues, it’s awesome to be able to just log in to the DHCP server to change IP addresses of printers, phones, and wireless access points.
Also, when configuring, shipping, and deploying new devices to these offices, I can simply log and write down the MAC address, configure the DHCP reservation, and the device will get the IP address I’ve chosen once it’s connected to the network and powered on.
Using DHCP reservations, you can easily make big changes to these remote networks without having to be present. If you were to use Static IPs and something was misconfigured, this might cause a physical visit to the site to resolve.
If by change a vendor directly dropships equipment to the remote site, I can simply call someone at that office to get the MAC address. Most devices with a NIC (printers, MFPs, wireless access points), all usually have their MAC addresses printed on the outside of the box. With this information provided, I can login to the remote server, create a DHCP reservation, configure drivers, and push the device config out to the network.
DHCP reservations add to the whole concept of a centrally managed environment, which further helps ease of maintaining, and supporting it.
You have VMware Horizon View deployed along with Duo Multi-Factor Authentication (2FA, MFA), and you’re you having user experience issues with 10ZiG Zero Clients and multiple login dialog boxes and planning on how to deal with the MFA logins.
I spent some time experimenting with numerous different settings trying to find the cleanest workaround that wouldn’t bother the user or mess up the user experience. I’m going to share with you what I came up with below.
If you’re interesting in 10ZiG products and looking to buy, don’t hesitate to reach out to me for information and/or a quote! We can configure and sell 10ZiG Zero Clients (and thin clients), help with solution design and deployment, and provide consulting services! We sell and ship to Canada and the USA!
The Issue
When you have DUO MFA deployed on VMware Horizon, you may experience login issues when using a 10ZiG Zero Client to access the View Connection Server. This is because the authentication string (username, password, and domain) aren’t passed along correctly from the 10ZiG Login Dialog Box to the VMware Horizon View Client application.
Additionally, when DUO is enabled on VMware View (as a RADIUS authentication), there is no domain passed along inside of the DUO login prompt on the view client.
This issue is due to limitations in the VMware Horizon View Linux Client. This issue will and can occur on any system, thin-client, or Zero Client that uses a command string to initialize a VMware View session where DUO is configured on the View Connection Server.
Kevin Greenway, the CTO at 10ZiG, reached out to say that they have previously brought this up with VMware as a feature request (to support the required functionality), and are hopeful it gets committed.
At this point in time, we’d like to recommend everyone to reach out to VMware and ask for this functionality as a feature request. Numerous simultaneous requests will help gain attention and hopefully escalate it on VMware’s priority list.
The Workaround
After troubleshooting this, and realizing that the 10ZiG VMware login details are completely ignored and not passed along to the VMware View client, I started playing with different settings to test the best way to provide the best user experience for logging in.
At first I attempted to use the Kiosk mode, but had issues with some settings not being passed from the 10ZiG Client to the View Client.
Ultimately I found the perfect tweaking of settings that created a seamless login experience for users.
The Settings
On the 10ZiG Zero Client, we view the “Login” details of the “VMware Horizon Settings” dialog box.
10ZiG Zero Client VMware Horizon Settings Login Settings
Login Mode: Default
Username: PRESS LOGIN
Password: 1234
Domain: YourDomain
Please Note: In the above, because DUO MFA is enabled, the “Username”, “Password” and “Domain” values aren’t actually passed along to the VMware View application on the Zero Client.
We then navigate to the “Advanced” tab, and enable the “Connect once” option. This will force a server disconnection (and require re-authentication) on a desktop pool logoff or disconnection.
10ZiG Zero Client VMware Horizon Settings Advanced Settings
Please Note: This option is required so that when a user logs off, disconnects, or get’s cut off by the server, the Zero Client fully disconnects from the View Connection Server which causes re-authentication (a new password prompt) to occur.
The Login User Experience
So now that we’ve made the modifications to the Zero Client, I want to outline what the user experience will look like from Boot, to connection, to disconnection, to re-authentication.
Turning on the 10ZiG Zero Client, you are presented with the DUO Login Prompt on the View Connection Server.
You then must pass 2FA/MFA authentication.
You are then presented with the desktop pools available to the user.
Upon logging off, disconnecting, or getting kicked off the server, the session is closed and you are presented to the 10ZiG VDI Login Window.
To re-establish a connection, click “Login” as instruction by the “Username” field.
You are presented with the DUO Login Window.
And the process repeats.
As you can see it’s a simple loop that requires almost no training on the end user side. You must only inform the users to click “Login” where the prompt advises to do so.
Once you configure this, you can add it to a configuration template (or generate a configuration template), and then deploy it to a large number of 10ZiG Zero Clients using 10ZiG Manager.
Let me know if this helps, and/or if you find a better way to handle the DUO integration!
In this post, we’ll be going over how to deploy an existing configuration template that is stored inside of your 10ZiG Manager management software.
This allows you to push out configs on the fly to either a single device, or 10,000 devices at once. This is a MUST for managing small, medium, and large sized 10ZiG deployments.
If you’re interesting in 10ZiG products and looking to buy, don’t hesitate to reach out to me for information and/or a quote! We can configure and sell 10ZiG Zero Clients (and thin clients), help with solution design and deployment, and provide consulting services! We sell and ship to Canada and the USA!
This post is part three of a three part 10ZiG Manager Tutorial series:
Choose the 10ZiG Zero Client(s) that you’d like to deploy the configuration to. You can “CTRL + Click” or “SHIFT + Click” to select more than one 10ZiG Zero Client.
In the menu, expand “Configuration” -> and select “Apply Template”.
A “Configuration Template Note” is displayed. Please read and understand this, then click “Ok”.
In the “Configuration Templates” window, select and highlight the configuration template you’d like to deploy, and then click “Ok”. In my example, I’m choosing “DA-MainTemplate”.
The “Configuration Cloning Target” dialog box is displayed. Here you can change the target hostname, and choose to immediately push the configuration. Select “Ok”.
And now the “Reboot” dialog box is displayed. Here you can choose how you’d like the reboot to be handled once the configuration is pushed to the device(s). Select your preference, or leave as default and select “Ok”.
You’ll be brought back to the 10ZiG Manager interface. Here you’ll see a new task in the tasks list at the bottom of the window.
Once completed, you have successfully deployed the configuration.
You’re done! You have successfully pushed the configuration template to your 10ZiG Zero Client(s).
You can maintain, edit, and use multiple templates for different users, organizational units, or geographical units.
This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish.
Do you accept the use of cookies and accept our privacy policy? AcceptRejectCookie and Privacy Policy
Privacy & Cookies Policy
Privacy Overview
This website uses cookies to improve your experience while you navigate through the website. Out of these cookies, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may have an effect on your browsing experience.
