Skip to content
GitHubLinkedIn

Identity & server access

For server details (OS, IPs, and what runs where), see Servers.

Microsoft Entra ID is LEF’s primary identity provider. When a system supports SSO, we prefer integrating it with Entra so access and MFA are centrally managed.

Entra is also the identity backbone for Microsoft 365 (see Microsoft 365).

Some identities are synchronized from Active Directory (core.lef) into Entra using Entra Connect. This matters for Microsoft 365 sign-in and for SSO patterns that rely on synced identities.

See Entra Connect (AD sync) for scope, OU filters, and UPN suffix rules.

  • Access portals (VPN, EVEO portal, Vault): see Access.
  • Service/admin URLs (DNS, S3, Kanban, Workflow, etc): see Services.

See the Servers overview for the canonical list of login targets and service accounts by host group.

If you see older documentation referencing short hostnames like tools.lef, proxy.lef, or tokio.lef, use the canonical *.core.lef hostnames in Servers.

Perimeter ingress and VPN access are provider-managed. See Firewall & public ingress.

  • Use SSH: ssh <user>@<login-target>
  • Prefer personal accounts; use privileged accounts only when required and approved.
  • Prefer DNS hostnames in configs; IPs are for troubleshooting.
  • Use Remote Desktop to rds.core.lef (VPN/LAN required).
  • Certificate binding guidance: see Remote Desktop SSL.
  • Not on VPN → internal DNS and services are unreachable.
  • Public hostname resolves to public IP from inside LAN → use split-horizon DNS (see DNS split horizon).
  • Wrong account or missing rights → follow the access control policy and request the right role/group.
  • Local/shared accounts outside Entra become “invisible” to access reviews; avoid them unless required.
  • Duplicating credentials across systems increases offboarding risk; prefer SSO.