Yes, I do believe this is the bug in question. I did find this yesterday and noticed that while the problem may not happen 100% of the time, There are reports of it still happening. Even as late as version 3.5.10.. I am planning on adding my incident to the list... Thanks Much, Robert ________________________________________ From: freeradius-users-bounces+robert.roll=utah.edu@lists.freeradius.org [freeradius-users-bounces+robert.roll=utah.edu@lists.freeradius.org] on behalf of Phil Mayers [p.mayers@imperial.ac.uk] Sent: Monday, July 30, 2012 10:11 AM To: freeradius-users@lists.freeradius.org Subject: Re: Invalid Authenticator... i.e. "munged" nt-key from Winbindd ... On 30/07/12 16:14, Robert Roll wrote:
This is in regards to the "munged" nt-key bug in Winbindd. Most of
Are you referring to this bug: https://bugzilla.samba.org/show_bug.cgi?id=6563 It looks to me like that bug has fallen into the weeds after being thought fixed. My advice would be to post on the Samba mailing list, and see if you can get someone interested.
to go back to Samba 3.2.X'ish ? Well we are(were) running Samba 3.5.6. I figured that was relatively safe? Actually, I had noticed that the bug did still seem to exist, but would only occur after running Winbindd for a "while". I found other admins on the net reporting the same thing. We all seemed to adopt the same solution. Simply re-start Winbindd when the problem arose.
This scheme worked very well for over a year. Then around 16:40 last Friday afternoon, something in our environment changed and this "bug" seemed to get tweaked all of the time. The radius servers just seemed to start to melt down. Actually, after a few hours 4 of 10 of our backend servers seemed to find a somewhat "stable" situation.
For what it's worth, we're running Samba 3.5.4 (RHEL5 package samba3x-3.5.4-0.70.el5) on Win2k8R2 DCs, and have no problems. Have you spoken to your AD admins? It seems likely some event (AD controller rebooting for patches?) triggered it. If you can figure out how to reproduce it, you can gather detailed debugging and hopefully solve the problem. Hell, if you can figure out how to reproduce it, *I* will crack out GDB and take a look.
After all said above, my real question is, has anybody seen anything somewhat definitive on this bug that would indicate the source of the problem has really been found and fixed ? Or, does it just seem that other changes to Winbindd have just "seemed" to make this bug go away (or hide better) ?
I know it's not what you want to hear, but this really *is* a Samba problem. Active Directory is, fundamentally, a closed system. You can only access it with the interfaces Microsoft makes available. Those interfaces are poorly documented, and have undesirable failure characteristics in the very best case.
However, I'm not sure, but some EKG devices in the future might start using this to actually ship the EKG results in real time to a doctor that is actually remotely located. This and other potential real time uses start to scare me a bit ??? I know that these devices should have some other backup capabilities for transmitting the data, but......
I'm sympathetic to your concerns but honestly, if you have a requirement for that level of reliability, my advice would be to abandon Active Directory for those credentials. It is relatively simple to store some credentials in a local users file or SQL database, and disable ntlm_auth for those users e.g. med-device-123 Cleartext-Password := "foo", MS-CHAP-Use-NTLM-Auth := 0 ...or equivalent in SQL. As well as being a lot more reliable, this approach has some other advantages - you don't necessarily want to use a "real" username for this kinds of embedded systems, and provisioning an AD account for them runs the risk of that account being given privileges it shouldn't have. If your local policy permits, and you can justify it, you could even do this will all users (use a password change policy DLL to capture all passwords to a database, optionally NT-hashed). But I doubt that's tenable. Alternatives include using EAP-TLS with client certs (horrible PKI mess) or EAP-TTLS/PAP and use a simpler method than ntlm_auth to check the PAP. In theory, EAP-TEAP (formerly EAP-FASTv2) with tickets on the client would solve this, but I see no realistic possibility of that appearing in client devices any time soon :o( Cheers, Phil - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html