Skip to main content

Selection Guide · Business Email and Collaboration

Selecting Hybrid Identity: AD, Workspace and Microsoft 365

Authoritative source, synchronization and SSO are separate hybrid-identity decisions. Local AD may be the source while Workspace or Entra acts as an application identity provider. Avoid…

Technical review:

Architecture and operating model

Authoritative source, synchronization and SSO are separate hybrid-identity decisions. Local AD may be the source while Workspace or Entra acts as an application identity provider. Avoid circular designs in which both systems overwrite the same user.

Review Windows join, file ACLs, application protocols and device management. Workspace/Microsoft 365 selection is not just an email-interface choice; identity lifecycle and app integration drive operating cost.

Central SSO affects availability during identity-service failure. Pilot protected emergency accounts, legacy exceptions and offboarding. Synchronization does not automatically configure MFA or revoke all sessions.

  1. 1Identity source
  2. 2Sync/provisioning
  3. 3SSO/device
  4. 4Outage/offboarding
Identify the authoritative source.

Design parameters

Source ownership
Define one authoritative writer for names, email, groups and roles.
Application protocol
Inventory LDAP/Kerberos, SAML/OIDC and SCIM needs separately.
Outage plan
Keep emergency identity and audit access independent of normal SSO.

Worked example

Of 100 users, assume 70 use Windows/AD applications and 30 browser apps. Pilot joining, renaming and leaving for both profiles. Do not force multiple platforms when duplicate licenses/identity sources are unnecessary; calculate existing dependencies and exit cost.

Troubleshooting

ObservationLikely cause / distinctionVerification
Rename splits identityMatching uses a mutable username instead of stable ID.Check stable ID/target-account linkage.
IdP outage locks everyone outNo emergency identity/independent path.Exercise a preapproved break-glass scenario.

Acceptance checks

  1. Identify the authoritative source.
  2. Map protocol dependencies.
  3. Verify MFA scope separately.
  4. Pilot account renames.
  5. Test IdP outage.
  6. Complete offboarding/data ownership.

Related concepts

Authentication and sessions

Authentication proves who a user or workload is; authorization determines what that identity may do. Successful sign-in does not grant access to every resource. User sessions, service identities, API tokens and device certificates have different lifecycles. Design session duration, token renewal, employee departure, lost-device handling and emergency access alongside initial sign-in. Measure which existing sessions remain usable and which new accesses are denied when the identity provider becomes unavailable.

Dependencies and restart order

Services commonly depend on identity, DNS, time, networking, databases and licensing. Record a dependency graph describing conditions for operation, not merely an equipment list. Recovery order follows that graph; circular dependencies may require emergency access paths. Distinguish restored infrastructure from resumed business activity. Assign an owner, validation method and alternative access path to each dependency. Test assumptions by deliberately making one component unavailable in a controlled end-to-end exercise.

Availability versus recovery

High availability aims to keep service running through specified failures with a short interruption; backup recovers lost or corrupted data from an earlier point. A cluster can replicate an accidental deletion to another node. HA therefore does not replace backup. Consider DNS, identity, network, storage and power dependencies together. Successful node failover is insufficient by itself: measure user sessions, application writes and external integrations after the transition as well.

File permissions and service identities

File access combines users/groups, permission bits, ACLs and security policies. Running an application as root can hide permission problems; prefer a justified, restricted service identity in production. Directory traversal permission differs from file-read permission. Sharing permissions do not necessarily override filesystem restrictions. Identify the actual runtime user, directory chain and ACLs when troubleshooting. Test narrowly required access rather than opening permissions globally.

Version and support lifecycle

Installability does not prove production support. Review the compatibility chain across OS, application, drivers, extensions and management tools. Update plans should record version, support end, restart needs and rollback methods. An unrepresentative test environment can produce misleading results. Validate service health and existing workflows after a change, not just version numbers. Remember that pinning a version can also prevent future security fixes.

Cost boundaries

Cost includes more than purchase price or a monthly resource bill. Licensing scope, storage, egress, backup, support, operating effort and disruption impact are separate items. Compare equal service levels, capacity and time periods; a cheaper option may exclude an obligation. Compare forecast and actual spending by resource or business unit. Assess underuse risk for commitments and uncontrolled growth for flexible models. Verify pricing and licensing conditions against official documents at decision time.

Primary documentation

Prepared by the Doz Teknoloji technical team using the primary references below. Calculations and lab scenarios state their assumptions; validate the applicable product version before rollout.

Knowledge Center

Enterprise IT Product Sales, Licensing and Deployment
Enterprise IT Project & Solution Scenarios
View all related content
Text on WhatsApp
Copied!