Skip to main content

Hello all,

 

Requiring our org to update the password complexity and have a quick few questions.

 

We have a configuration profile setup to update the password complexity to a higher number of digits needed. Currently our systems have static passwords.

 

We are doing this in a two pronged approach

1. Config profile will be updated from 12 characters to 16 characters

2. Policy will be run on the determined group of people at a determined time.

 

 

# Pulls the current logged in user
currUser=$(ls -l /dev/console | awk '{print $3}')
pwpolicy -u "$currUser" -setpolicy "newPasswordRequired=1"

 

 

 

Since we are planning to roll out this update with groups of people at a time, can we push the config profile (step 1 above) to ALL users without it prompting them to update their password until we run the policy/remote command (step 2 above) to flag the account for a password reset? Or does the config profile have to be scoped to each group at a time (depending on when we determine its their turn)?

  • Asking this specific question since all passwords are currently static and do not expire

 

Additionally, is there a way to determine when the password on a machine was last changed, and add that as an exclusion to the policy that runs to flag the account for a password reset?

  • Can this also be done as an EA?

When the config profile lands, users will be prompted to update passwords at login. The Configuration Profile process gives no regard to any CLI stuff you may be doing. 

 

I would recommend getting your password stuff in line and updated before pushing the configuration profile, and leave an air gap of a few weeks. However, you can adjust your password script to drop a file and make an extension attribute to look for that file. Set an extension attribute to look for /var/logs/theThingWasDone.log, and target your configuration profile at a smart group with the ThingWasDone.log on the device.

# Pulls the current logged in user
currUser=$(ls -l /dev/console | awk '{print $3}')
pwpolicy -u "$currUser" -setpolicy "newPasswordRequired=1"

touch /var/logs/theThingWasDone.log

 

If your users have secure tokens, you cannot modify the passwords with CLI. You would need to use an account with a secure token to modify an account with a secure token. JAMF runs everything as Root, Root does not have a secure token. It is possible to script this, but you would need a fairly complex script.

 

 

When the config profile lands, users will be prompted to update passwords at login. The Configuration Profile process gives no regard to any CLI stuff you may be doing. 

 

I would recommend getting your password stuff in line and updated before pushing the configuration profile, and leave an air gap of a few weeks. However, you can adjust your password script to drop a file and make an extension attribute to look for that file. Set an extension attribute to look for /var/logs/theThingWasDone.log, and target your configuration profile at a smart group with the ThingWasDone.log on the device.

# Pulls the current logged in user
currUser=$(ls -l /dev/console | awk '{print $3}')
pwpolicy -u "$currUser" -setpolicy "newPasswordRequired=1"

touch /var/logs/theThingWasDone.log

 

If your users have secure tokens, you cannot modify the passwords with CLI. You would need to use an account with a secure token to modify an account with a secure token. JAMF runs everything as Root, Root does not have a secure token. It is possible to script this, but you would need a fairly complex script.

 

 


Hey AJPinto,

 

I've tested the config profile and policy script on a test machine a few times with success.

Updating the config profile to point to my test machine and then running the script:

# Pulls the current logged in user

currUser=$(ls -l /dev/console | awk '{print $3}')

pwpolicy -u "$currUser" -setpolicy "newPasswordRequired=1"

 

via a policy has worked for me to force a reset.

 

If I just scope the configuration profile to my machine, and not the policy that flags the machine for a password reset, I have not been prompted to reset the password.

- Just tested this with my own machine as well and had the same result (1 intel/1 M1)

 

Additionally, set an EA script which doesn't seem to be working. Can you/someone take a look and see why its not populating in JAMF? When run on my machine it works fine.

 

currUser=$(ls -l /dev/console | awk '{print $3}')
date -r $(sudo dscl . -read /Users/"$currUser" accountPolicyData |
tail -n +2 |
plutil -extract passwordLastSetTime xml1 -o - -- - |
sed -n "s/<real>\\([0-9]*\\).*/\\1/p")

Can someone assist with making this EA display correctly?

 

I want an EA to basically display how many days it has been since the last password change

 

What I currently have is this:

 

#!/bin/bash



# Logged in user

LoggedInUser=`ls -l /dev/console | awk '{ print $3 }'`



# Current password change policy

PasswdPolicy=0



# Last password set date

LastPasswordSet=`dscl . read /Users/$LoggedInUser | grep --context=3 passwordLastSetTime`



# Calculations

LastPasswordCalc1=`expr $LastPasswordSet / 10000000 - 1644473600`

LastPasswordCalc2=`expr $LastPasswordCalc1 - 10000000000`

TimeStampToday=`date +%s`

TimeSinceChange=`expr $TimeStampToday - $LastPasswordCalc2`

DaysSinceChange=`expr $TimeSinceChange / 86400`

DaysRemaining=`expr $PasswdPolicy - $DaysSinceChange`



echo "<result>$DaysRemaining</result>"

 

Can't get this to work correctly.

 

If this could display in a date format readable by jamf (ex YYYY-MM-DD hh🇲🇲ss) that would be awesome

Is there any way to get the output for this to display in a date format that JAMF recognizes (ex. YYYY-MM-DD hh🇲🇲ss)?

currUser=$(ls -l /dev/console | awk '{print $3}')

date -r $(sudo dscl . -read /Users/"$currUser" accountPolicyData |

  tail -n +2 |

  plutil -extract passwordLastSetTime xml1 -o - -- - |

  sed -n "s/<real>\\([0-9]*\\).*/\\1/p")

Reply


Terms & ConditionsCookie settings