Guest access without a sign-in

Guest access lets people open the portal without signing in. Visitors are signed in silently as one portal account you choose, the guest account, and see whatever that account is allowed to see. Combined with an automatic launch rule, a visitor can open an address and land straight in an application. This page explains how to set it up safely.

When to use it

• A public or customer-facing application that anybody with the address may use, such as a catalogue, a booking tool or a demonstration.
• A kiosk or shared terminal where nobody should have to sign in.
• One address of a multi-tenant installation that is public, while other addresses stay sign-in only.

Guest access is off by default, everywhere. Turning it on for one address never opens any other address.

How it works

• You choose one guest account: an ordinary portal account. Every visitor is signed in as this account, so it is that account's access list, user groups and automatic launch rules that decide what visitors get.
• You choose where visitors are admitted: on addresses that have no tenant binding, on particular tenant addresses, or both.
• Each visitor still gets their own Windows session and their own file transfer folder. Visitors never share a session with each other, and each visitor's device takes one Relay Seat while they have a session open.
• Staff can still sign in with their own accounts on a guest address by opening the sign-in page with ?signin=1 added, for example https://apps.example.com/portal/login?signin=1.

Before you begin

1. Create the guest account. Under Authentication → Users, create a portal account, for example guest. It must be active, must not be an administrator, and must not be waiting for a password change. Give it a strong password that nobody needs to know. See Users and groups.
2. Grant it what visitors should see. Add the guest account (or a user group it is in) to the access list of each resource visitors may use, and to nothing else. See Giving people access to resources.
3. Use a saved Windows account for those resources. Visitors have no Windows password, so the resources must use Fixed Credentials, not Pass-Through. Use a least-privilege Windows account made for the purpose; never an administrator account. See Publishing applications.
4. Optional: open the application automatically. Add an automatic launch rule for the guest account, with full screen if you like, and use a theme without the top bar, so visitors land straight in the application. See Automatic launch and single-application portals.

Turn on guest access

Guest access is set up on the Anonymous Access section of Authentication → Authentication Methods, which is laid out in this order.

1. Open the page. Go to Authentication → Authentication Methods and find Anonymous Access.
2. Choose the guest account. Pick the portal account you created. It is checked whenever it is used; an account that is inactive, an administrator or waiting for a password change is refused.
3. Choose where visitors are admitted.
   • Tick Allow anonymous access to admit visitors on every address that has no tenant binding (for example the server's own name or IP address).
   • Tenant addresses that admit visitors are listed underneath, each linking to its own settings. Those are turned on per address, as described next, and are not affected by this switch.
4. Consider the human check. See Keeping robots out below.
5. Read the checklist at the bottom of the section; it repeats the host settings you need.
6. Save, and try it. Open the address in a private browser window. You should go straight into the portal (or the application) without a sign-in page.

Guest access on one tenant address

1. Open the address. Go to Appearance → Tenancy & Branding, open the address and choose Access.
2. Choose Anybody, without signing in under who this address admits. The page names the installation's guest account and links to Authentication → Authentication Methods, where it is chosen.
3. Save. The save is refused if no usable guest account has been chosen yet. On the Tenancy & Branding list, the address now shows the warning tag Anyone, no sign-in.

To make the address sign-in only again, choose Anybody who can sign in (or limit it to particular groups) and save.

There is one guest account for the whole installation. Every public address shares it, and so shares its access. To give different public addresses different applications, use automatic launch rules on each address rather than different guest accounts.

Keeping robots out New in 2.0

A public address is visited by search engines, scanners and robots, and each would otherwise become a guest visitor, write a sign-in to the audit log and possibly start a session. Tick Ask visitors to prove they are a person first to stop this.

• Visitors see a short "just checking" page, styled with your theme, before entering. It uses the picture check or the provider chosen under Authentication → Security; see Sign-in protection.
• A visitor who passes is admitted and the audit log notes that they passed the check. Robots that fail leave no audit entry.
• A link on the check page lets staff sign in with an account instead.
• If no check can be shown (for example a third-party provider with no keys), visitors are let in, and the page warns you.

You can also block an abusive address outright from System → Audit Log or the Network Access page; see Sign-in protection.

What happens on the host

All visitors log on to Windows with the same saved account. DartRelay recognises this kind of shared logon and handles it for you:

• each visitor's browser gets its own Windows session, so one visitor never takes over another's screen;
• when a visitor closes their last tab, DartRelay signs out the disconnected Windows session they leave behind, so the next visitor is never handed it. Sessions that are still in use are not touched.

Use a Windows account with no more rights than the application needs, and check the host's session settings on Host session options.

Turning guest access off

Untick Allow anonymous access, or change a tenant address away from Anybody, without signing in, and save. Visitors who are already in are signed out on their next click, and their applications close. They see the ordinary sign-in page.

Example: a public booking application

A sports centre publishes a booking program for the public on book.example.com, while staff use staff.example.com.

1. A portal account guest is created and granted only the booking application, which uses a saved Windows account CORP\booking-kiosk.
2. An automatic launch rule opens the booking application in full screen for guest on the book.example.com address.
3. On Authentication → Authentication Methods, guest is chosen as the guest account and the human check is ticked. Allow anonymous access is left off, so the server's own address still asks for a sign-in.
4. On book.example.com's Access page, Anybody, without signing in is chosen. staff.example.com stays on Anybody who can sign in.

Members of the public open book.example.com, answer the picture check and land in the booking program. Staff sign in as normal on their own address.

If something goes wrong

Related pages