FortiOS 6.0 Explicit Proxy Kerberos problem

[Wurstsalat]

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?

[Debbie_FTNT · Accepted solution]

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:

https://community.fortinet.com/t5/FortiGate/Technical-Tip-Strip-domain-strings-from-a-UPN-in-Kerbero...

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

[Wurstsalat]

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

[Wurstsalat]

Sadly what worked yesterday...stopped working today

[Debbie_FTNT]

Hey Wurstsalat,

sorry to hear that it stopped working!

Are you getting the group query failed error again, or something else?

[Wurstsalat]

Same error and log entries

Ldap connection tests are still successful, browsing directory still works

[Debbie_FTNT]

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.

[Wurstsalat]

[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

[Debbie_FTNT]

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.