
StephenC.92115 (Customer) asked a question.
At this time, all my employer wants from Okta on Linux is 2FA. We prefer that authorization remain with locally created accounts and groups. We also do not want Okta providing sudo entitlements. In a recent conference call it was implied that letting Okta control authorization was essential to ASA working correctly but I am hoing that interpretation of what was said is incorrect.
Can the creation of accounts and groups be turned off?

Hello @StephenC.92115 (Customer),
Can you give us details of what you want to change on your setup, I understand that you want to change the authentication from external users (Okta Users) to local users, is this correct?
Regards,
Natalia
Okta Inc.
Not exactly. I am OK with authentication happening through Okta. We only use it to the jump host anyway. It is the authorization part that I am concerned about.
Okta seems to like creating accounts on the fly. Those accounts can be configured to be deleted when the person logs off but I've encountered a persistence that could make this automatic creation a security risk. In one test I was able to copy the state.json file from one client to another and Okta happily logged me in from the second client without any challenge.
The Linux access model is a little different from Microsoft's AD. It is closer to how Cisco manages authentication and authorization on its switches. Authentication may be local or centralized (TACACS, Radius, Kerberos, etc) but privileges (authorization) is still local.
Thank you for your reply.