I’m looking at getting some servers migrated to azure and I’m stuck at the first hurdle, whether to set up Iaas servers as domain controllers and use Azure AD connect and enable pass thru authentication or to set up Azure AD Domain services and create a one way trust back to on premise and set it up as a resource domain .
The environment at the moment has a tiered architecture, with all key resources sitting in a tier 0 network on premise.
I think what I’d like to know is what does AD use to send the traffic on a trust relationship, I think AD connect uses port 443 and are there any benefits for using AADDS rather than Iaas VMS with ad connect?
Thanks in advance and hope that makes sense.
To answer your first question, network connectivity / traffic, here is the traffic map that is necessary for active directory services forest trust, https://support.microsoft.com/en-ca/help/179442/how-to-configure-a-firewall-for-domains-and-trusts
the RPC requires a lot of ports, and you cannot restrict it to specific ports.
As for your second question, using AAD DS the benefits is mainly that it's a managed service, you don't have to patch or manage any of domain controller infrastructure like you would a DC VM. you also don't need to manage the aadconnect configuration. But in return, with AADDS, you give up a bit of flexibility. Such as, you are not a domain/forest/enterprise admin. as this is all managed by Microsoft. the other thing you give up with aadds is schema extensions.
here is a doc on comparing between aadds and adds. https://learn.microsoft.com/en-us/azure/active-directory-domain-services/compare-identity-solutions#azure-ad-ds-and-self-managed-ad-ds
Hopefully this helps you on your journey to decide which architecture suits you better.
Related
I'm currently in the process of moving into a properly hybrid on-prem/Azure setup. I have a test group of machines that are registered as hybrid joined, I have my AD connector going to Azure AD for users and systems. And I have write back setup. So - if a user logs into their Office 365 account, they can change their password, and it's immediately reflected for their email and attached SSO services. However, if their machine is off premises, their new password will not work to log them into their system.
This, I know, is because the system is looking for the on-premise domain controller, but I'm at a loss as to where to begin with telling the systems to authenticate against Azure components. I've recently read Moskowitz's book on MDM, Intune, Azure, but I feel like I've missed something in that book that covers this very thing. Any help on this would be helpful, since I feel like I'm missing something really obvious here.
Your machines need to be Azure AD Joined.
More detailed assessment and planning documents are provided at
How to: Plan your Azure AD join implementation
We are using a third-party IT provider that handles our network administration and domain accounts, but as part of moving to a different office and setting up new infrastructure, we are considering dropping that and using Azure Active Directory only.
Researching the topic online seems to indicate that Azure AD is not a complete replacement for on-premises Active Directory, as things like local resource access and group policies outside of Azure would be missing. However, we are moving towards using Azure for most things (file storage, etc), so that should be fine if we still have that functionality there.
Before finalizing the decision to go in that direction, we just need to be certain of a few things:
1) Is there a way to create a new account in Azure AD so that it can be used to login from any machine in the office, without having to create it locally first and then connect the two?
2) Is there a way to sync user data, such as user/desktop files, across any devices the account is used to log into?
3) Is it possible to have an office printer configured in Azure so that it can be used with an Azure AD login, completely independent on any on-premises setup (i.e, not Hybrid Cloud Print, which seems to require an on-premises network/AD to be joined with Azure AD)?
The goal is to be able to log in and work from any internet-connected device, whether in the office or at home, without needing to use a VPN and/or remote desktop, and forego on-premises AD administration.
This is possible as long as the device is joined to Azure AD. Once the device is joined to Azure AD, then newly created cloud-only users can also login to the devices.
Ref: https://learn.microsoft.com/en-us/azure/active-directory/devices/concept-azure-ad-join
Enterprise state roaming should help in this aspect. It might not cover everything you are looking for but the important app-specific data and user settings are synced.
Ref: https://learn.microsoft.com/en-us/azure/active-directory/devices/enterprise-state-roaming-overview
There is no direct solution from Microsoft for pure cloud scenarios. There are few 3rd party services offered for this.
Ref: https://appsource.microsoft.com/en-us/product/azure/printix.64182edf-4951-40d5-91c8-733e1c896b70
Hope this helps.
I have to implement Single Sign on with following user case:
We have three kinds of users:
1) Corporate employees [Stored in Active directory]
2) Clients can access our application
3) We have hosted separate application for each client and clients employees can access this application [hosted on our server] and number of employees can be have million.
So we cannot store use credentials in active directory because we need per user license to use.
Please help me to find better solutions
ADFS only works with AD. The next version of ADFS will work against LDAP so that's a possibility.
I would look at Azure Active Directory (you could use something like AAD Sync. to migrate your existing AD users) or something like OpenAM or PingFederate (both of which are Java based) which you have to pay for or something like shibboleth (Java based but open source). These all support LDAP.
Or if you want to go the SQL Server route, look at thinktecture's identityserver.
I've generated an AD-LDS instance on a Windows Server 2008 R2 and successfully connected to it via ADSI Edit on a windows 7 machine (both computers are situated on the same domain).
My goal is to create a lightweight .NET program that will be run by all domain users and determine whether a specific user can or cannot perform a certain action (roles & groups).
So far i've managed to write most of it, but i'm now facing a small security issue: althought no credentials are required when running from the server itself, when running from another user (in the same domain, ofcourse), LDS connection requires the instance's administrator credentials - and i'm not too keen to leave this kind of thing lie around in my code.
I've search the web quite a lot for a way to bypass that (Active Directory binding? / SimpleBinding?), but all solutions i found involved SSL and certificate installations.
Is there a simple way for a user in the domain to connect the LDS instance without exposing his/the server's credentials?
Thanks.
Have you looked at permissions in the instance itself? There are groups you can add principals to. It sounds like you're running the code locally as the user that installed LDS which by default gets all sorts of perms, but other users were not granted enough rights (secure by default and all that).
I found a Microsoft support article that describes the exact scenario except the article addresses Server 2003 instead of Server 2008R2: http://support.microsoft.com/?kbid=830576 .
The resolution in the article is to establish a two way trust between forests so the trusting domain can access the Kerberos key server in the trusted domain. That is unfortunately not a possibility in this network.
I'm hoping there is some other way to get Kerberos happening between these two domains even though the trust is only one direction.
The link says it straight out: you need a two way trust. No other option. This is how we do it with tens of subdomains.