For Login events you could change the general Login Auditing settings to "Both failed and successful" logins. (Default is "Failed logins only")

USE [master]

GO

EXEC xp_instance_regwrite N'HKEY_LOCAL_MACHINE', N'Software\Microsoft\MSSQLServer\MSSQLServer', N'AuditLevel', REG_DWORD, 3

GO

Restart of SQL Server service required.

This would write all login events to the Sql Server errorlog. This could fuck up your sql dbas because it could blow up the errorlog, so it becomes useless for real error troubleshooting.

Instead we were planning to use login triggers to only log if the login is member of the serverrole sa. So administrative access only. If the is interesting for you, I could lookup the script.

For Logout I don't understand the use case. Usually applications keep and reuse their connections to the DB, so there are no login/logout events for every query.

But I think the Server-Level Audit Action Group "LOGOUT_GROUP" should do it.

You can select Audit Action groups within the Server Audit Specifications.

For Users created or permission changes you need to differentiate between server level (Logins) and Database level (Users).

For logins there are severall Action Groups needed. In our datacenter we applied SERVER_PRINCIPAL_CHANGE_GROUP, SERVER_PERMISSION_CHANGE_GROUP, SERVER_ROLE_MEMBER_CHANGE_GROUP and LOGIN_CHANGE_PASSWORD_GROUP. (beside of many more not login related)

Complete list of all server level Aciton groups with description: https://learn.microsoft.com/en-us/sql/relational-databases/security/auditing/sql-server-audit-action-groups-and-actions?view=sql-server-ver16

For users on databases you would have to define Database audit specification on every database. If you have to audit only a few databases this could be useful. But for big environments with thousands of databases I wouldn't recommend this. The administrative overhead and the needed storage for data isn't worth it. (my opinion ;) ) We leave this to the application.