Open Directory issue with MS-CHAPv2 via VPN – could be a bug?

[iain]

Greetings,

We use an OD server (10.5.4) to authenticate two other 10.5.4 servers running the stock VPN. Each provides access to separate portions of the internal net. It has worked flawlessly for months, but this weekend, both vpns stopped authenticating users. There were no errors in the OD logs, except for this repeating message in /var/log/system.log any time someone tried to connect:

Jul 28 09:23:45 (hostname) /usr/sbin/PasswordService[54]: wrong-sized secret 32
Jul 28 09:23:45 (hostname) /usr/sbin/PasswordService[54]: Unexpected State Reached in MS-CHAPv2 plugin

The second we re-entered a user’s password in WGM in OD, they could log in again via VPN.

We also authenticate users via OD for Kerio mail (Kerberos), and this worked fine throughout the problem.

So it seems to be an issue on the OD server, related specifically to authenticating via MS-CHAPv2, or even more specifically, MS-CHAPv2 with the stock VPN server.

Thanks for any help you can provide.

[iain]

It appears that accounts with the hash-only bit set to 1 are the issue. When I do a mkpass -dump on the guid, any user that has problems with radius or ms-chapv2 has this set to 1. It seems like this would be an easy issue to solve, if it did not recur at random times.

Does anyone know what specifically controls this flag? It would be great to be able to fix this problem w/o having to issue a password change for the user each time, to at least make some headway.

[iain]

It seems so far this issue is somehow tied to replication. Removing our OD replicas has prevented the issue from continuing. Specifically, the issue prevented SMB and MS-CHAPv2 authentication, while other auth mechs continued to function.

[wstrucke]

i’ve come to the same conclusion — i have a thread on the macos-x-server mailing list about this issue. on several occasions i have successfully established a directory replica for my directory only to have this problem start occurring immediately. it seems that anything that uses NTLM authentication fails and the passwords become corrupt until they are reset.

the test I’ve found that works 100% to determine if this problem is occuring is:

dirt -u (username)

will succeed with the correct password

dirt -a nt -u (username)

will fail with the correct password

the directory is rock solid without any replicas though so that’s how we’re running for now…

[Author]

Posts