Q: After Upgrade to El Capitan, Clicks on "Allow" or "Always Allow" on keychain dialogs don't register

Thanks for posting this!

I was trying every single thing posted as a solution on the internets and it still wasn't working.

In my case, the culprit was Screen Sharing app on Mac. While using it to import apple developer profile into Xcode on the mini remotely, it'd present this dialog with Always, Always Allow and Deny. And, only the Deny button would work remotely.

Whatever it is with the "synthetic clicks" its a pain to manage a remote build machine with this "security feature".

Radar: 23561390

Thanks heaps Kristin.

I spent all morning trying to renew the certificate on my OS X Server machine and getting to the dialog with only 'Deny' working. Plugging the server into a mouse, keyboard and screen allowed me to do it.

Crazy that this is now the only way to do it. How are you supposed to remotely manage a server room or data centre co-lo?

Yea, it's pretty frustrating and a major PITA for anyone remotely managing Macs. I've submitted a bug report, but so far, no resolution...

k.

Yeah, I filed rdar://23314241 and it was marked as a duplicate of rdar://22923527, which means I'll never be notified when this is "fixed".

As mentioned above, how are we supposed to administer remote servers now? Sigh.

Not sure about the solution, but this seems to have cropped up somewhere, and let me guess: you are using File Vault.

Please ignore.

Luis—"cropped up somewhere"? It's a documented byproduct of a security update that was part of 10.11.1. Has nothing to do with whether or not the client machines are running File Vault (but, for argument's sake, none of the machines I've tested this issue against are running File Vault—I don't trust File Vault enough to ever enable it on any of our machines...but that's another thread). Any machine running 10.11.1 and being remotely managed will be affected by this issue.

kristin. wrote:

 

Luis—"cropped up somewhere"? It's a documented byproduct of a security update that was part of 10.11.1. Has nothing to do with whether or not the client machines are running File Vault (but, for argument's sake, none of the machines I've tested this issue against are running File Vault—I don't trust File Vault enough to ever enable it on any of our machines...but that's another thread). Any machine running 10.11.1 and being remotely managed will be affected by this issue.

For some reason I saw only the original post and none of the subsequent replies. I have retracted my comment.

I was having the same problem and the Keychain prompt wouldn't accept anything other than the "Deny" option.

I saw your post about adding Hazel to Accesibility and I what I did was add Keychain Access in there. It seems that has solved the issue now.

Adding Keychain Access to Accessibility...didn't try that, but it makes sense! That said, that'll essentially "disable" the security patch that Apple deployed with 10.11.1 (which resulted in this bug). So, while it's a workaround for the bug, you end up reverting back to an insecure Keychain. My suggestion would be, if you need to do remote work on machines (which require clicking "Always Allow"), I'd implement this workaround, do the work you need to do, then remove Keychain Access from Accessibility.

Hopefully Apple will fix this (no sign of a fix yet, though, in my testing) so we don't have to jump through these hoops.

k.

kristin. wrote:

 

...

 

That said—this isn't the only thing causing this problem. Any third party application running on your machine that OS X sees as "taking control" of your window will also trigger the issue (for example, I have Hazel running on a few of my machines, and that was causing the same problem—I couldn't even physically click "Always Allow" on these machines. Disabling Hazel solved the problem ...

I had MagicPrefs running to do '3-Finger Middle Click', and this was causing the issue for me.  Quitting MagicPrefs, and restarting Office365 allowed me to click the 'Always Allow' and 'Allow' buttons for the Keychain request.

This helped me. Add MagicPrefs in Security Accessibility, then quit and restart MagicPrefs.

I've talked to Apple support in Cork, Ireland today. They can reproduce this problem and told me, this should not be. They will escalate it to the developer to fix this with an update, but they can not tell how fast this will come. It would really help if all of you also call the Apple support and report the same problem. As more people report it as faster it will be fixed, so they told me.

Greetings!

Hope they fix this soon.  Wisely, I didn't upgrade any of the build machines in the lab to El Captain, but the new mac mini came with it.

Confirm is the same problem, as long as you are in any screen sharing mode, you cannot change the access permission for a key chain, but it let you DELETE or add any keychain.

THE FIX THAT WORKED FOR ME

Like everyone here, this has been driving me crazy for ages!

I tried almost everything I could find online but nothing worked for me.

What worked for me was to UNPLUG MY WACOM TABLET. I dug out an old bluetooth mouse, connected and had a crack. It worked straight away.

I'm sure this won't fix everyones problems, but fingers crossed it will help a few people.

cheers

Andrew

Thanks Kristin. Based on your post I figured it might be the fact that I was using my Wacom tablet to click the 'allow' or 'always allow' buttons. Switching to my magic mouse solved the problem. Just updated the Wacom drivers, perhaps it was outdated and blocked by OS X absurd security settings.