In this lesson we'll have a look at user access to the PI data archive
but before we get into the nitty gritty let's have some light revision on how security works.
A connection comes in to the PI data archive and if they've got a mapping then they're given an
identity. This is a little bit like a security badge that they can use to gain access to parts
of the system. More accurately they're usually assigned multiple identities so in this case
they're assigned to the PI admins identity and also the PI world identity. By default
all authenticated connections are always assigned the PI world identity so after they're in they
have permission to do whatever their identities are allowed to do. This card they can scan to
do whatever they want and they can switch it out for the other identity if they want to
and see if that one works. So essentially when we want to give them permission to do something we
have to give one of their identities permission to do it. So this PI world identity is really
an easy way for you to configure default baseline security access for everyone.
You can see these identities when you connect with client tools so in PI SMT
is at the bottom left-hand corner of the window it looks a little bit like this.
Okay back to what we're doing in this video your goal here is to set up a security model
that is secure, requires very little maintenance by you the administrator. When configuring user
security we're going to lean heavily on windows active directory groups. We already
know how to create mappings we've done that for interfaces already so creating mappings for users
is essentially the same. When we created the mappings for our interfaces we created a
mapping for the svc PIINT account this account has already been created by our IT department, it's a
domain account. When we configure user security we're going to create mappings to domain groups
containing the users we want to access the system. When you do this in the real world
you could leverage already created groups in your company or work with your IT department
to create special groups for the PI system. We recommend creating groups for PI administrators,
PI interfaces, PI users and PI point and analysis creators. Those are really the bare minimum you'll
need. Once IT has created these groups you'll need to create mappings for them on the PI system.
After you've created the mappings your job's basically done.
When a new user needs access to the PI System they'll make an internal request
to be added to one of these groups by IT and go through whatever internal processes
your organization has and after they have been through those processes essentially it adds them
to the group and they automatically have access to the PI system. On the virtual environment we've
been using so far our IT department has already created these groups we'll create identities and
map these groups to the new identities but we also need to talk about how to configure access for
each one of these identities. PI administrators should have access to everything. The default PI
admins legacy group already has this access we're just going to leverage that. We already have our
PI interfaces identity it has no permissions explicitly given but we have given it permission
to write to specific tags. We'd remember to do that whenever we create new tags. PI users is
a completely new identity we'll need to create, so we'll create it and set up the mapping to the
domain group. We don't really need to create any special permissions for users either,
by default users will have read-only access to tags through the PI world identity anyway.
In some situations you'll need to create multiple different user groups and give them read access to
different tags. We're not going to configure this situation right now but it's common on a joint
venture project so if you've got a system shared by employees and contractors and if you're doing
this you might need to set up multiple groups and give employees access to a certain set of tags
and contractors access to a different set of tags. If you do something like that then you'll
need to set up these multiple identities and groups and then disable the PI world identity.
Our last identity PI point and analysis creators is also a new identity.
We're going to give this identity permission to create PI points and essentially everyone
in your organization that needs to be able to create points should be assigned to this group.
So right here is our security mapping as we've configured it so far in this course.
We have three mappings and they all serve very specific purposes. We're going to add in the
rest of the identities that we just talked about and also map them to our domain groups.
So the first one is PI administrators, so this domain group already exists we're going to take
advantage of it and map it to PI admins here. So let's say new, find our windows
account or our windows group click on the ellipsis and here we've got PI administrators
and okay on that and the identity we would like to map it to is PI admins.
Okay next up we have PI interfaces so we've already got this mapping,
mapping our service account directly to the svc PIINT identity. Let's make that a little
more compliant with our model the first thing I'm going to do is go to identities users and trusts
and then rename our svc PIINT identity to match our group that we're just
about to map it to. So I'm going to go into properties and change this to PI interfaces.
Now when I go down to mappings and trusts I see that my service account
is now mapped to the identity called PI interfaces. So I'm going to make a new
mapping. This mapping is going to map the domain group PI interfaces let's search for that.
Okay now it's going to map it to the PI identity PI interfaces.
Next up we have PI users, so PI users will be a completely new identity,
let's go to identities users and groups now let's make a identity called PI users. New identity
PI users and create. Now we need to go to mappings and trusts
and map our domain PI users group to this PI user's identity. So let's make a new mapping,
our windows account will be PI users and our identity will be PI users.
Now we don't need to do anything special for PI users either, when a PI user connects and
gets authenticated they will get the PI world identity anyway and PI world already has read
access to everything that the users will need. Now our last one is PI point and analysis creators.
So let's make an identity for those and we'll make a mapping.
Okay we've got our mapping, we've got our identity. Now this one will require some specific
permissions, we need to give this identity permission to create points and how we do that is
we go into database security and we give this new identity write access to the PI point database.
So we'll double click on PI point and then add in our new identity.
It's going to have read write permission and okay. So we've created all of our new identities.
Now the very last thing to do is clean up a little bit.
Let's go into identities users and groups and the PI data archive comes with these default
identities that we're not actually going to use so I'm going to remove them one by one, engineers,
operators and supervisors. Everything left are identities that we are actually actively using.
In this lesson we talked about how security works on the PI data archive and how to apply
a minimum security configuration using best practices. You can go above and beyond this
obviously, but this is really the minimum that we would recommend you set up.