Category Archives: FortiOS 6

Configuring certificate-based authentication

Configuring certificate-based authentication

You can configure certificate-based authentication for FortiGate administrators, SSL VPN users, and IPsec VPN users.

In Microsoft Windows 7, you can use the certificate manager to keep track of all the different certificates on your local computer. To access certificate manager, in Windows 7 press the Windows key, enter “certmgr.msc” at the search prompt, and select the displayed match. Remember that in addition to these system certificates, many applications require you to register certificates with them directly.

To see FortiClient certificates, open the FortiClient Console, and select VPN. The VPN menu has options for My Certificates (local or client) and CA Certificates (root or intermediary certificate authorities). Use Import on those screens to import certificate files from other sources.


Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

Troubleshooting certificates

Troubleshooting certificates

There are times when there are problems with certificates — a certificate is seen as expired when its not, or it can’t be found. Often the problem is with a third party web site, and not FortiOS. However, some problems can be traced back to FortiOS such as DNS or routing issues.

Enable and disable SHA1 algorithm in SSH key exchanges

In order to investigate your security and conduct compliance testing, a global option allows you to enable/disable SHA1 algorithm in SSH key exchange. Note that, the algorithm is enabled by default.

Syntax

config system global set ssh-key-sha1 {enable | disable}

end

Certificate incorrectly reported as expired

Certificates often are issued for a set period of time such as a day or a month, depending on their intended use. This ensures everyone is using up-to-date certificates. It is also more difficult for hackers to steal and use old certificates.

Reasons a certificate may be reported as expired include:

  • It really has expired based on the “best before” date in the certificate l The FortiGate unit clock is not properly set. If the FortiGate clock is fast, it will see a certificate as expired before the expiry date is really here.
  • The requesting server clock is not properly set. A valid example is if your certificate is 2 hours from expiring, a server more than two time zones away would see the certificate as expired. Otherwise, if the server’s clock is set wrongly it will also have the same effect.

Troubleshooting

  • The certificate was revoked by the issuer before the expiry date. This may happen if the issuer believes a certificate was either stolen or misused. Its possible it is due to reasons on the issuer’s side, such as a system change or such. In either case it is best to contact the certificate issuer to determine what is happening and why.

A secure connection cannot be completed (certificate cannot be found)

Everyone who uses a browser has encountered a message such as This connection is untrusted. Normally when you try to connect securely to a web site, that web site will present its valid certificate to prove their identity is valid. When the web site’s certificate cannot be verified as valid, the message appears stating This connection is untrusted or something similar. If you usually connect to this web site without problems, this error could mean that someone is trying to impersonate or hijack the web site, and best practices dictates you not continue.

Reasons a web site’s certificate cannot be validated include:

  • The web site uses an unrecognized self-signed certificate. These are not secure because anyone can sign them. If you accept self-signed certificates you do so at your own risk. Best practices dictate that you must confirm the ID of the web site using some other method before you accept the certificate.
  • The certificate is valid for a different domain. A certificate is valid for a specific location, domain, or sub-section of a domain such as one certificate for example.com that is not valid for marketing.example.com. If you encounter this problem, contact the webmaster for the web site to inform them of the problem.
  • There is a DNS or routing problem. If the web site’s certificate cannot be verified, it will not be accepted. Generally to be verified, your system checks with the third party certificate signing authority to verify the certificate is valid. If you cannot reach that third party due to some DNS or routing error, the certificate will not be verified.
  • Firewall is blocking required ports. Ensure that any firewalls between the requesting computer and the web site allow the secure traffic through the firewall. Otherwise a hole must be opened to allow it through. This includes ports such as 443 (HTTPS) and 22 (SSH).

Online updates to certificates and CRLs

If you obtained your local or CA certificate using SCEP, you can configure online renewal of the certificate before it expires. Similarly, you can receive online updates to CRLs.

Local certificates

In the config vpn certificate local command, you can specify automatic certificate renewal. The relevant fields are:

scep-url <URL_str> The URL of the SCEP server. This can be HTTP or HTTPS. The following options appear after you add the <URL_str>.
scep-password <password_str> The password for the SCEP server.
auto-regenerate-days <days_ int> How many days before expiry the FortiGate unit requests an updated local certificate. The default is 0, no auto-update.
auto-regenerate-days-warning <days_int> How many days before local certificate expiry the FortiGate generates a warning message. The default is 0, no warning.

In this example, an updated certificate is requested three days before it expires.

config vpn certificate local edit mycert

Troubleshooting

set scep-url http://scep.example.com/scep set scep-server-password my_pass_123 set auto-regenerate-days 3 set auto-regenerate-days-warning 2

end

CA certificates

In the config vpn certificate ca command, you can specify automatic certificate renewal. The relevant fields are:

Variable                                                 Description
scep-url <URL_str>              The URL of the SCEP server. This can be HTTP or HTTPS.
How many days before expiry the FortiGate unit requests an auto-update-days <days_int> updated CA certificate. The default is 0, no auto-update.
auto-update-days-warning        How many days before CA certificate expiry the FortiGate

<days_int>                     generates a warning message. The default is 0,no warning.

In this example, an updated certificate is requested three days before it expires.

config vpn certificate ca edit mycert set scep-url http://scep.example.com/scep set auto-update-days 3 set auto-update-days-warning 2

end

Certificate revocation lists

If you obtained your CRL using SCEP, you can configure online updates to the CRL using the config vpn certificate crl command. The relevant fields are:

Variable Description
http-url <http_url> URL of the server used for automatic CRL certificate updates. This can be HTTP or HTTPS.
scep-cert <scep_certificate> Local certificate used for SCEP communication for CRL autoupdate.
scep-url <scep_url> URL of the SCEP CA server used for automatic CRL certificate updates. This can be HTTP or HTTPS.
update-interval <seconds> How frequently, in seconds, the FortiGate unit checks for an updated CRL. Enter 0 to update the CRL only when it expires.

Not available for http URLs.

update-vdom <update_vdom> VDOM used to communicate with remote SCEP server for CRL auto-update.

In this example, an updated CRL is requested only when it expires.

Troubleshooting

config vpn certificate crl edit cert_crl set http-url http://scep.example.com/scep set scep-cert my-scep-cert

set scep-url http://scep.ca.example.com/scep set update-interval 0 set update-vdom root

end

Backing up and restoring local certificates

The FortiGate unit provides a way to export and import a server certificate and the FortiGate unit’s personal key through the CLI. If required (to restore the FortiGate unit configuration), you can import the exported file through the System > Certificates page of the web-based manager.

As an alternative, you can back up and restore the entire FortiGate configuration through the System Information widget on the Dashboard of the web-based manager. Look for [Backup] and [Restore] in the System Configuration row. The backup file is created in a FortiGate-proprietary format.

To export a server certificate and private key – CLI:

This procedure exports a server (local) certificate and private key together as a password protected PKCS12 file. The export file is created through a customer-supplied TFTP server. Ensure that your TFTP server is running and accessible to the FortiGate unit before you enter the command.

  1. Connect to the FortiGate unit through the CLI.
  2. Type the following command:

execute vpn certificate local export tftp <cert_name> <exp_filename> <tftp_ip>

<password>

where:

l <cert_name> is the name of the server certificate; typing ? displays a list of installed server certificates. l <exp_filename> is a name for the output file. l <tftp_ip> is the IP address assigned to the TFTP server host interface.

  1. Move the output file from the TFTP server location to the management computer for future reference.

To import a server certificate and private key – web-based manager:

  1. Go to System > Certificates and select Import.
  2. In Type, select PKCS12 Certificate.
  3. Select Browse. Browse to the location on the management computer where the exported file has been saved, select the file, and then select Open.
  4. In the Password field, type the password needed to upload the exported file.
  5. Select OK, and then select Return.

To import a server certificate and private key – CLI:

  1. Connect to the FortiGate unit through the CLI.
  2. Type the following command:

 

Configuring certificate-based authentication

execute vpn certificate local import tftp <file_name> <tftp_ip_address> <file_type> <Enter for ‘cer’>|<password for ‘p12’> For example:

execute vpn certificate local import tftp FGTF-extern.p12 10.1.100.253 p12 123456

To import separate server certificate and private key files – web-based manager

Use the following procedure to import a server certificate and the associated private key file when the server certificate request and private key were not generated by the FortiGate unit. The two files to import must be available on the management computer.

  1. Go to System > Certificates and select Import.
  2. In Type, select Certificate.
  3. Select the Browse button beside the Certificate file Browse to the location on the management computer where the certificate file has been saved, select the file, and then select Open.
  4. Select the Browse button beside the Key file Browse to the location on the management computer where the key file has been saved, select the file, and then select Open.
  5. If required, in the Password field, type the associated password, and then select OK.
  6. Select Return.

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

Certificates overview

Certificates overview

Certificates play a major role in authentication of clients connecting to network services via HTTPS, both for administrators and SSL VPN users. Certificate authentication is optional for IPsec VPN peers.

This section includes:

l Certificates and protocols l IPsec VPNs and certificates l Certificate types on the FortiGate unit

Certificates and protocols

There are a number of protocols that are commonly used with certificates including SSL and HTTPS, and other certificate-related protocols.

SSL and HTTPS

The secure HTTP (HTTPS) protocol uses SSL. Certificates are an integral part of SSL. When a web browser connects to the FortiGate unit via HTTPS, a certificate is used to verify the FortiGate unit’s identity to the client.

Certificates overview

Optionally, the FortiGate unit can require the client to authenticate itself in return.

By default, the FortiGate unit uses a self-signed security certificate to authenticate itself to HTTPS clients. When the certificate is offered, the client browser displays two security messages.

  • The first message prompts users to accept and optionally install the FortiGate unit’s self-signed security certificate. If the user does not accept the certificate, the FortiGate unit refuses the connection. When the user accepts the certificate, the FortiGate login page is displayed, and the credentials entered by the user are encrypted before they are sent to the FortiGate unit. If the user chooses to install the certificate, the prompt is not displayed again.
  • Just before the FortiGate login page is displayed, a second message informs users that the FortiGate certificate distinguished name differs from the original request. This message is displayed because the FortiGate unit redirects the connection (away from the distinguished name recorded in the self-signed certificate) and can be ignored.

Optionally, you can install an X.509 server certificate issued by a certificate authority (CA) on the FortiGate unit. You can then configure the FortiGate unit to identify itself using the server certificate instead of the self-signed certificate.

For more information, see the FortiOS Handbook SSL VPN guide.

After successful certificate authentication, communication between the client browser and the FortiGate unit is encrypted using SSL over the HTTPS link.

Certificate-related protocols

There are multiple protocols that are required for handling certificates. These include the Online Certificate Status Protocol (OCSP), Simple Certificate Enrollment Protocol (SCEP), Server-based Certificate Validation Protocol (SCVP), and Certificate Management Protocol (CMP).

Online Certificate Status Protocol

Online Certificate Status Protocol (OCSP) allows the verification of X.509 certificate expiration dates. This is important to prevent hackers from changing the expiry date on an old certificate to a future date.

Normally certificate revocation lists (CRLs) are used, but OCSP is an alternate method available. However a CRL is a public list, and some companies may want to avoid the public exposure of their certificate structure even if it is only invalid certificates.

The OSCP check on the certificate’s revocation status is typically carried out over HTTP with a request-response format. The authority responding can reply with a status of good, revoked, or unknown for the certificate in question.

Simple Certificate Enrollment Protocol

Simple Certificate Enrollment Protocol (SCEP) is an automated method of signing up for certificates. Typically this involves generating a request you send directly to the SCEP service, instead of generating a file request that may or may not be signed locally.

Server-based Certificate Validation Protocol

Server-based Certificate Validation Protocol (SCVP) is used to trace a certificate back to a valid root level certificate. This ensures that each step along the path is valid and trustworthy.

Certificates overview

Certificate Management Protocol version 2

Certificate Management Protocol version 2 (CMPv2) is an enrollment and revocation protocol for certificates.

IPsec VPNs and certificates

Certificate authentication is a more secure alternative to pre-shared key (shared secret) authentication for IPsec VPN peers. Unlike administrators or SSL VPN users, IPsec peers use HTTP to connect to the VPN gateway configured on the FortiGate unit. The VPN gateway configuration can require certificate authentication before it permits an IPsec tunnel to be established. See Authenticating IPsec VPN users with security certificates on page 126 .

Certificate types on the FortiGate unit

There are different types of certificates available that vary depending on their intended use. FortiOS supports local, remote, CA, and CRL certificates.

Local certificates

Local certificates are issued for a specific server, or web site. Generally they are very specific, and often for an internal enterprise network. For example a personal web site for John Smith at www.example.com (such as http://www.example.com/home/jsmith) would have its own local certificate.

These can optionally be just the certificate file, or also include a private key file and PEM passphrase for added security.

For information about generating a certificate request, see Generating a certificate signing request on page 115. For information about installing a local certificate, see Obtaining and installing a signed server certificate from an external CA on page 118

Remote certificates

Remote certificates are public certificates without a private key. For dynamic certificate revocation, you need to use an Online Certificate Status Protocol (OCSP) server. The OCSP is configured in the CLI only. Installed Remote (OCSP) certificates are displayed in the Remote Certificates list. You can select Import to install a certificate from the management PC.

CA root certificates

CA root certificates are similar to local certificates, however they apply to a broader range of addresses or to whole company; they are one step higher up in the organizational chain. Using the local certificate example, a CA root certificate would be issued for all of www.example.com instead of just the smaller single web page.

Certificate revocation list

Certificate revocation list (CRL) is a list of certificates that have been revoked and are no longer usable. This list includes certificates that have expired, been stolen, or otherwise compromised. If your certificate is on this list, it will not be accepted. CRLs are maintained by the CA that issues the certificates and includes the date and time when the next CRL will be issued as well as a sequence number to help ensure you have the most current version of the CRL.

 

Certificate signing

The trust in a certificate comes from the authority that signs it. For example if VeriSign signs your CA root certificate, it is trusted by everyone. While these certificates are universally accepted, it is cumbersome and expensive to have all certificates on a corporate network signed with this level of trust.

With self-signed certificates nobody, except the other end of your communication, knows who you are and therefore they do not trust you as an authority. However this level is useful for encryption between two points — neither point may care about who signed the certificate, just that it allows both points to communicate. This is very useful for internal networks and communications.

A general rule is that CA signed certificates are accepted and sometimes required, but it is easier to self-sign certificates when you are able.

For more on the methods of certificate signing see Generating a certificate signing request on page 115.

BIOS certificate compatibility

FortiOS supports backwards compatibility between BIOS version 4 and BIOS version 3.

BIOS V4 certificates:

  • Fortinet_CA l Fortinet_Sub_CA l Fortinet_Factory

BIOS V3 certificates:

  • Fortinet_CA_Backup l Fortinet_Factory_Backup

When FortiOS connects to FortiGuard, FortiCloud, FortiManager, FortiAnalyzer, FortiSandbox as a client, the

BIOS certificate Fortinet_Factory will be the default client certificate. When the server returns its certificate (chain) back, FortiOS looks up the issuer of the server certificate and either keeps client certificate as is or switches to the BIOS certificate Fortinet_Factory_Backup. This process occurs in one handshake.

When FortiOS connects to FortiCare, the BIOS certificate Fortinet_Factory is the only client certificate and Server Name Indication (SNI) is set. There is no switchover of certificate during SSL handshake.

When FortiOS acts as a server when connected by FortiExtender, FortiSwitch, FortiAP, etc., Fortinet_Factory is the default server certificate. FortiOS detects SNI in client hello, and if no SNI is found or if the CN in SNI is different from the CN of Fortinet_CA, it switches to use the Fortinet_Factory_Backup.

Managing X.509 certificates

Managing security certificates is required due to the number of steps involved in both having a certificate request signed, and then distributing the correct files for use.

You use the FortiGate unit or CA software such as OpenSSL to generate a certificate request. That request is a text file that you send to the CA for verification, or alternately you use CA software to self-validate. Once validated, the certificate file is generated and must be imported to the FortiGate unit before it can be used. These steps are explained in more detail later in this section.

This section provides procedures for generating certificate requests, installing signed server certificates, and importing CA root certificates and CRLs to the FortiGate unit.

For information about how to install root certificates, CRLs, and personal or group certificates on a remote client browser, refer to your browser’s documentation.

l Generating a certificate signing request l Generating certificates with CA software l Obtaining and installing a signed server certificate from an external CA l Installing a CA root certificate and CRL to authenticate remote clients l ExtendedKeyUsage for x.509 certificates

Generating a certificate signing request

Whether you create certificates locally with a software application or obtain them from an external certificate service, you will need to generate a certificate signing request (CSR).

When you generate a CSR, a private and public key pair is created for the FortiGate unit. The generated request includes the public key of the FortiGate unit and information such as the FortiGate unit’s public static IP address, domain name, or email address. The FortiGate unit’s private key remains confidential on the FortiGate unit.

After you submit the request to a CA, the CA will verify the information and register the contact information on a digital certificate that contains a serial number, an expiration date, and the public key of the CA. The CA will then sign the certificate, and you install the certificate on the FortiGate unit.

The Certificate Request Standard is a public key cryptography standard (PKCS) published by RSA, specifically PKCS10 which defines the format for CSRs. This is defined in RFC 2986.

To generate a certificate request in FortiOS – web-based manager:

  1. Go to System > Certificates.
  2. Select Generate.
  3. In the Certificate Name field, enter a unique meaningful name for the certificate request. Typically, this would be the hostname or serial number of the FortiGate unit or the domain of the FortiGate unit such as example.com.

Prior to FortiOS 5.4, passwords for local certificates that were generated via either SCEP or CLI could not have their passwords reset. Passwords can be set in the CLI using the following command:

config vpn certificate local edit <name> set password <password>

next end

  1. Enter values in the Subject Information area to identify the FortiGate unit:
  • If the FortiGate unit has a static IP address, select Host IPand enter the public IP address of the FortiGate unit. If the FortiGate unit does not have a public IP address, use an email address (or fully qualified domain name (FQDN) if available) instead.
  • If the FortiGate unit has a dynamic IP address and subscribes to a dynamic DNS service, use a FQDN if available to identify the FortiGate unit. If you select Domain Name, enter the FQDN of the FortiGate unit. Do not include the protocol specification (http://) or any port number or path names.

If a domain name is not available and the FortiGate unit subscribes to a dynamic DNS service, an “unable to verify certificate” type message may be displayed in the user’s browser whenever the public IP address of the FortiGate unit changes.

  • If you select E-Mail, enter the email address of the owner of the FortiGate unit.
  1. Enter values in the Optional Information area to further identify the FortiGate unit.
Organization Unit Name of your department. You can enter a series of OUs up to a maximum of 5. To add or remove an OU, use the plus (+) or minus (-) icon.
Organization Legal name of your company or organization.
Locality (City) Name of the city or town where the FortiGate unit is installed.
State/Province Name of the state or province where the FortiGate unit is installed.
Country Select the country where the FortiGate unit is installed.
e-mail Contact email address.
Subject Alternative Name Optionally, enter one or more alternative names for which the certificate is also valid. Separate names with a comma. A name can be:

l e-mail address l IP address l URI l DNS name (alternatives to the Common Name) l directory name (alternatives to the Distinguished Name)

You must precede the name with the name type. Examples:

IP:1.1.1.1 email:test@fortinet.com email:my@other.address

URI:http://my.url.here/

Password for private key Option to export local certificate and its private key in password protected p12.
  1. From the Key Type list, select RSA or Elliptic Curve.
  2. From the Key Size list, select 1024 Bit, 1536 Bit, 2048 Bit, 4096 Bit or secp256r1, secp384r1, secp521r1 Larger keys are slower to generate but more secure.
  3. In Enrollment Method, you have two methods to choose from. Select File Based to generate the certificate request, or Online SCEP to obtain a signed SCEP-based certificate automatically over the network. For the SCEP method, enter the URL of the SCEP server from which to retrieve the CA certificate, and the CA server challenge password.
  4. Select OK.
  5. The request is generated and displayed in the Local Certificates list with a status of PENDING.
  6. Select the Download button to download the request to the management computer.
  7. In the File Download dialog box, select Save and save the Certificate Signing Request on the local file system of the management computer.
  8. Name the file and save it on the local file system of the management computer. The certificate request is ready for the certificate authority to be signed.

Generating certificates with CA software

CA software allows you to generate unmanaged certificates and CA certificates for managing other certificates locally without using an external CA service. Examples of CA software include ssl-ca from OpenSSL (available for Linux, Windows, and Mac) or gensslcert from SuSE, MS Windows Server 2000 and 2003 come with a CA as part of their certificate services, and in MS Windows 2008 CA software can be installed as part of the Active Directory installation. See Example — Generate and Import CA certificate with private key pair on OpenSSL on page 128.

The general steps for generating certificates with CA software are

  1. Install the CA software as a stand-alone root CA.
  2. Provide identifying information for your self-administered CA.

While following these steps, the methods vary slightly when generating server certificates, CA certificates, and PKI certificates.

Server certificate

  1. Generate a Certificate Signing Request (CSR) on the FortiGate unit.
  2. Copy the CSR base-64 encoded text (PKCS10 or PKCS7) into the CA software and generate the certificate. PKCS10 is the format used to send the certificate request to the signing authority. PKCS7 is the format the signing authority can use for the newly signed certificate.
  3. Export the certificate as a X.509 DER encoded binary file with .CER extension
  4. Upload the certificate file to the FortiGate unit Local Certificates page (type is Certificate).

CA certificate

  1. Retrieve the CA Certificate from the CA software as a DER encoded file.
  2. Import the CA certificate file to the FortiGate unit at System > Certificates and select Import > Certificates.

PKI certificate

  1. Generate a Certificate Signing Request (CSR) on the FortiGate unit.
  2. Copy the CSR base-64 encoded text (PKCS#10 or PKCS#7) into the CA software and generate the certificate. PKCS10 is the format used to send the certificate request to the signing authority. PKCS7 is the format the signing authority can use for the newly signed certificate.
  3. Export the certificate as a X.509 DER encoded binary file with .CER extension.
  4. Install the certificate in the user’s web browser or IPsec VPN client as needed.

Obtaining and installing a signed server certificate from an external CA

To obtain a signed server certificate for a FortiGate unit, you must send a request to a CA that provides digital certificates that adhere to the X.509 standard. The FortiGate unit provides a way for you to generate the request.

To submit the certificate signing request (file-based enrollment):

  1. Using the web browser on the management computer, browse to the CA web site.
  2. Follow the CA instructions for a base-64 encoded PKCS#10 certificate request and upload your certificate request.
  3. Follow the CA instructions to download their root certificate and CRL.

When you receive the signed server certificate from the CA, install the certificate on the FortiGate unit.

To install or import the signed server certificate – web-based manager

  1. On the FortiGate unit, go to System > Certificates and select Import > Local Certificates.
  2. From Type, select Local Certificate.
  3. Select Browse, browse to the location on the management computer where the certificate was saved, select the certificate, and then select Open.
  4. Select OK, and then select Return.

Installing a CA root certificate and CRL to authenticate remote clients

When you apply for a signed personal or group certificate to install on remote clients, you can obtain the corresponding root certificate and CRL from the issuing CA. When you receive the signed personal or group certificate, install the signed certificate on the remote client(s) according to the browser documentation. Install the corresponding root certificate (and CRL) from the issuing CA on the FortiGate unit according to the procedures given below.

To install a CA root certificate

  1. After you download the root certificate of the CA, save the certificate on the management computer. Or, you can use online SCEP to retrieve the certificate.
  2. On the FortiGate unit, go to System > Certificates and select Import > CA Certificates.
  3. Do one of the following: l To import using SCEP, select SCEP. Enter the URL of the SCEP server from which to retrieve the CA certificate. Optionally, enter identifying information of the CA, such as the filename.

l To import from a file, select Local PC, then select Browse and find the location on the management computer where the certificate has been saved. Select the certificate, and then select Open.

  1. Select OK, and then select Return.

The system assigns a unique name to each CA certificate. The names are numbered consecutively (CA_Cert_1, CA_Cert_2, CA_Cert_3, and so on).

To import a certificate revocation list

A Certificate Revocation List (CRL) is a list of the CA certificate subscribers paired with certificate status information. The list contains the revoked certificates and the reason(s) for revocation. It also records the certificate issue dates and the CAs that issued them.

When configured to support SSL VPNs, the FortiGate unit uses the CRL to ensure that the certificates belonging to the CA and remote peers or clients are valid. The CRL has an “effective date” and a “next update” date. The interval is typically 7 days (for Microsoft CA). FortiOS will update the CRL automatically. Also, there is a CLI command to specify an “update-interval” in seconds. Recommendation should be 24 hours (86400 seconds) but depends on company security policy.

  1. After you download the CRL from the CA web site, save the CRL on the management computer.
  2. Go to System > Certificates and select Import > CRL.
  3. Do one of the following:
    • To import using an HTTP server, select HTTP and enter the URL of the HTTP server.
    • To import using an LDAP server see this KB article.
    • To import using an SCEP server, select SCEP and select the Local Certificate from the list. Enter the URL of

the SCEP server from which the CRL can be retrieved.

  • To import from a file, select Local PC, then select Browse and find the location on the management computer where the CRL has been saved. Select the CRL and then select Open.
  1. Select OK, and then select Return.

To import a PKCS12 certificate from the CLI

The following CLI syntax can be entered to import a local certificate file:

execute vpn certificate local import tftp <file name> <tftp ip address> <file type> <Enter for ‘cer’>|<password for ‘p12’>

For example:

execute vpn certificate local import tftp FGTF-extern.p12 10.1.100.253 p12 123456

 

Troubleshooting

In addition, the following CLI syntax can be entered to update certificate bundles from an FTP or TFTP server:

execute vpn certificate ca import bundle <file-name.pkg> <ftp/tftp-server-ip>

ExtendedKeyUsage for x.509 certificates

As per Network Device Collaborative Protection Profile (NDcPP) v1.0 requirements, server certificates used for TLS connections between FortiGate and FortiAnalyzer have the “Server Authentication” and “Client Authentication” extendedKeyUsage fields in FIPS/CC mode.

The following CLI command is available under log fortianalyzer setting to allow you to specify the certificate used to communicate with FortiAnalyzer.

CLI syntax

config log fortianalyzer setting set certificate <name>

end


Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

What is a security certificate?

What is a security certificate?

A security certificate is a small text file that is part of a third-party generated public key infrastructure (PKI) to help guarantee the identity of both the user logging on and the web site they where they are logging in.

A certificate includes identifying information such as the company and location information for the web site, as well as the third-party company name, the expiry date of the certificate, and the public key.

FortiGate units use X.509 certificates to authenticate single sign-on (SSO) for users. The X.509 standard has been in use since before 2000, but has gained popularity with the Internet’s increased popularity. X.509 v3 is defined in RFC 5280 and specifies standard formats for public key certificates, certificate revocation lists, and a certification path validation algorithm. The unused earlier X.509 version 1 was defined in RFC 1422.

The main difference between X.509 and PGP certificates is that where in PGP anyone can sign a certificate, for X.509 only a trusted authority can sign certificates. This limits the source of certificates to well known and trustworthy sources. Where PGP is well suited for one-to-one communications, the X.509 infrastructure is intended to be used in many different situations including one-to-many communications. Some common filename extensions for X.509 certificates are listed below.

Certificates overview

Common certificate filename extensions

Filetype Format name Description
.pem Privacy Enhanced Mail (PEM) Base64 encoded DER certificate, that uses:

“—–BEGIN CERTIFICATE—–” and

“—–END CERTIFICATE—–”

.cer

.crt

.der

Security Certificate Usually binary DER form, but Base64-encoded certificates are common too.
.p7b

.p7c

  Structure without data, just certificates or CRLs.

PKCS#7 is a standard for signing or encrypting (officially called “enveloping”) data.

.p12 PKCS#12 May contain certificate(s) (public) and private keys (password protected).
.pfx personal information exchange (PFX) Older format. Came before PKCS#12. Usually today data is in PKCS#12 format.

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

Captive portals

Captive portals

A captive portal is a convenient way to authenticate web users on wired or WiFi networks.

This section describes:

l Introduction to captive portals l Configuring a captive portal l Customizing captive portal pages

Introduction to captive portals

You can authenticate your users on a web page that requests the user’s name and password. Until the user authenticates successfully, the authentication page is returned in response to any HTTP request. This is called a captive portal.

After successful authentication, the user accesses the requested URL and can access other web resources, as permitted by security policies. Optionally, the captive portal itself can allow web access to only the members of specified user group.

The captive portal can be hosted on the FortiGate unit or on an external authentication server. You can configure captive portal authentication on any network interface, including WiFi and VLAN interfaces.

When a captive portal is configured on a WiFi interface, the access point initially appears open. The wireless client can connect to the access point with no security credentials, but sees only the captive portal authentication page.

WiFi captive portal types:

  • Authentication — until the user enters valid credentials, no communication beyond the AP is permitted.
  • Disclaimer + Authentication — immediately after successful authentication, the portal presents the disclaimer page—an acceptable use policy or other legal statement—to which the user must agree before proceeding.
  • Disclaimer Only — the portal presents the disclaimer page—an acceptable use policy or other legal statement— to which the user must agree before proceeding. The authentication page is not presented.
  • Email Collection — the portal presents a page requesting the user’s email address, for the purpose of contacting the person in future. This is often used by businesses who provide free WiFi access to their customers. The authentication page is not presented.

Configuring a captive portal

Captive portals are configured on network interfaces. On a physical (wired) network interface, you edit the interface configuration in Network > Interfaces and set Security Mode to Captive Portal. A WiFi interface does not exist until the WiFi SSID is created. You can configure a WiFi captive portal at the time that you create the SSID. Afterwards, the captive portal settings will also be available by editing the WiFi network interface in Network > Interfaces.

To configure a wired Captive Portal – web-based manager:

  1. Go to Network > Interfaces and edit the interface to which the users connect.
  2. In Security Mode select Captive Portal.
  3. Enter
Authentication Portal Local – portal hosted on the FortiGate unit.

Remote – enter FQDN or IP address of external portal.

User Groups Select permitted user groups or select Use Groups from Policies, which permits the groups specified in the security policy.

Use Groups from Policies is not available in WiFi captive portals.

Exempt List Select exempt lists whose members will not be subject to captive portal authentication.
Customize Portal Messages Enable, then select Edit. See Customizing captive portal pages on page 105.
  1. Select OK.

To configure a WiFi captive portal – web-based manager:

  1. Go to WiFi & Switch Controller > SSID and create your SSID.

If the SSID already exists, you can edit the SSID or you can edit the WiFi interface in Network > Interfaces.

  1. In Security Mode, select Captive Portal.

Configuring a captive portal

  1. Enter
Portal Type The portal can provide authentication and/or disclaimer, or perform user email address collection. See Introduction to captive portals on page 102.
Authentication Portal Local – portal hosted on the FortiGate unit.

Remote – enter FQDN or IP address of external portal.

User Groups Select permitted user groups.
Exempt List Select exempt lists whose members will not be subject to captive portal authentication.
Customize Portal Messages Click the link of the portal page that you want to modify. See “Captive portals” on page 105.
  1. Select OK.

Exemption from the captive portal

A captive portal requires all users on the interface to authenticate. But some devices are not able to authenticate. You can create an exemption list of these devices. For example, a printer might need to access the Internet for firmware upgrades. Using the CLI, you can create an exemption list to exempt all printers from authentication.

config user security-exempt-list edit r_exempt config rule edit 1 set devices printer

end end

IPv6 and captive portals

Captive portal supports IPv6. Host name and address commands are available under config auth setting:

 

config auth setting set captive-portal6 –> IPv6 captive portal host name set captive-portal-ip6 –> Captive portal IPv6 address

end

Customizing captive portal pages

These pages are defined in replacement messages. Defaults are provided. In the web-based manager, you can modify the default messages in the SSID configuration by selecting Customize Portal Messages. Each SSID can have its own unique portal content.

The captive portal contains the following default web pages: l Login page—requests user credentials

Typical modifications for this page would be to change the logo and modify some of the text.

You can change any text that is not part of the HTML code nor a special tag enclosed in double percent (%) characters.

There is an exception to this rule. The line “Please enter your credentials to continue” is provided by the %%QUESTION%% tag. You can replace this tag with text of your choice. Except for this item, you should not remove any tags because they may carry information that the FortiGate unit needs. l Login failed page—reports that the entered credentials were incorrect and enables the user to try again.

Customizing captive portal pages

The Login failed page is similar to the Login page. It even contains the same login form. You can change any text that is not part of the HTML code nor a special tag enclosed in double percent (%) characters.

There is an exception to this rule. The line “Firewall authentication failed. Please try again.” is provided by the %%FAILED_MESSAGE%% tag. You can replace this tag with text of your choice. Except for this item, you should not remove any tags because they may carry information that the FortiGate unit needs.

  • Disclaimer page—is a statement of the legal responsibilities of the user and the host organization to which the user must agree before proceeding.(WiFi or SSL VPN only)
  • Declined disclaimer page—is displayed if the user does not agree to the statement on the Disclaimer page. Access is denied until the user agrees to the disclaimer.

 

Changing images in portal messages

You can replace the default Fortinet logo with your organization’s logo. First, import the logo file into the FortiGate unit and then modify the Login page code to reference your file.

To import a logo file:

  1. Go to System > Replacement Messages and select Manage Images.
  2. Select Create New.
  3. Enter a Name for the logo and select the appropriate Content Type. The file must not exceed 24 Kilo bytes.
  4. Select Browse, find your logo file and then select Open.
  5. Select OK.

To specify the new logo in the replacement message:

  1. Go to Network > Interfaces and edit the interface. The Security Mode must be Captive Portal.
  2. Select the portal message to edit.
    • In SSL VPN or WiFi interfaces, in Customize Portal Messages click the link to the portal messages that you want to edit.
    • In other interfaces, make sure that Customize Portal Messages is selected, select the adjacent Edit icon, then select the message that you want to edit.
  3. In the HTML message text, find the %%IMAGE tag.

By default it specifies the Fortinet logo: %%IMAGE:logo_fw_auth%%

  1. Change the image name to the one you provided for your logo. The tag should now read, for example, %%IMAGE:mylogo%%
  2. Select Save.
  3. Select OK.

Modifying text in portal messages

Generally, you can change any text that is not part of the HTML code nor a special tag enclosed in double percent (%) characters. You should not remove any tags because they may carry information that the FortiGate unit needs. See the preceding section for any exceptions to this rule for particular pages.

To modify portal page text

  1. Go to Network > Interfaces and edit the interface.

The SSID Security Mode must be Captive Portal.

  1. Select the portal message to edit.
    • In SSL VPN or WiFi interfaces, in Customize Portal Messages click the link to the portal messages that you want to edit.
    • In other interfaces, make sure that Customize Portal Messages is selected, select the adjacent Edit icon, then select the message that you want to edit.
  2. Edit the HTML message text, then select Save.
  3. Select OK.

Configuring disclaimer page for ethernet interface captive portals

While you can customize a disclaimer page for captive portals that connect via WiFi, the same can be done for wired connections. However, this can only be configured on the CLI Console, and only without configuring user groups.

When configuring a captive portal through the CLI, you may set security-groups to a specific user group. The result of this configuration will show an authentication form to users who wish to log in to the captive portal— not a disclaimer page. If you do not set any security-groups in your configuration, an “Allow all” status will be in effect, and the disclaimer page will be displayed for users.

The example CLI configuration below shows setting up a captive portal interface without setting security-groups, resulting in a disclaimer page for users:

config system interface edit “port1” set vdom “root” set ip 172.16.101.1 255.255.255.0 set allowaccess ping https ssh snmp http set type physical set explicit-web-proxy enable set alias “LAN”

set security-mode captive-portal

set snmp-index 1

next end

 


Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

VPN authentication

VPN authentication

All VPN configurations require users to authenticate. Authentication based on user groups applies to: l SSL VPNs l PPTP and L2TP VPNs

l an IPsec VPN that authenticates users using dialup groups l a dialup IPsec VPN that uses XAUTH authentication (Phase 1)

You must create user accounts and user groups before performing the procedures in this section. If you create a user group for dialup IPsec clients or peers that have unique peer IDs, their user accounts must be stored locally on the FortiGate unit. You cannot authenticate these types of users using a RADIUS or LDAP server.

Configuring authentication of SSL VPN users

The general procedure for authenticating SSL VPN users is:

  1. Configure user accounts.
  2. Create one or more user groups for SSL VPN users.
  3. Enable SSL VPN.
  4. Optionally, set inactivity and authentication timeouts.
  5. Configure a security policy with the user groups you created for SSL VPN users.

See FortiOS Handbook SSL VPN guide.

Configuring authentication timeout

By default, the SSL VPN authentication expires after 8 hours (28 800 seconds). You can change it only in the CLI, and the time entered must be in seconds. The maximum time is 72 hours (259 200 seconds). For example, to change this timeout to one hour, you would enter:

config vpn ssl settings set auth-timeout 3600

end

If you set the authentication timeout (auth-timeout) to 0 when you configure the timeout settings, the remote client does not have to re-authenticate unless they log out of the system. To fully take advantage of this setting, VPN authentication

the value for idle-timeout has to be set to 0 also, so that the client does not time out if the maximum idle time is reached. If the idle-timeout is not set to the infinite value, the system will log out if it reaches the limit set, regardless of the auth-timeout setting.

Configuring authentication of remote IPsec VPN users

An IPsec VPN on a FortiGate unit can authenticate remote users through a dialup group. The user account name is the peer ID and the password is the pre-shared key.

Authentication through user groups is supported for groups containing only local users. To authenticate users using a RADIUS or LDAP server, you must configure XAUTH settings. See Configuring XAuth authentication.

To configure user group authentication for dialup IPsec – web-based manager:

  1. Configure the dialup users who are permitted to use this VPN. Create a user group with Type set to Firewall and add them to it.

For more information, see Users and user groups on page 49

  1. Go to VPN > IPsec Wizard, select Remote Access, choose a name for the VPN, and enter the following information.
Incoming Interface Select the incoming interface name.
Authentication Method List of authentication methods available for users. Select Pre-shared Key and enter the pre-shared key.
User Group Select the user group that is to be allowed access to the VPN. The listed user groups contain only users with passwords on the FortiGate unit.
  1. Select Next and continue configure other VPN parameters as needed.
  2. Select OK.

To configure user group authentication for dialup IPsec – CLI example:

The peertype and usrgrp options configure user group-based authentication.

config vpn ipsec phase1 edit office_vpn set interface port1 set type dynamic set psksecret yORRAzltNGhzgtV32jend set proposal 3des-sha1 aes128-sha1 set peertype dialup set usrgrp Group1

end

Configuring XAuth authentication

Extended Authentication (XAuth) increases security by requiring additional user authentication information in a separate exchange at the end of the VPN Phase 1 negotiation. The FortiGate unit asks the user for a username and password. It then forwards the user’s credentials (the password is encrypted) to an external RADIUS or LDAP server for verification.

XAuth can be used in addition to or in place of IPsec phase 1 peer options to provide access security through an LDAP or RADIUS authentication server. You must configure a dialup user group whose members are all externally authenticated.

To configure authentication for a dialup IPsec VPN – web-based manager:

  1. Configure the users who are permitted to use this VPN. Create a user group and add the users to the group. For more information, see “Users and user groups” on page 49.
  2. Go to VPN > IPsec Wizard, select Remote Access, choose a name for the VPN, and enter the following information.
Incoming Interface Select the incoming interface name.
Authentication Method List of authentication methods available for users. Select Pre-shared Key and enter the pre-shared key.
User Group Select the user group that is to be allowed access to the VPN. The listed user groups contain only users with passwords on the FortiGate unit.
  1. Select Next and continue configure other VPN parameters as needed.
  2. Select OK.
  3. Go to VPN > IPsec Tunnels, edit the Tunnel just created, select Convert To Custom Tunnel, and edit XAUTH as following:
Type Select PAP, CHAP, or AUTO. Use CHAP whenever possible. Use PAP with all implementations of LDAP and with other authentication servers that do not support CHAP, including some implementations of Microsoft RADIUS. Use AUTO with the Fortinet Remote VPN Client and where the authentication server supports CHAP but the XAuth client does not.
User Group Select the user group that is to have access to the VPN. The list of user groups does not include any group that has members whose password is stored on the FortiGate unit.
  1. Select OK.

For more information about XAUTH configuration, see the IPsec VPN chapter of the FortiOS Handbook.

To configure authentication for a dialup IPsec VPN – CLI example:

The xauthtype and authusrgrp fields configure XAuth authentication.

config vpn ipsec phase1 edit office_vpn set interface port1 set type dynamic set psksecret yORRAzltNGhzgtV32jend set proposal 3des-sha1 aes128-sha1 set peertype dialup set xauthtype pap set usrgrp Group1 end

VPN authentication

Some parameters specific to setting up the VPN itself are not shown here. For detailed information about configuring IPsec VPNs, see the FortiOS Handbook IPsec VPN guide.

Configuring authentication of PPTP VPN users and user groups

Configuration of a PPTP VPN is possible only through the CLI. You can configure user groups and security policies using either CLI or web-based manager.

LDAP user authentication is supported for PPTP, L2TP, IPsec VPN, and firewall authentication.

However, with PPTP, L2TP, and IPsec VPN, PAP (Packet Authentication Protocol) is supported, while CHAP (Challenge Handshake Authentication Protocol) is not.

To configure authentication for a PPTP VPN

  1. Configure the users who are permitted to use this VPN. Create a security user group and add them to it. For more information, see Users and user groups on page 49.
  2. Configure the PPTP VPN in the CLI as in this example.

config vpn pptp set status enable set sip 192.168.0.100 set eip 192.168.0.110 set usrgrp PPTP_Group

end

The sip and eip fields define a range of virtual IP addresses assigned to PPTP clients.

Configure a security policy. The source interface is the one through which the clients will connect. The source address is the PPTP virtual IP address range. The destination interface and address depend on the network to which the clients will connect. The policy action is ACCEPT.

Configuring authentication of L2TP VPN users/user groups

Configuration of a L2TP VPN is possible only through the CLI. You can configure user groups and security policies using either CLI or web-based manager.

LDAP user authentication is supported for PPTP, L2TP, IPsec VPN, and firewall authentication.

However, with PPTP, L2TP, and IPsec VPN, PAP (Packet Authentication Protocol) is supported, while CHAP (Challenge Handshake Authentication Protocol) is not.

To configure authentication for a L2TP VPN

  1. Configure the users who are permitted to use this VPN. Create a user group and add them to it. For more information, see Users and user groups on page 49.
  2. Configure the L2TP VPN in the CLI as in this example.

config vpn l2tp set status enable set sip 192.168.0.100 set eip 192.168.0.110 set usrgrp L2TP_Group end

The sip and eip fields define a range of virtual IP addresses assigned to L2TP clients.

  1. Configure a security policy. The source interface is the one through which the clients will connect. The source address is the L2TP virtual IP address range. The destination interface and address depend on the network to which the clients will connect. The policy action is ACCEPT.

 


Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

Authentication in security policies

Authentication in security policies

Security policies control traffic between FortiGate interfaces, both physical interfaces and VLAN subinterfaces. The firewall tries to match the session’s user or group identity, device type, destination, or other attribute to a security policy. When a match is found, the user connects to the requested destination. If no security policy matches, the user is denied access.

A user who has not already been authenticated by a captive portal, FSSO, or RSSO can match only policies where no user or user group is specified. If no such policy exists, the firewall requests authentication. If the user can authenticate and the session can be matched to a policy, the user connects to the requested destination, otherwise, the user is denied access. This section includes:

  • Enabling authentication protocols l Authentication replacement messages l Access to the Internet l Configuring authentication security policies l Identity-based policy l NTLM authentication l Certificate authentication
  • Restricting number of concurrent user logins

Enabling authentication protocols

Users can authenticate using FTP, HTTP, HTTPS, and Telnet. However, these protocols must be enabled first.

Another authentication option is to redirect any attempts to authenticate using HTTP to a more secure channel that uses HTTPS. This forces users to a more secure connection before entering their user credentials.

To enable support for authentication protocols – web-based manager:

  1. Go to User & Device > Authentication Settings.
  2. Select one or more of HTTP, HTTPS, FTP, Telnet, or Redirect HTTP Challenge to a Secure Channel (HTTPS). Only selected protocols will be available for use in authentication.
  3. Select the Certificate to use, for example Fortinet_Factory.
  4. Select Apply.

To enable support for authentication protocols – CLI:

config user setting set auth-type ftp http https telnet set auth-cert Fortinet_Factory

end

As of FortiOS 5.4, the Fortinet_Factory certificate has been re-signed with an expiration date of 2038. It is used instead of Fortinet_ Factory2, which has been removed.

Authentication replacement messages

A replacement message is the body of a web page containing a message about a blocked website message, a file too large message, a disclaimer, or even a login page for authenticating. The user is presented with this message instead of the blocked content.

Authentication replacement messages are the prompts a user sees during the security authentication process such as login page, disclaimer page, and login success or failure pages. These are different from most replacement messages because they are interactive requiring a user to enter information, instead of simply informing the user of some event as other replacement messages do.

Replacement messages have a system-wide default configuration, a per-VDOM configuration, and disclaimers can be customized for multiple security policies within a VDOM.

These replacement messages are used for authentication using HTTP and HTTPS. Authentication replacement messages are HTML messages. You cannot customize the security authentication messages for FTP and Telnet.

The authentication login page and the authentication disclaimer include replacement tags and controls not found on other replacement messages.

More information about replacement messages can be found in the config system replacemsg section of the FortiOS CLI Reference.

 

List of authentication replacement messages

Replacement message name (CLI name) Description
Login challenge page

(auth-challenge-page)

This HTML page is displayed if security users are required to answer a question to complete authentication. The page displays the question and includes a field in which to type the answer. This feature is supported by RADIUS and uses the generic RADIUS challenge-access auth response. Usually, challenge-access responses contain a Reply-Message attribute that contains a message for the user (for example, “Please enter new PIN”). This message is displayed on the login challenge page. The user enters a response that is sent back to the RADIUS server to be verified.

The Login challenge page is most often used with RSA RADIUS server for RSA SecurID authentication. The login challenge appears when the server needs the user to enter a new PIN. You can customize the replacement message to ask the user for a SecurID PIN.

This page uses the %%QUESTION%% tag.

Disclaimer page

(auth-disclaimer-page-1)

(auth-disclaimer-page-2)

(auth-disclaimer-page-3)

This page prompts user to accept the displayed disclaimer when leaving the captive portal to access Internet resources. It is displayed when the captive portal type is Authentication and Disclaimer or Disclaimer Only.

In the CLI, the auth-disclaimer-page-2 and auth-disclaimer-page-3 pages seamlessly extend the size of the disclaimer page from 8 192 characters to 16 384 and 24 576 characters respectively. In the web-based manager this is handled automatically.

See Disclaimer on page 84.

Email token page

(auth-email-token-page)

The page prompting a user to enter their email token. See Email on page

1.

FortiToken page

(auth-fortitoken-page)

The page prompting a user to enter their FortiToken code. See FortiToken on page 56.
Replacement message name (CLI name) Description
Keepalive page

(auth-keepalive-page)

The HTML page displayed with security authentication keepalive is enabled using the following CLI command:

config system globalset auth-keepalive enable end

Authentication keepalive keeps authenticated firewall sessions from ending when the authentication timeout ends. In the web-based manager, go to User & Device > Authentication Settings to set the Authentication Timeout.

This page includes %%TIMEOUT%%.

Login failed page

(auth-login-failed-page)

The Disclaimer page replacement message does not re-direct the user to a redirect URL or the security policy does not include a redirect URL. When a user selects the button on the disclaimer page to decline access through the FortiGate unit, the Declined disclaimer page is displayed.
Login page

(auth-login-page)

The authentication HTML page displayed when users who are required to authenticate connect through the FortiGate unit using HTTP or HTTPS.

Prompts the user for their username and password to login.

This page includes %%USERNAMEID%% and %%PASSWORDID%% tags.

Declined disclaimer page

(auth-reject-page)

The page displayed if a user declines the disclaimer page. See Disclaimer on page 84.
SMS Token page

(auth-sms-token-page)

The page prompting a user to enter their SMS token. See SMS on page 56.
Success message

(auth-success-msg)

The page displayed when a user successfully authenticates. Prompts user to attempt their connection again (as the first was interrupted for authentication).

Access to the Internet

A policy for accessing the Internet is similar to a policy for accessing a specific network, but the destination address is set to all. The destination interface is the one that connects to the Internet Service Provider (ISP). For general purpose Internet access, the Service is set to ALL.

Access to HTTP, HTTPS, FTP and Telnet sites may require access to a domain name service. DNS requests do not trigger authentication. You must configure a policy to permit unauthenticated access to the appropriate DNS server, and this policy must precede the policy for Internet access. Failure to do this will result in the lack of a DNS connection and a corresponding lack of access to the Internet.

Configuring authentication security policies

To include authentication in a security policy, the policy must specify user groups. A security policy can authenticate by certificate, FSSO, and NTLM. The two exceptions to this are RADIUS SSO and FSSO Agents.

Before creating a security policy, you need to configure one or more users or user groups.

Creating the security policy is the same as a regular security policy except you must select the action specific to your authentication method:

Authentication methods allowed for each policy Action

Action Authentication method Where authentication is used
ACCEPT FSSO Agent or a security policy that specifies an FSSO user group Agent-based FSSO on page 147.
  NTLM See NTLM authentication on page 86.
  Certificates See Configuring certificate-based authentication on page 124.
  RADIUS SSO See SSO using RADIUS accounting records on page 192.
DENY none none

Disclaimer

A WiFi or SSL captive portal can include a disclaimer message presented after the user authenticates. The user must agree to the terms of the disclaimer to access network resources.

Customizing authentication replacement messages

Customizing disclaimers or other authentication replacement messages involves changing the text of the disclaimer message, and possibly the overall appearance of the message.

Changing the disclaimer in System > Replacement Messages is not the same as selecting to customize a disclaimer used in a captive portal. The captive portal location is a customized disclaimer that inherits the default format for the disclaimer message, but then can be customized for this portal.

To customize the disclaimer for a captive portal – web-based manager:

  1. Go to Network > Interfaces. Either select an existing interface or create a new one.
  2. Under Security Mode, select Captive Portal, and enable Customize Portal Messages.
  3. Select the Edit You can select and edit any of the pages. Change your text or layout as needed. Enabling security logging

There are two types of logging that relate to authentication — event logging, and security logging.

When enabled, event logging records system events such as configuration changes, and authentication. To configure event logging, go to Log & Report > Log Settings and enable Event Logging. Select the events you want to log, such as User activity event.

When enabled, security logging will log security profile and security policy traffic.

You must enable logging within a security policy, as well as the options that are applied to a security policy, such as security profiles features. Event logs are enabled within the Event Log page.

For more information on logging, see the FortiOS Log and Reporting guide.

For more information on specific types of log messages, see the FortiOS Log Message Reference.

To enable logging within an existing security policy – web-based manager:

  1. Go to Policy & Objects > IPv4 Policy.
  2. Expand to reveal the policy list of a policy.
  3. Select the security policy you want to enable logging on and then select Edit.
  4. To log all general firewall traffic, select the check box beside Log Allowed Traffic, and choose to enable Security Events or All Sessions.
  5. Select OK.

Identity-based policy

An identity-based policy (IBP) performs user authentication in addition to the normal security policy duties. If the user does not authenticate, access to network resources is refused. This enforces Role Based Access Control (RBAC) to your organization’s network and resources.

Identity-based policies also support Single Sign-On operation. The user groups selected in the policy are of the Fortinet Single Sign-On (FSSO) type.

User authentication can occur through any of the following supported protocols, including: HTTP, HTTPS, FTP, and Telnet. The authentication style depends on which of these protocols is included in the selected security services group and which of those enabled protocols the network user applies to trigger the authentication challenge.

For username and password-based authentication (HTTP, FTP, and Telnet) the FortiGate unit prompts network users to enter their username, password, and token code if two-factor authentication is selected for that user account. For certificate-based authentication, including HTTPS or HTTP redirected to HTTPS only, see Certificate authentication on page 96.

With identity-based policies, the FortiGate unit allows traffic that matches the source and destination addresses, device types, and so on. This means specific security policies must be placed before more general ones to be effective.

When the identity-based policy has been configured, the option to customize authentication messages is available. This allows you to change the text, style, layout, and graphics of the replacement messages associated with this firewall policy. When enabled, customizing these messages follows the same method as changing the disclaimer. See Disclaimer on page 84.

Types of authentication also available in identity-based policies are l NTLM authentication l Certificate authentication

NTLM authentication

NT LAN Manager (NTLM) protocol can be used as a fallback for authentication when the Active Directory (AD) domain controller is unreachable. NTLM uses the web browser to send and receive authentication information. See “NTLM” and “FSSO NTLM authentication support”.

To enable NTLM

  1. Edit the policy in the CLI to enable NTLM. For example, if the policy ID is 4:
  2. Go to Policy & Objects > IPv4 Policy and note the ID number of your FSSO policy.
  3. The policy must have an FSSO user group as Source User(s). There must be at least one FSSO Collector agent configured on the FortiGate unit.

config firewall policy edit 4 set ntlm enable

end

NTLM guest access

Guest profile access may be granted to users who fail NTLM authentication, such as visitors who have no user credentials on the network. To allow guest user access, edit the FSSO security policy in the CLI, like this:

config firewall policy edit 4 set ntlm enable set ntlm-guest enable

end

NTLM enabled browsers – CLI

User agent strings for NTLM enabled browsers allow the inspection of initial HTTP-User-Agent values, so that non-supported browsers are able to go straight to guest access without needlessly prompting the user for credentials that will fail. ntlm-guest must be enabled to use this option.

config firewall policy edit 4 set ntlm enable set ntlm-guest enable

set ntlm-enabled-browsers <user_agent_string>

next end

<user_agent_string> is the name of the browser that is NTLM enabled. Examples of these values include “MSIE”, “Mozilla” (which includes FireFox), and “Opera”.

Value strings can be up to 63 characters in length, and may not contain cross site scripting (XSS) vulnerability characters such as brackets. The FortiGate unit prevents use of these characters to prevent exploit of cross site scripting (XSS) vulnerabilities.

 

Kerberos authentication for explicit web and transparent web proxy users

Kerberos authentication is a method for authenticating both explicit web proxy and transparent web proxy users. It has several advantages over NTLM challenge response:

  • Does not require FSSO/AD agents to be deployed across domains. l Requires fewer round-trips than NTLM SSO, making it less latency sensitive.
  • Is (probably) more scalable than challenge response. l Uses existing Windows domain components rather than added components. l NTLM may still be used as a fallback for non-Kerberos clients.

Enhancements to Kerberos explicit and transparent web proxy

FortiOS 5.6.x authentication is managed by schemes and rules based on protocol and source address. As such, configurable authentication settings have been introduced to enhance authentication.

CLI commands (config authentication rule, scheme, and setting) allow explicit proxy rules and schemes to be created to separate user authentication (e.g. authentication rules and schemes used to match conditions in order to identify users) from user authorization (proxy-based policies with users and/or user groups).

CLI syntax – config authentication rule

config authentication rule edit <name> set name <name> set status {enable|disable} set protocol {http|ftp|socks} config srcaddr <addr-name or addrgrp-name> edit <name> set name <ipv4-policy-name>

next

end

config srcaddr6 <addr-name or addrgrp-name> edit <name> set name <ipv6-policy-name>

next

end set ip-based {enable|disable} set active-auth-method <scheme-name> set sso-auth-method <scheme-name>

set transaction-based {enable|disable} – basic scheme + session-based set web-auth-cookie {enable|disable} set comments <comments>

next

end

Note: As shown above, HTTP, FTP, and SOCKSv5 authentication protocols are supported for explicit proxy.

Authentication rules are used to receive user-identity, based on the values set for protocol and source address. Having said this, if a rule fails to match based on source address, there will be no other attempt to match the rule, however the next policy will be attempted. This occurs only when:

l there is an authentication rule, but no authentication method has been set (under config authentication scheme; see below), so user identity cannot be found. l the user is successfully matched in the rule, but fails to match the current policy.

Once a rule is positively matched through protocol and/or source address, it must also match the authentication method specified (active-auth-method and sso-auth-method). These methods point to schemes, as defined under config authentication scheme.

CLI syntax – config authentication scheme

config authentication scheme edit <name> set name <name>

set method {basic|digest|ntlm|form|negotiate|fsso|rsso} set negotiate-ntlm {enable|disable} set require-tfa {enable|disable} set fsso-guest {enable|disable} config user-database edit <name> set name {local|<ldap-server>|<radius-server>|<fsso-name>|<rsso-name>|<tacacs+name>}

next

end

next

end

Combining authentication rules and schemes, granular control can be exerted over users and IPs, creating an efficient process for users to successfully match a criteria before matching the policy.

Additional options can be set under config authentication setting.

CLI syntax – config authentication setting

config authentication setting set sso-scheme <scheme-name> set active-scheme <scheme-name> set captive-portal <host-name> set captive-portal-port <tcp-port>

end

Integration of transparent and explicit proxy HTTP policy checking

A CLI command, under config firewall profile-protocol-options, allows HTTP policy checking to be enable or disabled. When enabled, transparent traffic can be matched in a firewall policy and policy user authentication can occur. In addition, separate SSL inspection policies can be created:

config firewall profile-protocol-options edit <name> set http-policy {enable|disable}

end

Internet Service Database in Explicit/Implicit proxy policies

CLI commands, under config firewall proxy-policy, implement the Internet Service Database (ISDB) as the webproxy matching factor, and override IP pool is also support:

config firewall proxy-policy

edit <name> set proxy {explicit-web|transparent-web|ftp|wanopt} set dstintf <dst-name> set poolname <ip-pool-name>

end

Multiple port/port range support for explicit web and explicit FTP proxy

Multiple port numbers and/or ranges can be set for explicit proxy, specifically for HTTP/HTTPS and FTP. Go to Network > Explicit Proxy and configure settings under Explicit Web Proxy and Explicit FTP Proxy, or under config web-proxy explicit in the CLI Console.

1. General configuration

1.1 Kerberos environment – Windows server setup

  1. Build a Windows 2008 Platform server.
  2. Enable domain configuration in windows server (dcpromo).
  3. Set the domain name TEST.COM (realm name).

1.2 Create users

  • testuser is a normal user (could be any existing domain user account).
  • testfgt is the service name. In this case it should be the FQDN for the explicit proxy Interface, For example the hostname in the client browser proxy config. l Recommendation: create username all in lowercase (even if against corporate standards).
  • The account only requires “domain users” membership l Password set to never expire l Set a very strong password
    • Add FortiGate to DNS

For Lab/Testing add the FortiGate Domain name and IP mapping in the hosts file

(windows/system32/drivers/etc/hosts). e.g., TESTFGT.TEST.COM 10.10.1.10

  • Generate the Kerberos keytab

Use the ktpass command (found on Windows Servers and many domain workstations) to generate the Kerberos keytab.

Example:

ktpass -princ HTTP/<domain name of test fgt>@realm -mapuser testfgt -pass <password> crypto all -ptype KRB5_NT_PRINCIPAL -out fgt.keytab

ktpass -princ HTTP/testfgt.test.com@TEST.COM -mapuser testfgt -pass 12345678 -crypto all ptype KRB5_NT_PRINCIPAL -out fgt.keytab

  • Encode base64

Use the base64 command (available in most Linux distros) command to encode the fgt.keytab file. Any LF (Line Feed) need to be deleted from the file. Example:

base64 fgt.keytab > fgt.txt

2. FortiGate configuration

2.1 Create LDAP server instance

config user ldap edit “ldap” <<< Required for authorization set server “10.10.1.1” <<< LDAP server IP, normally it should be same as KDC server set cnid “cn” set dn “dc=test,dc=com” set type regular

set username “CN=admin,CN=Users,DC=test,DC=com” <<< Your domain may require STARTTLS set password <FOOS>

next

end

2.2 Define Kerberos as an authentication service

config user krb-keytab edit “http_service” set principal “HTTP/testfgt.test.com@TEST.COM” <<< Same as the principal name in 1.4 set ldap-server “ldap” <<< the defined ldap server for authoriztion set keytab “BQIAAABNAAIACkJFUkJFUi5DT00ABEhUVFAAGlRPTllfRkdUXzEwMERfQS5CRVJCRVIuQ09NAAAAAQA

AAAAKABcAEJQl0MHqovwplu7XzfENJzw=” <<< base64 endoding keytab data, created in step 1.5 next

end

2.3 Create user group(s)

config user group <<< the group is used for kerberos authentication edit “testgrp” set member “ldap” config match edit 1 set server-name “ldap” <<< Same as ldap-server option in krb-keytab set group-name “CN=Domain Users,CN=Users,DC=TEST,DC=com”

next

end

next

end

2.4 Create firewall policy

config firewall proxy-policy edit 1 set uuid 5e5dd6c4-952c-51e5-b363-120ad77c1414 set proxy explicit-web set dstintf “port1” set srcaddr “all” set dstaddr “all” set service “webproxy” set action accept set schedule “always” set groups “CN=USERS LAB.PS FSSO”

next

end

2.5 Diagnostics

Once the keytab is imported, check that it has been properly decoded. The filename generated will be relatively random, but should be clearly visible.

Artoo-Deetoo (root) # fnsysctl ls -la /tmp/kt drwxr–r– 2 0  0 Fri Dec 2 10:06:43 2016   60 . drwxrwxrwt 22 0  0 Tue Dec 6 14:28:29 2016    3280 .. -rw-r–r– 1 0  0 Fri Dec 2 10:06:43 2016   392 1.0.89.keytab

3. Client side walkthrough

3.1 Check Kerberos is working

Log on to the domain by using testuser, created in 1.2. Use the klist command to list ticket information. In the below example, the client has received krbtgt, CIFS, and LDAP tickets. As there has been no interaction with the FortiGate, there are no references to it.

C:\Users\glenk>klist Cached Tickets: (5)

C:\Users\glenk>klist

Cached Tickets: (5)

#0> Client: glenk @ home.local

Server: krbtgt/HOME.LOCAL @ HOME.LOCAL

KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96

Ticket Flags 0x60a00000 -> forwardable forwarded renewable pre_authent

Start Time: 12/6/2016 14:58:06 (local)

End Time: 12/7/2016 0:58:04 (local)

Renew Time: 12/13/2016 14:58:04 (local)

Session Key Type: AES-256-CTS-HMAC-SHA1-96

#1> Client: glenk @ home.local

Server: krbtgt/HOME.LOCAL @ HOME.LOCAL

KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96

Ticket Flags 0x40e00000 -> forwardable renewable initial pre_authent

Start Time: 12/6/2016 14:58:04 (local)

End Time: 12/7/2016 0:58:04 (local)

Renew Time: 12/13/2016 14:58:04 (local)

Session Key Type: AES-256-CTS-HMAC-SHA1-96

#2> Client: glenk @ home.local

Server: cifs/EthicsGradient.home.local @ HOME.LOCAL

KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96

Ticket Flags 0x40a40000 -> forwardable renewable pre_authent ok_as_delegate

Start Time: 12/6/2016 14:58:06 (local)

End Time: 12/7/2016 0:58:04 (local)

Renew Time: 12/13/2016 14:58:04 (local)

Session Key Type: AES-256-CTS-HMAC-SHA1-96

#3> Client: glenk @ home.local

Server: ldap/EthicsGradient.home.local @ HOME.LOCAL

KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96

Ticket Flags 0x40a40000 -> forwardable renewable pre_authent ok_as_delegate

Start Time: 12/6/2016 14:58:06 (local)

End Time: 12/7/2016 0:58:04 (local)

Renew Time: 12/13/2016 14:58:04 (local)

Session Key Type: AES-256-CTS-HMAC-SHA1-96

#4> Client: glenk @ home.local

Server: LDAP/EthicsGradient.home.local/home.local @ HOME.LOCAL

KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96

Ticket Flags 0x40a40000 -> forwardable renewable pre_authent ok_as_delegate

Start Time: 12/6/2016 14:58:06 (local)

End Time: 12/7/2016 0:58:04 (local)

Renew Time: 12/13/2016 14:58:04 (local)

Session Key Type: AES-256-CTS-HMAC-SHA1-96

3.2 Configure client

Set up web-proxy in browser through the FortiGate. This can be achieved via a PAC file or direct browser configuration.

Some Firefox documentation indicates that it is necessary to make manual advanced configuration changes to allow Kerberos authentication work. However, builds 48 (and possibly much earlier) require no additional configuration beyond setting of the proxy server.

3.3 Open a connection to the Internet

  1. The client accesses the explicit proxy, but a HTTP 407 Proxy Authentication Required is returned.
  2. As “Negotiate” is set, the client has knowledge of the KRBTGT, it requests a ticket from the KDC with a krb-tgsreq This includes the REALM (HOME.LOCAL) in the reg-body section, and the provided instances SNAME and service (in this case, HTTP/artoo-deetoo.home.local).
  3. The KDC responds with a next KRB-TGS-REP.

This ticket is then available on the client.

In the example below, the ticket-granted-service has issued Ticket #2.

#2> Client: glenk @ home.local

Server: HTTP/artoo-deetoo.home.local @ HOME.LOCAL

KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)

Ticket Flags 0x40a00000 -> forwardable renewable pre_authent

Start Time: 12/6/2016 14:59:45 (local)

End Time: 12/7/2016 0:58:04 (local)

Renew Time: 12/13/2016 14:58:04 (local)

Session Key Type: RSADSI RC4-HMAC(NT)

  1. The conversation between the client and the proxy continues, as the client responds with the Kerberos ticket in the response.

The whole process takes less than a second to complete. The user should be visible as a FSSO logon in the Web UI.

Transparent web-proxy Kerberos authentication

Transparent web-proxy allows the FortiGate to process level 7 policy matching, even when the explicit web-proxy is not enabled on the client’s browser. The transparent web-proxy policy is set in proxy-policy too. The policy matching rule is the same as the explicit web-proxy.

In the firewall policy level, transparent web-proxy is regarded as a special UTM. The HTTP/HTTPS traffic matches the firewall policy first, then traffic is redirected to the web-proxy daemon. If the transparent web-proxy feature is disabled, http-policy options in profile-protocol-options is used to enable transparent web-proxy feature.

IP-based

Kerberos authentication requires the captive portal to be an FQDN address that is resolved to a local IP address. However, it becomes more complicated to setup an FQDN address in a local user deployment. Therefore you can set the captive-portal-type to either use an FQDN or IP address.

  1. Captive portal and the captive portal port must be configured in transparent web-proxy for support of Kerberos authentication:

config authentication setting set captive-portal-type {fqdn | ip} set captive-portal <fqdn-name> / <ip> set captive-portal-port “9998”

end

  1. Authentication rule, scheme, and krb-keytab need to be configured for Kerberos authentication (note the active-auth-method scheme referenced in the rule):

config authentication scheme edit <kerberos-scheme> set method negotiate set negotiate-ntlm <enable> set fsso-guest <disable>

next

end

config authentication rule edit <name> set status <enable> set protocol <http> set srcadrr “all” set ip-based <enable>

set active-auth-method <kerberos-scheme>

next

end

config user krb-keytab edit <name> set principal “HTTP/TESTFGT.TEST.COM@TEST.COM” set ldap-server “ldap

set keytab <base64-encoding-keytab-data>

next

end

  1. Configure LDAP and user group used for authorization:

config user ldap edit “ldap” set server “10.10.1.1” set cnid srt dn set type <regular>

set username “CN=admin,CN=Users,DC=test,DC=com”

set password ENC aW5lIAHkPMf4D+ZCKpGMU3x8Fpq0G+7uIbAvpblbXFA5vLfgb4/oRBx+B6R/v+CMCetP84e+Gdz5zEcM yOd3cjoBoIhFrpYJfXhRs4lSEOHezeVXfxwTSf5VJG+F11G/G5RpaY+AE8bortC8MBe7P2/uGQocFHu4

Ilulp5I6OJvyk6Ei3hDZMjTd8iPp5IkRJZVVjQ== next

end

config user group edit “testgrp” set memeber “ldap” config match

edit “1”

set server-name “ldap

set group-name “CN=Domain Users,CN=Users,DC=TEST,DC=com”

next

end

next

end

  1. Create proxy-policy, with groups as the authorizing policy-matching element:

config firewall proxy-policy

edit 1

set uuid 1bbb891a-9cd2-51e7-42ff-d1fa13cac3da set proxy explicit-web set dstintf “any” set srcaddr “all” set dstaddr “all” set service “webproxy” set action accept set schedule “always” set groups testgrp

next

end

  1. UTM must be enabled in the firewall policy to support the transparent web-proxy:

config firewall policy edit “1”

set name “policy1”

set uuid 8a6ceeac-b016-51e6-2b5c-165070d5bf50

set srcintf “mgmt1” set dstintf “mgmt1” set srcaddr “all” set dstaddr “all” set action <accept> set schedule “always” set service “ALL” set utm-status <enable>

set profile-protocol-options “transparent-web-proxy” set ssl-ssh-profile “deep-inspection”

set nat <enable>

next

end

config firewall profile-protocol-options

edit “transparent-web-proxy”

config http

set ports “80 8080” unset options set http-policy enable unset post-lang end …

next end

Session-based with web-auth cookie

The web-auth-cookie feature is necessary for session-based authentication under transparent web-proxy.

The configuration is the same as for IP-based authentication, except ip-based is disabled in the authentication rule:

config authentication rule edit “kerberos-rules” set status <enable> set protocol <http> set srcadrr “all” set ip-based <disable>

set active-auth-method <kerberos-scheme>

next

config authentication setting set captive-portal <fqdn-name> set captive-portal-port “9998”

end

HTTP tunnel authentication

You can trigger user authentication on HTTP CONNECT request at the policy level. A new CLI entry has been added under config firewall proxy-policy which will trigger the authentication process get-user, even when there is no user or group configured.

Note that, as shown below, explicit web proxy must be set.

Syntax

config firewall proxy-policy edit {policyid} set proxy explicit-web

set http-tunnel-auth {enable | disable}

next

end

Certificate authentication

You can configure certificate-based authentication for FortiGate administrators, SSL VPN users, and IPsec VPN users.

Certificates are also inherent to the HTTPS protocol, where the browser validates the server’s identity using certificates. A site certificate must be installed on the FortiGate unit and the corresponding Certificate Authority (CA) certificate installed in the web browser.

To force the use of HTTPS, go to User & Device > Authentication Settings and select Redirect HTTP Challenge to a Secure Channel (HTTPS).

Restricting number of concurrent user logins

Some users on your network may often have multiple account sessions open at one time either to the same network resource or accessing to the admin interface on the FortiGate unit.

While there are valid reasons for having multiple concurrent sessions open, hackers also do this to speed up their malicious work. Often a hacker is making multiple attempts to gain access to the internal network or the admin interface of the FortiGate unit, usually from different IP addresses to appear to the FortiGate unit as legitimate users. For this reason, the more concurrent sessions a hacker has open at once, the faster they will achieve their goal.

To help prevent this, you can disallow concurrent administrative access using the same administrator user name. This allows only one session with the same username even if it is from the same IP.

To disable concurrent administrator sessions – CLI:

config system global set admin-concurrent disable

end


Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

Authentication in captive portals

Authentication in captive portals

Network interfaces, including WiFi interfaces, can perform authentication at the interface level using a captive portal — an HTML form that requests the user’s name and password. A captive portal is useful where all users connecting to the network interface must authenticate. Optionally, on a WiFi interface, the captive portal can be combined with a terms of service disclaimer to which the user must agree before gaining access.

Once successfully authenticated, the user’s session passes to the firewall.


Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!