Giving people access to resources
Every desktop, application group and web application you publish has its own access list. This page shows how to fill it in, how DartRelay works out what each person sees, and what to check when somebody cannot see something they should.
How access works
A person sees a resource on My Resources and may launch it when any one of these is true:
- the resource is open to All Authenticated Users;
- their own account is on the resource's list;
- one of their groups is on the list (an active portal user group, an Active Directory group, or a local Windows group).
Grants add up. Nothing on an access list takes access away; it only gives it. The same check runs twice: once when the portal draws the page and again when the person clicks to launch, so a resource that is not shown cannot be started by somebody who knows its address.
Two more things can hide a resource even when it is granted:
- A restricted category. If every category a resource is filed in is restricted and the person is not allowed in any of them, the resource is hidden and cannot be launched. See Categories, folders and icons.
- The address they use. A portal address can be limited to particular groups. That decides who may sign in there, not what they see once inside. See Who may sign in where below.
An administrator whose role allows portal access sees every resource in the portal, whatever its access list says. Test what a user will see by signing in as a user, not as an administrator.
The Access Control card
The access list is on the Access Control card of each resource, on both its Add page and its Edit page:
- Catalog → Desktops
- Catalog → Remote Apps (application groups)
- Catalog → Web Apps
The card asks "Who can see and launch this in the portal?" and offers two choices.
| Choice | What it does | Default |
|---|---|---|
| All Authenticated Users | Anybody who can sign in to the portal sees the resource. | — |
| Only Allowed (Restricted) | Only the users and groups you add below see it. A restricted resource with an empty list is visible to nobody. | — |
Restrict a resource to particular people
- Open the resource. For example, go to Catalog → Remote Apps and open an application group, or click to add a new one.
- Choose Only Allowed. The list of allowed users and groups appears underneath.
- Click Add users or groups. The picker opens.
- Choose where to look. The location list offers each sign-in source that is switched on in Authentication → Authentication Methods: Portal Users & Groups, one Active Directory entry for each domain on your Authentication → Directories list (with an (all domains) entry first when there is more than one), and the local Windows accounts of the DartRelay server.
- Search and pick. Type at least two characters of a name. For Active Directory, results show as
DOMAIN\name. Click each user or group you want; they collect on the right. - Close the picker and save the resource. Each entry on the list shows a badge saying what it is: Portal User, Portal Group, an Active Directory user or group, or a local Windows user or group.
Grant to groups rather than to individuals wherever you can. When somebody joins or leaves a team, you change one group in Active Directory or in Authentication → User Groups and every resource follows.
What each kind of entry matches
| Entry | Who it admits |
|---|---|
| Portal User | That one portal account. |
| Portal Group | Every portal account in the group, as long as the group is active. |
| Active Directory user | That domain account, in that domain only. |
| Active Directory group | Every member of the group, including members of groups nested inside it. A group in one domain is never confused with a group of the same name in another domain. |
| Local Windows user or group | Accounts on the DartRelay server's own local account list. A local group called Helpdesk is a different thing from a domain group called Helpdesk, and never grants the domain group's access. |
The picker stores each directory entry with its domain, for example CORP\Finance. Always add entries through the picker; a group name typed without its domain would match nobody.
When membership changes take effect
To keep the portal quick, DartRelay remembers each person's Active Directory groups for a short time instead of asking a domain controller on every page.
- By default the answer is kept for 120 seconds. After you add somebody to a group in Active Directory, allow up to two minutes before they see the new resource. Removing somebody takes effect within the same time.
- The time is set by
DartRelay:DirectoryGroupCacheSecondsin the server configuration file, from 0 to 3600. Setting it to 0 checks the domain controller on every page, which makes changes take effect immediately at the cost of more directory traffic. - If no domain controller can be reached, DartRelay shows the person nothing rather than guessing, and tries again on the next page. It never keeps a failed answer.
Portal user group changes take effect straight away.
What the host also needs
An entry on the access list lets a person launch a resource from the portal. The Windows host still decides whether that person may log on and run the program. Three things commonly get in the way:
- Remote Desktop Users. A host lets only administrators log on through Remote Desktop until users are added to its Remote Desktop Users group. When DartRelay installs the Remote Desktop Session Host role, it can add the host's own domain's Domain Users for you (the Let the domain's users sign in option). People from other domains need their own group added on the host by hand. See Adding and preparing hosts.
- Permission on the program file. If a program sits in a folder that only administrators may read, it starts for an administrator and fails for everybody else. When you save an application group, DartRelay checks this and warns you; grant the users Read & Execute on the program on the host.
- Which Windows account is used. A resource set to Pass-Through logs the person on with their own Windows account, so it needs a domain or local Windows sign-in. A resource with Fixed Credentials uses one saved account for everyone. See Publishing applications.
Who may sign in where
If you serve several customers or departments from one installation on different addresses, each address under Appearance → Tenancy & Branding has an Access page that decides who may sign in on that address. You can admit anybody who can sign in, only particular portal groups, Active Directory groups, organisational units or local Windows groups, or (for public use) anybody without a sign-in. The list on Appearance → Tenancy & Branding shows the result for each address: Everyone, a number of groups, Nobody (limited but with nothing left to admit) or Not in force (the address is disabled).
This is a gate on the door, not a leash on the person. Limiting an address stops other people signing in there; it does not confine its own people to it, and it does not change which resources they see. Full details are in Tenancy & Branding and Guest access without a sign-in.
Worked examples
Everyone gets Office, only Finance gets the accounts package
- The Office application group is set to All Authenticated Users.
- The Accounts application group is set to Only Allowed with
CORP\Financeon its list. - A new finance clerk is added to
CORP\Financein Active Directory. Within two minutes, Accounts appears on their My Resources page.
Two domains, one application
A company has staff in CORP and in a subsidiary domain SUB, both on the Authentication → Directories list. The payroll application lists CORP\Payroll and SUB\Payroll. Membership of one does not satisfy the other: a person in SUB\Payroll is admitted by the second entry, not the first. The host running payroll must accept logons from both domains and have both groups in its Remote Desktop Users group.
If something goes wrong
| Problem | What to check |
|---|---|
| "No resources have been assigned to your account yet." | Nothing on any access list matches the person. Check that the resource is set to Only Allowed with the right group, that the portal group is active, and that the person is really a member. Allow up to two minutes after an Active Directory change. |
| The resource appears for an administrator but not for a user. | Administrators with portal access see everything. Sign in as the user to check. |
| A resource granted through a group shows for some members and not others. | Check whether the resource is in a restricted category, and whether the missing members belong to a different domain from the one the group is in. |
| The resource appears, but launching ends at once with "Server refused connection". | The person is probably not in the host's Remote Desktop Users group. Add their group on the host. |
| The application tab says the host would not start the program. | The person has no permission to run the program file on the host. Grant Read & Execute to the users, then save the application group again; the warning on save disappears when it is fixed. |
| Nobody sees anything and the domain was recently unreachable. | DartRelay shows nothing when it cannot read group membership. Once a domain controller answers again, the next page load works. |
Related pages
Users and groups
Portal accounts and user groups.
Active Directory
Domains, sign-in names and the Directories list.
Categories and folders
Folders that can hide what is in them.
Publishing applications
Pass-Through and Fixed Credentials.