What is the URL you are using to access the admin page? Can you share a screenshot? You may be looking at the connection status of the Indexed Search Crawler which is a separate service from the PI Web API service and that one may not be connected.
Sorry I think I misunderstood the behaviour.
On a customers machine which has a local install of PI-WebAPI 2015 R3 (R2 upgraded), local to my client, I enter the URL https://pi-pc.pidemo.local/piwebapi.
When I went to look in either the asset servers or data servers controller, I saw that the IsConnected attribute was set to false. I repeated this on my own test environment.
I then drilled down into the assetserver/dataserver and could see a list of points/assets. So I am assuming that this means the connection is implicit only when the first object within that system is referenced.
Could you please just confirm some other behaviour for me regarding the connection to the AF/DA servers?
On the customers own machine I have a local install of webapi on an application machine, running under a domain account which has rights to PI DA and AF systems. The machine does not have any SPN's created for it on the application machine. When I open the FQDN path to the piwebapi, I connect without any prompts and I can drill down to see PI Points etc.
When I try to do this in my own test environment, when I access either the main end point or admin endpoint, I am prompted for a username and password. If I don't enter one or even enter the same domain account that I was logged on the machine with I get the response below.
However, if I use the NetBIOS name for the URL it logs in automatically even though I have no SPN's on the machine.
Do you know what the difference is between using FQDN or non FQDN URL's? I am also not sure whether I need to create SPN's. Is this only if I have a table lookup reference and need to pass my credentials onto the target database? It seems to work fine on my test system without them.
I assume you are using Internet Explorer because what you describe sounds familiar with regards to the available security option in Internet Explorer. When you enter the NetBIOS name, IE recognizes you are accessing an Intranet side and applies the Intranet zone setting which will be to forward the credentials of the logged on user. I assume that the NetBIOS name shows in the list of Intranet sides but the FQDN does not?
When you close the login prompt without entering any credentials, authentication with PI Web API fails because PI Web API is not configured for Anonymous authentication.
I believe you may be misleading two different things here:
Web Client Authentication with the PI Web API
This occurs when your browser or the calling application interacts with the PI Web API. depending on the Authentication Method you are using, you will be granted access to the PI Web API methods or not.
To know which identity PI Web API has authenticated you with, you need to go here:
PI Web API Connections - to PI Data Archive and PI AF Servers
PI Web API will connect to the PI Data Archive or the AF Servers when required. What you need to know here is that AF SDK connections gets cached for a configurable time interval so it is not needed to reconnect each time a request is made to a server. This is built in mechanism in the AF SDK. So what you see in /piwebapi/assetservers is simply if the cached connection for your user is still connected to the system or not. Functionally speaking that changes nothing, except that the next time you'll ask for data to this asset server it may take slightly more time because the connection will need to reconnect.
So to your question :
Does PI Web API connection uses trust?
- Trust connection can only be used for the PI Data Archive, PI AF will need to be made with a windows user.
- For DataServers (PI Data archive), for Anonymous, Basic and Kerberos Authentication (see Authentication Method), assuming there is a trust configured for you PI Web API server on the PI Data Archive, a trust would work.
- For AssetServers it is not possible to connect with a trust thus you need to set windows identities in AF:
- Anonymous Authentication and Basic will use the PI Web API Service account: by default, will use the virtual service account NT Service\PIWebAPI
- For Kerberos, the user identity that is connecting to PI Web API will be passed to AF ( and to the PI Data Archive if a windows mapping exist, that would work.)
If PI Web API is configured with anonymous or basic authentication, PI Coresight will not be able to access the search.
After playing with this a lot I think I understand how it works now.
I tried with basic and Kerberos authentication from IE, Fiddler and from C#. It looks like very cool technology and is pretty fast.
I tried it on several machines using different windows accounts on different - but trusted domains. The machines I installed WebAPI on were in the Enterprise network/domain and the AF/PI Servers are in a DMZ, on a separate but trusted domain in the same forest.
One thing I did notice was that when I connected to the admin page on one of the enterprise machines hosting WebAPI, using an account on the same domain as the AF/PI Server (In the DMZ), I was able to add a reference to the PI Server and index it but got an authorization error when trying to add a reference to an AF database. However when using an account on the parent domain (Enterprise) from a machine on the enterprise, I was able to add crawler references to the AF databases OK. I am not sure what causes this. In all cases WebAPI is running under the same domain account.
using an account on the same domain as the AF/PI Server (In the DMZ), I was able to add a reference to the PI Server and index it but got an authorization error when trying to add a reference to an AF database. However when using an account on the parent domain (Enterprise) from a machine on the enterprise, I was able to add crawler references to the AF databases OK. I am not sure what causes this. In all cases WebAPI is running under the same domain account.
This issue may be related with kerberos delegation. Let me see if we can get more details with Lubos Mlcoch, he knows more than me on these things.