In the previous video we
learned how to recognize common security errors
such as these ones here. And we
also saw that as a user
we can successfully test if we
can connect to the Data Archive and we can
also see that if we are successful, specifically
how we are authenticating. In this video
we'll step through as a PI System
Administrator how can we check the authentication
for all the different
connections to the PI Data Archive which will allow us to identify
any missing access permissions for
any of our users or our applications.
This is going to allow us to troubleshoot
security issues and it will
also allow us to confirm the success of our
current security setup.
Now if your users are reporting errors
from the steps in the previous video, that's a
great starting point. If they aren't
sure how they are authenticating because they are using a web based tool
like PI Coresight or if you are setting up some
new permissions for users and applications and you
need to make sure that everything is working properly,
the first thing that you'll want to do is determine
basically how are your users and
applications authenticating? Essentially
what identities do they receive? And
we are going to be able to look at this for all of the
connections by using Network Manager Statistics
in PI System Management Tools.
After we know how a user
or application specifically authenticates,
we will then want to be able to
determine what are they authorized to do? This
essentially means checking what permissions
the identities they have received.
From there we can also reference
what access permissions are needed to complete
specific tasks that they may be trying to
do and this will allow us to identify are there any
missing permissions that we need to grant.
All these steps are really great if
a user or application is able to make some
sort of connection. But what about the
case of unsuccessful connections?
We need to make sure to look for
any unsuccessful connection attempts as well and
determine whether or not we need to setup
security to grant these connections the
ability to authenticate on our Data Archive.
I'll show you how you can do this with the
message logs in PI System Management Tools.
And finally at the very
end if for some reason a
user or application doesn't seem to be receiving
a mapping or a trust
when one has been correctly and properly configured,
we'll look at does their connection
protocol order matter. So let's start off
by checking how our users or
applications are authenticating with
the Network Manager Statistics in PI System Management Tools.
So I'm going to jump to a
machine where I have PI System Management
Tools installed and I can look at
Network Manager Statistics if I have the
correct PI Data Archive selected. If I go down
to operation and then right here
you can see that we have Network Manager Statistics.
And Network Manager Statistics
as you can see is providing information
about all the different connections to this PI Data Archive.
We can see local connections,
we can see remote connections and we can see a lot of
information about the individual connections.
In my case from a security
perspective, I want to focus on the remote
connections to this PI Data Archive. So I'm going to
use this column here, peer address,
to sort by the IP
address. So I'm going to sort by IP and sort
in reverse order so that all of the remote connections
show up here.
Let's look at some of these remote connections.
So first I want to focus your attention to
these ones here. And if we look at a
specific connection, we can tell
what is the application that's connecting. For
instance here I can see the PI SDK
utility. I see PI System Explorer,
PI DataLink, PI SMT, and PI
ProcessBook. And I
can also scroll over and see
that there are many columns presenting
information about these different connections.
Now towards the end, I want to point out
a couple of very important columns.
Here I can see the
Windows user and I can see
what identity that Windows user
received. So for all the
different client applications
that I've highlighted, those connections look like
they are all coming from Lucy
our engineer and we can see
her Windows credentials here and we
can see that she is receiving
these identities. So this is how she is
authenticating. She's receiving all company and
process engineers. This makes sense because I know the mappings
that we have in place will grant her
these identities.
Let's scroll back and look at some of these other
connections. I mentioned that leveraging
Network Manager Statistics is going to
be a really great way for us to look
at our PI Coresight connections.
So in this case at the top here, we
can see first the PI Web API
crawler service that's used by PI Coresight.
And this one right
here, the W3WP.exe
is our PI Coresight App Pools connection.
So in
addition to scrolling over, once I have a
specific connection selected, you can see
that the information is also getting
reported down here. So different ways to look at the same
information. And remember when we
were scrolling over, we were really focusing on
this user
and we were also focusing on the identity column.
And this is the same information.
When you are looking at the PI Coresight
connection, it's important to remember
whether or not you have Kerberos delegation configured.
So in this system we have
Kerberos delegation configured and
that means when a user
connects to the PI Coresight Server over a web browser,
we are actually passing
their Windows credentials and we are
then checking to see those
credentials, how they authenticate on the PI Data
Archive. And what data they should be
able to access.
So in this case this first one
here that's the account that we are running the PI Coresight
App Pool and you can see that it's a service account
and it's being granted the PI Coresight identity.
I'm going to also point
out that you'll notice that the
different identities as well as the different
users, those are separated by commas.
So remember the first one, that was the service
account and the next ones are users.
Here we can see
that we have Lucy
who connected and that Lucy is
receiving these identities.
You'll also notice that
I'm connected, we see my Windows
credentials here and that I'm receiving different
identities which is going to allow me to
potentially see different things when I am looking
for data in PI Coresight.
OK, so now you have a really great idea
of how to look at the PI Coresight connection. What about
some of our other applications?
If we look in this list here we can
also see our
connection from PI Buffer Subsystem
and we also see a connection for our PI Interface
for OPC DA. And then we also
see that PI ICU is open.
So these must be all coming from our Interface
Node. I'm going to look at
all of them at the same time. So I'm going to scroll
over. So what I
can see here is again this is the account
that we're running PI Buffer Subsystem Windows
Service as. And that it is receiving this identity.
Additionally I can see that
my user is running the PI Interface
Configuration Utility and so these
credentials are
being used for the PI ICU.
OK, now if we look at PI
Interfaces, we don't see anything in this
user column. It's completely blank.
And that's because our PI Interfaces are
connecting with the PI API
protocol. And so those have to use PI Trusts.
Scrolling over, we can see the
trust column. So in this case
we have our PI Interface for OPC DA
is connecting with the
API has to use a trust and this is the specific
trust that it's using. And this trust is
granting it the PI Interfaces identity.
OK, so as you can
see this is a great way for me to find
out which users and applications are
connecting, how they are connecting,
and what PI Identities that they are receiving.
I'm going to make one important point here
in case you have PI World enabled
on your Data Archive. PI World is
a default PI Identity and we are using
custom identities and you can actually see that none of these
are using PI World because PI World is actually disabled
on this Data Archive.
You can see whether or not PI World is enabled if you
go to security and identities, users and groups.
So if PI World is disabled, what
you'll see is this. It will look grey.
So in this case I know that PI World access won't be
granted. However if PI World
is enabled and you are looking at
Network Manager Statistics,
for your PI Interface which is connecting with
a trust or any other connections that you
have that are connecting with a trust, you will
see just the identity that is assigned in the
trust but you won't see PI World.
However remember that any authenticated
user to the PI Data Archive or application
in this case is going to receive
PI World if it's enabled. So just keep in
mind that if PI World is enabled
we won't see it listed here
but remember that there are additional
permissions that could be granted by the fact
that the authenticated users
and applications receive PI World.
So just an important point to keep in mind.
Now that we understand how to check
the identities that
our applications and user receive,
we can then start looking to see what are they
authorized to do? Remember that
checking for this is something that we can do by
looking at database security for the
high level. So under database
security, we can see, what is
all company for example authorized to do
by checking this table.
Additionally
for individual items such as
PI Points, we could look at the permissions on individual
PI Points.
Under the security tab.
So checking both the
database security and point
security or other individual security areas will help
us determine what are the
applications and users going to actually
be able to do on the PI Data Archive?
And if anything is missing,
that helps us know
what permissions we additionally need to grant.
And if we aren't sure what permissions
are needed for different tasks,
remember that a good reference is the
task based access permissions reference
that's a table that can be found
in the PI Server user guide on our
PI Live Library. And remember in this
table we can see that for a given
task what database security permissions are
needed and if any other permissions are needed.
Keep in mind that individual
user guides for different products may
also provide additional security permissions
information.
And to refresh your memory on how to make
security changes to either
the PI Points or on
the database security table level,
keep in mind that you can check out our previous
videos on configuring PI Data Archive security.
Now this is all really great for
our users and applications that can
actually make a connection but what about if
there is not security setup and they
simply can't connect at all. How are we going to be
able to know that? To look for unsuccessful
connections, we'll want to use the message
logs. So let's go to the message
logs
and to search for unsuccessful connections, we can actually filter
the message by including unsuccessful.
And doing a search.
In this case you can
see that I don't have any unsuccessful connections
within the last 5 minutes. So let me broaden my
time-range.
OK, and now I can see what an unsuccessful
connection would look like. I would see
this message that says unsuccessful
login.
Now if I expand this and
start looking at these messages, it will provide me
details as to
the connection ID, the IP
address that the connection was from.
The application that was being used
and what credentials were. So in this
case I can see that this Windows user
was trying to connect and you'll also
see what method was tried. In this case
I see Windows login. Windows login
means checking to see if a PI mapping is available.
We can then see the
error that no mapping existed.
Using all of this information
if this user needed to actually
connect, we would be able to
create a PI mapping for them.
Let's look at some of the other messages.
OK, so scrolling
up we can see that this message is pretty similar
and the only difference is at the end
we see that this is for the method trust and
we see that no trust was available.
And finally we see that this
message has the method of explicit
login and that this authentication method
is disabled by the server policy.
In conclusion, the message logs
are going to allow us to find out if
we have any unsuccessful logins
to the PI Data Archive. And the
messages themselves provide information that we could then
use to setup a new mapping or
trust for the particular user application
that's trying to connect if indeed
they should be able to connect to this Data Archive.
As a final note, you might've noticed that all of
these have the same connection ID and
essentially this is all the same connection.
But we saw three different unsuccessful login
error messages. Why was that the case?
Well for SDK connections
there is actually a
protocol order that the connection goes through.
First by default it will look for a
mapping, if that does not exist, by
default it will look for a trust next. And
if that does not exist then it can go
to using the explicit login method. These
are just the defaults for the connection protocol
order and the reason why
I bring this up is because
if for some reason a user or application
is not receiving a mapping or a
trust that you have setup that you would
expect them to receive, you may need to make
adjustments to the connection protocol order on the
machine that they are connecting from.
For more information about the connection protocol order,
you can check out our documentation.
I hope you now have the tools to
successful troubleshoot security issues
as a PI System Administrator.