MS365

I was setting up a Conditional Access policy to block sign ins from outside the country. I created a policy based on IP-based Named Locations, and specifying a country as the trusted region. However, the problem is that users who travel overseas could still sign in if they connected through a VPN or proxy which would then show their IP as being in the country. In some cases, mobile phone roaming plans would assign IP addresses from the country even when the device was physically overseas. The IP-based restriction wasn’t truly enforcing location. This reminds me of how we could get around streaming services like Netflix where you can use a VPN to see movie catalogs from a different country. ...

As I’ve been exploring passwordless authentication like Windows Hello for Business in my previous posts, one concept that has really captured my attention is the idea of phishing-resistant MFA. Traditional MFA methods, like SMS codes or OTP, can still be intercepted or tricked out of users through social engineering. Passkeys, however, are designed to close that gap by relying on cryptographic protocols that make phishing essentially impossible. Let’s say I’m signing into my account. I type in my username and password, and the system asks for a second factor. That could either be a text message with a six‑digit code or a push notification from Microsoft Authenticator on my phone. Both feel secure at first glance. But suppose I click on a fake login page that looks identical to the real one. I enter my username and password, and the fake site instantly relays those details to the real service. The service then sends me the MFA challenge. If it’s SMS, I get the code on my phone and type it into the fake page, not realizing the attacker is capturing it in real time. If it’s Authenticator, I see a push notification and approve it, thinking it’s legitimate but in reality, I’ve just confirmed the attacker’s login attempt. ...

In my previous post, I explored Windows Hello for Business using the Key Trust model. This time, I’m turning my attention to configuring Windows Hello to authenticate with Cloud Kerberos Trust. For this test, I’m working on an Entra ID–joined machine and attempting to access an on‑premises Active Directory domain‑joined file server. Signing in with Windows Hello for Business against Entra ID works perfectly for cloud applications, but the moment I try to reach on‑premises resources such as file shares, printers, or legacy apps, Kerberos is required. Traditionally the device must be domain‑joined, or the user is prompted again to supply their AD credentials. ...

I was troubleshooting an issue with Windows Hello for Business recently. I’ve tried setting it up in my home lab so I understand how it works for hybrid-joined computers. This post is about what I learned about the authentication flows for key trust and certificate trust, and why understanding them is essential for troubleshooting. I could sign in with Windows Hello on the corporate network but ran into issues when on a remote network (secured with specific firewall restrictions). It would initially work but then after some time, I couldn’t sign-in using the Windows Hello pin or biometric until I connected back to the corporate network. My setup is hybrid-joined. ...

If you run Microsoft 365 or Azure in a hybrid setup, chances are you’ve deployed Entra ID Connect (formerly Azure AD Connect). This handy tool keeps your on-premises Active Directory (AD) in sync with Entra ID, so users can log in seamlessly whether they’re working on-prem or in the cloud. When you create a user in your on-prem AD, Entra ID Connect syncs that account up to Entra ID. In Entra ID, every account has a property called On-premises Sync Enabled. ...