WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud
  • Tanzu
    • Application Modernization
    • Tanzu services
    • Tanzu Community Edition
    • Tanzu Kubernetes Grid
    • vSphere with Tanzu
  • Home Lab
  • Nested Virtualization
  • Apple

Blocking vSphere C# Client Logins

12.10.2012 by William Lam // 8 Comments

I recently picked up on this neat little tidbit from Mr. Not Supported aka Randy Keener, where you can block a user from logging into the vCenter Server using the vSphere C# Client. Other than playing a prank on your co-workers, you might be wondering is there a use case for this? Surprisingly, this is a request I have heard from a few customers in the past where they would like to block their users from using the vSphere C# Client in favor of leveraging only the vSphere APIs for routine tasks.

Since the vSphere C# Client also uses the vSphere API itself, a user with proper credentials to the vSphere environment can easily download the client from an alternative source and still login. Of course, there are ways of preventing this such as restricting application installation on end users desktop but there is some amount of management overhead of identifying those existing and new users, especially if access is delegated out to other teams.

There is a very simple solution if you choose to block ALL users from using the vSphere C# Client which requires a tiny modification on the vCenter Server itself and it takes effect immediately with no service restarts.

Disclaimer: This is probably not officially supported by VMware, use at your own risk.

Login to your vCenter Server and locate a file called version.txt

Windows: C:\ProgramData\VMware\VMware VirtualCenter\docRoot\client
VCSA: /etc/vmware-vpx/docRoot/client

There is parameter called exactVersion which will be set to current supported version of the vSphere C# Client which should also match the version of your vCenter Server. You just need to change this to some other value that you know will not exist in your environment such as 9.0.0. Once you have made this change, now when a user tries to connect and there is a miss-match in the version, the vCenter Server will provide you with a download to the vSphere C# Client located on the server as it normally would if you did not have the latest client.

What the user will find out shortly, is that this will continue in an infinite loop even after installing the proper vSphere C# Client. The reason for this is that the number in version.txt will never match the vSphere C# Client and vCenter Server will just continue serving the installer in an infinite loop. I also looked into this trick for a standalone ESXi host and you can do the same by editing a file called clients.xml which is located in /usr/lib/vmware/hostd/docroot/client and users will not be able to login to the ESXi host using the vSphere C# Client.

Now, even though this prevents users from logging into the vSphere C# Client, users will still be able to connect using the vSphere API which includes the use of vCLI/ESXCLI, PowerCLI, vCO, SDKs, etc. and the use of the vSphere Web Client for either vSphere 5.0 or 5.1 will continue to work. Ideally, it would be nice to be able to control this access on a per user/group basis and perhaps even specify how a user can connect whether that is through the use of the APIs or UI only. Is this even useful to have at all? Would love to hear your comments.

For now, if you want users to get familiar with the new vSphere Web Client 5.1 ... this is one way of "encouraging" them 😉

Categories // ESXi, vSphere Tags // esxi, vcenter, vsphere C# client, vsphere client

Changing VCSA Failed Login Attempt & Lock Out Period

10.05.2012 by William Lam // 2 Comments

I was going through my twitter-feed this morning and came across an interesting article by @herseyc Locked out of the vCenter Server Virtual Appliance. I recommend you give Hersey's article a read as it contains some very useful information about failed login attempts to the VCSA (vCenter Server Appliance).

There was a question posed at the end of the article on how to increase the number of login attempts before an account would be locked out. The answer is to simply modify one of the PAM modules on the VCSA, specifically /etc/pam.d/common-auth

The system default for login attempts before locking out an account is 3 and you can modify this by changing the following line, where X is the number of attempts:

auth    requisite       pam_tally.so deny=X

You also have the option of specifying an "unlock" time which will lock the account for the specified period of time after reaching the max failed login attempts. This can useful if you do not want to manually reset a user account due to a user fat fingering a password. For more details about these parameters, you can search on Google or refer to this article.

Note: The login attempts here is specific to the OS system login on the VCSA (5.0 & 5.1) and not vCenter Server. If you successfully login before hitting the maximum attempts, the tally will automatically reset back to 0.

In vSphere 5.1, and with the use of vCenter SSO, you now have an easy way of controlling password and lock out policy using the new vSphere Web Client. Here is a screenshot of where the configurations are located at:

Note: These policies only pertain to identity sources connected to vCenter SSO and not OS system logins.

Categories // Uncategorized Tags // appliance, lockout, login, pam, vcenter, vcsa, vcva, vSphere 5.0, vSphere 5.1

VCSA (vCenter Server Appliance) Resources

10.03.2012 by William Lam // 2 Comments

Here is a consolidated page on all the articles I have written about the VCSA (vCenter Server Appliance). Hopefully this will be useful when looking for anything related to VCSA.

VCSA 5.5

  • New vCenter Server Simulator 2.0 enhancements in VCSA 5.5 
  • How to bootstrap vCenter Server onto a single VSAN node Part 1?

VCSA 5.1

  • Automating VCSA 5.1 (vCenter Server Appliance) Configurations
  • How to Register a vCenter Server 5.0 with Admin Tool on VCSA 5.1 Using SSH Port Forwarding
  • Automatically Join Multiple VCSA 5.1 using New vCenter SSO (Single Sign-On)
  • Configuring Additional VCSA 5.1 as vSphere Web Client Servers
  • Configuring New vSphere Web Client Session Timeout
  • Specifying Default Domains for vSphere Web Client Login
  • Default Password for vCenter SSO Admin Account on VCSA
  • How to Add/Remove vCenter SSO Identity Sources Using the Command-Line for Windows vCenter Server & VCSA 
  • VCSA (vCenter Server Appliance) 5.1 VCDB & SSODB Password  
  • Seperating Out the vCenter SSO, vSphere Web Client and vCenter Server Services Using the VCSA 
  • vCenter Server Simulator

VCSA 5.0

  • Automating vCenter Server Appliance 5.0 (VCSA) Configurations

Additional Tips/Tricks

  • Forwarding vCenter Server Logs to a Syslog Server
  • How to Send vCenter Alarm Notification to Growl 
  • Changing VCSA Failed Login Attempt & Lock Out Period  
  • Getting Rid of the Inventory Tree in the New vSphere Web Client
  • vCloud Director Simulator 
  • Automating VCSA Network Configurations For Greenfield Deployments  
  • Automating SSL Certificate Regeneration in VCSA 5.1 & 5.5 (vCenter Server Appliance)
  • How to change the default HTML5 VM console port in vSphere 5.5? - See more at: http://www.virtuallyghetto.com/2013/10/how-to-change-default-html5-vm-console.html#sthash.I7qHQEq5.dpuf

    How to change the default HTML5 VM console port in vSphere 5.5?

  • Hybrid environment leveraging SSO Multi-Master Replication between vCenter Server for Windows & VCSA
  • How to automate NTP configurations on the VCSA using the CLI - See more at: http://www.virtuallyghetto.com/2014/02/how-to-automate-ntp-configurations-on.html#sthash.EwHydV3e.dpuf

    How to automate NTP configurations on the VCSA using the CLI

Categories // Uncategorized Tags // appliance, vcenter, vcsa, vcva, vSphere, vSphere 5.0, vSphere 5.1

  • « Previous Page
  • 1
  • …
  • 3
  • 4
  • 5
  • 6
  • 7
  • …
  • 9
  • Next Page »

Search

Author

William Lam is a Senior Staff Solution Architect working in the VMware Cloud team within the Cloud Infrastructure Business Group (CIBG) at VMware. He focuses on Cloud Native technologies, Automation, Integration and Operation for the VMware Cloud based Software Defined Datacenters (SDDC)

Connect

  • Email
  • GitHub
  • LinkedIn
  • RSS
  • Twitter
  • Vimeo

Recent

  • Automated ESXi Installation with a USB Network Adapter using Kickstart 02/01/2023
  • How to bootstrap ESXi compute only node and connect to vSAN HCI Mesh? 01/31/2023
  • Quick Tip - Easily move or copy VMs between two Free ESXi hosts? 01/30/2023
  • vSphere with Tanzu using Intel Arc GPU 01/26/2023
  • Quick Tip - Automating allowed and not allowed Datastores for use with vSphere Cluster Services (vCLS) 01/25/2023

Advertisment

Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Cookie Policy

Copyright WilliamLam.com © 2023