Active Directory timeout?

What kind of host do you have for the VM - does it NAT all traffic from VMs behind its own IP, or are you bridging with the NIC, such that the VMs have a unique IP from the host?

Can you put your finger on how long it usually (or always) takes for the timeout to occur? Is it about 8 hours (480 minutes)?

The VM has its own IP on our internal network (just like a physical workstation would).. its on esxi using windows 7 guest. 

What keeps the session alive? Under User & Devices > Monitor > Firewall the user is no longer listed.. so its 'forgetting' about it or timing out, etc. I don't know what keeps the session alive. 

I'm only in the testing phases, having just got the fortigate last week.. so no, I haven't been able to pin point how long it takes the session to timeout. One of the fortigate support guys was on my system for an unrelated issue and saw that "Authentication > settings> timeout" was set to 5 minutes, he changed it to 480.. (I wish there was a 0!). Many users leave their computers on all night (never log off).. so they'll be denied all traffic when it times out.. thats not good. There's no prompt to re-auth either that I can see.

Thanks Chris

Okay. The reason I ask about the timeout intervals is because the Dead Entry Timeout on a Collector Agent is 480 minutes, by default.

Whether by polling or DC Agent mode, a Collector Agent receives/retrieves notification of a user logon event. After this point, it needs to verify the identity of the user at a workstation every five minutes (Workstation Verify Interval). It does this by calling a service on each host called Remote Registry. The service needs to be started in order to return any information. Ports TCP/139 and TCP/445 also need to be open on *each* workstation in order to call against the service. If either of these conditions aren't met, the workstation call will time out after 2 seconds, and the status of the user in the Collector Agent will go from 'OK' to 'Not Verified'. The user will still have access through identity-based policies, but only until the Dead Entry Timeout expires. At that point (after 480 minutes, by default), the user is removed from the CA and the FortiGate, and will be subject to any guest user policies present, or will be flat-out denied, if there are none at all.

It's a different story if you are using the FortiGate in polling mode (leaning on LDAP), but the Collector Agent offers a reasonable explanation for why it might be happening, if you notice it takes around 8 hours for a user to time out.

To add more detail, these timers are distinct from an authentication timeout to a policy. In the case of FSSO, changing the value from 5 to 480 minutes (or any other value) should be transparent to the user: the FortiGate just goes back to the relevant source for who is using a certain source IP, whether it be a RADIUS, LDAP server, or FSSO CA. In the case of RADIUS and/or LDAP, the user could be prompted again for credentials, whereas with FSSO, it would be a silent check.

Alright, so I'm watching the User & Device > Monitor > Firewall page with FSSO Logons checked. The users duration is getting up to 8 hours and then the user is disappearing from the list.

I don't even see an option on prompting for re-authentication or something like that. We're currently using Websense to monitor/restrict users web activities, but I'm hoping to drop websense and just use the new fortigate for that. I can't do it if it keeps timing them out like this though..

Any ideas on what I can change/test, Chris? I have User & Device > Authentication > Settings > Authentication timeout set to 600 (10 hours).. so.. I'm a bit confused. Thanks for your help

I now have the fortigate implemented but am still struggling with web filtering and authentication. Need guidance here. I'm using hte "poll active directory server" option with "enable polling" on. Its detecting users just fine (provided they log in).. the problem is if they leave their computer on over night, when they come back to the office the next morning. They are no longer authenticated, hence, can't get anywhere on the net. Is this because I'm using polling mode? Should I look into installing the DC Agent setups on the domain controllers? Does that behave differently re: timeouts? It seems like there must be a way around this, as forcing the users to log off and back on isn't always ideal/enforceable.

I only just deinstalled the agent on the DC 2 days ago as it was no longer needed now that I was using LDAP.  I had an earlier model Fortigate that used the agent as that was prior to the LDAP AD integration that came about with 5.2.

Crap, this is the second "bug" we have had with 5.2.

Hi guys, 

This topic is very interesting. I would like to raise a few points.

Lets not forget the appliance is a security appliance. Being a security appliance its there to enforce security/company security policies.

Depending on what type of industry the client is in, its not a good thing for the firewall to remember logons "forever" sort of speak, its a breach of security. Is the user logged on forever "logon-history        hours to keep as an active logon. 0 means keeping forever".

Some clients do not want to install the DC agents on their DC and do not want to open ports on their workstations.

I've found that letting the fortigate poll the DC and explaining to the client that its not wise to have "forever sessions" and force users to re-authenticate as a security measure is not such a bad thing.

The first step would be to establish a company security policy and then work from there.

Any opinions?