Check (and modify) network drive mappings as an admin for other users
It does not appear that admins can check/modify a user's network drive mappings (e.g. from `\\server\shares` to a drive letter) via powershell? The various `Smb-` commands seem to be per user, and as far as I can tell, there is no way to run a powershell command as a different user without using their credentials (which seems to be poor security hygiene to ask users for their passwords), even if you are an admin. Am I missing something, or is this not possible? In case it helps clarify things, what I am asking about is the Windows equivalent to `sudo -u some_user some_command`.
Multitenant organization (MTO): user licenses
Hello everyone, As described https://learn.microsoft.com/en-us/microsoft-365/enterprise/set-up-multi-tenant-org, I have created an MTO. It seems to have worked because I can see users from tenant A in tenant B. Everything looks correct, as the users have #EXT# in their usernames, their type is “Member”, and their identity is “ExternalAzureAD”. BUT they are all unlicensed. My question: is there a way to synchronize the licenses of the users, or do I really have to purchase the same license twice for a single user? Specifically, I am interested in the following licenses: Microsoft 365 Business Premium (access to Teams, SharePoint, Exchange Online shared mailboxes, etc.) Dynamics 365 licenses (e.g., Business Central). Thank you very much for your assistance, and warm regards, Nico
Dynamic group membership rules stopped working
We've been using the following the following dynamic membership rule to check if a user is a member of another group: user.memberOf -any (group.objectId -in ['2b930be6-f46a-4a70-b1b5-3e4e0c483fbf']) The group is an Active Directory group that is represented in Entra with the stated Entra group object Id. The validation fails for every user and looks like this: It seems that all out dynamic groups are affected and stopped working. Have you seen this before? Thanks.
API-driven provisioning field mapping changes resynchronize all users and groups
We have configured API-driven provisioning for on-premises Active Directory, along with Azure AD Connect, to synchronize on-premises AD users with Azure Entra ID. As part of the provisioning setup, we have used a separate Organizational Unit (OU) in on-premises AD (designated as the default OU for new users) while configuring API-driven provisioning. We are attempting to make some changes to the API field mapping, specifically the ‘UserPrincipalName’ regular expression (custom domain) and the ‘manager’ field, and saving the configuration. Upon attempting to save, a prompt appears (as highlighted below screenshot), indicating that this action will resynchronize all users and groups. Could you please clarify: Will this resynchronization update any existing users outside the default provisioning Organizational Unit (OU)? Specifically, what does the resynchronization operation update? For instance, will it modify the 'UserPrincipalName' and 'manager' attributes for all users including old users outside of provisioning Organizational Unit (OU)? Screen Shot - While Saving Mapping.
Protect Tier 1. Sleep well at Night.
In case you have not yet protected Tier 0, consider reviewing our article about protecting Tier 0 the modern way. Tier 1 is more difficult to outline as there are typically different security levels, from highly critical (e.g. personal data or business secrets) to informative, or even public information. What remains the same is the “assume breach” approach: no matter which (Tier 1) system gets compromised, the infection must not spread. What causes us a lot of headaches is something we call “Permanently privileged Tier 1 accounts”: accounts which are members of the Local Administrators group on most (or even all) Tier 1 servers and left there indefinitely. This type of accounts draws attackers like moths to the flame, because by compromising a single account, attackers can gain full control of Tier 1. Optional Refresher: Lateral Movement (in Tier 1) In general, the term “lateral movement” refers to a group of techniques cyber criminals use to explore an infected network to find vulnerabilities, escalate and cement access privileges, and finally reach their ultimate target. It is called “lateral movement” because of the way the attackers move sideways from their initial point of entry to device, to application and so forth. The illustration below depicts how attackers move laterally across Tier 1: Attackers compromised T1-Server-01. Thanks to LAPS, lateral movement to other Tier 1 servers using the (local) Administrator account and password is unsuccessful. T1-Admin-01 logs on to T1-Server-01 to perform some administrative tasks, thereby exposing reusable credentials to the attackers waiting for their chance. Attackers steal reusable credentials from the server’s memory. Attackers move laterally to all T1-Servers accessible with the credentials stolen in step (3). Tackling the Security Challenge of standing Privileges Just-in-time (JIT) administration in Active Directory is a security practice that temporarily elevates user privileges only when needed, which massively reduces the risk of misuse. It works by granting privileged access for a limited time, ensuring that users can elevate only on a limited number of devices at the same time and are automatically removed from privileged groups after a defined period. By introducing JiT, we can get rid of identities which hold permanently privileged access to many systems at the same time. Let’s be very clear on this: JiT will not prevent a single server or account from being compromised, but it can prevent the attack from spreading by minimizing the window of opportunity for attackers to exploit elevated privileges. By limiting the duration and scope of privileged access, JIT administration reduces the chances of attackers moving laterally across the network and gaining control over critical systems. Due to complexity, pricing, and environmental overhead of many commercial JiT solutions, we were looking for an easier way to achieve secure JiT on a budget. The solution developed by Andreas Lucas and Andreas Luy is based on a PowerShell scripts, comes with a graphical user interface and is published on Github. So, what is still holding you back from protecting Tier 1? JiT on a Budget Please note: This is not an "official" Microsoft solution, but a project created and developed by people working in Microsoft Security Enterprise Services (which used to be known as Microsoft Consulting Services some time ago). The tool is written in PowerShell. Please review carefully before introducing in your environment. When doing that you will find some not yet documented features. We are working on improving the documentation. We also want to emphasize that implementing this tool is only one part of the journey to protect Tier 1 against today's attacks. JiT Configuration The configuration for the JiT solution will be stored in Active Directory. To make this possible an Active Directory Schema extension must be implemented. Even though most AD admins do not enjoy schema updates, AD turned out to be the perfect location for storing the JiT configuration: it is highly available by default, is less likely to be messed up (or even deleted) than config files. The solution uses an Active Directory object to save the general JiT configuration (like OU locations for T1-Servers or maximum allowed elevation time). In addition to that, an individual object is created for each T1-Server and a Container is used to hold individual objects for allowed delegations (in other words: which user is allowed to request elevation on which server/OU). JiT Automation After the JiT solution has been installed and configured, a Scheduled Task will be running on the JiT Management Server every few minutes (step 1 in the illustration below). This task runs in the security context of a gMSA (group Managed Service Account) and monitors Active Directory for newly added Tier 1 servers (step 2). In case a new T1 server is found, the Scheduled Task creates an individual AD group for each new Tier 1 server (step 3, e.g. T1-Admin#Server-01). The group is automatically added to the according Tier 1 server’s (local) Administrators group through Group Policy (step 4). All these “Jit administrative groups” created are Tier 0 groups and cannot be modified by Tier 1 assets. At this point no T1-Admin is yet a local Administrator on any Tier 1 server. T1-Admins who want to self-elevate to local Administrator on a Tier 1 Server, must log on to the JiT Management Server (step 1 in the illustration below). Please note that the JiT Management Server is classified as a Tier 0 system. There they start a PowerShell-based elevation UI Tool and select the Tier 1 Server they want to request elevation for (step 2). A Scheduled Task running in the security context of a gMSA then adds their T1-Admin account to the T1 Server’s specific domain group (e.g. T1-Admin#Server-02) together with the requested time-to-live (TTL) (step 3). Now the T1-Admin-01 is an indirect member of the (local) Administrator’s group on the T1-Server-02 and can log on to this server to fulfill his admin tasks (step 4 in the illustration above). After a defined time span (TTL), the Privileged Access Management (PAM) optional feature ensures that the T1-JiT-Admin’s account is removed from the T1-Admins#T1-Server-02 group. In addition, the gMSA-based task ensures that the Jit-Administrator Groups will not contain ANY permanent membership in the (local) Administrators groups. The PAM optional feature essentially unlocks two new capabilities in the AD Forest: Temporary time-based group memberships, and shadow principals. Both were introduced to allow the implementation of a Red (or bastion) Active Directory Forest, using a MIM (Microsoft Identity Manager) for requesting temporary privileged access. However, our JiT solution only leverages the former to ensure that after the specified time has elapsed, the user will be automatically removed from the security group (without administrator intervention). Find more information about possible drawbacks when enabling the PAM option feature, check out our colleague's blog: https://ryanries.github.io/?title=possible_performance_pitfall_privileged_access_management.html Let’s get started Now is the time to protect Tier 1. For too long, this critical layer has remained vulnerable—not because it’s unimportant, but because safeguarding it seemed too complex or resource-intensive. That’s no longer the case. With a simple and effective solution now available, there are no more excuses. Protecting Tier 1 is not just a technical necessity—it’s a strategic imperative. Let’s take this opportunity to secure what matters most, before it’s too late. The code and detailed documentation are provided at https://github.com/Kili69/Just-in-time.Unable to add Azure Virtual Desktop Client Enterprise App to Conditional Access
We currently use conditional access to allow certain contractors to sign into VMs, and from these VMs, access other MS Apps. Currently we block all applications from outside the VM ip range, but exclude the Virtual desktop applications to allow the users to do the initial signin to the VM. When contractors are using the Virtual Desktop app, it seems to work ok. However, recently when signing in via the browser only and launching from there, the conditional access rule is blocking them as the application ID isn't in the exclude list, and we are unable to add it: a85cf173-4192-42f8-81fa-777a763e6e2c The documentation: https://learn.microsoft.com/en-us/azure/virtual-desktop/set-up-mfa?tabs=avd shows that web signins may originate from this application ID, but without the ability to add this to the exclusion apps, we cannot find another workaround that allows access via the browser. I also tried adding this app in to the policy via GraphAPI, but I get an error saying that this first party application isn't allowed. I need to know if there is another workaround or if Microsoft are planning to add this to the CA compatibility list? I'm not sure why some of the Virtual desktop apps are there but this one is not.Access rights on domain controller
<p> I have three support team members, and I want to restrict their permissions so they only have rights to join computers to the domain and install software. Currently, someone from the team is frequently changing permissions, leading to confusion and blame-shifting. I’d like to prevent this by properly delegating roles. We are using on-premises Active Directory with Windows Server 2022, and all users authenticate via the domain controllers. Could you please guide me on how to set up these specific permissions? I tried delegations but had no luck. </p>
Entra ID Connect cloud sync: User and group sync is quarantined
Hi, I connected our on-premise AD with Entra ID with Azure AD Connect Cloud Sync. Agents are active, but User and group sync is quarantined with the following error. Error code: HybridSynchronizationContainerStateEnumerationFailed Error message: We were unable to process this request at this point. If this issue persists, please contact support and provide the following job identifier: AD2AADProvisioning.... Additional details: Encountered an error while enumerating container changes in the provisioning agent. Please make sure you are running the latest version of the agent. Contact support if the issue persists. Additional Error Details: UnwillingToPerform: The server cannot handle directory requests.. ResultCode: UnwillingToPerform, HResult: -2146233088, responseType: System.DirectoryServices.Protocols.SearchResponse, serializedResponse: {"MatchedDN":"","Controls":[],"ResultCode":53,"ErrorMessage":"error in module dsdb_paged_results: Unwilling to perform during LDB_SEARCH (53)","Referral":[],"References":[],"Entries":[],"RequestId":null}. I use SaMBa servers (4.19.4) as DCs. Agents are installed on Windows 2019 servers. How can I resolve the problem?
Adding AD users to a specific security group
Hi Everyone, Sorry if this question has already been asked as I couldn't find an answer. I’m trying to write a PowerShell script that runs as a scheduled task to add AD users to a specific AD security group. The goal is for this to run daily. The script will first check the users' OU to determine if they are already members of the security group. If they are, it will skip them; if they are not members, it will add them to the group. I have created the following script, but I’m unsure if it's the best approach. Additionally, can this script be executed on a server that doesn’t have Active Directory installed? If AD must be installed, would it be ideal to run it on a Domain Controller? # Check if Active Directory module is already imported, import only if necessary if (-not (Get-Module -Name ActiveDirectory)) { Import-Module ActiveDirectory } # Define the base OU and security group $BaseOU = "OU=W11_USERS,DC=W11,DC=NET" $SecurityGroup = "HR" # Get all users from W11_USERS and its sub-OUs $Users = Get-ADUser -SearchBase $BaseOU -SearchScope Subtree -Filter * # Loop through each user and check group membership before adding foreach ($User in $Users) { $UserDN = $User.DistinguishedName # Check if user is already a member of HR $IsMember = Get-ADGroupMember -Identity $SecurityGroup | Where-Object { $_.DistinguishedName -eq $UserDN } if (-not $IsMember) { Try { Add-ADGroupMember -Identity $SecurityGroup -Members $User -ErrorAction Stop Write-Host "Added $($User.SamAccountName) to $SecurityGroup" -ForegroundColor Green } Catch { Write-Host "Failed to add $($User.SamAccountName): $_" -ForegroundColor Red } } else { Write-Host "$($User.SamAccountName) is already a member of $SecurityGroup" -ForegroundColor Yellow } } Write-Host "User addition process completed."
