PI Users and PI Groups are primarily
a mechanism to preserve
our previous default security
mechanisms. So, it's something that, if you
have Version 3.4.380
of the PI Server or later, we
really do not suggest you make use of these PI Users or
these PI Groups at all. So, let's
start the discussion from that point of view. You know, if you, you are not in that
situation, if you do not, are not a Legacy User who have
lots of existing PI Users and PI Groups,
you should probably just stop the video and go on to the next video on
PI Identities, 'cause that's what we strongly recommend for security.
But, in any case, what a PI User is --
it is a Named User that has a password and
can be used for connecting to the PI System.
Now, a PI Group can contain one or more of
these PI Users, and, but Groups
cannot contain other Groups. So it is restricted
to just Users within Groups. And
then, these PI Users and these PI Groups can then be
made use of for the objects that require
security in PI, such as the PI Points. So,
for example, if I go out to this PI PointBuilder and see if we --
take a look at these Tags and in the security settings
you will notice that these
Point Security and the Data Security, we
can either associate PI identities or
these PI Users and PI Groups with their security
settings. Now, and the mechanism for that is
described in, in a lot greater detail in the
section later on about PI Identities.
So, I would suggest going there to learn more about that.
But, basically, as you, as you can see, you can choose
one of these Users here or identities
and then allow or disallow access
of different types: read, write, etc.
So that's what the, the PI Users have been
used for traditionally. They have been used as a
mechanism to allow people to log in using a Named
User with a password and then associate
that User with certain privileges by way of those
security settings in the PI Points. Now, there are two
PI Users that are created for every PI System by default:
piadmin and pidemo. piadmin
is for administrative purposes, and it's
kind of the superuser roughly equivalent to the
root user in UNIX. It's basically the master
user who get, can get to do anything
on the PI System. If you are logged in as piadmin, you basically
have access to everything. Now that's one of the main
reasons we suggest you do not use piadmin
as a User for just about anything
anymore. That's a very unrestricted access
to just about everything in the system, so we have
much better ways to go about granting
specific Users, Windows Users, access.
So, we suggest you use Windows Integrated Security
and mapping to specific identities
and no longer use that piadmin User.
Pidemo is a User that's set up just for, kind of
generic read access, and we see a lot
of longtime customers who have been using pidemo
for their general Users, to use with things like PI
ProcessBook or PI DataLink. Now I should point out that
these two Users are in fact --
nowadays, they are, they are really just a, a type of PI
identify. So, as you are going to see in a later video,
we describe identities as, you know, things that can
be mapped to Windows Users, and, and that
implement our Windows Integrated Security. Now PI
Users are essentially a special type of PI identity.
And like the regular PI identities,
they also can be mapped to, you know, through this
mapping mechanism here. They can be mapped to Windows
Users or Windows Active Directory Groups.
Now there is one situation in which you would want
to continue to use PI Users even if you do have the most recent
version of the PI Server. And that is if you have got
Windows Users that are in a domain that's a different
domain than the domain where the PI Server exists,
and there is no Trust between those two domains. In that
instance you would want to go ahead and implement
some kind of security, and that security can be based on
PI Users and PI Groups. So, to create a PI User
or a PI Group, just go into this SMT Application,
Identity Users and Groups, select the Users tab.
I will just create a brand new User.
And you can give him a password.
[typing]
And now this User can be used
where you would normally use an identify. It's really a special type of identity,
so I can go into the PointBuilder. I can now associate
that User, you know, let's go ahead and switch over
to Users here -- that User can be associated with
that object, and then certain privileges can be granted
based on the fact that he's logged in as a User.
So, when would that actually be used? When would
the User actually log in
and, and User, log in as a PI User?
Well, he would do that -- if you were to take a look at
the configuration here in the Connections
ialog -- he does that actually
at this point in the, this Connection
protocol sequence. What I am doing is looking
at the sequence in which we attempt to
implement security. The order that we are
using here is Windows Security first, and
if an incoming connection is not granted access using
Windows Security, then we will check to see if a Trust
exists, and if the Trust does not exist,
then we check to see if the User
can log in as the Default User. The Default User
in this case would be the PI User. Now that's
the User that you see listed right here in your
Connection Manager. That is the PI User.
Now that's a, a field that almost, almost
entirely you can ignore nowadays because
the, the, you know, as you can see that's the last thing
we check, and hopefully you are using the more robust,
the more secure method, which is Windows Security.
So, normally, under normal circumstances, it does not
actually get to the point at which we try to log
in using that PI User. Now, if
this PI User requires a password, that's going to throw
up a login prompt for the User to type in
the password. Or, if this has no password it will just
go ahead and connect them. So, that's the,
you know, those are the circumstances under which this PI User would actually be
used. And, because we strongly emphasize using
Windows Integrated Security, this is a field that most people are
going to be able to ignore. Oh, and by the way,
this is where I would put Fred's name if I did want
this incoming connection to be made using
Fred's credentials. Now if you are a longtime
User of PI, and you have existing Users,
one of the things that is different with the, the more recent versions
is now you can associate more than a
single User with a, a
security object. So, for example, back in our Point Builder,
this is something you really could not do before, but now,
I can select a Tag like this and I can add
multiple PI Users. That's something that we really
did not have the ability to do before, so if I,
you know, I had wanted to make a, a variety of these
Users associated with it I could do that.
And that's something that's relatively new.
Now I mentioned earlier that we do
suggest that you avoid using piadmin under any
circumstances. If you go in and you edit the piadmin User
you will notice that these are things that you can turn on and off.
So, one of the options we have is that we cannot use
piadmin as an explicit login. That's a real good
setting to make for piadmin. As I said, piadmin's
a Superuser, and so, with such a powerful User
like piadmin you normally do not want Users to be able to use that
for an explicit login. Now, many existing
customers are using piadmin as kind of the,
the User that is associated with
a, an incoming connection from an interface
that's done using a Trust. So, when
you create a Trust you can map that Trust to a User.
Well, piadmin is the Default User for many
existing PI Interfaces. It's not
the best way to go about it. You will see in our discussion on Interfaces
that we suggest instead of using piadmin,
you instead, you disable piadmin to be used in
Trusts, and instead, when
you build a Trust -- let me show you a Trust here
like this one for the OPC Interface -- when you build that
Trust, you instead associated it, not
with piadmin, but you associate it with an identity
that's specifically set up for that Trust.
So, you know, this is, this is where, if we wanted
to, we could associate this with piadmin, but,
well, actually, since I have, I have disabled it, it cannot do it right now.
But that's where, in many existing
PI Systems, you will see that piadmin
is associated with Trusts. We suggest you do not do that.
And so to further that, or to help you do that,
you go, go into piadmin and you can disable
this. So, if you are one of those folks
that has a lot of existing PI Users
from before we implemented Windows Integrated
Security, we do have a nice document that suggests
how to migrate all of those Users.
If you go out to our tech support website, you will
find this document, PI Server 2010, Configuring Security,
that has a section, a Quick Start, on Migrating.
So, one of the things that we would suggest if you are migrating
with a lot of existing Users -- let's say you have
got let's say 200 of your Users
who are currently all
logging in as a User called
pidemo, for example, or in some cases people
had created PIUsers -- let me go, go back to our
User Group here. Let's say you have got a User called
PIUsers, or PIUser
[typing]
Let's say you have got 300 Users who are
currently using that PIUser and the,
the way that they are being mapped to this User, PIUser,
is through the older, let's say,
either the older Trust mechanism or maybe they are just actually
typing in the password for PIUser, or maybe PIUser
does not even have a password. What you can do in that case
is you can, with this User, map
this User to your Windows Users.
So, if you have got 300 Users that are currently logging in
explicitly, you can just take all of those Users, put them in
a Windows Active Directory Group that maps,
through this mapping mechanism, to that PIUser, and
then all the security settings that you have set up in the past should
continue to work. It's just they are using a more
secure mechanism. So that would be a good first step
if you have got existing Users who are logging in either
using a password or with no password or mapping to
some kind of a Trust. Now, even though we do not recommend it,
I would like to go ahead and demonstrate what it would look like if you were
to log in as this User, Fred. As I said, we suggest
you use Windows Integrated Security instead. But, let's say
you are in that situation where you have got a Windows Users
in a different domain than the PI Server. Now to demonstrate
this, what I am going to do is, I will show you first
of all how it can be done poorly by forgetting
to do some things, 'cause this is typically what we see happen in the field.
And then I will show you the corn...the correction to make.
So, I am going to go ahead and run a program here that's going to
try to do an explicit login. I will go into Pi System
and I will choose this About PI SDK.
Okay. Within About
PI SDK I can see a Connection Dialog. This is just a little,
little utility we use for different things within the PI
Server. But, the important thing I am looking for here is this
Connection Manager here because what I want to do is I want to
explicitly define that I am going to connect
using that User called Fred.
And if we look at our options again, we will notice
it's going to attempt Windows Security and a Trust first.
And if it does not connect under either of those, it's going to go with that
User, Fred. Now, I know for a fact
that this particular application there is no Windows -- well, I am not
logged in as a Windows User who has access and also
there is no Trust configured for this application, or this
computer. So it should go to the third method.
So I will go ahead and change this to Fred.
I go ahead and save that. Now this is going to fail first time I try
to do it and I will show you why. It's attempting
to connect. Here's the, the key here. It says
Authentication method is disabled by current
server policy. That's the clue here. I have
actually done this to myself. My current server
policy, if I go into Security Settings, is
to disable explicit logins. So let me
go ahead and allow that.
Now I will still keep it disabled for
piadmin. Now this does require
a restart of the PI Base Subsystem.
So to demonstrate, let me go ahead and go into
Operation here. I will go into My Services
and I am going to restart this PI Base
Subsystem. Okay,
now having just stopped and restarted that --
now if I go back to my Interface Node,
because I have
made a change here in my Security Settings,
that change should have taken place,
or taken effect, and now, if I attempt to connect as
Fred, it should prompt me for
Fred's password as you see it's doing right now.
So, I did configure Fred with a password. If Fred had
no password, then that would not have appeared. It would just,
would have just connected to me, or connected me to PI as
Fred. But, I will go ahead and provide his password.
And as you can see, it's now connected as Fred.
So, again, we do not suggest you do it, but if
you do need to do it, that's how you would go about and doing it.