Invalid Authenticator... i.e. "munged" nt-key from Winbindd ...

[Robert Roll]

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 at lists.freeradius.org [freeradius-users-bounces+robert.roll=utah.edu at lists.freeradius.org] on behalf of Phil Mayers [p.mayers at imperial.ac.uk]
Sent: Monday, July 30, 2012 10:11 AM
To: freeradius-users at 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