armagetronad-common 0.2.8.3.2-1 / etc / armagetronad / settings_authentication.cfg

#########################################################################
# IMPORTANT: Users should NOT edit this file. Instead, copy the
#            lines you want to change into a new file named autoexec.cfg
#            ( either here or in your var directory ).
#            This file will be overwritten when you upgrade, autoexec.cfg won't.
#            Be sure to save the file as plain text, not rich text, especially
#            if you're using TextEdit on a Mac.
#########################################################################

#########################################################################
#
# Policies
#
#########################################################################

# As all Armagetron subsystems, Authentication is complex and has many
# options for you to tweak. The policies for the default settings were
# chosen with the following priorities:
# 1. Compatibility with old clients
# 2. Security
# 3. General usability
# If you are a very security aware person, you will probably disagree
# with the priority choilce of 1. vs 2, and want to get maximal security,
# even if that means old clients will not be able to authenticate on
# your server; in this case, uncomment the following line:

# HASH_METHOD_BLACKLIST bmd5

# this will disable the hash protocol clients up to 0.2.8.2.1 knew as
# the only one, which is vulnerable to relatively easy man in the
# middle attacks. New clients will, by default, refuse to use it, so
# if the the admins on your server are well educated and protect their
# login data with all means available to them, which includes using an
# up-to-date client, you should be safe even without this setting.
# You may get the occasional faked login from a regular player, though.

#########################################################################
#
# Local Accounts
#
#########################################################################

# To help your local users store their passwords, you should change the
# following settings to something server-specific:

MD5_PREFIX %u:
MD5_SUFFIX :arma

# those are strings that are appended/prepended to the password before
# the hash function is applied to them. So far, only the md5 protocol
# supports them, bmd5 ignores them. If you put a %u into the strings,
# it will be replaced by the username. This helps combat precomputation
# attacks; for team accounts, it will force the password to be kept in
# memory in plain text, though (not much of a problem).
# You need to set these up before you define the accounts.

# The following commands are available for you to create local accounts:

# LOCAL_USER <user name> <user password>

# Creates an account for a single player. You should restrict the username
# to ASCII characters, best lowercase letters and numbers, and avoid spaces
# and the symbols @, #, \, :, and %. They will still work, but look ugly
# in the logs and on the screen because they all need to get escaped.
# Spaces in the username, if you absolutely must have them, need to
# be quoted or escaped, the user "Foo Bar" can get an account with either
# LOCAL_USER "Foo Bar" <password>
# or
# LOCAL_USER Foo\ Bar <password>
# You can get a literal \ into a usename by putting it there twice.

# When logged in, local user accounts will appear as <user name>@ in the logs
# and on the screen, and they will have "Local" access rights by default.

# You can also define accounts for whole teams with

# LOCAL_TEAM <team name> <team password>

# Those accouts will allow login from all usernames with a name starting with
# the team name. Users logged in via such an account will appear as
# <user name>@L_TEAM and get the access rights of "Team Member", more
# about that later. Accounts of this type are intended to be used for organized
# tournaments.

# You can remove both kinds of accounts with USER_REMOVE.

#########################################################################
#
# Remote Accounts
#
#########################################################################

# We support a distributed authentication system where a user has to only get
# an account at the authority of his choice and use that to authenticate with
# on all participating servers. By default, this system is disabled. Enable
# it by changing the following setting to 1.

GLOBAL_ID 0

# Your server will then make connection to the remote authentication servers
# every time a user will try to authenticate; those connections will happen
# in the background and should not cause too much extra lag.

# Accounts from remote authentication servers will appear as
# <user name>@<authority> in your logs.

# Maybe you don't want to accept logins from all authorities. If you want to
# exclude some, put them into this comma separated list:

AUTHORITY_BLACKLIST

# If you only want to accept logins from a selected group of authorities, put
# them into this comma separated list:

AUTHORITY_WHITELIST

#########################################################################
#
# Access Rights
#
#########################################################################

# The old, single password inteface to the /admin command is disabled
# when you compile a server with this authentication. Instead, you
# can assign access rights to individual players with

# USER_LEVEL <user name> <level>

# The user name is the user's full authentication name as it appears in
# your logs, with all the escapes and character encodings; the "Foo Bar@"
# user from the example above would usually appear as Foo\_Bar@, and that
# is how you need to put him there. The level is the numberic access level;
# lower values are better. The predefined meanings (of course, you can
# disagree and define your own) of these are:

# Level  Meaning        Details
# 0      Owner          The owner of the server. Commands entered on the
#                       server console are executed with these rights.
# 1      Admin          A server administrator. By default, almost as
#                       powerful as the owner himself.
# 2      Moderator      A server moderator. Is still allowed to use /admin,
#                       but is restricted to player management commands.
# 7      Team Leader    Leader of a team. By default, no admin rights at all.
# 8      Team Member    Member of a team. Local team accounts get this level.
# 12     Local User     Players with local accounts get this level.
# 15     Remote User    Players with remote accounts get this level by default.
# 16 Fallen from Grace  Authenticated players who abused default rights given
#                       to them.
# 17     Shunned        Same, only worse :)
# 19     Authenticated  Minimal level authenticated players can get.
# 20     Program        Unauthenticated players.

# As you see, lower numeric values mean more access rights. When we say
# "a user needs at least level X to do Y", that means his numeric level
# needs to be smaller or equal than X.

# Remote (Global ID) accounts run a slightly higher risk of getting
# compromised than local accounts (simpy due to the fact that they
# will get used more often in more locations), so you should restrict
# Admin and Moderator rights to local accounts. To still have your
# Admins and Moderators appear with their Global ID accounts in your
# logs, use this little trick: define them a local account, give
# the rights to that, and define an alias for the local account:

# LOCAL_USER z-man <password>
# USER_LEVEL z-man@ 1
# USER_ALIAS z-man@ Z-Man@forums

# When your admin then logs in to your server under his global account,
# nothing special happens; only when he uses your local account, he
# will get the access rights, and apart from that, there will be no
# differences; he still wil appear under his global account.

# You can modifiy the minimal access rights required to do certain things.
# First, there are the administrative chat commands. To use /admin, you
# need to be at least

ACCESS_LEVEL_ADMIN 2

# To use the /teach or /rtfm command you need at least

ACCESS_LEVEL_RTFM 2

# To use the /op and /deop ad-hoc access level modifying
# commands, you need ot have at least

ACCESS_LEVEL_OP 7

# and that command cannot directly raise the level of a user above

ACCESS_LEVEL_OP_MAX 2

# (and of course, not above the player issuing these commands.)

# To manage teams with the /lock, /unlock, /invite and /univite commands
# in all circumstances, you need this access level:

ACCESS_LEVEL_TEAM 7

# As an emergency feature, /unlock and /invite are also always available
# to the players with the highest access level of a team.

# To play on the server, you need to be at least at

ACCESS_LEVEL_PLAY 20

# However, if at leat

ACCESS_LEVEL_PLAY_SLIDERS 4

# users of a higher access level than you want to play, and
# your level is below

ACCESS_LEVEL_PLAY_SLIDING 20

# you still will not be able to play. This is for servers with
# flexible tournament schedules, there you'll want to raise
# it to the level of 8 (Team Member), so that once some members
# of teams authorized to play on your server log in, all other
# players get removed.

# To be able to chat, you need at least this level:

ACCESS_LEVEL_CHAT 20

# If you don't have that, everyone on the server will be reminded
# that you want to chat at most every

ACCESS_LEVEL_CHAT_TIMEOUT 60

# seconds.

# If you are spectating a game and your access level is at least

ACCESS_LEVEL_SPY_TEAM 2

#, you will see all /team messages. And if your level is at least

ACCESS_LEVEL_SPY_MSG 0

# (no need to be a spectator), you will also see the /msg messages.

# Another change when compiling with armathication is that the old
# setting TEAM_ALLOW_SHUFFLE_UP is replaced by an access level
# that's required to shuffle up. This defaults to team members.

ACCESS_LEVEL_SHUFFLE_UP 8

# Issuing each vote type also requires a certain access level. By
# default (for unchanged behavior relative to previous versions),
# kick and suspend votes are available for everyone.

ACCESS_LEVEL_VOTE_REMOVE 20
ACCESS_LEVEL_VOTE_KICK 20
ACCESS_LEVEL_VOTE_INCLUDE 2
ACCESS_LEVEL_VOTE_COMMAND 2

# direct command votes will be executed at the access level of the
# vote submitter (usage example: poll for SCORE_HOLE in a tournament
# game), or, if that is higher, the following access level.

ACCESS_LEVEL_VOTE_INCLUDE_EXECUTE 2
ACCESS_LEVEL_VOTE_COMMAND_EXECUTE 2

# Having sufficient rights to use /admin does not entitle you to
# use all of the commands; they need to be unlocked for you.
# By default, most Admins can use all commands. To change the
# access level required to use a command, use

# ACCESS_LEVEL <command> <level>

# That command itself is by default restricted to be used by
# the owner, because it is the master key to all other commands.

# Sensible commands to unlock for moderator use are (this is the default):

ACCESS_LEVEL PLAYER_MESSAGE 2
ACCESS_LEVEL KICK 2
ACCESS_LEVEL BAN 2
ACCESS_LEVEL KICK_TO 2
ACCESS_LEVEL MOVE_TO 2
ACCESS_LEVEL SUSPEND 2
ACCESS_LEVEL UNSUSPEND 2
ACCESS_LEVEL KILL 2
ACCESS_LEVEL SILENCE 2
ACCESS_LEVEL VOICE 2
ACCESS_LEVEL ALLOW_RENAME_PLAYER 2
ACCESS_LEVEL DISALLOW_RENAME_PLAYER 2
ACCESS_LEVEL RENAME 2
ACCESS_LEVEL CONSOLE_MESSAGE 2
ACCESS_LEVEL CENTER_MESSAGE 2

# If you want to give team members access to the basic /admin command,
# you can also allow them to manage players:

ACCESS_LEVEL ALLOW_TEAM_CHANGE_PLAYER 7
ACCESS_LEVEL DISALLOW_TEAM_CHANGE_PLAYER 7

# A very powerful command with access levels is CASACL, prounounced
# like Quetzalcoatl, your friendly Aztec God. A bit like the suid flag
# on Unix executables, the setuid system command, and not completely
# unlike the sudo shell command or, if you go very far, Access Control
# in Vista, it allows to change the access level a config file is
# executed under. If you put

# CASACL <required access level> <elevated access level>

# into a configuration file, and a remote admin with at least the rights
# <required access level> orders to include that file, the commands after
# the CASACL command will be executed as if the user had access level
# <elevated access level>. Otherwise, script execution is aborted.
# The effect carries on to other config files included by the one with
# the CASACL command, but wears off as soon as processing the file with
# the command is done. Especially, since every command given as remote
# admin directly is considered one file, "/admin CASACL 20 0" will elevate
# the rights to Owner, but since no second command can be issued on the
# same line, nothing further happens.

# We recommend you put a CASACL command at the top of every configuration
# file your remote administrators are going to include; it serves two
# purposes then: it guards the file from unauthorized inclusion, and
# it makes sure all the commands in the file work whenever the initial
# CASACL command is passed, provided you test it once with any account.
# This avoids scripts that only work partially and leave your server
# in an unhealthy state.

# Oh yeah, CASACL is short for Check And Set ACcess Level.

#########################################################################
#
# Chat Commands
#
#########################################################################

# They have been mentioned in the previous section, so why not document
# them here? The following chat commands are available to authenticated
# users of high enough access level:

# /admin <command>

# executes the console command <command> with the access rights of
# the invoking user.


# /op <player name> <optional access level>

# gives another player a higher access level; the level defaults to the
# level one lower than the caller's access level, which is also the maximal
# possible level.

# /deop <player name>

# reverses /op; it takes away a player's access level, effectively making
# him unauthenticated again. Only works on players of lower access level than
# the invoker, of course.

# /promote <player name> <optional steps>

# elevates a player's access level the given number of steps (default: one).

# /demomote <player name> <optional steps>

# lowers a player's access level the given number of steps (default: one).

# Of course, you can't promote or demote someone of a higher access level than
# yourself, and you can't raise a player's access level to more than one level
# below yours with either command.


# /lock

# Locks your current team. Nobody can join it any more on their own.
# To let someone in, you need to invoke

# /invite <player name>

# From that moment on, the player is allowed to join you. Another effect
# of /inivte, even if your team is not locked, is that the invited player
# can read all of your team's /team messages. Invitations are permanent
# until revoked. That means a player who is invited into your team can
# join and leave it freely without further need to /invite him again.
# Players who were on the team when you /locked it are not automatically
# invited when they leave on their own account.

# /uninvite <player name>

# reverses /invite. The invitation is revoked, the player can no longer
# join you, and if he currently is on your team, he will be thrown out.

# /unlock

# makes your team available for everyone to join again.

#########################################################################
#
# Man in the middle prevention
#
#########################################################################

# when a client authenticates, it sends the IP address and port of the
# server it thinks it is connected to along with the password hash.
# If that IP doesn't match the IP the server thinks it runs under,
# login is denied. Two cases need special attention:

# If your public server is on a LAN and you expect players to connect over
# that LAN in addition to players coming from the Internet, those clients
# will send the LAN IP of the server, which won't match the public IP, so
# the authentication gets rejected. To allow clients from the LAN to bypass
# the check, set this to 1:

TRUST_LAN 0

# If your server does not talk to the master servers, it never gets told
# what its public IP is. You can set it manually with the following command:

#SERVER_DNS <your public ip or a DNS name resolving to it>

#########################################################################
#
# Various
#
#########################################################################

# The log format in ladderlog.txt is picked so that no unauthenticated
# user can ever appear under the same name as an authenticated user. To
# achieve that, @ signs are escaped for unauthenticated users. That
# changes their names relative to the way they appeared in older versions
# of the server. If you rather want to keep the names of unauthenticated
# players as they were before, change this to 1:

LEGACY_LOG_NAMES 0

# Then, instead of mangling unauthenticated names, the authenticated names
# get a 0: prepended before them.

# Really, really stupid users can be banned via their user ID with

# BAN_USER <user>

# Players of average intellect will not be stopped from playing by this,
# but they won't appear in your logs as authenticated and won't collect
# rating points for their account, so maybe this is not so useless as
# it seems. You can revert a ban with

# UNBAN_USER <user>

# and get a list with

# BAN_USER_LIST

# You can reserve a screen name to a certain user:

# RESERVE_SCREEN_NAME <screen name> <user>

# All other players, authenticated or not, will not be able to change their
# screen name to the picked name, then.  Use quotes around the screen name
# if it contains spaces, or replace the spaces with _. @s in the screen name
# need to be escaped ( @ -> \@ ).

# You can bend authenticated user names around with

# USER_ALIAS <user> <alias>

# after doing that, a player who authenticates as <user> will appear
# as <alias>. He will get granted the access rights you gave both
# IDs.

# By default, the authentication names of all players are visible to
# everyone. You can grant your players a certain degree of anonymity
# by allowing all players of a certain maximal access level to hide their
# identity with

ACCESS_LEVEL_HIDE_OF 20

# However, to users of the minimal access level

ACCESS_LEVEL_HIDE_TO 2

# , all user names are shown at all times.