LDAP Web Filtering Authentication

[Slingnet]

All,  I've setup a 100E with web filtering profiles and connected it to my DC successfully. However when I enable Web filtering and use the groups and users I've created users cannot login. I can login as a local firewall user but not an LDAP user. I've had users try their username, their full name, their username@domain.local, and domain\username. None of the above work. is there something I'm missing here? 

[Kenundrum]

In my opinion- it's easier to do FSSO for web filtering than using captive portal login when it's all your own devices/people. However, you may want to double check your LDAP config under Users - LDAP Servers.

The key fields are the Common Name and Distinguished Name. For most active directories, the best field to use for CN is sAMAccountName (case sensitive) that will map the username to the accountname in AD. So John Smith would typically be jsmith. If you want users to use a different parameter such as their email you need to map to the correct LDAP field. "mail" is typically the email address, "userPrincipalName" is typically the UPN aka user@domain.local.

The DN is where all the user accounts are located in your AD. This is typically "cn=Users,dc=<yourdomain>,dc=<extension>". I use a tool called Softerra LDAP Browser to view the AD hierarchy from a pure LDAP view and it has helped me a lot getting everything in the correct syntax.

Also- you may need to provide a "regular bind" user depending on your AD security settings. That provides a valid authenticated user to do the lookups for the other users. This username will need to be in the LDAP format and have a valid password entered.

[Slingnet]

Thanks for your response. Currently the Fortigate is in production in an entity that truly needs 24/7 uptime and the client is wanting this added on right now. Please see below the example of an LDAP bind I have setup for a user group called "full time employees" From what I understand SSO would automatically authenticate a user when they logged into their workstation without needing to pass a browser credential check. How would this work with mobile devices or logins not associated to a particular group. For example user A uses a shared machine with a shared account but needs specific policies enacted for that specific user. I'm assuming I would just make that shared account the most strict then the user would have to just "deal" with the restricted access, or is there a credential check available in the browser? 

[link]https://imgur.com/a/7nF7szC[/link]

[Kenundrum]

The way FSSO works is that there is an agent on a machine that talks to domain controllers on the firewall's behalf. If you have one or two DCs, the firewall itself can do all the heavy lifting without separate agents. The domain controllers log all user login activity and the IP address it came from. The FSSO agent looks for those logs and assigns a user to an IP address dynamically. The firewall connects to the agent and gets this list of ip/user mappings to apply to rules. If a device on a specific IP doesn't log in to anything then it doesn't get a user assigned to it. There is caching, so when a new user logs in, they might get the policy applied to the previous user for a few minutes. You could set a rule for authenticated users with one policy and then a catch-all rule afterwards with internet access policy for non-authenticated devices or force those users to a login portal.

As far as the bind for the ldap users, try posting the output of "show user ldap", that is more helpful. feel free to strip out anything private.  for example- here's one of mine...

config user ldap edit <ldap name> set server <server1> set secondary-server <server2> set tertiary-server <server3> set cnid "sAMAccountName" set dn "cn=users,dc=<domain>,dc=<local>" set type regular set username "CN=<user>,OU=<some OU>,DC=<domain>,DC=<local>" set password enc <password> set secure ldaps set port 636 next

[Slingnet]

Thanks for walking me through this. Below is the output of the command you requested:

show user ldap

config user ldap

    edit "Server 1"

        set server ""

        set cnid "cn"

        set dn "ou=mybusiness,dc=Domain,dc=local"

        set type regular

        set username "fortigateldap@domain.local"

        set password ENC

    next

end

[Kenundrum]

That output is very helpful. A few things...

First- i hope that the set server line actually has something in it because obviously it won't work with out that. Have you used the test function to make sure it successfully connects and binds? The username for the bind can be in a few different formats, so as long as it works you should be ok. I structured mine in the LDAP Distinguished Name format.

The CN you chose is cn. That explains why users are not able to log in with any normal username you expect. Active directory maps the cn field to their full name such as "John Smith". In order to log in, the users will have to type in their full name as a username- including the space. Without making any changes, you can try that in the captive portal login and it should work. 

I suggest changing the cn field mapping to be one of the fields I mentioned previously based on whatever username format you use most often.

Also- to make it more highly available, i suggest adding backup servers to the configuration. If a domain controller goes down, you don't want to be completely unable to authenticate people for internet access anymore. You can also set the server name to be simply <domain.local> (for your domain) since that should resolve to whichever domain controller answers first. The example setup I posted has that set as the tertiary server so that if the two closest DCs don't answer it will just poll anyone to get an answer.

Hope this helps.

[Slingnet]

Just wanted to check in with you and say that your responses were correct and solved my issue. Changing the CN allowed me to have this work properly. Unfortunately I'll have to re-import every user as the Fortigate does not recognize the change to the usernames. Hopefully the usernames are not case-sensitive because some are capital and others are not. Guess I will figure that part out soon.  Thanks, Again