Windows DSN Configuration
Using the Microsoft ODBC Data Source Administrator
You can use the Microsoft ODBC Data Source Administrator to edit the DSN configuration. Note that the DSN is created during the installation process.
Complete the following steps to edit the DSN configuration:
- Select Start > Search, and enter ODBC Data Sources in the Search box.
- Choose the version of the ODBC Administrator that corresponds to the bitness of your application (32-bit or 64-bit).
- Click the System DSN tab.
- Select the system data source and click Configure.
- Edit the information on the Connection tab and click OK.
Note: For .NET Framework 4.0, the driver distributes Microsoft Visual C++ 2015-2022 Redistributable. For .NET Framework 3.5, the driver distributes Microsoft Visual C++ 2008 Redistributable.
Ensuring Registry Access
The driver stores connection information in the Windows registry. To ensure that the driver can write to the registry, perform either of the following actions:
- Run the calling application as an administrator.
- Connect via a User DSN instead of a System DSN.
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 driver 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 driver 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 driver. 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
- 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.
- 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 driver 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.
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 driver from an EC2 Instance and have an IAM Role assigned to the instance, you can use the IAM Role to authenticate. Since the driver 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 driver 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 driver 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 driver reverts to IMDSv1.