FortiGate LDAPS Authentication Failure

Posted on 29/01/2021 by PeteLong

KB ID 0001733

Problem

Here’s a brief one that tripped me up a couple of weeks ago, I was deploying FortiGate LDAPS authentication for some FortiClient SSL VPN connections into a FortiGate firewall like so;

Despite my best efforts I was getting authentication failures? If I tested the username and password in the GUI web management portal, that worked fine?

Testing FortiGate LDAPS

First step is to test authentication at command line, like so;

[box]

Forti-FW # diag test auth ldap My-DC test.user Password123
authenticate 'test.user' against 'My-DC' failed!

[/box]

Note: My-DC is the domain controller, test, user is the username, and Password123 is the password for my AD user. (The fact I need to explain that is depressing, but c’est la vie).

So despite what the GUI is telling me, authentication is actually failing, remember I’m using LDAPS, so the FortiGate needs to have the CA certificate, (that issued the Kerberos certificates on my domain controller(s)), in its trusted CA list! And TCP port 636 needs to be open between the firewall and the domain controllers.

Debugging FortiGate LDAPS

So now we need to debug what’s going on;

[box]

Forti-FW # diagnose debug enable
Forti-FW # diagnose debug application fnbamd 255
Debug messages will be on for 30 minutes.

[/box]

Then simply attempt to authenticate via FortiClient, or recall the ‘diag test’ command from above.

[box]

Forti-FW # diag test auth ldap My-DC test.user Password123
[1932] handle_req-Rcvd auth req 1296531457 for test.user in My-DC opt=0000001b prot=0
[424] __compose_group_list_from_req-Group 'My-DC', type 1
[617] fnbamd_pop3_start-test.user
[970] __fnbamd_cfg_get_ldap_list_by_server-
[976] __fnbamd_cfg_get_ldap_list_by_server-Loaded LDAP server 'My-DC'
[1131] fnbamd_cfg_get_ldap_list-Total ldap servers to try: 1
[1713] fnbamd_ldap_init-search filter is: sAMAccountName=test.user
[1722] fnbamd_ldap_init-search base is: dc=testbench,dc=co,dc=uk
[1146] __fnbamd_ldap_dns_cb-Resolved My-DC:192.168.1.122 to 192.168.1.122, cur stack size:1
[919] __fnbamd_ldap_get_next_addr-
[1152] __fnbamd_ldap_dns_cb-Connection starts My-DC:192.168.1.122, addr 192.168.1.122 over SSL
[874] __fnbamd_ldap_start_conn-Still connecting 192.168.1.122.
[591] create_auth_session-Total 1 server(s) to try
[1097] __ldap_connect-tcps_connect(192.168.1.122) failed: ssl_connect() failed: 337047686 (error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed).
[930] __ldap_error-My-DC:192.168.1.122, addr 192.168.1.122
[725] __ldap_stop-Conn with 192.168.1.122 destroyed.
[919] __fnbamd_ldap_get_next_addr-
[902] __ldap_try_next_server-No more server to try for 'My-DC'.
[785] __ldap_done-svr 'My-DC'
[755] __ldap_destroy-
[2870] fnbamd_ldap_result-Error (3) for req 1296531457
[217] fnbamd_comm_send_result-Sending result 3 (nid 0) for req 1296531457, len=2044
authenticate 'test.user' against 'My-DC' failed!
Forti-FW # [747] destroy_auth_session-delete session 1296531457
[755] __ldap_destroy-
[1764] fnbamd_ldap_auth_ctx_free-Freeing 'My-DC' ctx
[2099] fnbamd_ldap_free-Freeing 'My-DC'

[/box]

OK so it’s SSL related? For SSL to work you need the following;

To trust the CA that issued the certificate
To be able to resolve (via DNS) the common name (or Subject Alternative Name) on the certificate
If you’ve specified the LDAP server by IP address the IP address of the server needs to be on the certificate as a Subject Alternative Name (SAN).
Your firewall and the AD/LDAP server need to have compatible SSL ciphers.

So I had number 1 covered, and the chance of it being number 4 are rare, (server and firewall are fully updated).

So my problem was initially number 2 I’d specified the LDAPS server via its internal IP. I needed to use its FQDN, then of course the firewall needed to be able to resolve that IP with a DNS lookup (try execute ping server-name.doman-name if you’re unsure!)

[box]

Forti-FW # execute ping win-server.testbench.co.uk
Unable to resolve hostname.  <---OOPS THAT'S NOT GOOD!

Forti-FW # execute ping 192.168.1.122 <---CONNECTIVITY IS OK!
PING 192.168.1.122 (192.168.1.122): 56 data bytes
64 bytes from 192.168.1.122: icmp_seq=0 ttl=128 time=5.4 ms
64 bytes from 192.168.1.122: icmp_seq=1 ttl=128 time=2.0 ms
64 bytes from 192.168.1.122: icmp_seq=2 ttl=128 time=1.9 ms
^C
--- 192.168.1.122 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 1.9/3.1/5.4 ms

[/box]

Once DNS was setup correctly;

[box]

Forti-FW # execute ping win-server.testbench.co.uk
PING win-server.testbench.co.uk (192.168.1.122): 56 data bytes
64 bytes from 192.168.1.122: icmp_seq=0 ttl=128 time=1.9 ms
64 bytes from 192.168.1.122: icmp_seq=1 ttl=128 time=2.3 ms
64 bytes from 192.168.1.122: icmp_seq=2 ttl=128 time=2.1 ms
^C
--- win-server.testbench.co.uk ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss <---BOOM THAT'S BETTER
round-trip min/avg/max = 1.9/2.1/2.3 ms

[/box]

Then retest.

[box]

Forti-FW # diag test auth ldap My-DC test.user Password123
authenticate 'test.user' against 'My-DC' succeeded!
Group membership(s) - CN=GS-VPN-Users,OU=Securty-Groups,DC=testbench,DC=co,DC=uk
                      CN=Domain Users,CN=Users,DC=testbench,DC=co,DC=uk

[/box]

Windows File Server Migration (Maintain Share & NTFS Permissions)

Posted on 27/01/2021 by PeteLong

KB ID 0001201

Problem

When attempting a File Server Migration why isn’t this better publicised? Did you know Microsoft have a set of Migration tools, and one of them is for file servers? Now traditionally I’d use RoboCopy or XCopy to migrate files and folders, and for ‘User Profiles’ I would normally back them up, and restore them to the new server. This is because the file permissions on ‘correctly deployed’ user profiles mean you can’t open them.

How about a tool, that migrates all the files, folders and profiles while maintaining all the NTFS permissions, AND Share permissions!

Windows File Server Migration Tools

Source Server Pre-requisites

Server 2003: .Net 2.0 (With SP1), and PowerShell 2.0, and 25MB free drive space.
Server 2008: PowerShell and 25Mb free drive space.
Server 2008 R2 and Newer: 25Mb free drive space.
All: UDP port 7000 needs to be open, from source to the destination server.

File Server Migration Server 2008 to Server 2019

File Server Migration from Server 2003!

Source Server: Windows Server 2003 Standard x64 (x86 supported as well)
Destination Server: Windows 2012 R2 Data Center 2012

Source Server: Here you can see my user profiles, I’ll do the migration with them, as usually they are the most ‘challenging’.

You need to create a shared folder on the Source Server, I’ve just granted everyone full control, (this is just for the migration tools).

Destination Server: Open a PowerShell windows and install the tools with the following command;

[box]

Install-WindowsFeature Migration –ComputerName {computer-name}

[/box]

Open an administrative command window > Now you need to deploy the migrations tools to the share on the destination server, to do that use the following command;

[box]

cd C:\Windows\System32\ServerMigrationTools

SmigDeploy.exe /package /architecture amd64 /os WS03 /path \\{Destination-Server}\{folder-name}

[/box]

Note: For x86 (32 bit) source servers use x86 instead of amd64. WS03 (Windows Server 2003), WS08 (Windows Server 2008), WS08R2 (Windows Server 2008 R2), and WS12 (Windows Server 2012).

Source Server: Open the folder you created earlier and within it you will find another folder that has the tools in. Open an administrative command window and change to this directory > then execute the following command;

[box]

.\smigdeploy

[/box]

Another PowerShell window will open, leave it open, and return to the destination server.

Destination Server: Here I’ve created a folder that I’m going to migrate into.

Destination Server: Open a PowerShell window and issue the following two commands;

[box]

add-pssnapin microsoft.windows.servermanager.migration

Receive-SmigServerData

[/box]

You will be asked to provide a password, (use what you want, but remember it, you will need it in a minute).

You now have a five minute window to get the migration running, or you will need to re-issie the last command again.

Source Server: Return to your open PowerShell Window, and issue the following command;

[box]

Send-SmigServerData -ComputerName {destination-computer-name} -SourcePath {path-to-source-folder} -DestinationPath {path-to-destination-folder} -include all -recurse

[/box]

Supply the password, then go and put your feet up.

Destination Server: You can watch progress here.

Profiles migrated! And permissions intact.

Don’t forget to change the path to the user profile, on the user(s) user object(s) in Active Directory.

If you have a lot you can do them in bulk by multi-selecting the users.

Domain Join SID Error

Posted on 26/01/2021 by PeteLong

KB ID 0001732

Problem

Thankfully I don’t see a SID error very often these days;

The following error occurred when attempting to join the domain ‘{domain-name}

The domain join cannot be completed because the SID of the domain you attempted to join was identical to the SID of this machine. This is a symptom of an improperly cloned operating system install. You should run Sysprep on this machine in order to generate a new machine SID.

Resolve SID Errors (Joining Domains)

In my case it was a server I was deploying into EVE-NG and I hadn’t ran says-rep on the image, (typically I only need one Windows server in my EVE-NG labs, but this time I needed another), so then I added a second and tried to add it to a domain, this happened. I should know better really!

If you have ever deployed or imaged Windows you can probably guess what the fix is, ‘Run Sysprep‘.

Note: I will probably get emails saying ‘Why not just run NewSID?’, well because it’s not officially supported any more, and sysprep is.

Navigate to C:\Windows\System32\Sysprep and run sysprep.exe > Tick the ‘Generalize’ option > Set the Shutdown option to ‘Reboot” > OK.

Go and have a coffee, when the server reboots, run though the OOBE setup, and try to join the domain again.

Migrate From Server 2012 to Server 2019 Domain Controllers

Posted on 25/01/2021 by PeteLong

Server 2012 DC to Server 2019 DC KB ID 0001731

Problem

I get asked about this quite a lot. In the past most of the queries were about moving from Server 2008 to Server 2019, if that’s what you are after then simply go here. This article is purely for the introduction of, and migration to Windows Server 2019 Domain Controllers. And it assumes your current domain controllers are Windows server 2012 (or 2012 R2).

Adding a Server 2019 Domain Controller

Once you have a Windows Server 2019 box stood up and fully updated, ensure it is added to the domain as a member server. Then from Server Manager > Manage > Add roles and features.

Next > Next > Next Next > Select “Active Directory Domain Services” > When prompted select ‘yes‘ to add the required services.

Next > Next > Next > Install > Close.

Click the ‘Warning Triangle‘ > Promote this server to a domain controller.

Next.

Enter the DSRM Password > Next.

That’s fine (if you’re worried see the link below) >Next.

Windows – A Delegation For This DNS Server Cannot Be Created

Next.

I’m accepting the default AD install locations > Next.

Next (forestprep and domainprep is all done for you now).

Next.

Install.

When complete the server will reboot.

View Server 2019 Domain Controller

You should now see the new domain controller listed in Active Directory

At this point I’m moving all the FSMO roles to the new Windows 2019 server.

Windows Server – Locating, Transferring, and Seizing FSMO Roles

Demoting the 2012 Domain Controller(s)

WARNING: Before proceeding, make sure anything on your network that may be using this server for DNS has been pointed to your new domain controllers. Don’t forget to change the DNS servers that are being distributed via DHCP, (update your DHCP scopes). And change your new domain controllers to look at themselves for DNS not the domain controller(s) you are about to demote!

Over on your 2012 domain controller > Server manager > Manage > Remove roles and features.

Next > Untick ‘Active Directory Domain Services’ > Demote this domain controller > Next.

Tick ‘Proceed with removal‘ > Next.

Untick ‘Remove DNS delegation’ > Next.

Set a new local administrator password for this server to use after it has been demoted (as it will be a member server at that point). You can of course still log into it as the domain admin. > Next > Demote.

When complete, the server will reboot.

You can now (if you wish raise your domain functional level). Note: Check you meet all the prerequisites for doing so, personally I rarely update them until I have a specific need to do so.

Once you are confident all your domain controllers in the domain have replicated, you can then update the forest functional level if you wish to do so.

FortiGate High Availability (Active / Passive)

Posted on 22/01/2021 by PeteLong

KB ID 0001730

So my aim was to setup FortiGate High Availability failover in Active / Passive mode. I’m setting this up in EVE-NG and here’s what my lab looks like;

Note: Im using TWO connections for Heartbeat/Failover, you can simply use one if you prefer.

FortiGate High Availability (Pre-Requisites)

Obviously the firewalls need to be the same! For physical firewalls that’s straightforward, but be careful if you are using virtual FortiGates, make sure they are the same hardware and licence versions!

As you can see in my topology (above), each port needs to be connected to the same network on BOTH firewalls.

Make sure both firewalls are running the SAME firmware.

Make sure the interfaces are not getting their IP addresses from DHCP, or PPPoE.

I’m assuming the primary firewall is all setup and configured properly, the secondary firewall then needs to be built, licensed, and internet connected (so it can update etc). Note: It will take it’s config from the primary firewall when configured.

FortiGate High Availability (Active Passive) From Command Line

I know, Fortinet like to say that there’s no need to be working at command line these days, but when you see how easy it is to setup from CLI, you might choose to do it that way instead.

Primary FortiGate High Availability Setup

FortiGate uses priority to set the primary firewall, by default it sets the value to 128. So I’m going to set my Primary firewall to 200 and my Secondary firewall to 100.

Here are the commands you can simply copy and paste;

[box]

config system ha
set group-id 10
set group-name HA-GROUP
set mode a-p
set password Password123
set hbdev port3 0 port4 0
set session-pickup enable
set override enable
set override-wait-time 10
set priority 200
end

[/box]

What does all that mean? The Group ID and Group Name, are shared by all firewalls in the cluster. (Yes cluster, you can scale this up to more firewalls). Mode simply sets the mode to a-p (active passive). Hbdev denotes the interfaces used for the heartbeat network, (the zeros denote that they will be used equally). Session-pickup allows the firewalls to share the session state table for your clients, (i.e. provides seamless TCP session failover). Override is enabled, this will fail back the the primary firewall when it becomes available. Note: wait-time is enabled and set to 10 seconds to avoid any ‘flap / stutter’ that may cause disconnections when executing the override. Then finally the priority is set to 200.

Secondary FortiGate Hight Availability Setup

Practically the same, but you don’t need to set override, and the priority will be lower (100).

[box]

config system ha
set group-id 10
set group-name HA-GROUP
set mode a-p
set password Password123
set hbdev port3 0 port4 0
set session-pickup enable
set priority 100
end

[/box]

FortiGate HA Monitor and TroubleShooting

At this point go and have a coffee, the config needs replicating from the primary to the secondary, and this can take a few minutes. Use the following command to check;

[box]

get system ha status

[/box]

You want to see them both ‘in-sync‘.

To troubleshoot, use;

[box]

diagnose system ha status

[/box]

FortiGate Failover (Active Passive) From GUI

On the Primary (pre configured) firewall, System > HA > Change the drop down to Active-Passive.

Device Priority: 200
Group name: HA-GROUP {or something sensible}.
Password: {needs to match on both firewalls}.
Sesión pickup: Enabled {replicates client session data}.
Monitor Interfaces: {you can leave this blank, unless you only want to monitor certain interfaces}.
Heartbeat Interfaces: {enter one or more interfaces}.

What’s Management interface Reservation? : You can use this to have separate management for each firewall, (usually you can’t get to the standby/secondary firewall for GUI/SSH management etc).

Clock OK when complete

You should see something like this;

Jump onto the Secondary firewall, and set it the same, (with the exception of the priority).

Note: Override (Fail Back) cannot currently be set in the GUI.

Wait a while and hit refresh, you should see both firewalls in Sync

Possible Bug in 6.4.4 build 1803 (GA)

When carrying out the above procedure (from the web management console), my firewalls did not sync, while trouble shooting at command line they were both set as primary and appeared not to be able to see the other, they were saying;

{Firewall Serial Number}is selected as the master because it’s the only member in the cluster.

Despite many hours of troubleshooting/rebuilding, this kept happening, it worked fine when configured from command line, but not from the GUI. When I checked the commands after using the GUI I noticed that “set group-id {number}” was missing from the config. If I added this manually it started syncing straight away?

FortiGate: SSL Inspection (HTTPS Inspection)

Posted on 15/01/2021 by PeteLong

KB ID 0001729

Problem

Do you inspect the traffic on your network? You have a firewall? Maybe an IDS appliance? That’s good news, do you inspect HTTPS traffic? In most cases the answer is no. Because either you do not have the capability, or enabling SSL Inspection will degrade the firewall’s performance so much that you accept the risk.

At time of writing (Early 2021) it’s estimated that 85% of all web traffic is now encrypted. Let that sink in, 85% of the web traffic traversing your firewalls and security appliances is potentially not even getting looked at, because it’s encrypted.

Probably over ten years ago I was at a security convention, and the speaker asked the crowd “What’s TCP Port 443?”, This prompted the obvious answer of “It’s HTTPS!” No, its the universal hacking and exploitation port!

Do something ‘Nefarious‘ and it’s best to do it over HTTPS, (or protect it with SSL encryption.) The last time I was asked to look at inspecting HTTPS traffic, it had such an adverse affect on the firewalls performance, the client looked at extra hardware (SourceFire at the time,) to do this instead of the firewalls, and the firewalls in question were a pair of ASA-5585 SSP40’s (that’s a 6 FIGURE price tag!).

When I saw the comparison of degradation between firewall vendors I was somewhat skeptical, but Fortinet do make some bold claims. Typically their marketing and sales ‘Battlecards’ show about 15% degradation with SSL inspection enabled, (that’s on a 500E) and that is typically compared to 73% degradation on a Cisco Firepower (4000 series), or 79% on a Palo Alto (5220), or 79% on a Check Point (15600). Note: I’ve not checked these figures.

So how easy is it to setup? Well to be honest it’s painfully simple, just bear in mind on a FortiGate there’s two ‘Types’ of SSL Inspection;

SSL Certificate Inspection: The FortiGate Checks the certificates presented to ensure the common name is correct, (resolvable) and checks it against a database of problem URLs and certificates.
SSL Full Inspection (Deep Packet Inspection): The Fortigate ‘Brokers the SSL traffic’ and sits in the middle, it decrypts and re-enrypts the traffic before sending it onto the end user, or the remote server. To do this it needs to be able to generate and sign certificates for any domain, and you need to trust it to do so.

If you are already running a FortiGate, you probably already have SSL certificate inspection enabled on your default internet access policy and didn’t even realise it! Below we will look at deep packet inspection.

FortiGate SSL Inspection (Simply)

WARNING: Read the whole article first, simply turning this on without some forethought and planning (in production) will result in bad things happening! Remember your clients’ have to trust the Firewall and at the moment they probably do not!

The FortiGare has its own built in Certification Authority, initially I’ll use that (below I’ll demonstrate how I would do this with a ‘proper’ domain PKI deployment). From the firewalls management page System > Certificates > Locate the Fortigate_CA_SSL certificate and download it.

Put that certificate on one of your client machines and then import/trust it. Below I’m making things as difficult as possible, and using Kali Linux, on a Windows box, double click the cert import it, and manually place it into ‘Trusted Root Authorities’ store.

Note: If you use Firefox as a browser, you will need to take extra steps see this article.

Now on the ‘Policy’ that’s being applied to your web traffic, we need to alter the SSL inspection. Policy & Options > Firewall Policy (or IPv4 Policy on older models) > Locate your policy for normal web traffic and edit it.

Change SSL Inspection to ‘deep-inspection’ > OK

Note: In the example shown below, I have AntiVirus inspection enabled, I mention this because that’s what I will use to test that SSL inspection is working.

So now when my clients go to any https:// website, the certificate that the client sees, is actually signed by the firewall NOT a publicly signed certificate vendor.

To ‘Test’ that you can go to the Eicar website (if you didn’t know Eicar produce files for testing AntiVirus and AntiMalware solutions) and attempt to download one of the files (Note: MAKLE SURE you attempt to download from the HTTPS section!)

What Next?

Well that was easy! Now for a real world deployment. Your problem is getting your client to trust the firewalls CA Signing certificate. You have THREE OPTIONS

Option 1: Manually install the certificate on your clients, if you have a small organisation then that might be a good option, the built in cert lasts ten years, you will probably have a new firewall before that certificate expires.

Option 2: Distribute the FortiGates CA signing certificate by Group Policy. For medium sized deployments, of if you are one of those that’s typically terrified of certificates, this might be your option.

Option 3: You have a properly deployed Certificate Services PKI deployment already, you can issue a SubCA certificate to the firewall to do the signing with, and your domain clients will trust it automatically.

I wont insult your intelligence explaining Option 1, but Options 2 and 3 I will outline below.

Deploying FortiGate CA Signing Certificate By Group Policy

On the Fortigate you need to download a copy of the CA certificate it uses, typically it is called Fortigate_CA_SSL. From the management GUI > System > Certificates > Select Fortigate_CA_SSL > Download > Save a copy somewhere you can get to it.

On a domain controller > Administrative tools >Group Policyy Management > Create a new policy (or you can edit an existing one.) Below I’m linking mine to the root of my domain, you may want to link yours to the OUs that your computer objets are in.

Edit the new policy and navigate to;

[box]

Computer Configuration > Policies > Windows Settings > Security Settings >Public Key Policies > Trusted Root Certification Authorities

[/box]

Right click > Import.

Follow the wizard, navigate to and select the certificate from the FortiGate > Make sure that it gets put in the Trusted Root Certification Authority store!

Close the policy editor, then wait a couple of hours or Force a Domain Policy Refre sh.

Replace FortiGate SSL Inspection CA Cert with a Microsoft Certificate Services SubCA Cert

This would be my preferred choice, if you have a proper PKI deployment in your domain your client will already trust it, so all you have to do is use a SubCA cert to the firewall. If you don’t have a PKI deployment yet, but this is the correct route to take run though the following first to get up and running;

Microsoft PKI Planning and Deploying Certificate Services

Even with your own Microsoft Certificate Services deployment, it’s just worth a quick check that you already have a template for ‘Subordinate Certification Authority‘. (it’s typically deployed by default).

I’m going to apply for my certificate using the ‘Certificate Authority Web Enrollment Role’ (this is an additional role you can add to Certificate Services to give you this nice web portal for getting certificates). Web browse to https://(FQDN-of-Certificate-Server}/Certsrv (Note: yours may be on http://) > Request a Certificate > Advanced Certificate Request > Create and Submit a Request to this CA.

Template: Subordinate Certification Authority
Name: The FQDN of the firewall (must be resolvable in DNS!)
Email to Country/Region: Fill out as applicable
Key Size: 2048
Mark keys as exportable: Ticked

Submit.

Install this certificate.

Use MMC to Inspect User Certificates

This will have dropped the certificate in YOUR user certificate container, we now need to locate and export it.

Windows Key +R > mmc.exe > File > Add/Remove Snap-in > Certificates > Add > Select User Account.

Expand Certificates – Current User > Personal > Certificates > Locate the certificate > All Tasks > Export.

Next > Yes: Export the private key > Next > Personal Information Exchange (PFX) > Next > Password (Type and confirm password you will remember) > Change the encryption to AES256–SHA256 > Next > Select a location to save the certificate > Next > Finish.

Back at the FortiGate > System >Certificates > Import Local Certificate.

Type: PKCS # 12 > Upload > Locate and select the certificate you exported above > Enter The password > Upload > OK.

FortiGate: Create SSL Inspection Profile

Security Profiles > SSL/SSH Inspection > Create New.

Give the policy a sensible name > Change the CA Certificate to the one you just uploaded > OK.

To use that Profile in your web access policy, Policy & Objects > Firewall Policy > Locate the policy that defines web traffic and edit it.

Change the SSL Inspection to use your new profile > OK.

Now you can test the deployment by going to an https secure website (like this one!) and taking a look at the certificate, it should have been issued by your SubCA/Firewall.

The Web Site for the CA Must be Configured to use HTTPS

Posted on 13/01/2021 by Migrated

KB ID 0000838

Problem

When attempting to contact a server running the Certification Authority Web Enrolment role, you may see the following error.

In order to complete certificate enrolment, the Web site for the CA must be configured to use HTTPS authentication

Solution

The correct fix is to set the web server (IIS) to serve the certificate website securely using https, though you can just set Internet explorer to ‘work’ from your client machine if you are in a hurry.

Make Internet Explorer Accept Your Certification Authority

Note: This would need to be done on every machine that you wanted to access the Certificate Services web portal from.

1. From within Internet Explorer > Internet Options > Security > Trusted Sites > Sites.

2. Untick ‘Require server verification (https:) for all sites in this zone’ > Then add in the URL of the CA > Close.

3. With Trusted sites still selected > Custom level > ‘Initialize and script ActiveX controls not marked as safe for scripting’ > Enable > OK > Yes.

4. Restart the browser and try again.

Set IIS to serve Certificate Services Securely (via https).

This assumes you have your CA and the web portal installed correctly.

1. On the Certificate Services Server > Launch IIS Manager > Expand {server-name} > Sites > Default Web Site > Right Click > Edit Bindings > https > Edit > Select the self signed server certificate [NOT the CA ONE] > OK.

Note: If https is missing simply add it!

2. Expand Default Web Site > Certsrv > SSL Settings.

3. Tick ‘Require SSL’ > Apply.

4. That should be all you need, if it does not take effect straight away then drop to command line and run iisreset /noforce.

EVE-NG: Create Windows Server 2019 VM

Posted on 13/01/2021 by PeteLong

KB ID Article

Problem

I’ve had a Windows 2012R2 server image that I’ve ben using in EVE-NG for ever. This week it bit the dust so I thought, can I deploy a shiny new 2019 server?

EVE-NG Windows Virtual Machines

Yes! In fact the deployment procedure is the same for 2019 as it was for earlier versions of Windows server. First log onto your EVE-NG host and create the folder;

[box]

mkdir /opt/unetlab/addons/qemu/winserver-2019/

[/box]

Then ‘upload’ a copy of the Windows Server 2019 installation iso into that folder with WinSCP or FileZilla.

Now rename the ISO image file to cdrom.iso, then create a new, (empty) hard drive file, that we will install windows onto. (Note: below I’m setting it to 60GB in size).

[box]

mv en_windows_server_2019_updated_nov_2020_x64_dvd_860005f.iso cdrom.iso
/opt/qemu/bin/qemu-img create -f qcow2 virtioa.qcow2 60G

[/box]

In EVE-NG create a new Lab and add in your Windows 2019 Server, then power it on.

It wont find the hard drive, because it has not got the controller driver, click ‘Load Driver‘.

Navigate to B:\Storage\2003R2\amd64 OK > Next > It will detect and load the ‘Red Hat Virtio‘ driver and install Windows. Once done shut the Windows server down.

WARNING: If you intend to deploy ‘multiple’ Server OS’s into single EVE-NG Labs, then run ‘Sysprep‘ on the server image select ‘Generalize’ and Shutdown THEN commit the image, once it’s shut down.

Now you need to ‘commit’ that image (so all new VMs will be created form that image). Ive written about this before, see the following link;

EVE-NG: Committing / Saving Qemu Virtual Machine Settings

But essentially get the ‘Pod Number’ from user management, and the Lab ID from Lab details.

Get the Node ID from the virtual machine, and execute the following command;

[box]

cd /opt/unetlab/tmp/POD-Number/Lab-ID/Node-Number/
e.g.
cd /opt/unetlab/tmp/1/b56699c-31b5-4399-af2e-697eab12981d/2/

[/box]

Lastly, don’t forget to tidy up and delete the ISO image now you no longer need it.

[box]

cd /opt/unetlab/addons/qemu/winserver-2019
rm -f cdrom.iso

[/box]

Software is Preventing Firefox From Safely Connecting to this Site

Posted on 12/01/2021 by PeteLong

KB ID 0001727

Problem

I was setting up some HTTPS/SSL inspection this week and while testing it, I ran into this problem;

Firefox Certificate Settings

So the machine I’m using DOES trust the CA that issued that certificate, (it’s a FortiGate firewall) But the BROWSER does not. (Firefox maintains its own list of certificates, and more importantly which CA certificates it will trust). Essentially the browser is trying to protect you from a MITM attack.

Browse to about:prefernces#privacy > Certificates > View Certificates.

Import.

Navigate to the CA certificate for the authority that signed the certificate(s) you are having a problem with, and import it > Select ‘Trust this CA to identify websites” > OK

FortiGate: SSL-VPN With FortiClient (AD Authenticated)

Posted on 06/01/2021 by PeteLong

KB ID 0001725

Problem

FortiGate Remote Access (SSL–VPN ) is a solution that is a lot easier to setup than on other firewall competitors. Here’s how to setup remote access to a FortiGate firewall device, using the FortiClient software, and Active Directory authentication. This is what my topology looks like;

Note: I’ve changed the FortiGates default management HTTPS port from 443 to 4433 (before I started). This was to let me use the proper HTTPS port of 443 for remote access SSL VPN. I suggest you also do this, as running SSL-VPN over an ‘odd’ port may not work from some locations. See the following article;

FortiGate: Change the HTTPS Management Port

Certificate: I’m also using a self signed certificate on the FortiGate, in a production environment you may want to purchase a publicly signed one!

Step 1: FortiGate LDAPS Prerequisites

Before we start, we need to make sure your firewall can resolve internal DNS. (Because the Kerberos Certificate name on your Domain Controller(s) gets checked, when doing LDAPS queries, if you DON’T want to do this then disable server identity check when you setup your LDAP server below). Or you can add the IP address to the servers Kerberos certificate as a ‘Subject Alternative Name‘ but thats a bit bobbins IMHO

Network > DNS > Specify > Add in your ‘Internal” DNS servers > Apply.

Certificate Prerequisites

To perform LDAPS the FortiGate needs to trust the certificate(s) that our domain controller(s) use. To enable that you need a copy of the CA Certificate, for the CA that issued them. At this point if you’re confused, you might want to run through the following article;

Get Ready for LDAPS Channel Binding

So to get a copy of your CA cert on a Windows CA server use the following command;

[box]

certutil -ca.cert My-Root-CA-Cert.cer

[/box]

To ‘Import‘ the certificate into the Fortigate > System > Certificates > Import > CA Certificate.

File > Upload > Browse to your CA Certificate > Open > OK.

Take note of the certificate name, (CA_Cert_1 in the example below,) you will need this information below.

Step 2: Allow FortiGate LDAPS Authentication (Active Directory)

User & Authentication > LDAP Servers > Add.

Name: Something Sensible!
Server IP/Name: Use the FQDN of the server (or you need to put the IP on the Kerberos certificate as a SAN!)
ServerPort: 636 (We’re not using 389 LDAP is NOT secure!)
Common Name Identifier: sAMAccountName
Distinguished Name: Enter the DN for either the top level of your domain or an OU that’s got all your users/groups in.
Bind Type: Regular.
Username: in DOMAIN\username format Note: A normal domain user account is sufficient it DOES NOT need to be a domain administrator.
Password: For the above user.
Secure Connection: LDAPS.
Certificate: Select YOUR CA Certificate.
Server Identity Check: Enabled.

Click ‘Test Connectivity‘ It should say successful, then you can check some other domain user credentials as a test > OK.

Domain / Active Directory Setup

Over in my Active Directory I’ve created a security group called GS-VPN-Users, and put my user object into it.

Now I need to create a FIREWALL GROUP and add my ACTIVE DIRECTORY GROUP to that. User & Authentication > User Groups > Create New.

Name: Something sensible!
Type: Firewall

Remote Groups > Add.

Change the Remote Server drop down list to be your LDAPS Server > Browse to your ACTIVE DIRECTORY GROUP, right click and Add Selected (Cheers, that took me three goes to find FortiNet!) > OK.

All being well you should see your LDAPS server AND the distinguished name of your AD group, (check that’s not missing!) > OK.

Step 3: Setup FortiGate SSL-VPN

First we need an SSL Portal > VPN > SSL-VPN Portals > Create New.

Name: Something sensible!
Enable Split Tunnelling: Enabled. (If you don’t do this then remote clients need to come though the FortiGate for web access, I usually enable split tunnel).
Source IP Pools: Add Then Create.

Address.

Name: Something sensible!
Type: IP Range
IP Range: The subnet you want to use. (Note:If you are routing on your LAN, make sure there’s a route back to the FortiGate for this subnet or bad things will happen!)
Interface: SSL-VPN tunnel interface

OK.

Enter a portal message, (the header on the page once a remote user connects) > Enable FortiClient download > OK.

If you see the following error, that’s because on some smaller firewalls, (like the 40F) there can only be one, so you need to edit the one that is there by default.

Maximum number 0f entries has been reached.

FortiGate SSL-VPN Settings

VPN > SSL-VPN Settings > Listen on Interfaces.

Set to the outside (WAN) interface > Address Range > Specify custom IP Ranges > IP Ranges > Add in the pool you created above.

DNS Server > Specify > Add in your internal DNS servers > Authentication Portal Mapping > Create New.

Users/Groups: Your AD GROUP.
Portal: Your Portal

OK.

Apply (Note: If it complains ‘All Other User/Group‘ is not configured, set that to web-access (as shown).

FortiGate SSL-VPN Firewall Policy

Policy & Objects > Firewall Policy (or IPV4 Policy on older versions) > Create New.

Name: Something sensible.
Incoming Interface: SSL-VPN Tunnel Interface.
Outgoing Interface: Inside (LAN).
Source: Your remote IP Pool AND your FIREWALL GOUP.
Destination: Local LAN (remember if you want DMZ access, add that in also)
Schedule: Always
Action: Accept
NAT: Disabled

Generate logs when session starts: Enabled

OK.

Step 4: Test FortiGate SSL-VPN

From your remote client, browse to the public IP/FQDN of the firewall and log in, you should see the SSL-VPN portal you created, and have the option to download the FortiClient (VPN) software for your OS version.

Install the FortiClient (Note: This is only the VPN component not the full FortiClient).

Remote Access > Configure VPN.

VPN: SSL-VPN.
Connection Name: Something sensible.
Remote Gateway: IP or FQDN of the FortiGate.
Authentication: Prompt on Logon (unless you want it to remember).
Do not warn invalid Server Certificate: Enabled (Unless you are using a publicly signed certificate on your FortiGate).

Save.

Then test connection, make sure you can ping internal IP addresses and DNS names.

Problem

Testing FortiGate LDAPS

Debugging FortiGate LDAPS

Related Articles, References, Credits, or External Links

Problem

Windows File Server Migration Tools

Related Articles, References, Credits, or External Links

Problem

Resolve SID Errors (Joining Domains)

Related Articles, References, Credits, or External Links

Problem

Adding a Server 2019 Domain Controller

View Server 2019 Domain Controller

Demoting the 2012 Domain Controller(s)

Related Articles, References, Credits, or External Links

FortiGate High Availability (Pre-Requisites)

FortiGate High Availability (Active Passive) From Command Line

Primary FortiGate High Availability Setup

Secondary FortiGate Hight Availability Setup

FortiGate HA Monitor and TroubleShooting

FortiGate Failover (Active Passive) From GUI

Possible Bug in 6.4.4 build 1803 (GA)

Related Articles, References, Credits, or External Links

Problem

FortiGate SSL Inspection (Simply)

What Next?

Deploying FortiGate CA Signing Certificate By Group Policy

Replace FortiGate SSL Inspection CA Cert with a Microsoft Certificate Services SubCA Cert

Use MMC to Inspect User Certificates

FortiGate: Create SSL Inspection Profile

Related Articles, References, Credits, or External Links

Problem

Solution

Make Internet Explorer Accept Your Certification Authority

Set IIS to serve Certificate Services Securely (via https).

Related Articles, References, Credits, or External Links

Problem

EVE-NG Windows Virtual Machines

Related Articles, References, Credits, or External Links

Problem

Firefox Certificate Settings

Related Articles, References, Credits, or External Links

Problem

Step 1: FortiGate LDAPS Prerequisites

Certificate Prerequisites

Step 2: Allow FortiGate LDAPS Authentication (Active Directory)

Domain / Active Directory Setup

Step 3: Setup FortiGate SSL-VPN

FortiGate SSL-VPN Settings

FortiGate SSL-VPN Firewall Policy

Step 4: Test FortiGate SSL-VPN

Related Articles, References, Credits, or External Links