svfbd (svfbd) asked a question.
I am currently evaluating Okta and Advanced Server Access for our organisation.
What I would like is to demonstrate to management that each time you run "sft ssh" you have to respond to MFA challenges for each connection. Second prize would be to at least have to require authentication regularly, say, every hour.
I successfully created and "sft ssh" to a test server yesterday, but now I am struggling to get to a state where I actually need to authenticate before I can recreate a connection.
No matter what I do, every time I run "sft ssh", even when it prints out "Waiting on browser", a browser window with Okta branding pops up briefly, but then, without any interaction at all (no password prompt, no choosing of second factor, no nothing), the browser immediately disappears and the SSH proceeds successfully without any authentication having occurred at all.
What I tried:
- Create a 30 day trial Okta Workforce Identity account and set up our company Google Workspace as a "Social" identity provider for it.
- Created a Advanced Server Access team and linked it to the trial Okta.
- Created an Authentication Policy inside the trial Okta account that requires password + another factor for access for all users, with both factors needing re-authentication on every attempt. Then I made sure that the Advanced Server Access application in Okta uses that policy.
- Inside the Advanced Server Access web admin console, changed the Team Settings to set the Client Session Duration to minimum (1 hour) and the Web Session Duration to minimum (30 minutes)
- Inside the Okta Admin Console created a Global Session Policy applicable to all sessions setting the Maximum session lifetime to 30 minutes and the idle session timeout to 10 minutes.
Then I left my computer for 2 hours, came back, and ran "sft ssh", and again it just succeeded, with a browser briefly popping up, but not requiring any interaction.
Next I tried revoking the client in the Advanced Server Access web admin console. I did have to run "sft enroll" on the client again, but again, a browser briefly popped up, disappeared without any interaction, and the enrolment succeeded. Not even after re-enrolling did I need to authenticate for "sft ssh" to succeed.
This morning I ran "sft ssh" while the client session duration was 12 hours. Do I have to wait for that session to expire before the new session durations take effect?
Why does Advanced Server Access not honour the "re-authentication on every attempt" setting?
After the previous 12 hour sft client session definitely expired, I tried "sft ssh" again. I was presented with a browser challenge, but only needed to accept an Okta Verify push notification, not a password challenge.
That despite the fact that the Sign-On policy for ASA in Okta is "Access:Allowed with password + another factor" and both factors are set to re-authenticate on "Every sign-in attempt".
Worse, when I ran "sft logout" and then ran "sft ssh", again, a browser popped up, but all I needed to do was click an accept button in the browser. I was not challenged with ANY authentication factor at all.
It is getting harder and harder to see ASA as a step up in security if it makes it so trivial to gain access to servers.
Hi Pieter,
The sign-on policy is evaluated when the user accesses the ASA console via the Okta Dashboard or the sft command line. Once the sft session is active, it will not check the sign-on policy until the session expires.
Cheers,
Andy