Technical Tip: Attribute-based access control (ABAC) using the 'Security & Access Value'

[Hatibi]

Description

This article describes how to leverage the 'Security Access Value' User attribute to apply control through NAC policies in addition to using the group membership and roles as criteria.

In this case a specific attribute of the user is selected in order to determine access to resources.

Scope

FortiNAC-F, FortiNAC.

Solution

The 'Security Access Value' can be a very helpful attribute to uniquely match Hosts and apply different controls based on it.

The value can be assigned to a User after it registers based on the following:

Guest/Contractor Templates:

Figure 1. Security Access Value specified in Guest/contractor Template

Standard User login in Portal Configuration.

Figure 2. Security Access Value specified in Portal configuration for standard user login

 

Security Access Value is inherited from user Attributes in the LDAP directory. To show an example of this, create a user 'jdoe' and modify the attribute 'company' to the value 'Fortinet' in the Attribute editor in AD:

Figure 3. Attribute editor in Active Directory User and Computers

 

Any of the listed attributes can be used as 'Security Access Value'. The benefit of this is that it is possible to leverage unique elements to apply control from FortiNAC and differentiate between users that may have the same Roles or group membership but unique Security Access Values.

In FortiNAC in System -> Settings -> Authentication -> LDAP -> Modify -> User Attributes, add the 'company' attribute as the Security Access Value to be updated for each registered LDAP user.

Figure 4. FortiNAC LDAP configuration of Security Access Value in User Attributes

Validation:

To test, perform registration as a Standard User login through the portal (LDAP authentication) and using the Security Attribute inherited from LDAP.

The value is assigned to the User record in FortiNAC, and the Host record will inherit it from the user. It is possible to verify in CLI as follows:

execute enter-shell

dumpuserrecords -userid jdoe

UserRecord:
Landscape = 91769544454 00:15:5D:E4:1F:06
ID = 5
Role = IT
Type = UserRecord
Admin Profile DBID = 0
Directory Policy = Fortinet
DN = CN=doe,CN=Users,DC=forti,DC=lab
Position = null
Email Address = null
First Name = john
Last Name = null
User ID = jdoe
Security Access Value = Fortinet

Attribute: Directory = 10.10.10.2
Attribute: MODEL_NAME = fortiDC
Attribute: AuthenticateType = LDAP
Attribute: msDS-PrincipalName = FORTI\jdoe

The host will additionally inherit the value from the user associated with it:

 

At this point, it is possible to leverage the Security Access Value in the Network Access policies as additional matching criteria for either the Host or Users.

Related documents:

User properties

Technical Tip: How to Populate a Role from a Group