user authentication issues with samba4-beta5 as a member server

[Jean Raby]

On 12-09-07 12:31 PM, Jean Raby wrote:
> On 12-09-06 6:02 PM, Andrew Bartlett wrote:
>> On Thu, 2012-09-06 at 09:59 -0400, Jean Raby wrote:
>>> On 12-09-05 7:17 PM, Andrew Bartlett wrote:
>>>>> Alright, I tested this again with beta8 and /usr/sbin/samba won't even
>>>>>> start when configured as a member server.
>>>>>> So I guess the release notes were right;-)
>>>>>>
>>>>>> We've been using samba as a DC along with openchange and sogo and it
>>>>>> works pretty well for our development needs, but we're trying to
>>>>>> find a
>>>>>> way to integrate that with existing domains with a windows DC.
>>>>>>
>>>>>> At first I thought that we'd simply have to join samba as a member
>>>>>> server, but obviously, that won't work for now.
>>>> It is meant to still permit a startup in this situation. Is there any
>>>> chance you could debug the code in source4/smbd/server.c that imposes
>>>> this restriction and work out why if doesn't allow you to start up?
>>> Indeed, samba will start if 'dcerpc endpoint servers' contains
>>> 'mapiproxy'.
>>> It didn't work in my tests since I was using a minimal smb.conf without
>>> this parameter.
>>>
>>> However, I get the same behavior when trying to authenticate a user
>>> using wbinfo -K :
>>
>> Ahh, this is simple. wbinfo -K is unimplemented in the winbind in the
>> 'samba' binary. wbinfo -a should work however.
>
> Unfortunately 'wbinfo -a' doesn't work either.
> I'll dive in with gdb and try to understand what's going on here.
>
> I've also attached the output from samba -d10, maybe that can be useful
> to understand what's wrong.
>
After digging for a while, it looks like the credentials are correctly 
sent to the DC, but it refuses them with 'access denied' as can be seen 
in the netlogon debug log:

09/07 16:13:04 [LOGON] OPENCHANGE: SamLogon: Network logon of 
OPENCHANGE\sogo1 from  (via SOGO) Entered
09/07 16:13:04 [LOGON] OPENCHANGE: SamLogon: Network logon of 
OPENCHANGE\sogo1 from  (via SOGO) Returns 0xC000002

Googling around for that kind of issue turned up some results stating 
that this could happen if the machine doing the auth request (SOGO in 
this case) is not correctly joined to the domain.

So I went ahead and tried 'wbinfo -t' to test the shared secret (which I 
assume is the machine account password?) and that didn't work either.
Here's the netlogon log excerpt:
09/07 16:14:41 [LOGON] OPENCHANGE: SamLogon: Network logon of 
OPENCHANGE\SOGO$ from SOGO (via SOGO) Entered
09/07 16:14:41 [LOGON] OPENCHANGE: SamLogon: Network logon of 
OPENCHANGE\SOGO$ from SOGO (via SOGO) Returns 0xC0000022

Is that expected at this time or should it work?

I've also tested the machine password using wbinfo -a 'sogo$' from a 
samba3 machine joined to the domain and it worked as expected...

-- 
Jean