You can help by commenting or suggesting your edit directly into the transcript. We'll review any changes before posting them. All comments are completely anonymous. For any comments that need a reply, consider emailing firstname.lastname@example.org.
We are experiencing playback issues from our video hosting provider. Please check back shortly.
1:32Changing admin Password
3:20Active Directory Authentication
2:33AD Database Hybrid
1:39AD Internal Hybrid
1:27Verifying an Authentication Profile
2:13Locking the Gateway
Take topic challenge
Ignition's default Authentication Profile stores its user information internally. This video shows how to add and edit users and roles to the profile using the Gateway interface and the User Management component. The Gateway Allow User Admin setting must be enabled to make changes using the User Management component in the Designer or Client.
Video recorded using: Ignition 7.9
Transcript(open in window)
[00:00] Internal user sources are a collections of users that are stored internally on the gateway. So alongside all of your gateway configurations and projects we store information on your users and how they can log in. I'm here in the gateway under Configure. Security and Users, Roles. And you see I have two user sources created. These were both generated automatically when I installed Ignition. You can see both of these user sources are of Type internal. The opcua-module user source is how Ignition connects to its own OPC UA server, so I'm going to leave this user source alone and we'll focus on default instead. So I'm going to click the manage user button on the right. You can see that we have the admin user that we used to first get into the gateway and that user has the Administrator role. Now if I needed to add a new role or new user, that's actually really easy to do. I'm going to start by adding a new role. I'll click the Roles tab here at the top. You can see the Administrator role exists. I'll click the Add Role link down below. And let's create a new role here. So how about we call this Operator. So I'll click the Add Role button down below and the new role exists inside of the user source. Next, how about we create a new user and assign this role to them? So I'll click on the Users tab at the top and see a list of my users. And I'll click the Add User link down below. So let's create a user for Operators. I'll call this oper, as the user. And just to match the notation on the admin user. In the very least we have to give them a password so I'll type one in. And I'll scroll down here. Now there are a bunch of additional properties we could pass in here too, such as First Name, Last Name, Schedule, preferred language, some notes on the user and so on. But the area I want to focus on is the Roles property down below here. I stated earlier that I wanted to give this user the Operator role, so I'll check that Operator role. However, it is entirely possible to have user without any roles at all. You commonly see this when you have a guest account or a guest user. Additionally, I could have users with many roles potentially. So I could assign the Administrator role to this user if I wanted to as well. However, I'm going to keep this user as just a Operator so I'll uncheck the Administrator role, I'll scroll down here and I'll click Add User down below. And you can see, we added my oper user and they have the Operator role. So it's fairly straight forward to create new roles and new users. Now there are a couple of important properties on the internal User Source so let's take a look at those next. So I'm going to head over to the left and under Security, I'm just going to click on Users and Roles again. It should take me back to the User Source page here. And this time for default I'm going to click on the Edit button. Now if we scroll down this list here, you'll see that there's a Main section and it has a list of properties that are available to all user sources, such as the Failover Source and Schedule Restriction and so on. So I'll just slide right past those. And I want to take a look at the Password Policy section. These properties are unique to internal user sources. As the name suggests, they provide an opportunity for you to implement some sort of password policy. So for example, the Password Max Age property here will expire each user's password after a certain number of days. So if you wanted your users to have to change their passwords every so often, you'd want to look at this property. You can also specify the minimum number of characters that a password can contain. Password Complexity allows you to specify a number of character types that are required. So what I mean by that is, there are four character types here. There are lowercase letters, uppercase letters, digits and punctuation. So for example, if I were to change this to 2, then when my users create new passwords for themselves, they have to use any two of these. So they can use lowercase letters and digits or uppercase letters and punctuation, for example. If I wanted to make it very, very secure, I could bump this up to 4 and they have to use all four character types. And last would be the Password History. This property determines if your users should be able to reuse the same password and after how many changes should they be able to reuse those passwords. So if you're going to apply a maximum age to your users' passwords and have their passwords expire, it is typically a good idea to make sure that they can't just reuse the same password again and again. So you would definitely want to change the Password History to something other than zero.