Active Directory and multiple domains

This page shows how to let people sign in to the portal with their Active Directory accounts, how DartRelay decides which domain a sign-in belongs to, and how to work with several domains, including domains your server's domain does not trust.

Before you begin

• Switch on Domain Users. Go to Authentication → Authentication Methods and switch on Domain Users. Nothing on this page applies until it is on.
• Run DartRelay on Windows. Active Directory sign-in uses Windows' own directory functions.
• Join the DartRelay server to a domain where you can. A joined server finds its own domain and any trusted domains by itself. A server that is not joined can still use domains it can reach, as described under Domains with no trust.
• Prepare the hosts. Each host must be joined to the person's domain, or to a domain that trusts it, and must let that domain's users log on through Remote Desktop. See Adding and preparing hosts.

Signing in with a domain account

People sign in to the portal with the same username and password they use for Windows. They can type their name in any of these forms:

A plain name is first checked against DartRelay's own portal accounts, then the domain, then the server's local Windows accounts. A name typed with a domain goes to that domain only.

Groups, entitlements and the Windows logon on the host all follow from the domain account. A person signing in as SUB\alice is always treated as SUB's alice, with SUB's group memberships, even if another domain has an account with the same name.

The Directories list New in 2.0

Authentication → Directories lists every Active Directory domain DartRelay accepts. Only domains on this list, and enabled, can sign in. A name that points anywhere else is refused with the message "X is not a domain this address signs in to", and no domain controller is contacted, so a mistyped domain never counts as a bad password against anybody's account.

How the list fills itself

• This server's domain is added automatically on a domain-joined server and marked This server's domain. It cannot be removed while the server is joined to it, only disabled.
• A domain named in the configuration file. If your configuration file had a domain set in DartRelay:AdDomain from an earlier version, that domain is added once and becomes the default, because it is what a plain username meant before. The page then shows a notice asking you to remove the key from the file; it is no longer used.
• The default. If nothing else has been chosen, the server's own domain is the default.

Add domains your server trusts

1. Open the Directories page. Go to Authentication → Directories.
2. Click Add from trusts, then Find trusted domains. DartRelay lists every domain in your forest and every domain your domain trusts directly, each with its relationship in plain words: This server's domain, Same forest, Trusted, users can sign in, or Trusts us, users cannot sign in here. The last kind is shown so you know why it is missing, but cannot be added.
3. Tick the domains you want and add them. Each is added with its DNS name and NetBIOS name already filled in.
4. Open each new row and click Test a user with a real account name, to confirm the domain answers and its groups can be read.

You can also use Add a domain by name and type a DNS name such as sub.corp.example.com. If the name cannot be found, the message gives both possible reasons: no such domain, or no domain controller answered.

Check again asks Windows for the trust list again, for example after the server has been joined to a different domain. It can take up to about 40 seconds.

Order, enable and default

• Move up / Move down sets the order of the Domain list on the sign-in page.
• Enable / Disable stops a domain signing in without removing its settings. The default domain cannot be disabled or removed; choose another default first.
• The Signing in section sets the installation-wide default domain (where a plain username goes) and whether the Domain list appears on the sign-in page.

With a single domain, the sign-in page looks exactly as it always has. The list appears on both the portal sign-in page and the console sign-in page, labelled with each domain's display name. If somebody types a domain in front of their name, what they typed wins over the list.

The domain's own settings

Open a domain on the list to edit it.

The domain's sign-in suffixes (UPN suffixes) are read from Active Directory automatically, when DartRelay starts, when you save the row and when you test a user. You do not type them.

How sign-in finds the domain New in 2.0

DartRelay sends each sign-in attempt to exactly one domain and never tries a password against several domains in turn. Trying each in turn would add a bad-password count in every domain and could lock out people who have the same username in two domains.

1. DOMAIN\name goes to the listed domain with that name, or is refused without contacting anything.
2. name@suffix goes to the listed domain that owns the suffix. In a forest, DartRelay finds which domain really holds the account, and that domain must also be on the list.
3. A plain name goes to the domain picked in the Domain list, if shown, or to the default.

The part after DOMAIN\ must be a plain account name. Forms such as CORP\OTHER\bob are refused as invalid.

Sign-in domain for each address New in 2.0

If you serve different organisations on different addresses, each address can have its own default domain and its own Domain list. Go to Appearance → Tenancy & Branding, open the address, choose Access, and use the Sign-in domain on this address card. The card appears once the Directories list exists.

An address can narrow sign-in, never widen it. A domain that is disabled on the Directories page cannot be offered on any address.

The theme's sign-in block also has a Domain dropdown position setting: between the username and password (the default), above the username, below the password, or hidden. See Building the sign-in and home pages.

Example: one address, one domain

A provider hosts two client companies. portal.alpha.example should accept only Alpha's domain, and users should type just their name.

1. Add both domains on Authentication → Directories.
2. Open Alpha's address under Appearance → Tenancy & Branding and choose Access.
3. Set Default domain to Alpha's domain, set the list to Hide, and tick Only the default domain signs in on this address. Save the card.
4. Check it. On that address, alice signs in as Alpha's alice with no Domain list shown, and a Beta user is told Beta "is not a domain this address signs in to".

This is a gate on the door. A Beta user can still sign in on Beta's own address, or on any address that offers Beta's domain.

Domains with no trust New in 2.0

Sometimes the people you serve are in a domain that has no trust with the DartRelay server's domain, for example a separate company's forest. DartRelay can still sign them in by talking to that domain's own domain controllers directly.

1. Make the domain reachable. The DartRelay server must be able to resolve the domain's DNS name and reach its domain controllers on the directory ports (389, or 636 for LDAPS). A conditional forwarder on your DNS server is the usual way.
2. Add it by name. On Authentication → Directories, click Add a domain by name and type its DNS name. Because no trust covers it, it is added as Separate (no trust) and its settings open.
3. Enter a service account. In the Connection card, under Service account, enter any ordinary user account in that domain and its password. DartRelay uses it only to look up accounts and read group membership. The password is stored encrypted and is never shown again. Until a service account is saved, the list shows Needs a service account and the domain cannot sign in.
4. Choose the connection security. By default DartRelay connects on port 389 with signing and encryption. You can choose LDAPS instead; if you do, list the domain controllers by name under Domain controllers, because their certificates rarely carry the bare domain name.
5. Click Test connection. It tries the details as typed, without saving, and reports the server reached, the identity it signed in as, the connection security and whether the domain could be read.
6. Save, then click Test a user with a real account to confirm sign-in and group lookup.

Changing the service account, the domain controllers or the LDAPS setting asks for the password again.

LDAPS certificates from the other organisation

If you choose LDAPS and the domain controller's certificate comes from the other organisation's own certificate authority, the DartRelay server will not trust it. Rather than installing that authority on your server for every purpose, use Trust this certificate for this domain. DartRelay shows the certificate's fingerprints, says whether the certificate was confirmed against the domain's own directory, and whether it trusts the authority (which survives the domain controllers renewing their certificates) or a single domain controller certificate (which has to be trusted again after renewal). Trusting needs the service account password typed and working. Stop trusting removes it.

What works differently with a separate domain

• Only that domain's own groups count. Groups from other domains of that forest are not read.
• Hosts that serve these users must be joined to that domain. When DartRelay installs the session host role on such a host, it can add that domain's Domain Users to Remote Desktop Users.

Passwords at launch

For resources set to Pass-Through, DartRelay logs the person on to the host with the password they signed in with. If that password is no longer held, for example after DartRelay has restarted or on another server in a pool, the portal asks for the Windows password once in a small prompt and then carries on with the launch. To avoid the prompt altogether, see Relay Pass.

If something goes wrong

Related pages