How to enable User Authentication on nonstandard protocols.

[mlassiter]

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).