I've inherited a mess from the IT "professional" I replaced and have been unable to successfully lobby for resources to setup a proper domain. I have Windows 10 PC's that are configured as "organizational" PC's not Personal, which allows our users to sign-in with their office365 accounts.
However when they do this they are logged in via AzureAD\ Domain, I'm certain this is the reason they cannot access the shared drives my organization has been using. I would very much like to keep using this AzureAD setup but if I cannot access local network resources it won't work for me.
I've searched around but maybe I haven't been asking the right question to find a solution to my problem, or it's possible one doesn't exist which would be unfortunate.
Has anyone ran into this issue?
Is there a way to access non-AzureAD domain resources from an AzureAD\User Account?
You will need a DC (a virtual machine (VM) in the cloud or a physical server).
That DC has Azure Active Directory (AAD) Connect installed and configured on it. That creates an account in AD that synchronizes accounts and passwords with AAD.
When a computer joined to AAD logs in it sends the login request to AAD. AAD then validates that authentication request against the information synchronized from AD.
If you have workstations and laptops joined to AAD and they try to access a share on a server that is in a different domain than what AAD synchronizes with you are going to need to provide credentials that exist in the server which hosts the resources, you are trying to access.
There are a few right ways to do this as,
If the clients are in a single location and will always be in the same location as the DC then join them to the domain regularly. For clients that will be used in other locations join those computers to AAD and install AAD Connect in the DC.
If you want to move all the servers out of your office spin up a VM for your DC in Azure and deploy a cloud firewall in front of your VM. Create a Site-to-Site Virtual Private Network (VPN) between the cloud firewall and your office firewall. Now join computers that will always be in the office to the domain like normal, join computers that are going to be used remotely to AAD, and install AAD Connect on the DC.
Refer: Windows 10 AAD Azure ad domain joined & SMB share, where similar discussion has been done
Related
i have configured kerberos authentication when accessing to file server.
there is no need for logging in when i map drive and acccess to the file server
Just a curious question, if i can add additional server name to be used for authentication
for example.
currently my file server name is server01
when i map network drive through server01 / IP address, there is no issue.
when i tried to access through a server name server02, then i get an error in mapping the drive.
is there any way i can do this by allowing multiple server name to be allowed for kerberos authentication ?
thanks in advance for any advise
You can map as many file shares as possible you want with Kerberos authentication on a Windows domain joined system if the file servers hosting the file shares are joined to the same domain as the client Windows system accessing them.
Thus, you may have multiple file servers in your domain environment but they all should be joined to the AD domain for the Kerberos authentication to work successfully and let the users accessing and mapping the file shares authenticate through it as Kerberos needs a KDC (Key Distribution Center) due to which Active Directory authentication is required.
Please find the below dependencies for Kerberos authentication to work successfully: -
Operating System --> Later then Windows 2000 for client and Windows 2003
TCP/IP Network Connectivity --> Should exist between DC, client, and the target server
Domain System --> DNS must be functioning and accessible for the client
Active Directory Domain --> Necessary to use Kerberos authentication
Time Service --> Time source should be same and synchronized on all the network computers
Service Principal Names --> Kerberos authentication needs to have an SPN set for it so that clients can identify the service on the network
Also, refer this document for more details.
I have mounted an azure file share on an azure VM using access keys ,the VM is not doman joined with the azure active directory instance.Please let me know if below scenario's will work out:-
If i apply acl's on the folders and sub folders will the acl's be
enforced in the mounted drive on the VM?
Will AZURE RBAC apply if someone tries to upload a file from the VM?
Note:- The Azure VM is on a VNET which has access to azure active directory.
Any information/answer/suggestion on the above questions would be greatly appreciated.
ACLs can exist for domain or non-domain accounts. Having a machine that is not domain joined, can obviously not set domain ACLs. So in that case local-server ACLs is all you can hope to get.
If another server mounts the share, and there is not another local user account + SID mapping, then there is no way these ACLs have any meaning on the second machine. But they will be enforced.
So that one will work albeit questionable in terms of usefulness.
RBAC is really a management plane construct. Meant to govern who can manage which Azure resource --> not access which data planes. Now in the case of AD / AAD DS support for Azure file shares, the team has decided to "stretch" the meaning of RBAC to govern share-level ACLs via Kerberos (where normal RBAC is OAuth only!)
Enough of the backend: What this basically means, is that there can be no support for local server accounts.
THese accounts only exist on a local server, not in AAD and certainly not DIRSYNC'ed from on-prem AD into AAD. So that means RBAC cannot work for local accounts, only for domain accounts.
I'm unclear what your scenario is.
A user coming into the server with some sort of local user credential?
Then creating/copying a file into a mounted Azure file share to that VM? --> That can work because there is no RBAC and since this is all happening through that single server that has that local user account, ACLs for these local accounts work natively.
A user coming into the server with a domain cred? --> will not work as the server isn't domain joined.
A user coming in with a local-server account and then using the Azure file share not via SMB mount but by going to the Azur file share directly: Cannot work because it's not a domain account and non-dimain accounts cannot work against Azure file shares. You'd use the srtorage access key to mount the file share to the VM, then you have access and leave auth. to the server with the set of local accounts.
Before you enable Azure AD over SMB for Azure file shares, make sure you have completed the following prerequisites:
Select or create an Azure AD tenant.
You can use a new or existing tenant for Azure AD authentication over SMB. The tenant and the file share that you want to access must be associated with the same subscription.
To create a new Azure AD tenant, you can Add an Azure AD tenant and an Azure AD subscription. If you have an existing Azure AD tenant but want to create a new tenant for use with Azure file shares, see Create an Azure Active Directory tenant.
Enable Azure AD Domain Services on the Azure AD tenant.
To support authentication with Azure AD credentials, you must enable Azure AD Domain Services for your Azure AD tenant. If you aren't the administrator of the Azure AD tenant, contact the administrator and follow the step-by-step guidance to Enable Azure Active Directory Domain Services using the Azure portal.
It typically takes about 15 minutes for an Azure AD DS deployment to complete. Verify that the health status of Azure AD DS shows Running, with password hash synchronization enabled, before proceeding to the next step.
Domain-join an Azure VM with Azure AD DS.
To access a file share by using Azure AD credentials from a VM, your VM must be domain-joined to Azure AD DS. For more information about how to domain-join a VM, see Join a Windows Server virtual machine to a managed domain.
Note:Azure AD DS authentication over SMB with Azure file shares is supported only on Azure VMs running on OS versions above Windows 7 or Windows Server 2008 R2.
Select or create an Azure file share.
Select a new or existing file share that's associated with the same subscription as your Azure AD tenant. For information about creating a new file share, see Create a file share in Azure Files. For optimal performance, we recommend that your file share be in the same region as the VM from which you plan to access the share.
Verify Azure Files connectivity by mounting Azure file shares using your storage account key.
To verify that your VM and file share are properly configured, try mounting the file share using your storage account key. For more information, see Mount an Azure file share and access the share in Windows.
I’ve recently been asked to look at a sync issue with Azure AD, however the guy who set it up has left and we have no idea where it’s configured from (AD Connect server) and what it is actually synchronising.
We also want to start synchronising our PP domain to the same AZure AD tenant, is that possible with not knowing what is being synced already and how would I resolve any conflicts, so confused!
Hope someone can help
Thanks in advance
Yes, absolutely it is possible to sync multiple domains. the easiest way to to know what is synced is by opening the azure ad connect "synchronization Service" app elevated as administrator. if you click the connectors, tab you will see what domains / forests are configured to sync. I would use the wizard to config more forests / domains.
Here are the supported topologies: https://learn.microsoft.com/en-us/azure/active-directory/hybrid/plan-connect-topologies#multiple-forests-single-azure-ad-tenant
Note that there can only be one azure ad connect syncing to a tenant at any given time, you cannot use multiple aad connect servers for that purpose.
Helo all,
I am trying to setup Azure AD connect for an Enterprise. They have local active directory on "internal.theirdomain.com", with local server DNS being setup for that too.
However in their Azure AD they have some accounts already under "theirdomain.com". This active directory has 3 domains associated with it: theirdomain.com, internal.theirdomain.com and theridomain.onmicrosoft.com where the first one is the primary.
I installed the Azure AD connect and set it up on the local server handling internal.theirdomain.com and after sync this happens:
local accounts go to Azure with ".internal.theirdomain.com", but accounts in the cloud are not downloaded.
Also, upon assigning a license to the accounts uploaded their email address is sent from "#theirdomain.onmicrosoft.com" while emails sent from their cloud accounts is sent from "#theirdomain.com". Do you happen to have any ideas on how to fix these:
have cloud accounts synced to local AD
have default email domain be "theirdomain.com" for all accounts
The one problem I can see for now is that "internal.theirdomain.com" is not resolvable from internet. I am adding that into their internet DNS but was wondering if you have any other tips.
Thanks a lot
My small company (about 100 users) is currently using Office 365. There have previously not been any domain controller. I am building an on premise domain controller and want to sync it with Azure Active Directory (Office 365). I used the sync service, with a small subset of users to no avail.
My main question: Can you sync FROM an Azure Active Directory to a new on premise Active Directory? My understanding is that it's the opposite - the on premise Active Directory is the "master" if you will. Is there a way to set it up the opposite? As in, Office 365 being the "master" or "seed" for an on premise?
At present, the Azure AD connect support the Password writeback, Group writeback and Device writeback.
You can refer the options features of Azure AD Connect from here.
At this point in time, synchronizing users FROM Azure AD to on-premises AD is NOT possible.
As Fei Xue pointed out, there are certain things (such as user passwords, groups and devices) that can be synchronized back to on-prem AD, but not users.
Depending on what you are trying to achieve, Azure Active Directory DS might be worth exploring as it allows you to create a VNet in Azure which has a AD-like support (LDAP, Active Directory domain join, NTLM, and Kerberos authentication).
More info on Azure AD DS: https://azure.microsoft.com/en-us/services/active-directory-ds/