Delete and Create Keychain - Authentication Check

[ruschg]

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"

[mm2270]

@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.

[bentoms]

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

[ruschg]

@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…"

[bentoms]

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