Beginning with this version of PI right here, we
started supporting Windows Integrated Security.
And in this video what we are going to look at is how to configure
a, an, what's knows as an
Identity that makes use of Active Directory
Users or Groups to allow somebody to connect
to the PI Server. Now, we are not, in this video,
going to be talking about setting up
security for tag configuration for editing tags.
We actually do that in a separate video called PI Tags
Security Configuration. That's coming up next.
For right now, we will get to the point where you can create a User,
a Windows User, create what's called a PI Identity
and then, by making use of that Identity,
we will go ahead and grant that User access to the PI Server.
So, the key here to granting access
using Windows Integrated Security is this concept
here called a PI Identity. A PI Identity
is a construct we have created that allows
you to, basically, to associate certain
privileges with that Identity and
the most basic privilege being just world
access, meaning the ability to even connect to the PI Server.
And, we map those
Identities to these Windows Users. So, Users
come in, in really two flavors. First you have
the individual Users and then you have individual Groups of Users,
Windows Active Directory Groups. Either of those
can be mapped over here to this, what's knows as a PI
Identity. So, that PI Identity gets mapped
to a Windows User, and that's how we accomplish it.
So let me show you what it looks like in, in action here. I will
demonstrate a User who has privileges
to, to connect. What we are looking at
is a PI Server. And, I will go in
to this right here. This is under
PI System, the PI System Management Tools.
And
I am going to go into the Security Section. Actually, mine's already open here.
And, if we take a look at this
construct, this Identity here, called
PISUP. PISUP is an
identity that I have created specifically to allow
Users, certain Windows Users,
to connect to the PI System. If we look at our
mappings, we can see we have mapped this
to a -- this is actually a
Group, an Active Directory Group in a domain
called VIRTUALLABS and the name of the Group is called
Solution_SUP. But I could add
other Windows Users to this, to this particular,
you know, Identity here, or this mapping I should
say. I can map other Users to this Identity.
In this case I have just mapped the one Group of Users.
Now, that's going to
help anybody who's in that Group. And if we take a look at our
Active Directory Users here,
we will look at this group called
Solution_SUP.
That's an Active Directory
Group. And in this case, we have,
we actually have two Users.
One called solution_samjones, solution_sidsmith.
Now these are Domain Users, so if anybody logs
on as a Domain User,
that Domain User through this mechanism that we call
The Mapping here, that Domain User gets mapped to PI
Supervisors, or this PI_Sup Identity.
What privileges does PI_Sup have?
Actually, PI_Sup has no privileges, but
it is a named User, it is
an identified Identity, so it does have one
privilege and that is it has the privilege of
World, basically being or meaning
that it is a valid User. So, at the least,
it's going to be able to connect to the PI Server.
Let me go ahead and demonstrate. I am going to go ahead and close out this
virtual machine. That's my Virtual Server.
I am going to open up my virtual
Interface Node. This is a separate computer that we have been using
for interface testing. It's a separate virtual machine
and it's connected to the PI Server. Now this
particular User that I am logged in
as right now, the User I am logged in as right now
on this machine is the administrator.
And the administrator is, well, he's not that User that I
had identified just a second ago. He's the administrator.
So, if I attempt to connect to this PI Server,
using this Connection Dialog here,
you are going to notice it's going to fail. It's going to fail
because administrator, though he may be a big deal
over here on this computer, he really does not have any privileges
over on the PI Server. So, who does have
privileges on the PI Server? Well, if you recall,
it was that User called -- I think we called
him solution_sid and sam.
So what I am going to do is go ahead and log off and log back
in as a new User.
Okay, now, here's where I would go to go
ahead and log in as that User, solution_sam.
And,
what you will notice is
unlike the administrator, when I log
on as solution_scan, sam, when
I attempt to connect, because there is an Identity
that maps that Windows User to,
or I should say, because there's a mapping . . .
Now, what you will notice is when I
attempt to connect to the PI Server this time,
because there's a mapping that maps that
Windows User, solution_sam, to
an Identity that, that exists as a legitimate,
you know, PI User or PI Identity,
then that's going to allow me to connect. Just the fact that he exists,
even if I do not have any privileges, it's still going to
allow me to connect. So, I will go ahead and choose Connections.
And, I will go ahead and choose --
you will see -- look, look right down here. What you will see is how I am going to
be connecting. So, I click on there and it should tell
me how I connected and, yes, it says it's --
I connected as solution_sam.
Even though this is -- the default is pidemo
here. This is actually a connection mechanism that will
kick in only if some of these other -- the Windows
Integrated Security fails. So,
in this case, we do not attempt that. We just go ahead and connect as that User.
So, that's quite a bit different than if I had logged in as administrator
and tried it. As you saw, when I did that, it just did not allow me the connection.
So to demonstrate, let me do it from scratch. I will just go ahead
and create a brand new User, as, as many of you might have to do.
This User, we want him to be able to connect to PI.
And that's all we are going to do right now. Just give him access to
connect to PI. We are not going to set up any, any point-by-point
security at this point. So my PI Server also
happens to be the Server that's running Active Directory, so I will
configure a new Active Directory User.
And we have got a Sid and a
Sam. Let me create a new one. We will call this guy
Sal, and we will go ahead and
set him up thus. So,
there's Sal. If I wanted to, what I could do is I could
create a new Active Directory Group and then put
Sal in that Group. I want to keep it simple this time though,
because when you create an Identify, you can associate, or map
that Identity to either a Group or a User. In this case,
just to demonstrate, I will map it to a
User, this Sal Test.
Now you will notice that in the previous example
we actually had mapped this -- what is his
name? -- solution_sam? Yeah, he was actually mapped
to a Group. We look at his Properties,
you can see he was a member of something called
Solution_SUP, and that's what I had used
to map that Solution_SUP
Active Directory Group to my Identity. So, it was because of his
membership in there that he was granted the privileges
of that Identity that I created. But, in this case, we are going to keep
it a little bit simpler. We will just simply map him
using this Sal Test. So, I have done just about everything
I need to do over here. Let me go ahead and
go into the PI System,
under the, this is PI
SMT, and I will create a new Identity
that will grant him permission. So, let's,
let's choose New Identity.
For this, I will just call this sals_
identity.
And that does not really accomplish much until I map
that Identity to something.
I need to map this through this Mappings and Trusts.
You can also map it over here.
I can go ahead and create a new Mapping, and,
and then, at this point I can go ahead and specify
the Identity. So,
either way, you know, here, here's the Identity I just created,
sals_identity. Either way. Probably the easier way is just go
back into that Identity and let's
map this Identity I created to that
Sal as the User, the Active Directory User.
I will go ahead and choose Add. I need to go out and
find Sal.
I will go ahead and check the names. Yeah, there we go, Sal Test.
That's the User.
And, he's mapped, as you can see, to this Identity called
sals_identity.
There we go. So the big finish, even though we really have not given him any
privileges now --
There we go.
Now, the grande finale to this is that he
should be able to connect using that User, the Windows
User called sal_test because he does have
a valid -- he is mapped to a valid Identity.
He does not have any privileges as that Identity, but he is
mapped to a valid Identity. So properly test this, let me go
ahead and launch that remote session where
I am going to log in as Sal.
He was this Domain User, and let me type
in his password.
And, as soon as this launches we should be able to test
to see if Sal can connect, and how he
connects will be important. We will keep an eye on the
bottom right-hand side of our screen when
we do that connect. So, under PI System, we are going to go into PI System
Management Tools. We will run that same Connection Dialog
we saw before, a couple of times, in which --
remember, the administrator failed to connect -- so, if we go into
File, Connections. Now, having logged in as Sal, my
brand new User should be able to connect
and there we go. Here's our big finish. A
VIRTUALLABS-Sal is the User we are currently
connecting with. It's his credentials, but,
that are being passed on to the PI Server, and it's through that
mapping that we map that Windows
User, Sal, to that identity called
sals_identity, and that's what -- because he is a legitimate
User, that's what gets, grants him access.
Now there's a few things I have not mentioned yet about
Identities. First of all, there are four
default Identities that you will find in the PI
Server when we first install it. It's these four right here:
Engineers, Operators, Supervisors and PI World.
And you know what? The first three here, you can
pretty much forget about 'em and ignore 'em if you want to,
because we just put them there as a kind of a courtesy or
just a kind of a, you know, here's something to get you started.
But they really do not have any specific privileges
or any restrictions and, and in fact,
you can, if you want to, you can just go ahead and delete these if you want.
They do not really do any, you know, do anything that's
specific or useful in the system other
than give you a mechanism for starting to
divide up how your Windows Users, or Windows Groups,
are going to be organized. In that case, we just had a,
an Identity called PIEngineers, and
presumably that's where you would map all of your Windows Users
who are Engineers. Since I deleted it, I can, you
just as soon put it back or create a new Identity
for my Engineers that's, that's called something else.
Does not really matter. Now, this fourth Identity is called
PIWorld. That's one that actually, you cannot
delete. The PIWorld Identity is, is basically
the Identity that any validated PI
User is mapped to. So, if,
if we have a User who's validated either through a Trust or
through a login, he's going to be mapped to PIWorld. As you
can see, it's described as this built-in Identity
and it's something that, although you can rename it
if you want, for whatever reason, you cannot really delete it.
Now, another thing about Identities is
a, a, a mapping of a Windows User
can only occur with one Identity.
So, in this case, Sal cannot be mapped to another Identity.
Now if you want Sal to have the benefit of having,
of being associated with more than one Identity,
you can create multiple Active Directory Groups, make
Sal a member of each of them, and then --
an, an Identity can be mapped to more than one Group.
That's not a problem. Now, lastly, if
you create Mappings, you have the option when you create
that Mapping, to associate that
Windows Account, as we saw, with a PI Identity.
But, in addition to associating with a PI
Identity, you can actually associate it with
a PI Group or a PI
User. Now, both of them are less desirable.
Groups and Users are still supported because
that's originally the only mechanism we had for security in
PI. You could have Groups of what we call PI Users
or individual PI Users. We do not
suggest you create mappings to those Groups and
Users. We suggest you go ahead and make use of
this new Identity Concept. That's where all of our strongest
security is, is associated now, and where all
of our development in the future will be. So
although you can map to individual
PI Users and PI Groups, we suggest you, instead,
map to Identities, and then use those Identities when it
comes to setting up specific privileges
for certain protected objects, or secure objects.
We will talk more about those secure objects -- you know there's
Points, etc., that can be edited only by some,
certain people -- in our next video.