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)
I have the same problem with 3.5.4. Simply downgrading to 3.4.8 results in the problem going away.
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.
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.
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.
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
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).
or is "demo" a trusted domain with an interdomain trust relationship to "STUD" ?
(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.
(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.
(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
I saw the same issue on 64 bit machines and heards reports that it works fine on 32 bit setups.
(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.
(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
> > 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.
> 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
(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.
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
(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.
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.
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
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
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