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.
1. Where admins are defined
All admin identities live in addons/amxmodx/configs/users.ini, one per line, in four fields:
; <name|steamid|ip> <password> <access flags> <account flags> "BiG_BoSS" "s3cretPass" "abcdefghijklmnopqrstu" "a"
The third field is the access flags (what commands they can run — see the flags reference). The fourth field is the account flags, and this is what decides how the player is authenticated. Getting the fourth field right is the whole game.
2. Account flags control the auth method
The letters in the fourth field are not command permissions — they tell AMXX how to match this entry to a connected player:
a— kick the player if they match this entry by name but supply the wrong password.b— treat the first field as a clan tag: match if the player's name contains it, not only if it is identical.c— the first field is a SteamID (authid).d— the first field is an IP address.e— do not check a password; grant access on name/IP/SteamID match alone.
If the flags contain neither c nor d, the entry is matched by name. That is the crux of the risk below.
3. Set up a password admin
For a name-plus-password admin, leave out c, d and e, and add a so a wrong password kicks rather than silently failing:
"BiG_BoSS" "s3cretPass" "abcdefghijklmnopqrstu" "a"
The player then tells AMXX their password with a client-side setinfo key. The key name is the amx_password_field cvar from amxx.cfg, which defaults to _pw:
setinfo _pw "s3cretPass"
Put that line in the player's own userconfig.cfg or autoexec.cfg so it is sent on every connect. If amx_password_field differs on your server, the client's setinfo key must match it exactly or authentication silently fails.
4. Name-only admins with the e flag
Adding e drops the password entirely and grants access to anyone using the configured name:
"BiG_BoSS" "" "abcdefghijklmnopqrstu" "ce" ; only safe because c = SteamID "BiG_BoSS" "" "abcdefghijklmnopqrstu" "e" ; DANGER: anyone using this name is admin
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 BiG_BoSS and inherit full admin. Never combine name-based matching with e on a public server.
5. Why SteamID is safer
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 adding them by SteamID instead. Reserve password auth for non-Steam boxes where you have no reliable ID — and even there, consider Reunion to get stable authids.
Common errors
- Admin not recognised after connecting — the
setinfokey does not matchamx_password_field, or the name inusers.inidoes not match the player's name character-for-character. See admin not recognised. - Everyone using a common name gets admin — you used the
eflag on a name entry. Removeeor switch to SteamID. - Wrong password does nothing instead of kicking — you omitted the
aaccount flag. Add it so a bad password is rejected clearly. - Line ignored entirely — a missing quote or a stray comment (
;) in the middle of the line. Each field must be quoted; the file is whitespace-separated.
Verification
Connect with the admin name and password set, then check your own access in the console:
amx_who
Your entry should list the access flags you assigned. Try connecting with the wrong setinfo _pw value and confirm you are kicked (with the a flag) rather than silently granted or denied. Once you are confident the entry works, review the full users.ini format so you know exactly what each field does before you add more admins.
