FG not trying to contact LDAP

[andmag]

Hi!

Running Fortigate 1200D cluster in Vdom mode.

I have configured an LDAP Server and it is no problem browsing the AD from the settings in GUI and Success with the testing function in GUI. Logs in AD see the user login in and do some credential lookup. All good!

But testing with AD-user in CLI totally fails and I see no attempts for FG to log in to AD at all.

Telnet from CLI on port tcp 389 is also successful. I have opened a ticket at Fortinet but it is sloooooow, probably the time difference to Sweden :)

Could we solve this before the official support? :D

-- Debug

## diagnose test authserver ldap ENVDC01 amagnusson XXXXXXXX

[1938] handle_req-Rcvd auth req 1356397311 for amagnusson in ENVDC01 opt=0000001b prot=0 [345] __compose_group_list_from_req-Group 'ENVDC01' [694] fnbamd_pop3_start-amagnusson [976] __fnbamd_cfg_get_ldap_list_by_server-Loading LDAP server 'ENVDC01' [984] resolve_ldap_FQDN-Resolved address 172.16.9.50, result 172.16.9.50 [1352] fnbamd_ldap_init-search filter is: sAMAccountName=amagnusson

[1355] fnbamd_ldap_init-search base is: dc=envirotainer,dc=com

[1495] fnbamd_ldap_start-Error in ldap_sasl_bind [441] ldap_start-Failed to start ldap request for 172.16.9.50 [456] create_auth_session-Error starting authentication [1957] handle_req-Error creating session [180] fnbamd_comm_send_result-Sending result 3 (error 0) for req 1356397311 authenticate 'amagnusson' against 'ENVDC01' failed!

-- Config

config user ldap edit "ENVDC01" set server "172.16.9.50" set cnid "sAMAccountName" set dn "dc=envirotainer,dc=com" set type regular set username "CN=SER081,OU=Service Accounts,OU=Accounts,OU=Envirotainer,DC=envirotainer,DC=com" set password XXXXXXXXXXXXXXXXXXXXXXXXXXX

[rwpatterson]

The working AD credentials I have are:

    edit "LDAP-AD_DC01"
        set server "192.168.1.158"
        set cnid "samaccountname"
        set dn "dc=ad,dc=company,dc=com"
        set type regular
        set username "cn=fortigate,cn=Managed Service Accounts,dc=ad,dc=company,dc=com"
        set password ENC /////+/sJ+m1GJREBTbkguglnn+ozh8LF6PNa5UIT97GAL1f1BZOVyroT5K2toP6mdJcaBc123wZegM1pR/xW4jmfVWOIUB23KYzSOCc73zajVj/X1SWHHtQsf873GGvmiPlRjNvgCoB3BQyQw5PnRFCiqp61S/p69vxmE1weRbBCIweJpuyJH39p85FA77vRfUCqw==
    next

As you see in mine, I didn't use any Organizational Units (OUs), I only used Containters (CNs) and it works like a charm. Try swapping those out and see where you get.

[andmag]

Thx for reply But there is no problem for the FortiGate to log into AD with the credentials provided, it is successful. The problem is the when SSL-Users try to login or I run diagnose test in CLI, it fails. Packet trace shows that it does not even try to contact AD :(

[rwpatterson]

OK. Been a while since I had to configure from scratch. You are right. In order to authenticate SSL VPN users against AD, I used an LDAP query into the AD architecture. The way Fortigate works with FSAE/FSSO Ad authentication, it needs to know the user is logged into AD with FSAE/FSSO before it will grant outbound access. It cannot do that if the user is on the dirty side of the firewall. For this SSL VPN mechanism to work, you need to do an AD query as the user tries to authenticate with the SSL VPN portal. This is the primary reason you will never see an FSAE/FSSO inquiry when an SSL VPN user attempts to authenticate.

[andmag]

Ok, but I am not using FSAE or FSSO, I just put the AD-Group that should have access to a User group.

"edit "ENVIROTAINER-Domain_users" set member "ENVDC01" config match edit 1 set server-name "ENVDC01" set group-name "CN=Domain Admins,CN=Users,DC=envirotainer,DC=com" next"

 It all seems to work, I see in debugging when I log in to SSL-VPN with Forticlient that it attempts to check in LDAP.

But Packet capture does not see any packets.

[emnoc]

Wait is the problem  user group or just that you see no traffic from LDAP_CLIENT to LDAP_SERVER?

When you run the  diag test authserver do you see packets from the ldap_client ( FGT )?

is the smaccount  allowed to search from the base DN  "dc=envirotainer,dc=com" ?

What happens if you do a ldap-search using a off-appliance tool openldap, curl,etc...?

Does the same account searches the complete tree?

e.g

ldapsearch -x -h 172.16.9.50 -D "theaccountname@envirotainer.com" -W -b "CN=Domain Admins,CN=Users,DC=envirotainer,DC=com"

   Does it pass ? Does it error ? Your error seems to tell me your account credentials are bad or wrong, can you  re-key them?

I would key the complete  user ldap

e.g

config user ldap

    edit "LDAP1"

        set server "10.2.2.1"

        set cnid "sAMAccountName"

        set dn "DC=example,DC=com"

        set type regular

        set username "CN=Ldapsvc,CN=Users,DC=example,DC=com"

        set password  myldapbindaccountpassword

    next

 NOTE:be careful of whitecaps and tabs in  the password.

[andmag]

Problem is that I do not see traffic from FG to DC at all. Browse and test ad with credentials from the server page is no problem.

[emnoc]

Your probably not do the diagnostic right

try openning two  sessions for commands executions

( 1st ssh screen )

diag sniffer packet any " port 389 or 636"

( 2nd  ssh screen and webgui )

Than run the Webgui check an the  cli diag test . Do you see traffic? If the webgui test works and the diag test auth ldap works than you known ldap is working ;)

Ken

[andmag]

Done that, when using test under LDAP settings in GUI I see trafic, log in to SSL or cli "diagn test authserver ldap ENV-DC amagnusson" show nothing.

Debuglog looks like LDAP fail to start:

[984] resolve_ldap_FQDN-Resolved address 172.16.9.50, result 172.16.9.50 [1352] fnbamd_ldap_init-search filter is: cn=amagnusson

[1355] fnbamd_ldap_init-search base is: dc=envirotainer,dc=com

[1495] fnbamd_ldap_start-Error in ldap_sasl_bind [441] ldap_start-Failed to start ldap request for 172.16.9.50 [456] create_auth_session-Error starting authentication [1957] handle_req-Error creating session [180] fnbamd_comm_send_result-Sending result 3 (error 0) for req 135639740

[xsilver_FTNT]

Hi andmag,

if you would run fnbamd debug with console timestamp enabled we might check the timing.

As we do not have the info my advise is a bit of shooting from the hip.

I would suggest to increase timeout value in system->global->ldapconntimeout  (ms) and retry.

Default is 500, which might not be enough for slow or loaded LDAP server.

Tomas