What is this?

This knowledgebase contains questions and answers about PRTG Network Monitor and network monitoring in general.

Learn more

PRTG Network Monitor

Intuitive to Use. Easy to manage.
More than 500,000 users rely on Paessler PRTG every day. Find out how you can reduce cost, increase QoS and ease planning, as well.

Free Download

Top Tags


View all Tags

Cross-domain SQL sensors

Votes:

0

Situation:
Multiple forests, all with their own (SQL) servers; one-way non-transitive trust to forest with monitoring cluster.

1 PRTG cluster, monitoring them all


Creating mssql sensor on a domain other than the domain the monitoring cluster is in.
The account used for monitoring the server is in the other domain.
PRTG giving an error 'Can not log in using the specified credentials!'


  • So, PRTG-cluster is in domain DomA (Trusted Domain)
  • SQL server is in domain DomB (Trusting Domain)
  • Windows-credentials for the SQL server is set to DomB\<user>
  • Windows sensors work fine.
  • Creating a mssql sensor, it tells me it 'can not log in using the specified credentials'
    When I change the Windows credentials to DomA\<user> (so, from the same domain the PRTG cluster is in, and is configured as a trusted domain in the trust between these domains), the sensor starts working.

    Seems like mssql sensors don't like impersonation with an account in another domain?
    Even though the Windows sensors (for example the disk sensor) is working fine?

    Note:
    Checked with my DBA, and he gets no messages in the sql log about this account trying to authenticate

    Note:
    Did another test, by running the sqlv2.exe utility on a server in DomB
    There it works fine.


    Any ideas on how to make this work?
    Because I cannot create a probe in DomB, just for sql sensors.
    Nor can I start monitoring DomB with a DomA\<user> account...

domains mssql trust user

Created on Nov 8, 2017 2:02:30 PM

Last change on Nov 13, 2017 8:29:09 AM by Luciano Lingnau [Paessler]



5 Replies

Accepted Answer

Votes:

0

We haven't tested this specific scenario. Are you currently using the following Credentials configuration?

Port for DatabasesSet automatically (default port, recommended)
Authentication ModeWindows authentication with impersonation
Timeout (Sec.)60

Are you able to use an SQL only account (i.e. Not Windows authentication with impersonation). Effectively, use the following setup:

Port for DatabasesSet automatically (default port, recommended)
Authentication ModeSQL server authentication
Userdbreadonlyuser
Passworddbreadonlypassword
Timeout (Sec.)60

This way the authentication should be simplier.

Best Regards,
Luciano Lingnau [Paessler Support]

Created on Nov 9, 2017 1:38:06 PM by Luciano Lingnau [Paessler]



Votes:

0

Hi Luciano,

We're using a Windows account for monitoring.
For monitoring our SQL environment, we use that same Windows account.
So, we don't use SQL server authentication.

The settings for SQL were indeed said as you asked (automatic port for databases, Windows authentication with impersonisation, timeout 60 secs)


For test, I had my DBA create a SQL account to test with.
Unfortunately that SQL account needs sysadmin permission in order to be able to access linked server procedure remote queries.
And he's not happy with giving the SQL account those permissions.
So right now, I can't use a SQL account for this either.


This means that I'm still looking for a decent, working solution...

Created on Nov 10, 2017 11:21:28 AM



Votes:

0

Hello Corné,
thank you for your reply.

And he's not happy with giving the SQL account those permissions.

I don't really understand the problem of giving an SQL account those privileges if you currently have a AD account with the very same privileges. While I'm not familiar with SQL Clusters (especially deployed across two domains) in regular deployments it is fairly straightforward to create read-only accounts, since the permission system in MS SQL is very granular.

As of now we don't have other suggestions/solutions for this sort of deployment/environment if you're not willing to go with the SQL Account or with Remote Probes.

Best Regards,
Luciano Lingnau [Paessler Support]

Created on Nov 13, 2017 8:34:39 AM by Luciano Lingnau [Paessler]



Votes:

0

Hello Luciano,

The Windows account used for monitoring, is subject to our password policies (password change, security requirements etc), where SQL accounts are not.

Creating a remote probe just for SQL sensors is not going to work (you can't cluster PRTG Probes).

My DBA is not happy giving a monitoring account sysadmin permissions.
So I've friendly requested him to create a SQL account without sysadmin permissions, but still with enough permissions to run the needed Stored Procedures for monitoring the SQL environment.

Let's see what he'll come up with ;-)

Created on Nov 13, 2017 10:16:18 AM



Votes:

1

Hi Luciano,

We decided to go with SQL account after all.
My DBA figured out the least amount of access rights needed :-)

Created on Nov 23, 2017 12:44:15 PM




Disclaimer: The information in the Paessler Knowledge Base comes without warranty of any kind. Use at your own risk. Before applying any instructions please exercise proper system administrator housekeeping. You must make sure that a proper backup of all your data is available.