# Domains

A domain is the top-level identity container in <code class="expression">space.vars.product\_name</code>. Each domain holds its own users, groups, tenants, and role assignments, giving you a separate namespace for managing identity. Domains in <code class="expression">space.vars.product\_name</code> follow the same identity model as OpenStack Keystone.

A domain is an identity boundary, not an infrastructure partition. Compute hosts and virtual networks are owned by the region. Volumes and VMs are owned by tenants. None of these are owned by domains. Adding a domain adds an identity namespace; it does not allocate hardware. To learn how resources are owned, see [Tenants & Region](/private-cloud-director/2026.1/identity-and-multi-tenancy/tenant.md).

### When to use multiple domains

Most single-organization deployments operate within the built-in `default` domain. Create additional domains when you need to:

* Keep two or more user populations in separate identity namespaces (for example, to host distinct business units or customers on the same <code class="expression">space.vars.product\_name</code>deployment).
* Configure a different SAML 2.0 identity provider for each domain. All users in a domain authenticate through the same identity provider. It is not recommended to mix identity sources within a single domain.
* Delegate user and group administration to a domain administrator without granting access to identities in other domains.

### What a domain contains

A domain contains the following identity entities:

* **Users.** Local or federated user accounts. Usernames must be unique within a domain; the same username can exist in two different domains.
* **Groups.** Collections of users in the same domain. Role assignments granted to a group apply to all of its members.
* **Tenants** (called `projects` in the API and CLI). Tenants are the unit of resource ownership. All Private Cloud Director resources, like virtual machines, virtual networks, routers, security groups, volumes, images, and floating IPs, belong to a tenant. Tenant names must be unique within their owning domain.
* **Role assignments.** A role assignment is a 3-tuple consisting of a role, a resource, and an identity. The resource is either a tenant or a domain. The identity is either a user or a group.

A user can hold role assignments in multiple domains and multiple tenants at the same time.

Domains are flat. You cannot nest one domain inside another. Tenants can be hierarchical; domains cannot.

### The default domain

Every Private Cloud Director deployment ships with a built-in domain named `Default` (ID `default`). When you create a user, group, or tenant without specifying a domain, <code class="expression">space.vars.product\_name</code> places it in the default domain.

### Domain name

A domain has a `name` attribute that is a free-form string identifier. The name must be unique across the deployment. Examples: `default`, `acme-corp`, `customer-42`.

The domain name is not a DNS hostname. Several Private Cloud Director features use the word `domain` in different context, here is a guided list:

| Concept                           | What it is                                             | Where it appears                                                                                                                              |
| --------------------------------- | ------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------- |
| Keystone domain name              | Identity namespace identifier (a string).              | Login screen, RC files, `pcdctl` and `openstack` CLI.                                                                                         |
| Management plane FQDN (`DU_FQDN`) | DNS hostname of the Private Cloud Director UI and API. | Installer, [Enterprise SSO](/private-cloud-director/2026.1/identity-and-multi-tenancy/enterprise-sso.md)                                      |
| DNS Domain Name                   | DNS suffix used in VM hostnames at provisioning time.  | Cluster blueprint configuration. See [Overview & Architecture](/private-cloud-director/2026.1/virtualized-networking/networking-overview.md). |
| DNSaaS zone                       | Managed DNS namespace (such as `example.com`).         | DNS as a Service.                                                                                                                             |

### Sign in to a domain

The Private Cloud Director login page has a field labeled **Domain**. Enter the name of the Keystone domain you are signing in to. The default value is `default`.

To sign in:

1. Open the Private Cloud Director URL in a browser.
2. In the **Domain** field, enter your domain name. Leave it as `default` for the built-in domain.
3. Choose how to authenticate:
   * Choose **Use local credentials** to authenticate against the local identity backend.
   * Sign in with SSO if your administrator has configured an identity provider for the domain.
4. Enter your credentials.

For multi-factor authentication, see [Login with Multi-factor Authentication](/private-cloud-director/2026.1/identity-and-multi-tenancy/login-with-multi-factor-authentication.md).

### Use a domain from the CLI and SDKs

When you download an OpenStack RC file from **Settings > API Access**, <code class="expression">space.vars.product\_name</code> sets the domain environment variables for you. The default values target the `default` domain:

```bash
export OS_AUTH_URL=https://<DU_FQDN>/keystone/v3
export OS_IDENTITY_API_VERSION=3
export OS_USER_DOMAIN_NAME=default
export OS_PROJECT_DOMAIN_NAME=default
export OS_PROJECT_NAME=<tenant-name>
export OS_USERNAME=<username>
export OS_PASSWORD=<password>
export OS_REGION_NAME=<region>
```

`OS_USER_DOMAIN_NAME` and `OS_PROJECT_DOMAIN_NAME` are read by `pcdctl`, the OpenStack CLI, the OpenStack Python SDK, the Terraform OpenStack provider, and the Ansible `openstack.cloud` collection.

To list the domains visible to your account, see [PCD CLI - pcdctl](/private-cloud-director/2026.1/reference/pcdctl-command-line.md).

### Configure SSO at the domain level

You can configure SAML 2.0 SSO per domain so users in that domain authenticate with their corporate identity provider.

To set up SSO for a domain:

1. Review the Enterprise SSO overview.
2. Follow the provider-specific guide. See [Enterprise SSO](/private-cloud-director/2026.1/identity-and-multi-tenancy/enterprise-sso.md) for more details.&#x20;

The DNS FQDN you use in the SAML configuration (`DU_FQDN`) is the management plane URL. It is not the Keystone domain name.

### Considerations

Keep these points in mind when you plan a multi-domain deployment:

* **Hosts onboard into the default domain.** In a multi-domain environment, hypervisor host onboarding must be performed by the user with the Administrator user in the `default` domain, not in a secondary domain. See [Pre-requisites](/private-cloud-director/2026.1/getting-started/pre-requisites.md).
* **Resource ownership is at the tenant level.** Networks, volumes, and VMs belong to tenants. To share a network across tenants, mark it as shared (see [Physical Network](/private-cloud-director/2026.1/virtualized-networking/physical-network.md) ). Cross-tenant resource sharing within or across domains follows the standard networking and block storage ownership rules in <code class="expression">space.vars.product\_name</code>.
* **Roles do not cross domains automatically.** A user with the Administrator role on domain A is not automatically an administrator on domain B. Grant cross-domain access by creating an explicit role assignment in the second domain.
* **Quotas are enforced per tenant.** See [Tenants & Region](/private-cloud-director/2026.1/identity-and-multi-tenancy/tenant.md) for tenant quotas, user quotas, and VM leases.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.platform9.com/private-cloud-director/2026.1/identity-and-multi-tenancy/domains.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.