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/
Related
I have a specific problem to which I couldn't find any answer online.
The situation is the following:
We created a Canvas app that connects to the Azure SQL database. We set the connection type to be AAD integrated.
Users that are members of the AD can see the data in the app, but guest users, even though we gave them all the rights and PowerApps plan, cannot see the data. they recieve the same authorization window as members, but when they click on allow, the app starts but no data is being pulled from the SQL database.
When we try to connect directly to the Azure SQL database with the guest user email and credentials (via SQL server management studio), everything works as expected and the guest can see all the tables.
When we use implicitly shared connection (with SQL server authentification), guests can see the data, but we need to use AAD integrated due to its security.
So far we tried:
Changing PA environment from sandbox to production
Adding special permissions in SQL database like database owner etc
Trying out different AAD guest user settings, eq- setting that guest users have the same privileges as members (picture below).
Nothing seems to work. I would be more than happy if you could tell me how to make this work or even push me in the right direction.
I've reproduced your problem in my side. Here's my experience.
After assigning powerapp license(I use O365 E5 here) to guest account and share the app to this account, I can visit the app but can't see the data in the table. I assume that it resulted from the connector hasn't been shared, but it's true that this connector can't be shared because of no 'share button'.
Then I tried to add access policy to my guest account with these two sql:
CREATE USER [tiny-wa_outlook.com#EXT##xx.onmicrosoft.com] FROM EXTERNAL PROVIDER;
GRANT SELECT ON dbo.tinyTest TO [tiny-wa_outlook.com#EXT##xx.onmicrosoft.com];
Pls note here, I used the User Principal Name here(can find the principal name in azure ad->users), I also tested to use 'tiny-wa#outlook.com' in the sql but after executing successfully, it didn't work.
So I think you can try to use the sql above to add your guests accounts and make them can access the powerapp.
Here's some related docs:
create contained users mapped to azure ad identities
Share app resources
add table permission to user
==========================UPDATE==========================
Share my experience of this troubleshot.
First I need to create a power app but I found that after creating the connector with sql server azure ad authentication, it can't connect to the sql server, the error message is like 'Credentials are missing or not valid. inner exception: The credentials provided for the SQL source are invalid', solution is add my admin account as sql server instance Active Directory Admin.
Then I choose a table and successfully create a sample app. With the creating account, I can visit the app but other accounts can't. Here needs to share the app and it's related connectors to other users. But other accounts still can't reach the app because of no license. Because sql server connector is premium connector, so I assign O365 E3 license here. I met an error when assign license, the user's 'Usage location' can't be null or it can't assign license in M365 admin center.
Then I met similar error with Op, the difference is that both member account and guest account can't see the data in app. I try to find the way to share the connector to these uses but failed, I haven't made sure if those connectors without share button can be shared to others. So I have no options to study if this kind of connectors are authenticated in other ways so they don't need to be shared at all.
Next actions is using the account which used to create the sql server and database to sign in database and execute the sqls above.
Then the member account can see data in the power app while the guest account can't see. The reason is I used xx#outlook.com as the parameter in the sql, when I used xx_outlook.com#EXT##xx.onmicrosoft.com, it worked finally.
Hope this can also help you.
===================================================
For creating my demo app: First, I'm sure my environment isn't a sandbox(the environment in the screenshot below). And I think it's easy to create a demo app, and my app is simple, just choose to create an app from data and then select sql server as the connector, next I choose auzre ad auth and click the connector, enter server name and database name then choose a table, after that my app has created. That table has one row of data so when I signed in the app with the creating account, I see it in the screen while other accounts(member or guests) can't.
My sql server instance and database are created long time ago, but I'm sure I followed this tutorial to create them.
This appears to still be a limitation to access to Azure SQL via PA connector for guest users:
https://powerusers.microsoft.com/t5/Power-Apps-Ideas/Azure-SQL-to-PowerApps-Connector-AAD-doesn-t-work-for-guest/idi-p/1637817
If the "guest" does NOT have a PowerApps Per-App/Per-User plan, they cannot use your PowerApps with SQL data source (Note: SQL is a premium connector).
Determine exactly which type of license the guest has. Then, either your organization or the guest (or guest's org) must purchase one of these licenses. $5/$10/$20 per month depending on your use case.
REF
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.
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 am using Redgate Data Platform Studio to transfer data from on-premise SQL Server to Azure-hosted SQL Server. This web-based application has the ability to use an Azure Storage account (for data transfer purpose) simply by logging into my company's ADFS. The web application can successfully see storage accounts inside a subscription (let's call it Subscription A) owned by my ADFS user, when I log in to my company's active directory (via ADFS). Let's call my company's AD Directory A.
I also have subscription B owned by a Microsoft account NOT related to my company's Active Directory. This subscription B is managed by another Azure AD Tenant B, with that Microsoft account as the Service Administrator & Owner. To link the two directories, I used B2B State 3 configuration described here. So in Directory B, my Directory A user shows up as Guest User with the Source=External Azure Active Directory.
For the storage accounts in Directory B, I grant the built-in role "Storage Blob Data Contributor" and "Storage Account Contributor" to the Guest User (source=external AAD Directory A). Therefore, in both Microsoft Azure Storage Explorer as well as in portal.azure.com I can see storage accounts inside Subscription B.
BUT if I log in to the Redgate application using Directory A credential (via my company's ADFS), only storage account inside Subscription A shows up in the Redgate application. I already tried giving the guest user in Directory B the following roles to the user, even at the highest Subscription B level, but no luck:
As Co-Administrator
As Contributor
As Storage Account Contributor
As Storage Blob Data Owner
My question: is this the application's limitation of not being able to access subscription in another directory (B), or is there some configuration either in directory A/B and/or subscription A/B that I need to set?
Is this the application's limitation of not being able to access subscription in another directory?
As per my official document and my understanding you cannot assign your subscription among many directory.
As said on official document "Multiple subscriptions can trust the
same Azure AD directory, but each subscription can only trust a single directory".
See the below screen shot and refer here
Note: When you associate a subscription to a different directory, users that have roles assigned using role-based access control (RBAC)
will lose their access. Classic subscription administrators
(Service Administrator and Co-Administrators) will also lose
access. Please check the Important Note here
If you want to know more details please refer this docs
When I try to deploy my SQL Server Analysis Services project to the server, I get the error message No mapping between user and security ids was done. I don't get where this is coming from!
I've checked the user credentials on the Data Source. I've previously deployed projects to the same server with the same credentials with no problems.
When I google this problem, I get a lot of hits for things to do with Active Directory, but nothing that directly links to SSAS. Where does this error spring from?
This error occurs when there are users defined in a role that are either not known to the server (i.e. a local account on the machine the project was designed on) or no longer available in the Active Directory. To solve this:
Open the cube in BIDS / Visual Studio
Go to the Roles node in the Solution Explorer
Per role, go to the tab "memberships"
Per member defined, check to see if that member still exists in the AD.
In my experience, it's advisable not to use local users in Roles, nor personal accounts. Instead, grant the rights to a role to a group, then add and remove users to that group in the Active Directory as needed.