Bug #80356 Access Denied to WMI Queries adding 5 second delay to .NET connector
Submitted: 12 Feb 2016 22:35 Modified: 23 Mar 2016 11:27
Reporter: Jeff Escamilla Email Updates:
Status: No Feedback Impact on me:
None 
Category:Connector / NET Severity:S3 (Non-critical)
Version:6.9.8 OS:Windows
Assigned to: Assigned Account CPU Architecture:Any
Tags: access denied, connector, wmi

[12 Feb 2016 22:35] Jeff Escamilla
Description:
When using the MySql.Data.dll class through IIS there is a 5 second delay when connecting to a MySql DB if access to WMI is restricted and the code is running via remote UNC path (due to the security level of the running process). Upon tracing the issue, it looks like it's being caused by the following function (MySql.Data - MysqlDefs.cs - Line 517)

[DisplayName("_os_details")]
    public string OSDetails
    {
      get
      {
        string os = string.Empty;
        try
        {
            var searcher = new System.Management.ManagementObjectSearcher("SELECT * FROM Win32_OperatingSystem");
            var collection = searcher.Get();
            foreach (var mgtObj in collection)
            {
                os = mgtObj.GetPropertyValue("Caption").ToString();
                break;
            }
            // os = "Microsoft Windows Server 2012 R2 Standard";
        }
        catch (Exception ex) { System.Diagnostics.Debug.WriteLine(ex.ToString()); }

        return os;
      }
    }

Whenever a connection.open() is called, the driver attempts to enumerate the "Caption" value from WMI to populate the connection attributes, but encounters a 5-second delay before receiving an "Access Denied" which is silently discarded (via the Debug.WriteLine call).

It looks like this code was introduced sometime between 6.4.8 and 6.5.7

How to repeat:
Via .net (pick your flavor/method)

- Restrict access to WMI for a particular user/process
- Build a .net app that makes a simple connect to a mysql server using the "Connector / Net" driver, make sure to put it on a UNC share
- Run and note the 5 second delay

To fix this issue:
- Add the "WMI Control" snap in to MMC
- Go to "Properties"
- Click on "Security" tab
- Select "Root\CIMV2"
- Click "Security"
- Check "Enable Remote" for "Authenticated Users"

Suggested fix:
Enabling a WMI call to get the OS type does allow for a more dynamic call, however WMI queries are not suited for remote and shared environments and is often restricted for security purposes. 

Suggest pulling the Operating System type via another method and/or having an option to disable it altogether.
[17 Feb 2016 12:31] Chiranjeevi Battula
Hello Jeff Escamilla,

Thank you for the bug report.
I tried to reproduce the issue at my end using MySQL Connector/Net 6.9.8 and WMI User but not seeing any delay in access denied time.
Could you please list out exact steps you tried out at your end, this would help us to reproduce the issue at our end. 

Thanks,
Chiranjeevi.
[17 Feb 2016 12:31] Chiranjeevi Battula
**********Normal Access Time************

Normal Access Time : 00:00:00.2560147 ms
Normal Access Time : 00:00:00.0400023 ms
Normal Access Time : 00:00:00.0790045 ms
Normal Access Time : 00:00:00.0350020 ms
Normal Access Time : 00:00:00.1400080 ms
Normal Access Time : 00:00:00.0670039 ms
Normal Access Time : 00:00:00.0720042 ms
Normal Access Time : 00:00:00.0750043 ms
Normal Access Time : 00:00:00.0680039 ms
Normal Access Time : 00:00:00.1430082 ms
Normal Access Time : 00:00:00.0830048 ms
Normal Access Time : 00:00:00.0780044 ms
Normal Access Time : 00:00:00.0710041 ms

**********Access Denied Time************

Access Denied Time : 00:00:00.2940168 ms
Access Denied Time : 00:00:00.0790045 ms
Access Denied Time : 00:00:00.0650037 ms
Access Denied Time : 00:00:00.0640037 ms
Normal Access Time : 00:00:00.0650037 ms
Access Denied Time : 00:00:00.0630036 ms
Access Denied Time : 00:00:00.0750043 ms
Access Denied Time : 00:00:00.0670039 ms
Normal Access Time : 00:00:00.0750043 ms
Access Denied Time : 00:00:00.0690039 ms
Access Denied Time : 00:00:00.0680039 ms
Access Denied Time : 00:00:00.0690039 ms
Access Denied Time : 00:00:00.0670038 ms
Access Denied Time : 00:00:00.0660037 ms
[17 Feb 2016 17:56] Jeff Escamilla
Howdy. I'm having my team look into it as well to figure out the exact policy that gets applied that prevents access to WMI. We can make the issue go away if we use IIS impersonation (even when using the same account that the application pool is running as).

I will follow up with them and get you the policy that we believe is responsible for this.

Thanks!
Jeffe
[24 Mar 2016 1:00] Bugs System
No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[22 Apr 2019 12:23] MARK LANDRY
Jeff, this WMI behavior is by design. I just worked a case with MS that confirmed it.

"The WMI code review showed, WMI is designed to keep the thread in sleep mode for  5 seconds in case of any exceptions such as lack of permissions (WBEM_E_ACCESS_DENIED) and the thread execution resumes after 5 seconds and returns the exception details to the called process / thread"

It's intended to foil denial of service attacks.
[22 Apr 2019 12:29] MARK LANDRY
The "fix" is to grant the executing user WMI "remote access" permissions.

These links will help.
https://www.gsx.com/blog/bid/86455/enable-remote-wmi-access-for-a-domain-user-account
https://docs.microsoft.com/en-us/windows/desktop/wmisdk/securing-a-remote-wmi-connection

(I'm adding this so the next surprised developer will have a starting point.)