SOP — Set Up and Manage Microsoft Entra ID

Goal: stand up Entra ID as the identity provider for mptwork.com — strong authentication, Conditional Access, and single sign-on to Microsoft 365 and third-party (SaaS / on-prem) applications.

0. Prerequisites

• The mptwork.com tenant exists with the verified domain (M365 SOP).
• Entra ID edition determines available features:
  • Free — basic users/groups, security defaults, SSO to pre-integrated apps.
  • P1 (included in M365 Business Premium / E3) — Conditional Access, dynamic groups, SSPR with writeback, SCIM app provisioning, Application Proxy, group-based licensing.
  • P2 (included in M365 E5) — Identity Protection (risk-based Conditional Access), Privileged Identity Management, access reviews, entitlement management.
• Admin with Global Administrator (initial setup) moving to least-privilege roles (e.g., Authentication, Conditional Access, Application administrators).

Part 1 — Identity foundation

1. In the Entra admin center → Overview, confirm the tenant and that mptwork.com is a verified, default domain.
2. Choose the identity model:
   • Cloud-only (recommended for new orgs) — all accounts native in Entra.
   • Hybrid — sync from on-prem Active Directory with Microsoft Entra Connect (or Cloud Sync), using password hash sync (simplest) or pass-through authentication, and enable Seamless SSO for AD-joined devices.
3. Set Org branding (Entra → User experiences / Company branding): sign-in page logo, background, and a support contact — users see this at every sign-in.

Part 2 — Users and groups

1. Ensure users exist (created in the M365 SOP), e.g. jsmith@mptwork.com.
2. Create the groups that will drive access and policy (Entra → Groups → New group):
   • Staff-All (assigned or dynamic) — baseline policies.
   • Dynamic group example for staff: rule (user.userType -eq "Member").
   • App-access groups (e.g., App-Salesforce) for SSO assignment.
3. For hybrid, confirm users/groups are syncing from AD via Entra Connect.

Part 3 — Authentication methods (MFA and passwordless)

1. Combined registration: ensure users register security info at https://aka.ms/mfasetup (or mysignins.microsoft.com); enforce registration via a Conditional Access "register security info" policy.
2. Self-service password reset (SSPR): Entra → Protection → Password reset → enable for Staff-All, require two methods, and enable on-premises writeback if hybrid.
3. Move toward passwordless (Authenticator passkeys / FIDO2) for the strongest, phishing-resistant authentication, especially for admins.

Go to Entra → Protection → Authentication methods → Policies. This is the single place to enable and target methods. Recommended posture:

Part 4 — Conditional Access (the access policy engine)

Conditional Access (P1+) replaces security defaults with granular rules. Build each in report-only first, validate against sign-in logs, then enforce. Entra → Protection → Conditional Access → New policy. Exclude the bg-admin* break-glass accounts from every policy.

Baseline policy set:

Use Named locations to define trusted office IPs (e.g., mptwork.com HQ egress) and tune policies accordingly.

Part 5 — Single Sign-On (SSO)

Entra is the identity provider; users authenticate once and reach all assigned apps. Apps are managed under Entra → Enterprise applications.

5.1 Choose the SSO type

• SAML 2.0 — most SaaS apps (e.g., Salesforce, Workday).
• OIDC / OAuth 2.0 — modern apps (often "Sign in with Microsoft").
• Password-based — Entra stores and replays credentials for apps without federation.
• Linked — deep-link an existing SSO in the My Apps portal.

5.2 Worked example — SAML SSO to a gallery app (Salesforce)

1. Enterprise applications → New application → search the gallery for Salesforce → Create.
2. Open the app → Single sign-on → SAML.
3. Basic SAML configuration (values from the SaaS app's SSO settings):
   • Identifier (Entity ID): e.g. https://mptwork.my.salesforce.com
   • Reply URL (ACS): the app's assertion consumer service URL
   • Sign-on URL: the app login URL
4. Attributes & Claims: map identity claims, e.g. send user.userprincipalname as the NameID and user.mail as email.
5. SAML signing certificate: download the Base64 certificate or Federation Metadata XML.
6. Copy the Login URL, Microsoft Entra Identifier, and Logout URL from Entra and paste them into the Salesforce SSO configuration (upload the certificate).
7. Users and groups: assign the App-Salesforce group and any app roles.
8. Test SSO from Entra and from https://myapplications.microsoft.com.

5.3 Custom / modern apps

• For in-house apps using OIDC/OAuth, use App registrations: register the app, set redirect URIs, create a client ID/secret (or certificate), define API permissions and app roles, then expose it as an enterprise app for assignment.

5.4 Automatic user provisioning (SCIM)

• For supported apps, open the enterprise app → Provisioning → Automatic → enter the app's SCIM tenant URL and secret token → map attributes → assign the access group → Start provisioning. Users are created/updated/deactivated in the SaaS app automatically (P1+).

5.5 On-premises and the user portal

• Application Proxy (P1): publish internal web apps with Entra pre-authentication via a lightweight connector — no inbound firewall ports.
• My Apps portal (myapplications.microsoft.com): users launch all assigned apps from one place; SSO and self-service.

Part 6 — Privileged access and governance

1. Least privilege roles: assign the narrowest admin roles; keep standing Global Admins under five.
2. Privileged Identity Management (P2): Entra → ID Governance → PIM — make admin roles eligible (just-in-time, time-bound, approval-required activation) rather than permanent.
3. Access reviews (P2): periodically recertify group membership, app access, and admin roles.
4. Break-glass accounts (bg-admin1/2@mptwork.onmicrosoft.com): excluded from Conditional Access, monitored with sign-in alerts.

Part 7 — Identity Protection (P2)

1. Entra → Protection → Identity Protection: review risky users, risky sign-ins, and risk detections.
2. Feed risk into Conditional Access (Part 4): require MFA on medium+ sign-in risk and a secure password change on high user risk.

Part 8 — Monitoring and ongoing operations

Appendix A — SSO protocol decision

Appendix B — Notes and caveats

• Report-only first: roll out every Conditional Access policy in report-only, validate with sign-in logs, then enforce — and always exclude break-glass accounts.
• SAML certificates expire (typically 3 years): track each app's signing-certificate expiry to avoid an SSO outage.
• Phishing-resistant MFA (FIDO2 / passkeys / Windows Hello) is strongly recommended for administrators.
• Verify current steps against Microsoft Learn — the Entra portal layout and authentication-methods migration change frequently.