Opserver keeps trying to authenticate with the wrong account

[jonas-wanninger]

Hello,

I deployed Opserver to IIS and configured it to use AD authentication in the SecuritySettings.conf.

<?xml version="1.0" encoding="utf-8"?>
<SecuritySettings provider="AD" >
</SecuritySettings>

<!--Example of global access for everyone:-->
<!--<SecuritySettings provider="alladmin" />-->

I also configured the appropriate AD groups in the web.config file under the key "AdminGroups". So when I navigate to /about I can see that my current role is Global Admin.

This is my SQLSettings.json

{
    "defaultConnectionString": "Data Source=$ServerName$;Initial Catalog=master;Integrated Security=SSPI;",
    "instances": [
        { 
            "name": "[ServerName]"
        },
    ]
}

As soon as I try to watch something on this instance I get this error: Login failed for [DomainName]\[ServerName]

Note: The SQL server and IIS server are running on the same server.

So in other words Opserver does not use my ad account to login but rather tries to use the computername as login. Why is Opserver not trying to login with my AD account?

Error logs says: No errors yet, yay! I also verified that i can login to that SQL server instance via ssms. My user is sysadmin on this instance.

[NickCraver]

A few things:

1. Not logging that error (login) is bad - I'll change this to be special cased so it surfaces in the exception log, with a helpful message.
2. There's some (very understandable) confusion around auth in general here. When you consider that Opserver is monitoring the SQL server all the time and once for n users, it's a little more apparent that it's never authenticating as the user. It's authenticating as the application. This means whatever account it's running under in IIS is what's in use. Since it's a background poll and not a foreground one (e.g. on-the-request), even impersonation through doesn't work. Because the request you're making to see the current data and the background process that gets the data aren't connected. If they were, we'd be a) far slower, and b) do the work n times (based on user count) rather than once per interval.

Does that clear up the why a bit? If not, let me know so that I can clarify another way.

As for a fix: you simply need to run the app pool in IIS under an account that has permissions to the SQL instances you want to monitor.

[jonas-wanninger]

Thanks for clearing things up. Totally clear now. I will just create a service account then and all should be fine.