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:

USE master;

GO

-- 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;

GO

GRANT VIEW SERVER STATE TO logon_trigger_login;

GO

-- create the logon trigger

CREATE TRIGGER connection_limit_trigger ON ALL SERVER

WITH EXECUTE AS 'logon_trigger_login'

FOR LOGON

AS

BEGIN

-- the list of logins to restrict

IF ORIGINAL_LOGIN() in ('login_test', 'login_test2', 'login_test3', 'login_test4')

AND (SELECT COUNT(*)

FROM sys.dm_exec_sessions

WHERE is_user_process = 1

AND original_login_name = ORIGINAL_LOGIN() ) > 2

BEGIN

ROLLBACK

END

END;

GO