Entra Id Domain
To set up an entra id domain, you register your custom DNS name and verify ownership. Then you link that domain to your user accounts and security groups. Most teams start by mapping broad directory groups to database and server roles. When those roles are too wide, one login gives full control over production data. How an entra id domain works in your directory Every new tenant starts with a built-in default domain name from the cloud provider. Teams add their own company domain so staff can
Microsoft Entra ID (Azure AD) + Cross-Domain SSO: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
To set up an entra id domain, you register your custom DNS name and verify ownership. Then you link that domain to your user accounts and security groups. Most teams start by mapping broad directory groups to database and server roles. When those roles are too wide, one login gives full control over production data.
How an entra id domain works in your directory
Every new tenant starts with a built-in default domain name from the cloud provider. Teams add their own company domain so staff can log in with work emails. To prove you own the domain, you place a text record in DNS. The directory reads that DNS record and marks the domain as ready for use.
Once the domain is active, admins create users and groups under that verified name. You can also sync users from an on-premise directory to keep names matched. Each user gets a single identity that works across cloud apps and backend tools. When a person leaves the team, disabling that one account blocks their login everywhere.
Groups in the domain help teams assign permissions without touching single user accounts. Admins put engineers into a group and tie that group to a role. When a user logs in, the directory sends a token with their group claims. The target system reads the token and grants the matching role for that session.
Howfederated versus managed domain login flows work
Teams can run a domain in either a managed or a federated mode. In a managed setup, the cloud directory checks passwords and handles multi-factor prompts directly. This keeps the setup simple because you do not run extra login servers. Most cloud-first teams pick this path to cut down on maintenance work.
In a federated setup, the cloud directory sends login requests to an outside provider. Your own identity server checks the user password and runs local security rules. After the check passes, that server sends a signed assertion back to the directory. Federated mode helps when rules require on-premise password checks or custom hardware keys.
Microsoft Entra ID (Azure AD) + Cross-Domain SSO: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What domain roles solve and where gaps remain
A verified domain gives your team a single place to manage who logs in. It stops password reuse across tools and lets you require strong multi-factor checks. You can see every sign-in event and block risky accounts from one central screen. For basic app login control, this directory setup does the job well.
Still, directory roles only decide who can open a session to a system. Once a database or server accepts the login token, the directory steps back. It cannot inspect the SQL queries or shell commands that run inside that session. If an engineer has a read-write role, they can drop tables or dump records.
Shared roles also make audits hard when many engineers map to one database user. The directory log shows when the user signed in to start work. Yet the database log only shows the shared role name next to each query. Teams also lack a way to mask emails, phone numbers, or card numbers in results. To fix this, you need controls that act on each command in flight.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
Why do I need to verify a custom domain in the directory?
Checking DNS proves your company owns the domain name before you assign user emails. It prevents other tenants from claiming your company name or spoofing your users.
Can one tenant hold more than one verified domain name?
Yes, a single tenant can hold many verified domain names for different brands. You pick one primary domain as the default for new user accounts.
Does a directory domain control what queries a user runs after login?
No, the directory only checks identity and passes group claims during the login step. It does not inspect, block, or mask individual queries inside an active session.