Very aggravating login message

monosodium
Contributor

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!

1 ACCEPTED SOLUTION

mm2270
Legendary Contributor III

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?

View solution in original post

15 REPLIES 15

jarednichols
Honored Contributor

What if instead you use the deleteAccount verb on the jamf binary? Different result?

monosodium
Contributor

I can try that. Does the deleteAccount verb allow for wildcard usage and such?

monosodium
Contributor

After trying the deleteAccount verb it is unable to find the user's home directory. Any other ideas?

mm2270
Legendary Contributor III

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.

monosodium
Contributor

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.

bentoms
Release Candidate Programs Tester

Hmmm... Are you customising the User Template? Perhaps deploying a ~/Library/login.keychain?

monosodium
Contributor

Many of the applications that I am deploying require me to Fill User Templates, so that would be a definite possibility.

monosodium
Contributor

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.

bentoms
Release Candidate Programs Tester

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.

monosodium
Contributor

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.

mm2270
Legendary Contributor III

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.

monosodium
Contributor

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.

monosodium
Contributor

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.

mm2270
Legendary Contributor III

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?

monosodium
Contributor

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.