DEV Community

Moisi Trungu
Moisi Trungu

Posted on • Originally published at flixzone.icu

ViciDial Login Incorrect Error — Fix Agent & Admin Auth Failures

#devops #linux #sip #voip

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode 
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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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;
Enter fullscreen mode Exit fullscreen mode

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);
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Look at the actual login script to identify the algorithm:

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

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  -
Enter fullscreen mode Exit fullscreen mode

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';
Enter fullscreen mode Exit fullscreen mode

Verify the update:

SELECT user_name, user_pass FROM vicidial_users WHERE user_name = 'agentname';
Enter fullscreen mode Exit fullscreen mode

Test Password Reset via CLI

Generate a test hash and verify it matches:

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

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
Enter fullscreen mode Exit fullscreen mode

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

echo -n "newpassword123" | sha256sum
# Output: 9f86d081884c7d6582ef8f3f00d7e1d7  -
Enter fullscreen mode Exit fullscreen mode

Then update the database:

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

Section 3: Diagnose Login Script Failures

Enable PHP Error Logging

Edit the PHP configuration to log errors:

sudo nano /etc/php.ini
Enter fullscreen mode Exit fullscreen mode

Ensure these settings are configured:

error_reporting = E_ALL
display_errors = Off
log_errors = On
error_log = /var/log/php-errors.log
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Restart Apache:

sudo systemctl restart apache2
# or for CentOS/RHEL:
sudo systemctl restart httpd
Enter fullscreen mode Exit fullscreen mode

Monitor Login Attempts

Tail the Apache error log while attempting login:

sudo tail -f /var/log/apache2/error.log
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

If permissions are wrong:

sudo chmod 1777 /var/lib/php/sessions
Enter fullscreen mode Exit fullscreen mode

Verify MySQL Connectivity from PHP

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

sudo nano /var/www/html/test_db.php
Enter fullscreen mode Exit fullscreen mode 
<?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();
?>
Enter fullscreen mode Exit fullscreen mode

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

Then remove the test file:

sudo rm /var/www/html/test_db.php
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Check if there's an IP restriction table:

SHOW TABLES LIKE '%ip%';
SHOW TABLES LIKE '%whitelist%';
SHOW TABLES LIKE '%access%';
Enter fullscreen mode Exit fullscreen mode

Locate IP Whitelist Configuration 

grep -r "ip_address\|whitelist" /usr/share/astguiclient/ | grep -v ".git"
Enter fullscreen mode Exit fullscreen mode

Review the Login PHP Script for IP Checks 

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

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
Enter fullscreen mode Exit fullscreen mode

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';
Enter fullscreen mode Exit fullscreen mode

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';
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Expected output:

[agentname](vicidial_agent)
type=friend
username=agentname
secret=sippassword
Enter fullscreen mode Exit fullscreen mode

Verify extensions.conf

The agent must be defined in extensions:

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

Reload Asterisk SIP Configuration

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

sudo asterisk -rx "sip reload"
Enter fullscreen mode Exit fullscreen mode

Verify the user loaded correctly:

sudo asterisk -rx "sip show peer agentname"
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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';
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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';
Enter fullscreen mode Exit fullscreen mode

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_*
Enter fullscreen mode Exit fullscreen mode

Then restart Apache:

sudo systemctl restart apache2
Enter fullscreen mode Exit fullscreen mode

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"
Enter fullscreen mode Exit fullscreen mode

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;
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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"
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Both should return HTTP 200.

Check PHP Modules

Ensure required PHP modules are loaded:

php -m | grep -E "mysql|mysqli|json|session|zlib"
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Check Apache Configuration for ViciDial 

grep -r "ViciDial\|vicidial" /etc/apache2/sites-enabled/
Enter fullscreen mode Exit fullscreen mode

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>
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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;
Enter fullscreen mode Exit fullscreen mode

Check Asterisk Logs for Authentication Errors 

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

Look for patterns like:

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

Monitor Asterisk in Real-Time

Open Asterisk CLI and monitor events:

sudo asterisk -r
Enter fullscreen mode Exit fullscreen mode

Inside the Asterisk console:

*CLI> sip set debug on
*CLI> core set verbose 3
Enter fullscreen mode Exit fullscreen mode

Attempt login and watch for SIP errors. Exit with:

*CLI> exit
Enter fullscreen mode Exit fullscreen mode

Section 10: Database Repair and Optimization

Repair Corrupted User Records

Run a database check:

CHECK TABLE vicidial_users;
REPAIR TABLE vicidial_users;
Enter fullscreen mode Exit fullscreen mode

If corruption is found, rebuild the table:

ALTER TABLE vicidial_users ENGINE=InnoDB;
Enter fullscreen mode Exit fullscreen mode

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;
Enter fullscreen mode Exit fullscreen mode

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;
Enter fullscreen mode Exit fullscreen mode

Optimize the Table

After repairs, optimize:

OPTIMIZE TABLE vicidial_users;
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

"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
Enter fullscreen mode Exit fullscreen mode

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';
Enter fullscreen mode Exit fullscreen mode

Then test:

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

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';"
Enter fullscreen mode Exit fullscreen mode

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';"
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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;
Enter fullscreen mode Exit fullscreen mode

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.

Top comments (0)