"set admin-concurrent disable" not working properly
I used the "set admin-concurrent disable" command in a FG with 5.4.2 and it seems that it doesn't work as I was expecting. According to the FortiOS handbook, with this command:
"[style="background-color: #ffff00;"]you can disallow concurrent administrative access using the same administrator user name.[/style]
[style="background-color: #ffff00;"]This allows only one session with the same username even if it is from the same IP[/style]."
However, the behavior I experienced was totally different: I opened one web session as admin and another as userxyz. The I tried to open a new session as userxyz again. The system refused with an "Authentication failure" message. So far so good. BUT the system also kicked me out from the first two sessions I had already opened (admin and userxyz) and I could't reconnect for a while, because of "too many login failures".
This is not the behavior was expecting according to the official documentation above. Am I hitting on some bug or something, or is this how this feature is supposed to work?
We've had this discussion 2 years ago (https://forum.fortinet.com/tm.aspx?m=112767) and concluded from the behavior that "concurrent" relates to the user credentials, not the user's IP address. So, from the same IP address, you can login using different credentials if access is restricted but not vice versa.
It seems from what you post that the behavior is correct but the action is wrong: kicking all users from the registered IP address instead of kicking all users by name.
It would be good if other users would try to set this up using v5.2, v5.4 and report back. If necessary you should open a ticket then with reference to this thread. If it's only an issue with documentation I volunteer to contact the team on this.
I did some tests in the behavior of "set admin-concurrent disable" command and concluded the following:
a. The command works fine and as expected, if you attempt to login with the same userid from different IP addresses.
b. If you attempt login with the same userid from the same IP address, then the connection is refused, but you are also kicked out from the first session too.
So, the command works at the userID level indeed, while it also takes into account the IP address you are coming from. It seems to me that the command is too strict in attempts from the same IP address (I was expecting that the first session wouldn't be lost), while it works very well when attempting from different IP addresses. I guess this is how it is supposed to work. Me and my customer should be fine, I suppose.