This section describes how to edit the DSN configuration and then authenticate and connect to MySQL APIs.

DSN Configuration

You can use the Microsoft ODBC Data Source Administrator to edit the DSN configuration. Note that the installation process creates a both a user DSN and a system DSN, as described in Installing the Connector.

Note: The connector stores connection information in the Windows registry. To ensure that the connector can write to the registry, either run Power BI as an administrator or use a User DSN for your connection instead of a System DSN.

User DSN

Complete the following steps to edit the DSN configuration:

1. Select Start > Search, and enter ODBC Data Sources in the Search box.
2. Choose the version of the ODBC Administrator that corresponds to the bitness of your Power BI Desktop installation (32-bit or 64-bit).
3. Select the system data source and click Configure.
4. Edit the information on the Connection tab and click OK.

System DSN

Configure the system DSN the same way as the user DSN, except you will need to switch to the System DSN tab before performing Step 3.

Connecting to MySQL

To connect to MySQL data, set the following properties:

• Server: The host name or IP of the server hosting the MySQL database.
• Port: The port of the server hosting the MySQL database.
• Database (optional): The default database to connect to when connecting to the MySQL Server. If this is not set, MySQL returns tables from all available databases.

Authenticating to MySQL

MySQL supports the following types of authentication:

• Standard
• NT Lan Manager (NTLM)
• LDAP
• SSL
• SSH
• Azure
• AWS

Standard Authentication

To authenticate using standard authentication, set AuthScheme to Password and set the following properties:

• User: The username of the authenticating MySQL user.
• Password: The password associated with the authenticating MySQL user.

NTLM

To authenticate using NTLM, set AuthScheme to NTLM.

By default, the connector determines user credentials and the NTLM domain automatically, using either the domain of the PC it is running on or the domain used by the machine running the MySQL instance. To discover the user credentials, the connector reads the current NTLM user.

If you want to specify a different domain, provide different login credentials, or change the target NTLM version via any or all of the following optional properties:

• User: The authenticating NTLM user.
• Password: The authenticating NTLM user's password.
• Domain: The name of the domain you want to connect to.
• NTLMVersion: The NTLM version used by the connector. Legal values are 1 (default) and 2.

LDAP

To authenticate as an LDAP user, set AuthScheme to LDAP.

Your LDAP credentials are auto-detected by default. If you want to designate a different user and account, set the following optional properties:

• User: The user to login as.
• Password: The user's password.

SSL

To leverage SSL authentication to connect securely to MySQL data, set these properties:

• SSLClientCert: The name of the certificate store for the client certificate. Used in the case of 2-way SSL, where truststore and keystore are kept on both the client and server machines.
• SSLClientCertPassword: The client certificate store's password. Required if the certificate store is password-protected.
• SSLClientCertSubject: The subject of the TLS/SSL client certificate. Used to locate the certificate in the store.
• SSLClientCertType:; The certificate type of the client store.
• SSLServerCert: The certificate to be accepted from the server.

SSH

To authenticate to a remote machine via SSH and access MySQL data, set these properties:

• SSHClientCert: The name of the certificate store for the client certificate.
• SSHClientCertPassword: If a client certificate store is password-protected, set this value to the store's password.
• SSHClientCertSubject: The subject of the TLS/SSL client certificate. Used to locate the certificate in the store.
• SSHClientCertType: The certificate type of the client store.
• SSHPassword: The password that you use to authenticate with the SSH server.
• SSHPort: The port used for SSH operations.
• SSHServer: The SSH authentication server you are trying to authenticate against.
• SSHServerFingerPrint: The SSH Server fingerprint used to verify the host you are connecting to.
• SSHUser: The username for authenticating to the SSH server.

MySQL on Azure

You can authenticate to a MySQL database hosted on Azure AD as an Azure AD user (using Azure AD user credentials), using Azure MSI (using a Managed Service Identity), or via an Azure Password. The following table describes required connection parameters for all three authschemes.

	Parameter	Set To...	Notes
Azure AD user	AzureTenant	The Microsoft Online tenant where MySQL is located.	See Note 1.
	AuthScheme	AzureAD	See Note 2.
Azure MSI	AzureTenant	The Microsoft Online tenant where MySQL is located.	See Note 1.
	AuthScheme	AzureMSI	Most often used when MySQL is running on an Azure VM.
	OAuthClientId	Managed identity's client_identity	Required to obtain a token for a managed identity or if the VM has multiple user-assigned managed identities.
Azure Password	AuthScheme	AzurePassword	To connect directly using your Azure credentials, specify the User and Password of the account you use to connect to Azure.

Notes

1. AzureTenant is generally supplied in the form companyname.microsoft.com, but it is also acceptable to specify the tenant Id. (The tenant Id is the same as the directory Id shown in the Azure Portal Azure Active Directory > Properties page.)

   When OAuthGrantType is set to CODE (the default), AzureTenant is usually not needed unless the user belongs to multiple tenants. When OAuthGrantType is set to CLIENT, AzureTenant is required.

2. The AzureAD AuthScheme is generally used with a custom OAuth application to establish the required OAuth credentials. These usually take the form of an account identifier or cllient ID, and the account password or client secret.

MySQL on AWS

You can connect to a MySQL database hosted on AWS using either IAM roles or EC2 roles.

AWS IAM Roles

Set AuthScheme to AwsIAMRoles.

In many situations, it may be preferable to use an IAM role for authentication instead of the direct security credentials of an AWS root user. If you are specifying the AWSAccessKey and AWSSecretKey of an AWS root user, you may not use roles.

To authenticate as an AWS role, set these properties:

• AWSAccessKey: The access key of the IAM user to assume the role for.
• AWSSecretKey: The secret key of the IAM user to assume the role for.
• AWSRoleARN: Specify the Role ARN for the role you'd like to authenticate with. This will cause the connector to attempt to retrieve credentials for the specified role.

If multi-factor authentication is required, specify the following:

• CredentialsLocation: The location of the settings file where MFA credentials are saved. See the Credentials File Location page under Connection String Options for more information.
• MFASerialNumber: The serial number of the MFA device if one is being used.
• MFAToken: The temporary token available from your MFA device.

This causes the connector to submit the MFA credentials in the request to retrieve temporary authentication credentials.

Note: If you want to control the duration of the temporary credentials, set the TemporaryTokenDuration property (default: 3600 seconds).

EC2 Instances

Set AuthScheme to AwsEC2Roles.

If you are using the connector from an EC2 Instance and have an IAM Role assigned to the instance, you can use the IAM Role to authenticate. Since the connector automatically obtains your IAM Role credentials and authenticates with them, it is not necessary to specify AWSAccessKey and AWSSecretKey.

If you are also using an IAM role to authenticate, you must additionally set AWSRoleARN to the Role ARN for the role you want to authenticate with.

IMDSv2 Support

The MySQL connector now supports IMDSv2. Unlike IMDSv1, the new version requires an authentication token. Endpoints and response are the same in both versions.

In IMDSv2, the MySQL connector first attempts to retrieve the IMDSv2 metadata token and then uses it to call AWS metadata endpoints. If it is unable to retrieve the token, the connector reverts to IMDSv1.