Are you using network based accounts?

I had that happen when the binding settings in Directory Utility were not set correctly. Under 'advanced options' we needed 'Create Mobile Account at Login.' This gave the account somewhere to store a keychain. It will also allow a user to login if the workstation is offline.

I agree with @jennifer_unger.

Sorry we are not using network or mobile accounts. Just a local standard account. thanks

Do you modify the Default User Template under ```
/System/Library/User Templates/
``` in your image? Mavericks can be touchy about modifying the keychain there... This thread might help:https://jamfnation.jamfsoftware.com/discussion.html?id=7462

How are you setting up your default user template?

We did not edit the user template.

Have you tried just deleting the login keychain and creating a new one?

Yeah - we tried but it is locked and the admin, user or any password will not open it.
Weird

Did you try to delete it from the Keychain Access App or the Keychian Folder?

You should be able to delete it from the ~/Library/Keychains/ folder with any admin account. After throwing it in the trash restart the system and let the user log back in. This should create the new one and then allow you to empty the trash with the old one in it.

@cherylfletcher, how did you capture your Mavericks image? Are you using an AutoDMG, Composer, or the OS that came with the machine? Depending on how you captured it may be a key in determining this rather odd issue.

We will try your suggestion nwiseman and post soon. Ahambridge - we used an autodmg to capture Mavericks iamge.

How did you package chrome? Did you happen to capture a keychain in the chrome package?

@ssrussell - That is a really good point.
@cherylfletcher - I would check all the packages in composer that you are installing. One of them must have /Library/Keychain/ in it, and you are passing FUT on it corrupting your user keychain.

That is my guess.

+1 to @ssrussell's suggestion, and I believe he and @pblake are on the right track.

Who owns the users files?

find /Users/[username] ! -user [username] -exec ls -al {} ;

Does the user own their own login keychain or is it owned by someone else, eg. root?
Do you also have a com.apple.security.plist file also owned by root in the users home account, for example?

If you open Keychain Access from Utilities and in Preferences select Reset My Default Keychain, does this help? Does this remove the above mentioned files if they existed?

This is happening on any program that uses a keychain. If we go to ~/library the user doesn't have a keychain folder. We made a new base image and are still having the same problems. If we go into the application, utilities, keychain access - it seems to be locked. It also doesn't have a login keychain on the left side where is usually does. It has local items, system and system root. We can not unlock it or anything - passwords we have for user, admin and etc do not work?

Also everytime we login the user, the setting up your mac after login comes up. Everytime the user logs in.

@cherylfletcher - Are you installing anything besides the base image? If you are installing any packages, please list them. I still think one of those packages has something in /Library/Keychains/ and that the package is set to FUT. Meaning it is taking a keychain file and replacing the one in the User Template.

Yes we are installing office and we were filling FUT. We are making a new image again with office on it - we will post our results.

@cherylfletcher - Before you even create the new Office image. Just drop the base image on a machine with no apps. See if you can login and have no keychain issue. If you can, then you have just proved the Office is the culprit. If you still have the issue, then it is not Office.

how are you creating the standard user accounts? Through the accounts system control panel? or are you using a script/package to create the local account?

does this occur for only the first local account created on the machine or for every local account?

I agree with the others above, if the base image is being created with autoDMG then it has to be an item that is being installed after this that is causing the problem, i'd try removing all packages and scripts from your configuration/workflow and trying them one by one until you find the culprit

OK- it was the office that was causing the problems. Once we redid that package - we are good to go. thanks everyone