PAM Segura Linux Access Without SSO – AD Users to Local Linux Accounts

[Danelame]

Hello colleagues,

I would appreciate your advice regarding PAM Segura implementation for Linux server access.

Currently, users authenticate to PAM through AD/LDAP, but SSO for Linux servers is not implemented and is not planned at this stage. Our DevOps team requires users to work with local accounts on the target Linux servers.

We are evaluating the following approach:

• Users authenticate to PAM using their AD accounts.
• Corresponding local accounts exist on Linux servers.
• Access to servers is granted only through PAM Segura.
• Session recording and audit logging are enabled.
• SSO is not being used.

We are trying to identify the most appropriate architecture from both security and operational perspectives.

We would appreciate hearing about your real-world experience:

1. How do you map AD users to local Linux accounts when SSO is not available?
2. Do you use shared SSH keys, individual credentials, or password vaulting for local accounts?
3. How do you manage password or key rotation for local privileged accounts?
4. Are you using Just-In-Time (JIT) access or temporary accounts?
5. Which approach was accepted by your security team and successfully passed audits?
6. What would you consider the recommended best practice for PAM Segura in this scenario?

Any recommendations, lessons learned, or implementation examples would be greatly appreciated.

Thank you in advance.

[tt-33]

I’m not sure if I understand the environment a 100%, but status quo seems like:

• You manage PAM, users login with their LDAP credentials
• DevOps at your company manages Linux servers, these are not domain joined, so AD login for users does not seem possible.
• Your company needs a full personalized audit trail against all systems

Does the DevOps team provision accounts on the Linux machines with the same name as AD credentials or do you expect Segura to provision them on demand?

---

1 - If there are pre-existing accounts with the same name on specific servers I’d use a PAM Core access policy which is scoped to the [#USERNAME#] variable:

• About filling out the Device and Username fields
• About Username alias (If the name on the server differs from the name used to login you could define additional aliases)
  → This way users are only able to see their own credentials

2 - If the user needs to be created you could bootstrap a JIT user via a service account:

• JIT User Creation Template for Ubuntu 23 (Example)
• How to configure a JIT credential (Docs, implementation mostly needs some trial and error…)

---

Password changing in general helps a lot to make sure access only goes through PAM. So I’d always recommend (if you have proper break glass processes in case of some emergency place).

Of course there are other possibilities like SSH Key based access. But to be honest, I think the whole SSH Key management process in Segura is really lacking and non intuitive at the moment.

Which frameworks/standards do you need to audit against?