Microsoft Entra ID

1) Simplicity is key. It is very easy and fast to add SSO configurations, and it can be done in the UI in seconds. At the same time, there are some more complex things (like the ent. apps policies) that are hidden in the API and can be used in more advanced scenarios if needed. 2) Automation capabilities. Everything you see in the portal can be called through the Graph API. It gives so much power for automation and integration with 3rd party systems (like Service Now or Azure DevOps). So, it is possible to provide most of the functionality as a service for your internal customers through that. 3) Road-map. A lot of new features are planned/coming. Entra is a key Microsoft product and the only Identity Provider vendor they have. So it gives a very good feeling of safety that it will be developed further for many years and it will stay.

Multifactor Authentication Strengths with Conditional Access helps improve security for certain applications. The ease of SAML and OIDC implementation. Access controls with conditional access and entitlements help restrict and secure much of the service.

I like the clear documentation provided online, helpful advice about pre-requisites for setting anything up, and the default configurations. Plenty of information available via Microsoft community and partners when configuration issues or help to address specific use cases come up. Servicing - checking on accounts and logs, and Reporting using dashboards, and email notifications is generally full of useful information, and very easy to take action on if needed.

1) Additional (and sometimes unexpected) costs. Entra IGAs, Verified ID, and some other features require additional licenses in fact on top of the M365 E5 license. This is not expected in a way that you might think that E5 should be enough for everything (as it is a top license). The same is applicable for external identities that require some licenses on top of E5. 2) Confusion and overlapping of some B2B vs B2C functionality. Some features have the same name (e.g. Sign-Up flow) but different meaning and implementation for B2B and B2C. E.g. Something that works for B2C may not work for B2B (and that is expected). It creates confusion and requires effort to do a very good scoping and fully understand what you plan to achieve and by which tools. 3) It would be great to have more customisation options for MFA methods. It is not possible to allow some MFA methods for SSPR (self-service password reset) and not allow it for MFA. It is not possible, for example, to allow phone/SMS for SSPR but block it for MFA (as it is not reliable). This has created issues in some areas where MFA Authenticator app access can be challenging (e.g. for companies who have offices in EU/US and China).

There is no way to delegate admin consent for users to specific groups, so we are forced to keep it as admin consent only. There are no customizable error or access denied pages; generic deny pages are confusing to users, so users are generally allowed into the application at the level providing the correct error. Group membership limitations should be flagged and exposed to users with large groups and what applications they will not be able to access. The users and application admins are unaware of this until after implementation and then a few users hit the error which is an empty claim. Nothing is exposed without a major effort to expose it is group memberships. This leads to this service not having a true Enterprise group management implementation. Sign-In log queries are slow and sometimes unresponsive.

Session management is still not set right as default. Its too easy for attackers to steal authenticated tokens using Aitm methods, and replay session tokens and compromise accounts. The availability of entra id, and certain applications such as exchange, mean it is more exposed to brute force attempts and password sprays than local ad only accounts. Logs are very numerous for background actions when servicing an account - lead to a lot of logs. Sometimes its not clear from these logs who the subject and target account is. Logs from EntraId can be hard to parse and understand for analysts involved in incident detection and response. Especially SSPR actions produce a lot of individual logs, and the auditlogs table in Azure for a lot of Entra ID actions put a large amount of details within single column like additionalDetails, that then need to be parsed out to be useful for queries / auditing.