Microsoft Entra ID Reviews

Usually, it is replicating an on-prem Active Directory environment into Azure. It is usually tied with generic email access and SharePoint Online access and building out provisioning for that. There typically is some sort of synchronization tool that is sometimes used in addition to or as a substitute for the typical Microsoft suite. So, it just depends upon the customers and how they're getting that information up there.

In terms of version, it tends to be a mixed bag. It just depends on the client environment and factors such as the maturity and the rigors of change management. Sometimes, it just lags, and we've dealt with those types of situations, but more often than not, it is more of a greener field Azure environment and tends to be the latest and greatest.

It certainly centralizes usernames, and it certainly centralizes credentials. Companies have different tolerances for synchronizing those credentials versus redirecting to on-prem. The use case of maturing into the cloud helps from a SaaS adoption standpoint, and it also tends to be the jumping-off point for larger organizations to start doing PaaS and infrastructure as a service. So, platform as a service and infrastructure as a service kind of dovetail off the Active Directory synchronization piece and the email and SharePoint. It becomes a natural step for people, who wouldn't normally do infrastructure as a service, because they're already exposed to this, and they have already set up their email and SharePoint there. All of the components are there.

Its area of improvement is more about the synchronization of accounts and the intervals for that. Sometimes, there're customers with other network challenges, and it takes a while for synchronization to happen to the cloud. There is some component of their on-prem that is delaying things getting to the cloud. The turnaround time for these requests is very time-sensitive. I don't mean this as derogatory for this service, but in my experience, that happens a lot. 

For the Active Directory component, there are some value differences and things like that as compared to on-prem. I have run into problems a few times when there is a custom schema involved with their on-prem installation. You can use it, but that custom schema or functionality is going to have to go somewhere else or rerouted back to on-prem.

I have been using this solution for probably two and a half years.

It is perfectly stable. I haven't had any concerns or any problems with that.

I have dealt with them. Overall, tech support is great if you have something that was working but it's broken and needs to get fixed. It is a different bucket if you have more of an implementation question like, "Hey, can we do this?", or "How to approach that?" Sometimes, it can be challenging to get the right people on that call to support those conversations.

Its initial setup really depends on the customer. I have one customer right now with a super simple environment. They're just replicating it up. It's all Microsoft stack top to bottom with no real surprises or anything else. They're happy as pie with that. 

I have larger customers who tend to want some sort of management layer on top of it for Active Directory management purposes. This tends to go into the cloud, which introduces its own little challenges. In a more sophisticated enterprise, I start running into custom schema or workflow dependencies that just don't translate well from on-prem to cloud, but it is rare. It usually ends up being a third-party solution that we route them to with that. So, it's not huge. The challenge is more in identifying that. Typically, as much as we try, we rarely get it identified early enough to change our statement of work or our implementation, so it becomes a bad surprise.

Its price is per user. It is also based on the type of user that you're synchronizing up there.

I would advise spending more time on planning and aligning your business processes with Active Directory and Azure in terms of custom schema and separating third-party accounts, external accounts, or customer's accounts from employee accounts. I've run into issues when people take an existing on-prem solution that has third-party entities or maybe external customers and start synchronizing it up. It is not a slam against the service, but that's where I start recommending people to do different instances of Azure Tenants to break that up a little bit and provide that separation. All of these are planning functions. Using this service can be deceptively easy, but you should spend more time on planning. Around 80% of it is planning, and the rest of it is the implementation.

I would rate Azure Active Directory an eight out of 10. It is super solid. I wouldn't say it's the best. I would love to have everything that you could do on-prem. I understand why it can't do that, but I would love that flexibility.

The primary use case is collaboration. So it's all about federation of identity and permissions.

Identity is one of those things that you need to be separate from your actual tenant. There's a benefit for it being separated from your actual tenant for reasons of security and containerization. 

It's very easy to run and it's part of their ecosystem and I don't think it's going anywhere anytime soon.

Back in '96, '97, '98, nobody was doing intake. So that was a new thing that came in 2000. And it created the container based inherited permissions, which was new for that stage. Before that it was very static, there wasn't inheritance, there wasn't assertions. Then they introduced that and they've slowly built it, and then it just got too big and old, and really the database that MT's on is just vulnerable to all these attacks. And that's primarily why they want people to get off it. There's about four or five open attacks that make it very easy to both intercept the credential requests, and also attack the database itself.

The ability to speed up delivery is a nice benefit, because rather than having external dependencies there's a certain guarantee that if you use anything within that technology platform. Whether it's full of applications, or various other things, there havee already been regression tests by the vendor. And you don't see the same defects that you get when you have integrated systems.

The fact that it's an ecosystem in itself is probably the best one. It fits into the whole Microsoft stack. Everything this year is all about stacks, and I tend to agree. The inter-operability  and complexity of things these days is just too big. These things change too much. So you don't really want to be stuck between three technology stacks that are changing. If there's a defect, you won't know which one it's in. Trying to hold the service provider to account is quite hard. I'd probably say, yeah, stay with the stack if you can.

I guess price would be the thing, and some of the proprietary lock-in. But, I guess documentation and support would be good.

The features are fine. I wouldn't suggest any features because you can keep adding to it. But, its simplicity is that it works under its own ecosystem. It's nice and reliable. If you start adding all these extra things to it, it'll probably cause complications with some of the legacy things that are still slowly just hanging onto them. But, to look at more documentation, engineering, or an open standard would be nice.

It's like any technology. It appears that if it did have stability problems they don't really exist anymore in the same way. It's like any introductory development technology. Because its identity, it has to be perfect. It is either secure, or it's not, and unfortunately there's a million ways for things to go wrong and there's only one way for things to go right when there's no give. You do see a lot of issues with it at the beginning.

It is mathematical. So, it's like most things. Took a while to get the XAML certificates and all that sort of stuff working. But,now it's a very common thing. You get a session certificate on your phone when you're doing things. When you join a session on your browser on your mobile phone. It's just very common things now.

I'd say there's about 5,600 users of this solution in our organization.

There are set rules. But, it's a security mechanism. If you try and get your swipe card pass for your office, and then you try and integrate it with one across the road, they're literally being designed not to integrate with each other by design. This is because if you want it secure, you don't want to have it integrate. The same thing works with changing the posture of something after you've initiated it. Expect this sort of behavior.

The tech support is OK. I'm talking more about the engineering structure of it. As I said, you can understand why security things have a tendency to not document it, because it's one of those things. Do you want more people to review it and make it harder, or do you want to covet it and reduce the exposure of it?  It's catch 22. You're damned if you do, damned if you don't. Doesn't matter which way you go.

We have prior experiene with Novell. 

It's easy in its essence, but part of the ease is like anything that seems easy is generally complex when you try and fix it because you've skipped over so many configurations. It's like a wizard that you go, "Yep, it's done." And then it breaks, and you say to yourself, "Oh, hang on, I clicked one button. How could I have done that differently?" It's a lot more stable than it used to be. They've got into a maturity plateau where they're not developing it anymore within for reasons of functionality and the product doesn't really break much.

There's no such thing as a "free lunch." If you'd save money here, it costs money there. If you pay more upfront, you pay less when you get off. The market equals itself out, like a free market. So, it generally does. It's more about convenience at the end of the day.

As a user, I'm not an owner of the tech, so as a consumer, even if I am a specialist, I still don't own the technology. I just want to lease it, subscribe it and make sure that the owners of it are able to meet the facilities of it in its life-cycle.

There's a couple of other options on the market like Okta, and a few things like that. They're quite simple, and because they're separate from the whole Microsoft ecosystem, they do have some benefits in that they're completely focused on only that product and only that requirement. With Microsoft, they're like an octopus. They have so many different requirements and priorities that sometimes they don't invest all their energy into the products that you have expectations to investigate.

Last year Microsoft had said that the onsite Active Directory ,as we know it, is going to be deprecated. So that means group policy, that means security groups, the NTLM and all that  we've relied on for so long is going to come to an end with this modern management philosophy. That's why I did those group policy changes. From group policy, which is essentially the ability to control the operating environments of managed devices, rather than that, Microsoft wants only a mobile device management policy. So it's pretty much a HTTPS or SSL assertion to manage devices off the domain, and they will all come from Intune.

So, they're not going to be managed by a set of static policies. They're going to be set by a whole heap of compliances. Does that make more sense? It's not conforming. It's when you assert yourself, and us for a particular requirement from the domain. They check your requirements per request, which takes the load off the environment quite a bit. So they only validate you when you ask.

It's a lot easier to get an engineer to understand the Microsoft stack then some esoteric random "Joe." There's just are not enough people in the field.

You're better off creating a pilot tenant on your own. You can set up one that's free using one of their 30 day trials, and while you're doing that try and make it as realistic as you can to the environment you're coming from. Make sure that it is true in terms of network, commissuib and integration. If you're going to use a MDN for mobile device management, or you're going to use applications for the federated sign-ons. Try and get as much as you can in it. You've got 30 days and they're quite liberal with allowing you to trial it.

Most of the capabilities are there internally. You can't expose external DNS names or anything and use it as an external platform, but internally you can. So spin up a VM or something internally and do the same things you would. I'd dare say: test it and prove it. You've got to prove it to yourself before anybody. I wouldn't trust anything from a brochure or anything else. Your reputation's on the line. You're doing something important for someone else and you've got to verify it yourself and put it through the paces. Spend enough time doing proof of concepts and pilots.

We use it as the Active Directory on the cloud. We have the systems on-premises and on the cloud. We connect the AD data to Azure. We have a single sign-on service on multi-cloud. We use the single sign-on feature on, for example, AWS.

In terms of the version, we use it as a service, and it is always updated to the latest version. 

Microsoft Entra ID helps to synchronize information from on-premise Active Directory. There are security features such as multifactor authentication. We can also use a single sign-on to connect with the other application on the cloud. 

It helps our admins to have more security. It is helpful for authentication methods, log checking, and audit trails in case of security concerns. However, it has not saved them time.

Microsoft Entra ID has not helped to save our organization money, but it helps to improve security.

The security features, multi-factor authentication, and service management features are valuable.

Microsoft Entra ID provides a single pane of glass for managing user access. Its menus are properly categorized, and they make it easy to use for our work and processes.

One thing that they need to improve is the cost. It already has a lot of features, but more protection of the identity would be beneficial for customers.

I have been using this solution for three years.

It is stable.

It is scalable. In our environment, we mostly have Microsoft solutions such as Microsoft 365, email, OneDrive, SharePoint, Power Apps, etc. Entra ID is deployed across multiple locations for multiple users. We have a Microsoft 365 license for all employees. We have two admins who take care of configuration and monitoring for security and data loss prevention. 

We have plans to increase its usage.

I have not contacted their support.

We did not use any other similar solution previously.

I was not involved in its deployment. 

It is costly.

I would recommend this solution to others. Overall, I would rate Microsoft Entra ID an eight out of ten.

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.

Identity verification would be the number one use case. It also factors into mobile device management for devices that aren't registered to the company. We use MFA, and the Authenticator app is a component for multifactor authentication. So, that's why we use it.

You can set policies to specify where users will have to use the Authenticator app to log into particular applications. 

It makes all junior users accountable. There is no excuse for someone else logging into anything because of the multifactor authentication and Authenticator app. You have to verify your identity to log in to specific applications that contain confidential information, especially in a HIPAA-compliant environment.

It enhances security, especially for unregistered devices. It 1000% has security features that help to improve our security posture. It could be irritating at times, but improving the security posture is exactly what the Authenticator app does.

For the end users, it can be confusing if they have worked for another company that had the Authenticator app. It is tricky if they have already had the Authenticator app and then work somewhere else. If they have to download it again and use it again on their phone, it is something that gets complicated. I know how to get through it. They just need to uninstall and reinstall the application, but for them, sometimes, it is confusing. You can have the Authenticator app for multiple services on your phone, and that's what drives them crazy. They get a code and say "I'm using the code for the Authenticator app, but I can't get in." I tell them that it is because they already had it in, but it is for something else. They now have to add. They don't like that at all. You could be on the phone for 45 minutes trying to figure out what their problem is because they don't.

Instead of authenticating by getting a passcode or answering the phone, fingerprint identification should be added to the Authenticator app. Currently, with the Authenticator app, you have to reply to the email, enter a code, or answer the phone. It can just call my phone and then I just press the button to verify that this is me.

I have been using this solution for at least six years. 

It is very stable. If the Authenticator app is set up, you're not going to get into anything without it. It definitely works.

I'm not aware of any bugs or glitches. We usually run updates for the whole environment at a time. I'm not familiar with having run into specific bugs with the Authenticator app. I haven't had any problems over the years.

I've managed over a hundred thousand users in total, but right now, there are about 10,000 users. We are HIPAA compliant. So, everybody has to use it for everything. They have to use it to log into everything under the Office 365 environment, but in other companies or other places where I worked, it was only for specific applications. So, that's based on company needs.

I never had to call technical support for this.

We were using normal MFA, which is similar. The Authenticator app is for mobile devices per se, but normal multifactor authentication doesn't have to focus on mobile devices. You can try and log in to, for example, SharePoint Online, and if MFA is activated, you would have to just scroll to your email and click, "Hey. Yeah, this is me." The Authenticator app is just for mobile devices in my eyes.

It is straightforward for the admins, but end users hate it. On the admin side, it takes 20 minutes at the most.

The Authenticator app wants you to have all your prerequisites designed for whatever environment you want. If you're going through Azure, you can pick the particular applications on which you want this. You can also pick the users for whom you want it to be effective. You can pick the type of ways they authenticate through the Authenticator app. Those are the simple steps.

One person is enough for its deployment and maintenance. I do that. That's not even a role. It depends on who you are, but that's not a role. That's not something for which I would employ a person. I wouldn't employ an IT person or an administrator just to focus on this.

I don't pay for it. Going by how I feel, I see the prices for any MFA solution going down because the more different alternatives there are, the cheaper things should be. Microsoft Authenticator app would be the preferred application, but there are too many ways to implement MFA. I don't know how much it cost, but the price should go down.

It is pretty seamless for the end users, besides the end users having an issue setting up at times.

It is a seamless transition. It is straightforward on the admin side to set up. As a consultant, my advice to any company is that when it comes to big changes, manage end-user pain or frustration. Communicate with the end users and let them know what's going to happen. Explain to them that they're going to be frustrated, but explain why this exists. 

I understand why it exists. So, it doesn't bother me, but our end users just hate it. I understand that they don't like it. Nobody likes it, but it is needed. You are never going to meet an end user who likes any type of MFA, but you need to be more clear about its purpose.

I would rate it an eight out of ten.

We use Azure Active Directory to add authentication for users when they sign into the applications. We also use it to provide single sign-on (SSO) to applications.

What I like most about Azure Active Directory is its SSO (single sign-on) feature, as we have a community of users with different IDs and passwords, and this feature helps integrate all these. 

I've been using Azure Active Directory since 2016.

Azure Active Directory is a very stable solution.

Azure Active Directory is scalable.

The technical support for this solution is fine.

Installing this solution was seamless, but it took time for it to complete. It took one month.

We used an integrator to deploy Azure Active Directory.

Azure Active Directory has different licensing plans. We're on a yearly subscription. It is expensive, but if you look at the technical benefits it provides, the price for it is decent. If the cost of the license could be lowered, then it would be better.

Azure Active Directory is a cloud-based solution in which we have done our integration with our applications.

We currently have five or six different teams using this solution. We have three people with admin rights, 3 technicians, and a technical team. Some users have admin rights, e.g. general admin rights, while some have basic rights.

Our plan to increase the usage of Azure Active Directory depends on how many new employees will join the company. It could happen.

I'm recommending Azure Active Directory to other people who want to start using it because it meets requirements.

I'm giving Azure Active Directory a score of 10 out of 10.

We're using Azure Active Directory for MFA.

It is very usable and easy to use.

It is easy to manage. I can manage systems with policies and automate our systems. Any professional system can be easily integrated with Azure Active Directory. It is widely used with Windows versions. 

Four years ago, we had an issue with Azure AD. We wanted to reverse sync from Azure AD to on-prem Active Directory, but we couldn't achieve this. Azure AD could connect only in one way, for example, from your site to Azure. If you needed to do the reverse and connect from Azure to on-prem, there was no way to achieve it. We asked Microsoft, and they told us that they don't support it.

Their support should be faster and more knowledgeable and customer-friendly.

I have been using this solution for maybe four years.

It is very stable.

It is very scalable. I don't know about the number of users that we have currently, but at the time I managed its synchronization, there were maybe 800 users. 

We're not satisfied with their support. We couldn't get support from Microsoft directly, and we made an agreement with a company. We weren't satisfied with their support. They were very slow and not friendly. They couldn't solve our problems because our program was very complex.

I didn't use any other solution. I only use Active Directory and Azure AD.

I installed hybrid Exchange. It was very easy for us. Its installation took a very short time. There was a connector system on Exchange, and we just had to set up the connection. It was very easy.

I installed it myself.  

Its maintenance is very cheap and easy. We have only two engineers to manage Azure AD and Azure Exchange.

We have an agreement with Microsoft, and my company pays yearly.

It is a very good product. I plan to keep using it because it is very easy to manage.

If you use an application in Azure and you want single sign-on for Azure products, you should prefer using Azure AD. You should synchronize your on-premise Active Directory to Azure AD. We synchronized Active Directory with Azure AD for single sign-on. For example, if a worker wants to sign in on your computer with the same user ID and password, he or she can connect to Azure services. Azure AD provides support for this.

I would rate Azure Active Directory a nine out of 10. 

We use it for the authentication of people in a hybrid configuration. In most cases,
Office 365 makes companies move to Azure Active Directory.

We have both on-premises and cloud deployments.

Its ability to provide secure connections to people at all locations is the most valuable. It is mostly used by enterprises.

The onboarding process for new users can be improved. It can be made simpler for people who have never registered to Azure AD previously and need to create an account and enable the MFA. The initial setup can be made simpler for non-IT people. 

It should be a bit simpler to use. Unless you get certifications, such as AZ-300 and AZ-301, it is not a simple thing to use at the enterprise scale.

I have been using this solution for four or five years.

I never use technical support. I usually find the information on my own or through my friends at Microsoft.

It is not complicated for me as an IT guy, but the feedback from the field or non-IT people is that it could be simpler.

MFA and P2 licenses for two Azures for fully-enabled scenarios and features cost a lot of money. This is where Okta is trying to get the prices down.

I have spent seven years at Microsoft, so I have a tendency to like Microsoft solutions because I know them and the philosophy behind them. Till now, Azure AD is probably the best solution for identity and security.

I also use Okta. For integration with Microsoft solutions, Office 365 Azure is just right. However, for some scenarios, such as consolidations, Okta seems to have a few advantages as compared to Active Directory. Okta also has a very interesting price.

I would rate Microsoft Azure Active Directory Premium an eight out of ten.