Azure DevOps Server 2022 (on-premise) AAD group members not updating? - azure-devops

We are evaluating Azure DevOps Server 2022, specifically using the Git repositories function. We require an on-premise solution due to some compliance requirements, which is why we aren't using Azure DevOps Services (cloud).
Something I can't wrap my brain around is application of new permissions. We configured some AD security groups and added to the appropriate DevOps groups. We have groups for Collection admins, project admins, build admins, and contributors. Everything looks great until we add a user to one of the groups. It seems the Azure DevOps server doesn't see membership changes until after an unspecified amount of time, sometimes as much as 24 hours.
My question is, why wouldn't group memberships be seen and applied with Azure DevOps immediately, and is there a process to force DevOps to check for and sync/refresh group memberships? Anything I find via a Google search always references Azure AD sync-related configurations, whereas our implementation is strictly on-premise using ADDS, not Azure AD.
Restarting the server and any related services.

TFS/Azure DevOps Server use a background synchronization job, scheduled every hour, to look for changes in Active Directory (or the local machine workgroup if the server is not domain joined). So, changes you make to local or Active Directory groups do not get reflected in TFS/Azure DevOps Server immediately. Instead, TFS/Azure DevOps Server will synchronize those groups regularly (by default every hour).
You can force the job to run using any of these techniques: How to synchronize TFS users with AD.
It could be that you still do not see the user or name listed in the UI even if synchronization is working. The synchronization job does not automatically create a user profile in the database for every user or group in the database, to avoid useless growth in big enterprises.
In such a case, the first time you use a new AD account (user or group), you must refer to it uses DOMAIN\account syntax so that TFS/Azure DevOps Server look up in AD on the fly and insert a profile record in the database for the account.
Further Troubleshooting Mr. Hinsh has a good troubleshooting guide if you still have troubles. It's still applied to Azure DevOps Server.

Related

connection between Azure devops and active directory

I've got an active directory and azure devops server 2020 on windows server . How can I connect the two? My server is not connected to the Internet.
Active Directory works with Domain Services. See Active Directory Domain Services Overview for details.
What you need is to join the Windows server which installs Azure DevOps Server to Domain. Please refer to Join a Computer to a Domain for details.
After that it will automatically sync with the corporate domain.
However, Azure DevOps use a background synchronization job, scheduled every hour, to look for changes in Active Directory (or the local machine workgroup if the server is not domain joined). So changes you make to local or Active Directory groups do not get reflected in Azure DevOps immediately. Instead, Azure DevOps will synchronize those groups regularly (by default every hour).
That's all required. After this, you could directly add domain users or groups to groups in Azure DevOps server.

Connecting an Azure Devops Server instance to AD

Sorry for the noob question - I'm a developer and don't know much about Windows administration. I'm upgrading from TFS 2017 to Azure Devops Server (onPrem). This will be on a new set of boxes though so it's not an in-plaee upgrade. Right now I'm doing proof-of-concept testing on a machine not on our domain so obviously I can't add users from the domain. My question is once I install Azure Devops Server on a machine on the domain will it automatically sync with the corporate domain? I've read that that happens once an hour - I'm just wondering if there's anything I need to install/setup to make that happen.
What you need is to join the Windows server which installs Azure DevOps Server to Active Directory.
After that it will automatically sync with the corporate domain.
However, Azure DevOps use a background synchronization job, scheduled every hour, to look for changes in Active Directory (or the local machine workgroup if the server is not domain joined). So changes you make to local or Active Directory groups do not get reflected in Azure DevOps immediately. Instead, Azure DevOps will synchronize those groups regularly (by default every hour).
That's all required. After this, you could directly add domain users or groups to groups in Azure DevOps server.
You can also try to force Azure DevOps Server to sync with Active Directory by following instructions mentioned in this article: How to synchronize TFS users with AD (Active Directory)?, it's still available for current Azure DevOps Server versions.

Azure Dev Ops restrict users from accessing repositories outside the organization [duplicate]

We've been told by Microsoft support that Azure DevOps Services supports tenant restrictions. While we have tenant restrictions enabled on a number of other services, it does't seem to apply to DevOps. Not only can we still log in to organizations outside of our tenant, we can also log in to our own organization and, if our corp email is added as a user in that org, the organization also shows up. I'd expect that our users would be blocked from logging into or accessing any external orgs.
I'm a little confused about why this isn't just working as expected and despite them saying Azure DevOps Services supports tenant restrictions, I'm not finding much documentation to back that up.
Have you been able to migrate to Azure DevOps Services and ensure that your users are only able to access orgs within your own tenant? How?
Azure DevOps Service supports the Azure Active Directory (Azure AD) tenant policy to restrict users from creating an organization in Azure DevOps. This policy is turned off, by default. You must be an Azure DevOps Administrator in Azure AD to manage this policy.
Check following link for more details:
https://learn.microsoft.com/en-us/azure/devops/organizations/accounts/azure-ad-tenant-policy-restrict-org-creation?view=azure-devops
Notice:
This policy is supported only for company owned (Azure Active
Directory) organizations. Users creating organization using their
personal account (MSA or GitHub) have no restrictions.
https://devblogs.microsoft.com/devops/policy-support-to-restrict-creating-new-azure-devops-organizations/
We finally received a more concrete answer to this question from Premier Support. Sounds like this wasn't entirely clear internally either. Azure DevOps Services supports TRv1 which provides tenant restrictions from client to proxy, but does not support TRv2 tenant restrictions which provides server to server restrictions. TRv1 will prevent you from authenticating against an org outside your tenant directly but does nothing to prevent the background authentication that happens if your account is configured to be able to access a secondary tenant's org. The server to server connection strips off the header information necessary to restrict you from accessing the secondary tenant. While this feature may be on their radar there is no expectation or firm timeline for it's release at this time.

Azure DevOps user migration

After a couple companies merge, we had to build up an AZ DevOps solution from scratch for the new business entity. Unfortunately, at that time we added some users from various companies under their original email addresses (reason: reuse of their VS subscriptions).
Now we need to migrate these users in Azure DevOps from their old bill.smith#oldcompany.com to their new bill.smith#newcompany.com without losing their work and settings. Afterwards the users should be able to log in with their new emails and see everything as if they would log in with their old addresses.
Any ideas how to solve this problem?
You need to open a support case and they can help you out. You get a excel file to map users between the domains and they can map them over in one go.
jessehouwing is right, if you want to migrate data to new Azure DevOps users, you need submit a support ticket here.
But there are something you need pay attention and get ready first:
Do not add them (bill.smith#newcompany.com) to Azure DevOps Service or let them logon to Azure DevOps Service. At this point
Azure DevOps Service support needs to migrate/transfer the users.
Provide a mapping list of users (old user > new user) to Azure DevOps
Service Support.
Azure DevOps Service will transfer identities to the new users. This should add the new account to Azure DevOps Service, assign work items to the new account, assign the Azure DevOps Service license to the new account , and remove the old account from Azure DevOps Service.

Moving a resource from an active directory to another within the same subscription

I have an Azure resource group under an Active Directory AC1 which I would like to move to another active directory AC2 within the same subscription. How can I achieve this using UI or powershell (or any other means)? To make thing easier I can forget all about the resource group itself and just for the sake of argument lets say I have a resource R1 in AC1 which I would like to move to AC2 within the same subscription.
How can I do this without recreating the resource in the destination directory?
So, given the way information is presented in Azure Portal one is led to believe that an Azure Subscription contains one or more Azure ADs which is not correct. From https://azure.microsoft.com/en-in/documentation/articles/active-directory-how-subscriptions-associated-directory/:
Every Azure subscription has a trust relationship with an Azure AD
instance. This means that it trusts that directory to authenticate
users, services, and devices. Multiple subscriptions can trust the
same directory, but a subscription trusts only one directory.
So to answer your question, you can move resources from one Azure Subscription to another provided both Subscriptions use same Azure AD as trust store. There's no automated way of moving resources from one Azure Subscription which trusts one Azure AD to a different Azure Subscription which trusts a different Azure AD.