Kerberos Pluggable Authentication is an extension included in the commercial product MySQL Enterprise Edition.
MySQL Enterprise Edition supports an authentication method that allows users to authenticate to MySQL Server using Kerberos, provided an appropriate Kerberos ticket can be obtained.
This authentication method is available in MySQL 8.0.26 and later for MySQL servers and clients on Linux. It is useful in Linux environments where applications have access to Microsoft Active Directory, which has Kerberos enabled by default. Starting with MySQL 8.0.27 (MySQL 8.0.32 for MIT Kerberos), the client plugin is also supported on Windows. Server-side plugins are still only supported on Linux.
Kerberos pluggable authentication provides the following features:
External authentication: Kerberos authentication enables MySQL Server to accept connections from users defined outside of the MySQL authorization tables, who have been issued the correct Kerberos tickets.
Security: Kerberos uses tickets with symmetric key cryptography to enable authentication without sending passwords over the network. Kerberos authentication supports userless and passwordless schemes.
Plugin and library names
| plugin or file |
plugin or file name |
| Server-side plugin |
authentication_kerberos |
| Client-side plugin |
authentication_kerberos_client |
| Library file |
authentication_kerberos.so, authentication_kerberos_client.so |
The server-side Kerberos authentication plugin is only included with MySQL Enterprise Edition. It is not included in the MySQL community distribution. Client plugins are included in all distributions, including community distributions. This enables clients from any distribution to connect to servers loaded with server-side plugins.
Prerequisites for Kerberos Pluggable Authentication
● The Kerberos service must be available for the Kerberos authentication plug-in to communicate.
● Every Kerberos user (principal) to be authenticated by MySQL must exist in the database managed by the KDC server.
● The Kerberos client library must be available on the system using the server-side or client-side Kerberos authentication plugin. Also, GSSAPI is used as an interface to access Kerberos authentication, so a GSSAPI library must be available.
How Kerberos Authentication for MySQL Users Works
Familiarity with Kerberos concepts and operations is assumed here. The following list briefly defines several common Kerberos terms. You may also find the Glossary section of RFC 4120 helpful.
● Principal: A named entity, such as a user or server. In this discussion, certain key related terms appear frequently:
■ SPN: Service Principal Name; the name of the principal representing the service.
■ UPN: User Principal Name; represents the name of the user's principal.
● KDC: key distribution center, including AS and TGS:
■ AS: Authentication Server; provides the initial ticket-granting tickets needed to obtain additional tickets.
■ TGS: Ticket Granting Server; provides additional tickets to Kerberos clients with a valid TGT.
• TGT: Ticketing Ticket; presented to the TGS to obtain a Service Ticket for service access.
● ST: Service ticket; provides access to services such as those provided by the MySQL server.
Authentication using Kerberos requires a KDC server, for example, provided by Microsoft Active Directory.
Kerberos authentication in MySQL uses the Generic Security Services Application Programming Interface (GSSAPI), which is a security abstraction interface. Kerberos is an instance of a specific security protocol that can be used through this abstract interface. Using GSSAPI, applications authenticate through Kerberos to obtain service credentials, which in turn use these credentials to enable secure access to other services.
On Windows,
the authentication_kerberos_client authentication plugin supports two modes, which the client user can set at runtime or specify in an options file:
● SSPI mode: Security Support Provider Interface (SSPI) implements GSSAPI (see Commands for Windows clients in SSPI mode). SSPI, while compatible with GSSAPI at the wire level, only supports the Windows single sign-on scenario and targets logged-in users exclusively. SSPI is the default mode on most Windows clients.
● GSSAPI mode: GSSAPI is supported through the MIT Kerberos library on Windows (see Commands for Windows clients in GSSAPI mode).
With the Kerberos authentication plugin, applications and the MySQL server can use the Kerberos authentication protocol to mutually authenticate users and MySQL services. In this way, both the user and the server are able to authenticate each other. No password is sent over the network, and Kerberos protocol messages are protected from eavesdropping and replay attacks.
Kerberos authentication follows the following steps, where the server-side and client-side parts
are performed using the authentication_Kerberos and authentication_ckerberos_client authentication plugins, respectively:
1. The MySQL server sends its service principal name to the client application. This SPN must be registered with the Kerberos system and
configured on the server side using the authentication_Kerberos_service_principal system variable.
2. The client application creates a Kerberos client authentication session using GSSAPI and exchanges Kerberos messages with the Kerberos KDC:
■ The client obtains a ticket-granting ticket from the authentication server.
■ Using a TGT, the client obtains a MySQL service ticket from the ticket-granting service.
This step can be skipped or partially skipped if the TGT, ST, or both are already cached locally. Clients can choose to use the client keytab file to obtain TGT and ST without providing a password.
3. Using GSSAPI, the client application presents the MySQL ST to the MySQL server.
4. The MySQL server uses GSSAPI to create a Kerberos server-side authentication session. The server verifies the user's identity and the validity of the user's request. It authenticates the ST using the service key configured in its service key tab file to determine whether the authentication succeeded or failed and returns the authentication result to the client.
Applications can authenticate using a supplied username and password, or using a locally cached TGT or ST (created, for example, using kinit or similar). Thus, the design covers everything from a completely userless and passwordless connection (where the Kerberos service ticket is obtained from a locally stored Kerberos cache) to providing a username and password and using it to obtain a valid Kerberos service ticket from the KDC to send to the MySQL server Various use cases for connectivity.
As mentioned earlier, MySQL Kerberos authentication uses two keytab files:
● On the client host, you can use the client keytab file to obtain the TGT and ST without providing a password.
● On the MySQL server host, the server-side service keytab file is used to verify the service ticket received by the MySQL server from the client. The keytab filename is
configured using the authentication_kerberos_service_key_tab system variable.
Install Kerberos Pluggable Authentication
Note: Server-side plugins are only supported on Linux systems. On Windows systems, only the client plugin is supported (starting with MySQL 8.0.27), which can be used in Windows systems to connect to Linux servers using Kerberos authentication.
To be used by the server, plugin library files must be located in the MySQL plugin directory (the directory named by the plugin_dir system variable). If necessary, configure the plugin directory location by setting the value of plugin_dir at server startup.
The base name of the server-side plugin library file is authentication_kerberos. The filename suffix for Unix and Unix-like systems is .so
To load a plugin at server startup, use the --plugin-load-add option to name the library file that contains the plugin. With this plugin loading method, this option must be given every time the server starts. Also, specify values for system variables provided by any plugins you wish to configure. The plugin exposes these system variables, allowing its operation to be configured:
●
authentication_kerberos_service_principal: MySQL service principal name (SPN). This name will be sent to clients attempting to authenticate using Kerberos. The SPN must exist in the database managed by the KDC server. Defaults to mysql/host_name@realm_name.
●
authentication_kerberos_service_key_tab: keytab file for authenticating tickets received from clients. This file must exist and contain a valid key for the SPN, otherwise client authentication will fail. The default is mysql.keytab in the data directory.
To load and configure the plugin, put the following lines in the my.cnf file, using the system variable values appropriate for your installation:
[mysqld]
plugin-load-add=authentication_kerberos.so
authentication_kerberos_service_principal=mysql/[email protected]
authentication_kerberos_service_key_tab=/var/mysql/data/mysql.keytabAfter modifying my.cnf, restart the server for the new settings to take effect.
Alternatively, to load the plugin at runtime, use the following statement:
INSTALL PLUGIN authentication_kerberos SONAME 'authentication_kerberos.so';INSTALL PLUGIN loads the plugin immediately and registers it in the mysql.plugins system table so that the server loads it on each subsequent normal startup without --plugin-load-add
When you install the plug-in at runtime without configuring its system variable in the my.cnf file, the system variable
authentication_kerberos_service_key_tab is set to the default value of mysql.keytab in the data directory. The value of this system variable cannot be changed at runtime, so if you need to specify a different file, you will need to add the setting to the my.cnf file and restart the MySQL server. For example:
[mysqld]
authentication_kerberos_service_key_tab=/var/mysql/data/mysql.keytabIf the keytab file is not in the correct location, or does not contain a valid SPN key, the MySQL server will not verify this, but the client will return authentication errors until you resolve this.
The authentication_kerberos_service_principal system variable can be set at runtime and persisted without restarting the server by using the SET PERSIST statement:
SET PERSIST authentication_kerberos_service_principal='mysql/[email protected]';
SET PERSIST为正在运行的MySQL实例设置一个值。它还保存了该值，从而将其转移到随后的服务器重新启动中。要更改正在运行的MySQL实例的值而不将其转移到后续的重新启动，请使用GLOBAL关键字而不是PERSIST。To verify plugin installation, check the Information Schema PLUGINS table or use the SHOW PLUGINS statement. For example:
mysql> SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME = 'authentication_kerberos';
+-------------------------+---------------+
| PLUGIN_NAME | PLUGIN_STATUS |
+-------------------------+---------------+
| authentication_kerberos | ACTIVE |
+-------------------------+---------------+If the plugin fails to initialize, check the server error log for diagnostic messages.
Pluggable authentication using Kerberos
This section describes how to use Kerberos pluggable authentication to enable MySQL accounts to connect to the MySQL server. It is assumed that the server is running with the server-side plug-in enabled, as described in Installing Kerberos Pluggable Authentication, and that the client-side plug-in is available on the client host.
Verify Kerberos Availability
The following example shows how to test the availability of Kerberos in Active Directory. The example makes the following assumptions:
● Active Directory is running on a host named krbauth.example.com with IP address 198.51.100.11.
● MySQL-related Kerberos authentication uses the MySQL.LOCAL domain, and also uses MySQL_LOCAL as the domain name.
● A topic named [email protected] is registered with KDC. (In the discussion that follows, this principal name is associated with the MySQL account that authenticates to the MySQL server using Kerberos.)
With these assumptions met, the following procedure is followed:
1. Please verify that the Kerberos library is properly installed and configured in the operating system. For example, to configure the MYSQL.LOCAL domain and realm for use during MYSQL authentication, the /etc/krb5.conf Kerberos configuration file should contain the following:
[realms]
MYSQL.LOCAL = {
kdc = krbauth.example.com
admin_server = krbauth.example.com
default_domain = MYSQL.LOCAL
}2. You may need to add an entry to /etc/hosts for the server host:
198.51.100.11 krbauth-krbauth.example.com3. Check that Kerberos authentication is working:
a. Authenticate to Kerberos using kinit:
$> kinit [email protected]
Password for [email protected]: (enter password here)The command authenticates for the Kerberos principal named [email protected]. When the command prompts for a password for the principal, enter it. The KDC returns a TGT that is cached on the client for use by other Kerberos-enabled applications.
b. Use klist to check if the TGT was obtained correctly. The output should be similar to this:
$> klist
Ticket cache: FILE:/tmp/krb5cc_244306
Default principal: [email protected]
Valid starting Expires Service principal
03/23/2021 08:18:33 03/23/2021 18:18:33 krbtgt/[email protected]Create a MySQL account using Kerberos authentication
MySQL authentication using the authentication_kerberos authentication plugin is based on kerberos user principal names (UPNs). The instructions here assume a MySQL user named karl authenticates to MySQL using Kerberos, a Kerberos realm named MySQL.LOCAL, and a user principal named [email protected]. This UPN must be registered in several places:
● Kerberos administrators should register usernames as Kerberos principals. This name includes a realm name. The client authenticates via Kerberos using the principal name and password, and obtains a ticket-granting ticket (TGT).
● The MySQL DBA should create an account corresponding to the Kerberos principal name and use the Kerberos plugin for authentication.
It is assumed that the Kerberos user principal name has been registered by the appropriate service administrator and that the MySQL server has been started with the appropriate configuration settings for the server-side Kerberos plug-in as described earlier in Installing Kerberos Pluggable Authentication. To create a MySQL account that corresponds to a Kerberos UPN of user@realm_name, the MySQL DBA uses a statement like this:
CREATE USER user IDENTIFIED WITH authentication_kerberos BY 'realm_name';Accounts named by users may include or omit the hostname portion. If hostname is omitted, it defaults to %. The realm_name is stored in the mysql.user system table as the authentication_string value for the account.
To create the MySQL account [email protected] corresponding to the UPN, please use the following statement:
CREATE USER 'karl' IDENTIFIED WITH authentication_kerberos BY 'MYSQL.LOCAL';For example, if MySQL must construct a UPN for the account to obtain or validate a ticket (TGT or ST), it will do so by combining the account name (ignoring any hostname parts) and the realm name. For example, the full account name generated by the preceding CREATE USER statement is 'karl'@'%' MySQL builds the UPN from the username part karl (ignoring the hostname part) and the realm name MySQL.LOCAL to generate [email protected].
Note that when creating an account that uses authentication_kerberos for authentication, the CREATE USER statement does not include the UPN realm as part of the username. Instead, specify the realm (MYSQL.LOCAL in this case) as the authentication string in the BY clause. This is different from creating accounts that use the authentication_ldap_sasl sasl ldap authentication plugin and the GSSAPI/Kerberos authentication method. For such accounts, the CREATE USER statement does include the UPN realm as part of the username.
Once the account is set up, clients can use it to connect to the MySQL server. The process depends on whether the client host is running Linux or Windows, as discussed below.
The use of authentication_kerberos is limited, i.e. UPNs with the same user part but different realm parts are not supported. For example, you cannot create MySQL accounts corresponding to these two UPNs:
Both UPNs have the user part for kate, but the realm part is different (MYSQL.LOCAL vs. EXAMPLE.COM). This is not allowed.
Connect to the MySQL server using a MySQL account
After setting up a MySQL account that uses Kerberos for authentication, clients can use it to connect to the MySQL server as follows:
1. Authenticate with Kerberos using the User Principal Name (UPN) and its password to obtain a Ticket-Granting Ticket (TGT).
2. Use the TGT to obtain a service ticket (ST) for MySQL.
3. Authenticate to the MySQL server by providing the MySQL ST.
The first step (authentication to Kerberos) can be performed in various ways:
● Before connecting to MySQL:
■ On Linux or Windows in GSSAPI mode, call kinit to get the TGT and save it in the Kerberos credential cache.
■ On Windows in SSPI mode, authentication may already be done at login time, which saves the logged in user's TGT in the Windows memory cache. No kinit is used, and no Kerberos cache.
● The client program itself can obtain a TGT when connecting to MySQL, if it can determine the required Kerberos UPN and password:
■ The information can come from sources such as command options or the operating system.
■ On Linux, the client can also use the keytab file or the /etc/krb5.conf configuration file. Windows clients in GSSAPI mode use configuration files. Windows clients in SSPI mode use neither.
The details of the client commands used to connect to the MySQL server vary between Linux and Windows, so each host type is discussed separately, but these command properties apply regardless of the host type:
● Each command shown includes the following options, but each option can be omitted in some cases:
■ The --default-auth option specifies the name of the client authentication plugin (
authentication_kerberos_client). This option may be omitted when the --user option is specified, because in this case MySQL can determine the plugin based on the user account information sent by the MySQL server.
■ The --plugin-dir option indicates to client programs
the location of the authentication_kerberos_client plugin. This option can be omitted if the plugin is installed in the default location (where it was compiled).
● The command should also include any other options needed to specify which MySQL server to connect to, such as --host or --port
● Enter each command on one line. If the command includes a --password option to request a password, enter the password for the Kerberos UPN associated with the MySQL user when prompted.
Connection commands for Linux clients
On Linux, the appropriate client command to connect to a MySQL server varies depending on whether the command uses a TGT from the Kerberos cache for authentication, or a command option based on the MySQL username and UPN password:
● Before invoking the MySQL client program, the client user can obtain the TGT from the KDC independently of MySQL. For example, a client user can authenticate to Kerberos using kinit by providing a Kerberos user principal name and principal password:
$> kinit [email protected]
Password for [email protected]: (enter password here)The resulting TGT of the UPN is cached and made available to other Kerberos-enabled applications, such as programs using client-side Kerberos authentication plugins. In this case, invoke the client without specifying the username or password options:
mysql --default-auth=authentication_kerberos_client --plugin-dir=path/to/plugin/directoryThe client plugin finds the TGT in the cache, uses it to get the MySQL ST, and uses the ST to authenticate to the MySQL server.
As mentioned earlier, when caching the TGT for a UPN, the username and password options are not required in the client command. If the command still contains them, they are handled as follows:
■ This command includes a username option:
mysql --default-auth=authentication_kerberos_client --plugin-dir=path/to/plugin/directory --user=karlIn this case, authentication fails if the username specified by the option does not match the username portion of the UPN in the TGT.
■ This command includes a password option, which can be entered when prompted:
mysql --default-auth=authentication_kerberos_client --plugin-dir=path/to/plugin/directory --passwordIn this case, the client plugin ignores the password. Because authentication is based on TGT, it can succeed even if the password provided by the user is incorrect. Therefore, the plugin produces a warning if a valid TGT is found that causes the password to be ignored.
● If the Kerberos cache does not contain a TGT, the client Kerberos authentication plugin itself can obtain the TGT from the KDC. Invoke the client with the MySQL username and password options, then enter the UPN password when prompted:
mysql --default-auth=authentication_kerberos_client --plugin-dir=path/to/plugin/directory --user=karl --passwordThe client Kerberos authentication plugin combines the username ( karl ) and the realm ( MYSQL.LOCAL ) specified in the user account to build a UPN ( [email protected] ). The client plugin uses the UPN and password to obtain a TGT, using TGT gets MySQL ST and uses ST to authenticate to MySQL server.
Alternatively, assuming the Kerberos cache does not contain a TGT, and the command specifies a password option but no username option:
mysql --default-auth=authentication_kerberos_client --plugin-dir=path/to/plugin/directory --passwordThe client-side Kerberos authentication plugin uses the operating system login name as the MySQL username. It combines the username with the fields in the user's MySQL account to build the UPN. The client plugin uses the UPN and password to obtain a TGT, uses the TGT to obtain a MySQL ST, and uses the ST to authenticate to the MySQL server.
If you're not sure if a TGT exists, you can use klist to check.
Explanation: The client user may not want to reuse the TGT when the client Kerberos authentication plugin itself obtains the TGT. As described in Client Configuration Parameters for Kerberos Authentication, a local /etc/krb5.conf file can be used to enable client plugins to destroy TGTs when they are in use.
Connection commands for Windows clients in SSPI mode
On Windows, using the default client plug-in options (SSPI), the appropriate client command to connect to the MySQL server varies depending on whether the command authenticates based on the MySQL username and UPN password command option, or uses the TGT in Windows memory cache.
The command can explicitly specify options for the MySQL username and UPN password, or omit these options:
● This command includes MySQL username and UPN password options:
mysql --default-auth=authentication_kerberos_client --plugin-dir=path/to/plugin/directory --user=karl --passwordThe client Kerberos authentication plugin combines the username ( karl ) and the realm ( MYSQL.LOCAL ) specified in the user account to build a UPN ( [email protected] ). The client plugin uses the UPN and password to obtain a TGT, using TGT gets MySQL ST and uses ST to authenticate to MySQL server.
Any information in the Windows memory cache is ignored; username and password option values take precedence.
● This command includes the UPN password option, but not the MySQL username option:
mysql --default-auth=authentication_kerberos_client --plugin-dir=path/to/plugin/directory --passwordThe client-side Kerberos authentication plugin uses the logged-in username as the MySQL username and combines that username with the realm in the user's MySQL account to build the UPN. The client plugin uses the UPN and password to obtain a TGT, uses the TGT to obtain a MySQL ST, and uses the ST to authenticate to the MySQL server.
● This command does not include options for MySQL username or UPN password:
mysql --default-auth=authentication_kerberos_client --plugin-dir=path/to/plugin/directoryThe client plugin gets the TGT from the Windows memory cache, uses the TGT to get the MySQL ST, and uses the ST to authenticate to the MySQL server.
This method requires the client host to be part of a Windows Server Active Directory (AD) domain. If not, manually enter the AD server and realm as the DNS server and prefix to help the MySQL client discover the IP address of the AD domain:
a. Launch console.exe and select "Network and Sharing Center".
b. From the sidebar of the Network and Sharing Center window, select Change adapter settings.
c. In the Network Connections window, right-click the network or VPN connection to configure it and select Properties.
d. On the Network tab, locate and click Internet Protocol Version 4 (TCP/IPv4), and then click Properties.
e. Click Advanced in the Internet Protocol Version 4 (TCP/IPv4) Properties dialog box. The Advanced TCP/IP Settings dialog opens.
f. In the DNS tab, add Active Directory Server and Realm as DNS Server and Prefix.
● This command includes the MySQL username option, but not the UPN password option:
mysql --default-auth=authentication_kerberos_client --plugin-dir=path/to/plugin/directory --user=karlThe client-side Kerberos authentication plugin compares the name specified by the username option with the logged-in username. If the names are the same, the plugin will use the logged in user TGT for authentication. If the names are different, authentication fails.
Connection commands for Windows clients in GSSAPI mode
On Windows, client users must
explicitly specify the GSSAPI mode using the plugin_authentication_kerberos_client_mode plugin option to enable support via the MIT kerberos library. The default mode is SSPI
GSSAPI mode can be specified:
● Before calling the MySQL client program in the option file. Underscores or dashes are valid for plugin variable names:
[mysql]
plugin_authentication_kerberos_client_mode=GSSAPIor:
[mysql]
plugin-authentication-kerberos-client-mode=GSSAPI• Use the mysql or mysqldump client programs from the command line at runtime. For example, the following command (with underscores or dashes) causes mysql to connect to the server through the MIT Kerberos library on Windows.
mysql [connection-options] --plugin_authentication_kerberos_client_mode=GSSAPIor:
mysql [connection-options] --plugin-authentication-kerberos-client-mode=GSSAPI● Client users can choose GSSAPI mode from MySQL Workbench and some MySQL connectors. On client hosts running Windows, you can override the default location:
■ Kerberos configuration files by setting the KRB5_CONFIG environment variable.
■ Default credential cache name with KRB5CCNAME environment variable (for example, KRB5CCNAME=DIR:/mydir/)
The appropriate client command to connect to a MySQL server will vary depending on whether the command uses a TGT from the MIT Kerberos cache for authentication, or a command option based on the MySQL username and UPN password. Support for GSSAPI through the MIT library on Windows is similar to GSSAPI on Linux, with the following exceptions:
• Tickets are always retrieved from or put into the MIT Kerberos cache on the host running Windows.
● kinit runs on Windows using a functional account with narrow privileges and specific roles. The client user does not know the kinit password.
● If the client user provides a password, the MIT Kerberos library on Windows will decide whether to use it or rely on an existing ticket.
● The destroy_tickets parameter described in Client Configuration Parameters for Kerberos Authentication is not supported because the MIT Kerberos library on Windows does not support the API member (get_profile_boolean) required to read its value from a profile.
Client Configuration Parameters for Kerberos Authentication
Only available for client hosts running Linux, not for client hosts running Windows.
Note: Typically,
client hosts running Windows with the authentication_kerberos_client client kerberos plugin set to GSSAPI mode do support the client configuration parameter, but the MIT kerberos library on Windows does not support the destroy_tickets parameter described in this section.
If no valid ticket-granting ticket (TGT) exists at the time the MySQL client application invokes it, the application itself may obtain and cache the TGT. If, during the Kerberos authentication process, a client application causes TGTs to be cached, they can be destroyed after any such added TGTs are no longer needed by setting the appropriate configuration parameters.
authentication_kerberos_client The client kerberos plugin reads the local /etc/krb5.conf file. An error occurs if this file is missing or inaccessible. Assuming the file is accessible, it can include an optional [appdefaults] section to provide information used by the plugin. Put the info in the mysql section of that section. For example:
[appdefaults]
mysql = {
destroy_tickets = true
}The client plugin recognizes these parameters in the mysql section:
● The destroy_tickets value indicates whether the client plug-in will destroy the TGT after obtaining and using it. destroy_stickets is false by default, but can be set to true to avoid TGT reuse. (This setting only applies to TGTs created by client plugins, not TGTs created by other plugins or outside of MySQ.)
On the client host, the client key tab file can be used to obtain the TGT and TS without providing a password.
Kerberos Authentication Debugging
The AUTHENTICATION_KERBEROS_CLIENT_LOG environment variable enables or disables debug output for KERBEROS authentication.
Explanation: Although
there is the word CLIENT in AUTHENTICATION_KERBEROS_CLIENT_LOG, the same environment variables apply to server-side plug-ins as in client-side plug-ins.
On the server side, the allowed values are 0 (off) and 1 (on). Log messages are written to the server error log, depending on the verbosity level of the server error log. For example, if priority-based log filtering is used, the log_error_verbosity system variable controls verbosity,
On the client side, allowed values are from 1 to 5, and are written to standard error output.
| log level |
meaning |
| 1 or not set |
no logging |
| 2 |
wrong information |
| 3 |
Error and warning messages |
| 4 |
Error, Warning, and Information Messages |
| 5 |
Error, warning, info, and debug messages |