Active Directory timeout?

joebrug · ‎01-13-2015

Hi all, new to fortigate products.. trying to get web filtering up and running so I can get rid of Websense and simply use the fortigates features. I'm hitting a little problem though.. so I'm using FSSO in polling mode to AD. Its recognizing the users fine, but it seems to be timing out at some point. For example, I have a windows 7 VM that I have using the fortigate as its gateway for testing. I log this machine in as a test user, test the policies, it blocks me to the appropriate sites, etc.. however after a while, it seems to just "forget" about me and won't let me access any sites at all unless I log off/back on. Annoying. Am I timing out? Any way to prevent this from happening or how do you handle? Using a Fortigate 200D

avondale · ‎03-17-2015

I logged a call with Fortigate and had an engineer remote in and see that after 8 hours the FSSO logons disappear, they just drop off. So he saw it for himself and then escalated it to another engineer who came back with a solution.

To change the authentication time for FSSO, please change the logon-history to longer time. Below are the commands to change. config user fsso-polling edit <ID> set logon-history <int> (0-48, default is 8) next end

I asked for some more detail of what I was changing and they replied config user fsso-polling edit 1 set logon-history <int> (0-48, default is 8), for the logon-history, it is refer timeout period that you need. default, it is 8 hours. next end So I did this and it all works.

Give it a go.

View solution in original post

Christopher_McMullan · ‎01-13-2015

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

Regards, Chris McMullan Fortinet Ottawa

joebrug · ‎01-13-2015

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

Christopher_McMullan · ‎01-13-2015

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.

Regards, Chris McMullan Fortinet Ottawa

Christopher_McMullan · ‎01-13-2015

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.

Regards, Chris McMullan Fortinet Ottawa

joebrug · ‎01-13-2015

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

joebrug · ‎02-25-2015

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.

avondale · ‎02-25-2015

We are having the same problem, we are using a Fortigate 140D and with the latest version of the firmware 5.2.2 and using LDAP for integrating with our Active Directory rather than the agent on the server. We are then using the AD groups that a user belongs to as to which internet access policy is assigned to them. We have also noticed that after 8 hours, the fortigate seems to forget what AD group they belong to and applies the default deny policy. Our staff logon at 8am, so by 4pm exactly 8 hours later they either have to reboot the PC or if they lock the screen and leave it a couple of minutes and then log back in they sometimes are able to access the internet again. I have just logged a call with Fortinet about this as we had some other issues with 5.2.2 and the device is only 1 month old, so still have the 12 months initial support.

joebrug · ‎02-25-2015

Thanks for responding. I also have a ticket open. Basically, what they're saying is that you have to install the agents on the DC's to get it to work over 8 hours. You also have to enable Remote Registry service on the workstations so the agent can "check" the workstation every few minutes to make sure its still logged on. I'm in the process of setting this up right now but having issues, obviously. and the documentation is severely outdated, so it makes it even tougher to figure out. Support initially told me "yeah, they have to log off" and I said that's BS.. so they came back with the below.

http://kb.fortinet.com/kb...54535493&stateId=0

avondale · ‎02-25-2015

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.