We're trying to lock down our service accounts as much as possible.
Does an Active Directory Service Account need Remote Desktop access?
What's the minimum permissions an AD Service Account would require?
The minimum permissions an AD service account needs are the minimum permissions to do the task that you've created the service account to perform.
If you created the service account so it can RDP into another machine and do something, then yes, it needs RDP access.
If you are not using it to RDP to another machine, then no, it doesn't need RDP access.
It's up to you to decide.
Related
I know that I have to create a service principal when I need an identity for an app that connects to Azure resources. But if someone asked me "Why not just create an AAD user and authenticate as that user?" I honestly couldn't answer besides "That's not how you do it.".
Can someone give me a proper explanation on why using an AAD service user instead of an app registration would be a bad idea?
Service principal is an application whose tokens can be used to authenticate and grant access to specific Azure resources from a user-app, service, or automation tool, when an organization is using Azure Active Directory
By using a Service Principal, we can avoid creating "fake users" (similar to service account in on-premises Active Directory) in Azure AD to manage authentication when you need to access Azure Resources
The Service Principals' access can be restricted by assigning Azure RBAC roles so that they can access the specific set of Azure resources only
So for better security purpose, we can use service principal instead of Azure AD User from an to authenticate and access Azure Resources.
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 have set up a Mediawiki for our small local domain (abc.local) on a linux VM (just for internal use). Our local domain controller is a Win Server 2008 R2. I've setup the Mediawiki LDAP Authentication extensions so that i can restrict editing of our Wiki to only domain Users. I've configured the Mediawiki LDAP configuration to use the domain Administrator credentials for this authentication.
Is there a way to create another account that can do this user authentication but can't change anything? Sort of like a "read-only" Administrator account?
thanks,
russ
An account can't be "read-only" and also "Administrator". It's one or the other.
"Authentication" can only ever be done with the user's own credentials. There is no special kind of account that lets you authenticate other accounts. All it needs credentials for is to look up accounts on the domain. So you only need a read-only account, which is basically any account that can authenticate on your domain.
So just create an account specifically for Mediawiki and use that.
I am creating a Service account for a domain in the AD. The user is created under Managed Service Accounts. But from any server, when the user is used to start a service, I get a logon failure.
What is the rigt procedure to create a Service user on AD with only logon as a service right?
What groups should the user belong to, to have logon as a service right?
Any AD user account can be a service account. It's how it's used that makes it a service account.
The "Log on as a service" privilege is a Group Policy setting that must be granted on each computer where it is needed. You can either do this in a Group Policy on the domain, or on the computer itself by running "gpedit.msc". You'll find "Log on as a service" under:
Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> User Rights Assignment
More information here: https://learn.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/log-on-as-a-service
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