---
title: "Adding Admins by Password or Nickname (and Why It's Risky)"
excerpt: "How AMX Mod X password- and name-based admin entries in users.ini work, the setinfo field clients use, and why SteamID auth is safer on public servers."
category: "administration"
tags: "admin, security"
image: ""
read_time: "8 min read"
---
<p>AMX Mod X can recognise an admin three ways: by SteamID, by IP, or by name plus a password. Password and name entries exist mainly for non-Steam servers where SteamIDs are unreliable, and they are convenient — but every one of them is a weaker link than a SteamID entry, and it is worth understanding exactly why before you hand out access this way.</p>

<h2>1. Where admins are defined</h2>
<p>All admin identities live in <code>addons/amxmodx/configs/users.ini</code>, one per line, in four fields:</p>
<pre>; &lt;name|steamid|ip&gt; &lt;password&gt; &lt;access flags&gt; &lt;account flags&gt;
"BiG_BoSS"  "s3cretPass"  "abcdefghijklmnopqrstu"  "a"</pre>
<p>The third field is the <strong>access flags</strong> (what commands they can run — see the <a href="/tutorials/amxx-admin-flags-reference">flags reference</a>). The fourth field is the <strong>account flags</strong>, and this is what decides <em>how</em> the player is authenticated. Getting the fourth field right is the whole game.</p>

<h2>2. Account flags control the auth method</h2>
<p>The letters in the fourth field are not command permissions — they tell AMXX how to match this entry to a connected player:</p>
<ul>
<li><code>a</code> — kick the player if they match this entry by name but supply the wrong password.</li>
<li><code>b</code> — treat the first field as a clan tag: match if the player's name <em>contains</em> it, not only if it is identical.</li>
<li><code>c</code> — the first field is a SteamID (authid).</li>
<li><code>d</code> — the first field is an IP address.</li>
<li><code>e</code> — do <strong>not</strong> check a password; grant access on name/IP/SteamID match alone.</li>
</ul>
<p>If the flags contain neither <code>c</code> nor <code>d</code>, the entry is matched by <strong>name</strong>. That is the crux of the risk below.</p>

<h2>3. Set up a password admin</h2>
<p>For a name-plus-password admin, leave out <code>c</code>, <code>d</code> and <code>e</code>, and add <code>a</code> so a wrong password kicks rather than silently failing:</p>
<pre>"BiG_BoSS"  "s3cretPass"  "abcdefghijklmnopqrstu"  "a"</pre>
<p>The player then tells AMXX their password with a client-side <code>setinfo</code> key. The key name is the <code>amx_password_field</code> cvar from <a href="/tutorials/amxx-cfg-explained">amxx.cfg</a>, which defaults to <code>_pw</code>:</p>
<pre>setinfo _pw "s3cretPass"</pre>
<p>Put that line in the player's own <code>userconfig.cfg</code> or <code>autoexec.cfg</code> so it is sent on every connect. If <code>amx_password_field</code> differs on your server, the client's <code>setinfo</code> key must match it exactly or authentication silently fails.</p>

<h2>4. Name-only admins with the e flag</h2>
<p>Adding <code>e</code> drops the password entirely and grants access to anyone using the configured name:</p>
<pre>"BiG_BoSS"  ""  "abcdefghijklmnopqrstu"  "ce"   ; only safe because c = SteamID
"BiG_BoSS"  ""  "abcdefghijklmnopqrstu"  "e"    ; DANGER: anyone using this name is admin</pre>
<p>The second line is the classic self-inflicted wound. On CS 1.6 — especially non-Steam — names are not unique. Anyone can set their name to <code>BiG_BoSS</code> and inherit full admin. Never combine name-based matching with <code>e</code> on a public server.</p>

<h2>5. Why SteamID is safer</h2>
<p>A SteamID (or a stable Reunion/dproto authid) cannot be typed by an impostor the way a name can. A password entry is better than name-only, but the password travels in a client config and is only as strong as the value you chose. Wherever a player has a genuine SteamID, prefer <a href="/tutorials/add-admin-by-steamid">adding them by SteamID</a> instead. Reserve password auth for non-Steam boxes where you have no reliable ID — and even there, consider <a href="/tutorials/install-reunion">Reunion</a> to get stable authids.</p>

<h2>Common errors</h2>
<ul>
<li><strong>Admin not recognised after connecting</strong> — the <code>setinfo</code> key does not match <code>amx_password_field</code>, or the name in <code>users.ini</code> does not match the player's name character-for-character. See <a href="/tutorials/fix-admin-not-recognized">admin not recognised</a>.</li>
<li><strong>Everyone using a common name gets admin</strong> — you used the <code>e</code> flag on a name entry. Remove <code>e</code> or switch to SteamID.</li>
<li><strong>Wrong password does nothing instead of kicking</strong> — you omitted the <code>a</code> account flag. Add it so a bad password is rejected clearly.</li>
<li><strong>Line ignored entirely</strong> — a missing quote or a stray comment (<code>;</code>) in the middle of the line. Each field must be quoted; the file is whitespace-separated.</li>
</ul>

<h2>Verification</h2>
<p>Connect with the admin name and password set, then check your own access in the console:</p>
<pre>amx_who</pre>
<p>Your entry should list the access flags you assigned. Try connecting with the wrong <code>setinfo _pw</code> value and confirm you are kicked (with the <code>a</code> flag) rather than silently granted or denied. Once you are confident the entry works, review the full <a href="/tutorials/users-ini-explained">users.ini format</a> so you know exactly what each field does before you add more admins.</p>