When you first log in to Pathfinder Core PRO, use the username Admin and the password Admin.
However, this can be changed and controlled using the System > Users link on the navigation bar.
The page has two lists:
Users: everyone who can log in, with the Security Group each one belongs to and whether they have Emergency Access
Security Groups: the sets of permissions that users are given. The Type column shows whether a group is an Administrator group or a User group
A user's rights come from their security group. To give several people the same rights, put them in the same group; to change those rights, edit the group once.
Users
Click edit to change a user's password or click Add + to add users to the system. Use the trash icon to delete users from the system.
Field | Description |
|---|---|
User Name | The name used to log in. Names must be unique, ignoring upper and lower case: operator and Operator cannot both exist. |
Password | Type the password twice. It cannot be empty or contain spaces. |
Emergency Access | Lets this user log in through the emergency login page when LDAP authentication is unavailable. See Emergency Access in the Security section of the System article. |
Security Group | The group whose rights this user has. |
Can Lock Routes, Route locks do not apply | Shown for compatibility. The user's security group decides both; set them on the group. |
After creating a new user, that user's credentials may be used to log into the Pathfinder Core PRO's web pages or using PathfinderClient, PathfinderMini, or PanelDesigner.
The system will not let you delete or change the last user with administrator rights, as there would then be no way to administer the system. (The ClusterAdmin user used by clustering does not count.) Removing the Admin user's administrator rights asks for confirmation first.
Warning: It is very important never to remove administrator rights from all of the users you can log in as or you may lose access to the system requiring support to get access to the operating system to reset things.
Security Groups
Two groups always exist and cannot be deleted or renamed: Administrator and user. Click Add + under the Security Groups list to add a group, edit to change one, or clone to copy one under a new name (by default the old name followed by _Copy). A group cannot be deleted while users still belong to it.
Field | Description |
|---|---|
Group Name | The group's name. When LDAP authentication is used, this is also the name of the LDAP or Active Directory group it stands for. |
Is Administrator | Members are Administrative users who have access to everything. The Menus and Allowed APIs sections are hidden for administrator groups. |
Can Lock Routes | Defines whether members have the ability to lock and unlock routes. |
Route locks do not apply | Members can change routes even when they are locked. |
For groups that are not administrator groups, the arrows next to Menus and Allowed APIs may be expanded to specify the group's rights. By default a new group will see all navigation menu items but will have no rights in the API so most or all of the menu items will not populate with any data.
The Menus section allows you to define which navigation bar menu items are available to members of the group.
The menus listed are the same as in the navigation bar on the web page. By setting items to hidden they will no longer appear in the user's navigation bar.
The Allowed APIs section defines in much more detail what members may access via the web pages, port 9600 login, and the client applications:
Each item in the displayed list has several options:
Inherit means that branch in the tree inherits the rights of the parent branch. In the case of root level objects such as Logic Flows the inherited state is No Access. No Access explicitly denies access to that branch.
Display allows the user to display the resource but not change or use it. For example, if you wanted the user to be able to view the route states of a router but not make any route changes, then selecting display for the router access would be a good idea.
Change/Use allows the user to do normal operations with the resource but not change the definition of the resource. For example, in the case of routers, selecting change/use would allow the user to make route changes on the router but would not allow them to add sources or destinations to the router.
Full access allows the user to have complete control over the resource including the ability to add to or delete the resource. This is the equivalent of Administrative rights to the resource.
It is important to note that by default, branches below a specific branch inherit the parent's properties. So, if you set the Routers branch to display, all routers will be displayed. You can then set no access on routers you do not want the user to see and/or Change/Use access to routers you want them to be able to use.
Upgrading From 1.10
Versions before 2.0 stored rights on each user. When a system is upgraded, each user is given a security group of their own, named after the user, with the same rights they had before; users with administrator rights are given an administrator group named after them. Nothing changes for the people using the system. Afterwards you can move users with the same rights into one group and delete the groups you no longer need.
Important Note: Take a backup before upgrading. Rights changed through security groups after the upgrade are not seen by an older version if you return to it.
Security Groups and LDAP
When LDAP authentication is enabled (see the Security section of the System article), a user who logs in with their directory credentials gets the rights of the security group whose name matches one of their LDAP or Active Directory groups. The match ignores upper and lower case. If several groups match, the user gets the most permissive combination. A user who is not a member of any matching group is refused.
For example, to give the members of an Active Directory group called PcpAdmin administrator rights, add a security group named PcpAdmin with Is Administrator ticked. In 1.10 this needed a placeholder user named after the directory group; in 2.0 no user is needed.
IP Address White Lists
Attempts to access the system from the specified IP address will bypass the normal login process and use the user permissions assigned to the white list entry for permissions. While the choice to configure and use this option degrades security somewhat (IP addresses can be spoofed), it allows systems which may not usually have a keyboard attached to reconnect without requiring a login. To add a whitelist entry, click on the Ip Address White List link on the Users page.
Click Add + to add a new whitelist entry or the Return to Users link to exit the white list configuration page.
Each entry requires a range of IP addresses specified using CIDR format. For example the entry above represents a single IP address. For help figuring out the correct format, there are numerous CIDR calculators available on the internet (e.g. http://jodies.de/ipcalc). You also must specify a Security User from the users list. That will specify the permissions that will be used if anyone tries to access the system from that IP address. A Description (up to 128 characters) is optional, and is a good place to note what the address belongs to. It is important to note that once an IP address range is specified, it is not currently possible to login as a different user than the one specified from that IP address.
Warning: Be careful that you do not specify your entire internal network along with a non-Admin user or you could lose the ability to configure Pathfinder Core PRO. That can require working with support to correct. While you can use the CIDR structure to specify a range, this feature is really intended to allow unattended systems such as wall displays to be able to automatically display panels without user intervention. It is not intended to be used to short circuit all security credentials.