In the previous
videos we've configured identities
for our users and applications. And
we've setup mappings
for all of them except for our PI Interface.
And for our PI Interface we setup
two plus trusts. And this is really great because we've
made sure that we are using the most secure
authentication methods possible.
However if we don't make sure that
we've also disabled the ability to use
the less secure authentication options on our
PI Data Archive, then we are at risk. So
let me show you where the possible authentication
options are setup and how we can make
sure that we are at the recommended
settings. So we are going to do this in
PI SMT and I'm going to go
to the security plug-in and navigate
down here to security settings.
So when I click on
this you'll see this security slider
bar showed up. And the reason why I can see the
settings here is because how I authenticate
has read access on the
PI Tuning and the PI User Database Security tables.
And if I have write access on those
tables as well I'll be able to make adjustments here.
You want to make sure that
you are at least at this level
and that all three of these have green
checks indicating that these are disabled.
You can learn about these different
security levels in our PI Live Library.
We have this section which specifically
goes through what all these levels are.
A few things that I want to highlight
is that these three
they really deal with an outdated
authentication method. Prior
to data archive versions 3.4.380.36
there were PI usernames
and passwords. And a given user could
type in any username and password when connecting.
And this is what we call explicit
login.
Now we
introduced integration with our Windows Active
Directory accounts in 3.4.380.36
which is why now we setup mappings to our
Windows groups and accounts. But
the explicit login method still exists to support backwards
compatibility. And even in new
systems there are default PI Users that still exist.
I want to emphasize
that using explicit login is not secure.
And we want to make sure that our
users and applications connect with mappings
and trusts. And that they cannot use
explicit login. To make sure
of this we want to make sure that our
security settings here are at least at this
level. Let me show you what could happen if our
security settings were not at this level.
For example, here the security
settings are in the lowest possible
level. This means even blank passwords
are allowed. Now let's say we have a new
employee Andy. And Andy hasn't completed
his training yet. So we aren't ready to give him
access to the PI System. But let's say that he's
curious about some of the clients that are
installed on his machine. And decides to open up
PI SMT.
And just click around.
Depending on the connection settings on his
machine even if he can't authenticate
with a mapping or a trust, he could
receive a login prompt just like this
which would allow him to explicitly login.
Now Andy doesn't know the
PI Demo password but in this case
PI Demo has a blank password. So if he
hits OK, he is now authenticated
on the Data Archive.
Down here we can indeed confirm
that he did authenticate as
PIDemo and keep in mind
that this essentially gives him access
without mapping or a trust. Now
hopefully PIDemo doesn't have permissions to do
many things. But it illustrates the importance
of disabling blank passwords.
Let's look at another example.
Say our security settings have been moved up one level
higher. So we are no longer allowing blank passwords. But we are
still allowing explicit
login for PI admin. What could happen in this case?
Again Andy still shouldn't
have any access and he
can still try to open up PI System Management
Tools and again click
around. And depending on the
connection settings on this machine, he may
receive an explicit login prompt. And let's
say the username is currently
setup PI admin. Now fortunately on our
server, PI admin doesn't have a blank password. But
maybe Andy guesses it because it's a
common password at the company or he's even seen the
password written down somewhere at somebody's desk.
Oh no,
we can see that he was successful
and that means he was able to authenticate
as PI admin. Again this is without
the mapping or a
trust. And PI admin
happens to be the very worst possible case
because PI admin is a superuser
with all privileges on the data archive.
I think this
makes it really clear that we absolutely
want to make sure to disable explicit
login for PI admin to avoid these type of
scenarios. And we want to avoid having
anyone be able to use PI Users to explicitly
login. This method is not secure and
it circumvents the mappings that we have setup.
Given this, we want to make sure to
bring our slider bar up to the recommended
default level. If you
are in an existing system and the slider bar is
not at this level yet, you want to make sure to
shift all your users and application's
authentications to newer methods by creating mappings
and trusts. And after successfully confirming
they aren't authenticating using the older
explicit login, then move the slider bar
up to this setting. Keep in mind
that adjustments to the slider
bar as you can see are going to typically
require a restart of the PI Base Subsystem
to take effect.
Lastly in our
system we are only using trusts for our PI Interface
and that means that we only have
API trusts.
Since we aren't using SDK
trust for things like PI Coresight but
are using mappings instead, this means that we'll be
able to move this default
up to this level
and disable SDK trust.
And this is an even more secure configuration
that you can do as long as you aren't using
SDK trust. Now if you are using
PI Interfaces, you'll always need
to have API trust and so this is going to
be the highest level that you can
use for security in that situation.
With that I hope you ensure that the least secure
authentication methods have been disabled
on your PI Data Archive.