Maybe this would be a better approach than a Logon Trigger. Instead, create the Logins and correlating Database Users for your domain users who should have access to the database via your C# app. Set the permissions on the Database Users appropriately. Disable their Logins on the server. Create a SQL Login and Database User dedicated for your C# application that has the highest level permissions any domain user would theoretically need.
In your C# app, use the dedicated SQL Login account to connect to your database. Use Windows Authentication to get the current domain user running the application. Whenever you make a database call, prefix the SQL code being executed with
EXECUTE AS USER = followed by the Database User that corresponds to that domain user (the names should theoretically match exactly). For example
EXECUTE AS USER = 'JD'; SELECT SomeField FROM SomeTable. Then the permissions you setup on your SQL instance will be applied for that database call to your dedicated SQL Database User, and you get your security enforcement and no domain user will be able to connect to your SQL instance any other way.
I also think this helps reduce the chances of a spoofing issue like Aaron Bertrand pointed out, via obscurity, since a domain user would need to know the name of the dedicated SQL Login (and password for that matter) to be able to connect to the server. And the only way they'd be able to do that is if they had the source code to your app. But even then, if you implement secure connection strings in your application (depending on the database framework you're using) theoretically the password should still be secured.
Downsides to this are it may be confusing to developers who are inexperienced with SQL Server on how the security permissions are being enforced, and if you want to use AD Groups for your Database Users then you need to implement an additional call in your C# code to look up the AD Groups that correspond to the current domain user running the app, before you
EXECUTE AS that AD group's correlating Database User. There's probably gotta be other reasons this isn't necessarily the best practice from a security model perspective or a code maintainability perspective, but seems like a nifty solution to your problem anyway.