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
Related
Sometimes you ask yourself a question and cannot answer or google the answer.
Question:
Is there any way to turn a single "on-premises mastered Directory Sync objects", to a "cloud mastered object"? Specificly a user account.
Can I revert this if I try with a real account?
And the major question: Thoughts about the consequences?
Background:
We move more and more processes to the cloud and I am beginning to "feel the need" for changing this. So I want to investigate the consequenses of changing, what breaks and what makes the change (if possible).
We have:
Office365 (mail,sharepoint, etc), onprem ADFS, AzureAD Sync. I am most worried about ADFS, since the account must be able to authenticate onprem. ~20.000 users and a applications onprem of all sorts.
As you aware in synced identities objects are mastered in our on-premise AD structure and cannot change it. If we need to make changes and edits to any of our users, this needs to be made on our on-premises AD structure. Once those changes are made, Azure AD Connect will then synchronize those up to Azure AD, and you'll see those changes after the next synchronization run.
Mostly Azure AD Connect assumes you start with a new Azure AD tenant and that there are no users or other objects there. But if you have started with an Azure AD tenant, populated it with users and other objects, and now want to use Connect, then kindly check this link.
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.
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 believe Windows auth is the best practice to use to connect to SQL DB. I am hear talking about application user account..
Is it true that SQL auth is only great for multiple role apps and window auth is only good for single role app? I never heard that windows auth with muitple role os only good for smaill internal app?
multiple Windows logins = multiple connections = no pooling = poor scaling?
The problem with using Windows auth for a web application is that many web applications store their application users' credentials in the same SQL database that is used for other application data.
So you have a chicken-and-egg problem. You can't authenticate the user before connecting to the database, and you can't connect to the database without authenticating the user.
It should be possible to use Windows authentication, and then also have application-specific attributes of the user stored inside the database. But most people find this cumbersome to administer, and also limiting to portability of the application.
For example, if one of the feature of the application allows users to change their own password, then the process running your web application needs the privilege to alter a Windows password, which may mean that the application needs to run with Administrator privileges.
If you let the application manage user ID for the context of the application, then to change a user's password is just an SQL operation, and your application is in charge of enforcing security for that.
I'm not sure what you mean by single-role and multi-role app. I have built apps before where there are multiple SQL Server Database Roles, each with a Windows Domain Group of users allowed in that role. So user management is completely within Active Directory, with a 1-1 correspondence between the Domain Group and the Database Role.
We typically did not manage the security within the application itself except obviously declaratively during the database creation where each object was granted access by particular roles according to the design. Typically, in a simple case, we relied on db_datareader role being granted for general usage to non-specific groups of users like database and network administrators for troubleshooting or report-writers or business analysts for ad hoc reporting. Actual users of the app would be granted execute on the relevant SPs to be able to modify any data (so all data creation or modification was through SPs and only explicit members of the ThisAppsUsers AD group could do it). Any advanced SPs (say, merging or deleting accounts) would only be accessible by ThisAppsAdmins AD group. And that was usually all we needed for moderate-sized applications. For more complex functionality, it was also possible to interrogate AD directly for custom attributes (user is an admin only for this customer account but for others is just a user)
This same technique can be used with SQL Server logins, but of course the individual SQL Server logins have to be added to the database roles, and you don't have the richness of AD and have to build some kind of directory service into your database.
The ability to even use AD may not be possible for many applications, so in that case, the security architecture would obviously have to cater to that model.
using the integratedSecurity=true option for SQL JDBC , by including the JDBC auth .dll, should give you database connectivity without authenticating...