What's the issue?
One or more endpoints have been determined to be owned by a user login.
Why is this a problem?
By default endpoints are set to be owned by whoever created them, so they can often be owned by user login. However, if the login that owns the endpoint becomes disabled in Windows, then the any high availability solutions you are using such as Availability Groups or Mirroring will cease communicating properly.
What should you do about this?
If the login that owns the endpoint was disabled in Windows, you'd already notice errors with connectivity. Before the owner is ever disabled in Windows, verify that the owner of the endpoint is a login used by a service account and not user.
We recommend changing the ownership to the sa login, which will allow the endpoints to communicate even if the sa login is disabled in SQL Server as we recommend.
USE master; GO ALTER AUTHORIZATION ON ENDPOINT::EndpointName TO sa;
Vulnerability
Category
What do the Vulnerability Levels mean?
0 - Information only. This is stuff you should know about your instances like version and service account used, but if you don't know it…well, now you do.
1 - High vulnerability requiring action. These are the issues that could most likely lead to your company being front page news for all the wrong reasons. If your instances have any results at this level then we recommend cancelling that 3-martini lunch and instead huddling with your team to figure out when to address these issues.
2 - High vulnerability to review. These include settings and assigned permissions you should review soon, if not immediately. These findings may not necessarily indicate a clear vulnerability, but we've found unexpected vulnerabilities in these categories at many, many clients.
3 - Potential vulnerability to review. These are configurations or assigned permissions you may be using that could lead to problems for users. Or maybe they're just required for your applications. Either way, we recommend reviewing these to make sure these are correct.
4 – Low vulnerability with recommended action. These are typically security inconsistencies that should be addressed. They aren't likely to cause problems, but you should clean up the mess.