Documentation PI Nexus+ Documentation

PI Nexus+ / User Guide

Access

This chapter is for administrators: only they see the Access page, Access issues and access changes. It shows who can read or change what in the PI System, lets you try a change before you make it, and takes you through a periodic access review.

Overview

This chapter is for administrators: only they see the Access page, Access issues and access changes. It shows who can read or change what in the PI System, lets you try a change before you make it, and takes you through a periodic access review.

The Access workspace

Access (under Overview) is one workspace: a toolbar on top, a sidebar on the left with Explore, Issues and Act, and the map filling the rest. The toolbar holds the server, one search for accounts, groups and identities, the Admin, Write, Read and Deny line filters, Read now and Review CSV. The map always shows what is selected: nothing selected shows the server's map, an account or group what it reaches on every server, an identity who is mapped to it and what it grants, an object who reaches it. Every selection is part of the address, so a link or Back returns to it. Below 760 px the map is hidden and the sidebar is the page.

Everything is derived from configuration: identities, mappings, security strings and group membership. PI trusts are not evaluated, and display data is assumed to be read with the viewer's own rights. What could not be read is shown as such, never left out.

Explore: who can do what, and why

Search an account, group or identity and pick it, or click one on the map; the map centres on it. With nothing selected, the sidebar summarises the server: its identities, how far they reach, the open issues, the identities to review and the riskiest identities. Any other account stands for an account in no group the directory knows: it still gets what Everyone, Authenticated Users, Domain Users and an enabled PIWorld grant.

For an account or group the sidebar shows one card per PI Data Archive, AF Server and PI Vision instance, strongest access first: the level, the rights held and through which identities. Open a card for the counts per object type; a count lists its objects (an object opens its dialog on the Access tab), and How shows each path from the account through groups and mappings to the identity. CSV downloads it. Click a grant on the account's map to read why it can reach it, in a panel on the map's right edge (the sidebar keeps the account): the rights there, each identity that grants them with its paths, and the allow and deny entries behind them. Under the explanation it lists the objects themselves: a rights pill picks which right's objects (the strongest held first), each opens its dialog on the Access tab, and a list of more than 50 can be searched. The arrow keys step to the next grant and the panel follows; the close button, Escape or a click on the empty map closes it.

For an identity the sidebar shows its server rights, mappings, accounts, open issues and review; Open details opens the identity dialog. All identities swaps the map for the list of every identity on every server, with filters, the Review column and a CSV; a row opens the identity.

The PI Point, AF and PI Vision display dialogs have an Access tab: who the object's security names, through which identities, with which right; its Map switch draws the same as a graph, and Open in Access map shows the object in the workspace. The identity dialog's ⋮ menu has Open in Access map too.

Read the map

Lines run from accounts and groups on the left through identities in the middle to what they grant on the right, coloured by right (admin, write, read; deny and disabled dashed). Hover a node to read its details in the line under the map; click it to keep only its paths, and click it again, the background or press Escape to clear. Similar accounts and identities are bundled; the arrow on a bundle opens it. A column with more than 60 entries ends in +N more, which lists exactly the nodes the map left out; an identity or account in that list opens. The toolbar search brings matching nodes and their paths to the front, and the line filters hide a right's lines. Fit shows the whole map again.

Issues: what is wrong

The Issues tab lists the server's Access issues by severity, or every server's with All servers; suppressed ones are behind Show suppressed. Click an issue to focus the map on its identity with the issue's path lit and its evidence below it. Suppress and Restore work as on the Issues page. For a broad write, a mapping to a disabled account or an unused identity, Stage in Act puts the obvious change into Act. Where PI Nexus+ can make the change itself, the issue card also has Fix... (see Fixing issues).

Access issues are also on the identity's Issues tab and on the Issues page, category Access. An issue stays open while the configuration shows it and resolves when it no longer does. A broad group that gains a right opens a new Error: that is the drift alert. Access issues do not change health percentages or the dashboard's issue figures. The Access tab of a PI point, AF object or display shows the issues of its own security; Open issue opens the identity they belong to.

A suppression covers exactly one case, such as one broad mapping or one PI Vision server: the same identity's other cases, and new ones, still open and are mailed. Suppressed issues leave the counts.

Some issues point at clean-up rather than danger. All are Info and never mailed, except the first:

  • Local administrators are server administrators (Warning): BUILTIN\Administrators of the PI or AF server is mapped to an admin identity, the installation default. Map a dedicated admin group, then remove the mapping.
  • Admin held by an individual account: a user or managed service account is mapped to an admin identity on its own. Map a group instead.
  • Accounts mapped individually: three or more accounts are mapped one by one to an identity without admin rights. Put them in a group.
  • Redundant mapping: an account is mapped directly and through a group mapped to the same identity. Remove the direct mapping.
  • Mapping to an empty group: the directory reports the mapped group without members, so the mapping grants nothing.
  • Unused identity: nobody holds the identity (no enabled mapping), or it is named in no security, so it grants nothing. Identities the server creates itself, such as piadmin, PIWorld, Administrators, World and Owner, are never reported.
  • Review overdue: an identity that can change data or configuration (Write or Admin at server level, or write on PI points, PI Vision displays or AF objects) was last reviewed more than a year ago. Review it again; the issue then resolves. Identities that were never reviewed are not reported.

Security changes appear in Change History under the category Access (identities, mappings, server security, group accounts) and as Security changed on PI points, AF objects and displays. An administrator can put an access change back with Revert... (see Fixing issues).

Act: change it safely and prove it

Act answers "what if" before you change security. Its Plan lists the staged changes; the tab shows how many. Stage a change in any of these ways:

  • Add change, the last row of the plan: starts with the identity, account or object you have open in Explore already picked. Remove, add, disable or enable a mapping; disable or enable an identity; add or remove a group member; grant, revoke or (AF) deny rights in server security or in a security many objects share (the form shows how many).
  • Right-click a node or a line on the map (or use its ... button) and pick the change. A mapping line: remove, disable or enable the mapping. An identity: disable or enable it, or Add a mapping.... An account or group: Map to an identity..., Add to a group..., and for a group Add a member.... A membership line: remove the member. An object type: Change security..., the form narrowed to that type's shared security (All settings widens it; a type with one setting starts with it picked); a server security row: Change server security.... An action ending in ... opens Add change with what you clicked already picked. There is no delete: for who can reach what, deleting an identity is the same as disabling it, and disabling can be undone.
  • Stage in Act on an issue, Simulate a change… in Explore, and Simulate removing on an account's path, on a mapping in the identity dialog or Simulate disabling in its menu.

While Act shows a plan, the map draws it: lost lines red and dashed, new lines green. The impact follows each edit: how many accounts lose and gain a right, how many issues resolve and appear, a short summary, the affected accounts (pick a set to see its own access before and after on the map), the identities that change and the issues. A plan covers one server, except that a membership change shows on every server that maps the group. Counts follow the stored group memberships, like the account counts on the Access page, and displays whose data an account cannot read are not compared. Nothing is changed in PI, AF or Active Directory.

Save keeps the plan as a scenario under a name; the scenario picker reopens it and its menu renames or deletes it. Export downloads the change instructions as one zip: a PowerShell script for an administrator to review and run (PI Nexus+ never runs it), the same steps for PI System Explorer, PI SMT and Active Directory Users and Computers, a one-page summary for the change request and the affected accounts as CSV. The script checks every step before it changes anything, stops when the state differs from what PI Nexus+ read, and ends by reading every step again and printing PASS or FAIL; PI database security and the security of AF elements, element templates and analyses are manual steps.

Instead of running the script yourself, Apply plan... lets PI Nexus+ make the changes, one step after the other, and undo them if needed (see Fixing issues). After the changes are made, use Read now: each change of a saved scenario then shows Applied (with its Change History entry), Pending or Conflicting, and the scenario shows Verified once every change is applied. PI point and AF object security show after the next scan of those objects.

Review access

  1. In Act, choose Review. It always opens on Start review, with how many identities of the server need a review: enabled identities never reviewed or changed since their review, and disabled ones with open issues. An identity reviewed since its last change is done, whatever issues it still has, until its review is more than a year old.
  2. Choose Start review. Each identity in turn is on the map, with its facts, open issues and what changed since its last review in the sidebar; the count above them is what is left.
  3. Check who is mapped and what it grants, add an optional note and choose Mark reviewed; the next identity follows. Skip moves on without a review, and the arrows go back and forth.
  4. At the end, choose Review CSV for the evidence file: one row per identity and account, with rights, how the account gets them, and the review status, reviewer, date and note.

A single identity can also be signed off in its dialog: the Review line in Overview, Mark reviewed. All identities shows Reviewed and the date; once the identity's mappings, accounts or rights change it shows Changed since review, and the dialog and the review list what changed. Filters > Review lists Not reviewed or Changed since review identities. Identities with write or admin rights need a review again after a year: they then show the Review overdue issue until they are marked reviewed again.

Reference: Access Issues