Posted inUS_1

Troubleshooting SQL Server Error 18456: Login Failed Issues

No Comments

Applies to: SQL Server

Understanding SQL Server Error 18456

When working with SQL Server, encountering error 18456 can be a frustrating experience. This error, identified as MSSQLSERVER_18456, signals a failed login attempt due to authentication problems. The core message, “Login failed for user ‘%.*ls’.%.*ls”, indicates that SQL Server rejected a connection attempt because the provided credentials could not be validated.

Authentication failures in SQL Server can stem from a variety of reasons, ranging from simple incorrect logins to more complex configuration issues. Understanding the potential causes and knowing how to troubleshoot them is crucial for maintaining seamless access to your SQL Server databases. This article aims to provide a comprehensive guide to diagnosing and resolving SQL Server Error 18456, empowering you to quickly restore connectivity and ensure the smooth operation of your SQL Server environment.

Common Causes and Resolutions for Error 18456

The following sections detail some of the most frequent scenarios leading to login failure error 18456. Each section outlines the potential cause and provides step-by-step resolutions to address the issue.

Login Failed for User ” or Login Failed for User ”

This variation of the error message often indicates the type of authentication failure based on whether a domain name is specified.

  • No Domain Specified: Indicates a failure with SQL Server login authentication.
  • Domain Specified: Points to a problem with Windows user account login.

Here are common causes and suggested solutions for these scenarios:

1. Incorrect Authentication Mode: SQL Server Configured for Windows Authentication Only

Potential Cause: You are attempting to use SQL Server Authentication, but the SQL Server instance is set to Windows Authentication mode.

Suggested Resolution:

  1. Verify Authentication Mode: Open SQL Server Management Studio (SSMS) and connect to your SQL Server instance using Windows Authentication.

  2. Access Server Properties: Right-click on the server name in Object Explorer and select Properties.

  3. Navigate to Security Page: In the Server Properties dialog, go to the Security page.

  4. Check Server Authentication: Examine the Server authentication section. If Windows Authentication mode is selected, this confirms the cause.

  5. Change to Mixed Mode (If Necessary): If you need to use SQL Server Authentication, select SQL Server and Windows Authentication mode.

  6. Restart SQL Server: Click OK to save changes and restart the SQL Server service for the new authentication mode to take effect.

    Ensure SQL Server is configured for “SQL Server and Windows Authentication mode” if you intend to use SQL Server logins.

    Alternative: Modify your application’s connection settings to use Windows Authentication if possible, aligning with the server’s configuration.

    Note: Check the SQL Server Error Log for messages like: Login failed for user '<username>'. Reason: An attempt to login using SQL authentication failed. Server is configured for Windows authentication only. This message explicitly confirms this scenario.

2. Group Access Issues and Permissions

Potential Cause: You are trying to access SQL Server through a group membership, and permissions are not correctly configured.

Suggested Resolution:

  1. Verify User Permissions: If you suspect permission issues, use the xp_logininfo extended stored procedure to check user access:

    EXEC xp_logininfo 'domainusername'
    • Error: If you receive an error, SQL Server cannot resolve the username. This could indicate issues with Active Directory (AD) or domain controller (DC) connectivity. Verify the username and domain, and check domain controller availability.
    • No Rows Returned: No groups grant access to the server. The user’s group membership isn’t providing SQL Server access.
    • Rows Returned: The user belongs to groups that provide access.

  2. Cross-Domain Access: For cross-domain scenarios, ensure the group granting access is in the SQL Server domain, not necessarily the user’s domain, for proper membership resolution.

  3. SSMS Login Verification: DBAs can verify permissions in SSMS:

    • Server-Level Logins: Check Security > Logins for server-level login permissions.
    • Database-Level Logins (Contained Databases): For contained databases, check Databases > [Database Name] > Security > Logins.

    Verify login permissions in SSMS Object Explorer under Security.

    Action for DBA: Review and adjust permissions in SSMS or using T-SQL commands like GRANT CONNECT SQL TO [domaingroup] or CREATE LOGIN [domainuser] FROM WINDOWS.

3. SQL Logins Not Enabled

Potential Cause: SQL Server might be configured to only allow Windows Authentication, and SQL logins are not enabled or permitted.

Suggested Resolution:

  1. Check Error Log: Examine the SQL Server error log for the message: “Login failed for user ”. Reason: An attempt to log in using SQL authentication failed. Server is configured for Windows authentication only.”

  2. Choose Authentication Method:

    • Integrated Login (Recommended): Use Windows Authentication. Modify connection strings to utilize integrated security:

      • OLE DB: Integrated Security=SSPI
      • ODBC: Trusted_Connection=Yes
      • .NET Provider: Accepts either syntax.

      Note: Ensure the application environment is properly configured for integrated authentication.

    • Enable SQL Logins (If Necessary): If SQL Server Authentication is required:
      a. In SSMS, right-click the SQL Server instance and choose Properties.
      b. Go to the Security pane.
      c. Select SQL Server and Windows Authentication mode.
      d. Click OK.
      e. Restart the SQL Server service.

      Note: Enabling SQL Server Authentication requires managing SQL logins and passwords.

    • Specify Windows Account: If using SQL Server Authentication is not necessary, use a local or domain Windows account for login, ensuring integrated security is utilized by the application.

4. Login Does Not Exist on the SQL Server Instance

Potential Cause: The specified login account does not exist in SQL Server.

Suggested Resolution:

  1. Verify Login Existence and Spelling: Ensure the SQL Server login (or Windows login) exists and is spelled correctly in the connection string or login attempt.

  2. Check SQL Server Error Log: Look for these messages in the error log:

    • Login failed for user 'username'. Reason: Could not find a login matching the name provided.
    • Login failed for user 'Domainusername'. Reason: Could not find a login matching the name provided.

  3. Correct Connection String: If connecting to the wrong server (e.g., production instead of development), update the connection string to point to the correct SQL Server instance.

  4. Create the Login (If Missing): If the login is missing, create it in SQL Server.

    • SQL Login: Use SSMS or the CREATE LOGIN T-SQL command.
    • Windows Login: Grant access to a Windows user or group directly, or add them to a Windows group that has SQL Server access.

    For example, to create a SQL Login:

    CREATE LOGIN MySQLLogin WITH PASSWORD = 'StrongPassword';

    To create a Windows Login:

    CREATE LOGIN [DOMAINWindowsUser] FROM WINDOWS;

    Create new SQL Server or Windows logins using SSMS.

    Refer to Create a Login for detailed instructions.

5. Incorrect Password for SQL Server Authentication

Potential Cause: Using SQL Server Authentication with an incorrect password for the specified SQL Server login.

Suggested Resolution:

  1. Verify Password Incorrect Error: Check the SQL Server error log for messages like: “Reason: Password did not match that for the login provided“.

  2. Use Correct Password: Ensure the correct password is used in the application’s connection string or login attempt.

  3. Password Reset (If Necessary): If the password is forgotten or unknown, contact your SQL Server administrator to reset the password for the SQL Server login.

  4. Temporary Workaround (Hardcoded Connection String): For troubleshooting application issues, temporarily hardcode the connection string with known correct credentials to isolate the problem. Use a UDL file or a simple script to test the connection.

6. Incorrect Connection String Syntax, Server Name, or User Credentials

Potential Cause: Errors within the connection string itself, such as incorrect syntax, server name, or user credentials.

Suggested Resolution:

  1. Review Connection String Format: Verify the connection string adheres to the correct format for the data provider being used (e.g., OLE DB, ODBC, .NET). Ensure all required parameters are present (server name, database, user name, password).

  2. Check Server Name: Confirm the server name in the connection string is accurate and resolvable.

  3. Named Instance: If connecting to a named instance of SQL Server, ensure the instance name is correctly included in the server name parameter (e.g., Server=ServerNameInstanceName).

  4. Correct Server: Double-check that the connection string points to the intended SQL Server instance.

  5. Grant Database Access (If Necessary): If the connection string is correct, ensure the login has access to the target database. Create a database user for the login and map it accordingly.

  6. Windows Login to Group: If using Windows Authentication, and the login is a Windows user, add the user to a local or domain group that is granted access to the SQL Server.

7. “No Login” Error Related to Kerberos or HOSTS File

Potential Cause: Issues related to Kerberos authentication, often involving incorrect HOSTS file entries or general login denials.

Suggested Resolution:

  1. Examine Error Details: Check the SQL Server error log for messages like:

    • Logon Error: 18456, Severity: 14, State: 11.
    • Logon Login failed for user 'CONTOSOJohnDoe'. Reason: Token-based server access validation failed with an infrastructure error. Check for previous errors. [CLIENT: ]

  2. HOSTS File Issue: A bad manual entry in the HOSTS file with an incorrect server name can cause this. Verify and correct the HOSTS file if necessary.

  3. Permission Denials: Ensure the user account is not explicitly denied login access and has been granted connect permissions.

  4. Group Membership Denials: Check if any group the user belongs to has explicit DENY permissions in SQL Server, which might override granted permissions.

8. Incorrect Domain for Windows Authentication

Potential Cause: Attempting to use Windows Authentication while logged into the wrong domain.

Suggested Resolution:

  1. Verify Domain Login: Ensure the user is logged into the correct Windows domain that is trusted by the SQL Server domain. The error message often displays the domain name to assist in verification.

9. Database Permissions Issues

Potential Cause: The user lacks explicit permissions to access the target database, even though the database appears online and accessible to others.

Suggested Resolution:

  1. Check Database Status: Confirm the database is online in SSMS.

  2. Test with Sysadmin Account: Attempt to connect using a user with sysadmin server role privileges to verify general connectivity and database availability.

  3. Grant Explicit Database Access: Grant the user explicit access to the database or add them to a SQL Server role or Windows group that has database access. Use T-SQL commands like:

    USE [YourDatabaseName];
CREATE USER [domainusername] FOR LOGIN [domainusername];
ALTER ROLE db_datareader ADD MEMBER [domainusername]; -- Example role

    Refer to:

10. Application Not Run as Administrator

Potential Cause: Running applications like SSMS without administrator privileges when administrator credentials are required for connection.

Suggested Resolution:

  1. Run as Administrator: Start the application (e.g., SSMS) using the “Run as Administrator” option.

  2. Add Windows User Login: Once connected with administrator privileges, add the Windows user account as a SQL Server login for regular access without needing to run as administrator every time.

11. Login Deleted After Migration to Contained Database User

Potential Cause: In environments using contained databases, logins might be inadvertently deleted after migrating to contained database users.

Suggested Resolution:

  1. Verify Login Existence: Confirm that the server-level login still exists after migrating to contained database authentication.

  2. Contained Database Authentication: If using contained databases, ensure authentication is configured correctly within the contained database itself.

    Refer to: Contained Database Authentication: Introduction.

12. Login’s Default Database Offline or Unavailable

Potential Cause: The default database configured for the login is offline, inaccessible, or otherwise unavailable.

Suggested Resolution:

  1. Check Database Availability: Contact your SQL Server administrator to verify and resolve any issues with the default database’s availability.

  2. Alternative Database Connection: If the login has permissions to other databases and accessing the default database is not immediately necessary:

    • Change Default Database (Administrator Action): Request the administrator to change the default database for the login using ALTER LOGIN statement or SSMS.

      ALTER LOGIN [YourLoginName] WITH DEFAULT_DATABASE = [SomeOtherDatabase];

    • Specify Database in Connection String: Explicitly specify a different, available database in the application’s connection string.

    • SSMS Connection Properties: In SSMS, use the “Connection Properties” tab in the Connect to Server dialog to specify an available database.

    Applications like SSMS might display errors like: Cannot open user default database. Login failed. Login failed for user <user name="">. (Microsoft SQL Server, Error: 4064). The SQL Server error log will show: Login failed for user '<user name="">'. Reason: Failed to open the database '<dbname>' specified in the login properties [CLIENT: <ip address="">].

    Refer to: MSSQLSERVER_4064.

13. Incorrect Database Specified in Connection String or SSMS

Potential Cause: The database name specified in the connection string or within SSMS is misspelled, offline, or unavailable.

Suggested Resolution:

  1. Correct Database Name: Carefully verify and correct the database name in the connection string. Pay attention to case sensitivity if the SQL Server instance uses a case-sensitive collation.

  2. Check Database Availability: If the name is correct, confirm with the SQL Server administrator that the database is online and accessible.

  3. Connect to Alternative Database: If access to the specified database is not immediately required, and the login has permissions to other databases, specify a different available database in the connection string or SSMS connection properties.

    The SQL Server error log will contain messages like: Login failed for user <username>. Reason: Failed to open the explicitly specified database 'dbname'. [CLIENT: <ip address="">].

    Note: If the login’s default database is available, SQL Server might still allow the connection to succeed, even if the explicitly specified database is problematic.

14. Insufficient Permissions to Requested Database

Potential Cause: The user lacks the necessary permissions to access the specific database they are attempting to connect to.

Suggested Resolution:

  1. Test with Sysadmin Login: Try connecting with a login that has sysadmin privileges to determine if general connectivity is possible.

  2. Grant Database Access: Grant the login access to the database by creating a corresponding database user and assigning appropriate database roles or permissions. For example:

    USE [YourDatabaseName];
CREATE USER [YourLoginName] FOR LOGIN [YourLoginName];
-- Grant specific permissions or add to database roles

    Refer to Troubleshooting Error 18456 for a more extensive list of error codes.

    For further troubleshooting assistance, consult Troubleshooting SQL Client / Server Connectivity Issues.

Login Failed for User NT AUTHORITYANONYMOUS LOGON

This specific error message, “Login failed for user ‘NT AUTHORITYANONYMOUS LOGON'”, often points to issues with credential delegation, particularly in scenarios involving “double-hop” authentication.

Double-hop refers to situations where user credentials need to be passed through multiple services across different computers, such as a client connecting to a web server (IIS) which then connects to SQL Server on a separate machine.

Here are potential causes and resolutions for “Login failed for user ‘NT AUTHORITYANONYMOUS LOGON'”:

1. NTLM Credentials Failure on the Same Computer

Potential Cause: Attempting to pass NTLM credentials between services on the same computer (e.g., IIS to SQL Server) fails.

Suggested Resolution:

  1. Disable Loopback Check: Add the DisableLoopbackCheck or BackConnectionHostNames registry entries to disable loopback checks, allowing local service-to-service communication with NTLM.

    Refer to: DisableLoopbackCheck or BackConnectionHostNames

2. Double-Hop (Constraint Delegation) Scenarios Across Multiple Computers

Potential Cause: Kerberos connection failures in double-hop scenarios across multiple computers, often due to Service Principal Name (SPN) issues.

Suggested Resolution:

  1. Run SQLCheck: Utilize the SQLCheck tool on both the SQL Server and the web server involved in the double-hop.

  2. Troubleshooting Guides: Consult these SQLCheck troubleshooting guides:

3. Duplicate SPNs or NTLM Fallback

Potential Cause: Duplicate SPNs exist, or the client is using LocalSystem or another machine account, leading to NTLM credentials instead of Kerberos.

Suggested Resolution:

  1. SPN Diagnosis Tools: Use SQLCheck or Setspn.exe to identify and resolve SPN-related issues.

  2. Kerberos Configuration Manager: Review Overview of the Kerberos Configuration Manager for SQL Server for SPN management and Kerberos configuration.

4. Local Security Policy Preventing Machine Account for Remote Authentication

Potential Cause: Windows Local Security Policy is configured to prevent the Local System account from being used for remote authentication requests.

Suggested Resolution:

  1. Local Security Policy Editor: Open Local Security Policy (secpol.msc).

  2. Navigate to Security Option: Go to Local Policies > Security Options.

  3. Network security: Allow Local System to use computer identity for NTLM: Locate this policy.

  4. Enable Policy: If the policy is disabled, select Enabled.

  5. Apply Changes: Click OK.

    Note: This policy is enabled by default in Windows 7 and later versions.

5. Expired Kerberos Ticket in Constrained Delegation

Potential Cause: Intermittent “ANONYMOUS LOGON” errors with constrained delegation might indicate an expired Kerberos ticket that the middle tier cannot renew.

Suggested Resolution:

  1. Delegation Settings Change: On the middle-tier server, change delegation settings from “Trust this computer for delegation to specified services only – Use Kerberos Only” to “Trust this computer for delegation to specified services only – Use any protocol.”

    Refer to: Intermittent ANONYMOUS LOGON of SQL Server linked server double hop.

6. NTLM Peer Login Issues

Potential Cause: Problems with NTLM peer authentication in workgroup or non-trusted domain environments.

Suggested Resolution:

  1. Identical Accounts: Ensure identical user accounts and passwords exist on both machines involved in NTLM peer authentication. NTLM Peer Login requires matching credentials on both sides.

7. Loopback Protection Interference

Potential Cause: Loopback protection preventing local applications from calling other services on the same machine.

Suggested Resolution:

  1. Disable Loopback Check or BackConnectionHostNames: Set either the DisableLoopbackCheck or (preferably) the BackConnectionHostNames registry key to allow loopback communication.

    Refer to: Error message when you try to access a server locally by using its FQDN or its CNAME alias after you install Windows Server 2003 Service Pack 1: Access denied or No network provider accepted the given network path.

8. Always-On Listener Loopback Protection

Potential Cause: When connecting to an Always-On Listener from the primary node, NTLM authentication might engage Loopback Check, resulting in “Login failed” with untrusted domain error.

Suggested Resolution:

  1. BackConnectionHostNames Registry Key: Add the Listener NETBIOS name and fully qualified name to the BackConnectionHostNames registry key on all machines in the Availability Group.

    Refer to: Error message when you try to access a server locally by using its FQDN or its CNAME alias after you install Windows Server 2003 Service Pack 1: Access denied or No network provider accepted the given network path.

9. LANMAN Compatibility Level Mismatch

Potential Cause: Compatibility issues between older (pre-Windows 2008) and newer computers related to LANMAN compatibility level.

Suggested Resolution:

  1. Set LANMAN Compatibility Level to 5: Set the LANMAN compatibility level to 5 on all computers involved. This setting also disables NTLM v1.

  2. Switch to Kerberos: Consider switching to Kerberos authentication to avoid NTLM-related compatibility problems.

10. Sensitive Account Restrictions

Potential Cause: Active Directory accounts marked as “Sensitive” cannot be delegated in double-hop scenarios.

Suggested Resolution:

  1. Check Account Sensitivity: If using a “Sensitive” account, understand delegation limitations and consider using a different account if delegation is required.

11. Constrained Delegation Target Issue

Potential Cause: If constrained delegation is enabled for a service account, Kerberos will fail if the target server’s SPN is not in the constrained delegation target list.

Suggested Resolution:

  1. Constrained Delegation Configuration: Verify and ensure the target SQL Server SPN is correctly added to the list of targets for constrained delegation on the service account being used.

12. Per-Service-SID Limitation

Potential Cause: The Per-Service-SID feature might restrict local connections to NTLM, preventing Kerberos authentication and delegation beyond a single hop.

Suggested Resolution:

  1. Understand Per-Service-SID: Be aware that Per-Service-SID can limit authentication methods and delegation capabilities for local service connections.

13. NTLM and Constrained Delegation with File Shares

Potential Cause: When the target resource is a file share in an NTLM and constrained delegation scenario, delegation type must be “Constrained-Any,” not “Constrained-Kerberos.”

Suggested Resolution:

  1. Delegation Type for File Shares: For file share targets in constrained delegation, configure the middle-tier service account delegation type to “Trust this computer for delegation to specified services only – Use any protocol.” (Constrained-Any).

Note: Double-hop scenarios are complex. For in-depth information, see:

Login Failed for User (empty)

The error “Login failed for user (empty)” or “Login failed for user ”” indicates that SQL Server could not obtain user credentials from the operating system. This often occurs due to network connectivity or Active Directory issues.

Potential Cause: Network connectivity problems preventing communication with the domain controller or Local Security Authority Subsystem Service (LSASS).

Suggested Resolution:

  1. Network Connectivity Check: Verify the computer’s network connection. Ensure it is properly connected to the network and can communicate with the domain.

  2. Domain Controller Availability: Check if the domain controller is reachable and responsive.

  3. Event Logs: Examine the system and application event logs on both the client and server machines for network-related or Active Directory-related errors around the time of the login failure. Look for events from sources like NETLOGON.

    Example event log message:

    Source: NETLOGON
Date: 8/12/2012 8:22:16 PM
Event ID: 5719
Level: Error
Description: This computer was not able to set up a secure session with a domain controller in domain due to the following: The remote procedure call was cancelled.

  4. SSPI Error Codes: Look for corresponding SSPI error codes in SQL Server error log, such as:

    • SSPI handshake failed with error code 0x80090311: No authority could be contacted for authentication.
    • SSPI handshake failed with error code 0x80090304: The Local Security Authority cannot be contacted.

  5. NLTEST.EXE for DC Issues: Use the NLTEST.EXE command-line tool to diagnose and potentially switch domain controllers:

    • Query DC: NLTEST /SC_QUERY:CONTOSO (replace CONTOSO with your domain name)
    • Reset DC: NLTEST /SC_RESET:CONTOSODC03 (replace with domain and specific DC name)

  6. Contact Active Directory Team: If network and domain controller issues persist, contact your Microsoft Active Directory team for further assistance.

Login Failed for User ‘(null)’

“Login failed for user ‘(null)'” suggests that LSASS (Local Security Authority Subsystem Service) could not decrypt the security token using the SQL Server service account credentials. This is often due to incorrect SPN (Service Principal Name) configuration.

Potential Cause: Incorrect SPN associated with the wrong account preventing LSASS from decrypting the security token.

Suggested Resolution:

  1. DNS Name Resolution: Diagnose and fix any Domain Name System (DNS) name resolution issues. Accurate DNS is crucial for Kerberos and SPN functionality.

    • Ping Tests: Use PowerShell ping -a <IP Address> and ping -a <ComputerName> (use -4 for IPv4, -6 for IPv6).
    • NSLookup: Use NSLookup to query local and remote computer names and IP addresses multiple times, looking for inconsistencies.

  2. Firewall and Network Devices: Ensure firewalls or other network devices are not blocking client communication with the domain controller. Clients need to access Active Directory to retrieve SPN information.

  3. SPN Verification: Use SETSPN -X and SETSPN -Q commands to check for duplicate or misplaced SPNs.

    Example:

    SETSPN -Q MSSQLSvc/SQLServerName.domain.com:1433

    Verify the correct SPN is registered for the SQL Server service account. If incorrect, use SETSPN -D to delete the incorrect SPN and SETSPN -A to add the correct one.

Additional Error Information (Error States)

The error message displayed to the client is intentionally generic for security reasons. However, the SQL Server error log provides more detailed error state information to help pinpoint the cause of the login failure.

Compare the “State” value in the error log (Error: 18456, Severity: 14, State: [State Number]) to the following table to understand the specific reason for the authentication failure:

State Description
1 Error information unavailable (permission issue to view error details).
2, 5 Invalid User ID.
6 Windows login name used with SQL Server Authentication.
7 Login disabled and incorrect password.
8 Incorrect password.
9 Invalid password.
11 Valid login, server access failed (e.g., Windows Admin credentials not provided).
12 Valid login, server access failed (general).
18 Password must be changed (password expiration policy).
38, 46 Database requested by user not found.
58 SQL Authentication attempted when server is in Windows Authentication mode only; SIDs mismatch.
62 Windows Authentication to contained database with SID mismatch.
102-111 Azure AD (Azure Active Directory) failure.
122-124 Empty username or password.
126 Database requested by user does not exist.
132-133 Azure AD failure.
Other Unexpected internal processing error.

Rare Cause: Mixed Mode and ODBC Connections Without Trusted Connection

Potential Cause: In mixed mode authentication, ODBC connections using TCP protocol might fail if they don’t explicitly specify a trusted connection. Similarly, named pipes connections in mixed mode might use impersonation without explicitly requesting trusted authentication.

Suggested Resolution:

  1. Include TRUSTED_CONNECTION = TRUE: Add TRUSTED_CONNECTION = TRUE to the connection string for ODBC connections to explicitly request Windows Authentication when using mixed mode.

Examples of Error 18456 in SQL Server Error Log

Example 1: Incorrect Password (State 8)

Date        Source    Message
---------------------------------------------------------------------------------
2007-12-05 20:12:56.34 Logon     Error: 18456, Severity: 14, State: 8.
2007-12-05 20:12:56.34 Logon     Login failed for user ''. [CLIENT: <client_ip>]

In this example, State 8 clearly indicates an incorrect password was provided.

Example 2: Initially Disabled ‘sa’ Login (State 7)

Note: When SQL Server is installed in Windows Authentication mode and later changed to Mixed Mode, the ‘sa’ login is initially disabled. Attempting to use ‘sa’ in this state will result in State 7: “Login failed for user ‘sa’.”

To enable the ‘sa’ login, see Change Server Authentication Mode.

See Also

Comments

No comments yet. Why don’t you start the discussion?

Leave a Reply

Your email address will not be published. Required fields are marked *