| Description | This article describes how to leverage 'Host' and 'User' group types' in Network Access Policies, depending on how the endpoint is registered. |
| Scope | FortiNAC-F v7.6 and greater. |
| Solution |
As of FortiNAC version F7.6.0, FortiNAC will automatically create 2 groups for each LDAP directory group after a directory synchronization is executed. This document, Schedule synchronization, provides additional details.
If the LDAP directory contains a group named 'TEST' that is marked for synchronization, FortiNAC will create the following two groups of type 'host' and 'user'.
These groups can be used as matching criteria in Network Access Policies.
When FortiNAC registers endpoints through the Persistent Agent, it has the following registration options:
Scenario 1. Register as a User. When registration through Persistent Agent is enabled, it is possible to define the 'Register as User' option in the Policy created in Policy & Objects -> Passive Agent.    Figure 1. Creating a Passive Agent policy to Register Hosts to User.
In this example, the user 'srogers' is part of the LDAP group 'Remote_users'. Upon synchronization, FortiNAC will create the following groups:
The membership of these groups can be checked in FortiNAC System -> Groups.   User 'srogers' signs in for the first time to a Windows PC that is not registered. FortiNAC registers the Host to the user based on Agent configuration. In Host view, it reports the following Host record and attributes:
 Figure 2. Host view attributes when a host initially registers through "Register as User" option.
At this point, FortiNAC will have performed the following actions:
naclab1 # execute enter-shell naclab1:~$ Group -name "Remote_users_host" -elements ******************************************************************************** Group ID: 278586019715072 Group Name: Remote_users_host Label: Remote_users_host Description: null Type: DynamicClient Type: 8 Inactive: 0 Days Valid: 0 PCX srogers C8:A3:62:04:D7:20 (id=278588003407872)
Since there is a logged-on user, the 'Remote_users_user' group is also populated.
naclab1:~$ Group -name "Remote_users_user" -elements ******************************************************************************** Group ID: 278586019631104 Group Name: Remote_users_user Label: Remote_users_user Description: null Type: UserRecord Type: 51 Inactive: 0 Days Valid: 0 srogers (id=278589498845184)
Policy matching behavior: Both groups can be leveraged as matching criteria in Network Access policies. The users/Hosts will match the policy if members of one of these groups, depending on how the user's host profile is configured.
A new user logs in to an already registered Host PCX. In the example below, User 'jdoe' logs in to the machine.
 Figure 3. Example of a new user login on a previously registered host.
At this point, FortiNAC performs the following actions:
This can be verified through the CLI:
naclab1 # execute enter-shell naclab1:~$ Group -name "Remote_users_user" -elements ******************************************************************************** Group ID: 278586019631104 Group Name: Remote_users_user Label: Remote_users_user Description: null Type: UserRecord Type: 51 Inactive: 0 Days Valid: 0 doe, john (id=278589481302016) srogers (id=278589498845184)
Scenario 2. Register as a Device. When registration through Persistent Agent is enabled, it is possible to define the 'Register as Device' option in the Policy created in Policy & Objects -> Passive Agent. 
User 'srogers' signs in for the first time to a Windows PC (Hostname: PCX) that is not registered. FortiNAC registers the Host to the user based on Agent configuration. In Host view, it creates the following Host record and attributes:
 Figure 5. Host record in FortiNAC when host is registered with method "Register as Device"
As noted in Figure 5, FortiNAC will only populate the 'Logged On User' entry. There will be no Host group membership populated. This is used only for tracking the user on which devices they are currently working.
FortiNAC performs the following actions after registration:
naclab1 # execute enter-shell naclab1:~$ Group -name "Remote_users_user" -elements ******************************************************************************** Group ID: 278586019631104 Group Name: Remote_users_user Label: Remote_users_user Description: null Type: UserRecord Type: 51 Inactive: 0 Days Valid: 0 srogers (id=278751227172864)
User 'srogers' signs out. A new User 'tester' signs in to Host PCX. This user has the same group membership as the previous user.
 Figure 6. New user login on previously registered host with method "Register as Device"
As noted in Figure 6, the host record is now populated with the new user 'tester'. The 'Registered To' field will remain empty since there is no ownership definition when registering as a Device. There will be no membership of the host record in 'Remote_users_host'.
naclab1 # execute enter-shell naclab1:~$ Group -name "Remote_users_user" -elements
Policy Matching behavior: When groups are used as matching criteria in Network Access policies, a match will be applied based on the '_user' type group that each user is a member of. When the user logs out, FortiNAC will clear the 'Logged on' field. The group is ignored in policy evaluation since there is no User entry present. FortiNAC will proceed to evaluate the next policy.
For troubleshooting, it is important to validate the 'Policy Details' tab by 'Right-clicking' a Host entry in FortiNAC host view. The details will show if the policy criteria are failing due to the host or user not being found as group members.
The example below shows a policy match failure due to group membership criteria not being fulfilled:
Potential Access Policy Match #5 [BYOD_Group_host]: AccessPolicy - DBID:[278586607583232] - Rank:[5] - Enabled:[true] - Name:[BYOD_Group_host] - Note:[] - Profile - DBID:[278586607476736] - Name:[ByoD_host] - Version:[0] - Note:[] - Groups:OR:[[Value:[278586019715072]]]
HostRecordUtil.getAbstractPolicy() HostRecord DBID: 278587171344384 Policy ID 278586607583232 Groups not matched: Required:OR[278586019715072] Provided:[23]
Unexpected policy matching behaviors: On some occasions, there could be multiple logged-on users in the same Host. This will bring inconsistencies in policy matching since the FortiNAC Agent might randomly report any of the multiple logged-on users as the active one.
For example: User A signs in with domain credentials. User A locks the session. A new User B signs in.
At this moment, the Host has 2 User entries logged in at the same time. The original user A session would still be running in the background since there is a switch between users and not a log out of the first user.
These scenarios are not recommended and are currently not supported.
Related documents: Customized Registrations through Passive Agent. Technical Tip: How to Populate a Role from a Group Technical Tip: Assign Roles based on User LDAP Directory Attributes |
