FortiGate
FortiGate Next Generation Firewall utilizes purpose-built security processors and threat intelligence security services from FortiGuard labs to deliver top-rated protection and high performance, including encrypted traffic.
mlassiter
Staff
Staff
Purpose
The purpose of this document is to describe how to configure the FortiGate to allow you to enforce user authentication on protocols other than the defaults of HTTP, HTTPS, FTP, and TELNET.

Expectations, Requirements
This document is written with the expectation that you already know how to create users and user groups on the FortiGate.  This will work for both remote and local users.  For more information on how to create users and user groups, please see the respective FortiOS Handbook (http://docs.fortinet.com/fortigate/admin-guides).

In addition, you will need multiple VDOMs for this configuration to work.

Configuration
Since the FortiGate is limited to issuing user authentication challenge requests only on HTTP, HTTPS, FTP and TELNET protocols, we must use one of these to initially authenticate the user.  Once the user is authenticated, they will then be able to access resources only accessible via Identity Based Policies.  In this example, we will use TELNET for the user authentication.

In order for this configuration to work successfully, we must set the following value:
config global
config system global
set auth-policy-exact-match disable
end
end
By default, user authentication only applies to the rule in which the authentication request was made.  By setting this value, we can authenticate users using a dummy TELNET policy and then have that validated user session apply to all policies using the same user group.

In order to get the FortiGate to send a user authentication challenge for TELNET sessions directed to it's own IP address, we need to trick it by using Inter-VDOM links and Virtual IPs.  We will use destination NATing to redirect the incoming TELNET sessions across a VDOM link which will force the FortiGate to issue a user authentication challenge.

First we need to create a new VDOM for the authentication requests.
config vdom
edit Auth
end

Next, create an Inter-VDOM Link between your main VDOM and the new Auth VDOM. In this case we will use the 'root' VDOM.
config global

config system vdom-link
edit "AuthLink"
next
end
config system interface

edit "AuthLink0"
set vdom "root"
set ip 192.168.6.1 255.255.255.0
set type vdom-link
next
edit "AuthLink1"
set vdom "Auth"
set ip 192.168.6.2 255.255.255.0
set type vdom-link
next
end
Be sure the IP adresses you configure on the Inter-VDOM link are not used elsewhere in your configuration.  Next, create a Virtual IP to translate the TELNET challenge request over the Inter-VDOM Link.
config vdom
edit root
config firewall vip
edit "AuthNat"
set extip 192.168.10.4
set extintf "port2"
set portforward enable
set mappedip 192.168.6.2
set extport 23
set mappedport 23
next
end
In this case, the test hosts are sitting behind 'port2' and the interface IP address for 'port2' is 192.168.10.4.  The IP address for the 'AuthLink1' is 192.168.6.2 thus we use that as the mapped IP.  Also the NAT is limited to port 23 for TELNET.
Now we can create our policy to allow the user authentication challenge.
config vdom
edit root
config firewall policy
edit 1
set srcintf "port2"
set dstintf "AuthLink0"
set srcaddr "all"
set dstaddr "AuthNat"
set action accept
set identity-based enable
set nat enable
config identity-based-policy
edit 1
set schedule "always"
set groups "UsrGrp"
set service "TELNET"
next
end
next
end
In the rule above, 'UsrGrp' is the user group used to validate authentication.  Now that the dummy TELNET rule is in place, we can add additional rules to enforce access based on user authentication.  In the following example, we are only allowing PING requests to hosts on 'port1' if the user is authenticated.  To do this:
config vdom
edit root
config firewall policy
edit 2
set srcintf "port2"
set dstintf "port1"
set srcaddr "all"
set dstaddr "all"
set action accept
set identity-based enable
set nat enable
config identity-based-policy
edit 1
set schedule "always"
set groups "UsrGrp"
set service "PING"
next
end
next
end
At this point, the main configuration is done.  You can customize your policy to suit any of your authentication needs.  Also, by default, authentication sessions only last 5 minutes.  You can tune this time with the following commands:
config vdom
edit root
config user setting
set auth-timeout 480
end
In this example, the timeout has been raised to 8 hours.


Verification
To verify the configuration is working correctly, TELNET to the 'AuthNat' IP address.  In this example, it's 192.168.10.4.  A successful authentication will look like this:
Firewall Authentication required before proceeding with service
login: test
password: ******
Welcome to Fortinet Firewall
Authentication is successful, please connect again

Connection to host lost.
Once you've been successfully authenticated, you can check the authenticated sessions on the FortiGate like this:
Fortigate-VM64 (root) # diagnose firewall auth list
policy id: 1, src: 192.168.10.155, action: accept, timeout: 293
user: test, group: UsrGrp
flag (80020): auth timeout_ext, flag2 (0):
group id: 3
----- 1 listed, 0 filtered ------
At this point, any Identity Based Policies that enforce the group 'UsrGrp' will be allowed from the source IP address of the authenticated host (192.168.10.155).

Contributors