Can I assume that with both OPA and ASA, that SSHD will use the following fields from these local files on the Linux server?

/etc/passwd

name:password:UID:GID:GECOS:directory:shell

/etc/shadow

login name:encrypted password:date of last password change:minimum password age:maximum password age:password warning period:password inactivity period:account expiration date:reserved field

We currently store the above fields (or their translated equivalents) and the below ones for sudo in Active Directory:

objectClass: top; sudoRole;

name: rootusersrule;

sudoRunAsUser: root;

sudoOrder: 100;

sudoOption: !authenticate;

sudoHost: +thisgroupofservers;

sudoCommand: ALL;

sudoUser: %admins;

objectClass: top; nisNetgroup;

name: thisgroupofservers;

nisNetgroupTriple: (linuxserver1.example.com,-,example.com);(linuxserver2.example.com,-,example.com);(linuxserver2.example.com,-,example.com);

How does the ScaleFT agent/client/tools work with sudo on the Linux server in order to provide these? It would appear from the demos that they are stored centrally in Okta somehow - is that true? Is it done the same way for both OPA and ASA?

does the Advanced Server Access linux agent replace its native Pluggable Authentication Modules infrastructure?

Okta Advanced Server Access group:

In order to permit SSHD access to a Linux server....

does the Advanced Server Access linux agent replace its native Pluggable Authentication Modules infrastructure? Does it also replace the SSSD or does it integrate with them?

If you can provide links on the detail for me that would be appreciated.

Currently sshd is using PAM/SSSD/LDAP/Kerberos to Active Directory for authentication & authorization.

Trying to understand how the ASA stack on linux would replace or work alongside what we know.

I do see these:

https://help.okta.com/asa/en-us/content/topics/adv_server_access/docs/user-attributes.htm

https://help.okta.com/asa/en-us/content/topics/adv_server_access/docs/user-management-linux.htm

So it sounds like it could work.

Thanks,

Tim