Home › Forums › OS X Server and Client Discussion › Open Directory › Open Directory issue with MS-CHAPv2 via VPN – could be a bug?

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
    Posts
  • July 28, 2008 at 5:29 pm #373532
    iain
    Participant

    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.

    September 23, 2008 at 4:41 pm #374221
    iain
    Participant

    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.

    October 7, 2008 at 10:51 pm #374394
    iain
    Participant

    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.

    October 10, 2008 at 3:03 am #374427
    wstrucke
    Participant

    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
Viewing 4 posts - 1 through 4 (of 4 total)
  • You must be logged in to reply to this topic.

Comments are closed

Copyright © 2025 AFP548. All Rights Reserved.