A couple weeks ago, I had a dell server completely lock up on me, including the iDRAC which meant a 90 minute trip in to the datacentre to give the server a kick. Annoying, but not a major issue.

When I got to the datacentre I power cycled the server and everything came back up. I thought it would be worth doing a firmware upgrade in case that was the cause of the lock up. At the time, the latest iDRAC firmware was 2.81.81.81

Installing idrac firmware is pretty easy, once done the idrac rebooted and that is when I had a panic.

At first I thought that the firmware had somehow corrupted but it turns out that Dell have introuduced a new security check which is documented in the release notes that I did not read.

In short, Dell have introduced a host name check into the idrac firmware in order to mitigiate a known security issue https://www.dell.com/support/kbdoc/en-uk/000183758/dsa-2021-041-dell-emc-idrac-8-security-update-for-a-host-header-injection-vulnerability

The fix is pretty simple, all you need to do is access the iDRAC using the IP and ensure that under the idrac network settings you have set the DNS and host name correctly. Once this is done and saved your access problems will go away.

On 8th June, the CDN provider Fastly had an outage that they associated with a 'configuration issue'. What that issue was, Fastly have so far refused to say although they have alluded to it being a customers configuration and not something they directly did. They have also admitted that it is something that they should have forecast.

Outages are going to happen. Anyone who works in IT knows this. Things break and I will admit that my banner here is a little click-baity as the reason companies and even individuals use providers like fastly is because they don't have to maintain the infrastructure and an outage like we saw on 8th June is a very rare thing.

Despite everything I have said, I do wonder just how many companies that have full DR and business continuity plans actually take into account an outage of an upstream provider like Fastly. During the outage it was pretty obvious just how many sites were either fully behind fastly or had some elements reliant on Fastly.

As site note, it is interesting to see that Forbes shows up as not secure. This makes me wonder if they are using SSL offload with faslty and if the data from fastly down to forbes is actually unencrypted.

Above are screenshots of several websites that had issues during the outage. There's a lot more of course but I didn't want to cover this whole blog with similar screenshots! It's pretty clear that some big websites like Reddit and forbes are behind fastly and this makes sense.
The more hits a site gets the more the need for a CDN to help manage the load on the servers themselves and it is far easier to use a service like Fastly rather than put servers all over the world and deal with the inevitable sync issues.

While issues like the one that fastly suffered are rare, I do think that as IT pros we do need to consider what happens should upstream providers like ISP's and CDN's have a major failure, attack or even what happens if they go out of business. All of these are potentially real scenarios. All of these should have some level of DR and BCP planning. It's time for a DR and BCP plans to evolve to take into account this brave new world of upstream SaaS and PaaS providers.

Focusing on this outage, I do worry a little as Fastly are being somewhat tight lipped as to the outage:

I always get suspicious when a company doesn't go into details as to the issue. I do think companies like fastly have a duty to disclose more technical information simply because they have so much internet traffic going through them but of course, Fastly are a private company and as such, don't have to say a single thing about this outage. Until and unless there are data sharing requirements around such outages I do think that companies need to add upstream providers into both their risk portfolios and their DR and BCP practicies.

UPDATE

Well, It seems that Akamai felt the need to copy Fastly as just six weeks after Fastly took a nose dive so did Akami (https://www.bleepingcomputer.com/news/security/akamai-dns-global-outage-takes-down-major-websites-online-services/)

Akami have released a statement saying that the problem was DNS:

At 15:46 UTC today, a software configuration update triggered a bug in the DNS system, the system that directs browsers to websites. This caused a disruption impacting availability of some customer websites

Once again, this highlights the fragility of the internet when you put everything behind a single companies load balancers.

Thanks to a combination of a playful cat and a loose power cable one of my storage systems had an inadvertant removal of power and an outage. This was the storage that VCentre was running on and as seen in my previous blog recovering a corrupt vcentre, vcentre really does not like having it's power removed on the plus side this gave me the opportunity to try out a restore from the vcentre backups that I'd configured vcentre to send to a NAS and I'm glad I did as I learned quite a few lessons about how to successfully recover vcentre from such an incident.

Before I start with the details, I should point out that this is VCentre 6.7 - I've not tried out 7.0 yet but it's very much on the to do list.

Once I'd recovered power to the storage array I needed to have a look at the state of the VM's and I was able to log directly in to the ESXi host to see that most recovered just fine. VCentre, as we've seen before, really hates having the rug pulled from under it and so it was no surprise that it was not exactly in a heathly state. It would not even boot into VCentre due to corruption in the file system itself. I used https://kb.vmware.com/s/article/2149838 to get VCentre to at least partially boot but the postgresdb was in such a state that the only option was a restore. Thanks Cat!!

Now, me being me, I did not read any instructions on how to do this as I thought it would be a point and click excercise but it is a little bit more involved than that so if you want to see how to do a restore skip down to the part titled "Getting it all to work".

Not getting it to work

I thought I'd be able to kick off a restore by firing up the GUI and selecting restore from the menu but that doesn't work at all.

For some reason, performing the restore this way leads to a screen where no matter what you try you get an "unsupported protocol" message. I did track down a KB article which stated that restores from NFS and SMB were not supported which just seems strange to me.
The NAS that I have the backups hosted on does support FTP but getting FTP setup is quite involved and I thought that it would be easier to restore using another method so I thought I could perform the restore using the restore.job API.

And nope. It seems that VCentre doesn't support a restore from a system where the firstboot has run - i.e. any system that has previosuly actually worked! I did have a quick search to see if there was a flag I could reset or delete to remove this firstboot restore lockout but couldn't find anything so I gave up that approach.

Getting it all to work

After some searching, the process I followed to get the restore working was to delete the corrupted VCentre appliance and then deploy a fresh one but rather than select restore on the install screen I selected install in the same way as I would for deploying a new appliance.

The appliance install is split into two parts. For the restore you need to complete stage 1 only.
After that you select the restore option. Note that the restore path must be the full path down to the JSON file because if you select the root folder where the backups are sent then you will get a non-helpful error.
Do make sure you're using a file path down to a folder that looks like the screenshot below. The folders themselves are in date order so make sure you select the folder with the date you want to restore back to.

Once done you should see a screen looking like this. My backups are held on an NFS volume but I found it interesting that the restore shows it is using port 21.

This process took me about an hour as it was a mix of install and then restore. I am not sure why selecting restore from the installer doesn't go through this particular process but this method worked well and it was fully GUI driven. Once done the GUI started all the services without needing to do a reboot and VCentre was back.

In summary, the restore process is pretty easy and quite slick if you restore the components in the right order and the best right order appears to be to ignore the restore option on the installer and go for a stage 1 VCentre install and then select a restore.

Former CEO Kevin Thompson echoed Ramakrishna's statement during the testimony. "That related to a mistake that an intern made, and they violated our password policies and they posted that password on their own private GitHub account," Thompson said. "As soon as it was identified and brought to the attention of my security team, they took that down."

https://thehackernews.com/2021/03/solarwinds-blame-intern-for-weak.html

The above comment was made last week by the CEO of Solarwinds, Kevin Thompson and his replacement Sudhakar Ramakrishna.
In short, the soon to be former CEO and the soon to be CEO of solarwinds put the blame for the recent security issue on an intern.

Now, there is absolutely no reason to doubt this statement and I am going to accept it as a fact. It's also the reason that I'll never be able to trust Solarwinds again and I suggest that anyone using solarwinds products think very hard about doing so and let me explain why.

Firstly, lets have a look at what an intern is.

a student or trainee who works, sometimes without pay, in order to gain work experience or satisfy requirements for a qualification.

To summerise - Solarwinds allowed someone who was basically a trainee to modify and submit code which was then pushed to product that had a weak password in it and during that process no system, no checks and no management caught it.
Of course, Solarwinds takes your security seriously.

I worked at Symbian for a number of years. During my time there I became a storage admin on their NetApp systems. One of the things we hosted on the NetApp was the Perforce repository. During my time there an iniative was started around code signing, the idea being that apps would need to be signed so that they could be installed on a mobile phone. It's something we see a lot today and it just guarentees the integrity of the app.
Even though I was only a storage admin I still had to go on a two day internal course about how to handle requests to access the area, the perforce repository and so on. Symbian really did take the security seriously and as such, no incidents occured and certainly no intern would ever be given access to such a sensitive area. Sure, they might be told about it, they might even be show that area with a specalist engineer sitting with them but they sure wouldn't have any sort of access to be able to modify anything and this was in something like 2007.

I have several questions for Solarwinds that I'd really like an answer to, here they are:

1. Why did an intern have access to such sensitive data?
2. Why was an intern allowed to modify such senstive data?
3. Why wasn't their any monitoring in place for anything being posted to private github accounts?
4. Why wasn't the intern working with an senior developer who could have checked for such code submissions?
5. Why didn't automated code testing find the password?
6. Did the intern have any training for handling sensitve code?
7. Why did the intern modify the code? Was it accidential? Malicious? To fix an issue?
8. What changes have you made to the integrity of the code checking process to ensure that this can never happen again?
9. How can you claim to treat security seriously when, not long ago, an intern was able to put a backdoor password into sensitive code and it went unchecked for a year?

I will make a bet now, before March is out the soon to be CEO Sudhakar Ramakrishna will backtrack on his statement. It's too late now because the damage is done and it's not just the damage to the companies reputation for security, it goes deeper than that.

I'm no psychologist but I suspect that Sudhakar Ramakrishna made an off the cuff statement and blamed an intern for this backdoor password. I suspect he did it because he thought that saying "the intern did it" would have people going "Oh that makes sense, of course someone junior could make a mistake like that" but it opens up two sets of problems, the first being the security aspects I mentioned above and the second being that Sudhakar Ramakrishna just revealed that under his leadership, he will have no issues in pointing the finger of blame at someone and throwing them under a bus.
This is not acceptable.

If you blame someone for a mistake they made then you are showing others that you will out them and you will not have their backs. This makes for a very uncomfortable working environment where people will not want to come forward in case others get pushed under the bus.
This also means that other flaws might go unntoiced by solar winds because people are too afraid to point them out.

Sudhakar Ramakrishna just made the security and working standards at Solarwinds many times worse and he probably didn't even realise it, the fact that Kevin Thompson backed him up shows to me that the working standards problem may have been an issue at solarwinds for some considerable time.

I predict more issues in solarwinds over the course of this year.

I recently needed to add a cert to a vcentre 7.0 enviroment to allow Skyline and this is normally a striaght forward process. Certainly, 7.0 is many times easier than previous versions.

Adding the cert is just a case of going into vcentre -> menu -> administrator -> certificate management

If you're not familiar with certs then I need to quickly explain that certs are basically just files that contain cryptographic elements. For VCentre there are generally three files involved, there may be more if the certificate is issued by a sub CA (Certificate Authority). If the certicate is issued by a root CA then there are just thtee files involved, they would be:

CA Public Key
VCentre Public Key
VCentre Private Key

The CA's public key is required as the CA is the issuing body for that cert. The certs public key is required so that vcentre can pass that cert out to client endpoints and the key is required so that the data can be decrypted when it's recevived.

In VCentre, cert management is basically broken up into two sections, the first section is for the CA cert and the second is for the cert itself.

I suspect that most places will use an internal CA to generate the cert for VCentre and this is perfectly fine, there really is no difference between an internal and an external cert except for how many clients the trust model covers. In the case of an internal cert, only your internal clients should trust the CA.

VCentre requires certs to be in a PEM format which is the standard for many cert generation tools - if you open up the cert file in something like notepad++ then you'll see something like this:

As long as it has the =BEGIN CERTIIFCATE= line you know you've got a PEM format cert and can continue.

Adding the root CA cert is just a matter of getting the public key (Which should be easily obtainable, it is designed to be public after all) and adding it to the cert management section.

Adding in the cert for vcentre itself needs the cert to be generated and then the public/private key exported in the previously mentioned PEM format. If you are doing this using a windows CA then you might end up with a PFX format cert. Windows, liking to be different, thinks that all clients will be windows and so doesn't provide any option to obtain a pem format. Not an issue as there are two ways to convert it. The easiest is via SSL shopper.
If you are not keen on giving your cert to a remote site and allowing them to do the conversion then you can do the change yourself if you have access to OpenSSL which is a standard linux tool. If you have the Windows Subsystem for linux then you can use that as well.

The command in OpenSSL to convert a PFX to PEM format is

openssl pkcs12 -in clientssl.pfx -out clientssl.pem -clcerts

openssl pkcs12 -in clientssl.pfx -out root.pem -cacerts

Now that we have both parts of the certificate in the correct format it is just a matter of adding them to VCentre by clicking on the Machine Cert -> Import and replace certificate -> replace with external CA certificate which will give you this screen:

The first box needs the public part of the certificate and the last box needs the private key. The middle box, the one that says "chain of trusted root certificates" only needs the public key of the CA cert if you generated the cert from the CA or it needs the public key of the CA and sub-ca if you generated the cert from a sub-ca. I don't use a sub-ca in my environment but if you do then you just need the public key of the root CA and sub-ca in the same file, it would basically be a file containing two or more sets of == BEGIN CERTIFICATE == entries.

When I attempted to add the cert I'd generated I got a stnrage error.

I have to admit that this stumped me for a few days. I could not figure out why VCentre was rejecting my cert and as you can see, the error itself is not very descriptive. Even my searches for the error 'Exception Found (Certifcate Exception. Caught exception unable to initalize java.IOexception)' were not finding very much at all.

To cut a long story short I eventually decided to run the certs through openssl to see if it could spot any issues and that's when I discovered that one part of the vcentre cert itself was corrupt. I am not sure how this happened but I suspect that the cert was opened in notepad and notepad being the text editor that it is somehow mangled the format. Either way, the problem was pretty easy to fix as I just did a fresh export of both parts of the cert from the internal CA tool and this time VCentre accepted the three parts I needed and everything worked correctly.

Validating certs in openssl is quite easy to do and it's useful to know how to do it:

openssl rsa -in privateKey.key -check

openssl x509 -in certificate.crt -text -noout

If you're not familiar with certs then it is worth setting up a CA server and playing around with internal certs a little. I also published a vlog on setting up a basic external cert with Let's Encrypt which can be an easier way to start as you do not have to set up your own CA.

As something of a CentOS fan I have been wanting to try out CentOS 8 for a little while now and I finally got some time to do so. I am always curious to see what new features are included and what verions of various packages are included.

The current released version is 8.1 1911 - 8.2 is coming but does not have a release date yet, installing 8.1 into VMWare with just one vcpu, one gig of RAM and 16GB of disk went very smoothly. I will likely take the install files and add CentOS 8 to the list of OS'es I can deploy via WDS. I have not yet tried out the CentOS 7 unattended file but I do not see any reason why it would not work.

Once installed 8.1 I did a full yum update which dropped down 89 updates, not too bad considering that 8.1 has been out for a few months. I should point out that CentOS 8 supports yum but DNF should be the go to tool for package installs as DNF is the next interation of yum.

For this initial run through, the things I am most curious to check out are the versions of OpenSSL and Apache as I want to move my hosted machines over to TLS 1.3 which can only be done with a newer version of OpenSSL and I'm pleased to see that included with 8.1 is OpenSSL 1.1.1c, version 1.1.1 supports TLS 1.3 which offers a lot of security features over TLS 1.2 including huge improvements in the implementation of Perfect Forward Secrecy..

Installing Apache gave me version 2.4.37 and I still had to install mod_ssl to get access to the SSL engine. I will admit that I'm a little surprised that Apache does not come withe mod_ssl built in by default.
Once apache was installed I generated a cert in my PFSense CA I was able to get a test web site up and running using HTTPS over TLS 1.3 in just a couple minutes:

My first attempt to connect to the website failed because the in built firewall only has three inbound rules allowed, dhcpv6, ssh and cockpit.

CentOS 8 uses FirewallD which which is a fairly easy to use firewall system. I won't go into detail here as this article is an excellent go to source for all things firewalld related. Once I had added HTTP and HTTPS I was able to connect to my website just fine.

Now that the test website was up and running over HTTPS I did take another look at the firewalld permanent services and I was curious what cockpit was and why it was included in the defuly list of permanent services. I had not heard of it before. Well, it appears that cockpit is the linux worlds version of Microsofts Windows Admin Centre - formally honolulu that I covered some time back.

Installation via dnf install cockpit was pretty easy and replacing the default cert with an internally trusted one was easy enough and once done I had full access to cockpit on CentOS.

It is a nice addition and it is easy to retrofit to CentOS 7 although some features are missing on CentOS 7. I am told that some features are missing on CentOS 8 as well as when running cockpit on Ubuntu there is a dashboard option that does not appear in CentOS 8. Cockpit is certainly an interesting addition and something I will be looking to understand better and use more in the future.

One thing I was surprised to see was that 8.1 still allows a login as root over SSH. Other distros have blocked this by default and I would like to see CentOS do this. Logging in as root is a security risk because it encourages people to not bother creating accounts with su type rights, other than that minor quibble I will admit to quite liking CentOS 8 and I will be deploying it to replace my CentOS 6 and 7 boxes.

Microsoft released the Windows terminal some time back and I have been using it since about version 0.1

If you have not seen the windows terminal before you can think of it as an upgrade to the command prompt. In many ways, it makes the command prompt more browser like with the addition of tabs. The windows terminal allows for simulateous sessions across various cli prompts. It is possible to have sessions in the standard cmd prompt, powershell and linux all at the same time.

The really nice thing about Windows terminal is just how configurable it is. If you hit settings you will not see a traditional settings menu. Instead you see a JSON file. While a little scary to look if you have not seen one before. This sort of thing makes Windows terminal almost infinitely configurable.

There are already a whole list of additional command line plugins that you can just add to the JSON file. There is a good GIT cli option here.

Installing it is very easy. You can get it from the Microsoft store. Personally, I am not that much of a fan of the MS store and it is awesome to see Microsoft starting to support [chocolately](https://www.gdwnet.com/2016/06/13/have_you_used_chocolatey/ installs as a quick "choco install microsoft-windows-terminal" will grab the latest build. Updates are just as easy to run via a "choco update microsoft-windows-terminal". Chocolately will need to run as a local admin for this to work.

There are also a hell of a lot of customisation options that I will touch on in future blog articles, for now, I just want to highlight how much better windows terminal is than the standard command line. As an example of this, Windows terminal supports a split pane option and you can get a view for how powerful this is with the command:

wt -d c:\ ;split-pane -p "command prompt" ; split-pane -p "ubuntu"

This is three panes. On the left is a standard windows cmd prompt. Top right is the unbuntu shall and bottom right is powershell.

I will be using the windows terminal in a lot more articles. For now I just wanted to highlight how handy this app is. You should go get it right now!

Who remembers the 25th May 2018?

That was the date that GDPR became law, it was also the day that the vast majority of companies sent out emails saying "We have updated our privacy policy". GDPR was known about for at two years prior to the launch date so why did so many companies wait until the very last minute (and in some cases, several days after the last minute) to review their privacy polices and update them?

BCP (Business continuity Practice) is often discussed alongside DR (Disaster Recovery) and while the two certainly go hand in hand during a systems outage or disaster that takes out a datacentre/cloud provider etc, BCP is something
that needs to be considered on an at least monthly, if not weekly or even daily basis under certain circumstances.

The whole point of BCP is about how to keep the business running if something happens, note that I am using the term "something happens" and not "something unexpected" because BCP isn't there just for the unexpected but for the expected and what do I mean by that? well, GDPR is a great example.
GDPR was known about for two years and yet how many companies ignored it until the final few weeks? While I don't have official figures for this, I will bet that the majority did based on the email flood I had in the 24 hour period before GDPR went live.

A good company would allow their BCP team to pull together the people it needed to ensure that GDPR did not cause any disruption to the normal flow of work, that same BCP team should be keeping a watch for anything that could potentially harm or disrupt normal business.

This leads me to the current conerns around Covid-19, the coronavirus currently at risk of becoming a pandemic. Now, I'm not going to comment on anything medical here, there is some good advice on the NHS website and, if in doubt, do speak to your local health providers.
What I'm more interested in is how business will ensure continuity of service in the event of a Wuhan style lockdown or should the general advice be to self isolate where possible.

A good BCP needs to consider several things:

1. Can staff work remotely?
2. If staff can work remotely, is the capacity there on any remote access systems or do they need augmenting?
3. Can additional facilities (e.g. AWS workspaces) be brought online in the cases where remote staff may not have corporate laptops?
4. How do we cope if office support staff (cleaners, security, etc) are unable to come in?
5. Do we need to slow down work plans and delay delivery schedules to accommodate sick team members?
6. How will we handle local system issues where a staff member would be needed to attend site to replace a part?
7. Do we have sufficient spare parts to handle a slowdown in the supply chain?

I know a few companies that are deeply concerned about a breakdown in the supply chain as many companies shun keeping spares on site seeing it as something of a sunk cost with no real pay off as the supply chain has not really let us down in the past. However, that's ignoring several things here. Firstly, the whole supply chain is based on a JIT (just in time) framework. Any disruption anywhere along that line and it can have a real impact and as the supply chain often involves transiting several countries there is a real risk of something like covid-19 or even a no deal brexit causing a significant disruption.

This is not to say that panic buying spare parts is the right solution, rather that a balanced approach should be taken over the course of time and stocks slowly increased. There is something of an irony that panic buying could disrupt the very supply chain that companies rely on long before covid-19 (or some other issue) really hits the supply chain.

If the worst does hit and Covid-19 turns into a pandemic, it becomes more important than ever to support staff if they are caught up in the middle of it.
I fear that too many companies will use guilt and intimidation to force sick people to work rather than letting them fully recover. I can also foresee cases of companies abandoning staff who might be on
overseas travel should major disruption hit. Don't do this, do support your staff and be understanding around deadlines, schedules, etc. The IT industry does a lot of talk around being agile and flexible and this is one of the times when it can really be shown to be agile, flexible and hopefully supportive.

The last thing I want to say is simply this - do take care of yourselves and family before any work commitments and I hope that Covid-19 ends up blowing itself out in a relatively short time frame.

As some are probably aware, Microsoft were planning on releasing a patch in March 2020 that will make some changes to LDAP. Since that announcecment MS have admitted that they have had a lot of feedback on this upcoming change and so have scaled back their plans. Thier blog article is pretty good and worth a read just to understand what is coming. You can read it here.
I will admit that even though this article is a few months old, (I assume that the date is in US format, so 4th Nov 2019 - People, please use dates that the whole world recognises), I wasn't aware of the planned changes to LDAP until a few weeks ago.

It is worth having a read though the MS article and checking to see if your AD environment uses LDAP for any services. If it does, it is a very good idea to move over to LDAPS because LDAP does not use any encryption. If it's being used in AD then passwords will be going over the wire in plain text.

Fortunately, enabling LDAPS on AD servers is not a difficult task. All it needs is a cert that supports server authentication and that is it.

If you run a Windows CA environment then the chances are that you already have the necessary certs in place as the Windows CA can do these for you. If not, it is very easy to add them using a different CA host.

The first thing to do is to test LDAP and LDAPS just to confirm the current status. I really like the LDAP browser application for this. It is free and you can download it from here (just make sure you click on the LDAP Browser tab as that is the free one).

Once downloaded, install the app, launch it and create a profile, add in the name of one of your AD servers then click on the 'credentials' tab and either select "Currently logged in user" or select "other credentials" and then "GSS negotiate" from the drop down. LDAP on Active Directory does require an authenticated user, it cannot work with an anonymous user.

Once complete, hit OK and you should get a connection to the LDAP server.

That means that everything is working on port 389 and this should be the same for all your AD servers. LDAP should work right out of the box.

The next thing to do is test the connection against LDAPS and to do this, it is just a matter of changing the profile to use a secure connection:

When I run this test against one of my lab AD servers I get a com error:

This means that my server is not able to talk LDAPS. Fortunately, enabling it is pretty simple.

To get LDAPS working, I need to install a cert on that server. For LDAPS to work, I need a cert that supports "Server Authentication" as a cert function and fortunately, my personal internal CA of choice (pfsense) supports this type of cert so all I need to do in PFSense is create a cert. I could create one cert for each domain controller or I could just create a wildcard cert but I am not a fan of either option so what I will do is create a single cert that can support both AD servers.

In my PFSense internal CA, all I have to do is create a server certificate and name my two AD servers in the Alternative Names section as this will ensure that the cert will work against both servers

Once that has been done, I can download the private key and the cert from PFSense, now, windows being windows, I need to convert the public and private key files into a pfx file as that is what windows prefers and to do this I just use the online tool at https://www.sslshopper.com/ssl-converter.html

At this point, a few people might be horrified that the CA holds the private key and that I am using an online service to do the cert conversion especially as I will have to hand over my private key. Well, two things to remember - the CA is under my control so I am not too bothered about it hosting the private key and the second thing is that these certs are internal only. To get my internal clients to trust the CA I need to push out the CA public key to their trusted cert stores. If this was an external site I would not be as happy to give up the public key as I am with my internal CA.

Once I've got my PFX file, all I need do is copy it over to the domain controller and add it into the local machine cert store. It must be the local machine as LDAPS is "owned" by the server itself and not any admin who logs into the server:

And you should now be able to connect to the server using LDAPS.

Ben Hooper covers this process on the Windows CA and Let's encrypt side plus he has some very handy powershell commands for interrogating your AD servers for LDAPS. His blog article is worth a read and it can be found here