Best way remove a corrupt keychain file...

A script run from Casper Suite will not correctly target the logged in user with the ~/ usage. It will only affect the Casper service account or the root account, meaning the account that's running the script.

There are several ways around this though.
If you're looking to target all home directories and the User Template, you could script looping through all local accounts on the Mac and location and removing the keychain, and then remove it from /System/Library/User Template/English.lproj/Library/Keychains/ (or whatever language directories it was pushed to)

Completely untested:

#!/bin/bash

for user in $( dscl . list /Users UniqueID | awk '$2 > 500 {print $1}' ); do
     # Get user home dir path
     userHome=$( dscl . read /Users/$user NFSHomeDirectory | awk '{print $NF}' )
     rm -f "$userHome/Library/Keychains/login.keychain" 2> /dev/null
done

rm -f /System/Library/User Template/English.lproj/Library/Keychains/login.keychain

Sometimes the for/do loop doesn't read the accounts correctly. When I've run into that, I've switched to doing echo "$userlist" | while read user; do and that does the trick.

Thanks! I'll give it a try...

In bash, on the assumption all of the home accounts are in /Users/, you can just run:

rm /Users/*/Library/Keychains/login.keychain

No need to search dscl and find home account info, etc.

Depending on what you are doing, you can also edit keychains:

man security

Thanks for your help, so here's the odd thing it seems the corruption makes the OS think the keychains directory is a file. This works well enough:

rm -R /Users/*/Library/Keychains

The odd thing is there is no /Library/Keychains in the user template so I'm still not sure where the bad file is coming from. Anyway now I need to figure out how the best scope to deploy the script on... as new users are logging into the system all the time, I think it will need to continuously run on login, not sure what that will do with a new session but I'll see....

If the Keychains directory is a file, then you shouldn't require the -R option and it therefore can't have anything inside it, again making the -R option unnecessary. You clearly have a problem, that requires fixing, I don't think your users are going to be grateful if you keep deleting their keychain, if indeed they have one.

Out of interest, what happens when you run the following on an 'infected' user, eg. user sean:

ls -lO /Users/sean/Library/ | grep Keychains

ls -lO /Users/sean/Library/Keychains/

I'd suggest you'd be better spending your time working out what is causing the problem rather than spending that time trying to script around it and in turn affecting your users.

Agreed with @sean here. You probably should have mentioned that the Keychain folder was showing up as a file. There is a older thread on a similar issue, that might turn out to be the same problem for you, located here:
https://jamfnation.jamfsoftware.com/discussion.html?id=6211
This is different than just an issue with the login.keychain.

@sean and @mm2270 thank you for your help!

Regarding messing with my users keychains, I should clarify that these Mac's are drop-in lab systems for students to use where no local data or settings are guaranteed. This has been a problem with the build form the start thus they have never had a correct keychain. In this care this is on of those times when Apple's keychain system doesn't meet our use case and causes more problems then it solves, but thats besides the point.

@mm2270 the keychain = file thing is phenomena is something I just was able to replicate myself. I will look at the other post to see if that works.

Thanks again for all your help!