Bug 4622 - authentication always fail with security = server on 3.0.25
authentication always fail with security = server on 3.0.25
Status: RESOLVED FIXED
Product: Samba 3.0
Classification: Unclassified
Component: User/Group Accounts
3.0.25
All All
: P3 normal
: none
Assigned To: Samba Bugzilla Account
Samba QA Contact
:
: 4638 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-05-16 05:19 UTC by WS Chan
Modified: 2007-06-10 20:14 UTC (History)
2 users (show)

See Also:


Attachments
Patch (659 bytes, patch)
2007-05-16 17:50 UTC, Jeremy Allison
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description WS Chan 2007-05-16 05:19:20 UTC
We use security = server to authenticate with an Active Directory server:
security = server
password server = NAME_OF_AD_SERVER
workgroup = DOMAIN_NAME_OF_AD

With 3.0.25, authentication always fails:
[2007/05/16 17:52:30, 2] samba-3.0.25/source/auth/auth.c:check_ntlm_password(319)
  check_ntlm_password:  Authentication for user [wschan] -> [wschan] FAILED with
 error NT_STATUS_NO_SUCH_USER

I compared the log of this version and that of the previous version and noticed the mapped user names are different:
With 3.0.25:
[2007/05/16 17:52:30, 3] samba-3.0.25/source/auth/auth.c:check_ntlm_password(224)
  check_ntlm_password:  mapped user is: [NAME_OF_SMB_SERVER]\[wschan]@[NAME_OF_PC]

With 3.0.23a:
[2007/05/16 17:52:30, 3] samba-3.0.23a/source/auth/auth.c:check_ntlm_password(224)
  check_ntlm_password:  mapped user is: [DOMAIN_NAME_OF_AD]\[wschan]@[NAME_OF_PC]

I guessed authentications had failed because of an incorrect domain name submitted to the AD server. Instead of the DOMAIN_NAME_OF_AD, NAME_OF_SMB_SERVER was submitted by 3.0.25 to the AD server.

Tracing the source code a bit, I found that a difference in the set_server_role function in param/loadparm.c may be the cause:
In 3.0.25:
                case SEC_SERVER:
                        if (lp_domain_logons())
                                DEBUG(0, ("Server's Role (logon server) conflict
s with server-level security\n"));
                        /* this used to be considered ROLE_DOMAIN_MEMBER but tha
t's just wrong */
                        server_role = ROLE_STANDALONE;

In 3.0.23a:
                case SEC_SERVER:
                        if (lp_domain_logons())
                                DEBUG(0, ("Server's Role (logon server) conflict
s with server-level security\n"));
                        server_role = ROLE_DOMAIN_MEMBER;
                        break;

Then I changed that segment of code in param/loadparm.c of 3.0.25 to make it look like that of 3.0.23a. Authentications worked again.
Comment 1 Volker Lendecke 2007-05-16 09:42:25 UTC
Thanks for that hint. But to me it seems that this ROLE_STANDALONE is the right thing at that place, it influences other stuff as well. The fix must be somewhere else.

Looking.

Volker
Comment 2 Jeremy Allison 2007-05-16 17:50:09 UTC
Created attachment 2697 [details]
Patch

This is Volker's patch I'm committing for 3.0.25a.
Jeremy.
Comment 3 WS Chan 2007-05-16 21:00:17 UTC
(In reply to comment #1)
> Thanks for that hint. But to me it seems that this ROLE_STANDALONE is the right
> thing at that place, it influences other stuff as well. The fix must be
> somewhere else.
> 
> Looking.
> 
> Volker
> 

Yes, I worried that too. Instead of changing param/loadparm.c, I did a temporary workaround by patching passdb/passdb.c:
42c42
<       if ( lp_server_role() == ROLE_STANDALONE )
---
>       if ( lp_server_role() == ROLE_STANDALONE && lp_security() != SEC_SERVER )

so that I could continue to try it with Vista in our site.
Comment 4 Gerald (Jerry) Carter 2007-05-18 11:05:42 UTC
*** Bug 4638 has been marked as a duplicate of this bug. ***
Comment 5 Gerald (Jerry) Carter 2007-05-18 11:06:29 UTC
Fixed for 3.0.25a