4 Replies Latest reply on Oct 8, 2009 8:21 PM by RJKSolutions

    Active Directory Security - Planning ahead

    JeffHopper

      With PI Version 3.4.380.xx we will get the integrated security opportunity with the PI Server.   While dreamy in theory, this is going to take a lot more planning with IT to implement.   And from OSI, it doesn't like 3.4.380 integrates into any current IT security processes, like auditing of the system\application\security logs.

       

      Are you planning on jumping on the new security model?  Do you view this as a simplification of projects or a political uphill battle?  Anyone roll out the beta?

       

       

        • Re: Active Directory Security - Planning ahead

          Well I think you touched a good point Jeff: the fact nobody answered might indicate not many people jumped on the new security model just yet (now that PI Server 3.4.380 has been released). People have asked for Windows-Integrated Security (WIS) for years and we now have it – but we understand that people will think and plan for a little while before to actually deploy it...

           

          Jeff Hopper

          this is going to take a lot more planning with IT to implement
          In practice, it all depends on how the Active Directory is set up. In an organization that has a good AD setup, there shouldn't be much to "plan" beside inter-domain trusts, if applicable.

           

          Jeff Hopper

          it doesn't like 3.4.380 integrates into any current IT security processes, like auditing of the system\application\security logs
          You are correct: we do not. However since 3.4.380 can be totally integrated with Windows authentication, we have security audits - at least for all interactive applications, which is what regulators/IT care about. Oh, and if you shut down the PI Message Subsystem, you have all PI messages to the Application Event Log   However this is not recommended because A) the app log is usually configured to hold a lot less information than what we store in our own message log and B) that would mean we compete with all other apps on the system...

           

          Jeff Hopper

          Do you view this as a simplification of projects or a political uphill battle?
          In the long run, I (we, OSIsoft) think this will be a simplification of projects. For those concerned with political battles, keep in mind you can configure PI Identities and Mappings in PI without AD, meaning you can go ahead not IT involvement whatsoever, and still have Kerberos authentication.

           

          At this point I would like to invite everybody to review the new "Configuring PI Server Security" guide available with 3.4.380. For instance, on page 24 you'll find "Other Security Configurations", where we talk about if you don't have access to AD or if your access is limited in some way.

           

          Jeff Hopper

          Anyone roll out the beta?
          Don't! It's now released  (see on the vCampus Download Center)

           

           

           

          As a side note to those who hesitate to upgrade to 3.4.380, note that it is possible to proceed with the upgrade and keep the existing security model (PI Users and PI Groups, passwords, etc.). Later, when your organization is ready, you can raise the security level (via the new "Security Settings" plug-in in SMT 3.3.x and later) and move toward real WIS.

           

          Just like Jeff, I'm still looking forward to hearing from network admins, PI admins and systems integrators of this world!

            • Re: Active Directory Security - Planning ahead
              JeffHopper

              Well as the fates have it, since the release of PI 3.4.380.36 fell right in the middle of a NERC CIP upgrade project which targets specifically tracking failed logins... we are becoming early adoptors.

               

              After a thorough pawing through of the "Configuring PI Server Security" guide and running through the install on our test machines, I have to concur with Steve that is is both possible to run with pre-3.4.380.36 AD security after the upgrade, with a couple notable exceptions:

               

              1.  It's not possible to have a PIadmin account without a password after the upgrade.  The upgrade will not let you pass by without a password on the "super user" account.  This reminds me of something.... ah yes SQL Server!

               

              2.  A long overdue clarification is performed automatically - PIADMIN group turns into PIADMINS group.  Thank you!

               

              In general I thought the upgrade was pretty painless.  And the IE like security slider tool for PI-SMT is very clear... though I miss piconfig.  ok no I don't.

               

              We chose to keep the security model pretty similar but we are:

               

              1.  Disabling password authentication for piadmin.
              2.  Disabliing password authentication for PI Users with blank passwords.

               

              The exlusiveness of information in the PI Message Log (for API connections and PI Trust connections) vs the windows event log (native windows authentication), means it's tricky to perform an auditing of logins for all methods.  It would be "nice" if PI had an option to insert login auditing events into the windows application log for API and SDK connections since it's easier for IT to scrape the Windows Event Logs then it is to run pigetmsg and parse its output.

                • Re: Active Directory Security - Planning ahead
                  dvacher

                  Hi Jeff,

                   

                  Glad to hear you went through the upgrade path and came back to write about it. Thank you!
                  I just wanted to add a couple of comments about your points.

                   

                  Jeff Hopper


                  1.  It's not possible to have a PIadmin account without a password after the upgrade.  The upgrade will not let you pass by without a password on the "super user" account.  This reminds me of something.... ah yes SQL Server!

                   

                  That's not entirely true. We force a non-blank password for piadmin for new installs only. For upgrades, we prompt you but you can still opt out, even if we highly recommend entering a strong password for piadmin (or better, disabling it for explicit logins).

                   

                  Jeff Hopper


                  2.  A long overdue clarification is performed automatically - PIADMIN group turns into PIADMINS group.  Thank you!

                   

                  You're very welcome. :) The PI Group PIUSER is now PIUSERS too, for more consistency.

                   

                  Jeff Hopper


                  We chose to keep the security model pretty similar but we are:
                  1.  Disabling password authentication for piadmin.
                  2.  Disabliing password authentication for PI Users with blank passwords.

                   

                  An excellent start! You should be able to gradually move away from PI Users/passwords and replace them with PI Mappings to Windows/AD groups & users. We allow mappings against existing PI Groups and/or PI Users for that purpose. Once you know Windows authentication works, you can disable explicit login for each PI User, and eventually adjust the server-wide security policy.

                   

                  Jeff Hopper


                  The exlusiveness of information in the PI Message Log (for API connections and PI Trust connections) vs the windows event log (native windows authentication), means it's tricky to perform an auditing of logins for all methods.  It would be "nice" if PI had an option to insert login auditing events into the windows application log for API and SDK connections since it's easier for IT to scrape the Windows Event Logs then it is to run pigetmsg and parse its output.

                   

                  Interesting requirement that we will certainly consider for the next release.
                  Thanks again for the feedback!

                    • Re: Active Directory Security - Planning ahead

                      Planning ahead from a development perspective we see WIS as a great way to simplify developments providing the correct Identities and Mappings are in place.  From most clients there is no real issue with Active Directory (except in some cases being a member of too many groups) so it is a case of setting up the mappings.

                      Thinking of the following scenario WIS is great way to reduce coding.
                      Using ProcessBook displays provides a way to have HMI displays for users to perform certain tasks above what their current PI Trust to a PI server allows them.  So typically when performing certain tasks some VBA code kicks in and changes the connection to the PI server using an explicit login (one that allows certain tags to be written to for a task).  Some other coding checks the domain user account of the logged on user and permissions to run the display are checked against a database.  Once the task is complete, the connection reverts back to it's original connection credentials.  Sounds simple but causes all sorts of disconnected states for open displays on the users machine so some more VBA ensures that everything changes without any interruption.

                      Part of the plans to move to WIS without explicit logins enabled mean that this gets so much more simpler.  An AD group is created for the task performed in the display & the relevant users added, this is mapped (PI Mapping) to a PI Identity that is configured in the DataSecurity attribute for write access to the required tags.  The code for managing the connection credentials and displays management become absolete and a lot more simple.

                      I am certainly excited to start rolling out PI WIS.