Microsoft 365

I am the Systems Administrator for a (total online) Microsoft 365, and Microsoft Azure, Sentinel Cyber school. I have been searching for over a year about ways to combat logins from all over the globe. I receive a daily report of logins that shows me who and where from they are trying to get access to our domain. I came across this article and I am trying to incorporate it into our Microsoft 365, and Azure, Sentinel; it seems it is almost straight forward until about halfway through then I don't seem to get where to create a playbook from. If someone has figured out a way to install Fail2ban in a Microsoft Azure, Sentinel, and 365 Defender location I would greatly appreciate the help, or if someone could help me get through the playbook section that would also be very helpful.

Thank you Morris

We use SendGrid for sending transactional emails to the users of our Chain SMS service. This includes emails like verifying your email address, welcome emails and password reset emails.

We recently switched from sending emails using an Microsoft Office 365 email account to using SendGrid. Here we've changed our approach from consuming a lower level capability (we used an SMTP interface to the Office 365 account) to consuming the higher level SendGrid service which we interact with using their C# client library.

We gradually rolled out the change to our user base and measured the % of users confirming their email address to estimate email delivery, we found SendGrid performed at least as well as an Office 365 account.

We found using more advanced email confirmation (SPF, DKIM, etc.) has made a significant improvement to delivery rate (increased the delivery rate by 10%).

We've also found that the email activity feature in SendGrid (which shows whether an email has been delivered, bounced etc) is particularly useful and has helped us learn more about how emails can go wrong (e.g. hard/soft bounce).

How we ended up choosing Confluence as our internal web / wiki / documentation platform at Katana.

It happened because we chose Bitbucket over GitHub . We had Katana's first hackaton to assemble and test product engineering platform. It turned out that at that time you could have Bitbucket's private repositories and a team of five people for free - Done!

This decision led us to using Bitbucket pipelines for CI, Jira for Kanban, and finally, Confluence. We also use Microsoft Office 365 and started with using OneNote, but SharePoint is still a nightmare product to use to collaborate, so OneNote had to go.

Now, when thinking of the key value of Confluence to Katana then it is Product Requirements Management. We use Page Properties macros, integrations (with Slack , InVision, Sketch etc.) to manage Product Roadmap, flash out Epic and User Stories.

We ended up with using Confluence because it is the best fit for our current engineering ecosystem.

We use G Suite because of its cheap costs, easy management/administration, Excellent DKIM score, and everything that comes with it. We switched from Microsoft Office 365 because it doesn't work on Linux which is our OS of choice. Furthermore, G Suite does not lack any of the features that Office365 had to offer, I'd even say it offers more.