3rd party email provider / O365 / NCSC warnings....

[Koldov]

For years (well almost as long as I've been here) we have been using a 3rd party Learning Platform for our email.

 

Back in the day I believe we had an onsite Exchange server (but it was gone by the time I started) and then I think we had an LEA Exchange server.

 

At some point the LEA decided it would no longer provide this service (or any other IT support) and 'helpfully' sourced 'a 3rd party' to provide a Learning Platform and email solution (and a new IT support service staffed with previous high level LEA IT support staff - who had suddenly become consultants).

 

I think I hadn't been here long and so had no say in the matter (not that I would have at that time) but Staff here were never really interested in the Learning Platform side of things.... the email address has become ingrained obviously (printed on everything, website, not to mention years of contacts). I think they also used to originally use Exchange but a few years ago, moved everything on to an O365 tenant... how they license this I don't know (probably a free version)...

 

Some of you may be thinking that it's not difficult to change a school's email address, but I'm not keen and have no support for this anyway (I have tried).

 

Added to this is that somehow the Domain Name is not actually owned by us (not even by the LEA, it was created by the 3rd party), then a former employee of said 3rd party started a company (named as Director - yes, all very strange) owned them for a while, then another company (with the same Director) and now I think it is E2BN, therefore we can't easily make changes to the DNS and such, which brings me to the other issue...

 

We signed up to NCSC and I am now being bombarded daily with this email:

 

MyNCSC events between 5:01am 4 Oct 2022 and 5:01am 5 Oct 2022

New findings detected (1 Urgent):

• Urgent | Mail Check | TLS

Asset: school.domain.co.uk

Certificate host mismatch.

The certificate Subject Alternative Name does not match host 1234567890.mail.outlook.com. (Host: 1234567890.mail.outlook.com.).

 

Support has been unable to resolve it and have all but said that they are possibly looking into alternatives (which might include washing their hands of it and dumping the O365 tenant on us - something I'm not particularly keen on having never been responsible for an email tenant/domain before).

 

But for now, does anyone know if the above error is more of a DNS issue to do with SPF, DKIM or DMARC settings on the Domain and if so, will a quick email to E2BN be able to sort it out?

[mavhc]

Possibly a problem with CNAME on DNS.

 

I suggesting telling the people who own the domain you need it transfering to you, moving it to nominet, setting up cloudflare for dns, then changing the nameservers on nominet to point to cloudflare.

[Koldov]

Thanks I think I'm going to query it with E2BN.

 

Unfortunately when the tenant was set-up, the 3rd party created all schools that were under the previous LEA as a sub-domains of the higher level domain name, so I don't think there would ever be a way to buy it.

 

So, for us it goes something like @school1.PRIMARYTOWN.CO.UK and the school down the road is @school2.PRIMARYTOWN.CO.UK

[mavhc]

ooh, yeah, that's bad.

 

As a school you should still have your sch.uk domain, get that set up in the background and plan to move people over one day, meanwhile use it to practise.

[Koldov]

Yes, we have a sch.uk domain and it has a M365 tenant already (long story about Word on an iPad)!!! We are also an LGfL school so I've had that all that set up in the background for years, we also have a Google Workspace domain, a website domain... plenty of alternatives.

 

I doubt it but it might be the push I need to convince them to move email address, even though it is a pain with the amount of media with it printed on (let alone many years worth of contacts, website sign-ins, resource logins etc),

 

I've tried over the years to move them onto something else but it has always had a lot of resistance from SLT.

[chaplic]

How are you getting alerts for a domain you dont own in myncsc ? doesn't it require domain validation so you need to be able to update DNS to flag you own the domain

[Koldov]

Yes, although we don't 'own' the full domain as such the sub domain which our O365 tenant sits on, only relates to our school, all parties were happy for us to request the change with the registrar so that the required DNS records reflect that.

 

Anyway, I thought I would reach out to the domain registrar just in case it was something to do with DNS and got a reply to the tune of the internet version of RTFM!!!

 

https://techcommunity.microsoft.com/t5/exchange-team-blog/introducing-mta-sts-for-exchange-online/ba-p/3106386

 

I got halfway down and zoned out...

[free780]

MTA_STS requires placing a web server with inbound tcp/443 to validate sources of e-mail I believe.

[Koldov]

Yes, I got the bit about needing to host the config file somewhere... seems to be beyond me so I guess just live with the warnings?

[chaplic]

Im not sure the error is related to Mta-sts

 

It could be a transient error in O365 where their servers answering connections when someone wants to send you an email dont offer up the right certificate, although something ending mail.outlook.com isnt a dns name for o365 I recognise off the top of my head.

 

You should be able to check this yourself if it's consistent. Look at mx records, figure out A records, connect to them and see what cert is offered.

[BlueScreen]

I don't think this is an MTA-STS issue, I think the error might be relating to the MX record of the subdomain.

They may still have the MX record pointing directly at the 123456789.mail.outlook.com server instead of a newer school-domain-co-uk.mail.protection.outlook.com. server.

 

They will need to check the tenant's O365 Admin Center -> Settings -> Domains -> DNS records for the updated MX value. They can even connect O365 to some DNS providers to automate any changes that might be needed.

 

If you manage the DNS records of the domain can't you just change the SOA / NS record for the subdomain so that you control it again?