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.
Related
I'm not able to access any tabs in AAD. What could be the issue?
Please check if below points can be worked around in your case.
Buttions or options being greyed out maybe because , you may not have had global admin rights/user administrator rights on the azure AD tenant. There are a few roles which can create users within the directory. You may not have any roles within the directory which permit the operations.
Reference: github issue.
Even in Azure AD free edition ,one should be able to create the users if you have proper roles .
On completion of the first 30 days of Microsoft Azure’s free trial,
your ‘Free Trial’ Azure Subscription will be disabled. To fix this,
the subscription needs to be changed to the ‘Pay-As-You-Go’ plan
instead of the ‘Free Trial’ plan which it is currently on.
For example :For applications under Enterprise application, one of the following roles: Global Administrator, Cloud Application
Administrator, Application Administrator, or owner of the service
principal.
You can check Azure AD built-in roles, and by checking the
description of role , assign the required one to manage identity .
You can Assign Azure AD roles to users to manage the identities
if you have global or role administrator rights. Approach the
admin to assign the roles .Also see custom roles in Azure AD
if needed.
Please check if this issue in - Microsoft Q&A can relate .
If issue still remains you can raise a support request in troubleshoot+support blade.
we have an on premises Active Directory. The environment got hacked and domain controllers were restored to a backup that is clean according to forensic people.
For better explanation, let's assume the hack occurred on October 1st and the backup it got restored to was from September 1st.
All local accounts that were created and synchronized before September 1st are fine. All local accounts that were created and synchronized between September 1st and October 1st are lost on premises.
A new AADC instance has been installed, configured and is synchronizing happily. For some reason, the accounts created after September 1st and before October 1st were not deleted in the cloud when AADC started synchronizing again. We do not know why. They do not exist on premises any more though.
These local accounts are supposed to be created again, so they can access on premises resources.
I looked at Microsoft documentation about soft/hard matching in AADC: Azure AD Connect: When you already have Azure AD | Microsoft Docs
It states that object newly imported to AADC will be hard matched or soft matched if possible and afterwards, AAD will mark them as " Directory synced". It also states:
The match is only evaluated for new objects coming from Connect. If you change an existing object so it is matching any of these attributes, then you see an error instead.
My question is: If we have those accounts in the cloud that are marked as "Directory synced" and create them on premises, will this be considered as a "new object" by AADC and hard matched or soft matched? Or will this cause duplicate accounts in the cloud or the error mentioned above?
If we stop the AADC sync service locally, create the accounts on premises and assign those newly created on premises accounts the same "sourceAnchor/immutableID" value as the cloud object and restart synchronization, will this work or will it cause an error?
Thanks!!!
• First, reverse synchronization, i.e., synchronization of user identities from Azure AD to on premises AD is not possible as of today even using Azure AD Connect. There are only few attributes that can be written back, and that's mostly for hybrid configurations, and passwords if you have the corresponding feature (and licenses) enabled. So, in your case, if you have enabled ‘password writeback’ and ‘password hash synchronization’ in Azure AD Connect, then only you can edit these properties of the users in on premises through Azure AD. Also, if that’s what you want, you can simply export the list of users via PowerShell (Get-MsolUser/Get-AzureADUser) or the Graph API, along with any relevant attributes, then use the exported data to recreate them in AD (again, PowerShell helps). You cannot export passwords. Once the export/import is done, you can "match" the on-premises users with the cloud ones and give them the SSO experience. The process is known as soft match. The other type of syncing between both the environments is called hard match. You can find more details in the link below: -
https://learn.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-install-existing-tenant#sync-with-existing-users-in-azure-ad
• But there is a way you can try as given in the links below by creating those users who were created during that month whose backup isn’t available and ensuring their domain suffix and email as well as alias attributes are identical to those as synced in Azure AD during that month. Thus, when you create users identical, primary SMTP, email, alias, and domain suffix, you may be able to sync these users’ identity once again to the same identities synced(created) in Azure AD earlier. Please refer the links below for detailed steps to follow: -
https://support.microsoft.com/en-us/topic/how-to-use-smtp-matching-to-match-on-premises-user-accounts-to-office-365-user-accounts-for-directory-synchronization-75673b94-e1b8-8a9e-c413-ee5a2a1a6a78
https://www.slashadmin.co.uk/how-to-sync-an-existing-office365-tenant-into-a-new-active-directory-domain/
If users once synced with Azure AD Connect Cloud Provisioning can be moved to synchronization via Forest trust without having to remove and re-add the users?
Cloud provisioning can be used to sync from multiple Active Directory forests. In the multi-forest environment, all the references (example, manager) need to be within the domain. Users and groups must be represented only once across all forests.
Kindly check the document for Azure AD connect cloud provisioning supported topologies to get detailed information about this
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.