NoMAD AD Password Change issues

[danbaver]

Hi all,

Is anyone having issues with users changing their AD password with NoMAD and macOS 10.15.5?

The error we sometimes get is "Configuration file does not specify default realm." What I have done to resolve this in the past is simply reapply the NoMAD Config profile to the user's machine. With 10.15.5, I've found that reinstalling NoMAD is sometimes necessary. However, I have one user who is still getting the error even after a new reinstall of NoMAD and after reapplying the config profile.

Has anyone else encountered this?

[azwart]

I'm seeing the same error with one of my MacBooks that is running macOS 10.14.6.

[RJH]

@azwart @danbaver we have encountered this at various stages in the environment with NOMAD. The fix we have in place is to have an EA which collects the default kerberos realm, and then a script to re-apply this IF the realm is blank. This solution was grabbed off another post, so credit (and thanks) to that/those creators.

EA

#!/bin/bash
#
# Author: Johan McGwire - Yohan @ Macadmins Slack - Johan@McGwire.tech
#
# Description: Looks up the default kerberos realm preference for the user and reports it to JAMF as an EA result
user=$(/usr/bin/python -c 'from SystemConfiguration import SCDynamicStoreCopyConsoleUser; import sys; username = (SCDynamicStoreCopyConsoleUser(None, None, None) or [None])[0]; username = [username,""][username in [u"loginwindow", None, u""]]; sys.stdout.write(username + "
");')

realm=$(su $user -c '/usr/libexec/PlistBuddy -c "print :libdefaults:default_realm" ~/Library/Preferences/com.apple.Kerberos.plist')
resultCode=$?

if [ $resultCode == 0 ]; then
    echo "<result>${realm}</result>"
else
    echo "<result>null</result>"
fi

# Exiting and returning the policy call code

exit $resultCode

SCRIPT implemented via policy scoped on the REALM EA if blank.

#!/bin/bash
#
# Author: Johan McGwire - Yohan @ Macadmins Slack - Johan@McGwire.tech
#
# Description: Sets the users default kerberos realm manually, this script pairs well with my jamf EA script
#

# Set the realm
realm="YOUR-DOMAIN-HERE"

# Saving the JAMF user varible to something more verbose
if [ -z $3 ]; then
    user=$(/usr/bin/python -c 'from SystemConfiguration import SCDynamicStoreCopyConsoleUser; import sys; username = (SCDynamicStoreCopyConsoleUser(None, None, None) or [None])[0]; username = [username,""][username in [u"loginwindow", None, u""]]; sys.stdout.write(username + "
");')
else
    user=$3
fi
echo "Running for: ${user}"

# if [ -z $user ]; then
if [ -z $3 ]; then
   echo "User is not logged on - cannot apply fix - command aborting "
   exit 1
fi 

# Saving the preference as the user
echo "Setting realm: ${realm}"
su $user -c "defaults write com.apple.kerberos libdefaults -dict default_realm ${realm}"
resultCode=$?

if [ $resultCode ]; then
    echo "Success"
else
    echo "Failure"
fi

# Exiting and returning the policy call code
exit $resultCode

Hope this helps !

[mickl089]

Unfortunately, I know the mistake all too well.

I helped myself by simply installing NoMad over it and then first logging out the user, then logging back in.

[RJH]

@mickl089 this sounds like a lot of hard work, when it should, AFAIK, simply be a case of re-applying the kerberos realm to the NoMAD plist file, as per my above post. Saves re-installing NoMAD and logging out/logging in the user.???

[dstranathan]

Late to this party, but I ran into this error after doing some demobilization tests with Macs previously bound to AD. After rebooting the Mac once demobiization script was completed, NoMAD worked OK (after password prompt) and NoMAD Shares mounted my SMB volumes, too, but attempting to change the users (AD) password via NoAMD failed with the error above. After a reboot the issues was resolved. Didnt test re-pushing the NoMAD config profile or anything else.