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.
- 1Identity source
- 2Sync/provisioning
- 3SSO/device
- 4Outage/offboarding
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
| Observation | Likely cause / distinction | Verification |
|---|---|---|
| Rename splits identity | Matching uses a mutable username instead of stable ID. | Check stable ID/target-account linkage. |
| IdP outage locks everyone out | No emergency identity/independent path. | Exercise a preapproved break-glass scenario. |
Acceptance checks
- Identify the authoritative source.
- Map protocol dependencies.
- Verify MFA scope separately.
- Pilot account renames.
- Test IdP outage.
- 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.