UserPrototypes under an LDAP user service are needed to map the appropriate station permissions and other items to different LDAP users that access the station. This mapping begins with a specific LDAP attribute applied to all LDAP users, as configured in the “Attr Prototype” property of the LdapConfig or ActiveDirectoryConfig child of the LDAP user service.
Figure 4. Default attribute in Active Directory for prototype mapping (Attr Prototype) is “memberOf”
In the LdapConfig container for the LdapV3UserService or LdapUserService, this Attr Prototype property has no default value
(is blank). But as shown in Figure 4, in the ActiveDirectoryConfig (of the LdapV3ADUserService or ActiveDirectoryService) the default value for this property
is: memberOf
This property should always be set to specify a particular LDAP attribute, typically one used to define different groups or “types” of users in the LDAP system. Then, you create additional UserPrototype components under the service’s UserPrototypes container, being careful to name them to match possible values for that attribute (as assigned to LDAP users). For example, you may create three UserPrototypes, named Manager, Operator, and Engineer (in addition to the existing Default Prototype).
In each of the UserPrototypes (including Default Prototype), you assign different, appropriate permissions and other Niagara-specific items, e.g. Nav File, Facets, Default Web Profile, and Mobile Web Profile.
When an LDAP user accesses the station, their LDAP-sourced user information such as name, email address, and language is used in the User component (automatically created for them). The remaining User properties are sourced from a UserPrototype that “name matches” the string value of the LDAP attribute specified in the “Attr Prototype”. For example, an Active Directory user with a “memberOf” value of “Manager” would have the permissions, Nav file, etc. from the UserPrototype named Manager.
In the case where no “name matching” UserPrototype is found, the permissions, Nav file, etc. are sourced from the Default Prototype. Note if you leave the “Attr Prototype” property blank (default in LdapConfig), all LDAP users will use the Default Prototype property values—regardless if other UserPrototypes exist.
For related details, see Mapping of permissions and other preferences to LDAP users.
To add and configure UserPrototypes
With the station opened in Workbench:
-
In the Nav tree, expand the user service to see
User Prototypes; expand again for 
Default Prototype.
-
Open the property sheet of the Default Prototype (double-click it).
Set appropriate values for the following User properties:
-
Permissions (for the Default Prototype, this typically is a very minimal set of permissions)
-
Facets
-
Nav File
-
Default Web Profile
-
Mobile Web Profile
-
the property values in the User Prototype.
-
In the Nav tree, right-click the
Default Prototype, and select 
.
-
In the popup Name dialog, rename from “
defaultPrototype1” to a possible attribute value name, for example, “Manager”, “Engineer”, and so on, and click .Repeat this (duplication) until you have the required number of uniquely-named User Prototypes.
-
Double-click each duplicated User Prototype, and in the property sheet of each one, adjust (as necessary) the same properties as you did for the Default Prototype (Permissions, Nav File, and so on), saving each when done. See Step 3 and Step 4.
For example, you may assign more Permissions and a different Nav file and Default Web Profile to a User Prototype named “Manager” than you would one named “Operator”.
-
When done, the station (right-click its Config node, and select ->).
-
Essentially, User Prototypes under an LDAP user service operate differently than they do under the standard (baja) UserService, where typically only the Default Prototype matters. However, just as with the standard UserService, the Default Prototype is always used as the “template” for all User property values when creating any local user in the station.
Note “non-default User Prototypes” under the baja UserService are utilized in “network user” scenarios; however, network users are not supported if using an LDAP user service.
-
If an LDAP user has multiple values for the “Attr Prototype” attribute, the top-to-bottom ordering of associated User Prototypes in the station can determine that User’s property values (including permissions, among other things).
For example, in an Active Directory scenario, if a user has “memberOf” values including “Engineer”, “Operator” and “Manager”, when that user accesses the station, if under the UserPrototypes container the User Prototype named “Operator” is ordered at the top, properties like Permissions, Nav File and so are source from that User Prototype (and not from any other User Prototype, even if the name matches another attribute value). For more details on this, see Mapping of permissions and other preferences to LDAP users.
-
If after an LDAP user accesses the station and a User component is created for them (using whatever source User Prototype component property values), if you subsequently change a property in that User Prototype, this change should be dynamically updated in the corresponding User component. For example, if you increase permissions in that User Prototype, the permissions in any User that originally sourced from that User Prototype should also update to match.