You could keep a list of logins hardcoded in the trigger as the example shows, or as I said you would need to keep them in a separate table. Having them in a separate table would allow you to manage the list of logins without recompiling the trigger, but it could turn into a lot more code depending on how many properties you wanted to track in the table, and test for. Whatever you decide, keep the trigger as lightweight as possible.
The code sample in the BOL article is actually poorly put together in my opinion. I would setup a login to be used only to execute the trigger. The BOL example tests for login_test in the trigger itself, which does not make sense to me. Try it this way:
-- no one should ever use this login to actually logonto the server. it only exists for purposes of
-- executing the login trigger
CREATE LOGIN logon_trigger_login WITH PASSWORD = '3KHJ6dhx(0xVYsdf' MUST_CHANGE, CHECK_EXPIRATION = ON;
GRANT VIEW SERVER STATE TO logon_trigger_login;
-- create the logon trigger
CREATE TRIGGER connection_limit_trigger ON ALL SERVER
WITH EXECUTE AS 'logon_trigger_login'
-- the list of logins to restrict
IF ORIGINAL_LOGIN() in ('login_test', 'login_test2', 'login_test3', 'login_test4')
AND (SELECT COUNT(*)
WHERE is_user_process = 1
AND original_login_name = ORIGINAL_LOGIN() ) > 2
There are no special teachers of virtue, because virtue is taught by the whole community.