Azure & Active Directory Center

Last year I wrote "Microsoft 365 Security Assessment" Part 1 and Part 2, where I provided a list of actions one should perform or check in one’s Microsoft 365 environment as a security assessment.

When you’re in your own data center and your security model is based on perimeter security and passwords, you’re not cloud ready. Security models that only leverage firewalls and passwords, leave organizations exposed as soon as cloud services start to be consumed. However, many organizations don’t realize just how exposed they are.

Years back, Active Directory (AD) was all the rage. I recall its release with Microsoft Windows Server 2000 and entire books were written on the subject, everything from design to deployment to continued maintenance. Over time, AD has lost its novelty as the shiny new toy, but it hasn’t lost its value as the foundation piece to all other aspects of your network and on-premises servers, like Exchange. That has held true even with its cloud-based cousin Azure AD. Nothing takes out the entire Microsoft 365 suite like an Azure AD outage because identity management and a host of other server necessities are tied back to it.

Identity Management . . . . a fancy term for keeping tabs on credentials with access to our systems. All cyber security attacks share a common factor: the attacker gained access to a system. Commonly, this occurs using compromised user accounts.

Azure AD Connect is one of Microsoft’s products for syncing your Active Directory users, groups, and devices to Azure AD. Of these products, it is the most used one and although it has some customization it also is very automated and easy to use in its set up and operations.

Active Directory replication failures are like a leaking water pipe in your wall.   You don’t notice anything at first, but by the time you do, there is significant damage. It’s probably not altogether difficult to “repair” AD at this point and stop the "leak", but the damage remains. Monitoring Active Directory replication is essential to catching the little problems before they become major. It all starts with AD object inconsistencies between domain controllers.

When a network issue leaves your domain controller stranded on an “island”

Your users know immediately when they lose their internet connection. Those “internet is down!” tickets start flowing. But what happens when the network segment hosting their domain controller (DC) is unreachable?

Previously, MVP Nicolas Blank wrote an interesting article "Having an Identity Crisis" and it talked about all kinds of attacks on your environment. One such attack is on user email.  Users tend to choose a password that is easy for them to remember and this makes the password weak and easy to guess by others.  Even with some social engineering, user passwords are easy to retrieve, as can be seen on this YouTube clip What is your password?

What a great time to be an IT pro. I mean really, who has it better than us? On any given day there is so much going on, so much to learn, so much to improve, and that's why I do really enjoy my job(s). As I think about how to open this blog post, it occurs to me that I’ve had some great opportunities in my career. Sort of a “as one door closes, another one opens” sort of thing.

Office 365 allows for various authentication mechanisms, which includes federated authentication through Active Directory Federation Services. Federated authentication in Office 365 is configured per domain. However, if you register multiple subdomains in your Office 365 tenant, those subdomains will automatically inherit the authentication settings from the parent domain IF you registered the subdomains in the tenant after the parent domain.