popvm
Hot Shot
Hot Shot

Privilege Elevation - User Installed Apps

Jump to solution

I was trying to configure privilege elevation using DEM 2009 on our test environment and looks like its not working correctly.

I have kept firefox and Notepad++ installers on a share and configured DEM with path-based user-installed application. When I connect to the desktop, access the location and double click on the apps, it always brings up the UAC prompt. Is this expected? UAC is kept at lowest level and I am not accessing the share as a mapped drive.  According to logs, its applied correctly.

=========

2021-03-25 12:39:52.672 [INFO ] Privilege elevation statistics:
2021-03-25 12:39:52.672 [INFO ] Elevated \\au-bne-poc-dem\JubzLogs\Jubish\Firefox Installer.exe 1 time (path-based user-installed application)
2021-03-25 12:39:52.673 [INFO ] Elevated \\au-bne-poc-dem\JubzLogs\Jubish\npp.7.9.5.Installer.x64.exe 5 times (path-based user-installed application)

=========

Any clue on what could be wrong?

Labels (1)
0 Kudos
1 Solution

Accepted Solutions
popvm
Hot Shot
Hot Shot

To close the loop, this was indeed a bug in DEM 10.0 and 10.1 which got fixed in 10.2.

https://docs.vmware.com/en/VMware-Dynamic-Environment-Manager/2009/rn/VMware-Dynamic-Environment-Man... 

@DEMdev Thanks for your time on this, as always!

View solution in original post

14 Replies
popvm
Hot Shot
Hot Shot
Attaching the UAC prompt.
0 Kudos
popvm
Hot Shot
Hot Shot

Did some testing and this always work in the second and subsequent logins. I was testing using instant clones with the policy 'Refresh on Logoff'. So when the user logs off, the desktop will be refreshed and privilege elevation does not work upon the immediate login after the refresh. If I reboot the desktop and login back, it will work. Also, if I disable 'Refresh on Logoff' policy and login the second time, it works. But this doesn't seem to be working in the first login.

Tagging our DEM hero @DEMdev to throw some light on this.

0 Kudos
DEMdev
VMware Employee
VMware Employee

Hi @popvm,

Pardon the late response; I was out for a few days.

That's a strange one... DEM does not distinguish between a first logon and subsequent ones.

What do you mean with "UAC is kept at lowest level"? Does other privilege elevation functionality (i.e any type of elevated application or an elevated task) work correctly at a "first" logon?

0 Kudos
popvm
Hot Shot
Hot Shot

Thanks @DEMdev for the response!

By UAC at lowest level I mean it will not notify the user when changes are made to the computer. 

Screen Shot 2021-03-25 at 12.53.35 pm.png

But I think that doesn't matter, the behaviour is same irrespective of that setting.

I created an exe to create a folder under Program Files and set it as path based elevated application. This setting also gets applied at the second login, not at the first login 😞

I have sent you a video via PM which shows the behaviour. 

0 Kudos
popvm
Hot Shot
Hot Shot

Just verified that the behaviour is same in the test environment as well as in production. They both use the same AD, but the Horizon and DEM environments are independent and use different versions.

Tags (1)
0 Kudos
DEMdev
VMware Employee
VMware Employee

Hi @popvm,

I think we pretty much depend on UAC being at its default level for privilege elevation to work. (I know it's not documented as such, but that's because we did not expect UAC being turned off in typical managed desktop scenarios...)

Could it be the case the in the "second" logon, the UAC configuration is different than in the first?

0 Kudos
popvm
Hot Shot
Hot Shot

Just verified that the UAC setting is same on first and second logins. Also tested using different UAC settings (including the default), but the behaviour is same unfortunately. 

0 Kudos
DEMdev
VMware Employee
VMware Employee

Hi @popvm,

Please open an official support ticket, so we can get this looked at by an engineer who actually knows privilege elevation in detail, instead of me 🙂

popvm
Hot Shot
Hot Shot
Support Request Confirmation Number:
21209533503
0 Kudos
popvm
Hot Shot
Hot Shot

To close the loop, this was indeed a bug in DEM 10.0 and 10.1 which got fixed in 10.2.

https://docs.vmware.com/en/VMware-Dynamic-Environment-Manager/2009/rn/VMware-Dynamic-Environment-Man... 

@DEMdev Thanks for your time on this, as always!

DEMdev
VMware Employee
VMware Employee

Hi @popvm,

Thank you for closing the loop! I hadn't heard back yet through our internal channels whether it was indeed this 10.0/10.1 issue. Thanks to @Pim_van_de_Vis for the suggestion, as this issue (and fix) had completely slipped my mind...

I'm still stumped how a "first" logon can differ from a "second" one in an IC setup, but hey, as long as your issue is fixed I'm happy 😉

popvm
Hot Shot
Hot Shot

I don't think this is limited to IC desktops as the above documentation does not mention about the type of desktops and as far as I remember, we were seeing this for LC as well. I am curious too to know why this happens only on the first logon. If we can find it from the code change in 10.2, it will be great.

0 Kudos
DEMdev
VMware Employee
VMware Employee

Hi @popvm,

The issue is not limited to IC, but my confusion is 🙂 In my understanding, every logon to IC is a "first" one, so I do not understand how things could start working on a "second" logon.

As for the issue details: DEM's FlexService sets up some privilege elevation-related infrastructure during logon. There's no point in doing that if the product is installed but there's no agent configuration, so we optimized that a bit in 10.0. Unfortunately, that introduced a timing-related issue in NoAD scenarios. The fix in 10.2 resolves that (and the 10.0/10.1 release notes describe a workaround.)

Talking about timing issues: the known issue in 10.0 and 10.1 was only added to the respective release notes pages on 3/31. That explains why you did not come across it in your initial research (re: your note in the SR.)

0 Kudos
popvm
Hot Shot
Hot Shot

Ah, okay. Traditionally, an IC desktop is always set to 'Refresh on Logoff', which means every logon is a new logon as you mentioned. But recent releases have the option to disable the 'Refresh on Logoff'. Privilege elevation will work in the second logon only if 'Refresh on Logoff; is turned off. Same is the behaviour if 'Refresh on Logoff' is set on an LC pool.

Thanks for explaining the issue in detail, much appreciated.