Sidebar Sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

Mojave Security Update 2021-004

Patrice Brousseau said:
Is MS Office (Word, OneDrive) using Kerberos?
Click to expand...
Not under normal circumstances. If you were using Kerberos for Office authentication you would know.

Martin Berthiaume said:
It impacts only Businesses or Schools that use windows active directory and/or windows file servers.

Martin
Click to expand...
Additionally, I found that 10.14 machines that were not bound at the time of the update do not exhibit this behavior (e.g. they are still able to mount SMB shares). I have not tried to subsequently bind them but if I do, I'll post the results.
 
  • Like
Reactions: Patrice Brousseau
croaker_1 said:
The problem is definitely being caused by the credentials cache, more specifically the Heimdal kcm (credential cache server) and seems limited to machines bound to a directory (possibly only Active Directory) before Security Update 2021-004 got installed.
Click to expand...
It seems not only Active Directory.

Open Direktory is Working here, but no Console Login or ARD to the OD Server and Replik anylonger possibel since the Update.

Thx

dodi
 
croaker_1 said:
Following up from my previous post. After doing some (a lot of) reading about Heimdal Kerberos, reports on the #MacAdmin Slack and a lot of trial and error here is what I have discovered. The problem is definitely being caused by the credentials cache, more specifically the Heimdal kcm (credential cache server) and seems limited to machines bound to a directory (possibly only Active Directory) before Security Update 2021-004 got installed. It may also affect machines bound after the Security Update but I have not tested that. I have not yet figured out exactly what is happening but the end result is that updated machines are no longer able to access the credential cache; which consequently prevents any ticket action from taking place. I could only find two lines of interest form the logs and you can see that they relate directly to cache config:

View attachment 1782147

The fix (well, really just a stop-gap measure until I can discover the actual cause) is to basically tell the OS to ignore cached Kerberos credentials for authorization (as well as screensaver). A shout out to @jojo on #MacAdmins for confirming my suspicions. To do this you will need to edit two system files (yours should look similar to these):

Code: 
/etc/pam.d/authorization
    # authorization: auth account
    auth       optional       pam_krb5.so use_first_pass use_kcminit
    auth       optional       pam_ntlm.so use_first_pass
    auth       required       pam_opendirectory.so use_first_pass nullok
    account    required       pam_opendirectory.so

/etc/pam.d/screensaver
    # screensaver: auth account
    auth       optional       pam_krb5.so use_first_pass use_kcminit
    auth       required       pam_opendirectory.so use_first_pass nullok
    account    required       pam_opendirectory.so
    account    sufficient     pam_self.so
    account    required       pam_group.so no_warn group=admin,wheel fail_safe
    account    required       pam_group.so no_warn deny group=admin,wheel ruser fail_safe

Using your favorite text editor (sudo) remove use_kcminit from each file.

For good measure I also killed related processes:
Code: 
sudo pkill coreauthd
sudo pkill kcm
sudo pkill kdc

In my testing this does not prevent remote users (those without connectivity to the domain controller) from logging into/unlocking their machines but I urge you to do your own testing before rolling it out.

I've also written a no-frills script to make it easy to deploy to users:
Bash: 
#!/bin/bash
sed -i '' "s/use_kcminit//" "/etc/pam.d/authorization"
sed -i '' "s/use_kcminit//" "/etc/pam.d/screensaver"
pkill coreauthd
pkill kcm
pkill kdc
Click to expand...
On the script, I get a return with Directory not found. Any other ideas on where I can find those files?
 
croaker_1 said:
Not under normal circumstances. If you were using Kerberos for Office authentication you would know.


Additionally, I found that 10.14 machines that were not bound at the time of the update do not exhibit this behavior (e.g. they are still able to mount SMB shares). I have not tried to subsequently bind them but if I do, I'll post the results.
Click to expand...
Thanks guys, the update was flawless but I always make a TM and a CCC backup prior to that.
 
After working with @croaker_1's workaround for about a day now, my machine hung again when accessing a network share. I hadn't restarted it since yesterday. A friendly sudo pkill kcm brought it back to life.
 
My original script was written as a test/quick fix so it wasn’t annotated and doesn’t provide any error checking or feedback. I’ve updated it to give some (hopefully) useful feedback as well as a method to check the success of the patch. I haven’t fully tested it so please let me know if you run into any trouble.

Bash: 
#!/bin/bash
## Mojave Security Update 2021-004 Kerberos hang fix/workaround
## Stops processes from hanging during Kerberos authentication on Active Directory bound machines
## by preventing macOS from asking for cached Kerberos credentials
## v1.1 - 27 May 2021
echo "Running pam.d fix"
## remove use_kcminit entry from pam.d authorization and screensaver
[[ -f /etc/pam.d/authorization ]] && sed -i '' "s/use_kcminit//" "/etc/pam.d/authorization" || echo "pam.d/authorization not found"; exit 1
[[ -f /etc/pam.d/screensaver ]] && sed -i '' "s/use_kcminit//" "/etc/pam.d/screensaver" || echo "pam.d/screensaver not found"; exit 2
# kill related processes
echo "Killing related processes"
pkill coreauthd kcm kdc
echo "Testing patch using klist"
## check success using klist 
            ## "2>&1"   - redirects stderr to stdout so even "Cache not found" gets stored in results
results=$(klist 2>&1 &)
            ##      "&" - send klist to the background so even if it hangs the script will continue
sleep 2
if [[ $results ]]; then
  echo "klist success"
else
  echo "klist fail"
  ## kill backgrounded klist because it is likely to be stuck
  pkill klist
  echo "Patch failed"
  exit 3
fi
## kill backgrounded klist in case it is still running
pkill klist
echo "Patch complete"
exit 0
 
  • Like
Reactions: Martin Berthiaume
Thankyou @croaker_1 ! I've spent the last 2 days thinking I was going mad, and finally today I see that while I may well be, this particular problem has external causes.. 😆
There may be an issue in your "improved" script; the only echo I got was "Running pam.d fix"- and nothing else. And the problem persisted. So I manually pkill'd coreauthd, kcm, kdc and then HUZZAH! - fixed. I can't see how your script snuck out without the exit 1 or exit 2 messages.. but it seems it did...
But anyway, thank you, thank you, thank you, for restoring my sanity.. or at least my ability to log in to things..!!
 
tomlawton said:
Thankyou @croaker_1 ! I've spent the last 2 days thinking I was going mad, and finally today I see that while I may well be, this particular problem has external causes.. 😆
There may be an issue in your "improved" script; the only echo I got was "Running pam.d fix"- and nothing else. And the problem persisted. So I manually pkill'd coreauthd, kcm, kdc and then HUZZAH! - fixed. I can't see how your script snuck out without the exit 1 or exit 2 messages.. but it seems it did...
But anyway, thank you, thank you, thank you, for restoring my sanity.. or at least my ability to log in to things..!!
Click to expand...
Ah, thanks for the feedback. I'll make a few tweaks that should make it a bit more verbose. You can run a quick cat /etc/pam.d/authorization | grep use_kcminit to make sure it has actually been removed.
 
  • Like
Reactions: tomlawton
tomlawton said:
There may be an issue in your "improved" script; the only echo I got was "Running pam.d fix"- and nothing else.
Click to expand...
Version 1.2
Bash: 
#!/bin/bash
## Mojave Security Update 2021-004 Kerberos hang fix/workaround
## Stops processes from hanging during Kerberos authentication on Active Directory bound machines
## by preventing macOS from asking for cached Kerberos credentials
## v1.1 - 27 May 2021 - initial release
## v1.2 - 27 May 2021 - improved flow of the fix section, added extra status text

echo "Running pam.d fix"
## remove use_kcminit entry from pam.d authorization and screensaver
if [[ -f /etc/pam.d/authorization ]]; then
  echo "  1 - Processing /etc/pam.d/authorization"
  sed -i '' "s/use_kcminit//" "/etc/pam.d/authorization"
else
  echo "/etc/pam.d/authorization not found"
  echo "Patch failed"
  exit 1
fi

if [[ -f /etc/pam.d/screensaver ]]; then
  echo "  2 - Processing /etc/pam.d/screensaver"
  sed -i '' "s/use_kcminit//" "/etc/pam.d/screensaver"
else
  echo "/etc/pam.d/screensaver not found"
  echo "Patch failed"
  exit 2
fi

# kill related processes
echo "  3 - Killing related processes"
pkill coreauthd kcm kdc

echo "  4 - Testing fix using klist"
## check success using klist
            ## "2>&1"   - redirects stderr to stdout so even "Cache not found" gets stored in results
results=$(klist 2>&1 &)
            ##      "&" - send klist to the background so even if it hangs the script will continue

echo "  5 - Waiting two seconds"
sleep 2

echo "  6 - Checking test results"
if [[ $results ]]; then
  echo "klist success"
else
  echo "  klist fail"
  ## kill backgrounded klist because it is likely to be stuck
  pkill klist
  echo "Patch failed"
  exit 3
fi

## kill backgrounded klist in case it is still running
pkill klist
echo "Patch complete"
exit 0
 
Last edited:
  • Like
Reactions: tomlawton
@RoboFlex on #MacAdmins Slack brought up a good point about restoring these files when (or if) Apple releases a fix. Here is a quick way to "unfix" them:
Bash: 
#!/bin/bash
sed -i '' "s/pam_krb5.so.*/&use_kcminit/" "/etc/pam.d/authorization"
sed -i '' "s/pam_krb5.so.*/&use_kcminit/" "/etc/pam.d/screensaver"

Another concern mentioned over at #MacAdmins was about running this script on a machines updated machine that is not experiencing problems. It should be fine but if you are concerned you can run the klist check before the sed commands run. Just put this at the beginning of the script:

Bash: 
precheck=$(klist 2>&1 &)
sleep 2
if [[ $precheck ]]; then
  echo "klist success"
  echo "All good. Patch not required"
  exit 0
else
  echo "klist fail"
  ## kill backgrounded klist because it is likely to be stuck
  pkill klist
  echo "Patch is required. Keep going..."
fi

For more information about #MacAdmins Slack and how to join: https://www.macadmins.org
 
  • Like
Reactions: tomlawton
NOTE - this appears to hang when on a Mac that is already experiencing the issue. Curious if others have attempted to add this to the script.

Bash: 
precheck=$(klist 2>&1 &)
sleep 2
if [[ $precheck ]]; then
  echo "klist success"
  echo "All good. Patch not required"
  exit 0
else
  echo "klist fail"
  ## kill backgrounded klist because it is likely to be stuck
  pkill klist
  echo "Patch is required. Keep going..."
fi
 
Hey everybody!
Thanks for the scripts it helped very well!

our first aid, was to block the security update after some macs got it and claimed problems..
they are now working fine again.

Now i wonder.. will apple release another "fix" Update for this Mojave Security Update or will they just ignore it?

Do you guys think it is recomended to unblock the Security Update and push immidiatly the script right after?

Thanks for some Advice!

Greetings
 
Good question. Ignorance is bliss. I installed the update on my Mini anyway a few days ago. I've not noticed any problems.
 
Last edited:
  • Like
Reactions: MarkC426
Wasn't sure whether this was a standard MacOS thing or because users have something installed.
 
Gregg2 said:
Good question. Ignorance is bliss. I installed the update on my Mini anyway a few days ago. I've not noticed any problems.
Click to expand...
This bug only affects machine bound to Active Directory (i.e. within a company, school, organization, etc.)
 
  • Like
Reactions: MarkC426
prbsparx said:
NOTE - this appears to hang when on a Mac that is already experiencing the issue. Curious if others have attempted to add this to the script.

Bash: 
precheck=$(klist 2>&1 &)
sleep 2
if [[ $precheck ]]; then
  echo "klist success"
  echo "All good. Patch not required"
  exit 0
else
  echo "klist fail"
  ## kill backgrounded klist because it is likely to be stuck
  pkill klist
  echo "Patch is required. Keep going..."
fi
Click to expand...
Ah...thanks for the feedback. I was not able to find an unpatched machine to test this on. I had assumed (silly me) that the background (&) called the command (klist) but maybe it is the other way around. I'll do some reading and testing: if there is a better way I'll post more info here.
 
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back