Example of LDAP to allow Dial-in through member-attribute – CLI

In this example, users defined in MicroSoft Windows Active Directory (AD) are allowed to setup a VPN connection simply based on an attribute that is set to TRUE, instead of based on being part of a specific group.

In AD, the “Allow Dial-In” property is activated in the user properties, and this sets the msNPAllowDialin attribute to “TRUE”.

This same procedure can be used for other member attributes, as your system requires.

Configuring LDAP member-attribute settings

To accomplish this with a FortiGate unit, the member attribute must be set. Setting member attributes can only be accomplished through the CLI using the member-attr keyword – the option is not available through the webbased manager.

Before configuring the FortiGate unit, the AD server must be configured and have the msNPAllowDialin attribute set to “TRUE” for the users in question. If not, those users will not be able to properly authenticate.

The dn used here is as an example only. On your network use your own domain name.

To configure user LDAP member-attribute settings – CLI:

config user ldap edit “ldap_server” set server “192.168.201.3” set cnid “sAMAccountName” set dn “DC=fortinet,DC=com,DC=au” set type regular

set username “fortigate@example.com” set password ****** set member-attr “msNPAllowDialin”

next end

Configuring LDAP group settings

A user group that will use LDAP must be configured. This example adds the member ldap to the group which is the LDAP server name that was configured earlier.

To configure LDAP group settings – CLI:

config user group edit “ldap_grp” set member “ldap” config match edit 1 set server-name “ldap” set group-name “TRUE”

next

end

end

Once these settings are in place, users can authenticate.

Troubleshooting LDAP

The examples in this section use the values from the previous example.

LDAP user test

A quick way to see if the LDAP configuration is correct is to run a diagnose CLI command with LDAP user information. The following command tests with a user called netAdmin and a password of fortinet. If the configuration is correct the test will be successful.

FGT# diag test authserver ldap ldap_server netAdmin fortinet

‘ldap_server’ is not a valid ldap server name — an LDAP server by that name has not been configured on the FortiGate unit, check your spelling.

authenticate ‘netAdmin’ against ‘ldap_server’ failed! — the user netAdmin does not

exist on ldap_server, check your spelling of both the user and sever and ensure the user has been configured on the FortiGate unit.

LDAP authentication debugging

For a more in-depth test, you can use a diag debug command. The sample output from a shows more information about the authentication process that may prove useful if there are any problems.

Ensure the “Allow Dial-in” attribute is still set to “TRUE” and run the following CLI command. fnbamd is the Fortinet non-blocking authentication daemon.

FGT# diag debug enable

FGT# diag debug reset

FGT# diag debug application fnbamd –1 FGT# diag debug enable

The output will look similar to:

get_member_of_groups-Get the memberOf groups. get_member_of_groups- attr=’msNPAllowDialin’, found 1 values

 

TACACS+ servers

get_member_of_groups-val[0]=’TRUE’ fnbamd_ldap_get_result-Auth accepted fnbamd_ldap_get_result-Going to DONE state res=0

fnbamd_auth_poll_ldap-Result for ldap svr 192.168.201.3 is SUCCESS fnbamd_auth_poll_ldap-Passed group matching

If the “Allow Dial-in” attribute is not set but it is expected, the last line of the above output will instead be:

fnbamd_auth_poll_ldap-Failed group matching