CalleMosen's Posts

I'm trying to find information about how the Enhanced Authentication Plugin really works. I know how to use it and how to install it, what i want to know is what happens under the shell: -   ... See more...
I'm trying to find information about how the Enhanced Authentication Plugin really works. I know how to use it and how to install it, what i want to know is what happens under the shell: -     What version/release of Kerberos is being used? -     What protocols and ports are being used in the client/network/server? -     What algorithms are used for encryption? -     How is the plugin protected from tampering/exploitation? It's not asking much of VMware to provide this information, but the information provided is limited to superficial sales-pitches and endless rows of "install howto's". Am i missing the "elephant graveyard" where VMware White Papers go to meet a quiet death, or is it provided in a  "special, paying members, invite only"-area?
I'm having problems finding actual, deep technical information about WHY i should use the solutions built into vCenter, specifically smart card and authentication proxy. Googling the subject y... See more...
I'm having problems finding actual, deep technical information about WHY i should use the solutions built into vCenter, specifically smart card and authentication proxy. Googling the subject yield hundreds of nice walk through's of HOW to enable/install, or simplistic high level "this is safe, do this"-articles. What i need is low-level information about what traffic is moving between vCenter - ESXi - Active Directory and using what protocols. Educated guessing how it "probably" works wont get me through the security audit process. My situation is; In the system I'm building smart card is already implemented, login to vCenter is done through the vSphere Authentication Plugin. I see no reason to add another layer of authentication complexity to the system, by setting up smart card in vCenter as well. Add to this the fact that the vCenter smart card model is too basic to handle the double PKI structure of my Active Directory. Smart card certificates is handled through an external PKI supplier and it doesn't seem like vCenter can handle separate "smart card "UPN's" for accounts received from active directory. I'm "bound" by the STIG hardening guidelines for Vmware which states that authentication proxy should be installed. The STIG guidelines does not however, require the use of smart cards which is a bit surprising. I would have expected the other way around ... To my understanding; By using smart card to login to the client and the authentication plugin to connect to vCenter, all authorization is thereby managed by kerberos tickets and there are no need to save multiple login credentials in vCenter. This effectively should negate the main arguments for using both "smart card" and "authentication proxy" ... or? The only credentials saved in vCenter are the ones used to connect vCenter to Active Directory, this is of course done using a locked down AD service accounts. The same credentials is used to connect the ESXi-hosts. Again, it's hard to find information about HOW and WHERE those credentials are saved in vCenter; Are they hashed? Enrypted? All of the above? Algorithms? It's really easy to find high-level, almost stupefying information text about these subjects, but it's almost impossible to find any actual, technical information. If doesn't get easier when 80% of the information, even on the VMware website, only applies to old version and/or Windows based versions of vCenter. Is all the deep, technical information hidden behind some kind of "VMware Partner"-abstraction layer?
Adding the RC4_HMAC_MD5 to allowed kerberos types is what fixed the "Invalid credentials"-problem in my POC-setup (vCenter 6.7 U2, Server 2016 (Build 1607), Firefox 66.0 x64). However, i also ha... See more...
Adding the RC4_HMAC_MD5 to allowed kerberos types is what fixed the "Invalid credentials"-problem in my POC-setup (vCenter 6.7 U2, Server 2016 (Build 1607), Firefox 66.0 x64). However, i also had to enable AES128_HMAC_SHA1 and AES256_HMAC_SHA1 in order for RDP-TLS to work using FQDN. I need to continue investigating other ways to login to vCenter, that does not include kerberos authentication using a insecure encryption algorithm (RC4). It's highly unlikely that a setup using RC4 will pass through our security audit process and be approved for usage. VMware need to fix this, requiring kerberos based on RC4 in 2019 is not acceptable!