Failed to authenticate & Unable to synchronize login time

Question

buckster Author

Level 4

2,819 points

Failed to authenticate & Unable to synchronize login time

Hi,

My OSX clients are bound to OSX Server.

Most clients are 10.8, some are 10.9.

Server is 10.10, recently migrated from 10.6.8.

Most clients can log in to the user accounts in good order.

However I have a couple of clients that cannot log in (they both happen to be 10.9 clients).

The login box just shakes when credentials for any network user are enetered.

When this happens the systme.log on client shows:

Oct 30 09:33:24 imac1252 SecurityAgent[166]: User info context values set for userxyz

Oct 30 09:33:25 imac1252 authorizationhost[182]: Failed to authenticate user <xyz> (error: 9).

The system.log on 10.10 server shows:

DSUpdateLoginStatus: Unable to synchronize login time for userxyz: 77009

I have checked the time and time zones on server and client and they are identical.

Does anyone have any guidance, please?

Thanks,

b.

OS X Yosemite (10.10)

Posted on Oct 30, 2014 7:32 AM

Reply

Answer 1

buckster Author

Level 4

2,819 points

Nov 7, 2014 6:18 AM in response to buckster

I spent some hours with Apple Support on this.

Apple Support logged into my server, had me do some testing from different clients with them watching, detroyed & rebuilt OD database, tested with a brand new fresh OD database, uploaded some files for analysis, etc.

The problem is...

Looking back 8 years or so, my mobile user accunts were created on server 10.6 (or maybe even 10.4 can't remember that far back 🙂 )

OSX server (back then) did not require or even have have a certiftcate for these accounts.

Jumping forward to today...

Server 4 on 10.10 requires a certificate for 10.9 clients (and above). But my my OD database (created years ago) does not have a certificate for the accounts to use, and they would not know anything about it even if I created one.

So, support tell me the only option to get things working again is to destroy and rebuild the OD database. I can keep Users, Groups etc, by exporting, but I will need to recreate all passwords.

I will do that in due course.

In the meantime my workaround is to have 10.9 users disconnect from network at the time they enter their login password. They can reconnect as soon as they hit 'return'.

b.

Reply

Answer 2

dmltv

Level 1

10 points

Feb 12, 2015 10:20 AM in response to buckster

I have the same issue. Wonder how you are doing currently.

- I have already rebuilt the OD after upgrading from 10.8 to Yosemite.

- I have set my OD server to be the NTP master for all local machines

- I have set the time server on all clients to server.local (the hostname of the server)

I manage to get stuff working usually but this is becoming a daily routine where the people depending on the server can't do their work.

I have posted in several topics but all suggestions so far have not lead to the desired results.

Reply

Answer 3

buckster Author

Level 4

2,819 points

Feb 12, 2015 11:37 AM in response to dmltv

Hi,

I am working OK, but I had to 'bite the bullet' of destroying/rebuilding OD.

These are the steps I took:

1. Backup OD, and Users & Groups

2. Export Users (except DIRADMIN)

3. Export Groups (except WORKGROUP)

4. Destroy OD database

5. Create new OD database

6. Create new OD database, with new DIRADMIN user

7. Import Users

8. Import Groups

9. Reset passwords

10. Restart server

11. Unbind clients, restart clients, rebind clients

FWIW, even after rebuilding OD I still get a lot of the following error on the server system log:

DSUpdateLoginStatus: Unable to synchronize login time for userxyz: 77009

But it seems harmless.

Hth,

b.

Reply

Answer 4

dmltv

Level 1

10 points

Feb 12, 2015 11:41 AM in response to buckster

Anyone know if running it through wi-fi might be the cause of the problems? Problems seem a bit random, as at times it's the notification "you currently can't login to this user account" or the "OS X needs to repair your library, enter admin password" when they do get to log in. I've managed to minimize the issues by using NTP local master/slave configuration. I might try your solution after all else fails. thanks.

Reply

Answer 5

buckster Author

Level 4

2,819 points

Feb 12, 2015 11:55 AM in response to dmltv

My problem was very consistent, rather than random.

10.9 and 10.10 clients could never log in unless their network cables were removed before clicking to login. Same if they were laptops on WiFI.

I did not see errors like those you mention.

I suggest that destroying/rebuilding OD will not fix your problem, especially since you mention you built your OD Under 10.8.

Another temporary workaround we employed was to remove the OD Server from Directory Utility. This allowed the users to log in, but obviously any password changes on the server were not reflected locally.

hth,

b.

Reply

Answer 6

Aug 31, 2015 7:25 PM in response to buckster

This is exactly, what I had to do. I have now bound my Yosemite iMac (10.10.5) to my Yosemite Xserve (10.10.5). The iMac uses network home folders with network users in an Open Directory Master domain hosted on the Xserve.

However, I have no idea, how the Open Directory Master I wound up having to destroy got corrupted. One post had recommended to rekerberize the server (“If a network user can’t be created after you upgrade or migrate to OS X Server”), and doing that on the previous Open Directory Master produced this error:

2015-08-31 22:13:00 +0000 Error synchronizing removal of attribute draft-krbPrincipalACL from record deb8bdb6-4c3e-11e5-9be3-002436f3b8c2: 77013 result: 16 No such attribute

I then ran the series of commands from Apple’s article “If a network user can’t be created after you upgrade or migrate to OS X Server” again, and the above error went away. This indicated to me that the rekerberization had been successful. Obviously, something else had been amiss, but I’ll never know, what it was.

Reply

Answer 7

Jul 14, 2016 2:57 AM in response to buckster

Hi Buckster,

Maybe your issue is solved now but, here's what worked out for me.

I had to put to connection to LDAP in ssl mode, in the workstation login options.

Step-by-step:

- Login with a local admin user

- Go to System Prefs, Users and Groups, unlock the padlock, Options, edit the Network Account Server, Open Directory Utility, double-click on LDAPv3, check the SSL checkbox.

- Log out and log in as network / mobile user

Hope this will help...

Have fun.

Reply