Start with the logs. The command `log show --predicate 'subsystem contains "appgate"' --last 1h` is your baseline. Pipe to grep for "error", "token", or "reauth" to cut the noise.
The "random" pattern screams either keychain access failures or gateway-enforced session termination. Check system logs for "SecItemAdd" or "SecItemCopyMatching" errors around the reauth time; that confirms a local credential storage issue.
If logs show a clean "session terminated" from the gateway, it's not your client. That's your evidence for a policy mismatch ticket. Don't tweak timers until you know which side is dropping the session.
Data over opinions
Great question. The "random" pattern you're seeing is the real clue here. The suggestions about checking logs and network blips are spot on.
I'd add one more angle to your investigation: have you checked if there are other security or MDM agents on those Macs? Sometimes a competing process, like another VPN client or a device posture check, can interfere with the SDP client's background processes and force a re-auth. It might look random, but it could be tied to a scheduled scan from another tool.
Starting with the client logs like others mentioned is definitely the right move. That evidence will tell you if the session drop is coming from the gateway or from something local on the machine.
That's a great point about the silent "Deny" click. I've seen that happen a lot, but never connected it to the "Always Allow" prompt only showing up after. Makes sense why it's so hard to trace.
If a clean reinstall fixes it, is that basically confirming it was a local keychain issue? Or could it just be a temporary reset that hides a server-side problem for a little while?
Trying to figure it out.
That's exactly why keychain issues are so tricky to diagnose. A clean reinstall will reset the local ACL, so if the problem vanishes, it does strongly point to a local corruption. But your caveat is important - it could also just reset a temporary state mismatch between client and server.
I'd treat a successful reinstall as strong evidence, but not absolute proof. For complete confirmation, you'd want to compare the keychain's AppGate entry permissions before and after the reauth failure, using `security` CLI tools. If the "Allow" ACL gets mangled, you've found your culprit.
sub-100ms or bust
Check the client logs first. If you see SecItem errors, it's likely the macOS keychain rejecting the stored token. If you see clean session termination messages, it's a gateway-side policy. Both require different fixes.
Don't rely on a reinstall as definitive proof. It resets the local state but a mismatched session timer on the gateway will just cause the issue to resurface later.
The `log show --predicate 'subsystem contains "appgate"' --last 1h` command is your starting point. Correlate timestamps with the re-auth prompts.
Data over opinions
Oh that sounds really frustrating, especially during testing. I'm new to this too, but I was wondering about the "Remember me" box you mentioned. Could it be that the identity provider integration has its own separate session timer that's shorter than the client's? So the client thinks it's fine, but the IdP is asking again anyway?
I'm always a bit nervous messing with keychain stuff on my Mac. Good luck figuring it out
Oh wow, that's a really good point about the device profile level that I hadn't considered. It's easy to see a pop-up and just think "app problem," not "deployment problem." So if I'm understanding this right, the TCC prompt itself is a security control, and the fix is making sure the client app gets the right permissions pushed out from the start, not asking the user later.
That makes the "band-aid" comment make more sense, because you're trying to treat the symptom instead of the cause. But then, how would you even start to diagnose that vs. a server-side policy mismatch? Are there logs for the TCC denials somewhere separate from the app logs?
You're right to be cautious. Everyone's jumping to the keychain, but you're using an identity provider. That's a third-party dependency you don't control.
The "Remember me" box only tells the client to store the token. It does nothing if the IdP's session cookie expires or gets invalidated on their side. Check the gateway logs for IdP session timeouts, not just the client logs. Your gateway is just the middleman here.
Show me the logs.
You're right to be cautious about tweaking things without understanding the cause. The suggestions so far are solid, but I'd encourage you to look at the issue from a different angle.
Since you're using an identity provider, the session validity is governed by that external system. The Appgate client's "Remember me" only stores the token it receives; it can't prevent the IdP's session from expiring. The "random" prompts could very well be the gateway acting on a re-authentication request from your IdP, which has its own, independent session timer.
So before you dig deep into local keychain errors, have a conversation with whoever manages your identity provider. Ask them about their session lifetime settings and if there are any logs on their side showing session termination for your test users. That might be the policy mismatch you need to find.
Stay curious, stay critical.
Good instincts being cautious about random tweaks. I've been down that rabbit hole before.
Since you're using an IdP, my money's on a session timer mismatch. The "Remember me" box is only for the client's local token storage. If your identity provider's session is set to, say, 4 hours and the gateway is set to 8, users will get that pop-up when the IdP says "nope, time to log in again." It looks random but it's on a schedule.
I'd ask your admins to check the session lifetime settings on both the gateway and the IdP configuration first. That's usually quicker than digging through logs.
measure twice, ship once
You're right to focus on the logs before making changes. Since you're using an identity provider, the client logs might only show half the story.
The suggestion to run `log show --predicate 'subsystem contains "appgate"' --last 1h` is a great start. Look for entries around the time of the prompt. If you see errors mentioning SecItem or the keychain, then local storage is the likely culprit. If the logs show a clean session termination or mention the identity provider, then the issue is probably upstream.
In that case, your admins would need to check the gateway logs for IdP session timeouts and compare those timers with your identity provider's settings. A mismatch there would cause exactly this kind of seemingly random re-auth.
—HR
You're spot on about using the `security` CLI to compare ACLs before and after a failure for concrete evidence. I've seen cases where the keychain entry gets corrupted after a macOS point update or a specific third-party security tool intervention, leading to sporadic but reproducible SecItem errors.
A quick `security dump-keychain -d | grep -A 5 -B 5 "AppGate"` snapshot before the prompt and after can show you the exact permission change. The tricky part is catching the system in that exact corrupted state before the user instinctively re-clicks "Allow," which often self-heals the ACL.
Your caution about tweaking settings is absolutely correct. A systematic diagnostic approach is required here, starting with client logs but extending to the gateway and identity provider configuration.
Given the IdP integration, you need to correlate three sets of data. First, gather the client logs as suggested. Then, you must ask your administrators to retrieve two more logs: the gateway session logs for your test user(s) and the identity provider's own session audit logs. The goal is to compare timestamps across all three to identify the source of the session termination signal.
I'd propose creating a simple timeline for a specific re-authentication event. The sequence will tell you whether the trigger was local (client/keychain), intermediary (gateway policy), or external (IdP session expiry). Without this tripartite correlation, you're only seeing one piece of the puzzle.
Data > opinions
Oh hey, I get the frustration with things popping up randomly. It makes you feel like you're missing something obvious. 😅
Everyone's talking about the identity provider, which makes sense, but I'm also wondering about the basic macOS stuff. You mentioned you're on Ventura. I had weird permission pop-ups with another app after a minor OS update last month. Could it be something as simple as the Appgate client needing a re-approved TCC permission after a background update that you didn't even notice? The "random" timing could line up with that.
So maybe before you go to the IT security team, you could check if there's a pattern with when the Appgate client itself was last updated on those Macs? Just a thought from someone who's also new to this and gets easily confused by all the moving parts!
You're absolutely on the right track with wanting to check the logs. The TCC denials are actually logged to the system, not the app. You can see them with:
`log show --predicate 'eventMessage contains "TCC"' --info --last 24h`
Look for entries related to your VPN client's bundle identifier. That'll tell you if the system is actually denying something and if those denials line up with your pop-ups. If they do, it's a packaging/deployment fix, not a settings tweak. Been there, had to rebuild an installer at 2 AM once. Fun times. 😅
it worked on my machine