Skip navigation

Password problem after migrating to Mountain Lion Server

3394 Views 17 Replies Latest reply: Sep 19, 2012 1:16 PM by elgringito RSS
1 2 Previous Next
elgringito Level 1 Level 1 (20 points)
Currently Being Moderated
Aug 16, 2012 8:14 AM

Hello everyone,

 

Yesterday, I migrated our Lion Server to Mountain Lion Server. Everything seemed to work fine. Except since this morning, none of the network user cannot connect to their calendar, reminders, and wiki. They can connect to their account and to their mails. The following line appears multiple times in ApplePasswordServer.Error.log:

 

Aug 16 2012 16:52:50 700250us    client response doesn't match what we generated

 

It seems that only web services are concerned (vpn, mobile accounts, and mails are working). My initial guess is that the hash computed on the basis of the user password is not computed on the same way on the client machine (which is running Mountain Lion by the way) and on the server. On the other hand, this would be very surprising, since all this stuff is based on standards and unlikely to have changed since Lion.


I tried to create a new "Test" user. Even this new user, created after the migration, cannot connect to its calendar, etc. I also tried to reset my user password using the Server App. It makes no difference, the same lines appear in the logs.

 

Is anyone experiencing a similar problem ? Does anyone have a clue of what to try next ?

 

Thanks a lot !

OS X Server, Mountain Lion Server
  • mbresink Calculating status...

    I can only confirm that I have exactly the same problem with one of my Open Directory user accounts. Resetting the password does not change anything. However, all other accounts (with basically the same setup) mysteriously work fine.

     

    This would suggest that something in the password server itself is damaged. Due to total lack of documentation, it's difficult to find out what exactly is going on here.

  • mbresink Level 1 Level 1 (20 points)

    I found out the following:

     

    After looking at the contents of the password server database using the slot numbers of several user accounts, it seems that all users where WEBDAV-DIGEST authentication is failing, have two entries for the digest method "*cmusaslsecretDIGEST". This is obviously wrong. All users who can authenticate successfully have only one such entry.

     

    Deleting and recreating the user account has no effect. In fact, updating the password server with a new entry may actually trigger this error. It could be that all users where this is failing have changed their passwords after the server was updated to Mountain Lion.

     

    It would be interesting to know if you also see duplicate entries for "*cmusaslsecretDIGEST" in the database. You can display a password server record via the user account's slot number (in your example, the 0xd6ace...) using the command

     

    sudo mkpassdb -dump <slot-number>

     

    At the end of the record dump, you should see 10 digest entries with their method identifiers.

  • mbresink Level 1 Level 1 (20 points)

    Hi elgringito,

     

    thanks a lot for your confirmation!

     

    There might have been some slight misunderstanding: The effect you are seeing appears to be exactly the same as mine. The digest 7 is "half empty", but there is another entry for *cmusaslsecretDIGEST at digest 2. This digest might be the correct one, possibly conflicting with the one at 7.

     

    Digests 1, 8, and 9 are always empty for me, and digest 7 is empty for users who didn't change their passwords.

     

    When I fnd some time, I'll try to reproduce this on an empty server and file a bug report with Apple.

  • mbresink Level 1 Level 1 (20 points)

    Unfortunately, this theory did not prove to be correct.

     

    Although it is the case that users who changed their passwords have duplicate cmusaslsecretDIGEST entries, this does not seem to be the cause of the problem.

     

    A "clean" test server also shows the duplicate entries, but WEBDAV-DIGEST authentication is working anyway.

     

    Hm... :-(

  • Kostas B Level 1 Level 1 (90 points)

    Count me in as well, I have the same issue.

     

    Best regards

     

    Kostas

  • mbresink Level 1 Level 1 (20 points)

    I have reproduced this problem on an empty server now. This is definitively a bug in the Mountain Lion Server upgrade procedure.

     

    It seems that in all cases where one of the available authentication mechanisms had been disabled in Lion Server (before the upgrade), WEBDAV-DIGEST authentication will fail in OS X Server on Mountain Lion for all Open Directory user accounts which have either been created after the upgrade, or for which the password has been changed.

     

    Could you either confirm or deny that you had deactivated one of the authentication mechanisms in Lion?

     

    It was common practice to disable unsafe an unneeded mechanisms, recommended by Apple in the administration reference manual.

  • Kostas B Level 1 Level 1 (90 points)

    Thank you for your answer.

     

    I had Snow Leopard before upgrading. However, I can confirm that no new or old OD accounts can use ANY web services (Web sites realms or Profile Manager).

     

     

    Best regards

     

    Kostas

  • felddy Calculating status...

    I too had disabled APOP on Lion Server and am seeing the exact same issues with digest authentications failing after a migration to ML Server.

     

    They say misery loves company, but it is even more reassuring finding an active thread on the path to a solution. 

    If there are any theories I can help explore let me know.  

1 2 Previous Next

Actions

More Like This

  • Retrieving data ...

Bookmarked By (4)

Legend

  • This solved my question - 10 points
  • This helped me - 5 points
This site contains user submitted content, comments and opinions and is for informational purposes only. Apple disclaims any and all liability for the acts, omissions and conduct of any third parties in connection with or related to your use of the site. All postings and use of the content on this site are subject to the Apple Support Communities Terms of Use.