######################################################################### # 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.
