Delete and Create Keychain - Authentication Check

ruschg
New Contributor II

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"

4 REPLIES 4

mm2270
Legendary Contributor III

@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
Release Candidate Programs Tester

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

ruschg
New Contributor II

@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
Release Candidate Programs Tester

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