Closed. This question is not about programming or software development. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 7 days ago.
Improve this question
I have an issue where Windows Server Service Accounts [on prem] are not syncing with Azure AD to Azure VM server.
Currently have a VM in Azure and AD on prem which syncs with AAD.
All user accounts sync but not Service accounts.
My question is what are Azure equivalent for Windows service accounts if those type of account cannot sync? Can we use user/system-assigned managed identity instead? If so..how? And lastly how will we see this managed identity in the Azure VM?
I am new to AAD so any help would be appreciated.
I have created a user-assigned managed identity but cannot see this as a type of service account in the VM. It is not appearing in Active Directory in the VM in Azure.
I tried to reproduce the same in my environment to sync service Accounts on -prem to Azure AD
I created a service account on-prem like below:
Add-KDSRootKey -EffectiveTime ((Get-Date).AddHours(-8))
add-kdsrootkey -EffectiveImmediately
Get-KdsRootKey
New-ADServiceAccount –Name gserviceaccount1–DNSHostname DC1.comptech.com –PrincipalsAllowedToRetrieveManagedPassword "gserviceaccount1Group"
Note that: Azure service accounts are specific to the Azure platform and are not associated with an on-premises Active Directory. Synchronizing an Azure service account from an on-premises AD to Azure Active Directory is not possible.
Service accounts shouldn't be members of any privileged groups, because privileged group membership confers permissions that might be a security risk.
My question is what are Azure equivalent for Windows service accounts if those type of account cannot sync? Can we use user/system-assigned managed identity instead? If so..how? And lastly how will we see this managed identity in the Azure VM?
You can use user/system-assigned managed identity for that In your Virtual machine -> undersetting. click identity -> status on like below:
In your subscription or any service click Access control (IAM), choose assign access as Managed identity and select your vm members like below:
Reference:
Active Directory service accounts - Microsoft Entra | Microsoft Learn
Related
We have an application which is hosted on the on-premises Windows server (IIS) server
now I created a windows server on azure and building a web app for it.where the application needs to authenticate the user by windows server (DC) using kerbrose protocol but I couldn't find any documentation regarding this from Microsoft's side
Is the above query possible to be implemented in the azure web app?
No, it's not possible. Windows Authentication is something for on-premise deployments. For Azure Web Sites Azure Active Directory is clearly the best option. Sync from AD to Azure Active Directory is also quite easy to setup.
If you still want to absolutely use Windows Auth and host your website on Azure, you can create Windows VM and host your website there. You then need to join the VM to your AD. To this, both VMs must be in the same network. So if your VM is on-premise you will need to create an site-to-site VPN.
For more information, follow this SO which also discussed about this.
If your intention is to join the VM hosting the website to a domain then as others have mentioned, this isn't possible.
However, doing Kerberos authentication itself within an Azure website isn't particularly difficult, but it does require manual implementation. Windows natively handles all of this for you on domain joined machines and and IIS exposes that functionality. Since you can't domain join you have to manually do all that heavy lifting and request and validate the tickets yourself.
This involves creating a service account in Active Directory and keeping the account password in sync. Once you have that you need to indicate to the browser that it needs to negotiate auth, which is done with the WWW-Authenticate: negotiate header on a 401 response. The client, if configured to send tickets, will send a ticket in the Authorization: Negotiate YII... request header on a subsequent response. At this point you need to shove that negotiate header and that original service account password into something that can validate Kerberos tickets. Windows SSPI will do this for you, but it's a pain. I built a library that'll do this for you: Kerberos.NET. YMMV with what works best for you.
All of that said, it may be more beneficial to switch over to a more modern authentication mechanism like OAuth/OpenIDConnect/SAML.
There are several ways depending on if you have to allow access to users who are associated with a on-premise Active Directory or not.
You should have a look at this service: https://learn.microsoft.com/en-us/azure/active-directory-domain-services/
It will offer an Active Directory within Azure where you can domain join your VM to and then using Kerberos as authentication protocol (should work the same way like on prem).
The other option would be to create a new Active Directory within your Virtual Network (via 1 or 2 small Windows Server VMs where you create the AD).
The good thing if you are using Active Directory Domain Services would be that you could extend it to your on-prem Active Directory by synchronizing or federating your on-prem AD.
There are more informations regarding these scenarios here:
https://learn.microsoft.com/en-us/azure/active-directory/hybrid/whatis-hybrid-identity
For a Azure App Service - Web App you would connect it to your Azure Active Directory (AAD) and use the hybrid identity model to allow users who originate from an on-prem AD access to it:
https://learn.microsoft.com/en-us/azure/app-service/configure-authentication-provider-aad
Hope this helps a bit, it is a rather complicated topic you are digging into.
We have almost 16 users in our Azure DevOps Organisation. I am having the admin privilege for the azure account. I saw a few blogs regarding Active Directory Enabling method and all. But it was not clear.
How can we manage this restriction in Azure DevOps.
NB:-Our users are accessing Azure DevOps through their outlook account.For ex:-sample.orgnization#outlook.com
Depending on your setup, there are a couple of options:
Azure DevOps configured as MSA backed with AAD guests in Azure DevOps
When your Azure DevOps account is configured to be backed by Microsoft Accounts (formerly Live IDs, or Outlook.com or Hotmail.com), it can add Azure Active Directory users as guests into the account. This feature was added last autumn.
In this configuration, you can invite AAd and MSA users directly from Azure DevOps and the MSA users don't get any access to the Azure account.
Azure DevOps configured as AAD backed with MSA guests in Azure Active Directory
When your Azure DevOps account is configured to be backed by Azure Active Directory, it can only add users who are known in Azure Active Directory. However, you can invite Microsoft Accounts into your AAD as guests. You can even invite users from other AADs as federated guests.
In this configuration you can only invite users who are known by AAD into you Azure DevOps account. If they're not in AAD, you'll have to invite them into AAD first.
Switching
You can switch the account between the different association modes. To migrate existing users from one type to another (AAD->MSA, MSA->AAD) you currently need to open a support request to get all of the users mapped over. In this scenario you get an excel export from your account and you provide a mapping between the old and the new uesr account. Support will mapthem for you.
Manual process
You can also take a manual approach. This model isn't well documented. And when manually mappign you'll have to re-apply the security permissions manually as well. As such, thsi approach isn't recommended.
Once in AAD
Once your users are all in Azure Active directory, you can set policies on their access patterns, restrict IP addresses, require 2FA tokens and such. The value is questionable for external users as it won't work for all guest types. It will be valuable for your own users. You can enforce policy on users in your AAD. It's recommended to work with your federation partners to ensure that they're also using the right policies for their own users.
I think this will help you, I also faced the same problem which I mentioned, this article explained in details very clearly that how we can apply 'Conditional Access Policies' to avoid unauthorized access on Azure repositories(Code). after apply the policies on Azure portal, We need to enable the option on dev.portal Enable Conditional Access for Azure DevOps, Hope this will helps you.
I am curious to know why we always need to register our CRM online instance on an Azure Active Directory in order to authenticate the Web API while accessing from outside CRM domain.
That is, for example, if I need to access CRM online instance through another website using CRM's Web API endpoint, then I must register my CRM instance to Azure Active Directory.
Though I am aware that, its a very nominal charge to create an Azure Active Directory, still I would need to subscribe to Azure even if I just want to perform some general research for CRM connectivity through Web API.
Why this is must? Are there any security considerations behind this?
Why can't we use the same authentication mechanism as we used to do with Organization service?
Any details on this will be much appreciated.
The CRM WebAPI uses OAuth2 and Azure AD is the only currently supported authentication platform to provide this (Windows Server 2016 will support OAuth2 for on-premise).
The Organisation service is a WCF service and as such uses SOAP for authentication and authorization. This is an entirely different technology stack that brings it's own set of problems, many of which the OAuth2 protocol tries to solve in this scenario.
Although you manage your CRM Online users through the Office 365 portal the underlying technology for these accounts is also Azure AD. Check if you can use this existing AD tenant created as part of your subscription rather than having to create another.
If you are using CRM online you already have aan Azure Active Directory. If you haven't already done so, you can signup for an Azure subscription and import the underlying AAD into your Azure subscription. You will need a credit card, but as far is I know using the Azure AD is free.
This page states that before an application can access the API (I'm particularly interested in the Calendar API), it must be registered with Azure AD. Is this also true for organizations that may host their own Exchange servers?
Could someone provide a breakdown of what's necessary for me to get started with accessing the API to access the users' Calendar? I'm aware of the API reference, but I'm not entirely sure what's necessary to do before I can use the API.
That page is for Office365, not self hosted ones.
You can access your local/self hosted Exchange server with Exchange Web Services by using username/password, or even your local AD if you set it up correctly.
The API it is talking about is not available to on-premise Exchange Server, it is only available to Exchange Online in Office 365. This may change in the future, but currently you cannot use it in on-premise. Exchange Web Services is the way to go for on-premise.
I am very new in TFS 2010. I have setup my PC as server. I need to connect the client machine with this server. I have added a Service Account in TFS console. The client machine are connected with this account.
Now, my question is that, is the Service Account is intended to connect the client with server?
Can anyone explain me the purpose of this account?
Also I need to know, how to find(or setup) the TFS admin?
Are you referring to the "TFSSERVICE" service account from the installation guide? That account is used to run various services related to TFS, for example the TFS Task Scheduler. It should have the minimum privileges possible on the machine.
The client should not connect to the server with a service account, they should be using their own account which you grant access to the relevant repositories in TFS. If you connect all clients with the service account, how will you know who checked in each changeset?
You might find the installation guide of use which can be found here. See section entitled "Accounts Required for Installation of Team Foundation Components".
If you are using a domain, you should be able to follow the instructions in this article for how permissions work in TFS. You can allocate permissions to resources from the Team Explorer pane within Visual Studio.
If you're using TFS in a workgroup then it's a little different as you need to set up local accounts for your users. See this article.