#Modern Workplace

For the last couple of days, I have been working on securing my own tenant and as a result of this, I wanted to enable passkeys for all my test accounts. Passkeys (FIDO2) not only improves productivity and provide better security, but also make the authentication process seamless by eliminating the need for entering a username or password. This can be achieved through both FIDO2 security key and Microsoft Authenticator. Due to this fact, Microsoft and its partners are investing in both synced and device bound passkeys for work accounts. However, and during my own testing, enabling passkey on the user's side can go into a loop when trying to add a passkey in Microsoft Authenticator application. This may not be a case for every tenant, but if you have conditional access policies created that specifically leverage phishing-resistant authentication strength, then you will most likely run into this issue. Luckily there are some work arounds available and require further actions. In this...

When it comes to enrolling devices in Intune, there are multiple ways to do so. In a user based enrolment, one will require to provide Entra ID credentials at some stage or the other. However, things can become challenging when there are other authentication requirements like certificates in addition to providing standard user credentials. This is normally a case in organization that are federated with Active Directory Federation Services (ADFS) or with a non Microsoft Identity provider. A configuration requires a trusted certificate issued to a user or a device before the authentication can be allowed, but one cannot really deliver the certificate if the device is being born in the cloud and hasn't yet enrolled in Intune yet. It's a chicken and egg kind of situation. So how does one get around this without compromising on the security? The answer lies in the sign-in options at the time of the enrolment. There are some options available with the Sign-in options, but it is '...

Credits: Adobe Stock While working on a MDM migration project, I came across an interesting issue in Intune that almost had me heading down a rabbit hole. As part of the migration, the existing mobile devices were to be un-enrolled from a non Microsoft MDM solution and then enrolled into Intune using the Company Portal method. Nothing fancy, but when this process didn't work, I obviously got into an investigation mode and started looking at some of the obvious things. The obvious items that I looked at - 1. Network requirements for Intune, Android and Apple services. I must state that in this customer's tenant they had ADFS setup, so that added to the complexity. However, since the enrolment was taking place outside the customer's network, none of the network requirements really played a factor. 2. Intune device platform restrictions. Normally when a device is not allowed to enrol in Intune, more often than not it is due to device platform restriction policies. Especially ...

Source:Microsoft While going through the Defender for Endpoint configuration in my tenant, I realized that I had Vulnerability management partially configured for iOS devices and therefore, decided to put things in order. Before I dive into the specifics, here is a little something on what MDE Vulnerability assessment of apps is really all about. As part of MDE, Vulnerability management helps in identifying, assessing, remediating vulnerabilities across all onboarded devices. It delivers asset visibility, intelligent assessments, and built-in remediation tools for Windows, macOS, Linux, Android, iOS, and network devices. With the help of capabilities like Microsoft threat intelligence, breach likelihood predictions, business contexts, and devices assessments, Defender Vulnerability Management continuously prioritizes the biggest vulnerabilities on your most critical assets and provides security recommendations to mitigate risk. In case of iOS specifically, vulnerability assessments sup...