Replies

This is interesting. According to some forensics geeks, last summer for a few days you were apparently able to access per-mailbox audit data via some secret REST API call but MS swiftly took that access away. The data was allegedly available regardless of whether you had enabled auditing on a given mailbox.

I’ve been doing things with some of the current unified audit logs around compromised Office365 accounts and it’s worth noting that you can already get events around Inbox rules and mailbox permission changes via these more system-level unified audit logs.

I suppose there may be occasions where having events for every tiny action taken in a mailbox is useful, but I’m struggling to see much practical mileage in knowing that some logon via an IP address in a far-away land read a specific mail at a specific time. What do you do with that info unless it happens to be a mail containing some secret that can be changed e.g. some kind of credentials?

If you’re a corporate employing in-house security analysts then you’re almost certainly capable and dealing with most of this now. MS turning on per-mailbox auditing is just one thing your existing 365 mailbox configuration tools won’t need to do now, but you’ll probably keep them doing it to ensure it stays enabled. Or disabled if you don’t want it.

For everyone else, the Bad Guys tend to set about doing things like making rules to intercept and modify incoming invoices with their bank details etc. and you can see that in the current unified audit logs without resorting to per-mailbox audit logs. You do need to ensure unified audit logs are turned on first though.

MS making even reasonable security features (not just advanced ones) here cost additional money is beginning to annoy me a lot. The default level is not enough and I think asking for money to fix that is immoral, especially when it’s education/charity Office 365 tenants.

 

I’ve just used MDT to make a 1809-beta[1] VM with the Nov 2018 cumulative update KB4457708 integrated into it by dropping the catalogue download in MDT’s ‘packages’ folder.

When I got to the desktop I checked and File Explorer says the ntoskrnl.exe file version is 17763.134

I then sorted out a web-proxy, clicked the check for updates and it looks like it tried to install KB4457708 all over again (first failed, second suceeeded 2 minutes later).

Think I’m going to abandon trying to understand what-the-bleep updating is doing & why.

[1] I’ve been calling the Oct 2018 release ‘1809-alpha’, and the Nov 2018 re-release ‘1809-beta’.

Last week, for me, 1803 was ignoring the default folder exclusions when saving a roaming profile at log-off. As a consequence it got stuck at random places copying stuff under <profile>\AppData\Local and gave ‘could not save your profile’ messages.

Solution was to add the default exclusions to my custom folder exclusions (via the GPO FolderExclusions policy setting).