Posted on 11-13-2012 12:15 PM
Hello All,
Upon using a script to delete all non-admin users I am getting a very annoying keychain message. The script is:
#!/bin/sh
# Define current user
current_user=`ls -l /dev/console | awk '{print $3}'`
# Loop through users with homes in /Users; exclude any accounts you don't want removed (i.e. local admin and current user if policy runs while someone is logged in)
for username in `ls /Users | grep -v aaalabs | grep -v $current_user`
do
echo "Removing user: $username"
dscl . delete /Users/$username
rm -rf /Users/$username
done
# Remove all sharepoint groups to speed up login.
for group in `dscl . list /Groups | grep "com.apple.sharepoint"`
do
echo "Deleting group: $group"
dscl . delete /Groups/$group
done
# Remove MCX files
rm -rf "/Library/Managed Preferences"
Upon logging in, I now receive the error message "The system was unable to unlock your Keychain". This message is simple enough to bypass with a continue... but is very confusing to our users. Any way to remove this message?
Thanks from a very perplexed Admin!
Solved! Go to Solution.
Posted on 11-14-2012 09:45 AM
Its sounding more and more like a login.keychain file with old information is being dropped into your User Template folder as Ben hinted at. Then, every time a user logs in, the OS reads back that keychain, sees that it cannot be unlocked and the user gets the prompt. Perhaps the local admin keychain file somehow got deployed into the User Template Library folder?
Posted on 11-13-2012 12:24 PM
What if instead you use the deleteAccount verb on the jamf binary? Different result?
Posted on 11-13-2012 12:46 PM
I can try that. Does the deleteAccount verb allow for wildcard usage and such?
Posted on 11-13-2012 01:11 PM
After trying the deleteAccount verb it is unable to find the user's home directory. Any other ideas?
Posted on 11-13-2012 01:20 PM
Can you explain who you are logging in as when you get this message? The user that was logged in when the script ran? Or someone else? I don't think that part is clear, at least not to me.
Posted on 11-13-2012 02:32 PM
My apologies for the confusion. The machines are joined to AD, and this issue affects any and all users that log in. The only exception is the previously created admin account, aaalabs, and any other accounts that have bypassed the message in some way. Every user is a unique user for the most part as we have hundreds of students and hundreds of computers, so the latter part does not really help any.
Posted on 11-13-2012 02:35 PM
Hmmm... Are you customising the User Template? Perhaps deploying a ~/Library/login.keychain?
Posted on 11-13-2012 03:35 PM
Many of the applications that I am deploying require me to Fill User Templates, so that would be a definite possibility.
Posted on 11-13-2012 03:39 PM
I should also mention that I recently changed the Admin account password universally; I can see this causing an issue but not sure where to look to propagate the correct settings.
Posted on 11-13-2012 10:15 PM
Ah. I guess it's the admin pass change that is the issue.
When you see the error, click "Update Keychain" then enter the old password.
Then logout then back in & volia! No prompt.
Posted on 11-14-2012 09:03 AM
bentoms: Tried your suggestion and it only fixed the issue for that particular user. These machines are in a lab environment with AD logins... so I need a solution that will work for all users on the machine.
Posted on 11-14-2012 09:17 AM
If the login.keychain is the issue, why not just include a simple one line script to blow away the admin login.keychain file? It will get recreated automatically the next time that account gets logged in. Unless there is something in that keychain file that you definitely need to retain.
Or perhaps I'm misunderstanding the issue.
Posted on 11-14-2012 09:35 AM
mm2270: The problem is that I have tried manually deleting the login keychain. I have tried updating the keychain with the new password. Unless this particular script does something that cannot be done in the keychain GUI then I doubt it will do much.
Posted on 11-14-2012 09:38 AM
I have also noticed that with a new lab image that I just deployed the machines are still having the issue. So it appears the script is not the culprit... I will go through and check any recently made packages and post what I find here.
Posted on 11-14-2012 09:45 AM
Its sounding more and more like a login.keychain file with old information is being dropped into your User Template folder as Ben hinted at. Then, every time a user logs in, the OS reads back that keychain, sees that it cannot be unlocked and the user gets the prompt. Perhaps the local admin keychain file somehow got deployed into the User Template Library folder?
Posted on 11-14-2012 10:09 AM
It is looking that way. I narrowed the issue down to a package that is causing this whole mess. I am going to remake the particular package and am willing to bet it will resolve the issue.