Skip to main content
Wurstsalat
Wurstsalat
Explorer
April 13, 2022
Solved

FortiOS 6.0 Explicit Proxy Kerberos problem

  • April 13, 2022
  • 1 reply
  • 8913 views

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

 

Wurstsalat_1-1649843205544.png

Response is with negotiate YII.... so its kerberos, fine

Wurstsalat_2-1649843340816.png

 

But we get this when we add, for example the domain users group to a rule

Wurstsalat_3-1649843431364.png

And in user events we can see this

Wurstsalat_7-1649847051235.png

 

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

Wurstsalat_4-1649843650071.png

 

Krb config

Wurstsalat_5-1649843739630.png

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.

Wurstsalat_6-1649843881948.png

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?

 

Best answer by Debbie_FTNT

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-Kerberos/ta-p/198782

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

1 reply

Debbie_FTNT
Staff & Editor
Debbie_FTNTAnswer
Staff & Editor
April 13, 2022

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-Kerberos/ta-p/198782

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
    WurstsalatAuthor
    Explorer
    April 13, 2022

    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

    Terms & ConditionsAccessibility statement