Setting License Authorization Rules

This section describes how to set up license authorization rules for concurrent user, named user, credit and token licenses for users or machines.

The role of the Authorizations tab is to set authorization rules for licenses. There are four types of rules:

  • Allow: authorize users or groups of users, computers or groups of computers, IP ranges and IP range groups to use licenses
  • Deny: deny authorization to the above
  • Reserve: reserve a given quantity of licenses for a list of users, computers or IP ranges
  • Limit: limit a list of users, computers or IP ranges to a given quantity of licenses.

These rules are referred to as standard rules, to distinguish them from composite rules. A composite rule is a set of standard rules which allow you to manage combinations of rules types.

Whether you use standard or composite rules, only one rule type can be applied to a given licensed feature at a time.

Concurrent user licenses can be shared among users and are not tied to specific users. Certain licenses can be sold as shareable, which can be granted and released, for example, during a session using the Shareable Products tab. Shareable licenses comply with the Concurrent User Licensing model and are network licenses served by the DS License Server. By default, concurrent user licenses can be used without prior authorization by the DS License Server.

Token licenses are similar to concurrent user licenses. The main differences are that a token license cannot be shared by several client processes (even running on the same computer), and that several tokens can be granted to a given client process.

Credit licenses are consumable token licenses: their quantity decreases when they are granted (consumed).

Named user licenses are typically granted to users managed by the 3DSpace-side Platform Management or Manage My P&O and Content3DSpace tools, or by the Assign Licensing by Product command. However, in certain cases, you may need to enforce an additional stricter level of license control of named user licenses on the DS License Server. To do so, you can optionally set authorization rules for named user licenses.

Note: A license authorization rule for a specific named user license takes precedence over license assignments made on the 3DSpace server. This mechanism is particularly useful when you have several instances of a 3DSpace server and a single DS License Server. In this case, for example, the number of potential named users declared on the 3DSpace server instances (and to whom licenses are assigned) may exceed the number of licenses available. Centralizing named user license rules on the single DS License Server will enable you to enforce exactly the number of licenses granted to your company.

However, when managing authorization rules for a pre-V6R2012x license server, a License Administration Tool cannot manage named user licenses. When upgrading the DS License Server, existing authorization rules are automatically set to the concurrent user model.

This task shows you how to:

Manage standard authorization rules

  1. Select the Authorizations tab.

    The license servers available are listed to the left (highlighted in red). The list to the right contains the enrolled licenses classified first by editor, then by license model (Concurrent User, Named User, Token, Credit) followed by the license feature.

    Our example illustrates separate sections for both concurrent and named user licenses you can authorize or deny for the selected license server. For example, the concurrent licenses enrolled on the server for M3D for the editor Dassault Systemes are visible, along with a number of named user licenses for other roles:

    Expand a licensed feature node, for example MDG:

    where some or all of the following items may be visible:

    • LicenseId: license ID
    • PricingStruct: specifies the license duration and support conditions specified in the license contract: for example, ALC, QLC, YLC
    • CustomerCountry: your company may be present in several countries
    • CustomerSite: your company may have several sites
    • CustomerId: your customer ID.

    The number of licenses for each is displayed in parentheses.

    In our example, 66 licenses have been enrolled for the feature MDG:

    • the licenses all have the same license ID
    • 22 are ALC (Annual License Charge), 22 are YLC (Yearly License Charge) and 22 are QLC (Quarterly License Charge)
    • 33 of the 66 licenses are authorized for use in country France (FRA), or specifically on site DS HQ, or specifically by country ID DSFRA123, and 33 are authorized for use in country Italy (ITA), or specifically on site DS Italy, or specifically by country ID DSITA567

    For a given feature, you can set an Allow/Deny/Reserve/Limit authorization rule:

    • either directly on the feature (recommended if you do not have specific needs)
    • or on the PricingStruct, CustomerCountry, CustomerSite or CustomerId.

    This provides the capability to fine-tune license access even further. For example, you may want to make sure that sub-contractors only have access to QLC-type licenses.

    To limit and display only useful data, by default, a licensed feature will only be expanded if one of its LicenseId, PricingStruct, CustomerCountry, CustomerSite or CustomerId hosts an authorization rule or an offline control.

  2. Right-click in the space below Users/Hosts/IP Ranges and select the Add command to create a User, Host or IP Range.

    The New User/Host/IP Range dialog box appears:

    Note: When the licensing client you are using is connected to the 3DSpace server, the user name is the P&O login name. When the client is not connected, the user name is the operating system login name.
  3. Enter the name and check the appropriate option for what you are creating: user or host name, then click OK.

    User or Host

    Enter the user name or host name.

    User and host names are case-insensitive, whatever the input method (by the GUI, command line mode or XML file). For example, "Bob" and "BOB" are considered to be the same user. When entering user names and host names, all characters are converted to lowercase.

    If upgrading from a DS License Server level lower than or equal to R2013x, user names and host names are migrated to lowercase. Whenever migration leads to a collision (for example, "BOB" and "Bob" are both migrated to "bob"), only one set of rules is kept, randomly. Behavior was unpredictable anyway.

    Note that group names can still contain uppercase characters.

    A host name cannot contain the "." character. For FQDN host names, the comparison is performed with the very first part of the hostname. Note that:

    • you cannot enter a "." using the GUI
    • a name truncated at the first "." in command line mode, when using an XML file, or when migrating from a previous DS License Server level.

    In our example, the User/Host Definition field contains two users (administrator and demodesigner):

    IP Range

    Enter the IP range name. This is slightly different from the user/host names because for IP range the name and the value are different.

    Then click the IPRange button to display the following:

    Declare the IP ranges by clicking either the Classless Inter-Domain Routing button or the IPv4 or IPv6 range: button:

    • Classless Inter-Domain Routing (CIDR)

      Example: 127.0.0.1/32 is an individual IPv4 address in CIDR notation

      fd00::/10 is a range of IPv6 addresses in CIDR notation.

    • IPv4 or IPv6 range (classful network)

      Example: 10.232.0.0-10.232.255.255 is a range of IPv4 addresses in classical notation.

  4. Click on the symbol next to the M3D license. Do not select the individual license id if the imported license is a license group (which is nearly always the case). Then, right-click and select the Add new rule - Allow command to create a standard ALLOW rule.

    Click Yes when asked to confirm.

    The Rule properties dialog box appears:

    Note that you can select multiple lines for creating the same authorization rule for several licenses in one shot.

    Select the type:
    Select the type: User, Host, IPRange, User Group, Host Group, or IPRange Group.
    Choose the name:
    Click and choose the User, Host, IPRange, User Group, Host Group or IPRange Group name.
  5. To authorize the user we created to use the M3D license, select the type, choose the name, click the Add button then click OK.

    The Authorizations tab now looks like this:

    The M3D license is now highlighted in green, signifying that a rule has been created allowing the user to use the license.

    If a user other than the authorized user attempts to log in, the following message is displayed:

    No license available at this time for this product

    Click OK and a second message appears confirming that the license is not authorized, for example:

    Failed to request license for M3D version: 10 or higher)
Error: License not authorized for this user
License server configuration file path: C:\ProgramData\DassaultSystemes\Licenses\DSLicSrv.txt (default path)
List of license servers:
[01/01] lw5ses1dsy:4085 OK: License server is running
  6. To cancel the rule, click the M3D license and select the Remove rule command.

    When prompted, confirm that you want to remove the rule by clicking OK. The M3D license is no longer highlighted in green.

    You can multi-select several rules for deletion.

  7. To deny authorization, click the M3D license and select the Add new rule - Deny command. Select the type, choose the name, click the Add button then click OK.

    The Authorizations tab now looks like this:

    The M3D license is now highlighted in red, signifying that a "deny" rule has been created.

    Click the user name and select the Properties command to display the user properties:

    If the user then selects the Shareable Products tab in a client session and tries to reserve the license for M3D, a popup message appears:

    No license available at this time for this product

    Click OK and a second popup message appears confirming that the license is not authorized:

    Failed to request license for M3D (version: 10 or higher)
Error: License not authorized for this user
License server configuration file path: C:\ProgramData\DassaultSystemes\Licenses\DSLicSrv.txt (default path)
List of license servers:
[01/01] lw5ses1dsy:4085 OK: License server is running

    If you click the Server Logs tab and scroll the log, you will see a message like this:

    2016/08/07 18:04:40:402 W LICENSESERV M3D not granted, user administrator not authorized (from client LW5SES1DSY 
(42721022FAFE292A-0ae84648.0):administrator:administrator:C:\Program Files\Dassault Systemes\B419\win_b64\code\bin\3DEXPERIENCE.exe)
    Note:

    You can also set Allow and Deny authorization rules directly on the Editor name: Dassault Systemes, Dassault Systemes V5 or Dassault Systemes V4. This type of rule acts as a preliminary filter: the other rules set on the feature name or LicenseID are also taken into account, but only after the rule on the Editor has been processed. These rules are also applied to offline extraction. However, you cannot activate offline controls: keyword and maximum extraction duration cannot be set at the Editor name level.

    When an Allow rule is set, the Editor name icon appears with a green background:

    When an Deny rule is set, the Editor name icon appears with a red background:

  8. To create a group, right-click in the space below Group definition and select the Add command.

    The Create new group dialog box appears:

    Note: Note that operating system user groups are not supported.

    1. Enter a name for the group.
    2. Check the User, Host or IPRange option.
    3. Select the user or host name or IP range, then click the Add>> button and click OK.

      The group is created. Click the group name and select the Properties command to display the group's properties:

      Note: When you display the properties of a group, the Group name field can be modified.

  9. You can also copy user, host and group definitions and rules to another license server by clicking the appropriate item and selecting the Copy to server command.
  10. Click on a user, host, user group or host group and right-click to select the Remove command to delete the object.

    Contrary to V6R2014 and previous levels, you can delete a user, host, IPRange, user group, host group or IP range group even if it is referenced by a rule or belongs to a group. This behavior avoids modifying all rules tied to a user/host/group/IP range before deleting this user/host/group/IP range. When deleting the latter, the rules and groups which become empty (if any) are also deleted.

  11. To reserve a quantity of licenses, click the M3D feature and right-click to select the Add new rule - Reserve command to create a standard RESERVE rule.

    The Define a rule on the feature dialog box appears:

    Select the type:
    Select the type: User, Host, IPRange, User Group, Host Group, or IPRange Group.
    Choose the name:
    Click and choose the User, Host, IPRange, User Group, Host Group or IPRange Group name.
    Quantity of licenses:
    Specify the number of licenses to reserve.

    Select the type, choose the name, specify the quantity of licenses then click the Add button then OK.

    The Authorizations tab now looks like this:

    The M3D license is now highlighted in blue, signifying that a "reserve" rule has been created.

  12. Right-click a license feature in the tree on the right to access the Control offline command.

    Select the command to display the Extract offline license configuration dialog box:

    which allows you to set the maximum extraction duration, keyword protection and additional rules.

    Licenses can be extracted for a maximum duration of 30 days in all cases. You can decide to reduce the maximum duration for offline extraction of a given license feature, from 30 days (default) to 0 day, by 1-day increments. When set to 0, offline extraction is prevented for this license feature.

    End users then attempting to extract the offline license from the licensing client side for a license feature controlled by a rule will only be able to extract the offline license for the duration specified in the rule.

    When an offline restriction is set, the following icon is displayed:

    When both an authorization rule and an offline restriction are set, the previous icon is displayed with the colored background matching the rule type. For example, in the case of an ALLOW rule:

    You can also associate a keyword to each license feature using the Extraction keyword: field. When a license is protected by a keyword, the end user has to enter the keyword on the licensing client side.

    Keywords are not passwords: they are not encrypted. They appear unscrambled in several places, for example in the XML file containing the authorization rules.

    You can also set standard allow and deny authorization rules for fine-tuning offline extraction restriction. In the dialog box, the choices are:

    • None: by default, there are no restrictions.
    • Allow: offline extractions are granted only to the selected User, Host, IPRange, User Group, Host Group or IPRange Group. Click the Define rule button to define the rule using the standard method.
    • Deny: offline extractions are denied only to the selected User, Host, IPRange, User Group, Host Group or IPRange Group. Click the Define rule button to define the rule using the standard method.

    The Allow/Deny authorization rule for restricting the offline extraction is the third level filter:

    • if a rule is set on the EditorID, then it must be observed
    • if so, if a rule is set on the feature, the LicenseID, PricingStruct, CustomerCountry, CustomerSite or CustomerId, then it must be observed
    • if so, the rule on the offline extraction is checked at this step
    • If this new check is successful, then the user has to enter the keyword if a keyword has been set by the license server administrator.

    When a license has expired or has been deleted, the above controls are kept (if they had been set) by the license server and appear as ghost controls, as for ghost authorization rules.

    As for rules, ghost offline restrictions can appear at the bottom of the tab:

  13. To ensure that either a list of users or a list of hosts cannot consume more than a limited quantity of licenses, proceed in the same way, this time by selecting the Add new rule - Limit command.

    Note:

    Mixing users, computers and IPRanges is not allowed for RESERVE and LIMIT rules. It is only allowed for ALLOW and DENY rules. In this case, if both users and hosts are declared, then both are checked when granting a license. For example:

    • ALLOW USER1 and HOST1: only USER1 on HOST1 will obtain the license
    • DENY USER2 and HOST2: USER2 cannot obtain the license whatever the computer. No user can obtain the license if logged onto HOST2.

    The Authorizations tab now looks like this:

    The M3D license is now highlighted in brown, signifying that a "limit" rule has been created.

    Here is an example to illustrate RESERVE and LIMIT rules:

    Let's assume there are 100 licenses of ABC enrolled in a license server, and that you create a group of users composed of 25 members:

    • If you reserve 12 ABC licenses for this group, then you guarantee that at least 12 members of the group can obtain an ABC license. The remaining 25-12=13 members can obtain or not a license depending on the consumption of the 100-12=88 non-controlled licenses. With this rule, a maximum of 88 users not belonging to the group can obtain a license, even if no group member consumes any license.
    • If you limit to 12 ABC, then only 12 members of the group can obtain a license. The remaining 25-12=13 members cannot obtain one of the 100-12=88 other licenses, even if some of them are not consumed. With this rule, 100 users not belonging to the group can obtain a license, if they are not consumed by any member group.

    How to prevent users or hosts not declared in a license authorization rule from acquiring licenses

    A situation may arise in which all the licenses you have acquired have not yet been assigned to existing users/hosts by existing authorization rules. As long as this situation continues, you may consider that there is a risk that users/hosts not referenced by a license authorization rule may acquire licenses.

    Consequently, you may wish to be able to partition both existing licenses and licenses purchased in the future in an authorization rule. Using this technique, each declared user/host group will only be granted a specific number of licenses which cannot be used by any other users/hosts.

    To illustrate this mechanism in a concurrent user license context, let's assume you have the following users: A,B,C,D,E,F,G,H,I,J,K,L. You want to partition the users into 3 groups: A,B,C in Group1 sharing only one license, D,E,F in Group2 sharing two licenses, G,H,I in Group3 also sharing two licenses. You want to deny access to users J,K,L. The license name is XXX, and you have purchased 10 licenses.

    The solution is as follows:

    1. create a RESERVE rule for Group1, quantity=1
    2. create a RESERVE rule for Group2, quantity=2
    3. create a RESERVE rule for Group3, quantity=2
    4. create dummy group DummyGroup and create a RESERVE rule linked to DummyGroup, quantity=5.



    As a result, the remaining 5 licenses are assigned to the dummy group containing no users, so users J,K,L will be denied access to any licenses since they are not referenced by any license authorization rule.

    The authorization rules you just set up will be sufficient until you purchase and enroll additional licenses. So yet again there will be a risk that they can be granted to anyone not referenced in the rule. The solution is to reset, once and for all, the quantity of licenses assigned to the dummy group to an exceedingly high number which by far exceeds the number of licenses that you will ever purchase (for example, 1000). Using this technique, even the new licenses will be denied to users/hosts not referenced by the rule, and you will not have to edit the rule each time you add additional licenses.

    The fourth RESERVE rule in this context would then be, for example: create a RESERVE rule for DummyGroup, quantity=1000.

    To illustrate this mechanism in a named user license context, let's assume that 70 licenses for ABC have been enrolled. You could create the following RESERVE rules:

    • reserve 30 ABC licenses for HostA: HostA users are granted access to 30 ABC licenses
    • reserve 30 ABC licenses for HostB: HostB users are granted access to 30 ABC licenses
    • reserve 1000 ABC licenses for a non-existing dummy host, for example named "NonExistingHostName": nobody (including HostA/B) can use the remaining 10 ABC licenses (70-30-30=10), because firstly the number of licenses reserved is greater than the number of currently enrolled ABC licenses, and secondly because in any case nobody can log onto host "NonExistingHostName" which of course does not exist.

    The rule must be modified to enable anybody else to use the 10 ABC licenses and any future licenses.

    Note: The number of reserved licenses can be greater than the number of enrolled licenses not only when a RESERVE rule has been configured this way, but also for example when some licenses expire after the RESERVE rule has been configured.

  14. To set a rule for a named user license, proceed in the same manner.

    When you assign a rule to a named user license, this rule takes precedence over all assignments for the same license made on the 3DSpace Service.

    Let's take the following example.

    User1 is granted access (on the 3DSpace Service) to the named user license for the feature LIV-MDEVPM (this feature is just an example and does not exist).

    You then set an ALLOW authorization rule (on the DS License Server) granting User2 (who must previously have been declared as a named user in the P&O database on the 3DSpace Service) access to the named user license for the feature LIV-MDEVPM.

    The result is as follows:

    • User2 can use the feature LIV-MDEVPM
    • User1 CAN NO LONGER use the feature LIV-MDEVPM: the reason is that an ALLOW-type authorization rule has now been set for this feature on the DS License Server side. This rule grants the feature license to ONLY User2. And even though User1 was previously granted access via an 3DSpace Service-side tool, the authorization rule takes precedence. If User1 attempts to log on, the following message will be displayed:
      No license assigned to this user

    Note:

    If a license is removed or expires, and a rule had been assigned to that license, the rule is not deleted. It becomes a ghost rule and is displayed in the lower right-hand corner:

    This allows the administrator to avoid having to create the rule again if a new license is added. To display the properties of the ghost rule, click on its name. To remove the ghost rule, click the red icon.

    Note:

    In the case of named user licenses, if you add a rule after some licenses have already been granted to named users, then you may have to manually recycle them.

    In example 1, let's assume that named user ABC license is granted to Steve:

    1. Add a rule DENY Steve on ABC.
    2. Steve can no longer use ABC, but the ABC license cannot be used by someone else.
    3. You have to recycle Steve's licenses.

    In example 2, let's assume that there are 10 named user XYZ licenses and that 2 of them are granted to Alan and Barbara:

    1. Add a rule RESERVE 9 XYZ to UserGroup1. (Alan and Barbara don't belong to UserGroup1).
    2. Alan and Barbara can still use XYZ and only 8 users of UserGroup1 can use XYZ.
    3. You have to recycle either Alan's or Barbara's licenses.

  15. Edit an authorization rule to monitor the number of licenses consumed by the user, user group, host, host group, IP range or IP range group linked to the rule.

    In this simple example, we created an ALLOW rule for the user plmadm on the LIV-MDEVPM feature. To edit the rule, click on the rule and right-click to select the Edit rule command. The Currently consumed column specifies that one LIV-MDEVPM license has been consumed by user plmadm:

    Note: The term "currently consumed" means that the license has been granted to the user and the licensed process has been effectively executed at least once, in particular for named user licenses: it does not mean that the licensed process is being executed at the same time as you edit the rule. The Currently consumed column is not displayed when setting a rule, only when editing a rule.

    In the following example, we created a user group named MyGroup (containing the users demoreviewer and administrator), and created a rule reserving five licenses for the group. The Currently consumed column specifies that one LIV-MDEVPM license has been consumed by a member of the group:

    The list may also contain several lines. For each line (corresponding to a user, a host machine, a group of users or a group of host machines), the number of licenses currently consumed is displayed.

    The number displayed is the number of licenses, even if the rule is declared for host machines. For example, this number can be very high for only one host machine declared in the rule, if the host machine is an application server hosting a 3DSpace server.

    When the number is red, it means that the rule is not enforced. This can happen when the rule has been applied after a named user license has been previously granted to a named user.

    For example, in the following LIMIT rule related to the IFW license, the following rules have been set: 100 IFW maximum for GroupA and 2 IFW maximum for GroupB. 2 IFW are consumed by GroupA and 4 IFW are consumed by GroupB:

    “4” appears in red, because it is a case of over-use: the rule limiting to 2 has been set after the 4 named user IFW licenses have been granted to 4 named users.

    For a DENY rule, usually the number is equal to 0. However, if it is not the case it is displayed in red.

    When a name is present in a standard rule as an individual item and also as a member of one or several groups, then only the individual declaration is taken into account by the rule.

    For example, if Oliver belongs to UserGroup1 and a RESERVE rule is defined as 1 license for Oliver and 4 licenses for UserGroup1, we consider that Oliver was not a member of UserGroup1: when a license is granted to Oliver, 4 licenses are still reserved for other members of UserGroup1.

    When a name is present in several groups (and not as an individual item), only the group having the lowest alphabetical name is taken into account by the rule.

    For example, if Oliver belongs to UserGroup1 and UserGroup2, and a RESERVE rule is defined as 10 licenses for UserGroup1 and 15 licenses for UserGroup2, we consider that Oliver was not a member of UserGroup2: when a license is granted to Oliver, only 9 licenses are now reserved for other members of UserGroup1, but 15 licenses are still reserved for other members of UserGroup2.

    When a user uses the same license from several computers, only the last grant is taken into account by the rule. This can happen when a named user uses IFW from several application servers: the last computer will be used in the rule.

    For example, if a LIMIT rule is defined as 10 licenses for Computer1 and 15 licenses for Computer2, and Oliver logs on to Computer1 then on to Computer2 while staying logged on to Computer1, the same IFW license is granted to Oliver but it is first counted among the 10 licenses for Computer1 then, when Oliver logs on to Computer2, counted among the 15 licenses for Computer2 (and no longer among the 10 licenses for Computer1).

    You can also monitor license usage by connecting to the license server in command-line mode then running the getLicenseUsage command. For each license currently consumed, if the license has been granted by an authorization rule, the individual name or group name will be displayed in the authorization item field.

    In our example in which we created the group MyGroup, the getLicenseUsage command returns the following information:

    Dassault Systemes (5E756A80-1C80-478D-B83A-1D5913677621)
.....
IFW maxReleaseNumber: 17 type: NamedUser count: 11 inuse: 2 customerId: DSFRA123
internal Id: PLMADM granted since: Jul 5, 2016 6:45:30 PM last used at: Jul 5, 2016
7:29:58 PM  by user: PLMADM on host: WIN-KNKSL07ILFV (FFFFFFFFFFFFFFFF-c0a81f80.0)
internal Id: demoreviewer granted since: Jul 5, 2016 7:24:02 PM last used at: Jul 10, 2016
10:32:50 AM  by user: demoreviewer on host: WIN-KNKSL07ILFV (FFFFFFFFFFFFFFFF-c0a81f80.0)
...
internal Id: demoreviewer granted since: Jul 5, 2016 7:24:15 PM last used at: Jul 10, 2016
10:02:50 AM  by user: demoreviewer on host: WIN-KNKSL07ILFV (FFFFFFFFFFFFFFFF-c0a81f80.1)
authorization item: MyGroup
...
...

  16. Display or edit the properties of a user/host/IPrange, a group or a rule by either double-clicking on it or right-clicking then selecting Properties or Edit.

Note: When a licensing client requests a license, the license server checks the authorization rules before granting the license. Later, the client can check that the previously granted license is still granted by the license server. At this moment, the license server checks only the ALLOW and DENY rules, but not the RESERVE and LIMIT rules. Consequently:
  • if the license server administrator added, changed or removed an ALLOW or DENY rule during the client session, then the client can receive a KO, but
  • if the license server administrator added, changed or removed a RESERVE or LIMIT rule during the client session, then the client cannot receive a KO for this reason.

Manage composite authorization rules

A composite rule is a set of ALLOW, DENY, RESERVE and LIMIT declarations, each on a single line, that can be managed like a standard rule.

  1. Select the Authorizations tab.
  2. Click either directly on the feature or on the PricingStruct, CustomerCountry, CustomerSite or CustomerId type, then right-click and select Add new rule - Composite.

    A rule properties dialog box like this is displayed:

    A composite rule enables you to combine and enforce a potentially large number of authorization rules of different types (within the restrictions specified below). The rule may look like this (note the different rule types):

    Note that the composite rule contains several declaration lines.

    A composite rule is symbolized in the Authorizations tab like this:

    The following rules determine to what extent you can mix and combine different declaration types:

    • a composite rule can contain any number of lines
    • when you declare RESERVE lines in a composite rule, the RESERVE lines can only apply to: either users and user groups, or host and host groups, or IPRanges and IPRange groups
    • when you declare ALLOW, DENY and LIMIT lines in a composite rule, the lines can apply to all of the following: users, user Groups, Hosts, Host Groups, IPRanges and IPRange Groups.

    It is possible to create declarations applied to a combination of user/host/IPRange types in certain contexts, and not others.

    Declarations applied to a combination of users, hosts and IPRanges ARE allowed in:Standard ALLOW rules
    Standard DENY rules
    ALLOW lines in composite rules
    DENY lines in composite rules
    LIMIT lines in composite rules
    Declarations applied to a combination of users, hosts and IPRanges ARE NOT allowed in:Standard LIMIT rules
    Standard RESERVE rules
    RESERVE lines in composite rules

    Furthermore, the license server behaves differently depending on whether standard rules or composite rules are deployed.

    DeclarationBehavior
    ALLOW

    In standard rules, all declarations must be validated: for example, a license will be granted to user BOB on HOST1 only if both an ALLOW declaration for user BOB AND an ALLOW declaration for HOST1 have been validated.

    In composite rules, at least one of the declarations must be validated: using the same example, if user BOB is authorized, OR HOST1 is authorized, the license will be granted.

    DENY All declarations must be validated.
    LIMITYou cannot combine user/host/IPRange types in standard rules, but combining types is authorized in composite rules.
    RESERVE

    In standard rules, if an individual item is also part of a group, only individual types are taken into account.

    In composite rules, if an individual item is also part of a group, as a priority, individual types are always taken into account first, then group types.

    Examples

    The following example illustrates how to use ALLOW declarations in a composite rule. Create:

    • an IPrange for a protected building (IPrange1)
    • an IPrange for a non-protected building (IPrange2)
    • a user group containing privileged users (Group1)
    • a user group containing non-privileged users (Group2).

    Let's assume you want to enforce the following licensing rules:

    IPrange1IPrange2
    Group1GrantedGranted
    Group2DeniedGranted

    To enforce the above rules, create a composite rule containing an ALLOW declaration for the privileged user group, and an ALLOW declaration for the non-protected IPrange. For illustration purposes, it looks like this: 

    Group1 ... ALLOW
IPrange2 ... ALLOW

    In this case:

    • privileged users in Group1 can consume licenses from both buildings (IPrange1 and IPrange2), because the composite rule Group1 ... ALLOW is sufficient to allow the user to consume a license from both buildings
    • but non-privileged users in Group2 can consume licenses only from the non-protected building.

    The following example illustrates how to use RESERVE declarations in a composite rule. Let's assume your company has offices in three countries: India, France and the USA, and you have purchased 10 licenses for feature MDG. You can create a single composite rule to enforce the following rules:

    • reserve the usage of two licenses to an IPRange named france for French computers
    • reserve the usage of five licenses to an IPRange named india for Indian computers
    • reserve the usage of the three remaining licenses to an IPRange group named France and India containing only Indian and French computers
    • restrict license usage in the USA (there are no licenses available since they are all reserved).

    The rule will look like this:

    and for illustration purposes:

    france IPRange 2 RESERVE
india IPRange 5 RESERVE
France and India IPRange group 3 RESERVE

    When this rule is enforced, the behavior is as follows (and in the order specified):

    • when Indian users log on, as a priority they will first consume licenses from IPrange india, because RESERVE declaration lines with individual items (IPrange india) are taken into account before group items (IPrange group France and India)
    • once the first five licenses have been consumed, Indian users will then consume the remaining three licenses from IPrange group France and India
    • when French users log on, they will consume the remaining two licenses from IPrange france.
    Note: The total number of counts indicated in the Currently consumed column for a composite license can be higher than the total number of licenses. This can be the case, for example, when an item is present in a LIMIT and a RESERVE declaration, and when a client session triggers a match on a user, a host and an IPrange.

Limitations

Avoid erroneous and incoherent declarations, since the license server processes them along with the rest and does not reject them. For example, if you reserve eight licenses for host1, then limit host1 to five licenses, three licenses cannot be consumed.