Security Settings??

mbharrel

Is there a way to limit the ability of a user to only see the alert and details?

For instance, if I wanted a developer to receive the alert and be able to see the alert details but not have the manipulate the clear alert or edit alert configuration buttons.

dlkj

SQL Response doesn't currently support this.

I've added this to our bug track system and we will consider it for a future release.

Thanks for the feedback,
--
Daniel

mbharrel

Thank you for adding that to your tracking system. Here is one more thing that pertains to security. Is there anyway to allow the use of different SQL Server Instance Accounts that are Windows Authentication based?

We would like to have one repository alert database but monitor multiple servers across multiple domains which all have there own unique user names and passwords per SQL instance based on agency and usage i.e Development vs Production. The way we are understanding the product currently we would have to create a SQL Account for each SQL Instance.

dlkj

This isn't possible due to the way that SQL connection authentication is implemented.

We would recommend that you create a windows user that has admin privileges on all the SQL Servers you wish to monitor and set the SQL Response Alert Repository to run as this user.

--
Daniel

mbharrel

Thanks for the reply but that is precisely what we would not do in our environment. It would be nice to be able to customize the login per SQL instance in a future release.

dlkj

This isn't a limitation of SQL Response, this is a limitation of Windows Authentication and SQL Server.

If the connecting machine is not on the same domain as the SQL Server or a trusted domain, it is not possible to use Windows Authentication.

If the SQL Server is on the same domain, or on a trusted domain, it is possible to create an admin user for monitoring purposes.

How many domains do you have your servers spread over and roughly how many servers are you planning on monitoring?

Regards,
--
Daniel

mbharrel

We have over 130 SQL Servers and that size grows each month. I have never counted the number of domains but I can count 14 off the top of my head.

lewismoten

I have a similar situation where I have two domains. Essentially we will need to setup two individual repositories since each one authenticates with different credentials to access the servers. We have a service account in each domain that can access each SQL server instance in that domain in the same way.

I can see a need where you would want each individual instance to have separate login information to improve security. The only thing I can think of is a separate repository for each login credential since the repository uses the same account that it runs under to access each server that it monitors. That sounds like a nightmare to "make the rounds" when ever you want to check in on them with the SQL Response client.

I often leave a SQL Response client running throughout the day to keep tabs on alerts as they happen (don't have email setup yet). Setting an additional one up at the same time would start to get unmanageable.

Here is my feature request.

1. By default, if no login credentials are sepcified, let the repository connect to the SQL Server instance via the same credentials it uses to run as a service.

2. Allow windows login credentials to be specified per-instance. If login credentials are specified, then the repository will impersonate that account when querying against the SQL Server instance.

3. Allow a repository to query another repository for all of its logs. This would allow us to query one repository with SQL Response client rather than logging into many repositories.

4. Allow an SQL Response client to monitor multiple repositories.

5. Allow a repository to optionally store/share it's logs to an SQL database (problematic if the database is down)

dlkj

lewismoten wrote:

1. By default, if no login credentials are sepcified, let the repository connect to the SQL Server instance via the same credentials it uses to run as a service.

This is the current behavior.

lewismoten wrote:

2. Allow windows login credentials to be specified per-instance. If login credentials are specified, then the repository will impersonate that account when querying against the SQL Server instance.

We currently support specifying SQL authentication. We recommend created a monitoring windows user with access to all the servers to be monitored then using the behavior described about in point 1.

We are reluctant to implement impersonation as it still requires the repository to be on the same domain as the monitored sql server or on a trusted domain. This doesn't get you any more flexibility than having a dedicated monitoring windows user.

lewismoten wrote:

3. Allow a repository to query another repository for all of its logs. This would allow us to query one repository with SQL Response client rather than logging into many repositories.

4. Allow an SQL Response client to monitor multiple repositories.

Both of these have been logged as feature requests.

lewismoten wrote:

5. Allow a repository to optionally store/share it's logs to an SQL database (problematic if the database is down)

We don't currently have any plans to enable data to be exported from the alert repository, but I've logged this as well.

Cheers,
--
Danel

conradicus

I assume cross domain access to repositories are still not possible in version 1.1?

I am able to ping and get responses from my alert repository (windows server 2003). I can also acces the SQL Server via SQL Authentication if need be.

It's domain authentication that prevents me from accessing the data on that repository via SQL Response client : (.

dlkj

Hi,

Unfortunately cross domain authentication wasn't addressed in the 1.1 release due to time constraints.

I have a fix for this issue working in the 1.2 development build at the moment. We are planning to release 1.2 in Q1 next year.

Cheers,
--
Daniel