You are likely familiar with using service
accounts managed at the domain level to run some PI
applications like PI Buffer Subsystem.
Using Windows Integrated Security to authenticate
those applications to the PI Data Archive using
mapping. If you are using PI API 2016 for Windows Integrated
Security, you may even be doing this for API
connections such as PI Interfaces. This
was all possible because the interface in PI Data Archive
are in the same domain. And Active Directory
manages the user and service accounts across the domain
with their associated passwords. However,
what happens when your interface is in a
workgroup but you still want to take advantage of the benefits of Windows
integrated security and PI API for Windows
integrated security? The interface node doesn't
recognize the domain users or service
accounts. And if you setup local accounts on the worker
machine for your users and services, they won't be
recognized by machines on the domain. So you won't be able to
authenticate to the PI Data Archive using Windows
Integrated Security. Since security is a top concern,
we want to avoid 2+ trusts.
The solution is Windows Credential Manager
which let's us store domain credentials on a
workgroup node and link them to local accounts.
This video goes through linking these accounts. In addition
to setting up these links, we will verify connection
information on the PI Data Archive for the
user, buffer and interface from the workgroup node to
show that credential manager is working. Additional
information can be found in KB01457
using Windows Credential Manager with PI
Applications. In this video, we will be linking
local accounts on the interface node to low
privileged destination domain
accounts. Note that the KB also describes an alternate
approach of using different local accounts on both the interface
node and the PI Data Archive node and linking
them with Windows Credential Manager. The
approach of using two identical local accounts on the interface and
PI Data Archive node should be
avoided. Let's take a look at some details of our environment.
On the PI School domain, we have our two service accounts,
SVC, PIBuffer and SVCPIInterface.
And Student01 user accounts with their
domain passwords. These service accounts are used across
the domain for other interface nodes that are connecting to the PI Data
Archive. The two service
account have been provided minimum permissions needed on the archive, through
PI Mappings and Student01 is mapped to PI
Admin. On our workgroup interface
node, PIInt02, we are currently logged
in as InterfaceLocalAdmin using
the password of that local account. The interface
is running as a local account, PI OPC Interface,
and the Buffer is running as local account, PI Buffer.
And we'll take a look at that in just a second.
Again, we had to use the local passwords for the workgroup
node to setup these services. We've
already setup the interface in PI Buffer
but have disabled the Trust and the PI Data Archive that was
used during that setup. Also note that the interface
node does have API for Windows Integrated
Security installed, so we will be able to use a
Mapping for API connections such as the PI OPC
interface. Let's start by going over to the
interface node and confirm the local service
accounts. Let's go into
services,
and you can see that
PI Buffer Subsystem is setup using a local
Surface account PI Buffer. and
OPC Interface is setup using a
local account, PI OPC Interface. However, neither
of the two services are currently
running. Let's now go ahead and open
ICU. Since we are logged in as
Interface Local Admin, ICU will be running under
those credentials. When it tries to connect to the PI
Data Archive, it will also use those credentials.
Since they are off the domain, the PI Data Archive will not
understand who we are and will get a security error as shown
here. As an example
to what these types of errors can look like on the PI Data Archive node,
let's head on over to that node on the domain
and open up System Management Tools.
Let's go to
operation, message logs.
And let's load the last five minutes of
logs. You can see here that there is an
attempted connection from ICU. It is from
IP address .06 which is our workgroup
node. And you can see here that the attempted
connection is for hostname PIInt02 and the
account is Interface Local Admin.
Since this is off the domain, the PI Data Archive does not
understand what this credential
is. So we cannot create a mapping and therefore there will be an unsuccessful login.
As you can see, we had an unsuccessful
login since there are currently no
credentials currently stored in Windows Credential Manager. Let's setup our first
credential in Windows Credential Manager,
linking the local interface local admin account
to the domain student 01 account. To
do that, let's go over to PIInt02. Since we are
currently logged in as Interface Local
Admin and we like to link that account to a domain
account, we can directly open Credential Manager.
Go to Windows Credentials, add a
Windows Credential. We would like to connect
to PISRV01. So we'll type in
PISRV01.PISchool.Int
and the user
that we would like to link to our local
admin account is the
student01 account on the PI School
domain. And the password is the domain
account for student01.
And you can see here that there is a stored credential for
student01 on the PI School domain connecting to
PISVR01 on the PI School domain
with the associated domain password.
Let's close ICU and try and reconnect.
And you can see that now that there is a successful
connection, we can go ahead and see our
OPC interface in ICU.
Let's take a look at PISVR01 and let's
refresh our message logs. And
we can see here that there is a successful
login from ICU. But
the user that it sees on this
side on the domain is the domain
credentials, Student01 account for the PI School
domain even though we are logged into the
workgroup machine as interface local admin. Let's take a look at
our mappings and security and we can see here that
Student01 is mapped to PI Admins and that we
have these two domain service accounts mapped
to two identities, PI Buffers and PI Interfaces. What we need to do
next is link our PI Buffer
local account to SVC-PIBuffer
on the domain. And also link
PI OPC local account to SVCPIInterface
on the domain. Let's head on over to PIInt02
and we'll open the message logs.
Let's go ahead and
start PI Buffer Subsystem just to take a
look at the failed connection
information. You can see here that there is an
error connecting to
PISVR01 or PI Buffer Subsystem. No
access secure object.
Let's try the same for the OPC interface.
You can see here that there is also an
error connecting for the OPC interface.
Let's go ahead and stop our services and setup the links
through Credential Manager.
Stop the interface and stop
Buffer Subsystem.
Now last time when we wanted to link our local admin
account to a domain account, we opened Credential
Manager directly from the
UI. However this time we want
to link PI Buffer. And to do that we are going to have to use
command line. So first thing we'll do is open the command
line and then we want to run the command line as that
user. To do that, let's type in
Run As, forward
slash user and let's do this first
for PI Buffer.
This is the local account PI Buffer on
the workgroup node. And then we want
to run command line. And
you can see here that it's asking for the password.
This is the local buffer account
password.
OK. And we get a new command line
and it says at the top running as PIINT02
User PIBuffer. Also we can type in who am
I and it'll go ahead and show
us who this command line is running as.
The next thing we'd like to do is add our credentials for this
user. And the command that we
use is CMDKey and if you type in CMDKey-?
we can take a look at some of the options that
we have for this command.
We'll of course be using the add feature
here to create a domain
credential or a linkage to a domain credential for this user.
But we can also list the
current credentials and if needed we can
delete the credentials. So let's go ahead
and start by listing the credentials to show that there aren't any.
For this
user, you can see that there are no stored credentials for
PI Buffer. Let's go ahead and add our
credential, we are going to use the same
three inputs that we needed when we did it
for Interface Local Admin. So we'll type in
CMDKey and the first thing is the target name.
That again is PISRV01.PISchool.Int
Then
we need the username of the domain account that we want
to link to the local account.
That will be PISchool
SVC-PIBuffer
The domain account. And finally,
we need the password to be stored
locally.
And that credential was added successfully.
And let's go ahead and list
it. And you can see
here that
for user PIInt02, PI Buffer running locally in
the workgroup, there is now a stored credential
for target PISRV01 on the PISchool domain
with its associated domain password and the
user is the PISchool domain, SVC-PIBufferUser.
Let's do the same now
for the PI OPC Interface
local user that we are running the OPC interface as. Again, we'll need
to run command line as that user. As an alternate approach,
if the command line is already running,
I'm going to right click and hold shift
and then right click on the command
prompt here and in some versions of Windows you'll get run as
different user. Here we want to run the
command line again for the local
workgroup PIInt02 but we want to run for
PI OPC Interface. And again this is the
local PI OPC
Interface user's password.
And in this case, it doesn't show at the
top who the local user is. But what I can
do is type in who am
I and I can see that I'm running the command
line as PI OPC Interface. I'm going
to check if I have any stored
credentials which I
do not. And then I'm going to add a credential
which links the local PI OPC Interface account to
SVC-PI Interface on the
domain. So I type in CMDKey
add and my target name is
PISRV01.PISchool.Int
My user is on the
PISchool domain and it's
SVC-PI Interface.
And I need to store the local password.
Or sorry, store the domain password locally.
This is the password for the
domain account.
If I do CMDKey
list, you can
see that for PIInt02,
PI OPC Interface, we now
have a credential stored with a
target of PISRV01 on the PISchoolInt
domain, storing the domain password locally.
And this is for the PISchool SVC-PI Interface
account.
Let's go ahead and take a look at the message logs and let's
start PI Buffer Subsystem.
And we can see here that we have a successful
connection to the PI Data Archive.
Let's also start our OPC Interface. We can see that the
start-up got a lot further than last
time.
And we can see here that we are connected
to the server.
Let's go ahead and head on over to System Management
Tools and let's take a look at the message logs and see how we are connecting for these two
services. First off, we have a new
connection for PI Buffer Subsystem.
Again, it's coming from IP address
.06 which is our workgroup
machine. But now it's coming through as a
domain account, SVR-PIBuffer
even though it's running as local account
on the workgroup machine. We can see
the same thing for our OPC interface, it's
coming through as PISchool
SVR PI Interface which gives it the PI Mapping even though
it is running as a local account on the interface
machine. If we took at Network Manager Statistics,
I'll hit
refresh, I'll sort by IP address. And we can
see that there are three connections
coming from IP address .6. There is
ICU, PI Buffer Subsystem
and our OPC Interface. And if we go ahead and take a look over
here, we can see that they are coming through as
student01 getting PI Admins,
SVR-PIBuffer, getting PI Buffers.
And SVC-PIInterface getting PI Interfaces.
Even though they are all running as
local accounts on the workgroup, they all now have
individual credentials in Windows Credential Manager.
A few additional notes. If you are
currently connecting to the PI Data Archive from a workgroup
machine using a Trust and you disable this
Trust and setup Windows Credential
Manager, please be sure to restart your services to re-authenticate
to the PI Data Archive and ensure
that they are coming through using the appropriate mappings and
identities. If you do not restart, they may
continue to use the existing trust even though
it has been removed until there is a reconnection to the PI Data
Archive. Also,
passwords stored in the Credential Manager are not
updated when domain passwords are
changed. For service accounts, this is usually not an issue
because service accounts often have passwords that do not
expire. However for user accounts such as
student01, the password may end up
changing on the domain. But it would not be
updated in Windows Credential Manager.
So the next time interface local admin logs into
the workgroup machine, they will not be able to load ICU and will
need to update the password in Windows Credential Manager.
Now that you know how to link domain credentials to
local accounts on workgroup machines, you can take
great advantage of the security benefits of using
Windows Integrated Security.