Samba AD Password Replication Issue
A Samba server is configured as a domain member in an Active Directory environment. Users report that after changing their password on a Windows client, they cannot authenticate to Samba shares. The Samba server is using winbind and the 'idmap_ad' backend. What is the most likely cause?
Quick Answer
The answer is that password changes are not replicating to the domain controller Samba authenticates against. This is the most likely cause because in an Active Directory environment, a password change is first written to the specific domain controller that processed the request from the Windows client. Samba, configured as a domain member using winbind and the idmap_ad backend, authenticates against a particular DC; if that DC has not yet received the replicated password update due to replication latency, authentication to Samba shares will fail. On the LPIC-2 exam, this scenario tests your understanding of AD replication mechanics versus local authentication, often appearing as a trap where candidates mistakenly blame winbind configuration or time skew. Remember the key insight: Samba does not see the password change until the DC it queries has the updated hash. Memory tip: “Password first, then propagate—Samba waits for the copy.”
⚠ Common exam trap
Many exam-takers assume the issue is with local caching or ID mapping backends, when in fact the root cause is the asynchronous replication of password changes between domain controllers in a multi-DC environment.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Password changes are not replicated to the domain controller that Samba authenticates against
In an Active Directory domain member configuration, Samba authenticates against a specific domain controller (DC). When a user changes their password on a Windows client, the new password is initially written to the DC that processed the change. If the Samba server's winbind service is authenticating against a different DC that has not yet received the replicated password update, authentication will fail. This is the most likely cause because password replication in AD is not instantaneous and depends on replication latency.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The 'winbind offline logon' option is not enabled
Why it's wrong here
Offline logon allows cached credentials, not related to password changes.
- ✓
Password changes are not replicated to the domain controller that Samba authenticates against
Why this is correct
If the DC contacted hasn't received the updated password, authentication fails.
- ✗
The winbind cache is outdated and needs to be cleared
Why it's wrong here
Clearing cache might help if there are stale entries, but the core issue is replication.
- ✗
The 'idmap backend' must be set to 'rid' instead of 'ad'
Why it's wrong here
Changing backend would require reconfiguration but not fix replication lag.
Go deeper
Related to this question
About these practice questions
Courseiva writes every LPIC-2 question from scratch — 507 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
1 more way this is tested on LPIC-2
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. A Samba server is configured with 'security = ads' and joined to an Active Directory domain. Users can authenticate but cannot access shares. The smb.conf includes 'winbind use default domain = yes'. What could be the problem?
hard- A.The 'winbind use default domain' option should be 'no'
- B.The 'idmap backend' is not configured
- C.The Samba server's time is not synchronized with the domain controller
- ✓ D.The 'valid users' parameter uses domain prefix while default domain is set
Why D: When 'winbind use default domain = yes' is set, Winbind strips the domain prefix from usernames, so users authenticate as 'username' instead of 'DOMAIN\username'. If the 'valid users' parameter in a share definition explicitly uses the domain prefix (e.g., 'valid users = DOMAIN\username'), the stripped username will not match, and access is denied. This mismatch is the most direct cause of authentication succeeding but share access failing.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This LPIC-2 practice question is part of Courseiva's free LPI certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the LPIC-2 exam.