Samba 4 - very long login time on Windows 7

[f***@crackmonkey.us]

Hi list!

I'm happy to report great success with Samba 4 alpha 15 on Ubuntu Lucid
LTS with two Windows 7 Ultimate clients. :D

I notice though that my two workstations are taking ~10 minutes to log
in. On both systems, Event Viewer shows event IDs 6005 and 6006 each
occurring twice during login.

6005 is "The winlogon notification subscriber <x> is taking long time to
handle the notification event (Logon)", where x is Profiles in the
first instance and GPClient in the second on both systems.

6006 is "The winlogon notification subscriber <x> took y second(s) to
handle the notification event (Logon)", where x is Profiles in the
first instance and GPClient in the second on both systems, and y varies
but is around about 90 seconds in the first instance and 300 in the
second.

Do we know how to fix/workaround this? My Google searches suggest it
might be a Windows issue. I should add that I'm not running any login
scripts, and running "gpresult /Z" on both systems returns "the user
does not have RSOP data".

Is there a log file I can check on my Ubuntu DC?

TiA,
Adam J Richardson

[Matthieu Patou]

Post by f***@crackmonkey.us
Hi list!
I'm happy to report great success with Samba 4 alpha 15 on Ubuntu Lucid
LTS with two Windows 7 Ultimate clients. :D
I notice though that my two workstations are taking ~10 minutes to log
in. On both systems, Event Viewer shows event IDs 6005 and 6006 each
occurring twice during login.
6005 is "The winlogon notification subscriber<x> is taking long time to
handle the notification event (Logon)", where x is Profiles in the
first instance and GPClient in the second on both systems.
6006 is "The winlogon notification subscriber<x> took y second(s) to
handle the notification event (Logon)", where x is Profiles in the
first instance and GPClient in the second on both systems, and y varies
but is around about 90 seconds in the first instance and 300 in the
second.

Try to add this
host msdfs = yes in the [default] section of your smb.conf it will
activate the DFS referral support from Samba4 if it didn't help please
provide us tcpdump traces between your s4 server and your client (1 is
sufficient). See http://wiki.samba.org/index.php/Capture_Packets for how
to make a trace.

Matthieu.

[fatman]

On Tue, 18 Jan 2011 17:05:05 -0700

Subject: Re: Samba 4 - very long login time on Windows 7
Date: Tue, 18 Jan 2011 23:29:43 +0300

Post by f***@crackmonkey.us
On both systems, Event Viewer shows event IDs 6005 and 6006
each occurring twice during login.

Try to add this
host msdfs = yes in the [default] section of your smb.conf it will
activate the DFS referral support from Samba4 if it didn't help
please provide us tcpdump traces between your s4 server and your
client (1 is sufficient). See
http://wiki.samba.org/index.php/Capture_Packets for how to make a
trace.
Matthieu.

Thanks Matthieu.

I've added "host msdfs = yes" to the [global] section of my smb.conf,
which I suspect you meant. I tried adding a [default] section and samba
complained when I started it, so I put it in [global] and it didn't
complain again.

I've tried logging out and logging in on one of the workstations. I
tried rebooting and logging in again. No joy - still the 10 minute
login. "host msdfs" doesn't seem to have helped. Unless I need to
reboot the server for some odd reason?

Now I'll get a tcpdump trace.

Regards,
Adam J Richardson

[fatman]

Date: Wed, 19 Jan 2011 22:02:09 +0000
Subject: Re: Samba 4 - very long login time on Windows 7
On Tue, 18 Jan 2011 17:05:05 -0700

Subject: Re: Samba 4 - very long login time on Windows 7
Date: Tue, 18 Jan 2011 23:29:43 +0300

Post by f***@crackmonkey.us
On both systems, Event Viewer shows event IDs 6005 and 6006
each occurring twice during login.

please provide us tcpdump traces between your s4 server and your
client (1 is sufficient).

Now I'll get a tcpdump trace.

I've got a login trace. This time it only took 6 minutes.

I would include a logout trace but I think it synchronised the profile,
which means the logout trace is huge.

I'm hosting the login trace here:
https://dreamtrack.dnsalias.com/downloads/login-trace.7z

Ignore the SSL error.

Regards,
Adam J Richardson

[Matthieu Patou]

Post by fatman

Date: Wed, 19 Jan 2011 22:02:09 +0000
Subject: Re: Samba 4 - very long login time on Windows 7
On Tue, 18 Jan 2011 17:05:05 -0700

Subject: Re: Samba 4 - very long login time on Windows 7
Date: Tue, 18 Jan 2011 23:29:43 +0300

Post by f***@crackmonkey.us
On both systems, Event Viewer shows event IDs 6005 and 6006
each occurring twice during login.

please provide us tcpdump traces between your s4 server and your
client (1 is sufficient).

Now I'll get a tcpdump trace.

I've got a login trace. This time it only took 6 minutes.
I would include a logout trace but I think it synchronised the profile,
which means the logout trace is huge.
https://dreamtrack.dnsalias.com/downloads/login-trace.7z

It seems that you are using roaming profiles, have you made the test
without ?
And also the trace shows no activity on the network between 0:50 to
6:08, do you have anything suspect in the windows logs ?

Also it seems that the trace is not complete, can you make a trace from
the moment when the workstation boot ?

Matthieu.

[Gianni L]

Date: Wed, 19 Jan 2011 22:02:09 +0000

Post by f***@crackmonkey.us
On both systems, Event Viewer shows event IDs 6005 and 6006
each occurring twice during login.

I've got a similar issue with a W7 client on a W2K domain.. there was
a problem with the W2K GPO's I needed to to put the W7 client in a new
OU with a fresh made GPO..

another issue was with samba4 and a WXP client on centos.. but there
the problem was a wrong configured iptables script.. totally my fault
that time..

It seems that you are using roaming profiles, have you made the test without
?

sometimes on roaming profiles the issue could be a non correctly
working folder redirection.. yeah.. I catched users with several gigs
on the desktop.. XD

And also the trace shows no activity on the network between 0:50  to  6:08,
do you have anything suspect in the windows logs ?

this long pause could be a a cause of the firewall setup.. but I'm
really not sure if I am supposing it right

G.

[fatman]

On Fri, 21 Jan 2011 01:15:49 +0300

Post by Matthieu Patou

Post by fatman

Post by f***@crackmonkey.us
On both systems, Event Viewer shows event IDs 6005 and 6006
each occurring twice during login.

please provide us tcpdump traces between your s4 server and your
client (1 is sufficient).

It seems that you are using roaming profiles, have you made the test
without ?

No. I can make a user without a profile. Will that do or do I need
to disable profiles completely?

Post by Matthieu Patou
And also the trace shows no activity on the network between 0:50 to
6:08, do you have anything suspect in the windows logs ?

The only suspect thing in the Windows logs is events 6005 and 6006, as
mentioned previously. It's almost as if the login halts completely
between each 6005/6006 pair.

Post by Matthieu Patou
Also it seems that the trace is not complete, can you make a trace
from the moment when the workstation boot ?

That's right, I only started the log when the client was at the login
screen. I'll get a new one from boot this time.

Btw, the command I'm using is "sudo tcpdump -p -s 0
-w /root/file.pcap port 445 or port 139 -i eth0", which is almost
per the page you linked, except that I had to specify the interface
as it didn't work without.

-----

Post by Matthieu Patou

Post by fatman
https://dreamtrack.dnsalias.com/downloads/login-trace.7z

This time it contains a trace from boot plus Windows event log, once
with a profile and once without (because I logged in the wrong user
first time :P). I've included the event log in various formats since I
don't know which will be most useful.

Regards,
Adam J Richardson

[Andrew Bartlett]

Post by fatman
On Fri, 21 Jan 2011 01:15:49 +0300

Post by Matthieu Patou

Post by f***@crackmonkey.us
On both systems, Event Viewer shows event IDs 6005 and 6006
each occurring twice during login.

please provide us tcpdump traces between your s4 server and your
client (1 is sufficient).

It seems that you are using roaming profiles, have you made the test
without ?

No. I can make a user without a profile. Will that do or do I need
to disable profiles completely?

Post by Matthieu Patou
And also the trace shows no activity on the network between 0:50 to
6:08, do you have anything suspect in the windows logs ?

The only suspect thing in the Windows logs is events 6005 and 6006, as
mentioned previously. It's almost as if the login halts completely
between each 6005/6006 pair.

Post by Matthieu Patou
Also it seems that the trace is not complete, can you make a trace
from the moment when the workstation boot ?

That's right, I only started the log when the client was at the login
screen. I'll get a new one from boot this time.
Btw, the command I'm using is "sudo tcpdump -p -s 0
-w /root/file.pcap port 445 or port 139 -i eth0", which is almost
per the page you linked, except that I had to specify the interface
as it didn't work without.

Please don't restrict the ports. AD logon uses more protocols than
that.

ie, the examples under 'If you're sure the problem is only related to
SMB, you can filter the traffic based on the ports:' does not apply to
use of Samba4.

Andrew Bartlett

[fatman]

On Mon, 24 Jan 2011 10:45:06 +1000

Post by Andrew Bartlett

Post by fatman
Btw, the command I'm using is "sudo tcpdump -p -s 0
-w /root/file.pcap port 445 or port 139 -i eth0", which is almost
per the page you linked, except that I had to specify the interface
as it didn't work without.

Please don't restrict the ports. AD logon uses more protocols than
that.
ie, the examples under 'If you're sure the problem is only related to
SMB, you can filter the traffic based on the ports:' does not apply to
use of Samba4.

Whoops. Heh. It's late, and I don't think/read straight at this time of
night. I'll get a new trace tomorrow.

Regards,
Adam J Richardson

[fatman]

On Mon, 24 Jan 2011 10:45:06 +1000

Post by Andrew Bartlett

Post by fatman
On Fri, 21 Jan 2011 01:15:49 +0300

Post by Matthieu Patou

Post by f***@crackmonkey.us
On both systems, Event Viewer shows event IDs 6005 and 6006
each occurring twice during login.

please provide us tcpdump traces between your s4 server and
your client (1 is sufficient).

It seems that you are using roaming profiles, have you made the
test without ?

No. I can make a user without a profile. Will that do or do I need
to disable profiles completely?

Post by Matthieu Patou
And also the trace shows no activity on the network between 0:50
to 6:08, do you have anything suspect in the windows logs ?

The only suspect thing in the Windows logs is events 6005 and 6006,
as mentioned previously. It's almost as if the login halts
completely between each 6005/6006 pair.

Post by Matthieu Patou
Also it seems that the trace is not complete, can you make a trace
from the moment when the workstation boot ?

That's right, I only started the log when the client was at the
login screen. I'll get a new one from boot this time.
Btw, the command I'm using is "sudo tcpdump -p -s 0
-w /root/file.pcap port 445 or port 139 -i eth0", which is almost
per the page you linked, except that I had to specify the interface
as it didn't work without.

Please don't restrict the ports. AD logon uses more protocols than
that.
ie, the examples under 'If you're sure the problem is only related to
SMB, you can filter the traffic based on the ports:' does not apply to
use of Samba4.
Andrew Bartlett

Sorry this took so long.

I've put a new trace at the usual location:
https://dreamtrack.dnsalias.com/downloads/login-trace.7z

This one is a full trace from boot, using a user without profile, event
log included, and not restricting any ports. You'll have to filter out
my SSH and web traffic, not that there's much of either. The command I
used was "sudo tcpdump -p -s 0 -w /root/file.pcap -i eth0".

Hope I didn't forget anything this time. ;)

Regards,
Adam J Richardson

[fatman]

Post by fatman
https://dreamtrack.dnsalias.com/downloads/login-trace.7z
This one is a full trace from boot, using a user without profile,
event log included, and not restricting any ports. You'll have to
filter out my SSH and web traffic, not that there's much of either.
The command I used was "sudo tcpdump -p -s 0 -w /root/file.pcap -i
eth0".

Hi guys. Any joy with this?

I can do another trace if required.

Regards,
Adam J Richardson