![]() Instead of purchasing 1'600 Azure P1 licenses (75'000eur/year), the client just now pays 35eur/year to have this "buffer" email address running. Eventually we found a workaround: we set up an automatic forward for the ticketing system reply address to an external cheap email hosting provider who still supports "legacy" POP3/IMAP authentication. Problem solved for the first account.īut for the second account things were more complicated: the ticketing system is neither OAUTH2 nor SAML compatible so it cannot connect to ExO, even if we register it and create an application principal. The drawback is that the client app needs to implement OAUTH2 or SAML.Īfter conducting a feasibility study, we identified that we could easily convert all powershell scripts to use an application principal instead and log using OAUTH2. Apparently, this is a known and intentional limitation of Azure AD security defaults: Microsoft wants customers to refrain from using the regular "user" account for non-interactive sessions (legacy concept of "service accounts") and wants them to use registered apps identities instead. While discussing the same topic on another forum, we somehow got our answers. Their issue was only that two accounts need to log into the system non-interactively, hence they could not be subject to MFA, hence the incompatibility with security defaults. It has been and it is working very well until today. This is not our use case: they just run powershell scripts to add/update/delete users from their internal IAM tool to their Azure AD. ![]() I will just share here in case someone has the same issue.First, I was not referring to automated provisioning in the sense of AAD regularly synchronizing its identities into a third-party app using SCIM. My apologies for the delay, it was an ongoing topic here and we finally got our answers. Hello u/flappers87, thank you for taking the time to reply. Another account would very likely be used to give our internal ticketing tool access to a mailbox a short exchange with our partner, he is telling us that if we want to implement these two accounts, our only option is to purchase 1'600 Azure P1 licenses for the other accounts (~$120K/year) so that we can configure Azure AD to disable MFA for the two service accounts.Ĭan anyone confirm whether this is true? I can easily understand why all "interactive users" would be subject to a single and unique policy when using security defaults but, how do other companies solve the issue of a service account? One account would not be MS365 licensed and be used to perform regular tests and the provisioning of user accounts (we have an in-house IAM platform). One thing we are probably misunderstanding is the question of service accounts. We plan on enabling security defaults on the tenant to have general baseline protection (MFA, no legacy protocol access, etc.). That would cover ~1'600 students, who would be licensed with Office 365 E3. We are considering migrating one of our faculties from our directory to Azure AD. The replacement Security Defaults option can be found by going to Azure Active Directory > Manage Properties > Manage Security Defaults (its.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |