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