Script at Login Issue

You could use the Once per User frequency in the policy to do this, but be aware of one potential issue. The JSS treats once per user as truly once per user. The details of this are outlined in this Feature Request thread:
https://jamfnation.jamfsoftware.com/featureRequest.html?id=45

Essentially, if user "johndoe" logs into ComputerA, the policy runs, the JSS logs that as the once per user run for user "johndoe". If the user later logs into ComputerB, 5 minutes later or 5 months later, no difference, it will not run again for that user login. This could present a problem if users occasionally log into different Macs, or if a Mac becomes re-imaged for example.

Were trying to run this to set chrome to SSO globally but the setting doesnt appear to apply even though it returns code 0 implying its complete in Casper Remote.

defaults write com.google.Chrome AuthServerWhitelist *.XYZ.com

I added sudo the the beginning also since its needed but this makes no difference is this a script problem or is this something with how casper executes it ?

Our Chrome SSO script can be pushed out at any time and runs at the system level. It does two things: uses the defaults command to write the AuthServerWhitelist entry for each existing user account, then writes it to the default user template so the Chrome plist is inherited for all new users.

Here is that part of the script. I'm sure it could be more efficient (regarding the user account checks), but it works:

userList=`dscl . list Users`

inusers=`ls -l /Users/ | awk '{print $9}'`
for f in ${inusers[@]}; do
    case $f in
        Shared | Guest | administrator | ".localized" | Root | ".DS_Store")
            log "Skipped $f"
            continue
            ;;
        *)
        checkUserList=`echo $userList | grep $f`
        if [ "$checkUserList" ]; then
            userlookup=`dscl . read Users/$f UniqueID | awk '{print $2}'`
            if [[ $userlookup -gt 10000 ]]; then
                log "User $f, UID $userlookup, is a network account.  Writing whitelist preferences."
                defaults write /Users/"$f"/Library/Preferences/com.google.Chrome.plist AuthServerWhitelist 'server1','server2','server3'
                chown "$f":staff /Users/"$f"/Library/Preferences/com.google.Chrome.plist
                echo "Applied to $f"
            else
                log "User $f, UID $userlookup, is a local account.  Skipping."
            fi
        else
            log "User $f not in dscl user list, skipping"
            echo "Skipped $f"
        fi
        ;;
    esac
done

defaults write /System/Library/User Template/English.lproj/Library/Preferences/com.google.Chrome.plist AuthServerWhitelist 'server1','server2','server3'

Your defaults example above will only work when the logged in user runs it. If you don't specify the path to the plist to manipulate, it assumes the home folder and path to Preferences for the user running the command. In this case it would be root or your Casper service account, so that's why its not working.

There are a couple ways to fix this. You can either get the logged in user's name and their home directory path and then run the cpmmand on their Chrome plist. or you can instruct the script to run the command as the user. Here are some examples of each. Not tested, so I can't say if these will actually work, but they should in general.

First example - get the logged in user name and home folder path

#!/bin/sh

loggedInUser=$( ls -l /dev/console | awk '{print $3}' )
userHome=$( dscl . read /Users/$loggedInUser NFSHomeDirectory | awk '{print $NF}' )

## Now write the setting to the user's Chrome plist
defaults write $userHome/Library/Preferences/com.google.Chrome AuthServerWhitelist *.XYZ.com

Second example, instruct it to run the defaults command as the user

#!/bin/sh

## Run the defaults command as the logged in user
loggedInUser=$( ls -l /dev/console | awk '{print $3}' )

sudo -iu $loggedInUser defaults write com.google.Chrome AuthServerWhitelist *.XYZ.com

I personally would use the first option, since I think its more reliable. but you can try either one and see what works best for you. There are of course additional options beyond what I've written above.

Do I have to compile these into a .sh script I am a total noob at scripting Im only just learning how we can do this with casper - We're trying with Casper 9.3 and its still not applying.

I've tried defining the script in Casper online under Scripts and also as a .sh I could be making a mistake though so any more help would be immense.

I'm not that well versed on entering scripts directly into the JSS under version 9, so I can't say how that works, though I'd imagine it should. You could also copy/paste one of the scripts above (@alexjdale's is better as it will get you closer to what you're looking for) into a text file and save with a .sh extension. Although you could use TextEdit, I don't really recommend it as it has default settings that try to convert things like straight quotes into curly quotes and other nastiness that will mess up your script. Its just TextEdit trying to be helpful and not actually helping. :)
Go to the App Store and download a free copy of TextWrangler. I use it daily when writing scripts and its never let me down.

Once you've saved it as a script file (make sure it has only a .sh extension), upload it and if needed sync to any DPs you may have. You should then be able to add the script to your policy and test it out.

HTH

I've tested both scripts and still chrome refuses to work correctly per the SSO this is the same for OSX 10.6 and OSX 10.9 clients :(

I've deployed in script and also via .sh and pushed it ... I'm not sure whats wrong we just want all users on all machines to have the SSO enabled by default is there a machine level command we can run instead ?

Something that blanket sets as a global setting for it ?, At a loss just now.

Note we're connected to an AD network not OD

My script is not complete, it's just a snippet from my overall script. It won't execute properly on its own.

The issue here is that the Chrome preference file is stored "per user" so there is no global command to enable SSO for every user on the system. Either each user has to run that defaults write command under their own account (which will automatically write it to the correct plist in their profile), or you need to run it for them with an explicit path to their preference file (which is what my script does).

We set this via a manage preference, works like a charm for all users & at every login.

Seems much simpler than scripting it.