Bug 7481 - Authentication with winbind running on a DC fails with NT_STATUS_INVALID_HANDLE
Summary: Authentication with winbind running on a DC fails with NT_STATUS_INVALID_HANDLE
Status: RESOLVED WORKSFORME
Alias: None
Product: Samba 3.5
Classification: Unclassified
Component: Winbind (show other bugs)
Version: 3.5.3
Hardware: All Linux
: P3 major
Target Milestone: ---
Assignee: Michael Adam
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-05-31 06:47 UTC by Deyan Stoykov
Modified: 2011-03-27 19:14 UTC (History)
13 users (show)

See Also:


Attachments
Patch (or hack) with fix, indicating a possible cause (863 bytes, patch)
2010-07-21 09:00 UTC, Roel van Meer
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Deyan Stoykov 2010-05-31 06:47:38 UTC
When winbind is running on the DC, authentication through ntlm_auth fails with message "NT_STATUS_INVALID_HANDLE: Invalid handle (0xc0000008)". Member servers are not affected. Authentication against trusted domains is not affected.

Steps to reproduce:

1. Setup a minimum DC configuration. In my case:

        workgroup = STUD
        passdb backend = ldapsam:"ldap://***"
        add machine script = /usr/sbin/smbldap-useradd -w "%u"
        logon script = welcome.vbs
        logon path = \\%L\profiles\manprof
        logon drive = H:
        domain logons = Yes
        domain master = Yes
        wins support = Yes
        ldap admin dn = ***
        ldap group suffix = ou=groups
        ldap machine suffix = ou=machines
        ldap passwd sync = yes
        ldap suffix = dc=stud,dc=ru,dc=acad,dc=bg
        ldap user suffix = ou=people

2. Join, net getlocalsid, etc. 

3. Check NTLM auth.

[root@trident ~]# wbinfo -t
checking the trust secret for domain STUD via RPC calls succeeded

[root@trident ~]# wbinfo -a user1%user1
plaintext password authentication failed
Could not authenticate user user1%user1 with plaintext password
challenge/response password authentication failed
error code was NT_STATUS_INVALID_HANDLE (0xc0000008)
error messsage was: Invalid handle
Could not authenticate user user1 with challenge/response

[root@trident ~]# ntlm_auth --username=user1 --password=user1
NT_STATUS_INVALID_HANDLE: Invalid handle (0xc0000008)
Comment 1 Roel van Meer 2010-07-20 03:58:34 UTC
I have the same problem with 3.5.4. Simply downgrading to 3.4.8 results in the problem going away.
Comment 2 Roel van Meer 2010-07-21 06:29:06 UTC
I think I've partly found the cause for this.

After the auth request of wbinfo, winbindd is trying to contact the domain in winbindd_dual_pam_auth_samlogon(). This domain is internal, so it is always online. However, domain->conn.cli is NULL, so rpc_pipe_open_np(), when it checks for it, returns NT_STATUS_INVALID_HANDLE.

The first version where this fails is 3.5.0.
Comment 3 Roel van Meer 2010-07-21 07:07:09 UTC
I've noticed something that might be related.

First of all, wbinfo --all-domains show two domains: DEMO and BUILTIN.

How to reproduce:
start smbd, nmbd and winbindd
run wbinfo --online-status
run wbinfo -a demo\\user%pass
wait a while
run wbinfo --online-status
run wbinfo -a demo\\user%pass

With 3.5.4 wbinfo --online-status shows both domains as online immediately. The wbinfo -a command fails with NT_STATUS_INVALID_HANDLE.

With 3.4.8, wbinfo -online-status shows BUILTIN as online and DEMO as offline at first. At that point, wbinfo -a fails with NT_STATUS_NO_LOGON_SERVERS. After a while, wbinfo -online-status shows both domains as online, and then wbinfo -a succeeds.

In seems in 3.5.4 the DEMO domain is set as online immediately, while in 3.4.8, some work has to be done for this to happen.
Comment 4 Roel van Meer 2010-07-21 09:00:49 UTC
Created attachment 5856 [details]
Patch (or hack) with fix, indicating a possible cause

This patch fixes the problem for me. Essentially it re-introduces a bit of code that was removed between 3.4.8 and 3.5.4, with some logging that shows its effect.
I'm not sure why the code was removed in the first place, so I can't tell if this is a proper fix or not. Hopefully it's useful.
Comment 5 Roel van Meer 2010-08-19 04:32:11 UTC
Hi all,

I've just tested samba 3.6.0pre1 and the problem does NOT occur with that version. It seems this bug only affects the 3.5.x versions.

Regards,

roel
Comment 6 Guenther Deschner 2010-09-22 15:53:09 UTC
I am not sure I correctly understand this:

Are you saying that wbinfo -a demo\\user%pass with winbindd on a DC works with 3.4.8 ? (neither 3.4.x nor 3.5.x have actually code for this to happen, AFAIK).
Comment 7 Guenther Deschner 2010-09-22 15:55:40 UTC
or is "demo" a trusted domain with an interdomain trust relationship to "STUD" ?
Comment 8 Roel van Meer 2010-09-23 01:54:37 UTC
(In reply to comment #6)
> I am not sure I correctly understand this:
> 
> Are you saying that wbinfo -a demo\\user%pass with winbindd on a DC works with
> 3.4.8 ? (neither 3.4.x nor 3.5.x have actually code for this to happen, AFAIK).

Well, yes, it does with 3.4.8 and 3.6.0pre1, but not with 3.5.x. I'll post a minimal smb.conf in a few minutes.
Comment 9 Roel van Meer 2010-09-23 01:55:50 UTC
(In reply to comment #7)
> or is "demo" a trusted domain with an interdomain trust relationship to "STUD"

No, those are two reports of the same issue; their configs aren't related.

Comment 10 Roel van Meer 2010-09-23 02:19:30 UTC
(In reply to comment #6)
> I am not sure I correctly understand this:
> 
> Are you saying that wbinfo -a demo\\user%pass with winbindd on a DC works with
> 3.4.8 ? (neither 3.4.x nor 3.5.x have actually code for this to happen, AFAIK).

This is a short smb.conf with which I can reproduce it:

[global]
        workgroup = DEMO
        netbios name = SERVER1
        server string = server1
        domain logons = Yes
        os level = 254
        preferred master = Yes
        domain master = Yes
        local master = Yes
        wins support = Yes
        passdb backend = ldapsam:ldap://localhost
        ldap suffix = dc=example,dc=tld
        ldap machine suffix = ou=users
        ldap user suffix = ou=users
        ldap group suffix = ou=Groups
        ldap idmap suffix = ou=Idmap
        ldap admin dn = cn=admin,dc=example,dc=tld
        ldap ssl = No
        idmap backend = ldap:ldap://localhost
        idmap uid = 10000-20000
        idmap gid = 10000-20000


To be precise, with this config both  wbinfo -a demo\\user%pass  and  wbinfo -a user%pass  work with 3.4.x and 3.6.0pre1, but not with 3.5.x. With 3.4.x the output is

root@server1:~# wbinfo -a user%pass
plaintext password authentication succeeded
challenge/response password authentication succeeded

while with 3.5.x the output is

root@server1:~# wbinfo -a user%pass
plaintext password authentication failed
Could not authenticate user user%pass with plaintext password
challenge/response password authentication failed
error code was NT_STATUS_INVALID_HANDLE (0xc0000008)
error messsage was: Invalid handle
Could not authenticate user ad with challenge/response

Regards,

roel
Comment 11 Björn Jacke 2010-10-15 07:34:50 UTC
I saw the same issue on 64 bit machines and heards reports that it works fine on 32 bit setups.
Comment 12 Roel van Meer 2010-10-18 02:47:57 UTC
(In reply to comment #11)
> I saw the same issue on 64 bit machines and heards reports that it works fine
> on 32 bit setups.

I can test this on 32 bit if anyone's interested. Just let me know.
Comment 13 Michael Adam 2010-10-18 03:06:14 UTC
(In reply to comment #12)
> (In reply to comment #11)
> > I saw the same issue on 64 bit machines and heards reports that it works fine
> > on 32 bit setups.
> 
> I can test this on 32 bit if anyone's interested. Just let me know.

Yes, that would be very helpful!

And also one more question:
From the report I take it that the problem exists _only_ for winbindd
running on a DC and authenticating against its own domain, not for
winbindd running on a member server and authenticating against its
own domain.
Is that right?

Thanks - Michael
Comment 14 Roel van Meer 2010-10-18 03:30:30 UTC
> > I can test this on 32 bit if anyone's interested. Just let me know.
> 
> Yes, that would be very helpful!

Just did so with 32-bit samba 3.5.2 and I can reproduce it there as well, so with my setup the problem exists both in 32-bit and 64-bit archs.

> And also one more question:
> From the report I take it that the problem exists _only_ for winbindd
> running on a DC and authenticating against its own domain, not for
> winbindd running on a member server and authenticating against its
> own domain.
> Is that right?

I'm not completely sure, but I'm inclined to agree. I haven't tested winbindd on a member server, so I cannot confirm that the problem does not exist in that setup. I'll see if I can get around to that today.
Comment 15 Roel van Meer 2010-10-18 05:12:28 UTC
> And also one more question:
> From the report I take it that the problem exists _only_ for winbindd
> running on a DC and authenticating against its own domain, not for
> winbindd running on a member server and authenticating against its
> own domain.
> Is that right?

Update - I cannot reproduce it with winbindd running on a domain member, so I think your analysis is correct.

(This was with samba 3.5.4 as member of an NT-style domain with samba as DC).

Regards,

roel
Comment 16 Tamas Pisch 2010-10-18 06:50:20 UTC
(In reply to comment #14)
> Just did so with 32-bit samba 3.5.2 and I can reproduce it there as well, so
> with my setup the problem exists both in 32-bit and 64-bit archs.
> 
I tested it on a 32 bit samba 3.5.6 BDC, and the bug still exists on that.
Comment 17 Michael Adam 2010-10-18 07:06:31 UTC
Thanks folks, for testing.

It seems that there is another unrelated bug with
winbindd on a 64bit member that Björn was referring to.
We still need a reproducer for that.

Cheers - Michael
Comment 18 Gennady G. Marchenko 2010-11-18 10:26:32 UTC
(In reply to comment #16)
> (In reply to comment #14)
> > Just did so with 32-bit samba 3.5.2 and I can reproduce it there as well, so
> > with my setup the problem exists both in 32-bit and 64-bit archs.
> > 
> I tested it on a 32 bit samba 3.5.6 BDC, and the bug still exists on that.
> 

I tested it on a 32b samba too. 3.5.6 BDC, the bug still exists.

I will test it on amd64 for 2 or 3 days.
Comment 19 Wilco Baan Hofman 2011-03-01 10:26:32 UTC
I'm hitting this bug as well. 

I can also confirm that changing is_internal_domain() to only use sid_check_builtin(sid) fixes it, which means there is something wrong with the handling of internal domains.

It worked with 3.4.8, I have not yet tested to see if 3.6.0 fixes it.
Comment 20 Volker Lendecke 2011-03-05 11:51:37 UTC
On Tue, Mar 01, 2011 at 10:26:32AM -0600, samba-bugs@samba.org wrote:
> I can also confirm that changing is_internal_domain() to only use
> sid_check_builtin(sid) fixes it, which means there is something wrong with the
> handling of internal domains.
> 
> It worked with 3.4.8, I have not yet tested to see if 3.6.0 fixes it.

Winbind authenticating the local domain has never been
supported. It has always been flaky, creating deadly
embraces between smbd and winbind all over the place.  With
3.6, winbind includes the complete passdb/samlogon magic
itself, so this will become a supported feature.

Volker
Comment 21 Volker Lendecke 2011-03-05 11:53:21 UTC
Closing as WORKSFORME (just tested with master). Please reopen if it does not work with v3-6-test or 3.6 when it's out.

Volker
Comment 22 SATOH Fumiyasu 2011-03-27 19:14:15 UTC
I found the following workaround on Samba 3.5.6:

1. Create /etc/samba/winbindd.conf as below:

  include = /etc/samba/smb.conf
  [global]
  security = domain
  domain logons = no

2. Start nmbd and smbd:

  # /usr/sbin/nmbd -D
  # /usr/sbin/smbd -D

3. Join winbindd to smbd domain:

  # net rpc join -S localhost -U administrator

4. Start winbindd with /etc/samba/winbindd.conf:

  # /usr/sbin/winbindd -D -s /etc/samba/winbindd.conf

5. Enjoy!

  # /usr/bin/wbinfo -a user%password