VMware Horizon Community
nielsgeursen
Enthusiast
Enthusiast
Jump to solution

Unable to browse for groups in Conditions and Condition Sets

Hi All,

Problem description:

I am having a strange issue within the VMware UEM Mangement Console. When I create a condition or condition set and I want to add the condition Group Membership I am unable to browse the AD. When hovering over the button Browse I am getting the message: Browsing for groups is only available on domain-joined computers. See attachment.

The machine is domain joined.

Info:

- VMware UEM version: 9.7.0.881

- Windows OS: Windows 2016 (domain joined)

- User is member of local administrators

What I already tried:

- Browsing via de Local Users and Groups is possible. Adding a domain user to a local group via browsing is also possible.

- ProcMon shows:

Event Class: File System

Operation: CreateFile

Result: NAME NOT FOUND

Path: \\Server01\UEM_Config_Customer$\PROD\Changelog\general\FlexRepository\ConditionSet\CON - TMP - UAT Admin.cl

But the file is not created on that location. I am able to create a file manually on that location.

- Ports (135;445) towards the domain controller are open.

Did someone encounter this issue as well and fixed it?

PS What I noticed as well was when choosing the Group Membership option from the list it takes about 10 seconds before the window pops-up.

1 Solution

Accepted Solutions
DEMdev
VMware Employee
VMware Employee
Jump to solution

From a private conversation with nielsgeursen, it seems that this is indeed related to port 389, as sjesse suggested. Specifically, UDP port 389.

If I block outbound UDP 389, I can reproduce the problem.

View solution in original post

18 Replies
DEMdev
VMware Employee
VMware Employee
Jump to solution

Hi nielsgeursen,

I think that message should have something added to it: "... and while logged-on with a domain account." 🙂

Given your "User is member of local administrators" statement, I gather this is a local account? Could you try with a domain account?

Reply
0 Kudos
nielsgeursen
Enthusiast
Enthusiast
Jump to solution

Hi UEMdev

Thanks for the reply.

Unfortunately I am logged on with a domain account. Smiley Sad

I just wanted to show that I am able to browse the AD from the machine where the Console is installed. Sorry for the confusion. 

The user has all the permission needed on the UEM archive shares and config shares.

The user also has permission to browse AD.

Reply
0 Kudos
DEMdev
VMware Employee
VMware Employee
Jump to solution

Hi nielsgeursen,

I don't quite recall, I'm afraid, but I think that the Management Console needs access to your primary DC. Could that be an explanation?

Reply
0 Kudos
ijdemes
Expert
Expert
Jump to solution

Hi Niels,

This is the behaviour I see using Procmon, just before I open an item in the UEM Management Console. It seems to do a check against the domain (controller). With mgmt01 being my management server hosting the UEM management console and doco01 being my domain controller.

pastedImage_0.png

Can you check with Procmon if you see the same behaviour. I know you can add items from the AD to the local admins group, but just to be sure, can you check/rule out firewalling?


\\ Ivan
---
Twitter: @ivandemes
Blog: https://www.ivandemes.com
nielsgeursen
Enthusiast
Enthusiast
Jump to solution

UEMdev

I am able to connect to the domain controller without any issues. I removed the machine from the domain and added him back to the domain without any issues. So the DC's are reachable.

- What kind of mechanism is UEM console using to determine if the machine is domain joined?

- Also does the console use a specific port to check the primairy DC? Maybe we need to open this port on the firewall.

Thanks again for the reply.

Reply
0 Kudos
nielsgeursen
Enthusiast
Enthusiast
Jump to solution

ijdemes

See below. I am not seeing a specific domain controller towards the connections is made. However all seems to be connecting without issue's.

pastedImage_0.png

Reply
0 Kudos
ijdemes
Expert
Expert
Jump to solution

I do see "SUCCESS" for all connections that are made. But all with IPv6 addresses. May that be the issue? I also don't see a reference to kerberos.dll in my log file. Just wondering what the differences are than, between your and my environment. Can you also provide what you see regarding the registry entries that are displayed in my trace?


\\ Ivan
---
Twitter: @ivandemes
Blog: https://www.ivandemes.com
Reply
0 Kudos
nielsgeursen
Enthusiast
Enthusiast
Jump to solution

ijdemes

I am not able to find any of the reg keys like those in your capture. The LSASS.exe process is also not opening any of those keys. Using search I am also not seeing any other process reading/opening one of those keys.

See blow all the LSASS actions in my capture.

pastedImage_0.png

Reply
0 Kudos
ijdemes
Expert
Expert
Jump to solution

Hmm, strange. I also see a reference to c:\windows\debug\netlogon.log. Anything in there that me be of interest?


\\ Ivan
---
Twitter: @ivandemes
Blog: https://www.ivandemes.com
Reply
0 Kudos
nielsgeursen
Enthusiast
Enthusiast
Jump to solution

ijdemes

Nothing interesting in the NETLOGON.log. It shows that the connection to the domain is there. So no problems found.

Also during the capture with ProcMon during the 10 second delay I am not seeing any failures or other strange network related items.

Reply
0 Kudos
ijdemes
Expert
Expert
Jump to solution

Hmm, I'm out of ideas to be honest. I only see differences between your and my Procmon trace, but not sure what to conclude from that. UEMdev​, do you have some additional thoughts/ideas?


\\ Ivan
---
Twitter: @ivandemes
Blog: https://www.ivandemes.com
Reply
0 Kudos
sjesse
Leadership
Leadership
Jump to solution

A few things I'd check is if you can use Active Directory User and Computers for this machine and run this powershell command and makes sure it comes back true.

Test-ComputerSecureChannel

It could be that the machine connection with ad isn't working anymore. If that the case if you remove it from the Domain and add it again it may help, I don't think I saw this in any of the previous comments.

ijdemes
Expert
Expert
Jump to solution

nielsgeursen​ indeed mentioned that the computer on which the management console runs was rejoined to the domain successfully. But maybe it's good to check with the cmdlet anyway.


\\ Ivan
---
Twitter: @ivandemes
Blog: https://www.ivandemes.com
Reply
0 Kudos
sjesse
Leadership
Leadership
Jump to solution

- Ports (135;445) towards the domain controller are open.

What about 389, I'm looking at both procmon traces, and I see it in yours but not the one provided by nielsgeursen . Its a problem I had in my enviornment where we have multiple domains, one of the remote domains blocks traffic over 389 which prevents tools that use ldap connections to look up users.

nielsgeursen
Enthusiast
Enthusiast
Jump to solution

Hi sjesse​,

Thanks for your reply.

Port 389 is open I am able to do a telnet towards the domain controller on that specific port.

The Test-ComputerSecureChannel gives me a True result. With the verbose option I am getting:

Verbose: Performing the opreration Test-ComputerSecureChannel on Computername

True

Verbose: The secure channel between the local computer and the domain DOMAINNAME is in good condition.

So all seems to be OK on the domain connection part.

Reply
0 Kudos
DEMdev
VMware Employee
VMware Employee
Jump to solution

From a private conversation with nielsgeursen, it seems that this is indeed related to port 389, as sjesse suggested. Specifically, UDP port 389.

If I block outbound UDP 389, I can reproduce the problem.

nielsgeursen
Enthusiast
Enthusiast
Jump to solution

UEMdev​,

The problem is fixed and it seems to be a firewall issue like you already mentioned. After a change on the firewall opening ports 389 and 445 the problem was fixed.

Thanks for the help on troubleshooting the problem.


Regards,

Niels

Reply
0 Kudos
DEMdev
VMware Employee
VMware Employee
Jump to solution

Hi nielsgeursen,

Thank you for reporting back; happy to hear that it's solved!

Reply
0 Kudos