Those SSMS categories are aggregates of various server side features. Take for instance the 'Security' tab, this shows 'Logins', 'Server Roles' and 'Credentials'. Consider the 'Logins' node:
- shows existing login, that is a view over
sys.server_principal
s and visibility of the objects in this catalog view is restricted to entities (logins) on which the current user has ownership or has view definition permission over.
- Allows to add a new login, which means
CREATE LOGIN
and this in turn requires ALTER ANY LOGIN
or ALTER LOGIN
permissions.
- Allows to delete a login, which means
DROP LOGIN
and this requires ALTER ANY LOGIN
.
Now you could in theory deny VIEW DEFINITION on the logins, deny ALTER ANY LOGIN and deny ALTER LOGIN to the user(s), but you will not be able to deny ownership of a login, so the user will still see something there (its own login). So it's a loosing battle. You could apply similar reasoning to any of the other panels in SSMS you want to hide and you'll reach similar results.
That said, you are approaching this from the wrong angle. Security never relies on DENY, always relies on GRANT. Your users should not have any unnecessary rights, period. You should not have to explictly deny anything, bare some extraordinary circumstances.