VMware Horizon Community
Aginaco
Contributor
Contributor
Jump to solution

Users can not login to horizon cloud with UPN name, only with netbios

Hi Community,

In our Horizon Cloud environment we have setup an Azure AD pod. Horizon validates users against Azure AD using AD DS. Users are synced from an on-prem AD with Add Connect. When users try to log into Horizon Cloud through an external UAG to access the pod resources they can not use their UPN´s, they can only log in using Netbios name. Also when I make assignments in Horizon  I must search for the users using their Netbios name.

If I´m already logged in HZ Cloud with my Netbios name and launch a Windows  VDI from one pool, from this machine I can RDP the IPs of other machines from the same pool or another pool and in that case I can use the UPN to log into these machines .

Any idea why the users can not log into HZ Cloud with their UPN´s?

Your comments will be welcome

Thank you

0 Kudos
1 Solution

Accepted Solutions
XtravirtMatt
Contributor
Contributor
Jump to solution

Hi Aginaco,

Our reference platform uses Pod version 1976.0, however, the newly deployed platform that does not exhibit the defect is version 2298.0.

The availability of an upgrade for the Pod is governed by VMware:

Updating Your Horizon Cloud Pod guide:

End-to-End Process

Starting from when the VMware Operations team designates your customer account to use the new manifest version, the end-to-end sequence is:

I've requested VMware make an update available for our reference platform ASAP, such the I can confirm that an update from 1976.0 to 2298.0 resolves this defect. I'm pretty confident it will.

the Updating Your Horizon Cloud Pod guide:

End-to-End Process

Starting from when the VMware Operations team designates your customer account to use the new manifest version, the end-to-end sequence is:

View solution in original post

10 Replies
tryExplore
Enthusiast
Enthusiast
Jump to solution

Hi,

I think the UPN you mentioned is xxx fo xxx@domain.com

when log in to HZC via UAG, you need to input <in one case>

domain's NetBIOS \ xxx for username

password for password

So I don' understand what you mean for "they can only log in using Netbios name"

0 Kudos
Aginaco
Contributor
Contributor
Jump to solution

Hi, tryExplore

thank you for your answer!

yes, when I mean UPN I mean the "user logon name"  in format username@domain.com and when I mean the Netbios name I mean the "user logon name (pre-window 2000)" as you can see it in the user properties. Usualy this pre-windows 2000 name matches the username of the UPN name without the @domain.com suffix but this is not our case,

the UPN can be for example:

"testuser@domain.com"

and the pre-windows 2000 name

"OTHERDOMAIN\test-1"

Additionaly users don´t know their pre-windows 2000 names .

What I mean is that we can only log in HZC via UAG using this pre-windows 2000 name and we can not log in with username@domain.com.

Also when I spoke about the assignments in HZC Admin portal I wanted to explain that users can only be found in Azure Ad via AD DS and assign to pod resources if you use this pre-windows 2000 name in the search box when doing the assignment.

regards

0 Kudos
tryExplore
Enthusiast
Enthusiast
Jump to solution

Hi,

I don't know where there are any difference between different horizon cloud (On IBM, On AWS, On Azure, etc.)

the following is what I know

■user's information

- domain

NetBIOS.domain.com

- user

testuser@NetBIOS.domain.com

(UPN)

or

NetBIOS\testuser

(pre-window 2000)

■For user's log in

Username : testuser

Password : Password

Domin : NetBIOS

■For assign

Domain Choose : NetBIOS

User / Group : testuser

■For your case

What I mean is that we can only log in HZC via UAG using this pre-windows 2000 name and we can not log in with username@domain.com.

Also when I spoke about the assignments in HZC Admin portal I wanted to explain that users can only be found in Azure Ad via AD DS and assign to pod resources if you use this pre-windows 2000 name in the search box when doing the assignment.

-> I think this is proper.

   Cause UPN can not be use here.

Aginaco
Contributor
Contributor
Jump to solution

Hi,

will have a look to all this

appreciate your help!

regards

0 Kudos
XtravirtMatt
Contributor
Contributor
Jump to solution

We're experiencing the same behavior with our UAGs /Gateways deployed via Horizon Cloud on Microsoft Azure. That is to say the UAGs will only accept either {domainname}\{username} or {username}, when using the UPN name ID format of {username}@{domainname} the login fails.

When we manually deploy UAGs into either On-Premises or VMC on AWS vCenters, users are able to authenticate successfully using all name ID formats.

Additionally we are unable to successfully launch the available Horizon resources from Workspace ONE Access (previously called VMware Identity Manager).I have a hunch that the issue with launching resources from Workspace ONE Access is linked to the configuration of the auto deployed UAGs, as if a user authenticates to the UAGs using either {domainname}\{username} or {username}, prior to authenticating to Workspace ONE Access the Token already exists and the connection to the desktop is successful

We're progressing a case with VMware Support on this issue. I'll update this thread with anything noteworthy.

Matt

0 Kudos
Aginaco
Contributor
Contributor
Jump to solution

Hi Matt,

thank you for your comments, we have also ask VMware Support about this issue. I will inform about their response if it is worthy.

regards

0 Kudos
XtravirtMatt
Contributor
Contributor
Jump to solution

Hi Aginaco

I have an update. Although the Horizon Air GSS team have not been able to offer either a fix nor explanation as to why the UPN user ID format cannot be utilised on my existing Horizon Cloud on Azure deployments, this week (WC Monday July 13th 2020), I have deployed a new Horizon Cloud Pod on Azure based the July 2020 update. With this new deployment users are able to use a UPN user ID format for authentication.

Regards

Matt

0 Kudos
Aginaco
Contributor
Contributor
Jump to solution

Hi Matt,

thank you so much for your feedback, we have also no satisfactory answer from VMware. So you mean after this update  of July 2020 deleting the existing  pod and recreating it again would solve the problem? Our pod version is 1976.0 , what is yours?

Regards

0 Kudos
XtravirtMatt
Contributor
Contributor
Jump to solution

Hi Aginaco,

Our reference platform uses Pod version 1976.0, however, the newly deployed platform that does not exhibit the defect is version 2298.0.

The availability of an upgrade for the Pod is governed by VMware:

Updating Your Horizon Cloud Pod guide:

End-to-End Process

Starting from when the VMware Operations team designates your customer account to use the new manifest version, the end-to-end sequence is:

I've requested VMware make an update available for our reference platform ASAP, such the I can confirm that an update from 1976.0 to 2298.0 resolves this defect. I'm pretty confident it will.

the Updating Your Horizon Cloud Pod guide:

End-to-End Process

Starting from when the VMware Operations team designates your customer account to use the new manifest version, the end-to-end sequence is:

Aginaco
Contributor
Contributor
Jump to solution

Hi Matt,

Your answer has point us in the wright direction. We have also ask VMware for this update, Let´s see when we can get it. I will let you know if it also works for us.

Thank you for your response, Appreciate your help!

Regards

0 Kudos