SourceMod admin flags, groups and immunity

SourceMod decides what an admin can do with single-letter flags (b generic admin, c kick, d ban, up to z root) attached to an identity, normally a SteamID, in addons/sourcemod/configs/admins_simple.ini. A number before the flags, as in "STEAM_0:1:123456" "50:bcdj", is the admin's immunity level: by default an admin cannot target another admin with higher immunity, and admins with equal immunity can target each other, which sm_immunity_mode in cfg/sourcemod.cfg can change. Groups in admin_groups.cfg bundle flags and immunity so you change a role in one place, and admin_overrides.cfg changes which flag a command needs. That is the whole model; the rest of this post is the detail that makes it behave the way you expect.

It applies to every game SourceMod runs on: Team Fortress 2, Garry's Mod (where SourceMod is less common than ULX or SAM), Left 4 Dead 2, Counter-Strike: Source, Day of Defeat: Source and others. Counter-Strike 2 does not run SourceMod; its equivalent is CounterStrikeSharp, covered in CS2 plugins with Metamod and CounterStrikeSharp.

Where SourceMod reads admins from#

All of these live in addons/sourcemod/configs/ under the game folder (tf/, left4dead2/, cstrike/ and so on).

Both admin files are read, so an admin can be in either. Pick one per server and stick to it: a person defined in both, with different flags, is a confusing afternoon waiting to happen. admins_simple.ini is fine for a handful of people; admins.cfg with groups is better once you have roles; SQL-based admins are better once you have several servers, because a change in the database applies everywhere - global ban systems for communities covers sharing that database.

After editing any of these files, sm_reloadadmins in the server console re-reads them without a restart.

SQL admins for more than one server

SourceMod ships the pieces for database-backed admins, disabled by default. Move admin-sql-threaded.smx (or admin-sql-prefetch.smx, which loads everything at map start) and sql-admin-manager.smx from plugins/disabled into plugins, and add an entry called "admins" to databases.cfg with the host, database, user and password. Then, from the server console:

sm_create_adm_tablessm_sql_addgroup "Moderator" bcj 20sm_sql_addadmin "Jan" steam STEAM_0:1:5555555 "" 0sm_sql_setadmingroups steam STEAM_0:1:5555555 "Moderator"

The first command creates the tables, the rest create a group and an admin who belongs to it. Every server pointed at the same database sees the same admins, so promoting or removing someone happens once rather than once per server. The flat files still work alongside the database, which is handy for keeping the owner's entry local in case the database is unreachable - and a reason to check both places when someone has rights they should not. If you prefer to manage admins through a web interface, the SourceBans++ panel can manage admins and groups for the servers it knows about as well as bans.

The flags, and what each really grants#

Two of these are effectively root by another name and deserve the same care as z:

• `m` (rcon) runs any console command. That includes rcon_password, exec, quit, and changing anything SourceMod itself would otherwise protect. Somebody with m can give themselves anything else.
• `h` (cvar) is wide. Many plugins are configured entirely through cvars, so h lets an admin reconfigure them, including turning off logging or the plugins that would notice.

n is the flag that ends public servers: cheats on means noclip and spawning for anyone with the commands.

b is the one people forget. Most admin commands and plugins expect an admin to have it, and the admin menu (sm_admin) needs it. An admin with cd but no b will often find commands refusing them for no obvious reason.

The custom flags o to t mean nothing until a plugin uses them. A plugin's documentation says which one it checks, and admin_overrides.cfg lets you change it.

Reserved slots and the a flag

Flag a is the one flag that is often given to people who are not staff at all: donors, regulars, clan members. It does nothing until reserved slots are configured in cfg/sourcemod.cfg, using the reservedslots.smx plugin that ships with SourceMod:

sm_reserved_slots 2     // how many slots are kept for flag asm_hide_slots 0         // 1 hides the reserved slots from the visible maxsm_reserve_type 0       // 0, 1 or 2, see below

With sm_reserve_type 0, the last slots are kept for reserved players: when the public slots are full, ordinary players are refused and players with a can still join. With 1, the server can fill completely, and when a reserved player joins a full server someone without reserved access is kicked - the player with the highest latency, or another rule depending on settings - to make room. 2 behaves like 1 but stops kicking once a set number of admins are on. Type 0 is the least surprising for players; type 1 keeps the server full but kicks people mid-game, which you should say in your rules if you use it.

Because a carries no power over other players, it is safe to give widely. It is also the flag most likely to end up on someone who later becomes staff, so check for existing entries before adding a person a second time.

Identities: SteamID, IP and name#

An admin entry starts with an identity. There are three kinds:

• SteamID, such as STEAM_0:1:123456. The only kind that is verified by Steam, and the one to use.
• IP address, written with a leading !, such as "!203.0.113.5". Only sensible for a fixed address you control, such as a server talking to itself.
• Name with a password. The admin's in-game name, with the password supplied by the client.

The SteamID format must match what the server sees. The safe method is to have the person connect, run status in the server console, and copy the ID exactly as printed - different Source games print slightly different forms, and retyping invites mistakes.

Name-based admins are verified with a client setting. In addons/sourcemod/configs/core.cfg, PassInfoVar names it (the default is _password), and the admin types setinfo _password "their-password" in their console before joining. The weakness is that setinfo values are sent to every server the player joins, and any of those servers can read them. Name-and-password admins are a last resort for servers where Steam verification is not available.

admins_simple.ini in full#

The format, from SourceMod's own documentation, is:

// "<SteamID, !IP or name>" "[immunity:]<flags or @group>" ["password"]"STEAM_0:1:1111111"   "99:z"              // owner"STEAM_0:0:2222222"   "@Senior Admin"     // flags and immunity from the group"STEAM_0:1:3333333"   "40:bcdefgjk"       // admin without rcon or cvars"STEAM_0:0:4444444"   "20:bcj"            // moderator: kick and chat"!127.0.0.1"          "z"                 // local tools only"Night Shift Tom"     "bcj"   "a-long-password"

The rules:

• Immunity is optional. "bcj" with no number means immunity 0.
• @Group Name instead of flags takes everything from that group in admin_groups.cfg, including its immunity.
• The password field only applies to name-based entries.
• Comments start with //, and a missing quote breaks the whole file. If an admin suddenly has no rights after an edit, check the quotes on every line, then look in addons/sourcemod/logs/ for the error.

Groups, admins.cfg and group immunity#

Groups make roles maintainable. You define "Moderator" once and change it once.

Groups{	"Senior Admin"	{		"flags"		"bcdefgijk"		"immunity"	"60"	}	"Moderator"	{		"flags"		"bcj"		"immunity"	"20"		"Overrides"		{			"sm_map"		"deny"			"sm_slap"		"allow"		}	}}

Admins then refer to the group, either with @Moderator in admins_simple.ini or in admins.cfg:

Admins{	"Anna"	{		"auth"		"steam"		"identity"	"STEAM_0:0:2222222"		"group"		"Senior Admin"	}	"Jan"	{		"auth"		"steam"		"identity"	"STEAM_0:1:5555555"		"group"		"Moderator"		"flags"		"k"	}}

Jan gets the Moderator flags plus k for votes. Flags from groups and from the admin's own entry add together.

Group immunity has two forms. A number is applied to members only if it is higher than the immunity they already have, so a group can raise immunity but never lower it. A value written as `@GroupName` makes members immune from that group specifically, regardless of numbers - useful for "moderators can never target senior admins" even if somebody later gives a moderator a high number by mistake.

The group's Overrides block allows or denies specific commands for members. It does not change flags: in the example, moderators are denied sm_map even if some other entry gives them g, and allowed sm_slap even though they lack f.

Immunity: who can target whom#

Immunity decides whether one admin's command can affect another admin - a kick, a ban, a slay. It does not affect ordinary players, who have no immunity and can always be targeted.

The behaviour comes from sm_immunity_mode in cfg/sourcemod.cfg:

Under the default 1, two moderators at immunity 20 can kick each other, and neither can touch a senior admin at 60. Under 2, equals are protected from each other too, which suits servers where staff disputes have happened. Root admins (z) ignore immunity entirely, which is one more reason to give z to as few people as possible.

A layout that works for most communities:

Keep m, h, i and n with the owner unless a specific person has a specific need, and leave gaps between immunity numbers so you can add a role later without renumbering everyone.

Overrides: changing which flag a command needs#

Plugins choose a default flag for each command. When that default does not fit your staff structure, admin_overrides.cfg changes it without editing the plugin:

Overrides{	"sm_map"		"k"     // let vote-trusted staff change the map	"sm_rcon"		"z"     // rcon only for root, not for flag m	"sm_chat"		""      // anyone can message admins}

An empty string means anyone can use the command. A name starting with @, such as "@CSDM" "m", is a command group, which some plugins register so that several related commands can be overridden at once; the plugin's documentation names the group if it has one.

Overrides are where most "why can my moderator do that?" questions are answered, so keep a short comment beside each one saying why it exists.

Checking and troubleshooting#

The commands that tell you what SourceMod actually thinks:

sm_who                  // connected players and their admin flagssm_reloadadmins         // re-read every admin filesm plugins list         // confirm admin-flatfile.smx is loadedsm_dump_admcache        // write the full admin cache to a file for inspection

An admin has no rights at all. The SteamID does not match (copy it from status), the line has a syntax error, or admin-flatfile.smx is not loaded or has been moved to plugins/disabled. Check addons/sourcemod/logs/ for parse errors.

Rights work after a map change but not immediately. You edited the file but did not run sm_reloadadmins.

An admin can kick another admin they should not. Their immunity values are equal and sm_immunity_mode is 1. Raise one, switch to mode 2, or use group immunity with @GroupName.

A plugin command refuses an admin who has the flag. They are missing b, or an override has changed the required flag. Look in admin_overrides.cfg and in any Overrides block of their group.

Somebody has rights you never gave them. Check both admins_simple.ini and admins.cfg, every group they belong to, and the SQL admin tables if you use them. If you still cannot explain it, treat it as a compromise - what to do when your server is hacked has the order of work.

Admin actions, logs and visibility#

SourceMod logs admin actions to addons/sourcemod/logs/, with daily files, so you can see who kicked or banned whom and when. Read them when a player complains about a staff member, and occasionally when nobody has.

sm_show_activity in cfg/sourcemod.cfg controls how admin actions are announced in game. It is a sum of values: 1 shows activity to non-admins anonymously, 2 adds admin names for them, 4 shows activity to admins anonymously, 8 adds names for admins, and 16 always shows names to root admins. The default 13 means players see that "an admin" did something, and admins see who. Many communities set 15 so that players can see which admin acted, which discourages abuse.

On RE:NODE, the panel console runs every one of these commands without an RCON client, and subusers can be given console access without file access - so a moderator can run sm_reloadadmins or read sm_who without being able to edit the admin files. Team Fortress 2, Garry's Mod and Counter-Strike 1.6 have their own pages under game servers, and Team Fortress 2 SourceMod plugins covers installing SourceMod from scratch.

FAQ#

What is the difference between flag b and flag z?

b makes someone an admin with no particular powers; every other flag adds a specific power. z is every flag at once, including flags plugins add later, and it ignores immunity. Give b to all staff and z to the owner.

Can I give an admin access to one command only?

Yes. Give them b, then use a group Overrides block with "command" "allow", or change the command's required flag in admin_overrides.cfg to a custom flag only they have.

Does immunity protect admins from votes?

Not by itself. Immunity applies to admin commands targeting a player. Whether a vote kick can remove an admin depends on the vote plugin, many of which check immunity or flags separately.

Should I use admins_simple.ini or admins.cfg?

admins_simple.ini for a few admins on one server. admins.cfg with groups once you have roles. A database once you have several servers sharing staff.

Why does an admin keep their rights after I removed them?

The admin cache is still loaded. Run sm_reloadadmins, and check they are not also defined in the other admin file or in a group-based SQL setup.