8 Replies Latest reply on May 16, 2013 3:46 PM by Gregor

    Coresight Server and PI server in different Domain




      We are currently planning an installation of Coresight at out customer, but looking at the administrator guide that clearly states that the 


      coresight server and PI server should be in the same domain we are wondering if Coresight can be deployed in a real-life screnario. 


      Most of our customers have a collective where the primary pi server sits in the process control domain and the secondary sits in a DMZ, and that's it.


      Can anybody shed some light why OSI so clearly makes this statement and does not simply say 'there should be a pi trust between Coresight and PI server' ?



        • Re: Coresight Server and PI server in different Domain

          Hi Aldo,


          It really depends on your definition of real-world scenario because my experience is different; customers may have PI infrastructure at the PCD + DMZ but all required data is replicated to the office domain where there is sufficient PI infrastructure to serve consumers at that level.  Typically, there needs to be some application or system that requires access to PI data in the PCD (probably at a higher frequency of update) to require a PI System to be there in the first place, otherwise it makes more sense to have the data closer to the consumers of the data in the office domain.  This avoids PI to PI replication from PCD -> OD and allows the PI Interfaces to replicate directly to the OD.


          Coresight sits on top of PI Data Services which in turn sits on top of PI SDK and AF SDK, so any existing authentication methods for a PI Server or AF Server I think is fair to say can be applied in the case of Coresight - there is a nice TechSupport article on Windows Authentication options here: http://techsupport.osisoft.com/Support+Solution/8/KB00354.htm


          The way I remember reading the documentation is that like all recommendations from OSIsoft now, Windows Authentication is the recommended authentication method, not the only authentication method.  Soon we may not have a choice but to use Windows Authentication for some products (look at the StreamInsight adapters as an example).


          Just some of my thoughts...

            • Re: Coresight Server and PI server in different Domain

              Wow, that is a quick reply...


              thanks for the answer...From what I read from your answer and the docs it is more a recommendation than a requirement...


              So it all comes down to 'the proof of the pudding'...


              Perhaps OSIsoft should provide some more guidance on different deployment scenario's.



                • Re: Coresight Server and PI server in different Domain

                  Hi, just want to share my results with forum,




                  I can confirm Coresight works with ANY trust to a PI server, it even worked from within my VirtualBox instance going to our development server. 


                  This was my setup.....





                  • Re: Coresight Server and PI server in different Domain

                    I will give you a quick rundown of our setup (10'000m view), some of the issues we've had and the work arounds/solutions.


                    Like most big corporates we have multiple domains; of which two of relevance to this discussion. We have a process control domain (PCD - I'm using Rhys TLAs for consistency) and the office domain (OD). We do have a trust relationship between the domains.


                    We have installed the Coresight servers on the PCD domain in close proximity to the PI/AF Servers (as a side note we try and keep the PI/AF servers in close proximity to the users). However, the bulk of the users reside on the OD. We have managed to get this working seamlessly from a user’s perspective.


                    The first thing that you need to understand is that you do have the potential of a double hop authentication. The users authenticate on Coresight and then Coresight passes this authentication to PI and AF to get the actual data. This is where the fun starts. To get this working you need to setup a SPN (Service Principle Name). If you don't get the SPN right your users will have problems accessing the actual data. An area where we have had problems is on the cross domain authentication; users on the PCD could access the data but users on the OD couldn't. As a temporary work around I setup a trust between the Coresight server and the PI server (read-only) the user would then authenticate to the Coresight (CS) server using their normal credentials and CS would authenticate to PI using a normal SDK trust. We've done this while our IT figures out cross domain Kerberos authentication; I'm wondering if we don't need a SPN on the PI and AF servers.


                    From a security perspective this isn't ideal, but it isn't a catastrophe either. The users still need to authenticate to the frontend server and the trust is read-only. The biggest disadvantage is that a user’s may get access to data that they shouldn't.


                    To answer your original mail. I've taken OSIsoft's manual as a recommendation rather than gospel. On a side note I work recommend that OSIsoft expand the Admin guide to cover cross domain authentication as this is the reality. From a technical perspective I don't see an issue with CS being on the OD; either way you will have a double hop authentication problem. The trust work around will also still work.