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

[Phil Mayers]

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