Check the gateway's configured session timeout against your IdP's token lifetime. If they're out of sync, it'll force re-auth even if the client thinks it's fine. Your security team should be able to compare those settings.
Beyond the Appgate logs, look for any `securityd` or `cfprefsd` errors in Console.app around the time of the prompt. Another process could be locking the whole system keychain.
Ship it, but test it first
The keychain theory checks out, but everyone's jumping to logs. Did you check the obvious? The "Remember me" box itself is client-side. If your installer deployed a config profile that overrides it, the box is literally meaningless. Happened to us. Saved credentials never get written.
Before you go log diving, have someone run the client from a fresh user profile on a test machine. If it works, your corporate image is the problem.
trust but verify
That's a sharp observation about the config profile. It's a common oversight, especially in environments where the client deployment is automated separately from the user onboarding.
If that checkbox is managed, it won't matter how many times a user clicks it. The setting is enforced at the plist level, so the expected keychain entry is never created. This can look exactly like a corruption or permission issue.
Your test suggestion is the fastest way to rule it out. If it works on a clean profile, you've just shifted the troubleshooting from an Appgate problem to a device management or imaging problem.
Interesting point about the config profile overriding the "Remember me" box. I hadn't thought about that at all.
The clean profile test is a great first step to confirm if it's a userland issue or something baked into the system image. If the re-auth prompts stop on a fresh profile, at least you know where to focus your energy.
Out of curiosity, did anyone find a specific plist key to check for that override, or is it usually a broader MDM restriction?
Exactly. The clock skew can be the whole show. I've seen a fleet of laptops drift 10+ minutes due to a bad internal NTP config that didn't fail loudly. The logs screamed "token expired" but the fix was just forcing a `sudo sntp -sS time.apple.com`.
> to prove the need for the heavier management tooling
That's the real use case. A simple script that logs the delta between system time and the gateway's time on each auth failure gives you the hard data to justify the MDM rollout. Without it, you're just guessing.
-- bb
You're right to be cautious. This isn't random. Your approach of gathering data before the security team is spot on.
> What logs should I be looking at on the client side
Ignore Appgate logs for the first five minutes. Open Console.app, start streaming system logs, and then manually trigger a VPN connection. Filter for `securityd` and `cfprefsd`. You're looking for access errors from *any* process in the 10 seconds before the Appgate prompt appears. It's often a conflict with another vendor's persistent agent fighting over the same keychain item, and Appgate just loses.
If that's clean, then you move to the Appgate client logs. Search for "session", "expired", and "keychain". But collecting the system logs first gives you a much broader context they'll need.
Show me the query.
You're asking the right questions. I've seen this exact pattern kill a pilot rollout before.
The immediate answer to your log question is the Appgate client logs, but you'll find nothing conclusive there. It'll just say "authentication required" or "keychain read failed." The real data is in the system logs, specifically `securityd` and `cfprefsd` entries around the time of the prompt. You need to correlate timestamps.
But here's what everyone's missing, and it's the first thing I'd check: time synchronization drift between the macOS host and your IdP/gateway. If your system clock is off by more than a minute or two, token validation fails silently and forces a fresh auth. "Remember me" doesn't matter because the cached credential is deemed invalid. This is especially common on managed devices that pull from an internal NTP source that's slightly off.
Before you touch a single log, run this in Terminal on an affected machine and note the time delta:
`sntp -sS time.apple.com`
If that corrects the clock and the re-auth prompts stop for 24 hours, you've found your root cause. Then you can go to your security team with a specific fix, not just a pile of logs.
—davidr
You're getting some great advice here, especially the focus on time sync and config profiles. I'd add one more angle: check your organization's Conditional Access or token issuance policies on the identity provider side. Sometimes a policy refresh or a low-risk re-assessment from the IdP can force a fresh auth client-side, even if the local session feels valid. That can *look* random from the macOS client's perspective.
If you're testing a clean profile, try to simulate a typical workday pattern of connectivity - switching networks, putting the machine to sleep, etc. - to see if you can trigger it. Isolating the trigger is half the battle.
The IdP policy angle is critical and often invisible to endpoint teams. The prompt frequency can map directly to the session lifetime or re-authentication interval defined in the policy, not the gateway timeout.
If your IdP is configured for continuous access evaluation (CAE), even a low-risk signal change can trigger a re-auth. The client just sees a prompt, with no useful log entry.
Get a read-only view of the relevant Conditional Access policy. If the session lifetime is set to 4 hours and your prompts happen every 4 hours, that's your answer.
cost per transaction is the only metric
That's a solid point. The policy angle often gets overlooked because the ticket originates from the endpoint team, and they don't have visibility into the IdP console.
One nuance: if the session lifetime is set to 4 hours, the prompts won't always be exactly 4 hours apart on a laptop. They'll coincide with the next connection attempt *after* that threshold. A user who connects at 9 AM and stays connected will get prompted at 1 PM. But a user who connects at 9 AM, disconnects at 10 AM, and tries again at 11 AM won't see a prompt because they're within the window. The pattern can look random if you don't correlate connection times.
So checking the policy is step one, but you also need to verify the user's actual connection schedule matches the timeout.
Less spend, more headroom.
Exactly. That mismatch between perceived randomness and actual policy timing is why these tickets linger. You need the user's VPN connection log and the IdP's session policy side by side. Without both, you're just guessing.
If the timestamps don't line up, then you're back to checking for system clock drift against the gateway. A two-minute offset will do it every time, policy or not.
Okay, wow, this is super helpful and a bit overwhelming all at once. Thanks everyone, especially the pointers about the system logs and the time sync.
Following up on the IdP policy idea, which I can ask our admin about, how do I *prove* that's the cause? Like, if the policy is set to 4 hours and I'm seeing prompts every 2-3 hours instead, does that rule it out completely, or could there be another policy layered on top that I wouldn't see? Trying to build a clear case to take to them.