Logins against AD failing in *most* cases. Can see why, but don't*understand* why.

[Meyers, Dan]

>   Given *my* background: I tend to blame everything *other* than
> FreeRADIUS.  If there's a bug, it gets fixed pretty quickly.  That's
> more than you can say for Microsoft.

Finally got it sorted, and it was indeed nothing to do with FreeRADIUS
but was a combination of several factors all related to Samba (posted
here in case anyone else has similar issues in future and thinks it's
FreeRADIUS):

1) We needed to upgrade to a newer version of Samba to be able to talk
to Windows Server 2008 R2 (R2 made some significant changes over
straight 2008, according to our Windows admins, so R1 or straight 2008
might be more lenient) using ntlm_auth (something we did quite early in
the attempt to get it working). We're now on 3.4.3 compiled from source
(3.4.0 in packages for Debian 5.0 didn't seem to work).

2) We needed to change our smb.conf. The config that worked with Server
2003 seems to not work with 2008 R2.

3) (And this was the one that really got me towards the end and caused
me much confusion for the last few days when it sometimes worked and
sometimes didn't): 

You *must* start Samba (i.e. nmbd and smbd) before winbind. If you start
winbind first, then ntlm_auth gives every indication of working
correctly. An ntlm_auth --username=whatever and then giving a password
returns NT_STATUS_OK: Success (0x0). An incorrect password returns
NT_STATUS_WRONG_PASSWORD, so it's evidently talking to the DC OK.
Likewise taking a username, challenge and nt response from a radius
request in debug mode and testing on the command line does return an NT
key like it should. *However* that NT key, which is the same every time
the command is run for a given username, challenge and response, is
*not* the same as the NT key returned for the same username, challenge
and response if you start Samba before winbind. If you start winbind
first, the client will reject the NT key returned. If you start Samba
first, it works fine.

Bit of a noddy error on my part, that one. But if ntlm_auth had actually
given any indication of not being able to talk to the domain I would
have spotted it much sooner. Because all indications were that it was
communicating fine it never occurred to me that the NT key being
returned might be invalid.

Thanks all.