Skip to main content

Restrict ARK Ascended admission with an EOS allowlist

Use an admission allowlist when you want an ARK: Survival Ascended community to accept named accounts. A shared password can reach people outside your group. An identity list lets you approve individual accounts, but a mistaken identity or startup option can also lock out your organisers. Arrange a short admission test with two volunteers before you invite the community.

Check identity support first

Wildcard documented an ASA fix for PlayersJoinNoCheckList.txt with -exclusivejoin, specifying EOS IDs. Do not populate that list with an old Survival Evolved Steam-only list. Ask your host how the installed ASA build exposes the relevant EOS identities and which existing file the server reads. Keep player identities out of public screenshots and support posts.

Open your panel's startup page and record its present options. Download the current admission file, if one exists. You need permission to edit both the startup configuration and the file; file access alone cannot prove that the admission mode is enabled. If the panel hides the required flag or file location, request the change through support rather than renaming unrelated files.

Run an approved and an unapproved test

  1. Tell your volunteers the test window. Choose one account to approve and one to leave outside the list. Record their exact identities through the method supported by your build.
  2. Stop the server through its normal panel control and wait for the process to exit. Save copies of its startup configuration and existing admission list.
  3. Add the approved account to the server's actual PlayersJoinNoCheckList.txt. Preserve the format expected by the installed server. Remove accidental spaces around identities and check that the editor has not changed the filename extension.
  4. Enable -exclusivejoin through the supported startup setting. Keep the map, save location, ports and mod selection unchanged. Start the server and watch for configuration or startup errors.
  5. Have the approved account make a fresh connection. Then ask the unapproved volunteer to attempt a fresh connection using the same advertised route. An existing session does not test a new admission decision.

Confirm the result before adding more names

Record both outcomes and the server build. The approved player must reach the expected character and world; the other volunteer must fail admission. A browser listing alone proves neither condition. If both accounts join, inspect whether the panel retained the flag and whether the server loaded the intended list. If neither joins, check the recorded identities before adding unrelated networking changes.

Recover without altering the world

Use the panel to stop the process and restore the previous admission file and startup options if you lose access. Restart and repeat the original joining check. You do not need a new map, a reinstall or a player-data reset for this configuration rollback. Keep a named owner responsible for future additions and removals, and retest admission after a template or major server update.

Wildcard ASA patch notes.

No comments to display