Domains

Use domains in Private Cloud Director to define identity boundaries that contain users, groups, tenants, and role assignments.

A domain is the top-level identity container in Private Cloud Director. Each domain holds its own users, groups, tenants, and role assignments, giving you a separate namespace for managing identity. Domains in Private Cloud Director 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.

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 Private Cloud Directordeployment).

• 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, Private Cloud Director 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
DNS Domain Name	DNS suffix used in VM hostnames at provisioning time.	Cluster blueprint configuration. See Overview & Architecture.
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.

Use a domain from the CLI and SDKs

When you download an OpenStack RC file from Settings > API Access, Private Cloud Director sets the domain environment variables for you. The default values target the default domain:

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.

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 for more details.

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.

• 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 ). Cross-tenant resource sharing within or across domains follows the standard networking and block storage ownership rules in Private Cloud Director.

• 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 for tenant quotas, user quotas, and VM leases.