Skip to main content

Hello All,



Just doing a little digging on JAMFNation in setting up our Self Service Portal, came across a script from Andrina Kelly (below) and her 2013 JNUC Presentation. Essentially, I'm looking to add perhaps an authentication hook to ensure that end-users are "indeed" entering their updated password instead of avoiding a mistaked keystroke. Perhaps a test map to a server or something.



Any advice or resources are warmly welcome! Thank you.



!/bin/bash



############################################################


Created By: Andrina Kelly, andrina.kelly@bellmedia.ca, Ext 4995



Creation Date: July 2013



Last modified: July 25th, 2013



Brief Description: Deletes the users login.keychain, and creates a new keychain



############################################################


Set CocoaDialog Location



CD="/Path/to/CocoaDialog.app/Contents/MacOS/CocoaDialog"



Find out who's logged in



USER=who | grep console | awk '{print $1}'



Get the name of the users keychain - some messy sed and awk to set up the correct name for security to like



KEYCHAIN=su $USER -c "security list-keychains" | grep login | sed -e 's/"//g' | sed -e 's/// /g' | awk '{print $NF}'



Go delete the keychain in question...



su $USER -c "security delete-keychain $KEYCHAIN"



Ask the user for their login password to create a new keychain



rv=($($CD secure-standard-inputbox --title "Set New Keychain Password" --no-newline --informative-text "Enter your current login password"))
PASSWORD=${rv[1]}



Create the new login keychain



expect <<- DONE
set timeout -1
spawn su $USER -c "security create-keychain login.keychain"



# Look for prompt
expect "?chain:"
# send user entered password from CocoaDialog
send "$PASSWORD
"
expect "?chain:"
send "$PASSWORD
"
expect EOF
DONE



Set the newly created login.keychain as the users default keychain



su $USER -c "security default-keychain -s login.keychain"

@ruschg Are these Macs joined to an Active Directory domain, in range of a DC when this is run, and the user account its being run from is AD based?
If the answer to all of those is yes, I would look at using ldapsearch using the user's Distinguished Name to see if it can do a lookup against its own account, or an account you know is always there, like a service account in AD, for example. If this is successful using the user's entered password, then its the right password since ldapsearch would fail if the password entered is wrong.


@ruschg Have you looked at also deleting Local Items &/or ADPassMon?


@mm2270 and @bentoms - many thanks for your responses. With these ideas in mind, I believe I'm all set.



@bentoms - this made my day: "But if I had a £ for every Keychain call…"


@ruschg Haha glad you like it & that we could help :)


Reply