On 28/08/15 09:20, Volker Lendecke wrote:> On Thu, Aug 27, 2015 at 08:17:15AM +0200, L.P.H. van Belle wrote: >> This was a test on debian Jessie with sernet samba 4.2.3. >> and the test was, "login" with a AD user on ssh. >> this worked, fine, but this i noticed later. > Ok, got more information. But I am still not able to > reproduce it. Unless someone would be willing to give a > developer root login to such a box (which I see as pretty > unlikely) I think I have done what I could and have to leave > this to the real experts like Simo or Andrew Bartlett. > winbind according to all my information seems to spin > somewhere deep in the kinit code. > > Sorry, > > Volker >Hi Volker, it seems pretty easy to reproduce, just throw up a test DC in a VM, create a user and set the password to need to be changed at next login. Now create a member server in another VM and join this to the DC. now open three terminals, ssh into the member server as root from one and start 'top' , ssh into the member server as root from another and finally attempt to ssh into the member server as the user you created from the last one. Now watch the 'top' running in the other terminal, it should show winbind using 100% CPU (or very close to it) at this point go to the open root terminal and run gdb. I can easily reproduce it on an X86_64 machine running Samba Version 4.2.3-SerNet-Debian-7.wheezy I get this from gdb: (gdb) bt #0 0x00007f6449c6cf19 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00007f644ae45e43 in ?? () from /usr/lib/x86_64-linux-gnu/samba/libgse-samba4.so #2 0x00007f644e25fc36 in krb5_get_init_creds_password () from /usr/lib/x86_64-linux-gnu/samba/libkrb5-samba4.so.26 #3 0x00007f644ae460ff in kerberos_kinit_password_ext () from /usr/lib/x86_64-linux-gnu/samba/libgse-samba4.so #4 0x00007f64519fde1d in kerberos_return_pac () #5 0x00007f6451a1cb5f in winbindd_dual_pam_auth () #6 0x00007f6451a319c4 in ?? () #7 0x00007f644f32c741 in ?? () from /usr/lib/x86_64-linux-gnu/samba/libtevent.so.0 #8 0x00007f644f32a9fb in ?? () from /usr/lib/x86_64-linux-gnu/samba/libtevent.so.0 #9 0x00007f644f327381 in _tevent_loop_once () from /usr/lib/x86_64-linux-gnu/samba/libtevent.so.0 #10 0x00007f6451a34a6f in ?? () #11 0x00007f6451a34bd7 in ?? () #12 0x00007f644f327d38 in ?? () from /usr/lib/x86_64-linux-gnu/samba/libtevent.so.0 #13 0x00007f644f327be5 in tevent_common_loop_immediate () from /usr/lib/x86_64-linux-gnu/samba/libtevent.so.0 #14 0x00007f644f32c48a in ?? () ---Type <return> to continue, or q <return> to quit--- from /usr/lib/x86_64-linux-gnu/samba/libtevent.so.0 #15 0x00007f644f32a9fb in ?? () from /usr/lib/x86_64-linux-gnu/samba/libtevent.so.0 #16 0x00007f644f327381 in _tevent_loop_once () from /usr/lib/x86_64-linux-gnu/samba/libtevent.so.0 #17 0x00007f6451a0d319 in main () (gdb) But of course, this is probably me trying to teach my granny to suck eggs :-) Rowland
On Fri, Aug 28, 2015 at 10:29:41AM +0100, Rowland Penny wrote:> On 28/08/15 09:20, Volker Lendecke wrote: > >On Thu, Aug 27, 2015 at 08:17:15AM +0200, L.P.H. van Belle wrote: > >>This was a test on debian Jessie with sernet samba 4.2.3. > >>and the test was, "login" with a AD user on ssh. > >>this worked, fine, but this i noticed later. > >Ok, got more information. But I am still not able to > >reproduce it. Unless someone would be willing to give a > >developer root login to such a box (which I see as pretty > >unlikely) I think I have done what I could and have to leave > >this to the real experts like Simo or Andrew Bartlett. > >winbind according to all my information seems to spin > >somewhere deep in the kinit code. > > > >Sorry, > > > >Volker > > > > Hi Volker, it seems pretty easy to reproduce, just throw up a test > DC in a VM, create a user and set the password to need to be changedI used a S4 DC and did not get samba-tool to set this bit right. S4 did not give the right error message sending heimdal into the endless loop with our kerb_prompter. See my other mail with the patch. Give me a bit to recompile winbind with it and re-test it. Everyone else feel free to also give that patch a try. Volker -- SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen phone: +49-551-370000-0, fax: +49-551-370000-9 AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen http://www.sernet.de, mailto:kontakt at sernet.de
Hi Rowland,> Hi Volker, it seems pretty easy to reproduce, just throw up a test DC in > a VM, create a user and set the password to need to be changed at next > login. Now create a member server in another VM and join this to the DC. > now open three terminals, ssh into the member server as root from one > and start 'top' , ssh into the member server as root from another and > finally attempt to ssh into the member server as the user you created > from the last one. > Now watch the 'top' running in the other terminal, it should show > winbind using 100% CPU (or very close to it) at this point go to the > open root terminal and run gdb. > > I can easily reproduce it on an X86_64 machine running Samba Version > 4.2.3-SerNet-Debian-7.wheezyAs you can easily reproduce this, can you please file a bug report and upload network captures. For the following cases: 1. the original problem 2. with Volkers patch 3. with your changed sshd config It would be perfect if you could also provide a keytab in order to decrypt the krb5 traffic. Looking at captures will likely help in order to judge if Volker's fix is correct/complete related to security. Thanks! metze -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: <http://lists.samba.org/pipermail/samba/attachments/20150828/47822465/signature.sig>
On 28/08/15 15:38, Stefan Metzmacher wrote:> Hi Rowland, > >> Hi Volker, it seems pretty easy to reproduce, just throw up a test DC in >> a VM, create a user and set the password to need to be changed at next >> login. Now create a member server in another VM and join this to the DC. >> now open three terminals, ssh into the member server as root from one >> and start 'top' , ssh into the member server as root from another and >> finally attempt to ssh into the member server as the user you created >> from the last one. >> Now watch the 'top' running in the other terminal, it should show >> winbind using 100% CPU (or very close to it) at this point go to the >> open root terminal and run gdb. >> >> I can easily reproduce it on an X86_64 machine running Samba Version >> 4.2.3-SerNet-Debian-7.wheezy > As you can easily reproduce this, can you please file a bug report > and upload network captures. For the following cases: > > 1. the original problem > 2. with Volkers patch > 3. with your changed sshd config > > It would be perfect if you could also provide a keytab in order to > decrypt the krb5 traffic. > > Looking at captures will likely help in order to judge if Volker's fix > is correct/complete related to security. > > Thanks! > metze >OK, I will go back to what I was doing before Volker's fix popped up and sent me off on a tangent, I was creating a new DC and a client in VM's What I will say is that I didn't use Volkers fix, my reasoning was that 'what if winbind is spinning because it is waiting for the password to be changed and could it actually be a ssh problem'. I found a google result: https://support.software.dell.com/authentication-services/kb/82402 This led to getting prompted for a new password (twice) but still didn't log me in, I examined sshd_config again and found this: #PasswordAuthentication yes I uncommented it, restarted ssh and I could then login I may be some time :-) Rowland