ViciDial Login Incorrect Error — Fix Agent & Admin Auth Failures

Learn how to diagnose and resolve "login incorrect" authentication failures in ViciDial for both agents and administrators, including database verification, configuration checks, and real-world debugging techniques.

Prerequisites

Before troubleshooting ViciDial login errors, ensure you have:

• Root or sudo access to your ViciDial server
• SSH access to the production system
• Database credentials for the asterisk database
• Basic understanding of MySQL/MariaDB queries
• Familiarity with Linux file permissions and Apache/PHP logs
• A backup of your ViciDial configuration before making changes
• Knowledge of your ViciDial version (check /usr/share/astguiclient/VERSION)

Verify your environment:

mysql -u root -p -e "SELECT VERSION();"
asterisk -rx "core show version"
ps aux | grep -E "apache|mysql|asterisk" | grep -v grep

Understanding ViciDial Authentication Architecture

ViciDial uses a dual-layer authentication system:

1. Agent login — Handled by /agc/vicidial.php, authenticates against the vicidial_users table with MD5 password hashing
2. Admin login — Handled by /vicidial/admin.php, authenticates against the vicidial_users table with role-based access control (RBAC)

Both systems validate credentials against the same user database but enforce different permission levels. The authentication flow checks:

• User existence in vicidial_users
• Password hash match (MD5 in most installations, though some use SHA-256)
• User status (active vs. inactive)
• User group permissions
• IP whitelist rules (if configured)

Common Causes of "Login Incorrect" Errors

Password Hash Mismatches

The most frequent cause is an incorrect password hash stored in the database. ViciDial's default password hashing uses MD5, but some installations have been upgraded to use SHA-256 or bcrypt.

Database Sync Issues

In clustered ViciDial setups, database replication lag can cause authentication failures on secondary nodes while working on the primary.

Corrupted User Records

Missing or malformed entries in the vicidial_users table prevent proper authentication.

PHP Session Configuration

Incorrect PHP session settings, disabled extensions, or permission issues on session storage directories cause failures.

IP Whitelist Blocking

ViciDial can restrict logins by IP address. An overly restrictive whitelist blocks legitimate agents.

Asterisk User Correlation Issues

The agent user must exist in both vicidial_users and the Asterisk sip.conf or extensions.conf for full functionality.

Section 1: Verify User Existence in the Database

The first diagnostic step is confirming the user exists and is properly configured.

Query the vicidial_users Table

Connect to the asterisk database and retrieve the user record:

mysql -u root -p asterisk

SELECT user_id, user_name, user_pass, user_email, full_name, user_level, 
       user_group, active, user_phone FROM vicidial_users 
WHERE user_name = 'agentname' LIMIT 1\G

Expected output should show the user with active = 'Y'. Note the exact password hash value — you'll use this for validation.

Verify User Status and Permissions

SELECT user_id, user_name, user_level, user_group, active, 
       closer_login_allowed, lead_search_enabled 
FROM vicidial_users 
WHERE user_name = 'agentname'\G

Ensure:

• active = 'Y' (not 'N' or NULL)
• user_level is appropriate (1-9, where 1 is admin, 9 is agent-only)
• user_group exists and is not NULL
• closer_login_allowed = 'Y' for agents attempting to log in

Check for Duplicate Users

Duplicate usernames cause authentication confusion:

SELECT user_name, COUNT(*) as count 
FROM vicidial_users 
GROUP BY user_name 
HAVING count > 1;

If duplicates exist, delete the obsolete record:

DELETE FROM vicidial_users 
WHERE user_id = (SELECT MIN(user_id) FROM (SELECT user_id FROM vicidial_users WHERE user_name = 'agentname') AS t);

Section 2: Password Hash Validation and Repair

Identify the Password Hashing Algorithm

Check the ViciDial configuration to determine which algorithm is in use:

grep -r "password" /etc/asterisk/vicidial.conf | head -20
grep -r "MD5\|SHA" /usr/share/astguiclient/ | head -10

Look at the actual login script to identify the algorithm:

grep -i "md5\|sha\|hash" /var/www/html/agc/vicidial.php | head -20

Generate an MD5 Hash for Password Reset

If you need to reset an agent's password to a known value, generate the MD5 hash:

echo -n "newpassword123" | md5sum
# Output: 2e99758ae89ac59c117d7aab61d41f18  -

The hash (without the trailing dash) goes into the database.

Update the User Password

UPDATE vicidial_users 
SET user_pass = MD5('newpassword123') 
WHERE user_name = 'agentname';

Verify the update:

SELECT user_name, user_pass FROM vicidial_users WHERE user_name = 'agentname';

Test Password Reset via CLI

Generate a test hash and verify it matches:

php -r "echo md5('testpass'); echo PHP_EOL;"
# Output: 5a105e8b9d40e1329780d62ea2265d8a

Handle SHA-256 Installations

Some modern ViciDial installations use SHA-256. Check for this in the PHP login code:

grep -n "hash\|sha" /var/www/html/agc/vicidial.php | grep -i sha

If SHA-256 is in use, generate the hash:

echo -n "newpassword123" | sha256sum
# Output: 9f86d081884c7d6582ef8f3f00d7e1d7  -

Then update the database:

UPDATE vicidial_users 
SET user_pass = SHA2('newpassword123', 256) 
WHERE user_name = 'agentname';

Section 3: Diagnose Login Script Failures

Enable PHP Error Logging

Edit the PHP configuration to log errors:

sudo nano /etc/php.ini

Ensure these settings are configured:

error_reporting = E_ALL
display_errors = Off
log_errors = On
error_log = /var/log/php-errors.log

Create the log file if it doesn't exist:

sudo touch /var/log/php-errors.log
sudo chown apache:apache /var/log/php-errors.log
sudo chmod 644 /var/log/php-errors.log

Restart Apache:

sudo systemctl restart apache2
# or for CentOS/RHEL:
sudo systemctl restart httpd

Monitor Login Attempts

Tail the Apache error log while attempting login:

sudo tail -f /var/log/apache2/error.log

In another terminal, attempt a login and observe the error output.

Check PHP Session Directory Permissions

ViciDial stores PHP sessions. Verify the directory has correct permissions:

ls -ld /var/lib/php/sessions
# Should output: drwxrwxrwt ... /var/lib/php/sessions

If permissions are wrong:

sudo chmod 1777 /var/lib/php/sessions

Verify MySQL Connectivity from PHP

Create a test script to verify the PHP-to-MySQL connection:

sudo nano /var/www/html/test_db.php

<?php
$db_user = 'root';
$db_pass = 'yourpassword';
$db_host = 'localhost';
$db_name = 'asterisk';

$conn = new mysqli($db_host, $db_user, $db_pass, $db_name);

if ($conn->connect_error) {
    die("Connection failed: " . $conn->connect_error);
}

$result = $conn->query("SELECT user_name, user_pass FROM vicidial_users LIMIT 1");

if ($result->num_rows > 0) {
    while ($row = $result->fetch_assoc()) {
        echo "User: " . $row["user_name"] . " | Pass Hash: " . $row["user_pass"] . "\n";
    }
} else {
    echo "No users found\n";
}

$conn->close();
?>

Access it via browser: http://your-server/test_db.php

Then remove the test file:

sudo rm /var/www/html/test_db.php

Section 4: Check IP Whitelist Restrictions

ViciDial can restrict logins by source IP address. Verify this isn't blocking legitimate agents.

Query IP Restrictions

SELECT vicidial_id, user_id, user_name, ip_address, active 
FROM vicidial_users 
WHERE user_name = 'agentname'\G

Check if there's an IP restriction table:

SHOW TABLES LIKE '%ip%';
SHOW TABLES LIKE '%whitelist%';
SHOW TABLES LIKE '%access%';

Locate IP Whitelist Configuration

grep -r "ip_address\|whitelist" /usr/share/astguiclient/ | grep -v ".git"

Review the Login PHP Script for IP Checks

grep -n "ip\|whitelist\|access" /var/www/html/agc/vicidial.php | head -30

If IP restrictions are enforced, identify the agent's actual IP address from Apache logs:

sudo tail -50 /var/log/apache2/access.log | grep agentname

Look for the IP address in the columns before the timestamp.

Disable or Update IP Restrictions

If the IP whitelist is too restrictive, you can disable it temporarily for testing:

UPDATE vicidial_users 
SET ip_address = '0.0.0.0/0' 
WHERE user_name = 'agentname';

This allows login from any IP. For production, use the agent's actual subnet:

UPDATE vicidial_users 
SET ip_address = '192.168.1.0/24' 
WHERE user_name = 'agentname';

Section 5: Verify Asterisk User Configuration

Agents must exist in both the ViciDial database and the Asterisk SIP configuration.

Check sip-vicidial.conf

Examine the Asterisk SIP configuration:

grep -A 5 "agentname" /etc/asterisk/sip-vicidial.conf

Expected output:

[agentname](vicidial_agent)
type=friend
username=agentname
secret=sippassword

Verify extensions.conf

The agent must be defined in extensions:

grep -B 2 -A 10 "exten => agentname" /etc/asterisk/extensions-vicidial.conf

Reload Asterisk SIP Configuration

If you add or modify a user, reload the SIP module:

sudo asterisk -rx "sip reload"

Verify the user loaded correctly:

sudo asterisk -rx "sip show peer agentname"

Expected output shows the peer details including IP, port, and registration status.

Section 6: Troubleshoot Admin Login Issues

Admin login uses the same database but enforces additional role checks. Address these specific issues:

Verify Admin User Level

Admin users must have user_level between 1-5 (where 1 is superadmin):

SELECT user_name, user_level, user_group, active 
FROM vicidial_users 
WHERE user_level <= 5 
AND user_name = 'adminname'\G

If the user_level is 6 or higher, they're classified as an agent, not admin.

Update User to Admin Level

UPDATE vicidial_users 
SET user_level = 1 
WHERE user_name = 'adminname';

Check Admin-Specific Permissions

SELECT user_name, admin_login_allowed, admin_phonebook, 
       admin_reports, admin_settings, admin_users 
FROM vicidial_users 
WHERE user_name = 'adminname'\G

Ensure admin privilege columns are set to 'Y':

UPDATE vicidial_users 
SET admin_login_allowed = 'Y', 
    admin_reports = 'Y', 
    admin_settings = 'Y', 
    admin_users = 'Y' 
WHERE user_name = 'adminname';

Clear Admin Session Cache

Some ViciDial versions cache admin sessions. Clear this:

sudo rm -rf /tmp/vicidial_*
sudo rm -rf /var/lib/php/sessions/vicidial_*

Then restart Apache:

sudo systemctl restart apache2

Section 7: Database Replication and Sync Issues

In clustered ViciDial deployments, database replication lag can cause authentication failures.

Check Replication Status

On the database slave:

mysql -u root -p -e "SHOW SLAVE STATUS\G"

Look for:

• Slave_IO_Running: Yes
• Slave_SQL_Running: Yes
• Seconds_Behind_Master: 0 (or a small number)

If Seconds_Behind_Master is high, replication is lagging.

Verify Master-Slave Consistency

-- On master:
SHOW MASTER STATUS;

-- On slave:
SHOW SLAVE STATUS;

Compare the File and Position columns. They should match between master and slave after replication catches up.

Force User Sync

If replication is stuck, manually sync the user record:

# Export from master
mysqldump -u root -p asterisk vicidial_users --where="user_name='agentname'" > /tmp/user_export.sql

# Import on slave
mysql -u root -p asterisk < /tmp/user_export.sql

Restart Replication

If replication is broken:

# On slave, as root:
mysql -u root -p -e "STOP SLAVE;"
mysql -u root -p -e "SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;"
mysql -u root -p -e "START SLAVE;"
mysql -u root -p -e "SHOW SLAVE STATUS\G"

Section 8: Check Web Server and PHP Configuration

Verify Apache is Serving ViciDial Correctly

Test the web paths:

curl -I http://localhost/agc/vicidial.php
curl -I http://localhost/vicidial/admin.php

Both should return HTTP 200.

Check PHP Modules

Ensure required PHP modules are loaded:

php -m | grep -E "mysql|mysqli|json|session|zlib"

Missing modules will prevent database access. Install missing extensions:

# Ubuntu/Debian:
sudo apt-get install php-mysql php-json php-zlib

# CentOS/RHEL:
sudo yum install php-mysql php-json php-zlib

Verify ViciDial File Permissions

The web server must read ViciDial files:

ls -la /var/www/html/agc/vicidial.php
# Should show: -rw-r--r-- apache:apache

Fix permissions if needed:

sudo chown -R apache:apache /var/www/html/agc
sudo chown -R apache:apache /var/www/html/vicidial
sudo chmod -R 755 /var/www/html/agc
sudo chmod -R 755 /var/www/html/vicidial

Check Apache Configuration for ViciDial

grep -r "ViciDial\|vicidial" /etc/apache2/sites-enabled/

Ensure the VirtualHost or Directory block includes:

<Directory /var/www/html/agc>
    Options FollowSymLinks
    AllowOverride All
    Require all granted
</Directory>

<Directory /var/www/html/vicidial>
    Options FollowSymLinks
    AllowOverride All
    Require all granted
</Directory>

Section 9: Audit Login Attempt Logs

Find Login Audit Tables

ViciDial logs authentication attempts:

SHOW TABLES LIKE '%log%';
SELECT * FROM vicidial_log LIMIT 5\G

Query recent login failures:

SELECT call_date, user_id, user_name, phone_number, lead_id, status, notes 
FROM vicidial_log 
WHERE user_name = 'agentname' 
AND call_date >= DATE_SUB(NOW(), INTERVAL 1 HOUR) 
ORDER BY call_date DESC LIMIT 20;

Check Asterisk Logs for Authentication Errors

sudo tail -100 /var/log/asterisk/messages | grep -i "auth\|login\|fail\|agentname"

Look for patterns like:

• "Authentication failed"
• "Invalid extension"
• "Connection refused"

Monitor Asterisk in Real-Time

Open Asterisk CLI and monitor events:

sudo asterisk -r

Inside the Asterisk console:

*CLI> sip set debug on
*CLI> core set verbose 3

Attempt login and watch for SIP errors. Exit with:

*CLI> exit

Section 10: Database Repair and Optimization

Repair Corrupted User Records

Run a database check:

CHECK TABLE vicidial_users;
REPAIR TABLE vicidial_users;

If corruption is found, rebuild the table:

ALTER TABLE vicidial_users ENGINE=InnoDB;

Verify Data Integrity

Ensure no NULL values in critical fields:

SELECT * FROM vicidial_users 
WHERE user_name IS NULL 
OR user_pass IS NULL 
OR user_level IS NULL;

If results are found, delete those rows:

DELETE FROM vicidial_users 
WHERE user_name IS NULL 
OR user_pass IS NULL 
OR user_level IS NULL;

Optimize the Table

After repairs, optimize:

OPTIMIZE TABLE vicidial_users;

Troubleshooting

Agent Login Works on One Server but Not Another

Symptom: Agent successfully logs in via Server A but gets "login incorrect" on Server B.

Diagnosis:

• Database replication lag on Server B
• Different PHP configuration between servers
• Mismatched password hashing algorithms

Solution:

# Verify database sync on Server B
mysql -u root -p -e "SELECT COUNT(*) FROM vicidial_users;"

# Compare with Server A
# If different, force sync:
mysqldump -u root -p asterisk vicidial_users | mysql -u root -p -h serverB asterisk

"Login Incorrect" Despite Correct Password

Symptom: User enters correct password but receives "login incorrect".

Diagnosis:

• Password hash algorithm mismatch
• Corrupted user record in database
• PHP session cache corruption

Solution:

# Reset password with known hash
echo -n "testpassword" | md5sum
# Use the output hash:
mysql -u root -p asterisk -e "UPDATE vicidial_users SET user_pass=MD5('testpassword') WHERE user_name='agentname';"

# Clear session cache
sudo rm -rf /var/lib/php/sessions/*
sudo systemctl restart apache2

Admin Login Fails but Agent Login Works

Symptom: Admin cannot log in to /vicidial/admin.php but agents use /agc/vicidial.php successfully.

Diagnosis:

• Admin user lacks proper role/permissions
• Admin login script specific error
• Admin IP whitelist is too restrictive

Solution:

UPDATE vicidial_users 
SET user_level = 1, 
    admin_login_allowed = 'Y', 
    ip_address = '0.0.0.0/0' 
WHERE user_name = 'adminname';

Then test:

# Check for admin-specific errors
sudo tail -50 /var/log/apache2/error.log | grep -i admin

Login Works from Office Network but Fails from Home

Symptom: Agent logs in successfully from office but gets "login incorrect" from home IP.

Diagnosis:

• IP whitelist is blocking home IP address

Solution:

# Find agent's home IP from browser
# Add it to the whitelist:
mysql -u root -p asterisk -e "UPDATE vicidial_users SET ip_address='192.168.0.0/16,203.0.113.100' WHERE user_name='agentname';"

# Or disable IP whitelist for testing:
mysql -u root -p asterisk -e "UPDATE vicidial_users SET ip_address='' WHERE user_name='agentname';"

Password Hash Length Mismatch

Symptom: Password hash in database is wrong length (e.g., 32 chars for SHA-256).

Diagnosis:

• Password was hashed with different algorithm than what login expects

Solution:

# Check current hash length and algorithm
mysql -u root -p asterisk -e "SELECT user_name, LENGTH(user_pass) FROM vicidial_users LIMIT 5;"

# If MD5 (32 chars), regenerate:
mysql -u root -p asterisk -e "UPDATE vicidial_users SET user_pass=MD5('newpass') WHERE user_name='agentname';"

# If SHA-256 (64 chars):
mysql -u root -p asterisk -e "UPDATE vicidial_users SET user_pass=SHA2('newpass', 256) WHERE user_name='agentname';"

Multiple Failed Login Attempts Lock Account

Symptom: After several failed logins, account becomes locked.

Diagnosis:

• ViciDial has login attempt limiting enabled
• Account lockout table stores failed attempts

Solution:

-- Check for lockout table
SHOW TABLES LIKE '%lockout%';
SHOW TABLES LIKE '%attempt%';

-- Query failed attempts
SELECT * FROM vicidial_user_lock WHERE user_name = 'agentname';

-- Clear lockout
DELETE FROM vicidial_user_lock WHERE user_name = 'agentname';

-- Or reset via ViciDial config (check settings):
grep -i "lockout\|max_attempt" /etc/asterisk/vicidial.conf

Case Sensitivity in Usernames

Symptom: "agentname" and "AgentName" are treated as different users.

Diagnosis:

• Database has case-sensitive username collation

Solution:

-- Check collation
SHOW CREATE TABLE vicidial_users\G

-- If case-sensitive, standardize to lowercase:
UPDATE vicidial_users SET user_name = LOWER(user_name);

-- Change collation to case-insensitive
ALTER TABLE vicidial_users MODIFY user_name VARCHAR(20) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

Summary

ViciDial "login incorrect" errors stem from misaligned database records, password hash issues, or web server configuration problems. Systematically verify:

1. User existence — Confirm the user exists in vicidial_users with active = 'Y'
2. Password hash — Verify the hash matches the authentication algorithm (MD5 or SHA-256)
3. User permissions — Ensure user_level, user_group, and role permissions are correct
4. Database sync — Check that replication is current in clustered deployments
5. IP restrictions — Confirm the agent's IP isn't blocked by whitelist rules
6. Asterisk correlation — Verify the user exists in SIP configuration for agent logins
7. Web server — Validate PHP modules, file permissions, and Apache configuration
8. Session handling — Ensure PHP session directory permissions are correct

Use the database queries and CLI commands provided to diagnose issues quickly. When in doubt, reset the password with a known hash, clear the PHP session cache, and restart Apache. For production systems, always test changes on a non-critical agent account first, maintain database backups, and log all authentication modifications for audit compliance.