Without User ID, the current user and host identification is done on a best effort basis using what information is available in clear text such as the username in Kerberos or a digest header, DNS responses and mac addresses. An example of this is at the bottom of this email.

There are two approaches to pulling user login information from active directory – Polling and Agent based. Polling mode is like you’ve suggested below where the FortiGate connects to AD and parses logs every few minutes. Agent based (known as FSSO) relies on a FortiGate service that runs on one or more servers and performs this event log monitoring and supplies the FortiGates with a live feed.

I typically recommend agent based because it’s lower overhead on both the FortiGates and domain controllers and is less prone to missing login events.

For terminal servers, there is a specific agent we need to install. What this does is essentially sit in the network stack and allocate a range of source ports to each user, and then tell the FortiGate who has been allocated which port.  However, this does come work a warning that this source port restriction can break some applications (legacy ODBC based SQL applications in particular) –  so this will need some testing.

You also need to use the FortiGate FSSO agent approach with terminal server agents to avoid giving the FortiGate’s conflicting information.

 vd root/0  00:50:56:84:12:50  gen 1194584  req OA/24

    created 19084696s  gen 10  seen 0s  NIKV310  gen 541225

    ip 10.36.30.200  src mac

    hardware vendor ‘VMware’  src mac  id 0  weight 120

    os ‘Windows’  src http  id 1453  weight 130

    software version ’10’  src http  id 1453  weight 130

    host ‘XXXXXXX.yarracm.com’  src dhcp

    user ‘XXXXXXX’  src Kerberos