8 Replies Latest reply on Feb 9, 2015 4:43 PM by sdriscoll

    Coresight 2014 search not working

    jlangan

      So I have developed a small application to take my home power meter info and puts it into PI using the web api.  For ease of development (I am not a developer and did not want to deal yet with security), I had added anonymous (and basic while I was at it) authentication to the web api so the configuration https://localhost/piwebapi/system/configuration looked something like this:

      "AuthenticationMethods": [

        "Kerberos",

        "Basic"

        "Anonymous"

        ],

       

      I got my program up and running and decided to install Coresight at this point to build a display to monitor my power consumption.  I was not able to search in Coresight.  My first issue was that Coresight 2014 must be installed in a domain in order for searching to work (I guess it requires Kerberos authentication to the web api for af searching).  It would have been nice to know this first (huge warning on the install program might be nice - or maybe don't even let me install without acknowledging this), but it was easy enough to switch from workgroup to domain on my vm.  Ok - so now searching af or tags still would not work!  So now everything looks right - the index crawler was running (https://localhost/piwebapi/admin/search/database.html) - I've switched to a domain (and reinstalled where necessary under a domain account that had the right groups/privileges) - what else is there?  I realized at some point the only other change I had made to the configuration of the system was the web api authentication.  This did not make sense - as I hadn't disabled Kerberos web api authentication, but I went ahead and I removed anonymous from the web api authentication to look like this:

      "AuthenticationMethods": [

        "Kerberos",

        "Basic"

        ],

      So I discovered that Coresight 2014 requires that you remove anonymous authentication from the web api if you happen to have added it in

       

      So I am posting this for 2 reasons.  First is to share my experience in case someone else is having this problem.

      The second is to ask the question - why does Coresight 2014 require that anonymous be removed?  I realize it requires Kerberos - but it also seems to be checking first to see if anonymous is enabled.

       

      As for me - I am more curious then anything at this point - I just want to understand more around this design (I assume it is by design).  But in the scheme of things, it doesn't matter - I already changed my web api program to use authentication (a best practice anyway - it wasn't the best idea to have anonymous authentication to the web api, especially since disablewrites=false was set allowing full read/write access to any anonymous user).

        • Re: Coresight 2014 search not working
          sdriscoll

          Coresight requires NTLM or Kerberos, and requests from Coresight to Web API include an authorization token so you are required to use Kerberos or NTLM for communication.

           

          I'm not sure why allowing Anonymous on the Web API side would have any effect. Based on your observation I would also have expected the inclusion of Basic to fuddle the process as well. I'm curious, if you add Anonymous again can you reproduce the same issue.

           

          EDIT: As Lubos pointed out, you can use Basic authentication with Coresight but it isn't enabled by default and frankly not recommended, IMO. If enabled you will of course want to require SSL. But to my point above, I still contest that if anonymous was the issue then basic would also have the same issue. I'm curious Joey, if you can reproduce the issue by enabling anonymous again.

            • Re: Coresight 2014 search not working
              Roger Palmen

              The Web API does have a use outside of CoreSight, and that is where this level of control is quite good to have (have used this in the past).

               

              Although Lubos is technically correct (yes, i like that level of detail), i always recommend to use AF, and then you quickly need Kerberos in a multi-server environment. If you expose CoreSight to truly mobile (public network) users, you really should use constrained delegation. So for all practical cases, i'd say, yes you need kerberos. Unless you really know the difference or build a single-server stack (e.g. a development VM), or know how to contain the security issues.

               

              Reading my own comments, i think this is more my opinion on how to approach this. Technically, a lot of less secure options are available. But as we see the secutiy threaths increasing, i'd recommend to take security more serious than our industry has done in the past.

               

              Food for thougt: A Cyberattack Has Caused Confirmed Physical Damage for the Second Time Ever | WIRED

              1 of 1 people found this helpful
                • Re: Coresight 2014 search not working
                  lmlcoch

                  From what I've seen, customers employ third-party gateways if truly mobile access is required.

                  That greatly mitigates the risk (usually there's two-factor authentication just to access the gateway, e.g. token + password, and additional login to individual resources managed by the gateway may be required).

                • Re: Coresight 2014 search not working
                  jlangan

                  Yep - I can replicate this.  Add anonymous authentication for the web api (from PSE and check-in), wait about 10 seconds or so, search again - search does not work; remove anonymous (check-in), search works.  When I say search does not work, I can still search for displays - but not tags or elements, and the drill down into a pi af does not work (unless it has already been cached).  As a note, Coresight continues to work with just one problem: you just can't build new displays since you can't search and select an element (or tag).

                   

                  I do understand that I can use basic authentication with Coresight - in fact I am using that (with https) for testing (I am not wanting to get into a security debate at this point, but agree it is very important and should revisit) - but again I am not talking about Coresight authentication (that has never been an issue - I've always been able to log into and use Coresight), it is just the search (which uses the web api).

                   

                  I am more curious about the architecture - of how the search box interacts with the rest of Coresight - it seems like it independently logs into the web api to search (and if anonymous is available, it uses that first (even though already logged into Coresight), gets a 200 response back because it is allowed to connect, but can't find anything because it doesn't have the privileges to search the points/elements ??)

                • Re: Coresight 2014 search not working
                  lmlcoch

                  Coresight 2014 does NOT require Kerberos at all! (although it is highly recommended).

                   

                  For example, you can run Coresight with Basic authentication + PI Trust with absolutely no problems.

                  PI WebAPI has to be configured to use Kerberos (default), otherwise Coresight won't be able to communicate with it.

                   

                  Coresight 2014 (incl. Indexed Crawler and WebAPI) must be in a domain.This is due to the fact that the Indexed Crawler utilizes several features of a Windows domain.

                  The search indexes are stored LOCALLY on the Coresight server (%programdata%\OSIsoft\WebAPI\).

                  When you search, there is no connection to PI Data Archive (or PI AF). The search is done locally on the Coresight/WebAPI webserver > the connection to PI/AF opens AFTER you drag an item into the display.
                  This is the search engine part of Coresight 2014 - a users must have a mapping in PI Server to be able to search for PI Points in Coresight.

                   

                  However, PI Trust or PI Mapping (which means configuring Kerberos delegation) can be used for the data connection to PI Data Archive.

                  As far as PI AF goes, PI Data Services retrieves an AF object with its own user, and then checks the access control list for the user accessing through Coresight, so there is no double hop or delegation.

                   

                  My favorite setup is enabling HTTPS + Basic AND Windows (Negotiate only, disable NTLM) Authentication.

                  Desktop access: Negotiate (+ Kerberos delegation to PI Data Archive)

                  Mobile access: Basic (+ forwarding credentials to PI Data Archive)

                  HTTPS enabled due to the fact that when Basic authentication is used, user credentials are sent in plain text.

                   

                  EDIT: It appears that enabling Anonymous authentication for PI WebAPI (regardless of other authentication protocols) actually breaks the ability to search in Coresight after all.

                  1 of 1 people found this helpful
                  • Re: Coresight 2014 search not working
                    sdriscoll

                    Here is what I've gathered from some discussions/investigation.

                     

                    Joey Langan I think you briefly touched on the issue in your last post with the HTTP response. To give a general overview, the PI Indexed Search Crawler is used to create indexed files, the PI Web API is used to query the files, so when you use Coresight's search bar you are creating a web api GET request to query the indexed files. Assuming the search service has crawled and indexed PI/AF correctly, you can omit Search from the equation.

                     

                    In PI Web API, when you enable Anonymous, any request that comes in without an authorization header is now valid and NO 401 challenge is generated. Traditionally, clients send a request without an authorization header and upon receiving a list of available security protocols (in the 401 challenge) will choose one when resending the request. Assuming that, Coresight will send a request without an authorization header first, never receive a 401 challenge and therefore never be able to authenticate as anything other than Anonymous, and be unable to "see" any of the indexed search results because there is no mapping for an Anonymous connection (with good reason ).

                     

                    EDIT: If an Anonymous connection is used PI Web API uses the identity running the service account for authentication purposes. I think that if you assigned this to a domain user that had read permissions to PI/AF then your issue might be resolved. Different security consideration.

                     

                    EDIT 2: Apparently the recommendation in the first edit does not work, investigating more but thought I would let you know.

                    1 of 1 people found this helpful