Microsoft Entra ID Reviews

We use Azure AD to implement conditional access when using Microsoft Network (MSN) services. Our infrastructure is primarily on-prem, and we operate our email in a hybrid environment and use the solution for continuity between our on-prem and cloud landscapes.

The solution improved our organization, especially in terms of security control. Overall, we're 65-70% satisfied with the product.

The most valuable feature is Conditional Access, and we use it extensively.

Azure AD provides a single pane of glass for managing user access; we integrated multiple APIs and use single sign-on for all of our Microsoft products. I can't speak in universal terms, but we had some positive feedback from our users regarding user experience.  

We use the Conditional Access feature to enforce fine-tuned and adaptive access controls, an excellent feature we use to enhance the security of all the machines connected to our domain. Users cannot access long-term data, data from untrusted devices, or data on connected personal devices.  

We use Azure AD Verified ID, which is a good feature for privacy and control of identity data; it offers a good level of secrecy. 

We've been using the solution for over six years now. 

The product is stable. 

The scalability isn't an issue; it depends on our license.

We previously used Microsoft's technical support, which was excellent; they were very responsive. Now, we use a CSP, and their support is lacking, so I rate them five out of ten.

Neutral

The initial setup was straightforward, and a partner was present to assist us during the implementation. We have around 250 users, and the solution doesn't require any maintenance.

The product's price is in the midrange. 

I rate the solution eight out of ten. 

Azure AD helped to save some time for our IT admins but not for our HR department, as they don't currently have access to the tool.

I recommend the product to those considering it, though it depends on the use case and requirements. If Azure AD has featured you don't need, then going with one of the cheaper competitors could be a better option.   

My primary use case is Azure SSO. Then, it is a hybrid synchronization of users and computers, and also for SCIM provisioning.

Using this product has helped improve our security posture. I don't handle security directly, but I know that our security team was able to identify logs containing erratic behavior, such as logins that were not authentic. They were able to identify and solve those problems.

This solution has improved our end-user experience a lot because previously, users had to remember different passwords for different applications. Sometimes, the integration with on-premises AD was a little bit difficult over the firewall. However, with Azure, that integration has become seamless. The users are also happy with the additional security afforded by multifactor authentication.

One of the benefits that we get from this solution is the Azure hybrid join, where my presence of the domains is both on-premises and on the cloud. It has allowed us to manage the client machines from the cloud, as well as from the on-premises solution. We are currently building upon our cloud usage so that we can manage more from the Azure instance directly.

Our cloud presence is growing because most people are working from home, so the management of end-users and workstations is becoming a little challenging with the current on-premises system. Having cloud-based management helps us to manage end-users and workstations better. This is because, with an on-premises solution, you need a VPN connection to manage it. Not all users have a VPN but for a cloud-based solution, you just need the internet and almost everyone now has an internet connection.

The most valuable feature is the single sign-on, which allows any application that is SAML or OAuth compatible to use Azure as an identity provider for seamless sign-in.

I like the SCIM provisioning, where Azure is the single database and it can push to Google cloud, as well as Oracle cloud. This means that the user directory is synchronized across platforms, so if I am managing Azure AD then my other platforms are also managed.

In a hybrid deployment, when we update the UPN or email address of a user who has license assigned, it does not get updated automatically during normal sync. This means that we have to update it manually from Azure, which is something that needs to be corrected. Essentially, if it's a hybrid sync then it should happen automatically and we shouldn't have to do anything manually.

Azure AD DS allows only one instance in a particular tenant, which is something that could be improved. There are people that want to have AD DS on a per-subscription basis.

I have been using Azure Active Directory for more than three years.

Other than a few global outages, I have not seen any specific outages to the tenant that we use. In the typical case, we haven't faced any issues.

The scalability has been good. For the infrastructure that we have developed, there were no issues. We have nothing in terms of abnormal outages or any abnormal spikes that we have observed. Overall, scalability-wise, we are happy with it.

We have thousands of users on the Azure platform. The entire organization is on Azure AD, and everyone has a different, specific role assigned to them. Some people are using the database, whereas somebody else is using other infrastructure service, and the same is true for all of the different features. We have different teams using different features and I am part of managing identities, which involves using Azure AD and its associated features.

The support from Microsoft is very good. I would rate them a nine out of ten. They are responsive and very knowledgeable.

Prior to Azure AD, we used on-premises Active Directory.

The initial setup was not very complicated because there are very good articles online, published by Microsoft. They give detailed steps on the process and including what challenges you may face. In our setup, the articles online were sufficient but suppose you run into any issues, you simply reach out to Microsoft for support.

Taking the purchases, planning, and everything else into account, it took between three and four months to complete the deployment.

Our in-house team was responsible for deployment. In a few cases, we reached out to Microsoft for support.

We have not evaluated other options. The reason is that the integration between Azure AD and on-premises Active Directory is seamless and easy. Both solutions are by Microsoft.

My advice for anybody who is implementing Azure AD is to consider the size of their environment. If it's a large on-premises environment then you should consider a hybrid model, but if it's a small environment then it's easy to move to the Azure cloud model directly. If it's a small environment then Azure AD is also available on a free license. This is how I would suggest you start looking at having a cloud presence.

Azure AD is easy to integrate and manage, and it will reduce your capital cost a lot.

In summary, this is a good product but there is always scope for improvement.

I would rate this solution a nine out of ten.

We use this solution to authenticate to the portal. There are also some VMs that are not domain-joined, so we use Azure users that we create natively in the portal.

We also use it for our applications. The accounts that we create natively in Azure are used for application authentication.

We have a hybrid deployment model where some accounts are primarily native in Azure, whereas others are on-premises. We also have accounts that are synchronized between our on-premises servers and Azure.

Azure AD has features that have helped to improve our security posture. We have a service called Azure AD Privileged Identity Management, where instead of our administrators having permanent access or permanent admin assignment, they can now activate admin roles only when they need to perform administrative-level tasks.

This means that instead of using permanent assignments, our administrators activate the specific roles that they need at the moment that they need them. After the task is complete, the administrative access expires. This has definitely improved our security posture.

Using this product has also had a positive effect on our end-user experience. The self-service password reset is something that has definitely improved our end-user experience. Instead of having to call our service desk, users can now reset their own passwords.

This is important because due to our multi-factor authentication, we no longer have policies where we have to have periodic password changes. We have three and four-factor stages of authentication, which makes our logins more secure. This is why users don't have to change or reset their passwords on a regular basis.

One of the ways that Azure AD has improved the way our organization functions is to help cut down on service desk requests. If I have an issue with my password, in the past, I would have had to log a ticket with the service desk. With most of us working remotely, this would've posed a challenge. It would have required the service desk to verify that I am who I say I am, for example. Now, because users set up their own profiles and are able to change passwords for themselves, at any moment that their account is compromised, they're able to change their own password.

Overall, this solution has definitely improved our organization's security posture. We no longer have permanent administrative permission assignments, and we are also able to restrict who is able to log in to certain applications. Finally, we are able to see and review any risky or suspicious sign-ins.

Specifically, in the infrastructure team, we now have managed identities. Instead of having to create service accounts, we have managed identities that are directly linked to our resources that support them. All of that is managed by Azure Active Directory.

Another way that this solution has improved how we do our work is that we no longer have to keep a record of all service accounts or use one service account for multiple services. Now, each service that supports managed identities can have its own service account, and that is managed by Azure AD.

The most valuable feature is the conditional access policies. This gives us the ability to restrict who can access which applications or the portal in specific ways. We are able to define access based on job roles. For example, I'm primarily in the infrastructure team and only certain people should be able to connect to the Resource Manager. We can also define which IP addresses or locations those people can connect from before they can access the portal.

If your organization requires additional security then the subscription will be more expensive.

I have been using Azure Active Directory for approximately five years, since 2016.

In terms of stability, Azure Active Directory is definitely an improvement from what we used in the past. I'm happy so far with the offerings and we hardly ever have any service disruptions.

We have a lot of different people using this solution. We have normal users and we have administrators. It's a large organization.

So far, I've been happy with the technical support.

There are very few service disruptions and also, because of our agreement with Microsoft, we are able to get escalated support.

We hardly ever have any downtime. When we do need support, it's normally escalated and our service is restored in a reasonable timeframe.

I would rate the technical support a nine out of ten.

Prior to this solution, we used the on-premises version of Active Directory.

The switch was part of our cloud migration strategy. For us to be able to use our apps and workloads in the cloud, we had to have Identity Management as part of our migration scope. It's linked to our cloud migration strategy.

I was not involved with the initial setup but I assume that it was not complex because we have Microsoft consultants assisting us.

We specifically work with Microsoft directly. We don't use a reseller or service provider. All of the assistance that we get is directly from the vendor.

Our technical team is responsible for deployment and maintenance. I'm not sure how many people are in that team. Somebody from security is involved, but I'm not sure what other roles are required for maintenance tasks.

We have definitenly seen a return on investment from using this product. We have seamless authentication, quicker response times, more robust security, access from anywhere without having to set up VPN links, and federated models.

If we had similar services on-premises, I assume that it would be expensive, especially given that we used to have a perpetual licensing model. Now that we are able to have a subscription-based service, it has not only improved our security posture but also cut down on costs.

My advice concerning the pricing and licensing would vary depending upon the stage of maturity of the organization. I've been with companies that are using the Office 365 license for Active Directory, whereas others are able to use the free version of it.

For organizations such as the one that I'm at now, where we require more security and have services like the Conditional Access Policies or Privileged Identity management, you have to upgrade to a higher level of the solution.

I'm not sure about the specific costs or how they're calculated, but essentially, the costs go up based on the level of security that is required by the organization.

I can't say for certain what our future plans are for Azure AD but I see it being used long-term. It has helped our organization to grow because of what we are able to do. Also, it has greatly improved our security posture because of the services that are available.

I would rate this solution an eight out of ten.

I was a consultant. I recently changed my job (seven days ago). Most of my customers did everything in Azure. They used Azure Active Directory Domain Services (AD DS) as well as Active Directory Federation Services (ADFS) to sync a user's profile using AD Connect and a federated model. So, they could access an application on-premises as well as in a cloud. 

I am now a CTO for a big hospital. I manage Azure AD for all hospitals as the CTO. They also use Office 365 across all four of their hospitals. 

The solution is hybrid cloud. We have the Active Directory on-premises and Active Directory Domain services in Azure. This is where I use AD Connect (or sync server) to sync the user's profile.

Azure AD has features that have helped improve security posture. From a security point of view, they integrated with Okta, which is one of the integrations that we used for a customer's use case. From there, their entire security posture is managed and integrated with Azure.

It gave better visibility on our customers' security posture - the way that they configure users, configure their end user computing, and multi-factor authentication. This is where they get better visibility and manageability through this particular solution.

A use case that we did for an end user in a manufacturing organization: We used WVD with biometric authentication because 1,500 processes need to happen in a process. The user didn't want to use a login using their credentials. They wanted to use fingerprinting or tap their ID. That is where we integrated with the authentication. Now, they can process in a couple of hours, and they run those 1,500 processes every day. This changed their login process, which improved the manufacturing process. This helped a lot for their high deployment.

In my current organization, it is connected only for Office 365. We are getting into other services that Azure has to offer, but that has not yet started. The first use case that we are going to do is backup and recovery through Azure AD.

We are trying to do backup for some Tier 1 applications through Commvault. We will use that data to restore within the Azure environment or Azure Virtual Network (VNet), recovering all the applications. We then make sure that we have the capability for recovering those applications end-to-end. This is where Azure AD will play a huge role, so we don't have to come down to on-premises for authentication.

• The authentication process, e.g., multi-factor authentication.
• Directory Domain Services.
• Azure AD Connect (sync services).

The biggest thing is if they could integrate with their IPS/IDS processes as well as have integration with another app, like a third-party application. Varonis was another solution that my customers are trying to integrate with ADFS. For some reason, they were seeing some difficulties with the integration. There is a case open with Microsoft on this particular thing.

The only issue is the OU is not properly synced. Therefore, you have to do a manual sync sometimes or you might lose the connector due to AD Connect or sync servers.

I have been using it for a couple of years.

I haven't seen any major issues. 

We had a customer with roughly around 80,000 users. They had three SMEs or FTEs managing their Active Directory environment or solution.

Maintenance-wise, we need at least two FTEs for backup, making sure that we have the right coverage 24/7.

I think we can add more systems to make sure that we can connect. The documentation provides more detail about the sizing information for OVA files or AD Connect files on the server. So, you have those kinds of capabilities built into the scalability.

Before, we used to manage most technical issues. For example, if there was a critical thing that had to happen, then we would open a case. The support that we used to get from Microsoft was great because we were a Gold partner with Microsoft, so we had good access for the technical team.

We don't use the technical support too much because we have engaged a partner for my current organization. 

The initial setup was so straightforward. The documentation is good. There were no problems deploying it. We did the deployment for one customer in less than an hour. Another customer took some time because it is more like a process for change management. Otherwise, the actual installation, download, and configuration took less than a couple of hours.

My previous company's focus was on how to integrate a customer's Active Directory with Okta, how to integrate it with MFAs, and how to integrate with security IMs.

The deployment was easy to do and integrate with on-premises. So if it was a small- or medium-sized customer, we could bring them into the cloud in no time. Also, we could start looking into other applications that the customer could use: Docker containers or DevOps. This is where we spent most of the time, i.e., with customer design.

Every hospital with Office 365 comes with Active Directory Domain Services so you need to sync all your users. That is how the implementation is done today.

At my previous employer, most of our customers' application deployment used Ruby on Rails in their AWS environment and were looking for an authentication process. So, we installed Active Directory or ADFS in Azure for a specific client. Then, all applications would get authenticated to Azure Active Directory and synced from their on-premises environment. 

There was another client for whom we installed Azure Directory Domain Services, which synced with their on-premises data and federated model so we could get the single sign-on. We then installed Azure VMware Solution in Azure for their expanding or extending their on-premises VMware architecture.

We created a questionnaire where we documented the customer's current environment. For example, customers wanted to sync the amount of users. We then used that questionnaire to take care of the prerequisite before we even started deploying this solution.

The whole deployment process should take less than one FTE.

It provides an organization flexibility to move towards the public cloud, so their workload can be upstream. They can see that they don't have to come down to their on-premises for any authorization authentications. That is where we were seeing more development environments, staging environments, and DevOps environments, as most of our customers were pushing towards the public cloud, which would then be integrated with their Azure Active Directory.

The licensing model is straightforward. I don't think there are any issues with the E3 license or E5 license.

We had a customer with very traditional architecture in AWS. We spun up the ECP instance, then installed and replicated the Active Directory. Other than that, I don't think we had another customer who was going in a different direction.

We have a budget for Q4 2021. By Q1 2022, we are hoping to get one hospital completely in Azure by 2022.

The only way to learn about the value that Azure brings to the table is if a customer can use as an evaluation copy or license. Then, they can integrate and push the development OUs or the test OU to make sure that they can integrate with the MFAs.

I would rate this solution as an eight or nine (out of 10).

I am an operational engineer and consultant that assists organizations with their Azure Active Directory implementation. I primarily deal with administrative functions in my day-to-day tasks. I am responsible for creating and configuring Azure AD users and groups, as well as assigning the dynamic membership required by the organization to their users. Another common task is that I set up guest user access for organizations that want to grant access to users on a temporary basis.

For customers that want to use a cloud-based deployment, I can assist them with that. In cases where the customer wants an on-premises deployment then we will provide them with help using AD Connect, which is used for synchronization between cloud-based and on-premises data.

This solution helps to improve security for our clients using a specific directory structure and by using a variety of options. There is a default directory, which is owned by Microsoft, and in there you can create custom directories for your use. 

There is a panel available for the administration of users, groups, and external identities. 

Options are included for uploading your on-premises applications to the cloud, and they can be registered with Azure. This means that you can also create your own applications.

Identity governance is available for paid users.

Using Azure Active Directory has benefitted several of my clients, with an example being a startup organization. Startups have three or four things that they need to do in order to begin work. First, they need a domain, and after that, they need a DNS record to be created for their domain. For instance, these services are provided by godaddy.com or similar vendors. Once these steps are complete, they connect to Azure AD with the help of the DNS record that was created. At this point, Azure AD performs the role of a Platform as a Service. Once Active Directory is connected and verified, you can create the users and groups, and begin managing your processes. 

These are the only steps that are required for a startup. For an enterprise that wants to migrate its on-premises data to the cloud, there are several additional steps. For instance, you need to create a virtual machine and install your server. Alternatively, if you already have a server, it can be connected with the help of AD Connect.

This is a good solution for end-users because the vendor provides good documentation and if the users experience errors or issues, they get a popup alert to explain the problem. Furthermore, it can provide a solution to resolve the issue.

The most valuable feature is Identity and Access Management. As an IT administrator, this feature allows me to manage access for users and groups.

This product is easy to use and easy to manage.

The application policies, licensing, and AD Connect options are valuable.

Multifactor authentication provides more security. Having a user ID and password is compulsory but after that, you can add different security features. For example, it can work with biometrics such as fingerprints, retinal scans, and facial recognition. There are many more options that may suit you better, as per your requirements.

When you log in to the Azure portal, there is an option available called Resource Groups. Here, you can add multiple things including printers and different servers. There are Windows servers available, as well as servers hosting many different flavors of Linux. Once a server is created, you can add in a database, for instance.

There are four levels of subscription and the security features are not available for free. At the free or basic level of service, Azure should provide identity protection features including single sign-on and multifactor authentication. These are the most important features for organizations and everybody should be able to utilize them for working remotely.

I have been working with Azure Active Directory for approximately three years.

Worldwide, Azure has many servers available and in fact, they are the largest cloud organization in the world. As long as you are paying for the service, you don't have to worry about availability. There is a Microsoft backend team available that can provide you with what you need.

The availability is the best in the cloud industry.

You don't need to create or manage your own infrastructure, as it is handled by the Azure team. Also, through the Azure portal, you can add databases.

This is a scalable product. You can scale it to any number of users and any number of servers, and there is no issue. As your organization grows day by day, you can increase your users, your databases, and compute services including RAM, CPU, and networking capabilities. This will ensure availability on the platform.

If you are part of a very large organization, with between 50,000 and one million users, then you might generate between 500 and 1,000 terabytes of data each day. You have two options for uploading this data to the cloud, including an online option and an offline option. In the online option, you use a gateway. The offline option includes Data Box, which is a device used to transfer your data. These hold 800 terabytes and above.

I have not used technical support from Microsoft myself. However, it is available and they can provide proper resolution to problems that people are having.

The support documentation that is supplied on the web page is very good. If anything changes then there is a section for notes in the documentation that explains it.

Using technical support is a more cost-effective solution than hiring somebody to maintain the product full-time.

The initial setup is not a complex process. It is simplest in a cloud-based deployment and it will not take much time. If your current server is on-premises then you only need two things. One is your enterprise domain users, which have full access permissions. The other is a global administrator on the cloud side. Both sides need to be integrated and this is done with the help of Azure AD connect. Once this is complete, you can have interaction between your on-premises data and cloud data.

It is helpful to have a basic level of understanding of the product prior to implementing it.

We provide support to our customers, depending on the error or issues that they are having.

There are four different levels of subscription including the free level, one that includes the Office 365 applications, the Premium 1 (P1) level, and the Premium 2 (P2) level. There are different options available for each of the different levels.

Everybody can get a one-month free trial.

This product is cheaper than Amazon AWS and Google GCP.

I do not use the other Active Directory solutions, although I do check on them from time to time. One thing I have noted is that the Google platform charges you on an hourly basis. In the case where you need a virtual machine for only one or two hours, this is a good option. However, if you forget to log out of your machine, then the cost will be large.

AWS provides you with a one-month free trial so that you can test using the resources.

At this time, Azure AD is the biggest cloud Platform as a Service that is available. They have 60+ cloud data centers available worldwide, which is more than any other organization. It is a service that I recommend.

My advice for anybody interested in this product is to utilize the free trial. Microsoft will not charge you anything for the first month. They will also give you a $200 credit so that you can use the services.

I would rate this solution an eight out of ten.

The use cases typically include external customer authentication, which we do, and by customers, I mean our hotel partners. There is basic user authentication and the ability to isolate those users based on a particular security environment, whether they are coming from a PCI environment, lab environment, corp environment, etcetera. Each of those has to pass through specific security, so everything that your Active Directory or Windows AD is solving on-premise is essentially the use case, except for the external customer situation which was the one thing that made me look at Entra ID. Unfortunately, the way Entra ID works created a major security issue that I cannot go into regarding guest users for our tenant. We are now trying to fix that.

We tried to stand it up as a PoC, and we went back and forth with Microsoft on it for a few months. We never got to a resolution because there is an architectural design issue with the service itself, and Microsoft is not going to change their service for us. We tried to use it, and then we gave up, killed it, and went back to the original plan, which was to use Okta. Our goal is to eventually completely get out of the Microsoft Identity ecosystem and move over to Okta.

We do not use Entra ID anymore. We have moved away from Entra ID. We could not justify it from a business standpoint. That is the crux of the situation. We now have a solution that can meet all of our business needs.

Microsoft Entra does not provide a single pane of glass for managing user access. It is not fully featured yet. There are some things within that Entra ID administrator portal, but it is not as robust as simply going to Entra ID service and then going to different features that it has to maintain identities. It is not even a single pane of glass if you look at how Microsoft does identity between Entra ID, Azure Resource Manager, and M365 itself. I know that they are trying to fix the situation between Entra ID and M365, but the subscription-level identity access controls need to be moved out of the subscription level and need to be globally managed from the identity provider. I am sure there was a design choice for that, but it just does not work when you are a company of our scale because we just cannot keep managing individual resources, so we would like to centralize the identity system.

I used Microsoft Entra Permission Management in a very specific scenario but because we are a hybrid environment, we often found ourselves fighting with cloud groups. We moved a lot of security groups into Entra from our Windows AD environment. We have a lot of stuff that has been built upon that for the past 20 years. Not being able to have Windows Active Directory security groups that are synced to Entra ID to control access to resources was a big pain for us. We would have had to create a cloud group and then add all the members of those on-prem security groups to it, so we did not even bother with it. When you have a company of our age and our size and you have nested security groups, there is a lot of linkage there, and it is not attainable. 

It is great for mom-and-pop shops or small businesses that are truly coming into the enterprise ecosystem and that have not come from a legacy environment. Current statistics show that 99% of the world that was in an Active Directory authentication environment is still in the Active Directory or Windows AD authentication environment and just supplementing Okta, so we are not doing anything new. A previous Microsoft employee that I talked to said that in the last decade, there has literally been only one customer to get fully off their hybrid environment and go fully into Entra, and it took them over ten years. Therefore, Microsoft needs to focus more on Entra and fix not only the design flaws but also address a lot of the customers' needs. It has a lot of potential specifically around taking business from IIQ for some of those UAR workflows, identity workflows, etcetera. Their biggest competitor is Okta, and Okta is currently the better solution.

We have been trying not to use the solution. It is used for a specific use case, which is around authenticating M365, and we are trying to see if we can get out of using it, but that is only because our environment is extremely complicated. Entra ID is not battle-tested or stable enough to support a business of our size. There are some design issues specifically around support for legacy services. We used to be part of Microsoft, so we have about 15-year-old services sitting in our data center that still need to use legacy LDAP authentication. The way we currently have the environment set up is for one very specific domain. I am using a domain for specific context here to keep it simple. We have 36 Active Directory domains, and that does not include the child. We follow the least privileged access model. Our environment currently consists of using AD Connect to synchronize objects from our corporate tenant into Entra ID, and then from Entra ID, we wanted to stand up Azure domain services as a possibility for retiring legacy LDAP services. The issue with Entra ID specifically is that the way it replicates objects out of its database into the Azure domain services Active Directory tenant or Active Directory service is that it uses the display name. This is a bad practice, and it has been known as a bad practice even by Microsoft over the past decade, so the design is not good. The issue with replicating based on the display name is that when you are coming from an environment that uses a least privilege access model, where you want to obfuscate the type of security account being used by hiding it behind a generic display name, instead of myusername_da, myusername_ao, etcetera, to have an idea of what accounts are being used when they are logging in, it is unable to reconcile that object when it creates a new domain. If they all have the same DM, you end up with quadruplicates of each user identity that was replicated to it from the directory. Those quadruplicates or their same account names, as well as the display names within the cloud domain services directory, have a unique identifier with the original account name attached. What that does is that it not only breaks that LDAP legacy authentication, but it also drives up the cost for your customers because you are paying for each additional seat, additional user objects that are created, or additional users. You also cannot tell any of those accounts apart unless you dive deep into the user object to peel back what type of account that is to map it back to what came from on-prem itself, so the service is completely useless. What we have done in our case is that we do not really need Entra ID. We have Okta, so we use an Okta LDAP endpoint. That does exactly what we need in using SCIM, which is the technology that is able to take identities from multiple dynamic providers and merge them together into a single record. It is able to act as an official LDAP endpoint for the business, so legacy apps work. We do not have a problem. Microsoft could learn from that.

Entra should allow for external MFA providers rather than forcing you into a walled garden and the Microsoft ecosystem. Flexibility is a big thing, especially for companies of our size. A big issue for us is that we want the identity to be in Entra for sure, but we want it to come from Okta. We want the authentication and stuff to work, but we want Okta to control the PIM rules. We want it to do the MFA and all those things, but Entra does not play nice with others. Okta has engineered some ways to get it done, but it is not as full-featured as we would like it to be. Microsoft should do what they do with some other partners such as Nerdio and Jamf where they have their own version of a service, but they are still partnering with those other companies to at least add options on the market.

Fully customizable UARs and Azure Secure Identity Workflows would be great. Currently, you can do it if you cobble together a bunch of Azure functions and use Sentinel. If you are sending logs to Sentinel and are able to match patterns and run automation based on that, it would be great. They can help with a solution that abstracts away a lot of that complexity across multiple services into exactly what IIQ does. I could definitely foresee Entra being the choice for identity for pretty much all cloud providers if they can focus on the areas that SailPoint's IIQ does. A big pain point for a business of our size by being in Okta is that we do not have the same workflows that we have between IIQ and AD. With the amount of data that our company generates, we wanted Sentinel. I had their security department onboard, and it was going to be millions a month just to use Sentinel, but we could not use it, so we decided to leverage Splunk and a few other SIEM providers. 

They should also stop changing the name of the product.

We used it for a few months.

Microsoft's support has been so bad when we have had issues in Azure that we recently poured 24 million dollars out of our spend for Azure, cut our unified support agreement with them, and sent it to somebody else. I would rate their support a zero out of ten. It is so bad. We probably never had a support engineer solve our problem. Usually, I or somebody else in the company has to reverse engineer service to try and find the solution. The things that we find are not even documented on the Microsoft site. The second way is to pull the information from the blog of some old guy who found the same issue and ended up solving it. 

People on the support side at Microsoft just read from a runbook and then send us to another part of the world where they ask us the same question, read from a runbook, and then we repeat ourselves, so we sent all that support to Insight. They were happy, and they were way cheaper. It only cost us less than four million. It was significantly cheaper. Our leadership is like, "Wow! IT actually saved us money this year."

Negative

We were using Active Directory, and we will never get off AD. There is too much legacy stuff for us to even bother getting off AD. It is a very mature product. It would be crazy for us to leave Windows Active Directory for something else, even Okta. There are core things that we need to function a certain way, so Entra ID just does not make sense. Entra sometimes even has access issues and replication delays with identity and adding objects to a new access control list within its platform or service.

We are not a typical company. We used to be part of Microsoft, so a lot of things that we inherited were very complex, and we also do things differently. For the old NT systems and SMB shares, we are still using Active Directory groups, and they work just fine. We have automation built around membership. We control the membership of those groups, the auditing of those groups, and everything else, so it does not make sense. It would be too much work to move us over to Entra ID.

I was involved in its deployment. It was complex, but that was not Microsoft's fault. That was our fault because we have a very complicated environment.

We have a hybrid environment. We were in IBM, but we pulled back. We have Oracle's cloud platform, and we have AWS as well as Azure, but 99% of our cloud workloads are all in AWS.

When we initially started, Microsoft was not there. The initial implementation strategy was to synchronize the Windows Active Directory corporate domain to Entra ID. That way, we had the identities and we could use the same AD connector to synchronize the AD distribution lists. The other side was the mailbox. 

We did not take the help of any integrator. It does not require much. You stand up your servers. You have a staging host with its own database, and then a sync host with its own database. You then hook them up and make sure you have all the permissions in your previous tenant.

Microsoft puts MSOL accounts in some default directory. You should be able to tell the agent to put the MSOL accounts in a more secure OU. For instance, the original recommendation, which has changed recently, when we set up the service was to use an enterprise admin to set up the agent, which generates a bunch of MSOL accounts. Those MSOL accounts ended up in our all users' organizations. When you have a company of our size, that is not the only MSOL account that exists in the directory, and it is really hard to tell those apart, so we have to look through the logs, see which MSOL account it is using, and move it into the proper OU for the on-prem domain. It would be nice if you could determine where that goes at the time of creation.

We were able to reclaim the money that we did not spend with Microsoft and spend it elsewhere. It is technically an ROI, an investment of our time in negotiating other deals.

Microsoft is so expensive. You know it is expensive when a Fortune 100 company like ours is complaining about the cost. That has been a big thing for me. When I really want to use an Azure service, it is very hard for me to justify the cost, especially with Microsoft support. 

To those evaluating Entra ID, I would say that if you are on Windows Active Directory, just stay on it.

I would rate it a five out of ten. It is not ready yet. It needs focus by Microsoft.

We sync up our on-premise Active Directory with Azure AD and use it for app registration. All of our cloud-based DevOps activities use Azure Active Directory.

Azure Active Directory has many automation capabilities, and you can apply policies on top. You can do a lot of things with these combinations and integrate other tools like PingFederate. We've likely saved some money, but I don't know how much. 

The solution has made our environment more controlled and robust. At the same time, functions become more challenging for users when you add more controls and multi-factor authentication. However, these measures are essential when you're dealing with a complex environment that crosses multiple regions and cloud platforms. 

I like Azure Active Directory's integration with GT Nexus, and it improves our overall security. Azure AD enables us to manage user access from a single pane of glass. We use single sign-on and multifactor authentication. Teams are required to have Authenticator downloaded on their devices. 

We use Azure AD's conditional access feature to fine-tune access controls and implement a zero-trust policy using authentication tokens. The calling application needs to verify those tokens. The tokens contain information that the application needs to verify. Every application or user needs to be registered in the system to access it.

In Azure AD, applications either use the managed identity or ARBAC for permission control, and we use SaaS on top of that. Policies can be used if there is anything else infrastructure or access-related. 

Permission management works the same way across all cloud platforms. You can have granular or course-grade permissions. It depends on what you want to use and how you want to use it. I'm on Azure, so I know how they use it. 

Azure AD could be more robust and adopt a saturated model, where they can offer unlimited support for a multi-cloud environment.

I have used Azure AD for two years. 

I rate Microsoft's support a nine out of ten. We are preferred partners, so we get high-priority support. 

Positive

I rate Azure Active Directory an eight out of ten.

The primary use case is for the authentication of the users. We actually onboarded around 3000 to 4000 users at our go live, which are various application users from across the US and the other regions.

The best feature is the single sign-on provision for the various type of users. That is our sole purpose for working on that and utilizing that service as creating a custom solution for a single sign-on would be difficult when we have around 50 applications within our company that has been used by users across the globe. That includes North America plus Europe, Russia, and the Middle East. It is very difficult and complicated to do things on our own. Instead of doing that, we just acquired the service from Microsoft for single sign-on, and for that purpose, we are using the Microsoft Azure Active Directory authentication.

From our utilization perspective, they are providing almost everything. That said, the customization, like the data sharing between the application, is something that needs to be improved from their side. For example, we are sharing certain types of data. We have a container application structure, so we have a single sign-on application where we are using the Active Directory authentication, and when the user clicks on that application, the information of that user is passed to the child application, and the child application does not authenticate the user again. That is a single sign-on concept, which is available across 50 applications within that container. We pass a lot of various types of data, therefore, there's a limited capability of doing that in Microsoft Azure as, on the Azure Active Directory, we may be able to create some additional attributes, however, there are certain limitations.

Technical support could be better.

I haven't explored all aspects of the solution just yet. There's still more to look at.

We've been using the solution for as far as our last project, in which is currently being used. We have been using it for the last four years.

This is a stable solution. Since our product went live in 2017, we never got an issue with respect to authentication.

The product is scalable. It is not even region-specific. You can change the region. For example, if you want to target European users, you can simply purchase a plan for a European server or something like that. Currently, I know that our application is running in the United States region, and our targeted users are from the United States, so our application is working in the North American region, the east area.

Technical support is a thing they need to improve a lot from their side.

The engineers from the Microsoft side are professional, however, the thing is they're working on the shifts. For example, if you encountered an issue which is affecting our production application, and we talk to a guy from Microsoft in Central Standard Time. While he will be available then if the issue is ongoing for more than eight hours, which exceeds their standard working hours, he will just put a hold on the call and will say that my next representative will get back to you on this issue, and when the next representative arrives you kind of need to start over.

Neutral

The Active Directory just plays a role in authenticating the user, and it doesn't do anything else, just authentication. The services where the deployment is being done, that is a different thing. It is an application service in itself. We have an Azure Active Directory service. Besides that, we have application deployments or application services on Azure as well. That is a separate service, which is used for the deployment of the application, so when a user is accessing the application, he is redirected to the Microsoft Azure authentication application where the authentication is being performed. So far, the authentication has been performed, and that user is being redirected to our actual application, which has been deployed on the Azure service. Therefore, there isn't really a direct deployment per se for this product.

I'm not familiar with the pricing aspect of the solution. The client deals with that end of things. My general understanding is that it is quite expensive.

I'd rate the solution an eight out of ten. They do have an outstanding service compared to the competition.