Hot!LDAP Web Filtering Authentication

Author
Slingnet
New Member
  • Total Posts : 4
  • Scores: 0
  • Reward points: 0
  • Joined: 2019/08/20 08:54:31
  • Status: offline
2019/08/20 09:12:14 (permalink)
0

LDAP Web Filtering Authentication

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 [link=mailto:username@domain.local,]username@domain.local,[/link] and domain\username. None of the above work. is there something I'm missing here? 
#1

6 Replies Related Threads

    Kenundrum
    Gold Member
    • Total Posts : 148
    • Scores: 15
    • Reward points: 0
    • Joined: 2008/05/15 10:25:50
    • Location: Rhode Island, US
    • Status: offline
    Re: LDAP Web Filtering Authentication 2019/08/20 09:59:45 (permalink)
    0
    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.

    NSE4
    Some FGT500Es, 500Ds, 60Ds at work
    FWF60E, FWF80CM at home
    #2
    Slingnet
    New Member
    • Total Posts : 4
    • Scores: 0
    • Reward points: 0
    • Joined: 2019/08/20 08:54:31
    • Status: offline
    Re: LDAP Web Filtering Authentication 2019/08/20 10:50:53 (permalink)
    0
    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? 
     
    https://imgur.com/a/7nF7szC
    #3
    Kenundrum
    Gold Member
    • Total Posts : 148
    • Scores: 15
    • Reward points: 0
    • Joined: 2008/05/15 10:25:50
    • Location: Rhode Island, US
    • Status: offline
    Re: LDAP Web Filtering Authentication 2019/08/20 17:49:49 (permalink)
    0
    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

    NSE4
    Some FGT500Es, 500Ds, 60Ds at work
    FWF60E, FWF80CM at home
    #4
    Slingnet
    New Member
    • Total Posts : 4
    • Scores: 0
    • Reward points: 0
    • Joined: 2019/08/20 08:54:31
    • Status: offline
    Re: LDAP Web Filtering Authentication 2019/08/23 07:59:44 (permalink)
    0
    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
    #5
    Kenundrum
    Gold Member
    • Total Posts : 148
    • Scores: 15
    • Reward points: 0
    • Joined: 2008/05/15 10:25:50
    • Location: Rhode Island, US
    • Status: offline
    Re: LDAP Web Filtering Authentication 2019/08/23 08:31:50 (permalink)
    0
    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.

    NSE4
    Some FGT500Es, 500Ds, 60Ds at work
    FWF60E, FWF80CM at home
    #6
    Slingnet
    New Member
    • Total Posts : 4
    • Scores: 0
    • Reward points: 0
    • Joined: 2019/08/20 08:54:31
    • Status: offline
    Re: LDAP Web Filtering Authentication 2019/08/23 14:18:59 (permalink)
    0
    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 
    #7
    Jump to:
    © 2019 APG vNext Commercial Version 5.5