I'm trying to find out why UAC-prompt is triggered for some users when launching *.msc-files (standard administrative tools in %windir%\system32) and wonder if someone has seen this issue before and know what's causing it Member of domain group and local administrators: No UAC-prompt - ok Member of domain group (not local admin): UAC-prompt with result access denied (logon type 2=log on locally) Not member of domain group (not local admin): No UAC-prompt - ok If adding/removing user from the domain group, the UAC-prompt is turned on/off for non-admin users. I first saw the issue in the TS/RDS-farm (2008R2), but later found it was the same when testing on office clients (WinVista/Win7). It looks like some security option or user right is restricting the domain group from launching *.msc-files when not authorized to logon locally, but can't find out what setting is forcing the UAC-prompt. The domain group isn't local admin, so UAC-policies should be the same?

Hi, The following articles could be helpful to understand the behavior: http://technet.microsoft.com/en-us/library/dd835546(WS.10).aspx http://support.microsoft.com/kb/922708 If there is anything unclear, please feel free to respond back.This posting is provided "AS IS" with no warranties, and confers no rights. Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Thanks for the reference. For the moment, I haven't found the reason for why the member of the domain group also must be local administrator to avoid UAC-prompt. Shouldn't it be the same for all non-admins?

Hi, Please help collect the following information on the computer that you encounter the issue for research: 1. Please right-click cmd.exe, select run as administrator, and then run secedit /export /cfg exportsec.inf. 2. Please logon the computer with a user that is a member of the domain group to reproduce the issue. And then, please open a command prompt and run whoami /groups > membership.txt. After that, please upload the exportsec.inf and membership.txt files to the following space: https://sftasia.one.microsoft.com/choosetransfer.aspx?key=c496b9c4-ded8-4769-9eb4-e1adcc833370 Password: %J_BVJD8eWoq)mgs Thanks.This posting is provided "AS IS" with no warranties, and confers no rights. Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Files uploaded. I attached two different whoami-dumps for same user with/without the group turning on/off UAC-prompt. MMC used in test is the standard DNS Manager %windir%\system32\dnsmgmt.msc

Hi, Thanks for the information. I’ve checked the group membership of the users. They are different; however, I find that the groups are in the same domains. As a result, it should not cause different behaviors. Based on the current situation, I would like to confirm the exact name of the domain groups you mentioned. Meanwhile, please help collect the following information: 1. Please help collect Process Monitor log when the two users try to launch the same dnsmgmt.msc console. Process Monitor http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx 2. Please run gpresult /z to collect the group policy results for the two users. 3. Please help export the permission setting for the dnsmgmt.msc console. Thanks for your cooperation. This posting is provided "AS IS" with no warranties, and confers no rights. Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

It's the exact same user with the difference that the domain group IT has been added/removed to turn on/off the issue. The group is as shown in the whoami-dumps nested into a couple of other groups (more than I was aware of). I'll upload the requested output later.

Hi, Have you identified the exact domain group causing the issue? If so, please let me know the group name for further research. Thanks.This posting is provided "AS IS" with no warranties, and confers no rights. Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Hi, How's everything going? We've not heard back from you in a few days and wanted to check the current status of the issue. If there is anything unclear, please do not hesitate to respond back. Thanks.This posting is provided "AS IS" with no warranties, and confers no rights. Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

I'm sorry for the lack of reply due to there was other stuff that neaded to get higher priority and after that it rolled on and haven't had time to look on this issue again. I tried now to use procmon on my win7 client having same issue With a filter on "ACCESS DENIED" when the problem occurs, there's a lot about read/write in registry related to certificates (HKLM\SOFTWARE\Microsoft\EnterpriseCertificates, HKLM\SOFTWARE\Microsoft\SystemCertificates etc).

I'm sorry for the lack of reply due to having other stuff that neaded to get higher priority and after that it rolled on and haven't had time to look on this issue again. I tried now to use procmon on my win7 client having same issue With a filter on "ACCESS DENIED" When the problem occurs, there's a lot about read/write in registry related to certificates (HKLM\SOFTWARE\Microsoft\EnterpriseCertificates, HKLM\SOFTWARE\Microsoft\SystemCertificates etc). Process name firing this is consent.exe

I tried to grant Users group on the local machine temporary full control on the registry keys that procmon complained about without changed result for the main problem with UAC prompt. I had missed to investigate all groups IT was member of, so at last I found out that the domain group "Group Policy Creator Owners" is the group causing the issue, and not IT itself. As only a few of IT neads to be member of "Group Policy Creator Owner", removing the nested membership and replace it with the individual users will solve the problem. Not sure why this happens, but verified with another external domain that the same behaviour occurs when adding a non-admin user into the "Group Policy Creator Owners" group.