Hi there,
we run through the handbook for FortiOS 6.0 to enable explicit proxy with kerberos authentication
Handbook | FortiGate / FortiOS 6.0.0 | Fortinet Documentation Library
We have done anything correctly, we think. Proxy address matches the address we used for spn/keytab.
kerb auth is correctly requested and send back
Response is with negotiate YII.... so its kerberos, fine
But we get this when we add, for example the domain users group to a rule
And in user events we can see this
Which is kind of not expected, but we cant figure out why this happens.
To our ldap/kdc/domain controller Server we have opened the ports 636 TCP and 88 TCP/UDP, we use LDAPS for LDAP connection which seems to work (able to browse ldap directory and connection test is successful)
SPN on Kerberos User is set to HTTP/<hostname we use for proxy access> through ktpass
We are able to browse ldap directory
For the LDAP configuration we use another user than the kerberos user
Krb config
the realm is written in upper cases, so HTTP/<hostname we use for proxy access>@DOMAIN.LOCAL
Keytab was translated to base64 and the *.keytab files are created inside the forti, we can confirm through
fnsysctl ls -la /tmp/kt
Just one point, we see 2 keytab files created instead of 1.
We have defined auth rule and scheme
Still, it does not work and we have no idea why.
Additional question, is there a way to use multiple ldap/ad servers in "config user krb-keytab"? So we have no single point
We dont want to open port 450 and enable NTLM Authentication. Anyone an idea what we are doing wrong?
Solved! Go to Solution.
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
Hey Wurstsalat,
the 'group information failed' error can happen depending on how your LDAP server entry in FortiGate is set up.
In particular, FortiGate parses the username from Kerberos (which tends to be UPN format) and then tries to bind to LDAP with it to get group information. There are settings you can add to allow FortiGate to handle the Kerberos username correctly:
You might also need to change your LDAP server to use sAMAccountName as Common Name Identifier, not CN, to get the bind with stripped UPN to work.
If your LDAP server entry is used for other authentication as well (VPN for example) this could impact how users can authenticate.
Let me know if you still have questions or issues :)
Hey Wurstsalat,
the 'group information failed' error can happen depending on how your LDAP server entry in FortiGate is set up.
In particular, FortiGate parses the username from Kerberos (which tends to be UPN format) and then tries to bind to LDAP with it to get group information. There are settings you can add to allow FortiGate to handle the Kerberos username correctly:
You might also need to change your LDAP server to use sAMAccountName as Common Name Identifier, not CN, to get the bind with stripped UPN to work.
If your LDAP server entry is used for other authentication as well (VPN for example) this could impact how users can authenticate.
Let me know if you still have questions or issues :)
Created on 04-13-2022 09:05 AM Edited on 04-13-2022 09:40 AM
Ufff hope this will work out...but yea this is maybe a point.
Our UPN @ reflects not our Domain Name (domain name = domain.local but user up is @domain.de). Additionally, our upn differs from the samaccountname.
I will give it a shot and let you know.
so many thanks for this hint
just to mention it, your article is outdated :)
set account-key-name
is not available in FortiOS 6.0.14
instead "set account-key-filter", is available, so i tried:
set account-key-filter "(&(sAMAccountName=%s)(!(UserAccountControl:1.2.840.113556.1.4.803:=2)))"
And it worked out well, seems to run, yihaa. So for anyone else, this is how our config looks like
config user ldap
edit "dc03.domain.local"
set server "dc03.domain.local"
set cnid "cn"
set dn "dc=domain,dc=local"
set type regular
set username "CN=blabla,OU=Accounts,OU=FortiGate,DC=domain,DC=local"
set password ENC
set secure ldaps
set ca-cert "DOMAIN_ROOT_CA"
set port 636
set account-key-processing strip
set account-key-filter "(&(sAMAccountName=%s)(!UserAccountControl:1.2.840.113556.1.4.803:=2))"
next
Great help
Sadly what worked yesterday...stopped working today
Hey Wurstsalat,
sorry to hear that it stopped working!
Are you getting the group query failed error again, or something else?
Same error and log entries
Ldap connection tests are still successful, browsing directory still works
Hey Wurstsalat,
ok, in that case I would suggest some debug to figure out what's going on with the group query.
The commands:
#dia de reset
#dia de app fnbamd -1
#dia de en
-> fnbamd daemon handles communication to remote LDAP (including the group lookup post-Kerberos auth)
-> try to access explicit proxy until you get the error
-> to end the debug:
#dia de dis
#dia de reset
That debug should contain some details about binding to LDAP, querying the user, and then (if it finds the user) doing a memberOf search.
Created on 04-14-2022 08:45 AM Edited on 04-14-2022 10:22 AM
[882] __ldap_rxtx-Change state to 'DN search'
[815] __ldap_rxtx-state 11(DN search)
[592] fnbamd_ldap_build_dn_search_req-base:'dc=domain,dc=local' filter:(&(sAMAccountName=mysamaccountname)(!UserAccountControl:1.2.840.113556.1.4.803:=2))
[598] fnbamd_ldap_build_dn_search_req-Error in ldap_search
[736] __ldap_error-
[725] __ldap_stop-svr 's-dc03.domain.local'
[3112] fnbamd_ldap_result-Error (5) for req 887105992
[181] fnbamd_comm_send_result-Sending result 5 (error 0, nid 0) for req 887105992
[736] destroy_auth_session-delete session 887105992
While "(&(sAMAccountName=mysamaccountname)(!UserAccountControl:1.2.840.113556.1.4.803:=2))" used with powershell module for active directory and get-aduser -ldapfilter...i get my user back. So syntax is correct
Wireshark on the dc shows me the traffic on port 636 to domain controller...so dont get whats the problem
edit2
Found again a solution but i am unsure if this is a bug or not
This one doesnt work (but pretty sure this worked earlier but stopped for now)
set account-key-filter "(&(sAMAccountName=%s)(!UserAccountControl:1.2.840.113556.1.4.803:=2))"
But this is working in any active directory tool as ldap filter
Instead this one works (for now)
set account-key-filter "(&(sAMAccountName=%s)(!(UserAccountControl:1.2.840.113556.1.4.803:=2)))"
Mention the addition ( before ! and ) at the end
Thanks for sharing, Wurstsalat :)
I'm not entirely sure if this would count as a bug or not, the debug options on Fortigate don't show very much if the FortiGate has issues with the LDAP filter syntax (and it doesn't explain why the first filter was working for you for a bit).
If I find the time, I'll do some tests in the lab to see why syntax is accepted by the FortiGate and/or fails later.
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1641 | |
1069 | |
751 | |
443 | |
210 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.