Cloud Consultant at a tech vendor with 11-50 employees
Consultant
2018-11-12T09:12:00Z
Nov 12, 2018
If you have connections with a PSP partner, it will be easy, I guess. If you're buying an Azure AD Premium independently, you won't have a helping hand from them. You'll have support but, not much other than that. With a PSP partner, you will feel like that you can implement or you can quadrate. Once Azure is developed, and fully established, it will be a perfect product. It is still in the development stage at present.
I don't know if it's something that's going to be addressed in the future, or not, but having Azure AD the boundary of action for Active Directory as a region when you define the domain so you can't extend the domain to another region because it's a limitation that Azure AD has that doesn't allow you to extend the domain to another region for say geolocation purposes or disaster recovery. If you have your Azure AD on the Sydney data center, you're not going to be able to extend that to say, Singapore. But, it is not highly unlikely, but it's a very rare occasion that you lose a region or a whole data center. It can happen, obviously, but it's very unusual. So the chances of that happens are very low. When we did the design for this customer that was one of the limitations that we mentioned, and they were happy with it because you know Microsoft is a respectable company and obviously they would do the best to keep their data centers running all the time. And, to keep the cloud infrastructure for their customers online all the time. So they accepted the limitation or the risk and we went ahead and did it. But that's definitely something that I notice as a limitation to me. In my opinion, you have a good look at your current infrastructure and make a decision on what is fit for the cloud, and what is not, because there are certain applications, or certain systems, that it will take longer time to migrate to the cloud. Normally, this is a good approach and is actually the Microsoft approach, as they recommend you to go hybrid first. First, you do a very good assessment and then you migrate your on-prem AD to Azure AD and the systems that support your operation will follow in time, if remediations are required, but it is a journey to work better and more efficiently.
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.
The biggest piece of advice is if you're planning for all applications that need authentication, and making sure that all applications that need authentication or that you're going against, that you're using the premium parts of Active Directory for, are compliant with the solution and not finding out afterwards.
Senior Technical Consultant at a tech services company with 51-200 employees
Consultant
2018-11-11T13:13:00Z
Nov 11, 2018
When implementing for one client, where they ad ADFS turned on, we could not ID enough ADFS and when there was no internet connection. This was a Catch-22 for us, and very frustrating. I would advise new users to use Azure over the ADFS.
Microsoft Entra ID is used for extending on-premises Active Directory to the cloud, managing application access, enabling multi-factor authentication, and single sign-on. It facilitates policy enforcement and secure access, ensuring centralized identity management across cloud and on-premises resources.
Organizations utilize Microsoft Entra ID for robust user and group management, identity synchronization, and conditional access. Its seamless integration with third-party apps,...
If you have connections with a PSP partner, it will be easy, I guess. If you're buying an Azure AD Premium independently, you won't have a helping hand from them. You'll have support but, not much other than that. With a PSP partner, you will feel like that you can implement or you can quadrate. Once Azure is developed, and fully established, it will be a perfect product. It is still in the development stage at present.
I don't know if it's something that's going to be addressed in the future, or not, but having Azure AD the boundary of action for Active Directory as a region when you define the domain so you can't extend the domain to another region because it's a limitation that Azure AD has that doesn't allow you to extend the domain to another region for say geolocation purposes or disaster recovery. If you have your Azure AD on the Sydney data center, you're not going to be able to extend that to say, Singapore. But, it is not highly unlikely, but it's a very rare occasion that you lose a region or a whole data center. It can happen, obviously, but it's very unusual. So the chances of that happens are very low. When we did the design for this customer that was one of the limitations that we mentioned, and they were happy with it because you know Microsoft is a respectable company and obviously they would do the best to keep their data centers running all the time. And, to keep the cloud infrastructure for their customers online all the time. So they accepted the limitation or the risk and we went ahead and did it. But that's definitely something that I notice as a limitation to me. In my opinion, you have a good look at your current infrastructure and make a decision on what is fit for the cloud, and what is not, because there are certain applications, or certain systems, that it will take longer time to migrate to the cloud. Normally, this is a good approach and is actually the Microsoft approach, as they recommend you to go hybrid first. First, you do a very good assessment and then you migrate your on-prem AD to Azure AD and the systems that support your operation will follow in time, if remediations are required, but it is a journey to work better and more efficiently.
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.
Be aware that it may not work perfectly globally yet. There are still glitches with the solution in Africa.
The biggest piece of advice is if you're planning for all applications that need authentication, and making sure that all applications that need authentication or that you're going against, that you're using the premium parts of Active Directory for, are compliant with the solution and not finding out afterwards.
When implementing for one client, where they ad ADFS turned on, we could not ID enough ADFS and when there was no internet connection. This was a Catch-22 for us, and very frustrating. I would advise new users to use Azure over the ADFS.
I like it, I love it and it works fine.
It is easy to use, straightforward, and in my language. It does exactly what is says, and does not pretend to be anything else.